oo processes for software development course introduction cop 4331 and eel4884 © dr. david a....

OO Processes for

Software Development

Course Introduction

COP 4331 and EEL4884

© Dr. David A. Workman

School of EE and Computer Science

January 8, 2009

Jan 8, 2009 (C) Dr. David A. Workman 2

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.


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


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.


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

• References1. 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, Addison-Wesley, 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


Grading Policy• Programming Assignments

– 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

• Requirements and Design Modeling in UML – Individual & Team– Write Formal Specifications

• Simulation Project– 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% )

– 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

50% (30% Individual; 20% Team)


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


Grocery Store – The Virtual World

Entry

Exit

Ais

le 1

Ais

le 2

Cart Pool Conveyor

0

1

2

9

Aisle Delta

Checkout Queue

clerk

Ais

le n

Aisle Width

StartingPoint

SalesRegister

BaggingBin

bagg

er

ShopperEnters

Bagger ReturnsCart

Bagger& Shopper

Exit

CheckoutSubsyste

m

Shopper & Cart


Checkout Station Model

ConveyorScales

&Scanner

Clerk

BaggingBin

SalesTerminal

Bagger

Shopper Cart Cart

1: Shopper unloads groceryitems, if there is room on conveyor.

2: Shopper places plasticdivider on conveyor afterlast grocery item.

3: Conveyor has a fixedcapacity in numbers of items and transports themat a constant rate to theclerk’s station.

4:Clerk removes grocery itemsfrom conveyor and enterstheir identity and price intothe sales system. Some itemsare identified and priced bybar codes. Other items mustby manually identified and weighed.

5: When all items have been processed by the clerk, the shopperis presented with the total amountof the purchase.

6: The shopper pays for the groceriesand is given a sales receipt.

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 grocerybags with items that havebeen priced by the clerk.Bags are held in the bin until the cart becomes available from the shopper.

9:When the payment transaction has been completed and all bagshave been loaded in thecart, the shopper leavesthe store with the baggedgroceries.


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.


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]

Software ProcessIntroduction

COP 4331

© Dr. David A. Workman

School of EE and Computer Science

August 19, 2007


Process ModelsDefinition (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, scriptsProcessors = people: client, management, developers, administrative staff, application expertsAlgorithms = 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.)


Process Model: Example

RemoveGrocery

Item

Shopper (partition) Clerk (partition)

[Cart Not Empty]

PlaceItem on

Conveyor

PlaceDivider onConveyor

Take ItemFrom

Conveyor

Ring UpPrice

Ask ForPayment

[Item Not The Divider]

GiveCart toBagger

(join)

(condition check)

(activity)

(start)

(condition)

(sequential flow)

UML ActivityDiagram!!!!

(See Text Ch5.6)


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):

• System Engineering

• Software Requirements Analysis

• Software Design (Architectural & Detailed)

• Code and Unit Testing

• Integration

• Installation & Maintenance


Life Cycle vs. Development Cycle

“Cradle” “Grave”

Need and ConceptFormation

(Systems Eng.)

Obsolescenceand De-Commission

•Feasibility Study•System Architecture(Systems Eng.)

Software/Hardware Allocation(Systems Eng.)

Software RequirementsElicitation

(Requirements Model)

RequirementsElaboration

(Software RequirementsAnalysis and Spec.)

SoftwareDesign

Code &Unit Testing

ComponentIntegration

andSystem Test

DeliveryInstallation& Training

Operationand

Maintenance

Software Development Cycle

Software Engineering


Unified Process Model

RequirementsElaboaration

(OO-Analysis)

RequirementsElaboaration

(OO-Analysis)

Object-OrientedDesign

Object-OrientedDesign

Object-OrientedImplementation(Programming)

Object-OrientedImplementation(Programming)

Problem Statement& User NeedsUse Case

Model

The process of defining and modeling the Problem Space

The process of defining and modeling the Solution Space

