11 topic 9 ooa

Lecture 14 & 15 1CS540 Software Design

Object-Oriented Paradigm

• Object-oriented paradigm– Reaction to perceived shortcomings in structured

paradigm– Problem of larger products– Data and action treated as equal partners


Object-Oriented Analysis (OOA)• Semi-formal specification technique • Multiplicity of different methods • All essentially equivalent• Nowadays, we represent OOA using UML (unified

modeling language)


The Three Steps of OOA• 1. Use-case modeling

– Determine how the various results are computed by the product (without regard to sequencing)

– Largely action oriented• 2. Class modeling (“object modeling”)

– Determine the classes and their attributes– Purely data-oriented

• 3. Dynamic modeling – Determine the actions performed by or to each class– Purely action-oriented

• Iterative process

Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall

The Object-Oriented Modeling Approach

• Benefits1. The ability to tackle more challenging problem

domains2. Improved communication among users, analysts,

designers, and programmers3. Reusability of analysis, design, and programming

results4. Increased consistency among the models developed

during object-oriented analysis, design, and programming

A.4A.4


The Object-Oriented Modeling Approach (continued)

• Object-Oriented Systems Development Life Cycle– Process of progressively developing

representation of a system component (or object) through the phases of analysis, design, and implementation

– The model is abstract in the early stages– As the model evolves, it becomes more and more

detailed

A.5A.5


The Object-Oriented Systems Development Life Cycle

• Analysis Phase– Model of the real-world application is developed showing

its important properties– Model specifies the functional behavior of the system

independent of implementation details• Design Phase

– Analysis model is refined and adapted to the environment• Implementation Phase

– Design is implemented using a programming language or database management system

A.6A.6


The Object-Oriented Systems Development Life Cycle (continued)

• Unified Modeling Language (UML)– A notation that allows the modeler to specify, visualize and

construct the artifacts of software systems, as well as business models

– Techniques and notations• Use cases• Class diagrams• State diagrams• Sequence diagrams

A.7A.7


Use-Case Modeling• Applied to analyze functional requirements of the

system• Performed during the analysis phase to help

developers understand functional requirements of the system without regard for implementation details

• Use Case– A complete sequence of related actions initiated by an

actor• Actor

– An external entity that interacts with the system

A.8A.8


Use-Case Modeling• Use cases represent complete functionality

of the system• Use cases may participate in relationships

with other use cases• Use cases may also use other use cases

A.9A.9


Elevator Problem: OOA• 1. Use-Case Modeling

– Use case: Generic description of overall functionality

• Get comprehensive insight into behavior of product


Normal Scenario


Exception Scenario


Use Case

• Use Case Name• Actors• Pre-Conditions• Normal Flow• Post-Conditions• Exceptions or Alternate Flows


Class Modeling

• Extract classes and their attributes• Represent them using an entity-relationship

diagram• Deduce the classes from use cases and their

scenarios• Often there are many scenarios

– Possible danger: too many candidate classes


Two Approaches to Class Modeling

• Noun extraction– Always works

• CRC classes– Need to have domain expertise


Noun Extraction

• Stage 1. Concise Problem Definition– Define product in single sentence

• Buttons in elevators and on the floors control the motion of n elevators in a building with m floors.


Noun Extraction (contd)

• Stage 2. Informal Strategy– Incorporate constraints, express result in a

single paragraph • Buttons in elevators and on the floors control

movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator to stop at a specific floor; illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.


Noun Extraction (contd)• Stage 3. Formalize the Strategy

– Identify nouns in informal strategy. Use nouns as candidate classes

• Nouns– button, elevator, floor, movement, building, illumination,

door – floor, building, door are outside problem boundary —

exclude– movement and illumination are abstract nouns — exclude

(may become attributes)• Candidate classes: Elevator and Button • Subclasses: Elevator Button and Floor Button


First Iteration of Class Diagram

• Problem– Buttons do not communicate directly with elevators– We need an additional class: Elevator Controller


Second Iteration of Class Diagram

• All relationships are now 1-to-n – Makes design and

implementation easier


CRC Cards• Class Responsibility Collaboration (CRC)• Used since 1989 for OOA• For each class, fill in card showing

– Name of class– Functionality (responsibility)– List of classes it invokes (collaboration)– Now automated (CASE tool component)

• Strength– When acted out by team members, powerful tool for

highlighting missing or incorrect items• Weakness

– Domain expertise is needed


3. Dynamic Modeling

• Produce UML state diagram

• State, event, predicate distributed over state diagram

