RTSE Group: Software Design

RTSE Group
Software Design DIRGANTARA INDONESIA

INDONESIAN AEROSPACE (IAe)
Table of Contents
1. Introduction
2. Aims and Objectives of Software Specification
3. Design : Procedure
4. Object Oriented Design Concepts
5. TOOD (Technique of Object Oriented Design)
6. Specification/Design Transition
7. Design Document: SDD
8. Verification Techniques
9. Conclusion
RTSE Group
1. Introduction
 The main objective is to set up a basis for
software implementation (coding)
 Organized software part to meet the required

function
 Delivers general architecture, interfaces, static

and dynamic behavior of software product
RTSE Group
Overview Analysis and design
WHAT?
Analysis of HOW?
software Preliminary
requirements
Design
Detailed
Design
Coding &
Integration
CSU test & CSC test
CSCI test
SRS SDD SDD

§3 §4
RTSE Group
Analysis and design Goal
 GOAL OF THE ANALYSIS
– What are the functions to be implemented to achieve the
mission of the system ?
– Among these functions, what are these that will be
automatised (computerised, …) ?
 GOAL OF THE DESIGN

– How to organise the computerised part of the system to meet the
required functions, with the required constraints ?
RTSE Group
Design Problem
 Software of big size are difficult to control
 Changes in specification, maintenance on problem or change

report
 Project team mobility, work distribution
 Definition and control of interfaces
 Documentation organisation
 Assessment and control (through quality criteria) of the static and

dynamic aspects
RTSE Group
Table of Contents
1. Introduction
9. Conclusion
RTSE Group
2. Aims and Objective of Software Design
Design objectives
– Define one solution
…from the specification
– Provide an organisation
…meeting the quality criteria
– Define the interfaces
…for distribution and control
– Justify the conception concepts
…for communication and maintenance
RTSE Group
Design : For Whom & For What ?
 The project manager, to
– share the work and sequence the tasks, and track the
progress
– assure a good coherence of the decomposition
– localize the risks and begin with them (first the most
critical tasks)
 The configuration manager, to
– organize the developmental configuration
management
– identify compilation packages
– organize the automatic compilation files
 The product quality manager, to
– verify the traceability with the specification
documents
– identify any other criteria that can have an impact on
the design (simplicity, …)
RTSE Group
Design : For Whom & For What ? (Cont’d)
 The developer, to
– know exactly what he has to code
– define the associated unitary tests
– know the interfaces of the modules to realize
 The integrator, to
– know how to compose the system from the
different CSUs & CSCs (like a puzzle)
– be compliant with the integration states
– identify the requirements and associated tests for
each CSCs
 The maintenance, to
– be able to navigate in the software
– be able to identify the reason of the problem
– localize the tuning and evolutions interventions
RTSE Group
Design : When ?
• After the requirements specification and before the coding.
SSR
Software requirements
analysis
PDR
Preliminary Integration
Design tests
CDR
Detail Unitary
SRS Design tests
IRS (*)
pSDD Coding
final
SDD
RTSE Group
Design : by Whom ?
This is the Software Project Manager decision
• Preliminary Design : Architectural choices must be compliant with the constraints :
– Functional requirements,
– Timing requirements,
– Configuration management constraints,
– Quality & Security constraints,
– …
• Detail Design :
– The work is shared according to the availability, skills, …
– If it is possible, the detail design, coding and unitary testing will be done by the
same developer.
• Discussion : the reusing
RTSE Group
Design : What ?
3 Points :
• Software Architecture = Breakdown in items and interfaces
– The detail design will describe each item : its data, its algorithm, …
• Design choices justification
• Traceability (how ?)
RTSE Group
Design : What ?
Goal of the design : how to organize the software to meet the required functions
according to the required constraints
CREATIVE ACTIVITY
Main characteristics of a design Method :
• Enable the creativity,
• Flexible & non constraining,
• Guideline,
• Using rigorous models,
• Independent from any hardware environment,
• Help in setting up and respect of the standards,
• Make easier the reusing.
RTSE Group
Design : What ?
ARCHITECTURE ?
Breakdown in CSCs/CSUs
Design items identification
Files organization
– It should be possible to make the link between design items and files
organization.
RTSE Group
Design : What ?
• The tool is a model : it allows to identify the studied entities.
• To the tool is associated a construction procedure that :
– Guarantees the construction of the TRACEABILITY,
– Uses the specification model
• The transition from the specification to the design is always delicate,
• It’s natural to use the SA-RT model as starting point for the design phase,
• The SA-RT model being a functional approach, the transition to a functional
design is almost natural.
– Brings evaluation and transformation criteria,
– The detail design philosophy favours some objectives of the design. We use the
modularity to localize always correctly evolutions, adaptations and
modifications.
RTSE Group
Table of Contents
1. Introduction
9. Conclusion
RTSE Group
Specification/Design Transition
• The transition is not automatic

