1. Information Systems Analysis and Design Class Modeling
Glenn Booker
INFO 620
Lecture #4

2. Operation vs Method vs Message
Operation: A service that can be requested from an object to effect behavior. An operation has a signature, which may restrict the actual parameters that are possible. (all from UML 1.5 spec)
Method: The implementation of an operation. It specifies the algorithm or procedure associated with an operation.
INFO 620
Lecture #4

3. Operation vs Method vs Message
Message: A specification of the conveyance of information from one instance to another, with the expectation that activity will ensue. A message may specify the raising of a signal or the call of an operation.
So ‘message’ is the most abstract interaction description; which may call an ‘operation,’ which is implemented with a ‘method’
INFO 620
Lecture #4

4. Domain Model
The Domain Model is the highest level (most vague) class diagram for a system
Also known as the Conceptual Class Diagram
Looks similar to an ERD, but isn’t the same
It shows the classes, their associations, and attributes
INFO 620
Lecture #4

5. Domain Model
This is not the level where actual software classes with specific responsibilities (methods) will be defined
Conceptual classes do NOT explicitly include things like databases (as in CustomerDatabase) or interfaces, and do NOT include responsibilities (methods)
INFO 620
Lecture #4

6. Conceptual Class Diagram
INFO 620
Lecture #4

7. Class Naming Conventions
Class and attribute names are singular (Sale, not Sales), and words are spelled out
Capitalization conventions:
Class names use initial capital letters for each word; no spaces between them (SalesLineItem)
Attributes use all lower case (date)
Associations use initial capital letters for the first word and dashes between words (Contained-in)
INFO 620
Lecture #4

8. Formal Class Definition
Each class has three ways of describing it
Symbol which represents the class
Intension; a definition of the intent of the class
Extension; the set of all members of the class (e.g. every sale)
We mostly care about the class’ symbol and intension
INFO 620
Lecture #4

9. How find Classes?
Structured analysis used functional decomposition (break down what the system needs to be able to do) to find entities
OOAD looks instead for concepts involved in the problem
Classes can be abstract and transient
INFO 620
Lecture #4

10. Iterative Development
Classes are best found by looking at use case scenarios, and deciding what ideas are cited there
Expect many more classes than you would have entities for the same system
Some conceptual classes may not have any attributes – that’s okay!
INFO 620
Lecture #4

11. Identifying Classes
Already mentioned using 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?
INFO 620
Lecture #4

12. Identifying Classes
Also can use the list on pp for ideas (Table 10.1)
Notice that classes can be actions, transactions, or events, like BookingASeat
There is not a single correct list of classes for a problem
INFO 620
Lecture #4

13. 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
When in doubt, make it a separate class
INFO 620
Lecture #4

14. 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)
So many sales or manufacturing systems will have a ProductDescription class type
or ProductSpecification
INFO 620
Lecture #4

15. UML versus RUP
The Rational Unified Process defines the Domain Model concept – it isn’t part of the UML per se
UML recognizes the class diagram concept, and defines the visual representation of it
The same diagramming concepts can be used for conceptual, specification, or implementation perspectives
INFO 620
Lecture #4

16. Conceptual to Design Class
Many of the conceptual classes will eventually become classes in the Design Class Diagram
Others will get broken down into more detailed classes
The fact that we started using native terminology helps understand how the classes relate to the problem’s environment
INFO 620
Lecture #4

17. Domain Model and the RUP
The domain model, or conceptual class diagram, is usually started and finished in the Elaboration phase of the RUP
It forms the basis for the Design Class Model and later Implementation Class Model
The Domain Model is a variation on the Business Object Model (BOM)
INFO 620
Lecture #4

18. 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.
Associations imply a relationship which may be kept for a second, or forever
INFO 620
Lecture #4

19. Adding Associations
Associations are often from a need-to-know basis – e.g. we ‘need to know’ what line items were associated with a given sale
For a conceptual model with ‘n’ classes, there can be n*(n-1) possible associations
Which are significant?
Associations are assumed bidirectional for now – information can go both directions
INFO 620
Lecture #4

