Download pdf - SOEN 6461-1-intro_W2014

1

SOEN 6461 Software Design Methodologies:

Introduction

2

Course Orientation

Course Logistics

Prof: Dr. Nora Houari

Office: EV3.301

Email: [email protected]

Office hours: Tuesdays 17:00-18:00, and by appointment

Theory, here with me (H411) Mondays: 17:45-20:15

Programmer-On-duty hours:TBA, room TBA

What this course about?

A (deep) look at OO design

Software architecture: where global decision are made

Design process: domain model, use cases design

Emphasis: model, architectural patterns, GRASP principles, design patterns, responsibility, collaboration

4

Give you in depth appreciation of S/W design

Elevate you skills beyond coding

Make sure you will not be offshored

Demand for software designers/architects is high and of course for big paycheck

Understand the value of good design and apply it in the software systems you build

Why take this course?

What the course is not?

Not a course in UML, Java You should know the basics of these

And become expert (as needed) yourself

Not a course in tools: Eclipse, Visual studio You can work through tutorials yourself

Not a course in UI, DB design, Games

Not a course in software engineering, software management, software testing, software reuse,

6

Most of our courses are taught using the Java programming language for many reasons!

SOEN 6461 course: examples and exams code using java

This course aims at teaching software design methodologies to an audience well-trained in computer programming and putting the newly acquired knowledge into practice through a challenging project

Project: you are free to use any OO language-as long as your team member are comfortable with that!

Rationale

Topic Coverage

Software Design Methodologies Overview

Domain Modeling

Design Objects with Responsibilities

Software Architecture: Views and Styles

Design Patterns

Software Architecture Analysis and Documentation

Anti-patterns

Refactoring

GoF Patterns

Service Oriented Architecture

Recommended References

Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd., Prentice Hall

And many other resources listed each week and made available via Moodle

Advice

Keep up as material is cumulative

study the practice examples in the lectures and the PODs practice examples/exercises and play with them

Study in groups

Evaluation

Four components of evaluation:

3 Assignments and 3 Quizzes 15%

Midterm exam 20%

Project (team of 5 members) 25%

Final exam 40%

Some thoughts This course requires a fair amount of time

commitments!

Lectures: weekly/papers reading/ assignments/3 Quizzes/Midterm/Final

Do not take it if you cannot spare the time

Software design is part science and part art

You need to be steeped in to appreciate it

Some things you can only learn from experience ( team project)

Intellectually rich and rewarding experience

Project individual teams having 5 members

Must work in groups in the real world

The completion of the project is divided into two separate builds

teams presentation in class for each build

Communicate with colleagues (team members)

Communication problems are natural!

What have you done?

You must document your work!

Everyone must keep an on-line notebook/Forum

Communicate with me

How is the teams plan/progress is going?

Short progress reports/meetings are required:

What is each members responsibility?

Peer evaluation

Project

To do from now on. Sign up for this class on Moodle

Monitor the Moodle for course content and announcement

Start thinking about project teams (5 members) right away..

You need to pick up your team by Jan 19th at the latest

Structure how to work/communicate and have fun!

Decide if you are willing and able to handle the workload.

15

Things You Already Know(aka cheating)

It is an academic offence to give someone your work

It is an academic offence to claim someone else's work as your own

When it happens in industry, people are fired, sued, or sent to jail!

Thank you and welcome aboard

17

Software Design Methodologies: Overview

Text book: chap. 1 and 2

18

Today Important questions

1. What are software engineering difficulties?

2. What is an agile process?

3. What are the different existing agile processes?Pitfalls/Challenges?

4. What do we do in Software Design Methodologies?

The Unified Process (UP)

Iterative Development

Comments on Iterative Development and the UP

19

The Origins

Software Engineers have always employed software architectures Very often without realizing it!

Address issues identified by researchers and practitioners Essential software engineering difficulties Unique characteristics of programming-in-the-large Need for software reuse

Many ideas originated in other (non-computing) domains

20




3. What are the different existing agile processes? Their Pitfalls/Challenges?





21

Software Engineering Difficulties Software engineers deal with unique set of problems

