1 CS 432 Object-Oriented Analysis and Design Week 3 The Design Model.

1

CS 432 Object-Oriented Analysis and Design

Week 3The Design Model

2

Use Case ModelRequirements

Analysis Model

Design Model

DeploymentModel

Implementation

Analysis

Design

Implementation

Test

specified by

Test Model

realized by

distributed by

implemented by

verified by

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

Primary Unified Process Models

Deployment

* From Unified Software Development Process [Jacobson, Booch, & Rumbaugh, 1999]

3

What is Object-Oriented Design?

The bridge between a user’s requirements and programming for the new system “Blueprints”, or design models, are

necessary to build systems An adaptive approach to development

Requirements and design are done incrementally within an iteration

A complete set of designs may not be developed at one time

4

Overview of Object-Oriented Programs

Object-oriented programs consist of a set of computing objects that cooperate to accomplish a result Each object has program logic and data

encapsulated within it Objects send each other messages to collaborate

Most object-oriented programs are event-driven

Instantiation of a class creates an object based on the template provided by the class definition

5

Object-Oriented Design Models

Identify all objects that must work together to carry out a use case

Divide objects into groups for a multilayer design

Interaction diagrams describe the messages that are sent between objects Includes sequence and communication

diagrams Design class diagrams document and

describe the programming classes

6

Object-Oriented Design Models (continued)

Statecharts capture information about the valid states and transitions of an object

Package diagrams denote which classes work together as a subsystem

Design information is primarily derived from Domain model class diagrams

Interaction diagrams

7

Object-Oriented Design Process

Create a first-cut model of the design class diagrams

Develop interaction diagrams for each use case or scenario (communication or sequence)

Update the design class diagrams Method names, method parameters, attributes,

attribute data types, and relationship multiplicity Partition the design class diagrams into

related functions using package diagrams

8

Design Classes and Design Class Diagrams

Design class diagrams are extensions of domain or analysis class model diagrams Elaborate on attribute details Define parameters and return values of methods Define the internal logic of methods

A first-cut design class diagram is based on the domain model and engineering design principles

Interaction diagrams are used to refine a design class diagram as development progresses

ArchitecturalDesign

[Architect]

Design aUse Case

[Use-Case Engineer]

Design aClass

[Component Engineer]

Design aSubsystem

[Component Engineer]

AnalysisModel

SupplementaryRequirements

Design Workflow

Use-CaseModel

Analysis Class(complete)

Design Class(outlined)

Interface(outlined)

ArchitecturalDescription

(design view)

DeploymentModel

Use CaseRealization

(Design)

Subsystem(outlined)

Design Class(complete)

Subsystem(complete)

Interface(complete)

ArchitecturalDescription

(analysis view)

10

The Design Workflow The input to the design workflow is the set of

analysis workflow artifacts These artifacts are iterated and incremented until

they can be used by the programmers A major aspect of this iteration and

incrementation is The identification of operations or methods The identification of method parameters and

parameter data types The identification of attribute types, and Their allocation to the appropriate classes Relationships between classes – type and multiplicity

11

The Design Workflow (contd)

Many other decisions have to be made as part of the design workflow, including Choice of programming language Deciding how much of existing

information systems to reuse in the new information system

Level of portability The allocation of each software

component to its hardware component

12


The case studies in this class are small-scale information systems Under 5,000 lines of Java or C++ code in length

The Unified Process was designed for developing large-scale information systems 500,000 lines of code or more These information systems are at least 100 times

larger than the case studies presented in this class

Therefore, some aspects of the Unified Process are inapplicable to our case studies

13


During the analysis workflow, a large information system is partitioned into analysis packages Each analysis package consists of a set of related

classes that can be implemented as a single unit Example:

Accounts payable, accounts receivable, and general ledger are typical analysis packages

The concept underlying analysis packages is: It is easier to develop smaller information systems

than larger information systems A large information system will be easier to develop if

it can be decomposed into independent packages

14


The idea of decomposing a large workflow into independent smaller workflows is carried forward to the design workflow

The objective is to break up the upcoming implementation workflow into manageable pieces Subsystems

15


Reasons why subsystems are utilized It is easier to implement a number of

smaller subsystems than one large system

If the subsystems are independent, they can be implemented by programming teams working in parallel

The information system as a whole can then be delivered sooner

16