• The transition and the manner in which it is approached can follow several paths:
Enhancement of an OO analysis
– Textual analysis (Abbott)
– Analysis of a structured model (e.g. SA/RT)
– Analysis of domain
– etc.
• Watch out for the complexity
RTSE Group
RTSE Group
RTSE Group
Abstraction Level
 Two abstraction Level
Preliminary Design: Software Architecture,
interface
 Detailed Design: Implementation choices,

algorithms description, preparation for coding
RTSE Group
Preliminary Design
INPUTS
• detailed requirements for the CSCI (SRS - IRS)
• qualification method for the CSCI requirements
ACTIVITIES
• develop the CSCI preliminary design
• do the detailed study of analysis/options
• allocate the requirements to the CSCs
• develop the test plans (STP) for the FQT of the CSCIs
RESULTS
• design detailed requirements for the CSCs
• CSCI preliminary design
• CSCI interfaces preliminary design
• description of the FQT of the CSCIs (STP)
• CSCs integration tests requirements
RTSE Group
Preliminary Design items
Functions
External interfaces
CSCIx States & modes
Global data
Shared data files
Functions
Interfaces
States & modes
Memory & time
CSCx.1 Control flows CSCx.2 CSCx.y
Data controls
Allocated requirements
Design constraints
CSCx.1.1 CSCx.1.2 CSCx.2.1 CSCx.2.2
RTSE Group
Detailed Design
INPUTS
• CSCI preliminary design (CSCs)
• CSCI interface preliminary design
• CSCIs FQT description (STP)
• CSCs integration tests requirements
ACTIVITIES
• develop the CSCI detailed design
• develop plans, schedule for the test of the CSCs/CSUs
• describe the test procedures for the CSCIs FQT (pSTD)
RESULTS
• CSCI detailed design, i.e. CSUs ready to be coded
• CSCI interfaces detailed description (???)
• CSCs/CSUs unitary & integration tests plans
• test cases for the FQT of the CSCIs (pSTD)
RTSE Group
Detailed Design items
CSCIx
Functions
CSCx.1 CSCx.2 Allocated requirements CSCx.y
Design constraints
Programming language
Library identification
I/O data, local data
CSCx.1.1 CSCx.1.2 CSCx.2.1 Interrupts & signals
CSCx.2.2
Algorithms
Faults recovery
Data transformation
Data structures
Local Files / Data bases
Limitations
CSU CSU CSU CSU CSU CSU CSU CSU

x.1.1.1 x.1.2.1 x.1.2.2 x.2.1.1 x.2.1.2 x.2.1.3 x.2.1 x.y.1
RTSE Group
Table of Contents
1. Introduction
9. Conclusion
RTSE Group
Object Oriented Design Concepts
RTSE Group
OOD Concepts: Contents
• Overview
• The Object model: basic principles
– "Philosophical" approach
– Abstraction
– Encapsulation/masking
– Modularity
– Hierarchy
– Typing
– Concurrency
– Persistence
• Classes and Objects
• Difficulties and potential traps
RTSE Group
Overview: History
• The Seventies: structured programming and design
– Decisive moment
– Initial approach to program structuring
– Influences the creation of languages such as Pascal
– Restricted approach for large software (modularity, maintenance, upgrades, etc.)
• The Eighties: object programming and design
– Software engineering
– Modular programming (Ada)
– Object programming (C++)
– Object oriented design methods
• The Nineties: object programming, design and analysis
– Object oriented design and analysis methods (OMT, Booch, etc.)
RTSE Group
Overview
Structured approach v Object approach
Structured approach OBJECT approach