(Relatively)Young field with tremendous expectations

Building of vastly complex, but intangible systems Software is not useful on its own e.g., unlike a car,

thus It must conform to changes in other engineering

areas Some problems can be eliminated

These are Brooks accidental difficulties Other problems can be lessened, but not eliminated

These are Brooks essential difficulties

No Silver Bullet; Essence and Accidents of Software Engineering, Fred Brooks , 1986

22

Accidental Difficulties

Solutions exist Possibly waiting to be discovered

Past productivity increases result of overcoming Inadequate programming constructs &

abstractions Remedied by high-level programming languages

Increased productivity by factor of five

Complexity was never inherent in program at all

23

Accidental Difficulties (contd)

Past productivity increases result of overcoming (contd) Difficulty of using heterogeneous programs

Addressed by integrated software development environments

Support task that was conceptually always possible

24

Essential Difficulties

Only partial solutions exist for them, if any

Cannot be abstracted away

Complexity

Conformity

Changeability

Intangibility

25

Complexity

No two software parts are alike If they are, they are abstracted away into one

Complexity grows non-linearly with size E.g., it is impossible to enumerate all states of

program

Except perhaps toy programs

26

Conformity

Software is required to conform to its Operating environment

Hardware

Often last kid on block

Perceived as most conformable

27

Changeability

Change originates with New applications, users, machines, standards,

laws

Hardware problems

Software is viewed as infinitely malleable

28

Intangibility

Software is not embedded in space Often no constraining physical laws

No obvious representation E.g., familiar geometric shapes

29

Primacy of Design

Software engineers collect requirements, code, test, integrate, configure, etc.

An architecture-centric approach to software engineering places an emphasis on design Design pervades the engineering activity from

the very beginning

But how do we go about the task of architectural design?

30




3. What are the different existing agile processes?Pitfalls/Challenges?





Agile Processes

Development processes that address the problem of volatile requirements: requirements that change due to rapidly changing technology

or market, requirements that are difficult to define in advance because

of the exploratory nature of the development.

They cope with change in the following ways: 1. they employ short iteration cycles, which permit incremental

delivery and rapid feedback for project management purposes

2. they generally have low documentation overheads 3. they encourage an inclusive relationship with the customer,

often with flexible contract arrangements

Exemplar Agile Processes

Extreme Programming (XP)

based on Test-Driven Development (TDD).

Feature-Driven Development (FDD)

integrates ideas from plan-driven processes, too.

SCRUM

Crystal family

Agile Modelling

Dynamic Systems Development Method (DSDM)

33

Agile Project Management Features(1/5) Agile Development :The manifesto for agile software

development has revolutionized the way companies plan, develop, test and release software. Throwing away years of accumulated orthodoxy, agile development methods have now become the accepted way to develop software.

Scrum :One of the most popular agile methodologies in use today. Scrum is a lightweight software development methodology that focuses on having small time-boxed sprints of new functionality that are incorporated into an integrated product baseline. Scrum places an emphasis on customer interaction, feedback and adjustments rather than documentation and prediction.

34

Agile Project Management Features(2/5) Extreme Programming (XP) is a set of software

development principles that were designed to reduce waste and better cope with changing requirements during the software development lifecycle. XP focuses primarily on engineering techniques and approaches rather than project management.

Spiral / Iterative The spiral/iterative model of development was one of the first approaches to challenge the orthodoxy of waterfall software development. It is based around having an initial prototype that is subsequently refined in each new spiral of functionality that is added to the initial prototype

35

Agile Project Management Features(3/5)

Agile Unified Process (AUP) The Agile Unified Process (AUP) grew up out of the Rational Unified Process (RUP). Both RUP and AUP specify that the various activities of the software development lifecycle occur in parallel during the lifecycle rather than solely in specific phases.

Dynamic Systems Development Method The Dynamic Systems Development Method (DSDM) is a well-defined agile methodology managed by the DSDM Consortium that provides a project delivery framework that aids the development and delivery of business solutions to tight timescales and fixed budgets.

36


Kanban / Lean: Lean development practices are based on the lean methodologies that have been used successfully in manufacturing processes. Kanban is a lean software development methodology that focuses on just-in-time delivery of functionality and managing the amount of work in progress (WIP)

