System Modeling with UML Diagrams

System Modeling

• After completing the course on system modeling, students should be able to explain analysis and design models using the Unified Modeling Language (UML).
• Students should also learn to develop UML diagrams during the software analysis and design stages.
• UML diagrams can be drawn manually, or created using CASE tools, there are options to consider when deciding which CASE tool your group will use.

Topics Covered

• Introduction to System Modeling
• Context models
• Interaction models
• Structural models
• Behavioral models

What is a Model?

• A model is an abstract representation of something real
• A useful model has the right level of detail, representing only what's important to the task
• Many things can be modeled, including bridges, buildings, economic policies, and software

System Modeling Details

• System modeling is the process of developing model-based requirements
• Each model presents a different view or perspective of the system
• Helps to find missing or inconsistent functionality
• Model-based requirements reduce ambiguity
• Used to communicate with customers
• A system model holds the right level of details by only representing what is important for software development using a System Modeling Language.

System Modeling Languages

• UML (Unified Modeling Language) is used, among other modelling languages, for software architecture.

What is UML?

• UML consists of an integrated set of diagrams to express the design of a system in different perspectives.
• The requirements engineer elicits user requirements from stakeholders to document model-based requirements using UML.

Models and Diagrams

• A model may consist of a single diagram or consist of many related diagrams.
• Each model presents a different view or perspective of the system.

Object-Oriented Modeling

• Context Model
• Interaction Model
• Behavioral Model
• Structural Model

Procedural Modeling

• Context Diagram

What is a Diagram?

• Abstract symbols/signs/notations are used to represent things or actions from the real world
• Diagrams follow rules or standards to ensure that different people will interpret them in the same way

Diagrams in SRS

• Diagrams in Software Requirements Specification broken down by Procedural Modeling and Object-Oriented Modeling

Procedural Modeling

• Context Diagram (also known as Data Flow Diagram Level-0)

Object-Oriented Modeling

• UML Use Case Diagram
• UML Activity Diagram
• UML Sequence Diagram
• UML Class Diagram
• UML State Diagram

Case Study: Car Park Management System (CPMS)

About the System

• Customers and parking attendants register accounts and log in to access the system
• Customers can manage debit/credit card information
• When a customer enters or exits parking, an external system called the 'Vehicle Number Recognition System' will provide the license plate number and entry/exit times to CPMS
• CPMS calculates the total fee when the customer exits the parking area
• A customer who pays with a debit or credit card will be managed by a "Payment Processing System"
• Parking attendants can delete customer accounts

Context Diagram

• Represents the software being developed, external entities interacting with the software, and data flowing between the software and external entities
• There should be one context diagram for one software

Steps to Draw a Context Diagram

Step 1

• Write the software name and draw a circle around it

Step 2

• Write down external entities and enclose each one in a rectangle
  • Human users who interact with the software
  • External software integrated with the system
  • Every external entity must be a noun

Step 3

• Identify the data flowing from your software to an external entity and use an arrow to represent the direction
  • Every data must be a noun

Step 4

• Identify the data flowing from an external entity to your software and use an arrow to indicate the direction.

Context Diagram for Car Park Management System

• Includes customer with username, password, vehicle plat number, vehicle color and credit card number
• System boundary, parking management system provides removal ID, and Total Fee
• Parking attendant provides customer details, and also receives online payment status through payment processing system
• Includes Vehicle Number Recognition System, receiving the license plate, enter time, and exit time.

System Boundary

• Defines what is inside the system
• Identify the data that flows in and out between external entities and the system boundary.

Interaction Model

• UML Use Case Diagram

UML Use Case Diagram

• Shows the interactions between a system and its actors
• Actors in a use case may be people or external systems
• There is only one UML Use Case Diagram for one software

UML Use Case Diagram Details

• Demonstrates the high-level functional requirements of the software from the user's perspective using use case notation

Usecase Notation Details

• Is drawn as ellipses with a name in or below each ellipse
• Represents a major piece of system functionality
• The name must begin with a verb, followed by a noun
• The name starts with lower case
• Every use case in a use case diagram may have a unique ID (optional)
• Must have unique names
• Follows a [verb] [noun] format

Example Usecases

• Register account
• Login

Tips for Usecases

• One use case should have 3 to 12 actions within it

Diagram Limitations

• The size of a use case should only have 3 to 12 actions within it.
• A use case should not be too small or too big

UML Use Case Diagram- System Boundary

Considerations

• Documents the scope of the software using system boundary notation
• A rectangle around a group of use cases that belong to the same software to represent the software’s scope
• Every system boundary must have the system name written in the top-middle

UML Use Case Diagram - Actors

• The diagram shows different kinds of actors that interact with the software

Actors

• Drawn as stick people with a name (be specific and avoid naming as ‘user’)
• Actors are outside the system boundary
• Can be people or external systems that interact with a particular use case or use cases
• If two job titles need to interact with the exact same set of use cases, combine those 2 job titles into 1 actor.

UML Use Case Diagram - Association Notation

• Shows which actors are interacting with which use case, using association notation
• Links an actor with the use case(s) with which they interact

UML Use Case Diagram - Include Relationship

• Purpose: a use case need to be reused by other use case OR if you want to highlight the feature to user OR the action is done by another actor. using <> or <> notation.

• <> means, it is MANDATORY to use the actions in the included use case, in order to achieve objective of the base use case

• <> means, it is OPTIONAL to use the actions in the extending use case, in order to achieve objective of the base use case

• Car Park Management System use case where a customer needs to register account, login, pay with debit/credit card, and delete customer account

• System must manage debit/credit card information.

• 'include' and 'extend' are also displayed

UML Use Case Diagram Specifics

• Every time a customer or parking attendant logs into the system, it is mandatory for the system to perform multi-factor authentication
• A Customer can manage debit/card information to add, edit, or delete card details
• The customer can access the "Manage Debit/Credit Card" feature via a button or link in the menu after logging in
• Additionally, when a customer receives the total parking fee and proceeds with payment using a debit/credit card, they will have the Option to Manage their Card information during this process.

UML Use Case Diagram - Actor Generalization

• Both Customer and Parking Attendant are Actors.
• They inherit the action of a User
• However, each has extra specialization that they can do
• If two job titles need to interact with the exact same set of use cases, combine those 2 job titles into 1 actor.