information systems analysis and design class modeling
DESCRIPTION
Information Systems Analysis and Design Class Modeling. INFO 620 Glenn Booker. Operation vs Method vs Message. - PowerPoint PPT PresentationTRANSCRIPT
INFO 620 Lecture #4 1
Information Systems Analysis and DesignClass Modeling
INFO 620
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
Part of Fig. 10.1 Conceptual class diagram
-date-time
Sale-quantity
SalesLineItem
-amount
Payment
1
1
Paid-by
11..*Contained-in
Association
Conceptual class
Attribute
Multiplicity (discuss later)
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
-date-time
Sale
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. 134-135 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 arrow1 1Records-current >
-date-time
Sale
-date-time
Register
Fig. 11.2, p. 155
INFO 620 Lecture #4 21
Finding Associations
• Other than need-to-know basis, can find associations from the list on pp. 155-157– 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
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
-id:ItemID
ProductSpecification
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:
-id
ItemIDProductSpecification
1 1
-attribute:Data type
ClassName
Format:
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
-/quantity
SalesLineItemItem
0..1 1..*