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
