welcome
1
Object Oriented
Software Systems Engineering
Meetings: Every second Saturday, 9:00-15:30pm
Instructor: Panayiotis Alefragis ([email protected])
2
Course Topics

Software development methodology







Object-oriented
What is most likely to happen in real world
software development
Requirements analysis
Domain analysis and modeling
Design
Iterative development with Java
Testing
3
Goals



Apply requirements and domain analysis
Apply design with objects
Apply patterns – principles and idioms to use





Object-oriented design
 Assigning responsibility to software components
Apply UML
Learn an Object Oriented Language (Java)
Apply iterative development
Apply testing strategies
4
Lecture Outline

Intro







Topics
Goals
Prerequisites
Overview Example
Syllabus
Software Engineering Principles
Iterative Development and the Unified
Process (UP)
5
Overview Example, Step 1:
Requirements, Use-Case Model


Not an object-oriented step.
Use case: Play Dice Game
Main success scenario:
 Player picks up the two dice and rolls them.
 If face value is 7 then they win…
 Else …
6
Example, Step 2: Domain Model
Player
1
Rolls
2
name
Die
face value
1
2
Plays
1
Dice Game
1
Includes
7
Example, Step 3:
Design: Interaction Diagram

Dynamic object design
:Dice Game
play()
Die1 :Die
Die2 :Die
roll()
fv1:= getFaceValue()
roll()
fv2:= getFaceValue()
8
Example, Step 3:
Design: Class Diagram

