1. INFO 355Week #31 Systems Analysis II Domain Modeling INFO 355 Glenn Booker

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 INFO 355Week #32

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) INFO 355Week #33

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 INFO 355Week #34

5. Attributes  Lots of nouns are attributes (data about something else)  Collect attributes with their noun owners INFO 355Week #35

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 INFO 355Week #36

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 INFO 355Week #37

8. INFO 355Week #38 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)

9. INFO 355Week #39 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

10. INFO 355Week #310 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

11. INFO 355Week #311 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

12. INFO 355Week #312 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

13. INFO 355Week #313 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

14. INFO 355Week #314 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

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

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

17. INFO 355Week #317 Analogies to ERD ERD hasClass Diagram has EntitiesClasses RelationshipsAssociations CardinalityMultiplicity Data elements or attributes or fields Attributes

18. INFO 355Week #318 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

19. INFO 355Week #319 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

20. INFO 355Week #320 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)

21. INFO 355Week #321 Finding Classes

22. INFO 355Week #322 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?

23. INFO 355Week #323 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

24. INFO 355Week #324 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

25. INFO 355Week #325 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

26. INFO 355Week #326 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)

27. INFO 355Week #327 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

28. INFO 355Week #328 Finding Associations

29. INFO 355Week #329 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

30. INFO 355Week #330 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

31. INFO 355Week #331 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?)

32. INFO 355Week #332 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

33. INFO 355Week #333 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 ‘ ’ in the label for the arrow 11 Records-current > -date -time Sale -date -time Register Don’t need arrow if association is read left-right or top-bottom

34. INFO 355Week #334 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

35. INFO 355Week #335 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’

36. INFO 355Week #336 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

37. INFO 355Week #337 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 and Flight Flies-from Airport

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

39. INFO 355Week #339 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

40. INFO 355Week #340 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

41. INFO 355Week #341 Finding Attributes

42. INFO 355Week #342 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)

43. INFO 355Week #343 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

44. INFO 355Week #344 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

45. INFO 355Week #345 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)

46. INFO 355Week #346 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

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 INFO 355Week #347

48. Generalization  Subclasses inherit attributes (and methods) from superclasses Inheritance is a key object oriented concept INFO 355Week #348