60-322 Object-Oriented Analysis and Design

1. 60-322 Object-Oriented Analysis and Design Feb 2, 2009

2. From last lecture… • The quintessential object-oriented analysis is • the decomposition of a domain into noteworthy concepts or objects. • A domain model is a visual representation of conceptual classes or real-situation objects in a domain. • It has nothing to do with programming. • Applying UML notation, a domain model is illustrated with a set of class diagrams in which no operations (method signatures) are defined. 2

3. Ch.9 Domain Model • How to create a domain model? • Bounded by the current iteration requirements under design: • Find the conceptual classes • Draw them as classes in a UML class diagram. • Add associations and attributes. 3

4. Attributes • Conceptual classes have been identified, drawn using UML. • Associations have been identified, drawn using UML. • It is now time to find out attributes for each conceptual class. • An attribute is a logical data value of an object. 4

5. Attributes • So when do I know that I need an attribute for an conceptual class? • Guideline: Include attributes that the requirements (for example, use cases) suggest or imply a need to rememberinformation. • For example, a receipt (which reports the information of a sale) in the Process Sale use case normally includes a date and time, the store name and address, and the cashier ID, among many other things. Therefore, • Sale needs a dateTime attribute. • Store needs a name and address. • Cashier needs an ID. 5

6. Applying UML: Attribute Notation Attributes are shown in the second compartment of the class box. Their type and other information may optionally be shown. 6

7. Attributes As a convention, most modelers will assume attributes have private visibility (-) unless shown otherwise {readOnly} is probably the most common property string for attributes. • The full syntax for an attribute in the UML is: visibility name : type multiplicity = default {property-string} Multiplicity can be used to indicate the optional presence of a value, or the number of objects that can fill a (collection) attribute. 7

8. Attributes: Where to document attributes? • Didn’t we just record attributes in each class in UML format? So We document attributes in domain model, in those conceptual classes we drew? • Some modelers accept leaving such specifications only in the domain model, This is certainly one option. • Or place all such attribute requirements in the UP Glossary, which serves as a data dictionary. • Perhaps I've spent an hour sketching a domain model with a domain expert; afterwards, I can spend 15 minutes looking through it and transferring implied attribute requirements into the Glossary. 8

9. Attributes: Derived Attribute • The total attribute in the Sale can be calculated or derived from the information in the SalesLineItems. • When we want to communicate that • 1) this is a noteworthy attribute, but • 2) it is derivable, • we use the UML convention: a / symbol before the attribute name. 9

10. Attributes: Derived Attribute • As another example, a cashier can receive a group of like items (for example, six tofu packages), • enter the itemID once, and • then enter a quantity (for example, six). • Consequently, an individual SalesLineItem can be associated with more than one instance of an item. • The quantity that is entered by the cashier may be recorded as an attribute of the SalesLineItem. • However, the quantity can be calculated from the actual multiplicity value of the association, so it may be characterized as a derived attribute - one that may be derived from other information. 10

11. Attributes: Derived Attribute 11

12. Attributes types? • Informally, most attribute types should be what are often thought of as "primitive" data types, such as numbers and booleans. • The type of an attribute should not normally be a complex domain concept, such as a Sale or Airport. • For example, the currentRegister attribute in the Cashier class is undesirable because its type is meant to be a Register, which is not a simple data type (such as Number or String). • The most useful way to express that a Cashier uses a Register is with an association, not with an attribute. 12

13. Attributes types? Guideline • The attributes in a domain model should preferably be data types. Very common data types include: Boolean, Date (or DateTime), Number, Character, String (Text), Time. • Other common types include: Address, Color, Geometrics (Point, Rectangle), Phone Number, Social Security Number, Universal Product Code (UPC), SKU, ZIP or postal codes, enumerated types. • FOCUS ON DATA TYPE ATTRIBUTES. 13

14. Attributes types? • A common confusion is modeling a complex domain concept as an attribute. • To illustrate, a destination airport is not really a string; it is a complex thing that occupies many square kilometers of space. Therefore, Flight should be related to Airport via an association, not with an attribute. Guideline: • Relate conceptual classes with an association, not with an attribute. 14

15. More on Data types • Attributes in the domain model should generally be data types; • Informally these are "primitive" types such as number, boolean, character, string, and enumerations (such as Size = {small, large}). • More precisely, this is a UML term that implies a set of values for which unique identity is not meaningful (in the context of our model or system) . • Said another way, equality tests are not based on identity, but instead on value. • For example, it is not (usually) meaningful to distinguish between: • Separate instances of the Integer 5. • Separate instances of the String 'cat'. • Separate instance of the Date "Nov. 13, 1990". • By contrast, it is meaningful to distinguish (by object identity) between two separate Person instances whose names are both "Jill Smith" because the two instances can represent separate individuals with the same name. 15

