CS585 1/ Principals of Object Orientation OO Analysis Modeling with UML –UML Views User model view Structural view Behavioral view Implementation view.

CS5851/

Principals of Object Orientation OO Analysis Modeling with UML

– UML Views• User model view

• Structural view

• Behavioral view

• Implementation view

• Environment view

Functional View

Static View

Dynamic View

CS5852/

Principals of Object Orientation

CS5853/

What is an Object?

A thing A Visible Thing It has:

– Identity

– Behavior • What the object do and what can be done to it

– State – this includes • static properties and dynamic values of these properties

Structure and behavior of similar objects are defined in a common CLASS.

CS5854/

What is an Object

Behavior of objects is achieved via its– Operations and

– Methods.

The state of an object is realized thought the contents of its data.

Objects can communicate via messaging protocols

CS5855/

Object Behavior - Object Life Cycle

HandleHandleRequestRequest

HandleHandleRequestRequest

InitializeInitializeObjectObject

InitializeInitializeObjectObject

TerminateTerminateObjectObject

TerminateTerminateObjectObject

Wait forWait forRequestRequest

Wait forWait forRequestRequest

CS5856/

Principals of OO - Abstraction

Abstraction– Denotes the essential characteristics of an object that

distinguishes it from all kinds of objects.

• What does the object do without any implication on how does it do it

– A software object is an abstraction

• A representation of something in the real word like a student, a book, …

CS5857/

Principals of OO - Encapsulation

Encapsulation– The process of Compartmentalizing the elements of

an object that constitute its structure and behavior • Data hiding

• Localize design decisions

– What are the encapsulated elements?• Information that describes the object (the things an

object know about itself)– No of pages, cover type, ISBN, and other Book

information– State, the object’s current condition (or state)

• Behavior– What the object can do (register, drop etc.)– What can be done to it (a pencil object can Write!!)

Encapsulation

CS5858/

Principals of OO - Encapsulation

Encapsulation– What you need to know to use the object

• The interface

– What you need to know in order to make the object work properly

• Mechanism to respond to the interface, THE IMPLEMENATION FOR EACH INTERFACE

Example– Driving a car!

• You need to know the ignition, steering, brake, and gas pedal

• No need to know about the mechanics of the engine, spark plugs, etc.

CS5859/

Principals of OO

Modularity– OO is different from Structured Paradigm

– In Structured Paradigm module and function are the same

– In OO Paradigm Classes and objects are the lowest form of Modularity.

• A module could have multiple classes

CS58510/

Principals of OO

Hierarchy– Ranking of ordering of abstraction

Inheritance (is a)– The relationship between classes

• One class share the structure and behavior of one or more classes

• Generalization and Specialization

CS58511/

Inheritance

Class: Furniture

Cost

Dimensions

Weight

Color

Object: Chair

Chair inherits all attributes and operations of class Furniture

Cost

Dimensions

Weight

Color

Buy

SellBuy

Sell

CS58512/

Principals of OO

Polymorphism– The same operation may behave differently on different

classes.

• Example + sign

– When an object is substituted with one of its children at run time

• (The is-a relationship)

– Overloading of operations

• Same operation with different signatures

CS58513/

Principals of OO

Identifying Classes– External Entities (devices, people)

– Things (reports, forms, Features, Estimates)

– Occurrences or Events (Moving)

– Roles (Mangers, Engineers, Group, Team)

– Places (Loading dock, Shipping Floor)

– Structures(Computers)

CS58514/

OO Analysis

CS58515/

OO Modeling

OO has its own Modeling Techniques

UML – Unified Modeling Language– Grady Booch Method

– James Rumbaugh Method

– Ivar Jacobson Method

CS58516/

OO Modeling

Grady Booch Method– Micro Development Process

• Defines a set of analysis tasks that are re-applied in the Macro process

• Identifies classes, objects, and relationships

– Macro development Process

• Refine

CS58517/

OO Modeling

James Rumbaugh Method– Object Modeling Technique (OMT) for

• Analysis, creates:– The object model – objects, classes, and relationships

– The dynamic model – objects and system behavior

