Software Engineering

Modeling

© 2024 Dr. Omar Janeh

University of Technology | Computer Engineering Department
What is Modeling?
● Modeling consists of building an abstraction of reality.
● Abstractions are simplifications because:
○ They ignore irrelevant details and
○ They only represent the relevant details.
● What is relevant or irrelevant depends on the purpose of the model.
Example: University of Technology Map
Why Model Software?
● Software is getting increasingly more complex.
○ Windows XP > 40 millions of lines of code.
○ A single programmer cannot manage this amount of code in its entirety.
● Code is not easily understandable by developers who did not write it.
○ We need simpler representations for complex systems.
● Modeling is a mean for dealing with complexity.
Software Design vs. Modeling?
● Design is the process of defining software methods, functions, objects, and the
overall structure and interaction of your code so that the resulting functionality
will satisfy your users requirements.
● Modeling should address the entire software design including interfaces,
interactions with other software, and all the software methods.
● For object-oriented software, an object modeling language such as Unified
Modeling Language (UML) is used to develop and express the software
design.
○ This allows the designer to try different designs and decide which will be best for the final
solution.
○ You will continue to modify your drawings until you arrive at a design that meets all your
requirements. Only then should you start cutting boards or writing code.
○ The benefit of designing your software using UML is that you discover problems early and fix
them without refactoring your code.
What is UML?
● The Unified Modeling Language (UML) was created to forge a common,
semantically and syntactically rich visual modeling language for the
architecture, design, and implementation of complex software systems
both structurally and behaviorally. UML has applications beyond software
development, such as process flow in manufacturing.
● It is analogous to the blueprints used in other fields, and consists of
different types of diagrams. In the aggregate, UML diagrams describe the
boundary, structure, and the behavior of the system and the objects
within it.
● UML is not a programming language but there are tools that can be used
to generate code in various languages using UML diagrams. UML has a
direct relation with object-oriented analysis and design.

https://www.lucidchart.com/pages/what-is-UML-unified-modeling-language
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/
Types of UML Diagrams
● Use Case Diagram
○ Describe the functional behavior of the
system as seen by the user.
● Class Diagram
○ Describe the static structure of the system:
Objects, Attributes, Associations.
○ These are only a subset of diagrams, but are
most widely used.
Use Case Diagram
● Used for describing a set of user scenarios.
● Mainly used for capturing user requirements.
● Work like a contract between end user and software developers.
● The use case diagram is used during the entire analysis and design
process.
● We can use a use case diagram to answer the following questions:
○ What is being described? (The system)
○ Who interacts with the system? (The actors)
○ What can the actors do? (The use cases)
Example: Student Administration System
● System (what is being described?)
○ Student administration system
● Actors (who interacts with the system?)
○ Professor
● Use cases (what can the actors do?)
○ Query student data
○ Issue certificate
○ Announce exam
Use Case
● Describes functionality expected from the system under development.
● Provides tangible benefit for one or more actors that communicate with
this use case.
● Derived from collected customer wishes.
● Set of all use cases describes the functionality that a system shall provide.
● Documents the functionality that a system offers.
● Alternative notations:
Actor (1/3)
● Actors interact with the system:
○ by using use cases (i.e., the actors initiate the execution of use cases).
○ by being used by use cases (i.e., the actors provide functionality for the execution of use
cases).
● Actors represent roles that users adopt.
○ Specific users can adopt and set aside multiple roles simultaneously.
● Actors are not part of the system (i.e., they are outside of the system
boundaries)
● Alternative notations:
Actor (2/3)
● Usually, user data is also administered within the system.
● This data is modeled within the system in the form of objects and classes.
● Example: actor Assistant
○ The actor Assistant interacts with the system Laboratory Assignment by using it.
○ The class Assistant describes objects representing user data (e.g., name, role, etc.).
Actor (3/3) Human
Primary
Active
● Human
○ E.g., Student, Professor Human
● Non-human Secondary
Active
○ E.g., E-Mail Server
● Primary: has the main benefit of the
execution of the use case Human
Primary
● Secondary: receives no direct benefit Active

