Software Modelling & Design Summary PDF

SWEN30006: Software Modelling & Design
Summary
February 28, 2015
Contents
1 The Design Problem
1.1 Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Design Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
4
4
2 Methods for Solving the Design Problem

2.1 Funtion Oriented Methods . . . . . . . . .
2.1.1 Data Flow Diagram . . . . . . . .
2.1.2 Product Engineering . . . . . . . .
2.1.3 Design Steps . . . . . . . . . . . .
2.2 Data Structure Oriented Design Methods
2.2.1 Design Strategy . . . . . . . . . .
2.3 Component Oriented Design Methods . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
6
6
7
7
7
3 Software Design Process and Modelling

3.1 Systems Analysis Processes . . . . . . . .
3.1.1 Analysis of the Waterfall . . . . . . .
3.1.2 The Interactive Model . . . . . . . .
3.1.3 Rapid Prototyping . . . . . . . . . .
3.2 Executable versus Non-Executable Models
3.2.1 Non-Executable Models . . . . . . .
3.2.2 Types of Prototypes . . . . . . . . .
3.2.3 Uses of Prototyping . . . . . . . . .
3.2.4 Prototyping Risks . . . . . . . . . .
3.3 Activity Diagrams . . . . . . . . . . . . . . .
3.3.1 Activity Partitions . . . . . . . . . . .
3.3.2 Control and Data Flows . . . . . . .
3.3.3 Activity Parameters . . . . . . . . .
3.3.4 Activity Diagram Conventions . . . .
3.4 Use Case Models . . . . . . . . . . . . . .
3.4.1 Use Case Diagrams . . . . . . . . .
3.4.2 Use Case Descriptions . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
10
11
11
11
11
12
13
13
13
14
14
14
15
15
17
4 Domain Modelling with Classes

4.1 Types of Class Models . . . . .
4.2 Attribute Specification Format .
4.3 Operation Specification Format
4.4 Associations . . . . . . . . . .
4.5 Multiplicity . . . . . . . . . . . .
4.6 Object diagrams . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
20
20
20
20
21
21
.
.
.
.
.
.
21
21
22
22
22
24
24
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Interaction Models
5.1 Sequence Diagrams . . . . . . . . . .
5.1.1 Message Specification Format
5.1.2 Interaction Fragments . . . . .
5.1.3 Sequence Diagram Heuristics
5.1.4 Uses for Sequence Diagrams .
5.1.5 Interaction Design Process . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.2 Control Styles . . . . . . . . .

5.2.1 Centralised . . . . . .
5.2.2 Delegated . . . . . . .
5.2.3 Dispersed . . . . . . .
5.3 Principle of Least Knowledge
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
25
25
26
6 Software Architectures
6.1 Role of Software Architecture . . . . . .
6.2 Characteristics of Software Architecture
6.3 Guidelines for a Good Design . . . . . .
6.3.1 Heuristics for Good Design . . .
6.4 Decomposition . . . . . . . . . . . . . .
6.4.1 Hierarchical Decomposition . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
26
26
26
27
27
27
7 Architecture Styles
7.1 Repository Style . . . . . . . .
7.1.1 Problem . . . . . . . . .
7.1.2 Solution . . . . . . . . .
7.2 Pipes and Filters . . . . . . . .
7.2.1 Problem . . . . . . . . .
7.2.2 Solution . . . . . . . . .
7.3 Client-Server . . . . . . . . . .
7.4 Control Styles . . . . . . . . . .
7.4.1 Call-Return Model . . .
7.4.2 Manager Model . . . . .
7.4.3 Event Driven . . . . . .
7.4.4 Reference Architectures
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
28
28
29
29
29
29
29
30
30
30
30
30
8 State Charts
8.1 Transition String Format . . . .
8.2 Symbol Compartments . . . . .
8.3 Internal Transitions . . . . . . .
8.4 Sequential Composite States .
8.5 Stubs . . . . . . . . . . . . . .
8.6 State Chart Heuristics . . . . .
8.7 Recognisers and Transducers .
8.8 Dialog Map . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
31
31
32
32
32
33
34
.
.
.
.
.
.
.
34
34
34
35
35
35
35
36
9 Designing with Classes

9.1 OO Design Principles . . . . . . . . . . . . .
9.1.1 Open-Closed Principle (OCP) . . . . .
9.1.2 Liskov Substitution Principle . . . . .
9.1.3 Dependency Inversion Principle (DIP)
9.1.4 Single Choice Principle . . . . . . . .
9.1.5 Favor Composition Over Inheritance .
9.1.6 Composition . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10 Software Architecture and Design Patterns

10.1 Gang of Four design patterns . . . . . . . . .
10.1.1 Factory Method Pattern . . . . . . . .
10.1.2 Observer Pattern . . . . . . . . . . . .
10.1.3 Model View Controller (MVC) Pattern
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
36
38
39
11 Architectural Design Specification

41
11.1 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
The Design Problem
The design problem is to develop a description of the system that can be implemented by developers and, if implemented, will meet all of the requirements. Designs can be seen as a
reasoning from a set of requirements and constraints to a new piece of reality; bringing something new into being. Requirements (what) and design (how) come from different conceptual
worlds and can have different competing objectives. The design problem is solved by:
Design Methods A set of activities that systematically guides the development of a solution
to a design problem.
Modelling represents the objects, system and software in a way that aids understanding and
solution.
Decomposition breaks the complicated problem down into smaller and more easily solved
pieces.
Design Knowledge uses, adapts and extends previously developed ideas where applicable.
1.1
Waterfall Model
!!"#$!%$&$'()!*+,-$.!/$0$123.$&-!4(5$6)+)1$!728$1!
Requirements
Software Requirements
Package
System
Design
System Designs
H/W and S/W
Software
Design
Software Architecture
and Detailed Designs
Implementation
Code
Testing
System
Maintenance
SWEN30006: Software Modelling and Design
Semester 1, 2013
10
Concept aims to identify the initial idea of the system.

Requirements aims to identify the needs, features, function and capabilities of the system.
Design aims to address how the hardware and software are to be implemented.
Implementation aims to address the programming of the system in code.
Testing aims the find and eliminated any faults (bugs) in the software.
Maintenance aims to incorporate updates and new features into a system as the needs change.
1.2
Software Architecture
Component Design aims to identify the key sub-systems and establish a framework for both
control flow and communication between sub-systems. Key activities in component design are:
System Structuring
4
Control Modelling
Modular Decomposition
Component design also aims to design the services that each component must deliver
and develop abstract models of the components.
Interface Design aims to develop the interface for each component including method calls,
messages and event handlers.
Data in the systems consists of:
Persistent data that is saved long term.
Data that flows between components; attribute data in classes.
1.3
Design Methods
Structured Methods Notations, guidelines and often sets of activities that can be used to
move from requirements to design.
Data flow
Jackson's technique
Entity-relationship modelling
Structural and functional block modelling
OO analysis and design
1. Start with use cases and domain model
2. Add more detail to class models to evolve design into something that can be
implemented
3. Repeat 2 until a model is reached in which the classes, interfaces and control
strategies are straightforward to implement.
2
2.1
Methods for Solving the Design Problem

Funtion Oriented Methods
Begin with the functional requirements specified in the requirements specification. During the
design process:
High-level functions are successively decomposed into more detailed functions
When the functions are simple enough - such that they could be implemented - they are
mapped to a module structure.
Essentially taking the problem, breaking it down and rebuilding it into a known structure. n.b.
most function oriented design solutions assume a common system state or data store which
the functions operate.
The General Pattern of a Function Oriented

