Principals of Object Orientation - IIT-Computer Scienceoaldawud/Slides/Class7_OO_UML.pdf · – Object Oriented Software Engineering – Use Cases oriented method. 20 OO Analysis

1

2

3

Principals of Object Orientation

Chapter 20,21,22

Go To Slid 71 Statecharts

4

What is an Object?

• A thing• A Visible Thing • It has:

– Identity – Behavior– State – this includes

• static properties and dynamic values of these properties

5

What is an Object?

• An object has a state, behavior and identity.• Structure and behavior of similar objects are

defined in a common CLASS.

6

What is an Object

• Behavior of objects is achieved via its methods.

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

• Objects can communicate via messaging protocols

7

Object Behavior - Object Life Cycle

HandleRequestHandleHandle

RequestRequest

InitializeObject

InitializeInitializeObjectObject

TerminateObject

TerminateTerminateObjectObject

Wait forRequestWait forWait forWait forRequestRequestRequest

8

Principals of OO

• 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

9

Principals of OO

• 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?

10

Principals of OO

• Modularity– OO is different form Structured– 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

11

Principals of OO

• Hierarchy– Ranking of ordering of abstraction

• An object is a class

• Inheritance (is a)– The relationship between classes

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

12

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

13

Principals of OO

• Polymorphism– The same operation may behave differently on

different classes.• Example + sign

• Aggregation (part of)– “a-part-of” relationship in which objects

representation the components of something are associated with an object representing the entire assembly

14

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)

15

OO Analysis

Chapter 21

16

OO Modeling

• OO has its own Modeling Techniques• UML – Unified Modeling Language

– Grady Booch Method– James Rumbaugh Method– Ivar Jacobson Method

17

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

18

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

19

OO Modeling

• Ivar Jacobson Method

– Object Oriented Software Engineering– Use Cases oriented method

20

OO Analysis Steps

• Elicit Requirements• Identify Scenarios• Select Classes and Objects• Identify Attributes and operations for each object• Define Structures and Hierarchies for Classes• Build an Object Relationship model• Build an Object behavior model• Review the OO analysis model against Use cases

or scenarios.

21

The Unified Modeling Language

Chapter 21

22

• 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?

23

Why do we model graphically?

• Graphics reveal data.

• 1 bitmap = 1 megaword.– Anonymous visual modeler

24

• 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

25

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

• Most recent minor revision is UML 1.3, adopted in November 1999.

• UML 2.0 is under review

What is UML

26

OMG UML Evolution

<<document>>UML 1.1

<<document>>UML 1.2

<<document>>UML 1.3

<<document>>UML 1.4

<<document>>UML 1.5

1997(adopted by OMG)

1998

1999

Q4 2000(planned minor revision)

2001(planned minor revision)

Editorial revision with nosignificant technical changes.

<<document>>ISO Publicly

AvailableSpecification

[read only]

<<document>>UML 2.0

[backward compatible]

2002(planned major revision)

The expected result of OMG'sformal liaison with ISO.

27

OMG UML ContributorsAonixColorado State UniversityComputer AssociatesConcept FiveData AccessEDSEnea DataHewlett-PackardIBMI-LogixInLine SoftwareIntellicorpKabira TechnologiesKlasse ObjectenLockheed Martin

MicrosoftObjecTimeOraclePtechOAO Technology SolutionsRational SoftwareReichSAPSofteamSterling SoftwareSunTaskonTelelogicUnisys…

28

OMG UML 1.3 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

29

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’sgraphic syntax

• UML Semantics – defines UML’ssemantics

30

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

31

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

32

Language Architecture

• Metamodel architecture• Package structure

33

Metamodel Architecture

«metaclass»Attribute

«metaclass»Class

«metaclass»Operation

«instanceOf»

<<metamodel>>UML Metamodel

Analysis Model

The attribute fare ofthe PassengerTicketclass is an instance ofthe metaclassAttribute.

The operationissue of thePassengerTicketclass is aninstance of themetaclassOperation.

«instanceOf»«instanceOf»

«instanceOf»

<<use>>

<<use>>

Represents theUser Object layerof the 4-layermetamodelarchitecturepattern.

«metaclass»Class

<<metamodel>>MOF Meta-Metamodel

«metaclass»Operation

«metaclass»Attribute

PassengerTicket

+total()+issue()+surrender()+refund()

+issuedBy : Airline+issuingAgent : TravelAgent+fare : Currency+tax : Currency

45723990550: PassengerTicket

+issuedBy : Airline = AcmeAirlines+issuingAgent : TravelAgent = TerrificTravel+fare : Currency = 1050.00+tax : Currency = 57.56

«instanceOf»

From Modeling CORBA Applications with UML chapter in [Siegel 00].

34

Package Structure

<<metamodel>>UML

ModelManagement

