Daniel Amyot

1
CSI 5112 Review of Software Engineering

• Daniel Amyot
• University of Ottawa
• 2007

2
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 planets 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 programs random number
  generator with a truly random seed.
• 1990 ATT Network Outage. A bug in a new
  release of the software that controls ATTs
  4ESS long distance switches causes these mammoth
  computers to crash.
• 1993 Intel Pentium floating point divide. A
  silicon error causes Intels 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 5s faster engines trigger a bug in an
  arithmetic routine inside the rockets flight
  computer.
• 1995-2000 Year 2000 Problem (Y2K). Two digits
  for representing a year aint 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.

3
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/illustrativer
  isks.html
• Digest
• http//catless.ncl.ac.uk/Risks/
• Software Horror Stories
• http//www.cs.tau.ac.il/nachumd/verify/horror.htm
  l

4
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.
• Software and Software Engineering
• Modelling, and Dealing with Complexity
• Modelling with UML 1.x
• Essential Java Features

5
Part ISoftware and Software Engineering

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

6
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?

7
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

8
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

9
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

10
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

11
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.

12
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

13
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

14
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.
15
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)

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

• Complete version http//seeri.etsu.edu/Codes/TheS
  ECode.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

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

• PUBLIC - Software engineers shall act
  consistently with the public interest.
• 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.
• PRODUCT - Software engineers shall ensure that
  their products and related modifications meet the
  highest professional standards possible.
• JUDGMENT - Software engineers shall maintain
  integrity and independence in their professional
  judgment.
• MANAGEMENT - Software engineering managers and
  leaders shall subscribe to and promote an ethical
  approach to the management of software
  development and maintenance.
• PROFESSION - Software engineers shall advance the
  integrity and reputation of the profession
  consistent with the public interest.
• COLLEAGUES - Software engineers shall be fair to
  and supportive of their colleagues.
• 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.

18
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!

19
Software Quality...

• Usability
• Users can learn it and fast and get their job
  done easily
• Efficiency
• It doesnt 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

20
Software Quality...
An example ontology
http//www.cs.cf.ac.uk/user/M.Burgess/phd/index.h
tml
21
Software Quality What is at Stake?
Customer

User
solves problems at
easy to learn
an acceptable cost in
efficient to use
terms of money paid and
helps get work done
resources used
Salesman/Distributor

simple packaging
customization
warranty and updates
benefit margins
Developer
Development manager

easy to design
sells more and
easy to maintain
pleases customers
easy to reuse its parts
while costing less
to develop and maintain
22
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

23
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

24
Software Engineering Projects

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

25
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.

26
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

27
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

28
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
• Programming
• Quality assurance
• Reviews and inspections
• Testing, validation, verification
• Deployment
• Change and process management

29
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!
30
(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 ...

31
(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

32
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.

33
Dilbert on Processes and Methodologies
34
The Opportunistic Approach
35
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.

36
The Waterfall Model
V
Requirements

Gathering and
V
Definition
V

Specification
V
V

Design
V
V

Implementation
V
V
Integration and

Deployment
V
V

Maintenance
V
37
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.

38
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.

39
The Phased-Release Model
Phase 1
V

Design
V
V
Requirements
V

Gathering and

Implementation
V
Definition
V
V
V

Specification
Integration and

V
Deployment
V
V

Planning
V
Phase 2
V

Design
V
V

Implementation
V
V

Integration and
V
Deployment
etc ...
40
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.

41
The Spiral Model
Release 2
Release 1
Analysis of risk
Review
Prototype
Requirements
Integration and
deployment
Specification
Implementation
Design
42
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.

43
The Evolutionary Model
Time
Development
Activity
44
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.

45
The Concurrent Engineering Model
46
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.

47
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.

48
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.

49
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

50
Dilbert on Extreme Programming
51
Dilbert on Extreme Programming
52
Part IIModelling, and Dealing with Complexity

• Review, CSI 5112
• (extract from Bernd Bruegge Allen H. Dutoit,
• Object-Oriented Software Engineering Using UML,
  Patterns, and Java)

53
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
1
5
8
3
Opponent
6
9
2
7
Opponent Wins!
54
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

55
Another Game Tic-Tac-Toe
Source http//boulter.com/ttt/index.cgi
56
A Draw Sitation
57
Strategy for Determining a Winning Move
58
Winning Situations for Tic-Tac-Toe
59
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

60
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

61
Example
1
5
8
3
6
9
2
7
8
1
6
3
5
7
4
9
2
62
Models are Good, but What is This?
63
Dealing with Complexity using Modelling

• Three important concepts
• Abstraction
• Decomposition
• Hierarchy

64
1. Abstraction

• Inherent human limitation to deal with complexity
• The 7 /- 2 phenomena (phone numbers)
• Chunking
• Group collection of objects
• Ignore unessential details ? Models

65
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?

66
Different but Related Model Types
67
Model-Based Software EngineeringCode is a
Derivation of Object Model
Pr
oblem Statement

A
stock exchange lists many companies.
Each company is identified by a ticker symbol
A good software engineer writes as little code as
possible
68
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 Jupiters
  moons rotate round Jupiter, not around Earth.

69
Issue-Modelling
Issue What is the Center of the Universe?
70
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?

71
Functional Decomposition
System Function

Top Level functions
Level 1 functions
Level 2 functions
Add R1, R10
Machine Instructions
Load R10
72
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

73
What is this Thing?
74
Modelling a Briefcase
BriefCase Capacity Integer Weight
Integer Open() Close() Carry()
75
A New Use for a Briefcase
BriefCase Capacity Integer Weight
Integer Open() Close() Carry()
SitOnIt()
76
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?

77
A Decomposition Problem

• Not all requirements can be assigned to just one
  component (? crosscutting concerns)

Scattering designelements to support R1 in many
components
Tangling single component has elements for
many requirements
Slide from G. Mussbacher
78
One Potential Solution Aspects
R1 elements
F.R1
Triggered behavior (code)
R1 elements
Predicate
R1 elements
R1 elements
R1 elements
Terminology based on AspectJ www.eclipse.org/aspe
ctj
79
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

80
Part-of Hierarchy
Computer
81
Is-Kind-of Hierarchy (Taxonomy)
82
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

83
Software Lifecycle Activities
and Their Models
System Design
Object Design
Implemen- tation
Testing
Requirements Elicitation
Analysis
84
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

85
Part IIIModelling with UML 1.x

• Review, CSI 5112
• (extracts from Bruegge Dutoit, Lethbridge
  Laganière,
• and from the Borland UML tutorial)

86
Good UML Tutorials

• http//bdn.borland.com/article/0,1410,31863,00.htm
  l
• 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

87
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

88
Systems, Models and Views
Flight Simulator
Blueprints
Aircraft
Model 2
View 2
View 3
System
View 1
Electrical Wiring
Model 1
Scale Model
89
Models, Views and Systems (UML)
90
UML Evolution
UML 2.0
Revision Task Force, Nov 2003
UML 1.5
Revision Task Force, March 2003
UML 1.4
Revision Task Force, May 2001
UML 1.3
Revision Task Force, June 1999
Approval OMG, Nov 1997
UML 1.1
1st submission à OMG, Jan 1997
91
Contributions to UML 1.X
92
Models and Diagrams
93
RUP (Rational Unified Process) Models
A model may include many diagrams (views) using
many notations.
A notation may be used in several models.
94
Use Case Diagrams
association
actor
use case
generalization
is-a
relations
From LL
Use case diagrams represent the functionality of
the system from the users point of view
95
Content of a Use Case Bubble

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

96
Class Diagrams
Class diagrams describe the static structure of
the system Objects, Attributes, Associations
97
Object Diagrams
Snapshots of run-time objects and their links
98
Object Diagrams and Class Diagrams

RecordingCategory
Recording
hasCategory

description
title
subcategory
artist
Objects are instances of classes (with real
values), and links are instances of
associations. No inheritance, no multiplicities.
99
Activity Diagrams
Describe the dynamic behavior of a system as a
flow (sequence, alternative, parallel) of
activities (workflow).
100
Sequence Diagrams
Describe the dynamic behavior as interactions
between actorsand the system and between objects
of the system
101
Collaboration Diagrams
2-D view of sequence diagrams, with numbered
messages
102
Statechart Diagrams
Describe the dynamic behavior of an individual
object (with states and transitions)
103
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)
104
Package Diagrams
Show a structure of packages, which are
collections of logically related UML elements
used to simplify, manage, and reuse complex
models.
105
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

106
Dilbert on UML
107
Part IVEssential 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)