16. More on Data types? • The recommendation that attributes in the domain model be mainly data types does not imply that C# or Java attributes must only be of simple, primitive data types. • The domain model is a conceptual perspective, not a software one. • In the Design Model, attributes may be of any type. • But you can also define new Data Type class if necessary. 16

17. Guideline on Defining New Data Type Class • Guideline on Defining New Data Type Class Represent what may initially be considered a number or string as a new data type class in the domain model if: • It is composed of separate sections. • phone number, name of person • There are operations associated with it, such as parsing or validation. • social security number • It has other attributes. • promotional price could have a start (effective) date and end date • It is a quantity with a unit. • payment amount has a unit of currency • It is an abstraction of one or more types with some of these qualities. • item identifier in the sales domain is a generalization of types such as Universal Product Code (UPC) and European Article Number (EAN) 17

18. Guideline on Defining New Data Type Class • Applying these guidelines to the POS domain model attributes yields the following analysis: • The item identifier (ItemID) is an abstraction of various common coding schemes, including UPC-A, UPC-E, and the family of EAN schemes. These numeric coding schemes have subparts identifying the manufacturer, product, country (for EAN), and a check-sum digit for validation. Therefore, there should be a data type ItemID class, because it satisfies many of the guidelines above. • The price and amount attributes should be a data type Money class because they are quantities in a unit of currency. • The address attribute should be a data type Address class because it has separate sections. 18

19. How to represent these new data type classes in UML If ItemID is a new type with its own attributes and associations, showing it as a conceptual class in its own box may be informative. There is no correct answer; resolution depends on how the domain model is being used as a tool of communication, and the significance of the concept in the domain. Since ItemID is a data type (unique identity of instances is not used for equality testing), it may be shown only in the attribute compartment of the class box. 19

20. Guideline • Attributes should not be used to relate conceptual classes in the domain model. The most common violation of this principle is to add a kind of foreign key attribute, as is typically done in relational database designs, in order to associate two types. • Relate types with an association, not with an attribute. 20

21. Guideline on Modeling Quantities and Units • Most numeric quantities should not be represented as plain numbers. Consider price or weight. Saying "the price was 13" or "the weight was 37" doesn't say much. Euros? Kilograms? • These are quantities with associated units, and it is common to require knowledge of the unit to support conversions. The NextGen POS software is for an international market and needs to support prices in multiple currencies. The domain model (and the software) should model quantities skillfully. • In the general case, the solution is to represent Quantity as a distinct class, with an associated Unit . It is also common to show Quantity specializations. Money is a kind of quantity whose units are currencies. Weight is a quantity with units such as kilograms or pounds. 21

22. Guideline on Modeling Quantities and Units 22

23. Examples on Attributes: NextGen POS 23

24. Examples on Attributes: Monopoly 24

25. We are Done Domain Model • Are those two case study domain models just shown correct? • There is no such thing as a single correct domain model. • All models are approximations of the domain we are attempting to understand; • The domain model is primarily a tool of understanding and communication among a particular group. • A useful domain model captures the essential abstractions and information required to understand the domain in the context of the current requirements, and aids people in understanding the domainits concepts, terminology, and relationships. • There is no such thing as a single correct domain model. 25

26. Iterative and Evolutionary Domain Modeling • In iterative development, we incrementally evolve a domain model over several iterations. • In each, the domain model is limited to the prior and current scenarios under consideration, rather than expanding to a "big bang" waterfall-style model that early on attempts to capture all possible conceptual classes and relationships. • For example, this POS iteration is limited to a simplified cash-only Process Sale scenario; therefore, a partial domain model will be created to reflect just that - not more. Guideline • Avoid a waterfall-mindset big-modeling effort to make a thorough or "correct" domain model - it won't ever be either, and such over-modeling efforts lead to analysis paralysis, with little or no return on the investment. • Limit domain modeling to no more than a few hours per iteration. 26

27. Put Domain Model Into Perspective 27

28. Put Domain Model Into Perspective • Inception • Domain models are not strongly motivated in inception, since inception's purpose is not to do a serious investigation, but rather to decide if the project is worth deeper investigation in an elaboration phase. • Elaboration • The Domain Model is primarily created during elaboration iterations, when the need is highest to understand the noteworthy concepts and map some to software classes during design work. 28

29. A Short Review Break • An association is a relationship between classes (more precisely, instances of those classes) that indicates some meaningful and interesting connection. • Consider including the following associations in a domain model: • Associations for which knowledge of the relationship needs to be preserved for some duration ("need-to-remember" associations). • Associations derived from the Common Associations List. • An attribute is a logical data value of an object. • Guideline: Include attributes that the requirements (for example, use cases) suggest or imply a need to rememberinformation.

