Problem Domain Analysis
Contents
What
The architecture can initially be expressed as a block diagram with very few details. For SW only projects UML, class diagrams, deployment diagrams, etc can be used. For mixed projects SysML block diagrams are more capable. The remainder of the document will use the term block diagram or architecture diagram.
Blocks responding dynamically shall also have either a State Machine Diagram or an Activity Diagram depicting the dynamics in the object.
How
The Dish
A block diagram with a brief description of each object and its responsibilities.
Diagrams depicting the dynamics of blocks with dynamic states.
Ingredients
Process
Inspect already-captured requirements, and extract candidates for objects and events.
Inspect the Rich Picture, the Storytelling and Preliminary Use Cases it often contains candidates for objects and events.
Assess the candidates, and draw the necessary block diagrams and other diagrams depicting the dynamics in objects which respond dynamically.
Why
Definitions
Problem Domain: The part of the environment which the system-to-be should control or administer.
Usage Domain: The users and other systems that control or administer a problem domain.
Block: A block defines an object's interface and implementation. It specifies the object's internal representation and defines the operations which the object can perform. Software developers can easily see the analogue class in this description. In SysML, the Block is a specialised UML Class.
Object: A run-time entity (HW or SW) which packages both data and the procedures which operate on that data. However, also something physical or artificial existing in the environment.
Event: An instantaneous occurrence which will influence one or more objects.
Domain Model: An object model of the domain which incorporates both behaviour and data. This will become the heart of the system-to-be.
Description
One of the first tasks is to create a model of the environment. Not the entire environment, but those parts which are needed in order to fulfil what the system-to-be is required to do. We will do this by analysing the Problem Domain.
Taking the system-to-be's point of view, we need a representation of the environment in the system, often called an abstraction of the environment. Only the parts of the environment which make sense for the system-to-be should be represented. If, for example, the system-to-be shall control a heating system, a representation of the outdoor and indoor temperature is good representatives from the environment to be candidates in the system-to-be. Early in the process the temperature is good to note. At the end of the Launch Phase, considerations about how to measure and represent the temperature will be done, possibly, leading to extra blocks and/or classes of which some may be hardware and some may be software.
In the early phases of the analysis, we use the general term and figure element Block to represent the object in the environment which shall be abstracted into the system. The block represents objects in the environment where the object can be a very abstract interpretation of the physical world. Temperature can be represented as a block. At this point in the analysis, we do not know how to retrieve the temperature or how to represent it in the system. All that is interesting at this point is that a representation of the temperature in the operating environment is needed. How to realise this is left until later in the process.
Finding candidates
An open-minded approach using brainstorm-like processes suggesting candidates to be represented in the system leaves the developers with a gross list to pick from when modelling the first block diagram.
It is important to be open-minded in the process of finding candidates. Do not judge the candidates while collecting them from the sources. The judgement will be relevant later when you compose the actual block diagram.
The result is a list or a table with candidates of which some may not survive in the final block diagram. Bear in mind that if you do not have enough candidates from the beginning, you may not have enough of them later in the development process.
After having produced a gross list of candidates to the block diagram, it can be helpful to also produce a list of candidates of important events in the environment which the system-to-be must react on. This results in the first descriptions of the dynamics in the system.
Events are instantaneous occurrences which the system-to-be needs to react on. Operators' usage of the system is a good candidate to reveal events. If the system-to-be has to interact with other systems, this interaction is also a good candidate. Of course, obvious events which occur in the environment also need to be considered. Finally it may be necessary to express pseudo events. A pseudo event is an event that is derived indirectly from something happening in the environment, e.g. the temperature is rising above a certain predefined level.
As for block candidates, the same approach of brainstorming a list of event candidates is a good approach to generate a comprehensive list.
The first block diagram is called a Domain Model. It represents what is needed from the environment in order to control, monitor or administer it. The Domain Model will be the heart of the system-to-be. Having a solid Domain Model allows the developer to model and, possibly, later re-model the rest of the system-to-be without changing the base of the whole system.
Assessment
After having gathered the candidate lists, the very first block diagram can be composed. At first, assess each candidate to be a block. Assess each candidate by asking these questions:
- Is it possible to identify objects from the block?
- Does the block contain unique information?
- Does the block include more objects?
- Does the block have some events?
If it is not possible to identify objects (remember object is very abstract here) of a block candidate, it is most certainly not the right candidate.
Selected candidates are modelled into a diagram. The blocks may be interconnected or, for the time being, left as a non-connected block. Again, remember the block is an abstraction of the environment which shall be used in the system-to-be to determine the system's action.
As for object candidates, the event candidates shall be assessed.
- Is the event instantaneous?
- Can the event be divided into more parts?
- Can it be identified when it occurs?
It is important that the event can be identified as instantaneous. If an event does have a timespan, it might be necessary to divide the event into more parts, for instance, the start and the end of the event. On the other hand, if only the end of the time span is interesting to the system, it should be chosen by renaming the event accordingly.
An event is always undividable. If we want to describe part-events, we should do so by selecting and naming the parts, rather than the whole.
Finally, it is important that we can identify when the event occurs. If it is not possible to identify the exact time, try to see if another approach to the event may lead to an alternative event. As an example: If a customer should fill in an application form, the event FormFilled cannot be identified - we do not know when the customer really filled in the form. Another event like FormReceived might be a better choice because we know when we receive the form in the company.
Table preparation
In order to find the objects which the events affect, it can be very useful to compile a table with the objects as the column name and the events as the row name. Put an x in the cross section where you believe the event will affect the object.
For the objects with "x"s, consider how each object will be affected. Will the object change state (where state here is information about two or more dynamically changeable states, and the object will react differently on next event)? Shall the stored information be updated (the state of the information is changed, but the object will have the same reaction to next event)?
If the assessment results in the object having to react differently at the next event, draw a diagram showing the dynamics in the object. There are several diagrams available for showing the dynamics: State Machine Diagram or an Activity Diagram. Select a diagram type which expresses the particular situation best.
While working with blocks and events, requirements may emerge. The requirements must be captured at this point in the Requirements Diagram to ensure that all requirements are captured. Likewise, already-captured requirements can reveal candidates for objects and events.
Finally, note that the process of building the Domain Model is not a one-shot process. While analysing other parts, for instance, the Usage Domain or the System Dynamics, information emerge which shall be kept in the Domain Model. Only after several iterations through all the analysis activities with no updates on the Domain Model, one can declare it to be solid and a good representation of the Problem Domain.