– The Functional Model – DFD like

• System level design

• Object level design

CS58518/

OO Modeling

Ivar Jacobson Method

– Object Oriented Software Engineering

– Use Cases Oriented method

CS58519/

The Unified Modeling Language

CS58520/

Provide structure for problem solving Experiment to explore multiple solutions Furnish abstractions to manage complexity Reduce time-to-market for business problem

solutions Decrease development costs Manage the risk of mistakes

Why do we model?

CS58521/

Tijuana “shantytown”: http://www.macalester.edu/~jschatz/residential.html

The Challenge

CS58522/

Fallingwater: http://www.adelaide.net.au/~jpolias/FLW/Images/FallingWater.jpeg

The Vision

CS58523/

Why do we model graphically?

Graphics reveal data.

1 bitmap = 1 megaword.– Anonymous visual modeler

CS58524/

The UML is a graphical language for– Specifying, can be used to communicate "what" is

required of a system, and "how" a system may be realized.

– Visualizing, it can be used to visually depict a system before it is realized

– Constructing, can be used to guide the realization of a system similar to a "blueprint".

– Documenting, can be used for capturing knowledge about a system throughout its life-cycle

the artifacts of software systems

What is UML

CS58525/

Added to the list of OMG adopted technologies in November 1997 as UML 1.1

Most recent minor revision is UML 2.0,

MDA

What is UML

CS58526/

OMG UML Evolution

<<docum ent>>UM L 1.1





1997(adopted by OM G)

1998

1999

Q4 2000(planned m inor revision)

2001(planned m inor revision)

Editorial revision with nosignificant technical changes.

<<docum ent>>ISO Publicly

AvailableSpecification

[read only]


[backward com patible]

2002(planned m ajor revision)

The expected result of OMG'sform al liaison with ISO.

CS58527/

OMG UML Contributors

AonixColorado State UniversityComputer AssociatesConcept FiveData AccessEDSEnea DataHewlett-Packard IBMI-LogixInLine SoftwareIntellicorpKabira TechnologiesKlasse ObjectenLockheed Martin

MicrosoftObjecTimeOraclePtech OAO Technology SolutionsRational SoftwareReichSAPSofteamSterling SoftwareSunTaskonTelelogicUnisys…

CS58528/

OMG UML Specification

UML Summary UML Semantics UML Notation Guide UML Standard Profiles

– Software Development Processes

– Business Modeling UML CORBAfacility Interface Definition UML XML Metadata Interchange DTD Object Constraint Language

CS58529/

the Language

language = syntax + semantics– syntax = how the symbols should look and how are they

combined (i.e words in natural language)

– semantics = rules that tells us the meanings of each symbol.

UML Notation Guide – defines UML’s graphic syntax

UML Semantics – defines UML’s semantics

CS58530/

UML Views User model view

– The system from the user’s perspective.

• Use-cases

Structural model view– Static structure

• Classes, objects, and relationships

Behavioral model view– Dynamic aspect of the system including collaborations between

elements identified in the user-model and the structural model views.

Implementation model view– Describes the structural and behavioral aspects of the

implementation.

Environment model view– Shows the actual hardware that is required to implement the solution.

UML Analysis Modeling

UML Design Modeling

CS58531/

Inter object behavior

Diagram UML decomposition dimension

Use case diagram Functional

Class diagram Static

Collaboration diagram Dynamic

Sequence diagram Dynamic

Intra object behavior

Statecharts Dynamic

UML Diagrams

CS58532/

UML Views

Static ViewClass DiagramObject Diagram

Functional ViewUse Case Diagram

Activity Diagram

Dynamic ViewSequence Diagram

Collaboration DiagramState Chart Diagram

CS58533/

UML Views

Structural model view– Class Diagram

User model view

Behavioral model view

Implementation model view

Environment model view

Structural model view or Static View

CS58534/

What is structural modeling?

Structural model: a view of a system that emphasizes the structure of the objects, including their classes, relationships, attributes and operations.

Used to model the static structure and relationships among the classes of an OO software system

A class diagram is made of:– Nodes (Classes and Interfaces)

– Links (Relationships)


