11/5/01OO Design1 Design Object-Oriented Design

11/5/01OO Design2 Object-Oriented Design  The process of determining the architecture, and specifying the classes needed to implement a software product in CONCURRENTLY

11/5/01OO Design3 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

11/5/01OO Design4 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

11/5/01OO Design5 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

11/5/01OO Design6 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

11/5/01OO Design7 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

11/5/01OO Design8 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

11/5/01OO Design9 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

11/5/01OO Design10 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

11/5/01OO Design11 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

11/5/01OO Design12 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)

11/5/01OO Design13 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!

11/5/01OO Design14 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.

11/5/01OO Design15 Subsystem Model  The most common reason of having subsystem is “divide and conquer”  Others reasons are reuse dividing the work – CS625/CS630 etc.

11/5/01OO Design16 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

11/5/01OO Design17 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

11/5/01OO Design18 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

11/5/01OO Design19  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 Subsystem Model

11/5/01OO Design20 Design Object Model  Consists of the classes, their attributes, operations, and interrelationships among the classes

11/5/01OO Design21 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

11/5/01OO Design22 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)

11/5/01OO Design23 Notation  See page 285

11/5/01OO Design24 Design Scenarios  Define system behaviors at a concrete level  Include information regarding how to trigger the scenarios

11/5/01OO Design25 Design Scenarios: Purposes  Define a complete set of functional specifications that define the externally visible behaviors  Define the assumptions and outcomes of Design OIDs

11/5/01OO Design26 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!

11/5/01OO Design27 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

11/5/01OO Design28 Design Scenarios: Approach #2  Start with Analysis Scenarios  Need to make design decision at the early stage

11/5/01OO Design29 Design Scenarios: Notation  Name  Trigger can be a method or a user event  Assumption  Outcome  Note

11/5/01OO Design30 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

11/5/01OO Design31 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

11/5/01OO Design32 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

11/5/01OO Design33 Design OID: Techniques (2)  Make sure the parameters and return values are well defined, especially for large systems  Clearly indicate control and threading data

11/5/01OO Design34 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

11/5/01OO Design35 Design OID: Notation  Focus of control  multitasking  process and subsystem boundary  Example on page 302

11/5/01OO Design36 Design OID: Good News  Only the major design scenarios are documents and developed into Design OID

11/5/01OO Design37 Design State Models  About the same as the Analysis state model  One diagram for each class

11/5/01OO Design38 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

11/5/01OO Design39 Rejected Design Alternatives  List the rejected designs decisions with reasons

11/5/01OO Design40 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