Detailed Design

NOTES

Mechanistic Design

Notes

Outline

System DesignRequirement Modeling – functional requirements (Use Cases)

Analysis Modeling

Structural Object Analysis – static model defining the relationships between classes (Class Diagrams, etc.)

Behavioral Object Analysis – model describing dynamic (behavioral) aspects (statecharts, etc.)

Design Modeling – design a software architecture

Architectural Design – system-wide

Mechanistic Design – inter-object

Detailed Design – intra-object

Rational Rose Real-Time (RoseRT)

Design CategoriesArchitectural Design

Mechanistic Design

Detailed DesignScope: Class

Class Name

Attributes

Operations

Class

Class

Class

Class

Node

PackageTask

TaskComponent

Scope: Sets of Collaborating Classes

Mechanistic Design

Describe how a small sets of objects and classes collaborate to achieve a common goal.

Discover and use patterns in an individual object collaboration; e.g., apply solutions to structurally similar problems (reification).

Optimize the analysis model against a set of design criteria.

Design Criteria

Performance

Predictability

Safety

Reliability

Maintainability

Portability

Cost

Patterns and Frameworks

Patterns support reuse of software architecture and mechanistic design.Patterns capture the static and dynamic structures of successful

solutions to problems that arise in a particular domain.

Frameworks support reuse of detailed design and code.

Patterns

Successful solutions to many problems are derived by using patterns.

Example: Becoming a Chess MasterLearn rules and physical requirements

Learn principles of game

Study games of other masters containing patterns that must be understood and applied repeatedly.

Design Patterns

Design patterns represent solutions to problems that arise when developing software solutions in a particular context.

Patterns capture dynamic and static structure and collaboration among key participants.

Patterns facilitate reuse of successful software architectures and designs.

Use Case Model

Target Path Planner Classes

Path planner Plans the full path, including all changes in position and velocity.

Path The plan created by the path planner.

Path segment A part of the plan, consisting of a short sequence of precisely timed rudder adjustments and changes in acceleration to adjust position and velocity.

GPS (position) sensor A sensor that determines the current position of the target.

Rudder sensor A sensor that determines current rudder position.

Rudder pump (actuator)

A pump that controls the rudder position.

Classes Roles

(etc.)

Path Control Analysis Model

Terms and Concepts

A class role is the behavior of a class within a specific context.

A collaboration is a set of class roles that exchange messages to achieve an overall, coordinated behavior.

A mechanism is a design pattern that applies to a society of collaborating classes.

Design Patterns

Design patterns are general solutions to commonly occurring design problems; e.g., an abstraction of a collaboration.

They consist of three parts:a common problem, including a common problem context

a generalization approach to a solution

consequences (pros and cons) of the pattern

Design Pattern Categories

Correctness Patterns - used to produce correct designs.

Creation Patterns - used to configure and initialize classes and objects.

Structural Patterns - used to decouple interface and implementation.

Execution (Behavioral) Patterns - used to model interaction and control.

Correctness Patterns

Smart pointer: avoid problems associated with dumb pointers.

Second guess: monitor collaboration results for reasonableness.

Exception monitor: ensure that pre- and post-conditions are met.

Watchdog monitor: ensure that equipment continues to operate within an acceptable range.

Smart Pointer Pattern

Problem:Pointers may be used before being initialized.

Pointers may be used after the memory they point to has been released (dangling pointers).

Memory may not be released (memory leak).

Solution: A smart pointer object can be used when a temporary pointer is called for. It uses an internal reference counter to determine whether other smart pointers are referring to the same object in memory.

Smart Pointer Pattern

Consequences:A smart pointer makes the design more robust.It increases the code complexity and requires an additional level of

indirection for each pointer reference; e.g., there is a small amount of run-time overhead.

If both smart and raw pointers are applied to the same object, reference counting should be disabled.

Second Guess PatternProblem: Long computations may become

erroneous due to a variety of maladies.

Solution: Two algorithms are represented, the primary one and a another (secondary) one (used as a reasonableness check).

