Object-Oriented Modeling: Static Models Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified...

56
Object-Oriented Modeling: Static Models Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, 2 nd edition, Addison Wesley, 2005.

Transcript of Object-Oriented Modeling: Static Models Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified...

Object-Oriented Modeling: Static Models

Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, 2nd edition, Addison Wesley, 2005.

2

Object-Oriented Modeling

• Using object-orientation as a base, model the system as a number of objects that interact.

• Our surroundings consist of objects, such as people, trees, cars, towns and houses which are in some way related to each other.

• A model which is designed using an O-O technology is often easy to understand, as it can be directly related to reality. No "semantic gap"

3

Key Object-Oriented Ideas• Identity

• Abstraction

• Classification

• Encapsulation

• Inheritance

• Polymorphism

• Persistence

4

Key Object-Oriented Ideas• Identity

– Data are organized into discrete entities called objects.

– Objects have behavior and state.• Abstraction• Classification• Encapsulation• Inheritance• Polymorphism• Persistence

5

Key Object-Oriented Ideas• Identity• Abstraction

– OO design uses different abstractions to capture different parts of the system.

• Classification• Encapsulation• Inheritance• Polymorphism• Persistence

6

Key Object-Oriented Ideas• Identity• Abstraction• Classification

– Objects are grouped together by commonalities.

– Groups of objects become the basis of classes.• Encapsulation• Inheritance• Polymorphism• Persistence

7

Key Object-Oriented Ideas• Identity• Abstraction• Classification• Encapsulation

– Classes encapsulate behavior and data. – Encapsulated aspects of classes hide

details from other classes.• Inheritance• Polymorphism• Persistence

8

Key Object-Oriented Ideas• Identity• Abstraction• Classification• Encapsulation• Inheritance

– Different OO objects can reuse common behaviors through inheritance.

• Polymorphism• Persistence

9

Key Object-Oriented Ideas• Identity• Abstraction• Classification• Encapsulation• Inheritance• Polymorphism

– Objects inherit types from parent classes as well as behavior

• Persistence

10

Key Object-Oriented Ideas• Identity• Abstraction• Classification• Encapsulation• Inheritance• Polymorphism• Persistence

– Objects have lifetime. – Attributes of an object may change over its

lifetime.

11

Advantages of O-O Approach• Shifting of development effort into analysis.

– Some development effort is moved to the analysis phase.

• Emphasis on data before function. • Seamless development process.

– Models developed during analysis are used for design and implementation. The work is progressively refined rather than converting from one representation to another.

• Iterative rather than sequential. – Each iteration adds or clarifies features rather than modifies

work that has already been done.

12

OO Analysis Objective

• To develop precise, concise, understandable, and correct models of the problem context.

13

Object Modeling

• Involves systems analysis and design based on three different views of the system: – Object Models– Dynamic Models– Functional Models

14

Activities and Products of OOA

0. State the requirements

1. Build an Object Model

2. Develop a Dynamic Model

3. Construct a Functional Model

4. Verify, iterate, and refine the three models

15

1. Build an Object Model

• Identify objects and classes• Identify associations between objects• Identify attributes of objects and

associations• Organize and simplify object classes

using inheritance• Verify that access paths exist for likely

queries

16

2. Develop a Dynamic Model

• Prepare scenarios of typical interaction sequences

• Identify Events between objects and prepare an event trace

• Build a state diagram, sequence diagram, or communication diagram

• Match events between objects to verify consistency

17

3. Construct a Functional Model

• Identify Input and Output Values

• Build Use Case scenarios

• Build Data Flow Diagrams showing functional dependencies

• Describe Functions

• Identify Constraints

• Specify Optimization Criteria

18

Three Orthogonal Models

• Object model (class diagram)– specifies static structure of objects and their

relationships– specifies what objects a system contains

• Dynamic model (state diagrams)– specifies aspects of a system that change over

time (when objects change)

• Functional model (data flow diagrams)– specifies data value transformations in a system

(how objects change)