Rapid Application Development (RAD) approaches allowing developers to rapidly create functioning prototypes during the requirements gathering process to validate assumptions and provide initial feedback.

37


Test-Driven Development (TDD) :a practice espoused by XP whereby the unit and acceptance tests become an upfront part of the requirements definition and validation process. The tests are written prior to development and the design is the minimum necessary for the test to pass.

Feature-Driven Development (FDD) :Feature-Driven Development (FDD) is an agile methodology that blends a number of industry-recognized best practices into a cohesive whole. The unifying theme of the methodology is that all activities are organized around client-valued functionality (features).

Classification of Agile Processes

Agile processes possess the following main characteristics: incremental, focusing on delivering small

releases;

cooperative, where the customer is embedded in the team;

straightforward, where the processes are easy to learn and sufficiently (and accurately) documented;

adaptive, welcoming changes, even late in the lifecycle.

39









Problems and Pitfalls/Challenges

Wide skepticism at the moment: XP claimed to be suitable for projects in the low criticality

band, but this view is not widely shared.

The lack of process fits badly with current standards. Though there are views that CMMI etc are to a point

compatible with XP practices.

Criticisms about effectiveness of project management in agile processes. Hard to extract data; data is of less value as it is much more

difficult to extrapolate.

Unsuitable for long-lived projects. No documentation, reuse is difficult.

Problems and Pitfalls Customer participation

Theres no single, clear role for customers in some systems; no one customer can know everything (aerodynamics, materials, structure, propulsion ...)

Also, independence may be an issue for safety Without a customer, management of the agile process will be

hard.

Scaling issues We need new means of enabling communication (or need to

adapt the means we use already). How do we manage 300 people? Sub-teams of domain

experts?

Testing White box testing is often ignored. Also acceptance testing for some safety critical systems is

usually expensive, and in some cases one-off.

Problems and Pitfalls

Simple design may be incompatible with the naturally long life of many systems.

Incremental development: Agile proposes deprecating low priority

requirements; critical systems normally have large numbers of inflexible requirements of high priority.

Can a safe but incomplete design be incrementally certified?

43









44

What do we do in Software Design Methodologies?

Think in Objects

Analyze requirements with use cases

Create domain models

Apply an iterative & agile Unified Process (UP)

Relate analysis and design artifacts

Read & write high-frequency UML

Practice Apply agile modeling

Design object solutions

Assign responsibilities to objects

Design collaborations

Design with patterns

Design with architectural layers

Understand OOP (e.g., Java) mapping issues

45

UML: Whats Important?

Harmful is knowing

how to read and

draw UML diagrams,

but not being an

expert in design and

patterns.

Important is object and

architectural design skills, not

UML diagrams, drawing, or

CASE tools.

46

UML: Whats Important?

47

UML vs. Thinking in Objects Unified Modeling Language (UML)

Just a diagramming notation standard. Trivial and relatively unimportant.

Not a method, process, or design guide.

InterfaceX

Abstract

ClassX

...

interface

InterfaceX

operation1()

ClassA ClassBAssociation-name

role-1 role-2

1 1

zero or

more;

"many"

one or

more

one to

forty

exactly

fiveClass ClassClass Class* 1..*

1..40 5

Whole

Part

1

*

AssociationClass

Composition

Multiplicity:

Associations:

ClassX

classAttribute

+ publicAttribute

- privateAttribute

attributeWithVisibilityUnspecified

attribute1 : type

burgers : List of VeggieBurger

attribute2 : type = initial value

finalConstantAttribute : int = 5 { frozen }

/derivedAttribute

classMethod()

+ constructor ClassX(int)

signal CaughtException1()

methodWithVisibilityUnspecified()

methodReturnsSomething() : Foo

abstractMethod()

abstractMethod2() { abstract } // alternate

+ publicMethod()

- privateMethod()

# protectedMethod()

~ packageVisibleMethod()

finalMethod() { leaf }

methodWithoutSideEffects() { query }

synchronizedMethod() { guarded }

exceptions

ThrownException1

