Addis Ababa University

College of Natural and Computational Sciences

Department of Computer Science

Introduction to Software Engineering (CoSc3311)

Chapter 2: An overview of UML
Introduction
• UML is a notation that resulted from the unification of
OMT (Object Modeling Technique [Rumbaugh et al.,
1991]), Booch [Booch, 1994], and OOSE (Object-
Oriented Software Engineering [Jacobson et al., 1992])
• The goal of UML is to provide a standard notation that
can be used by all object-oriented methods and to
select and integrate the best elements of precursor
notations.

3
 Introduction…
• UML has been designed for a broad range of
applications (distributed systems, analysis, system
design, deployment)
• System development focuses on three different models
of the system

4
Where Can the UML Be Used?
• The functional model
• The object model
• The dynamic model
These three models provide complementary views to fully describe a system
in UML: functional for user interactions, object for structure, and dynamic
for behavior.

5
The functional model
• Describes the functionality of the system from the
user's perspective.
• Focuses on what the system does, not how it does it.
• Often represented by Use Case Diagrams, which show
interactions between users (actors) and the system,
capturing the high-level functions (use cases) that the
system must provide.
The object model
• Focuses on the structure of the system.
• Describes the static aspects, such as classes, objects,
and their relationships (like inheritance and
associations).
• Represented by Class Diagrams and Object
Diagrams, showing the classes, attributes, methods,
and associations between objects.
The dynamic model
• Focuses on the behavior of the system over time.
• Describes how the system's objects interact and
how the system changes state.
• Represented by Sequence Diagrams, State
Diagrams, and Activity Diagrams, capturing the
flow of control, state transitions, and interactions
among objects or components.
UML notations
• Use Case Diagrams
– Use cases are used during requirements elicitation and analysis
to represent the functionality of the system.
– Use cases focus on the behavior of the system from an external
point of view.
– A usecase describes a function provided by the system that
yields a visible result for an actor.
– An actor describes any entity that interacts with the system

9
A UML use case diagram describing the functionality
of a simple watch
System Name
System Boundary
Actor
UseCase

10
Example…

UML use case diagram for First Responder Interactive Emergency

Navigational Database (FRIEND), an accident management system
11
UseCase Description
• detailed textual representation that complements a UML Use Case
Diagram (for every usecase) by explaining the interaction between an
actor and the system for a specific use case
• Components
• Use Case Name
• Participating Actors
• Flow of Events (basic/ alternative)
• Entry (pre ) condition
• Exit (post)Condition
• Quality Requirement
An example of a use case, ReportEmergency

13
Include relationships

14
Extend relationships

15
Inheritance relationships

16
An example of an inheritance relationship

17
Classes and objects
Class Diagrams
• Classes are abstractions that specify the common
structure and behavior of a set of objects.
• Class diagrams are used to describe the structure of the
system
• Class diagrams describe the system in terms of objects,
classes, attributes, operations, and their associations.

19
Classes and objects

20
A UML class diagram describing the elements
of a simple watch

21
Classes, Abstract Classes, and Objects

A UML class diagram depicting two classes,

Watch and CalculatorWatch.

• The names of abstract classes are italicized

22
A UML class diagram depicting instances of two
classes

23
Interaction Diagrams
• Interaction diagrams are used to formalize the dynamic
behavior of the system and to visualize the
communication among objects.
• They are useful for identifying additional objects that
participate in the use cases.

24
A UML sequence diagram for the Watch

25
State Machine Diagrams
• State machine diagrams describe the dynamic behavior
of an individual object as a number of states and
transitions between these states.
• A state represents a particular set of values for an
object.
• Given a state, a transition represents a future state the
object can move to and the conditions associated with
the change of state.

27
A UML state machine diagram for SetTime
use case of the Watch

28
Activity Diagrams
• An activity diagram describes the behavior of a system
in terms of activities.
• Activities are modeling elements that represent the
execution of a set of operations.
• The execution of an activity can be triggered by the
completion of other activities, by the availability of
objects, or by external events.

30
UML activity diagram

31
Example of packages: use cases of FRIEND organized
by actors

33
The FieldOfficer and EmergencyReport classes are located in the FieldStation
package, and the Dispatcher and Incident classes are located on the
DispatcherStation package.

34
Chapter 3: Requirements Elicitation

35
• A requirement is a feature that the system must have
• A constraint that a system must satisfy to be accepted by the client
• Requirements engineering aims at defining the requirements of the system
under construction.
• Requirements engineering includes two main activities; requirements
elicitation, which results in the specification of the system that the client
understands, and analysis, which results in an analysis model that the
developers can unambiguously interpret.
• A scenario describes an example of system use in terms of a series of
interactions between the user and the system
• A use case is an abstraction that describes a class of scenarios.
• Requirements elicitation is about communication among developers,
clients, and users to define a new system
36
Requirements Elicitation…
Errors introduced during requirements elicitation:
▪ expensive to correct
• missing functionality
• functionality that was incorrectly specified
• user interfaces that are misleading or unusable and
obsolete functionality

37
• Requirements elicitation and analysis focus only on the
user’s view of the system.
– the system functionality
– the interaction between the user and the system
– the errors that the system can detect and handle
– the environmental conditions in which the system functions
are part of the requirements.

38
39
Requirements elicitation includes the
following activities:
• Identifying Actors
• Identifying scenarios
• Identifying use cases
• Refining use cases
• Identifying relationships among use cases, actor and use cases
• Identifying nonfunctional requirements
– Joint Application Design (JAD)
40
 Functional Requirements
