System Modelling with UML

System Modelling

• System modelling involves creating abstract models of a system.
• Each model offers a unique view or perspective of the system.
• System models can be used to generate complete or partial system implementations.
• Unified Modelling Language (UML) serves as a standard language.
• UML is used for specifying, modeling, visualizing, constructing, and documenting software systems.

System Modelling Benefits

• Facilitates communication among project teams, including users, developers, analysts, testers, and managers.
• Aids in exploring potential designs.
• Validates the architectural design of the software and is independent of particular programming languages and development processes.

UML Diagram Types

• Activity diagrams illustrate the flow of activities within a process or during data processing.
• Use case diagrams depict interactions between a system and its environment.
• Sequence diagrams outline interactions between actors and a system, as well as among system components.
• Class diagrams show object classes within a system.
• Class diagrams also show the associations between them.
• State diagrams illustrate how a system responds to internal and external events.

Use of Graphical Models

• Graphical models can facilitate discussions about a proposed system.
• Incomplete models are acceptable for supporting discussion.
• Graphical models document an existing system.
• Models should accurately represent the system but may be incomplete.
• Graphical models can be used for detailed system descriptions that can implement the system.
• Models must be correct and complete.

Interaction Models

• Use case and sequence diagrams can be used for interaction modelling.
• Use case models and sequence diagrams present interaction at different levels of detail.
• This allows the model and diagrams to be used together.
• The details of interactions in a high-level use case can be documented in sequence diagrams.

Use Case Modelling

• Use Cases were originally developed to support requirements elicitation from stakeholders who interact directly with the system.
• Each use case represents a task involving interaction with an external system.
• Designed to focus on automated processes, not the order of execution.
• Naming conventions require use case names to begin with a verb.

Use Cases

• Use case diagrams provide a simple overview of an interaction and need more detail for full understanding.
• Further details can be provided through:
• Simple textual descriptions
• Structured descriptions in a table
• Sequence diagrams

Use Case Actor

• The Mentcare system has a use case with two actors: the operator transferring data and the patient record system.

Use Cases for the Medical Receptionist

• The medical receptionist manages patient registration, information viewing, and data transfer.
• In emergencies, the receptionist is responsible for contacting patients.

Use Case Actors

• Users of the system: Physical persons who directly uses the system.
• Other systems: Systems that interact with the system being built.
• Time: Time becomes an actor when the passing of a certain amount of time triggers some event in the system (out of control).

Relationships in Use Cases

• Association: The relationship between a use case and an actor only.
• Include and Extend: The only two types of relationships allowed between use cases.
• Generalization: The only relationship allowed between actors.

Association Relationship

• Used to show the relationship between a use case and an actor.
• Every use case must be initiated by an actor.
• Except for abstract use cases (in include and extend relationships).

Include Relationship

• Allows one use case to use the functionality provided by another use case.
• This is applicable in 2 scenarios:
• Multiple use cases share a large piece of identical functionality.
• A single use case has an unusually large amount of functionality.
• Include relationships suggest that one use case always utilizes the functionality of another.

Extend Relationship

• Allows one use case the option to extend functionality from another use case.
• When the "Change Reservation" use case is running, "Check Credit" runs only if the reservation amount has changed.
• The arrow in an extend relationship is drawn from the use case that is optionally run to the use case being extended.

Abstract Use Cases

• An abstract use case cannot be initiated directly by an actor.
• Provides additional functionality for other use cases.
• Use cases participating in include or extend relationships are abstract use cases.

Generalization

• Rather than learning the characteristics of every entity, place these entities in more general classes.
• Generalizations are shown as an arrowhead pointing to the more general class.
• Higher-level classes attributes and operations are associated with lower-level classes.
• Lower-level classes are subclasses that inherit operations from super classes and add specific attributes.

Generalization example

• It may be worth including actor generalizations if some use cases are initiated by some types of students, and other use cases are initiated by other types of students.
• If all students use the same use cases, it is probably not necessary to show an actor generalization.

Check List for Use Case Diagrams

• Verify each functional requirement is within at least one use case.
• Consider how each end user will interact with the system.
• Determine the information each end user will provide to and receive from the system.
• Consider maintenance issues for system initialization and shutdown.
• Identify all external systems and the information they provide to and receive from the system.

Identifying the Actor

• The actor is the one who directly uses the software.
• (e.g., If a student needs a grade report and asks an employee to prepare the request, the employee is the primary actor in that use case)

Functionalities in Use Cases

• Every use case should represent a main functionality.
• Steps are steps of a certain use case and not its own case e.g.(“Make Reservation”, “Register" or "Search for Products”)
• Avoid vague names.
• Do not create a use case for "enter data in database”, “choose” or “save data" , but rather create a use case called "manage data".
• Consolidate similar use cases into one more general one
• Don't create "Add course”, “delete course” and “update course” as 3 use cases but create one use case called "Manage course data".

Relationships Involving System Processes

• When a use case is processed by the system itself, without direct user interaction, it should not have a "system" actor.
• Add the system processed use case as an included case within a user-initiated use case for resolution or incorporate the "system" use case into the user initiated use case.

Avoiding Misuse of "Extend" Relationship

• Use "extend" to represent options.

Activity Diagrams

• UML activity diagrams may be used to define business process models.
• Activity diagrams illustrate the flow of functionality in a use case for used in requirements gathering.
• Activity diagrams used for modeling data processing.
• Activity diagrams define workflow start, end, activities, and their order.

Activity Diagram Symbols

• A filled circle indicates the start of a process.
• A filled circle inside another circle indicates the end.
• Activities are represented by rectangles with round corners.
• Arrows depict the flow of work.
• A diamond represents a decision point with multiple choices.
• A solid bar indicates activity coordination, where all incoming activities must complete before progress.
• A solid bar leading to activities indicates parallel execution.
• Arrows may contain guards specifying conditions for the flow.

Workflow Analysis

• Appropriate when different users with different roles interact via a user interface.
• Helps understand how work processes need the completion of several people (and roles).
• Workflow can be effectively represented by a UML swimlane diagram.
• A variation on the activity diagram.