1. DOMAIN MODEL CLASS DIAGRAM Prepared by: Fatimah Alakeel November, 2011

2. Last time … The use case model i.e. system functionality expressed in a way understandable to an end user Now … Domain model.... and Class diagram

3. Domain Model

4. A Domain Model illustrates meaningful concepts in a problem domain. It is a representation of real-world things, not software components. It is a set of static structure diagrams; no operations are defined. It may show: – Concepts / entities [ Modeled as classes and objects] – associations between concepts – attributes of concepts

5. When to create Domain Model  domain modelling is usually carried out in parallel with use case modelling.  the domain model represents a structural/static view whereas use case modelling focuses on behaviour.  The domain model is viewed through a class diagram Requirements Analysis Design Implementation Test Use case model Process workflows Requirements model UML + a domain model

6. Why do we need a domain model?  Gives a conceptual framework of the things in the problem space  Helps you think – focus on semantics

7. Features of a domain model  The following features enable us to express time invariant static business rules for a domain:- o Domain classes – each domain class denotes a type of object. o Attributes – an attribute is the description of a named slot of a specified type in a domain class; each instance of the class separately holds a value. o Associations – an association is a relationship between two (or more) domain classes that describes links between their object instances. Associations can have roles, describing the multiplicity and participation of a class in the relationship. o Additional rules – complex rules that cannot be shown with symbology can be shown with attached notes.

8. Domain classes?  Each domain class denotes a type of object. It is a descriptor for a set of things that share common features. Classes can be:- o Business objects - represent things that are manipulated in the business e.g. Order. o Real world objects – things that the business keeps track of e.g. Contact, Site. o Events that transpire - e.g. sale and payment.  A domain class has attributes and associations with other classes

9. How do I make a domain model? Perform the following in very short iterations: o Make a list of candidate domain classes. o Draw these classes in a UML class diagram. o If possible, add brief descriptions for the classes. o Identify any associations that are necessary. o Decide if some domain classes are really just attributes. o Where helpful, identify role names and multiplicity for associations. o Add any additional static rules as UML notes that cannot be conveyed with UML symbols. o Group diagrams/domain classes by category into packages. Concentrate more on just identifying domain classes in early iterations !

10. Identifying Domain Classes?  An obvious way to identify domain classes is to identify nouns and phrases in textual descriptions of a domain.  Consider a use case description as follows:-  1. Customer arrives at a checkout with goods and/or services to purchase.  2. Cashier starts a new sale.  3. Cashier enters item identifier.  4. System records the sale line item and presents the item description, price and running total.

11. Identifying attributes ?  A domain class sounds like an attribute if: - o It relies on an associated class for it’s identity – e.g. ‘order number’ class associated to an ‘order’ class. The ‘order number’ sounds suspiciously like an attribute of ‘order’. o It is a simple data type – e.g. ‘order number’ is a simple integer. Now it really sounds like an attribute!

12. Domain Model Example1

13. Some candidate objects/classes for the retail banking system? Classes and Objects Customer?Retail Customer?Business Customer? Customer accounts?Transactions on customer accounts? What about the bank itself? … and the ATM system? Shop assistant? What about other actors from the use case model? Credit card system?

14. withdrawCashATM «actor» Banking system validat e Amount validatePIN > «actor» ATM system The Domain Model Returning to retail banking example … customer > business customerretail customer part of the use case model

15. A possible domain model for the retail banking system > Customer Retail Customer Business Customer Bank > Account SavingsCheque Cash Management ATM system Transaction holds► ◄has has► maintains▼ *1 * 1..2 * 1 * 1 ◄connectsTo The Domain Model 11

16. A possible domain model for the retail banking system > Customer Retail Customer Business Customer Bank > Account SavingsCheque Cash Management ATM system Transaction holds► ◄has has► maintains▼ *1 0..1 1..2 * 1 0..1 1 ◄connectsTo The Domain Model could introduce qualified associations cust# acc# 11

