OO Processes
for
Software Development
Course Introduction
COP 4331 (or EEL4884)
© Dr. David A. Workman
School of EE and Computer Science
January 12, 2010
New Course Features!
•
•
•
•
COP 4331 is now required for CS majors! (Summer 2006 Catalog)
EEL 4884 is required for Cp E majors. This course should be taken
BEFORE you take Senior Design – do not take it in the same semester
with Senior Design II!
COP4331 is included in the set of Advanced Core Courses for which
CS majors must maintain a 2.5 GPA (Summer 2006 Catalog)
COP4331 is a 4 credit course
– TRF Lectures
– F Recitation/Lab Session will be used for lectures, quizzes, exams or labs,
whatever the Course Schedule dictates. It is therefore NOT optional that you
attend.
Jan 12, 2010
(C) Dr. David A. Workman
2
Course Objectives
•
Introduce Concepts, Principles, Methods, and Processes for developing large
software systems. Particularly those that relate to activities early in the
development cycle: OO requirements capture, requirements analysis and
specification, OO design, and OO implementation.
•
Developing a discipline of reading, understanding and adhering to constraints
imposed by requirements on the software development process.
•
Encourage students to become better OO software designers by applying principles
of “good design.”
•
Introduce students to discrete-event simulation using the message passing
paradigm and how to design simulators for real-world problem scenarios.
•
Introduce UML to students for use for modeling systems and specifying software
designs.
•
Introduce features of C++ suitable for large software systems development.
Jan 12, 2010
(C) Dr. David A. Workman
3
Assessment Outcomes
1. A passing student shall be able to construct correct UML diagrams of the
following types: Use Case Diagram, Class Diagram, Activity Diagram, State
Transition Diagram, Sequence Diagram and Data Flow Diagram.
2. A passing student shall be able to write a professional style technical
documentation for software systems; e.g. requirements model, design model,
and user guide.
3. A passing student shall demonstrate his or her ability to work cooperatively
and effectively as a member of a team.
4. A passing student shall demonstrate correct use of the following C++
features in a working program: IO streams, exception handling, friends,
namespaces, polymorphism and runtime binding, inheritance and subtyping,
and use of standard templates.
5. A passing student shall learn the fundamentals of project planning and
estimation by collecting basic software process and product metrics to
estimate personal software productivity.
6. A passing student shall be introduced to important software tools used to
develop and manage large software projects.
Jan 12, 2010
(C) Dr. David A. Workman
4
Text Books & References
•
Text Book: Object-Oriented Analysis and Design with Applications,
By Grady Booch et al., Addison-Wesley, 2007, ISBN=0-201-89551-X
•
References
1. UML Distilled: A Brief Guide to the Standard Object Modeling Language, by
Martin Fowler, Addison-Wesley, 2004.
2. The Rational Unified Process Made Easy, by Kroll and Kruchten, AddisonWesley, 2003.
– See handout for C++ and other related references.
•
Class Notes
–
–
–
http://www.cs.ucf.edu/~workman/cop4331/
Lecture material on OO development
Laboratory Manual for Programming Exercises
Jan 12, 2010
(C) Dr. David A. Workman
5
Grading Policy
•
Programming Assignments
–
–
–
–
–
•
Requirements and Design Modeling in UML
–
–
•
50% (30% Individual; 20% Team)
Team oriented
Collect Process and Product data
Write Formal Design Specifications
Code Discrete-event Simulator (C++)
All Lab Exercises must be Completed to Pass the Course!!!!
Quizzes ( 20% )
–
•
Individual & Team
Write Formal Specifications
Simulation Project
–
–
–
–
•
•
Individual & Team Assignments
Write design and code from formal specs.
Write Reusable Components for Simulation
Test and/or Analyze programs written by others
Collect Process and Product data
Encourages keeping up with course material on a regular basis.
Exams ( 30% )
Exams in this course are designed to be teaching as well as measuring instruments to evaluate
performance in this course – they will be challenging and do not expect to achieve perfection
– grades will be based on a “curve” and not on any absolute scale.
– Midterm exam
– Final exam
Jan 12, 2010
(C) Dr. David A. Workman
6
Discrete Event Simulation: A Case Study
•
Problem
Simulate the dynamic behaviors of shoppers and store personnel as they interact as
participants in the process of grocery checkout.
•
Features
–
–
–
–
The checkout system in a grocery store involves the coordination of several
concurrent processing activities. It therefore has several complexities and
characteristics common to the internal dynamics of modern operating systems
and distributed computing systems.
C++ programming exercises are designed to develop reusable simulator
components, thus illustrating the process of incremental development.
Software modeling and specification using UML.
Formal software documentation (Use Case and Design Models).
Jan 12, 2010
(C) Dr. David A. Workman
7
Grocery Store – The Virtual World
Aisle Width
Aisle n
Aisle 2
Aisle 1
9
2
1
0
Starting
Point
Aisle Delta
Exit
Cart Pool
Checkout
Queue
Conveyor
clerk
Entry
Shopper
Enters
Jan 12, 2010
Sales
Register
Bagger Returns
Cart
Bagging
Bin
bagger
Shopper & Cart
Bagger
& Shopper
Exit
Checkout
Subsyste
m
(C) Dr. David A. Workman
8
Checkout Station Model
6: The shopper pays for the groceries
and is given a sales receipt.
2: Shopper places plastic
divider on conveyor after
last grocery item.
5: When all items have been
processed by the clerk, the shopper
is presented with the total amount
of the purchase.
1: Shopper unloads grocery
items, if there is room on conveyor.
Shopper
Cart
Cart
Conveyor
3: Conveyor has a fixed
capacity in numbers of
items and transports them
at a constant rate to the
clerk’s station.
Scales
&
Scanner
Clerk
Bagging
Bin
Sales
Terminal
4:Clerk removes grocery items
from conveyor and enters
their identity and price into
the sales system. Some items
are identified and priced by
bar codes. Other items must
by manually identified and
weighed.
Jan 12, 2010
9:When the payment
transaction has been
completed and all bags
have been loaded in the
cart, the shopper leaves
the store with the bagged
groceries.
(C) Dr. David A. Workman
Bagger
7: When the cart has been
unloaded, the shopper gives
the cart to the bagger to be
filled with bags of groceries.
8:The bagger loads grocery
bags with items that have
been priced by the clerk.
Bags are held in the bin
until the cart becomes
available from the shopper.
9
Software Engineering
•
DEFINITION [Barry Boehm’76].
The practical application of scientific knowledge in the design and
construction of computer programs and the associated documentation
required to develop, operate, and maintain them.
–
–
–
–
–
•
Practical Applications
Scientific Knowledge
Design and Construction
Computer Programs and Documentation
Develop, operate, and maintain
DEFINITION [IEEE 1993]
1. The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of
engineering to software.
2. The study of approaches relevant to 1.
Jan 12, 2010
(C) Dr. David A. Workman
10
Computer Science
•
DEFINITION
Computer Science is concerned with the scientific study and description of
algorithms, programs, the devices that interpret them, and the phenomena
surrounding their creation and usage.
Software Engineering focuses on the application of this scientific
knowledge to achieve stated technical, economic, and social goals.
[Peter Freeman’80]
Jan 12, 2010
(C) Dr. David A. Workman
11
Software Process
Introduction
COP 4331
© Dr. David A. Workman
School of EE and Computer Science
August 19, 2007
Process Models
Definition (Process Models and Software Process)
Process models are “algorithms for developing software.”
Software process is “the execution of a process model.”
Data
= development artifacts : documents, source code, test programs and data, scripts
Processors = people: client, management, developers, administrative staff, application experts
Algorithms = methods + tools: languages, software tools, design methods
Definition (Software Process) A set of activities, methods, practices, and
transformations that people employ to develop and maintain software and its
associated artifacts (documents, etc.)
Jan 12, 2010
(C) Dr. David A. Workman
13
Process Model: Example
Clerk (partition)
Shopper (partition)
(start)
Remove
Grocery (activity)
Item
(sequential flow)
Place
Item on
Conveyor
Take Item
From
Conveyor
Ring Up
Price [Item Not
The Divider]
(condition check)
[Cart Not
Empty]
(condition)
Ask For
Payment
Place
Divider on
Conveyor
Give
Cart to
Bagger
UML Activity
Diagram!!!!
(See Text Ch5.6)
(join)
Jan 12, 2010
(C) Dr. David A. Workman
14
Process Models
Water Fall Model (Winston Royce ’70)
– First formal software development method (1950-70).
– Each development phase was completed before the next could begin.
– Documents produced as the output of one phase become inputs to the next phase.
– Did not allow for changing requirements. Frequently, the user was not happy
with the delivered system.
Phases (Activities focused to achieve specific objectives and to produce specific
artifacts):
•
•
•
•
•
•
Jan 12, 2010
System Engineering
Software Requirements Analysis
Software Design (Architectural & Detailed)
Code and Unit Testing
Integration
Installation & Maintenance
(C) Dr. David A. Workman
15
Life Cycle vs. Development Cycle
Software Development Cycle
“Grave”
“Cradle”
Need and Concept
Formation
(Systems Eng.)
Obsolescence
and De-Commission
Software
Design
Code &
Unit Testing
•Feasibility Study
•System Architecture
(Systems Eng.)
Component
Integration
and
System Test
Software/Hardware Allocation
(Systems Eng.)
Delivery
Installation
& Training
Software Requirements
Elicitation
(Requirements Model)
Requirements
Elaboration
(Software Requirements
Analysis and Spec.)
Operation
and
Maintenance
Software Engineering
Jan 12, 2010
(C) Dr. David A. Workman
16
Unified Process Model
Requirements
Elicitation
(Capture)
Use Case
Model
Requirements
Elaboaration
(OO-Analysis)
Analysis
Model
The process of defining
and modeling the
Problem Space
Object-Oriented
Design
Design &
Deployment
Models
Jan 12, 2010
Problem Statement
& User Needs
The Unified Software Development Process,
by Rumbaugh, Jacobson, and Booch,
Addison-Wesley, 1999, 0-201-57169-2.
The process of defining
and modeling the
Solution Space
Object-Oriented
Implementation
(Programming)
(C) Dr. David A. Workman
Mapping design to
Implementation
Space
Code in an
OOPL (Ada95)
(C++)(Java)
Component
Model
17
Software Requirements
Definition (IEEE)
Reference: IEEE Standard 830-98, Recommended Practice for Software Requirements Specification
Functional requirements should define the fundamental actions that must take place
in the software in accepting and processing the inputs and in processing and
generating the outputs. These are generally listed as "shall" statements starting
with "The system shall". These include:
a) Validity checks on the inputs [and report errors to appropriate users].
b) Exact sequence of operations
c) Responses to abnormal situations, including
1) Overflow (resource depletion or unavailability)
2) Communication facilities
3) Error handling and recovery
d) Effect of parameters
e) Relationship of outputs to inputs, including
1) Input/output sequences
2) Formulas for input to output conversion
It may be appropriate to partition the functional requirements into subfunctions or
subprocesses. This does not imply that the software design will also be partitioned
that way.
Jan 12, 2010
(C) Dr. David A. Workman
18
More on Requirements
Reference: Wikipedia Search ("Software Functional Requirements")
http://en.wikipedia.org/wiki/Requirements_analysis
A functional requirement defines a function of a software-system or its component. A function is described as a set of
inputs, the behavior, and outputs (see also software). Functional requirements may be calculations, technical details,
data manipulation and processing and other specific functionality that show how a use case is to be fullfilled. They are
supported by non-functional requirements, which impose constraints on the design or implementation (such as performance
requirements, security, or reliability).
As defined in requirements engineering, functional requirements specify particular behaviors of a system. This should be
contrasted with non-functional requirements which specify overall characteristics such as cost and reliability. (An alternative
view is that functional requirements specify specific behavior while non-functionals provide adjectives which may be used
to describe these behaviors.)
Typically, a requirements analyst generates functional requirements after building use cases. However this may have
exceptions since software development is an iterative process and sometimes certain requirements are conceived prior to
the definition of the use cases. Both artifacts (use cases documents and requirements documents) complement each other
in a bidirectional process.
A typical functional requirement will contain a unique name and number, a brief summary, and a rationale. This information
is used to help the reader understand why the requirement is needed, and to track the requirement through the development
of the system.
The core of the requirement is the description of the required behavior, which must be a clear and readable description of
the required behavior. This behavior may come from organizational or business rules, or it may be discovered through
elicitation sessions with users, stakeholders, and other experts within the organization. Many requirements will be uncovered
during the use case development. When this happens, the requirements analyst should create a placeholder requirement
with a name and summary, and research the details later, to be filled in when they are better known.
Software requirements must be clear, correct, unambiguous, specific, and verifiable.
Jan 12, 2010
(C) Dr. David A. Workman
19
Where We’re Going
2: Requirements
Elaboration
(Analysis &
Specification)
1: Requirements
Elicitation
(Capture)
Use Case
Model
Use Case
Diagram
Communication
Diagram
Software
Requirements
Spec
Activity
Diagram
Analysis
Model
Model
Models
Define System
System/Gui
Actor/System
Boundary;
behavior
Identify Actors Interactions
And External
Interfaces;
Class
Package
Identify Use Cases
Diagram
Diagram
(functional capabilities)
Identify Subsystems
their Interfaces &
Relationships
Jan 12, 2010
3: Software
Design
Commun.
Diagram
Identify Boundary,
Control Entity Classes
and their Relationships
Software
Development
Plan
4: Software
Construction
Design
Model
Partitions Software into
Work packages. Estimate
cost, resources, size, and
schedule.
A blueprint for
implementation.
Incorporates both
functional and nonActivity
functional system
Diagram
requirements.
Source
Code
An executable
form of the
system. Source
is written a
suitable
OOPL.
Defines computational processes
and their concurrency/synchronization
requirements.
(C) Dr. David A. Workman
20
•
UP Software Lifecycle
Definition
The complete history of a software system from concept formation through
decommission broken down into the following “maturation” activities (within
phases):
– Activity: requirements definition and capture (phase: Inception)
 Use Case Model