AlternateUMLFor

AbstractClass

{abstract}

...

ClassY

operation1()

...

generalizationinterface

implementation

AlternateUMLFor

ImplOfInterfaceX

operation1()

FinalClass

{leaf}

...

48

The Need for Software Blueprints

Knowing an object-oriented language and having access to a library is necessary but not sufficient in order to create object software.

In between a nice idea and a working software, there is much more than programming.

Analysis and design provide software blueprints, illustrated by a modeling language, like the Unified Modeling Language (UML).

Blueprints serve as a tool for thought and as a form of communication with others.

OOD: Principles and Patterns Priority

1. Assign responsibilities to objects

The GRASP patterns are the key learning aid

After that. . . ?

50

Object-Oriented Analysis

An investigation of the problem (rather than how a solution is defined)

During OO analysis, there is an emphasis on finding and describing the objects (or concepts) in the problem domain. For example, concepts in a Library Information

System include Book, and Library.

51

Object-Oriented Design Emphasizes a conceptual solution that

fulfils the requirements. Need to define software objects and how

they collaborate to fulfil the requirements. For example, in the Library Information

System, a Book software object may have a title attribute and a getChapter method.

Designs are implemented in a programming language. In the example, we will have a Book class in

Java.

52

From Design to Implementation

Book

title

print()

public class Book {

public void print();

private String title;

}

Book

(concept)

Analysis

investigation

of the problem

Design

logical solution

Construction

code

Domain concept Representation in

analysis of concepts

Representation in an

object-oriented

programming language.

53









54


A process is a set of partially ordered steps intended to reach a goal.

In Software Engineering, the goal is to efficiently and predictably deliver a software product that meets the needs of your business.

A software development process is an approach to building, deploying and maintaining software.

The Unified Process (UP) is a process for building object-oriented systems.

The goal of the UP is to enable the production of high quality software that meets users needs within predictable schedules and budgets.

55


For simple systems, it might be feasible to sequentially define the whole problem, design the entire solution, build the software, and then test the product.

For complex and sophisticated systems, this linear approach is not realistic.

The UP promotes iterative development:The life of a system stretches over a series of cycles, each resulting in a product release.

56

Old days: Waterfall Model

57









58


Development is organized into a series of short fixed-length mini-projects called iterations.

The outcome of each iteration is a tested, integrated and executable system.

An iteration represents a complete development cycle: it includes its own treatment of requirements, analysis, design, implementation and testing activities.

59


The iterative lifecycle is based on the successive enlargement and refinement of a system though multiple iterations with feedback and adaptation.

The system grows incrementally over time, iteration by iteration.

The system may not be eligible for production deployment until after many iterations.

60

Iterative Development (1/2)

[iteration N]

Requirements Analysis - Design- Implementation - Testing

[iteration N+1]

Requirements Analysis - Design- Implementation - Testing

Feedback from iteration N leads to

refinement and adaptation of the

requirements and design in iteration

N+1.

The system grows

incrementally.

Iterative Development (2/2)

Requirements

Design

Implementation &

Test & Integration

& More Design

Final Integration

& System Test

Requirements

Design

3 weeks (for example)

The system grows

incrementally.

Feedback from

iteration N leads to

refinement and

adaptation of the

requirements and

design in iteration

N+1.

Iterations are fixed in

length, or timeboxed.

Time

Implementation &

Test & Integration

& More Design

Final Integration

& System Test

62


The output of an iteration is not an experimental prototype but a production subset of the final system.

Each iteration tackles new requirements and incrementally extends the system.

An iteration may occasionally revisit existing software and improve it.

63

Embracing Change

Stakeholders usually have changing requirements.

Each iteration involves choosing a small subset of the requirements and quickly design, implement and testing them.

This leads to rapid feedback, and an opportunity to modify or adapt understanding of the requirements or design.

64

Iteration Length and Timeboxing

The UP recommends short iteration lengths to allow for rapid feedback and adaptation.

Long iterations increase project risk. Iterations are fixed in length (timeboxed).If

meeting deadline seems to be difficult, then remove tasks or requirements from the iteration and include them in a future iteration.