17. A possible domain model for the retail banking system > Customer Retail Customer Business Customer Bank > Account SavingsCheque Cash Management ATM system Transaction holds► ◄has has► maintains▼ *1 0..1 1..2 * 1 0..1 1 ◄connectsTo The Domain Model could introduce qualified associations cust# acc#.. and directed associations 11

18. Domain Model Example2

19. Classes and Objects Some candidate objects/classes for the restaurant booking system? a booking? a table? a customer? an advanced reservation? a walk in? the head waiter? the receptionist?

20. The Domain Model … now to the restaurant booking example … Table Transfer Record Booking Cancel Booking Record walk-in Display Booking Receptionist Head Waiter Staff Record Arrival Extension points: no booking > The use case diagram

21. The Domain Model … now to the restaurant booking example … Booking Table WalkInReservationCustomer 1 * 1 * ◄makes A UML note indicating a constraint on the association {Bookings for the same table must not overlap}

22. The Domain Model … only WalkIns and Reservations will be instantiated > Booking Table WalkInReservationCustomer 1 * 1 * ◄makes A UML note indicating a constraint on the association {Bookings for the same table must not overlap}

23. The Domain Model WalkInReservation 1 * 1 * ◄makes > Booking covers date time adding some attributes … Table places Customer name phone Glossary Booking: an assignment of a table to a party of diners for a meal Covers: The number of diners that a booking is made for. Customer: The person making the reservation. Places: The number of diners that can be seated at a particular table. Reservation: An advance booking for a table at a particular time. WalkIn: A booking that is not made in advance

24. The Domain Model WalkInReservation 1 * 1 * ◄makes > Booking covers date time Table places Customer name phone Restaurant Adding a class that will manage everything 1 * We will leave the issue of directional associations to later on

25. Class Diagram

26. Classes and Objects What are objects and classes? A preliminary definition: An object is a concept, an abstraction, or a thing with crisp boundaries and meaning for the problem at hand. An object has a state, behavior and identity. The structure and behavior of similar objects are defined in their common class. A person is a class whereas Fred, Tom and Mary are objects whose behavior and structure are defined by person. The decomposition of a problem into objects depends on judgement and the nature of the problem. There is no one correct representation Note:

27. Class Diagrams  The class diagram describes the structure, the common attributes and operations for the objects. In domain modeling the class diagrams do not include all detail. They may simply only show the class name and focus on the relationships between classes. In the analysis and early design models the class diagrams may provide further detail e.g. an indication of the major fields and methods within each class. Later in a more detailed design model further detail is provided e.g. the visibility of the fields and methods, the return values and parameters for all methods etc.

28. (UML) Class Diagrams Student In a domain model In an early analysis model moving towards a design model Student studNum studSurname getSurname() Student - studNum: int - studSurname: String - studGivenname: String + getSurname(): String + setSurname(name: String) : void

29. Software Design (UML) Classes ClassName attributes operations A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations in separate, designated compartments.

30. Software Design (UML) Class Names ClassName attributes operations The name of the class is the only required tag in the graphical representation of a class. It always appears in the top-most compartment. The class name is in bold and starts with a uppercase letter

31. Software Design (UML) Class Attributes Person name : String address : Address birthdate : Date ssn : Id An attribute is a named property of a class that describes the object being modeled. In the class diagram, attributes appear in the second compartment just below the name-compartment. The field name and data type of each field. Field names start with a lower case letter. This section must be shown if there are methods shown in the following section (although it can be empty).

32. Software Design (UML) Class Attributes (Cont’d) Person name : String address : Address birthdate : Date / age : Date ssn : Id Attributes are usually listed in the form: attributeName : Type A derived attribute is one that can be computed from other attributes, but doesn’t actually exist. For example, a Person’s age can be computed from his birth date. A derived attribute is designated by a preceding ‘/’ as in: / age : Date

33. Software Design (UML) Class Attributes (Cont’d) Person + name : String # address : Address # birthdate : Date / age : Date - ssn : Id Attributes can be: + public # protected - private / derived

34. Software Design (UML) Class Operations Person name : String address : Address birthdate : Date ssn : Id eat sleep work play Operations describe the class behavior and appear in the third compartment.

