i. the software development process development...software development practises alex cummaudo...

Software Development Practises Alex Cummaudo SWE20001 28 May 2014

I. The Software Development Process▸ The activities involved in building a system with requirements subject to constraints▸ They help us understand context in which software is developed

- In software development, development and not building (i.e. manufacturing) is critical

▪ Design and disk costs far outweigh the building costs- Contexts: the approaches/models to develop software▪ Technical fundamentals: Prototyping, validation, design, analysis, coding,

deployment, maintenance, testing▪ Management fundamentals: Planning, tracking, resource allocation, risk assessment,

budget, scheduling, scope definition▹ Technical SDP fundamentals is what goes behind the final product▹ Management SDP fundamentals keeps us organised and keep us in budget▫ Myki had bad management fundamentals, but was a techie's heaven (lots $$$)

Modelling SDP ▸ Both technical and management fundamentals must work hand-in-hand

- The SDP Models helps us organise this- Without modelling, what do follow? What do we do when and why?

▸ Models are just guidelines to develop the system- Models allows us to manage complexity of developing an entire system- Capture the primary activities required- Functional decomposition of the entire system development

▸ Models must be justified - Some models are more suitable for some systems

▪ A model that requires a very accurate system (e.g. Banking System) must also be very accurate and organised to ensure nothing goes wrong

- Models should be decided upon at the very start of the project

▪ This allows us to track the progress of the project▸ There can be multiple models for one system

- Large systems may have different models for different components of the one system

▪ Banking System -> Online Day-To-Day Transactions vs -> Loans system - Certain phases can have their own models:▪ If design phase is vital, adopt a model to finish just the design phase

� / �1 57


Software Process / SDLC Models

Waterfall Model ▸ Classical method▸ Oneway only

- All decisions made become final- Each stage is 'frozen' until the former stage is 100% completed

▸ Many iterations of the entire process is required- If the requirements were incorrect from the get-go or if client changes their mind, then

you start all over again

� ▸ Pros:

- Can very accurately track progress

▪ Management love it, because they OK final stages and therefore track progress- Each phase ends with a major deliverable

▪ An SRS document, a prototype, a build ▸ Cons:

- All decisions are final

▪ Developers cannot go back if they've realised they did something wrong earlier on▪ Hard to tell the client we can't go back if they change their mind

- Costly—approval of documents is expensive- Wasted effort—iterations require lots of work, and sometimes all for nothing

13

Waterfall Model: A Simplistic View

Requirements Analysis

Design

Implementation

Unit & Integration Test

System Testing

Acceptance Testing

Adapted from Figure 2.1 Pfleeger 2001

25

Waterfall Model: Alternative View

RequirementsProcess

SystemAllocation

Process

ProjectInitiationProcess

ConceptExploration

Process

DesignProcess

ImplementationProcess

InstallationProcess

Operation &Support Process

Verification& ValidationProcess

Adapted from Figure 12-8 Bruegge and Dutoit 2000

26

14

Waterfall – Too simplistic?� This model has problems!� Once a stage or phase has been “completed”, it can not

be revisited� requirements need to be “frozen”, design can not be altered� not true in practice

� Need to have many iterations� requirements may not have been understood, customers

may have changed their minds

� The actual development process may look more like…

27

Waterfall in Real Practice?

Requirement Analysis

Design

Deployment

Operations and Maintenance

System Test Unit Test

Coding

Adapted from Figure 2.2 Pfleeger 2001

28

� / �2 57


V-Model Representation Of Waterfall

� ▸ Dotted arrows represent association between tasks

- Validate Requirments: Does Acceptance Testing validate the initial Requirements?- Verify HL Design: Does the System work overall from its initial, abstract Design?- Verify LL Design: Does the code/objects work from their low-level Design?

▸ Still one way—it’s still waterfall! - But there is a mapping between the implementation and verification- You verify the corresponding design with the final product (during testing)

� / �3 57


Prototyping Model ▸ Involve the user to start off with informal and basic requirements▸ Work/Develop small prototypes developed over many iterations

- No decision is final until the user likes what they see!- Keep iterating the prototype until it matches what the user wants!

Exploratory Prototyping ▸ The best/most accurate prototype becomes the final system

�

Throw-Away Prototyping ▸ The best/most accurate prototype becomes the specification of the user requirements

- We throw away the prototype, since it’s only used to get our SRS Document- We use the information gathered to redevelop the new system

� ▸ Pros:

- Specifications are easily adaptable with the client

▪ More effective to grasp user requirements▸ Cons:

- Process/tracking is hard—management don’t like it: � means lots of iterations!- Exploratory Prototyping: Poorly structured system; it is just a prototype!- Throw-away Prototyping: Time and effort wasted for thrown away prototypes

� / �4 57


Incremental Model

� ▸ Deliver a large system fragment by fragment (i.e. incrementally).

- Each phase will continue to have more features added to it- The system is eventually developed fully

▸ Users suggest the most important features- Important features are prioritised over less important ones

▸ Each ‘increment’ or fragment is built with its own process model ▸ Pros:

- Users suggest the most important features early, which get the most attention- Early increments allow users to gain most experience on the requirements for later

increments- Decreased chance of failure

▸ Cons:- Difficult to map the size of increments based on user requirements solely- Basic core facilities (outside the system) fall outside of the user’s most critical services

Iterative Model ▸ Similar to Incremental Model but:

- 100% of the functionality are delivered ▸ With each increment, minor features that are not working at 100% capacity due to not

being fully developed then get developed

19

Evolutionary Approach – Pros and Cons

�Advantages�Specifications can be developed incrementally�More effective than the waterfall model to develop

systems that meet the immediate needs of customers

�Disadvantages�The process is not visible�For exploratory programming, the final systems are

poorly structured�For throw-away prototyping, time and effort are

wasted to build the prototype37

Incremental Model

Complete DeliveredSystem

Specify system increment

System Requirements(maybe informal or incomplete)

no

yes

System complete?

Build increment Validate increment

Validate system

Integrate increment

Adapted from Figure 8.4 Sommerville 2001

38

20

Incremental Model (cont.)� Customers identify the services (from most important to

least important) to be provided by the software� A number of delivered increments are then defined

depending on the priorities of the services� The most important services are delivered to the

customers early in the project� Once an increment is completed and integrated into the

software, customers can use it� Each increment can be built with the most appropriate

process model

39

Incremental Model – Pros and Cons� Advantages

� Customers can use the most critical services provided by the software early

� The early increments help the customers to gain experience on the requirements of later software increments

� The chance for the overall project to fail is lower� The most important services of the software receive the most testing

(because they were built earlier)

� Disadvantages� It is difficult to map customers’ requirements on to increments of right size

and appropriate functionalities� The basic facilities (that supports other parts of the software) are difficult

to identify if they fall outside the most critical services

40

� / �5 57


Spiral Model

� ▸ Emphasis is on high risk projects

- On each loop, we determine whether or not it’s worth risking- Good for long term projects

▸ On each loop, repeat the same 4 stages:- 1 ) Objective & Constraint Goal Setting: requirements, functionalities, budgets, time- 2 ) Risk Assessment: evaluate alternatives, identify/resolve (non-)technical risks- 3 ) Development & Validation: Build and test against user requirements- 4 ) Plan for next stage or loop: Based on the feedback of (3), review project▪ determine if continuing is a good idea

▸ Each loop is a phase in the software’s development▸ Pros:

- Explicit consideration of risks - Impose alternatives to achieve the same goals with varying constraints

▸ Cons: - Too high-level:

▪ not enough detail of a model for the technical personnel

Unified Process

21

Spiral Model

Developand Test

Plan

Determine Goals, BudgetsAlternatives, andConstraints

Evaluate Alternatives

and Risks

Requirements,life-cycle plan

Different Budgets (one per stage) Different Prototypes (one per stage)

Concept ofoperation

Detaileddesign

Code

Unit and integration test

SystemtestAcceptance

test

Implementationplan

Adapted from Figure 2.10 Pfleeger 2001 41

Spiral Model (cont.)� Proposed by Boehm (1988)

� The emphasis is on analysing risks at regular stages of software development

� Risks are results of inadequate information or uncertainties of the software project

� The software process is considered as a spiral

� Each loop in the spiral represents a phase in the software development

� At each loop, any development approach can be used� Examples:

� Prototyping to resolve requirement risk

� Waterfall model can be used too

42

22

Spiral Model (cont.)� Each loop in the spiral model is divided into 4 different

sectors:�Goal setting

� Determine objectives (functionalities, performances etc.), alternatives and constraints (budget, time, resources etc.)

� Risk assessment and reduction� Evaluate alternatives, identify and resolve risks involved (technical and

non-technical)

� Development and validation� Develop and validate the product (specifications, design, coding etc.)

� Planning for next stage� Review the project and make decision on whether to continue� Plan for the next stage, if decided to continue

43

Spiral Model – Pros and Cons

� Advantages� Explicit consideration of project risks

� Impose consideration of alternative ways to achieve the objectives and the constraints imposed on each of these alternatives

� Disadvantage� The representation is high-level, not enough detail to direct

the actions of software analysts, designers, programmers and testers.

44

� / �6 57


▸ Process for programming but:- Good for inexperienced or large teams

▸ Build up and refine the system gradually as a series of iterations ▸ Workflows/Disciplines Activities make up what we do within each iteration:

- 1 ) Business Modelling- 2 ) Requirements- 3 ) Analysis and Design- 4 ) Implementation- 5 ) Testing- 6 ) Deployment

�

Iterations ▸ A portion of the system that has been built or improved upon▸ Within each iteration is a series of activities (or disciplines)