BehavioralElements

Foundationpackage

dependency

35

UML Views

• User model view• Use-cases

• Structural model view• Behavioral model view• Implementation model view• Environment model view

36

Use Case Modeling

• Defines the functional and operational requirements of the system.

• Takes the place of the DFD in traditional analysis.• Model the system from the end-user's perspective.• Use case diagrams show different levels of

abstraction, just like DFDs.• 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.

37

What is use case modeling?

• 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’).

38

Use Case Modeling: Core Elements

Construct Description Syntax

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.

UseCaseName

ActorName

39


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

40


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

41

• Shows use cases, actor and their relationships

• Use case internals can be specified by text and/or interaction diagrams

• Kinds– use case diagram– use case description

Use Case Diagram Tour

42

Customer

Supervisor

SalespersonPlace

Establishcredit

Check

Telephone Catalog

Fill orders

Shipping Clerk

status

order

Use Case Diagram

43

Use Case Relationships

additional requests :

OrderProduct

Supply Arrange

«include»«include»«include»

RequestCatalog

«extend»Extension points

PaymentCustomer Data

after creation of the order

Place Order

1 * the salesperson asks forthe catalog

44

Actor Relationships

EstablishCredit

PlaceOrder

Salesperson

Supervisor

1 *

1 *

45

Use Case Description: Change Flight

nActors: traveler, client account db, airline reservation systemnPreconditions:

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

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

nAlternative courses• If no flights are available then …

46

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.

47

Use Case Modeling Tips

• Make sure that each use case describes a significant chunk of system usage 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 interactiondiagrams (see Lecture 2)

• 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

48

Example: Online HR System

Online HR System

LocateEmployees

UpdateEmployee

Profile

Update Benefits

Access TravelSystem

Access PayRecords

Employee

Manager

Healthcare Plan System

{if currentMonth = Oct.}

{readOnly}

Insurance Plan System

49

Online HR System: Use Case Relationships

Update MedicalPlan

Update DentalPlan

Update Benefits______________Extension pointsbenefit options:

after required enrollments

UpdateInsurance Plan

Employee

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

ElectReimbursementfor Healthcare

Elect StockPurchase

<<extend>>employee requestsstock purchase option

<<extend>>employee requestsreimbursement option

extensioncondition

extension pointname andlocation

50

Online HR System: Update Benefits Use Case

nActors: employee, employee account db, healthcare plan system, insurance plan systemnPreconditions:

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

nBasic 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.• …

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

51

UML Views

• User model view• Structural model view

– Class Diagram

• Behavioral model view• Implementation model view• Environment model view

52

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.

53


class a description of a set of objects that share the same attributes, operations, methods, relationships and semantics.

interface a named set of operations that characterize the behavior of an element.

component a physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces.

node a run-time physical object that represents a computational resource.

«interface»

Structural Modeling: Core Elements

54

Relationships in UML

• Association– To permit the exchange of messages– 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

55


• Aggregation (diamond at the owner)– 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.

56


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

57


• Generalization (Inheritance)– Is-a-kind-of relationship– 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 Animal

A cat is-a-kind-of Animal

58


• Dependency– <<bind>>– <<derive>>– <<friend>>– <<refine>>– <<extends>>– <<include>>

59


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 Relationships

60


realization a relationship between a specification and its implementation.

Structural Modeling: Core Relationships (cont’d)

61

62

• Show the static structure of the model– the entities that exist (e.g., classes, interfaces,

components, nodes)– internal structure– relationship to other entities

• Do not show– temporal information

• Kinds– static structural diagrams

• class diagram• object diagram

– implementation diagrams• component diagram• deployment diagram

Structural Diagram Tour

63

Static Structural Diagrams

• Shows a graph of classifier elements connected by static relationships.

• kinds– class diagram: classifier view– object diagram: instance view

64

Associations

Person

Manages

JobCompany

boss

worker

employeeemployer1..∗

∗

∗

0..1

Job

Account

Person

Corporation

{Xor}

salary

65

CompositionWindow

scrollbar [2]: Slidertitle: Headerbody: Panel

Window

scrollbar title body

Header Panel

2 1 1

Slider

111

66

GeneralizationShape

SplineEllipsePolygon

Shape

SplineEllipsePolygon

Shared Target Style

Separate Target Style

. . .

. . .

67

GeneralizationVehicle

WindPoweredVehicle

MotorPoweredVehicle

LandVehicle

WaterVehicle

venue

venuepowerpower

SailboatTruck

{overlapping} {overlapping}

68

Dependencies

«friend»ClassA ClassB

ClassC

«instantiate»

«call»

ClassD

operationZ()«friend»

ClassD ClassE

«refine» ClassC combinestwo logical classes

69

UML Views

• User model view• Structural model view• Behavioral model view