Data Objects
Processing
RTSE Group
The Object model : Basic principles (Booch)
– Abstraction
– Encapsulation/masking
– Modularity
– Hierarchy
– Typing
– Concurrency
– Persistence
RTSE Group
Abstraction
Abstraction arises from a recognition of similarities between certain objects,
situations, or processes in the real world, and the decision to concentrate upon these
similarities and to ignore for the time being the differences (Hoare).
An abstraction denotes the essential characteristics of an object that distinguish it

from all other kinds of objects and thus provide crisply defined conceptual
boundaries, relative to the perspective of the viewer. (Booch).
• Abstraction is used to control the complexity.
RTSE Group
Encapsulation/masking
Encapsulation is the process of compartmentalising the elements of an abstraction that
constitute its structure and behaviour; encapsulation serves to separate the contractual
interface of an abstraction and its implementation (Booch).
• Encapsulation allows the clients of an object to become

independent of the precise implementation of the services provided.
RTSE Group
Modularity
Modularisation consists of dividing a program into modules which can be compiled
separately, but which have connections with other modules (Liskov).
The connections between modules are the assumptions which the modules make about
each other (Parnas).
Modularity is the property of a system that has been decomposed into a set of cohesive
and loosely coupled modules. (Booch).
• Modularity allows the grouping of objects and classes of objects

in order to control the complexity of the physical architecture of
the software.
RTSE Group
Hierarchy
Hierarchy is a ranking or ordering of abstractions (Booch).
• Two types of hierarchy are preponderant:
is a (class structure)
HERITAGE
part of (object structure)

AGREGATION
RTSE Group
Typing
Typing is the enforcement of the class of an object, such that objects of different types
may not be interchanged, or at the most, they may be interchanged only in very
restricted ways (Booch).
• Strong typing reinforces object handling security.
RTSE Group
Concurrency
Concurrency is the property that distinguishes an active object from one that is not
active. (Booch).
• Concurrency is the acceptance of several flow controls of an

application.
RTSE Group
Persistence
Persistence is the property of an object through which its existence transcends time
(i.e. the object continues to exist after its creator ceases to exist) and/or space (i.e. the
object’s location moves from the address space in which it was created). (Booch).
• The spectrum of object persistence encompasses the following concepts

(Atkinson):
- Transient results in expression evaluation

- Local variables in procedure activations
- Global variables and heap items whose extent is different from their scope
- Data that exists between executions of a program
- Data that exists between various versions of a program
- Data that outlives the program.
RTSE Group
OOD Concepts: Contents
• Overview
• The Object model: basic principles
• Classes and Objects
– What is an object?
– What is a class?
• Difficulties and potential traps
RTSE Group
What is an object? (1)
POSTULATE
The real world is made up of autonomous entities which interact
An object holds part of the knowledge of a specific

domain
RTSE Group
• An object
– is correctly determined, and is quite separate from its environment.
– presents characteristics that can be observed.
– is surrounded by other objects.
– reacts to events that take place in its environment, or events that are signalled, by
undertaking actions.
– informs its environment of events concerning this environment or of which it has
knowledge.
• An object models
– a tangible object in the physical, natural or artificial world
– a construction of the mind (bank account, graphical window, path, etc.).
• An application is the result of co-operation between objects
RTSE Group
An object represents an individual, identifiable item, unit, or entity, either real or
abstract, with a well-defined role in the problem domain.
(Smith and Tockey).
... anything with a crisply defined boundary.

(Cox).
An object has state, behaviour, and identity; the structure and behaviour of similar
objects are defined in their common class; the terms instance and object are
interchangeable.
(Booch).
RTSE Group
Characteristics of an object (1)
• An object has a state
– Example:
– PRINTER Weight
Size
Serial number
ON/OFF
Number of sheets in the tray
Number of jobs queued
...
The state of an object encompasses all the (usually static) properties of
the object plus the current (usually dynamic) values of each of these
properties.
(Booch).
RTSE Group
• An object has a behaviour
– Exemple :
– Switch on / Switch off
– Send a print job
– Print one page
– Display an error message
– ...
Behaviour is how an object acts and reacts, in terms of its state changes and
message passing.
(Booch).
The state of an object represents the cumulative results of its behaviour.