19

Object Model --- Objects

• An Object is– A real world entity– Related to the problem domain– With crisply defined boundaries– Encapsulated along with its attributes and

behaviors– Whose behavior and attributes must be

understood in order to understand the problem.

20

Examples

• Objects usually correspond to nouns in a "natural" language.

• Objects may represent physical entities (such as companies, people, lumber, I/O devices, etc.), concepts (such as "business process", "data analysis", etc.), and everything in between.

• Examples of objects include: IBM, Juan Mendoza, a 2’ 2x4, the ZIP drive, the interview protocol, and zero-crossing analysis.

21

Classes

• A class is a "template" describing a set of objects with – similar properties (attributes), – common behavior (operations), – common relationships to other objects, and – common semantics.

22

Instances

An instance of a class is an object

• created at runtime

• based on a class (template).

• Sometimes class and object are used to mean the same thing (by mistake).

• An instance is used to refer to exactly one thing.

23

Terminology

• Class: – A category– A type– A set

• Instance (of a class)– Something in the category, is of the type,

or an element of the set– Object

24

How to Recognize Objects

• Tangible things– These are the easier to find. They correspond to

physical things: airplane, vehicle, book

• Roles played by persons or organizations– Example: patient, employee, client, etc.

• Incidents– Used to represent an occurrence or event:

something which happens at a specific time. Example: flight, accident, performance, etc.

25

More objects

• Interactions– A "transaction" or "contract", and relate to two or

more other objects in the model. – Examples are: Purchase (related to buyer, seller,

and thing purchased). Marriage (related to man and woman)

• Specifications– A standard or a definition. For example: a

refrigerator model, the specification of what it means to be a certain model can be an object.

26

Attributes

Abstraction of a single characteristic possessed by all the instances of a class. – May corresponds to an adjective or possessive

phrase in a natural language. – It is any property, quality, characteristic that can

be assigned to an object.– E.g., color, size, name, . . .

27

Good Attributes

complete: includes all the information pertaining an object

factorized. Each attribute captures one separated aspect of the objects' abstraction

mutually independent. The attributes take on their values independently of one another

28

How to Recognize Attributes• Descriptive attributes.

– Provide facts intrinsic to each instance of an object.– E.g., length, width

• Naming attributes. – Provide facts about the arbitrary labels and names

carried by each instance of an object.– E.g., user-name, part-number

• Referential attributes. – Capture the facts that tie an instance of one object to

an instance of another object.– E.g., is-controlled-by, is-driven-by

29

Operations and Methods

• Behavior of objects is realized via operations.– A function or transformation that may be applied

• to objects in a class. • by objects in a class

– All objects in a class share the same operations.

• Method: the implementation of an operation. • Operations usually correspond to verbs in a

natural language (print, open, transform, mail)

30

Recognizing Operations• Manipulate data

– add, delete, format, select, access.

• Perform a calculation – The calculation is performed according to the

value of the attributes of the object student.

• Monitor the object to verify the occurrence of an event that is controlling the object. – Think about monitoring an object needs to do to

respond to an external change. Verify the time continually to activate a process at exactly 12:00 Hrs.

31

In Class

• Pairs (2 minutes): create a class list with attributes and operations:A student may take up to five courses in a semester. Each course may have as many as 30 students in each section. Each course has one section per semester. A class room can hold at most one course at a time.

32

UML Class Diagram ---Notation for Classes

Class Name

Class Name

Attributes

Operations

These may be abstract or at the source code

level

33

Attributes and Operations

Car

speed

direction

Level of detail varies with level of

abstraction: start with high abstraction

34

Attributes and Operations

Car

speed

direction

Refine withTypes

Car

speed: Integer

direction: Tuple

35

Attributes and Operations

Car

speed

direction

Refine withTypes

VisibilityDefaults

Properties

Car

speed: Integer

direction: Tuple

35

Car

+speed: Integer = 0

+direction: Tuple {readOnly}

36

Attributes and Operations

Refine withTypes

