Systems Analysis II Domain Modeling

1. Systems Analysis IIDomain Modeling INFO 355 Glenn Booker Week #3

2. Problem Domain • Based on the requirements (use cases), we can start to identify the problem domain • What is part of our problem? • What isn’t? • Often develop this based on brainstorming what ‘things’ are of importance in the use cases Week #3

3. Things • Things such as • Tangible things (book, airplane) • Roles (employee, customer, patient) • Organizational units (division, dept) • Devices (sensor, controller, bin) • Sites (warehouse, facility, branch office) • Events (flight, contract, order) Week #3

4. Nouns • Or the domain might include more general nouns • What nouns appear often in use case descriptions? • Are they in the scope of the system? • Are they inputs, outputs, processes, …? • Does it describe some other noun? • Make a list and refine it as needed Week #3

5. Attributes • Lots of nouns are attributes (data about something else) • Collect attributes with their noun owners Week #3

6. ERD • One way to model the domain of a system is the entity relationship diagram • But you had this in INFO 200 • So instead we’ll focus on the domain model class diagram Week #3

7. Class Diagram • The class diagram goes through several stages of development in object-oriented modeling • The first is the domain model • Later we have the design class diagram and the application class diagram • Same thing, just with added detail Week #3

8. Purpose of Class Diagram • The Class Diagram shows many key characteristics of the system • What classes can exist • Their attributes (data) • Their methods (functions to get to the data) • How the classes see each other (like relationship and cardinality) Week #3

9. Class Diagram Evolves • The class diagram evolves as a system is analyzed • The initial conceptual class diagram might just show classes and key attributes, connected by associations • The application class diagram can show all classes needed to complete the system Week #3

10. Types of Classes • It often helps to think of three types of classes • Data classes are used to store data, much like traditional entities • Control classes are used to manage performing a use case, like scripts • Interface classes are the GUI seen by the user – they are the classes first acted upon Week #3

11. Types of Classes • Another set of terms for the same concept is Model-View-Controller • Model = data classes • View = interface classes • Controller = control classes • There are times when it’s good to combine model and controller, or view and controller, but this is a good pattern to consider Week #3

12. Classes versus Objects • Recall that objects are derived, or instantiated, from classes • Hence we assume that any class could be used one or more times to create objects • Objects can be created and destroyed, including interface classes and temporary data Week #3

13. The Conceptual Class Diagram • To define the conceptual class diagram, we’ll need to determine • Classes • Primarily data and major control classes • Associations • Including label and multiplicity • Attributes Week #3

14. Conceptual Class Diagram • Also called a Domain Model, the conceptual class diagram is the simplest form of the class diagram • It shows the classes, their associations, and attributes • Does not show methods or interface classes Week #3

15. Types of Classes • For the conceptual class diagram, focus on data classes, and controller classes for significant use cases • Fill in the rest later Week #3

16. 1..* Contained-in 1 SalesLineItem Sale -quantity -date -time Paid-by 1 Association Multiplicity (discuss later) 1 Conceptual class Payment -amount Attribute Conceptual Class Diagram Excerpt Association label Week #3

17. Analogies to ERD Week #3

18. Analogies to ERD • Just because a conceptual class diagram looks similar to an ERD, don’t think they are the same thing! • Classes can exist for transient data you’d never keep in an entity Week #3

19. Class Naming Conventions • Notice that Class and attribute names are singular (Sale, not Sales), and words are spelled out • The dash before attribute names has meaning … we’ll get to later Week #3

20. Class Naming Conventions • Capitalization conventions: • Class names use initial capital letters for each word; no spaces between them (SalesLineItem), also called camelback notation • Attributes start lower case (date, terminationDate) • Associations use initial capital letters for the first word and dashes between words (Contained-in) Week #3

21. Finding Classes Week #3

22. Identifying Classes • Use the use case scenarios for finding conceptual classes – look for noun phrases, then evaluate them • Is it an important concept for this system? • Is it an attribute of something bigger, or is it a self-contained idea or thing? Week #3

23. Identifying Classes • Consider the possibility that classes can have other classes within them • A single Sale can have many entries, each of which is a SalesLineItem • A ComputerSystem can have many ComputerParts Week #3

24. Identifying Classes • Notice that classes can be actions, transactions, or events, like • BookingASeat: A controller class for managing the process of booking a seat on an airline • There is not a single correct list of classes for a problem Week #3

25. Identifying Classes • Use terminology for class names which is native to the system’s environment • Don’t make the customer learn new words for old ideas • Omit things which aren’t relevant to meeting the system’s requirements • If in doubt, make it a separate class • Then see if it’s needed later Week #3