(Booch).
RTSE Group
• An object has an identity
LPT1:
LPT2:
LPT3:
The identity is the property of an object which distinguishes it from all

the other objects.
(Khoshafian and Copeland).
RTSE Group
Level of object introduction
• Domain objects (of the reality where the system intervenes)
– Account, Client, Secret code
• Interface objects (perception devices and system engines)

– Automatic teller machine, keyboard, accelerometer
• Cogwheel objects (data processing world),

– List of free spaces, Syntactical tree,
• Functional objects (application specific)

– Teller control, spreadsheet
RTSE Group
Class (1)
A class is a set of objects that share a common structure and a common

behaviour.
(Booch).
• An object belonging to a class is said to be an instance or

example of this class.
RTSE Group
Class (2)
• The description of a class groups the common description elements under the same name:
– attributes, domains of authorised values
– behaviour
– states/activities
– pertinent events
– transition/actions
– constraints
– associations with other classes
• Each instance of a class

– has its own specific attribute values
– shares the attribute names and events with the other objects of the class.
RTSE Group
Operation and method
• A method describes, step by step, the reaction of an object - according to its

class - to an event to which it is sensitive (interpreted by it as a request to be
met).
• A method is executed by an object, but is attached to its specific class.
• An operation is also said to be applicable to an object.
RTSE Group
Inheritance (1)
• Inheritance is a mechanism in programming languages used to obtain a unit
just by describing its differences with an existing unit (programming by
extension).
• Applied to classes, it is used to reflect the concept of classification: the

relationship "is a kind of", "is a sort of".
• Inheritance allows for the sharing of attributes and methods between several
classes.
RTSE Group
Inheritance (2)
• A sub-class
– benefits or inherits all the characteristics of its superclasses
– adds new specific characteristics
• Extremely vast sub-classes can be defined, scant in details and then refined
by more specific sub-classes.
• It is also possible - by examining similar classes - to establish these

similitudes in concepts deemed pertinent, make a superclass: extract and
group.
RTSE Group
Generics
• Generics is a static parametering mechanism used to factorise a common part

of several abstractions.
• A generic class is not a class: it is a class model, used to obtain classes by

specifying the particular parameters (model instantiation).
RTSE Group
Table of Contents
1. Introduction
9. Conclusion
RTSE Group
TOOD - Historic recalls
• TOOD :
– an Object Oriented Design method, synthesis of different works
within THOMSON-CSF
– a graphical design language (based on the OOSD method)
– a theoretical framework inspired by Grady BOOCH, with a
hierarchy notion
– code generation possible for Ada and C (& C++)
• To summarize : How to carry out object oriented design with OOSD

in a DoD-2167A context for real time applications ?
RTSE Group
TOOD entities
• Five types of entities:
– machine (resources management)
– abstract data type (risk management in type manipulation)
– process, abstract process type (risk management in parallelism)
– sub-application (risk management of the complexity)
– collection (utility for grouping)
• Differentiation criteria :
– basic / composite (organization)
– object / class of objects (model)
– passive / active
RTSE Group
Entities Classification
BASIC / COMPOSITE OBJECT / CLASS PASSIVE / ACTIVE
MACHINE BASIC OBJECT PASSIVE
ABSTRACT DATA TYPE BASIC CLASS PASSIVE (instances)
PROCESS BASIC OBJECT ACTIVE
ABSTRACT PROCESS TYPE BASIC CLASS ACTIVE (instances)
SUB-APPLICATION COMPOSITE OBJECT PASSIVE / ACTIVE
COLLECTION COMPOSITE - -
• Basic entities • SUB-APPLICATION witch can be made up of :

