oo methodology elaboration iteration 1- part 1. 2 table of contents use-case model: system sequence...

OO Methodology

Elaboration Iteration 1- Part 1

2

Table of Contents

• Use-case model: System Sequence Diagrams

• Domain Model: Visualizing Concepts

• Domain Model: Adding Associations

• Domain Model: Adding Attributes

• Use-Case Model: Adding Detail with Operation Contracts

• From Requirements to Design

• Interaction Diagram Notations

• GRASP: Designing Objects with Responsibilities

• Design Model: Use-case Realizations

• Design Model: Determining Visibilities

• Design Model: Creating Design Class Diagrams

• Implementation Model

3

Use-Case Model

NextGen

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

Handle ReturnsPayment

AuthorizationService

«actor»Tax Calculator

«actor»Accounting

System

alternatenotation fora computersystem actor

Process Rental

«actor»HR System

Cash In

Process Sale

«actor»Sales Activity

System

Manage Security

Analyze Activity

4

Use Case: Process Sale

Primary Actor: Cashier

Stakeholders and Interests: ...

Preconditions: ...

Postcondtions: ...

Main Success Scenario:

1. Customer arrives at POS checkout with goods adn/or services to purchase

2. Cashier starts a new sale

3. Cashier enters item identifier

4. System records sale line item and presents item description, prices, and running total.

Cashier repeats steps 3-4 until indicates done

5. System presents total with taxes calculated

6. Cashier tells Customer the total, and asks for payment

7. System logs completed sale and sends sale and payment information to the external Accounting system and Inventory system

8. System presents receipt

9. Customer leaves with receipt and goods

5

Requirements

• Implement a basic, key scenario of the Process Sale use case; entering items and receiving a cash payment

• Implement a Start Up use case as necessary to support the initialization needs of the iteration

• No collaboration with external services, such as a tax calculator or product databases

• No complex pricing rules are applied

6

Use-case model: System Sequence Diagrams

• System Sequence Diagrams– To illustrates input and output events related to the systems

under discussion

– To investigate and define the system behavior as a black box

– To isolate and illustrate the operations that an external actor requests of a system

• SSD for Process Sale

enterItem(itemID,quantity)

:System: Cashier

endSale()

makePayment(amount)

box may enlose aniteration area

the * [...] is an iterationmarker and clauseindicating the box is foriteration

external actor tosystem

Process Sale Scenario

system as black box

the name could be "NextGenPOS" but "System" keeps itsimple

the ":" and underline imply an instance, and are explained in alater chapter on sequence diagram notation in the UML

a message withparameters

it is an abstractionrepresenting thesystem event ofentering thepayment data bysome mechanism

description,total

return value(s)associated with theprevious message

an abstraction thatignores presentationand medium

the return line isoptional if nothing isreturned

total withtaxes

change due,receipt

* [more items]

makeNewSale()

7

Use-case model: System Sequence Diagrams

• SSDs and Use Cases

• Naming System Events and Operations– To capture the intent of the operation

• “enterItem” is better that “scanBarcode”

– To emphasize the command orientation: use verb• enter..., end..., make... etc.

: Cashier :System

Simple cash-only Process Sale scenario:

1. Customer arrives at a POS checkoutwith goods and/or services to purchase.2. Cashier starts a new sale.3. Cashier enters item identifier.4. System records sale line item andpresents item description, price, andrunning total.Cashier repeats steps 3-4 until indicatesdone.5. System presents total with taxescalculated.6. Cashier tells Customer the total, andasks for payment.7. Customer pays and System handlespayment....

enterItem(itemID,quantity)

endSale()

makePayment(amount)

description,total

total withtaxes

change due,receipt

* [more items]

makeNewSale()

8

UP Artifacts(SSD)

Glossary

SoftwareArchitecture Doc.

DomainModel

Requirements

ProjectManagement

BusinessModeling

Design

Sample UP ArtifactsPartial artifacts,refined in each

iteration.

Partial artifacts,refined in each

iteration.

Test

TestPlan

SoftwareDev. Plan

. . .

Use-Case Model

textuse

cases

:System

foo( x )

systemoperationcontracts

systemsequencediagrams

systemevents &data

systemoperations

design objectsto handle thesystem events

parameter orreturn data may beelaborated in theGlossary

Design Model

bar( y )

Environment

DevelopmentCase

9

Domain Model: Visualizing Concepts

• A domain model – a representation of real-world conceptual classes, not of

software components

– a visual representation of conceptual classes or real-world objects in a domain of interest

– also called conceptual model, domain object model, and analysis object model

• A domain model includes– domain objects or conceptual classes

– association between conceptual classes

– attributes of conceptual classes

• An example

Register

Item

Store

addressname

Sale

datetime

Payment

amount

SalesLineItem

quantity

Stocked-in

*

Houses

1..*

Contained-in

1..*

Records-sale-of

0..1

Paid-by

1

1

1

1

1

1

1

1

Captured-on

conceptor domainobject

association

attributes

10

Conceptual Class Identification

• Domain Model and Decomposition– Structured analysis : decomposition by functions

– Object-oriented analysis: decomposition by objects

