Chapter 5-D – System Modeling

{Structure Models/ UML Class Diagram}

Instructor: Dr. Murad Al-Rajab

Chapter 5 System Modeling 1

Topics covered

 Understand the rules and style guidelines for class diagrams.

 Understand the processes used to make class diagrams.
 Be able to make class diagrams.
 Understand the relationship among the structural models.

In many cases, the UML diagrams simply replace the older structured
techniques (e.g., class diagrams replace ERD diagrams)

Chapter 5 System Modeling 2

Introduction

 During analysis, software engineers build business process and functional

models to represent how the business system will behave.
 At the same time, software engineers need to understand the information
that is used and generated by the business system (e.g., customer
information, order information).
 In this chapter, we discuss how the objects underlying the behavior modeled
in the business process and functional models are organized and presented.

Chapter 5 System Modeling 3

Structural models

 Structural models of software display the organization of a system in terms of

the components that make up that system and their relationships.
 Main goal: to discover the key data contained in the problem domain and to
build a structural model of the objects

Chapter 5 System Modeling 4

Introduction (Cont.)

 A structural model is a formal way of representing the objects that are used
and created by a business system. It illustrates people, places, or things
about which information is captured and how they are related to one another.
 The structural model is drawn using an iterative process in which the model
becomes more detailed and less conceptual over time.
 By building a structural model of the problem domain, the software engineer
creates the vocabulary necessary for the software engineer and users to
communicate effectively.

Chapter 5 System Modeling 5

Classes, Attributes, and Operations

 A class is a general template that we use to create specific instances, or

objects, in the problem domain.
 All objects of a given class are identical in structure and behavior but contain
different data in their attributes.

 Classes
•Templates for instances of people, places, or
things
 Attributes
•Properties that describe the state of an instance
of a class (an object)
 Operations
•Actions or functions that a class can perform

Chapter 5 System Modeling 6

Classes, Attributes, and Operations

 An attribute of an analysis class represents a piece of information that is

relevant to the description of the class within the application domain of the
problem being investigated.
 An attribute contains information the software engineer or user feels the
system should keep track of.
 For example, a possible relevant attribute of an employee class is employee
name, whereas one that might not be as relevant is hair color. Both describe
something about an employee, but hair color is probably not all that useful
for most business applications.
 Only attributes that are important to the task should be included in the class.
Finally, only attributes that are primitive or atomic types (i.e., integers,
strings, doubles, date, time, Boolean, etc.) should be added. Most complex
or compound attributes are really placeholders for relationships between
classes. Therefore, they should be modeled as relationships, not as
attributes.

Chapter 5 System Modeling 7

Classes, Attributes, and Operations

 Attributes are properties of the class about which we want to capture

information.
 Operations are actions or functions that a class can perform.
 There are three kinds of operations: constructor, query, and update.
 Associations represent the relationships that classes have with one
another.
 Associations also have multiplicity, which shows how an instance of
an object can be associated with other instances.

Chapter 5 System Modeling 8

Classes, Attributes, and Operations

 The behavior of an analysis class is defined in an operation or service. In

later phases, the operations are converted to methods.
 Like attributes, only problem domain–specific operations that are relevant to
the problem being investigated should be considered.
 For example, it is normally required that classes provide means of making
instances, deleting instances, accessing individual attribute values, setting
individual attribute values, accessing individual relationship values, and
removing individual relationship values. However, at this point in the
development of the evolving system, the software engineers should avoid
cluttering up the definition of the class with these basic types of operations
and focus only on relevant problem domain–specific operations.

Chapter 5 System Modeling 9

Relationships

 Describe how classes relate to one another

 There are many different types of relationships that can be defined, but all
can be classified into three basic categories: generalization relationships,
aggregation relationships, and association relationships.
 Generalization Relationships enables the software engineer to build
classes that inherit attributes and operations of other classes. The software
engineer makes a superclass that contains basic attributes and operations
that will be used in several subclasses. The subclasses inherit the attributes
and operations of their superclass and can also contain attributes and
operations that are unique just to them. For example, a customer class and
an employee class can be generalized into a person class by extracting the
attributes and operations both have in common and placing them into the
new superclass, person.
 Generalization is represented with the a-kind-of relationship, so that we say