(cannot be decomposed) – machines
– MACHINE – processes
– PROCESS – sub-applications
– ABSTRACT DATA TYPE – collections
– ABSTRACT PROCESS TYPE • COLLECTION witch can be made up of :
– abstract data types
– abstract process types
– collections
RTSE Group
The 3 views of an entity
Interface view Environment view Body view
+ code
+ textual information (annotations)
RTSE Group
The Machine entity
• A machine :
– is a passive object, that cannot be decomposed and which is unique
– contains data for which it is responsible by itself
– provides services (functionality or part of functionality)
– hides its own implementation
• Interface :
status_report : status STORAGE_TABLE
read
item : T_ITEM
status_report : status
write status
item : T_ITEM
exist
exist : Boolean item : T_ITEM
RTSE Group
The environment of a Machine
DICTIONARY
ADT_DOC_NAME
T_MODE
DATABASE
T_DOC_NAME
open
close
ADT_WORD
read convert T_WORD
equal max_size :
INTEGER
ADT_CHAR
equal T_CHAR
T_CHAR_STRING
RTSE Group
The body of a Machine
STORAGE_TABLE
internal_data
read
item_list full
local_type
write pt_1st_full
internal_operation
pt_1st_empty empty
exist
access_management
STORAGE_TABLE
internal_data
read
item_list
local_type
write pt_1st_full
status
internal_operation
pt_1st_empty
exist
access_management
RTSE Group
Translation of a Machine into Code
• Ada
– Interface package specification
– Body package body
– Environment with clauses
– Operations procedures and functions organized where
appropriate in separate sub-units
• C-ANSI
– Interface file .h (types, constants, prototypes of functions)
– Body file .c (static data, functions body)
– Environment #include clauses
– Operations functions
RTSE Group
The Abstract Data Type entity
• An abstract data type (ADT_xxx, AT_xxx, ...) :
– is a class of passive objects that cannot be decomposed
– represents a model of data
– must be instantiated to obtain real objects
• Interfaces :
ADT_MARKER ADT_MARKER
marker_too_big mark : T_MARKER
T_MARKER status_report : status mark : T_MARKER T_MARKER
increment_line
increment_line
marker_too_big mark : T_MARKER status_report : status mark : T_MARKER

marker_too_big status
translate translate
char_string : T_CHAR_STRING
char_string : T_CHAR_STRING
max_value : initialize max_value :
T_MARKER mark : T_MARKER T_MARKER
initialize
marker : T_MARKER
RTSE Group
Environment & Body
• Environment of the Machine except that views
are possible only on abstract type
• Body of the Machine except that no data inside
RTSE Group
Translation of an Abstract Data Type into code
• Ada
– Interface private type in a package specification
– Body package body
– Environment with clause
– Operations procedures and functions organized where appropriate in
separate sub-units
• C-ANSI
– Interface file .h (typedef struct, constants, functions prototypes)
– Body file .c (functions body)
– Environment #include clauses
– Operations functions
– Programming rules are necessary to avoid a direct access to the type structure
(GDL30)
RTSE Group
TOOD and the parallelism
• Whenever possible, parallelism must be treated as late as possible.
• It is a very important source of difficulties :
– difficult to design
– difficult to test
– difficult to correct
– consume resources (change of context ...)
• Traditional cases where parallelism appears :
– input / output
– treatment to carry out with different priorities
– distributed systems
– treatment to carry out at regular intervals
RTSE Group
Synchronization
• Synchronous communication (rendezvous)
calling process
• Case 1 : high degree of synchronization
called process
item : T_ITEM
• Representation of the operation operation_name RV
calling process
• Case 2 : low degree of synchronization
called process
item : T_ELEM
• Representation of the operation operation_name RVs
Calling process
• Asynchronous communication
Called process
RTSE Group
The process entity
• A process entity is an active object, that is not decomposable and which is
unique.
• A process entity contains its own (and unique) thread of control.
• A process entity carries out :
– sequential processing
– synchronization with other processes
– communication with other processes, either as master or slave
• Interface :
PROCESS_NAME
oper1_name
item : T_ITEM
oper2_name
item : T_ITEM
oper3_name
P_PROCESS_NAME
proble
m
RTSE Group
The process entity
INPUT_MANAGER
• Example of process It_port IT
• Environment & body :

