Elaboration Iteration 1- Part 1 OO Methodology Elaboration Iteration 1- Part 1

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

Use-Case Model

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

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

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

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.

UP Artifacts(SSD)

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

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

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

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

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

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

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

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)

NextGen POS Domain Model Names-only domain model

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

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

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

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

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

NextGen POS Domain Model Associations

Need-to-know Associations

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

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

Domain Model Conclusion

UP Artifacts: Domain Model