System Modelling with UML Diagrams

• System modelling develops abstract models, each showing a different viewpoint of the system.
• A complete or partial system implementation can come from the system model.
• Unified Modelling Language (UML) is a standard language to specify, model, visualize, construct, and document software systems.

System Modelling Benefits

• Facilitates communication among users, developers, analysts, testers, managers involved in the project
• Helps explore potential designs.
• Validates the architectural design of the software.
• Remains independent of particular programming languages and development processes

UML Diagram Types

• Activity diagrams illustrate activity flow in a process or data processing.
• Use case diagrams show interactions between a system and its environment.
• Sequence diagrams detail interactions between actors, the system, and system components.
• Class diagrams display object classes within the system and their associations.
• State diagrams illustrate how the system reacts to internal and external events.

Use of Graphical Models

• Use as a discussion starter for proposed systems, where incomplete models work.
• Use to document existing systems, requiring accurate models which might be incomplete.
• Use as a detailed system description to generate a system implementation, models must be correct and complete.

Interaction Models

• Utilizes use case and sequence diagrams for interaction modelling.
• Use case models and sequence diagrams present interaction at varying detail levels and can be used together.
• Sequence diagrams document involved interactions in a high-level use case.

Use Case Modelling

• Use cases originally supported requirements elicitation from stakeholders interacting with the system.
• Each use case represents a discrete task involving interaction with an external system.
• Focus on automated processes.
• Use Case diagrams does not convey the execution order of use cases.
• Use case names should begin with a verb.

Use Cases

• Diagrams offer a simple interaction overview, requiring further details to understand the involvement.
• This involves a textual description, structured table description, or sequence diagram can provide further detail.

Use Case Actor

• A use case includes 2 actors: an operator transferring data and the patient record system.
• The operator transfers data and the patient record system.

Use cases for actor ‘Medical Receptionist’

• The medical receptionist registers the patients, views their information and transfers the data.
• The medical receptionist is able to contact the patients in case of emergencies.

Use Case Actors

• Three types of actors are: users, other systems, and time triggers.
• Users are physical people or users who directly use the system.
• Other systems interact with the system being built.
• Time triggers define when the passing of a certain amount of time evokes an event out of control.

Relationships in Use Cases

• Association: Establishes the relation between a use case and an actor.
• Include: Allows one use case to utilize functionality of another.
• Extend: Grants a use case the option to extend functionality provided by another one.
• Generalization: Specifies an allowed relation between actors.

Association Relationship

• Connects use case and actor only.
• Each use case should be started by an actor, except abstract use cases.

Include Relationship

• A use case utilizes functionality from another use case in 2 scenarios: if multiple use cases have an identical functionality or if one has a large functionality amount.
• Use case includes one functionality provided from others
• While the “Make Reservation" use case is running, "Check Credit" must run.

Extend Relationship

• A use case conditionally expands another's functionality
• During a "Change Reservation" use case, "Check Credit" runs only if reservation amount changes. Otherwise, it does not need to run.
• Arrow from the optionally run use case ("Check Credit") targets the being extended use case ("Change Reservation").

Abstract Use Cases

• Abstract use case is never started directly by the actor.
• Abstract use case contains functionalities for other use cases.
• Abstract use cases involve include/extend relationships.

Generalization

• Consolidates individual entities into general classes, learning characteristics of these general classes.
• Generalization is indicated by an arrow pointing to the general class.
• High-level class attributes/operations correlate with lower-level classes.
• Lower-level classes are subclasses inheriting superclass attributes/operations, adding specific attributes and operations.

For example

• You may have two types of students.
• If the type A students will initiate some use cases that type B students will not, its probably worth including the actor generalizations.
• If both types of students use the same use cases, its probably not necessary to show an actor generalization.

Check List

• Check if each functional requirement is present in at least one use case, or it will not be implemented.
• You should determine how can each end user interacts with the system.
• Check what information each end user is providing for the system.
• Check what information each end user will be receiving from the system.
• Ensure that you have considered maintenance issues: system startup and shutdown.
• All the external systems for the system should be identified to work with them.
• Specify what information each external system provides and receives from the system.

Diagrams

• The actor is who uses the SW directly.
• Example: if a student needs the grade report with the student affairs department, the employee is the actor.

Functionalities

• Every use case should be a main functionality.
• Its wrong to list “select seat”, “enter User name” as use cases
• Its wrong to create a use case with a vague name like “enter data in database”, “choose”
• Its better to Don’t create "Add course delete course and update course as 3 use cases" and generate only the use case “manage course data”

Relationships

• You cant have a system actor When the system performs a use case by itself.
• Its better to include the use case with the new one.
• Example: When you create a new account, the system checks for user name availability, the actor is the user.

Diagrams "extend" relationship

• "extend" relationship is not used to represent options.

Activity Diagram

• UML activity diagrams may be used to define business process models.
• Activity diagrams illustrate the flow of functionality and the flow of events.
• Activity diagrams may also define the processing of data
• Activity diagrams define the starts and the end.

Symbols

• The start of a process is indicated by a filled circle
• The end by a filled circle inside another circle.
• Rectangles with round corners represent activities.
• Arrows represent flow of work
• A diamond is used to represent some choice is made, it can have three choices.
• A solid bar is used to indicate activity.
• Arrows may be annotated with guards.

Workflow Analysis

• Applies in interfaces with many users and roles, beyond object elaboration/task analysis.
• Helps understand work processes involving multiple people and roles.
• Works for companies automating prescription drugs prescribing/delivering processes.
• Effective representation involves UML swimlane diagrams, variation of activity diagrams.