- Each iteration is a scope of detailed planning▸ At the end of the iteration is a minor release of the system▸ An increment of the phase must contain more content of the system

Phases ▸ A collection of iterations make up one phase of the SDLC▸ Any number of dev cycles will compromises the SDLC (e.g., DC for v1, v2 etc.)▸ At the end of the phase is a milestone

- Management review risk, budget, schedule at the end of each phase▸ There is a different perspective on the system from management and engineers:

- Management will macro-manage the system over its phases- Engineers will micro-manage the system over its iterations

23

Unified Process� Is a bit like the process you use for programming, but:

� For teams� Tackles whole-of-project scope� Designed for medium-to-large software projects� Includes problem definition, scoping, requirements gathering,

architecting, design, coding, testing, deployment, maintenance…

�Organised as a set of iterations or phases

� Uses Unified Modelling Language (UML) as key communication artefacts

45

46

UP - Basic concept

�A series of “mini-projects”�Each mini-project called an iteration�Similar activities in each – repetition�Activities consume and produce models� Iteration is scope of detailed planning

etc.

24

47

Phases, Iterations and ActivitiesActivities grouped into iterations

Iterations grouped into phases

Activitieswithin aniteration

Ref: Larman Chapter 2

48

UP Terminology

� Phases�Inception, Elaboration, Construction, Transition

� Disciplines (originally 䇾workflows䇿) �Business Modelling, Requirements, Design,

Implementation, Test, Deployment, etc.

� Any number of iterations in a project� Any number of cycles in a product’s lifetime

� / �7 57


� ▸ Each phase:

- I - Inception - Vision—what are the problems that will be addressed? Is it feasible?

- E - Elaboration - Determine requirements, specification, basic prototyping

- C - Construction - Complete the executables

- T - Transition - Mitigate transition of the executable into the real-world

� ▸ We can see that each discipline will vary in each phase

- Business Modelling will be high in initial Inception Phase - Implementation peaks between Elaboration and Construction Phases - Testing will spike and increase/decrease over time between many phases▪ We're constantly testing our system against:▹ User requirements, model developed etc.

25

49

UP - Phases

� End of each phase is a major milestone�risk, budget, schedule, etc. are reviewed

� Inception - 䇾vision䇿, feasibility � Elaboration - adequate requirements

specification, and possibly some code� Construction - complete the executables� Transition - install and hand over the system

50

Usual Presentation of UP

�Discipline activities can occur in each iteration(and therefore in each phase)

�The usual presentation of the UP is in the form of a grid, with �phases as the columns; and

�disciplines as the rows

�Emphasizes that similar activities and models can occur in each phase

26

51

The Unified Process

Inception Elaboration Construction Transition

Bus. Modelling

Requirements

Design

Implementation

Test

etc.

Iterations

PhasesDisciplines or Workflows

52

Unified Process and UML

Phases

Iterations

Disciplines

Release

Artifacts

has

produce

end with

UseEngineers

focus

monitor

UML used to document

� / �8 57


Which SDLC Model is right for me?▸ Waterfall

- Great for communication and reference- Okay for very small projects where there won't be many iterations- Management like its easy-to-track features- Not a reflection of reality at all

▸ Prototyping Models in General - Good for most projects- Very few reasons against building prototypes▪ Far beneficial to get the user involved in these prototypes earlier on

- Exploratory Prototyping:

▪ Okay where initial requirements are murky▪ When its hard to determine the problem domain

▪ Good for UI—the user will like the prototype UI, and doesn't need to worry about the backend at all

▸ Incremental - Strongly recommended for reasonably sized projects- Lowest risk- Allows for feedback

Best Practises ▸ Simple, Well-understood techniques

- Set of simple, core techniques - Flexible design- Simple architecture

▸ Motivation- Adaptive teams

▸ Building trust and predictability at inception with users▸ Culture + People (Knowledge and Experience) + Communication▸ NOT 100-page books, complex frameworks etc.

- Documents that add value, not subtract!

� / �9 57


Solving Software Problems

Why make software? ▸ Pain-Points

- Parts in a software system that drive people nuts/make them unhappy- They are:

▪ What is not working properly for them?▪ What is hurting them?

▪ How serious is this 'pain'?- We solve the pain by providing a new solution- Likewise, we have Pleasure-Points, parts which they love!

▸ Social and Emotional Reasons - Not as easily explainable:▪ Clippy from MS Office

- From pain points regarding:

▪ "I am bored"▪ "I need inspiration"

▸ Help to solve business goals

What's the problem? ▸ Software addresses pleasure/pain points

- Generalise the pleasure/pain points amongst the opinions of many stakeholders- Once we've identified an abstract pain/pleasure point, we can perform further analysis- Understand the context or Problem Domain

▪ You cannot generalise all contexts

▪ A balance between environment and user interaction with general pain/pleasure point

How do you understand the problem? ▸ To understand the context:

- Domain Vocabulary ▪ Terminology meaningful to the context of the system▹ Ask the users—not technical vocabulary!

▪ Teaching Period, Credit Points, Exemptions = terms for Swinburne Enrolment System- Domain Actions/Processes

▪ Processes which users currently perform▹ Something in this process causes pain-points

▪ NOT what the processes they'd wish the system would perform

▪ Enrolment Process, Timetable Process

� / �10 57


Actors ▸ Core entities in our system that play some role/have some interaction with the system

- Can be people, things, even external systems:

� ▸ Every actor has its own pain points:

- Even the Timetable System (a non sentient entity) has pain points of its own▸ Every actor has its own goals:

- Actors use the system to reach their goals- What do actors need to achieve in the system?

▸ Analyse actors in regards to developing a new system:- What impact will the new system have on these actors?

Constraints ▸ Restrict and limit choice on how to solve problems▸ Examples:

- Time: Finish it in 2 months- Budget: Maximum spending of $1 million- Language: Must be written in COBOL- Performance: Must respond within a second, even with 1000 requests at once- Environment: We run a UNIX environment- Laws/Regulation: Must comply with GST regulation- User Education Levels: McDonald's staff

Determine The Problem Domain ▸ Identify actors ▸ Understand need/impact of actors▸ Identify actor goals ▸ Identify constraints ▸ Identify domain vocabulary ▸ Mitigate assumptions:

- Verify assumptions with users:▪ Are they (somewhat) (in)valid assumptions?

- If you do not verify, can be catastrophic/wasting our and their time.

� / �11 57


How is the solution to be built? ▸ What is the direction of the final solution?▸ Which solution is the best solution?

- Decide between certain proposed solutions.- Use constraints and habits/personality of team to help guide the direction- Ask:

▪ Is this a reasonable choice? Can I defend it? ▪ Will this choice have much impact? It will constrain our future steps…

Solution Domain ▸ The domain needed to work towards our solution

- Keep refining the Solution Domain based on:▪ Understanding of the problem domain

▪ Previous decisions made for solution ▸ Remember:

- Start by looking at the Problem Domain- Use information from the Solution Domain to set boundaries- Solution Point-Of-View ≠ Problem Point-of-View:

�

Solution Statements ▸ Problem and Vision Statements

- Communicates what the solution is in a non-technical fashion (tech terms explained)- The communications bridge between technical and non-technical people

� / �12 57


▸ Problem Statement - What needs to be done, without mentioning how it is to be fixed- Adhered to by all members

▸ Vision Statement - Captures the essence of the new system- Keeps developers motivated on its core beliefs - Keep it brief by following a simple format: The Fiddle Went Under The Orange▪ The { Product } is a { Category }

▪ For { Person } Who is the system actually built for?

▪ Who { Need/Opportunity } Why is there a need/opportunity? Pain points!

▪ Unlike { Competitor Product Advantage }

▪ That { Key Benefit / Reason to Invest } ▪ Our Product { Key Differences / Advantage }

▪ Example:▹ Swinetgy { Product } is a RTS Game { Category } for students { Person } who are bored in

lectures { Need }. Unlike Warcraft { Competitor }, Swintegy is designed for Swinburne Students { Advantage } that ensures hours of interactive gameplay { Benefit }

Gap Analysis ▸ If gaps aren't analysed and filled (mitigated) they can cause failure to the entire project

- Knowledge Gaps—Do we know what to do?

▪ Knowledge of an issue or aspect of the problem is not complete- Skill Gaps—Do we have the skills to do this? ▪ Skills are difficult to develop without a certain level of practise—just because you've

programmed in C# once or twice, you're not skilled it in at all!

▪ Overconfident developers:▹ Ego tends to hide their knowledge gaps

- Technology Gaps—Do existing technologies exist?

▪ You know what to do but which technique and technology do you use?▪ Use technology and techniques that have worked on similar, previous projects

▸ Know how to deal with gaps initially - How critical are these gaps to your success?- Can you close the gap?

▪ Spiking plans—how are you going to fulfil this gap?▸ Know how to deal with gaps as they come

- As development continues, you will find more gaps- New questions will arise as you dig deeper into development

� / �13 57


Gathering Requirements Data (Requirements Engineering) ▸ Requirements are features or constraints which the user expects in the final system▸ Requirements engineering contains two steps: Elicitation and Analysis

Requirements Elicitation ▸ Defines each of the user requirements

- Expressed in layman's terms- Informally categorised and summarised

▸ Requirements collaboration between:- Users, with Problem/Application Domain Knowledge - Developers, with Solution/Implementation Domain Knowledge - Bridges the Users and Developers via Scenarios and Use Cases

▸ Aims to establish (of both the existing and new system(s))- Objectives- How they work- Any gov't regulation that will affect either- Economic and organisational environment (i.e. existing procedures, culture, structure)

▸ Types of requirements:- Functional Requirements

▪ Features of what the system needs to actually do▹ Qualitative metrics of the system

