Daniel Amyot University of Ottawa 200 7

«CSI5112»

D. AmyotU. Ottawa

CSI 5112CSI 5112

Review of Software EngineeringReview of Software Engineering

Daniel AmyotUniversity of Ottawa

2007

Review of Software Engineering 2

«CSI5112»

D. AmyotU. Ottawa

A Few Bugs from the Past 25 Years… [http://www.wired.com/news/technology/bugs/0,2924,69355,00.html and other sources]

1982 — Soviet gas pipeline. Operatives working for the CIA allegedly plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline. The resulting event is reportedly the largest non-nuclear explosion in the planet’s history.1985-1987 — Therac-25 medical accelerator. A Canadian radiation therapy device malfunctions and delivers lethal radiation doses at several medical facilities.1988-1996 — Kerberos Random Number Generator. The authors of the Kerberos security system neglect to properly “seed” the program’s random number generator with a truly random seed.1990 — AT&T Network Outage. A bug in a new release of the software that controls AT&T’s #4ESS long distance switches causes these mammoth computers to crash.1993 — Intel Pentium floating point divide. A silicon error causes Intel’s highly promoted Pentium chip to make mistakes when dividing floating-point numbers that occur within a specific range.1995-1996 — The Ping of Death. A lack of sanity checks and error handling in the IP fragmentation reassembly code makes it possible to crash a wide variety of operating systems by sending a malformed “ping” packet from anywhere on the internet.1996 — Ariane 5 Flight 501. Working code for the Ariane 4 rocket is reused in the Ariane 5, but the Ariane 5’s faster engines trigger a bug in an arithmetic routine inside the rocket’s flight computer.1995-2000 — Year 2000 Problem (Y2K). Two digits for representing a year ain’t enough 2000 — National Cancer Institute, Panama City. In a series of accidents, therapy planning software created by Multidata Systems International, a U.S. firm, miscalculates the proper dosage of radiation for patients undergoing radiation therapy.2003 — North America blackout triggered by a local outage that went undetected due to a in General Electric Energy's XA/21 monitoring software.


«CSI5112»

D. AmyotU. Ottawa

RISK Stories by Peter G. Neumann

Illustrative Risks to the Public in the Use of Computer Systems and Related Technology

— http://www.csl.sri.com/users/neumann/illustrativerisks.html

Digest— http://catless.ncl.ac.uk/Risks/

Software Horror Stories— http://www.cs.tau.ac.il/~nachumd/verify/horror.html


«CSI5112»

D. AmyotU. Ottawa

Review

The review will be done in four parts. This information is meant to refresh your memory (many of these concepts should be known by now) and to motivate several aspects of the course.

1. Software and Software Engineering

2. Modelling, and Dealing with Complexity

3. Modelling with UML 1.x

4. Essential Java Features

«CSI5112»

D. AmyotU. Ottawa

Part I:Software and Software Engineering

Review, CSI 5112(Based on Lethbridge and Laganière)


«CSI5112»

D. AmyotU. Ottawa

Objective

Provide elements of answers to several important questions:

• What is software?

• What is software engineering?

• What does quality mean in that context?

• What kind of software projects exist?

• What about software project management and process models?


«CSI5112»

D. AmyotU. Ottawa

Why Software Engineering?

• To address real needs of users, in a profitable way

• To ensure quality

• To ensure security (of systems, information, people)

• To develop large, complex systems… and small ones

• To reduce development time

• To manage risks

• To select appropriate alternatives

• To support system evolution

• To consider human aspects

• … much more than just programming


«CSI5112»

D. AmyotU. Ottawa

The Nature of Software...

Software is intangible

• Hard to understand development effort

Software is easy to reproduce

• Cost is in its development

—Often, in other engineering products, manufacturing is the costly stage

The industry is labor-intensive

• Hard to automate


«CSI5112»

D. AmyotU. Ottawa

The Nature of Software ...

Untrained people can hack something together

• Quality problems are hard to notice

Software is easy to modify

• People make changes without fully understanding it

Software does not ‘wear out’

• It deteriorates by having its design changed:

— erroneously, or

— in ways that were not anticipated, thus making it complex


«CSI5112»

D. AmyotU. Ottawa

The Nature of Software

Observations

• Much software has poor design and is getting worse

• Demand for software is high and rising

• We are in a perpetual ‘software crisis’

— Very few projects actually deliver working software, on time

• We have to learn to ‘engineer’ software


«CSI5112»

D. AmyotU. Ottawa

Types of Software...

Custom

• For a specific customer

• Few copies in circulation

Generic

• Sold on open market

• Often called

— COTS

— Shrink-wrapped

Embedded

• Built into hardware

• Tons of copies in circulation

• Hard to change

Real time software

• Control and monitoring systems

• Must react immediately

• Safety often a concern

Data processing software

• Used to run businesses

• Accuracy and security of data are key

Many other aspects exist, and most software integrate many aspects at different levels.


«CSI5112»

D. AmyotU. Ottawa

What is Software Engineering?...

The process of solving customers’ problems by the systematic development and evolution of large, high-quality software systems within cost, time and other constraints

… Solving customers’ problems• This is the goal of software engineering• Sometimes the solution is to buy, not build• Adding unnecessary features does not help solve the

problem• Software engineers must communicate effectively to

identify and understand the problem


«CSI5112»

D. AmyotU. Ottawa

What is Software Engineering?…

… Systematic development and evolution• An engineering process involves applying well understood

techniques in a organized and disciplined way• Many well-accepted practices have been formally standardized

— e.g. by the IEEE or ISO • Most development work is evolution

… Large, high quality software systems• Software engineering techniques are needed because large systems

cannot be completely understood by one person• Teamwork and co-ordination are required• Key challenge: Dividing up the work and ensuring that the parts of

the system work properly together• The end-product that is produced must be of sufficient quality


«CSI5112»

D. AmyotU. Ottawa

What is Software Engineering?

… Cost, time and other constraints

• Finite resources

• The benefit must outweigh the cost

• Others are competing to do the job cheaper and faster

• Inaccurate estimates of cost and time have caused many project failures

“Software and Cathedrals are much the same: First we build them, then we pray!!!”

-Sam Redwine, Jr.


«CSI5112»

D. AmyotU. Ottawa

Software Engineering: a Profession

The term Software Engineering was coined in 1968

• People began to realize that the principles of engineering should be applied to software development

Engineering is a licensed profession

• In order to protect the public

• Engineers design artefacts following well accepted practices which involve the application of science, mathematics and economics

• Ethical practice is also a key tenet of the profession

• Examples: PEO (Ontario), OIQ (Québec)


«CSI5112»

D. AmyotU. Ottawa

Software Engineering Code of Ethics and Professional Practice, 5.2 (ACM/IEEE-CS)

• Complete version: http://seeri.etsu.edu/Codes/TheSECode.htm

• Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:


«CSI5112»

D. AmyotU. Ottawa

Software Engineering Code of Ethics and Professional Practice, 5.2 (ACM/IEEE-CS)

1. PUBLIC - Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest.

3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.

8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.


«CSI5112»

D. AmyotU. Ottawa

Typical Stakeholders in Software Engineering

1. Users

• Those who use the software

2. Customers

• Those who pay for the software

3. Software developers and maintainers

4. Development Managers

5. Salesmen/Distributors

Many other types of stakeholders could be discussed. Note that many roles can be fulfilled by the same person!


«CSI5112»

D. AmyotU. Ottawa

Software Quality...

Usability

• Users can learn it and fast and get their job done easily

Efficiency

• It doesn’t waste resources such as CPU time and memory

Reliability

• It does what it is required to do without failing

Maintainability

• It can be easily changed

Reusability

• Its parts can be used in other projects, so reprogramming is not needed

… and many other -ities


«CSI5112»

D. AmyotU. Ottawa

Software Quality...

Q uality

A dded-V a lue

Supplier

O ptions

Supple-m enta l

com p la in t p rocedu res

qua lity assu rancepe rsona lised se rv ice

repu ta tionsuppo rt se rv ices

paym en t op tionsop tion cho ices

spec ia l o ffe rs

p resen ta tionquan tity

cove rage

upda ting

ins truc tions / m anua ls

ve rsa tility

conven ience

w e igh t

spa re pa rts / a lte rna tives

com pa tib ility

s ize

T im e

F inancia l

Tem pora lde live ry tim e

m a in tenance

evo lvab ility

upda ting

cu rrency

C ost

F inancia l

Tem pora l

e lapsed tim e

deve lopm en t tim e

re trieva l / response tim e

ava ilab ility

Incom ing

O utgoing

tax

g ross

ne t

de live ry cos t

m a in tenance

spare pa rts

p rice

deve lopm en t cos ts

g rossne t

U tility

S u itab ility

V eracity

T im eg race fu l deg rada tion

cu rrency

upda ting

evo lvab ility

accu racy

re liab ilityob jec tiv ity

com p le teness

fit fo r in tended use

techn ica l leve l

re levance

accu racy

access ib ilityease o f use

cons is tency

cons is tency

e ffic iency

e ffic iency

e ffic iency

sa fe ty

aes the tics

deve lopm en t cos ts

g race fu l deg rada tionre trieva l / response tim e

du rab ility

fea tu res

pe rfo rm ance

tim e liness

p ro fit

in te roperab ility

in teg rity

secu rity

con fiden tia lity

usab ility

U sability

Perform ance

Standards

F itness

re liab ility

qua lity assu ranceindus try s tanda rds

e ffec tiveness

m a in ta inab ility

deprec ia tion

sa tis fac tion

[http://www.cs.cf.ac.uk/user/M.Burgess/phd/index.html]

An example ontology…


«CSI5112»

D. AmyotU. Ottawa

Software Quality: What is at Stake?

QUALITY SOFTWARE

Developer:easy to design; easy to maintain; easy to reuse its parts

User: easy to learn; efficient to use; helps get work done

Customer: solves problems at an acceptable cost in terms of money paid and resources used

Development manager: sells more and pleases customers while costing less to develop and maintain

Salesman/Distributor: simple packaging; customization; warranty and updates; benefit margins


«CSI5112»

D. AmyotU. Ottawa

Software Quality

The different qualities can conflict• Increasing efficiency can reduce maintainability or

reusability• Increasing usability can reduce efficiency

Setting objectives for quality is a key engineering activity

• You then design to meet the objectives• Avoids ‘over-engineering’ which wastes money

Optimizing is also sometimes necessary• E.g. obtain the highest possible reliability using a fixed

budget


«CSI5112»

D. AmyotU. Ottawa

Software Engineering Projects

Most projects are evolutionary or maintenance projects, involving work on legacy systems

• Corrective projects: fixing defects

• Adaptive projects: changing the system in response to changes in

—Operating system

—Database

—Rules and regulations

• Enhancement projects: adding new features for users

• Reengineering or perfective projects: changing the system internally so it is more maintainable


«CSI5112»

D. AmyotU. Ottawa


‘Green field’ projects• New development• The minority of projects


«CSI5112»

D. AmyotU. Ottawa


Projects that involve building on a framework or a set of existing components.

• The framework is an application that is missing some important details.

— E.g. Specific rules of organization, business logic...• Such projects:

— Involve plugging together components that are:- Already developed.- Provide significant functionality.

— Benefit from reusing reliable software.— Provide much of the same freedom to innovate

found in green field development.


«CSI5112»

D. AmyotU. Ottawa

Activities Common to Software Projects...

Requirements and specification• Includes

—Domain analysis and problem definition—Requirements elicitation

- Obtaining input from as many sources as possible

—Requirements analysis- Organizing the information

—Requirements specification- Writing detailed instructions about how the software

should behave

—Requirements validation—Requirements management


«CSI5112»

D. AmyotU. Ottawa

Activities Common to Software Projects...

Design• Deciding how the requirements should be implemented,

using the available technology• Includes:

— Systems engineering: Deciding what should be in hardware and what in software

— Software architecture: Dividing the system into subsystems and deciding how the subsystems will interact

— Detailed design of the internals of a subsystem— User interface design— Design of databases


«CSI5112»

D. AmyotU. Ottawa

Activities Common to Software Projects

Modelling• Creating representations of the domain or the software

—Use case modelling—Structural modelling—Dynamic and behavioural modelling—Issue modelling

ProgrammingQuality assurance

• Reviews and inspections• Testing, validation, verification

DeploymentChange and process management


«CSI5112»

D. AmyotU. Ottawa

Difficulties and Risks in Software Engineering

• Complexity and large numbers of details

• Uncertainty about technology

• Uncertainty about requirements

• Uncertainty about software engineering skills

• Constant change

• Deterioration of software design

• Political risks

Good management skills are required!


«CSI5112»

D. AmyotU. Ottawa

(Software) Project Management

Project management encompasses all the activities needed to plan and execute a project:

• Deciding what needs to be done

• Estimating costs

• Ensuring there are suitable people to undertake the project

• Defining responsibilities

• Scheduling

• Making arrangements for the work

• continued ...


«CSI5112»

D. AmyotU. Ottawa

(Software) Project Management

• Directing

• Being a technical leader

• Reviewing and approving decisions made by others

• Building morale and supporting staff

• Monitoring and controlling

• Co-ordinating the work with managers of other projects

• Reporting

• Continually striving to improve the process


«CSI5112»

D. AmyotU. Ottawa

Software Process Models

Software process models are general approaches for organizing a project into activities.

• Help the project manager and his or her team to decide:

— What work should be done;

— In what sequence to perform the work.

• The models should be seen as aids to thinking, not rigid prescriptions of the way to do things.

• Each project ends up with its own unique plan.


«CSI5112»

D. AmyotU. Ottawa

Dilbert on Processes and Methodologies


«CSI5112»

D. AmyotU. Ottawa

The Opportunistic Approach

Think of Idea for

Improvement

Modify Until

Satisfied

First Prototype


«CSI5112»

D. AmyotU. Ottawa

The Opportunistic Approach

… is what occurs when an organization does not follow good engineering practices.

• It does not acknowledge the importance of working out the requirements and the design before implementing a system.

• The design of software deteriorates faster if it is not well designed.

• Since there are no plans, there is nothing to aim towards.

• There is no explicit recognition of the need for systematic testing and other forms of quality assurance.

• The above problems make the cost of developing and maintaining software very high.


«CSI5112»

D. AmyotU. Ottawa

The Waterfall Model

V & V

Requirements Gathering and

Definition

V & V

Specification

V & V

Design

V & V

Implementation

V & V

Maintenance

V & V

Integration and Deployment


«CSI5112»

D. AmyotU. Ottawa

The Waterfall Model

The classic way of looking at S.E. that accounts for the importance of requirements, design and quality assurance.

• The model suggests that software engineers should work in a series of stages.

• Before completing each stage, they should perform quality assurance (verification and validation).

• The waterfall model also recognizes, to a limited extent, that you sometimes have to step back to earlier stages.


«CSI5112»

D. AmyotU. Ottawa

Limitations of the Waterfall Model

• The model implies that you should attempt to complete a given stage before moving on to the next stage

— Does not account for the fact that requirements constantly change.

— It also means that customers can not use anything until the entire system is complete.

• The model makes no allowances for prototyping.

• It implies that you can get the requirements right by simply writing them down and reviewing them.

• The model implies that once the product is finished, everything else is maintenance.


«CSI5112»

D. AmyotU. Ottawa

The Phased-Release Model

V & V

Requirements Gathering and

Definition

V & V

Specification

V & V

Design

V & V

Implementation

V & V

Planning

Phase 1

V & V

Design

V & V

Implementation

Phase 2

etc ...

V & V


V & V



«CSI5112»

D. AmyotU. Ottawa

The Phased-Release Model

It introduces the notion of incremental development.

• After requirements gathering and planning, the project should be broken into separate subprojects, or phases.

• Each phase can be released to customers when ready.

• Parts of the system will be available earlier than when using a strict waterfall approach.

• However, it continues to suggest that all requirements be finalized at the start of development.


«CSI5112»

D. AmyotU. Ottawa

The Spiral Model

Requirements

Specification

DesignImplementation

Prototype

Release 1

Release 2

Review Analysis of risk

Integration and deployment


«CSI5112»

D. AmyotU. Ottawa

The Spiral Model

It explicitly embraces prototyping and an iterative approach to software development.

• Start by developing a small prototype.

• Followed by a mini-waterfall process, primarily to gather requirements.

• Then, the first prototype is reviewed.

• In subsequent loops, the project team performs further requirements, design, implementation and review.

• The first thing to do before embarking on each new loop is risk analysis.

• Maintenance is simply a type of on-going development.


«CSI5112»

D. AmyotU. Ottawa

The Evolutionary Model

Time

Development Activity


«CSI5112»

D. AmyotU. Ottawa

The Evolutionary Model

It shows software development as a series of hills, each representing a separate loop of the spiral.

• Shows that loops, or releases, tend to overlap each other.

• Makes it clear that development work tends to reach a peak, at around the time of the deadline for completion.

• Shows that each prototype or release can take

— different amounts of time to deliver;

— differing amounts of effort.


«CSI5112»

D. AmyotU. Ottawa

The Concurrent Engineering Model

Plan

Integrate

Divide

Work on Component or

Layer X


Layer B


Layer A...


«CSI5112»

D. AmyotU. Ottawa

The Concurrent Engineering Model

It explicitly accounts for the divide and conquer principle.

• Each team works in parallel on its own component, typically following a spiral or evolutionary approach.

• There has to be some initial planning, and periodic integration.


«CSI5112»

D. AmyotU. Ottawa

Choosing a Process Model

• From the waterfall model:

—Incorporate the notion of stages.

• From the phased-release model:

—Incorporate the notion of doing some initial high-level analysis, and then dividing the project into releases.

• From the spiral model:

—Incorporate prototyping and risk analysis.

• From the evolutionary model:

—Incorporate the notion of varying amounts of time and work, with overlapping releases.

• From the concurrent engineering:

—Incorporate the notion of breaking the system down into components and developing them in parallel.


«CSI5112»

D. AmyotU. Ottawa

Reengineering

Periodically project managers should set aside some time to re-engineer part or all of the system

• The extent of this work can vary considerably:

— Cleaning up the code to make it more readable.

— Completely replacing a layer.

— Re-factoring part of the design.

• In general, the objective of a re-engineering activity is to increase maintainability.


«CSI5112»

D. AmyotU. Ottawa

Extreme Programming

Extreme Programming (XP) was created in response to problem domains whose requirements change.

• Your customers may not have a firm idea of what the system should do.

• You may not have to develop large requirement documents. Instead you write a series of user stories.

• Project planning is based on user stories. There must be a series of small and frequent/regular releases;

• In many software environments dynamically changing requirements is the only constant.

• XP requires an extended development team. The XP team includes not only the developers, but the managers and customers as well.

• Extreme Listening, Testing, Coding, Designing.

http://www.extremeprogramming.org


«CSI5112»

D. AmyotU. Ottawa

Dilbert on Extreme Programming…


«CSI5112»

D. AmyotU. Ottawa

Dilbert on Extreme Programming…

«CSI5112»

D. AmyotU. Ottawa

Part II:Modelling, and Dealing with Complexity

Review, CSI 5112(extract from Bernd Bruegge & Allen H. Dutoit,

Object-Oriented Software Engineering: Using UML, Patterns, and Java)


«CSI5112»

D. AmyotU. Ottawa

A Game: Get-15

• Start with the nine numbers 1, 2, 3, 4, 5, 6, 7, 8 and 9. • You and your opponent take alternate turns, each taking a number.• Each number can be taken only once: if your opponent has selected

a number, you can no longer take it. • The first person to have any three numbers that sums up to 15 wins

the game!• Example:

You:

Opponent:

1 5 83

6 9 27 OpponentWins!


«CSI5112»

D. AmyotU. Ottawa

Characteristics of Get-15

Hard to play…

The game is especially hard, if you are not allowed to write anything.

Why? • All the numbers need to be scanned to see if you

have won/lost• It is hard to see what the opponent will take if you

take a certain number• The choice of the number depends on all the

previous numbers• Not easy to devise a simple strategy


«CSI5112»

D. AmyotU. Ottawa

Another Game: Tic-Tac-Toe

Source: http://boulter.com/ttt/index.cgi


«CSI5112»

D. AmyotU. Ottawa

A Draw Sitation


«CSI5112»

D. AmyotU. Ottawa

Strategy for Determining a Winning Move


«CSI5112»

D. AmyotU. Ottawa

Winning Situations for Tic-Tac-Toe

WinningPatterns


«CSI5112»

D. AmyotU. Ottawa

Tic-Tac-Toe is “Easy”

Why? • Reduction of complexity through patterns and symmetries

Patterns• Knowing the following three patterns, the player can anticipate the opponents

move:

Symmetries• The player needs to remember only these three patterns to deal

with 12 different game situations• The player needs to memorize only 3 opening moves and their

responses


«CSI5112»

D. AmyotU. Ottawa

But Get-15 & Tic-Tac-Toe are Identical Problems!

• Any three numbers that solve the 15 problem also solve tic-tac-toe.

• Any tic-tac-toe solution is also a solution to the 15 problem• To see the relationship between the two games, we simply

arrange the 9 digits into the following pattern:

8 1 6

3 5 7

4 9 2


«CSI5112»

D. AmyotU. Ottawa

Example

8 1 6

3 5 7

1 5 83

6 9 27

You:

Opponent:

4 9 2


«CSI5112»

D. AmyotU. Ottawa

Models are Good, but… What is This?


«CSI5112»

D. AmyotU. Ottawa

Dealing with Complexity using Modelling

Three important concepts:

1. Abstraction

2. Decomposition

3. Hierarchy


«CSI5112»

D. AmyotU. Ottawa

1. Abstraction

Inherent human limitation to deal with complexity

• The 7 +/- 2 phenomena (phone numbers…)

Chunking

• Group collection of objects

Ignore unessential details Models


«CSI5112»

D. AmyotU. Ottawa

Models are Used to Provide Abstractions

System Model:• Object Model: What is the structure of the system? What are

the objects and how are they related?• Functional model: What are the functions of the system? How

is data flowing through the system?• Dynamic model: How does the system react to external events?

What is the event flow in the system ?

Task Model:• PERT Chart: What are the dependencies between the tasks?• Schedule: How can this be done within the time limit?• Org Chart: What are the roles in the project or organization?

Issues Model:• What are the open and closed issues? What are the goals and

objectives? What constraints were posed by the client? What resolutions were made?


«CSI5112»

D. AmyotU. Ottawa

Different but Related Model Types

Task Models

PERT Chart

Gantt Chart

Org Chart

Issue Models

Constraints

Issues

Proposals

Arguments

Pro Con

System Models

Object Model

FunctionalModel

Dynamic Model

class...class...class...

Code

ForwardEngineering

ReverseEngineering


«CSI5112»

D. AmyotU. Ottawa

Model-Based Software Engineering:Code is a Derivation of Object Model

Problem Statement : A stock exchange lists many companies. Each company is identified by a ticker symbolAnalysis phase results in object model (UML Class Diagram):

StockExchange Company

tickerSymbolLists **

Implementation phase results in code public class StockExchange{ private Vector companies = new Vector();}

public class Company{ public int tickerSymbol; private Vector stockExchanges = new Vector();}

A good software engineer writes as little code as possible


«CSI5112»

D. AmyotU. Ottawa

Example of an Issue: Galileo vs the Church

What is the center of the Universe?

• Church: The earth is the center of the universe. Why? Aristotle says so.

• Galileo: The sun is the center of the universe. Why? Copernicus says so. Also, the Jupiter’s moons rotate round Jupiter, not around Earth.


«CSI5112»

D. AmyotU. Ottawa

Issue-ModellingIssue:

What is the Center of the

Universe?

Proposal1: The earth!

Proposal2:

The sun!

Pro: Copernicus

says so.

Pro: Aristotlesays so.

Pro: Change will disturb

the people.

Con: Jupiter’s moons rotate

around Jupiter, not around Earth.

Resolution (1615):The church

decides proposal 1is right

Resolution (1998): The church declares

proposal 1 was wrong


«CSI5112»

D. AmyotU. Ottawa

2. Decomposition

A technique used to master complexity • “divide and conquer”

Functional decomposition• The system is decomposed into modules• Each module is a major processing step (function) in

the application domain• Modules can be decomposed into smaller modules

Object-oriented decomposition• The system is decomposed into classes (“objects”) • Each class is a major abstraction in the application

domain• Classes can be decomposed into smaller classes

Which decomposition is the right one?


«CSI5112»

D. AmyotU. Ottawa

Functional Decomposition

Top Level functions

Level 1 functions

Level 2 functions

Machine Instructions

System Function

Load R10 Add R1, R10

Read Input TransformProduceOutput

TransformProduceOutputRead Input


«CSI5112»

D. AmyotU. Ottawa

Functional Decomposition

Functionality is spread all over the system

Maintainers must often understand the whole system to make a single change to the system

Consequence:• Code is hard to understand• Code is complex and difficult to maintain• User interface is often awkward and non-intuitive

OO decomposition provides some help, but still has problems


«CSI5112»

D. AmyotU. Ottawa

What is this Thing?


«CSI5112»

D. AmyotU. Ottawa

Modelling a Briefcase

BriefCase

Capacity: IntegerWeight: Integer

Open()Close()Carry()


«CSI5112»

D. AmyotU. Ottawa

A New Use for a Briefcase

BriefCase

Capacity: IntegerWeight: Integer

Open()Close()Carry()

SitOnIt()


«CSI5112»

D. AmyotU. Ottawa

Questions

Why did we model the thing as “Briefcase”?

Why did we not model it as a “Chair”?

What do we do if the SitOnIt() operation is the most frequently used operation?

What if decompositions other than functional and OO were also needed?


«CSI5112»

D. AmyotU. Ottawa

A Decomposition ProblemNot all requirements can be assigned to just one component ( crosscutting concerns)

Requirement1 (R1)

Requirement2 (R2)

Requirement3 (R3)

RequirementN (RN)…

Scattering: designelements to support R1 in many components

Tangling: single component has elements for many requirements

ComponentA

R1 elements

ComponentF

R1 elementsR2 elementsR3 elementsRN elements

ComponentE

ComponentD

R1 elements

ComponentB

R1 elements

ComponentC

R1 elements

[Slide from G. Mussbacher]


«CSI5112»

D. AmyotU. Ottawa

Aspect

Triggered behavior

(code)

Predicate

F.R1

One Potential Solution: Aspects

ClassA

R1 elements

ClassC

R1 elements

ClassG

R1 elements

ClassF

R1 elementsR2 elementsR3 elementsRN elements

advice

pointcut

Terminology based on AspectJ: www.eclipse.org/aspectj

intertypedeclaration

ClassB

R1 elements

(identifies joinpointswhere advice is executed)

R1 elements

R1 elements

R1 elements

R1 elements

R1 elements


«CSI5112»

D. AmyotU. Ottawa

3. Hierarchy

We got abstractions and decomposition• This leads us to chunks (classes, objects, aspects) which

we view with an object model

Another way to deal with complexity is to provide simple relationships between the chunks

One of the most important relationships is hierarchy

2 important hierarchies• "Part-of" hierarchy• "Is-kind-of" hierarchy


«CSI5112»

D. AmyotU. Ottawa

Part-of Hierarchy

Computer

I/O Devices CPU Memory

Cache ALU Program Counter


«CSI5112»

D. AmyotU. Ottawa

Is-Kind-of Hierarchy (Taxonomy)

Cell

Muscle Cell Blood Cell Nerve Cell

Striate Smooth Red White Cortical Pyramidal


«CSI5112»

D. AmyotU. Ottawa

So Where Are We Right Now?

Three ways to deal with complexity:• Abstraction • Decomposition• Hierarchy

Object-oriented decomposition is a good methodology• Unfortunately, depending on the purpose of the system, different

objects can be found• Other limitations

How can we do it right? • Many different possibilities• Suggested approach: Start with a description of the functionality

(Use Case model), then proceed to the object model

This leads us to interesting software lifecycle activities


«CSI5112»

D. AmyotU. Ottawa

Software Lifecycle Activities…

Subsystems

Structured By

class...class...class...

SourceCode

Implemented By

Solution Domain Objects

Realized By

SystemDesign

ObjectDesign

Implemen-tation

Testing

Application

Domain Objects

Expressed in Terms Of

Test Cases

?

Verified By

class....?

RequirementsElicitation

Use CaseModel

Analysis

and Their Models


«CSI5112»

D. AmyotU. Ottawa

Summary

Software engineering is a problem solving activity

• Developing quality software for a complex problem within limited time and resources while things are changing

There are many ways to deal with complexity

• Modelling, decomposition, abstraction, hierarchy

• Issue models: Show the negotiation aspects— CSI 5112 emphasizes requirements engineering

• System models: Show the technical aspects — CSI 5112 emphasizes precise modeling with UML

• Task models: Show the project management aspects— CSI 5112 emphasizes project and change management

• Use Patterns: Reduce complexity even further

«CSI5112»

D. AmyotU. Ottawa

Part III:Modelling with UML 1.x

Review, CSI 5112(extracts from Bruegge & Dutoit,

Lethbridge & Laganière,and from the Borland UML tutorial)


«CSI5112»

D. AmyotU. Ottawa

Good UML Tutorials

http://bdn.borland.com/article/0,1410,31863,00.html

• Source of most of the figures used here

UML Distilled, Third Edition

• Martin Fowler, ISBN 0-321-19368-7

• Addison-Wesley, 2004, 208 pages

UML specification• http://www.omg.org/technology/documents/formal/uml.htm


«CSI5112»

D. AmyotU. Ottawa

Systems, Models, and Views

• A model is an abstraction describing a subset of a system (filtering out unimportant details)

• A view depicts selected aspects of a model

• A notation is a set of graphical and/or textual rules for depicting views

• Views and models of a single system may overlap each other. Examples:

— System: Aircraft

— Models: Flight simulator, scale model

— Views: All blueprints, electrical wiring, fuel system


«CSI5112»

D. AmyotU. Ottawa

View 1

Model 2 View 2

View 3

Model 1

Systems, Models and Views

Aircraft

Flight Simulator

Scale Model

Blueprints

Electrical Wiring

System


«CSI5112»

D. AmyotU. Ottawa

Models, Views and Systems (UML)

System Model View**

Depicted byDescribed by

Airplane: System

Blueprints: View Fuel System: View Electrical Wiring: View

Scale Model: Model Flight Simulator: Model


«CSI5112»

D. AmyotU. OttawaBooch method OMT

(Rumbaugh)

Unified Method 0.8OOPSLA 1995

OOSE(Jacobson)

Other methods

UML 0.9Web - June 1996

UML 1.11st submission à OMG, Jan 1997

Approval OMG, Nov 1997

UML 1.0UML partners

UML 1.3Revision Task Force, June 1999

Revision Task Force, May 2001 UML 1.4

UML Evolution UML 2.0Revision Task Force, Nov 2003

UML 1.5Revision Task Force, March 2003


«CSI5112»

D. AmyotU. Ottawa

Meyer

Before and after conditions

Harel

StatechartsGamma, et al

Frameworks and patterns

HP Fusion

Operation descriptions and message numbering

Embley

Singleton classes andhigh-level view

Wirfs-Brock

Responsibilities

Odell

Classification

Shlaer - Mellor

Object lifecycles

Rumbaugh

OMT

Booch

Booch method

Jacobson

OOSE

Contributions to UML 1.X


«CSI5112»

D. AmyotU. Ottawa

Models and Diagrams

StateDiagramsState

DiagramsComponentDiagrams

ComponentDiagramsComponent

DiagramsDeploymentDiagrams

StateDiagramsState

DiagramsObjectDiagrams

StateDiagramsState

DiagramsClassDiagramsUse Case

DiagramsUse CaseDiagramsUse Case

Diagrams

ScenarioDiagramsScenario

DiagramsCollaborationDiagrams

ScenarioDiagramsScenario

DiagramsStatechartDiagrams

Use CaseDiagramsUse Case

DiagramsSequenceDiagrams

ActivityDiagrams

Models


«CSI5112»

D. AmyotU. Ottawa

RUP (Rational Unified Process) Models

Use CaseDiagrams

CollaborationDiagrams

ComponentDiagrams

DeploymentDiagrams

ObjectDiagrams

StatechartDiagrams

SequenceDiagrams

ClassDiagrams

ActivityDiagrams

Use CaseModel

DesignModel

Depl.Model

Impl.Model

AnalysisModel

TestModel

A model may include many diagrams (views) using many notations.

A notation may be used in several models.


«CSI5112»

D. AmyotU. Ottawa

Use Case Diagrams

Use case diagrams represent the functionality of the system from the user’s point of view

Open file by typing name

Open file by browsing

Open file

System Administrator

Browse for file

Ordinary User

Attempt to open file that does not exist

«extend» «include»

actor use case

is-a

relations

generalization

association

[From L&L]


«CSI5112»

D. AmyotU. Ottawa

Content of a Use Case Bubble

Use cases are often described textually or with sequence diagrams. For instance:


«CSI5112»

D. AmyotU. Ottawa

Class Diagrams

Class diagrams describe the static structure of the system: Objects, Attributes, Associations


«CSI5112»

D. AmyotU. Ottawa

Object Diagrams

Snapshots of run-time objects and their links


«CSI5112»

D. AmyotU. Ottawa

Object Diagrams and Class Diagrams

RecordingCategory*subcategorydescription

Recording *hasCategory

titleartist

rockbluesclassicaljazzmusic video

video audio

subcategory subcategorysubcategorysubcategorysubcategory

:RecordingCategory :RecordingCategory

:RecordingCategory :RecordingCategory :RecordingCategory :RecordingCategory:RecordingCategory

9th Symphony

:Recording

Let it be

:Recording

The BeatlesBeethoven

Objects are instances of classes (with real values), and links are instances of associations. No inheritance, no multiplicities.


«CSI5112»

D. AmyotU. Ottawa

Activity Diagrams

Describe the dynamic behavior of a system as a flow (sequence, alternative, parallel) of activities (workflow).


«CSI5112»

D. AmyotU. Ottawa

Sequence Diagrams

Describe the dynamic behavior as interactions between actorsand the system and between objects of the system


«CSI5112»

D. AmyotU. Ottawa

Collaboration Diagrams

2-D view of sequence diagrams, with numbered messages


«CSI5112»

D. AmyotU. Ottawa

Describe the dynamic behavior of an individual object (with states and transitions)

Statechart Diagrams


«CSI5112»

D. AmyotU. Ottawa

Component and Deployment Diagrams

A component is a code module. Component diagrams are physical analogs of class diagram. Deployment diagrams describe the relationships among software and hardware components (a

configuration)


«CSI5112»

D. AmyotU. Ottawa

Package Diagrams

Show a structure of packages, which are collections of logically related UML elements used to simplify, manage,

and reuse complex models.


«CSI5112»

D. AmyotU. Ottawa

Also in UML 1.x

Object Constraint Language (OCL)• Will be covered later in this course

Semantic Metamodel• Some aspects will be viewed in this course

Profiles• Some aspects will be viewed in this course

Action Semantics (UML 1.5 only)• Will not be used in this course


«CSI5112»

D. AmyotU. Ottawa

Dilbert on UML…

«CSI5112»

D. AmyotU. Ottawa

Part IV:Essential Java Features

Review, CSI 5112(extract from Lethbridge & Laganière, 2001, and

Daniel Amyot (CSI 1500), 2004. See also http://www.site.uottawa.ca/school/research/lloseng/

BasicsOfJava.pdf)


«CSI5112»

D. AmyotU. Ottawa

Concepts that Define Object Orientation (OO)

Necessary for a system or language to be OO• Identity

— Each object is distinct from each other object, and can be referred to

— Two objects are distinct even if they have the same data• Classes

— The code is organized using classes, each of which describes a set of objects

• Inheritance— The mechanism where features in a hierarchy inherit from

superclasses to subclasses• Polymorphism

— The mechanism by which several methods can have the same name and implement the same abstract operation


«CSI5112»

D. AmyotU. Ottawa

Other Key OO Concepts

• Encapsulation— Details can be hidden in classes— This gives rise to information hiding:

- Programmers do not need to know all the details of a class

• Abstraction— Object something in the world— Class objects— Superclass subclasses— Operation methods— Attributes and associations instance variables

• Modularity— Code can be constructed entirely of classes


«CSI5112»

D. AmyotU. Ottawa

The Basics of JavaHistory

• The first object oriented programming language was Simula-67 — Designed to allow programmers to write simulation programs

• In the early 1980’s, Smalltalk was developed at Xerox PARC — New syntax, large open-source library of reusable code,

bytecode, platform independence, garbage collection.• late 1980’s, C++ was developed by B. Stroustrup,

— Recognized the advantages of OO but also recognized that there were tremendous numbers of C programmers

• In 1991, engineers at Sun Microsystems started a project to design a language that could be used in consumer ‘smart devices’: Oak

— When the Internet gained popularity, Sun saw an opportunity to exploit the technology.

— The new language, renamed Java, was formally presented in 1995 at the SunWorld ’95 conference.


«CSI5112»

D. AmyotU. Ottawa

Tools and APIs

Java2 API• 1.4.2: http://java.sun.com/j2se/1.4.2/docs/api/index.html • 5.0: http://java.sun.com/j2se/1.5.0/docs/api/index.html • 6: http://java.sun.com/javase/6/docs/api/

JVM• Java Virtual Machine (platform-dependent)

javac• Java compiler (produces platform-independent bytecode)

java• Java interpreter (runs bytecode on a JVM)

javadoc• Produces HTML documentation from Java code

drJava, Eclipse…• Integrated Development Environments (IDEs) for Java


«CSI5112»

D. AmyotU. Ottawa

Primitive Data Types

Void---------------void

Booleantrue or false1-bit boolean

Double64-bit IEEE 754 floating-point numbers64-bit double

Float32-bit IEEE 754 floating-point numbers32-bit float

Long+263-1

(9,223,372,036,854,775,807)-263

(-9,223,372,036,854,775,808)64-bit long

Integer+231-1

(2,147,483,647)-231

(-2,147,483,648)32-bit int

Short+215-1

(32,767)-215

(-32,768)16-bit short

Byte+127-1288-bit byte

CharacterUnicode 216-1Unicode 016-bit char

Wrapper TypeMaximum ValueMinimum ValueSizePrimitive Type

Void---------------void

Booleantrue or false1-bit boolean

Double64-bit IEEE 754 floating-point numbers64-bit double

Float32-bit IEEE 754 floating-point numbers32-bit float

Long+263-1

(9,223,372,036,854,775,807)-263

(-9,223,372,036,854,775,808)64-bit long

Integer+231-1

(2,147,483,647)-231

(-2,147,483,648)32-bit int

Short+215-1

(32,767)-215

(-32,768)16-bit short

Byte+127-1288-bit byte

CharacterUnicode 216-1Unicode 016-bit char

Wrapper TypeMaximum ValueMinimum ValueSizePrimitive Type


«CSI5112»

D. AmyotU. Ottawa

Some Basics Constructs…

Assignment and sequence of instructions

int var1; // defines a variable, initially at 0

int var2 = 3; // defines & initializes another one

var1 = var2 + 1; // assigns 4 to var1

Comments

Java instruction; // Comment, to end of line

Comments can also be between /* and */ (on many lines)

Displaying information

System.out.println(var1); // with carriage return

System.out.print("Sum: " + (var1 + var2));

// No CR. First + is concatenation, second is sum!


«CSI5112»

D. AmyotU. Ottawa

Arrays

Declaration of an Array variable (of some type)double [] myArray; // Initially worth null

Creating an array (reserving memory for N elements)myArray = new double[5]; // Valid indices: 0 to 4

Size of an arrayint theSize = myArray.length; // theSize = 5

Initializing an array during creationint[] array1 = new int [] { 3, 5, 4 };

Arrays are reference types (not primitive types)int[] array2 = array1;array2[0] = 6; // Also changes array1[0] to 6!

Multidimensional arrays (not limited to 2)int [][] M;M = new int[][] { {1, 2, 3}, {4, 5, 6} };


«CSI5112»

D. AmyotU. Ottawa

A Very Useful Type: String

Esay to manipulate

String hi = "Hello";

String message = hi + " world!";

System.out.println( message );

// displays Hello world!

Comparisons

String str1 = "abcde" ;

String str2 = "abcfg" ;

String str3 = "ab" ;

boolean c1 = str1.equals(str2); // false

int c2 = str1.compareTo(str3); // > 0

// Many other operations in the String class


«CSI5112»

D. AmyotU. Ottawa

Operators and Their Precedence

() (expression) [] (array index) . (object member)

+ – (unary plus/minus) ! (negation)

* / % (modulus)

+ - (binary addition/substraction)

< > >= <=

== !=

&& (logical AND)

|| (logical OR)

= (assignment)


«CSI5112»

D. AmyotU. Ottawa

Control StructuresConditionsif (x < 5) // Boolean expression { doThis(); // list of instructions }else{ doThat(); // list of instructions }

Loopswhile (Test) // some Boolean expression { body(); // list of instructions }

for (int i = 0; i < 9; i++){ m = m + i; // body, repeated 9 times}


«CSI5112»

D. AmyotU. Ottawa

Classes with a Main Method

public class HelloWorldApp

{

// main is a special, runnable method

public static void main(String[] args)

{

System.out.println("Hello World!");

}

}


«CSI5112»

D. AmyotU. Ottawa

Classes and Objects

Class definition

class Time

{

public int hours;

public int minutes;

}

Class instances (objects)

Time myTime; // definition, initially set to null

myTime = new Time( ); // new object created

myTime.hours = 17;

myTime.minutes = 45;


«CSI5112»

D. AmyotU. Ottawa

Attributes and Methods

Classes can contain attributes and/or methods

class Time { private int hours; private int minutes;

public void setTime(int h, int minutes) // Setter method { this.hours = h; // this is optional here this.minutes = minutes; // this is not optional here } public int getHours() // Getter method { return hours; } public int getMinutes( ) // Another getter method { return this.minutes; // this is optional here } }


«CSI5112»

D. AmyotU. Ottawa

Visibility and Encapsulation

•public: A public method can be invoked by any other method in any other object or class.

•protected: A protected method can be invoked by any method in the class in which it is defined or any subclasses of that class.

•private: A private method can only be invoked by other method in the class in which it is defined, but not in the subclasses.

• (default, no keyword) : The method is effectively public to all other classes within the same package, but private to classes external to the package. This is sometimes called package visibility or friendly visibility.

• These visibility modifiers can help reducing coupling in complex Java programs.

• They can also be applied to variables (fields) in a class.


«CSI5112»

D. AmyotU. Ottawa

Class and Instance Variables/Methods

The static keyword is used to specify class variables or methods (common to all instances of the classes). A non-static (instance) variable will have a content possibly different for all objects of that class. Static methods are limited to accessing static variables.

public static boolean isEqual( Time t1, Time t2 ){ return (t1.getHours() == t2.getHours()) && (t1.getMinutes() == t2.getMinutes());}

// Polymorphism allows for both methods in the same class!public boolean isEqual( Time t2 ) { return (this.hours == t2.getHours()) && (this.minutes == t2.getMinutes());}

public static final MAXMINUTES=60; // final means constant


«CSI5112»

D. AmyotU. Ottawa

ConstructorsInvoked when we create an object. Usually initialize class fields.// Constructor by default. Implicit in Java if no// constructor specified, overridden otherwise.// Constructors have the class name and return nothing.public Time(){ ; // do nothing to the fields! } // Another constructor, with parameters.public Time(int h, int m){ this.minutes = m % 60; // Handles the case where m>59 this.hours = h + m/60;}// Java uses garbage collection, hence destructors are not supported.

Creation of objects with newTime t1 = new Time(); // Uses first constructor, hours = minutes = 0 Time t2 = new Time(3, 45); // Uses second constructor, 3:45


«CSI5112»

D. AmyotU. Ottawa

Inheritanceimport java.applet.*; import java.awt.*;

/** * The HelloWorld class implements an applet that * simply displays "Hello World!". */

public class HelloWorld extends Applet // Single inheritance only in Java{

public void paint(Graphics g) {

// Display "Hello World!"g.drawString("Hello world!", 50, 25);

}

}


«CSI5112»

D. AmyotU. Ottawa

Exceptions

Anything that can go wrong should result in the raising of an Exception•Exception is a class with many subclasses for specific

things that can go wrongUse a try - catch block to trap an exception

try{ // some code}catch (ArithmeticException e){ // code to handle division by zero}


«CSI5112»

D. AmyotU. Ottawa

Interfaces

Like abstract classes, but cannot have executable statements

• Define a set of operations that make sense in several classes

• Abstract Data Types

• Can be used to “fake” multiple inheritance

A class can implement any number of interfaces

• It must have concrete methods for the operations

Important interfaces in Java’s library include•Runnable, Collection, Iterator, Comparable, Cloneable


«CSI5112»

D. AmyotU. Ottawa

Packages and Importing

A package combines related classes into subsystems

• All the classes in a particular directory

Classes in different packages can have the same name

• Although not recommended

Importing a package is done as follows: import java.applet.*;

import finance.banking.accounts.*;

// A good practice is to avoid the * and

// enumerate the exact classes imported.


«CSI5112»

D. AmyotU. Ottawa

Threads and Concurrency

Thread

• Sequence of executing statements that can be running concurrently with other threads

To create a thread in Java

1. Create a class implementing the Runnable interface or extending Thread

2. Implement the run method as a loop that does something for a period of time

3. Create an instance of this class

4. Invoke the start operation, which in turn calls run


«CSI5112»

D. AmyotU. Ottawa

Dilbert on Programming…

Documents

Daniel Amyot University of Ottawa 200 7