CS58535/

UML Class Diagram Source for code generation It represents classes, their members, and relationships. It

includes:– Attributes

– Operations

– Stereotypes

– Associations

– Inheritance

– Properties

It shows static view Blueprint for building Does not show behavior

CS58536/

UML Class Diagram - Modeling Attributes An Attribute describes a piece of information

– Show type of attribute• Primitive (Language supplied data type, int, boolean)• User defined class (String)

– Show visibility

• - private

•+ public

•# protected

•~ package

– Show default value– Show Constraints – Integrity rules– Show static values by underlining the attribute– Example

Visibility / attribute Name: Data Type = default value {constraint}

CS58537/

UML Class Diagram - Modeling Operations

An operation denotes behavior– Things an object can do and

– Things can be done to an object

– Show Name

– Show arguments – use attribute notation

– Show return type – use attribute notation

– Visibility (-,+,#,~)

– Example

+ totalOrderAmount (order: Order): Dollar {total >0}

CS58538/

Class Representation in UML

class Point {

int x,y;

public void move (int dx, int dy) {

x += dx;

y += dy;

}

}


Point

~x:int~y:int

+move(dx:int, dy:int)

CS58539/

Object Representation in UML

Point p1 = new Point ();

p1.x = 0; p2.y=0;

p1.move (20,15);

P1:Point

x =0y=0

P1:Point

x =20y=15

After sending the move message to p1

object


CS585 40

Modeling Relationships With UML

Association

CS58541/

Relationships in UML

Association– To permit the exchange of messages

• Associations are the mean for objects to communicate

– Default is bi-directional (support messages in either way)

– When an object uses the services of another object but does not own it.

– Client server


CS58542/

Class Diagram: Association

General Binary Relationship

Student Course

enroll

*

Faculty

Advisee

Adviser

*

1

teach

1

*


CS58543/

Association Elements - Association Name

Association Name– Expresses the purpose of the association (verb) that

describes how objects of one type (class) relate to objects of another type (class)

• A Person owns a Car

• A Person drives a Car

• A Person rents a Car

– You can show the direction to read the association name

Person Carowns

Person Carrents

Person Cardrives

CS58544/

Association Elements - Multiplicity

Association Multiplicity– Defines rules on how objects in each class are related

– A value can be assigned to each participant in the association

– Min..Max

– * denotes zero or more

– 1..* no upper limit

Person Cardrives

1..1 0..*

CS58545/

Association Elements - Roles

Association Roles– Generates code

Employee Projectparticipate

participate

participate

programmer

manager

UI Designer

CS58546/

Association Elements - Constraints

Association Constraints

Person Cardrives

Must have valid driver license

CS58547/

Association Elements - Class

Association Class– Encapsulate the association in a class to include

information about the association

Customer Productorder

Order-orderQuantity: int = 0

-orderDate: Date = today

-orderTerms: Terms=NULL

0..* 0..*

CS58548/

Association Elements - Reflexive

Reflexive Association – Objects in the same class can be associated and related

to one another

– Common for modeling Hierarchies

Employee0..*

0..*supervisor

subordinates

CS58549/

Association Elements - Qualified

Qualified Association – Indexes

– The customer uses the order number to lookup the order

– Used to reduce multiplicity just like indexes are used to reduce time to search a table

Customerplaces

Order-orderQuantity: int = 0

-orderDate: Date = today

-orderTerms: Terms=NULL

1..1 1..1orderNo: int

CS58550/

Associations

JobPerson

Manages

Company

boss

worker

employeeemployer

0..1

Jobsalary

CS585 51


Inheritance – Specialization and Generalization

CS58552/

Modeling Relationships With UML - Inheritance Inheritance

– Not a form of Association (no multiplicity)

– Extension Relationship (specialization and generalization)

– Extension between two interfaces

– Implementation (when a class implements an interface)

– UML uses hollow triangle (pointing toward the super class

Inheritance– specialization and Generalization

– “is-a”

– One class is a specialization of another

– The child has all the characteristics of a parent and it might specialize them

– Example: A mammal is-a-kind-of AnimalA cat is-a-kind-of Animal


CS58553/

Class Diagram: Inheritance

Student

Undergrad Graduate

PhDMaster

Extension Relationship

Interface

ImplementationImplementation of an

Interface

“is-a” Relationship


Generalization “is-a” or “type-of”

Vehicle –Car

–Motorcycle

–Truck

Vehicle

MotorcycleCar Truck

Representation of inheritance

A car “is-a” Vehiclea Truck “is-a” Vehicle

Specialization occurs when sub-classes add additional functionality or override existing ones


Generalization - Inheritance Credit Card Class is a subclass of the

Bank Card Class

Credit Card Class is a specialization of the Bank Card Class

Credit Card Class is a Bank Card Class

Credit Card Class inherits from the Bank Card Class

Credit Card Class is derived from the Bank Card Class

Bank Card

Debit CardCredit Card Loan Card

Credit card is a special kind of card

Specialization occurs when sub-classes add additional functionality or override existing onesInheritance is an implementation of the generalization relationship

Bank Card Class is a supper class of the Credit Card Class

Bank Card Class is a Generalization of the Credit Card Class

Bank Card Class is base/ parent class of the Credit Card Class


CS585 56


Aggregation and Composition

CS58557/

Relationships in UML- Aggregation & Composition

Aggregation (diamond at the owner)

– Is a type of Association used to indicate that objects are not independent , rather they (the parts) are assembled or configured together to create another object (the whole)

• A number of different parts are assembled to create a Car object

– One object contains another.

– The aggregation class is referred to as the owner, or whole. The aggregated class is the owned, or part.

– Example: a window has a drawing area, the drawing area can't stand on its own.


CS58558/

Relationships in UML- Aggregation & Composition

Composition (filled in diamond at the owner)– Strong aggregation

– the owner is responsible for creating and destroying of the part object.

– Composite object that creates it’s components

– Example: an active object with multiple threads of control.

– Is used for aggregation where the life span of the part is dependent on the whole. The aggregate has control over the creation and destruction of the parts

Aggregation & Composition Modeling– Small diamond at the end of association denotes Aggregation

– If diamond is filled it’s a Composition (“Consist of”)


CS58559/

Aggregation & Composition Examples


Team Player0..1 9..9

Chess Board Square1 64

Book Chapter1 1..*

CS58560/

Composition

Player

PlayerHead PlayerArms PlayerLegsPlayerBody


CS585 61


Dependency

CS58562/

Class Diagram: Dependency

One operation of a class1 depends on another operation of class2

–Use relationship

–Class C1 depends on class C2 if C1 uses C2.

In many instances, a client-server relationship exists between two classes.

–In such cases, a client-class depends on the server-class in some way and a dependency relationship is established


CS58563/

Relationships in UML

Dependency– <<bind>>

– <<derive>>

– <<friend>>

– <<refine>>

– <<extends>>

– <<include>>


CS58564/

Construct Description Syntax

association a relationship between two or more classifiers that involves connections among their instances.

aggregation A special form of association that specifies a whole-part relationship between the aggregate (whole) and the component part.

generalization a taxonomic relationship between a more general and a more specific element.

dependency a relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element).

Structural Modeling: Core RelationshipsStructural model view or Static View

CS58565/

Construct Description Syntax

realization a relationship between a specification and its implementation.

Structural Modeling: Core Relationships (cont’d)


CS58566/

UML Views

User model view

•Use-cases Structural model view

Behavioral model view

Implementation model view

Environment model view

CS585 67

Modeling Requirements with UML

Use-Case Diagram

User Model view or Functional View

CS58568/

Modeling Requirements With USE-CASES

Used to model Requirements

Describes the behavior of the system as seen by external entities called actors

Each actor represent a role played by a set of external entities that interact with the system

Describes “what”

Each use case represent a scenario

User Model view or Functional View

CS585 1/ Principals of Object Orientation OO Analysis Modeling with UML –UML Views User model view Structural view Behavioral view Implementation view.

Documents

object slide

oo analysis slide

encapsulation slide

object behavior of objects

software object

oo modeling oo

object model objects

pencil object