DESIGN PHASE

NAVI PERERA

SADCW_7e_Chapter12.pptx

Home >Computer Science homework help >DESIGN PHASE

Chapter 12

Click to edit Master text styles

Second level

Third level

Fourth level

Fifth level

Object-Oriented Design: Fundamentals

Chapter 12

Systems Analysis and Design in a Changing World 7th Ed Satzinger, Jackson & Burd

Chapter 12: Outline

Object-Oriented Design: Bridging from Analysis to Implementation

Steps of Object-Oriented Design

Design Classes and the Design Class Diagram

Designing with C R C Cards

Fundamental Principles for Good Design

Learning Objectives

Explain the purpose and objectives of object-oriented design

Develop design class diagrams

Use C R C cards to define class responsibilities and collaborations

Explain important fundamental principles of object-oriented design

Overview

This chapter and the next focus on designing software for the new system, at both the architectural and detailed level design

Design models are based on the requirements models learned in Chapters 3, 4, and 5

The steps of object-oriented design are explained

The main model discussed is the design class diagram

In this chapter, the C R C Cards technique is used to design the O O software

The chapter finishes with fundamental principles of good O O design

O O Design: Bridging from Analysis to Implementation

O O Design: Process by which a set of detailed OO design models are built to be used for coding

Strength of O O is requirements models from Chapters 3, 4, and 5 are extended to design models. No reinventing the wheel

Design models are created in parallel to actual coding/implementation with iterative S D L C

Agile approach says create models only if they are necessary. Simple detailed aspects don’t need a design model before coding

Object-Oriented Program Flow: Three Layer Architecture

Object-Oriented Program Flow

Instantiation

Creation of an object in memory based on the template provided by the class

Method

The function executed within an object when invoked by a message request (method call)

Sample Java with Methods

Sample V B.net with Methods

Analysis to Design to Implementation: Model Flow

Introduction to Design Models: Class Diagram

Introduction to Design Models: Sequence Diagram

Introduction to Design Models: Communication Diagram

Introduction to Design Models: Class-Responsibility-Collaboration (C R C)

Steps of Object-Oriented Design (1 of 2)

Object-oriented design

The process to identify the classes, their methods and the messages required for a use case

Use case driven

Design is carried out use case by use case

Steps of Object-Oriented Design (2 of 2)

Three paths

Simple use case use C R C Cards

Medium use case use Communication Diagram

Complex use case use Sequence Diagram

Design Class Diagrams

stereotype a way of categorizing a model element by its characteristics, indicated by guillemots (<< >>)

persistent class an class whose objects exist after a system is shut down (data remembered)

entity class a design identifier for a problem domain class (usually persistent)

boundary class or view class a class that exists on a system’s automation boundary, such as an input window form or Web page

controller class a class that mediates between boundary classes and entity classes, acting as a switchboard between the view layer and domain layer

data access class a class that is used to retrieve data from and send data to a database

Design Class Stereotypes

Notation for a Design Class

Syntax for Name, Attributes, and Methods

Notation for Design Classes (1 of 4)

Attributes

Visibility—indicates (+ or −) whether an attribute can be accessed directly by another object. Usually private (−) not public (+)

Attribute name—Lower case camelback notation

Type expression—class, string, integer, double, date

Initial value—if applicable the default value

Property—if applicable, such as {key}

Examples:

-accountNo: String {key}

-startingJobCode: integer = 01

Notation for Design Classes (2 of 4)

Method Signature

The notation for a method, contains the information needed to invoke a method

Methods

Visibility—indicates (+ or −) whether an method can be invoked by another object. Usually public (+), can be private if invoked within class like a subroutine

Method name—Lower case camelback, verb-noun

Parameters—variables passed to a method

Return type—the type of the data returned

Examples:

+getName(): string (what is returned is a string)

-checkValidity(date) : int (assuming int is a returned code)

Notation for Design Classes (3 of 4)

Class level method—applies to class rather than objects of class (aka static method). Underline it.

+findStudentsAboveHours(hours): Array

+getNumberOfCustomers(): Integer

Class level attribute—applies to the class rather than an object (aka static attribute). Underline it.

-noOfPhoneSales: int

Abstract class– class that can’t be instantiated.

Only for inheritance. Name in Italics.

Concrete class—class that can be instantiated.

Notation for Design Classes (4 of 4)

First-Cut Design Class Diagram

Proceed use case by use case, adding to the diagram

Pick the domain classes that are involved in the use case (see preconditions and post conditions for ideas)

Add a controller class to be in charge of the use case

Determine the initial navigation visibility requirements using the guidelines and add to diagram

Elaborate the attributes of each class with visibility and type

Note that often the associations and multiplicity are removed from the design class diagram as in text to emphasize navigation, but they are often left on

Start with Domain Class Diagram: R M O Sales Subsystem

Developing Design Classes

Navigation Visibility

The ability of one object to view and interact with another object

Accomplished by adding an object reference variable to a class.

Shown as an arrow head on the association line—customer can find and interact with sale because it has mySale reference variable

Navigation Visibility Guidelines

One-to-many associations that indicate a superior/subordinate relationship are usually navigated from the superior to the subordinate

Mandatory associations, in which objects in one class can’t exist without objects of another class, are usually navigated from the more independent class to the dependent

