Object Oriented Software Engineering

1
Software Engineering
Deliver yesterday, code today, think tomorrow ??
2
What is software

• Software is a set of items or objects that
  form a "configuration" that includes
• Programs
• documents
• data ...

3
What is software Engineering

• IEEE, 1990
• (1) The application of a systematic,
  disciplined,
• quantifiable approach to the development,
  operation, and maintenance of quality software
  and software services
• that is, the application of engineering to
  software.
• (2) The study of approaches as in (1)

4
Software Engineering Computer Science

• CS to SE is as Chemistry to CE.
• CS and programming languages are only tools to
  SE.
• Wring SE is art and need to be an engineering.
• Any one can write code to solve a problem but
  only SE can produce code that is robust and easy
  to understand and maintain and does it in most
  efficient way.

5
What is a Software Engineering Process ?

• Defines Who is doing What, When to do it,
• and How to reach a certain goal.

• The software engineering process is the process
  of developing a system from requirements, either
  new or changed.
• It is a controlled approach to a development task
  which follows a number of predefined activities
  and milestones and has a means to control and
  monitor the progress.

6
The course structure

• The backbone course for SE
• Semester A SW Design
• Semester B From Design to SW Product
• Actually is one course with two parts
• Final result an working SW product
• Same methods will be used next year for the
• final project

7
Semester A Design

• Application Requirements Definition .
• Application Requirements Analysis
• Software Requirements Specification
• UML
• Software Design
• Design for Software Quality assurance

8
Semester B Implementation

• Employees manag.
• DBA
• Coding
• Documentation
• Testing
• Performance tuning
• User training

• Installation
• versions control
• Maintenance
• Packaging
• Sales support
• Planing for new version

9
Cost of errors

• In the definition - X 1
• In the developments - X 1.5 - 6
• In the Maintenance - X 60 - 100

10
The Two Approaches to Solve it

• The Intuitive - ART
• Apply Engineering Processes

11
Cost of software

• Ratio of hardware to software procurement cost
  approaches zero
• Total cost of ownership 5 times cost of
  hardware.
• Gartner group estimates cost of keeping a PC for
  5 years is now 7-14k

12
Why Software Engineering Matters

• SW contribution to USeconomy ( 1996 fgures)
• Greatest trade surplus of exports
• 24B software exported, 4B imported, 20B
  surplus.
• Compare agriculture 26-14-12, aerospace 11-3-8,
• chemicals 26-19-7,vehicles
  21-43-( 22) ,
• manufactured goods
  200-265-( 64)

13
Development failures 1

• IBM survey, 1994
• 55 of systems cost more than expected
• 68 overran schedules
• 88 had to be substantially redesigned

14
Development failures 2

• Advanced Automation System ( FAA, 1982-1994)
  
• Industry average was 100/line,
• Expected to pay 500/ line
• Ended up paying 700-900/ line
• 6B worth of work discarded

15
Development failures 3

• Bureau of Labor Statistics ( 1997)
• for every 6 new systems put into operation, 2
  cancelled
• probability of cancellation is about 50 for
  biggest systems
• Average project overshoots schedule by 50
• 3/ 4 systems are regarded as operating failures .

16
Accidents caused by Software

• The most likely way for the world to be
  destroyed,
• most experts agree, is by
  accident.
• That is where we come in.
• We are computer professionals

17
Accidents caused by Software

• We cause accidents!
• Nathaniel Borenstein, inventor of MIME, 1991

18
The IBM OS/360 1963-1966

• At peak over 1000 people were working on it.
• Total more then 5000 man-years.
• The initial plan 200 people would take 25
  years.
• Brooks law
• Adding manpower to a late project make it
  later!

19
IRS (1980-1985)

• IRS ask Sperry Corporation to build new system.
• Budget for 50 million Cost 104 million and then
  need 90 million to make it work.
• IRS pay 40 million interest and 22 million for
  overtime for manual work.
• in 1996 a 6000 pages report documentation for
  improvements.

20
The Therac-25 1985-1987

• A radiation therapy and X ray machine killed
  sveral patients.
• The software designer had not anticipate the use
  of deveral arrow keys in nonstandard ways.