▪ Interactions between the system and environment, independent of implementation

▪ DOCUMENT: The user's expectations of functions in the new system - Nonfunctional Requirements

▪ Visible aspects of the system but non-related to business logic or functional behaviour: Responds in < 1 second; Accuracy of 100m▹ Quantitative metrics of the system

▪ DOCUMENT: The expected performance levels in the new system - Constraints (Pseudo-Requirements)

▪ Imposed by the client or environment in which the system will operate▹ Must be in COBOL

▪ DOCUMENT: These user/environment-specified constraints under which the new system is going to be built upon

- Must be: Correct, Complete, Consistent, Clear, Realistic, Verifiable, Traceable

Requirements Analysis ▸ Analysis: Technical and unified understanding of simple requirements to developers

- Expressed professionally via UML

� / �14 57


Gathering Data out from the Problem Domain ▸ Interviews

- To understand the user's perspective on the Problem Domain

▪ Subjective answers—we should interview many for generalisation - Gets stuff that survey questions can't answer▪ Open questioning allows for unexpected answers

- But interviews are time-consuming▪ Stop when you stop learning new things from interviews

▸ Questionnaire - Efficient way to obtain lots of statistics- Closed Questioning is good when you know what you’re looking for

▪ But sometimes limit answers, clarification issues etc- Poor response rates

▸ Prototyping - Define system requirements iteratively with users- Costly, time-consuming etc.

▸ Observation - Find out what people actually do rather than what they say they do- Analyse actors, roles, locations, interactions, tasks etc.- Hawthorne Effect

▸ Document Inspection - Reviewing documentations that specify current business processes- Think about an accountant doing an audit

▪ What is the existing documents currently being used▪ The input and output to/from these documents▹ Helps to include some functionality in new system

- Data out of date, little opinions etc. - No human factor

▸ User Story - Users talk about stories with the system▪ Assess the behaviour of the system

- Developer's listen, ask questions- Helps to understand context- Each story is goal-oriented; something to verify against

� / �15 57


Modelling in Software Development

Why Model? ▸ Helps us make informed decisions later on—sticking to a plan/decisions and document it▸ The abstraction process—abstract all the detail from reality to a software system▸ Visualises the entire system as a whole (structure & relationships)

- Therefore we can communicate the system easily amongst other professionals- We can look at the system from different viewpoints- Better than trying to interpret thousands of lines of code▪ It is difficult to understand and comprehend all this at once; no overview

▸ Models are templates/blueprints of what we want to build▸ The go-to place when to get started

- Capture the concepts of the system as early as possible- From the concepts, we can develop generalised artefacts, which will be useful later on- How your internal objects and classes will interact with each other

▸ Communicate information between different shareholders/user groups▸ E.g., clients, users designers (Mechanical Engineers), technical Writers (People who write

manuals), Testers (Unit Tests)

What is a model? ▸ A simplification of reality

- Helps us better understand the problem, domain or the desired system:▪ structurally (statically) via class diagrams—class definitions

▪ behaviourally (dynamically) via sequence diagrams—message passing▪ problematically via use case models

- A systematic way to understand what the users want▸ Categories

- Static Visual: a house floor plan; IC schematic diagram - Static Non-Visual: formulae from ; description of house from frolla - Dynamic Visual: a graph that shows changes in temperature over time - Dynamic Non-Visual: server logs, code, phone calls - Note! A model doesn't fit just one category▪ A graph can be both visual dynamic (over time) and visual static (over all time!)

▪ Dynamic—Model must capture things over time; not that the model changes itself!

� / �16 57


Modelling Process

� ▸ Abstraction from conceptual system (non-physical) from the concrete system (reality) to

the model (symbolic system)- If models (Symbolic System) are badly modelled, then it will not reflect the real world

properly: the abstraction process to conceptualisation has failed.▸ Follow a process:

- Observe the existing, physical system - Recognise the abstract concepts - Rendering the system systematically

▸ Usually, a single abstraction is not enough- Conceptualise reality from different viewpoints

▪ By looking at reality from multiple viewpoints, you will gain further insight ▪ More insight = more abstractions conceptualised of the real-world

▪ Each of these abstractions can be further developed into its own model

▪ Just because there are separate models, they are still all interrelated models—from the same system!

▪ Consider a house blueprint for structural modelling:▹ Viewpoint: The elevated model of the side-view of the house ▹ Viewpoint: The top-down model of the house floor plan ▹ Viewpoint: The roof lining model of the top of the house ▹ Different model—same house!

When Building Models… ▸ Representation of the model depends on the problem▸ Formality is up to you▸ Phases to modelling: conceptual, specification, implementation

7

Many, many, many UML tools… ! Model software

systems in various ways

! High level to low-ish levels of abstraction

! Used for different things @ different times during SD

13

14

Overview ! Roadmap – Modelling part of SDP ! What is a model?

! What is UML?

! How does it relate to software process?

8

15

Why Model? ! Models can help us to:

" Understand – large systems - difficult to comprehend

" Communicate

" Capture and document decisions " Represent and explain concepts visually

! Models offer a template that can be used when constructing the system

16

The Meaning Triangle

Conceptual System!

Concrete Business System!

Symbolic System!

Reflects / Represents!

Refer

s to

Symbolizes

This is in the modeler's mind!

These are accessible in the world!

This can be displayed, e.g.

diagram, code, form.!Con

cept

ualiz

atio

n

This can be sensed, viz. real things!

� / �17 57


▸ Iterate your models to refine it!▸ Fundamental principles:

- The model has a profound influence on the system—it must reflect the problem in the solution model (otherwise you've wasted your time!)

- No single model will do—you will need multiple- "Essentially all models are wrong, but some are useful"- "The practical question is how wrong do they have to be not to be useful"▪ If the model is not at all useful, we can throw it away

UML

▸ Provides users with an expressive modelling language that integrates best practises ▸ Ready-to-use core concepts; extensibility and specialisation mechanisms are available▸ Supports complex development concepts:

- collaborating objects, design patterns, components▸ UML is neutral with focused areas:

- Software development processes- Modelling guidelines (hand, computers)▪ Just the notation

- Programming languages

▪ Not just for OO languages!▸ UML Building Blocks

- Things, events, processes:

▪ Structural, behavioural, grouping or annotate (provides more info on certain entities) - Relationships

▪ Dependency between classes/use cases

▪ Association between classes▪ Generalisation between classes

- Capture multiple viewpoints in diagrams:

▪ The s ta t ic s t ruc tu re and dynamic behaviour

Diagrams ▸ Structure

- Class & Object Diagrams*- Component Diagrams

▸ Behaviour

� / �18 57

15

29

UML Diagrams ! Class & Object diagrams ! Component & Deployment diagrams ! Use case diagram ! Activity diagrams ! Sequence & Collaboration diagrams ! Statechart diagram ! Packages & Subsystem diagrams

12+ different diagrams

Structure

Behaviour

Model Management

UML Diagram to represent UML Diagrams!

UML v2.2 http://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg

30

16

31

A few important points about UML !  Explicit intention of UML developers was not to

prescribe " Any software development process " Any CASE tool " Any modelling guidelines (techniques)

" Any specific programming language

!  Dedicated goal: openness " Specifications are public and do not require a licence to use

32

Some UML Diagrams…

Use Case Diagram

Class Diagram

Collaboration Diagram

Sequence Diagram


- Use Case Diagram* (Summaries all the use cases)- Activity* Diagram

▪ Expresses the processes and flow in the system- Sequence* and Collaboration Diagram▪ Interactions between objects in the system

- Statechart Diagrams▸ Model Managements

- Packages and Subsystem Diagrams

UML Notation For Certain Diagrams

� ▸ You will need to iterate to your final models

- They are all correct - Some will be more correct than others

▸ UML Sequence Diagram:

�

� / �19 57


▸ Architecture diagrams are the technical physical devices used to deploy your system

�

How does UML Relate with the Software Process? ▸ Remember UML is used to document the artefacts that are to be produced at the end of

each major phase▸ These artefacts are a part of the Unified Process

- E.g., At the end of the Inception Face, we produce a Domain Model artefact to document the progress of the system

- The progress is given back to the management- Each discipline in the Unified Process develop certain models:

� ▸ Within each model developed, certain diagrams would be needed

- E.g., Implementation Model would have:▪ Implementation-Model Class Diagrams, (i.e., describes method calls)

▪ Sequence Diagrams,

▪ Collaboration Diagrams etc.- E.g., Design Model would also have Design-Level Class Diagrams etc.

21

Architecture – Deployment Diagram

41

42

Overview ! Roadmap – Modelling part of SDP ! What is a model?

! What is UML?

! How does it relate to software process?

22

43

Unified Process and UML

Phases

Iterations

Disciplines

Release

Artifacts

has

produce

end with

Use Engineers

Management

focus

monitor

UML used to document

44

UP - Disciplines and Models

!  In a project organized according to the Unified Process … " development work occurs in a series of disciplines, e.g.,

business modelling, requirements, ... deployment

" disciplines use and develop models, e.g., domain model, use-case model ... deployment model

23

45

Examples – Disciplines and models

!  Business Modelling !  Requirements

!  Design !  Implementation !  Test

Domain model

Use-case model

Deployment model

Design model

Implementation model

Test model

46

What is in each UP model?

!  Models contains diagrams (of various kinds) and other kinds of artefacts (e.g., documents)

!  Some kinds of diagram are closely associated with particular UP models, e.g., "  UML use-case diagram - UP use-case model

"  UML deployment diagram - UP deployment model

!  Other kinds of diagrams occur in several models "  e.g., UML class diagrams occur in domain, design and implementation models

but with different perspectives

24

47

What next? ! We’ll look at the BASICS of UML modelling & apply in

project #2: " Domain modelling (week 4) key concepts for a system " Behaviour modelling (week 4) – what it does " Detailed data modelling (week 5) – what it stores

" Domain and system modelling (week 5) – who does what " Detailed behaviour modelling (weeks 6, 7) – how it works " Detailed architecture (week 7) – how to deploy it

" Detailed input/output (week 8) – getting stuff in & out

48

Summary ! We model to understand, capture and communicate the

various views of a business or software system " Models can be used to represent structure and behaviour

! UML is a widely used modelling language !  It is good to consider multiple views when building

software systems ! Don’t draw models for the sake of it – they are a tool to

help you better understand the domain & system

� / �20 57


▪ (i.e., more general than Implementation-Model Class Diagram—no method calls yet!)▸ The final models will also contain other kind of artefacts/documents

Business Modelling & Requirements Gathering

▸ Business Modelling: Understand the problem domain▸ Requirements Gathering: Understanding the requirements▸ Activities: Use Case Models, Domain Models

Use Case Model ▸ Intended to capture the functionality of the new system▸ Describe how will the users will interact with the system▸ Support with a Use Case Diagram▸ Defining Actors within the Use Case Model

- Roles played by users when they interact with the system

▪ Staff Role▪ Student Role

- Note that actors can be played by the same people (I am a Staff and I am a Student)▸ Use Case Diagrams

- Summarise the relationships between actors and use cases (tasks) - Must show:

▪ The actors▪ The use cases/scenarios

▪ Who does what- Gives a summative overview of actors and system - UML Syntax:

� ▸ Use a template when developing full Use Cases

- A use case compromises all the possible interactions that a user can have when performing a given task—a dialogue between

� / �21 57


- Developed as Scenarios

▪ The different tasks that users can perform while interacting with the system

▪ Different scenarios describe the course of events:▹ Basic Scenarios—all good flow; expected flow▹ Extension Scenarios:▫ Alternative Scenarios—where some tasks are optional▫ Exceptional Scenarios—when an error has occurred; unexpected flow

- Problem Domain Scenario: as is at the moment - Solution Domain Scenario: visionary solution scenarios

Use Case Templates ▸ While UML doesn't tell us to stick to a template, SDP tells us to!

- Name of the Use Case (A verb—e.g., Booking Tables)- Actor and their Goals (Receptionist wants to Book a Table for customer)- Preconditions (Requirements and conditions for things to be true beforehand) - Success Guarantees/Postconditions (What is a successful outcome?) ▪ We need to know this for successful Test Cases ▹ Validations of functionality

- Scenarios▪ A basic scenario

▪ Number of alternative or exceptional scenarios—extensions ▸ One column; all dialogue in just one column ▸ Two column; dialogue in a request/response fashion

- actor does X and system responds with Y▸ Use case modelling, grasp a basic idea of the UI that the actor will use

- This will help you determine what an actor will need to do- E.g., design a UI to help determine a visual guide

▸ Remember to include alternative and exceptional scenarios to Use Case Model:- Exceptional Example:

� / �22 57

15

Actor Generalization� The last diagram shows that the Receptionist can performs

the Display bookings use case independently from the Record Booking use case.

� Head Waiters can also performs Display bookings use case.� Introduce a more general actor Staff to show what the other

two actors have in common.� The initial actors are specializations of the general actor.

29

Actor Generalization Notation

System

30

16

Use Case Extension

� Recording a walk-in can be described as an exceptional course of events:� someone arrives but there’s no booking recorded.

� It could also be a separate use case:� a customer arrives and asks if there's a free table.

� Then, it can extend ‘Record Arrival’:� even without a booking, the customer stays to eat.

31

Use Case Extension

Record Walk-in: Basic Scenario:1 Head waiter performs Display Bookings use case;

2 Head waiter enters details (time, number of covers and the table allocated to the customer);

3 System records and displays new booking.

� Very similar to Record Arrival use case. Can we simplify?� <<Include>> dependency is inappropriate. (why?)� Record Walk-in is performed in some cases of Record Arrival,

when there is no booking for the customer.

32


- Receptionist searches for a booking of 4 peopleTable available at their intended time But table accommodates 2 people onlySystem asks for confirmation of oversized booking (4 > 2)

Shared Functionality ▸ Different use cases can overlap each other▸ Move shared functionality to separate use cases

- So, if we have a Display Bookings use case, it can be used again in further use cases:

▪ Record: Receptionist runs Display Bookings to record a customer in▪ Arriving: Head Waiter runs Display Bookings when customers arrive at restaurant

Generalised Actors ▸ If actors are shared, then we can generalise them to general actors▸ In such a case, general actors that share use cases/scenarios can then just point to the

one use case (as per diagram)

<< include >> vs << extends >> ▸ Extend extends the functionality of the inheriting use case

- There must be a constraint in both cases, but the preconditions vary between the two▸ << include >>

- In one single single use case, you have extension scenarios▪ If I need to Record a Booking, I need to include the Display Booking use case

- Then an extension for that—i.e., same preconditions- E.g., Record Booking << include >> Display Booking

▸ << extends >>- One use case extends each other- Different preconditions:

▪ one condition is the basic scenario (customer arrives with booking)

▪ one condition is the exceptional scenario (customer arrives as walk in / no booking)

- The constraint/condition is noted next to the <<extend>>

- If a customer walks in out of no where, then we can extend record arrival use case—they didn't book we still record their arrival

� / �23 57


General Guidelines ▸ Covers full sequence of steps from beginning of task to the end▸ Describe user interaction ▸ Doesn't describe technical computations ▸ Independent as possible from UI design▸ Only include actors that interacts with the computer

Pros & Cons of Use Cases ▸ Pros

- Simple and Familiar▪ Easily understood by untrained personnel

▪ Involves users early in development- Emphasis user goals and from different perspectives- Scaleable

▸ Cons - Must ensure non-ambiguities- Actor-initiated activities are only implemented- Software isn't really described—manual processes only- Prevents innovative ways to be developed (we don't question these manual processes!)

Domain Modelling ▸ Make a UML diagram to construct a model of the real-world system▸ Helps us understand the problem domain

- Never going to get it correct the first-time- Never correct—we don't know when it

is going to be correct!

▪ There are lots of plausible models that can exist

▪ Remember, it's just a guide—not an end in itself!

▸ UML Syntax for Domain Model Diagram resembles simplified class diagram:

- Classes—Real-world entities▪ Can represent non-physical items: Table, Reservation

- Attributes—Represent data held about entities- Relationships

▪ Define a verb for the relationship is readable: Customer can make many reservations

▪ Define ordinalities: A Customer can make Many Reservations

� / �24 57


- Constraint

▪ Indicate conditions that cannot be shown graphically▪ i.e., Double-booking a table

- Generalisations

▪ Superclasses inherit shared properties▪ E.g., Different types of bookings: walk in or reservations

Static Models▸ Captures the structure of the solution we're going to make

- A way to document what we will code- Taking the domain model and making a solution from it

▸ From the domain model, identify what will be useful features will be in your solution- Not all classes in Domain Model will go into the Solution Model—e.g., customer class…- Likewise, we will need additional classes in the Solution Model that won't be in the

Domain Model—e.g., controller classes, UI classes etc.

Modelling Structure And The 3 Perspectives ▸ Class diagrams are key to OO Paradigm when it comes to capturing the static structure▸ Structure can be captured in three perspectives

� ▸ 1 ) Conceptual: Problem Domain—What do we identify from problem into the solution?

- What is the problem? - Captures business domain, and understand the problem—NO SOLUTION…- The structure and model about the concepts, relationships in the business domain- Natural objects and relationships—not necessarily realised in final solution▪ Key attributes

▪ Key associations & cardinality

▪ Generalisations▪ Do not include operations—methods▹ We haven't yet determined the solution… why have methods yet?

Business modelling with UML

Modelling structure 4

Modelling perspectives ! Conceptual perspective

" Structure and model the concepts in the business domain under study

! Specification perspective " Focus on the interface of the software only (consciously

ignore the implementation detail)

!  Implementation perspective " Modelling at this level is for developers familiar with the

implementation framework and language

8

Modelling perspectives

Conceptual

Specification

Implementation

Transformed into

Refined into a Models are very useful in capturing the structure for all of these perspectives

� / �25 57


- A vehicle to transport a family ▸ 2 ) Specification: Solution Domain—What can we identify that the solution?

- What will the solution do? - Looking at the software▪ Include only the interface of the software—what do the objects do…

▪ Ignore the implementation details—don't worry how they do it…

▪ It's hard to do this if you've already decided how you'll be making it; hard to ignore the implementation

- Identify a number of classes to include in the program▪ Attributes/State of the class

▪ Operations/Behaviour of the class- High Level▪ What are basic details from the conceptual specification?

▪ Details from the problem domain…▹ It needs to be a car with fuel efficiency for running costs etc.

- Low Level

▪ What are more finite details that we can think of from conceptual specification?▪ Details from the solution domain… ▹ V6 Engine, ABS etc…

- 3 ) Implementation: Solution Domain—Building the Solution ▪ How are we going to implement the solution?