VisibilityDefaults

Properties

36

Car

+speed: Integer = 0

+direction: Tuple {readOnly}

Visibility is “+” for public, “-” for private, # for

protected,~ for package

Types correspond to

the types from an implementation

language

Default is attribute=value

Property string is {} Property string is {} with one or more of with one or more of readOnly, ordered, readOnly, ordered,

sequencesequence

37

Notation for Objects• Rectangular box with one or two compartments

objectName: Classname

field1 = value1

……

fieldn = valuen

The top compartment shows the name of the object and its class.

The bottom compartment contains a list of the fields and their values.

p1:Point

x = 10

y = 20

p2:Point

x = 20

y = 30

38

Interfaces and Abstract Classes

<<interface>>

Runnable

+run(): void

Shape

{abstract}

Class Relationships

Association

Aggregation

Composition

Generalization

Realization

Dependency

39

40

Association• General binary relationships between classes• Commonly represented as direct or indirect

references between classes

Student Course

41

Association (Cont.)• May have an optional label consisting of a name

and a direction drawn as a solid arrowhead with no tail.

• The direction arrow indicates the direction of association with respect to the name.

Student Courseenroll

42

Association (Cont.)

• An arrow may be attached to the end of path to indicate that navigation is supported in that direction

• If omitted?

Student Courseenroll

43

Association (Cont.)• May have an optional role name and an optional

multiplicity specification.• The multiplicity specifies an integer interval, e.g.,

– l..u closed (inclusive) range of integers– i singleton range– 0..* entire nonnegative integer, i.e., 0, 1, 2, …

Student Facultyadvisee advisor

10..*

44

Example

Student Coursehas enrolled

advisee

advisorFaculty

teach

1..*

6..*

0..*

11

1

45

Aggregation• Special form of association representing has-a or

part-whole relationship. • Distinguishes the whole (aggregate class) from its

parts (component class). • No relationship in the lifetime of the aggregate and

the components (can exist separately).

Aggregate Component

46

Composition• Stronger form of aggregation• Implies exclusive ownership of the component

class by the aggregate class• The lifetime of the components is entirely included

in the lifetime of the aggregate (a component can not exist without its aggregate).

Composition Component

47

Example

Department

member-of

Faculty

College

chair-of

Student

1

1 1

1

1 1

1..*

0..*1..*

1..*

University

48

Dependency• Relationship between the entities such that the

proper operation of one entity depends on the presence of the other entity, and changes in one entity would affect the other entity.

• The common form of dependency is the use relation among classes.

Class1 Class2<<use>>

49

Complex Associations• Associations may be: binary, ternary, or higher

order. • Binary associations involve two classes. This is

the most common. • Higher order associations are more complicated

to draw, implement, and think about than binary associations. Ternary associations involve 3 objects:– It is an atomic unit – The division of a ternary association into binary

associations may loose information – The associations are represented by a diamond

50

Example

Project Language

Programmer

Class diagram

p1: Project C: Language

Java: Languagep2: Project

Joe: Programmer

Instance diagram

51

Notation: Association Class

Person Company0..*

0..2

employer

Employment

period: DateRange

Employment keeps information about the association that is not part of either object. Person could have two jobs. Employment is a 1-person/1-company relation.

Association class

52

Alternate Diagram

Person Company0..*

0..2

Employer

Employment

period: DateRange0..2

11

0..*

53

Recursive Associations

Node

0..*

0..*

node4

node2

node8

node1

node5

node6node7

node3

54

In Class: Draw the Class Diagram

There are four classes: Program, Block, CompoundStatement, and SimpleStatement

<program> ::= program <name> : <block> .<block> ::= <statement>*<statement> ::= <simple statement> | <compound><compound> ::= <block>

55

Generalization and Specialization

Customer

Corporate Customer

Private Customer

Every attribute of Customer is also an attribute of its subclasses.

56

In Class: Draw the Diagram

• A figure is either a group or a polygon.

• A group contains any number of figures.