OO Design Methodologyg gy

OOD Methodology :: Slide 1David Rye

Gather Initial DocumentationGather Initial Documentation

F ll itt t h i l d i ti f th i ti h d Full written technical description of the existing hardware: Geometry, mass and inertia matrix Power source(s), characteristics, storage, power flow( ), , g , p Things that can be controlled, and control mechanisms Things that can be monitored, and monitoring mechanisms

St t ti d h td & t diti Startup, operating and shutdown sequences, pre- & post-conditions Performance limitations, constraints, restrictions and de-rating Electrical/hydraulic etc. circuit diagrams y g Maintenance manual, operating manual Known faults and failure mechanisms

T lk t t ( ) h t t h t Talk to operators(s) – how to operate, what goes wrong...

Output: Hardware Description document as a concise sharedOutput: Hardware Description document as a concise shared reference of all this information

OOD Methodology :: Slide 2David Rye

Design and Implementation ModelDesign and Implementation Model

Use UML for systems modelling Use "iterative development"

(spiral development model) The repeated cycle of

Analysis -> Design -> Code -> Test steps produces a series of iterative prototypesof increasing capabilityof increasing capability

Define the minimal system for a first buildDefine the minimal system for a first build Once the first build is achieved, the system always "works” Successive builds add functionalityy Early risk reduction, high priority features build first,

early availability, etc...

OOD Methodology :: Slide 3David Rye

ROPESROPES

ROPES† = Rapid Object-Oriented Process for Embedded SystemsEmbedded Systems

Diagrams in these slides show the ROPES process g pand artefacts

†Douglass, B.P. Doing Hard Time. Addison Wesley, 1999

OOD Methodology :: Slide 4David Rye

ROPES Process ArtefactsROPES Process Artefacts

OOD Methodology :: Slide 5David Rye

AnalysisAnalysis

Answers the questionsWh d h li ll i ? What does the client really require?(i.e. what are we going to build) Can it actually be built? Can it actually be built?

Three analysis steps Three analysis steps Requirements SystemSystem Object

OOD Methodology :: Slide 6David Rye

ROPES Analysis ModelROPES Analysis Model

OOD Methodology :: Slide 7David Rye

Requirements AnalysisRequirements Analysis

Begin from the client statement of application i t i l direquirements, including

Mission scenarios Objectives and constraints Objectives and constraints Assumptions, initiation and termination Operational conditions - terrain, temperature, etcp , p , Design objectives - rational basis for tradeoffs (speed vs.

endurance, etc) Need to fully define a functional description of what

the system must do, for client approval. Will often be quite different from what the client

thought that they wanted…

OOD Methodology :: Slide 8David Rye

Requirements Analysis (2)Requirements Analysis (2)

Define use cases Define use cases Identify Actors and Use Cases Actor is a human or computer outside the scope of systemActor is a human or computer outside the scope of system

being considered - things that can use the system Use Case is a particular functionality of the system that

results in return of information to an actor - how the systemresults in return of information to an actor how the system can be used

Expand to add generalisations, including «includes» and «extends» Output: one or more use case diagrams Output: one or more use case diagrams

OOD Methodology :: Slide 9David Rye

Requirements Analysis (3)Requirements Analysis (3)

Define events and messages Nature of event/message

S d i t t d ti i f t/ Sender, receiver, content and timing of event/messages May include data streams, depending on what is the

"system"system Output: external event list

Define use case scenarioseach Scenario is one path through a Use Caseeach Scenario is one path through a Use Case Output: written description of a number of scenarios for each

use case Output: sequence diagram for each scenario, showing

content and timing of interactions between actors

OOD Methodology :: Slide 10David Rye

Requirements Analysis (4)Requirements Analysis (4)

D fi b h i ithi ti Define behaviour within reactive use cases Use statecharts to show reactive behaviour of event-driven

use casesuse cases All scenarios will be visible as paths through a statechart Outputs: one or more statechartsp

Identify Safety Hazardsy y Uncontrolled release of energy Output: list of all hazards that must be controlled in design,

including severity, risk and probability of occurrence

OOD Methodology :: Slide 11David Rye

Requirements Analysis (5)Requirements Analysis (5)

Write Test Set Output: written specifications of a set of tests designed to