• The software retained high setting and issue a
  highly concentrated dose of radiation when low
  levels were intended.

21
Polcemans in Scotland

• Two polcemans in Scotland were using a radar gun
  to indentify speeding motorists.
• The software malefunction and cause the radar to
  output twice the intesity and an low-flying
  Harrier jet flew by.
• It automatically start the fire on enmy''
  procedure.
• Luck is the plane was unarmed.

22
London Ambulance Service ( 1992)

• loss of calls, double dispatches from duplicate
  calls
• poor choice of developer inadequate experience
  
• see http / / www. cs.ucl. ac. uk/ staf/ A.
  Finkelstein/ las. html

23
Denver International Airport's automated baggage
handling system (1991-1995)

• Main contractor BAE - Boeing Airport Equipment.
• 300 486-class computers distributed in eight
  control rooms.
• 22 miles of track, 6 miles of conveyer belts,
  3100 standard telecars.
• 10000 monitors.
• Estimated cost was 193 million real cost was
  311.

24
Denver International Airport's automated baggage
handling system (1991-1995)

• Opening date set for October 31st 1993
• Finally began operations on February 28th, 1995
• Every month that they remained closed was about
  33.3 million.
• Total damage of more then 16X33 gt 500 million.
• Lack of planning and communication of the overall
  architecture doomed the project to failure almost
  right from the start.

25
Ariane-5 ( June 1996)

• European Space Agency Cost USD 500 milion.
• Complete loss of unmanned rocket shortly after
  take of due to exception thrown in Ada.
• Faulty code was not even needed after take of
• Due to change in physical environment
  undocumented assumptions violated
• see http / / www. esa. int/ htdocs/ tidc/
  Press/ Press96/ ariane5rep.

26
Mars Climate Orbiter (1998)

• NASA Mars Climate Orbiter Launched December 11,
  1998 - cost US327 million.
• On September 23 1999 it smashed into the
  planet's atmosphere and was destroyed.
• Engineers failed to convert English measures of
  rocket thrusts to newton,a factor of 2.2 in the
  navigation-related mission software.
• Large, complex software projects are so complex
  that they can fail even when methodologies are
  followed to the letter.

27
Software limits - scale

• Reagan propose in 1985 the Stratigic Defence
  Initiative (SDI) which include fault fr software
  system.
• It was estimate the antibalistic such system
  would required at least 10 milion lines of code
  and the upper estimate was talking about 100
  milions.
• In comparation in 1985 The Amrican space shuttle
  program consiste of 3 milions lines of code.

28
Software Development Why is it so Challenging
(Difficult) ?

• Software development is a highly intellectual
  activity and so is heavily dependent on human
  thought
• No valid theoretical models of software
  development exist
• No laws of software physics that can define
  logical constraints and relationships between
  various variables in the project and product
  environment

29
The Nature of Software (Brooks)

• The software essence
• Complexity
• Conformity
• Changeability
• Invisibility
• The software accidents
• Stakeholders
• Process
• Modeling language and tools

30
Process Structure

• A Framework
• SE paradigms
• A culture
• Development methodology
• QA methodology
• Engineering Components
• Requirements
• Analysis and Design
• Implementation
• Testing
• Supporting Components
• Management
• Deployment
• Environment
• Tools

31
Software Development Strategy
32

• Manage risks to avoid catastrophic setbacks
• Risk Assessment (identification, analysis,
  prioritization)
• Risk Control (planning, resolution, monitoring)

You have to keep schedule, cost, and product in
balance for the project to succeed
Schedule
Cost
Product
33
Development Life-Cycle
34
Software Lifecycle Phases

• Coarse granularity
• Analysis
• Design
• Implementation
• Maintenance
• Refined granularity
• Application Requirements determination
• Software Requirements specification
• Architectural design
• Detailed design
• Implementation
• Integration
• Testing

35
Application Requirements Phase

• Requirement statement of a system service or
  constraint
• Service
• Business rule
• Computation
• Constraint
• Information gathering
• Requirements document

36
Software Specification Phase

• Application Requirements document ? Software
  Specification document
• Visual modeling
• Class diagrams
• Use case models
• Implementation independent

37
Architectural Design

