System Modelling

  • UML was developed in the 90s as a general purpose modelling language, providing a formal scheme for describing system models.
    • Static/structural view of system (objects and their attributes)
    • Dynamic/behavioural view - dynamic behaviour of system (collaboration betwen objects and changing state)
  • Different perspectives for system modelling include:
    • External - the context of the system
    • Interaction
      • Between system and it's environment
      • Between components of system
    • Structural
      • Organisation of system
      • Structure of data being processed
    • Behavioural - dynamic behaviour of the system

Structural UML

  • Creating a static view of a system requires identifying entities, which can be done in one of four ways
    • Grammatical approach based on natural language of the system
      • Identify key items from the description of the problem
    • Identification of tangible things in the application domain
    • Behavioural approach to identify objects
    • Scenario-based, where objects, attributes and methods in each scenario are identified
  • Class diagram shows system classes and their relationships
    • Show structure of design and organisation of components
    • UML formal notation move requirements closer to a mathematical description
    • Forces us to think about the language used in D-requirements
    • Class name is shown in diagram
    • Attributes shown with types
    • Methods shown with return and argument types
    • Use the line with the crows foot for showing one-to-many or many-to-many
    • Use ranges to indicate how many objects there are
  • Writing correct class diagrams:
    • Class name should be at the top
      • Abstract classes go in italic
      • Interfaces are represented <<interface>>
    • Attributes represent internal datatypes and are optional
    • Methods that make up public interface should be included
      • Don't show inherited
      • Don't show getters/setters
    • Symbols indicate access modifier
      • + - public
      • - - private
      • # - protected
      • ~ - package private
      • / - derived
      • Static attributes/methos should be underlined
    • Comments can be associated with classes, use a folded note notation
    • Class inheritance hierarchies, drawn top down with arrows pointing to parent
      • Solid line with black arrow for class
      • Solid line with white arrow for abstract class
      • Dashed line with white arrow for interface
    • Multiplicity shown next to arrow/line ends
      • * is zero or more
      • 1 is exactly one
      • 2..4 is between two and four
      • 3..* is 3 or more
    • Include name and navigability on arrows
    • Association (no arrow) shows classes are associated in some way
    • White diamond shows aggregation
    • Black diamond shows composition
    • Dotted line shows a temporary use/dependency
  • Context models illustrate the operational context of the system and other systems
    • Show links between different systems

Behavioural UML

  • Activity diagrams are flowcharts to represent workflows of stepwise activities within the system
    • Involves actions, decision boxes, bars to introduce parallel actions
  • Use case diagram represents users interactions within the system, and how they interact with the components
    • Shows events occurring within system and how users trigger them
  • Sequence diagram shows temporal interaction between processes and user
    • Time progresses downward
    • example in slides
  • State machine diagram shows how the state of the system changes
    • Similar to activity diagram but some fundamental differences
    • State diagram performs actions in response to specific events
    • Flowchart transitions from node to node on completion of activities
    • Executing a program graph (flowchart) results in a state graph
    • Instructions vs states

Architectural Patterns

  • Writing correct sequence diagrams:

    • Participants are objects/entities
    • Messages (arrows) are communications between objects
    • Time moves from top to bottom
    • Various ways of representing an object
      • Name:Type, can omit either name or type
    • Dashed vertical line is the lifetime of the object, terminated with a cross
    • When an object is active, represented with a box
      • Nest boxes for recursion
    • Frame boxes allow for conditionals and loops

  • Architectural design is concerned with understanding how a system should be organised

    • Often represented with box and line diagrams
    • Two main uses:
      • Facilitating discussion about system design - high level view useful for stakeholders
      • Documenting that an architecture has been design with a complete system model
    • Non-functional requirements refer to system as a whole, so architectural design is closely related. Considers:
      • Performance
      • Security
      • Safety
      • Availability
      • Maintanability
    • First need to break system down into subsystems
    • Box/arrow diagrams show general interactions
      • Arrows show direction of data/control
      • May break down larger systems into subsystems