The architecture of an information system includes The various component modules How they fit together The allocation of components to

subsystems The task of designing the architecture is

specialized It is performed by an information system

architect

17


The architect needs to make trade-offs Every information system must satisfy its

functional requirements (the use cases) It also must satisfy its nonfunctional

requirements, including Portability, reliability, robustness, maintainability,

and security It must do all these things within budget and

within the time constraint The architect must assist the client by

laying out the trade-offs

18


It is usually impossible to satisfy all the requirements, functional and nonfunctional, within the cost and time constraints Some sort of compromises have to be made

The client has to Relax some of the requirements; Increase the budget; and/or Move the delivery deadline

19


The architecture of an information system is critical The requirements workflow can be fixed during

the analysis workflow The analysis workflow can be fixed during the

design workflow The design workflow can be fixed during the

implementation workflow But there is no way to recover from

suboptimal architecture The architecture must immediately be redesigned

20

Traditional versus Object-Oriented Design

In the traditional paradigm, the design phase consists of Architectural design

The information system is decomposed into modules

followed by Detailed design

Algorithms and data structures are designed for each module

21

Traditional versus Object-Oriented Design (contd)

Classes are modules Much of traditional architectural design is performed as

part of class extraction in the object-oriented analysis workflow

22

Some Fundamental Design Principles

Encapsulation Each object is a self-contained unit

containing both data and program logic Object reuse

Standard objects can be used over and over again within a system

Information hiding Data associated with an object is not

visible Methods provide access to data

23

Some Fundamental Design Principles (contd)

Navigation visibility Describes which objects can interact with each

other Coupling

Measures how closely classes are linked Want LOW coupling

Cohesion Measures the consistency of functions in a class Want HIGH cohesion

Separation of responsibilities Divides a class into several highly cohesive classes

24

University SystemUse Case Diagram

25

Analysis Class Diagram

26

How to Create Design-LevelClass Diagrams

To create and evolve a design class diagram, you need to iteratively model: Classes Responsibilities Associations Inheritance relationships Composition associations Association classes Interfaces

27

Classes

An object is any person, place, thing, concept, event, screen, or report applicable to your system.

Objects both know things (they have attributes) and they do things (they have methods).

A class is a representation of an object and, in many ways, it is simply a template from which objects are created.

Classes form the main building blocks of an object-oriented application.

Although thousands of students attend the university, you would only model one class, called Student, which would represent the entire collection of students.

28

Classes Classes are typically modeled as rectangles

with three sections: the top section for the name of the class, the middle section for the attributes of the class, and the bottom section for the methods of the

class.

ReferenceBook Class Name Begins with a capital letter Every other word is capitalized. No blanks

Three sections:

Name:

Attributes:

Methods:

UML Class

29

Attributes & Methods

Attributes are the information stored about an object (or at least information temporarily maintained about an object)

Students have student numbers, names, addresses, and phone numbers.

Methods are the things an object or class do.

Students also enroll in courses, drop courses, and request transcripts.

You should think of methods as the object-oriented equivalent of functions and procedures.

30

Responsibilities or Methods

How to find responsibilities which are methods?

Ask these questions: How am I going to be used? How am I going to collaborate with

other classes? How am I described in the context of

this system's responsibility? What do I need to know? What state information do I need to

remember over time? What states can I be in?

31

Identifying Responsibilities or

Methods

Methods usually correspond to queries about attributes (and sometimes association) of the objects.

Methods are responsible for managing the value of attributes such as query, updating, reading and writing.

32

Level of Detail An important consideration the appropriate level of detail. Consider the Student class modeled which has an attribute called

Address. Notice how the Address class has been modeled to include an

attribute for each piece of data it comprises and two methods have been added: one to verify it is a valid address and one to output it as a label (perhaps for an envelope).

By introducing the Address class, the Student class has become more cohesive.

The Address class could now be reused in other places, such as the Professor class, reducing your overall development costs.

A student may live in a different location than his permanent mailing address, such as a dorm¾information the system may need to track. Having a separate class to implement addresses should make the addition of this behavior easier to implement.

33

Level of Detail in a Design-Level Class Diagram

Class information: visibility and scope

34

Constructors Constructor methods provide a way of

initializing an object. A constructor method has the same name as its

class and is automatically invoked by the object-oriented programming environment (e.g., the Java Virtual Machine) when new instance objects of a class are created.

