«CSI5112» D. Amyot U. Ottawa CSI 5112 CSI 5112 Review of Software Engineering Review of Software Engineering Daniel Amyot University of Ottawa 2007
Jan 14, 2016
«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.
Review of Software Engineering 3
«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
Review of Software Engineering 4
«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)
Review of Software Engineering 6
«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?
Review of Software Engineering 7
«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
Review of Software Engineering 8
«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
Review of Software Engineering 9
«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
Review of Software Engineering 10
«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
Review of Software Engineering 11
«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.
Review of Software Engineering 12
«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
Review of Software Engineering 13
«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
Review of Software Engineering 14
«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.
Review of Software Engineering 15
«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)
Review of Software Engineering 16
«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:
Review of Software Engineering 17
«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.
Review of Software Engineering 18
«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!
Review of Software Engineering 19
«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
Review of Software Engineering 20
«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…
Review of Software Engineering 21
«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
Review of Software Engineering 22
«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
Review of Software Engineering 23
«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
Review of Software Engineering 24
«CSI5112»
D. AmyotU. Ottawa
Software Engineering Projects
‘Green field’ projects• New development• The minority of projects
Review of Software Engineering 25
«CSI5112»
D. AmyotU. Ottawa
Software Engineering Projects
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.
Review of Software Engineering 26
«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
Review of Software Engineering 27
«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
Review of Software Engineering 28
«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
Review of Software Engineering 29
«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!
Review of Software Engineering 30
«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 ...
Review of Software Engineering 31
«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
Review of Software Engineering 32
«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.
Review of Software Engineering 33
«CSI5112»
D. AmyotU. Ottawa
Dilbert on Processes and Methodologies
Review of Software Engineering 34
«CSI5112»
D. AmyotU. Ottawa
The Opportunistic Approach
Think of Idea for
Improvement
Modify Until
Satisfied
First Prototype
Review of Software Engineering 35
«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.
Review of Software Engineering 36
«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
Review of Software Engineering 37
«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.
Review of Software Engineering 38
«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.
Review of Software Engineering 39
«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
Integration and Deployment
V & V
Integration and Deployment
Review of Software Engineering 40
«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.
Review of Software Engineering 41
«CSI5112»
D. AmyotU. Ottawa
The Spiral Model
Requirements
Specification
DesignImplementation
Prototype
Release 1
Release 2
Review Analysis of risk
Integration and deployment
Review of Software Engineering 42
«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.
Review of Software Engineering 43
«CSI5112»
D. AmyotU. Ottawa
The Evolutionary Model
Time
Development Activity
Review of Software Engineering 44
«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.
Review of Software Engineering 45
«CSI5112»
D. AmyotU. Ottawa
The Concurrent Engineering Model
Plan
Integrate
Divide
Work on Component or
Layer X
Work on Component or
Layer B
Work on Component or
Layer A...
Review of Software Engineering 46
«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.
Review of Software Engineering 47
«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.
Review of Software Engineering 48
«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.
Review of Software Engineering 49
«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
Review of Software Engineering 50
«CSI5112»
D. AmyotU. Ottawa
Dilbert on Extreme Programming…
Review of Software Engineering 51
«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)
Review of Software Engineering 53
«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!
Review of Software Engineering 54
«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
Review of Software Engineering 55
«CSI5112»
D. AmyotU. Ottawa
Another Game: Tic-Tac-Toe
Source: http://boulter.com/ttt/index.cgi
Review of Software Engineering 56
«CSI5112»
D. AmyotU. Ottawa
A Draw Sitation
Review of Software Engineering 57
«CSI5112»
D. AmyotU. Ottawa
Strategy for Determining a Winning Move
Review of Software Engineering 58
«CSI5112»
D. AmyotU. Ottawa
Winning Situations for Tic-Tac-Toe
WinningPatterns
Review of Software Engineering 59
«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
Review of Software Engineering 60
«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
Review of Software Engineering 61
«CSI5112»
D. AmyotU. Ottawa
Example
8 1 6
3 5 7
1 5 83
6 9 27
You:
Opponent:
4 9 2
Review of Software Engineering 62
«CSI5112»
D. AmyotU. Ottawa
Models are Good, but… What is This?
Review of Software Engineering 63
«CSI5112»
D. AmyotU. Ottawa
Dealing with Complexity using Modelling
Three important concepts:
1. Abstraction
2. Decomposition
3. Hierarchy
Review of Software Engineering 64
«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
Review of Software Engineering 65
«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?
Review of Software Engineering 66
«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
Review of Software Engineering 67
«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
Review of Software Engineering 68
«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.
Review of Software Engineering 69
«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
Review of Software Engineering 70
«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?
Review of Software Engineering 71
«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
Review of Software Engineering 72
«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
Review of Software Engineering 73
«CSI5112»
D. AmyotU. Ottawa
What is this Thing?
Review of Software Engineering 74
«CSI5112»
D. AmyotU. Ottawa
Modelling a Briefcase
BriefCase
Capacity: IntegerWeight: Integer
Open()Close()Carry()
Review of Software Engineering 75
«CSI5112»
D. AmyotU. Ottawa
A New Use for a Briefcase
BriefCase
Capacity: IntegerWeight: Integer
Open()Close()Carry()
SitOnIt()
Review of Software Engineering 76
«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?
Review of Software Engineering 77
«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]
Review of Software Engineering 78
«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
Review of Software Engineering 79
«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
Review of Software Engineering 80
«CSI5112»
D. AmyotU. Ottawa
Part-of Hierarchy
Computer
I/O Devices CPU Memory
Cache ALU Program Counter
Review of Software Engineering 81
«CSI5112»
D. AmyotU. Ottawa
Is-Kind-of Hierarchy (Taxonomy)
Cell
Muscle Cell Blood Cell Nerve Cell
Striate Smooth Red White Cortical Pyramidal
Review of Software Engineering 82
«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
Review of Software Engineering 83
«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
Review of Software Engineering 84
«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)
Review of Software Engineering 86
«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
Review of Software Engineering 87
«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
Review of Software Engineering 88
«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
Review of Software Engineering 89
«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
Review of Software Engineering 90
«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
Review of Software Engineering 91
«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
Review of Software Engineering 92
«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
Review of Software Engineering 93
«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.
Review of Software Engineering 94
«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]
Review of Software Engineering 95
«CSI5112»
D. AmyotU. Ottawa
Content of a Use Case Bubble
Use cases are often described textually or with sequence diagrams. For instance:
Review of Software Engineering 96
«CSI5112»
D. AmyotU. Ottawa
Class Diagrams
Class diagrams describe the static structure of the system: Objects, Attributes, Associations
Review of Software Engineering 97
«CSI5112»
D. AmyotU. Ottawa
Object Diagrams
Snapshots of run-time objects and their links
Review of Software Engineering 98
«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.
Review of Software Engineering 99
«CSI5112»
D. AmyotU. Ottawa
Activity Diagrams
Describe the dynamic behavior of a system as a flow (sequence, alternative, parallel) of activities (workflow).
Review of Software Engineering 100
«CSI5112»
D. AmyotU. Ottawa
Sequence Diagrams
Describe the dynamic behavior as interactions between actorsand the system and between objects of the system
Review of Software Engineering 101
«CSI5112»
D. AmyotU. Ottawa
Collaboration Diagrams
2-D view of sequence diagrams, with numbered messages
Review of Software Engineering 102
«CSI5112»
D. AmyotU. Ottawa
Describe the dynamic behavior of an individual object (with states and transitions)
Statechart Diagrams
Review of Software Engineering 103
«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)
Review of Software Engineering 104
«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.
Review of Software Engineering 105
«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
Review of Software Engineering 106
«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)
Review of Software Engineering 108
«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
Review of Software Engineering 109
«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
Review of Software Engineering 110
«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.
Review of Software Engineering 111
«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
Review of Software Engineering 112
«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
Review of Software Engineering 113
«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!
Review of Software Engineering 114
«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} };
Review of Software Engineering 115
«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
Review of Software Engineering 116
«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)
Review of Software Engineering 117
«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}
Review of Software Engineering 118
«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!");
}
}
Review of Software Engineering 119
«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;
Review of Software Engineering 120
«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 } }
Review of Software Engineering 121
«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.
Review of Software Engineering 122
«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
Review of Software Engineering 123
«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
Review of Software Engineering 124
«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);
}
}
Review of Software Engineering 125
«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}
Review of Software Engineering 126
«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
Review of Software Engineering 127
«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.
Review of Software Engineering 128
«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
Review of Software Engineering 129
«CSI5112»
D. AmyotU. Ottawa
Dilbert on Programming…