1 of 25

SENG2021 Detailed Design Concepts

Fethi Rabhi

2 of 25

Design in SE cycle

Requirements analysis

Design

Implementation

Testing

Maintenance

Software architecture

Detailed design

3 of 25

Previous lecture: architecture

Architecture’s purpose

Connection between business and technical view

Gives an overview of what system does

Naming your software components is important

According to business functions

Will be mapped to a specific technology/language

4 of 25

Prerequisites before detailed design

Software architecture / software components has been defined

Implementation stack has been selected

Architecture satisfies functional and quality requirements

Extensibility (ability to add new features)

Adaptability (accommodating changing reqs.)

Simplicity (ease of understanding/implementing)

Efficiency (time/space)

5 of 25

Example

6 of 25

Detailed Design

Goes deeper than architectural design

    • Successions of refinements from the overall architecture
    • Involves modelling of certain elements to make implementation easier

Not one but many!

    • Function
    • Structure
    • Behaviour
    • Information

Design coverage

7 of 25

Detailed Design

Detailed design is usually closely associated with the implementation languages used

Object Oriented Modelling

    • Some design elements can be expressed in the Unified Modelling Language (UML)
    • UML is an OMG standard
    • UML contains lots of notations

Data Modelling

    • Information structure can be modelled using a conceptual modelling notation

8 of 25

UML Notations

9 of 25

Focus of this workshop

Given

Use cases / user stories

Architecture

Detailed design involves defining

Data model

User Interface model

Dynamic behaviour model

10 of 25

Data Modelling

Identify domain objects, their attributes and associations between objects

Normally, combination ER-diagram/sequence diagrams

Relational models

(for SQL databases)

Formal methods: more powerful and unambiguous

11 of 25

User Interface and visualisation design

    • Intuitive interfaces
    • Diversity in user devices
    • Easy to learn

Helping users to interact with systems

    • Viewing complex data
    • Infographics

Visualisation

12 of 25

Behavioural modelling

Architecture does not give sufficient information on how components interact with each other

Different notations for expressing behaviour

    • Sequence diagrams
    • Activity diagrams
    • Statecharts

13 of 25

Sequence diagram Example

14 of 25

More on sequence diagrams

15 of 25

Suggested detailed design process in SENG

Iterate

Iterate between these activities

For each user story

1) Develop its sequence diagram 2) Design its user interface

Data

Define ER diagram (can result in 1 or multiple databases)

Boundaries

Define architecture and draw diagram showing components and external entities

Focus

Keep number of user stories small

16 of 25

Example

Question: How is the architecture supporting the creation of invoices ? (use case / user story)

17 of 25

Example of a design process

17

Create Invoice

DETAILED SEQUENCE DIAGRAM

INITIAL SEQUENCE DIAGRAM

Create invoice (parameters)

Invoice

Deliveries Manager

Price Manager

i:Invoice

Invoice Manager

createInvoice (DA,PriceList)

Return(i)

User story

Create Invoice

Architectural component

Create Invoice

Invoice:createInvoice(despAdv,PriceList)

Invoice

produces

DeliveryAdv

uses

PriceList

uses

Data model

Class

18 of 25

Design process characteristics

  • Design is always evolving as user stories are implemented
  • For example, introducing a Price Manager in the previous architecture

  • May lead to a new use case “Manage Prices”

  • Architecture is refined together with use cases, sequence diagrams and data model. Keeping track of which classes are in which architectural component.

More important aspect is consistency between different design models (especially naming)

Invoice Manager

GUI

Price Manager

Deliveries Manager

19 of 25

Examples of sequence diagrams from previous workshops

20 of 25

Example 1

21 of 25

Example 2

22 of 25

Example 3

23 of 25

Good software design practices

23

    • Keep design documents “live” and shared between team members
    • Use design as a way to decompose work
    • Discuss design changes as a team

Things to do

    • Too much focus on notation
    • Quantity over quality
    • Creating something for other manager (tick boxes) and forgetting design is for team

Things to avoid

24 of 25

Design tools

24

    • Modelling design artifacts
    • Managing/sharing models

Why use a tool

    • For architecture, people tend to use a drawing tool
    • For detailed design, several UML tools exist (e.g. https://www.draw.io/)
    • Benefits: consistency checks, automatic code generation
    • Disadvantages: steep learning curve

Tools

25 of 25

Web resources