▪ Details of programming language: private, public, protected ▹ Describe these details in the model (e.g., +, —, #) ▹ This level only describes programming artefacts▹ All operations must be developed—how is the system going to work?

▪ How are we going to actually develop the solution?

▪ For developers:▹ Implementation via frameworks/languages, platforms to deploy solution on…

Class Diagrams

▸ Captures the building blocks/entities/objects of the system▸ Can be at different perspectives: Conceptual, Specification, Implementation

- Conceptual Classes (Domain Model) ≠ Implementation Classes (Solution Model)▸ Class Diagrams captures:

- Types of Objects = Classes

▪ Attributes (Fields)� / �26 57



15

Class diagrams ! A class diagram captures,

" Types of objects in the system $ “Class” " Attributes and behaviours of classes

! Relationships between Classes " Generalisation (Subtypes)

" E.g. A programmer is a kind of human

" Associations " E.g. A customer may rent a number of videos

" Other " E.g. dependency

16

Class diagram : Class Symbol

Client

companyAddress companyEmail companyFax companyName companyTelephone

Class name compartment

Attributes compartment

Operations compartment

© Bennett, McRobb and Farmer


▪ Behaviours (Operations)- Relationships between classes▪ Generalisation: Inheritance—a programmer is a human

▪ Association: One customer rents many videos▪ Others: Dependency etc

▸ Class Name Compartment - Choose a class name from the Business Domain—helps communication with the client

▸ Attributes Compartment—Objects KNOW - Essential to business description of the class- What does the object know…

▸ Operations Compartment—And can DO things - Talking about the solution- Behaviour and responsibilities of all objects of this class▪ Queries (property getters) or

▪ Commands (roles that the class can do—service provided)▸ Class Level Operations—STATIC attribute or method

- Represented with Underlined notation- Invoke messages on the CLASS object, not on the instance of the class- The class object can respond based on a message it recieves, not an instance:

[ NSString stringWithFormat:@"Something" ];

Object Diagrams ▸ The types of objects are describes in Class Diagrams▸ Object Diagrams specify relationships of two instances at a single point in time

- The state of the instance is X at this point in time- i.e., the attribute X of this instance is currently X

▸ Show this by adding a semicolon prefix to the member name:

SomeInstance:OfThisClass

Relationship Arrows ▸ Generalisation Relationships

- Inheritance-Type Relationships- Personal vs Corporate Customers Subtyped from the Supertype Customer

▪ Both inherit Roles & Responsibilities (Attributes & Operations) from the base Customer class…

� / �27 57


�

▸ Association Relationships - Any normal logical, permanent relationship between objects

▪ You can omit the Association Name/Label for the explicitly define the Association Roles for both classes

▪ Instance variables are held within the object to associate the two objects together

▪ Cardinality describes the range of permitted objects in an association to an object▹ Business rules regarding association—one to one, one to many etc.▹ Read using EACH X <Association Name> <Cardinality> Y

- N-ary association: where N = 2 (binary)

▪ Two classes are associated with each other:

�

- N-aray association: where N = 3 (ternary)

▪ Three classes are associated with each other

▪ A lecturer teaches 0 or * subjects in a 0 or * semesters

▪ One subject subject in a 0 or * semesters, there is 0 to 2 lecturers

▪ One semester has 0 to * subjects with 0 to 2 lectures



23

Class relationships: Generalisation ! Consider the following example:

" A company has personal customers and corporate customers

" There are differences between these two types of customers

" There are also many similarities between these customers

! UML recommends the use of "generalisation" to model situations like in the example above

24

Class diagram: Generalisation

Customer

Personal Customer Corporate Customer

! A personal customer is a kind of customer

! A corporate customer is a kind of customer

Note to programmers: Generalisation relationships need not always be implemented using inheritance Business modelling with UML


25

Class diagram: Associations

Direction in which name should be read

StaffMember staffName staffNo staffStartDate

Client companyAddress companyEmail companyFax companyName companyTelephone

liaises with staffContact

Association role Association

Association name

!  Associations represent: "  The possibility of a logical relationship or connection between

objects of one class and objects of another. "  Information stored about the associated objects.

26

Class relationship: Associations (cont.)�

! An association can have a label, which is used to describe the nature of the relationship

! You can exclude the association label, if you explicitly provide roles of classes for the association�

Option 1 Option 2

� / �28 57



Class Diagram: N-ary association

27

Lecturer Subject

Semester

teaches >

in

0..2

0..*

0..*

28

Class Diagram: Cardinality !  Associations have Cardinality !  Cardinality is the range of permitted objects linked in an

association to a given object. !  Represent business rules. !  For example:

" A staff member may liaise with one or more clients. " Each client must liaise with just one, and only one, staff

member.



- Association Navigation

▪ Without an association arrow (not reading-label arrow!) the association is bidirectional

▪ We can limit the association and explicitly define the direction▪ If an association navigation arrow is specified, then navigation of these class's

association relationship is one-way:

▸ Aggregation Relationships - Whole/Part-Of relationship- This object contains a whole bunch of the other objects

▪ A room (whole) has furniture (part)- Aggregation does not change the meaning of navigation across the

ASSOCIATION of the relationship—association is still constant…- Aggregation does not link the lifetimes of the whole/part▪ You don't OWN the objects that you aggregate

▪ You can SHARE part-of objects between one or more wholes

▪ I can take the furniture out of the room before I destroy the room

▪ Destroying the room does not guarantee the destruction of the furniture

▸ Composition Relationships - Like Whole/Part-Of Relationship- BUT you have a strong relationship▪ You the whole OWN the part

▪ You cannot SHARE the ▹ A wheel can only belong to one car and no other car

▪ Composition allows for lifetime linking:▹ If you destroy the car, you

destroy the wheels etc.

� / �29 57



29

Class Diagram: Association cardinality

StaffMember

staffName

staffNo staffStartDate

Client

companyAddress companyEmail companyFax companyName

companyTelephone

1 0..*

liaises with

Cardinality

• Exactly one staff member liaises with each client

• A staff member may liaise with zero, one or more clients


Class Diagram: Association Navigation

!  Navigation across an association is, unless otherwise specified, bidirectional.

!  Sometimes, you will want to limit navigation to just one direction.

30



33

Class diagram : Aggregation ! When modelling we often find the need to capture

"whole-part" relationships " An office room has furniture

! A type of association called aggregation can be used to capture whole-part relationships

! Aggregation is modelled as a hollow diamond in UML

Whole

Part

34

Aggregation example

Room

Computer Desk Chair 0..* 0..* 0..*



33

Class diagram : Aggregation ! When modelling we often find the need to capture

"whole-part" relationships " An office room has furniture

! A type of association called aggregation can be used to capture whole-part relationships

! Aggregation is modelled as a hollow diamond in UML

Whole

Part

34

Aggregation example

Room

Computer Desk Chair 0..* 0..* 0..*



37

Reading composition…

!  A wheel cannot be shared between cars !  Car is created implies engine, chassis & 4 wheels are created

!  Seats may be added/removed after Car is created !  When a car is destroyed all parts are also destroyed

Car

Wheel Seat Engine 1..4 1

Chassis

1 4

38

Composition example

!  It is best not to worry about composition/aggregations early in the modelling phase

!  Very important when the system is about to be implemented

!  Powerful when the semantics are well understood by the entire team -- can also lead to confusion if not properly understood

Car

Wheel Seat Engine 1..4 1

Chassis

1 4


▹ Seats more flexible; one or four seats may be added OR REMOVED (1..4) after the car is created

▸ Dependency Relationships - Relationship when one object has an impact on another object—but then forgets about

its existence.

▪ Temporary use—local variable use (NOT instance variable use) of another object

▪ No permanent relationship between the two objects; lives within one operation only - The LoginController temporarily uses the Authenticator to login within its Login method

▪ Once it has used the Authenticator (once Login method is finished), it forgets about it - Independent object has the arrow pointed to it—Authenticator is independent from LC

Constraints ▸ Used when properties cannot be

expressed graphically- E.g., no two tables can be double-

booked - Use note to signify this

How to Build A Class Diagram

▸ 1 ) Look for Candidate Classes - Examples:

▪ People

▪ Organisations▪ Structures: Team, Project, Campaign

▪ Physical Items: Forklift, Toothpaste

▪ Abstractions of People: Employee, Supervisor ▪ Abstractions of Physical Items: Wheeled Vehicle, Retail Goods

▪ Concepts: Campaign, Project, Qualification ▪ Enduring Relationships between Members of Other Categories: Rental▹ It has so many states about the relationship between Customer & Video that we

can make it its own class▸ 2 ) List all nouns then keep relevant/appropriate Nouns only

▪ Inappropriate nouns:

� / �30 57



Class Diagrams: Constraints

%  Not all domain properties can be shown graphically: %  e.g., it should be impossible to double-book a table.

%  Constraints add information to models: %  written in a note connected to the model element being constrained.

31

Constraints

Case Study 1: Tables and Reservation

32



39

Class relationships: Dependency !  In UML modeling, a dependency relationship is a

relationship in which changes to one model element (the independent “supplier”) impact another model element (the dependant “client”).

!  That the Client depends on (in some way) or uses the Supplier

!  You can also use dependency relationships in object diagrams, component diagrams, deployment diagrams, and use case diagrams.

LoginController Authenticator <<use>>

40

Dependency Vs Association…

! Association relationship means " It is a permanent link

" Instances are tied together for the whole lifetime of their existence

" You would expect to see an ‘instance variable’ in one of the classes based on the direction of the relationship

! Association example " class A {private B b; private C c; …. }

Class A is associated to class B & class C


▹ Cannot be instantiated: quality, ease▹ Meta-term: rule, process▹ Out of Scope of BD: at home, Melbourne▹ Measurements: second, mile ▹ Labels/Attributes: names, times ▹ Proper Nouns—values of Attributes: 2014-01-01, Fred ▹ Actors (okay if generalised—librarian bad, staff member good) ▹ Physical item that has nothing to do with a class—credit card, file

▪ Appropriate nouns:▹ Physical Items: person, book, customer, video▹ Roles or State: customer, client, member▹ Events: arrival, request, contract▹ Interactions: meeting, intersection, rents