● Active: initiates the execution of the use

case
Passive: provides functionality for the
Non-human
● Secondary
execution of the use case Passive
Relationships between Use Cases and Actors
● Actors are connected with use cases via solid lines (associations).
● Every actor must communicate with at least one use case.
● An association is always binary.
● Multiplicities may be specified.
Relationships between Use Cases
● The behavior of one use case (included use case) is integrated in the
behavior of another use case (base use case)
Base use case
requires the behavior of the included use case
to be able to offer its functionality

Included use case

maybe executed on its own

● Example
Relationships between Use Cases (1/3)
● The behavior of one use case (extending use case) may be integrated in the behavior of
another use case (base use case) but does not have to.
● Both use cases may also be executed independently of each other

Base use case

Extending use case

● A decides if B is executed.
● Extension points define at which point the behavior is integrated.
● Conditions define under which circumstances the behavior is integrated.
Relationships between Use Cases (2/3)
● Extension points are written directly within the use case.
● Specification of multiple extension points is possible.
● Example:
Relationships between Use Cases (3/3)
● Use case A generalizes use case B. Base use case

● B inherits the behavior of A and may

● either extend or overwrite it.
● B also inherits all relationships from A.
Sub use case
● B adopts the basic functionality of A but
● decides itself what part of A is executed or changed.
● A may be labeled {abstract}
○ Cannot be executed directly
○ Only B is executable
Relationships between Actors
● Actor A inherits from actor B Super-actor
● A can communicate with X and Y
● B can only communicate with Y
● Multiple inheritance is permitted Sub-actor
● Abstract actors are possible

● Example:

Professor AND Assistant needed Professor OR Assistant needed

for executing Query student data for executing Query student data
Best Practices «include»
UML standard Best practice
Best Practices «extend»
UML standard Best practice
Best Practices -Identifying Actors
● What are the main tasks that an actor must perform?
● Does an actor want to query or even modify information contained in the
system?
● Does an actor want to inform the system about changes in other systems?
● Should an actor be informed about unexpected events within the system?
Best Practices -Identifying Use Cases
● Who uses the main use cases?
● Who needs support for their daily work?
● Who is responsible for system administration?
● What are the external devices/(software) systems with which the system
must communicate?
● Who is interested in the results of the system?
Typical Errors To Avoid (1/5)
● Use case diagrams do not model processes/workflows!
Typical Errors To Avoid (2/5)
● Actors are not part of the system; hence, they are positioned outside the
system boundaries!
Typical Errors To Avoid (3/5)
● Use case Issue information needs EITHER one actor Assistant OR one
actor Professor for execution

✔
Typical Errors To Avoid (4/5)
● Many small use cases that have the same objective may be grouped to
form one use case.

✔
Typical Errors To Avoid (5/5)
● The various steps are part of the use cases, not separate use cases
themselves! -> NO functional decomposition.

✔
Example
● Create a use case diagram that describes the functionality of the information
system of a student office in accordance with the following Scenario:
○ Many important administrative activities of a university are processed by the student office.
Students can register for studies (matriculation), enroll, and withdraw from studies here.
Matriculation involves enrolling, that is, registering for studies.
○ Students receive their certificates from the student office. The certificates are printed out by an
employee. Lecturers send grading information to the student office. The notification system then
informs the students automatically that a certificate has been issued.
○ There is a differentiation between two types of employees in the student office: a) those that are
exclusively occupied with the administration of student data (service employee, or ServEmp), and
b) those that fulfill the remaining tasks (administration employee, or AdminEmp), whereas all
employees (ServEmp and AdminEmp) can issue information.
○ Administration employees issue certificates when the students come to collect them.
Administration employees also create courses. When creating courses, they can reserve lecture
halls.
Create a Use Case diagram
● identify the actors and their relationships to one another.
● determine the use cases and their relationships to one another.
● associate the actors with their use cases.
Identifying Actors
● Many important administrative activities of a university are processed by the student office.
Students can register for studies (matriculation), enroll, and withdraw from studies here.
Matriculation involves enrolling, that is, registering for studies.