that an employee is a-kind-of person.

Chapter 5 System Modeling 10

Relationships (Cont.)

 Aggregation Relationships Generally speaking, all aggregation

relationships relate parts to wholes or assemblies. For our purposes, we use
the a-part-of or has-parts semantic relationship to represent the aggregation
abstraction. For example, a door is a-part-of a car, an employee is a-part-of a
department, or a department is a-part-of an organization. Like the
generalization relationship, aggregation relationships can be combined into
aggregation hierarchies. For example, a piston is a-part-of an engine, and an
engine is a-part-of a car.
 Association Relationships There are other types of relationships that do
not fit neatly into a generalization (a-kind-of) or aggregation (a-part-of)
framework. Technically speaking, these relationships are usually a weaker
form of the aggregation relationship. For example, a patient schedules an
appointment.

Chapter 5 System Modeling 11

Classes

 A class represents a concept

 A class encapsulates state (attributes) and behavior (operations)
 Each attribute has a type
 Each operation has a signature
 The class name is the only mandatory information

Type
TarifSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)

TarifSchedule
zone2price Attributes Signature
getZones()
getPrice()
Operations TarifSchedule

Chapter 5 System Modeling 12

Object Identification

 Different approaches have been suggested to aid the software engineer in

identifying a set of candidate objects for the structural model. The four most
common approaches are textual analysis, brainstorming, common object
lists, and patterns.
 Most software engineers use a combination of these techniques to make
sure that no important objects and object attributes, operations, and
relationships have been overlooked (ignored).

Chapter 5 System Modeling 13

Textual Analysis (noun-verb analysis)

 The software engineer performs textual analysis by reviewing the use-case

diagrams and examining the text in the use-case descriptions to identify
potential objects, attributes, operations, and relationships.
 The nouns in the use case suggest possible classes, and the verbs
suggest possible operations.

Chapter 5 System Modeling 14

Mapping Parts of Speech to Object Model Components

Chapter 5 System Modeling 15

15
Textual Analysis (Example)

Chapter 5 System Modeling 16

16
Textual Analysis (Example)

 For example, if we applied Text Analysis rules to the Make Old Patient Appt
use case described in the previous slide figure, we can easily identify
potential objects for an old patient, doctor, appointment, patient, office,
receptionist, name, address, patient information, payment, date, and time
 We also can easily identify potential operations that can be associated with
the identified objects. For example, patient contacts office, makes a new
appointment, cancels an existing appointment, changes an existing
appointment, matches requested appointment times and dates with
requested times and dates, and finds current appointment.

Chapter 5 System Modeling 17

Brainstorming —people offering ideas

 Brainstorming is a discovery technique that has been used successfully in

identifying candidate classes. Essentially, in this context, brainstorming is a
process that a set of individuals sitting around a table suggest potential
classes that could be useful for the problem under consideration.
 Typically, a brainstorming session is kicked off by a facilitator who asks the
set of individuals to address a specific question or statement that frames the
session.
 For example, using the appointment problem described previously, the
facilitator could ask the development team and users to think about their
experiences of making appointments and to identify candidate classes based
on their past experiences.

Chapter 5 System Modeling 18

Common Object Lists

 As its name implies, a common object list is simply a list of objects common to the
business domain of the system.
 Several categories of objects have been found to help the software engineer in making
the list, such as physical or tangible things, incidents, roles, and interactions.
 Software Engineers should first look for physical, or tangible, things in the business
domain. These could include books, desks, chairs, and office equipment. Normally,
these types of objects are the easiest to identify. Incidents are events that occur in the
business domain, such as meetings, flights, performances, or accidents.
 Reviewing the use cases can readily identify the roles that the people play in the
problem, such as doctor, nurse, patient, or receptionist.
 Other types of objects that can be identified include places, containers, organizations,
business records, catalogs, and policies.
 Finally, there are libraries of reusable objects that have been generated for different
