Design

1. Design Object-Oriented Design OO Design

2. Object-Oriented Design • The process of • determining the architecture, and • specifying the classes needed to implement a software product in CONCURRENTLY OO Design

3. Design In General • Transfer the results of analysis phase into the design of a software solution • Define the overall S/W architecture • For OO Design • Non-private attributes, operations, and algorithms are defined for design objects • Implementation-oriented new objects are defined OO Design

4. More About Design • The boundary between design and implementation is both flexible and subjective • The goal of design is to achieve sufficient agreement on interface definition and internal structure that implementation work may then BE proceed independently in parallel OO Design

5. Design Work Products • Design Guidelines • System Architecture • APIs • Target Environment • Sub-system model • Design Object Model • Design Scenarios • Design Object Interaction Diagrams • Design State Models • Design Class Descriptions • Rejected Design Alternatives • Database tables Milestone #6 Milestone #7 OO Design

6. Design Guidelines • A set of rules that help in defining the design deliverables and guiding the design process • Extension of analysis guidelines • Recycle as much as possible • Address the work products apply to design OO Design

7. System Architecture • The set of project wide design decisions • Should cover the following areas • Structure-- how to layer and partition the S/W • Communication patterns among the components • Other communication issues • distribution • Persistence • Security • Error handling • Recovery • H/W and S/W configurations OO Design

8. More On System Architecture • Created by the “Project Architect” • Restricts what a developer can do • May include assumptions • For example, “Use VBScript on all the ASP pages except the first page, assuming client environment is IE4 or later.” • Nonfunctional requirements may affect this part greatly OO Design

9. Examples On System Architecture • Structure-- how to layer and partition the S/W • Show the software layers such as ODBC • Communication patterns among the components • Specify all the inter-component communication is achieved through the database • Other communication issues • Client to server communication using HTTP (TCP/IP) • Distribution • Using DBMS’ replication feature • Persistence • All the persistence data should be stored in the database OO Design

10. Examples On System Architecture • Security • Users need to be authenticated through LDAP • Error handling • Critical sections need to use • try … catch … final structure • Recovery • Relay on the database to provide check point • Use “transaction” operation to make data changes are atomic • Debugging • Each class need to provide a method “displayState” that prints out the values of all the members. • H/W and S/W configurations • Client environment is IE6 or later, Win3264 OS, X86 CPU, etc OO Design

11. APIs • One of the two • Application Programming Interfaces • Architecture Program Interface • One view of APIs are that they are a collection of public methods • This view enable the sub/system to be used without the needs to understand a class’ internal details, especially for applications that provide some services OO Design

12. Target Environment • The environment in which the application will operate • Come from non-functional requirements • It should specify • H/W • OS • runtime environment • It should provide specifications for both clients and servers (database, IIS, etc) OO Design

13. Target Environment • This work product ensures that both the user and the system architect share a common understanding of the operating environment • For distributed system you need to specify all the possible clients and servers, especially clients! • Users’ opinions count here! OO Design

14. Subsystem Model • Is a partitioning of a system into subsystems and delegation of system responsibilities. • There are many ways to divide the system. • A subsystem may contain sub-subsystem. • A subsystem model identifies existing subsystems that are to be reused as well as those that need to be constructed. OO Design

15. Subsystem Model • The most common reason of having subsystem is “divide and conquer” • Others reasons are • reuse • dividing the work – CS625/CS630 • etc. OO Design

16. How To Partition A System • Developed V.S. under-developing • Already divided at the analysis phase • Divided by physical boundaries • For example, Staff, Student, classes • After Design Object Model for less amount of communication OO Design

17. More About Sub-system • Once a subsystem is identified, it is treated as a system in its own right • May have its own workbook • Subsystem model shows the interaction among sub systems • Each use case must be mapped into a subsystem or subsystems • Most use cases should be contain with a single subsystem OO Design