if th t i t tverify that requirements are met.

Write Requirements Specification Analyst's understanding of the fully-specified requirements. Output: requirements specification document Note - may be for the whole system or for a sub-system

OOD Methodology :: Slide 12David Rye

Systems AnalysisSystems Analysis

Detailed exploration of possible solutions

Objectives Find a system design that is demonstratively capable

of satisfying the Requirements Specification, without having to design and build the whole system!having to design and build the whole system!

Reduce risk by achieving proof of correctness and completeness at an early stage in the cyclecompleteness at an early stage in the cycle

Solution use executable analysis models wheneverSolution - use executable analysis models whenever possible

OOD Methodology :: Slide 13David Rye

Systems Analysis (2)Systems Analysis (2)

Executable models can includeExecutable models can include Finite state machines, continuous controllers,

estimators sensor noise models etcestimators, sensor noise models, etc Use Matlab, Simulink, Stateflow, etc. for fidelity

Construct simulation interfaces to map onto eventual system interfaces testing without hardware testing with “enhanced” or “degraded” hardware

Generate final algorithms from executable analysis models minimal discard of code "the model is the system"

OOD Methodology :: Slide 14David Rye

Systems Analysis (3)Systems Analysis (3)

St t ith li i t i t lik l f ti lStart with a preliminary cut into likely functional subsystems

Sub system is a large organisational unit containing (usually) Sub-system is a large organisational unit containing (usually) hardware and software - e.g. navigator

For each subsystem, define the interfaces to/from each hardware and software component high level definitions based on information flow form of high-level definitions, based on information flow, form of

information, data rate, etc. For each sub-system, make a preliminary partition between

hardware and software. For each subsystem, define the interfaces to/from each

hardware and software componenthardware and software component again, high-level interface definitions only

OOD Methodology :: Slide 15David Rye

Systems Analysis (4)Systems Analysis (4)

S t h b t t ti l titi d i tSystem has now been tentatively partitioned into a number of subsystems, with each subsystem containing one or more software or hardwarecontaining one or more software or hardware (electronic and/or mechanical) components.

Conduct detailed analysis on each high-risk subsystem (some may be simple and straightforward)(some may be simple and straightforward)

analysis method depends on subsystem under analysis... base assumed hardware performance levels on experience, p p

consult with potential vendors estimate code size and speed (very hazardous!)

OOD Methodology :: Slide 16David Rye

Systems Analysis (5)Systems Analysis (5)

Continue subsystem analyses until it is clear that this set of partitions will satisfy the requirements

Otherwise, do new subsystem and/or ysoftware/hardware and/or mechanical/electronic partition, and repeat...

OOD Methodology :: Slide 17David Rye

Systems Analysis (6)Systems Analysis (6)Outputs from Systems AnalysisOutputs from Systems Analysis Output: Deployment diagram showing the computer boxes with their

software components, interfaces and sensor/actuator hardware Output: Hardware Specification detailed statement of responsibility Output: Hardware Specification - detailed statement of responsibility

and performance specifications of each hardware component Output: Software Specification - detailed statement of responsibility

and performance specifications of each software componentand performance specifications of each software component Output: Mathematical models used in the analysis of estimators,

control systems, etc Output: Simulation results tuning results Output: Simulation results, tuning results Output: Executable state machines (we don't do this presently, but

should...) Output: Test set - written specifications of a set of tests designed to Output: Test set - written specifications of a set of tests designed to

verify that requirements are met. Output: Test plan

Note that the solution has not yet been determined, although we should be happy that the system can be built.

OOD Methodology :: Slide 18David Rye

Object AnalysisObject Analysis

So far functional and behavioural views of the systemSo far, functional and behavioural views of the system have been defined.

Next, all of the objects and classes that are essential to implementing a solution are identified.p g

For large systems, split the analysis into a number of D i t ll k i ll lDomains to allow work in parallel.

A Domain contains a group of related classes thatA Domain contains a group of related classes that collaborate to achieve part of a solution

OOD Methodology :: Slide 19David Rye

Object Analysis (2)Object Analysis (2)

Structural object (static) analysisStructural object (static) analysis Identify the essential objects Identify the classes, and collaborations between the classesIdentify the classes, and collaborations between the classes Output: class diagrams of static classes Refine class diagrams to show collaboration, increasing detail

