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

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


InitializeInitializeObjectObject


TerminateTerminateObjectObject


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 Contributors

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

MicrosoftObjecTimeOraclePtech OAO Technology SolutionsRational SoftwareReichSAPSofteamSterling SoftwareSunTaskonTelelogicUnisys…

CS58527/

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

CS58528/

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

CS58529/

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

CS58530/

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

CS58531/

UML Views

Static ViewClass DiagramObject Diagram

Functional ViewUse Case Diagram

Activity Diagram

Dynamic ViewSequence Diagram

Collaboration DiagramState Chart Diagram

CS58532/

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

CS58533/

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)


CS58534/

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

CS58535/

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}

CS58536/

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}

CS58537/

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)

CS58538/

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 39

Modeling Relationships With UML

Association

CS58540/

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


CS58541/

Class Diagram: Association

General Binary Relationship

Student Course

enroll

*

Faculty

Advisee

Adviser

*

1

teach

1

*


CS58542/

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

CS58543/

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..*

CS58544/

Association Elements - Roles

Association Roles– Generates code

Employee Projectparticipate

participate

participate

programmer

manager

UI Designer

CS58545/

Association Elements - Constraints

Association Constraints

Person Cardrives

Must have valid driver license

CS58546/

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..*

CS58547/

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

CS58548/

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

CS58549/

Associations

JobPerson

Manages

Company

boss

worker

employeeemployer

0..1

Jobsalary

CS585 50


Inheritance – Specialization and Generalization

CS58551/

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


CS58552/

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 55


Aggregation and Composition

CS58556/

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.


CS58557/

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”)


CS58558/

Aggregation & Composition Examples


Team Player0..1 9..9

Chess Board Square1 64

Book Chapter1 1..*

CS58559/

Composition

Player

PlayerHead PlayerArms PlayerLegsPlayerBody


CS58560/

Example

See Figure 2.7 Page 35 for Class Diagram Aggregation and Composition Example

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/

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


realization a relationship between a specification and its implementation.

CS58564/

UML Views

User model view

•Use-cases Structural model view

Behavioral model view

Implementation model view

Environment model view

CS585 65

Modeling Requirements with UML

Use-Case Diagram

User Model view or Functional View

CS58566/

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


CS58567/

Software Engineering: A Practitioner’s Approach, 6/e

Use-case diagram

Modeling Requirements with UML

CS58568/


Used to model Requirements

Describes the behavior of the system as seen by external entities – Actors

– Other Systems

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

CS58569/


Model the system from the end-user's perspective. Objectives:

– Define the functional and operational requirements of the system (product) by defining a scenario of usage. (These should be agreed upon by the users and developers.)

– Describes how the system and the users will interact.

use case model: a view of a system that emphasizes the behavior as it appears to outside users.

A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’).

CS58570/

Use Case Modeling

Use Case model has three views– The use case diagram

• High level definition of the relationship between the system and its users (actors)

• Block box view of the system

– The use case narrative

• Standard set of information that is required to guide for the development of the feature

• Textual description

– The use case scenarios

• One logical sequence of the execution of the use case.

CS58571/

Use Case Modeling

System

Use Case diagramDefined by UML

NameAssumption

Pre ConditionsDialog

Post ConditionsExceptions

Future EnhancementsOpen Issues

Use Case NarrativeUse Case Scenario

CS58572/


A use case diagram is made of:– System

– Use cases defines required feature of the system

– Actors

– Association Relationships• between use-cases and actors

• It represents the fact that Actors communicate with the use case

– Dependencies Relationships– Defines a communication relationship between 2 use cases

• Include• Extend

– Generalization Relationships• Inheritance relationship between 2 actors or 2 use cases

CS58573/

Use Case Modeling: Core Elements


use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.

actor A coherent set of roles that users of use cases play when interacting with these use cases.

system boundary

Represents the boundary between the physical system and the actors who interact with the physical system.

UseCaseNam e

ActorNam e


CS58574/


association The participation of an actor in a usecase. i.e., instance of an actor andinstances of a use case communicatewith each other.

extend A relationship from an extension usecase to a base use case, specifyinghow the behavior for the extensionuse case can be inserted into thebehavior defined for the base usecase.

generalization A taxonomic relationship between amore general use case and a morespecific use case.

Use Case Modeling: Core Relationships

<<extend>>

CS58575/


include An relationship from a base use caseto an inclusion use case, specifyinghow the behavior for the inclusion usecase is inserted into the behaviordefined for the base use case.

Use Case Modeling: Core Relationships (cont’d)

<<include>>


CS58576/

Customer

Supervisor

SalespersonPlace

Establishcredit

Check

Telephone Catalog

F ill orde rs

Shipping Clerk

status

order

Use Case Diagram


CS58577/

Use Case Diagram - Relationships

Association– Communication between actors and use cases

– Uni or Bi directional

<<include>>– When one use case seeks help form another

– Example Deposit Money use case includes the Update Account use case

– Delegate

– Dashed arrow form the using use case to the used use case


Withdraw Cash Update Account<<include>>

ActorNam e

CS58578/


<<extend>>– The extend Dependency says that one use case might

need help from another use case

– The extension point is the point where the extended use cases is tested to see weather its needed or not