Static design
Dice Game
play()
1
2
Die
faceValue : int
getFaceValue() : int
roll()
9
Example, step 4:
Object-oriented Program
Dice Game
die1 : Die
die2 : Die
class DiceGame {
private Die die1 = new Die();
private Die die2 = new Die();
play()
:Dice Game
public void play() {
die1.roll();
int fv1 = die1.getFaceValue();
…}
}
play()
Die1 :Die
Die2 :Die
roll()
fv1:=getFaceValue()
fv2:=getFaceValue()
roll()
10
Artifact Influence
Domain
Model
Use-Case
Model
Design Model
(Static and Dynamic Diagrams)
OO Code
(Java, C++, C#)
11
Syllabus

What are we going to do in this class?
Project
Intro
Require
ments
and Use
Cases
1 week
UML
Structural
Diagrams
UML
Behavioral
Diagrams
Complete
Design
Example
1 week
Introduction
to Java
1 week
Selection &
Integration
OOAD with
Developme
nt Tools
Company
issues
Testing
Deployment
2 weeks
Advanced Java
GUI, Threads, Exceptions,
Network, security, JDBC
Patterns
Frameworks
Architectures
1 week
Enterprise
Programming
12
Syllabus
Project
Presentations
Due:
Documents,

Design model
& Final Code

Teams of 2-4 people
Assignment:


Exams

Write your resume
To be used for team
selections.
Email them to me until
next Friday
13
Syllabus

What are we going to use in this class?



Visual Paradigm Suite(CASE tool)
JBuilder (IDE tool)
Books




UML Distilled 3rd Edition
Applying UML and Patterns
Object Oriented Design with Java and UML
Java How to Program
14
Lecture Outline

Intro







Topics
Goals
Prerequisites
Overview Example
Syllabus
Software Engineering Principles
Iterative Development and the Unified
Process
15
1.1 The Nature of Software...

Software is intangible


Software is easy to reproduce


Hard to understand development effort
Cost is in its development
 in other engineering products, manufacturing is
the costly stage
The industry is labor-intensive

Hard to automate
16
The Nature of Software ...

Untrained people can hack something
together


Software is easy to modify


Quality problems are hard to notice
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
17
it complex
The Nature of Software

Conclusions




Much software has poor design and is getting
worse
Demand for software is high and rising
We are in a perpetual ‘software crisis’
We have to learn to ‘engineer’ software
18
Types of Software...

Custom


Generic



For a specific customer
Sold on open market
Often called
 COTS (Commercial Off The Shelf)
 Shrink-wrapped
Embedded


Built into hardware
Hard to change
19
Types of Software

Differences among custom, generic and
embedded software
Custom
low
Generic
medium
Embedded
high
Total processing power
devoted to running this type
of software
low
high
medium
Worldwide annual
development effort
high
medium
low
Number of copies in use
20
Types of Software

Real time software




Data processing software



E.g. control and monitoring systems
Must react immediately
Safety often a concern
Used to run businesses
Accuracy and security of data are key
Some software has both aspects
21
1.2 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
22
to identify and understand the problem
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
23
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
24
1.3 Software Engineering and the
Engineering 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 artifacts following well accepted practices
which involve the application of science, mathematics and
economics
Ethical practice is also a key tenet of the profession
25
1.4 Stakeholders in Software
Engineering

1. Users


2. Customers




Those who use the software
Those who pay for the software
3. Software developers
4. Development Managers
All four roles can be fulfilled by the same
person
26
1.5 Software Quality...

Usability


Efficiency


It does what it is required to do without failing
Maintainability


It doesn’t waste resources such as CPU time and memory
Reliability


Users can learn it and fast and get their job done easily
It can be easily changed
Reusability

Its parts can be used in other projects, so reprogramming is not
needed
27
Software Quality...
Customer:
solves problems at
an acceptable cost in
terms of money paid and
resources used
User:
easy to learn;
efficient to use;
helps get work done
QUALITY
SOFTWARE
Developer:
easy to design;
easy to maintain;
easy to reuse its parts
Development manager:
sells more and
pleases customers
while costing less
to develop and maintain
28
Software Quality

The different qualities can conflict



Setting objectives for quality is a key
engineering activity



Increasing efficiency can reduce maintainability or
reusability
Increasing usability can reduce efficiency
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
29
fixed budget
Internal Quality Criteria

These:



Characterize aspects of the design of the software
Have an effect on the external quality attributes
E.g.
 The amount of commenting of the code
 The complexity of the code
30
Short Term Vs. Long Term Quality

Short term:



Does the software meet the customer’s immediate
needs?
Is it sufficiently efficient for the volume of data we
have today?
Long term:


Maintainability
Customer’s future needs
31
1.6 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
32
Software Engineering Projects

‘Green field’ projects


New development
The minority of projects
33
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 this organization.
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.
34
1.7 Activities Common to
Software Projects...

Requirements and specification

Includes
 Domain analysis
 Defining the problem
 Requirements gathering


Requirements analysis


Obtaining input from as many sources as possible
Organizing the information
Requirements specification

Writing detailed instructions about how the software
should behave
35
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
36
Activities Common to Software
Projects

Modeling



Programming
Quality assurance




Creating representations of the domain or the software
 Use case modeling
 Structural modeling
 Dynamic and behavioural modeling
Reviews and inspections
Testing
Deployment
Managing the process
37
1.9 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
38
Lecture Outline

Intro







Topics
Goals
Prerequisites
Overview Example
Syllabus
Software Engineering Principles
Iterative Development and the Unified
Process
39
Iterative Development and
the Unified Process (UP)

Iterative Development




A software development methodology
Repeat software development disciplines, such as
analysis, design, etc.
State-of-the-art approach
The Unified Process



An instance of iterative development
Well-known, you are likely to be exposed to it
Other: XP, Agile development, etc.
40
The Sequential “Waterfall”
Lifecycle
Most requirements,
Defined and Stabilized
Design
Implementation
Integration and
Testing
Long lifecycle 6 months
41
Iterative Lifecycle:
Short Iterations
Requirements
Design
Requirements
feedback
Implementation &
Test & Integration
& More Design
Implementation &
Test & Integration
& More Design
Final Integration &
System Test
Short 2-6 weeks
Design
Final Integration &
System Test
Iterations are
fixed in length,
timeboxed
System grows
incrementally
42
Iterative Development Lifecycle
1
Use case:
process sale
2
Use case:
process sale
3
…
Use case:
process sale
New use case:
process rental
43
Disciplines Across Iterations
UP Disciplines
Business Modeling
Requirements
Design
Implementation
…
44
Key Ideas in UP

High risks early on, drive down



Test and validate early


Managerial
Technical
 Integration of subsystems, as early as possible
Related to risk
Feedback
45
Key Ideas in UP


Research shows that UP works better than
the “waterfall” approach. Why?
Change
46
Disciplines Across IterationsTransition
UP Disciplines
Inception
Elaboration
Construction
Business Modeling
Requirements
Design
Implementation
…
47
Our Course
Requirements &
use case modeling
inception
OO
Analysis
Other
requirements
elaboration
OO
Design
…
Translating
Design to
Code
48
True or false?

Inception = Requirements

Elaboration = Design

Construction = Implementation

But…
49
Object Orientation

Analyzing requirements?

Design?

Construction? Maintenance?

Usability?
50