1. 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.

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

3. 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

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

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

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

7. 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

8. 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

9. 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

10. 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!!

11. 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

12. 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

13. 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

14. 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?

15. 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

16. 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?

17. 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 17.10 Adv. And dadv. of interfaces

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

19. 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

20. 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

21. 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

22. 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. 20.3-11

23. Implementation Implement class Implement subsystem Perform unit testing

24. 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

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

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

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

28. Topics for CASE tool http://www.cs.queensu.ca/Software- Engineering/toolcat.html#label233http://www.cs.queensu.ca/Software- Engineering/toolcat.html#label233 http://www.rspa.com/spi/CASE.html http://www.geocities.com/millermax2001/c asetool.htmlhttp://www.geocities.com/millermax2001/c asetool.html www.Ilogix.com www.gentleware.com