Consequences:The secondary algorithm can be used to verify the computation

within a predefined range.

It imposes some computational overhead.

Exception-Monitor PatternProblem: Exceptions must be handled to build a

safe and reliable system.

Solution: Add exception handling by adding exception safe classes:Exception

Exception Handler

Exception Monitor

Exception Log

Global Exception Handler

Exception-Monitor Pattern

Consequences:The unpredictability of language-based, exception-handling

mechanisms can be removed by using the exception-monitor pattern.

Standard language mechanisms simply walk the call stack backwards.

Unsafe Linear Accelerator

LinearAccelerator

BeamEmitter

(Actuator)

BeamDetector(Sensor)

Set Intensity

Start Beam

End Beam

Beam Intensity

Beam Duration

Safe Linear Accelerator

LinearAccelerator

BeamEmitter

(Actuator)

BeamDetector(Sensor)

Set Intensity

Start Beam

End Beam

Beam Intensity

BeamDuration

SafetyProcessorWatchdog

StatusStart Beam, etc.

Request Status orEmergency Shutdown

Cut-OffSwitch

Off

On

Off

Creation Patterns

Factory - method in a derived class creates associates; e.g., centralize the assembly of resources needed to create an object.

Builder - factory for building complex objects incrementally.

Prototype - factory for cloning new instances.

Singleton - factory for a singular instance.

Structural Patterns

Adapter - translator adapts a server interface for a client.

Bridge - abstraction for binding different implementations.

Wrapper - encapsulate or simplifies the interface for a subsystem.

Proxy - one object approximates another.

Adapter Pattern

Problem: Client expects a different interface.

Solution: Convert the interface of a class into another interface the client expects.

Consequences: Provides an interface that expresses the similarities of classes the

seem different.

Requires additional level of indirection.

Wrapper Pattern

Problem: Need to avoid tedious, error-prone, and non-portable programming of low-level IPC mechanisms.

Solution: Encapsulate lower-level functions within a type-safe, modular, and portable class interface.

Wrapper Pattern

Execution Control PatternsPolicy StateState-Table State-WalkerControl-LoopReactive Control-LoopFuzzy-StateNeural Network

Policy Pattern

Problem: Many classes realize the same interface, but differ in terms of how they operate internally.

Solution:The algorithm used to implement the black-box behavior is called a

policy.

Policies can be abstracted away from the main class to simplify the interface, improve reuse, and allow for dynamic choice of policies.

Policy Pattern ObjectsClient - uses services and operations of the Context

object.Context - provides a context for the Abstract Policy

object, and invoke services necessary to implement the policy.

Abstract Policy - provides a virtual interface to the Concrete Policy object.

Concrete Policy- implements the algorithm and services for the selected policy.

State Pattern

Problem: Many systems spend most of their time in only a few states. It is more efficient to make this part of the system more efficient; e.g., lightweight.

Solution: A composite object can manage the state behavior.

State Table Pattern

Problem: Need a simple mechanism to manage large state machines efficiently.

Solution: A state table can be implemented as an n x m array wheren is the number of states, and

m is the number of transitions.

Mechanistic Design Summary

Mechanistic Design - design patterns capture successful solutions for collaborating classes

More Design Patterns: http://www.cs.uiuc.edu/users/patterns/patterns.html

Detailed DesignArchitectural Design

Mechanistic Design

Detailed DesignScope: Class

Class Name

Attributes

Operations

Class

Class

Class

Class

Node

PackageTask

TaskComponent

Scope: Sets of Collaborating Classes

Detailed DesignAn object can be defined as “a set of tightly coupled

attributes and the operations that act on them”.

The scope of detailed design is limited to individual objects.

Detailed design specifies intra-object details; e.g., “what the man behind the curtain (in the black box) does”.

Intra-Object DetailsData structuring of non-primitive attributes

Implementation of associations

Detailed definition of object interface

Finalization of operations defined for a class

Detailed design of algorithms implemented by those operations

Exceptions handled and thrown