• UML “guards” are in brackets


Testing during the OOA Phase• CRC cards are an excellent testing technique


CRC Cards• Consider responsibility

– 1. Turn on elevator button

• Totally unacceptable for object-oriented paradigm

• Responsibility-driven design ignored• Information hiding ignored• Responsibility

1. Turn on elevator button

should be1. Send message to Elevator Button to turn itself on


CRC Cards (contd)

• A class has been overlooked– Elevator doors have a state that changes during

execution (class characteristic)– Add class Elevator Doors– Safety considerations

• Reconsider class model• Then reconsider dynamic model, use-case

model


Second Iteration of CRC Card


Third Iteration of Class Diagram


Second Iteration of Normal Scenario


Elevator Problem: OOA (contd)

• All three models are now fine• We should rather say:

– All three models are fine for now• We may need to return to the object-

oriented analysis phase during the object-oriented design phase


Why Is All This Iteration Needed?• Perhaps the method is not yet mature?

– Waterfall model (explicit feedback loops)– Rapid prototyping model (aim: to reduce iteration)– Incremental model, and– Spiral model

• Latter two explicitly reflect iterative approach• Iteration is an intrinsic property of all software

production– Especially for medium- and large-scale products– Expect iteration in the object-oriented paradigm

10.32Figure 10.5 An example of a state diagram

10.33

Use case diagramsA use-case diagram gives the user’s view of a system: it shows how users communicate with the system. A use-case diagram uses four components: system, use cases, actors and relationships. A system, shown by a rectangle, performs a function.

Figure 10.6 An example of use case diagram

10.34

Class diagramsThe next step in analysis is to create a class diagram for the system. For example, we can create a class diagram for our old-style elevator. To do so, we need to think about the entities involved in the system.

Figure 10.7 An example of a class diagram

10.35

State chartAfter the class diagram is finalized, a state chart can be prepared for each class in the class diagram. A state chart in object-oriented analysis plays the same role as the state diagram in procedure-oriented analysis.


Object Modeling:Class Diagrams

• Object– An entity that has a well-defined role in the application domain, and

has state, behavior, and identity• State

– A condition that encompasses an object’s properties and the values those properties have

• Behavior– A manner that represents how an object acts and reacts

• Object Class– A set of objects that share a common structure and a common

behavior

A.36A.36


Object Modeling:Class Diagrams (continued)

• Class Diagram– Class is represented as a rectangle with three

compartments– Objects can participate in relationships with

objects of the same class

A.37A.37


Object Modeling:Object Diagrams

• Object Diagram– A graph of instances that are compatible with a given class diagram;

also called an instance diagram– Object is represented as a rectangle with two compartments

• Operation– A function or service that is provided by all the instances of a class

• Encapsulation– The technique of hiding the internal implementation details of an

object from its external view

A.38A.38


A.39A.39


Representing Associations• Association

– A relationship between object classes– Degree may be unary, binary, ternary or higher– Depicted as a solid line between participating classes

• Association Role– The end of an association where it connects to a class– Each role has multiplicity, which indicates how many

objects participate in a given association relationship

A.40A.40


A.41A.41


Representing Generalization

• Generalization– Abstraction of common features among multiple classes,

as well as their relationships, into a more general class

• Subclass– A class that has been generalized

• Superclass– A class that is composed of several generalized subclasses

A.42A.42


Representing Generalization (continued)

• Discriminator– Shows which property of an object class is being

abstracted by a generalization relationship• Inheritance

– A property that a subclass inherits the features from its superclass

• Abstract Class– A class that has no direct instances but whose descendents

may have direct instances• Concrete Class

– A class that can have direct instances

A.43A.43


A.44A.44


Representing Aggregation

• Aggregation– A part-of relationship between a component

object and an aggregate object– Example: Personal computer

• Composed of CPU, Monitor, Keyboard, etc.

A.45A.45


Dynamic Modeling:State Diagrams

• State– A condition during the life of an object during which it satisfies some

conditions, performs some actions or waits for some events– Shown as a rectangle with rounded corners

• State Transition– The changes in the attributes of an object or in the links an object has

with other objects– Shown as a solid arrow– Diagrammed with a guard condition and action

• Event– Something that takes place at a certain point in time

A.46A.46


A.47A.47


Dynamic Modeling:Sequence Diagrams

• Sequence Diagram– A depiction of the interaction among objects during

certain periods of time

• Activation– The time period during which an object performs an

operation

• Messages– Means by which objects communicate with each other

A.48A.48