26. Identifying Classes • People’s roles might be classes • Does the type of user require a separate class, or is it just an attribute? • Might need a class if the user type affects what data are needed (attributes) or functions can be performed (methods) Week #3

27. Description Conceptual Classes • Often it is needed to have a place for information about a thing – such as a product description • We tend to keep a class for such descriptions, in case all those things disappear (e.g. are sold) • Many sales or manufacturing systems will have a ProductDescription class or ProductSpecification This is another design pattern Week #3

28. Finding Associations Week #3

29. Adding Associations • An association is shows that there is a meaningful connection between two classes • Formally, it is: The semantic relationship between two or more classifiers that specifies connections among their instances Week #3

30. Adding Associations • Associations imply a relationship which may be kept for a second, or forever • Associations are often from a need-to-know basis – e.g. we ‘need to know’ what line items were associated with a given sale Week #3

31. Adding Associations • Associations are generally needed to trace data • In order to find some piece of data, what do I need to know to track it down? (customer might need to look up their orders, for example) • Or, what comes first in the process? (if I’m creating a new order, do I need to know what customer is doing so, or can I add that later?) Week #3

32. Adding Associations • For a conceptual model with ‘n’ classes, there can be n*(n-1) possible associations • You need to determine: which associations are significant? • Associations are assumed bidirectional for now – information can go both directions • We’ll refine this later Week #3

33. 1 1 Register Records-current > Sale -date -date -time -time Labeling Associations • Each association has a label to describe the association, and may use an arrow to indicate which way the label should be read • In Visio, can use ‘<‘ or ‘>’ in the label for the arrow Don’t need arrow if association is read left-right or top-bottom Week #3

34. Finding Associations • Most common association types are • Physical or logical types (e.g. Register is physically located in Store) • When information is stored, recorded or captured (Register reports Sale) • Classes are more critical to identify than associations • Avoid too many associations • But at least one per class Week #3

35. Multiplicity • Here ‘*’ means many, but by itself it means ‘0, 1, or many’ • ‘1..*’ means one or many • ‘1..40’ means a range from 1 to 40 • ‘n’ means only the value of ‘n’ • Obsolete (from UML 1.x): • ‘a, b, c’ means only a, b, and c are allowable values, e.g. ‘2, 5, 7’ Week #3

36. Multiplicity • To determine multiplicity, think of what values may be true at any one moment • Consider what multiplicity is meaningful from your system’s point of view • If your system will never handle the case of 0 multiplicity, don’t need 0 to show in the domain model Week #3

37. Multiple Associations • It is possible to show two associations between the same two classes, if the associations are handled very differently by the system • E.g. Flight Flies-to Airport andFlight Flies-from Airport Week #3

38. Cleaning up Associations • In general, we may define associations conceptually that don’t get implemented (used), or may later find associations we missed here Week #3

39. Cleaning up Associations • Whether an association is needed depends heavily on the system’s requirements • “Sale Initiated-by Customer” may be trivial for a gas station, but important for a grocery store which analyzes its regular customers Week #3

40. Cleaning up Associations • OTOH, might want to keep associations which reveal key information about the problem, even though we may never implement them • “Sale Initiated-by Customer” could be kept as a reminder of who starts the purchasing process • Associations might be used with logging transactions Week #3

41. Finding Attributes Week #3

42. Adding Attributes • Attributes are data values which describe a class • Following the need-to-know concept, we want all attributes which we need to remember for our system • Attributes may be described by their type of data (particularly for non-primitive data types) Week #3

43. Adding Attributes • Key to finding good attributes is to make sure each one is • A simple characteristic • Which is uniquely defined by the class to which it belongs Week #3

44. Adding Attributes • Don’t worry about “keys” for defining associations to other classes, such as primary and secondary keys • Don’t worry about data normalization either • Focus only on data characteristics of each class Week #3

45. Primitive vs. Non-Primitive Data • Primitive data types are the most basic ways to represent data in a computer • Boolean (True/False, Yes/No, 0/1) • Number (integer or real) • String (text) • Date • Time (may be merged with Date) Week #3

46. Primitive vs. Non-Primitive Data • Most complex data types are considered non-primitive • Phone number, SSN, money, etc. are all non-primitive • We’ll discuss non-primitive data types next week Week #3

47. Generalization • We saw generalization in the use case diagram • It came from the class diagram • The arrow points to the superclass, away from the subclass • Use it when classes have similar attributes, but might differ in some ways from each other Week #3

48. Generalization • Subclasses inherit attributes (and methods) from superclasses • Inheritance is a key object oriented concept Week #3