Lecture01 - 3/20/10 CMPSC 24: Lecture 1 So4ware Development...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: 3/20/10 CMPSC 24: Lecture 1 So4ware Development Process Divyakant Agrawal Department of Computer Science UC Santa Barbara Syllabus and other course informaIon •  hJp://www.cs.ucsb.edu/~agrawal/spring2010/ cmpsc24.html Announcements •  Revised curriculum for Lower Division courses: –  Prepare you for the real‐world –  Based on the principle of “Learn by PracIce” –  Enable students to solve problem in language‐ agnosIc manner –  Hands‐on Laboratory SecIons –  Extensive programming projects –  Pair programming (i.e., team approach for so4ware development) 1 3/20/10 Lecture outline •  So4ware Development processes and principles •  AbstracIon, EncapsulaIon, and InformaIon Hiding: –  Abstract Data Types –  Classes in C++ So4ware Process •  So#ware Engineering –  A disciplined approach to the design, producIon, and maintenance of computer programs that are developed on Ime and within cost esImates, using tools that help to manage the size and complexity of the resulIng so4ware products •  So#ware Process –  A standard, integrated set of so4ware engineering tools and techniques used on a project or b an organizaIon 5 The So4ware Life Cycle •  •  •  •  •  •  •  •  •  Problem analysis Requirements idenIficaIon So4ware specificaIon High‐ and low‐level design ImplementaIon TesIng and VerificaIon Delivery OperaIon Maintenance List are so dull ! 6 2 3/20/10 So4ware Life Cycle: Waterfall Model Pictures are be1er ! 7 So4ware Life Cycle: Spiral Model 8 Agile So4ware Development •  Reduce the development cycle •  Short iteraIons –  A working prototype at the end of each iteraIon •  In tune with user requirements –  Minimize risks •  Minimal documentaIon •  Face to face communicaIon among programmers –  Pair programming •  Working so4ware as the primary means of progress •  In wide use currently 3 3/20/10 Programmer’s ToolBox •  Hardware –  The computers and their peripheral devices •  So#ware –  OperaIng systems, editors, compilers, interpreters, debugging systems, test‐data generators, and so on •  Ideaware –  Shared body of knowledge Including all you learn in this course! –  Algorithms 10 Goals of Quality So4ware •  It works. •  It can be modified without excessive Ime and effort. •  It is reusable. •  It is completed on Ime and within budget. 11 Goals of Quality So4ware •  Requirements –  A statement of what is to be provided by a computer system or so4ware product •  So#ware specifica:on –  A detailed descripIon of the funcIon, inputs, processing, outputs, and special requirements of a so4ware product; it provides the informaIon needed to design and implement the program 12 4 3/20/10 Program Design •  Abstrac:on –  A model of a complex system that includes only the details essenIal to the perspecIve of the viewer of the system •  Programs are abstracIons •  Module –  A cohesive system subunit that performs a share of the work; an abstracIon tool 13 Program Design •  Informa:on Hiding –  The pracIce of hiding the details of a funcIon or data structure with the goal of controlling access to the details of a module or structure •  Abstrac:on and informa:on hiding are fundamental principles of so#ware engineering 14 Stepwise Refinement •  A problem‐solving technique in which a problem is approached in stages and similar steps are followed during each stage, with the only difference being the level of detail involved –  Top‐down –  BoJom‐up –  FuncIonal decomposiIon –  Round‐trip gestalt design 15 5 3/20/10 Two Approaches to Building Manageable Modules OBJECT‐ORIENTED DESIGN FUNCTIONAL DECOMPOSITION IdenIfies various objects composed of data and operaIons, that can be used together to solve the problem. Divides the problem into more easily handled subtasks, unIl the funcIonal modules (subproblems) can be coded. FOCUS ON: processes FOCUS ON: data objects An Example of FuncIonal DecomposiIon •  Planning a large party 17 FuncIonal Design Modules Main Prepare File for Reading Get Data Print Data Find Weighted Average Print Weighted Average Print Heading 6 3/20/10 Object‐Oriented Design A problem‐solving methodology that produces a soluIon to a problem in terms of self‐contained enIIes called objects Object – A thing or enIty that makes sense within the context of the problem For example, a student, a car, 8me, date 19 Object‐Oriented Design A technique for developing a program in which the soluIon is expressed in terms of objects -- self‐ contained enIIes composed of data and operaIons on that data. m1 m2 . . . Private data m3 World View of OOD Problems are solved by –  isolaIng the objects in a problem, –  determining their properIes and acIons (responsibiliIes), and –  lemng the objects collaborate to solve a problem 21 7 3/20/10 Object‐Oriented Design An analogy: You and your friend fix dinner • Objects: you, friend, dinner • Class: you and friend are people – People have name, eye color, … – People can shop, cook, … • Instance of a class: you and friend are instances of class People, you each have your own name and eye color, you each can shop and cook • You collaborate to fix dinner 22 Object‐Oriented Design • Class (or object class) – A descripIon of a group of objects with similar properIes and behaviors; a paJern for creaIng individual objects • Object (instance of a class) – A concrete example of the class • Classes contain fields that represent the properIes (name, eye color) and behaviors (responsibiliIes) (shop, cook) of the class • Method – A named algorithm that defines behavior (shop, cook) 23 Data AbstracIon Separa:on of a data type’s logical proper:es from its implementa:on. LOGICAL PROPERTIES IMPLEMENTATION What are the possible values? How can this be done in C++? What operaIons will be needed? How can data types be used? 24 8 3/20/10 Data AbstracIon The separa:on of the representa:on of data from the applica:ons that use the data at a logical level; a programming language feature that enforces informa:on hiding. APPLICATION int REPRESENTATION y; y = 25; 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 25 AbstracIon of C++ Data Type int TYPE int Value range: INT_MIN . . INT_MAX Operations: + prefix - prefix + infix - infix * infix / infix % infix Relational Operators infix (inside) RepresentaIon of int as 16 bits two’s complement + ImplementaIon of OperaIons 26 Abstract Data Type (ADT) •  A data type whose proper:es (domain and opera:ons) are specified independently of any par:cular implementa:on. 27 9 3/20/10 Data from 2 different levels •  Logical (or ADT) level: abstract view of the domain and opera:ons. WHAT •  Implementa7on level: specific representa:on of the structure to hold the data items, and the coding for opera:ons. HOW 28 C++ class data type •  A class is an unstructured type that encapsulates a fixed number of data components (data members) with the func:ons (called member func:ons) that manipulate them. •  The predefined opera:ons on an instance of a class are whole assignment and component access. 29 An Example (High Level) •  Special type of a Queue: –  EnIIes in the Queue have priority –  Service the queue enIIes (people, files, forms, etc.) in the priority order •  WHAT concerns: –  Add to the queue –  Remove from the queue •  HOW concerns: –  Internally: maintain the enIIes sorted? Unsorted? –  Many choices at the design/implementaIon Ime 10 3/20/10 ADDITIONAL MATERIAL – FOR FURTHER READING/REVIEW VerificaIon of So4ware •  Program verifica:on –  The process of determining the degree to which a so4ware project fulfills its specificaIons •  Program valida:on –  the process of determining the degree to which so4ware fulfills its intended purpose 32 VerificaIon vs. ValidaIon Program verificaIon asks, “Are we doing the job right?” Program validaIon asks, “Are we doing the right job?” B.W. Boehm, SoHware Engineering Economics, 1981 33 11 3/20/10 Bugs! •  Dijkstra decries the term “bugs” •  Ever since the moth was found in the hardware, computer errors have been called bugs. Edsger Dijkstra chides us for the use of this terminology. He says that it can foster the image that errors are beyond the control of the programmer—that a bug might maliciously creep into a program when no one is looking. He contends that this is intellectually dishonest because it disguises that the error is the programmer’s own creation. 34 VerificaIon of So4ware Where do you begin to look for errors? 35 Kinds of errors •  SpecificaIon and design errors –  Can you give an example? •  Compile‐Ime errors –  Can you give an example? •  Run‐Ime errors (data) –  Can you give an example? •  Robustness –  The ability of a program to recover following an error; the ability of a program to conInue to operate within its environment 36 12 3/20/10 Cost of an Error Based on When It Is Discovered VerificaIon of So4ware •  TesIng –  The process of execuIng a program with data sets designed to discover errors •  Formal verificaIon •  Other aspects 38 Formal VerificaIon •  Pre‐condi:ons –  AssumpIons that must be true on entry into an operaIon or funcIon for the postcondiIons to be guaranteed. •  Post‐condi:ons –  Statements that describe what results are to be expected at the exit of an operaIon or funcIon, assuming that the precondiIons are true •  Loop invariants •  Logics & theorem proving •  Model checking 39 13 3/20/10 Other Aspects of VerificaIon • Desk checking – Tracing an execuIon of a design or program on paper • Walk‐through – A verificaIon method in which a team performs a manual simulaIon of the program or design • Inspec:on – A verificaIon method in which one member of a team reads the program or design line by line and the other members point out errors 40 Excep:ons An unusual, generally unpredictable event, detectable by so4ware or hardware, that requires special processing; the event may or may note be erroneous Three parts to an excepIon mechanism: –  Define the excepIon –  Generate (raising) the excepIon Try, throw, and catch –  Handling the excepIon statements in C++ 41 Program TesIng •  For each data set –  Determine inputs that demonstrate the goal of test case –  Determine the expected behavior of the program –  Run the program and observe the resulIng behavior –  Compare the expected behavior and the actual behavior 42 14 3/20/10 Types of TesIng Unit tesIng TesIng a module, class, or funcIon by itself Black‐box tesIng TesIng a program or funcIon based on the possible input values, treaIng the code as a “black box” Clear (white) box tesIng TesIng a program or funcIon based on covering all of the statements, branches, or paths of the code 43 More kinds of tesIng •  Acceptance test –  The process of tesIng the system in its real environment with real data •  Regression tesIng –  Re‐execuIon of program tests a4er modificaIons have been made to ensure that the program sIll works 44 Program TesIng Statement coverage Every statement in the program or funcIon is executed at least once Branch A code segment that is not always executed; for example, a switch statement has as many branches as there are case labels Path A combinaIon of branches that might be traversed when a program or funcIon is executed Path tesIng A tesIng technique whereby the tester tries to execute all possible paths in a program or funcIon 45 15 3/20/10 Program TesIng •  For program tesIng to be effecIve, it must be planned •  Start planning for tesIng before wriIng a single line of code •  A program is not complete unIl it has been thoroughly tested •  Your test plan should convince a reader that the program is correct 46 IntegraIon TesIng •  Is performed to integrate program modules that have already been independently unit tested. Main Prepare File for Reading Get Data Print Data Find Weighted Average Print Weighted Average Print Heading IntegraIon TesIng Approaches TOP‐DOWN Ensures correct overall design logic. BOTTOM‐UP Ensures individual modules work together correctly, beginning with the lowest level. USES: placeholder USES: a test driver to call module “stubs” to test the funcIons being tested. the order of calls. 16 3/20/10 Test plan •  Document showing the test cases planned for a program or module, their purposes, inputs, expected outputs, and criteria for success –  Goals –  Data to test goals –  Expected output •  Implemen:ng a test plan –  Running the program with the test cases listed in the test plan 49 17 ...
View Full Document

Ask a homework question - tutors are online