18. The Subsystem Model Includes • 1. Subsystem diagram • A. subsystems • B. contracts • 2. For each subsystem • A. Name • B. Description • C. Contracts • 2. For each contract • A. Name • B. Description • C. API • D. Notes OO Design

19. Subsystem Model • Subsystem can be larger enough to have its own workbook • Balancing the amount of work should not be a Criterion for partition a system. However, that is what you will do because CS430 OO Design

20. Design Object Model • Consists of the classes, their attributes, operations, and interrelationships among the classes OO Design

21. Design Object Model • Document the static aspect of an OO solution to a problem • Shows the structure of the software system, not the problem domain • An analysis class may be mapped into two or more classes. For example • One for data processing • One for data presentation • May introduce new classes • Security OO Design

22. Design Object Model • Start with Analysis Object Model • Add new classes for views and utilities • May consult with Design OID and Design State Models for completeness/correctness • Consider subclass carefully • May need to consider accessibility (public, protected, private) OO Design

23. Notation • See page 285 OO Design

24. Design Scenarios • Define system behaviors at a concrete level • Include information regarding how to trigger the scenarios OO Design

25. Design Scenarios: Purposes • Define a complete set of functional specifications that define the externally visible behaviors • Define the assumptions and outcomes of Design OIDs OO Design

26. Design Scenarios: Approaches • Approach #1 (emphasize on mechanisms). Transform Analysis OIDs into Design OIDs, then transform the corresponding Analysis scenarios • Approach #2 (emphasize on interfaces). Transform Analysis scenarios first, then analysis OIDs. • IBM recommends approach #1 • Key: Scenarios and OIDs are closely linked! OO Design

27. Design Scenarios: Approach #1 • Working on Design OIDs based on Analysis OIDs. • Once a Design OID is created, its corresponding Design Scenario is created or updated OO Design

28. Design Scenarios: Approach #2 • Start with Analysis Scenarios • Need to make design decision at the early stage OO Design

29. Design Scenarios: Notation • Name • Trigger • can be a method or a user event • Assumption • Outcome • Note OO Design

30. Design Scenarios: Example • Name: User rents a tape • Trigger: a correct video id is entered • Assumption: • A rental object is defined (REN_getRenalID() returns not null) • The video is available (VID_videoAvailable(Vid) returns true) • Outcome • Video count decrement(VID_VideoCountDecrease(Vid)) • Tape is recorded rented by user (REN_AddTape(RID, VID)) • Note • id can either be entered by an employee or bar code reader OO Design

31. Design Object Interaction Diagrams (OIDs) • Is used for dynamic modeling • Is a graphical representation of object collaborations • Involve newly added classes for control, interface, communication, distribution, and storage (may come from reusable code) • Is architecture driven • Client/Server implementation should be different from desk top implementation OO Design

32. Design OID: Techniques • Start with everything you have: • use cases, analysis and design scenarios, and analysis OIDs • Consider the responsibilities of newly added design classes • Reflect the interaction among objects in Design Object Model • Always start with a task and ask: which object can handle this task OO Design

33. Design OID: Techniques (2) • Make sure the parameters and return values are well defined, especially for large systems • Clearly indicate control and threading data OO Design

34. Design OID: Techniques (3) • Have the group work on a couple together • Have every group member work on several • Have another meeting to review the results • Update the Design Object Model, if necessary OO Design

35. Design OID: Notation • Focus of control • multitasking • process and subsystem boundary • Example on page 302 OO Design

36. Design OID: Good News • Only the major design scenarios are documents and developed into Design OID OO Design

37. Design State Models • About the same as the Analysis state model • One diagram for each class OO Design

38. Design Class Descriptions • Very much the same as analysis class descriptions • For developers • map out members and methods for • public • protected • private • See book for notation changes OO Design

39. Rejected Design Alternatives • List the rejected designs decisions with reasons OO Design

40. Database Design • Not from IBM • Define all the tables • The name • Columns • Data type and size of all columns • Restrictions on all columns (default value, initial value, allow NULL, etc) • Key • Foreign keys • Other important business rules OO Design