108
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

109
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

110
The Basics of Java

• History
• The first object oriented programming language
  was Simula-67
• Designed to allow programmers to write simulation
  programs
• In the early 1980s, Smalltalk was developed at
  Xerox PARC
• New syntax, large open-source library of reusable
  code, bytecode, platform independence, garbage
  collection.
• late 1980s, 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.

111
Tools and APIs

• Java2 API
• 1.4.2 http//java.sun.com/j2se/1.4.2/docs/api/ind
  ex.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

112
Primitive Data Types
113
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!

114
Arrays

• Declaration of an Array variable (of some type)
• double myArray // Initially worth null
• Creating an array (reserving memory for N
  elements)
• myArray new double5 // Valid indices 0 to 4
  
• Size of an array
• int theSize myArray.length // theSize 5
• Initializing an array during creation
• int array1 new int 3, 5, 4
• Arrays are reference types (not primitive types)
• int array2 array1
• array20 6 // Also changes array10 to 6!
• Multidimensional arrays (not limited to 2)
• int M
• M new int 1, 2, 3, 4, 5, 6

115
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) // gt 0
• // Many other operations in the String class

116
Operators and Their Precedence

• ( ) (expression) (array index) . (object
  member)
• (unary plus/minus) ! (negation)
• / (modulus)
• - (binary addition/substraction)
• lt gt gt lt
• !
• (logical AND)
• (logical OR)
• (assignment)

117
Control Structures

• Conditions
• if (x lt 5) // Boolean expression
• doThis() // list of instructions
• else
• doThat() // list of instructions
• Loops
• while (Test) // some Boolean expression
• body() // list of instructions
• for (int i 0 i lt 9 i)
• m m i // body, repeated 9 times

118
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!")

119
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

120
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

121
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.

122
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 MAXMINUTES60 // final means
  constant

123
Constructors

• Invoked 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 mgt59
• this.hours h m/60
• // Java uses garbage collection, hence
  destructors are not supported.
• Creation of objects with new
• Time t1 new Time() // Uses first constructor,
  hours minutes 0
• Time t2 new Time(3, 45) // Uses second
  constructor, 345

124
Inheritance

• import 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)

125
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 wrong
• Use a try - catch block to trap an exception
• try
• // some code
• catch (ArithmeticException e)
• // code to handle division by zero

126
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 Javas library include
• Runnable, Collection, Iterator, Comparable,
  Cloneable

127
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.

128
Threads and Concurrency

• Thread
• Sequence of executing statements that can be
  running concurrently with other threads
• To create a thread in Java
• Create a class implementing the Runnable
  interface or extending Thread
• Implement the run method as a loop that does
  something for a period of time
• Create an instance of this class
• Invoke the start operation, which in turn calls
  run

129
Dilbert on Programming