The UP recommends that an iteration should be between two and six weeks in duration.

65

Phases of the Unified Process Inception Elaboration Construction Transition

A UP project organizes the work and iterations

across four major phases:

Inception - Define the scope of project.

Elaboration - Plan project, specify features,

baseline architecture.

Construction - Build the product

Transition - Transition the product into end

user community

time

66

Iterations and Milestones

Each phase and iteration has some risk mitigation focus, and concludes with a well-defined milestone.

The milestone review provides a point in time to assess how well key goals have been met and whether the project needs to be restructured in any way to proceed.

The end of each iteration is a minor release, a stable executable subset of the final product.

Preliminary

Iteration

Iter. #1 Iter. #2

Inception Elaboration Construction Transition

Milestone Release Final production

release

67

The UP Disciplines

Management

Environment

Business Modeling

Implementation

Test

Analysis & Design

Preliminary Iteration(s)

Iter. #1

Phases

Process Disciplines

Iterations

Iter. #2

Iter. #n

Iter. #n+1

Iter. #n+2

Iter. #m

Iter. #m+1

Deployment

Configuration Mgmt

Requirements

Elaboration Transition Inception Construction

Supporting Disciplines

68

The UP Disciplines

Management

Environment

Business Modeling

Implementation

Test

Analysis & Design


Iter. #1

Phases

Process Disciplines

Iterations

Iter. #2

Iter. #n

Iter. #n+1

Iter. #n+2

Iter. #m

Iter. #m+1

Deployment

Configuration Mgmt

Requirements



In an iteration you

walk through all

disciplines.

69

The UP Disciplines

Management

Environment

Business Modeling

Implementation

Test

Analysis & Design


Iter. #1

Phases

Process Disciplines

Iterations

Iter. #2

Iter. #n

Iter. #n+1

Iter. #n+2

Iter. #m

Iter. #m+1

Deployment

Configuration Mgmt

Requirements



Focus of this

course.

70

Disciplines and Phases

Although an iteration includes work in most disciplines, the relative effort and emphasis change over time. Early iterations tend to apply greater emphasis to

requirements and design, and later ones less so. Figure illustrations are suggestive, not literal.

Note that activities and artifacts are optional (except code!) Developers select those artifacts that address their

particular needs.

71

Advantages of an Iterative Process

Reduce risks Risks are identified early, progress is easier to see.

Get a robust architecture Architecture can be assessed and improve early.

Handle evolving requirements Users provide feedback to operational systems. Responding to feedback is an incremental change.

Allow for changes System can adapt to problems

Attain early learning Everyone obtains an understanding of the different

workflows early on.

Scenario(1/3)

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5

20%

2%

requ

irem

ents

softw

are

30%

5%

requ

irem

ents

softw

are

50%

8%

90% 90%

20%10%

requirements workshops

Imagine this will

ultimately be a 20-

iteration project.

In evolutionary iterative

development, the

requirements evolve

over a set of the early

iterations, through a

series of requirements

workshops (for

example). Perhaps

after four iterations and

workshops, 90% of the

requirements are

defined and refined.

Nevertheless, only

10% of the software is

built.

1 2 3 4 5 ... 20

week 1

M T W Th F

week 2

M T W Th F

week 3

M T W Th F

kickoff meeting

clarifying iteration

goals with the team.

1 hour

team agile

modeling &

design,

UML

whiteboard

sketching.

5 hours

start

coding &

testing

a 3-week iteration

de-scope

iteration

goals if

too much

work

final check-in

and code-

freeze for the

iteration

baseline

demo and

2-day

requirements

workshop

next

iteration

planning

meeting;

2 hours

Most OOA/D and

applying UML during

this period

Use-case modeling

during the workshop

Scenario(2/3)

inc. elaboration construction transition

iteration phase

development cycle

release

A stable executable

subset of the final

product. The end of

each iteration is a

minor release.

increment

The difference

(delta) between the

releases of 2

subsequent

iterations.

final production

release

At this point, the

system is released

for production use.

milestone

An iteration end-

point when some

significant decision

or evaluation occurs.

Sample

UP Disciplines

Business

