INFORMATION SYSTEMS @ X INFO425: Systems Design Chapters 11 &12 The Object Oriented Approach to Design

INFORMATION SYSTEMS @ XINFORMATION SYSTEMS @ X

INFO425: Systems DesignINFO425: Systems Design

Chapters 11 &12Chapters 11 &12

The Object Oriented Approach to DesignThe Object Oriented Approach to Design



Learning ObjectivesLearning Objectives

Explain the purpose and objectives of object-Explain the purpose and objectives of object-oriented designoriented design

Develop design class diagramsDevelop design class diagrams

Develop interaction diagrams based on the Develop interaction diagrams based on the principles of object responsibility and use case principles of object responsibility and use case controllerscontrollers



Learning Objectives (Learning Objectives (continuedcontinued))

Develop detailed sequence diagrams as the core Develop detailed sequence diagrams as the core process in systems designprocess in systems design

Develop communication diagrams as part of Develop communication diagrams as part of systems designsystems design

Document the architectural design using package Document the architectural design using package diagramsdiagrams



OverviewOverview

Primary focus of this chapter is how to develop Primary focus of this chapter is how to develop detailed object-oriented design modelsdetailed object-oriented design models

Programmers use models to code the system – Programmers use models to code the system – design models are bridgedesign models are bridge

Two most important models are design class Two most important models are design class diagrams and interaction diagrams (sequence diagrams and interaction diagrams (sequence diagrams and communication diagrams)diagrams and communication diagrams)

Class diagrams are developed for domain, view, Class diagrams are developed for domain, view, and data access layersand data access layers

Interaction diagrams extend system sequence Interaction diagrams extend system sequence diagramsdiagrams

The bulk of the design work….The bulk of the design work….

interaction (sequence) diagramsinteraction (sequence) diagrams



Overview of Object-Oriented ProgramsOverview of Object-Oriented Programs

Set of objects that cooperate to accomplish resultSet of objects that cooperate to accomplish result Object contains program logic and necessary Object contains program logic and necessary

attributes in a single unitattributes in a single unit Objects send each other messages and Objects send each other messages and

collaborate to support functions of main programcollaborate to support functions of main program OO systems designer provides detail for OO systems designer provides detail for

programmersprogrammers Design class diagrams, interaction diagrams, and some state Design class diagrams, interaction diagrams, and some state

machine diagramsmachine diagrams



Object-Oriented Three-Layer Program



Sequence Diagram for Updating Student Sequence Diagram for Updating Student (Figure (Figure 11-12)11-12)



Student Class Examples for the Domain Class and the Student Class Examples for the Domain Class and the Design Class Diagrams Design Class Diagrams (Figure 11-13)(Figure 11-13)



Example Example Class Class Definition in Definition in Java for Java for Student ClassStudent Class(Figure 11-4a)(Figure 11-4a)



Object-Oriented Design Object-Oriented Design Processes and ModelsProcesses and Models

Diagrams developed for analysis/requirementsDiagrams developed for analysis/requirements Use case diagrams, use case descriptions and activity Use case diagrams, use case descriptions and activity

diagrams, domain model class diagrams, and system diagrams, domain model class diagrams, and system sequence diagrams sequence diagrams

Diagrams developed for designDiagrams developed for design Interaction diagrams and package diagrams Interaction diagrams and package diagrams Design class diagrams – include object-oriented classes, Design class diagrams – include object-oriented classes,

navigation between classes, attribute names, method names, navigation between classes, attribute names, method names, and properties needed for programmingand properties needed for programming



Design Models Design Models with Their with Their Respective Respective Input ModelsInput Models(Figure 11-2)(Figure 11-2)



Iterative Process of OO DesignIterative Process of OO Design——Design Steps Design Steps (Figure 11-6)(Figure 11-6)

RealizationRealization of use case – specification of all detailed system processing for of use case – specification of all detailed system processing for each use caseeach use case



Design Class SymbolsDesign Class Symbols

UML does not distinguish between design class UML does not distinguish between design class notation and domain model notationnotation and domain model notation

