GlurGeek.Com-SE_Lesson09_System Modeling
GlurGeek.Com-SE_Lesson09_System Modeling
Todsapon Banklongsi
Department of Computer Engineering
Bangkok University
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 has now come to mean representing a
system using some kind of graphical notation, which is
now almost always based on notations in the Unified
Modeling Language (UML)
• System modeling helps the analyst to understand the
functionality of the system and models are used to
communicate with customers
2
Existing and planned system models
• Models of the existing system are used during requirements
engineering. They help clarify what the existing system
does and can be used as a basis for discussing its strengths
and weaknesses. These then lead to requirements for the
new system.
• Models of the new system are used during requirements
engineering to help explain the proposed requirements to
other system stakeholders. Engineers use these models to
discuss design proposals and to document the system for
implementation.
• In a model-driven engineering process, it is possible to
generate a complete or partial system implementation from
the system model.
3
Software Modeling
User Modeling
Requirement (Analysis and Design)
Modeling
- Analysis and Design
Model
- Visual Modeling
(Specification)
Tools Manually
Coding
Program
4
Software Development Process
5
Software modeling and models
• Software modeling helps the engineer to
understand the functionality of the system
• Models are used for communication among
stakeholders
• Different models present the system from
different perspectives
– External perspective showing the system’s context or
environment
– Process models showing the system development process
as well as activities supported by the system
– Behavioural perspective showing the behaviour of the
system
– Structural perspective showing the system or data
architecture
6
System Model
http://www.omgsysml.org/INCOSE-OMGSysML-Tutorial-Final-090901.pdf 7
System perspectives
• An external perspective, where you model the context
or environment of the system
• An interaction perspective, where you model the
interactions between a system and its environment, or
between the components of a system.
• A structural perspective, where you model the
organization of a system or the structure of the data
that is processed by the system
• A behavioral perspective, where you model the dynamic
behavior of the system and how it responds to events
8
Product Engineering Hierarchy
System
Human Hardware Software Database Component
Engineering Engineering Engineering Engineering Engineering
Function
Data and
Behavior
Analysis
Classes Modeling
Construction
9
Analysis Modeling
The Analysis Model is the first technical representation of a system.
Analysis modeling uses a combination of text and diagrams to represent
software requirements (data, function, and behavior) in an understandable
way.
System
Description
Analysis
Model Design
Model
10
The Analysis Model
11
Analysis Modeling Approaches
12
Types of Analysis Model
1. Structural Analysis or 2. Object Oriented Analysis or
Non-UML System Modeling Methods UML System Modeling Methods
Process Model (process-driven systems) Structural Diagram
- Data Flow Diagram (DFD) - Class Diagram
- Flowcharts - Object Diagram
- Structure Charts - Component Diagram
- Decision Table, Decision Tree - Deployment Diagram
Data Model (data-driven systems) Behavioral Diagram
- Entity Relationship Diagram - Use Case Diagram
(ER Diagram) - Sequence Diagram
- Data Dictionary - Activity Diagram
- Warneir Diagram - Collaboration Diagram
Control-Oriented Methods (real-time
- State Diagram
systems)
- State Transition Diagrams (STD)
13
Structural Analysis
• Structured analysis: the focus is only on process and procedures.
Modeling techniques used in it are DFD(Data Flow Diagram),
Flowcharts etc.
• Structuring system process requirements
– Data flow diagrams (DFD) - process modeling
– Context diagram
– Process decomposition (DFD levels): 4 types of DFD:
• Current physical: adequate detail only
• Current logical: enables analysts to understand current system
• New logical: technology independent, show data flows, structure, and
functional requirements of new system.
• New physical: technology dependent.
– Logical modeling: using structured English, decision table/tree
– Structuring system data requirements: using ER diagram
14
Data Flow Diagram : DFD
15
Data Flow Diagram : DFD
16
Data Flow Diagram : DFD
2. Data Flow
17
Data Flow Diagram : DFD
a ‘D’ used to represent a
computer data
3. Data Store
a ‘M’ used to represent manual
data stores
18
Data Flow Diagram : DFD
4. External Entity
External Entity
19
Data Flow Diagram : DFD
Diagram Layering and Process Refinement
Context-level diagram
(DFD Level 0)
Process Specification 20
Context Diagram (DFD Level 0)
Customer Kitchen
• Highest level view of the
P
system
Food Ordering
• Contains ONLY one process,
i.e., the “system”
Customer Order Food Order
System
• (“electronic” or “manual”)
And all data flows between
Reports
•
Restaurant data sources/sinks and the
Manager
process
• It contains NO data stores
21
DFD Level 1
DFD Level 1 Diagram - Food Ordering System
Kitchen
• Expands the main
Customer
Customer Order process from
context diagram
Receipt
P1 • Represents the
Receive &
Transf Cust Food Order
system’s major
Food Ord processes
• Which are the
P2 P3
primary individual
processes at the
Update Goods Inventory Data Update
Sold File Goods Sold Inventory File
highest possible
level
This is called
Formatted Goods Sold Data Formatted Inventory Data
•
“functional
D Goods Sold File Daily Goods Sold Amounts D1 Inventory File
P4
decomposition”
Restaurant Produce
Manager Management Reports Management
Reports
Reports
Daily Inventory Depletion Amts
22
DFD Level 2
(DFD Level 1 of Process 1)
DFD Level 2 Diagram (DFD Level 1 of P1)- Food Ordering System
Customer Order 1
P1.1 Customer Order 5 P1.5 P3
Customer
Receive Generate Update
Customer Order Inventory Decr Inventory Data Inventory File
Customer Order 2
Receipt
Customer Order 4 Customer Order 3
Goods Sold
P2
Update Goods
Sold File
23
Entity Relationship Diagram (ERD)
• An entity-relationship diagram (ERD) is a graphical representation of an
information system that shows the relationship between people, objects,
places, concepts or events within that system. An ERD is a data modeling
technique that can help define business processes and can be used as the
foundation for a relational database.
24
Entity Relationship Diagram (ERD)
25
Entity Relationship Diagram (ERD)
http://www.conceptdraw.com/How-To-Guide/picture/Design_Elements(Chen-ERD).png 26
Entity Relationship Diagram (ERD)
1:1= one to one
1:N = one to many
N:M = many to many
27
Object Oriented Analysis
• In the system analysis or object-oriented analysis phase of
software development, the system requirements are determined,
the classes are identified and the relationships among classes are
identified
• A semiformal analysis technique for object-oriented paradigm
Structuring system process requirements
28
The Unified Modeling Language
• Devised by the developers of object-oriented analysis and design methods
• Has become an effective standard for software modelling
UML-Structural Diagram
• Class diagrams, which show the object classes in the system and the
associations between these classes.
• Object diagrams is a graph of instances, including objects and data
values. A static object diagram is an instance of a class diagram; it shows
a snapshot of the detailed state of a system at a point in time. The use
of object diagrams is fairly limited, namely to show examples of data
structure.
• Component diagrams illustrate the pieces of software, embedded
controllers, etc., that will make up a system. A component diagram has a
higher level of abstraction than a Class Diagram - usually a component is
implemented by one or more classes (or objects) at runtime. They are
building blocks so a component can eventually encompass a large portion
of a system.
• Deployment diagrams depicts a static view of the run-time configuration
of processing nodes and the components that run on those nodes. In
other words, deployment diagrams show the hardware for your system,
the software that is installed on that hardware, and the middleware used
to connect the disparate machines to one another. 30
Class Diagrams
• Class diagrams are used when developing an object-
oriented system model to show the classes in a system
and the associations between these classes
• An object class can be thought of as a general
definition of one kind of system object
• An association is a link between classes that indicates
that there is some relationship between these classes.
• When you are developing models during the early
stages of the software engineering process, objects
represent something in the real world, such as a
patient, a prescription, doctor, etc.
31
Class Diagram
แสดงโครงสร้ างหยุดนิ่งของระบบในลักษณะความสัมพันธ์ ระหว่ างคลาส
32
Class Diagram
Visibility
Use visibility markers to signify who can access the information contained within a class. Private visibility hides
information from anything outside the class partition. Public visibility allows all other classes to view the marked
information. Protected visibility allows child classes to access information they inherited from a parent class.
33
Class Diagram - Relationship
2) Binary Relationship เป็ น
1) Unary Relationship เป็ นความสัมพันธ์
ความสัมพันธ์ ทเี่ กิดขึน้ ระหว่ างคลาส 2 คลาส เช่ น
ทีเ่ กิดกับคลาสเดียว เช่ น หัวหน้ าห้ องของนักศึกษาแต่ ละคน
ความสัมพันธ์ ระหว่ างคลาส “นักศึกษา” กับ คลาส “คณะ
วิชา” ซึ่งสัมพันธ์ กนั โดยความสัมพันธ์ “สังกัด”
34
Class Diagram
35
Class Diagram
http://creately.com/blog/diagrams/uml-diagram-types-examples/ 36
Class Diagram –
Relations between Classes
Association
Aggregation
Composition
Inheritance/Generalization
37
Class Diagram – Association
38
Class Diagram – Multiplicity
39
Class Diagram – Aggregation
• An aggregation model
shows how classes that
are collections are
composed of other classes
• Aggregation models are
similar to the part-of
relationship in semantic
data models
40
Class Diagram – Composition
Composition is a strong form of association in which the ‘part’ objects are
dependent on the ‘whole’ objects.
1. a ‘part’ object can only belong to one composite at a time,
2. when a composite object is destroyed, all its dependent part must be
destroyed at the same time .
41
Class Diagram –
Inheritance/Generalization
Generalization is an everyday
technique that we use to
manage complexity
Rather than learn the detailed
characteristics of every entity
that we experience, we place
these entities in more general
classes (animals, cars, houses,
etc.) and learn the
characteristics of these
classes
This allows us to infer that
different members of these
classes have some common
characteristics, e.g. squirrels
and rats are rodents
42
Class Diagram – Generalization
• In modeling systems, it is often useful to
examine the classes in a system to see if
there is scope for generalization. If
changes are proposed, then you do not
have to look at all classes in the system to
see if they are affected by the change.
• In object-oriented languages, such as
Java, generalization is implemented using
the class inheritance mechanisms built
into the language
• In a generalization, the attributes and
operations associated with higher-level
classes are also associated with the
lower-level classes
• The lower-level classes are sub-classes
that inherit the attributes and operations
from their super-classes. These lower-
level classes then add more specific
attributes and operations.
43
Class Diagram –
Generalization and Specialization
44
Class Diagram
45
Object Diagram
Object diagrams are also closely linked to class diagrams. Just as an object is an
instance of a class, an object diagram could be viewed as an instance of a class diagram.
Object diagrams describe the static structure of a system at a particular time and they
are used to test the accuracy of class diagrams.
46
Object Diagram
Active object
Objects that control action flow are called active objects.
Illustrate these objects with a thicker border.
Multiplicity
You can illustrate multiple objects as one symbol if the
attributes of the individual objects are not important.
Links
Links are instances of associations. You can
Self-linked
draw a link using the lines used in class
Objects that fulfill more than one role can be self-
diagrams.
linked. For example, if Mark, an administrative
assistant, also fulfilled the role of a marketing
assistant, and the two positions are linked, Mark's
instance of the two classes will be self-linked.
47
Object Diagram
48
Component Diagram
A component diagram could represent
- Logical Components (e.g., business components, process components), and
- Physical Components (e.g., CORBA components, EJB components, COM+ and .NET components,
WSDL components, etc.),
Port
Ports are represented using a square
along the edge of the system or a
component. A port is often used to
help expose required and provided
interfaces of a component.
49
Component Diagram
50
Deployment Diagram
Deployment diagrams depict the physical resources in a system
including nodes, components, and connections. (Hardware and Software)
แสดงการนําโปรแกรมที่พฒ
ั นาไปติดตั้งในฮาร์ ดแวร์ ในระบบ
Component
A node is a physical resource that executes code components.
Association
Association refers to a physical connection between nodes,
such as Ethernet.
51
Deployment Diagram
http://www.conceptdraw.com/How-To-Guide/picture/Design-elements-UML-deployment-diagrams.png 52
Deployment Diagram
53
Deployment Diagram
http://www.uml-diagrams.org/deployment-diagrams-overview.html 54
UML-Behavioral Diagram
• Use case diagrams, which show the interactions between a system
and its environment
• Sequence diagrams, which show interactions between actors and
the system and between system components
• Activity diagrams, which show the activities involved in a process
or in data processing
• Collaboration Diagram or Communication Diagrams like UML
sequence diagrams, are used to explore the dynamic nature of
your software. Collaboration diagrams show the message flow
between objects in an OO application, and also imply the basic
associations (relationships) between classes.
• State diagrams, which show how the system reacts to internal and
external events
55
Use Case Diagrams
• Use Case Diagrams gives a graphic overview of the actors involved in a
system, different functions needed by those actors and how these
different functions are interacted.
• Use cases were developed originally to support requirements elicitation
and now are incorporated into the UML
• Each use case represents a discrete task that involves external
interaction with an actor
• Actors in a use case may be people or other systems
ปฏิสัมพันธ์ ระหว่างผู้ใช้ ภายนอกและฟังก์ชันการทํางานหลักภายในระบบ
- Use cases are represented as the horizontally shaped ovals and display the different uses.
- Actors are the people that employ the use cases and are represented on the diagram as figures of persons.
Actors cannot be related each to other (except relations of generalization/inheritance).
- Associations are shown as lines between actors and use cases.
- System boundary – the box with the name and ovals (use cases) inside that sets a system scope to use
cases.
- Packages that allow you to add the elements in groups.
56
Use Case Diagrams
57
57
Use Case Diagrams
Actor - a role that an Association - an Use Case -the interaction between
outsider takes on when actor and a business an actor and a business system,
interacting with the use case meaning it describes the functionality
business system. of the business system
58
Use Case Diagrams
59
Sequence Diagrams
• Sequence diagrams are part of the UML and are used
to model the interactions between the actors and the
objects within a system
• A sequence diagram shows the sequence of
interactions that take place during a particular use
case or use case instance
• The objects and actors involved are listed along the
top of the diagram, with a dotted line drawn vertically
from these
• Interactions between objects are indicated by
annotated arrows
60
Sequence Diagrams
Sequence diagrams describe interactions among classes in terms of an exchange
of messages over time.
Activation
Activation boxes represent the time an object needs
to complete a task.
61
Sequence Diagrams
Messages
Messages are arrows that represent communication between objects. Use half-arrowed
lines to represent asynchronous messages. Asynchronous messages are sent from an
object that will not wait for a response from the receiver before continuing its tasks.
Lifelines
Lifelines are vertical dashed lines that
indicate the object's presence over time.
62
Sequence Diagrams
Destroying Objects Loops
Objects can be terminated early using an arrow A repetition or loop within a sequence diagram is
labeled "<< destroy >>" that points to an X. depicted as a rectangle. Place the condition for
exiting the loop at the bottom left corner in
square brackets [ ].
63
Sequence diagram for
View patient information
64
Sequence Diagrams
65
Activity Diagram
An activity diagram illustrates the dynamic nature of a system by modeling the flow of
control from activity to activity. An activity represents an operation on some class in the system
that results in a change in the state of the system. Typically, activity diagrams are used to model
workflow or business processes and internal operation. Because an activity diagram is a special
kind of state chart diagram, it uses some of the same modeling conventions.
Action Flow
Action flow arrows illustrate the relationships among action states.
Object Flow
Object flow refers to the creation and modification of objects by
activities. An object flow arrow from an action to an object means that
the action creates or influences the object. An object flow arrow from
an object to an action indicates that the action state uses the object.
66
Activity Diagram
Initial State
A filled circle followed by an arrow represents the initial action state.
Final State
An arrow pointing to a filled circle nested inside another circle represents the final
action state.
Synchronization
Branching A synchronization bar
A diamond represents a helps illustrate parallel
decision with alternate transitions.
paths. The outgoing Synchronization is also
alternates should be called forking and
labeled with a condition joining.
or guard expression. You
can also label one of the
paths "else."
Swimlanes
Swimlanes group related activities into one column.
67
Activity Diagram
68
Process model of involuntary
detention
69
Collaboration Diagram
A collaboration diagram or Communication Diagrams like UML sequence diagrams, are used
to explore the dynamic nature of your software. Collaboration diagrams show the message flow
between objects in an OO application, and also imply the basic associations (relationships)
between classes.
แสดงการปฏิสัมพันธ์ ระหว่ างออบเจ็กต์ โดยไม่ มีลาํ ดับของเวลาเข้ ามาเกีย่ วข้ อง
Class roles
Class roles describe how objects behave. Use the UML object
symbol to illustrate class roles, but don't list object
Association roles
attributes.
Association roles describe how an association will
behave given a particular situation. You can draw
association roles using simple lines labeled with
stereotypes.
Messages
Unlike sequence diagrams, collaboration diagrams do not have an
explicit way to denote time and instead number messages in order of
execution. Sequence numbering can become nested using the Dewey
decimal system. For example, nested messages under the first
message are labeled 1.1, 1.2, 1.3, and so on. The a condition for a
message is usually placed in square brackets immediately following the
sequence number. Use a * after the sequence number to indicate a
loop.
70
Collaboration Diagram
71
State Diagram
A state diagram shows the behavior of classes in response to external stimuli. This
diagram models the dynamic flow of control from state to state within a system.
States
States represent situations during the life of an object. You can easily
illustrate a state by using a rectangle with rounded corners.
Transition
A solid arrow represents the path between different states of an
object. Label the transition with the event that triggered it and the
action that results from it.
Initial State
A filled circle followed by an arrow represents the object's initial
state.
Final State
An arrow pointing to a filled circle nested inside another circle
represents the object's final state.
72
State Diagram
Synchronization and Splitting of
Control
A short heavy bar with two transitions entering it
represents a synchronization of control. A short heavy
bar with two transitions leaving it represents a splitting
of control that creates multiple states.
73
State Diagram of a microwave oven
74
Microwave oven operation
75
States and stimuli for the
microwave oven (a)
State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ‘Half power’.
Full power The oven power is set to 600 watts. The display shows ‘Full power’.
Set time The cooking time is set to the user’s input value. The display shows
the cooking time selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on.
Display shows ‘Not ready’.
Enabled Oven operation is enabled. Interior oven light is off. Display shows
‘Ready to cook’.
Operation Oven in operation. Interior oven light is on. Display shows the timer
countdown. On completion of cooking, the buzzer is sounded for five
seconds. Oven light is on. Display shows ‘Cooking complete’ while
buzzer is sounding.
76
States and stimuli for the
microwave oven (b)
Stimulus Description
Half power The user has pressed the half-power button.
77
References
78