▸ 3 ) List all appropriate verbs - Verbs may not represent relationships but operations- An verb customer cancels product is an operation

Dynamic Behaviour

Activity Diagram ▸ Modelling the business processes within the domain model

- High-level processes that the system will do- Helps us:

▪ Business Flow: Confirm whether or not we understand the business flow of domain

▪ Use Cases: Interrelation and interaction of the system▪ Design: Design of algorithms and complex sequences

- Strength is that we can represent concurrent activities - Abstract view of a complex system

▪ Easy to identify the important components of the system

▪

� / �31 57


�

� ▸ Forking

- Concurrent flows in the business process- A synchronisation bar indicates when to specify fork

(split activity) or join (wait for activities to meet)

▪ Think Thread.Join() and Thread.Start()… ▸ Swim-Lanes

- Group relates activities into logically, readable 'lanes'—improves readability

Sequence Diagrams ▸ Modelling the dynamic processes that the system will do

- Activity Diagrams capture high-to-medium level concepts of the system- The low-level of the objects themselves are captured in Sequence Diagrams ▪ Object message passing

▪ When objects should invoke messages to each other

▪ How objects collaborate- Capture the flow of events of a use case

▪ How does the system actually fulfil this use case?

▪ What is needed by the system (on the object-level) for the use case to be achieved?

� / �32 57

6

Activity Diagram

� Diagram Elements:

Activity Initial Node

Activity End Node Transition Activity

Decision Fork Join Swim Lane

Activity Diagram

� Activity:� Fundamental block in an activity diagram.� Represents a unit of work (something is done).� Automatic transition upon completion.

� Transition:� Represents the control flow: it is simply a movement between

activities.

� Initial and End Node:� Show the beginning and ending points in an activity diagram.


▪ How does the system interact with itself/behave for functionality to be achieved?

▪ Not a System Sequence Diagram (that's just a visual Use Case)

▸ WARNING WITH CLASS DIAGRAMS! - Should have a relationship if sequence diagram passes a message between objects- The receiving object should implement that message if it is passed to it (i.e., show it in

the Class Diagram!!!)▸ Know the left/right top/down order:

- Sequence of responsibility starts from the topmost level object and moves - Sequence of message passing goes from top down

� ▸ Sequential flow displayed in one diagram

- If you have multiple concurrent activities, then you need one per activity

Lifeline Boxes ▸ Represent objects▸ Presented in 3 ways:

- 1 ) [ someObject ]

▪ Object not tied to a class- 2 ) [ someObject:SomeClass ]- 3 ) [ :SomeClass ]

▪ Don't know what instance of this class is sending it▸ A dotted line indicates how long that object is alive within the disarm

- How long that object is activated for

Message Passing ▸ Use an righthand solid arrow to indicate a message▸ Use a lefthand dotted arrow to indicate return value from message

- Alternatively, you can just use retVal = someMessage

� / �33 57


� Creating/Destroying New Objects ▸ Creating

- Use a <<create>> message to make a new instance of an object

- This will make a new activation box ▸ Destroying

- Use a <<destroy>> message to destroy the instance

- The lifeline of the activation box will end with an X

Looping & Conditional Frames

�

� / �34 57


�

�

Collaboration Diagram ▸ More-open design; FREEDOM!

� ▸ Graph objects anywhere you want▸ Place message passes on a communication late

- Indicate the direction of the message with an arrow

� / �35 57


▸ Capture time by adding numbers to each message passed- BUT Harder to see than a Sequence Diagram

Design

▸ Perform use case realisation to our use cases- Adding operations to the business entities- Move closer to an actual class in program.

▸ Remember analysis is not design - "Do the right thing (Analysis) and do the thing right (Design)"

▪ Analysis determines what are we doing…

▪ Design determines how we are going to do it… - Analysis describes real-world (as-is) system—focus on system requirements

▪ Determine/Describe the object/concepts that are described in the real-world

▪ Plane, Flight, Pilot

- Design realises the proposed system—focus on potential system implementation

▪ Define how these objects could collaborate to fulfil requirements

▪ Plane: _tailNumber; getFlightHistory();

▪ Flight: _number;

▪ Pilot: _name;

Software Architecture ▸ High-Level description of the overall system

- Top-level structure and roles of subsystems- Identify what these high level subsystems are…

▪ Minesweeper: Overall system▹ Display: GUI Subsystem▹ Application Logic: Game Subsystem▹ Storage: High Score Subsystem

� / �36 57

Minesweeper

Display

Application Logic

Storage


▸ Design well:- Improve class cohesion: group related concepts that work well together in one class

▪ Reduce gigantic methods into smaller methods

▪ Group related smaller methods into appropriate subsystem (class) ▹ E.g., making one method display the Mine, work out the mines underneath it and

save the score is BAD COHESION- Reduce class coupling: minimise two classes' interdependent as much as possible▪ Display should not directly interact with storage, it should only talk with its App▹ Interaction should only be there IF NEEDED

� / �37 57

Display

mouseClickSquare

menuClickExit

Application Logic

checkForMine

getBoardsaveBoard

Storage

storeHighScore

readHighScore

7/04/2014

9

Minesweeper: System Three

� Coupling:� Reduced. MSGUI depends on Minesweeper only. Minesweeper depends on MSStorage only.

� Low coupling enables easy maintenance, e.g.:� Changing MSGUI to MSTextUI would not affect the main

application at all.

� Can swap in another storage class, e.g., database storage, by providing the same methods.

Minesweeper: Systems Comparison

System 2

Minesweeper

System 3

MSGui

MSStorage

Minesweeper

MSGui

MSStorage

System 1

Minesweeper

�Bad Cohesion

�No Coupling

�Good Cohesion

�Medium Coupling�Good Cohesion

�Low Coupling


Layered Architectures ▸ VIEW: Presentation Layer

- How the Application is Displayed (View)- Very dependent on domain

▸ MODEL: Application Layer- The underlying logic of the system

▸ Storage Layer- Keeps the application persistent- Domain-independent—one database can store

several domain▸ Each layer can aggregate many classes or

packages (collection of classes) - By packages we mean C++/C# namespace…

▸ Present all this in a Package Diagram (RHS)- The package diagram has arrows to indicate dependency:

▪ Which package depends on other packages… ▸ Each layer insulates changes to the system ▸ Stereotypes on classes will have typical roles:

- Boundaries—Classes that interact with outside actors (View)- Control—Manage use case behaviour (what happens when the

system is separated)- Entity—Persist the business logic/retain the data (Model)▪ Entities

▪ Databases - Allows us to know which objects serve which purposes ▪ StaffUI—Class responsible for displaying the bookings

▪ DisplayControl—Class responsible for retrieving the bookings▪ Booking—Class responsible for representing a booking

� / �38 57

7/04/2014

11

UML Package Diagram

Dependency:Represent the “make use

of” relationship .

Package:Collection of classes or

sub-packages.

Minesweeper: Package Diagram

Presentation

Minesweeper

Application

MSGUI

MSStorage

Storage

� Corresponds to programming construct:� Java: Package.

� C++: namespace.

7/04/2014

13

� Stereotypes can be text or a graphic icon.� The icon can replace the normal class box.

Class Stereotype Notation

Use Case Realization: OverviewUse case realization = implementation of the use case.� Steps:

�Go through each use case.� Identify interaction using a UML sequence diagram.� Refine the domain class diagram.

� Possible refinements:� Adding a new class and/or data.� Define association nagivability (direction) and role name.

�Adding operation to an existing class.

� Focus is on System Functionality during Analysis phase.� Ignore other layers (Presentation and Storage).� Concentrate on the Application layer.


Realising The Use Case▸ How can we go from Use Case to the Sequence Diagram?

- Go through each Use Case- Identify interaction in the Use Case using a Sequence Diagram

▪ This may mean a refinement of the Domain Model (some things will be needed, other classes may not be needed)

- Add operation to existing classes- Define navigation with association relationships and a role name

▸ 1 ) Focus only on the Behaviour (System Response) of the system- Use Cases are concerned with how the system will interact with Actors and vice/versa

▸ 2 ) Then focus on the Entities of the System- Collection classes that aggregate collections should be denoted as ClassList

▪ E.g., Client and ClientList are two separate classes - Use double boxes to indicate ClassLists in UML—>

▸ 3 ) Then focus on the Boundaries (I/O)

�

Note: The Sequence Diagram was defined from Use Case ONLY—

not realisation of actual system… missing boundaries!!!!!!!!!!!!! � / �39 57

:Client


▸ Heuristics to the final sequence diagram- 1—Actor that initiates use case- 2—Boundary to the UI- 3—Control to distribute reflections or get data to/from entity- 4+—Entities within the system

▸ Start with Actor to Boundary (4 actions below from Actor), move deeper into the system…

�

From here we can develop our Class Diagrams with the

relationship associations specified!!!! :D :D :D :D :D

� / �40 57


Capturing the Architecture▸ Try and capture all the machines in the infrastructure of the system▸ Capture the physical machines of the system▸ Use deployment diagrams to do this

- Captures all the execution environments (platforms)—e.g., .NET

▪ Denote the kind of execution environment—e.g., <<device>>- Artefacts are a specification of physical space used or produced by a software

development process—e.g., Files/Databases- Association relationships between each Execution Environments

� ▸ Should be verbally discussed and visually/diagrammatically designed▸ Consider in the discussion:

- How to install the system? Number of servers? Their software etc.?▪ Base physical hardware… servers, RAM, networking etc.

▪ Can it be installed just by a script—i.e., installed by an expert?

▪ Should it be installed with a GUI wizard—i.e., installed by a novice?