Domain model class diagram shows conceptual Domain model class diagram shows conceptual classes in users’ work environmentclasses in users’ work environment

Design class diagram specifically defines software Design class diagram specifically defines software classesclasses

UML uses UML uses stereotypestereotype notation to categorize a notation to categorize a model element by its characteristicsmodel element by its characteristics



Standard Stereotypes Found in Design ModelsStandard Stereotypes Found in Design Models



Standard Design ClassesStandard Design Classes

EntityEntity – design identifier for problem domain class – design identifier for problem domain class Persistent classPersistent class – exists after system is shut down – entities – exists after system is shut down – entities

usually persistentusually persistent

Control Control – mediates between boundary and entity – mediates between boundary and entity classes, between the view layer and domain layerclasses, between the view layer and domain layer

Boundary Boundary – designed to live on system’s – designed to live on system’s automation boundary, touched by usersautomation boundary, touched by users

User interface and windows classesUser interface and windows classes

Data accessData access – retrieves data from and sends data – retrieves data from and sends data to databaseto database

Control, boundary and Data access classes – not persistent Control, boundary and Data access classes – not persistent



Notation Used to Define a Design ClassNotation Used to Define a Design Class



Student Design Student Design Class ExampleClass Example



Developing the First-Cut Design Class DiagramDeveloping the First-Cut Design Class Diagram

Extend domain model class diagramExtend domain model class diagram Elaborate attributes with type and initial value informationElaborate attributes with type and initial value information Define navigation visibilityDefine navigation visibility

Detailed design proceeds use case-by-use case Detailed design proceeds use case-by-use case Interaction diagrams implement navigationInteraction diagrams implement navigation Navigation arrows are updated to be consistentNavigation arrows are updated to be consistent Method signatures are added to each classMethod signatures are added to each class



Developing First-Cut Design Class DiagramDeveloping First-Cut Design Class Diagram

Choose classes involved with the use caseChoose classes involved with the use case Add use case controllerAdd use case controller Elaborate attributesElaborate attributes

Visibility, type-expression, initial-value, propertyVisibility, type-expression, initial-value, property

Establish first-cut navigation visibilityEstablish first-cut navigation visibility One-to-many relationships usually navigated from superior to One-to-many relationships usually navigated from superior to

subordinatesubordinate Mandatory relationships usually navigated from independent to Mandatory relationships usually navigated from independent to

dependent dependent When an object needs information from another object, When an object needs information from another object,

navigation arrow points to the object itself or to its parent in navigation arrow points to the object itself or to its parent in hierarchyhierarchy

Navigation can be in both directions (arrows bidirectional)Navigation can be in both directions (arrows bidirectional)



Start with Domain Model Class DiagramStart with Domain Model Class Diagram



Navigation VisibilityNavigation Visibility

A design principle in which one object has reference to another A design principle in which one object has reference to another objectobject

An object interacts with other objects by sending messages…’invoke’ An object interacts with other objects by sending messages…’invoke’ Objects can only interact if there is navigation visibilityObjects can only interact if there is navigation visibility During design – define which objects can interact with othersDuring design – define which objects can interact with others Visibility signified by direction of arrowVisibility signified by direction of arrow May be one or two directionMay be one or two direction Discovered as you work through use cases … does one object need to send a Discovered as you work through use cases … does one object need to send a

message to another in order to carry out the use case?message to another in order to carry out the use case?



First-Cut RMO First-Cut RMO Design Class Design Class Diagram for Diagram for Look Up Item Look Up Item AvailabilityAvailability Use Use Case Case (Figure 11-(Figure 11-21)21)



Exercise 1 on page 278Exercise 1 on page 278

Form groups 2-3 Form groups 2-3 Build a domain class diagram for exercise 1 on Build a domain class diagram for exercise 1 on

page 278page 278



Design Patterns and the Use Case ControllerDesign Patterns and the Use Case Controller

Design patternDesign pattern A standard solution template to a design requirement that A standard solution template to a design requirement that

