detailed design notes. mechanistic design notes outline system design requirement modeling –...
TRANSCRIPT
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