Data StructuresPrimitive Types

Subrange Constraintstypedef subrange<int, 0, 99> tWeight;

tWeight item_weight;

Derived Attributesattributes that can be reconstructed from other attributes within the

class

added to optimize performance

Data-Collection Structure

Data-Collection StructureCollections of primitive data attributes can be

structured in different ways: list, stack, queue, vectors, trees, etc.

Common role constraints provided by UML{ordered} = sorted

{bag} = may have several copies of same item

{set} = only single copies of each item

{hashed} = reference via a keyed hash

{ordered set}, etc. = combinations of above

AssociationsAssociations allow client objects to invoke the

operations provided by server objects.

There are many ways to implement associations.

Detailed design resolves the management of associations between the objects.

Crossing thread boundaries complicates the resolution of associations.

Container Pattern ExampleMultivalued roles (1-*) are frequently resolved using the Container Pattern:

Associations: Crossing Thread Boundaries

Crossing thread boundaries complicates the resolution of associations

Direct calling may not be possible

Other MechanismsMessage Queues

Pipes

Named Pipes

Network Protocols (TCP/UDP/RPC/CAN)

Message Passing Patterns

Observer Pattern

Proxy Pattern

Adaptor Pattern

Observer Pattern

Standard pattern for monitoring objects.This pattern sets up two types of objects:

subjects

objects

Observers register with subjects, and are notified of state changes.

Observers acknowledge to subjects when a change has been observed.

Object InterfaceAn interface is a named set of operations.

An interface in the UML is an abstract notion that cannot be instantiated; interfaces are realized by eitherlogical elements (classes and packages), or

run-time artifacts (components).

Interfaces may be realized by different classes, and a single class may realize different interfaces.

Definition of OperationsOperations defined by a class specify how the data may

be manipulated.Example: Queue

template <class T, int size> class queue { protected: T q[size]; int head, tail; public: queue(void): head(0), tail(0); virtual void put(T, myT); virtual T get(void); };

Detailed Algorithmic Design

An algorithm is a step-by-step procedure for computing a desired result.

The complexity of an algorithm is usually measured in space and time using big-O.

O( f ) = { t(n) : t(n) <= c * f(n) for sufficiently large values of n }.

Representing Algorithms in the UML

Single- and multi-threaded algorithms can be captured by the UML in several ways:Statecharts - can describe event-driven algorithms,Activity diagrams - concurrent flowcharts can depict programmatic

constructs of sequence, branch, loop, fork, and join.Sequence diagrams - don’t show concurrency well.

Response Calculator Example

Exceptions

In the UML, a Signal is a metaclass defined as a “specification of an asynchronous stimulus communicated between instances”.

An Exception is a specialized type of Signal that is used when the stimulus is a fault of some kind; e.g., the violation of a range invariant, etc.

Exceptions (continued)An Event is a “specification of a significant occurrence

that has a location in time and space”. A SignalEvent is an Event that associates with Signal.

Signal and Operation are two kinds of Request (which are specifications of MessageInstances).

Class operations can raise (or throw) exceptions.

Modeling Exceptions in the UML

Language-Based Exception Handling

Two primary benefits:Exceptions cannot be ignored.Separates exception handling from the usual execution path.

if ((fp=ftest1(x,y,z)) == NULL) { try { printf(“Failure on test 1. \n”); ftest1(x,y,z); exit(1); }} catch (test1Failure& t1) {

cout << “Failure on test 1.”; throw;}

Language-Based Exception Handling

Each operation must answer two questions:What exceptions should be caught? Generally, all exceptions that it has the

context to handle.

What exceptions should be thrown? Generally, all other exceptions.

Exceptions:Destructors should never throw exceptions or call operations that might

throw exceptions.

Constructors of exception classes should not throw exceptions.

State-Based Exception Handling

In reactive classes, exception handling is straightforward.

Exceptions are associated with the triggering events specified in the class statechart.

Additional states are used to represent fault conditions; stereotype = <<exception>>.

State-Based Exception Handling