30. Ch.10 System Sequence Diagrams (SSD) • What is SSD? • A system sequence diagram (SSD) is a fast and easily created artifact that illustrates input and output events related to the systems under discussion.. • Why study SSD? • They are input to operation contracts and most importantly - object design. (more convincing answer to come) • UML sequence diagram is used to illustrate SSD.

31. Ch.10 System Sequence Diagrams (SSD) • Another way to look at SSD: • Recall in Domain model, we only specified attributes, associations, and we are explicitly told not to worry about methods. • Domain model is static • We want to explore the dynamic aspect of the project domain. • A visual representation of use case.

32. The use case text and its implied system events are input to SSD creation. The SSD operations (such as enterItem) can in turn be analyzed in the operation contracts, detailed in the Glossary, and most important- serve as the starting point for designing collaborating objects.

33. Example NextGen SSD: • An SSD shows, for a particular course of events within a use case, • the external actors that interact directly with the system, • the system (as a black box), and • the system events that the actors generate. • Time proceeds downward, and the ordering of events should follow their order in the scenario.

35. Ch.10 System Sequence Diagrams (SSD) • Use cases describe how external actors interact with the software system we are interested in creating in text. • During this interaction an actor generates system events to a system, usually requesting some system operation to handle the event. • For example, when a cashier enters an item's ID, the cashier is requesting the POS system to record that item's sale (the enterItem event). That event initiates an operation upon the system. • The use case text implies the enterItem event, and the SSD makes it concrete and explicit.

36. Ch.10 System Sequence Diagrams (SSD) • The UML includes sequence diagrams as a notation that can illustrate actor interactions and the operations initiated by them. • A system sequence diagram is a picture that shows, for one particular scenario of a use case, • the events that external actors generate, • their order, and • inter-system events. • All systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems. • Guideline • Draw an SSD for a main success scenario of each use case, and frequent or complex alternative scenarios.

37. Identify System Events • We want to know What events are coming in to our system? • Because we have to design the software to handle these events (from the mouse, keyboard, another system, …) and execute a response. • Basically, a software system reacts to three things: • 1) external events from actors (humans or computers), • 2) timer events, and • 3) faults or exceptions (which are often from external sources). • It is useful to know what, precisely, are the external input events - the system events. They are an important part of analyzing system behavior.

38. Why SSD? • Before proceeding to a detailed design of how a software application will work, it is useful to investigate and define its behavior as a "black box." • System behavior is a description of what a system does, without explaining how it does it. • One part of that description is a system sequence diagram. • Other parts include the use cases and system operation contracts (to be discussed later). • Everything we did so far, including domain model just covered, is again for better understanding the project domain.

39. Applying UML: Sequence Diagram. • The UML does not define something called a "system" sequence diagram but simply a "sequence diagram." • The qualification is used to emphasize its application to systems as black boxes. • Later, sequence diagrams will be used in another context-to illustrate the design of interacting software objects to fulfill work. • We already saw UML sequence diagram. • We will see it again later.

40. SSD vs. use cases • An SSD shows system events for one scenario of a use case, therefore it is generated from inspection of a use case.

41. Naming System Events and Operations • Which is better, scan(itemID) or enterItem(itemID)? • System events should be expressed at the abstract level of intention rather than in terms of the physical input device. • Thus "enterItem" is better than "scan" (that is, laser scan) • because it captures the intent of the operation while remaining abstract and noncommittal with respect to design choices about what interface is used to capture the system event. It could by via laser scanner, keyboard, voice input, or anything. • It also improves clarity to start the name of a system event with a verb (add…, enter…, end…, make…), since it emphasizes these are commands or requests.

42. Modeling SSD involving other External Systems • SSDs can also be used to illustrate collaborations between systems, such as between the NextGen POS and the external credit payment authorizer. • However, this is deferred until a later iteration in the case study, since this iteration does not include remote systems collaboration. • Worry about this later (Ch 24).

43. SSD Information in Glossary • The elements shown in SSDs (operation name, parameters, return data) are terse. • These may need proper explanation so that during design it is clear what is coming in and going out. The Glossary is a great place for these details. • For example, the figure on slide 40, there is a return line containing the description "change due, receipt.“ • That's a vague description about the receipta complex report. So, the UP Glossary can have a receipt entry, that shows sample receipts (perhaps a digital picture), and detailed contents and layout. • Guideline • In general for many artifacts, show details in the Glossary.

44. Example Monopoly SSD