Design Analysis builds a logical model that delivers the functionality. Design fully specifies how this functionality will be delivered. Design looks from the implementation point of view.

Goals Flexible, Flexible, Flexible Should be fluid enough to modify and extend Efficiency Secure and reliable Look for available components

Each package becomes a subsystem Details for interfaces is emphasized For small systems you may take the analysis model and convert it into the design model For large complex systems maintain two models Ensure that these two models are consistent with each other

Deliverables Design classes – with all details Design subsystems – with all details Interfaces Use-case realization design Deployment diagram

Flexibility Model-View-Controller Architecture UI Application Database Three separate pieces that are developed independently Interfaced with each other

Design considerations Concurrency issues Language issues Administrative issues –Procedures –Versioning –Permissions and security –Responsibilities –Documentation –Schedules and testing

Design classes Ready to be implemented classes Interface and implementation Detailed and Refined analysis classes Implementation required classes All attributes and operations are to be specified Figure 15.2 Completeness and sufficiency for users of the class

High cohesion and low coupling Use inheritance with care In analysis inheritance is used only when an “is- a” relationship exists between analysis classes In design you may use inheritance for the sake of code re-use Inheritance is the strongest form of coupling and most inflexible Template classes (general-purpose classes) that can be parameterized at runtime may be used

Relationship - design Refining associations into aggregation or composition Implementing all forms of associations (1-1, 1-n, n-n) Aggregation and composition implements 1-1 and 1-n and n-1 Issues with reflexive association Implementing association classes Clarifying all of this is refining analysis relationship into design relationship

Associations can have properties – particularly when multiplicity is allowed This clarifies cases of every instance of association Composition, Aggregation, Collection When to use collection? Many to Many association needs to be reified – concretized Bidirectional associations needs to reified to avoid cyclical ownership!!

Analysis may have Association class!! Simple association constraints since it depicts only one association for every instance of the object pair associated Otherwise you need a separate class then inter-relate them appropriately Navigation through a multiple association can be qualified using a qualifier (like member-id) as part of the association

Sample Relationship Manager manages one office Supervisor may manage many projects Supervisor’s time is broken-up over projects A vendor works with many offices An office uses many vendors A project is assigned the necessary personnel

Sample Relationship Corporation has a head office and many other offices Offices co-ordinate many projects and warehouses Projects may have warehouses assigned Projects may choose from one or another plant Offices may be added or eliminated Newer warehouses may be added

Collection class These specialize in managing collection of other objects Essentially an ADT handler Vector class is an example Implements 1 to * Reify for n-n or * - * – what does that mean?

Interfaces Interface defines a contract Separates definition from implementation Class defines an interface and an implementation Interfaces do not carry any attributes and relationships Derived classes gets the interface, attributes, and relationships from the parent class

Interfaces contribute only contracted operations and can be used for plug-in components Do not carry relationship One may use pure abstract classes without relations – instead Interfaces can become complex – why? Interfaces have additional overhead – how?

Figure 17.3, 17.4 shows the use of interface Section 17.4 describes how to design using interfaces Subsystems are designed to –Separate design concerns –Represent large grain component –Wrap legacy systems Figure Adv. And dadv. of interfaces

Use-case design Detail the steps of use-case – sequence diagram. Fig 18.2,3,4 Refine activity diagrams Develop state charts

State Chart Similar to DFA Defines states and transitions of one Reactive Object Reactive objects respond to external events, clear lifecycle and state dependent behavior Start node and potential end-node Other nodes are intermediate well-defined states of the element State transitions are triggered by system events Events can be guarded Transitions can also have actions Figure 19.4, 19.5

State Info State name Entry with action Exit with action Internal transitions and actions Internal activity Actions are atomic/uninterruptible Activities may be interrupted by events

Call event Signal event –one way asynchronous communication Change event –Boolean condition change Time event –Absolute time –Elapsed time There can be composite states - with decomposition indicators

There can be concurrent composite states –Fork and/or join –Indicative of concurrency within the object –Can communicate between concurrent states using attributes Sync states –Synchronization/communication between sub- machines History of an object –Shallow and deep history Fig

Implementation Implement class Implement subsystem Perform unit testing

Component Physical replaceable part of a system Each component may contain many classes and realize many interfaces A class can be shown to be inside a component in 2 ways - fig 22.2 Components usually are used to implement significant aspects of the system

Database access Issues pertaining to distributed system –Synchronization –Replication –Failure handling Transaction processing Persistence Security Resource Pooling User Interface

Deployment Map of software architecture to hardware architecture Type and possible deployments Nodes, relationships and component on nodes

Objectives of Design Streamline Implementation Faster delivery Standardized product Cheaper Components Patterns Framework

Topics for CASE tool Engineering/toolcat.html#label233http:// Engineering/toolcat.html#label asetool.htmlhttp:// asetool.html