You are on page 1of 4

Introduction to Embedded Computer Systems Design 1

An Object Oriented Approach to Embedded Computer System Design


The Unified Modelling Language (UML)
The UML is a graphical language that forms a basis for visualising, specifying, constructing, and documenting the components of a software-intensive system. It provides an industry-standard basis for modelling use cases and scenarios to define and refine the functionality that a software system is expected to provide. It also provides several views for designing the object architecture to implement functionality that will fulfil the requirements implicit in the use cases and scenarios. These design views include the class and package views as well as the dynamic and collaboration diagrams.

The Process for Object Oriented System Design


The system architecture can be broadly divided into the Requirements Architecture and the Solutions Architecture: The Requirements Architecture defines what the system does: is an external viewpoint of the system, which defines what is expected of it from an outside perspective; is the conceptualisation of the system, where a vision for the core system requirements are established, and assumptions are validated; is the analysis of the system, where the process of capturing and understanding a complete and consistent set of requirements, allow the behaviour of the system to be modelled; enables systems, hardware and software engineers to visualise and agree on a system in its initial stages of evolution.

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

Introduction to Embedded Computer Systems Design 1

A Model for the Process

Models Used in Object Oriented System Design


Requirements Architecture
System Scope Model: describes the system and its interfaces with both human users, external devices and external systems. shows how people (actors) interact with the system. views the system as a black box; indicates how transducers (sensors and actuators) are used by the system; indicates how external events affect the system and how system events affect the outside world; identifies the system boundary and what entities are the responsibility of the system these identify the functionality provided by the system: captures the SHALL or implied SHALL statements from the specification documents or discussions with domain experts.

Console Diagram: Context Diagram:

SHALL Statements:

Page 2 of 4

Introduction to Embedded Computer Systems Design 1


System Constraints Model: indicates general limitations to the system as a whole.

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

System Usage Model:

Use Case Diagram:

Use Case Description:

Use Case Scenario:

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.

The Class Model:

Class Diagram:

The Interaction Model:

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:

Introduction to Embedded Computer Systems Design 1


Collaboration Diagram: The Dynamic Model: shows interactions organised around the roles of objects.

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.

State Transition Diagram:

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:

Persistence Model: Storage Diagram: System Architecture:

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

You might also like