Dynamic Modeling:Sequence Diagrams (continued)

• Synchronous Message– A type of message in which the caller has to wait

for the receiving object to finish executing the called operation before it can resume execution itself

• Simple Message– A message that transfers control from the sender

to the recipient without describing the details of the communication

A.49A.49


A.50A.50


Moving to Design

• Start with existing set of analysis model• Progressively add technical details• Design model must be more detailed than

analysis model• Component Diagram

– A diagram that shows the software components or modules and their dependencies

• Deployment Diagram– A diagram that shows how the software components,

processes and objects are deployed into the physical architecture of the system

A.51A.51


A.52A.52


Summary

• Object-Oriented Modeling Approach– Benefits– Unified Modeling Language

• Use cases• Class diagrams• State diagrams• Sequence diagrams

• Use Case Modeling

A.53A.53

EXAMPLE 2

55

USE CASE:

How do we find the use cases?

• What functions will the actor want from the system?• Does the system store information? What actors will create, read, update.

Or delete that information?• Does the system need to notify an actor about changes in its internal

state?

56

USE CASE:

• Generic format for documenting the use case:

- Pre condition: If any– Use case : Name of the case.– Actors : List of actors(external agents), indicating who

initiates the use case.– Purpose : Intention of the use case.– Overview : Description.– Type : primary / secondary.– Post condition: If any

• Typical Course of Events:

ACTOR ACTION : Numbered actions of the actor.

SYSTEM RESPONSE : Numbered description of system responses.

57

USE CASE:

USE CASE documentation example:• The following use case describes the process of opening a new account in

the bank. Use case :Open new account

Actors :Customer, Cashier, Manager

Purpose :Like to have new saving account.

Description :A customer arrives in the bank to open the new

account. Customer requests for the new account

form, fill the same and submits, along with the

minimal deposit. At the end of complete successful

process customer receives the passbook.

Type :Primary use case.

58

Grouping USE CASES:

• Those use case functionality which are directly dependent on the system environment are placed in interface objects

• Those functionality dealing with storage and handling of information are placed in entity objects

• Functionality's specific to one or few use cases and not naturally placed in any of the other objects are placed in control objects

By performing this division we obtain a structure which helps us to understand the system from logical view

59

OOAD --- USE CASE driven

Capture,clarify& validate use cases

Analysis Design &Implementation

Implement use cases

Use cases make up the glue

Test

Verify that use cases are satisfied

60

SYSTEM BOUNDARY:

What is System Boundary?

• It is shown as a rectangle. • It helps to identify what is external verses internal, and what the

responsibilities of the system are. • The external environment is represented only by actors.

61

RELATIONSHIP:

What is Relationship?

• Relationship between use case and actor. Communicates

• Relationship between two use cases Extends Uses

• Notation used to show the relationships:

<< >>

62

RELATIONSHIP:

• Relationship between use case and actor is often referred as “communicates” .

• Relationship between two use cases is refereed as either uses or extends.

USES: • - Multiple use cases share a piece of same functionality.• - This functionality is placed in a separate use case rather than

documenting in every use case that needs it.

63

RELATIONSHIP:

Contd...• A uses relationship shows behavior that is common to one or

more use cases.

EXTENDS:• It is used to show optional behavior, which is required only

under certain condition.

64

USE CASE diagram:

Use case diagram for the shown functionality.

Balance status report

Withdraw cash

Validation

uses

CustomerClerk

Manager

extends

ATM

65

Objective

• To understand and capture the detailed specification of a system to be developed, from user perspective.

66

Beginning Analysis and Design

• Completion of first version of use case diagram initiates the processes of analysis and design.

• UML provides the framework to carry out the process of analysis and design in form of set of diagrams.

• Every diagram and notation used in the diagram carries the semantics.• First step towards analysis and design is to specify the flow of events.

67

Flow of Events:

• A flow of events document is created for each use case.• Details about what the system must provide to the actor when the use is

executed.• Typical contents

– How the use case starts and ends– Normal flow of events– Alternate flow of events– Exceptional flow of events

• Typical Course of Events has:

Actor Action(AA)

System Response(SR)

68

Normal Flow of Events:

For withdrawal of cash:• 1.(SR) The ATM asks the user to insert a card.• 2.(AA) The user inserts a cash card.• 3.(SR) The ATM accepts the card and reads its serial number.• 4.(SR) The ATM requests the password.• 5.(AA) The user enters 1234.• 6.(SR) The ATM verifies the serial number and password with the

