10  Skill 3 - Skills in using analytical tools and techniques

10.1 UML

10.1.1 What is UML?

UML, or Unified Modeling Language, is a way to visually represent how software systems are designed and how they work. Think of it as a blueprint for building software, similar to how architects use blueprints to design buildings.

When you create a software application, there are many different parts, like classes, objects, and functions, that work together to make the program run. UML helps you organize and understand these parts by using different types of diagrams.

10.1.1.1 Why Use UML?

  • Clear Communication: UML diagrams make it easier to explain complex ideas to others, whether they are developers, teachers, or clients. By using visual diagrams, everyone involved can see how the system is supposed to work.

  • Planning: Before writing any code, you can use UML to plan out your software. This helps you avoid mistakes and think through problems ahead of time.

  • Documentation: UML diagrams serve as a record of how your system is designed. This is useful if you need to update the software later or if someone else needs to understand how it works.

10.1.2 Common UML Diagrams

In our course, we will focus on several key types of UML diagrams that are essential for understanding and designing software systems:

  • Use Case Diagrams: These diagrams show the different ways users (or “actors”) interact with the system. A use case diagram helps us understand what the system needs to do from the user’s perspective by identifying the different scenarios in which the system will be used.

  • Context Diagrams: A context diagram provides a high-level overview of the system and its environment. It shows the system as a single process and identifies external entities (like users or other systems) that interact with it. This diagram helps us understand how the system fits into the bigger picture.

  • Data Flow Diagrams (DFD): These diagrams illustrate how data moves through the system. They show the sources of data, the processes that transform the data, and the destinations of the data. Data flow diagrams are useful for understanding how information flows within the system.

  • Class (Object) Diagrams: Class diagrams show the structure of the system by displaying the classes (or objects), their attributes, and the relationships between them. For example, a class diagram might show how an Event class is related to a User class. This type of diagram helps us understand the building blocks of the system and how they interact with each other.

By learning to use these diagrams, you’ll be able to visually represent complex systems, making it easier to plan, communicate, and understand the design of your software projects.

10.1.3 UML Class

Event Class:

Use CharField for location now but we might change to something for Google Maps or OpenStreetMap.

classDiagram
    Model <|-- Event

    class Model {
        +save(*args, **kwargs)
        +delete(*args, **kwargs)
        +__str__()
        +Meta
    }

    class Event {
        +CharField name
        +DateTimeField time
        +CharField location
        +TextField description
        +URLField link
    }

classDiagram
    Model <|-- Event

    class Model {
        +save(*args, **kwargs)
        +delete(*args, **kwargs)
        +__str__()
        +Meta
    }

    class Event {
        +CharField name
        +DateTimeField time
        +CharField location
        +TextField description
        +URLField link
    }

10.1.4 UML Use Case Diagram

Key Features of a Use Case Diagram

  • System Boundary: The rectangle labeled “Event Management System” represents the system boundary, encapsulating all the use cases that belong to the system.

  • Actors: User and Admin User are the actors interacting with the system. Actors represent the roles that users or external entities play when interacting with the system.

  • Generalisation: The arrow from Admin User to User (with an open triangle) indicates that Admin User is a specialised role that inherits all behaviors of the User, plus additional capabilities.

  • Use Cases: The ellipses, such as View Events and Edit Events, represent the actions or functions the system performs for the actors.

  • <<includes>> Relationship: The arrow from Edit Events to Admin UI with <<includes>> indicates that the Edit Events use case includes the Admin UI use case as part of its process.

  • <<extends>> Relationship: The arrow from View Events on mobile phone to View Events with <<extends>> indicates that View Events on mobile phone is an optional extension of the View Events use case, adding additional behavior in certain scenarios.

@startuml
left to right direction

actor User
actor "Admin User" as Admin


User <|-right- Admin

rectangle "Event Management System" as EMS {
    (View Events) 
    (Edit Events) -up-> (Admin UI): <<includes>>
    (View Events on mobile phone) -up-> (View Events) : <<extends>>
}