20. 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
INFO 620
Lecture #4

21. Finding Associations
Other than need-to-know basis, can find associations from the list on pp
The first four types shown may be aggregations, which we’ll discuss later
The known/logged type includes any form of recording data
“Organizational subunit” could be any kind of department
May not need to keep “uses or keeps” relations
INFO 620
Lecture #4

22. Finding Associations
Most common association types are the physical or logical types (e.g. Register is physically located in Store), or when information is stored, recorded or captured (Register reports Sale)
Classes are more critical to identify than associations
Avoid too many associations
INFO 620
Lecture #4

23. Roles
Each association describes a role (allowable behavior between the classes)
Roles may have names and multiplicity (we’ll add navigability later)
Multiplicity is like cardinality for an ERD
Here, more flexible
Multiplicity can give allowable ranges, specific values, or the classic 0/1/many
INFO 620
Lecture #4

24. 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’
‘a, b, c’ means only a, b, and c are allowable values
INFO 620
Lecture #4

25. 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
INFO 620
Lecture #4

26. More on Naming Associations
General rule of thumb: If the association is oriented top to bottom, or left to right, don’t need to show an arrow
The name of an association is the class name, space, association label, space, then the other class name; e.g. from slide 20:
“Register Records-current Sale” is the association name
INFO 620
Lecture #4

27. Multiple Associations
It is possible to show two associations between two classes, if the associations are handled very differently by the system
E.g. Flight Flies-to Airport and Flight Flies-from Airport
INFO 620
Lecture #4

28. Cleaning up Associations
In general, we may define associations conceptually that don’t get implemented, or may later find associations we missed here
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
INFO 620
Lecture #4

29. 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
INFO 620
Lecture #4

30. 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)
INFO 620
Lecture #4

31. The primitive data types are in bold; others are non-primitive
Attribute Types
Boolean (T/F)
Address
Color
Date
Zip/Postal Code
Shape
Number
Phone
UPC or EAN
String (Text)
SSN
SKU
Time
Money
Enumerated
The primitive data types are in bold; others are non-primitive
INFO 620
Lecture #4

32. 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
Don’t worry about “keys” for defining associations to other classes; focus only on the characteristics of each class
INFO 620
Lecture #4

33. Adding Attributes
If a potential attribute starts appearing complex, make it a separate class instead, and associate the two classes
Remember, this is an iterative process for finding attributes, so don’t be afraid to put down your best guess for now, and refine it later
When in doubt, make it a separate class
INFO 620
Lecture #4

34. Avoid Implementation
Don’t worry how the attributes will be implemented in source code
The focus is still on describing the problem domain
INFO 620
Lecture #4

35. Primitive vs Non-Primitive
Primitive data types are the most basic ways to represent data in a computer
Boolean, Date, Number, String, Time
Most complex data types are considered non-primitive
INFO 620
Lecture #4

36. Non-Primitive Data Types
Use non-primitive if any of the following guidelines apply (p. 171):
Data has separate sections (phone)
There are operations associated with it (SSN)
It needs other characteristics (start/end date)
It has units (height)
Or any other complex concept (UPC)
INFO 620
Lecture #4

37. Non-Primitive Data Types
So a credit card number could be a non-primitive data type, since it has
Type of card (Visa/MC/Discover)
Fixed length depending on type
Validation rules based on first digit
Non-primitive data can be shown as separate conceptual classes, or just flagged as specific data types
INFO 620
Lecture #4

38. Non-Primitive Data Types
Format:
The Class is called ProductSpecification.
One attribute is called ‘id’, which is of the non-primitive data type ‘ItemID’.
Can show the same thing this way:
INFO 620
Lecture #4

39. Attributes with Units
Things with units ($, ft., lb., etc.) need to be modeled with non-primitive data types
This helps support internationalization and conversion to other measurement systems (e.g. dollars to Euros, or English to SI units)
INFO 620
Lecture #4

40. Derived Attributes
Some attributes may be derived from other information from that class or classes with which it’s associated
Denote derived attributes with a slash in front of the attribute name
INFO 620
Lecture #4