SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
Software Engineering
CS317
TOPIC: SYSTEM MODELING
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CHAPTER OBJECTIVES
● Understand how graphical models can be used to represent software
systems and why several types of model are needed to fully represent a
system;
● Understand the fundamental system modeling perspectives of context,
interaction, structure, and behavior;
● Understand the principal diagram types in the Unified Modeling
Language (UML) and how these diagrams may be used in system
modeling
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
SYSTEM
MODELING
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
SYSTEM MODELING
System modeling is the process of developing abstract models of a system,
with each model presenting a different view or perspective of that system.
System modeling now usually means representing a system using some kind
of graphical notation based on diagram types in the Unified Modeling
Language (UML).
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
SYSTEM MODELING
The graphical representation of the system which the software developer
wants to develop is called a system model. The system is developed based
on user requirements and system requirements.
The system models describe the system in detail using graphical notation.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
SYSTEM MODELING
There are four types of system models:
● context model,
● interaction structural model,
● behavioural model, and
● structural model
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CONTEXT MODEL
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CONTEXT MODEL
The external perspective model represents how the system that must be built
will interact with other systems within its environment. It shows the
boundaries of a system that includes various automated systems in an
environment.
It is used to explain developers, stakeholders, or customers. Some factors
need to be kept in mind while creating the context model. The factors can be
the overall cost of the system, the time required to analyze the system, etc.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CONTEXT MODEL
Example of the Bank ATM System
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CONTEXT MODEL
Example of the Order Processing System
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CONTEXT MODEL
Example of the Mentcare System
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
INTERACTION
MODEL
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
INTERACTION MODEL
All systems involve interaction of some kind. This can be user interaction,
which involves user inputs and outputs; interaction between the software
being developed and other systems in its environment; or interaction
between the components of a software system.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
INTERACTION MODEL
There are two related approaches to interaction modeling:
● Use case modeling - which is mostly used to model interactions
between a system and external agents (human users or other systems)
● Sequence diagrams - which are used to model interactions between
system components, although external agents may also be included.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
INTERACTION MODEL
Use Case Modeling
Use case modeling was originally developed by Ivar Jacobsen in the 1990s
(Jacobsen et al. 1993), and a UML diagram type to support use case modeling
is part of the UML.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
INTERACTION MODEL
Use Case Modeling
Each use case represents a discrete task that involves external interaction
with a system. In its simplest form, a use case is shown as an ellipse, with the
actors involved in the use case represented as stick figures
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
INTERACTION MODEL
Use Case Modeling
Tabular Form
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
INTERACTION MODEL
Use Case Modeling
Composite use case diagram show a
number of different use cases.
Sometimes it is possible to include all
possible interactions within a system in
a single composite use case diagram.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
INTERACTION MODEL
Sequence Modeling
Sequence diagrams in the UML are primarily used to model the interactions
between the actors and the objects in a system and the interactions between
the objects themselves.
As the name implies, a sequence diagram shows the sequence of interactions
that take place during a particular use case or use case instance.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
INTERACTION MODEL
Sequence Modeling
This diagram models the
interactions involved in the
View patient information use
case, where a medical
receptionist can see some
patient information.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
STRUCTURAL
MODEL
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
STRUCTURAL MODEL
Structural models of software display the organization of a system in terms of
the components that make up that system and their relationships. Structural
models may be static models, which show the organization of the system
design, or dynamic models, which show the organization of the system when
it is executing.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CLASS DIAGRAM
In software engineering, a class diagram in the Unified Modeling Language
(UML) is a type of static structure diagram that describes the structure of a
system by showing the system's classes, their attributes, operations (or
methods), and the relationships among objects.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CLASS DIAGRAM
Purpose of Class Diagrams
● Shows static structure of classifiers in a system
● Diagram provides a basic notation for other structure diagrams
prescribed by UML
● Helpful for developers and other team members too
● Business Analysts can use class diagrams to model systems from a
business perspective
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CLASS DIAGRAM
A UML class diagram is made up of:
● A set of classes and,
● A set of relationships between classes
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CLASS DIAGRAM
What is a Class?
● Structural features (attributes) define what objects of the class "know"
○ Represent the state of an object of the class
○ Are descriptions of the structural or static features of a class
● Behavioral features (operations) define what objects of the class "can do"
○ Define the way in which objects may interact
○ Operations are descriptions of behavioral or dynamic features of a class
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CLASS DIAGRAM
Class Notation
A class notation consists of three parts:
● Class Name - The name of the class appears in the first partition.
● Class Attributes
○ Attributes are shown in the second partition.
○ The attribute type is shown after the colon.
○ Attributes map onto member variables (data members) in code.
● Class Operations (Methods)
○ Operations are shown in the third partition. They are services the class provides.
○ The return type of a method is shown after the colon at the end of the method signature.
○ The return type of method parameters is shown after the colon following the parameter name.
○ Operations map onto class methods in code
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CLASS DIAGRAM
Class Relationships
A class may be involved in one or more relationships with other classes. A
relationship can be one of the following types:
● Inheritance
● Simple Association
● Aggregation
● Composition
● Dependency
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CLASS DIAGRAM
Class Relationships - Inheritance
● Represents an "is-a" relationship.
● SubClass1 and SubClass2 are
specializations of Super Class.
● A solid line with a hollow
arrowhead that point from the
child to the parent class
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CLASS DIAGRAM
Class Relationships - Simple
Association
● A structural link between two peer
classes.
● There is an association between
Class1 and Class2
● A solid line connecting two classes
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CLASS DIAGRAM
Class Relationships - Aggregation
A special type of association. It
represents a "part of" relationship.
● Class2 is part of Class1.
● Many instances (denoted by the *) of
Class2 can be associated with Class1.
● A solid line with an unfilled diamond
at the association end connected to
the class of composite
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CLASS DIAGRAM
Class Relationships - Composition
A special type of aggregation where parts
are destroyed when the whole is
destroyed.
● Objects of Class2 live and die with
Class1.
● Class2 cannot stand by itself.
● A solid line with a filled diamond at
the association connected to the class
of composite
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CLASS DIAGRAM
Class Relationships - Dependency
● Exists between two classes if the
changes to the definition of one
may cause changes to the other
(but not the other way around).
● Class1 depends on Class2
● A dashed line with an open arrow
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
CLASS DIAGRAM EXAMPLE
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
BEHAVIORAL
MODELS
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
BEHAVIORAL MODELS
Behavioral models are models of the dynamic behavior of a system as it is
executing. They show what happens or what is supposed to happen when a
system responds to a stimulus from its environment. These stimuli may be
either data or events:
● Data becomes available that has to be processed by the system. The
availability of the data triggers the processing.
● An event happens that triggers system processing. Events may have
associated data, although this is not always the case.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
DATA-DRIVEN MODELING
Data-driven models show the sequence of actions involved in processing
input data and generating an associated output.
Data-driven models were among the first graphical software models. In the
1970s, structured design methods used data-flow diagrams (DFDs) as a way
to illustrate the processing steps in a system.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
DATA-DRIVEN MODELING
Data Flow Diagrams are simple and intuitive and so are more accessible to
stakeholders than some other types of model. It is usually possible to explain
them to potential system users who can then participate in validating the
model.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
DATA-DRIVEN MODELING
An alternative way of showing the
sequence of processing in a system
is to use UML sequence diagrams.
You have seen how these diagrams
can be used to model interaction,
but if you draw these so that
messages are only sent from left to
right, then they show the sequential
data processing in the system.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
EVENT-DRIVEN MODELING
Event-driven modeling shows how a system responds to external and internal
events. It is based on the assumption that a system has a finite number of
states and that events (stimuli) may cause a transition from one state to
another.
For example, a system controlling a valve may move from a state “Valve
open” to a state “Valve closed” when an operator command (the stimulus) is
received.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
EVENT-DRIVEN MODELING
This view of a system is particularly appropriate for real-time systems. Event-
driven modeling is used extensively when designing and documenting real-
time systems.
The UML supports event-based modeling using state diagrams, which are
based on Statecharts (Harel 1987). State diagrams show system states and
events that cause transitions from one state to another. They do not show the
flow of data within the system but may include additional information on the
computations carried out in each state.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
EVENT-DRIVEN MODELING
A state diagram is used to
represent the condition of the
system or part of the system at
finite instances of time. It’s a
behavioral diagram and it
represents the behavior using finite
state transitions.
SOFTWARE ENGINEERING
SOFTWARE ENGINEERING
EVENT-DRIVEN MODELING
FUNDAMENTALS OF DATABASE SYSTEMS
END OF CHAPTER 6

