Software Modeling

Adama Science and Technology University

School of Electrical Engineering and Computing
Department of Computer Science and Engineering
 Requirement Modeling
 The SW requirements describe the functionality that the
system must provide for the users.
 Requirement Analysis:
What is your role in the current system?
How do you use the current system?
What are the advantage and limitation of the current system?
What features the new should provide for you?
After the analysis the requirements has to be specified.
Requirement specification document need to be agreed by
both the analysts and users. (functional and nonfunctional)
08/26/25 2
 Requirement Modeling
 In defining the functional requirement, it is necessary to
describe:
 What functionality the system needs to provide
 What information needs to be input from external
 What the system needs to output to the external
 What stored information the system reads or update
 Consider the following for a well written SRS:
 Correct, Complete, Unambiguous, Consistent, Verifiable,
Understandable by non-technical, Modifiable, Traceable.
 Several reviews need to be held with users.
08/26/25 3
 Use Cases Modeling
 Use case model describes the functional requirements of
the system interims of actors and use cases:
 A use case defines a sequence of interactions between one or
more actors and the system.
 What the system do.
 A use case always starts with input from an actor.
 The actor provides input to the system and the system response
to the actor.
 More complex use cases might involves more than one actors.

08/26/25 4
 A Simple Use Case
 The essentials use case description consist of the
following:
 The name of the use case, View Alarms.
 The name of the actor, Monitoring Operator.
 A one-sentence use case summary
 The description of the main sequence of events.
 The description of any alternative to the main sequence

08/26/25 5
 A Simple Use Case

08/26/25 6
 Actors
 Actor can be human or external system (out side the system)
 Actor can be:
 Primary actor: initiates a use case.
 Secondary actor: can participate in the use case.

External system actors Input device actors

08/26/25 7
 Primary and Secondary Actors
 In some case, an actor can be an input device actor or an
input/output device actor.
 This can happen when there is no human involvement with the
use case.
 An actor can also be a timer actor that periodically sends
timer events to the system.

Example of timer actor

08/26/25 8
 Identifying Use cases
 To determine the use cases, it is useful to start by
considering the actors and the interactions they have with
the system.
 Each use case describe interactions b/n the actor and the
system.
 In this way, the functional requirements of the system are
described in terms of the use cases.
 To avoid functional decomposition, focuses on a sequence of
events that provide s a useful result to the actor.

08/26/25 9
 Identifying Use cases
 Each sequence through the use case is called a scenario.
 A use case usually describes several scenarios, one main
sequence and a number of alternative sequences.

 Note that a scenario is a complete sequence through the

use case:
 So a scenario could start out executing the main sequence
and then follow an alternative branch at the decision
point.
08/26/25 10
 Documenting Use Cases in Use case Model
 Each use cases in the use case model is documented in the use case
description:
 Use case name: name of the use case.
 Summary: brief description (1 or 2 sentences)
 Dependency: optional (includes / extends)
 Actors: primary and secondary
 Precondition: one or more conditions
 Description of main sequence: the most usual sequence
 Description of alternative sequences: alternative branches off the main
 Nonfunctional requirements: description of nonfictional requirements
 Postcondition: condition that must be true at the end of the use case
 Outstanding questions: question to be discussed with the user

08/26/25 11
 Use case Descriptions

 An example of a use case for Make Order Request, which

is one of the use cases from the Online Shopping System.

08/26/25 12
 Use case Descriptions

08/26/25 13
 Use case Descriptions

08/26/25 14
 Use Cases Relationships
 When use cases get too complex, dependencies between
use cases can be defined by using the include and extend.

 The objective is to maximize extensibility and reuse of use

cases.
 Include use case: common to more than one use case.
 An inclusion use case is executed in conjunction with a
base use case.

08/26/25 15
 Use Cases Relationships

Example of an include use case and include relationships

08/26/25 16
 Use Cases Relationships

08/26/25 17
 Use Cases Relationships

08/26/25 18
 Use Cases Relationships
 The include relationship can also be used to structure a
lengthy use case.
 The base - high level sequence, the inclusion low-level sequence.

Example of multiple include use case and include relationships

08/26/25 19
 Use Cases Relationships
 The extend relationship is used to model alternative paths
that a use case might take.
 The extend relationship can be used as follows:
 To show a conditional part of the base use case that is
executed only under certain circumstances.
 To model complex or alternative paths.

 The extension use case, depends on the base use case and
executes only if the condition in the base use case is true.

08/26/25 20
 Use Cases Relationships

Example of an extend relationship and extension use case

08/26/25 21
 Use Cases Relationships

08/26/25 22
 Use Cases Relationships

