Jan 16, Ron McFadyen1 Ch 9. Use-case model: drawing System Sequence Diagrams Iteration 1: a simple cash-only success scenario of Process Sale beginning a wide-and-shallow design and implementation touches on many major architectural elements begins with a expansion of the Use Case Model with a System Sequence Diagram

Jan 16, Ron McFadyen2 Simple cash-only Process Sale scenario 1. Customer arrives at a 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, price, 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...

Jan 16, Ron McFadyen3 System Sequence Diagram a picture showing actors and systems events and their sequence for a particular scenario :Cashier :System an arbitrary cashier a cashier object the software system to be developed

Jan 16, Ron McFadyen4 System Sequence Diagram :Cashier :System Message at Time1 from :Cashier to :System Message at Time2 from :System to :Cashier A directed arrow from one lifeline to another lifeline shows a message being sent Suppose the Cashier sends a message first, followed later by a return message from the System : Earlier events are above later events in the diagram time travels downward Time1 earlier than Time2: Time1 < Time2

Jan 16, Ron McFadyen5 Figure 9.1

Jan 16, Ron McFadyen6 Figure 9.3

Jan 16, Ron McFadyen7 Ch 10. Domain Model: Visualizing Concepts Domain model illustrated with a class diagram (with no operations defined) emphasis on real-world objects a visual dictionary a map of concepts in a domain contains (conceptual) classes from the problem domain associations attributes

Jan 16, Ron McFadyen8 Ch 10. Domain Model: Visualizing Concepts Domain model

Jan 16, Ron McFadyen9 Classes are usually derived from: Where Examples thingsbook, copy, course, student, building roleslibrary member, student, director of students, admissions clerk eventsarrival, leaving, request interactionsmeeting, interaction Good object oriented design results in a class model which does not distort the conceptual reality of the domain

Jan 16, Ron McFadyen10 Associations correspond to verbs expressing a relationship between classes objects do not exist in isolation - they fit together in some way examples: a Library Member borrows a Copy of a Book a Person works for a Company Multiplicities we indicate via multiplicities the range of allowable cardinalities for participation in an association examples: 1, 1..*, 0..*, 1..3 PersonCompany 1..* 1

Jan 16, Ron McFadyen11 zero or more; "many" one or more one to forty exactly five T T T T * 1.. * T 3, 5, 8 exactly three, five or eight Customer Video Rents  * One instance of a Customer may be renting zero or more Videos. One instance of a Video may be being rented by zero or one Customers Multiplicity

Jan 16, Ron McFadyen12 Associations Names and roles you can name the relationship and indicate how to read it you can give role names for participating objects PersonCompany Works for 1..* 1 employer employee The role of a Person in this relationship The role of a Company in this relationship The name of the relationship and the direction for reading the name

Jan 16, Ron McFadyen13 Attributes an object contains data which are defined as part of the Class definition examples: Students have names, addresses, etc; Courses have titles, descriptions, prerequisite information. Rectangle corner: Point Student name: string address: string

Jan 16, Ron McFadyen14 Attributes show only “simple” relatively primitive types as attributes connections to other concepts are to be represented as associations, not attributes we do not show attributes that would be implementations of associations example: an Invoice would not have an attribute for Customer; that is handled by the association between Customer and Invoice Invoice invDate: date Customer name: string address: string