1. Elaboration Iteration 1- Part 1
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

4. Use Case: Process Sale Primary Actor: Cashier
Stakeholders and Interests: ...
Preconditions: ...
Postcondtions: ...
Main Success Scenario:
Customer arrives at POS checkout with goods adn/or services to purchase
Cashier starts a new sale
Cashier enters item identifier
System records sale line item and presents item description, prices, and running total.
Cashier repeats steps 3-4 until indicates done
System presents total with taxes calculated
Cashier tells Customer the total, and asks for payment
System logs completed sale and sends sale and payment information to the external Accounting system and Inventory system
System presents receipt
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
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

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.

8. UP Artifacts(SSD)

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

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:
Customer arrives at POS checkout with goods and/or services to purchase
Cashier starts a new sale
Cashier enters item identifier
System records sale line item and presents item description, prices, and running total.
Cashier repeats steps 3-4 until indicates done
System presents total with taxes calculated
Cashier tells Customer the total, and asks for payment
Customer pays and System handles payment
System logs completed sale and sends sale and payment information to the external Accounting system and Inventory system
System presents receipt
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 Sale
Register 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 model
List the candidate conceptual classes
Draw them in a domain model
Add the associations necessary to record relationships
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
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

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)

17. NextGen POS Domain Model
Names-only domain model

18. Domain Model: Adding Associations
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

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

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
Project
Language
Person
0..*
Job
1..*
Company
Person
Job
salary
job title

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 *
Text
Window 1 3
Button
Menu 1

23. NextGen POS Domain Model Associations

24. Need-to-know Associations

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

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

27. Domain Model Conclusion

28. UP Artifacts: Domain Model