• Incremental building a domain model in iterative development

• General guideline– it is better overspecify a domain model with lots of fine-

grained conceptual classes than to underspecify it

• Two techniques to identify conceptual classes– Use a conceptual class category list

– Identify noun phrases

11

Conceptual Class Identification

• Conceptual Class Category List– physical or tangible objects : Register, Airplane– specifications, descriptions : ProductionSpecification FlightDescription– places : Store, Airport– transactions : Sale, Payment Reservation– transaction line items : SaleLineItem– roles of people : Cashier, Pilot– containers of other things : Store, Bin, Airplane– things in a container : Item, Passenger– external systems : CreditPaymentAuthori- zationSystem AirTrafficControl– abstract noun concepts : Hunger,

Acrophobia– organizations : SalesDepartment : KoreanAirLine– processes : SellingAProduct BookingASeat– rules and policies : RefundPolicy

CancellationPolicy– catalogs : ProductCatalog PartCatalog– records of finance, work etc. : Receipt, Ledger, Contract– ...

12

Noun Phrase Identification

• Consider nouns and noun phrases as candidate conceptual classes or attributes

• Fully dressed uses cases are an excellent source to draw from

• Example Main Success Scenario:

1. Customer arrives at POS checkout with goods and/or services to purchase

2. Cashier starts a new sale

3. Cashier enters item identifier

4. System records sale line item and presents item description, prices, and running total.

Cashier repeats steps 3-4 until indicates done

5. System presents total with taxes calculated

6. Cashier tells Customer the total, and asks for payment

7. Customer pays and System handles payment

8. System logs completed sale and sends sale and payment information to the external Accounting system and Inventory system

9. System presents receipt

10. Customer leaves with receipt and goods

• Weakness of this approach– imprecision of natural language : goods, services

13

Candidate Conceptual Classes for the Sales Domain

• From simplified scenario of Process SaleRegister ProductionSpecification

Item SalesLineItem

Store Cashier

Sale Customer

Payment Manager (from StartUp use case)

ProductCatalog

• Why Receipt is not included in the model?– a receipt is a record of a sale and payment that buyer keeps

– a receipt has a special role in terms of the business rules: the right to the bearer of the receipt to return bought items

– it would be considered to include it at Handle Returns use case

14

Domain Modeling Guidelines

• How to make a domain model1. List the candidate conceptual classes

2. Draw them in a domain model

3. Add the associations necessary to record relationships

4. Add the attributes necessary to fulfill the information requirements

• A common mistake in identifying conceptual classes– if we do not think of some conceptual class X as a number or

text in the world, X is probably a conceptual class, not an attribute

– e.g. Should Store be an attribute of Sale or a separate conceptual class

or

– e.g. Should destination be an attribute of Flight or a separate conceptual class Airport

or

– If in doubt, make it a separate concept

Sale

store

Sale

Store

phoneNo

Flight

destination

Flight

Airport

name

15

Domain Modeling Guidelines

• Resolving Similar Conceptual Classes– Register vs. POST (point of sale terminal)

• Specification or Description Conceptual Classes– there needs to be a description about an item or service,

independent of the current existence of any instances of those items or services

– deleting instances of things they describe results in a loss of information

– it reduces redundant or duplicated information

• Description of Services– MultiPack, Na, BiGi, JeJu4DaysTrip etc.

as a rule of thumb, a domain model is not absolutely correct or wrong,but more or less useful

Item

descriptionpriceserial numberitemID

ProductSpecification

descriptionpriceitemID

Item

serial number

Describes Better

Worse

1 *

16

UML Notation and Models

• UML does not superimpose a method or modeling perspective on raw diagrams types, such as class diagrams etc.

• Rather, a process(such as UP) applies raw UML in the context of models

• a diagram can be interpreted differently in different models

– conceptual perspective – conceptual class(class)

– specification perspective – software abstraction (class)

– implementation perspective – software implementation(class)

Payment

amount

Sale

datetime

Pays-for

Payment

amount: Money

getBalance(): Money. . .

Sale

date: DatestartTime: Time

getTotal(): Money. . .

Pays-for

UP Domain Model

Raw UML class diagramnotation used in anessential modelvisualizing real-worldconcepts.

UP Design Model

Raw UML class diagramnotation used in aspecification modelvisualizing softwarecomponents.

1 1

1 1

17

NextGen POS Domain Model

• Names-only domain model

StoreRegister SaleItem

Payment

SalesLineItem

Cashier Customer Manager

ProductCatalog


18

Domain Model: Adding Associations

• Association– a relationship between types that indicates some meaningful

and interesting connection

– a semantic relationship between two or more classifiers that involve connections among their instances

– need-to-know associations : associations for which knowledge of the relationship needs to be preserved for some duration

• Example– do we need to remember what SalesLineItem instances are

associated with a Sale instance?

– do we need to have memory of a relationship between a current Sale and a Manager?

• UML notation

SaleRegisterRecords-current

1 1

association

19


• Common Association List

– A is a physical part of B Drawer-Register Wing – Airplane– A is a logical part of B SalesLineItem –

Sale FlightLeg –

