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
. . . . . . . . . . . . . . . . .
10 10 10 10 11 11 11 11 12 13 13 13 14 14 14 15 15 17
. . . . . .
20 20 20 20 20 21 21
. . . . . .
21 21 22 22 22 24 24
. . . . . . .
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 . . . . . . . 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 . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
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
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
6 Software Architectures 6.1 Role of Software Architecture . . . . . . 6.2 Characteristics of Software Arc Archite itecture 6.3 Guidelines for a Good Design . . . . . . 6.3.1 Heuristics for Good Design . . . 6.4 Decomposition . . . . . . . . . . . . . . 6.4.1 Hierarchical Decomposition . . . 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 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 . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
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 Princ inciple (DIP) 9.1.4 Single Choice Principle . . . . . . . . 9.1.5 Favor Compositi ition Over Inherita itance . 9.1.6 Composition . . . . . . . . . . . . . .
2
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
. . . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . . . .
. . . . .
24 24 25 25 26
. . . . . .
26 26 26 26 27 27 27
. . . . . . . . . . . .
27 28 28 29 29 29 29 29 30 30 30 30 30
. . . . . . . .
31 31 31 31 32 32 32 33 34
. . . . . . .
34 34 34 35 35 35 35 36
10 Software Architecture and Design Patterns 10.1 Gang of Four design patterns . . . . . . . . . 10.1.1 Fa Factory Method Pattern . . . . . . . . 10.1.2 Ob Observer Pattern . . . . . . . . . . . . 10.1.3 Mod Model View iew Controller ler (MVC) Pattern
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
36 36 36 38 39
11 Architectural Design Specification 41 11.1 No Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3
1
The The Desi Design gn Prob Proble lem m
The design The design problem is problem is to develop a description of the system that can be implemented by develope velopers rs and, if implement implemented, ed, will meet meet all of the require requiremen ments. ts. Design Designs s can be seen seen as a reasoning from a set of requirements and constraints to a new piece of reality; bringing something new into being. Requirements Requirements (what) (what) and design (how) come from different different conceptual conceptual worlds worlds and can have different different competing objectives. objectives. The design problem is solved solved by: Design Methods A set of activities that systematically guides the development of a solution to a design problem. Modelling represents represents the objects, system system and software software in a way that aids understandin understanding g 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 Water Waterfal falll Model Model
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
Concept aims to identify the initial initial idea of the system. Requirements aims to identify identify the needs, features, features, function function and capabilities capabilities of the system. system. Design aims to address how the hardware hardware and software software are to be implemented. implemented. Implementation aims to address the programming programming of the system in code. Testing aims the find and eliminated any faults (bugs) (bugs) in the software. software. Maintenance aims aims to inco incorp rpor orat ate e upda update tes s and and new new feat featur ures es into into a syst system em as the the need needs s chan change ge..
1.2
Software Software Architectu Architecture re
Component Design aims to identify identify the key sub-systems sub-systems and establish establish a framework framework for both control control flow and communication communication between sub-systems sub-systems.. Key activities activities in component component design are: • System System Structuring Structuring 4
• Control Control Modelling Modelling • Modular Modular Decompositio Decomposition n 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 Persistent data that that is saved long term. term. • Data that flows between between components; components; attribute attribute data in classes. classes.
1.3 Design Design Metho Methods ds Structured Methods Notations, guidelines and often sets of activities that can be used to move from requirements to design. • Data Data flow flow • Jackson's Jackson's techniq technique ue • Entity-rela Entity-relationsh tionship ip modelling • Structural Structural and functional functional block modelling modelling • OO analysis analysis and and design design 1. Start with with use cases and domain domain model 2. Add more detail detail to class models models to evolve evolve design design into someth something ing that can be implemented 3. Repeat Repeat 2 until a model is reached reached in which the classes, classes, interfaces interfaces and control strategies are straightforward to implement.
2 2.1
Method Methods s for for Solvi Solving ng the the Desi Design gn Prob Problem lem Funtion Funtion Oriented Oriented Methods Methods
Begin with the functional the functional requirements specifi requirements specified ed in the requirements requirements specification. specification. During the design process: • High-level High-level functions functions are successiv successively ely decomposed decomposed into more detailed more detailed functions • When the functions functions are simple enough - such that they could be implemented implemented - they are mapped mapped to a module structure structure.. Essentially Essentially taking taking the problem, problem, breaking it down and rebuilding rebuilding it into a known structure structure.. n.b. most function oriented design solutions assume a common system state or data store which the functions operate.
5
System State
F1
F3
F2
F4
2.1.1 2.1.1
F5
Data Data Flow Flow Diagra Diagram m
1. Start Start with with the context the context diagram 2. The The System transform System transform must be decomposed to include the details of exactly how inputs 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 implementatio implementation, n, choose one of the transforms transforms and expand it as in step 2. Go back to step 3. n.b. n.b. Not dealing dealing with program program logic, logic, flow charts charts or any notion notions s of sequenci sequencing ng in data data flow diagrams - just breaking transitions into smaller transitions that are easily implementable.
:
Figure 1: Data flow diagram notation.
Project Coordinators
Project Coordinators Commands
Students
Project Details
Reports
SEPD System
Queries
Students
Project Details
Administrators
:
Project Details
Project Clients
Figure 2: Context diagram in SEPD.
6
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 2.1.2
Produc Productt Engine Engineeri ering ng
In the context diagram data must flow from the environment into the system transform and out of the system transform transform back into the environment environment.. External External data must be transformed 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 system and transform transform it to internal form. Transform Transform Centre At the the heat heat of the the syst system em wher where e inco incomi ming ng data data flow flows s pass pass thro throug ugh h the the tran transsform centre and start to move on paths back to the environment. Output Flows are data flows that lead back to the environment. environment.
Figure Figure 3: Determining Determining the flow boundaries boundaries and transform transform centre.
2.1.3 2.1.3
Design Design Steps Steps
1. Review Review context context diagram 2. Review Review and refine data flow diagrams diagrams:: consid consider er coupling coupling and cohesion and cohesion of transforms. Want high cohesion among transforms and low coupling between transforms. 3. Determine Determine where the DFD has transform transform flow and transaction transaction flow. flow. 4. Isolate Isolate the transform centre centre by specifying specifying input flows and output flows. 5. Perfor Perform m `First `First Level Factorin Factoring': g': create create a progra program m struct structure ure based on the input flows, flows, transform centre and centre and output output flows. flows. and a top level control control module to coordinate 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 Add the the lowe lowerr leve levell modu modules les to the the cont contro roll hier hierar arch chy y alre alread ady y crea create ted. d.
7
• Start at the transform centre centre and work outwards outwards along input flows and then forward forward along output flows. • Each Each transfor transform m is added as a sub-mo sub-modul dule e of the one it is connecte connected d to by a data data flow. • Modules Modules can be combined combined according according to the good design design (high cohesion, cohesion, low coupling).
Figure Figure 4: First and Second level factoring. factoring.
2.2
Data Structur Structure e Oriente Oriented d Design Design Methods 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. structures. Thus, a correct model of the data can be transforme transformed d into a system that incorporates incorporates a correct correct view of the world. world. 2.2.1 2.2.1
Design Design Strate Strategy gy
1. Form a system network network using Jackson's Jackson's notation notation that models the problem domain 2. Define and verify verify the data-flow data structures structures (input (input and output) output) 3. Derive Derive and verify the program program structures structures 4. Derive Derive and verify verify the elementary operations operations 5. Write Write the structure structure text and program text These steps can be separately and independently encouraging a separation a separation of concerns. concerns.
2.3
Componen Componentt Orien Oriented ted Design Design Methods Methods
A software A software component is is an independent unit with well defined interfaces and dependencies. It is also a package, web service, web resource or module that encapsulate encapsulates s a set of function function or data or both. They can be composed composed or deployed deployed independently independently.. Component Component design is about providing, developing and integrating components to form complete architectures. Key design issue is assuring levels of trust in component component based design.
8
Hierarchy Sequence
A
B
C
Sequence
Legend Act io ion/ Pr Process
Selection
It er eration
*
Procedure
Figure 5: Jackson's Structure Diagrams.
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
Figure 6: Step 1: form the network diagram e.g. SEPD.
Project Details
Company Contact
Name
Email
Environment
Features
Mobile
*
Tool-Chain
Project Status
IP
Contract
IP Position
Prog. * Languages Operating System Spec. Hardware Spec.
Figure 7: Step 2: define the data structures e.g. an input to SEPD.
9
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.
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 Process
!"# %&'(#)) )*&+(*+&# (,- .# *&,-)/,*#0 *' 1+-(2'-) 3- 4 5"#&# *"# %&'(#)) 6!"#"$%&"'(")*$&'+7 3) *"# ,%-# %&'(#0+ 9/*#&-,2:#/; *"# %&'(#)) (,- .# #,)3/; *&,-)/,*#0 *' (/,))#) 5"#&# #,(" %&'(#)) 3) 3<%/#<#-*#0 .; , <#*"'08
Figure 9: Step 5: write the program text e.g. SEPD.
10
3
Software Software Design Design Process Process and Modelling Modelling
3.1
Systems Systems Analysis Analysis Processe Processes s
Activity is the action that a person or a group undertakes undertakes to achieve 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 processes are then further divided up into: • Analysis Analysis Activities Activities (Product (Product Design) • Design Design Activities Activities (Engineering (Engineering Design) 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
3.1.1 Analysis Analysis of the Waterfal Waterfalll Has built in milestones milestones for contracting contracting;; each stage produces artefacts artefacts such as documents, models or code. There can be tendency tendency to over-docum over-document ent and over-engineer over-engineer when using the strict strict waterfall. waterfall. Is a good model for previously previously built systems systems and for well-defined well-defined systems that have well-define goals. 3.1.2 3.1.2
The Intera Interacti ctive ve Model Model
Aims to develop a minimal but useable system and then improve by performing successive iterat iteration ions s over over it. Each Each new iteratio iteration n builds builds in new requirem requirement ents, s, improv improves es the design design and existing existing code. Can get constant feedback feedback from clients to improve. improve. Is a combination combination of product design design and produc productt engine engineeri ering. ng. Each Each iterati iteration on combin combines es produc productt design design in the analys analysis is activi activity ty,, and product engineering engineering in the design, implementation implementation and testing activities. activities. Product Product design activities in successive iterations are linked: • Each successive product product design activity extends and improves the results of the previous previous product design activity.
11
Analysis
Architecture
Test
Implementation
Design
• Each successive product product design activity extends and improves the results of the previous previous product engineering activity. The products engineering activities in successive iterations are similarly linked. 3.1.3 3.1.3
Rapid Rapid Protot Prototypi yping ng
Is a form of iterative development. development. Each iteration iteration focuses on the production production of a Prototype. Prototype. Prototype is an incomplete or preliminary version of the system from which the complete production system can be developed.
3.2
Executab Executable le versu versus s Non-Ex Non-Execut ecutable able Models Models
3.2.1 Non-Execut Non-Executable able Models Models Token passing semantics semantics (e.g. Activity Activity Diagrams) Diagrams) tell us which activity is being done but little about the actual actions being undertaken. undertaken. UML class diagrams diagrams are not executable executable - they just model the relationships relationships between the classes classes (entities) in a system. system. It is sometimes sometimes necessary 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 technology or different things. Is iterative in nature nature and the production production of prototypes prototypes can expose expose vague or uncertain uncertain requirements 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 Prototypes realises part or all of the product's product's user interface. interface. Horizontal Prototype realises • One program program layer • Mock-ups Mock-ups Vertical Prototype does processing processing apart from that required to present present a user interface interface • Cuts across across program program layers layers
12
• Proof of concept concept prototy prototype pe Throwaway Prototype is developed developed as a design aid and then discarded discarded • Exploratory Exploratory prototy prototype pe • Quick Quick to build build • Risky to to use in final product product Evolutionary Prototype becomes (part of) the final product • Iterative Iterative developmen developmentt • More expensi expensive ve to build build • Difficult Difficult to build to handle handle change Low-Fidelity Prototype does not resemble resemble the final product product well • Paper or rough electronic electronic prototyp prototypes es • "Executed" "Executed" by walking through through interactions interactions • Very Very quick quick and easy High-fidelity Prototypes resembles the final product well • Usually Usually electronic electronic • Take longer to build (good (good tools help) 3.2.3 3.2.3
Uses Uses of Protot Prototypi yping ng
Needs elicitation • Discussion, jogs memory memory,, inspires ideas • Usually Usually throwaway throwaway horizontal horizontal paper prototypes prototypes Needs analysis • Captures Captures developers developers understandi understanding ng of needs • Usually Usually throwaway throwaway horizontal horizontal paper prototypes prototypes at various levels of fidelity Requirements generation and refinement • Design Design alternative alternatives s • Explore Explore new ideas • Often throwaway throwaway horizontal horizontal paper prototypes prototypes Requirements evaluation and selection • Usability Usability studies studies • Requirement Requirements s feasibility feasibility • Usually Usually higher fidelity; sometimes sometimes vertical vertical prototypes prototypes Design finalisation • Better for for review review than a SRS • Advisable to make high-fidelity high-fidelity evolutionary horizontal prototypes prototypes 13
3.2.4 3.2.4
Protot Prototypi yping ng Risks Risks
Using a throwaway prototype as the bases for development: • Avoid Avoid making high-fidelity high-fidelity throwaway throwaway prototypes prototypes • Make it very clear to stakeholde stakeholders rs that a prototype prototype only appears to work Fixation on appearance rather than function: • Do not use prototypes for functional functional needs elicitation elicitation • Use low-fidelity low-fidelity prototypes prototypes for needs elicitation elicitation Prototype is "better" than final product: • Use low-fidelit low-fidelity y prototypes prototypes • Ensure that high-fidelity prototypes prototypes are accurate accurate representations
3.3 Activi Activity ty Diagr Diagrams ams Model processes by showing the activities that are performed in a process and show the flow of control and data between the activities. activities.
merge node
guards
decision node
fork node
join node
:
3.3.1 3.3.1
Activi Activity ty Partit Partition ions s
Activities can be grouped into activity partitions (swimlanes) to denote the person/subsystem/object that implements implements and is responsible responsible for it. 14
Do Laundry
Sort Clothes
Wash Whites
Wash Darks
Dry Clothes Fold Clothes
Machine A
Machine B Person X
:
3.3.2 3.3.2
Contro Controll and and Data Data Flows 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.
control flow pin data flows
control flow
:
3.3.3 3.3.3
Activi Activity ty Parame Parameter ters s
Object Object nodes placed on activity symbols symbols to indicate indicate data or object object inputs or outputs. outputs. Contain Contain the data or object name. Types are specified specified in activity activity symbol beneath the activity name. 3.3.4 Activity Activity Diagram Diagram Conventio Conventions ns • Flow control control and object object down the page and left to right • Name activities activities and actions actions with verb and phrases phrases • Name object object nodes nodes with nouns nouns • Don't use both control control and data flows when a data flow alone is enough 15
• Make sure all nodes entering entering an action node can provide provide tokens concurrently concurrently • Use the [else] [else] guard at every every branch
FindMax a : int[1..*] max : int a
max = a[0] i=1
[else] [i < a.length] [else] [max < a.[i]] max = a[i]
max
i++
:
3.4 3.4
Use Use Case Case Mode Models ls
Model the interactions interactions that an external external entity has with the system. system. Consists Consists of: 3.4.1 3.4.1
Use Case Case Diagra Diagrams ms
Are static models that capture the users' interaction with the system. Consist of use cases and the actors involved in each use case. Actor is a type of agent, or external entity, entity, that interacts with a product. Actors 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. A scenario 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 gene genera rate te use use case case by iden identi tify fyin ing g acto actors rs and and the the sequ sequen ence ce of acti action ons s that that must must be take taken n during during an interaction interaction to achieve the goals of an activity. activity.
16
System Select a Wash Customer
Stall Sensor Buy a Wash
Activate/ Deactivate Soap Sensor Wash the Car
Produce a Log Manager
:
f
Beneficiary of a use case is an actor that receives receives some benefit 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 description of a use case case or an actor. actor. e.g. Customer: Customer: A person who comes to the car wash to get a car washed. e.g. Buy Wash: Accepting a reques requestt for a car wash, wash, checki checking ng if the car wash if ready ready for the next next wash.. wash.... Briefs Briefs supplement the use case diagram and help document the use case. Every use case diagram must have: • At least least one use case case • At least least one actor actor • At least one actor associate associated d with each use case • At least one use case associated associated with each each actor • No association association line between between actors actors • No association association line between between use cases cases • Name every every actor actor and use case case • No label on any any association association line line Some use case diagram heuristics: • Name actors actors with with nouns • Name use use cases with with verbs • Achieve Achieve a stakeholder' stakeholder's s goal in a use case • Make use cases cases of uniform size and complexity complexity • Fit the top level use use case diagram diagram for the system system on a single page
17
3.4.2 3.4.2
Use Case Case Descri Descripti ptions ons
Is a specificat specification ion of the interaction interaction between the actors and the system system in a use case. It shows: • the actions actions and responses responses of each party in the interaction interaction and the use case • the order order in which each each party acts acts • all possible courses courses of interaction interaction between parties and the system - results in complex activity flows Is a dynamic dynamic model of the system. system. Use case descriptions descriptions consist consist of: • Use case case name and and number number • Actors Actors • Stakeholder Stakeholders s and their needs 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 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. begin. May be the first step in the use case. • Basic flow 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
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 # stepDescription …
Extensions: extensionIdentifier condition: extensionIdentifier # stepDescription … …
Extensions use a special numbering scheme: • Numbers Numbers are for action step sequencin sequencing g 18
• Letter Letter are for extension extension triggers triggers • Extension Extension identifiers identifiers have interleaved interleaved numbers and letters • An asterisk asterisk refers refers to all action steps • A dash is used for ranges ranges of action steps steps • A comma separates separates action action steps steps in a list Use case description heuristics: • Fill in the use case template template from from top to bottom • Obtain Obtain use case and actor names from use case case diagram • Make human actors actors stakeholders stakeholders whose needs include completion completion of the task done by the use case • Write Write simple declarative declarative sentences sentences in the active active voice • Make actors actors or the product the subject subject of each step description description • Write Write a basic flow with three three to nine steps • Avoid Avoid sequences sequences of steps by actors or the product product • Don't specify specify physical physical details details • Impose Impose minimal order order on activities 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. Generalisation between actors When one actor does the same and more of another actor. actor. Inclusion relationships between use cases is used when some use cases will always need another use case included. Extension relationships between use cases is used to show where one use case is optionally extended by an additional use case.
19
20
4
Domain Domain Modell Modelling ing with with Classe Classes s
4.1 Types ypes of of Clas Class s Mod Models els Domain (conceptual) class models repr represe esent nt the proble problem m includ including ing import important ant entitie entities s or conconcepts and their attributes attributes and important important relationships relationships.. Important Important in product product design because they help to: • Understand Understand the problem problem domain domain • Setup data data requirements requirements • Validate requireme requirements nts Important in engineering design because they help to: • Understand Understand a product product design • Provide Provide a basis for engineering engineering design modelling modelling Conceptual modelling process: 1. Identify Identify classes classes 2. Add attribu attributes tes 3. Add associati associations ons 4. Add multiplicit multiplicities ies 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 Attribute Specificat Specification ion Format Format
name : type [multiplicity] = initial-value e.g. roundScore : int = 0, words : String[*] = ""
4.3
Operation Operation Specifica Specification tion Format Format
name(parameter-list) : return-type-list e.g. getScore() : int, setName(in : String)
4.4 Assoc Associat iation ions s Generalisation (inheritance) is useful when a class is the name as another class, and more part-whole relationship relationships. s. Composition Composition is a weaker weaker form. Aggregation used to show part-whole Association are associations between classes that is not either of previous two.
21
1
Pedals 2
2
Frame 1
1
Brakes
1
Bicycle
:
1
1
2
1
Seat
Wheels
4.5 4.5
Multi Multipl plic icit ity y
Number of instances of target class associated with single instance of source class. :
4.6 Object Object diagra diagrams ms Models that show state of one or more objects at a moment during during execution. execution. Dynamic Dynamic model as opposed to class diagrams-s diagrams-static. tatic. Used in development development of class diagrams. diagrams. Comprised Comprised of object name and attributes. object-name : class-name attribute-name = value
5
Intera Interacti ction on Models Models
Interaction Diagrams are notati notation on used used for modelli modelling ng the commun communica ication tion behavi behaviour our of indivi individduals exchanging information to accomplish some task. Focus is on sequence diagrams.
5.1 Seque Sequence nce Diagra Diagrams ms Most widely used because they model the message flow between individuals which is the essential sential aspect of collaboration. collaboration. Show message message flow in the order it happens in time - sequence. Frame is a rectangle rectangle with pentagon pentagon in top-left top-left corner called called name compartment . sd interactionIdentifyer sd interactionIdentifyer - either a simple name or an operation from a class diagram.
:
22
:
Lifeline Object, lifeline, activation, destroy. Synchronous arrow has filled in head and suspends execution 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 Message Specificatio Specification n Format Format variable = name(argumentList) e.g. hello(), msg = getMessage(helloMessage), x = sin(a/2)
5.1.2 Interactio Interaction n Fragments Fragments Opt is equivalent equivalent to an if statement statement
Alt is the equivalent to a switch or if-elseif-else if-elseif-else Break is the same as in Java Loop 5.1.3 Sequence Sequence Diagram Diagram Heuristics Heuristics • Put the sender sender of first message message leftmost leftmost • Put individuals individuals that interact interact heavily heavily next to each other
23
:
24
• Position Position individuals individuals to make arrows short short and go from left to right • Put the self lifeline leftmost and draw the execution execution occurrence form the top to the bottom • Name individuals individuals only if they are message arguments arguments or are used in expressions expressions • Choose Choose a level of abstraction abstraction for the diagram diagram • Suppress Suppress messages messages individuals send to themselves themselves unless they generate generate messages messages to other individuals • Suppress Suppress return arrows arrows when using execution execution occurrences occurrences • Don't assign assign values to message message parameters parameters by name 5.1.4 5.1.4
Uses Uses for for Seque Sequence nce Diagra Diagrams ms
• Interactions between product and environment environment - system sequence diagrams • interaction between systems systems components in architecture architecture design • Interactio Interactions ns in mid-level design design • Can be used as (partial) (partial) use case descriptions descriptions 5.1.5 Interactio Interaction n Design Design Process Process Components Components and interactions interactions must be designed designed together together - component and interaction codesign design - because: • Components Components may not support needed needed interactions interactions • Interactio Interactions ns may rely on missing missing or unbuilt features of components components This all comes down to interfaces. interfaces. Outside-in design is designing from top-down, from most abstract to least abstract. • Use cases and requirement requirement specificat specifications ions • Design for interactions interactions with environment environment (outside) (outside) first and then internal internal (in).
5.2 Contro Controll Styles Styles 5.2.1 5.2.1
Centra Centralis lised ed
A few controllers make all significant decisions. Advantages: • Easy to locate locate decision decision making • Easy to see how decisions decisions are made and alter the decision decision making process process Disadvantages: • Controller Controller may become bloated bloated - large, complex complex and hard to understand understand,, maintain, text.
25
• May treat other components components are data repositories repositories - increases coupling coupling and destroys destroys information hiding Heuristics: • Avoid Avoid interaction interaction designs where most messages originate originate from a single single component • Keep compone components nts small small • Make sure operational operational responsib responsibilities ilities are not all assigned to just a few components components • Make sure operations operations responsibilities responsibilities are consistent consistent with data responsibilite responsibilites s 5.2.2 5.2.2
Delega Delegated ted
Decision Decision making is distributed distributed among a few controller controller making the main decisions. decisions. Advantages: • Controllers Controllers coupled coupled to fewer components, components, reducing reducing coupling • Information Information hidden hidden better better • Progtram Progtram easier easier to divide into layers layers • Preferred Preferred control control style style Heuristics: • Have components components delegate delegate as many low-level tasks tasks as possible 5.2. 5.2.3 3
Disp Disper erse sed d
Decision making spread widely through program with few or no components making decisions on their own. Disadvantages: • Hard to see and understa understand nd flow of control control • Components Components cannot cannot do much on their own - increases increases coupling coupling • Hard to hide hide information information • Poor cohesion cohesion • Few modularity modularity principles principles satisfied satisfied Heuristics: • Avoid Avoid interactions interactions that require each component component to send many message.
26
5.3
Principle Principle of Least Least Knowledg Knowledge e
Also known as the Law the Law of Demeter . • Units have have limited knowledge knowledge of other other units • Units only only talk to friends and and not strangers strangers Basically, object should assume as little as possible about other objects. Advantages: • Hides information information • Keeps low coupling coupling • Keeps high cohesio cohesion n • Discourages an over-centralised control control style • Encourages Encourages a delegated delegated control control style
6
Softwa Software re Archit Architect ecture ures s
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 Software Architect Architecture ure
The architecture acts as a "blue-print" for the development team and provides the necessary schematic schematic which they can use to integrate integrate their component. 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
Characte Characteristi ristics cs of of Softwar Software e Archite Architectur cture e
Reliability and redundancy do we requir require e redund redundant ant syste systems ms to meet meet reliabi reliability lity requir requireme ements nts Performance what is the model of mean response or throughput times; what are the performance bottlenecks and resource usage safety monitoring or fail-safe fail-safe modes Safety do we need to build in safety Modifiability and maintainability what is the life of the system. What provisions will be made for future extensions and modifications.
6.3 Guidel Guideline ines s for for a Goo Good d Desig Design n Functional Independence is a measur measure e of how well separa separated ted modules modules of a system 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 degree to which a module module relies relies on other other modules modules.. Low coupled coupled usually usually implies implies a small interface interface through which a module interacts 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 Heuristics for Good Design Design • Reuse Reuse existing components components where possible possible • Structure Structure design to reflect problem structure structure where possible possible • Designs Designs should appear appear to have been written by one person in one sitting • Designs Designs should be built to accommodate accommodate change change • Designs Designs should be robust robust in the face of bad data or other conditions conditions • Design Design should not descend descend to the level of code code • The quality of the design should be assess throughout throughout the design process process
6.4 Decom Decompos positio ition n 6.4.1 Hierarchical Hierarchical Decomposit Decomposition ion A sequence of layers. Layers are ordered ordered so that each subsystem subsystem in a later depends depends only on the sub-system sub-system in the layers layers below. below. Sub-syste Sub-systems ms in the layers have no knowledge knowledge of the subsystems 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 . Architectu Architecture re is closed is closed if each layer depends only on the layer immediately below otherwise it is open
Layer 1 ( Top)
A:Subsystem
B:Subsystem
E:Su E:Subs bsys yste tem m
C:Subsystem
D:Subsystem
Layer 2
G:Subsystem
Layer 3 ( Bottom)
F:Su F:Subs bsys yste tem m
ISO/OSI Model The decomposition into layers allows the developer to build up simple interfaces between between layers that hide the details of the layer below. below. Layering Layering allows a clean separation of concerns - the developer can concentrate on the details of one layer while not not need needin ing g to worr worry y abou aboutt the the deta details ils of othe otherr laye layers rs.. OSI OSI is a clos closed ed arch archite itect ctur ure. e. Utili Utilise sed d abstraction. :
7
Archit Architect ecture ure Styles Styles
Software Architecture consists of: • A system system decompositio decomposition n • Global and and persistent persistent data • Global control control flow and interact interaction ion 28
• Boundary Boundary conditions conditions • Inter-subsystems communications protocols protocols Architectural Style is a template template or a form of design design pattern that can use common structures structures and interactions interactions to specify high-level high-level designs. designs. Part of the knowledge knowledge base of good designers. Typical styles: • Pipes and Filters Filters • Repositorie Repositories s • Object Objects s • Layere Layered d • Event-drive Event-driven n • Client-Serve Client-Server r • Process-c Process-contro ontroll • Interpreter Interpreters s 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 already been done. They capture capture existing knowledge knowledge about trade-off trade-offs s in system system architecture.
7.1 Repos Reposito itory ry Style Style Centralised Centralised data base for all shared shared data. Advantages: • Efficient Efficient way to share share large amounts amounts of data • Sub-system Sub-systems s don't care about how data is held/produc held/produced ed • Centralised Centralised management management e.g. backups, backups, security security Disadvantages: • Sub-system Sub-systems s must agree on repository repository data model - effectively effectively a compromise compromise • Data evolution evolution is difficult difficult and expensive expensive • No scope for specific specific management management policies policies • Data is difficult difficult to distribute distribute efficiently efficiently 7.1. 7.1.1 1
Probl Problem em
Typically used when: • There There is a structured structured body of data that is to be maintained maintained • There There are a number of different different and frequently frequently used operations operations to be performed performed on the data • Data is persistent persistent and must maintain integrity integrity despite the high number and frequency of operations operations on it 29
7.1. 7.1.2 2
Solu Soluti tion on
• Data is independent independent from computatio computation n • Interaction style is given by the computational elements interacting the central data store • Control Control style varies and depends on the application; application; can be state driven driven (depends on the data), synchronous or asynchronous
7.2 Pipes Pipes and Filter Filters s 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. 7.2.1 1
Probl Problem em
• Used when there there is a series series of operations to be performed performed on data • Requires Requires problem to be decomposed decomposed into a set of computation computational al elements that continuously transforms transforms data from input to output 7.2. 7.2.2 2
Solu Soluti tion on
• Interactio Interaction n style is through through data-streams; data-streams; data may be represente represented d as ASCII text, XML or internal data structures • Control Control style between filters filters in linear; output of one filter is fed directly the input of next filter. filter. Thread Thread of control control is inside the filters and thus is independent independent and may be complex
7.3 Client Client-Se -Serve rver r Model for implementing systems distributed across networks. Consists of: • Set of stand-alone servers servers that provide specific services e.g. printing, database management • Set of clients clients that call on the services services • Network Network for connecting connecting clients to servers servers Implicitly needs to be able to handle concurrent access to servers - threading. Advantages: • Distribution Distribution of data is straightforw straightforward ard • Make efficient efficient use of networked networked systems - cheaper hardware hardware • Easy to add new servers servers or upgrade existing existing servers servers Disadvantages: • No shared data model; sub-system sub-systems s will tend to organise data their own way - inefficient inefficient data interchange 30
• Redundant Redundant management management in each server server • No central central register of names or services services - hard to find out what servers servers and services services are available Client-Server with layers can decompose server into the following layered sub-systems: • Presentatio Presentation n Tier - the user interface, interface, display display results • Logic Tier - interpreting interpreting requests, requests, making decisions • Data Tier - managing data, data, accessing accessing data and maintaining maintaining data integrity integrity
7.4 Contro Controll Styles Styles 7.4.1 7.4.1
Call-R Call-Retu eturn rn Model 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 7.4.2
Manage Managerr Model Model
Applicable to concurrent systems. One system component controls stopping, starting and coordinatio dinations ns of other other subsys subsystem tems. s. Can be implem implement ented ed in sequen sequentia tiall system systems s with with case case statem statement ent.. e.g. embedded embedded system with uC and peripheral peripheral components. components. 7.4.3 7.4.3
Event Event Driven 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 Effective in integrating integrating subsystems subsystems of different different computers and in a network • Sub-sytems register their their interest in specific events events and are notified when and event occurs • Control Control is not part of event detection detection but of the components components who handle the events events Interrupt Model Utilised Utilised in real time systems. systems. Events Events are detected by interrupt handler handler and passed on to the appropriate components for processing. • Known interrupts interrupts types types - interrupt vector vector - with a handler handler defined in each • Allows for fast response response but complex to program and difficult difficult to validate 7.4.4 Reference Reference Architectu Architectures res Generic Models are are abst abstra ract ction ions s from from a numb number er of real real syst system ems s that that enca encaps psula ulate te the the princ princip ipal al 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
8
Stat State e Char Charts ts
Specified Specified by a: 1. Set of of states states 2. Set of of inputs inputs 3. Set of outputs outputs 4. Next state state function function Deterministic means that an input to every state has a clear transition transition to another state. Nondeterministic means that it could go to different states from the current state with a single input.
8.1
Transition ransition String String Format Format
event-signature [guard] / action-expression e.g. buttonPress buttonPress [enabled [enabled]] / closeWindow closeWindow.. Don't have have to have a guard and an action. action. Must have an event-sig though.
8.2 Symbo Symboll Compa Compartm rtmen ents ts Name, internal transitions and optionally nested diagram (composite).
Action Labels
Name
Idle
entry/amount = 0 do/display( greeting )
Internal Transitions
8.3
Internal Internal Transitions ransitions
action-label / action-expression e.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 action completion include a finite state automaton (composite)
32
8.4
Sequentia Sequentiall Composite Composite States States
1. Entering Entering a composite composite state also means entering entering its nested nested state. Its entry command command is executed executed as well as its nested state. state. This continues continues until there are no more nested nested state. They jointly become the current state. 2. A transitions transitions from the enclosed state causes causes the exit actions of that state to be exited, along with any other enclosing states. 3. The transition transition action action is then performed 4. The entry actions actions of entered entered state are executed executed from outermost outermost state to innermost innermost state as in step 1.
8.5 Stu Stubs Symbol used as a termination and origin point for transitions to and from states in a suppressed nested state chart.
8.6 State State Chart Chart Heuri Heuristi stics cs • Check Check every non-completion non-completion transition transition arrow is labeled 33
• Check Check that no arrow leaves leaves a final state • Check Check for black holes (get stuck) stuck) and white holes (can't (can't get to) • Label states states with adjective adjectives s • Name events events with verbs or nouns describin describing g actions • Name actions actions with with verbs • Combine Combine arrows with same same source and target target states • Use stubs and the include include internal transition transition to decompose decompose large and complicated complicated state charts • Make on initial state in every state chart (including (including nested state state charts) • Check Check that no event labels two or more transitions transitions from a state • Check Check that all guards on same event are exclusive exclusive • Use [else] guards guards to help ensure ensure that guards are exclusive exclusive and exhaustive exhaustive
8.7
Recognis Recognisers ers and Transduce ransducers rs
Recogniser is a finite automaton automaton that responds to events but generates generates no actions. actions. Typically ypically used to determine if the input is valid - accepted or recognised. recognised. Accepted Accepted iff: 1. The automaton automaton reads each each input value value 2. The automaton automaton moves to the correspond corresponding ing new state for the input symbol symbol 3. and finishes finishes in an accepting accepting state state when all the input is consumed consumed Typical examples include language translators, lexical analysers and interpreters Transducer is a finite finite automa automaton ton that that both both respon responds ds to events events and genera generates tes action actions. s. Typical ypically ly used to model things that transform inputs to outputs. outputs. • Useful Useful in product product design as well as engineering engineering design • Examples: devices, programs with complex state-based state-based behaviour. behaviour. 34
8.8 8.8
Dial Dialog og Map Map
Acceptors also used to model user interfaces. Dialog Map is a state diagram diagram whose nodes represent represent user interface interface states. Events Events are occurrences (user input actions) that drive the program between user interface states.
User Interface Diagram is a drawing drawing of (part of) a product's product's visual display display when it is in a particular ticular state. Dialog maps and user interface diagrams 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.
9
Design Designing ing with with Classe Classes s
9.1 OO Design Design Princ Principl iples es 9.1.1 Open-Close Open-Closed d Principle Principle (OCP) (OCP) Software Software modules should should be Open for extension, extension, yet Closed for modification. 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 Liskov Substitut Substitution ion Principle Principle Functions that use references to super-classes must be able to use objects of derived subclasses without knowing it. 9.1.3 Dependency Dependency Inversion Inversion Principle Principle (DIP) Program to and interface, not an implementation. Advantages: • Clients Clients are unaware of the specific specific class of the object they are using using • Loosens Loosens coupling coupling • Increases Increases likelihoo likelihood d of reuse • Improves Improves opportunities opportunities for composition composition since contained contained objects can be of any class that implements a specific interface since interfaces don't have attributes. Disadvantages: • Modest increase in design complexity. complexity. 9.1.4 9.1.4
Single Single Choice Choice Princi Principle ple
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 Compositio Composition n Over Inheritanc Inheritance e Advantages of Inheritance: • New implementatio implementation n is easy, easy, since most of it is done (inherited) (inherited) • Easy to modify or extend extend the implementation implementation being used Dangers of Inheritance: • Breaks Breaks encapsulation encapsulation since it exposes subclass subclass to implementati implementation on details of super class class - "white box" reuse • Subcla Subclasse sses s may need to be change changed d when when the implement implementati ation on detail details s of super super class class change • Implementatio Implementations ns inherited from super-class super-class can not be changed changed at runtime. runtime. Coad's Rules for when to use Inheritance; • A sub-class sub-class "is a special kind of" and not "is a role played played by a..." relationship relationship between between classes • An instance instance of a sub-class sub-class never never needs to become an object of another class class • A sub-class sub-class extends, rather than overrides overrides or nullifies, nullifies, the responsibi responsibilities lities of its supersuperclass • A sub-class sub-class does not extend the capabilitie capabilities s of what is merely a utility class • For a class in the actual problem problem domain, the sub-class sub-class specialises specialises a role, transaction transaction or device 36
9.1.6 9.1.6
Compos Compositi ition on
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. composition. e.g. window class class having a rectangle rectangle attribute attribute to delegate all the rectangle related related operations to. Window shouldn't shouldn't merely inherit rectangle rectangle because not every window must be a rectangle. Delegation occu occurs rs when when two two objec objects ts are are invo involv lved ed in hand handlin ling g a requ reques est: t: a rece receiv ivin ing g obje object ct and and a delegate.
10
Software Software Architect Architecture ure and Design Design Patterns Patterns
Design pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it. Features: • Why create create something new if there is something something out there that works works well? • Well-struc Well-structured tured OO systems have recurring recurring patterns patterns of classes classes and objects objects • Knowledge Knowledge of patterns that have worked worked allow the designer designer to be more productive productive and the resulting designs to be more flexible and reusable Advantages: • Capture Capture expertise and make it accessible accessible to non-experts non-experts in standard standard form • Facilitate Facilitate communication communication among developers developers by providing a common language • Make Make it easier easier to reuse reuse succes successfu sfull designs designs and avoid avoid alterna alternativ tives es that that diminis diminish h reusab reusabilility • Facilitate Facilitate design modificat modifications ions • Improve Improve design understandabi understandability lity • Improve Improve design documentatio documentation n
10.1
Gang of Four design design patterns 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 Factory Method Method Pattern Pattern • Intent Intent - define an interface interface for creating an object, but let subclasses subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. • Motivation Motivation The createDocument() The createDocument() method method is a factory method. • Applicability Applicability - used used when: when: – A class can't anticipate anticipate the class of object it must create 37
Document
Application
open() close() Save()
createDocument() openDocument()
MyD oc oc um ume nt nt
Document doc=createDocument() docs.add(doc) doc.open()
MyA pp ppl ic ic at at io ion createDocument()
return MyDocument
Creator
factoryMethod()
Product
anOperation()
ConcreteProduct
…. product = factoryMethod() ….
ConcreteCreator factoryMethod()
return new concreteProduct() concreteProduct()
– A class wants it subclasses to specify the objects it creates • Structure Structure • Participant Participants s Product defines defines the interface interface for the type of objects the factory method creates ConcreteProduct Implements the Product interface Creator declares declares the factory method, which returns returns an object object of type Product Product ConcreteCreator Overrides the factory method to return an instance of a ConcreteProduct • Collaboratio Collaborations ns - Creator Creator relies on its subclasse subclasses s to implement implement the factory method method so that it returns an instance of the appropriate ConcreteProduct • Benefi Benefits ts – Code Code is made made more more flex flexibl ible e and and reus reusab able le by the the elim elimin inat ation ion of inst instan anti tiat atio ion n of appl applic icat ation ion-specific classes – Code deals only with the interface interface of the Product Product class and can work with any ConcreteProduct class that supports this interface • Liabilities - Clients might have to subclass the Creator Creator class just to instantiate a particular ConcreteProduct • Implementatio Implementation n Issues 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 10.1.2 Observ Observer er Patter Pattern n • Inte Intent nt - defin define e a oneone-to to-m -man any y depe depend nden ency cy betw betwee een n obje object ct so that that when when one one objec objectt chan change ges s state, all its dependents are notified and updated automatically • Also Known As - Dependents Dependents,, Publish-Subscrib Publish-Subscribe, e, Model-View Model-View • Motivations Motivations - the need to maintain maintain consistency consistency between related objects objects without making classes tightly coupled • Applicability Applicability - use use when: – When an abstraction has two aspects, one dependent on the other. Encapsulating these aspects aspects in separate separate objects let you vary and reuse them independently independently – When a change to one object requires requires changing 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()) object.update()) Subject
0..* Attach(Observer) 1 Detach(Observer) Notify() For all o in Observers o-> Update()
Doument DoumentState
Observer
Update()
Reviewer ReviewerState 0..*
1 UpdateDocument()
GetDocument() SetDocument()
ObserverState = Subject->GetState() Subject->GetState()
Return subject state
• Participant Participants s – Subject * Keeps track track of its observers observers * Provides Provides an interface interface for attaching and detaching Observer Observer objects – Observer - defines an interfaces for update notification – ConcreteSubject (model) * The object object being observed observed * Stores state state of interest interest to ConcreteOb ConcreteObserv server er objects * Sends a notification notification to its observers observers when its state changes changes – ConcreteObserver * The observin observing g object object * Stores state state that should stay consistent consistent with the subject's] subject's] * Implements Implements the Observer Observer update interface interface to keep its state consistent consistent with the subject's • Benefi Benefits ts – Minimal coupling between the Subject and Observer * Can reuse subjects subjects without reusing reusing their observers observers and vice versa * Observers Observers can be added without modifying modifying the subject 39
* All subject subject knows is its list of observer observers s * Subject Subject does not need to know the concrete class class of an observer, observer, just that each observer implements the update interface * Subject Subject and observer can belong to different different abstraction abstraction layers – Support for event broadcasting * Subject Subject sends notification notification to all subscribe subscribed d observers observers * Observers Observers can be added/remov added/removed ed at any time • Liabilities Liabilities – Possible cascading of notifications - observers are not necessarily aware of each other and must be careful careful about triggering triggering updates – Simple update interface requires observers to deduce changed item • Implementatio Implementation n Issues Issues – How does the subject keep track on its observers? observers? (List) (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 subject whenever its state state changes * The observers observers after after they cause one or more state changes changes * Some third third party object( object(s) s) – Make sure the subject updates its state before sending out notifications notifications – How much info about the change should the subject send to the observers? observers? * Push Push Model Model - lots * Pull Model 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 intermediary object object which acts as a mediator * Subj Subjec ects ts send send noti notific ficat atio ions ns to the the medi mediat ator or obje object ct whic which h perf perfor orms ms any any nece necess ssar ary y processing before notifying the observers 10.1.3 Model View Controller Controller (MVC) Pattern Pattern Is an architectural pattern that is similar to the observer pattern where there are multiple clients interacting interacting with a single model. Model cont contai ains ns the the data data and and the the meth method ods s that that gove govern rn the the acce access ss to and and upda update tes s of the the data 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 translated the user's interaction interactions s with the view into actions that the model will perform. MVC Dynamic Behaviour: • The user only manipulate manipulates s the controller controller • The controller controller may alter (seletc) (seletc) the view or (update) (update) the model • If the different view is selected by the controller, controller, the view redisplays redisplays itself by accessing accessing the model to obtain the latest and/or the required data in order to display • When the model is altered by the controller controller,, it responds responds by doing the required computacomputations. – Once it is done, the model issues a notification notification that is has changed changed – Can be done by announcing an event, or by directly notifying notifying controllers controllers and views – In any case this is done internally internally and fits the bill for a layered layered architecture architecture
:
Advantages: • View and controllers controllers can be added, removed removed or changed changed without disturbing disturbing the model • Views Views can be added or changed during execution execution • User interface interface components components can be changed even at runtime Disadvantages: 41
• Views Views and controllers controllers are often hard to separate separate • Frequent Frequent updates may slow data display display and degrade degrade user interface performance performance • The MVC style style makes makes user user interfa interface ce compon component ents s highly highly depend dependent ent on model model compon component ents s Implementation issues: • MVC can be implemented implemented using using a push- or pull-model 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
Architec Architectura turall Design Design Specifica Specification tion
Architectural design usually begins during product design for many reasons: • Judging Judging the feasibility feasibility of product designs designs is not often possible without without knowing the architecture - helps product feasibility • Without Without a high level architectur architecture e it is difficult difficult to convince convince stakeholder stakeholders s their needs can be met - helps show people what you mean • Architectu Architectures res are required required to conduct conduct trade-off trade-off analysis analysis in quality quality attributes
11.1
Non-Func Non-Functiona tionall Requirem Requirements ents
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: • Developmen Developmentt attributes attributes Maintainability is how easily a product product can be corrected corrected,, improved or ported Reusability is the degree to which a product's product's parts can be reused in another product product • Operationa Operationall attributes attributes Performance is the ability to accomplish accomplish product function function within time or resource resource limits Availability is how ready the product is for use Security is the the abil ability ity to resi resist st bein being g harm harmed ed or caus causin ing g harm harm by host hostile ile acts acts or influ influen ence ces s 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: trade-offs: • For example example - availability availability could could be increased increased through through the use of server farms, farms, but this makes the architecture more complicated - could result in less reliability. • For example - encryption encryption/decr /decryptio yption n will improve security security but it will impact impact performanc performance e (speed, throughput).
42
