software modelling & design summary.pdf

43
SWEN30006: Software Modelling & Design Summary February 28, 2015

Upload: bradley-jackson

Post on 22-Jan-2016

36 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Software Modelling & Design Summary.pdf

SWEN30006: Software Modelling & DesignSummary

February 28, 2015

Page 2: Software Modelling & Design Summary.pdf

Contents

1 The Design Problem 31.1 Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Design Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Methods for Solving the Design Problem 42.1 Funtion Oriented Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Product Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Design Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Data Structure Oriented Design Methods . . . . . . . . . . . . . . . . . . . . . . 72.2.1 Design Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Component Oriented Design Methods . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Software Design Process and Modelling 103.1 Systems Analysis Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1 Analysis of the Waterfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.2 The Interactive Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.3 Rapid Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Executable versus Non-Executable Models . . . . . . . . . . . . . . . . . . . . . 113.2.1 Non-Executable Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.2 Types of Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.3 Uses of Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.4 Prototyping Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Activity Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.1 Activity Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.2 Control and Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3.3 Activity Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3.4 Activity Diagram Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4 Use Case Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.1 Use Case Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4.2 Use Case Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Domain Modelling with Classes 204.1 Types of Class Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Attribute Specification Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 Operation Specification Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.4 Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.5 Multiplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.6 Object diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Interaction Models 215.1 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1.1 Message Specification Format . . . . . . . . . . . . . . . . . . . . . . . . 225.1.2 Interaction Fragments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.3 Sequence Diagram Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 225.1.4 Uses for Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . 245.1.5 Interaction Design Process . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1

Page 3: Software Modelling & Design Summary.pdf

5.2 Control Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2.1 Centralised . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2.2 Delegated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2.3 Dispersed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.3 Principle of Least Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6 Software Architectures 266.1 Role of Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2 Characteristics of Software Architecture . . . . . . . . . . . . . . . . . . . . . . . 266.3 Guidelines for a Good Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.3.1 Heuristics for Good Design . . . . . . . . . . . . . . . . . . . . . . . . . . 276.4 Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.4.1 Hierarchical Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 Architecture Styles 277.1 Repository Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7.1.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.1.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.2 Pipes and Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.2.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.2.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.3 Client-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.4 Control Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7.4.1 Call-Return Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.4.2 Manager Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.4.3 Event Driven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.4.4 Reference Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8 State Charts 318.1 Transition String Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318.2 Symbol Compartments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318.3 Internal Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318.4 Sequential Composite States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.5 Stubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.6 State Chart Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.7 Recognisers and Transducers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338.8 Dialog Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9 Designing with Classes 349.1 OO Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.1.1 Open-Closed Principle (OCP) . . . . . . . . . . . . . . . . . . . . . . . . . 349.1.2 Liskov Substitution Principle . . . . . . . . . . . . . . . . . . . . . . . . . 359.1.3 Dependency Inversion Principle (DIP) . . . . . . . . . . . . . . . . . . . . 359.1.4 Single Choice Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359.1.5 Favor Composition Over Inheritance . . . . . . . . . . . . . . . . . . . . . 359.1.6 Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2

Page 4: Software Modelling & Design Summary.pdf

10 Software Architecture and Design Patterns 3610.1 Gang of Four design patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

10.1.1 Factory Method Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3610.1.2 Observer Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3810.1.3 Model View Controller (MVC) Pattern . . . . . . . . . . . . . . . . . . . . 39

11 Architectural Design Specification 4111.1 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3

Page 5: Software Modelling & Design Summary.pdf

1 The Design Problem

The design problem is to develop a description of the system that can be implemented by de-velopers and, if implemented, will meet all of the requirements. Designs can be seen as areasoning from a set of requirements and constraints to a new piece of reality; bringing some-thing new into being. Requirements (what) and design (how) come from different conceptualworlds 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 solutionto a design problem.

Modelling represents the objects, system and software in a way that aids understanding andsolution.

Decomposition breaks the complicated problem down into smaller and more easily solvedpieces.

Design Knowledge uses, adapts and extends previously developed ideas where applicable.

1.1 Waterfall Model

Semester 1, 2013 10 SWEN30006: Software Modelling and Design

!!"#$!%$&$'()!*+,-$.!/$0$123.$&-!4(5$6)+)1$!728$1!

Testing

Requirements

SystemDesign

Implementation

Software Requirements Package

Code