bank and gets the notification accordingly.• 7.(SA)The ATM asks the user to select the kind of transaction.• 8.(AA)User selects the withdrawal.

69


Contd...• 9.(SR)The ATM asks for the amount of cash; user enters Rs. 2500/-• 10.(SR)The ATM verifies that the amount of cash is within predefined

policy limits and asks the bank, to process the transaction which eventually confirms success and returns the new account balance.

• 11.(SR) The ATM dispenses cash and asks the user to take it.• 12.(AA) The user takes the cash.• 13.(SR) The ATM asks whether the user wants to continue.• 14.(AA) The user indicates no.

70


Contd...• 15.(SR) The ATM prints a receipt, ejects the card and asks the user to take

them• 16.(AA) The user takes the receipt and the card.• 17.(SR) The ATM asks a user to insert a card.

71

Alternative Flow of Events:

For withdrawal of cash use case:• 9. The ATM asks for the amount of cash; the user has change of mind and

hits the “cancel”.

72

Exceptional Flow of Events:

For withdrawal of cash use case:• 3 Suspicious pattern of usage on the card.• 10 The machine is out of cash.• 11 Money gets stuck in the machine.

73

Why flow of events?

• It helps in understanding the functionality of a system to be developed.• Flow of events helps in finding objects of the system to be developed.• Happens to be most important and very first step towards analysis and

design.

74

What is Scenario?

• The functionality of the use case is captured in flow of the

events.• A scenarios is one path through the flow of events for the use

case.• Scenarios are developed to help identify objects, classes and

object interactions for that use case.

75

USE CASE Realizations:

• The use case diagram presents an outside view of the system• Interaction diagrams describe how use cases are realized as interactions

among societies of objects.• Two types of interaction diagrams

– Sequence diagrams– Collaboration diagrams

76

What is Interaction diagram?

• Interaction diagrams are models that describe how groups of objects collaborate in some behavior

• There are 2 kinds of interaction diagrams • Sequence diagram• Collaboration diagram

• Sequence diagrams are a temporal representation of objects and their interactions

• Collaboration diagrams are spatial representation of objects, links and interrelations

77

What is sequence diagram?

• Typically these diagrams capture behaviors of the single scenario.• Shows object interaction arranged in time sequence.• They show sequence of messages among the objects.• It has two dimensions, vertical represents time & horizontal • represents objects.• Components of sequence diagram:

-objects

-object lifeline

-Message

-pre/post conditions.

78

OBJECT & OBJECT LIFE LINE:

•Object are represented by rectangles and name of the objects are underlined.•Object life line are denoted as dashed lines. They are used to model the existence of objects over time.

Name:Class

79

MESSAGES:

• They are used to model the content of communication between objects. They are used to convey information between objects and enable objects to request services of other objects.

• The message instance has a sender, receiver, and possibly other information according to the characteristics of the request.

• Messages are denoted as labeled horizontal arrows between life lines.

• The sender will send the message and receiver will receive the message.

80

MESSAGES:

Contd…• May have square brackets containing a guard conditions. This is a Boolean

condition that must be satisfied to enable the message to be sent.• May have have an asterisk followed by square brackets containing an

iteration specification. This specifies the number of times the message is sent.

• May have return list consisting of a comma -separated list of names that designate the values of returned by the operation.

• Must have a name or identifier string that represents the message.• May have parentheses containing an argument list consisting of a comma

separated list of actual parameters passed to a method.

81

:Customer :ATM :BankRequest password

Verify accountEnter the password

Account o.k.Request option

Enter option

Request amount

Enter the amountUpdate transactionTransaction commit

Insert card

Dispense cashRequest take cash

Take cashRequest continuation

TerminatePrint receipt ,eject card

Request take cardTake card

Display main screen and prompt for the card.

:TransactionCreate Transaction

Transaction complete

Sequence diagram [for withdrawal of cash, normal flow]

82

What is Collaboration diagram?

• Collaboration diagrams illustrate the interaction between the objects, using static spatial structure.

• Unlike sequence diagram the time is not explicitly represented in these diagrams

• In collaboration diagram the sequence of messages is indicated by numbering the messages. The UML uses the decimal numbering scheme.

• In these diagrams, an actor can be displayed in order to represent the triggering of interaction by an element external to the system.

• This helps in representing the interaction, without going into the details of user interface.

83

Components of collaboration diagram:

• Named objects• Links: Links are represented by a continuous line between objects, and

indicates the exchange of messages.• Messages has following attributes:

• Synchronization --thread name, step within thread.• Sequence number• Message labels : The name of the message often corresponds to an operation