Design & DeploymentModels

Code in anOOPL (Ada95)(C++)(Java)ComponentModel

Mapping design to Implementation Space

RequirementsElicitation(Capture)

RequirementsElicitation(Capture)

Analysis Model

The Unified Software Development Process, by Rumbaugh, Jacobson, and Booch, Addison-Wesley, 1999, 0-201-57169-2.


Software Requirements

Definition (IEEE)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 operationsc) Responses to abnormal situations, including

1) Overflow (resource depletion or unavailability)2) Communication facilities3) Error handling and recovery

d) Effect of parameterse) Relationship of outputs to inputs, including

1) Input/output sequences2) 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.

Reference: IEEE Standard 830-98, Recommended Practice for Software Requirements Specification


More on RequirementsReference: Wikipedia Search ("Software Functional Requirements")

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.

http://en.wikipedia.org/wiki/Requirements_analysis

http://en.wikipedia.org/wiki/Portal:Software

http://en.wikipedia.org/wiki/Use_case

http://en.wikipedia.org/wiki/Non-Functional_Requirements


http://en.wikipedia.org/wiki/Non-Functional_Requirements

http://en.wikipedia.org/wiki/Use_case

http://en.wikipedia.org/wiki/Artifact




Where We’re Going

1: RequirementsElicitation(Capture)

2: RequirementsElaboration(Analysis &

Specification)

3: SoftwareDesign

SoftwareDevelopment

Plan

SoftwareRequirements

Spec

Use CaseModel

Use CaseDiagram

CommunicationDiagram

ActivityDiagram

ModelSystem/Gui

behavior

ModelsActor/SystemInteractions

Define SystemBoundary;

Identify ActorsAnd External

Interfaces;Identify Use Cases

(functional capabilities)

AnalysisModel

ClassDiagram

PackageDiagram

Identify Boundary, Control Entity Classes and their Relationships

Identify Subsystemstheir Interfaces &

Relationships

Partitions Software into Work packages. Estimate cost, resources, size, and schedule.

DesignModel

Commun.Diagram

Defines computational processesand their concurrency/synchronizationrequirements.

A blueprint forimplementation.Incorporates bothfunctional and non-functional systemrequirements.

4: SoftwareConstruction

SourceCode

An executableform of the system. Sourceis written a suitableOOPL.

ActivityDiagram


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


Overview of USDP

• 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

Inception Elaboration Construction Transition

Birth Death

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion… …

Itera-tion

Itera-tion


Overview of USDP

• 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


Birth Death

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion… …

Itera-tion

Itera-tion


Overview of USDP

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


Birth Death

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion

Itera-tion… …

Itera-tion

Itera-tion


Overview of USDPUSDP Models

test1OK

test2OKUse Case Model

Analysis Model

Design Model

Test Model

Implementation Model Deployment

Model

implementedby

realizedby

specifiedby

distributedby

verifiedby


Overview of USDP

Core Work Flows

Requirements

Analysis

Design

Implementation

Test


Distribution of Core Activities Across Phases

Phases


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


Development Phase Breakdown

Integration = 24%

Unit Testing = 21%

Coding = 15%

Design = 19%

Specification = 15%

Requirements = 6%

(Schach - Classical and Object-Oriented Software Engineering)


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.


Boehm’s Spiral Model

2: Evaluate alternatives and their risks

1: Determine objectives, alternative solutions, & constraints.

4: Review outcome andPlan next cycle.

3: Develop, verify next

system increment.

risk analysis

prototyping

Design

Implementation

Planning

Review Test

Acceptance &

Installation


Measurement and Control

Metrics

Database

Development

Activity

Quality Review

Progress & Quality Analysis

Process Change

Directives

(Project Mangement)

Product Change

Directives

Quality

Products

Raw

Products

Product

Specifications

Effort and Size

Metrics Quality Metrics

Progress & Quality

Metrics