facilitates the use of good design principlesfacilitates the use of good design principles

Use case controller patternUse case controller pattern Design requirement is to identify which problem domain Design requirement is to identify which problem domain

class should receive input messages from the user interface class should receive input messages from the user interface for a use casefor a use case

Solution is to choose a class to serve as a collection point for Solution is to choose a class to serve as a collection point for all incoming messages for the use case. Controller acts as all incoming messages for the use case. Controller acts as intermediary between outside world and internal system intermediary between outside world and internal system

Artifact Artifact –– a class invented by a system designer to handle a a class invented by a system designer to handle a needed system function, such as a controller classneeded system function, such as a controller class



Some Fundamental Design PrinciplesSome Fundamental Design Principles

EncapsulationEncapsulation – each object is self-contained unit that – each object is self-contained unit that includes data and methods that access dataincludes data and methods that access data

Object reuseObject reuse – designers often reuse same classes for – designers often reuse same classes for windows componentswindows components

Information hiding Information hiding –– data associated with object is not data associated with object is not visible to outside worldvisible to outside world

Protection from variationsProtection from variations – parts of a system that are – parts of a system that are unlikely to change are segregated from those that willunlikely to change are segregated from those that will

Indirection Indirection –– an intermediate class is placed between an intermediate class is placed between two classes to decouple them but still link them two classes to decouple them but still link them



Some Fundamental Design Principles Some Fundamental Design Principles (Continued)(Continued)

CouplingCoupling – qualitative measure of how closely – qualitative measure of how closely classes in a design class diagram are linkedclasses in a design class diagram are linked

Number of navigation arrows in design class diagram or Number of navigation arrows in design class diagram or messages in a sequence diagrammessages in a sequence diagram

Loosely coupled – system is easier to understand and Loosely coupled – system is easier to understand and maintainmaintain

CohesionCohesion – qualitative measure of consistency – qualitative measure of consistency of functions within a single classof functions within a single class

Separation of responsibilitySeparation of responsibility – divide low cohesive class into – divide low cohesive class into several highly cohesive classesseveral highly cohesive classes

Highly cohesive – system is easier to understand and Highly cohesive – system is easier to understand and maintain and reuse is more likelymaintain and reuse is more likely



Iterative Process of OO DesignIterative Process of OO Design——Design Steps Design Steps (Figure 11-6)(Figure 11-6)

RealizationRealization of use case – specification of all detailed system processing for of use case – specification of all detailed system processing for each use caseeach use case



Realizing Use Cases and Defining Methods Realizing Use Cases and Defining Methods ——Designing with Sequence DiagramsDesigning with Sequence Diagrams

Realization of use case done through interaction Realization of use case done through interaction diagram developmentdiagram development

Determine what objects collaborate by sending Determine what objects collaborate by sending messages to each other to carry out use casemessages to each other to carry out use case

Sequence diagrams and communication diagrams Sequence diagrams and communication diagrams represent results of design decisionsrepresent results of design decisions

Use well-established design principles such as coupling, Use well-established design principles such as coupling, cohesion, separation of responsibilitiescohesion, separation of responsibilities



Object ResponsibilityObject Responsibility

Objects are responsible for system Objects are responsible for system processingprocessing

Responsibilities include knowing and Responsibilities include knowing and doingdoing

Knowing about object’s own data and other classes of Knowing about object’s own data and other classes of objects with which it collaborates to carry out use casesobjects with which it collaborates to carry out use cases

Doing activities to assist in execution of use case Doing activities to assist in execution of use case > Receive and process messagesReceive and process messages> Instantiate, or create, new objects required to complete use caseInstantiate, or create, new objects required to complete use case

Design means assigning responsibility to Design means assigning responsibility to the appropriate classes based on design the appropriate classes based on design principles and using design patternsprinciples and using design patterns



Annotated System Sequence Diagram (SSD) for the Annotated System Sequence Diagram (SSD) for the Look Up Look Up Item AvailabilityItem Availability Use Case Use Case (from Chapter 7)(from Chapter 7)