– Sequence Diagrams– StateCharts

• Implementation model view• Environment model view

70

Sequence Diagrams

• 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

71

72

StateCharts

• 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).

• Statecharts show the behavior of an object (Intra-Object)

• Invented by David Harel and adopted by UML as the Intra-object behavioral language.

73

Object Behavior - Object Life Cycle


RequestRequest

InitializeObject


TerminateObject



Can be captured by Statecharts

stop

74

Statecharts• Statechart is a behavioralbehavioral language for the

specification of real-time, event driven, and reactive systems.– states– events– actions– Transitions

FULLFULLFULL

PARTIALPARTIALPARTIAL

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

Event [Condition] / Action

75

Statecharts• Statecharts describe both:

– how objects communicate (collaborate) and – how they Cary out their own internal behavior

• Statecharts states :– Basic state, Or-state, And-state

• Orthogonal regions (dashed line)– Idle for modeling concurrency.– interactions between regions typically through:

• Message Broadcasting / Propagating• shared variables • awareness of other regions state changes “ the IN() Operator”.

76

Concurrency in UML

A

C E

S

T

T2

T1T3

T3

T3

B

D

77

Concurrency in UML

C E

S

T

T2

T1T2

T3

T3

B

D

A B

78

ONONON

Automata• A machine whose output behavior is not only a

direct consequence of the current input, but of some past history of its inputs

• Characterized by an internal state which represents this past experience

ONONONONONON ONONON

OFFOFFOFF

79

off

on

State Machine (Automaton) Diagram

• Graphical rendering of automata behaviorLamp OnLamp OnLamp On

Lamp OffLamp OffLamp Off

off

on

80

Outputs and Actions

• As the automaton changes state it can generate outputs:

on

off

Lamp Onprint(”on”)Lamp OnLamp Onprint(”on”)print(”on”)

Lamp Off

Lamp Lamp OffOff

off

on

Moore automaton

on

off

Lamp On

Lamp Lamp OnOn

Lamp Off

Lamp Lamp OffOff

off

on/print(”on”)print(”on”)

Mealy automaton

81

top

Basic UML Statechart Diagram

ReadyReadyReady

stop

/ctr := 0stop

StateStateState

TriggerTriggerTrigger

ActionActionAction

Initial pseudostate

Initial Initial pseudostatepseudostate

TransitionTransitionTransition

Final stateFinal Final statestate

DoneDoneDone

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

82

What Kind of Behavior?

• In general, state machines are suitable for describing event-driven, discrete behavior– inappropriate for modeling continuous behavior

timetime

thresholdthreshold

83

Object Behavior - General Model

• Simple server model:


RequestRequest

InitializeObject


TerminateObject



void:offHook ();{busy = true;obj.reqDialtone();…};

Handling depends on specific request type

Handling depends on Handling depends on specific request typespecific request type

84

Object Behavior and State Machines

• Direct mapping:

HandleHandleEventEvent



Wait forWait forEventEvent

on

off

Lamp On

Lamp Lamp OnOn

Lamp Off

Lamp Lamp OffOff

off

on/print(”on”)

stop

85

HandleRequest

HandleHandleRequestRequest

InitializeObject


TerminateObject


Wait forRequest

Wait forWait forRequestRequest

HandleRequest


InitializeObject


TerminateObject


Wait forRequest


Object and Threads•Passive objects: depend on external power (thread of execution)•Active objects: self-powered (own thread of execution)

86

Passive Objects: Dynamic Semantics

•Encapsulation does not protect the object from concurrency conflicts!•Explicit synchronization is still required

HandleRequest


InitializeObject


TerminateObject


Wait forRequest


87

anActiveObjectanActiveObject

##currentEventcurrentEvent : Event: Event

+ start ( )+ start ( )+ poll ( )+ poll ( )+ stop ( )+ stop ( )

Active Objects and State Machines

• Objects that encapsulate own thread of execution

created

ready

start/^master.ready()

poll/^master.ack()

stop/

poll/defer

ready

created

start start/^master.ready() ready

88

Active Objects: Dynamic Semantics

Run-to-completion model:•serialized event handling •eliminates internal concurrency•minimal context switching overhead

ActiveObject:

89

UML Views

• User model view• Structural model view• Behavioral model view• Implementation model view

– Component Diagram

• Environment model view– Deployment Diagram

90

The Implementation View

• Describes the structural and behavioral aspects of the implementation.

• Diagrams: Component Diagram– Component diagrams - shows the implementation

view of the system. It shows the organization and dependencies between actual components.

– This is where the detail design is done.Pseudocode may be used.

– Examples of things shown:• Call relationships are shown.• Link dependencies are shown.

91

The Environment View

• Shows the actual hardware that is required to implement the solution.

• Diagram: Deployment Diagram– Shows the environment of the system. Its

