Agile Semiotics – Step one

The steps to heaven.

An AS primitive.

Build an Overall Model and Test Plan

This is a project-wide activity it includes domain experts, members of the requirements engineering, business analysis, development and test, teams and is chaired by the Application Architect, the System Designer or the Data Scientist (the chair is the person who has the overview of the project regardless of their title it is the big picture person).
The stages are:

  • A very high-level walk through of the scope and context of the system.
  • A high level acceptance test plan describing what the system will deliver.
  • Creation of a domain model.
  • A list of the areas of the domain that will need a more detailed walk through.
  • Peer review of models and unit tests.
  • Merging of unit tests and models back into the overall domain model
  • Plan the next iterative updates where all of the above steps are refined.


The System

The System may be a single application but if so it will be an application within context, that is it is an application with users, or an application with other applications, it could be applications with data or knowledge or an application with a process or processes. It may be a software that enables a bunch of processes that are described by or achieved through other software. More than likely it is a combination of business rules, users, software applications and data, it will have inputs and outputs, it will perform operations. On occasions we may refer to the system and on other occasions we may refer to the application, as in “The system will provide reports that can be ordered by users”. On other occasions we may refer to an application as in “The application will allow users to log in using a user name and password”.
The outcome of the high-level walk through is a domain class diagram or diagrams, as in figure 1, which relates to a system that a staffing company may require. As I spent quite a few years working with a business in this sector I will use examples from systems we developed by way of illustration.

fig 1
fig 1

The main domain objects may at this stage be simply definitions of the processes that the client company has to carry out. These could be decomposed into specific operations as in figure 2.

fig 2
fig 2

The scope of the project may also be described by taking a single operation and looking at that in detail and seeing how it is associated with other operations, as in figure 3.

fig 3
fig 3

Looking at the code that describes the operation

 class Selection {
 private $contract;
 private $rate;
    private function createContract(){

    public function getRate(){
    private function addRate(){

provides the first test case.

protected function setUp() {
parent::setUp ();
 $this->Selection = createContract();

When the first test case is written it is a good time to stop  and review everything that led up to this point because now the actually system exists. By identifying the processes, and the operations within them, we can ask who performs these operations. In other words we are now discovering who the users of the system are and it is time to ask where should we begin recruiting  further domain (subject matter) experts from? In our illustration this is beginning to tell us we need some experts from sales, recruitment, resource management, compliance, account management, finance etc.

Some areas that need a more detailed walk through have now been identified and the modelling teams can, if required, break out into distinct groups based on subject or system areas. For example in the illustration we are using there may be three areas of grouped functionality; Customer Management, Service Management and Finance. These areas (domains) may then have distinct audiences and users within them and may be serviced by distinct software and data requirements and distinct applications to fulfill their needs.

Another aim of the detailed domain walk through is to find out how domain objects are associated to each other, how do groups of functionality join up and how do feature sets relate to one another.

domain class showing associations
Domain class showing associations

Having visualised the associations any structural problems with the architecture should begin to emerge and solutions to these can then be included into the model. For example the need to gather data from different data storage locations through different applications could emerge from writing the user acceptance test for a credit control feature, and from this service layers would be added to the model. Now at this stage we are not specifying how the system is being built we are describing the functionality and listing the features so we do not need to specify SOAP or REST or whatever merely that a service is required.

Application service and data layers
Application service and data layers

Without the UAT test case the model may not have had to be refined to include services at this stage. This is an example of where building tests into the very early stages of designing can influence the model at the outset.


UAT test case
UAT test case

So from the first session we have created some artifacts, a sketchy domain class diagram, a line or two of pseudo code, a unit test and a test case. The domain class will not be neat UML’s like the ones included above but white board gestures and scribbled notes incoherent ramblings and stream of consciousness drawings, not things to be seen by the light of day but from the from these creatures in the swamp we will derive a system.


One thought on “Agile Semiotics – Step one

Leave a Reply to SutoCom Cancel reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s