• Solution strategy
• Client
• Server
• Application logic layer
• Modules
• UML
• Packages
• Components
• Deployment

38
Detailed Design

• User interface (client)
• Database (server)
• Application logic
• Algorithms
• Functions
• Methods

39
Implementation

• Coding
• Testing
• Performance tuning
• DBA
• Installation
• User training

40
Integration

• Incremental integration
• Dependencies between modules (coupling)
• Stubs
• Drivers
• Uniform distribution of intelligence in modern OO
  systems
• Designing OO systems for integration

41
Maintenance

• Housekeeping
• Adaptive maintenance
• Perfective maintenance
• Software phasing-out
• Perfective maintenance cannot help
• Unpredictable effects of changes
• Lack of documentation
• Platform to be replaced

42
Basic Life Cycle Models

• Linear
• The Waterfall
• The W
• Spiral

43
The Waterfall Model (B.W. Boehm)
44
W - Whole Life Cycle
Write Req.
Test Req.
Acceptance Test
Install
Test Design
Build System
System Test
Logical Design
Build Software
Test Design
Physical Design
Integration Test
Code
Unit Test
45
Traditional Life Cycle

• Linear, sequential phases
• No overlap between phases
• Assumes stable requirements up-front
• Even if everything goes right, whats wrong ?

46
Spiral (I 3) Life Cycle

• Antithesis of Waterfall
• Iterative - many refinements
• Incremental - moving forward
• functions, features, quality
• Integrative - continual integration of work
  products
• Non-linear, evolving prototypes
• More time spent in Analysis Design
• Less time spent in Development

Risk Analysis
Plan
Development
Validation
47
The Spiral (I 3) Philosophy

• Supports the notion of cycles
• Is Iterative-Incremental-Integrative
• Is an Evolutionary Delivery Model
• Supports System Thinking

48
The Rational Unified Process(RUP)
49
Characteristics of the Process

• Iterative Process
• Architecture Centric
• Software Modeling
• Use Case Driven
• Supports Object-Oriented techniques
• Scalable
• Ongoing Quality Control Risk Management

50
Phases and Iterations (2)

• A phase is the span of time between two
  major milestones of the process in which a
  well-defined set of objectives are met, artifacts
  are completed, and decisions are made whether to
  move into the next phase.
• Four phases
• Inception - Establish the business case
  for the project
• Elaboration - Establish a project plan and a
  sound architecture
• Construction - Grow the system
• Transition - Supply the system to its end
  users
• An iteration represents a complete
  development cycle, from requirements capture in
  analysis to implementation and testing, that
  results in the release of an executable project.

51
Phases and Iterations (1)
52
Software Development Methodology
53
The Three Dimensions of a System

• Static
• Represents the static, structural, data
  aspects of a system.
• Dynamic
• Represents the temporal, behavioral,
  control aspects of a system.
• Functional
• Represents the transformational,
  function aspects of a system.

Functional (flow/processes)
Static (Objects)
Dynamic (events/states)
54
Software Development Approaches

• The past
• Procedural programs
• Deterministic execution
• Program in control
• The present
• Interactive program
• Event-driven execution
• Objects
• Structured vs. Object-Oriented

55
The Structured (SSAD) Approach

• Modeling Techniques
• Hierarchical Functional System Decomposition
• Graphical Description by Data Flow Diagrams
  (DFDs)
• Entity Relationship Diagrams (ERDs)
• State Diagrams (STDs)
• Data Dictionaries
• Structure Charts
• Problems
• Sequential and transformational
• Inflexible solutions
• No reuse

56
The Object Oriented Approach

• The focus is on
• Responsibility and Roles
• Co-operation and Collaboration between objects
• The 3 aspects of a system (Function, Data and
  Behavior) are melted into one concept and are
  considered as one unit

57
Object-Oriented Approach

• Data-centric
• Addresses emerging applications
• Addresses application backlog
• Follows iterative and incremental process
• Problems
• Project management
• Solution complexity

58
Structured vs. Object Oriented

• In structured approach the system decomposition
  (divide-and-conquer) is primarily by function or
  process, resulting in a hierarchical breakdown of
  processes composed of sub-processes. This is a
  solution oriented approach.