● Students receive their certificates from the student office. The certificates are printed out by an
employee. Lecturers send grading information to the student office. The notification system then
informs the students automatically that a certificate has been issued.

● There is a differentiation between two types of employees in the student office: a) those that are
exclusively occupied with the administration of student data (service employee, or ServEmp), and b)
those that fulfill the remaining tasks (administration employee, or AdminEmp), whereas all
employees (ServEmp and AdminEmp) can issue information.

● Administration employees issue certificates when the students come to collect them. Administration
employees also create courses. When creating courses, they can reserve lecture halls.
Identified Actors
Identifying Use Cases
● Many important administrative activities of a university are processed by the student office.
Students can register for studies (matriculation), enroll, and withdraw from studies here.
Matriculation involves enrolling, that is, registering for studies.

● Students receive their certificates from the student office. The certificates are printed out by an
employee. Lecturers send grading information to the student office. The notification system then
informs the students automatically that a certificate has been issued.

● There is a differentiation between two types of employees in the student office: a) those that are
exclusively occupied with the administration of student data (service employee, or ServEmp), and b)
those that fulfill the remaining tasks (administration employee, or AdminEmp), whereas all
employees (ServEmp and AdminEmp) can issue information.

● Administration employees issue certificates when the students come to collect them. Administration
employees also create courses. When creating courses, they can reserve lecture halls.
Identified Use Cases
Identified Associations
Notation Elements (1/2)
Name Notation Description

Boundaries between the system

System
and the users of the system

Use case Unit of functionality of the system

Actor Role of the users of the system