– Arrow is going from the use case that is providing help to the main use case



ActorNam e Withdraw Cash with Overdraft

Protect Overdraft<<extend>>

CS58579/


Generalization– Inheritance relationship between use cases


Customer


Withdraw Cash with Overdraft

Protect Overdraft<<extend>>

CS58580/

Use Case Relationships

additional requests :

OrderProduct

SupplyArrange

«include»«include»«include»

RequestCatalog

«extend»Extension points

PaymentCustomer Data

after creation of the order

Place Order

1 * the salesperson asks forthe catalog


CS58581/

Actor Relationships

EstablishCredit

PlaceOrder

Salesperson

Supervisor

1 *

1 *


CS58582/

Use Case Description: Change Flight

Actors: traveler, client account db, airline reservation systemPreconditions:

Traveler has logged on to the system and selected ‘change flight itinerary’ option

Basic course System retrieves traveler’s account and flight itinerary from client account database System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. System asks traveler for new departure and destination information; traveler provides information. If flights are available then … System displays transaction summary.

Alternative courses If no flights are available then …


CS58583/

When to model use cases

Model user requirements with use cases.

Model test scenarios with use cases.

If you are using a use-case driven method

– start with use cases and derive your structural and behavioral models from it.

If you are not using a use-case driven method

– make sure that your use cases are consistent with your structural and behavioral models.


CS58584/

Use Case Modeling Tips

Make sure that each use case describes a significant chunk of system usage OR FEATURE that is understandable by both domain experts and programmers

When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams

Factor out common usages that are required by multiple use cases– If the usage is required use <<include>>

– If the base use case is complete and the usage may be optional, consider use <<extend>>

A use case diagram should– contain only use cases at the same level of abstraction

– include only actors who are required


CS58585/

Example: Online HR System

Online HR System

LocateEm ployees

UpdateEm ployee

Profile

Update Benefits

Access TravelSystem

Access PayRecords

Em ployee

M anager

Healthcare P lan System

{if currentM onth = O ct.}

{readO nly}

Insurance P lan System


CS58586/

Online HR System: Use Case Relationships

Update M edicalP lan

Update DentalP lan

Update Benefits______________Extension pointsbenefit options:

after required enrollm ents

UpdateInsurance P lan

Em ployee

<<include>> <<include>> <<include>>

ElectReim bursem entfor Healthcare

Elect StockPurchase

<<extend>>em ployee requestsstock purchase option

<<extend>>em ployee requestsreim bursem ent option

extensioncondition

extension pointname andlocation


CS58587/

Online HR System: Update Benefits Use Case

Actors: employee, employee account db, healthcare plan system, insurance plan systemPreconditions:

Employee has logged on to the system and selected ‘update benefits’ option

Basic course System retrieves employee account from employee account db System asks employee to select medical plan type; include Update Medical Plan. System asks employee to select dental plan type; include Update Dental Plan. …

Alternative courses If health plan is not available in the employee’s area the employee is informed and asked to select another plan...


CS585 88

Modeling Behavior with UML

Sequence Diagram

State Diagram

CS58589/

Sequence Diagram

Depicts Object Interaction in time

Used to capture Scenarios (Use cases)

Step-by-step sequence of messages exchanges among objects.

Map directly to use cases– Used to realize a use case

Example 2.11 Page 37

CS58590/

State Diagram

Each class must be associated with a statechart that describes its behavior.– Sequence diagrams show behavior of objects and how

they collaborate to achieve the goal at hand (Inter-Object).

– State Diagram show the behavior of an object (Intra-Object)

Depicts flow of control using states and transitions

CS58591/

State Diagram

off

on

Lamp OnLamp OnLamp OnLamp On

Lamp OffLamp OffLamp OffLamp Off

off on

CS58592/

State Diagram

ONONONON ONONONONONONONON ONONONON

OFFOFFOFFOFF

CS58593/

The States of a System state—a set of observable circumstances that

characterizes the behavior of a system at a given time

state transition—the movement from one state to another

event—an occurrence that causes the system to exhibit some predictable form of behavior

action—process that occurs as a consequence of making a transition

[Event-List] [Guard] / [Action]

Example 2.11 Page 37

CS58594/

Object Behavior - Object Life Cycle









Can be captured by Statecharts

stop

CS58595/

Statecharts Statechart is a behavioralbehavioral language for the specification

of real-time, event driven, and reactive systems.

– states

– events

– actions

– Transitions

FULLFULLFULLFULL

PARTIAPARTIALL

PARTIAPARTIALL

Put [noOFitems=MAX] / print(”writing”)

Event [Condition] / Action

CS58596/

top

Basic UML Statechart Diagram

ReadyReadyReadyReady

stop

/ctr := 0stop

StateStateStateState

TriggerTriggerTriggerTrigger

ActionActionActionAction

Initial Initial pseudostatepseudostate

Initial Initial pseudostatepseudostate

TransitionTransitionTransitionTransition

Final Final statestateFinal Final statestate

DoneDoneDoneDone

““top” statetop” state““top” statetop” state

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

Documents

object slide

object behavior of objects

software object

pencil object

encapsulation slide

sell slide

principals of oo modularity

specialization slide