User -- (View Events)
Admin -- (Admin UI)
@enduml
@startuml
left to right direction

actor User
actor "Admin User" as Admin


User <|-right- Admin

rectangle "Event Management System" as EMS {
    (View Events) 
    (Edit Events) -up-> (Admin UI): <<includes>>
    (View Events on mobile phone) -up-> (View Events) : <<extends>>
}

User -- (View Events)
Admin -- (Admin UI)
@enduml

10.1.5 UML Context Diagram

10.1.5.1 Context Diagram for “Code Club Membership System”

  • Level 0 DFD: Represents the entire “Code Club Membership System” as a single process.
  • Process: Depicts the “Code Club Membership System” within a single boundary.
  • External Entity: Users, Admins, or external systems that interact with the “Code Club Membership System.”
  • Data Flow: Arrows indicating interactions or data exchange between the “Code Club Membership System” and external entities.
@startuml
left to right direction

actor "Payment Gateway System" as PaymentGateway
actor "Club Member" as Member
actor "Club Admin" as Admin

(Code Club Membership System) as CCMS

Member --> CCMS : Register/Update Profile
CCMS --> Member : Confirmation/Notifications

Admin --> CCMS : Manage Memberships
CCMS --> Admin : Reports/Statistics

PaymentGateway -right-> CCMS : Process Membership Fees
CCMS --> PaymentGateway : Payment Confirmation
@enduml
@startuml
left to right direction

actor "Payment Gateway System" as PaymentGateway
actor "Club Member" as Member
actor "Club Admin" as Admin

(Code Club Membership System) as CCMS

Member --> CCMS : Register/Update Profile
CCMS --> Member : Confirmation/Notifications

Admin --> CCMS : Manage Memberships
CCMS --> Admin : Reports/Statistics

PaymentGateway -right-> CCMS : Process Membership Fees
CCMS --> PaymentGateway : Payment Confirmation
@enduml

10.1.6 UML Data Flow Diagram

A Data Flow Diagram (DFD) visually represents how data moves through a system, highlighting the processes, data stores, and external entities involved. Remember to use arrows to indicate the direction of data flow and verbs to describe the actions performed by each process.

@startuml
left to right direction

actor User #red

User --> (User Request) : HTTP Request
note top of (User Request) : browser

(Get User Request) as URLDispatcher
note top of URLDispatcher : URL Dispatcher

(Process Request) as ViewComponent
note top of ViewComponent : View

(Query/Save Data) as ModelComponent
note top of ModelComponent : Model

(Render HTML) as TemplateComponent
note top of TemplateComponent : Template

[Membership/Event Data] as DataStore
note top of DataStore : Database

(User Request) --> URLDispatcher
URLDispatcher --> ViewComponent : Route Request
ViewComponent --> ModelComponent : Request Data
ModelComponent --> DataStore : Retrieve/Store Data
DataStore --> ModelComponent : Return Data
ViewComponent --> TemplateComponent : Send Data
TemplateComponent --> (User Response) : Render HTML

(User Response) --> User : Display HTML
@enduml
@startuml
left to right direction

actor User #red

User --> (User Request) : HTTP Request
note top of (User Request) : browser

(Get User Request) as URLDispatcher
note top of URLDispatcher : URL Dispatcher

(Process Request) as ViewComponent
note top of ViewComponent : View

(Query/Save Data) as ModelComponent
note top of ModelComponent : Model

(Render HTML) as TemplateComponent
note top of TemplateComponent : Template

[Membership/Event Data] as DataStore
note top of DataStore : Database

(User Request) --> URLDispatcher
URLDispatcher --> ViewComponent : Route Request
ViewComponent --> ModelComponent : Request Data
ModelComponent --> DataStore : Retrieve/Store Data
DataStore --> ModelComponent : Return Data
ViewComponent --> TemplateComponent : Send Data
TemplateComponent --> (User Response) : Render HTML

(User Response) --> User : Display HTML
@enduml