oo methodology elaboration iteration 1- part 1. 2 table of contents use-case model: system sequence...
TRANSCRIPT
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
ProductSpecification
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
Domain Model: Adding Associations
• 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
Domain Model: Adding Associations
• 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
Domain Model: Adding Associations
• 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
Domain Model: Adding Associations
• 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
ProductSpecification
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
ProductSpecification
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
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
ProductSpecification
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
ProductSpecification
descriptionpriceitemID
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-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