shows the configuration and how the software components are mapped to it.

92

Exam Review

93

Q1

• a): Use Prototype for the Video Store software

• b): Use Waterfall Model for the credit card software

94

Q2) Incremental Model

AnalysisAnalysis DesignDesign CodeCode TestTest




• When staffing is not available by deadline.

95

Q2) Incremental Model

• It combines characteristics of the Waterfall model and the iterative nature of the Prototyping model.

• 1st build is usually the CORE product• Each increment “Deliverable” may add a new

functionality.• This is repeated until the product is complete• Go to page 35 for Figure

96

Q3) Requirement Elicitation

• Ask the Customer what the system should do.– Objectives?– What is to be Accomplished?– How the system will satisfy the needs of the

business?– How the system will be used?

97

Q4)

• Behavioral Model– Depict Impact of events– STD

• Functional Model– How data is trasnformed– DFD

• Data Model– Define data objects, attributes and relationships– ERD

98

Q5)Three Generic team organizations

1. Democratic Decentralized (DD)– No Leader– Task Coordinators be appointed for short duration– Group made decisions– Communication is Horizontal

2. Controlled Decentralized (CD)– Defined leader and secondary leader (subtasks)– Problem solving remains a group activity– Implementation is partitioned– Communication is Horizontal

99

Three Generic team organizations

• Controlled Centralized (CC)– Top-level problem solving and team leader– Vertical Communication

100

How to Decide team structure to use?

• Things to Consider:1. How Difficult is the problem

CC DDCD

Simple Complex

101


• Things to Consider:2. Size of the Project

CC DDCD

Large Small

102


• Things to Consider:3. Time team will stay together

CC DDCD

Short Long

103


• Things to Consider:4. The degree to which a problem can be modularized

CC DDCD

High Low

104


• Things to Consider:5. Quality and Reliability of SW to be built

CC DDCD

High Low

105


• Things to Consider:6. How Firm is the Due Date

CC DDCD

Less Time More Time

106


• Things to Consider:7. Communication Required for the Project

CC DDCD

Low High

107

Q6) Project Parameters

• Five constraints that must remain in balance:– Scope– Quality– Cost– Time– Resources

108

Q6) Design Models• Data Design

– Transform the information domain (created in analysis) into Datastructures.

• Architectural Design:– Defines the relationship between major structural elements of the

software.– The design patterns that can be used to achieve the goal

• Interfaces Design - How the system interfaces:– With itself (procedure calls)– With other systems– With users (Screens)

• Components Design– Structural elements into procedural description

109

Q7(A) Cohesion

• Each module should have a central theme or purpose.– Should be able to describe a cohesive module using a

sentence with one subject and one verb

• High cohesion is good. Low cohesion is to be avoided.

110

Q7(a) Coupling

• Refers to the degree of interconnectedness between modules

• Minimize coupling to reduce the ripple effect when changes are made.

• The goal is to reduce connection paths between modules.

• High coupling limits reuse.• lowest possible coupling

111

Q7(b)Coupling Types

• Stamp coupling (low):

112

Process Maturity Levels

• Level 1: Initial– Ad hoc, fewer processes are defined.

• Level 2: Repeatable– Level 1 +– Basic PjM processes to track Cost, Schedule and

Functionality.• Level 3: Defined

– Level 2 +– Documented and standardized and integrated into an

org wide SW process for all development and maintenance activities

113

Q8)CMM and KPA

• Five point grading scheme that determines compliance with CMM which defines key activities required at each level.

114

Key Process Areas

• Each Maturity Level is associated with KPAs.• KPAs describe those SW engineering functions

that must present to satisfy a maturity level.

• Each KPA is described by identifying:– Goals, Commitments, Abilities, Activities, and

Methods for Monitoring and Verifying Implementation.

• 18 KPAs are defined across maturity model and mapped into different levels of the process maturity (Book page 25, 26).

115

Go to Design Document Template

116

Homework #2

• Q#1: 50 Points) Sketch the following OO diagrams for the class Project (Feature Tracking SW):– Use Cases as discussed in class (Complete) – Class Diagram showing Estimates, Features, Managers

as objects – Sequence diagrams for at least 3 use cases from (a)– Describe the behavior of the Feature Class using

Statechart.

117

Homework #2

• Q#2: 50 Points)

– (a) Explain the object life cycle as shown in the figure below (25 Points).

– (b) How does the object life cycle related or can be captured by a statechart? (25 Points)

118

Object Life Cycle

HandleRequest


InitializeObject


TerminateObject


Wait forRequest

Wait forWait forWait forRequestRequestRequest

Documents

Principals of Object Orientation - IIT-Computer Scienceoaldawud/Slides/Class7_OO_UML.pdf · – Object Oriented Software Engineering – Use Cases oriented method. 20 OO Analysis