Professional Documents
Culture Documents
The Solutions Architecture defines how the system does it: takes an inside viewpoint and identifies the software and hardware components needed to realise the requirements; is the creation and design of the system architecture, where tactical policies are established; makes use of an evolutionary approach, where the implementation is matured through a succession of executable releases; the Solutions Architecture divides the system into three lower level architectures: first, the Object Architecture identifies the objects in the system and details the collaboration between them; second, the Software Architecture details the multi-tasking structure of the system, as well as it real-time storage requirements; finally, the System Architecture shows the processing elements of the system as well as other hardware assemblies such as computational and communication subsystems.
There is also post-delivery evolution of the system, known as system maintenance. This is accomplished by modifying the existing Requirements Architecture and Solution Architecture to incorporate the modified functionality. The development of a system does not usually proceed in a simple sequence of stages. There is an overlap, feedback and feed-forward between stages. System development is an iterative process within stages and over multiple stages.
Page 1 of 4
SHALL Statements:
Page 2 of 4
Constraints Table: Constraints Diagram: System Modes Model: State Transition Diagram:
contains details of each system constraint. a diagrammatic form of representing system constraints.
shows the valid modes of system operation, and the transitions between each state. shows all possible ways in which the system as a whole can respond to events either from inside or outside the system; show the allowable states that may exist for the whole system and the permitted transitions between the states. shows how the system's users interact with the system, including scenarios, operational constraints and contingencies. is a broad stroke description of how a system will be used; it provides a high-level view of the system's intended functionality that is understandable by engineers and nonengineers alike. provides a verbal description of a use case, and includes system pre-conditions and post-conditions, non-functional requirements, alternative courses of action and sample screen layouts. uses an Activity Diagram to show the procedural flow of activities associated with a particular use case; the Activity Diagram can be used to show concurrent (multitasking) behaviour. captures the timing of message interactions between the system and actors, external devices and external systems
Sequence Diagram:
Solution Architecture
Object Architecture: details the collaboration between objects. Objects communicate by sending messages to each other, either request for information or instructions. Messages can be sent asynchronously, synchronously or sequentially. describes the various domains in the system and the classes within them, and represents the static structure of the Object architecture. captures the common structure and the common behaviour of a set of objects.
Class Diagram:
describes how objects and classes collaborate to implement the functionality identified in the Requirements Architecture, and represents the dynamic interplay between objects. shows object interactions arranged in time sequence.
Page 3 of 4
Sequence Diagram:
describes how the states of objects affect their response to events and operations. Dynamic modelling examines the events and associated state changes that can happen to an object through different periods of time. shows the sequence of states that an object goes through in response to events during its life, together with its responsive actions.
Software Architecture:
documents the technology, multitasking and database functionality. It shows the static structures of the tasking model and the real-time database, as well as dynamic task interactions between objects, and data access requirements. allocates objects to tasks, which then operate in a multitasking mode require inter-task communications and sharing of information. shows the tasks which operate in a multitasking environment (e.g. RTOS); Indicates inter-task communication and synchronisation; where tasks share information, mutual exclusion techniques are required.
Concurrency Model:
Concurrency Diagram:
describes how permanent data is to be retained. shows what persistent data is to be stored in files, relational or object databases.
defines the physical distribution of the system, showing processing and interface nodes and the connection between nodes. System Architecture Diagram: shows the implementation of the system; the static view indicates the structure of the computational and communication elements; the dynamic view indicates the communications traffic on the system.
Page 4 of 4