As the return type of the constructor is always the same as the class and the constructor’s name, the return type is often omitted from the UML visual representation of the constructor.

Since a constructor may also have parameters like any method, the parameters of a constructor can be used to assign initial values to the attributes of the object.

35

Constructor Example

In programming source code, new instance objects are created by using the new command, which executes any code in the constructor, and returns the new object.

// Create a new account object with id 12 and // assign it to the acct variable. Account acct = new Account(12);

// Get the id of the new account object. int id = acct.getId();

36

Refactoring or Class Normalization

A process in which you refactor the behavior of classes to increase their cohesion and/or to reduce the coupling between classes.

A seminar is an offering of a course, for example, there could be five seminar offerings of the course "CS 208 Introduction to Computer Science."

The attributes name and fees were moved to the Course class and courseNumber was introduced.

37

Course with Accessor and Mutator Methods

Depicts Course as it would appear with its getter and setter methods modeled

38

Associations (Binary Relationships)

Objects are often associated with, or related to, other objects.

Several associations exist: Students are ON WAITING LIST for seminars Professors INSTRUCT seminars Seminars are an OFFERING OF courses A professor LIVES AT an address

Associations are modeled as lines connecting the two classes whose instances (objects) are involved in the relationship.

When you model associations in UML class diagrams, you show them as a thin line connecting two classes

The label, which is optional, although highly recommended, is typically one or two words describing the association.

For example, professors instruct seminars.

39

Associations (contd)

UML Notation:

You also need to identify the multiplicity of an association.

The multiplicity of the association is labeled on either end of the line, one multiplicity indicator for each direction

40

Multiplicity Indicators

Indicator Meaning

0..1 Zero or one

1 One only

0..* Zero or more

1..* One or more

n Only n (where n > 1)

0..n Zero to n (where n > 1)

1..n One to n (where n > 1)

41

Multiplicity: 1-to-1(Bank Example)

This multiplicity simply indicates that one Customer object owns exactly one Account Object, and the Account is owned by exactly one customer object.

42

Multiplicity: Many-to-1(University Example)

43

Inheritance Relationships

Similarities often exist between different classes. Very often two or more classes will share the

same attributes and/or the same methods. Because you don’t want to have to write the

same code repeatedly, you want a mechanism that takes advantage of these similarities.

Inheritance models “is a” and “is like” relationships, enabling you to reuse existing data and code easily.

When A inherits from B, we say A is the subclass of B and B is the superclass of A.

The UML modeling notation for inheritance is a line with a closed arrowhead pointing from the subclass to the superclass.

44

Inheritance hierarchy

45

Guidelines For Identifying Super-sub Relationships: Top-

down

Look for noun phrases composed of various adjectives on class name.

Example, Military Aircraft and Civilian Aircraft.

Only specialize when the sub classes have significant behavior.

46

Guidelines For Identifying Super-sub Relationships:

Bottom-up

Look for classes with similar attributes or methods.

Group them by moving the common attributes and methods to super class.

Do not force classes to fit a preconceived generalization structure.

47


Reusability

Move attributes and methods as high as possible in the hierarchy.

At the same time do not create very specialized classes at the top of hierarchy.

This balancing act can be achieved through several iterations.

48


Multiple inheritance Avoid use of multiple

inheritance. It is also more

difficult to understand programs written in multiple inheritance system.

Java does not support multiple inheritance but C++ does.

49

Multiple Inheritance

One way to achieve the benefits of multiple inheritance is to inherit from the most appropriate class and add an object of other class as an attribute.

In essence, a multiple inheritance can be represented as an aggregation of a single inheritance and aggregation. This meta model reflects this situation

Multiple Inheritance

Single Inheritance Aggregation

50

Abstract Classes & Inheritance

The Person class is abstract: objects are not created directly from it, and it captures the similarities between the students and professors.

Abstract classes are modeled with their names in italics, as opposed to concrete classes, classes from which objects are instantiated, whose names are in normal text.

Both classes had a name, e-mail address, and phone number, so these attributes were moved into Person.

The Purchase Parking Pass method is also common between the two classes.

By introducing this inheritance relationship to the model, the amount of work to be performed was reduced.

Instead of implementing these responsibilities twice, they are implemented once, in the Person class, and reused by Student and Professor.