▪ Can it be installed remotely?

▪ Who can install the system?- Maintaining the system?

▪ Can it be updated or patched whilst it is running?

▪ Backing up the system?

� / �41 57


▹ Important client data—we don't want to ever lose it!!!- Starting up the entire system?▪ Who can start/stop the system? Admins, or everyone?▹ Who has the skills to start it? Network admin, sever admin skills…

▪ Should the startup/shutdown procedures be traced?▹ Trace who has started/stopped it—enhances security breaches!▫ i.e., a person who wasn't authorised to start it did start it

▹ Need to ensure it that the trace file can be viewed by others too…▫ i.e., is the trace file viewable to the bad guy who started it? Then doesn't help!!!

▪ Initialisation process?▹ Initial configuration of system▹ Loading data from external data source

▪ Shutdown is just the opposite end▹ Do we need to ensure that no clients are still connected before we shut it down▹ Are users currently writing data to the server? If so, then it could be corrupted▹ Force shutdown vs graceful shutdown▫ Memory that need to be returned safely to avoid corruption▫ Store configuration for next time's initialisation process (i.e., user had this tab

last opened)▫ Were all connections, databases, and files/resources closed properly?

UI Design

▸ Keep in mind:- 80% of the time is worrying about user output

▪ Information needs to be clearly and organised once rendered onscreen- 20% of the time is worrying about user input

▪ Ensure for UI feedback so user is guided - Though there are exceptions (like MS Word)

▸ Wireframing to keep it simple—this isn't a HCI unit- How to present structure on the web page?

▸ Present information to users- Can do this via reports

Design Rationale (DR)

▸ Contains:� / �42 57


- Decision objectives- Options considered- Trade-offs- Arguments that led to the decision

▸ Experience speeds up the decision process- We've made a lot of successful Obj-C iPhone Apps, so we'll make it on iOS

▸ Pros:- DR improves decision making in a team: helps negotiation between team members- DR improves learning: learn from past experience (i.e., from rationale from past)- DR improves design evaluation: ▪ helps address decisions make in design components

▪ conflicts between design decisions- DR improves maintenance

▪ Reduces the cost of fixing in future (need to know the decisions made in the past)▸ Cons:

- DR needs to have the entire team to make the decision- DR will keep discussing same issues- DR decisions or assumptions may be incorrect- DR is hard to organise and trace

▸ How?- QOC—Questions, Options, Criteria▪ What are the questions at stake? What are we deciding on?

▪ What are our various options?▪ Which criteria do we need to satisfy for a good decision?

Bugs

▸ Mistake:- Done by humans- Humans make mistakes- Machine's do not

▸ Error: - Developer has actually

written wrong code- Designer has actually designed wrong model- May not introduce a fault- An error may generate many faults

� / �43 57


▸ Fault: - Not observable—may not how up as

failures- May not generate failure- Faults in the system- A fault may generate 0 to many failures

▸ Failure: - The system has actually failed to produce

its goals- Failures are observable—the system does

not work▪ May not even be caused by error

▪ i.e., phone should make a call in <10 seconds, but doesn't! - Report a failure as a defect

▸ Defect: - Consequences of errors or faults once discovered- Once a defect is reported, it needs to be investigated- Exterminate bugs- May introduce new bugs

▸ Bug is all of the above

Why Do Bugs Exist? ▸ Misinterpretation of User's Requirements from Developer or Client▸ Misinterpretation of User's Business Logic from Developer or Client▸ Modular Design is inconsistent with requirements▸ Program Design is inconsistent with requirements▸ Tired and stressed programmers▸ Errors in data entry▸ Errors in testing verification▸ Bug fixes

Verification and Validation ▸ Validation

- Whether you have built the right product- Does it meet what the user expect? Conforms to the specification?- User-side: Users are involved in the checking process - Meets the needs of clients ▪ Use User-Acceptance Testing

� / �44 57


▸ Verification- Whether you are building the product right: Is it being built in the right way? - Developer/Process-side: Developers checking code against User's supposed

requirements - Software conforms to the

specification ▸ When do V&V?

- All the way through the SDLC - Why?

▪ Costs more later on in the stages

▸ Ways of V&V:- Dynamic V&V ▪ Execute the program

▪ Needs an executable—such as a program or program▹ Testing, debugging, profiling

- Static V&V

▪ Manual process—does not require an executable

▪ Thought process▪ Applied on documentation:▹ desk-checking (run through program in mind) walkthroughs, reviews, inspections

How to Test ▸ Testing locates bugs, even if we didn't know that they were there▸ Need a executable software system▸ Test case defines what the expected input is

- A finite number of test cases, since all possible input is impossible▸ Output results is the actual output

� / �45 57


▸ The Testing Oracle - Defines all possible test inputs and expected output - If the actual output has deviated from expected output, then it is flagged as a failure- Therefore, all tests need to satisfy the testing oracle

▸ Testing can catch:- Missing or incorrect capability- Unanticipated side affects▪ Undesirable features

- Inadequate performance, deadlocks- Poor usability- Incorrect output- Abnormality crashes

Testing Terminology ▸ Test Case

- Set of inputs with execution conditions- Expected results from the system for particular objective- Execute the system and want to see failure, so you can detect fault- Includes:

▪ 1 ) Requirement—What are we testing?

▪ 2 ) Objective—Purpose of the Test Case? e.g., test valid small input in year > 2013

▪ 3 ) Type of Test—Blackbox/Whitebox?▪ 4 ) Input

▪ 5 ) Expected Output

▪ 6 ) Actual Output

▪ 7 ) Environment—Elements needed to invoke the test: SIM Card, Cellular Network...▸ Test Criteria

- Under what conditions of observation should the test pass?- What is the criteria for the test to pass or fail?

▸ Test Design - The process of producing a suite of test cases- Develop a design using testing strategy as heuristics

▸ Test Strategy - Set of heuristics used to develop a Test Design

▸ Test Stub: Partial implementation of components where the tested component depends ▸ Test Driver: A software system used to invoke a component under test ▸ Test Harness: A system of test drivers and other tools to support test execution

� / �46 57


▸ Test Suite - Collection of related test cases▪ Allows a test of isolated tests from other tests of the system

▪ Carry out testing of a unit or package at any time- For example, subsystem tests

▸ Test Message - Code in a test driver sent to a method of the object under test- i.e., message passing between objects, specifically designed for tests

▸ Test Script - Automated tests using scripts- Scripts capture the result

▸ Fault Model - Relationships and components of the system that are most likely to have faults- Based on common sense, experience, suspicion, analysis, experiment

▸ Test Model - Extend your previous models (use case, sequence diagrams etc.)- Testable representation of the relationships among elements of an implementation- Test highlight the elements of the Implementation- Use Case Models extended for testing purposes (extend it to include more detail)

Activities in Testing ▸ Identify an artefact at each level of granularity or scope

- Functions?- Units?- Entire Packages?

▸ Specify objectives of the test- Work out what you should be doing- Work out what the most popular/common tests are for systems like this (historically)

▸ Test planning and design test cases▸ Execute all tests, capture and analyse the results▸ Regression testing

- Identify what has changed- Focus testing on changed elements- Reuse most of the test cases already from the last round of testing- New test cases will be needed for these changed elements

Test Levels ▸ Various levels of testing for granularity

� / �47 57


- Unit Testing

▪ The smallest possible units in the system—i.e., methods or module (procedural)- Integration Testing

▪ Test interaction between each of the units

▪ Collaboration of units (i.e., packages/subsystems)

▪ Detect faults between systems

▪ 3 Different Approaches:—->▪ 4th exists too: Big-Bang▹ Test everything at once▹ Not good for complex system

- System Testing

▪ Collaboration of entire system

▪ Make sure the system is fulfilling what customer asked for▪ Generated from high-level documentation (SRS)—not based on code itself

▪ Function Testing ▹ Testing overall features of the system▹ Testing functional requirements▹ Need to test invalid inputs

▪ Performance Testing ▹ Testing performance of the system▹ Testing non-functional requirements▹ Volume (lots of data) and Stress (lots of users)

- User Acceptance Testing

▪ Show clients what was built

▪ Is this what you actually wanted?

▪ Alpha testing: within d e v e l o p e r ' s organisation

▪ Beta testing: outside d e v e l o p e r ' s organisation

- Installation Testing▪ Install the system in the

user environment

� / �48 57

45

89

Test Levels and Focus Area

Test Level Core focusUnit Method, Class, ComponentIntegration Cluster, Package, Sub-SystemSystem Entire System – verification of

function & performanceAcceptance Entire system from users viewInstallation Entire system from

deployment view

90

Test Design Methods

�Tests can be designed from a functional or a structural point of view

�These three views provide for key forms of testing:�Functional Testing – Black-Box Testing

�Structural Testing – White-Box or Glass-Box Testing

�Hybrid Testing – A combination of the above two


▪ Test the final system in operation in user environment

Blackbox vs. Whitebox Testing

▸ Blackbox - Cannot see what happens inside the program—no information about interior of system- Put things into the program and see what comes out- No idea how it works inside - Compare output to specifications/functionalities - Design the test cases using component representations

▸ Whitebox - Look exactly what happens inside the source code- Testing the logic flow within the program- We see how methods work, so we can see if we can break the logic- Design the test cases using internal components

Unit Testing

� / �49 57

46

91

Black Box Testing� The software is treated as a black-box – testers are

not aware of the internals� Focus is on verifying that the system functions as

specified� Takes the end-users’ point of view� In principle can detect all bugs but would take an

infinite time to do so� Also known as responsibility based testing� Functional test design is used more at later stages of

the testing steps – Function, Acceptance, Installation

92

Black Box Testing – A common view

