INFO 355 Week #3 1

Systems Analysis IIDomain Modeling

INFO 355Glenn Booker

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 355 Week #3 2

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 355 Week #3 3

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 355 Week #3 4

Attributes

Lots of nouns are attributes (data about something else)

Collect attributes with their noun owners

INFO 355 Week #3 5

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 355 Week #3 6

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 355 Week #3 7

INFO 355 Week #3 8

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)

INFO 355 Week #3 9

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

INFO 355 Week #3 10

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

INFO 355 Week #3 11

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

INFO 355 Week #3 12

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

INFO 355 Week #3 13

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

INFO 355 Week #3 14

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

INFO 355 Week #3 15

Types of Classes

For the conceptual class diagram, focus on data classes, and controller classes for significant use cases

Fill in the rest later

INFO 355 Week #3 16

Conceptual Class Diagram Excerpt

-date-time

Sale-quantity

SalesLineItem

-amount

Payment

1

1

Paid-by

11..*Contained-in

Association

Conceptual class

Attribute

Multiplicity (discuss later)

Association label

INFO 355 Week #3 17

Analogies to ERD

ERD has Class Diagram has

Entities Classes

Relationships Associations

Cardinality Multiplicity

Data elements or attributes or fields

Attributes

INFO 355 Week #3 18

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

INFO 355 Week #3 19

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

INFO 355 Week #3 20

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)

INFO 355 Week #3 21

Finding Classes

INFO 355 Week #3 22

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?

INFO 355 Week #3 23

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

INFO 355 Week #3 24

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

INFO 355 Week #3 25

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

INFO 355 Week #3 26

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)

INFO 355 Week #3 27

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 classor ProductSpecification

This is another design pattern

INFO 355 Week #3 28

Finding Associations

INFO 355 Week #3 29

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

INFO 355 Week #3 30

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

INFO 355 Week #3 31

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?)

INFO 355 Week #3 32

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

INFO 355 Week #3 33

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

1 1Records-current >

-date-time

Sale

-date-time

Register

Don’t need arrow if association is read left-right or top-bottom

INFO 355 Week #3 34

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

INFO 355 Week #3 35

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’

INFO 355 Week #3 36

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

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

INFO 355 Week #3 38

Cleaning up Associations

In general, we may define associations conceptually that don’t get implemented (used), or may later find associations we missed here

INFO 355 Week #3 39

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

INFO 355 Week #3 40

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

INFO 355 Week #3 41

Finding Attributes

INFO 355 Week #3 42

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 355 Week #3 43

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

INFO 355 Week #3 44

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

INFO 355 Week #3 45

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)

INFO 355 Week #3 46

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

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 355 Week #3 47

Generalization

Subclasses inherit attributes (and methods) from superclasses Inheritance is a key object oriented

concept

INFO 355 Week #3 48