Architecture Design: Conceptual Architectural view

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.

components.png
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.png

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.
connector.png

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
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License