Transcript Week #3

Systems Analysis II
Domain Modeling
INFO 355
Glenn Booker
INFO 355
Week #3
1
Problem Domain

Based on the requirements (use
cases), we can start to identify the
problem domain



INFO 355
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
2
Things

Things such as






INFO 355
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
3
Nouns

Or the domain might include more
general nouns





INFO 355
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
4
Attributes


INFO 355
Lots of nouns are attributes (data
about something else)
Collect attributes with their noun
owners
Week #3
5
ERD

One way to model the domain of a
system is the entity relationship
diagram


INFO 355
But you had this in INFO 200
So instead we’ll focus on the
domain model class diagram
Week #3
6
Class Diagram

The class diagram goes through
several stages of development in
object-oriented modeling



INFO 355
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
7
Purpose of Class Diagram

The Class Diagram shows many
key characteristics of the system




INFO 355
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
8
Class Diagram Evolves

The class diagram evolves as a
system is analyzed


INFO 355
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
9
Types of Classes

It often helps to think of three types
of classes



INFO 355
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
10
Types of Classes

Another set of terms for the same
concept is Model-View-Controller




INFO 355
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
11
Classes versus Objects



INFO 355
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
12
The Conceptual Class Diagram

To define the conceptual class
diagram, we’ll need to determine

Classes


Associations


INFO 355
Primarily data and major control classes
Including label and multiplicity
Attributes
Week #3
13
Conceptual Class Diagram



INFO 355
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
14
Types of Classes


INFO 355
For the conceptual class diagram,
focus on data classes, and controller
classes for significant use cases
Fill in the rest later
Week #3
15
Conceptual Class Diagram Excerpt
1..*
1 Contained-in
Sale
SalesLineItem
-quantity
-date
-time
Paid-by
Association label
1
Association
1
Multiplicity (discuss later)
Conceptual class
Payment
-amount
INFO 355
Attribute
Week #3
16
Analogies to ERD
ERD has
INFO 355
Class Diagram has
Entities
Classes
Relationships
Associations
Cardinality
Multiplicity
Data elements or
attributes or fields
Attributes
Week #3
17
Analogies to ERD


INFO 355
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
18
Class Naming Conventions


INFO 355
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
19
Class Naming Conventions

Capitalization conventions:



INFO 355
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
20
Finding Classes
INFO 355
Week #3
21
Identifying Classes

Use the use case scenarios for
finding conceptual classes – look for
noun phrases, then evaluate them


INFO 355
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
22
Identifying Classes

Consider the possibility that classes
can have other classes within them


INFO 355
A single Sale can have many entries,
each of which is a SalesLineItem
A ComputerSystem can have many
ComputerParts
Week #3
23
Identifying Classes

Notice that classes can be actions,
transactions, or events, like


INFO 355
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
24
Identifying Classes

Use terminology for class names
which is native to the system’s
environment



Omit things which aren’t relevant to
meeting the system’s requirements
If in doubt, make it a separate class

INFO 355
Don’t make the customer learn new
words for old ideas
Then see if it’s needed later
Week #3
25
Identifying Classes


People’s roles might be classes
Does the type of user require a
separate class, or is it just an
attribute?

INFO 355
Might need a class if the user type
affects what data are needed
(attributes) or functions can be
performed (methods)
Week #3
26
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
INFO 355
Week #3
27
Finding Associations
INFO 355
Week #3
28
Adding Associations


INFO 355
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
29
Adding Associations


INFO 355
Associations imply a relationship
which may be kept for a second,
or forever
Associations are often from a needto-know basis – e.g. we ‘need to
know’ what line items were
associated with a given sale
Week #3
30
Adding Associations

Associations are generally needed
to trace data


INFO 355
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
31
Adding Associations

For a conceptual model with ‘n’
classes, there can be n*(n-1)
possible associations


Associations are assumed
bidirectional for now – information
can go both directions

INFO 355
You need to determine: which
associations are significant?
We’ll refine this later
Week #3
32
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 >
-date
-time
1
Sale
-date
-time
Don’t need arrow if association is read left-right or top-bottom
INFO 355
Week #3
33
Finding Associations

Most common association types are




Classes are more critical to identify
than associations
Avoid too many associations

INFO 355
Physical or logical types (e.g. Register
is physically located in Store)
When information is stored, recorded
or captured (Register reports Sale)
But at least one per class
Week #3
34
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):

INFO 355
‘a, b, c’ means only a, b, and c are
allowable values, e.g. ‘2, 5, 7’
Week #3
35
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

INFO 355
If your system will never handle the
case of 0 multiplicity, don’t need 0
to show in the domain model
Week #3
36
Multiple Associations

It is possible to show two
associations between the same
two classes, if the associations
are handled very differently by
the system

INFO 355
E.g. Flight Flies-to Airport and
Flight Flies-from Airport
Week #3
37
Cleaning up Associations

INFO 355
In general, we may define
associations conceptually that
don’t get implemented (used),
or may later find associations
we missed here
Week #3
38
Cleaning up Associations

Whether an association is needed
depends heavily on the system’s
requirements

INFO 355
“Sale Initiated-by Customer” may be
trivial for a gas station, but important
for a grocery store which analyzes its
regular customers
Week #3
39
Cleaning up Associations

OTOH, might want to keep
associations which reveal key
information about the problem,
even though we may never
implement them


INFO 355
“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
40
Finding Attributes
INFO 355
Week #3
41
Adding Attributes



INFO 355
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
42
Adding Attributes

Key to finding good attributes
is to make sure each one is


INFO 355
A simple characteristic
Which is uniquely defined by the
class to which it belongs
Week #3
43
Adding Attributes



INFO 355
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
44
Primitive vs. Non-Primitive Data

Primitive data types are the most
basic ways to represent data in a
computer





INFO 355
Boolean (True/False, Yes/No, 0/1)
Number (integer or real)
String (text)
Date
Time (may be merged with Date)
Week #3
45
Primitive vs. Non-Primitive Data

Most complex data types are
considered non-primitive


INFO 355
Phone number, SSN, money, etc.
are all non-primitive
We’ll discuss non-primitive data
types next week
Week #3
46
Generalization

We saw generalization in the use
case diagram



INFO 355
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
47
Generalization

Subclasses inherit attributes (and
methods) from superclasses

INFO 355
Inheritance is a key object oriented
concept
Week #3
48