business domains. For example, with regard to the appointment problem, the
Common Open Source Medical Objects could be useful to investigate for potential
objects that should be included. (See Common Open Source Medical Objects, Sourceforge,
sourceforge.net/projects/cosmos/.)
Chapter 5 System Modeling 19
Class Diagrams

 Class diagrams represent the structure of the system in terms of classes and
objects
 It is used as a basis for implementation, testing, and maintenance.
 The class diagram is a static model shows the classes and the relationships
among the classes that remain constant in the system over time.
 Elements of diagram include:
• Classes
• Attributes
• Methods
• Associations (Relationships)
 Class is the main building block of a class diagram, which stores and
manages information in the system. During analysis, classes refer to the
people, places, events, and things about which the system will capture
information. Later, during design and implementation, classes can refer to
implementation-specific artifacts such as windows, forms, and other objects
Chapter 5 System Modeling 20
used to build the system
Elements of a Class Diagram

Chapter 5 System Modeling 21

Class Diagram Syntax

Chapter 5 System Modeling 22

Class Diagram Syntax (Cont.)

Chapter 5 System Modeling 23

Elements of a Class Diagram (Cont.)

 Class The main building block of a class diagram is the class, which stores and
manages information in the system.
 Each class is drawn using a three part rectangle, with the class’s name at the top,
attributes in the middle, and operations at the bottom. We can see that the classes
identified earlier, such as Participant, Doctor, Patient, Receptionist, Medical History,
Appointment, and Symptom.
 The attributes of a class and their values define the state of each object created from
the class, and the behavior is represented by the operations.
 Attributes are properties of the class about which we want to capture information.
 At times, you might want to store derived attributes, which are attributes that can be
calculated or derived; these special attributes are denoted by placing a slash (/) before
the attribute’s name, e.g., age is derived from date of birth
 It is also possible to show the visibility of the attribute on the diagram. Visibility relates