Modeling

Requirements

Design

Implementation

...

The relative effort in

disciplines shifts

across the phases.

This example is

suggestive, not literal.

incep-

tionelaboration construction

transi-

tion

...

Scenario(3/3)

The NextGent POS System (1/2)

A POS system computerized application used to record sales and handle payments typically used in retail stores.

POS includes:

Hardware components(computer and bar code scanner

Software

POS interfaces to various service application (e.i. Tax calculator and inventory control)

POS system supports multiple client-side terminals and interfaces

POS a commercial system for different clients with disparate needs in terms of business rule processing: flexibility and customization

76

Case Study Focus

Many systems can be divided into 3 layers

User interface

Business logic (application)

Integration (DB & other systems)

Focus is on business layer because

Its design is less technology dependent

OOAD skills can be applied to other layers

More likely to have stable design

The NextGen POS System (2/2)

User Interface

Sale Payment

Logging ... Database Access ...

application

logic layer

other layers or

components

minor focus

explore how to connect to

other layers

primary focus

of case studies

explore how to

design objects

secondary

focus

Iteration 1

Iteration 2

Iteration 3

Introduces just those

analysis and design

skills related to

iteration one.

Additional analysis and

design skills introduced.Likewise.

SOEN6461: Learning path through iterations

Inception

(req. Analysis)

OOA/D and responsibilities' assignment to objects

Object design,

Design Patterns Architectural analysis, framework design

79









80


81

Additional UP Best Practices and Concepts The central idea behind the UP is short

timeboxed iterative, adaptive development.

Tackle high-risk and high-value issues in early iterations. Leave easier work in later iterations.

This way the project does not fail late

Better to fail early if at all.

82

Additional UP Best Practices and Concepts Continuously engage users.

Development involves taking small steps and getting feedback.

The majority of failed projects are correlated with lack of user engagement [Standish, 1994]

Early iterations focus on core architecture.

Continuously verify quality. No big surprises near the end of the project.

83

Additional UP Best Practices and Concepts Apply Use Cases.

Use Cases explore and record functional requirements. Capture requirements, used for design, testing and

writing end-user documentation.

UML supports abstract (and visual) models of software.

Carefully manage requirements. Poor requirements management is a common factor on

troubled projects [Standish, 1994]

Control changes. UP embraces change, not chaos.

84

The Construction and Transition Phases During Elaboration most requirements

are understood. Elaboration builds the risky and architecturally

significant core of the system.

Construction builds the remainder. Development proceeds through a series of

timeboxed iterations.

Testing during Construction is referred to as alpha testing.

85

The Construction and Transition Phases Construction ends when the system is

ready for operational deployment and all supporting materials are complete (user guides, training material etc.)

The purpose of Transition phase is to put the system into production use. Testing during Transition is referred to as

beta testing

86

Motivations for Timeboxing an Iteration Development team has to focus to produce

a tested executable partial system on-time.

Timeboxing forces developers to prioritize work and risks, as well as identify tasks of high business and high technical value.

Complete mini projects build team confidence and stakeholder confidence.

87

The Sequential Waterfall Lifecycle Clarify, record and commit to a set of final

requirements.

Design a system based on these requirements.

Implement based on design.

Integrate different modules.

Evaluate and test for correctness and quality.

88

Some Problems with the Waterfall Lifecycle Tackling high-risk or difficult problems late.

In a waterfall lifecycle there is no attempt to identify and tackle riskiest issues first.

In an iterative development (like the UP) early iterations focus on driving down the risk.

Requirements speculation and inflexibility. The waterfall process assumes that requirements can

be fully specified and then frozen in the first phase of the project. Stakeholders want to see something concrete very early. Market changes.

In iterative development requirements tend to stabilize after several iterations.

89

Some Problems with the Waterfall Lifecycle Design speculation and inflexibility.

The waterfall lifecycle dictates that the architecture should be fully specified once the requirements are clarified and before implementation begins. Since requirements usually change, the original

design will not be reliable.

Lack of feedback on design until long after design decisions are made.

90

Succeeding with Agile

Agile Succeeds Three Times More Often Than Waterfall

91