08/26/25 23
 Specifying Nonfunctional
Requirements

 The nonfunctional requirements can be specified in a

separate section of the use case.
 For the Validate PIN use case, they would be described as
follows:

08/26/25 24
 Use Case Packages

 A use case package groups together related use cases to

manage the large number of use cases in a large system.

08/26/25 25
 Static Modeling

08/26/25 26
 Static Modeling

 A static model describes the static structure of the system.

 The classes in the system
 The attributes of the class
 The relationship b/n the class
 The operations of each class

 The multiplicity of an association:

 One-to-one, One-to-many, Numerically specified, Optional,
Many-to-many association.

08/26/25 27
 Static Modeling

Example of association on class diagram (bank application)

08/26/25 28
 Static Modeling

Example of class attributes

08/26/25 29
 Association Class

 A class that models an association between two or more

classes.
 The attributes of the association class are the attributes of
the association

Example of association class

08/26/25 30
 Composition and
Aggregation
 Identify a class that is made up of other class (whole/part).
 A composition is a stronger relationship than an aggregation
 An aggregation is a stronger relationship than an
association

Example of composition hierarchy (physical class)

08/26/25 31
 Composition and
Aggregation
 In aggregation parts can be added and removed from the
aggregate whole. (conceptual classes)

Example of aggregation hierarchy

08/26/25 32
 Generalization and
Specialization
 A discriminator is an attribute that indicates which
property of the object is being abstracted by the
generalization relationship.

Generalization / Specialization hierarchy

08/26/25 33
 Static Modeling of the
System Context
 To understand the scope of the system.
 Context modeling explicitly identifies what is inside the
system and what is outside. It can be done at:
 The total system (HW and SW) level
 The software system (software only) level

 System context diagram: shows the border b/n the system

and the external environment.
 Software system context diagram: shows the border b/n the
SW system and the external environment.
08/26/25 34
 Static Modeling of the
System Context

Banking HW/SW system context class diagram

08/26/25 35
 Static Modeling of the System
Context

Banking software system context class diagram

08/26/25 36
Categorization of classes using
UML Stereotypes

 In class structuring, the COMET method advocates

categorizing classes in order to group together classes with
similar characteristics.
 Stereotypes are used to distinguish among the various kinds
of classes.
 A class is categorized by the role it plays in the application.
 Such as:
 <<entity>> class or <<boundary>> class
 External class can categorized: <<external system>> <<external
user>>

08/26/25 37
Categorization of classes using
UML Stereotypes

Example of UML classes and their stereotypes

08/26/25 38
Categorization of classes using
UML Stereotypes

Banking System Software context class diagram with stereotype

08/26/25 39
 Modeling External Classes

 Classification of external classes from the perspective of

the software system.

Classification of external classes by stereotype

08/26/25 40
 Modeling External Classes

 The standard association names on software system context

class diagrams are Inputs to, Outputs to, Communicates
with, Interacts with, and Signals.

08/26/25 41
 Modeling External Classes

 To develop a SW system context class diagram:

 Determine the external classes from the static model
 Categorized the external classes using stereotype

08/26/25 42
Actors and External Classes

 The relationship between actors and external classes is as

follows:
 An I/O device actor is equivalent to an external I/O devices class.
 An external system actor is equivalent to an external system class.
 A timer actor interfaces to the system via an external timer class.
 A human user actor has the most flexibility.

08/26/25 43
Actors and External Classes

Automated Guided Vehicle System software system context class diagram with external class stereotypes

08/26/25 44
Actors and External Classes

 In order to determine the external classes from the actors, it is

necessary to understand the characteristics of each actor and
how each actor interacts with the system.

08/26/25 45
 Static Modeling of Entity
Classes

 Entity classes are conceptual data-intensive classes.

 To store data and provide access to this data
 The COMET approach emphasizes static modeling of
entity classes, in order to take advantage of the strengths of
the static modeling.
 Entity classes are often mapped to a database in the design
phase.
 The COMET emphasis is on determining the entity classes
that are defined in the problem, their attributes, and their
relationships.

08/26/25 46
 Static Modeling of Entity
Classes

Entity class model for online shopping application

08/26/25 47
 Modeling Class Attributes

 An important consideration in modeling entity classes is to

define the attributes of each entity class.
 An entity class is data-intensive, meaning that it has
several attributes.
 Entity classes having only one attribute is questionable.
 Most probably it can be an attribute of another class.

08/26/25 48
 Modeling Class Attributes

Entity class attributes for online shopping application

08/26/25 49
 Question & Answer

08/26/25 50
 Thank You !!!

08/26/25 51