Maintenance

System

SoftwareDesign

System DesignsH/W and S/W

Software Architectureand Detailed Designs

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 bothcontrol flow and communication between sub-systems. Key activities in component de-sign are:

• System Structuring

4

Page 6: Software Modelling & Design Summary.pdf

• Control Modelling• Modular Decomposition

Component design also aims to design the services that each component must deliverand 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 tomove 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 model2. Add more detail to class models to evolve design into something that can be

implemented3. Repeat 2 until a model is reached in which the classes, interfaces and control

strategies are straightforward to implement.

2 Methods for Solving the Design Problem

2.1 Funtion Oriented Methods

Begin with the functional requirements specified in the requirements specification. During thedesign process:

• High-level functions are successively decomposed into more detailed functions

• When the functions are simple enough - such that they could be implemented - they aremapped 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 whichthe functions operate.

5

Page 7: Software Modelling & Design Summary.pdf

Semester 1, 2013 6 SWEN30006: Software Modelling and Design

The General Pattern of a Function Oriented Design Solution

System State

F1 F3F2

F4 F5

!"#$%&'()*"(%+,-.($./%0.#-1(%2"3'*"(#%4##'5.%4%)"55"(%#6#$.5%#$4$.%",%/4$4%#$",.%'7"(%89-)9%$9.%:'()*"(#%"7.,4$.;%2.1.1 Data Flow Diagram

1. Start with the context diagram

2. The System transform must be decomposed to include the details of exactly how inputsflows are transformed into output flows. Add new transforms and create new data flowsto achieve this.

3. If more detail is need to achieve implementation, choose one of the transforms and ex-pand 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 flowdiagrams - just breaking transitions into smaller transitions that are easily implementable.

Semester 1, 2013 10 SWEN30006: Software Modelling and Design

DATA-FLOW DIAGRAM NOTATION

Figure 1: Data flow diagram notation.

Semester 1, 2013 12 SWEN30006: Software Modelling and Design

The Context Diagram

Project Coordinators

Students

Administrators

SEPDSystem

Project Coordinators

Students

Project Clients

Commands

Project Details

Queries

Reports

ProjectDetails

ProjectDetails

Figure 2: Context diagram in SEPD.

6

Page 8: Software Modelling & Design Summary.pdf

Context Diagram shows the data flows coming into - and out of - the system.The system isrequired 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 andout of the system transform back into the environment. External data must be transformed tointernal 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 systemwhere incoming data flows pass through the trans-form centre and start to move on paths back to the environment.

Output Flows are data flows that lead back to the environment.

Semester 1, 2013 22 SWEN30006: Software Modelling and Design

Determining the Flow Boundaries

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 resideat 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.

7

Page 9: Software Modelling & Design Summary.pdf

• Start at the transform centre and work outwards along input flows and then forwardalong output flows.

• Each transform is added as a sub-module of the one it is connected to by a dataflow.

• Modules can be combined according to the good design (high cohesion, low cou-pling).

Semester 1, 2013 24 SWEN30006: Software Modelling and Design

Second Level Factoring

Figure 4: First and Second level factoring.

2.2 Data Structure Oriented Design Methods

Jackson's technique; data-structure oriented design methods start out by designing the inputand output data structures. The assumption is that any system interacts with the outside worldthough its data structures. Thus, a correct model of the data can be transformed into a systemthat 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. Itis also a package, web service, web resource or module that encapsulates a set of function ordata or both. They can be composed or deployed independently. Component design is aboutproviding, developing and integrating components to form complete architectures. Key designissue is assuring levels of trust in component based design.

8

Page 10: Software Modelling & Design Summary.pdf

Semester 1, 2013 6 SWEN30006: Software Modelling and Design

Jackson’s Structure Diagrams

Procedure

Sequence

A B C

Hierarchy

Sequence

Action/Process Selection Iteration *

Legend

Figure 5: Jackson's Structure Diagrams.

Semester 1, 2013 9 SWEN30006: Software Modelling and Design

Jackson’s Network Diagram for the SEPD

Generate Report R1

Generate Report R2

Generate Report R3

Cmds

Proj.Details.

Queries

ReportR1

ReportR2

ReportR3

ProjectDetails

(Persistent Store)

Data Stream State VectorProcess

Symbols

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

Semester 1, 2013 10 SWEN30006: Software Modelling and Design

Input Data Structures for a Report Generator

Project Details

CompanyContact Environment Features

*

HardwareSpec.

Operating System Spec.

Prog. Languages

*

Tool-ChainName Email Mobile

IPProject Status

Contract IP Position

Figure 7: Step 2: define the data structures e.g. an input to SEPD.

9

Page 11: Software Modelling & Design Summary.pdf

Semester 1, 2013 13 SWEN30006: Software Modelling and Design

The Program Structure Based on the Output

GenerateReport 1

GenerateCompany

Generate Contact

Generate Name

Generate Email

GenerateMobile

GenerateIP

Generate Project Status

GenerateContract

GenerateIP Position

GenerateReport Layout

!"#$%&'(&)*$+,&-.,-&#$/+$"/#&)&."/.)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$

Figure 8: Step 3: derive the program structures e.g. report generator 1 of SEPD.

Semester 1, 2013 14 SWEN30006: Software Modelling and Design

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.

10

Page 12: Software Modelling & Design Summary.pdf

3 Software Design Process and Modelling

3.1 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 toand end point to achieve a set of desired goals.

Systems analysis processes are performed by developers starting from the time the client pro-vides the list of needs through to the delivery of the product to the client. The processes arethen further divided up into:

• Analysis Activities (Product Design)

• Design Activities (Engineering Design)

Semester 1, 2013 7 SWEN30006: Software Modelling and Design

!"#$%&'()#'$*+,#-.+//$0-&1#22$

Requirements Engineering

Design

Implementation

Testing

Maintenance

0-&'31,$45+/62(2$ 0-&'31,$758(5##-(58$

9#2(85$:,6/#2;$0+<#-52$+5'$%#,"&'2$+-#$32#'$"#-#=$

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 thestrict waterfall. Is a good model for previously built systems and for well-defined systems thathave well-define goals.

3.1.2 The Interactive Model

Aims to develop a minimal but useable system and then improve by performing successiveiterations over it. Each new iteration builds in new requirements, improves the design andexisting code. Can get constant feedback from clients to improve. Is a combination of productdesign and product engineering. Each iteration combines product design in the analysis activity,and product engineering in the design, implementation and testing activities. Product designactivities in successive iterations are linked:

• Each successive product design activity extends and improves the results of the previousproduct design activity.

11

Page 13: Software Modelling & Design Summary.pdf

Semester 1, 2013 9 SWEN30006: Software Modelling and 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!

Analysis

Architecture

Implementation Design

Test

• Each successive product design activity extends and improves the results of the previousproduct 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 pro-duction 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 littleabout the actual actions being undertaken. UML class diagrams are not executable - they justmodel the relationships between the classes (entities) in a system. It is sometimes necessaryto 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 canexpose vague or uncertain requirements. Has the advantage of being able to show theclient how the system might look and behave. Also a good way of development team togain 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

Page 14: Software Modelling & Design Summary.pdf

• 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

Page 15: Software Modelling & Design Summary.pdf

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 flowof control and data between the activities.

Semester 1, 2013 24 SWEN30006: Software Modelling and Design

Click to edit Master title style !"#$%&'(!)&*+,*-.!/,*0#1&0+!

guards

merge node

decision node

Semester 1, 2013 28 SWEN30006: Software Modelling and Design

Click to edit Master title style !!"#$%&'(!)'*!+#&'&'(!,#*-.!

fork node

join node

3.3.1 Activity Partitions

Activities can be grouped into activity partitions (swimlanes) to denote the person/subsystem/objectthat implements and is responsible for it.

14

Page 16: Software Modelling & Design Summary.pdf

Semester 1, 2013 31 SWEN30006: Software Modelling and Design

Click to edit Master title style !"#$%&'(!)*+$$,-.!

Sort Clothes

Wash Whites

Wash Darks

Dry Clothes

Fold Clothes

Do Laundry

Machine A Machine B Person X

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.

Semester 1, 2013 34 SWEN30006: Software Modelling and Design

Click to edit Master title style

control flow

control flow

data flows

!"#$%&#'!($)!*(%(!+'#,!-.(/0'1!

pin

3.3.3 Activity Parameters

Object nodes placed on activity symbols to indicate data or object inputs or outputs. Containthe 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

Page 17: Software Modelling & Design Summary.pdf

• Make sure all nodes entering an action node can provide tokens concurrently

• Use the [else] guard at every branch

Semester 1, 2013 37 SWEN30006: Software Modelling and Design

!!"#$%&'(!)&*+,*-!./*-012!

max = a[i]

FindMax a : int[1..*] max : int

[else] [i < a.length]

i++

[max < a.[i]]

[else]

max = a[0] i = 1 a

max

3.4 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 andthe actors involved in each use case.

Actor is a type of agent, or external entity, that interacts with a product. Actors are roles notindividuals; the product in never an actor.

Semester 1, 2013 9 SWEN30006: Software Modelling and Design

Click to edit Master title style Use Case Diagram Symbols

Actor Name

Use Case Name

Association Line

Use Case Symbol

Actor Symbol

Scenario is a concrete interaction between a product and particular individuals. A use case isan abstraction of the interaction between the product and specific individuals. A scenariois thus an instance of a use case. Scenarios can help to envisage how the product maybe used. Designers can use a bunch of scenarios to explore ideas about the product andhow it could be designed for the way it will be used. The scenarios are then generalisedto generate use case by identifying actors and the sequence of actions that must be takenduring an interaction to achieve the goals of an activity.

16

Page 18: Software Modelling & Design Summary.pdf

Semester 1, 2013 10 SWEN30006: Software Modelling and Design

Exercise – Determine the Key Functions of a System fro a Use case Diagram.

System

Buy a Wash

Select a Wash

Activate/ Deactivate

Wash the Car

Produce a Log

Stall SensorCustomer

Manager

Soap Sensor

Beneficiary of a use case is an actor that receives some benefit from the use case. If thereare 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: Acceptinga request for a car wash, checking if the car wash if ready for the next wash... Briefssupplement 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

Page 19: Software Modelling & Design Summary.pdf

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 complexactivity 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 interactionbetween actors and the systems in a use case. Begins at the trigger and continues untilthe use case ends.

• Extensions

– Show alternative action flows– May begin and end anywhere– Extensions may have extensions

Semester 1, 2013 30 SWEN30006: Software Modelling and Design

Use Case number: name Actors: actorList Stakeholders and Needs:

stakeholder—needsList. … stakeholder—needsList.

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 …

!"#$!%&#$!'$#()*+,-.!/$0+1&2$!

Extensions use a special numbering scheme:

• Numbers are for action step sequencing

18

Page 20: Software Modelling & Design Summary.pdf

• 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 bythe 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 one actor does the same and more of another actor.

Inclusion relationships between use cases is used when some use cases will always needanother use case included.

Extension relationships between use cases is used to show where one use case is option-ally extended by an additional use case.

Semester 1, 2013 37 SWEN30006: Software Modelling and Design

•  !"#$%&"#'#%()%*+'#%&",$%+$#%-#')(+$%+.%&"#%/)#%0,)#1%2(&"%3(4#'#$&%-#')(+$)%)+*#%,05+$)%($%0+**+$%,$3%)+*#%,05+$)%/$(6/#%&+%&"#%/)#%0,)#%/)#%7#$#',8(9,5+$:%

Generalization between use cases

19

Page 21: Software Modelling & Design Summary.pdf

Semester 1, 2013 38 SWEN30006: Software Modelling and Design

Click to edit Master title style !!"#$#%&'()&*+$!,#'&*+$-.(/-!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'&--#-@!

Semester 1, 2013 39 SWEN30006: Software Modelling and Design

•  !"#$%#$%&$'(%)"'*%$+,'%&$'%-.$'$%)#//%./).0$%*''(%.*+1"'2%&$'%-.$'%#*-/&('(3%–  452+-'$$%5.0,'*16%)#//%$7//%8'%.%$1.*(./+*'%&$'%-.$'%1+%8'%&$'(%9+2%

4:.*&.//0%.((%-.2%$".2'263%

!"#$%&'(");'/.7+*$"#<$%='1)''*%>$'%?.$'$%

