Daniel Amyot - PowerPoint PPT Presentation

Loading...

PPT – Daniel Amyot PowerPoint presentation | free to view - id: 6e97a-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Daniel Amyot

Description:

[http://www.wired.com/news/technology/bugs/0,2924,69355,00.html and other sources] ... AT&T's #4ESS long distance switches causes these mammoth computers to crash. ... – PowerPoint PPT presentation

Number of Views:170
Avg rating:3.0/5.0
Slides: 130
Provided by: daniel642
Category:
Tags: amyot | daniel | mammoth

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com