RV_block RV
– identical to that of a machine
RV_unblock RVs
RTSE Group
Synchronization & Communication
item : T_ITEM
RECEIVER
SENDER
operation_name IT
RVs_block RV
item : T_ITEM
port_it IT RVs_unblock RV
operation_name EVT MAILBOX
item : T_ITEM write read
operation_name FIFO
item : T_ITEM
operation_name MBX
item : T_ITEM RECEIVER
SENDER
operation_name XX RVs_block RV
port_it IT RVs_unblock RV
write MBX
RTSE Group
Translation of the process entity into code
• Possible translations :
– Process = Ada task, in a dedicated package.
– Case of muti-processors : process = application being executed on a
given processor.
– Sequential Ada : process = Ada procedure attached subsequently by the
subjacent executive.
– In C it depends on the Operating System.
• Operations :
– Rendezvous = task entry (Full Ada)
– Translation via executive communication mechanisms (FIFO, events,
etc...)
RTSE Group
The Sub-Application entity
• Organization entity allowing a decomposition hierarchy.
• Assembly of entities (machines, processes, sub-applications, collections).
• Strict sub-application : strictly composed of its entities.
• Non strict sub-application : part of the structure and/or behavior is linked to
"assembly objects".
RTSE Group
Interface and body of a sub-application
- Interface: item : T_ITEM TRACKING
accept_target
saturatio
saturation n
item : T_ITEM
console_comm A *
- Body :
console_comm RV accept_target FIFO
saturatio
*
n
accept_target FIFO
FILTERING
CO_TA
A 1 3
* saturation
Console_comm RV treat
TRACKING_TABLE
CONSOLE read
2 4
* write
RTSE Group
Translation of a sub-application into code
• The sub-application is just a view of the software organization : no
translation
• Two possible translations in Ada :
– The Sub-Application (SA) interface is effectively used as an external
interface (masking of the implementation). In this case, the SA is
translated using a package containing renaming of operations, constants
and exceptions, and declarations of sub-types.
– The SA is seen as a "compact" set of Ada code (use of a unique package),
it is then possible either to :
• use a package encompassing the packages of the SA,
• rename the operations, types, constants and exceptions in a package
specification (in this case there is no generated code).
RTSE Group
The collection entity
• Group of models (abstract types or generic entities).
• A collection can be made up of sub-collections.
• 3 possibilities :
– Empty interface diagram
Body diagram
– "Restricted visibility" interface diagram
Body diagram
– "Complete" diagram
• No explicit visibility arrows
• No translation : the collection is a purely design item.
RTSE Group
Possible interfaces of a collection entity
CO_AT_TEXT CO_AT_TEXT
AT_INDEXED_WORD
AT_DOC_NAME
2
1
AT_MARKER AT_WORD
3 4
AT_CHAR
CO_AT_TEXT 5 CO_BASIC_AT
AT_DOC_NAME AT_WORD CO_AT_Numeric
AT_MARKER AT_INDEXED_WORD CO_AT_Enumeration
AT_CHAR CO_AT_etc
RTSE Group
Design choices and Performances
• Design choices have an impact on the performances :
– Using multi-tasking software : major technical risk in software
development
Prefer to use sequential solution
– Dynamic creation/destruction of processes (always compromise between
memory & CPU resource) :
Create all the required processes during the initialization phase.
– Dynamic creation/destruction of objects using C++ (constructor,
destructor).
– Dynamic allocation/release of memory :
Allocate all the required memory during the initialization phase, if
available.
RTSE Group
Table of Contents
1. Introduction
9. Conclusion
RTSE Group
Standard Process
• Identify the entities and their attributes

• Identify the functionalities and distribute them to the entities
• Determine the interface and visibility of the entities (operations,...)
• Describe the entities (body)
RTSE Group
The standard process
informations
entities
What are we talking about ?
attributes What are the pertinent informations ?
entities
attributes functionalities What are the expected functionalities ?

entities
What are the exchanged informations ?
attributes visibility functionalities Who is responsible for the exchange ?
entities
attributes visibility operations functionalities What are the necessary operations ?
RTSE Group
Standard Process
Step 1 : Identify the entities and the attributes
• Identify the informations, collect them in "cloud" entities.