to the level of information hiding to be enforced for the attribute. The visibility of an
attribute can be public (+), protected (#), or private (−).

Chapter 5 System Modeling 24

Elements of a Class Diagram (Cont.)

 Operations are actions or functions that a class can perform.

 The functions that are available to all classes (e.g., create a new instance,
return a value for a particular attribute, set a value for a particular attribute,
delete an instance) are not explicitly shown within the class rectangle.
Instead, only operations unique to the class are included, such as the cancel
without notice operation in the Appointment class and the calculate last visit
operation in the Patient class.
 Notice that both the operations are followed by parentheses, which contain
the parameter(s) needed by the operation. If an operation has no
parameters, the parentheses are still shown but are empty. As with
attributes, the visibility of an operation can be designated public, protected,
or private. The default visibility for an operation is normally public.

Chapter 5 System Modeling 25

Elements of a Class Diagram (Cont.)

 Relationships A primary purpose of a class diagram is to show the

relationships, or associations, that classes have with one another. These are
depicted on the diagram by drawing lines between classes.
 When multiple classes share a relationship (or a class shares a relationship
with itself), a line is drawn and labeled with either the name of the
relationship or the roles that the classes play in the relationship.
 For example, the two classes patient and appointment are associated with
one another whenever a patient schedules an appointment. Thus, a line
labeled schedules connects patient and appointment, representing exactly
how the two classes are related to each other.
 Also, notice that there is a small solid triangle beside the name of the
relationship. The triangle allows a direction to be associated with the name of
the relationship. For example, the schedules relationship includes a triangle,
indicating that the relationship is to be read as “patient schedules
appointment.”

Chapter 5 System Modeling 26

Elements of a Class Diagram (Cont.)

 Relationships also have multiplicity, which documents how an instance of an object

can be associated with other instances. Numbers are placed on the association path
to denote the minimum and maximum instances that can be related through the
association in the format minimum number.. maximum number

Chapter 5 System Modeling 27

Elements of a Class Diagram (Cont.)

 Generalization and Aggregation Associations

 A generalization association shows that one class (subclass) inherits from another
class (superclass), meaning that the properties and operations of the superclass
are also valid for objects of the subclass. The generalization path is shown with a
solid line from the subclass to the superclass and a hollow arrow pointing at the
superclass. For example, doctors, nurses, and receptionists are all kinds of
employees and those employees and patients are kinds of participants. Remember
that the generalization relationship occurs when you need to use words like “is a
kind of” to describe the relationship.
 An aggregation association is used when classes actually comprise other classes.
For example, think about a doctor’s office that has decided to create health care
teams that include doctors, nurses, and administrative personnel. As patients enter
the office, they are assigned to a health care team, which cares for their needs
during their visits.

Chapter 5 System Modeling 28

A generalization association

Chapter 5 System Modeling 29

A generalization hierarchy with added detail

30/10/2014 Chapter 5 System Modeling 30

Elements of a Class Diagram (Cont.)

 A diamond is placed nearest the

class representing the aggregation
(Department), and lines are drawn
from the diamond to connect the
classes that serve as its parts
(Employee). Typically, you can
identify these kinds of associations
when you need to use words like
“is a part of” or “is made up of” to
describe the relationship.
 Aggregation is depicted on a UML
class diagram by a hollow or white
diamond.

Chapter 5 System Modeling 31

Making Class Diagrams

 Making a structural model is an incremental and iterative process whereby the

software engineer makes a rough cut of the model and then refines it over time.
 It is important to remember that class diagrams can be used to describe both the as-is
and to-be structural models of the evolving system, but they are most often used for
the to-be model.
 In this section, we describe a use-case–driven process that can be used to generate
the structural model of a problem domain.
 As a general rule, attributes are private and operations are public.

 Steps in building a class diagram:

1. Identify classes.
2. Identify attributes and operations.
3. Draw associations between the classes.

Chapter 5 System Modeling 32

Campus Housing Example

 In the previous chapter, we identified a set of use cases (Add an Apartment, Delete an
Apartment, and Search Available Rental Units) for the campus housing service that
helps students find apartments. By reviewing the use cases, we can easily determine
that the campus housing service must keep track of information for each available
apartment and its owner. The information to be captured for each apartment is the
location of the apartment, the number of bedrooms in the apartment, the monthly rent,
and how far the apartment is from the campus. Regarding the owner of the apartment,
we need to capture the owner’s contact information (e.g., name, address, phone
number, e-mail address). Since students are simply users of the system, there is no
need to capture any information regarding them; that is, in this case, students are
simply actors. Finally, with regards to relationships among the classes, there is a
single, optional, one to many association relationship that links the two classes
together.

owns

Chapter 5 System Modeling 33

Sales Order Class Diagram

 Class diagram for a sales

order use case (attributes
and methods omitted for
clarity).
 Notice that the sales office
has one sales manager
who can have anywhere
from zero to many sales
rep.
 Each sales rep can have
anywhere from zero to
many customers, but each
customer has only one
sales rep

Chapter 5 System Modeling 34

A Library Example

 The library contains books and journals. It may have several copies of a
given book. Some of the books are reserved for short-term loans only.
All others may be borrowed by any library member for three weeks.
Members of the library can normally borrow up to six items at a time, but
members of staff may borrow up to 12 items at one time. Only members
of staff may borrow journals.
 The system must keep track of when books and journals are borrowed and
returned and enforce the rules.

Chapter 5 System Modeling 35

A Library Example (Candidate Classes)

Chapter 5 System Modeling 36

Relations between Classes

Chapter 5 System Modeling 37

Methods

Chapter 5 System Modeling 38

A Possible Class Diagram

Chapter 5 System Modeling 39

 What to include in your Project from this chapter
Phase 3.

 In this phase, you will make the analysis object model and dynamic model of the
system you proposed in Phase1 and 2. Make the following diagram.

1) Class Diagram:
 Based on the use cases and problem statement you created in Phase 2, build a class
diagram to represent the entity, boundary, and control object types. Also show
relationships with multiplicities between the object types.

Chapter 5 System Modeling 40

References

 Software Engineering, 10th Edition, Ian Sommerville

 Systems analysis and design, 6th Edition, Dennis, wixom, and roth
 Systems analysis and design with UML Version 2.0, 3rd Edition, Dennis,
wixom, and Tegarden

Chapter 5 System Modeling 41