Problem Domain Analysis
The architecture can initially be expressed as a block diagram with very few details. For SW-only projects, the UML class diagrams 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.
A block diagram with a brief description of each object and its responsibilities.
Diagrams depicting the dynamics of blocks with dynamic states.
Captured requirements from the Requirements Analysis
Inspect already captured requirements and extract 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.
The objects are candidates for being a block. A block, when representing parts of the environment, can be implemented at a later state in hardware, software or in a combination of the two.
Events express the dynamics of the system. The events will often be represented in the System Behaviour Analysis.
Architecture: Architecture is an asset that describes the system as a whole. An architecture defines the system structure comprising the components, their externally visible properties and their relationships among each other. An architecture diagram is a static view of the system.
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 operating on that data. However, it may also be 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.
One of the first tasks is to create a model of the environment. Not the entire environment, but of those parts needed in order to fulfil what the system-to-be is required to do. We will do this by analysing the Problem Domain.
In the early phases of the analysis, we often draw one or more block diagrams to gain an overview of the system-to-be.
A Block is a general term, and by the time of identifying it, no decisions, whether to be implemented as HW or SW, exist.
The figure element 'Block' represents the object in the environment which shall be abstracted into the system. 
The block represents objects in the environment where each object can be a very abstract interpretation of the physical world. For example, 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. What is interesting here is that a representation of the temperature in the operating environment is needed.
We do not yet take much notice of how to realise this (probably a HW sensor, an analogue to digital interface, SW for interfacing and converting...), but will leave this until later in the process.
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 composing 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 on which the system-to-be has to react. This results in the first descriptions of the dynamics in the system.
Events are instantaneous occurrences on which the system-to-be reacts. 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 to 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.
After having gathered the candidate lists, the very first block diagram can be composed. First, assess each candidate to be a block. Assess each candidate by asking the following questions:
- Is it possible to identify objects from the block?
- Does the block contain unique information?
- Does the block include more objects?
- Is it possible to identify events that can change the blocks behaviour?
- Will the block fit "logically" in between remaining blocks in the system?
If it is not possible to identify objects (remember that '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 that the block is an abstraction of the environment which should be used in the system-to-be to determine the system's action.
As for object candidates, the event candidates should 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 has a timespan, it might be necessary to divide the event into more parts, e.g. the beginning and the end of the event. On the other hand, if only the end of the timespan 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 received the form in the company.
In order to find the objects affected by the events, 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 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 to the next event)? Should the stored information be updated (the state of the information is changed, but the object will have the same reaction to the next event)?
If the assessment results in the object having to react differently to the next event, draw a diagram illustrating the dynamics in the object. There are several diagrams available for illustrating the dynamics(e.g. a 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. To ensure that all requirements are captured, a Requirements Diagram from the Requirements Analysis is a useful feature. 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 emerges which should 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.
Software Only Projects
In SW-only projects, the block diagram can be substituted by a Class Diagram. The above recommendations and advice are still valid for classes.
An incomplete architecture diagram from early stages of the analysis.