When an object needs information from another object, a navigation arrow might be required

Navigation arrows may be bidirectional.

Create First Cut Design Class Diagram: Use Case Create telephone sale with controller added

Designing With C R C Cards

C R C Cards—Classes, Responsibilities, Collaboration Cards

O O design is about assigning Responsibilities to Classes for how they Collaborate to accomplish a use case

Usually a manual process done in a brainstorming session

3 × 5 note cards

One card per class

Front has responsibilities and collaborations

Back has attributes needed

Example of C R C Card

C R C Cards Procedure

Because the process is to design, or realize, a single use case, start with a set of unused C R C cards. Add a controller class (Controller design pattern).

Identify a problem domain class that has primary responsibility for this use case that will receive the first message from the use case controller. For example, a Customer object for new sale.

Use the first cut design class diagram to identify other classes that must collaborate with the primary object class to complete the use case. Flesh our the cards.

Add user-interface classes to identify inputs and outputs

Add any other required utility classes

C R C Cards Suggestions

Start with the class that gets the first message from the controller. Name the responsibility and write it on card.

Now ask what this first class needs to carry out the responsibility. Assign other classes responsibilities to satisfy each need. Write responsibilities on those cards.

Sometimes different designers play the role of each class, acting out the use case by verbally sending messages to each other demonstrating responsibilities

Add collaborators to cards showing which collaborate with which. Add attributes to back when data is used

Eventually, user interface classes or even data access classes can be added

Example: Create customer account (1 of 5)

First-cut D C D

Example: Create customer account (2 of 5)

Controller and primary domain class

Example: Create customer account (3 of 5)

Problem domain classes and user interface classes

Example: Create customer account (4 of 5)

Adding data access classes

Example: Create customer account (5 of 5)

Final D C D with method signatures

Example: Create telephone sale

Example: D C D for Create telephone sale

Fundamental Design Principles (1 of 6)

Object Responsibility

A design principle that states objects are responsible for carrying out system processing

A fundamental assumption of O O design and programming

Responsibilities include “knowing” and “doing”

Objects know about other objects (associations) and they know about their attribute values. Objects know how to carry out methods, do what they are asked to do.

Note that C R C cards and the design in the next chapter involve assigning responsibilities to classes to carry out a use case.

If deciding between two alternative designs, choose the one where objects are assigned responsibilities to collaborate to complete tasks (don’t think procedurally).

Fundamental Design Principles (2 of 6)

Separation of Responsibilities

A K A Separation of Concerns

Applied to a group of classes

Segregate classes into packages or groups based on primary focus of the classes

Basis for multi-layer design – view, domain, data

Facilitates multi-tier computer configuration

Fundamental Design Principles (3 of 6)

Protection from Variations

A design principle that states parts of a system unlikely to change are separated (protected) from those that will surely change

Separate user interface forms and pages that are likely to change from application logic

Put database connection and S Q L logic that is likely to change in a separate classes from application logic

Use adaptor classes that are likely to change when interfacing with other systems

If deciding between two alternative designs, choose the one where there is protection from variations

Fundamental Design Principles (4 of 6)

Indirection

A design principle that states an intermediate class is placed between two classes to decouple them but still link them

A controller class between U I classes and problem domain classes is an example

Supports low coupling

Indirection is used to support security by directing messages to an intermediate class as in a firewall

If deciding between two alternative designs, choose the one where indirection reduces coupling or provides greater security

Fundamental Design Principles (5 of 6)

Coupling

A quantitative measure of how closely related classes are linked (tightly or loosely coupled)

Two classes are tightly coupled of there are lots of associations with another class

Two classes are tightly coupled if there are lots of messages to another class

It is best to have classes that are loosely coupled

If deciding between two alternative designs, choose the one where overall coupling is less

Fundamental Design Principles (6 of 6)

Cohesion

A quantitative measure of the focus or unity of purpose within a single class (high or low cohesiveness

One class has high cohesiveness if all of its responsibilities are consistent and make sense for purpose of the class (a customer carries out responsibilities that naturally apply to customers)

One class has low cohesiveness if its responsibilities are broad or makeshift

It is best to have classes that are highly cohesive

If deciding between two alternative designs, choose the one where overall cohesiveness is high

Summary (1 of 3)

This chapter focused on designing software that solves business problems by bridging the gap between analysis and implementation.

Design of software proceeds use case by use case, sometimes called “use case driven” and the design of each use case is called use case realization.

The process of design proceeds along three paths depending on the complexity of the user case. Simple use cases use C R C cards, medium complexity uses communication diagrams, complex use cases proceed with sequence diagrams.

Summary (2 of 3)

Design class diagrams include additional notation because design classes are now software classes, not just work concepts.

Key issues are attribute elaboration and adding methods. Method signatures include visibility, method name, arguments, and return types.

Other key terms are abstract vs. concrete classes, navigation visibility, and class level attributes and methods,

Summary (3 of 3)

C R C Cards technique can be used to design how the classes collaborate to complete each use case. C R C stands for Classes, Responsibilities, and Collaborations.

Once responsibilities are assigned to classes, the design class diagram is updated by adding methods to classes and updating navigation visibility.

Decisions about design options are guided by some fundamental design principles. Some of these are coupling, cohesion, protection from variations, indirection, and object responsibility.