L5 – System Modelling

Monday, March 27, 2023 1:12 PM

• In requirements we check what requirements to build upon and make

an SRS
• System modelling is useful in this aspect

System Modelling

• Sometimes it may easy to straight away to start coding the solution

• But when there are complex problems, it may be needed to document
everything, especially if the documentation is long
○ For the both the developers and the users to understand the
system
• In a system model, they provide different views and perspectives of the
system
○ In such causes we select the perspective we want to build on
depending on the problem

○ UML is good to help developers understand

○ A use-case diagram to help users understand the system
implementation
 • So it is good to draw models of the old and find the good and bad
○ Which can help understand the requirements based on what
should be maintained and what isn't implemented

• A model diagram can help see where the issues can come up due to an
issue that occurs

• A model helps give an understanding even though it may not be

accurate
○ These can help lead to discussions to build a better model
• But for documentation
○ It should be accurate and correct but it may not be complete and
will take time to complete it until implementation
○ Or if we were looking at a certain aspect of the model only, it is
sufficient only covering that only
• When implementing it should be correct and complete

System Perspectives

• Multiple system perspectives are needed to give a definitive plan of

how the system should implementation and reduces ambiguity of the
system
• External
○ With the environment
• Interaction
○ Between the components
• Structural
○ How the system is structural
• Behavioral
○ How the various components are working together
Context Models
External Perspective

○ For example, the system implementation maybe limited to some

different extents and boundaries
▪ Like Financial payments which need to be physical,
• It wouldn't fall under the perview of the project and it will
only need a system to interact to it

Example:

• Context model shows what are the external components that interact
with the system

Process Perspective

• Unlike the context perspective, process perspective looks at the

interactions with external systems

Example: An activity diagram

 • This shows which activities the system needs to look with in the
environment and work with

<<Nadun's Kuppi>>
• In addition to the Context Diagram, we explain the processes that
happen between classes
• Process Diagram can have branching which works as If conditions and
which way they need to move

Interaction Models

• There may be multiple forms of interactions we need to account for

○ User
▪ Useful to identify their requirements
○ Between systems
▪ Highlights the communication problems that may arise
○ Between components
▪ Within the system and check if the overall system can perform
to the requirements and whether it is dependable

Use-Case and Sequence Diagrams can be used for this purpose

Use Case Modelling

Example: Shows how the data is transferred in between in a high level

A more descriptive method can be given using a tabular method

A more comprehensive one can be given by showing the different use cases
we can do
Sequence Diagram

• Shows how the interactions go about within the system with the users
• The step-by-step interaction from one component to the other and
which functions it should call

Example:

• The vertical axis shows the time as going down

• The vertical blocks shows the time when that particular object is in
scope of the problem
• The stick figures act as the external objects

Structural Models

<<< Check Class Diagrams and related >>>

<<Nadun's Kuppi>>
• It may be sufficient to show the connection of the class names only and
there cardinality (whether there are 1 to 1 or so)
Behavioral Models

• Unlike the Structural models, this looks at how it works with

inputs/stimuli such as data or events from the environment
• Important in real-time or embedded systems

1. Data-Driven Modelling

○ Data-Flow diagrams is an intuitive way of describing how the

system works as it processes input data

• Need to draw activity and data alternatively to each other

○ Get the data
○ Do something to do the data

2. Event Driven Modelling

• Both internal(between components) and external events can be

considered

State Machine Models

 • As events happen the system changes its state
Eg:

Model-Driven Models

• In model driven, more focus is given on the models rather than the
executable program
Pros
• Rather than thinking about the code itself, we can look at the more
formal aspects of the program
• Easy to implement on different platforms for a short time

Cons
• This method is good for abstraction but may not be accurate to
implement
• The costs of moving to different implementations need to be
considered

Model Driven Architecture

How the Model driven architecture is being built