• Some traditional channels for identification :
– Textual specification :
• Analysis of names : potential candidates for the
informations and attributes
• Analysis of verbs : potential candidates for the
functionalities
– Analysis of the SA_RT model
RTSE Group
Standard Process
Step 2 : Identify the functionalities and distribute them
• Analysis of the specification (textual, SA / RT model, ...)

– Identification of functionalities
• Allocate functionalities to one entity (and only one)
– Distribution of responsibilities
– Distribution criteria : high cohesion, low coupling
RTSE Group
Standard Process
Step 3 : Determine the interface of the entities (operations, ...)
• Determine the information flows (data, control).

• Determine the control of the exchange (and deduce the
visibility).
• Determine the operations (and the associated parameters /
exceptions).
• Determine the pre-conditions and post-conditions
(comments,...).
• Check the level.
RTSE Group
Standard Process
Step 4 : Describe the entities (body)
• Describe completely the body of each entity (detailed design).

or
• Decompose the entities in several entities (decomposition
hierarchy)
• Examples
–
RTSE Group
From SA-RT to TOOD
RTSE Group
From SA-RT to TOOD
• SA / RT : functional approach, data flow oriented.

• Hierarchy approach, but different organization (different
objectives)
• The SA / RT model can be used to discover:
– entities
– functionalities
RTSE Group
From SA-RT to TOOD
• Terminations can be candidate to Interface Objects
– machine
– sub-application
– process
• Data flow : abstract types
• Data storage
– a storage + associated functionalities : an ideal object
• Verb in a process name : potential functionality
• Control flow : potential action
RTSE Group
From SA-RT to TOOD
• Constants in storage
– attributes of an object (e.g. constants of initialization)
• P-spec
– they describe the functionality in detail (algorithm for detailed design or
information for decomposition).
• C-spec
– they can evoke objects themselves in complex automata cases. In this
case, this object is responsible of the scheduling of operations (caution :
do not re-invent a real time monitor)
• The SA-RT hierarchy is not equivalent to the decomposition hierarchy of the
TOOD model.
RTSE Group
RTSE Group
Table of Contents
1. Introduction
9. Conclusion
RTSE Group
Document SDD
1 - SCOPE 4 - DETAILED DESIGN
1.1 Identification 4.X Xth CSC name and project unique
1.2 System overview identifier
1.3 Document overview 4.X.Y Yth CSU name and project
2 - REFERENCED DOCUMENTS unique identifier
3 - PRELIMINARY DESIGN 4.X.Y.1 Design
specification/constraints
3.1 CSCI overview
4.X.Y.2 Design
3.1.1 CSCI architecture
5 - CSCI DATA
3.1.2 System states and modes
6 - CSCI DATA FILES
3.1.3 Memory and processing time
allocation 6.1 Data file to CSC/CSU cross reference
3.2 CSCI design description 6.X (Data file name and project unique
identifier
3.2.X CSCx name and project unique
identifier 7 - REQUIREMENTS TRACEABILITY
8 - NOTES
RTSE Group
RTSE Group
Table of Contents
1. Introduction
9. Conclusion
RTSE Group
Design Evaluation
• Documents • TOOD diagrams quality

– Understandability – Simplicity / balance (no more
– Consistency (internal, external) than 5 TOOD entities per
– Template compliant level)
– Traceability with up-front – Low coupling !!!
documents
• SDP
• SRS/IRS
RTSE Group
Preliminary Design & Traceability
Requirements allocation (SRS & IRS) to the CSCs
CSCI
CSC1 CSC2 CSC3
CSC2.1 CSC2.2
R10 X X
F1 R11 X X
R12 X
F2 R20 X X
F0 R30 X X
R31 X
F3
R32 X X
R33 X X
F4 R40 X
RTSE Group
Preliminary Design Review
• OBJECTIVES
– Evaluate progress, consistence and technical appropriateness for design & test
philosophy
– Evaluate the traceability
– Evaluate the preliminary version of the using and logistic support documents
• REVIEWED ITEMS : pSDD, (pIDD), STP & pCSOM, pSUM, pCRISD
– Functional flux,
– Store allocation data,
– Control functions description,
– CSCI structure,
– Security
– Tools and Utilities for development and tests
– Logistic support documents and resources,
– Traceability (with SRS, IRS & SDP),
– Reliability, maintainability, transportability
– Human factors, test, ...
RTSE Group
Detailed Design & Traceability
Requirements allocation (SRS & IRS) to the CSUs
CSCI
CSC1 CSC2 CSC3
CSC2.1 CSC2.2
CSU10 CSU11 CSU210 CSU211 CSU220 CSU221 CSU222 CSU31 CSU32 CSU33
R10 X X
F1 R11 X X X
R12 X
F2 R20 X X
F0 R30 X X
R31 X
F3
R32 X X X
R33 X X
F4 R40 X X
RTSE Group
Critical Design Review
• OBJECTIVES
– Evaluate the performance and test characteristics for the solution
– Evaluate the risks
– Traceability
• REVIEWED ITEMS : SDD, IDD, pSTD, CRISD, SPM, FSM, & pCSOM,
pSUM
– Detailed design of the CSUs
– Data, data bases, …
– Detailed definition of the interfaces
– Traceability
– Reliability, Maintainability, Human factors, …
– Test
– Support Documentation
– …
RTSE Group
Table of Contents
1. Introduction
9. Conclusion
RTSE Group

RTSE Group: Software Design

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

RTSE Group: Software Design

Hochgeladen von

Copyright:

Verfügbare Formate

RTSE Group

Software Design DIRGANTARA INDONESIA

 Organized software part to meet the required

 Delivers general architecture, interfaces, static

SRS SDD SDD

 GOAL OF THE DESIGN

 Changes in specification, maintenance on problem or change

 Project team mobility, work distribution

 Definition and control of interfaces

 Assessment and control (through quality criteria) of the static and

Design items identification

• The transition is not automatic

 Detailed Design: Implementation choices,

CSCx.1.1 CSCx.1.2 CSCx.2.1 CSCx.2.2

CSU CSU CSU CSU CSU CSU CSU CSU

Structured approach OBJECT approach

An abstraction denotes the essential characteristics of an object that distinguish it

• Abstraction is used to control the complexity.

• Encapsulation allows the clients of an object to become

• Modularity allows the grouping of objects and classes of objects

• Two types of hierarchy are preponderant:

part of (object structure)

• Strong typing reinforces object handling security.

• Concurrency is the acceptance of several flow controls of an

• The spectrum of object persistence encompasses the following concepts

- Transient results in expression evaluation

An object holds part of the knowledge of a specific

... anything with a crisply defined boundary.

The state of an object represents the cumulative results of its behaviour.

The identity is the property of an object which distinguishes it from all

• Interface objects (perception devices and system engines)

• Cogwheel objects (data processing world),

• Functional objects (application specific)

A class is a set of objects that share a common structure and a common

• An object belonging to a class is said to be an instance or

• Each instance of a class

• A method describes, step by step, the reaction of an object - according to its

• Applied to classes, it is used to reflect the concept of classification: the

• It is also possible - by examining similar classes - to establish these

• Generics is a static parametering mechanism used to factorise a common part

• A generic class is not a class: it is a class model, used to obtain classes by

• To summarize : How to carry out object oriented design with OOSD

• Basic entities • SUB-APPLICATION witch can be made up of :

Interface view Environment view Body view

+ textual information (annotations)

status_report : status STORAGE_TABLE

marker_too_big mark : T_MARKER status_report : status mark : T_MARKER

• Environment & body :

AT_MARKER AT_INDEXED_WORD CO_AT_Enumeration

• Identify the entities and their attributes

attributes functionalities What are the expected functionalities ?

attributes visibility operations functionalities What are the necessary operations ?

• Identify the informations, collect them in "cloud" entities.

• Analysis of the specification (textual, SA / RT model, ...)

• Determine the information flows (data, control).

• Describe completely the body of each entity (detailed design).

• SA / RT : functional approach, data flow oriented.

• Documents • TOOD diagrams quality

CSC1 CSC2 CSC3

CSC1 CSC2 CSC3

Das könnte Ihnen auch gefallen