Notation Elements (2/2)
Name Notation Description
Relationship between use cases
Association
and actors
Inheritance relationship
Generalization
between actors or use cases
Extend B extends A: optional use of use
relationship case B by use case A
A includes B: required use of
Include
use
relationship
case B by use case A
Class Diagram
● The class diagram is a central modeling technique that runs through
nearly all object-oriented methods. This diagram describes the types of
objects in the system and various kinds of static relationships which exist
between them.
● Relationships: There are three principal kinds of relationships which are
important:
○ Association: represent relationships between instances of types (a person works for a
company; a company has a number of offices.
○ Inheritance: the most obvious addition to ER diagrams for use in OO. It has an
immediate correspondence to inheritance in OO design.
○ Aggregation: Aggregation, a form of object composition in object-oriented design.
Class

Class name

Attributes

Operations
 Class Variables & Class Operations
class Person {

public String firstName;

public String lastName;
private Date dob;
Class variable protected String[] address;
private static int pNumber;
public static int getPNumber() {…}
public Date getDob() {…}
}
Class operation
Specification of Classes: Different Levels of Detail
coarse-grained fine-grained
Generalization Relationships (inheritance)
● A class (the “subtype”) is considered to be a specialized form of another
class (the “supertype”) or, alternatively, the supertype is a generalization
of the subtype if:
○ conceptual: all instances of the subtype are also instances of the supertype
○ specification: the interface of the subtype contains all elements of the interface of the
supertype
○ The subtype interface is said to conform to the interface of the supertype
○ implementation: the subtype inherits all attributes and operations of the supertype

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Diagramming Generalization
● The UML symbol for this relationship is
an arrow with an unfilled, triangular
head.
● Read this arrow as “is a specialization
of”, “is a kind of”, or “is a”. (The latter
can be a bit ambiguous however, as we
might also say that Webster’s Dictionary
“is a” Book, but that’s not a
generalization relationship.
● We infer from the relationship that
books and magazines have titles and
dates of publication and that we can get
their content. However, not all
publications have ISBNs.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Multiple Specializations
● Some classes may participate in
multiple generalization
relationships. The arrows are
grouped together to indicate
related, mutually exclusive,
divisions:

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Association
● An association is any kind of relationship between instances of classes.
○ Generalization is not an association because it is a relation between the classes
themselves, not between their instances (objects).
● In a conceptual perspective, associations represent general relationships.
In a specification perspective, associations often denote responsibilities.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Diagramming Associations
● Associations are shown as lines connecting classes.
○ Plain associations like these are not particularly useful.
○ This one tells us, for example, that some spreadsheets have some kind of relationship
with some cells.
■ Only in very rare circumstances would that be a useful insight into the author’s
understanding of the spreadsheet world.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Decorations
● We make the associations meaningful by attaching various decorations.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Relationship Names
● Most important of these are the decorations that name the relationship
being shown.
○ Names: Names of relationships are written in the middle of the association line.
○ Good relation names make sense when you read them out loud:
■ “Every spreadsheet contains some number of cells”,
■ “an expression evaluates to a value”
○ They often have a small arrowhead to show the direction in which direction to read the
relationship, e.g., expressions evaluate to values, but values do not evaluate to
expressions.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Roles
● Roles: a role is a directional purpose of an association.
● Roles are written at the ends of an association line and describe the
purpose played by the associated class in the relationship.
○ E.g., A cell is related to an expression. The nature of the relationship is that the expression
is the formula of the cell.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Roles and Attributes
● In a specification or implementation perspective, roles often correspond
to attribute names. These two representations are, in a sense, equivalent.
○ If we have conventions for naming attribute retrieval functions (e.g., get/set) , we can infer
those from the role name.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Multiplicity
● Multiplicity indicates how many instances of a class participate in the
relationship.
● Multiplicity is encoded as:
○ k: Exactly k instances (where k is an integer or a known constant)
○ k..m: Some value in the range from k to m (inclusive)
○ *: Denotes the range 0..infinity. Can also be used on the upper end of a “..”, e.g., 1..*
means “at least one”.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Diagramming Multiplicity
● This diagram above indicates that:
○ Each spreadsheet contains any number of cells, but that
○ A cell is contained within exactly one spreadsheet.
○ Each cell contains exactly one expression and one value, and these values and
expressions are not shared with other cells.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Navigability
● Navigability arrows indicate whether, given
one instance participating in a relationship,
it is possible to determine the instances of
the other class that are related to it.
● The diagram above suggests that,
● given a spreadsheet, we can locate all of the
cells that it contains, but that
● we cannot determine from a cell in what
spreadsheet it is contained.
● Given a cell, we can obtain the related
expression and value, but
● given a value (or expression) we cannot find
the cell of which those are attributes.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Aggregation
● Denoted by an arrowhead drawn as an unfilled diamond, aggregation can
be read as “is part of” or, in the opposite direction as “has a”.
● This diagram suggests that cells are part of a spreadsheet and that an
expression and a value are each part of a cell.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Aggregation Details
● The multiplicity at the arrowhead defaults to “1”.
● Aggregation is almost never named and roles are only used if the
attribute name would be unexpected.
● There is a lot of variation in deciding when to use use aggregation.
○ For example, experts might disagree on whether a Library can be represented as an
aggregate of its Librarians and of its Patrons.
○ I recommend reading your suggested aggregations, out loud, as “is part of” and asking
yourself whether they make sense.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Composition
● Composition is stronger form of aggregation. It implies that the “lifetime”
of the parts is bound to the lifetime of the whole.
○ The usual test to see if composition applies is to ask, “if I delete/destroy the container, do
the parts go away as well?”
○ Composition is denoted by an arrowhead drawn as a filled-in diamond.

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
 Composition Example
● This diagram suggests that destroying a cell would also destroy its value
and formula. That makes sense if the cell does not share those
components with other objects.
● However, destroying a spreadsheet does not necessarily destroy its cells.
○ (We can infer that because, if the cells have been cut or copied to the clipboard, the
spreadsheet could be destroyed and yet the cells would remain available for pasting into
some other spreadsheet.)

https://www.cs.odu.edu/~zeil/cs330/latest/Public/classDiagrams/index.html
Example: University Information System
● A university consists of multiple faculties which are composed of various
institutes. Each faculty and each institute has a name. An address is known for
each institute.
● Each faculty is led by a dean, who is an employee of the university.
● The total number of employees is known. Employees have a social security
number, a name, and an email address. There is a distinction between
research and administrative personnel.
● Research associates are assigned to at least one institute. The field of study of
each research associate is known. Furthermore, research associates can be
involved in projects for a certain number of hours, and the name, starting
date, and end date of the projects are known. Some research associates hold
courses. Then they are called lecturers.
● Courses have a unique number (ID), a name, and a weekly duration in hours.
Identifying Classes X
● A university consists of multiple faculties which are composed
of various institutes. Each faculty and each institute has a name.

●
An address is known for each institute.
Each faculty is led by a dean, who is an employee of the
university.
X
● The total number of employees is known. Employees have a
social security number, a name, and an email address. There is
a distinction between research and administrative personnel.
● Research associates are assigned to at least one institute. The
field of study of each research associate is known. Furthermore,
research associates can be involved in projects for a certain
number of hours, and the name, starting date, and end date of
the projects are known. Some research associates hold courses.
Then they are called lecturers.
● Courses have a unique number (ID), a name, and a weekly
duration in hours.
Identifying the Attributes
● A university consists of multiple faculties which are composed of
various institutes. Each faculty and each institute has a name. An
address is known for each institute.
● Each faculty is led by a dean, who is an employee of the university.
● The total number of employees is known. Employees have a social
security number, a name, and an email address. There is a
distinction between research and administrative personnel.
● Research associates are assigned to at least one institute. The
field of study of each research associate is known. Furthermore,
research associates can be involved in projects for a certain
number of hours, and the name, starting date, and end date of
the projects are known. Some research associates hold courses.
Then they are called lecturers.
● Courses have a unique number (ID), a name, and a weekly
duration in hours.
Identifying Relationships (1/6)
Abstract, i.e., no other types
● Indication of a generalization of employees

● “There is a distinction between

research
● and administrative personnel.”
● “Some research associates hold
courses. Then they are called
lecturers.”
Identifying Relationships (2/6)
● “A university consists of multiple faculties which are composed of various
institutes.”

Composition to show existence dependency

Identifying Relationships (3/6)
● “Each faculty is led by a dean, who is an employee of the university”

In the leads-relationship, the

Employee takes the role of a
dean.
Identifying Relationships (4/6)
● “Research associates are assigned to at least one institute.”

Shared aggregation to show that

ResearchAssociates are part of an
Institute, but there is no existence
dependency
Identifying Relationships (5/6)
● “Furthermore, research associates can be involved in projects for a certain
number of hours.”

Association class enables to store the

number of hours for every single Project
of every single ResearchAssociate
Identifying Relationships (6/6)
● “Some research associates hold courses. Then they are called lecturers.”

Lecturer inherits all characteristics,

associations, and aggregations from
ResearchAssociate. In addtion, a Lecturer
has an association teaches to Course.
Complete Class Diagram
Notation Elements (1/3)
Name Notation Description

Description of the structure and

Class
behavior of a set of objects

Class that cannot be

Abstract class
instantiated

Relationship between classes:

navigability unspecified,
Association
navigable in both directions,
not navigable in one direction
Notation Elements (2/3)
Name Notation Description

n-ary Relationship between n (here 3)

association classes

Association More detailed description of an

class association

An object of C is in a relationship
xor
with an object of A or with an
relationship
object of B but not with both
Notation Elements (3/3)
Name Notation Description

Shared Parts-whole relationship (A is

aggregation part of B)
Strong Existence-dependent
aggregation = parts-whole relationship (A is
composition part of B)
Inheritance relationship (A
Generalization
inherits from B)
Object Instance of a class

Link Relationship between objects