35. Software Design (UML) Class Operations (Cont’d) PhoneBook newEntry (n : Name, a : Address, p : PhoneNumber, d : Description) getPhone ( n : Name, a : Address) : PhoneNumber You can specify an operation by stating its signature: listing the method name, type, and default value of all parameters, and, in the case of functions, a return type. This section may be omitted.

36. Software Design (UML) Depicting Classes Person name : String birthdate : Date ssn : Id eat() sleep() work() play() When drawing a class, you needn’t show attributes and operation in every diagram. Person name address birthdate Person eat play Person

37. Software Design (UML) Class Responsibilities A class may also include its responsibilities in a class diagram. A responsibility is a contract or obligation of a class to perform a particular service. SmokeAlarm Responsibilities -- sound alert and notify guard station when smoke is detected. -- indicate battery state

38. Software Design (UML) Relationships In UML, object interconnections (logical or physical), are modeled as relationships. There are three kinds of relationships in UML: dependencies generalizations associations

39. Software Design (UML) Dependency Relationships CourseSchedule add(c : Course) remove(c : Course) Course A dependency indicates a semantic relationship between two or more elements. The dependency from CourseSchedule to Course exists because Course is used in both the add and remove operations of CourseSchedule.

40. Software Design (UML) Generalization Relationships Person A generalization connects a subclass to its superclass. It denotes an inheritance of attributes and behavior from the superclass to the subclass and indicates a specialization in the subclass of the more general superclass. Student

41. Software Design (UML) Generalization Relationships (Cont’d) Student UML permits a class to inherit from multiple superclasses, although some programming languages (e.g., Java) do not permit multiple inheritance. TeachingAssistant Employee

42. Software Design (UML) Association Relationships If two classes in a model need to communicate with each other, there must be link between them. An association denotes that link. Instructor Student

43. Software Design (UML) Association Relationships (Cont’d) We can indicate the multiplicity of an association by adding multiplicity adornments to the line denoting the association. The example indicates that a Student has one or more Instructors: Instructor Student 1..*

44. Software Design (UML) Association Relationships (Cont’d) The example indicates that every Instructor has one or more Students: Instructor Student 1..*

45. Software Design (UML) Association Relationships (Cont’d) We can also indicate the behavior of an object in an association (i.e., the role of an object) using rolenames. Instructor Student 1..* learns fromteaches

46. Software Design (UML) Association Relationships (Cont’d) We can also name the association. Team Student membership 1..*

47. Software Design (UML) Association Relationships (Cont’d) We can specify dual associations. Team Student member of 1..* president of11..*

48. Software Design (UML) Association Relationships (Cont’d) We can constrain the association relationship by defining the navigability of the association. Here, a Router object requests services from a DNS object by sending messages to (invoking the operations of) the server. The direction of the association indicates that the server has no knowledge of the Router. Router DomainNameServer

49. Software Design (UML) Association Relationships (Cont’d) Associations can also be objects themselves, called link classes or an association classes. Warranty ProductRegistration modelNumber serialNumber warrentyCode

50. Software Design (UML) Association Relationships (Cont’d) A class can have a self association. LinkedListNode nex t previous

51. Software Design (UML) Association Relationships (Cont’d) We can model objects that contain other objects by way of special associations called aggregations and compositions. An aggregation specifies a whole-part relationship between an aggregate (a whole) and a constituent part, where the part can exist independently from the aggregate. Aggregations are denoted by a hollow-diamond adornment on the association. Car Engine Transmission

52. Software Design (UML) Association Relationships (Cont’d) A composition indicates a strong ownership and coincident lifetime of parts by the whole (i.e., they live and die as a whole). Compositions are denoted by a filled-diamond adornment on the association. Window ScrollbarTitlebarMenu 1 1 1 1 1 1.. *

53. Domain model vs. Design Class Diagram – differences? Figure 16.2

54. References  Business Modelling with UML” – Penker  “Analysis patterns” – Fowler These books provide patterns for domain models.