LifelinesLifelines

Vertical line under object or actor: shows passage of timeVertical line under object or actor: shows passage of time

If dashed: creation and destruction of thing is not important for If dashed: creation and destruction of thing is not important for scenarioscenario

Long narrow rectangles: activation lifelines used to emphasize Long narrow rectangles: activation lifelines used to emphasize that an object is active only during part of a scenario for a that an object is active only during part of a scenario for a sequence diagramsequence diagram



MessagesMessages

Requests from one actor or object to another to do some Requests from one actor or object to another to do some actionaction

Invokes a particular methodInvokes a particular method Syntax:Syntax:

[true/false condition] return-value:=message-name[parameter list][true/false condition] return-value:=message-name[parameter list]> True/false conditon: test to see if message to be sent True/false conditon: test to see if message to be sent

[first_item] ordernumber:= createOrder()[first_item] ordernumber:= createOrder()

> Return-value: what is to be returned from invoked method Return-value: what is to be returned from invoked method Previous example - ordernumberPrevious example - ordernumber

> Message name: name of message – descriptive Message name: name of message – descriptive createOrdercreateOrder

> Parameter list: List of values passed to the method to be executedParameter list: List of values passed to the method to be executed createOrderitem (itemID, qty)createOrderitem (itemID, qty)



First-Cut Sequence DiagramFirst-Cut Sequence Diagram

Start with elements from SSDStart with elements from SSD Replace Replace :System:System object with use case controller object with use case controller Add other objects to be included in use caseAdd other objects to be included in use case

Select input message from the use caseSelect input message from the use case Add all objects that must collaborateAdd all objects that must collaborate

Determine other messages to be sent Determine other messages to be sent Which object is source and destination of each message?Which object is source and destination of each message?



Objects included in Objects included in Look Up Item AvailabilityLook Up Item Availability



Guidelines for Sequence Diagram Development Guidelines for Sequence Diagram Development for Use Casefor Use Case

Take each input message and determine internal Take each input message and determine internal messages that result from that inputmessages that result from that input

For that message, determine its objectiveFor that message, determine its objective Needed information, class destination, class source, and Needed information, class destination, class source, and

objects created as a resultobjects created as a result Double check for all required classesDouble check for all required classes

Flesh out components for each messageFlesh out components for each message Iteration, guard-condition, passed parameters, return valuesIteration, guard-condition, passed parameters, return values



First-Cut Sequence Diagram for the First-Cut Sequence Diagram for the Look Up Item Look Up Item AvailabilityAvailability Use Case Use Case (Figure 11-14)(Figure 11-14)



Maintain Product InformationMaintain Product Information



Maintain Product InformationMaintain Product Information

Specific object, different one for Specific object, different one for each loopeach loop



Another ExampleAnother Example

Create a first cut sequence diagram for the following event, Create a first cut sequence diagram for the following event, based on this class diagrambased on this class diagram

TimeslotTimeslot

RoomRoom

ProfessorProfessor

SectionSection

11

0.*0.*11

11

EventEvent TriggerTrigger SourceSource ActivityActivity ResponseResponse DestinationDestination

Registrar Registrar creates new creates new course sectioncourse section

Section Section schedule schedule requestrequest

RegistrarRegistrar Create a new section Create a new section and assign to a and assign to a professor timeslot professor timeslot and a roomand a room

Scheduled Scheduled section section

RegistrarRegistrar

Assumptions:Assumptions:Registrar supplies prof ID, CourseID and max enrolmentSystem provides list of available rooms in specific time slots. Registrar chooses room / timeslot comboSystem creates section (and assigns CRN when prof, room and timeslot info has been found)System returns, Prof name, CRN., room desc. and timeslot to registrar once section has been createdCourseCourse

110.*0.*



Sequence DiagramSequence Diagram

sectionsection

timeslottimeslotroomroomprofessorprofessorRegistrarRegistrar

scheduleSection (CourseID, Prof ID, max

enrolment)profName:=getProfNam

e (Prof ID)

