UvA-DARE (Digital Academic Repository) Fluoride-releasing … · o.o. EE oo UU oo oo oo
OO Desigggn Methodologyyweb.aeromech.usyd.edu.au/.../08a_OOD_Methodology.pdf · Design is the...
Transcript of OO Desigggn Methodologyyweb.aeromech.usyd.edu.au/.../08a_OOD_Methodology.pdf · Design is the...
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