FlightRoute– A is physically contained in B Register – Store Passenger –

Airplane– A is a description for B ItemDescription –

Item FlightDescription–

Flight– A is a line item of a transaction SalesLineItem – Sale or report B– A is known/logged/recorded/ Sale – Register

reported/captured in B Reservation - FlightManifest– A is a member of B Cashier – Store Pilot – Airline– A is an organizational subunit of B Department – Store– A uses or manages B Cashier – Register Pilot – Airplane– A communicate with B Customer – Cashier Reservation Agent – Passenger– A is related to a transaction Customer – Payment– etc

20


• Association Guidelines– focus on those associations for which knowledge of the

relationship needs to be preserved for some duration

– it is more important to identify conceptual classes than to identify associations

– Too many associations tend to confuse a domain model

– Avoid showing redundant or derivable associations

• Multiplicity– defines how many instances of a class A can be associated

with one instance of a class B at a particular moment

– 1 0..* 1..* 1..5 3,5,8

• Roles in an Association– an association can have roles connected to each class

involved in the association

– a role indicates the role played by the class in terms of the association

• Navigability : directional or bidirectional

ItemStore Stocks

*

multiplicity of the role

1

21


• Multiple associations between two types

• N-ary Association– more than two classes can be associated

• Association Class– Modeling an association as a class

Flight Airport

Flies-to

Flies-from*

* 1

1

Project Language

Person

Company Person0..* 1..*

Job

salaryjob title

Job

22


• Aggregation – is the “part-whole” or “a-part-of” relationship

– a special form of association

• Composite aggregation– is a strong form of aggregation

– requires that a part instance be included in at most one composite at a time

– requires that the composite object has sole responsibility for the disposition of its parts

Store Cashier**

Window

Text

Button

Menu

1

*

3

1

23

NextGen POS Domain Model Associations

Register

ItemStore

Sale

Payment

SalesLineItem

CashierCustomer

Manager

ProductCatalog


Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Described-by

*

Records-sale-of

0..1

Started-by

Paid-by Initiated-by

Logs-complete

d*

Records-sales-on

1

1

1

1

1

1..*

11

1

1

1

1

1

1

1

1 1

1

Initiated-by

1

1

24

Need-to-know Associations

Register

ItemStore

Sale

Payment

SalesLineItem

CashierCustomer

Manager

ProductCatalog


Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Described-by

*

Records-sale-of

0..1

Started-by


Logs-complete

d*

Records-sales-on

1

1

1

1

1

1..*

11

1

1

1

1

1

1

1

1 1

1

Initiated-by

1

1

25

Domain Model: Adding Attributes

• An attribute is a logical data value of an object– those for which the requirements imply a need to remember

information

– e.g.Sale class needs a date and time attribute

• Valid attribute types– some things should be represented as associations

– the attributes in a domain model should be simple attributes or data types

• Numbers, Date, String, Boolean, Address, Color, PhoneNo. etc.

– do not model a complex domain concept as an attribute

Cashier

namecurrentRegister

Cashier

name

Register

number

Uses

Worse

Better

not a "simple" attribute

1 1

Flight

Flight

destinationWorse

BetterFlies-to Airport1 1

destination is a complexconcept

26

Domain Model: Adding Attributes

• Data types vs Non-primitive data type classes– objects in data types(in UML term) are value objects(id is not

important)

– primitive-like attribute(such as string, number etc) may be considered as non-primitive class

• has separate sections (phone number, person name etc)

• has associated operations

• has attributes

– A domain model is a tool of communication

• Not attributes as foreign keys

OK

OK

ItemIDProduct

Specification


id : ItemID

1AddressStore

Store

address : Address

11 1

Cashier

namecurrentRegisterNumber

Cashier

name

Register

number

Uses

Worse

Better

a "simple" attribute, but beingused as a foreign key to relate toanother object

1 1

27

Domain Model Conclusion

Register

ItemStore

addressname

Sale

date

time

Payment

amount

SalesLineItem

quantity

CashierCustomer

Manager

ProductCatalog


descriptionpriceitemID

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Described-by

*

Records-sale-of

0..1

Started-by


Logs-completed

*

Records-sales-on

1

1

1

1

1

1..*

11

1

1

1

1

1

1

1

1 1

1

28

UP Artifacts: Domain Model

Glossary

SoftwareArchitecture Doc.

DomainModel

Requirements

ProjectManagement

BusinessModeling

Design

Sample UP ArtifactsPartial artifacts,refined in each

iteration.

Partial artifacts,refined in each

iteration.

Test

TestPlan

SoftwareDev. Plan

. . .

Use-Case Model

textuse

cases

:System

foo( x )

systemoperationcontracts

systemsequencediagrams

terms, conceptsattributes,associations

state changes indomain objects,attributes,associations

elaboration ofsome terms inthe domainmodel

software classes inthe domain layer ofthe design takeinspiration from thenames, attributes,and associations inthe domain model

bar( y )

usecase

diagrams

**

Design Model

Environment

DevelopmentCase

oo methodology elaboration iteration 1- part 1. 2 table of contents use-case model: system sequence...

Documents