Requirements Analysis

Designing the software system based on requirements gathered in analysis:

Conceptual Model

Model the structure of the system via UML Class Diagram:

• Objects aka Classes
• Attributes aka Properties of objects.
• Operations aka Methods that can be performed on Objects.

Dynamic Model

Model the implementation of the system via UML Diagrams:

• Single Use Case

  • Sequence Diagram: focused on timing & order of interactions between objects.
  • Communication Diagram: Interactions between objects. Focused on objects.

• Multiple Use Cases

  • State Machine Diagram: visualise single system as a set of States.
  • Activity Diagram: visualise interactions ≥ 1 system(s) as a set of workflow steps.

Class Diagram

• Abstract Class class name is in italics.
• Multiplicity eg. many (*) Mechanics to 1 (1) Garage.
• Inheritance subclass SportsCar inherits from class Car.
• Implements implementation Car implements Drivable interface.
• Aggregation Car is part of Garage, but can exist independently.
• Composition Engine is part of Car, but cannot exist independently.
• Dependency Mechanic uses Engine temporarily, but does not have an Engine attribute / property.

Access Modifiers

Access Modifier controls access to Attributes & Operations:

Access Modifier	Symbol	Description
Public	+	Members are accessible from anywhere.
Private	-	Members are accessible only within the class.
Protected	#	Members are accessible within the class and its subclasses.

Class Stereotype Diagram

Class Diagram with no details (methods or attributes) visualising only:

• Interactions between classes via <<usage>> dependency.

• Class Stereotype of each class:

  • Boundary interface between actor and system.
  • Control app logic classes.
  • Entity data model classes.

Sequence Diagram

Visualises timing and order of interactions between objects:

• 1 Use Case = 1 Sequence Diagram

Visualises timing and order of interactions between objects:

• 1 Use Case = 1 Sequence Diagram
• Vertical Bar on the object's lifeline indicates when the object is active.
• Synchronous blocking message is solid arrow ->
• Asynchronous non-blocking message is thin arrow ->
• Return non-blocking message is thin dotted arrow <-

Frames used in Sequence Diagram:

• sd frame wrapping entire sequence diagram
• ref reference another sequence diagram.
• loop repeating interactions.
• alt Alternative branch: if-else.
• opt Optional branch: if.
• par interactions run in parallel.

Communication Diagram

Messages are performed in the order of sequence no.:

• * Iteration indicates that the message may be performed repeatedly.
• [CONDITION] Guard only executes message if CONDITION is true.

State Machine Diagram

State Machine Diagram aka Dialog Map Models system States and transition Events between states.

• Start black filled circle is the starting state.
• End outer line circle with inner black filled circle is end state.
• Nesting States can be nested. eg. AwaitingPayment is nested in PaymentPending.

State

Actions performed in the State Lifecycle are specified in the body of the state:

• entry/ACTION perform ACTION once after entering the state.
• do/ACTION perform ACTION repeatedly while the state is active.
• exit/ACTION perform ACTION once before exiting is active.

Event

EVENT(ARGS,....)[CONDITION]/ACTION

Event transitions format:

• EVENT the name of the event that caused the state transition
• ARGS arguments passed to the event handler. Can be empty.
• CONDITION Optional. Only performs the transition if CONDITION is true.
• ACTION Optional. Side effect action performed when transitioning.

Activity Diagram

• Start black filled circle is the starting step.
• End outer line circle with inner black filled circle is end step.
• Decision Diamond shape indicates a conditional decision.
• Parallel Solid liine indicates parallel execution.