Software Engineering - System Modeling.pptx

  • 1.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING SoftwareEngineering CS317 TOPIC: SYSTEM MODELING
  • 2.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CHAPTEROBJECTIVES ● Understand how graphical models can be used to represent software systems and why several types of model are needed to fully represent a system; ● Understand the fundamental system modeling perspectives of context, interaction, structure, and behavior; ● Understand the principal diagram types in the Unified Modeling Language (UML) and how these diagrams may be used in system modeling
  • 3.
  • 4.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING SYSTEMMODELING System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system. System modeling now usually means representing a system using some kind of graphical notation based on diagram types in the Unified Modeling Language (UML).
  • 5.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING SYSTEMMODELING The graphical representation of the system which the software developer wants to develop is called a system model. The system is developed based on user requirements and system requirements. The system models describe the system in detail using graphical notation.
  • 6.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING SYSTEMMODELING There are four types of system models: ● context model, ● interaction structural model, ● behavioural model, and ● structural model
  • 7.
  • 8.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CONTEXTMODEL The external perspective model represents how the system that must be built will interact with other systems within its environment. It shows the boundaries of a system that includes various automated systems in an environment. It is used to explain developers, stakeholders, or customers. Some factors need to be kept in mind while creating the context model. The factors can be the overall cost of the system, the time required to analyze the system, etc.
  • 9.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CONTEXTMODEL Example of the Bank ATM System
  • 10.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CONTEXTMODEL Example of the Order Processing System
  • 11.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CONTEXTMODEL Example of the Mentcare System
  • 12.
  • 13.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING INTERACTIONMODEL All systems involve interaction of some kind. This can be user interaction, which involves user inputs and outputs; interaction between the software being developed and other systems in its environment; or interaction between the components of a software system.
  • 14.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING INTERACTIONMODEL There are two related approaches to interaction modeling: ● Use case modeling - which is mostly used to model interactions between a system and external agents (human users or other systems) ● Sequence diagrams - which are used to model interactions between system components, although external agents may also be included.
  • 15.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING INTERACTIONMODEL Use Case Modeling Use case modeling was originally developed by Ivar Jacobsen in the 1990s (Jacobsen et al. 1993), and a UML diagram type to support use case modeling is part of the UML.
  • 16.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING INTERACTIONMODEL Use Case Modeling Each use case represents a discrete task that involves external interaction with a system. In its simplest form, a use case is shown as an ellipse, with the actors involved in the use case represented as stick figures
  • 17.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING INTERACTIONMODEL Use Case Modeling Tabular Form
  • 18.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING INTERACTIONMODEL Use Case Modeling Composite use case diagram show a number of different use cases. Sometimes it is possible to include all possible interactions within a system in a single composite use case diagram.
  • 19.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING INTERACTIONMODEL Sequence Modeling Sequence diagrams in the UML are primarily used to model the interactions between the actors and the objects in a system and the interactions between the objects themselves. As the name implies, a sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance.
  • 20.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING INTERACTIONMODEL Sequence Modeling This diagram models the interactions involved in the View patient information use case, where a medical receptionist can see some patient information.
  • 21.
  • 22.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING STRUCTURALMODEL Structural models of software display the organization of a system in terms of the components that make up that system and their relationships. Structural models may be static models, which show the organization of the system design, or dynamic models, which show the organization of the system when it is executing.
  • 23.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CLASSDIAGRAM In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects.
  • 24.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CLASSDIAGRAM Purpose of Class Diagrams ● Shows static structure of classifiers in a system ● Diagram provides a basic notation for other structure diagrams prescribed by UML ● Helpful for developers and other team members too ● Business Analysts can use class diagrams to model systems from a business perspective
  • 25.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CLASSDIAGRAM A UML class diagram is made up of: ● A set of classes and, ● A set of relationships between classes
  • 26.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CLASSDIAGRAM What is a Class? ● Structural features (attributes) define what objects of the class "know" ○ Represent the state of an object of the class ○ Are descriptions of the structural or static features of a class ● Behavioral features (operations) define what objects of the class "can do" ○ Define the way in which objects may interact ○ Operations are descriptions of behavioral or dynamic features of a class
  • 27.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CLASSDIAGRAM Class Notation A class notation consists of three parts: ● Class Name - The name of the class appears in the first partition. ● Class Attributes ○ Attributes are shown in the second partition. ○ The attribute type is shown after the colon. ○ Attributes map onto member variables (data members) in code. ● Class Operations (Methods) ○ Operations are shown in the third partition. They are services the class provides. ○ The return type of a method is shown after the colon at the end of the method signature. ○ The return type of method parameters is shown after the colon following the parameter name. ○ Operations map onto class methods in code
  • 28.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CLASSDIAGRAM Class Relationships A class may be involved in one or more relationships with other classes. A relationship can be one of the following types: ● Inheritance ● Simple Association ● Aggregation ● Composition ● Dependency
  • 29.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CLASSDIAGRAM Class Relationships - Inheritance ● Represents an "is-a" relationship. ● SubClass1 and SubClass2 are specializations of Super Class. ● A solid line with a hollow arrowhead that point from the child to the parent class
  • 30.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CLASSDIAGRAM Class Relationships - Simple Association ● A structural link between two peer classes. ● There is an association between Class1 and Class2 ● A solid line connecting two classes
  • 31.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CLASSDIAGRAM Class Relationships - Aggregation A special type of association. It represents a "part of" relationship. ● Class2 is part of Class1. ● Many instances (denoted by the *) of Class2 can be associated with Class1. ● A solid line with an unfilled diamond at the association end connected to the class of composite
  • 32.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CLASSDIAGRAM Class Relationships - Composition A special type of aggregation where parts are destroyed when the whole is destroyed. ● Objects of Class2 live and die with Class1. ● Class2 cannot stand by itself. ● A solid line with a filled diamond at the association connected to the class of composite
  • 33.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING CLASSDIAGRAM Class Relationships - Dependency ● Exists between two classes if the changes to the definition of one may cause changes to the other (but not the other way around). ● Class1 depends on Class2 ● A dashed line with an open arrow
  • 34.
  • 35.
  • 36.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING BEHAVIORALMODELS Behavioral models are models of the dynamic behavior of a system as it is executing. They show what happens or what is supposed to happen when a system responds to a stimulus from its environment. These stimuli may be either data or events: ● Data becomes available that has to be processed by the system. The availability of the data triggers the processing. ● An event happens that triggers system processing. Events may have associated data, although this is not always the case.
  • 37.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING DATA-DRIVENMODELING Data-driven models show the sequence of actions involved in processing input data and generating an associated output. Data-driven models were among the first graphical software models. In the 1970s, structured design methods used data-flow diagrams (DFDs) as a way to illustrate the processing steps in a system.
  • 38.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING DATA-DRIVENMODELING Data Flow Diagrams are simple and intuitive and so are more accessible to stakeholders than some other types of model. It is usually possible to explain them to potential system users who can then participate in validating the model.
  • 39.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING DATA-DRIVENMODELING An alternative way of showing the sequence of processing in a system is to use UML sequence diagrams. You have seen how these diagrams can be used to model interaction, but if you draw these so that messages are only sent from left to right, then they show the sequential data processing in the system.
  • 40.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING EVENT-DRIVENMODELING Event-driven modeling shows how a system responds to external and internal events. It is based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another. For example, a system controlling a valve may move from a state “Valve open” to a state “Valve closed” when an operator command (the stimulus) is received.
  • 41.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING EVENT-DRIVENMODELING This view of a system is particularly appropriate for real-time systems. Event- driven modeling is used extensively when designing and documenting real- time systems. The UML supports event-based modeling using state diagrams, which are based on Statecharts (Harel 1987). State diagrams show system states and events that cause transitions from one state to another. They do not show the flow of data within the system but may include additional information on the computations carried out in each state.
  • 42.
    SOFTWARE ENGINEERING SOFTWARE ENGINEERING EVENT-DRIVENMODELING A state diagram is used to represent the condition of the system or part of the system at finite instances of time. It’s a behavioral diagram and it represents the behavior using finite state transitions.
  • 43.
  • 44.
    FUNDAMENTALS OF DATABASESYSTEMS END OF CHAPTER 6