roomDesc:=getRoom (Size)

coursecourse

timeSlot:=getTimeslot (Length)CRN:creatSecti

on (profID, Room ID, Timeslot)

confirmSectioncreation (prof name, CRN, room

desc., timeslot)

Room_Time_slot_selection:=selectRoomTime

(time_slot. room)

sectionhandlersectionhandler

scheduleSection (CourseID, Prof ID, max

enrolment)

confirmSectioncreation (prof name, CRN, room

desc., timeslot)

Room_Time_slot_selection:=selectRoomTime

(time_slot. room)



Assumptions About First-Cut Sequence DiagramAssumptions About First-Cut Sequence Diagram

Perfect technology assumptionPerfect technology assumption Don’t include system controls like login/logout (yet)Don’t include system controls like login/logout (yet)

Perfect memory assumptionPerfect memory assumption Don’t worry about object persistence (yet)Don’t worry about object persistence (yet) Assume objects are in memory ready to workAssume objects are in memory ready to work

Perfect solution assumptionPerfect solution assumption Don’t worry about exception conditions (yet)Don’t worry about exception conditions (yet) Assume happy path/no problems solutionAssume happy path/no problems solution



Exercise Exercise

Exercise 1a – Thinking Critically – page 431 - be Exercise 1a – Thinking Critically – page 431 - be sure to add controller classsure to add controller class

Assume: to check out, librarian scans bookcopy# (not Assume: to check out, librarian scans bookcopy# (not catalog#) which is PK for BookCopy. Assume that Bookcopy catalog#) which is PK for BookCopy. Assume that Bookcopy retains FK to Book Title. retains FK to Book Title.

Book title contains attributes author and titleBook title contains attributes author and title Assume you don’t need to return bookcopy# (because we Assume you don’t need to return bookcopy# (because we

were able to scan this info).were able to scan this info).

Exercise 1c – annotate your copy of the domain Exercise 1c – annotate your copy of the domain classes with navigation visibility (and new classes with navigation visibility (and new class….)class….)



Developing a Multilayer DesignDeveloping a Multilayer Design

First-cut sequence diagram – use case controller First-cut sequence diagram – use case controller plus classes in domain layerplus classes in domain layer

Add data access layer – design for data access Add data access layer – design for data access classes for separate database interactionclasses for separate database interaction

No more perfect memory assumptionNo more perfect memory assumption Separation of responsibilitiesSeparation of responsibilities

Add view layer – design for user-interface classesAdd view layer – design for user-interface classes Forms added as windows classes to sequence diagram Forms added as windows classes to sequence diagram

between actor and controllerbetween actor and controller



Approaches to Data Access LayerApproaches to Data Access Layer



First-Cut Sequence Diagram for the First-Cut Sequence Diagram for the Look Up Item Look Up Item AvailabilityAvailability Use Case Use Case



Adding Data Access Layer for Adding Data Access Layer for Look Up Item Look Up Item AvailabilityAvailability Use Case Use Case



Designing the View LayerDesigning the View Layer

Add GUI forms or Web pages between actor and Add GUI forms or Web pages between actor and controller for each use casecontroller for each use case

Minimize business logic attached to a formMinimize business logic attached to a form

Some use cases require only one form; some Some use cases require only one form; some require multiple forms and dialog boxesrequire multiple forms and dialog boxes

View layer design is focused on high-level View layer design is focused on high-level sequence of forms/pages – the dialogsequence of forms/pages – the dialog



<<View>> ProductQuery Form Added for <<View>> ProductQuery Form Added for Look Look Up Item AvailabilityUp Item Availability Use Case Use Case



Complete Complete Look Up Item AvailabilityLook Up Item Availability Use Case with View Use Case with View LayerLayer



ProductWindow and MsgWindow for ProductWindow and MsgWindow for Maintain Maintain Product InformationProduct Information Use Case Use Case



Complete Complete Maintain Product InformationMaintain Product Information Use Case Use Use Case Use Case with View LayerCase with View Layer