51

Aggregation Relation An aggregation is an association that supports a

loose relation between objects in which one object is considered a “part of” the other object in the relation.

Consider the relation between a Computer and a Printer.

“a Computer may be attached to 0 or more Printers; at any one point in time a Printer is connected to 0 or 1

Computer; over time, many Computers may use a given Printer; the Printer may exist even if there are not attached

Computers the Printer is, in a very real sense, independent of the

Computer.”

52

Composition Relation

A composition relation is a stronger form of aggregation that should be used when the part class has no independent existence from the whole.

For example, since a customer’s account would not exist in a system without the customer, it qualifies as a composite relation. In this capacity an Account should be though of as being part-of a customer.

53

Composition Relation (contd)

Another example: A building is composed of one or more

rooms, and then, in turn, that a room may be composed of several subrooms (you can have recursive composition)

Customer Order from a Retail Catalog

DVD Movie VHS Movie Video Game

Rental Item

Rental Invoice

1..*1

Customer

Checkout Screen

0..1

1

Simple

Association

Class

Abstract

Class

Simple

Aggregation

GeneralizationComposition

Multiplicity

Video Store Example

56

Association Classes

The association between the two classes may be modeled as a class

You use this when you have many-to-many relationships like the association class in an ERD

57

Interfaces The C# and Java programming languages allow for the

creation of interface entities that capture a collection of methods representing a public interface. (C++ uses abstract classes)

An interface is similar to an abstract class that does not have any concrete methods at all.

An interface is simply a collection of method signatures. A List interface provides a nice example of the benefits of

using interfaces.

58

Interfaces (contd)

59

Interfaces (contd) Interfaces are implemented, “realized” in UML

parlance, by classes and components To realize an interface a class or component must

implement the operations. Any given class or component may implement zero or

more interfaces and one or more classes or components can implement the same interface.

Report

MemberReport ManagerReport

DBMgr

**

«interface»ChocAn

1

*

ServiceCatalog

1

*

1*

60

Polymorphism

Polymorphism means many forms and concerns the ability of an object to dynamically take on a different form depending on the runtime context.

Although technically correct, this definition is a bit misleading since the object does not exactly change form, but instead the way in which it’s viewed by other objects changes.

We should also note that polymorphism involves the behavior of objects.

61

Polymorphism (contd)

Consider the following three class fragments taken from a graphical user interface application.

The abstract Component class represents a generic component that captures the common functionality of graphical widgets that can be displayed on a canvas/window.

The Button and TextField classes share the common functionality, having an (x, y) position in the window and responding to messages requesting them to paint themselves on the canvas, erase themselves, and move themselves from one location to another.

62


63


Assume we are given a List of component objects which we wish to draw on the screen. The following pseudo-code would accomplish this desire:

ForEach component In the list Do Send the component a paint() message;

Polymorphism concerns the fact that although we are sending messages to Component objects, the actual method that handles the message will be executed as part of a Button or TextField object.

When an object receives a message, the most specific method of it’s parent class or it’s ancestors will execute.

However, the key point isn’t what method executes, but what the type of object is receiving the message.

64

Signatures and Method Overloading

A significant difference between procedural functions and object-oriented methods concerns method overloading, which is based on the concept of signatures.

A method signature is the combination of its visibility, name, parameter cardinality (number of parameters), the types of these parameters, and its return type.

For example, all of the methods in the following list have different signatures:

+getId():int OR -getId():int // Visibility differs +getBalance():int // Different name +withdraw(amount:int):void // Different name +withdraw(amount:float):void // Parameter type

differs +withdraw(id: int,amount:float):void// Different

parameter cardinality Note that current object-oriented programming languages

require that all methods in the same class and with the same name have the same return type.

65

Overloading An overloaded method occurs when two or more methods

with the same name in the same class have different signatures.

For example, the Withdraw method in the following example class is overloaded.

In this example the withdraw method is overloaded since the parameter type of the single parameter is different in each method.

When an object of this Account class receives a withdraw method, the object-oriented execution environment (e.g., the Java Virtual Machine) will dynamically select and execute the withdraw method with the corresponding parameter type.

1 CS 432 Object-Oriented Analysis and Design Week 3 The Design Model.

Documents

Transcript of 1 CS 432 Object-Oriented Analysis and Design Week 3 The Design Model.