SWE Lecture 5
System modelling & Design
A General Model of the Design Process
Design Inputs
Platform Information - Details about the operating system, database, and other systems
the software will interact with.
Requirements Specification - A description of the software's functionality and
performance.
Data Description - Information on the data the system will process.
Design Activities
Architectural Design - Defining the overall system structure, its main components,
relationships.
Interface Design - Specifying interfaces between system components.
Component Design - Designing individual system components, detailing their functionality.
Database Design - Designing the system's data structures and how they will be
represented in a database.
Design Outputs
For critical systems, detailed design documents are created with precise descriptions.
In a model-driven approach, outputs are often diagrams.
With agile methods, the design outputs are typically represented in the program's.
The goal of the design process is to create a clear guide that meets all
requirements and addresses the software’s data, functionality, and behavior
for developers, testers, and support teams.
System Modelling
It's the process of developing abstract models of a system.
It's representing the system using some kind of graphical notation.
When to use ?
During requirements engineering to help derive system requirements.
During the design process to describe the system to engineers.
After implementation to document the system's structure and operation.
Models of the existing system clarify its functionality and inform new system
requirements. Models of the new system help explain requirements, guide
design, and can generate system implementation in model-driven engineering.
System Perspectives
1. External perspective: Models the system's context or environment.
2. Interaction perspective: Models interactions between the system and its environment or
its components.
3. Structural perspective: Models the system's organization or the structure of its data.
4. Behavioral perspective: Models the system's dynamic behavior and responses to events.
Usage of Graphical Models
Facilitate discussions about an existing or proposed system.
Document an existing system.
Provide a detailed description for system implementation.
Benifits
Improve communication among stakeholders (users, developers, analysts, etc.).
Validate the system’s architectural design.
Remain independent of specific programming languages and development processes.
Context Model
It shows the environment surrounding a system, including interactions with other automated
systems, but doesn’t specify the exact relationships between them.
It highlights data exchanges.
It's often used alongside other models to provide a fuller understanding of system
interactions.
UML (Unified Modeling Language)
it's a set of over 9 diagram types used to model software systems.
It includes :
1. Use Case diagram
2. Activity diagram
3. Class diagram
4. Sequence diagram
Interaction models
They focus on different types of system interactions:
1. User Interaction: Involves user inputs and outputs, helping identify user requirements.
2. System-to-System Interaction: Highlights communication issues between the system
being developed and other systems.
3. Component Interaction: Helps assess if the system structure will meet performance
and dependability requirements.
Two related approaches for modeling interactions are:
1. Use case modeling: Models interactions between a system and external actors (users
or other systems).
2. Sequence diagrams: Model interactions between system components, including
external agents.
Use Case Modelling
It is widely used for requirements elicitation, describing what users expect from a system.
Each use case represents a specific task or functionality involving external interaction with
the system.
A use case is depicted as an oval, with actors shown as stickman figures ;).
Use case diagrams show interactions between:
Use cases: Representing what the system should do.
Actors: Representing anyone or anything outside the system's scope that interacts
with it (e.g., individuals, groups, or companies).
Actors in a use case diagram include:
Users of the system.
Time.
Other systems.
Use Cases should be named in user-friendly terms and must be meaningful to the
customer.
Association Relationship
Represents the relationship between a use case and an actor.
Every use case must be initiated by an actor, except in the case of use cases involved in
include or extend relationships.
Use case diagrams provide a simple overview of interactions, but more detail is needed to
fully understand what exactly happens. This detail can be provided in the following ways:
A simple textual description (flow of events).
A structured description in a table.
A sequence diagram to show the interaction flow.
Use Case: Flow of Events
It's purpose is to document the flow of logic through the use case.
A use case includes:
1. A brief description.
2. Preconditions.
3. Flow of events.
4. Postconditions
There are three primary users of the flow of events:
1. Customers.
2. System Designers.
3. Quality Assurance Team.
There are three types of flows in a use case:
1. Primary Flow: The "happy day" scenario, representing the most common or successful
path through the use case.
Example: A successful ticket purchase when buying a flight.
2. Alternate Flow: Deviations from the primary flow that are not errors.
Example: A flight may not be available, but this is not an error.
3. Error Flow: Deviations that suggest an error or problem in the system.
Example: The system fails to verify the credit card or check flight availability.
Include & Extend Relationships
Includes relationship allows one use case to use the functionality of another use case.
Extends relationship allows one use case to optionally extend the functionality of another
use case.
Abstract Use Case
An abstract use case is not initiated directly by an actor.
It provides additional functionality that can be used by other use cases.
Abstract use cases typically participate in include or extend relationships with other use
cases.
Generalization Relationship
It's is used to show that several actors are related, typically through a parent-child
relationship.
Sequence Diagrams
It shows the sequence of interactions that take place during a particular use case.
Shows, step-by-step, flows through a use case:
What objects are needed for the flow.
What messages the objects send to each other.
What actor initiates the flow.
What order the messages are sent.
Sequence Diagram users:
Users
Analysts
Developers
Sequence diagrams are interaction diagrams ordered by time
Objects and actors involved are listed along the top of the diagram, with a dotted line
drawn vertically from each.
Interactions between objects are shown with annotated arrows indicating the messages
exchanged.
A rectangle on the dotted line represents the lifeline of the object, indicating the time the
object is involved in the interaction.
The diagram is read from top to bottom.
Alternatives (IF-ELSE)
A box named alt is used with the conditions indicated in square brackets.
Loops
Boundary Classes
Act as interfaces between the system and external actors (users or other systems).
Handle user input and output, providing a way for external systems or users to interact with
the system.
Example: An API interface.
Entity Classes
Represent the core data in the system.
Typically hold the data and business logic related to the system’s main functionality.
Example: A database in an e-commerce system.
Control Classes
Coordinate the flow of data between boundary and entity classes.
Implement system logic and decision-making, controlling the sequence of actions.
Example: A class that handles the process of placing an order, interacting with both
customer data and inventory.
System Sequence Diagram SSD
Purpose of SSD – Helps identify system events and major operations.
Key Elements of SSD – Represents the system as a black box, shows external actors,
system events, and the temporal order of operations.
Example (Process Sale Scenario) – Demonstrates how a sale transaction is processed,
showing interactions between the user and system step-by-step.