PROGRAM outputinput

Specifications, functionalities

Test Case Selection Strategies

compare

47

93

White Box Testing� Looks at the implementation and design of the code to

develop the test cases

� This method of testing can help in verifying that we cover all possible paths of execution through the program

� This is also known as Glass-Box Testing orImplementation Based Testing

� Structural test design techniques are applied at early testing stages – Unit and Integration

94

White Box Testing – A common view

PROGRAM

…If (a > b) Then

Do somethingElse

Do other things…

outputinput

Test Case Selection Strategies


▸ Unit Testing is usually done by a separate testing team▸ Since the development needs to be tested by people who don't know the implementation▸ Identification of units based on:

- Specifications (SRS) - Use Case, Class, Sequence Diagrams - Source Code

▸ What makes a good test?- Reasonable probability of catching

errors- Not redundant to bugs already

discovered- Best possible test for what its trying

to test- Not too simple nor too complex- Makes observation of failure obvious

Black Box Testing ▸ Strategies to develop the best test cases for black box testing:

- Equivalence Partition Testing - Boundary Testing - Sequence Testing

▸ Use Black Box Testing in par with your Specification Documents, Use Cases- i.e., Black Box tests features and makes sure it works

Equivalence Partition Testing ▸ Minimises the number of test cases

- Split all the possible input ranges into grouped, similar partitions- Rather than testing all values in the partition, choose a representative from each

partition▸ All possible inputs are partitioned into equivalence partition sets

- Identify equivalence partitions- E.g., Odd and Even number partitions - Each partition is unique- Each partition should cover all possible input range

▸ Every value in the same partition should produce the same output in the system- This is a good representation of every other data in the same range- Minimise the actual testing work▪ Each value in the partition will be the same

� / �50 57

4

Unit Test Objectives

Unit Test Objectives

Find Faults

EstablishConfidence

7

Unit Testing Process

Identify Unit

Specify Test Objectives

Plan

Design Test Cases

ExecuteTest Suite

DevelopTest Suite

ResultAnalysis

8


- One test case is selected for each partition

▪ E.g., 5 and 2 ▪ Every other number that is odd or even should be the same

▪ If I tested 8, then that is equivalent to 2 ▸ An equivalence partition requires:

- Coverage: Must cover entire input range of that particular input

▪ E.g., a range of 0 to 1000 for the isEven unit ▪ For each equivalence test, a valid and invalid input should be tested

- Disjointedness: A value in one partition is mutually exclusive to that partition only!- Representation: Modification of the partition to give a higher chance of the fault

Boundary Testing ▸ Focuses on the edge of each equivalence partition ▸ Boundary of the partition is where there is a boundary

- Why? Always higher chance at the corners of the partitions- Don't play near the cliff edge, since it's dangerous!

Issues with Testing ▸ Does not test combinations of input data▸ Cause-Effect testing addresses this problem by establishing a logical relationship between

input and outputs or inputs and transformations- Inputs = clauses- Outputs = effects- Technique assumes that input/output behaviour can be mapped to boolean function

Operation Sequence Testing ▸ Valid sequences vs invalid sequences of testing

- Valid Sequences:

▪ Simple and complex type

▪ Boundary▪ State build up

- Invalid Sequences:

▪ Upper Boundary▪ Empty

▪ Build Empty

White Box Testing ▸ Know the code▸ Know what the output will be based on the input params▸ Identifies the implementation faults

� / �51 57


▸ Path Testing- Idea is to view the program as a whir box- Base test cases based on the internals of the program

▸ Control Flow Graphs (CFG)- Visual representation of how the flow of control will go- Simplify the entire program structure and make it into a visual digram

▪ Take away unnecessary implementation details▪ We want to see looping and branching (i.e., selection statements)

- Find all possible paths and test each possible path

▪ Node is a selection block▪ Path is a path taken by control flow

▪ Paths are the different possible paths based on input data▹ Use a test case that matches EACH POSSIBLE BASIS PATH ( = region ) ▹ e - n + 2 (no edges - no nodes + 2) ▫ e = 6 (Each edge is a line…) ▫ n = 5 ▫ therefore Paths = 6 - 5 + 2 = 1 + 2 = 3 (and hence there are the 3 paths

above!)

� / �52 57


▹ Looping should be done ONCE (i.e., design tests that will loop once) ▫ i.e., BASIS path, not ALL paths (i.e. loop once… traverse each edge ONCE)

▹ For each path find one test cases

▪ Exhaustive test path▹ High complexity (case statements and do each case label)

▪ State-Based Testing▹ Base your tests on state diagrams

▸ Test effectiveness - All statements executed at least once- All loops tested- All branches tested- All inheritance tested

▸ Test results - After running for say all night, check what the output file is- Results can either be PASS or FAIL▪ Actual output is same as expected output

- Analysis of the results

▪ Classify Defects ▹ Defect Categories: Database Defects, Initialisation Defects, Algorithm Defect ▹ Must be orthogonal: a defect should only belong to one and only one category

▪ Work out which test cases are good and bad

▪ Test cases that found most bugs—i.e., effective test cases

▪ Test cases that found least bugs—i.e., noneffective test case

Software Quality

▸ SDP gets us Software Quality▸ Software Quality has different stakeholder's perspectives:

- Users judge software on its fitness for purpose (functionality) and fault frequency - Developers will judge the software based on how easily we can adapt and improve it- Operation/Help-Desk judge software on how easily it can be installed and maintain - Managers judge software based on development cost and conflicts it causes in org.

▸ Quality:- Isn't just functionality (a Mac vs. a PC are both functional though the former has quality)- What is your goal?

▪ Don't use fuzzy words; always concise wording (e.g., It should be easy = BAD)- How is your goal measured? (i.e., test cases confirm goals)

� / �53 57


- A clear goal will help us design tests - Quality should be:▪ Non-absolute

▪ Multidimensional

▪ Subject to constraints▪ About acceptance compromise▹ Factors working against each other▹ Which direction do we choose that will get best outcome?

▪ Interacting criteria▹ Criteria can overlap▹ May cause conflict

▪ Think of the different perspectives to base your argument on:▹ User View ▹ Manufacturing View ▹ Product View ▹ Value-Based View

▸ To obtain quality, need to measure- Things you can measure you can control

▪ Projects without metrics are like cars without speedometers - Managed by management- Measure attributes of entities

▪ Usually in SDLC, entity is typically entire software dev process▪ Direct—LOC, duration to execute function

▪ Indirect—productivity = LOC / person in month; req stability = initial req / total req etc ▸ Different scales to measure

- Nominal

▪ Stats into mutually exclusive categories: Languages: Obj-C, C++, C#, PHP

▪ No rankings between categories (don't compare them)- Ordinal

▪ Similar to nominal scale but comparable categories

▪ Non-fixed separation▪ Minor Error, Marginal Error, Major Error, Catastrophic Error

- Interval

▪ Fixed separation between values▪ Normal statistics permitted; work out sum, mean etc.

▪ Final Marks in SDP: HD (80), D (70), C (60), P (50) - Ratio

� / �54 57


▪ Permits scaling

▪ Requirement Stability (%) = Initial Requirements / Total Requirements - Absolute

▪ Counting the number of elements in the entity set

▪ Number of Developers ▸ Objective vs. Subjective data

- Objective data is not opinionated (unlike Subjective Data)- Objective data is consistent

▸ In summary:- Customers pay for quality functionality- To ensure quality, we need control- To maintain control, we test our requirements and code- Quality has to be engineered into a product intentionally- We measure quality attributes to maintain control

Summary▸ Stages in SDLC

- Requirements ▪ Focus on the pain points!

▪ What is the business value?▪ What constraints are we working with?

▪ What is the context?

▪ Are requirements consistent, complete, reasonable, realisable?- Analysis

▪ Understand what do we want to do▹ Cover what the problems are in the existing problem space▹ DO NOT DISCUSS THE SOLUTION

▪ Build models to help us understand▹ Domain model ▹ Use cases

▪ Communicate our thoughts to ensure we understand correctly▹ Show you domain model to the client!

- Design

▪ Start making decisions of the final product▹ Architecture: Structural and technical choices▹ Detailed Design: Compositional and building choices

� / �55 57


▪ Use the domain model and use cases to help you build the design/make decisions▹ Base sequence diagrams, class diagrams etc. on these!

▪ Coding is a design activity▪ Verify as we make choices

- Implementation

▪ Critical requirements needed before coding begins▹ Production definition ▹ Solution outline

▪ Cutting code too soon will lead to reanalysis, decision-making, selection- Testing

▪ Unit Tests should happen as we code

▪ Comprehensive testing should happen towards the end▪ Quality Assurance is there to tell you everything is OK▹ Where QA fails, it's too late—QA is past the point of no return

▪ Testing is an activity that:▹ outlines the defects▹ increase confidence that system works as should

▸ Communication is imperative - Clarify, sell, justify decisions need communication!- Will fail otherwise!- Use Documentation

▪ Who reads them?

▪ How often will it be read?▪ People should actually read them! Other waste of time!

▸ Quality Goals - Quality is often subjective, but some can be objective- Functionality is objective, test for correctiveness!

▸ Iterative Development - Work depending on the current phase and context- Produce chunks of the project- Habits- Comms

� / �56 57


Closing Thoughts ▸ Understand the problem and the domain first ▸ Ensure that gaps are spiked out ▸ Analysing = Understanding ▸ Designing = Decision making ▸ Quality requirements drive the architecture ▸ Programming is a small aspect in software development

- Without this skill the rest are not easy to do ▸ Testing is important - allocate sufficient resources to this task ▸ Habits are strong - use history to help plan for the future

� / �57 57