The Conceptual view is the closest to the application domain. In it we model the architecture as a collection of decomposable conceptual components and connectors. Other views are still relevant however, as current software technology does not directly implement this model. Also, we need to consider the non-functional requirements of the system that are global (ie: performance, dependability) which will need to be considered in other views.
Once the conceptual view is produced it should be able to handle all functional requirements (verifiable via use cases).
Design activities
This can be an iterative process. Also, if possible we should start with a reference architecture. Activities in the creation of the conceptual view include:
- Global analysis (most has already been completed but this is ongoing and iterative)
- Central design tasks
- Identification of conceptual components & connectors, conceptual configuration
- Evaluation of the architecture using Issue cards
- Final design task
- Resource budgeting (initial budgeting only, may need to be re-visited in execution view)
Central design tasks
Identification of conceptual components / connectors
During this stage we define component and connector types, as well as how they interconnect. We map the functionality of the system to components and the control aspects to the connectors. Components can have other components, connectors and ports.
Ports
Represents an interaction point for a component. It defines both incoming and outgoing operations. A port can have an associated implementation and is associated with a protocol (specifies the ordering of incoming/outgoing messages).
Component behaviour
We can define the behaviour of components using UML statecharts, sequence diagrams or natural language. Similarly, control aspects of a connector can be defined using the same tools.
Conceptual configuration
This task is associated with defining the relations between components and connectors. A conceptual configuration containing component and connector types constrains how instances of these can be interconnected (via ports).
Resource budgeting
This is the final task in conceptual modelling. It allocates resources for the component and connector instances. This is useful in identifying early in the design process whether critical resources can be made available.
Protocols and Behaviour
The protocols and behaviour specify how the components, connectors, port and roles interact and functionally behave.
- Specify the behaviour of components that are not decomposed further
- Use statecharts and sequence diagrams where appropriate
- Protocols are sets of:
- Incoming message types
- Outgoing message types
- Valid message exchange sequences