1. OO Processes for Software Development Course Introduction COP 4331 and EEL4884 © Dr. David A. Workman School of EE and Computer Science January 8, 2009

2. Jan 8, 2009(C) Dr. David A. Workman2 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.

3. Jan 8, 2009(C) Dr. David A. Workman3 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.

4. Jan 8, 2009(C) Dr. David A. Workman4 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.

5. Jan 8, 2009(C) Dr. David A. Workman5 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, 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

6. Jan 8, 2009(C) Dr. David A. Workman6 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)

7. Jan 8, 2009(C) Dr. David A. Workman7 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).

8. Jan 8, 2009(C) Dr. David A. Workman8 Grocery Store – The Virtual World Entry Exit Aisle 1 Aisle 2 Cart Pool Conveyor 0 1 2 9 Aisle Delta Checkout Queue clerk Aisle n Aisle Width Starting Point Sales Register Bagging Bin bagger Shopper Enters Bagger Returns Cart Bagger & Shopper Exit Checkout Subsyste m Shopper & Cart

9. Jan 8, 2009(C) Dr. David A. Workman9 Checkout Station Model Conveyor Scales & Scanner Clerk Bagging Bin Sales Terminal Bagger Shopper Cart 1: Shopper unloads grocery items, if there is room on conveyor. 2: Shopper places plastic divider on conveyor after last grocery item. 3: Conveyor has a fixed capacity in numbers of items and transports them at a constant rate to the clerk’s station. 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. 5: When all items have been processed by the clerk, the shopper is presented with the total amount of the purchase. 6: The shopper pays for the groceries and 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 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: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.

10. Jan 8, 2009(C) Dr. David A. Workman10 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.

11. Jan 8, 2009(C) Dr. David A. Workman11 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]

12. Software Process Introduction COP 4331 © Dr. David A. Workman School of EE and Computer Science August 19, 2007

13. Jan 8, 2009(C) Dr. David A. Workman13 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.)

14. Jan 8, 2009(C) Dr. David A. Workman14 Process Model: Example Remove Grocery Item Shopper (partition) Clerk (partition) [Cart Not Empty] Place Item on Conveyor Place Divider on Conveyor Take Item From Conveyor Ring Up Price Ask For Payment [Item Not The Divider] Give Cart to Bagger (join) (condition check) (activity) (start) (condition) (sequential flow) UML Activity Diagram!!!! (See Text Ch5.6)

15. Jan 8, 2009(C) Dr. David A. Workman15 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

16. Jan 8, 2009(C) Dr. David A. Workman16 Life Cycle vs. Development Cycle “Cradle” “Grave” Need and Concept Formation (Systems Eng.) Obsolescence and De-Commission Feasibility Study System Architecture (Systems Eng.) Software/Hardware Allocation (Systems Eng.) Software Requirements Elicitation (Requirements Model) Requirements Elaboration (Software Requirements Analysis and Spec.) Software Design Code & Unit Testing Component Integration and System Test Delivery Installation & Training Operation and Maintenance Software Development Cycle Software Engineering

17. Jan 8, 2009(C) Dr. David A. Workman17 Unified Process Model Requirements Elaboaration (OO-Analysis) Requirements Elaboaration (OO-Analysis) Object-Oriented Design Object-Oriented Design Object-Oriented Implementation (Programming) Object-Oriented Implementation (Programming) Problem Statement & User Needs Use Case Model The process of defining and modeling the Problem Space The process of defining and modeling the Solution Space Design & Deployment Models Code in an OOPL (Ada95) (C++)(Java) Component Model Mapping design to Implementation Space Requirements Elicitation (Capture) Requirements Elicitation (Capture) Analysis Model The Unified Software Development Process, by Rumbaugh, Jacobson, and Booch, Addison-Wesley, 1999, 0-201-57169-2.

18. Jan 8, 2009(C) Dr. David A. Workman18 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 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. Reference: IEEE Standard 830-98, Recommended Practice for Software Requirements Specification

19. Jan 8, 2009(C) Dr. David A. Workman19 More on Requirements Reference: 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).softwareuse casenon-functional requirements 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.)requirements engineeringnon-functional requirements 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.use casesartifacts 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

20. Jan 8, 2009(C) Dr. David A. Workman20 Where We’re Going 1: Requirements Elicitation (Capture) 2: Requirements Elaboration (Analysis & Specification) 3: Software Design Software Development Plan Software Requirements Spec Use Case Model Use Case Diagram Communication Diagram Activity Diagram Model System/Gui behavior Models Actor/System Interactions Define System Boundary; Identify Actors And External Interfaces; Identify Use Cases (functional capabilities) Analysis Model Class Diagram Package Diagram Identify Boundary, Control Entity Classes and their Relationships Identify Subsystems their Interfaces & Relationships Partitions Software into Work packages. Estimate cost, resources, size, and schedule. Design Model Commun. Diagram Defines computational processes and their concurrency/synchronization requirements. A blueprint for implementation. Incorporates both functional and non- functional system requirements. 4: Software Construction Source Code An executable form of the system. Source is written a suitable OOPL. Activity Diagram

21. Jan 8, 2009(C) Dr. David A. Workman21 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

22. Jan 8, 2009(C) Dr. David A. Workman22 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 InceptionElaboration ConstructionTransition Birth Death Itera- tion Itera- tion Itera- tion Itera- tion Itera- tion Itera- tion Itera- tion Itera- tion … … Itera- tion Itera- tion

23. Jan 8, 2009(C) Dr. David A. Workman23 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 InceptionElaboration ConstructionTransition Birth Death Itera- tion Itera- tion Itera- tion Itera- tion Itera- tion Itera- tion Itera- tion Itera- tion … … Itera- tion Itera- tion

24. Jan 8, 2009(C) Dr. David A. Workman24 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. InceptionElaboration ConstructionTransition Birth Death Itera- tion Itera- tion Itera- tion Itera- tion Itera- tion Itera- tion Itera- tion Itera- tion … … Itera- tion Itera- tion

25. Jan 8, 2009(C) Dr. David A. Workman25 Overview of USDP USDP Models test1 OK test2 OK Use Case Model Analysis Model Design Model Test Model Implementation Model Deployment Model implemented by realized by specified by distributed by verified by

26. Jan 8, 2009(C) Dr. David A. Workman26 Overview of USDP Core Work Flows Requirements Analysis Design Implementation Test InceptionElaboration Construction Transition Distribution of Core Activities Across Phases Phases

27. Jan 8, 2009(C) Dr. David A. Workman27 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).

28. Jan 8, 2009(C) Dr. David A. Workman28 Development Phase Breakdown Integration = 24% Unit Testing = 21% Coding = 15% Design = 19% Specification = 15% Requirements = 6% (Schach - Classical and Object-Oriented Software Engineering)

29. Jan 8, 2009(C) Dr. David A. Workman29 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.

30. Jan 8, 2009(C) Dr. David A. Workman30 Boehm’s Spiral Model 2: Evaluate alternatives and their risks 1: Determine objectives, alternative solutions, & constraints. 4: Review outcome and Plan next cycle. 3: Develop, verify next system increment. risk analysis prototyping Design Implementation Planning ReviewTest Acceptance & Installation

31. Jan 8, 2009(C) Dr. David A. Workman31 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