Design

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#label233 • http://www.rspa.com/spi/CASE.html • http://www.geocities.com/millermax2001/casetool.html • www.Ilogix.com • www.gentleware.com