defined in the class of the object that is the destination of the message. Message names may have the arguments and return values.

• *[iteration].• It uses decimal notation.• Message direction.

84

Semantics of components:

• Object names identify which objects are participating and the links show which objects collaborate

• A link between two objects must exist for one object to send message to another and vice a versa.

• Messages in the collaboration diagram get transformed to more detailed signature.

• They use the decimal notation system for numbering the messages.• The direction of the message defines the sender and receiver of the

message

85

The elements of message:

• Predecessor• Role names• Message qualifiers

– Iteration expression– Parameters– Return values– Guard– Message stereotypes

• Concurrent thread sequencing• Thread dependencies• Message expression

[Pre] A1:*(expression):doIt(p,r):return value

86

The examples of message:

4:Display(x,y) Simplemessage

3.3.1:Display(x,y) Nestedmessage

4.2:subtract[Today,Birthday]:age Nestedmessage withreturn value

[Age >=18] 6.2:Vote() Conditionalmessage

4.a,b.6/c.1:Turnon(Lamp) Synchro. withother flow ofexecution

1*:wash() Iteration

3.a,3.b/4*||[i:=1..n]:Turnoff() Paralleliteration

87

Collaboration diagram [for withdrawal of cash, normal flow.]

1. Insert cardEnter password, Enter kindEnter amount,Take cash, Take cardcancel,Terminate, Continue

Display main screen unreadable card message,request password,request kind, request amount,canceled message, eject card, failure message,dispense cash, request take cashrequest continuation,print receipt, request take cardbad account message,bad bank account message

Verify account,process transaction

Transaction succeedTransaction failedaccount o.k.bad account,bad password,bad bank code

Create TransactionTransaction completeCUST-

OMER

BANK

ATMTRANSA-CTION

88

Objective of the fifth module

• To know the interaction among the objects in temporal and spatial form. • To know how objects collaborate among each other and hence delegate

the responsibility to the respective objects.• To understand how the messages get matured with more information.

89

Module-5

90

What is Class diagram?

• A class diagram shows the existence of classes and their relationships in the logical view of a system

• UML modeling elements in class diagrams are:– Classes, their structure and behavior.– relationships components among the classes like association,

aggregation, composition, dependency and inheritance– Multiplicity and navigation indicators– Role names or labels.

91

Major Types of classes:

Concrete classes• A concrete class is a class that is instantiable; that is it can have different

instances.• Only concrete classes may be leaf classes in the inheritance tree.Abstract classes• An abstract class is a class that has no direct instance but whose

descendants classes have direct instances.• An abstract class can define the protocol for an operation without

supplying a corresponding method we call this as an abstract operation.• An abstract operation defines the form of operation, for which each

concrete subclass should provide its own implementation.

10.93

10-3 DESIGN PHASE

The design phase defines how the system will accomplish what was defined in the analysis phase. In the design phase, all components of the system are defined.

10.94

Procedure-oriented design

In procedure-oriented design we have both procedures and data to design. We discuss a category of design methods that concentrate on procedures. In procedure-oriented design, the whole system is divided into a set of procedures or modules.

10.95

Structure chartsA common tool for illustrating the relations between modules in procedure-oriented design is a structure chart. For example, the elevator system whose state diagram is shown in the previous slides can be designed as a set of modules shown in the structure chart below

A structure chart

10.96

ModularityModularity means breaking a large project into smaller parts that can be understood and handled easily. In other words, modularity means dividing a large task into small tasks that can communicate with each other. The structure chart discussed in the previous section shows the modularity in the elevator system. There are two main concerns when a system is divided into modules: coupling and cohesion.

Coupling is a measure of how tightly two modules are bound to each other.

Coupling between modules in a software systemmust be minimized.

i

10.97

Another issue in modularity is cohesion. Cohesion is a measure of how closely the modules in a system are related. We need to have maximum possible cohesion between modules in a software system.

Cohesion between modules in a software systemmust be maximized.

i

10.98

Object-oriented design

In object-oriented design the design phase continues by elaborating the details of classes. As we mentioned in Chapter 9, a class is made of a set of variables (attributes) and a set of methods. The object-oriented design phase lists details of these attributes and methods. Figure 10.9 shows an example of the details of our four classes used in the design of the old-style elevator.

Figure 10.9 An example of classes with attributes and methods

11 topic 9 ooa

Documents

usecase modeling use

use casesa

system use cases

implementationdetails

class modeling object

pearson education

dynamic modeling

class modeling noun