0% found this document useful (0 votes)
15 views

GlurGeek.Com-SE_Lesson09_System Modeling

System modeling is the process of creating abstract representations of a system, often using graphical notations like UML, to aid understanding and communication among stakeholders. It involves both existing and planned system models to clarify requirements and facilitate design discussions. Various modeling approaches, including structural and object-oriented analysis, are utilized to define system functionality and relationships among components.

Uploaded by

drwalkrzysztof
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views

GlurGeek.Com-SE_Lesson09_System Modeling

System modeling is the process of creating abstract representations of a system, often using graphical notations like UML, to aid understanding and communication among stakeholders. It involves both existing and planned system models to clarify requirements and facilitate design discussions. Various modeling approaches, including structural and object-oriented analysis, are utilized to define system functionality and relationships among components.

Uploaded by

drwalkrzysztof
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 78

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

• Requirement Specification : define problem domain


• Analysis : what problem to be solved?
• Design : how to solve the problem?
• Implementation : how to implement the solution?
• Testing : how to ensure that the solution can solve the
problem?
• Maintenance : how to adjust the solution to accomodate
change?
• Retirement : when does the system to be retired?

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

Product Requirements Engineering

System
Human Hardware Software Database Component
Engineering Engineering Engineering Engineering Engineering

Function
Data and
Behavior
Analysis
Classes Modeling

Data/Class Architectural Interface Component Design


Design Design Design Design 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

1. Process This might be a


physical location or
the staff
responsible.

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)

DFD Level 1 diagram

DFD Level 2 diagram

Process Specification 20
Context Diagram (DFD Level 0)

DFD Context Diagram - Example Food Ordering System

Customer Kitchen
• Highest level view of the
P
system
Food Ordering
• Contains ONLY one process,
i.e., the “system”
Customer Order Food Order
System

• It also shows all external


data sources/sinks
Receipt

• (“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

P1.2 P1.4 P1.3


Generate Generate Transform Food Order Kitchen
Customer Goods Sold Order to
Receipt Incr Kitchen Fmt

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.

Entity-Relationship Diagrams Database Structure Diagrams

24
Entity Relationship Diagram (ERD)

25
Entity Relationship Diagram (ERD)

Strong entity คือเกิดขึ้นด้วยตนเองไม่ Weak entity คือขึ้นโดยอาศัย entity


ขึ้นกับ entity ใด เช่น นักศึกษา หรื อ อาจารย์ อื่น เช่น เกรดเฉลี่ย ที่มาจากแฟ้ มผลการเรี ยน หรื อ
หรื อสิ นค้า เป็ นต้น สิ่ งต่าง ๆ ที่ผใู ้ ช้งานฐานข้อมูลจะต้องยุง่ เกี่ยวด้วย
เช่น คน แผนก ประเภท การสัง่ ซื้อ

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 คลาส เช่ น
ทีเ่ กิดกับคลาสเดียว เช่ น หัวหน้ าห้ องของนักศึกษาแต่ ละคน
ความสัมพันธ์ ระหว่ างคลาส “นักศึกษา” กับ คลาส “คณะ
วิชา” ซึ่งสัมพันธ์ กนั โดยความสัมพันธ์ “สังกัด”

3) Ternary 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.

แสดงโครงสร้ างหยุดนิ่งของระบบในลักษณะความสัมพันธ์ ระหว่ างออบเจ็กต์


Object names Object attributes
Each object is represented as a rectangle, which contains As with classes, you can list object attributes in a
the name of the object and its class underlined and separate compartment. However, unlike classes, object
separated by a colon. attributes must have values assigned to them.

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.),

แสดงองค์ประกอบหรือไฟล์ จริงของระบบ (เช่ นไฟล์ exe และ dll)ที่ออกแบบและสถานที่เก็บ


Component
A component is a physical building block Interface Dependencies
of the system. It is represented as a
An interface describes a group Draw dependencies among
rectangle with tabs. of operations used or created components using dashed
by components. arrows.

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.

Components and Nodes


Place components inside the node that deploys them.

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

Actor - a role that


an outsider takes on
when interacting
with the business
system.

Association - an actor and


a business use case

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

System Boundary - Include relationship - a


provides use case relationship between two
containment behavior. business use cases that
signifies that the business
use case on the side to
which the arrow points is
included in the use case on
the other side of the
arrow. (provides, another
functionality 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.

แสดงการปฏิสัมพันธ์ ระหว่ างออบเจ็กต์ สําหรับแต่ ละ Use Case โดยมีลาํ ดับของเวลาด้ วย


Class roles
Class roles describe the way an object will behave in context. Use the UML object symbol to
illustrate class roles, but don't list object attributes.

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.

แสดงกระบวนการทํางานทางธุรกิจ หรือแสดงปฏิสัมพันธ์ ของกลุ่มของออบเจ็กต์ เพือ่ แสดง


ลําดับการไหลและกิจกรรมของแต่ ละ Use Case หรือกิจกรรมของหลายคลาส
Action states
Action states represent the noninterruptible actions of objects.

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.

Lift State Diagram

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.

Full power The user has pressed the full-power button.


Timer The user has pressed one of the timer buttons.

Number The user has pressed a numeric key.


Door open The oven door switch is not closed.
Door closed The oven door switch is closed.
Start The user has pressed the Start button.
Cancel The user has pressed the Cancel button.

77
References

- Ian Sommerville, Software Engineering, 10th Edition


Pearson Education, Addison-Wesley, 2015.
- Roger S. Pressman and Bruce R. Maxim. Software
Engineering a Practitioner’s Approach. Eighth Edition.
McGraw-Hill, 2014.
- Ivan Marsic. Software Engineering. 2012.
- John Satzinger, Robert Jackson and Stephen Burd.
Systems Analysis and Design in a Changing World.
Sixth Edition. Course Technology, 2012.

78

You might also like