Behavioural object analysis Define the essential behaviour of reactive objects Define the essential behaviour of reactive objects Identify the class to which each statechart belongs Output: class diagrams of classes containing statecharts

One useful test: "walk through" the use case scenarios using the identified objects.the identified objects.

OOD Methodology :: Slide 20David Rye

DesignDesign

Given the understanding that comes from analysis, we need to specify (choose) one solution that is

i t t ith th l iconsistent with the analysis.

Design is the process of identifying one solution that "best" meets all of the requirements – no new “surprises”

Three stages of designg g Architectural: system-wide - processors, packages,

components, tasks Mechanistic: groups of collaborating classes Detail: design at the individual class level

OOD Methodology :: Slide 21David Rye

ROPES Design ModelROPES Design Model

OOD Methodology :: Slide 22David Rye

Architectural DesignArchitectural Design

The "big" strategic decisions that affect all of theThe "big", strategic decisions that affect all of the system:

Distribution of software components across processors &Distribution of software components across processors & processes

Identification and definition of processes and threads Choice of concurrently and scheduling models (in association Choice of concurrently and scheduling models (in association

with choice of OS) Implementation patterns for active objects (root threads) and

state based objectsstate-based objects Inter-processor comms, including protocols and hardware layers Implementation pattern for error handlingp p g Implementation pattern for safety system (homogeneous

redundancy, diverse redundancy, actuator-monitor, etc) Fail-safe actuator design Fail-safe actuator design Fault detection and recovery policys

OOD Methodology :: Slide 23David Rye

Architectural Design (2)Architectural Design (2)

Outputs are refined and extended versions of the analysis diagrams:analysis diagrams:

Output: class and object diagrams, including depiction of architectural patternsO t t ll b ti d/ di Output: collaboration and/or sequence diagrams

Output: statecharts

OOD Methodology :: Slide 24David Rye

Mechanistic DesignMechanistic Design

Mechanistic design adds standard design patterns (container-iterator, smart pointer, etc) to connect the main architectural elements together.

OOD Methodology :: Slide 25David Rye

Implementation (Translation)Implementation (Translation)

Translate the various models into source code, compile and unit test.

Can be manual Use frameworks and “style guide”Use frameworks and style guide

or automatic (e.g. Rational Rose, Ilogix Rhapsody) Expensive learning curveExpensive, learning curve Model stays in synch with the code…

OOD Methodology :: Slide 26David Rye

ROPES Implementation ModelROPES Implementation Model

OOD Methodology :: Slide 27David Rye

Implementation (Translation) (2)Implementation (Translation) (2)

“U it t ti ” i th h t ti f it f t bl d “Unit testing” is thorough testing of a unit of executable code before it is added to the system

A unit can be as small as one class, or as large as a group of collaborating classes that form an executable subsystem.

A unit can include sensor, actuator or other hardware.

Objective of unit testing is to ensure that the unit implementation is consistent with the design

Unit testing is “white-box” – have to understand (and often delve into) what is inside in order to test itdelve into) what is inside in order to test it

OOD Methodology :: Slide 28David Rye

TestingTesting

Testing proper begins when unit testing ends

Integration testingIntegration testing “Gray box” – some understanding of internals required

Validation testing “Black box” – testing at the system boundaryBlack box testing at the system boundary

OOD Methodology :: Slide 29David Rye

ROPES Testing ModelROPES Testing Model

OOD Methodology :: Slide 30David Rye

Testing (2)Testing (2)

Integration Testing Add a component to the system, and test interfaces (new public

f ti lit dd d)functionality added) Conducted by build master or component developer

Validation TestingT t i t lid ti t t d i d f i Test against validation tests derived from previous requirements and analysis documents

Ideally a separate test team designs and runs validation tests Ideally, a separate test team designs and runs validation tests

Safety system validation: go “inside” the system andSafety system validation: go inside the system and systematically break one thing at a time.

OOD Methodology :: Slide 31David Rye

Testing (3)Testing (3)

Test phase results in Output: Validated Component: software/hardware component

increases system functionality Output: items added to Defect List

D f t f ld d b k f f th Defects are folded back for a further analysis – design – implement – test

cycle…cycle…

OOD Methodology :: Slide 32David Rye