Designing with Communication DiagramsDesigning with Communication Diagrams

Communication diagrams and sequence diagramsCommunication diagrams and sequence diagrams Both are interaction diagramsBoth are interaction diagrams

Both capture same informationBoth capture same information

Process of designing is same for bothProcess of designing is same for both

Model used is designer’s personal preferenceModel used is designer’s personal preference Sequence diagram – use case descriptions and dialogs follow Sequence diagram – use case descriptions and dialogs follow

sequence of stepssequence of steps

Communication diagram – emphasizes couplingCommunication diagram – emphasizes coupling



The Symbols of a Communication Diagram The Symbols of a Communication Diagram (Figure (Figure 11-24)11-24)



A Communication Diagram for A Communication Diagram for Look Up Item Availability Look Up Item Availability (Figure 11-25)(Figure 11-25)



Standard Stereotypes Found in Design ModelsStandard Stereotypes Found in Design Models



Look Up Item AvailabilityLook Up Item Availability Use Case Use Case Using Iconic Symbols Using Iconic Symbols



Updating the Design Class DiagramUpdating the Design Class Diagram

Design class diagrams developed for each layerDesign class diagrams developed for each layer New classes for view layer and data access layerNew classes for view layer and data access layer New classes for domain layer use case controllers New classes for domain layer use case controllers

Sequence diagram’s messages used to add methodsSequence diagram’s messages used to add methods Constructor methods Constructor methods Data get and set method Data get and set method Use case specific methodsUse case specific methods



Design Class with Method Signatures, Design Class with Method Signatures, for the ProductItem Class for the ProductItem Class (Figure 11-27)(Figure 11-27)



Updated Design Updated Design Class Diagram Class Diagram for the Domain for the Domain LayerLayer (Figure 11-28)(Figure 11-28)



Package DiagramPackage Diagram——Structuring Structuring the Major Componentsthe Major Components

High-level diagram in UML to associate classes of High-level diagram in UML to associate classes of related groupsrelated groups

Identifies major components of a system and Identifies major components of a system and dependenciesdependencies

Determines final program partitions for each layerDetermines final program partitions for each layer View, domain, data accessView, domain, data access

Can divide system into subsystem and show Can divide system into subsystem and show nesting within packagesnesting within packages



Partial Design of Partial Design of Three-Layer Three-Layer Package Diagram Package Diagram for RMOfor RMO

(Figure 11-29)(Figure 11-29)



RMO Subsystem Packages RMO Subsystem Packages (Figure 11-30)(Figure 11-30)



SummarySummary

Object-oriented design is the bridge between user Object-oriented design is the bridge between user requirements (in analysis models) and final system requirements (in analysis models) and final system (constructed in programming language)(constructed in programming language)

Systems design is driven by use cases, design Systems design is driven by use cases, design class diagrams, and sequence diagramsclass diagrams, and sequence diagrams

Domain class diagrams are transformed into design class Domain class diagrams are transformed into design class diagramsdiagrams

Sequence diagrams are extensions of system sequence Sequence diagrams are extensions of system sequence diagrams (SSDs)diagrams (SSDs)



Summary (Summary (continuedcontinued))

Object-oriented design principles must be appliedObject-oriented design principles must be applied Encapsulation – data fields are placed in classes along with methods Encapsulation – data fields are placed in classes along with methods

to process that datato process that data Low coupling – connectivity between classesLow coupling – connectivity between classes High cohesion – nature of an individual classHigh cohesion – nature of an individual class Protection from variations – parts of a system that are unlikely to Protection from variations – parts of a system that are unlikely to

change are segregated from those that willchange are segregated from those that will Indirection –Indirection – an intermediate class is placed between two classes to an intermediate class is placed between two classes to

decouple them but still link them decouple them but still link them Separation navigation – access classes have to other classesSeparation navigation – access classes have to other classes

Three-layer design is used because maintainableThree-layer design is used because maintainable

Documents

INFORMATION SYSTEMS @ X INFO425: Systems Design Chapters 11 &12 The Object Oriented Approach to Design