• Describe the interactions between the system and its
environment independent of its implementation.

• The environment includes the user and any other

external system with which the system interacts

41
Nonfunctional Requirements
• Usability
• Reliability
• Performance
• Supportability
• Constraints or pseudo requirements
– Implementation requirements
– Interface requirements
– Operations requirements
– Packaging requirements
– Legal requirements

42
Completeness
• all possible scenarios through the system are
described, including exceptional behavior

43
Consistency
• it does not contradict itself
• Unambiguous
Correctness
• it represents accurately the system that the client
needs and that the developers intend to build

44
Realism
• The system can be implemented within constraints
Verifiability
• Repeatable tests can be designed to demonstrate that the
system fulfills the requirements specification

45
Traceability
• Each requirement can be traced throughout the
software development to its corresponding system
functions
• Greenfield Engineering
• Reengineering
• Interface Engineering

46
Requirements Elicitation Activities
Identifying Actors
• Actors represent external entities that interact with the system.
• An actor can be human or an external system

Actors for the SatWatch system

47
Requirements Elicitation Activities…
Questions for identifying actors
• Which user groups are supported by the system to
perform their work?
• Which user groups execute the system’s main functions?
• Which user groups perform secondary functions, such as
maintenance and administration?
• With what external hardware or software system will the
system interact?

48
Requirements Elicitation Activities…
Identifying Scenarios
• A scenario is “a narrative description of what people do and
experience as they try to make use of computer systems and
applications” [Carroll, 1995
• A scenario is a concrete, focused, informal description of a single
feature of the system from the viewpoint of a single actor.

49
50
Requirements Elicitation Activities…
Scenarios can have many different uses during requirements
elicitation and during other activities of the life cycle
• As-is scenarios describe a current situation
• Visionary scenarios describe a future system
• Evaluation scenarios describe user tasks against which the
system is to be evaluated
• Training scenarios are tutorials used for introducing new
users to the system

51
Requirements Elicitation Activities…
Questions for identifying scenarios
• What are the tasks that the actor wants the system to perform?
• What information does the actor access? Who creates that data?
Can it be modified or removed? By whom?
• Which external changes does the actor need to inform the
system about? How often? When?
• Which events does the system need to inform the actor about?
With what latency?.

52
Requirements Elicitation Activities…
Identifying Use Cases
• A scenario is an instance of a use case; that is, a use case
specifies all possible scenarios for a given piece of
functionality.
• A use case is initiated by an actor. After its initiation, a use
case may interact with other actors, as well.
• A use case represents a complete flow of events through the
system in the sense that it describes a series of related
interactions that result from its initiation.
53
54
The use case ReportEmergency of which the scenario warehouseOnFire is an instance

55
Simple Use Case Writing Guide
• Use cases should be named with verb phrases. The name of the use case should indicate what the user is trying
to accomplish (e.g., ReportEmergency, OpenIncident).
• Actors should be named with noun phrases (e.g., FieldOfficer, Dispatcher, Victim).
• The boundary of the system should be clear. Steps accomplished by the actor and steps accomplished by the
system should be distinguished
• Use case steps in the flow of events should be phrased in the active voice. This makes it explicit who
accomplished the step.
• The causal relationship between successive steps should be clear.
• A use case should describe a complete user transaction (e.g., the ReportEmergency use case describes all the
steps between initiating the emergency reporting and receiving an acknowledgment). Exceptions should be
described separately.
• A use case should not describe the user interface of the system. This takes away the focus from the actual steps
accomplished by the user and is better addressed with visual mock-ups (e.g., the ReportEmergency only refers
to the “Report Emergency” function, not the menu, the button, nor the actual command that corresponds to this
function).
• A use case should not exceed two or three pages in length. Otherwise, use include and extend relationships to
decompose it in smaller use cases,
56
Requirements Elicitation Activities…
Refining Use Cases
• The use of scenarios and use cases to define the functionality
of the system aims at creating requirements that are validated
by the user early in the development.
• As the design and implementation of the system starts, the cost
of changing the requirements specification and adding new
unforeseen functionality increases

57
Requirements Elicitation Activities…
Identifying Relationships among Actors and Use Cases
• Relationships among actors and use cases enable the developers
and users to reduce the complexity of the model and increase its
understandability.
• We use communication relationships between actors and use
cases to describe the system in layers of functionality.
• We use extend relationships to separate exceptional and common
flows of events.
• We use include relationships to reduce redundancy among use
cases.
58
Extend versus include relationships
• The main distinction between these constructs is the direction of the
relationship.
• For include relationships, the event triggering the target (i.e.,included) use
case is described in the flow of event of the source use case.
• For extend relationships, the event triggering the source (i.e., extending) use
case is described in the source use case as a precondition.
• In other words, for include relationships, every including use case must
specify where the included use case should be invoked.

59
Requirements Elicitation Activities…
Identifying Initial Analysis Objects

Identifying Nonfunctional Requirements

60
61
Documenting Requirements Elicitation
• The results of the requirements elicitation and the analysis activities are
documented in the Requirements Analysis Document (RAD).
• This document completely describes the system in terms of functional and
nonfunctional requirements.
• The audience for the RAD includes the client, the users, the project
management, the system analysts (i.e., the developers who participate in the
requirements), and the system designers (i.e., the developers who participate in
the system design).
• The first part of the document, including use cases and nonfunctional
requirements, is written during requirements elicitation. The formalization of
the specification in terms of object models is written during analysis
62
63
RAD document due date
November 20 , 2024

64