Transcript Information Systems Analysis and Design Class Modeling INFO 620 Glenn Booker INFO 620 Lecture #4 Operation vs Method vs Message • Operation: A service that can be.

Information Systems Analysis
and Design
Class Modeling
INFO 620
Glenn Booker
INFO 620
Lecture #4
1
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
2
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
3
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
4
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
5
Conceptual Class Diagram
1..*
1 Contained-in
Sale
SalesLineItem
-quantity
-date
-time
Paid-by
1
Association
1
Multiplicity (discuss later)
Conceptual class
Payment
-amount
Attribute
Part of Fig. 10.1 Conceptual class diagram
INFO 620
Lecture #4
6
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
7
Formal Class Definition
• Each class has three ways of describing it
– Symbol which represents the class
Sale
-date
-time
– 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
8
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
9
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
10
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
11
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
12
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
13
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
14
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
15
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
16
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
17
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
18
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
19
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
Register
1
Records-current >
1
-date
-time
Sale
-date
-time
Fig. 11.2, p. 155
INFO 620
Lecture #4
20
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
21
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
22
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
23
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
24
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
25
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
26
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
27
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
28
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
29
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
30
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
31
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
32
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
33
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
34
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
35
Non-Primitive Data Types
• Use non-primitive if any of the following
guidelines apply (p. 171):
–
–
–
–
–
INFO 620
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)
Lecture #4
36
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
37
Non-Primitive Data Types
ProductSpecification
-id:ItemID
Format:
The Class is called ProductSpecification.
ClassName
-attribute:Data type
One attribute is called ‘id’, which is of the
non-primitive data type ‘ItemID’.
Can show the same thing this way:
1
ItemID
ProductSpecification
INFO 620
1
-id
Lecture #4
38
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
39
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
0..1
1..*
SalesLineItem
Item
-/quantity
INFO 620
Lecture #4
40