• In Object Oriented approach the problem space is
  decomposed by objects. This is a problem domain
  oriented approach.

59
Structured vs. OO Example
The Library Information System
Structured A/D Decomposed by functions or
processes
Object Oriented A/D Decomposed by objects or
concepts
System
Catalog
Librarian
Report Fines
Record Loans
Add Resources
Book
Library
60
Software Modeling
61
What is a Model ?

• A model is an abstraction of something for
  the purpose of understanding it before building
  it.
• Models serve several purposes
• Understanding the problem
• Testing a physical entity before building it
• Communication with customers
• Visualization
• Reduction of complexity
• Finding errors and omissions
• Planning the design
• Generating code

62
Why do we model?

• Furnish abstractions to manage complexity.
• Provide structure for problem solving.
• Experiment to explore multiple solutions.
• Reduce time-to-market for business problem
  solutions.
• Decrease development costs.
• Manage the risk of mistakes.

63
What is Visual Modeling?
Modeling captures essential parts of the
system. Dr. James Rumbaugh
Visual Modeling is modeling using standard
graphical notations
64
Object Modeling Methods

• Following is a list of the most common methods
  that are in use
• OOD G. Booch 1991
• HOOD HOOD Technical Group 1993
• OOA S. Shlaer and S. Mellor 1988, 1992
• OOA/OOD T. Coad and Y. Yourdan 1991
• OMT J. Rambaugh, M. Blaha, 1991
• OOSE I. Jacobson, 1992
• FUSION D. Coleman, 1994
• UML Booch, Rambaugh, Jacobson 1998

65
Object Management Group (OMG)

• Was founded in April 1989 by eleven companies,
  including 3Com, American Airlines, Canon, Data
  General, HP, Philips, Sun and Unisys Corporation.
  
• Establishment of industry guidelines and
  standardized object software modeling to provide
  a common framework for application development.
• http//www.omg.org/news/about/

66
What is the UML ?

• OMG's Unified Modeling Language (UML)
• Helps you specify, visualize, and document models
  of software systems, including their structure
  and design, in a way that meets all of these
  requirements.

67
UML

• UML stands for Unified Modeling Language
• The UML is the standard language for visualizing,
  specifying, constructing, and documenting the
  artifacts of a software-intensive system
• It can be used with all processes, throughout the
  development life cycle, and across different
  implementation technologies.

68
History of the UML
69
Unified Modeling Language - UML

• The UML is a notational system (including
  semantics for its notations) aimed at modeling
  system using object-oriented concepts.
• The UML has been accepted as an industry standard
  for object-oriented modeling by OMG (Object
  Management Group, an industry standards body).
• The UML is a language for software modeling it
  does not guide a developer in how to do
  object-oriented analysis and design or what
  development process to follow, but it provides
  framework and the communication mechanism in the
  process of designing OO systems.

Process
Tool
70
Development Life Cycle with UML
2) Problem DomainConcepts
1) Use Case Model
3) Conceptual Model
Define Apll. Requirements
Development Cycle 1
Application Req. Analysis
Development
1) Class Diagrams
2) Sequence Diagrams
3) Collaboration Diagrams
Software Req. Analysis
5) Activity Diagrams
4) State Charts
6) Use Case Model Refinements
Development Cycle 2
Design
...
1) Collaboration Diagrams Refin.
2) Class Diagrams Refin.
Construction
4) Component Diagrams
3) Package Diagrams
5) Deployment Diagrams
Testing
71
The basic building blocks of UML

• model elements (classes, interfaces, components,
  use cases, etc.)
• relationships (associations, generalization,
  dependencies, etc.)
• diagrams (class diagrams, use case diagrams,
  interaction diagrams, etc.)
• Simple building blocks are used to create large,
  complex structures.

72
Formal Modeling Methods

• Mathematics-based
• Unambiguous
• For specification/requirements
• usually including correctness proof rules
• usually including specific notations
• usually including process/methodology
• usually including tools
• The Z Notation
• Specification Description Language - SDL

73
Summary

• Nature of software development craft or even
  art
• The triangle for success stakeholders, process,
  modeling language and tools
• The software development lifecycle
• Structured development approach
• Object-oriented development approach
• Software Modeling