System Models
Software Engineering, COMP201 Slide 1
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.
● Many notations over time
• State machines
• Entity-relationship diagrams
• Dataflow diagrams
Why model software?
● Software is getting increasingly more complex
• Windows XP > 40 mio 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
Objectives
● System models are abstract descriptions of systems
whose requirements are being analysed
● To describe
• Behavioural modelling (FSM, Petri-nets),
• Data modelling and
• Object modelling (Unified Modeling Language, UML)
System modelling
● System modelling helps the analyst to understand the
functionality of the system and models are used to
communicate with customers
● Different models present the system from different
perspectives
• External perspective showing the system’s context or
environment
• Behavioural perspective showing the behaviour of the system
• Structural perspective showing the system or data architecture
Behavioural models
● Behavioural models are used to describe the overall
behaviour of a system
● Two types of behavioural model
• Data processing models that show how data is processed as it
moves through the system
• State machine models that show the systems response to
events
● Both of these models are required for a description of the
system’s behaviour
Data-processing models
● Data flow diagrams are used to model the system’s
data processing
● These show the processing steps as data flows through
a system
● IMPORTANT part of many analysis methods
● Simple and intuitive notation that customers can
understand
● Show end-to-end processing of data
Data flow diagrams
● DFDs model the system from a functional perspective
● Tracking and documenting how the data associated
with a process is helpful to develop an overall
understanding of the system
● Data flow diagrams may also be used in showing the
data exchange between a system and other systems in
its environment
Object models
● Object models describe the system in terms of
object classes
● An object class is an abstraction over a set of objects
with common attributes and the services (operations)
provided by each object
● Various object models may be produced
• Inheritance models
• Aggregation models
• Interaction models
Object models
● Natural ways of reflecting the real-world entities
manipulated by the system
● More abstract entities are more difficult to model using
this approach
● Object class identification is recognised as a difficult
process requiring a deep understanding of the
application domain
● Object classes reflecting domain entities are reusable
across systems
What is UML
• UML → “Unified Modeling Language”
• Language: express idea, not a methodology
• A standardized, graphical “modeling language” for
communicating software design.
• Modeling: Describing a software system at a high level
of abstraction
• Unified: UML has become a world standard
• Object Management Group (OMG): www.omg.org
Motivations for UML
● UML is a fusion of ideas from several precursor
modeling languages.
● We need a modeling language to:
• help develop efficient, effective and correct designs,
particularly Object Oriented designs.
• communicate clearly with project stakeholders (concerned
parties: developers, customer, etc).
• give us the “big picture” view of the project.
12
Objectives
● SYSTEM MODELS (in UML notation)
• Functional Model – use case diagrams
• Object Model – class diagrams
• Dynamic Model – sequence diagrams, state chart
diagrams and activity diagrams
Types of UML diagrams
● There are different types of UML diagram,
each with slightly different syntax rules:
• use cases.
• class diagrams.
• sequence diagrams.
• package diagrams.
• state diagrams
• activity diagrams
• deployment diagrams.
Use-Case Diagrams
● A Use Case diagram is a graphical representation of
the high-level system scope
• includes use cases, which are pieces of
functionality the system will provide
• actors, who are the users of the system.
● A use case is a model of the interaction between
• External users of a software product (actors) and
• The software product itself
• More precisely, an actor is a user playing a specific
role
Use Case Diagrams
● Actors represent roles, that
is, a type of user of the
system
● Use cases represent a
sequence of interaction for a
Passenger type of functionality; summary
of scenarios
● It is a complete description of
the functionality of the
system and its environment
PurchaseTicket
Actors
● An actor models an external entity which
communicates with the system:
• User
• External system
Passenger • Physical environment
● An actor has a unique name and an
optional description.
● Examples:
• Passenger: A person in the train
• GPS satellite: Provides the system
with GPS coordinates
Use Case
● A use case represents a class of functionality provided
by the system as an event flow
● Examples: withdraw money, process loan
● A use case consists of:
• Unique name
• Participating actors
• Entry conditions
• Flow of events
PurchaseTicket
• Exit conditions
• Special requirements coordinates
Defination
● Association: Communication between an actor and a
use case; Represented by a solid line.
● System boundary: Rectangle diagram representing
the boundary between the actors and the system.
Use Case Diagram for
Appointment System
Use-Case Diagram for
Specialized Actor
The <<extends>> Relationship
● The exceptional event flows
are factored out of the main
Passenger event flow for clarity.
● Use cases representing
exceptional flows can extend
more than one use case.
PurchaseTicket
● The direction of a
<<extends> <<extends>> relationship is
> to the extended use case
<<extends>
> <<extends>
>
<<extends>
OutOfOrder TimeOut
>
Cancel NoChange
The <<includes>> Relationship
● <<includes>> relationship
represents behavior that is
Passenger factored out of the use case.
● <<includes>> behavior is
factored out for reuse, not
PurchaseMultiCard
because it is an exception.
PurchaseSingleTicket ● The direction of a
<<includes>
> <<includes>> relationship is to
<<includes>
> the using use case (unlike
<<extends>> relationships).
<<extends> CollectMoney <<extends>
> >
NoChange Cancel
Steps in Creating the Use Case
Diagram
1. Identify use cases
2. Draw the system boundary
3. Place use cases on the diagram
Group use cases into packages
Add special use case associations
4. Identify the actors
5. Add Associations
Execercise
Use Case Diagrams: Summary
● Use case diagrams represent external behavior
● Use case diagrams are useful as an index into the use
cases
● Use case descriptions provide meat of model, not the
use case diagrams.
● All use cases need to be described for the model to be
useful.
Library class hierarchy
END
