Information Systems Analysis and Design Class Modeling

INFO 620 Lecture #4 1

Information Systems Analysis and DesignClass Modeling

INFO 620

Glenn Booker


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.


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’


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


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)


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


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)


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


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


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!


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?


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


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


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


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


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


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)


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


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


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


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


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


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


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


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


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


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


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


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


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)


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


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


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


Avoid Implementation

• Don’t worry how the attributes will be implemented in source code

• The focus is still on describing the problem domain


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


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)



• 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



-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:


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)


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..*

Documents

Information Systems Analysis and Design Class Modeling