– Activity: requirements analysis and specification (phase: Elaboration)
 Analysis Model
– Activity: design (phase: Elaboration)
 Design Model + Deployment Model
– Activity: implementation (phase: Construction)  Component Model
• Coding
• Unit Testing
– Activity: component integration (phase: Construction)  Test Model
• Subsystem testing
• System testing (acceptance testing)
– Activity: operation & maintenance (phase: Transition)
• Corrective : removing bugs ( 17.5% )
• Enhancement: improving exiting capability = perfective ( 60.5%) + adaptive ( 18% )
– Retirement
Jan 12, 2010
(C) Dr. David A. Workman
21
Overview of USDP
Birth
Death
Inception
Itera- Iteration tion
•
Elaboration
Iteration
Iteration
Construction
Iteration
…
Iteration
Iteration
Transition
…
Itera- Itera- Iteration tion tion
Inception (focus on “Feasibility”)
Develop a vision of the end product and prepare a business case. Answers the
questions:
• What is the system boundary? Begin to identify interfaces with systems outside the
boundary.
• What is the system going to do? What are the major classes of users? (Develop
Initial Use Case Model )( Identify and describe major use cases and functional
requirements. )
• What is a possible system architecture? ( Identify most critical subsystems )
• What is the project plan? What will the system cost? ( Identify critical risks )
(Develop a Project Management Plan)
• Demonstrate feasibility by building a prototype.
•
•
•
Elaboration
Construction
Transition
Jan 12, 2010
(C) Dr. David A. Workman
22
Overview of USDP
Birth
Inception
Itera- Iteration tion
•
•
Death
Elaboration
Iteration
Iteration
Construction
Iteration
…
Iteration
Iteration
Transition
…
Itera- Itera- Iteration tion tion
Inception
Elaboration ( focus on “Do-Ability” )(Architecture + high-fidelity cost est.)
– Develop detailed use cases (80% of use cases).
– Develop a stable architectural view of the system using the Analysis Model, Design
Model, Implementation Model, and Deployment Model.
– Create a baseline system specification.
– Produce the Software Development Plan (SDP) which describes the next phase.
•
•
Construction
Transition
Jan 12, 2010
(C) Dr. David A. Workman
23
Overview of USDP
Birth
Inception
Itera- Iteration tion
•
•
•
Death
Elaboration
Iteration
Iteration
Construction
Iteration
…
Iteration
Iteration
Transition
…
Itera- Itera- Iteration tion tion
Inception
Elaboration
Construction (focus on building an operational capability)
Build the system (usually in increments defined by releases ). Each release
encapsulates defined use cases. Releases are ordered by priority determined by
customer needs and project risks.
•
Transition (focus on producing a formal release )
Product (release) enters beta testing and then distribution. This phase involves
manufacturing, training, and providing customer support infrastructure.
Transition ends with maintenance: corrective, adaptive, perfective.
Jan 12, 2010
(C) Dr. David A. Workman
24
Overview of USDP
USDP Models
Use Case Model
verified
by
test2
OK
specified
by
realized
by
implemented
by
Implementation
Model
Jan 12, 2010
test1
OK
Test Model
distributed
by
Analysis Model
Design Model
(C) Dr. David A. Workman
Deployment
Model
25
Overview of USDP
Phases
Inception
Elaboration
Construction
Transition
Requirements
Analysis
Core
Work
Flows
Design
Implementation
Test
Distribution of Core Activities Across Phases
Jan 12, 2010
(C) Dr. David A. Workman
26
Software Development Process
•
Definition
An organized and structured set of procedures, tools, standards, and techniques for
producing software as defined by the following lifecycle phases.
– Requirements definition phase: system concept is refined and customer and user
requirements are elicited.
– Requirements analysis and specification phase: a formal (complete, precise,
consistent, and unambiguous) description of “what” the system must do is
prepared by the developer and reviewed by the customer (system specification
document); a software development plan is produced at the end of this phase.
– Design phase: The specification is elaborated in two steps that define “how” the
system will work: Architectural Design breaks down the whole system into
component parts (modules) and the interactions between them (interfaces);
Detailed Design involves elaborating the design of individual components by
specifying data structures and algorithms.
– Implementation phase: Designs are translated to code and unit tested.
– Integration phase: Components are integrated into larger functional aggregates
(subsystems) and tested in the target operational environment. The final step tests
the complete system (acceptance testing – customer agrees that the system meets
the specification).
Jan 12, 2010
(C) Dr. David A. Workman
27
Development Phase Breakdown
Requirements = 6%
Integration = 24%
Specification = 15%
Unit Testing = 21%
Design = 19%
Coding = 15%
(Schach - Classical and Object-Oriented Software Engineering)
Jan 12, 2010
(C) Dr. David A. Workman
28
Meta Process Models
•
Spiral Model
A cyclic approach to software development marked by four basic stages that
are repeated on each cycle until the target system is delivered. A risk-driven
meta model.
– Developed by Barry Boehm, “A Spiral Model of Software Development and
Enhancement”, IEEE Computer, Vol 21, No 5, May 1988.
Stage 1: Identify objectives, alternative solutions, and constraints for the part
of the system currently under consideration.
Stage 2: Evaluate alternatives and identify associated risks using prototyping
and simulation.
Stage 3: Develop and verify the next system increment.
Stage 4: Review outcome of earlier stages and plan the next cycle.
Jan 12, 2010
(C) Dr. David A. Workman
29
Boehm’s Spiral Model
2: Evaluate alternatives and
their risks
1: Determine objectives,
alternative solutions, &
constraints.
risk analysis
prototyping
Acceptance
&
Installation
Planning
Design
Implementation
Review
Test
4: Review outcome and
Plan next cycle.
Jan 12, 2010
(C) Dr. David A. Workman
3: Develop, verify next
system increment.
30
Boehm’s Spiral Model
1: ____________________
______________________
2: ____________________
______________________
Acceptance
&
Installation
4: ____________________
______________________
Jan 12, 2010
(C) Dr. David A. Workman
3: ____________________
______________________
31
Measurement and Control
(Project Mangement)
Process Change
Directives
Progress & Quality
Progress &
Quality Analysis
Metrics
Effort and Size
Metrics
Product
Development
Raw
Specifications
Activity
Products
Metrics
Quality Metrics
Quality
Review
Database
Quality
Products
Product
Change
Directives
Jan 12, 2010
(C) Dr. David A. Workman
32