Design Solution
System State
F1
F3
F2
F4
F5
!"#$%&'()*"(%+,-.($./%0.#-1(%2"3'*"(#%4##'5.%4%)"55"(%
2.1.1 Data Flow

Diagram
#6#$.5%#$4$.%",%/4$4%#$",.%'7"(%89-)9%$9.%:'()*"(#%"7.,4$.;%
1. Start with the context diagram
2. The System transform must be decomposed to include the details of exactly how inputs
Semester 1, 2013
6
flows are transformed into output flows. Add new transforms and create new data flows
to achieve this.
3. If more detail is need to achieve implementation, choose one of the transforms and expand it as in step 2. Go back to step 3.
n.b. Not dealing with program logic, flow charts or any notions of sequencing in data flow
diagrams - just breaking transitions into smaller transitions that are easily implementable.
DATA-FLOW DIAGRAM NOTATION
Semester 1, 2013
10
Figure 1: Data flow diagram notation.
The Context Diagram
Project
Coordinators
Project
Coordinators
Commands
Students
Project
Details
Reports
SEPD
System
Project
Details
Students
Project
Details
Queries
Administrators
Project Clients
Figure 2: Context diagram in SEPD.
Semester 1, 2013
12
Context Diagram shows the data flows coming into - and out of - the system.The system is
required to transform the inputs to outputs.
2.1.2
Product Engineering
In the context diagram data must flow from the environment into the system transform and
out of the system transform back into the environment. External data must be transformed to
internal data flows, processed and then transformed back into external data flows.
Input Flows are data flows that take data into the system and transform it to internal form.
Transform Centre At the heat of the system where incoming data flows pass through the transform centre and start to move on paths back to the environment.
Output Flows are data flows that lead back to the environment.
Determining the Flow Boundaries
Semester 1, 2013
22
Figure 3: Determining the flow boundaries and transform centre.
2.1.3 Design Steps

1. Review context diagram
2. Review and refine data flow diagrams: consider coupling and cohesion of transforms.
Want high cohesion among transforms and low coupling between transforms.
3. Determine where the DFD has transform flow and transaction flow.
4. Isolate the transform centre by specifying input flows and output flows.
5. Perform `First Level Factoring': create a program structure based on the input flows,
transform centre and output flows. and a top level control module to coordinate the flows.
Factoring results in a program structure in which decision making and control function reside
at higher levels in hierarchy, and transformations and processing reside at lower levels.
Second Level Factoring Add the lower level modules to the control hierarchy already created.
Start at the transform centre and work outwards along input flows and then forward
along output flows.
Each transform is added as a sub-module of the one it is connected to by a data
flow.
Modules can be combined according to the good design (high cohesion, low coupling).
Second Level Factoring
Figure 4: First and Second level factoring.
2.2
Semester 1, 2013
24
Data Structure Oriented Design Methods
Jackson's technique; data-structure oriented design methods start out by designing the input
and output data structures. The assumption is that any system interacts with the outside world
though its data structures. Thus, a correct model of the data can be transformed into a system
that incorporates a correct view of the world.
2.2.1 Design Strategy
1. Form a system network using Jackson's notation that models the problem domain
2. Define and verify the data-flow data structures (input and output)
3. Derive and verify the program structures
4. Derive and verify the elementary operations
5. Write the structure text and program text
These steps can be separately and independently encouraging a separation of concerns.
2.3 Component Oriented Design Methods

A software component is an independent unit with well defined interfaces and dependencies. It
is also a package, web service, web resource or module that encapsulates a set of function or
data or both. They can be composed or deployed independently. Component design is about
providing, developing and integrating components to form complete architectures. Key design
issue is assuring levels of trust in component based design.
Jacksons Structure Diagrams

Hierarchy
Sequence
Sequence
Legend
Action/Process
Selection
Iteration
Procedure
Semester 1, 2013
Figure 5: Jackson's Structure Diagrams.
Jacksons Network Diagram for the SEPD

Cmds
Proj.
Details.
Project
Details
(Persistent Store)
Queries
Process
State Vector
Generate
Report R1
Report
R1
Generate
Report R2
Report
R2
Generate
Report R3
Report
R3
Data Stream
Symbols
Semester 1, 2013
Figure 6: Step 1: form the network diagram e.g. SEPD.
Input Data Structures for a Report Generator

Project
Details
Company
Contact
Name
Email
Features
Environment
Mobile
Tool-Chain
Project Status
IP
Contract
IP Position
Prog. *
Languages
Operating
System Spec.
Hardware
Spec.

1, 2013
10
Figure
7: Step 2: define the data structures e.g.Semester
an input
to SEPD.
The Program Structure Based on the Output

Generate
Report 1
Generate
Report
Layout
Generate
Contact
Generate
Company
Generate
Name
Generate
Mobile
Generate
Email
Generate
IP
Generate
Contract
Generate
Project Status
Generate
IP Position
Figure 8: Step 3: derive the program structures e.g. report generator 1 of SEPD.
!"#$%&'(&)*$+,&-.,-&#$/+$"/#&)&."/.)0$)12$,"#$%&'.#++#+$#3#.-,#$0#4$,'$&/(",5$6,$
7'00'8+$,"#$'-,%-,$2),)$+,&-.,-&#$9-/,#$.0'+#0:$/1$,"/+$#3)*%0#$;-,$,"/+$/+$1',$
)08):+$,"#$.)+#5$<4#1$"#-&/+=.+$)12$+'*#$2#)0$'7$.&#)=>/,:$/+$1##2#2$,'$(#,$
,"#$'-,%-,$7&'*$,"#$/1%-,5$
Semester 1, 2013
The Program Text using Pseudo Code

Process Generate_IP is
Generate_Name;
Generate_Email;
Generate_Phone;
End Generate_IP
Process Generate_Report_1 is
Generate_Report_Layout;
Generate_Company;
Generate_Contact;
Generate_IP;
Generate_Project_Status;
End Generate_Report_1
!"#$%&'(#))$)*&+(*+&#$(,-$.#$
*&,-)/,*#0$*'$1+-(2'-)$3-$4$5"#&#$
*"#$%&'(#))$6!"#"$%&"'(")*$&'+7$3)$
*"#$,%-#$%&'(#0+&#8$$
9/*#&-,2:#/;$*"#$%&'(#))$(,-$.#$
#,)3/;$*&,-)/,*#0$*'$(/,))#)$5"#&#$
#,("$%&'(#))$3)$3<%/#<#-*#0$.;$,$
<#*"'08$$
Figure 9: Step 5: write the program text e.g. SEPD.
Semester 1, 2013
10
14
13
3
3.1
Software Design Process and Modelling

Systems Analysis Processes
Activity is the action that a person or a group undertakes to achieve a goal.

Process is a collection of related activities that are performed to get from a starting point to
and end point to achieve a set of desired goals.
Systems analysis processes are performed by developers starting from the time the client provides the list of needs through to the delivery of the product to the client. The processes are
then further divided up into:
Analysis Activities (Product Design)
Design Activities (Engineering Design)
!"#$%&'()#'$*+,#-.+//$0-&1#22$
0-&'31,$45+/62(2$
Requirements
Engineering
0-&'31,$758(5##-(58$
9#2(85$:,6/#2;$0+<#-52$+5'$
%#,"&'2$+-#$32#'$"#-#=$
Design
Implementation
Testing
Maintenance
Semester 1, 2013
3.1.1 Analysis of the Waterfall

Has built in milestones for contracting; each stage produces artefacts such as documents,
models or code. There can be tendency to over-document and over-engineer when using the
strict waterfall. Is a good model for previously built systems and for well-defined systems that
have well-define goals.
3.1.2 The Interactive Model
Aims to develop a minimal but useable system and then improve by performing successive
iterations over it. Each new iteration builds in new requirements, improves the design and
existing code. Can get constant feedback from clients to improve. Is a combination of product
design and product engineering. Each iteration combines product design in the analysis activity,
and product engineering in the design, implementation and testing activities. Product design
activities in successive iterations are linked:
Each successive product design activity extends and improves the results of the previous
product design activity.
11
!!"#$!%&$'()*$!+,-$.!
Analysis
Architecture
Test
Implementation
Design
"#$!(/0!/1!(1!/&$'()*$!
0,-$.!/2!&,!-$*$.,3!(!
0/1/0(.!45&!!"#$%&'
262&$0!(1-!&#$1!/03',*$!
53,1!/&!,*$'!2577$22/*$!
/&$'(),128!'!
9(7#!1$:!/&$'(),1!45/.-2!
/1!1$:!'$;5/'$0$1&2<!
/03',*$2!&#$!-$2/=1!(1-!
$>/2)1=!7,-$8!
Semester 1, 2013
Each successive product design activity extends and improves the results of the previous
product engineering activity.
The products engineering activities in successive iterations are similarly linked.
3.1.3 Rapid Prototyping
Is a form of iterative development. Each iteration focuses on the production of a Prototype.
Prototype is an incomplete or preliminary version of the system from which the complete production system can be developed.
3.2
Executable versus Non-Executable Models
3.2.1 Non-Executable Models

Token passing semantics (e.g. Activity Diagrams) tell us which activity is being done but little
about the actual actions being undertaken. UML class diagrams are not executable - they just
model the relationships between the classes (entities) in a system. It is sometimes necessary
to show how something will behave before it is built - prototype.
Prototyping creates executable models of the parts of the systems to explore requirements,
technology or different things. Is iterative in nature and the production of prototypes can
expose vague or uncertain requirements. Has the advantage of being able to show the
client how the system might look and behave. Also a good way of development team to
gain understanding of the system and its environment.
3.2.2 Types of Prototypes
Horizontal Prototype realises part or all of the product's user interface.
One program layer
Mock-ups
Vertical Prototype does processing apart from that required to present a user interface
Cuts across program layers
12
Proof of concept prototype

Throwaway Prototype is developed as a design aid and then discarded
Exploratory prototype
Quick to build
Risky to use in final product
Evolutionary Prototype becomes (part of) the final product
Iterative development
More expensive to build
Difficult to build to handle change
Low-Fidelity Prototype does not resemble the final product well
Paper or rough electronic prototypes
"Executed" by walking through interactions
Very quick and easy
High-fidelity Prototypes resembles the final product well
Usually electronic
Take longer to build (good tools help)
3.2.3 Uses of Prototyping
Needs elicitation
Discussion, jogs memory, inspires ideas
Usually throwaway horizontal paper prototypes
Needs analysis
Captures developers understanding of needs
Usually throwaway horizontal paper prototypes at various levels of fidelity
Requirements generation and refinement
Design alternatives
Explore new ideas
Often throwaway horizontal paper prototypes
Requirements evaluation and selection
Usability studies
Requirements feasibility
Usually higher fidelity; sometimes vertical prototypes
Design finalisation
Better for review than a SRS
Advisable to make high-fidelity evolutionary horizontal prototypes
13
3.2.4 Prototyping Risks

Using a throwaway prototype as the bases for development:
Avoid making high-fidelity throwaway prototypes
Make it very clear to stakeholders that a prototype only appears to work
Fixation on appearance rather than function:
Do not use prototypes for functional needs elicitation
Use low-fidelity prototypes for needs elicitation
Prototype is "better" than final product:
Use low-fidelity prototypes
Ensure that high-fidelity prototypes are accurate representations
3.3
Activity Diagrams
Model processes by showing the activities that are performed in a process and show the flow
of control and data !"#$%&'(!)&*+,*-.!/,*0#1&0+!
between
Click to the
editactivities.
Master title style
merge
node
guards
decision
node
!!"#$%&'(!)'*!+#&'&'(!,#*-.!
Click to edit Master title style
Semester 1, 2013
24
fork node
join node
Semester 1, 2013
28
3.3.1 Activity Partitions

Activities can be grouped into activity partitions (swimlanes) to denote the person/subsystem/object
that implements and is responsible for it.
14
!"#$%&'(!)*+$$,-.!
Do Laundry
Sort
Clothes
Wash
Whites
Wash
Darks
Dry
Clothes
Fold
Clothes
Machine A
Person X
Machine B
Semester 1, 2013
31
3.3.2 Control and Data Flows

Similar to control, data also can flow through a process.
Object nodes represent data; rectangles with the state in square brackets
An edge can represent a control or data flow:
Control flow begins and ends at activity nodes
Data flow begins or ends on a data node
A pin represents the data.
!"#$%&#'!($)!*(%(!+'#,!-.(/0'1!
control flow
pin
data flows
control flow
Semester 1, 2013
34
3.3.3 Activity Parameters

Object nodes placed on activity symbols to indicate data or object inputs or outputs. Contain
the data or object name. Types are specified in activity symbol beneath the activity name.
3.3.4 Activity Diagram Conventions
Flow control and object down the page and left to right
Name activities and actions with verb and phrases
Name object nodes with nouns
Don't use both control and data flows when a data flow alone is enough
15
Make sure all nodes entering an action node can provide tokens concurrently
Use the [else] guard at every branch
!!"#$%&'(!)&*+,*-!./*-012!
FindMax
a : int[1..*]
max : int
max = a[0]
i=1
[else]
[i < a.length]
[else]
[max < a.[i]]
max = a[i]
max
i++
3.4
Semester 1, 2013
37
Use Case Models
Model the interactions that an external entity has with the system. Consists of:
3.4.1 Use Case Diagrams
Are static models that capture the users' interaction with the system. Consist of use cases and
the actors involved in each use case.
Use
Case
toagent,
edit
Diagram
title style
Actor is aClick
type of
orMaster
external Symbols
entity,
that interacts with a product. Actors are roles not
individuals; the product in never an actor.
Use Case Name

Actor Name
Actor
Symbol
Association
Line
Use Case
Symbol
Scenario is a concrete interaction between a product and particular individuals. A use case is
an abstraction
of the interaction between the product and specific
individuals.9 A scenario
Semester 1, 2013
is thus an instance of a use case. Scenarios can help to envisage how the product may
be used. Designers can use a bunch of scenarios to explore ideas about the product and
how it could be designed for the way it will be used. The scenarios are then generalised
to generate use case by identifying actors and the sequence of actions that must be taken
during an interaction to achieve the goals of an activity.
16
Exercise Determine the Key Functions of a System fro

a Use case Diagram.
System
Select a
Wash
Customer
Stall Sensor
Buy a
Wash
Activate/
Deactivate
Soap Sensor
Wash the
Car
Produce a
Log
Manager
Semester 1, 2013
10
Beneficiary of a use case is an actor that receives some benefit from the use case. If there
are no beneficiaries of a use case then it is questionable if the use case is needed at all.
Use case and Actor briefs is a short description of a use case or an actor. e.g. Customer:
A person who comes to the car wash to get a car washed. e.g. Buy Wash: Accepting
a request for a car wash, checking if the car wash if ready for the next wash... Briefs
supplement the use case diagram and help document the use case.
Every use case diagram must have:
At least one use case
At least one actor
At least one actor associated with each use case
At least one use case associated with each actor
No association line between actors
No association line between use cases
Name every actor and use case
No label on any association line
Some use case diagram heuristics:
Name actors with nouns
Name use cases with verbs
Achieve a stakeholder's goal in a use case
Make use cases of uniform size and complexity
Fit the top level use case diagram for the system on a single page
17
3.4.2 Use Case Descriptions

Is a specification of the interaction between the actors and the system in a use case. It shows:
the actions and responses of each party in the interaction and the use case
the order in which each party acts
all possible courses of interaction between parties and the system - results in complex
activity flows
Is a dynamic model of the system. Use case descriptions consist of:
Use case name and number
Actors
Stakeholders and their needs
Pre-conditions - an assertion that must be true when an activity or operation begins.
This is assumed but not check by the use case.
Post-conditions - an assertion of what must be true when an activity or operation ends.
It must satisfy stakeholder needs.
Trigger - an event that causes a use case to begin. May be the first step in the use case.
Basic flow - An action flow is a sequence of steps that describes a successful interaction
between actors and the systems in a use case. Begins at the trigger and continues until
the use case ends.
Extensions
Show alternative action flows
May begin and end anywhere
Extensions may have extensions
!"#$!%&#$!'$#()*+,-.!/$0+1&2$!
Use Case number: name
Actors: actorList
Stakeholders and Needs:
stakeholderneedsList.
stakeholderneedsList.
Pre-conditions: what is assumed at the start.
Post-conditions: what is guaranteed at the end.
Trigger: the event that starts the use case.
Basic Flow:
# stepDescription
Extensions:
extensionIdentifier condition:
extensionIdentifier # stepDescription
Semester 1, 2013
Extensions use a special numbering scheme:

Numbers are for action step sequencing
18
30
Letter are for extension triggers

Extension identifiers have interleaved numbers and letters
An asterisk refers to all action steps
A dash is used for ranges of action steps
A comma separates action steps in a list
Use case description heuristics:
Fill in the use case template from top to bottom
Obtain use case and actor names from use case diagram
Make human actors stakeholders whose needs include completion of the task done by
the use case
Write simple declarative sentences in the active voice
Make actors or the product the subject of each step description
Write a basic flow with three to nine steps
Avoid sequences of steps by actors or the product
Don't specify physical details
Impose minimal order on activities
Use case diagrams can show different types of relationships between use cases and actors:
Generalisation between use cases When there is more than one version of the use case,
with some common actions and some unique actions then case use generalisation.
Generalisation
between actors
When oneuse
actorcases
does the same and more of another actor.
Generalization
between
Inclusion relationships between use cases is used when some use cases will always need
another use case included.
!"#$%&"#'#%()%*+'#%&",$%+$#%-#')(+$%+.%&"#%/)#%0,)#1%2(&"%
Extension relationships
between use cases is used to show where one use case is option3(4#'#$&%-#')(+$)%)+*#%,05+$)%($%0+**+$%,$3%)+*#%,05+$)%
ally extended
by an additional use case.
/$(6/#%&+%&"#%/)#%0,)#%/)#%7#$#',8(9,5+$:%
Semester 1, 2013
19
37
!!"#$#%&'()&*+$!,#'&*+$-.(/-!0#12##$!341+%-!
5$!1.#!6&%!7&14.!#8&9/'#:!
;%&$4.(-##!4&$!<+!#=#%>!
1.($?!1.#!&<9($(-1%&1+%!4&$!
<+!&$<!9+%#@!!
A.(-!4&$!B#!4&/1C%#<!($!&!
?#$#%&'()&*+$!%#'&*+$-.(/!
B#12##$!1.#!&41+%-!D!-(9('&%!
1+!($.#%(1&$4#!B#12##$!
4'&--#-@!
!"#$%&'(");'/.7+*$"#<$%='1)''*%>$'%?.$'$%
Semester 1, 2013
38
!"#$%#$%&$'(%)"'*%$+,'%&$'%-.$'$%)#//%./).0$%*''(%.*+1"'2%&$'%
-.$'%#*-/&('(3%
452+-'$$%5.0,'*16%)#//%$7//%8'%.%$1.*(./+*'%&$'%-.$'%1+%8'%&$'(%9+2%
4:.*&.//0%.((%-.2%$".2'263%
%!"#$%&'(%)@'2-1*/$"#0%A')+''/%B,)*.$%%
Semester 1, 2013
39
!"#$%#$%&$'(%)*%$"*+%,-$'$%+"'.'%*/'%&$'%,-$'%#$%*01*/-223%
'4)'/('(%53%-/%-((#1*/-2%&$'%,-$'6%
7/%)"'%'4-802'%)"'%9:.*,'$$%:-38'/);%&$'%,-$'%,*/)-#/$%-22%)"'%<&/,1*/-2#)3%
.'=&#.'(%<*.%-%,-$"%*.%,"'=&'%0-38'/)>%"*+'?'.%#$%"-$%)*%5'%'4)'/('(%<*.%
,.'(#)%*.%('5#)%,-.(%0-38'/)6%
Semester 1, 2013
20
40
4
4.1
Domain Modelling with Classes

Types of Class Models
Domain (conceptual) class models represent the problem including important entities or concepts and their attributes and important relationships. Important in product design because they help to:
Understand the problem domain
Setup data requirements
Validate requirements
Important in engineering design because they help to:
Understand a product design
Provide a basis for engineering design modelling
Conceptual modelling process:
1. Identify classes
2. Add attributes
3. Add associations
4. Add multiplicities
Design class models represent the classes in a software system including their attributes,
operations, association but no implementation details.
Implementation class models represent the classes in software system with implementation
details
Design and implementation class models represent the solution to the problem.
4.2
Attribute Specification Format
name : type [multiplicity] = initial-value

e.g. roundScore : int = 0, words : String[*] = ""
4.3
Operation Specification Format
name(parameter-list) : return-type-list
e.g. getScore() : int, setName(in : String)
4.4
Associations
Generalisation (inheritance) is useful when a class is the name as another class, and more
Aggregation used to show part-whole relationships. Composition is a weaker form.
Association are associations between classes that is not either of previous two.
21
!!"##$%&'($)#!'*+!,*+#+)-+.!/*'01&%'223!&)!456!
Labeled or unlabeled lines

Readable in two directions
Direction arrows
Role names
!!"##$%#&'()!
Pedals
Bicycle
1
Brakes
Frame
Semester 1, 2013
15
1
2
Seat
Wheels
4.5
Multiplicity
Number of instances of target class associated with single instance of source class.
4.6
Semester 1, 2013
17
Object diagrams
Models that show state of one or more objects at a moment during execution. Dynamic model
as opposed to class diagrams-static. Used in development of class diagrams. Comprised of
object name and attributes.
object-name : class-name
attribute-name = value
Interaction Models
Interaction Diagrams are notation used for modelling the communication behaviour of individuals exchanging information to accomplish some task. Focus is on sequence diagrams.
5.1
Sequence Diagrams
Most widely used because

they model the message flow between individuals which is the es!!"##$%&'($)!*+,(-,&%&./!
sential aspect of collaboration. Show message flow in the order it happens in time - sequence.
012!3+,(-,&%&./!'.!.12!.'452.!%,'##!2)6!$7!')!'##$%&'($)!&#!
Frame is a rectangle with

pentagon in top-left corner called name compartment.
.12!)+3824!$7!&)#.')%2#!$7!.12!.'452.!%,'##!.1'.!%')!82!
'##$%&'.26!9&.1!'!#&)5,2!&)#.')%2!$7!.12!#$+4%2!%,'##:!
sd interactionIdentifyer
- either a simple name or an operation from a class diagram.
Semester 1, 2013
22
16

!"#$%&'()!*+!,-.(/0)!12!345!
Semester 1, 2013
Lifeline Object, lifeline, activation, destroy.
24
Synchronous arrow has filled in head and suspends execution until message is complete
Asynchronous arrow has un-filled head and continues execution after sending message
Synchronous message return arrow is dotted.
5.1.1 Message Specification Format
variable = name(argumentList)
e.g. hello(), msg = getMessage(helloMessage), x = sin(a/2)
5.1.2 Interaction Fragments
!"#$%&'(!)*'+,-&.!/0',#(-!
Opt is equivalent to an if statement
Alt is the equivalent

to a switch or if-elseif-else
Break is the same as in Java
Loop
5.1.3 Sequence Diagram Heuristics
Put the sender of first message leftmost
Put individuals that interact heavily next to each other
23
Semester 1, 2013
22
!"#$%&'()*%!+&(,-%'$!./(-0#%!
Semester 1, 2013
!"#$%&!'#%()$*+!,-%)./$!
Semester 1, 2013
26
!!"##$!%&'()*+,!-.')$/*!
Semester 1, 2013
24
29
24
Position individuals to make arrows short and go from left to right

Put the self lifeline leftmost and draw the execution occurrence form the top to the bottom
Name individuals only if they are message arguments or are used in expressions
Choose a level of abstraction for the diagram
Suppress messages individuals send to themselves unless they generate messages to
other individuals
Suppress return arrows when using execution occurrences
Don't assign values to message parameters by name
5.1.4 Uses for Sequence Diagrams
Interactions between product and environment - system sequence diagrams
interaction between systems components in architecture design
Interactions in mid-level design
Can be used as (partial) use case descriptions
5.1.5 Interaction Design Process
Components and interactions must be designed together - component and interaction codesign - because:
Components may not support needed interactions
Interactions may rely on missing or unbuilt features of components
This all comes down to interfaces.
Outside-in design is designing from top-down, from most abstract to least abstract.
Use cases and requirement specifications
Design for interactions with environment (outside) first and then internal (in).
5.2
Control Styles
5.2.1 Centralised
A few controllers make all significant decisions.
Advantages:
Easy to locate decision making
Easy to see how decisions are made and alter the decision making process
Disadvantages:
Controller may become bloated - large, complex and hard to understand, maintain, text.
25
May treat other components are data repositories - increases coupling and destroys information hiding
Heuristics:
Avoid interaction designs where most messages originate from a single component
Keep components small
Make sure operational responsibilities are not all assigned to just a few components
Make sure operations responsibilities are consistent with data responsibilites
5.2.2 Delegated
Decision making is distributed among a few controller making the main decisions.
Advantages:
Controllers coupled to fewer components, reducing coupling
Information hidden better
Progtram easier to divide into layers
Preferred control style
Heuristics:
Have components delegate as many low-level tasks as possible
5.2.3 Dispersed
Decision making spread widely through program with few or no components making decisions
on their own.
Disadvantages:
Hard to see and understand flow of control
Components cannot do much on their own - increases coupling
Hard to hide information
Poor cohesion
Few modularity principles satisfied
Heuristics:
Avoid interactions that require each component to send many message.
26
5.3
Principle of Least Knowledge
Also known as the Law of Demeter.

Units have limited knowledge of other units
Units only talk to friends and not strangers
Basically, object should assume as little as possible about other objects.
Advantages:
Hides information
Keeps low coupling
Keeps high cohesion
Discourages an over-centralised control style
Encourages a delegated control style
Software Architectures
Architectural design is the activity of specifying the major parts; their responsibilities; properties
and interfaces; and the relationships and interconnections between them.
6.1
Role of Software Architecture
The architecture acts as a "blue-print" for the development team and provides the necessary
schematic which they can use to integrate their component. It can be used to assess impact
of changes and provides basis for evaluating extensions and maintenance - does the same for
new or additional requirements.
6.2
Characteristics of Software Architecture
Reliability and redundancy do we require redundant systems to meet reliability requirements

Performance what is the model of mean response or throughput times; what are the performance bottlenecks and resource usage
Safety do we need to build in safety monitoring or fail-safe modes
Modifiability and maintainability what is the life of the system. What provisions will be made
for future extensions and modifications.
6.3
Guidelines for a Good Design
Functional Independence is a measure of how well separated modules of a system are. If

well separated, then making changes to one modules does not effect other modules.
Functional independence is ensured by high cohesion and low coupling
Coupling is the degree to which a module relies on other modules. Low coupled usually
implies a small interface through which a module interacts with other modules
Cohesion is a measure of how strongly-related and focused the various responsibilities of a
software module are
27
6.3.1 Heuristics for Good Design

Reuse existing components where possible
Structure design to reflect problem structure where possible
Designs should appear to have been written by one person in one sitting
Designs should be built to accommodate change
Designs should be robust in the face of bad data or other conditions
Design should not descend to the level of code
The quality of the design should be assess throughout the design process
6.4
Decomposition
6.4.1 Hierarchical Decomposition

A sequence of layers.
Layers are ordered so that each subsystem in a later depends only on the sub-system in the
layers below. Sub-systems in the layers have no knowledge of the subsystems in the
layer above (Law of Demeter). Layer that depends on no other layers is the bottom layer,
and the layer that no sub-system depends on is the top layer. Architecture is closed if
each layer depends only on the layer immediately below otherwise it is open
HIERARCHICAL DECOMPOSITION!
Layer 1 (Top)
A:Subsystem
B:Subsystem
E:Subsystem
C:Subsystem
F:Subsystem
D:Subsystem
Layer 2
G:Subsystem
Layer 3 (Bottom)
ISO/OSI Model The decomposition into layers allows the developer to build up simple interfaces between layers that hide the details of the layer below. Layering allows a clean
separation of concerns - the developer can concentrate on the details of one layer while
not needing to worry about the details of other layers. OSI is a closed architecture. Utilised
abstraction.
Semester 1, 2013
Architecture Styles
Software Architecture consists of:

A system decomposition
Global and persistent data
Global control flow and interaction
28
21
Boundary conditions
Inter-subsystems communications protocols
Architectural Style is a template or a form of design pattern that can use common structures
and interactions to specify high-level designs. Part of the knowledge base of good designers. Typical styles:
Pipes and Filters
Repositories
Objects
Layered
Event-driven
Client-Server
Process-control
Interpreters
The final architecture may come from a single style but usually is a combination of styles.
Awareness of styles simplifies problem of coming up with good system architectures - use
whats already been done. They capture existing knowledge about trade-offs in system
architecture.
7.1
Repository Style
Centralised data base for all shared data.

Advantages:
Efficient way to share large amounts of data
Sub-systems don't care about how data is held/produced
Centralised management e.g. backups, security
Disadvantages:
Sub-systems must agree on repository data model - effectively a compromise
Data evolution is difficult and expensive
No scope for specific management policies
Data is difficult to distribute efficiently
7.1.1 Problem
Typically used when:
There is a structured body of data that is to be maintained
There are a number of different and frequently used operations to be performed on the
data
Data is persistent and must maintain integrity despite the high number and frequency of
operations on it
29
7.1.2 Solution
Data is independent from computation
Interaction style is given by the computational elements interacting the central data store
Control style varies and depends on the application; can be state driven (depends on the
data), synchronous or asynchronous
7.2
Pipes and Filters
Data flows from input of pipeline through a variety of pipes to the output end of pipeline. As it
flows, functional transformations are carried out on the data. Extensively used in data processing systems but not suitable for top-level architecture of interactive systems.
7.2.1 Problem
Used when there is a series of operations to be performed on data
Requires problem to be decomposed into a set of computational elements that continuously transforms data from input to output
7.2.2 Solution
Interaction style is through data-streams; data may be represented as ASCII text, XML
or internal data structures
Control style between filters in linear; output of one filter is fed directly the input of next
filter. Thread of control is inside the filters and thus is independent and may be complex
7.3
Client-Server
Model for implementing systems distributed across networks. Consists of:

Set of stand-alone servers that provide specific services e.g. printing, database management
Set of clients that call on the services
Network for connecting clients to servers
Implicitly needs to be able to handle concurrent access to servers - threading.
Advantages:
Distribution of data is straightforward
Make efficient use of networked systems - cheaper hardware
Easy to add new servers or upgrade existing servers
Disadvantages:
No shared data model; sub-systems will tend to organise data their own way - inefficient
data interchange
30
Redundant management in each server

No central register of names or services - hard to find out what servers and services are
available
Client-Server with layers can decompose server into the following layered sub-systems:
Presentation Tier - the user interface, display results
Logic Tier - interpreting requests, making decisions
Data Tier - managing data, accessing data and maintaining data integrity
7.4
Control Styles
7.4.1 Call-Return Model

Top-down sub-routine model where control starts at the top of the sub-routine hierarchy and
moves downards - applicable to sequential systems - basically callbacks.
7.4.2 Manager Model
Applicable to concurrent systems. One system component controls stopping, starting and coordinations of other subsystems. Can be implemented in sequential systems with case statement.
e.g. embedded system with uC and peripheral components.
7.4.3 Event Driven
Control driven by external, usually of unknown timing (asynchronous), events.
Broadcast Model events are broadcast to all subsystems that are capable of handling the
events.
Effective in integrating subsystems of different computers and in a network
Sub-sytems register their interest in specific events and are notified when and event
occurs
Control is not part of event detection but of the components who handle the events
Interrupt Model Utilised in real time systems. Events are detected by interrupt handler and
passed on to the appropriate components for processing.
Known interrupts types - interrupt vector - with a handler defined in each
Allows for fast response but complex to program and difficult to validate
7.4.4 Reference Architectures
Generic Models are abstractions from a number of real systems that encapsulate the principal
characteristics of these systems - bottom up method
Reference Models are more abstract, idealised models. Provide information about a specific
class of systems and mean of comparing different specific architectures
31
State Charts
Specified by a:
1. Set of states
2. Set of inputs
3. Set of outputs
4. Next state function
Deterministic means that an input to every state has a clear transition to another state. Nondeterministic means that it could go to different states from the current state with a single
input.
8.1
Transition String Format
event-signature [guard] / action-expression

e.g. buttonPress [enabled] / closeWindow. Don't have to have a guard and an action. Must
have an event-sig though.
8.2
Symbol Compartments
Name, internal transitions and optionally nested diagram (composite).

!A$+$(!A3*4%1!B%*#+'$*(,$-!
Action Labels
Name
Idle
entry/amount = 0
do/display( greeting )
Internal Transitions
!"#!$%!$&'((!)%*#+'$*(,$-!
8.3 Internal
Transitions
.+*(!)%*#+'$*(,$!
/#0%,+12!*+3!4(!+5+)&(6!$%!+!$+4!$%!-+7(!-#+)(!
action-label
/ action-expression
e.g. entry
/ count
:= 0, do / display flashing light
8+$&,+*(!
9,$(',+1!$'+,-:0%,-!
9,$(',+1!$'+,-:0%,!-#():;)+0%,-<!%,(!#('!1:,(!
entry execute
the associated action-expression upon entry
='+,-:0%,!#'%)(--(6!>:$&%?$!)+?-:,@!+!-$+$(!)&+,@(!
exit execute the associated action-expression upon exit
/#0%,+1!
do execute
the associated action-expression upon state entry and continue until exit or action
.(-$(6!6:+@'+*!
completion
/#0%,+1!
include a finite state automaton (composite)
Semester 1, 2013
32
17
!"#$%$&"'(%)$"*+$(",-$&)-%."/)%-0+12-0"
8.4
Semester 1, 2013
21
Sequential Composite States
1. Entering a composite state also means entering its nested state. Its entry command is
executed as well as its nested state. This continues until there are no more nested state.
They jointly become the current state.
2. A transitions from the enclosed state causes the exit actions of that state to be exited,
along with any other enclosing states.
3. The transition action is then performed
4. The entry actions of entered state are executed from outermost state to innermost state
as in step 1.
Click to edit Master title /&01-!"#$&201-!3%4$%!

style
!"#$%&'($)!*$+$%,'-$!+.$!
5%'+$!416-!+.$!$#$&201-!1%4$%!71%!+.$!(+8+$!,14$9!
8.5
Semester 1, 2013
Stubs
Symbol used as a termination and origin point for transitions to and from states in a suppressed
nested state chart.
8.6
State Chart Heuristics

Check every non-completion transition arrow is labeled
33
26
to edit Master title style

!Click
"#$%%&'!"#(#&!)*(+,-&!
Semester 1, 2013
28
Check that no arrow leaves a final state

Check for black holes (get stuck) and white holes (can't get to)
Label states with adjectives
Name events with verbs or nouns describing actions
Name actions with verbs
Combine arrows with same source and target states
Use stubs and the include internal transition to decompose large and complicated state
charts
Make on initial state in every state chart (including nested state charts)
Check that no event labels two or more transitions from a state
Check that all guards on same event are exclusive
Use [else] guards to help ensure that guards are exclusive and exhaustive
8.7
Recognisers and Transducers
Recogniser is a finite automaton that responds to events but generates no actions. Typically
used to determine if the input is valid - accepted or recognised. Accepted iff:
1. The automaton reads each input value
2. The automaton moves to the corresponding new state for the input symbol
3. and finishes in an accepting state when all the input is consumed
Typical examples include language translators, lexical analysers and interpreters
Transducer is a finite automaton that both responds to events and generates actions. Typically
used to model things that transform inputs to outputs.
Useful in product design as well as engineering design
Examples: devices, programs with complex state-based behaviour.
34
8.8
Dialog Map
Acceptors also used to model user interfaces.

Dialog Map is a state diagram whose nodes represent user interface states. Events are occurrences
(user input actions) that drive the program between user interface states.
!"#$%&'!($)!*+$,)%-!
User InterfaceSWEN30006:
Diagram
is a drawing
of (part of) a product's visual
when
it is in a parSoftware Modelling
and Design
Semester display
1, 2013
40
ticular state. Dialog maps and user interface diagrams can be used together: every user
interface diagram should specify the visual form of a state in a dialog map, and every
state is a dialog map should have its visual form specified by a user interface diagram.
!"#$%!&'($%)*+$!,-*.%*/!01*/23$!
9
9.1
Semester 1, 2013
42
Designing with Classes

OO Design Principles
9.1.1 Open-Closed Principle (OCP)

Software modules should be Open for extension, yet Closed for modification. Basic idea is
to have an abstract class that be extended when changes to implementation may be needed.
Shape class example.
35
9.1.2 Liskov Substitution Principle

Functions that use references to super-classes must be able to use objects of derived subclasses without knowing it.
9.1.3 Dependency Inversion Principle (DIP)
Program to and interface, not an implementation.
Advantages:
Clients are unaware of the specific class of the object they are using
Loosens coupling
Increases likelihood of reuse
Improves opportunities for composition since contained objects can be of any class that
implements a specific interface since interfaces don't have attributes.
Disadvantages:
Modest increase in design complexity.
9.1.4 Single Choice Principle
Whenever a software system must support a set of alternatives, ideally only one class in the
system should know the entire set of alternatives
9.1.5 Favor Composition Over Inheritance
Advantages of Inheritance:
New implementation is easy, since most of it is done (inherited)
Easy to modify or extend the implementation being used
Dangers of Inheritance:
Breaks encapsulation since it exposes subclass to implementation details of super class
- "white box" reuse
Subclasses may need to be changed when the implementation details of super class
change
Implementations inherited from super-class can not be changed at runtime.
Coad's Rules for when to use Inheritance;
A sub-class "is a special kind of" and not "is a role played by a..." relationship between
classes
An instance of a sub-class never needs to become an object of another class
A sub-class extends, rather than overrides or nullifies, the responsibilities of its superclass
A sub-class does not extend the capabilities of what is merely a utility class
For a class in the actual problem domain, the sub-class specialises a role, transaction or
device
36
9.1.6 Composition
Method of reuse in which new functionality is obtained by creating an object composed of other
objects - new functionality obtained by delegating functionality to one of the objects used in
the composition. e.g. window class having a rectangle attribute to delegate all the rectangle
related operations to. Window shouldn't merely inherit rectangle because not every window
must be a rectangle.
Delegation occurs when two objects are involved in handling a request: a receiving object and
a delegate.
10 Software Architecture and Design Patterns

Design pattern addresses a recurring design problem that arises in specific design situations
and presents a solution to it. Features:
Why create something new if there is something out there that works well?
Well-structured OO systems have recurring patterns of classes and objects
Knowledge of patterns that have worked allow the designer to be more productive
and the resulting designs to be more flexible and reusable
Advantages:
Capture expertise and make it accessible to non-experts in standard form
Facilitate communication among developers by providing a common language
Make it easier to reuse successful designs and avoid alternatives that diminish reusability
Facilitate design modifications
Improve design understandability
Improve design documentation
10.1
Gang of Four design patterns
Creational Patterns abstract the object instantiation process

Structural Patters describe how classes and objects can be combined to form larger structures
Behavioural Patterns are most specifically concerned with communications between objects
10.1.1
Factory Method Pattern
Intent - define an interface for creating an object, but let subclasses decide which class
to instantiate. Factory Method lets a class defer instantiation to subclasses.
Motivation The createDocument() method is a factory method.
Applicability - used when:
A class can't anticipate the class of object it must create
37
!"#$"#%
!"#$"%&$%'$(")*&+"%*,)%+)"&-$.%&$%,/0"+(1%/2(%3"(%42/+3&44"4%5"+'5"%67'+7%
+3&44%(,%'$4(&$-&("8%9&+(,):%;"(7,5%3"(4%&%+3&44%5"*")%'$4(&$-&-,$%(,%
42/+3&44"48%
&'()*('"%
<,$4'5")%(7"%*,33,6'$.%*)&="6,)>8%
Document
Application
Theopen()
Factory Method
Pattern (contd)!
createDocument()
close()
openDocument()
Document doc=createDocument()
docs.add(doc)
Save()
!""#$%&'$#$()*
doc.open()
!"#$%&#$'()%*+,$-#%&*.$/(0#+1$21$(1,$*3$%&#$3*44*5216$"2%7(8*1"9$
:$)4(""$)(1;%$(18)2/(%#$%&#$)4(""$*3$*<=#)%"$2%$>7"%$)+#(%#?$
MyDocument
MyApplication
:$)4(""$5(1%"$2%"$"7<)4(""#"$%*$"/#)23,$%&#$*<=#)%"$2%$)+#(%#"?$
createDocument()
return MyDocument
+(,-%(-,.*
?7"%!"#$%#&'!()#*%@A%="(7,5%'4%&%*&+(,):%="(7,58%
Creator
factoryMethod()
Product
SWEN30006: Software
Modelling and Design
anOperation()
ConcreteProduct
.
product = factoryMethod() Semester 1, 2013
.
26
ConcreteCreator
factoryMethod()
return new concreteProduct()
Semester 1, 2013
27
A class wants it subclasses to specify the objects it creates

Structure
Participants
Product defines the interface for the type of objects the factory method creates
ConcreteProduct Implements the Product interface
Creator declares the factory method, which returns an object of type Product
ConcreteCreator Overrides the factory method to return an instance of a ConcreteProduct
Collaborations - Creator relies on its subclasses to implement the factory method so that
it returns an instance of the appropriate ConcreteProduct
Benefits
Code is made more flexible and reusable by the elimination of instantiation of applicationspecific classes
Code deals only with the interface of the Product class and can work with any ConcreteProduct class that supports this interface
Liabilities - Clients might have to subclass the Creator class just to instantiate a particular
ConcreteProduct
Implementation Issues
Creator can be abstract or concrete
If the factory method is to have the ability to create multiple kinds of products then
the factory method has a parameter (and possible and if-else/case) to decide what
object to create. We could override this factory method in a subclass to try to avoid
OCD problems.
38
10.1.2 Observer Pattern

Intent - define a one-to-many dependency between object so that when one object changes
state, all its dependents are notified and updated automatically
Also Known As - Dependents, Publish-Subscribe, Model-View
Motivations - the need to maintain consistency between related objects without making
classes tightly coupled
Applicability - use when:
When an abstraction has two aspects, one dependent on the other. Encapsulating
these aspects in separate objects let you vary and reuse them independently
When a change to one object requires changing many others
When an object should be able to notify other objects without making assumptions
about those objects (or minimal assumptions e.g. object.update())
!"#$%&'#()#($*+,#(-$./0-1234$
Subject
0..*
Attach(Observer) 1
Detach(Observer)
Notify()
For all o in Observers
o-> Update()
Doument
DoumentState
GetDocument()
SetDocument()
0..*
Observer
Update()
Reviewer
ReviewerState
UpdateDocument()
ObserverState
= Subject->GetState()
Return subject
state
Semester 1, 2013
40
Participants
Subject
* Keeps track of its observers
* Provides an interface for attaching and detaching Observer objects
Observer - defines an interfaces for update notification
ConcreteSubject (model)
* The object being observed
* Stores state of interest to ConcreteObserver objects
* Sends a notification to its observers when its state changes
ConcreteObserver
* The observing object
* Stores state that should stay consistent with the subject's]
* Implements the Observer update interface to keep its state consistent with the
subject's
Benefits
Minimal coupling between the Subject and Observer
* Can reuse subjects without reusing their observers and vice versa
* Observers can be added without modifying the subject
39
* All subject knows is its list of observers

* Subject does not need to know the concrete class of an observer, just that each
observer implements the update interface
* Subject and observer can belong to different abstraction layers
Support for event broadcasting
* Subject sends notification to all subscribed observers
* Observers can be added/removed at any time
Liabilities
Possible cascading of notifications - observers are not necessarily aware of each
other and must be careful about triggering updates
Simple update interface requires observers to deduce changed item
Implementation Issues
How does the subject keep track on its observers? (List)
What if an observer wants to observe more than one subject - have the subject tell
the observer who it is via the update interface
Who triggers the update?
* The subject whenever its state changes
* The observers after they cause one or more state changes
* Some third party object(s)
Make sure the subject updates its state before sending out notifications
How much info about the change should the subject send to the observers?
* Push Model - lots
* Pull Model - very little
Can the observers subscribe to specific events of interest
Can an observer also be a subject
What if an observer wants to be notified only after several subjects have changed
state
* Use an intermediary object which acts as a mediator
* Subjects send notifications to the mediator object which performs any necessary
processing before notifying the observers
10.1.3
Model View Controller (MVC) Pattern
Is an architectural pattern that is similar to the observer pattern where there are multiple clients
interacting with a single model.
Model contains the data and the methods that govern the access to and updates of the data. In
enterprise systems, a model serves as a software approximation of a real-world process.
View displays the content of a model. It specifies exactly how the data should be presented.
If the data changes, the view must update the presentation of the data as needed. Note
- there may be multiple views registered with a single model.
40
!"#$%&'($)&*"+,-"%%$-.
Controller
Method
Calls
Application behaviour
Maps user actions to model updates
Selects a view for a response
Notifies views of changes
Events
Select
View
Model
Updates
User
Actions
View
Model
Renders the model

Requests updates from models
Passes user actions to the model
State
Requests
Change
Notifications
Application State
Handles Queries about State
Notifies each view of changes in
state.
Controller translated the user's interactions with the view into actions that the model will perform.
Semester 1, 2013
49
MVC Dynamic Behaviour:

The user only manipulates the controller
The controller may alter (seletc) the view or (update) the model
If the different view is selected by the controller, the view redisplays itself by accessing
the model to obtain the latest and/or the required data in order to display
When the model is altered by the controller, it responds by doing the required computations.
Once it is done, the model issues a notification that is has changed
Can be done by announcing an event, or by directly notifying controllers and views
In any case this is done internally and fits the bill for a layered architecture
!"#$!%&'()*+!,-.(/*01!
Semester 1, 2013
52
Advantages:
View and controllers can be added, removed or changed without disturbing the model
Views can be added or changed during execution
User interface components can be changed even at runtime
Disadvantages:
41
Views and controllers are often hard to separate

Frequent updates may slow data display and degrade user interface performance
The MVC style makes user interface components highly dependent on model components
Implementation issues:
MVC can be implemented using a push- or pull-model
In a push model the view registers itself with the model and change notifications are
sent to the view (the model pushes changes to the view)
In a pull model the view must call the model whenever the view needs to retrieve the
most current data (view pulls data from the model)
11 Architectural Design Specification

Architectural design usually begins during product design for many reasons:
Judging the feasibility of product designs is not often possible without knowing the architecture - helps product feasibility
Without a high level architecture it is difficult to convince stakeholders their needs can be
met - helps show people what you mean
Architectures are required to conduct trade-off analysis in quality attributes
11.1 Non-Functional Requirements

Are one of the main considerations when evaluating and deciding up an architecture; also
known as:
Quality Attribute is a characteristic or property of a software product independent of its function that is important in satisfying stakeholder needs.
Architectures have a big influence on quality attributes:
Development attributes
Maintainability is how easily a product can be corrected, improved or ported
Reusability is the degree to which a product's parts can be reused in another product
Operational attributes
Performance is the ability to accomplish product function within time or resource limits
Availability is how ready the product is for use
Security is the ability to resist being harmed or causing harm by hostile acts or influences
Many architectures will be able to satisfy the functional requirements of a product, but they will
differ in their ability to satisfy the non-functional requirements. Some architectures may favour
certain non-functional requirements over others and there becomes trade-offs:
For example - availability could be increased through the use of server farms, but this
makes the architecture more complicated - could result in less reliability.
For example - encryption/decryption will improve security but it will impact performance
(speed, throughput).
42

Software Modelling & Design Summary PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Modelling & Design Summary PDF

Uploaded by

Copyright:

Available Formats

SWEN30006: Software Modelling & Design

February 28, 2015

2 Methods for Solving the Design Problem

3 Software Design Process and Modelling

4 Domain Modelling with Classes

5.2 Control Styles . . . . . . . . .

9 Designing with Classes

10 Software Architecture and Design Patterns

11 Architectural Design Specification

The Design Problem

SWEN30006: Software Modelling and Design

Concept aims to identify the initial idea of the system.

Methods for Solving the Design Problem

The General Pattern of a Function Oriented

2.1.1 Data Flow

SWEN30006: Software Modelling and Design

Figure 1: Data flow diagram notation.

The Context Diagram

Figure 2: Context diagram in SEPD.

SWEN30006: Software Modelling and Design

Determining the Flow Boundaries

SWEN30006: Software Modelling and Design

Figure 3: Determining the flow boundaries and transform centre.

2.1.3 Design Steps

Figure 4: First and Second level factoring.

SWEN30006: Software Modelling and Design

Data Structure Oriented Design Methods

2.3 Component Oriented Design Methods

Jacksons Structure Diagrams

SWEN30006: Software Modelling and Design

Jacksons Network Diagram for the SEPD

SWEN30006: Software Modelling and Design

Figure 6: Step 1: form the network diagram e.g. SEPD.

Input Data Structures for a Report Generator

SWEN30006: Software Modelling and Design

The Program Structure Based on the Output

The Program Text using Pseudo Code

Figure 9: Step 5: write the program text e.g. SEPD.

SWEN30006: Software Modelling and Design

Software Design Process and Modelling

Activity is the action that a person or a group undertakes to achieve a goal.

3.1.1 Analysis of the Waterfall

SWEN30006: Software Modelling and Design

Executable versus Non-Executable Models

3.2.1 Non-Executable Models

Proof of concept prototype

3.2.4 Prototyping Risks

SWEN30006: Software Modelling and Design

3.3.1 Activity Partitions

SWEN30006: Software Modelling and Design

3.3.2 Control and Data Flows

SWEN30006: Software Modelling and Design

3.3.3 Activity Parameters

SWEN30006: Software Modelling and Design

Use Case Models

Use Case Name

Exercise Determine the Key Functions of a System fro

SWEN30006: Software Modelling and Design

3.4.2 Use Case Descriptions

SWEN30006: Software Modelling and Design

Extensions use a special numbering scheme:

Letter are for extension triggers

SWEN30006: Software Modelling and Design