Introduction to
Software Engineering
Software Modeling
Tran Duy Hoang
Model
• A simplified representation of a thing from a specific perspective
• Capturing important aspects of a thing while ignoring others
• Different kinds of models
• Process models, use-case models, class model, object model, relationship
models, etc.
• Forms of software models
• Text
• Diagrams
• Pictures
Department of Software Engineering 2
System modeling
• Is the process of developing abstract models of a system
• each model presents a different view or perspective of that system.
• Represent a system using some kind of graphical notation
• based on notations in the Unified Modeling Language (UML).
• Helps the analyst to understand the functionality of the system and
models are used to communicate with customers.
Department of Software Engineering 3
Why modeling?
• Generally, modeling helps make things more precise, simpler, easy
to understand, more complete
• Specifically, models help
• capture and state precisely requirements and domain knowledge
• link requirements and design
• capture design decisions
• general usable work products (software artifacts)
• organize systems, especially large ones
• explore and contemplate multiple solutions
Department of Software Engineering 4
Modeling language
• Formal language used to create models of systems
• Examples of modeling language
• Unified Modeling Language (UML)
• C4 Model
• Business Process Model and Notation (BPMN)
• Systems Modeling Language (SysML)
Department of Software Engineering 5
Unified Modeling Language (UML)
• A general-purpose modeling language for software system analysis
and design
• History
• Unifying works on OO development methods by Grady Booch, James
Rumbaugh, Ivar Jacobson of Rational Software (now part of IBM)
• Adopted by Object Management Group (OMG) as a standard in 1997
• OMG now responsible for development of UML
Department of Software Engineering 6
UML modeling
• Static modeling – structural diagrams
• Class diagram
• Package diagram
• Object diagram
• Component diagram
• Deployment diagram
• Dynamic modeling – behavioral diagrams
• Use case diagram
• Sequence diagram
• Collaboration diagram
• Statechart diagram
• Activity diagram
Department of Software Engineering 7
Use case diagrams
• Use case diagrams are used to model the use case view of a
system as seen by end users, analysts, and testers
• Use case diagrams are usually a part of requirement specifications
• Accompanying use case specifications
• Main elements
• Actors
• Use cases
• Relationships
Department of Software Engineering 10
Benefits of Use case diagrams
• Capturing and visualizing precisely functional requirements
• Making connections between requirements, design,
implementation, and testing
• Facilitating communication between users and analysts, designers,
testers, implementers
• Supporting identifying functionality easily
• Supporting validation/testing
à Second most commonly used diagrams
Department of Software Engineering 11
Actors
• An actor represents an external person,
process, or anything that interacts with the
system
• It represents a role that a person, process, or
thing plays with the system
• One physical user can play multiple roles. Thus,
multiple actors can be bound to one physical user
• Multiple users have the same role, hence,
represented by one actor
• Between actors may have a generalization
Department of Software Engineering 12
Use case
• A use case describes a set of sequences of actions performed by
an actor to produce observable results value to the actor
Department of Software Engineering 13
Use case
• At the system level, use cases represent external behavior of a
system that is visible to outside users
• A use case specifies WHAT the system does, but not HOW it does
• A use case hides internal structure and operations of a system. It
usually represents system-level functions of a system
Department of Software Engineering 14
Use case description
• The behavior of a use case is described by a flow of events
• A use case has one main flow (basic flow) and alternative flows
• Basic path
• Alternative paths
• Exceptional paths
Department of Software Engineering 15
Department of Software Engineering 16
Department of Software Engineering 17
Scenarios
• A use case describes a set of sequences which each sequence in
the set represents a possible flow in the use case
• A scenario is a specific sequence of events happening
• A scenario is viewed as an instance of a use case
• A scenario is concrete or real
• Remember class vs. object?
Department of Software Engineering 18
Use case relationships
• Association
• Between actors and use cases
• Generalization
• Between general use cases and
more specific ones
• Include
• Between use cases
• Extend
• Between use cases
Department of Software Engineering 19
Include vs. Extend
• An include relationship between use cases specifies that the base
use case explicitly incorporates the behavior of another use case
• The included use case does not stand alone
• The base use case is aware of its included use case
• An extend relationship between use cases specifies that the base
use case implicitly incorporates the behavior of another use case at
location specified indirectly by the extending use case
• The extending use case may stand alone
• The base use case is not aware of the extending use case
Department of Software Engineering 20
Include vs. Extend
Department of Software Engineering 21
Notes on Use case diagrams
• A well-defined use case should
• specify identifiable and reasonably atomic behavior of the system
• include common behavior from included use cases
• distribute variations into extending use cases
• Number of use cases depends on how to include or extend system
behavior
• Only include use cases and actors essential to understanding an aspect
• Layout of elements is important to understanding
• minimize line crosses
• group related elements together
Department of Software Engineering 22
Class diagram
• The most commonly used
diagram in practice
• Main elements
• Classes
• Interfaces
• Relationships
• Common mechanisms
Department of Software Engineering 23
Class
• Defines the set of common objects that have same the same
attributes, operations, relationships, and semantics
• Represents a thing
• Notation
Department of Software Engineering 24
Attribute
• Defines data that characterize a class
• An abstraction of the kind of data or object
• title is an attribute of the kind of String object
• Data type is specified by a semicolon “:”
Department of Software Engineering 25
Operation
• An operation specifies a service that can be requested from objects
of the class
• Attribute and operation visibility
Department of Software Engineering 26
Interface
• An element that has a set of operations characterizing its behavior
• Notation
• A circle with a name
• OR a class with stereotype <<interface>>
Department of Software Engineering 27
Class relationships
• Most classes associate with others
• Classes have different types of relationship with each other
• Dependency
• Generalization
• Association
Department of Software Engineering 28
Class relationships
Department of Software Engineering 29
Dependency relationship
• Represents one class uses another
• Change in one class may affect the one that uses it
• e.g., two classes have dependency relationship if
• one operation calls another operation on another class
• one class is used as a parameter in another class
• Dependency is less restrictive than other
relationships
Department of Software Engineering 30
Generalization relationship
• A relationship between a
general class and more specific
class (superclass and subclass)
Department of Software Engineering 31
Association relationship
• A relationship specifying objects
of one class are connected to
objects of another
• Typically, one object holds
objects (instances) of the same
class or another
• Association can have a name,
roles at both ends
Department of Software Engineering 32
Multiplicity
• Refers to how many objects may be connected across an instance
of an association
Department of Software Engineering 33
Aggregation and Composition
• Composition – Strong association
• When a class owns another class, and is responsible for its lifetime
• Aggregation – Week association
• When a class uses another class but does not own it
Department of Software Engineering 34