Semester 1, 2013 40 SWEN30006: Software Modelling and Design

•  !"#$%#$%&$'(%)*%$"*+%,-$'$%+"'.'%*/'%&$'%,-$'%#$%*01*/-223%'4)'/('(%53%-/%-((#1*/-2%&$'%,-$'6%–  7/%)"'%'4-802'%)"'%9:.*,'$$%:-38'/);%&$'%,-$'%,*/)-#/$%-22%)"'%<&/,1*/-2#)3%

.'=&#.'(%<*.%-%,-$"%*.%,"'=&'%0-38'/)>%"*+'?'.%#$%"-$%)*%5'%'4)'/('(%<*.%,.'(#)%*.%('5#)%,-.(%0-38'/)6%

%!"#$%&'(%)@'2-1*/$"#0%A')+''/%B,)*.$%%

20

Page 22: Software Modelling & Design Summary.pdf

4 Domain Modelling with Classes

4.1 Types of Class Models

Domain (conceptual) class models represent the problem including important entities or con-cepts and their attributes and important relationships. Important in product design be-cause 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 classes2. Add attributes3. Add associations4. 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 implementationdetails

Design and implementation class models represent the solution to the problem.

4.2 Attribute Specification Format

name : type [multiplicity] = initial-valuee.g. roundScore : int = 0, words : String[*] = ""

4.3 Operation Specification Format

name(parameter-list) : return-type-liste.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

Page 23: Software Modelling & Design Summary.pdf

Semester 1, 2013 15 SWEN30006: Software Modelling and Design

!!"##$%&'($)#!'*+!,*+#+)-+.!/*'01&%'223!&)!456!

•  Labeled or unlabeled lines

•  Readable in two directions

•  Direction arrows

•  Role names

Semester 1, 2013 17 SWEN30006: Software Modelling and Design

!!"##$%#&'()!

Bicycle

WheelsBrakes Seat

Pedals Frame

1

2

1

1

1

2

2

1 1

1

4.5 Multiplicity

Number of instances of target class associated with single instance of source class.

4.6 Object diagrams

Models that show state of one or more objects at a moment during execution. Dynamic modelas opposed to class diagrams-static. Used in development of class diagrams. Comprised ofobject name and attributes.object-name : class-nameattribute-name = value

5 Interaction Models

Interaction Diagrams are notation used for modelling the communication behaviour of individ-uals 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.

Frame is a rectangle with pentagon in top-left corner called name compartment.sd interactionIdentifyer - either a simple name or an operation from a class diagram.

Semester 1, 2013 16 SWEN30006: Software Modelling and Design

!!"##$%&'($)!*+,(-,&%&./!

012!3+,(-,&%&./!'.!.12!.'452.!%,'##!2)6!$7!')!'##$%&'($)!&#!.12!)+3824!$7!&)#.')%2#!$7!.12!.'452.!%,'##!.1'.!%')!82!'##$%&'.26!9&.1!'!#&)5,2!&)#.')%2!$7!.12!#$+4%2!%,'##:!

22

Page 24: Software Modelling & Design Summary.pdf

Semester 1, 2013 24 SWEN30006: Software Modelling and Design

Click to edit Master title style !"#$%&'()!*+!,-.(/0)!12!345!

Lifeline Object, lifeline, activation, destroy.

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

Opt is equivalent to an if statement

Semester 1, 2013 22 SWEN30006: Software Modelling and Design

!"#$%&'(!)*'+,-&.!/0',#(-!

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

Page 25: Software Modelling & Design Summary.pdf

Semester 1, 2013 24 SWEN30006: Software Modelling and Design

!"#$%&'()*%!+&(,-%'$!./(-0#%!

Semester 1, 2013 26 SWEN30006: Software Modelling and Design

!"#$%&!'#%()$*+!,-%)./$!

Semester 1, 2013 29 SWEN30006: Software Modelling and Design

!!"##$!%&'()*+,!-.')$/*!

24

Page 26: Software Modelling & Design Summary.pdf

• 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 toother 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 co-design - 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

Page 27: Software Modelling & Design Summary.pdf

• May treat other components are data repositories - increases coupling and destroys in-formation 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 decisionson 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

Page 28: Software Modelling & Design Summary.pdf

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

6 Software Architectures

Architectural design is the activity of specifying the major parts; their responsibilities; propertiesand 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 necessaryschematic which they can use to integrate their component. It can be used to assess impactof changes and provides basis for evaluating extensions and maintenance - does the same fornew 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 perfor-mance 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 madefor 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. Ifwell 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 usuallyimplies 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 asoftware module are

27

Page 29: Software Modelling & Design Summary.pdf

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 thelayers below. Sub-systems in the layers have no knowledge of the subsystems in thelayer 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 ifeach layer depends only on the layer immediately below otherwise it is open

Semester 1, 2013 21 SWEN30006: Software Modelling and Design

HIERARCHICAL DECOMPOSITION!

A:Subsystem

B:Subsystem C:Subsystem D:Subsystem

E:Subsystem F:Subsystem G:Subsystem

Layer 2

Layer 3 (Bottom)

Layer 1 (Top)

ISO/OSI Model The decomposition into layers allows the developer to build up simple inter-faces between layers that hide the details of the layer below. Layering allows a cleanseparation of concerns - the developer can concentrate on the details of one layer whilenot needing to worry about the details of other layers. OSI is a closed architecture. Utilisedabstraction.

7 Architecture Styles

Software Architecture consists of:

• A system decomposition• Global and persistent data• Global control flow and interaction

28

Page 30: Software Modelling & Design Summary.pdf

• Boundary conditions• Inter-subsystems communications protocols

Architectural Style is a template or a form of design pattern that can use common structuresand interactions to specify high-level designs. Part of the knowledge base of good de-signers. 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 - usewhats already been done. They capture existing knowledge about trade-offs in systemarchitecture.

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 thedata

• Data is persistent and must maintain integrity despite the high number and frequency ofoperations on it

29

Page 31: Software Modelling & Design Summary.pdf

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 thedata), 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 itflows, functional transformations are carried out on the data. Extensively used in data process-ing 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 continu-ously transforms data from input to output

7.2.2 Solution

• Interaction style is through data-streams; data may be represented as ASCII text, XMLor internal data structures

• Control style between filters in linear; output of one filter is fed directly the input of nextfilter. 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 manage-ment

• 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 - inefficientdata interchange

30

Page 32: Software Modelling & Design Summary.pdf

• Redundant management in each server

• No central register of names or services - hard to find out what servers and services areavailable

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 andmoves downards - applicable to sequential systems - basically callbacks.

7.4.2 Manager Model

Applicable to concurrent systems. One system component controls stopping, starting and coor-dinations of other subsystems. Can be implemented in sequential systemswith 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 theevents.

• Effective in integrating subsystems of different computers and in a network• Sub-sytems register their interest in specific events and are notified when and eventoccurs

• 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 andpassed 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 principalcharacteristics of these systems - bottom up method

Reference Models are more abstract, idealised models. Provide information about a specificclass of systems and mean of comparing different specific architectures

31

Page 33: Software Modelling & Design Summary.pdf

8 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. Non-deterministic means that it could go to different states from the current state with a singleinput.

8.1 Transition String Format

event-signature [guard] / action-expressione.g. buttonPress [enabled] / closeWindow. Don't have to have a guard and an action. Musthave an event-sig though.

8.2 Symbol Compartments

Name, internal transitions and optionally nested diagram (composite).

Semester 1, 2013 17 SWEN30006: Software Modelling and Design

•  !"#!$%!$&'((!)%*#+'$*(,$-!•  .+*(!)%*#+'$*(,$!

•  /#0%,+12!*+3!4(!+5+)&(6!$%!+!$+4!$%!-+7(!-#+)(!•  8+$&,+*(!

•  9,$(',+1!$'+,-:0%,-!•  9,$(',+1!$'+,-:0%,!-#():;)+0%,-<!%,(!#('!1:,(!•  ='+,-:0%,!#'%)(--(6!>:$&%?$!)+?-:,@!+!-$+$(!)&+,@(!•  /#0%,+1!

•  .(-$(6!6:+@'+*!•  /#0%,+1!

!A$+$(!A3*4%1!B%*#+'$*(,$-!

Idle

entry/amount = 0do/display( greeting )

Internal Transitions

NameAction Labels

8.3 Internal Transitions

action-label / action-expressione.g. entry / count := 0, do / display flashing light

entry execute the associated action-expression upon entry

exit execute the associated action-expression upon exit

do execute the associated action-expression upon state entry and continue until exit or actioncompletion

include a finite state automaton (composite)

32

Page 34: Software Modelling & Design Summary.pdf

Semester 1, 2013 21 SWEN30006: Software Modelling and Design

Click to edit Master title style !"#$%$&"'(%)$"*+$(",-$&)-%."/)%-0+12-0"

8.4 Sequential Composite States

1. Entering a composite state also means entering its nested state. Its entry command isexecuted 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 stateas in step 1.

Semester 1, 2013 26 SWEN30006: Software Modelling and Design

Click to edit Master title style !"#$%&'($)!*$+$%,'-$!+.$!/&01-!"#$&201-!3%4$%!

5%'+$!416-!+.$!$#$&201-!1%4$%!71%!+.$!(+8+$!,14$9!

8.5 Stubs

Symbol used as a termination and origin point for transitions to and from states in a suppressednested state chart.

8.6 State Chart Heuristics

• Check every non-completion transition arrow is labeled

33

Page 35: Software Modelling & Design Summary.pdf

Semester 1, 2013 28 SWEN30006: Software Modelling and Design

Click to edit Master title style !"#$%%&'!"#(#&!)*(+,-&!

• 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 statecharts

• 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. Typicallyused to determine if the input is valid - accepted or recognised. Accepted iff:

1. The automaton reads each input value2. The automaton moves to the corresponding new state for the input symbol3. 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. Typicallyused 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

Page 36: Software Modelling & Design Summary.pdf

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 oc-currences (user input actions) that drive the program between user interface states.

Semester 1, 2013 40 SWEN30006: Software Modelling and Design

!"#$%&'!($)!*+$,)%-!

User Interface Diagram is a drawing of (part of) a product's visual display when it is in a par-ticular state. Dialog maps and user interface diagrams can be used together: every userinterface diagram should specify the visual form of a state in a dialog map, and everystate is a dialog map should have its visual form specified by a user interface diagram.

Semester 1, 2013 42 SWEN30006: Software Modelling and Design

!"#$%!&'($%)*+$!,-*.%*/!01*/23$!

9 Designing with Classes

9.1 OO Design Principles

9.1.1 Open-Closed Principle (OCP)

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

35

Page 37: Software Modelling & Design Summary.pdf

9.1.2 Liskov Substitution Principle

Functions that use references to super-classes must be able to use objects of derived sub-classes 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 thatimplements 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 thesystem 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 classchange

• 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 betweenclasses

• 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 super-class

• 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 ordevice

36

Page 38: Software Modelling & Design Summary.pdf

9.1.6 Composition

Method of reuse in which new functionality is obtained by creating an object composed of otherobjects - new functionality obtained by delegating functionality to one of the objects used inthe composition. e.g. window class having a rectangle attribute to delegate all the rectanglerelated operations to. Window shouldn't merely inherit rectangle because not every windowmust be a rectangle.

Delegation occurs when two objects are involved in handling a request: a receiving object anda delegate.

10 Software Architecture and Design Patterns

Design pattern addresses a recurring design problem that arises in specific design situationsand 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 productiveand 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 reusabil-ity

• 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 struc-tures

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 classto 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

Page 39: Software Modelling & Design Summary.pdf

Semester 1, 2013 26 SWEN30006: Software Modelling and Design

The Factory Method Pattern!

•  !"#$"#%•  !"#$"%&$%'$(")*&+"%*,)%+)"&-$.%&$%,/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%

Application

createDocument()openDocument()

Document

open()close()Save()

MyDocument MyApplication

return MyDocumentcreateDocument()

Document doc=createDocument()docs.add(doc)doc.open()

Application

createDocument()openDocument()

Document

open()close()Save()

MyDocument MyApplication

return MyDocumentcreateDocument()

Document doc=createDocument()docs.add(doc)doc.open()

•  ?7"%!"#$%#&'!()#*%@A%="(7,5%'4%&%*&+(,):%="(7,58%

Semester 1, 2013 27 SWEN30006: Software Modelling and Design

The Factory Method Pattern (cont’d)!

•  !""#$%&'$#$()*

•  !"#$%&#$'()%*+,$-#%&*.$/(0#+1$21$(1,$*3$%&#$3*44*5216$"2%7(8*1"9$•  :$)4(""$)(1;%$(18)2/(%#$%&#$)4(""$*3$*<=#)%"$2%$>7"%$)+#(%#?$

•  :$)4(""$5(1%"$2%"$"7<)4(""#"$%*$"/#)23,$%&#$*<=#)%"$2%$)+#(%#"?$

•  +(,-%(-,.*

Creator

factoryMethod()anOperation()

Product

ConcreteProduct ConcreteCreator

return new concreteProduct()factoryMethod()

….product = factoryMethod()….

Creator

factoryMethod()anOperation()

Product

ConcreteProduct ConcreteCreator

return new concreteProduct()factoryMethod()

….product = factoryMethod()….

– 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 createsConcreteProduct Implements the Product interfaceCreator declares the factory method, which returns an object of type ProductConcreteCreator Overrides the factory method to return an instance of a ConcreteProd-

uct

• Collaborations - Creator relies on its subclasses to implement the factory method so thatit returns an instance of the appropriate ConcreteProduct

• Benefits

– Code ismademore flexible and reusable by the elimination of instantiation of application-specific classes

– Code deals only with the interface of the Product class and can work with any Con-creteProduct class that supports this interface

• Liabilities - Clients might have to subclass the Creator class just to instantiate a particularConcreteProduct

• Implementation Issues

– Creator can be abstract or concrete– If the factory method is to have the ability to create multiple kinds of products thenthe factory method has a parameter (and possible and if-else/case) to decide whatobject to create. We could override this factory method in a subclass to try to avoidOCD problems.

38

Page 40: Software Modelling & Design Summary.pdf

10.1.2 Observer Pattern

• Intent - define a one-to-many dependency between object so that when one object changesstate, 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 makingclasses tightly coupled

• Applicability - use when:

– When an abstraction has two aspects, one dependent on the other. Encapsulatingthese 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 assumptionsabout those objects (or minimal assumptions e.g. object.update())

Semester 1, 2013 40 SWEN30006: Software Modelling and Design

!"#$%&'#()#($*+,#(-$./0-1234$

Attach(Observer)Detach(Observer)Notify()

Doument

DoumentState

GetDocument()SetDocument()

ReviewerReviewerState

UpdateDocument()

1 0..*

10..*

o-> Update()For all o in Observers

stateReturn subject

ObserverState= Subject->GetState()

Subject

Observer

Update()

• 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 thesubject'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

Page 41: Software Modelling & Design Summary.pdf

* All subject knows is its list of observers* Subject does not need to know the concrete class of an observer, just that eachobserver 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 eachother 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 tellthe 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 changedstate* Use an intermediary object which acts as a mediator* Subjects send notifications to the mediator object which performs any necessaryprocessing 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 clientsinteracting with a single model.

Model contains the data and the methods that govern the access to and updates of the data. Inenterprise 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

Page 42: Software Modelling & Design Summary.pdf

Semester 1, 2013 49 SWEN30006: Software Modelling and Design

!"#$%&'($)&*"+,-"%%$-.

ViewRenders the modelRequests updates from modelsPasses user actions to the model

ControllerApplication behaviourMaps user actions to model updatesSelects a view for a responseNotifies views of changes

ModelApplication StateHandles Queries about StateNotifies each view of changes in state.

StateRequests

Select View

ModelUpdates

UserActions

Change Notifications

MethodCalls

Events

Controller translated the user's interactions with the view into actions that the model will per-form.

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 accessingthe 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 computa-tions.

– 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

Semester 1, 2013 52 SWEN30006: Software Modelling and Design

!"#$!%&'()*+!,-.(/*01!

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

Page 43: Software Modelling & Design Summary.pdf

• Views and controllers are often hard to separate

• Frequent updates may slow data display and degrade user interface performance

• TheMVC stylemakes user interface components highly dependent onmodel 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 aresent 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 themost 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 archi-tecture - helps product feasibility

• Without a high level architecture it is difficult to convince stakeholders their needs can bemet - 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; alsoknown as:Quality Attribute is a characteristic or property of a software product independent of its func-

tion 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 portedReusability 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 limitsAvailability is how ready the product is for useSecurity 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 willdiffer in their ability to satisfy the non-functional requirements. Some architectures may favourcertain non-functional requirements over others and there becomes trade-offs:

• For example - availability could be increased through the use of server farms, but thismakes the architecture more complicated - could result in less reliability.

• For example - encryption/decryption will improve security but it will impact performance(speed, throughput).

42