SOFTWARE ENGINEERING

1 Designed according to Anna University Coimbatore syllabus FOR III YEAR CSE STUDENTS By R.SHANTHI VICTORIA., B.E.,M.E(SOFTWARE ENGINEERING) TAMIL NADU COLLEGE OF ENGINEERING KARUMATHAMPATTI, COIMBATORE. 2 080230019 SOFTWARE ENGINEERING L T P M C 3 0 0 100 3 UNIT I 9 Introduction to Software Engineering Introduction to Software Engineering -A systems Approach-An Engineering Approach-Members of the Development Team-How Has Software Engineering changed?-Information Systems Example-Real-Time Example Modeling the process and Life cycle The meaning of process –Software process Models-Tools and Techniques for Process Modeling-Practical process modeling-Information system Example-Real-Time Example Unit II 9 Planning and Managing the project Tracking progress-project personnel-Effort Estimation-Risk Management-The project Plan-Process Models and Project Management-Information System Example-Real Time Example Capturing the Requirements The Requirements Process-Requirements Elicitation-Types of Requirements-Characteristic of Requirements-Modeling Notations-Requirements and Specification Languages-Prototyping Requirements-requirements Documentation-Validation and Verification-Measuring Requirements –choosing a specification Technique. Unit III 9 Designing the System Introduction to Design-decomposition and Modularity-Architectural styles and Strategies-Issues in Design Creation-Characteristics of Good Design-Techniques of Improving Design-Design Evaluation and Validation-Documenting the Design-Information system Example-Real-Time Example Considering objects What is OO-the OO Development process –use cases-Representing OO: An Example using UML-OO System Design-OO Program Design-OO Measurement-Information systems Example-Real-Time Example Unit IV 9 Writing the programs Programming standards and procedures-Programming Guidelines-Documentation-The Programming process-Information systems Example-Real-Time Example Testing the programs 3 Software faults and failures-Testing Issues-unit Testing Integration Testing-Testing Object-Oriented Systems-Test Planning-Automated Testing Tools-When to stop Testing-Information’s Systems Example-Real-Time Example Unit V 9 Testing the Systems Principles of system testing -function testing-performance Testing-Reliability, Availability and Maintainability-Acceptance Testing-Installation Testing-Automated system Testing-Test Documentation-Testing safety-Critical systems-Information systems Example. Maintaining the system The changing system-The nature of maintenance-Maintenance Problems-Measuring Maintenance characteristics-Maintenance Techniques and Tools-Software Rejuvenation-Information Systems Example-Real-Time Example. Total : 45 Text Book: 1. Software Engineering Theory and Practice, Shari Lwarence Pfleeger, Joanne M.Atlee, Third Edition, Pearson Education, 2006 2. Object-Oriented Software Engineering Using UML, Patterns, and Java,Bernd Bruegge,Allen H.Dutoit, Second Editon, Pearson Edition, 2006 3. Roger S. Pressman, Software Engineering-A Practitioners Approach, McGraw-Hill International Edition, Seventh Edition, 2009 4 Chapter 1 What is Software Engineering? Contents 1.1 What is Software Engineering? 1.2 How Successful Have We Been? 1.3 What Is Good Software? 1.4 Who Does Software Engineering? 1.5 A System Approach 1.6 An Engineering Approach 1.7 Members of the Development Team 1.8 How Has Software Engineering Changed? 1.9 Information System Example 1.10 Real Time Example 1.11 What this Chapter Means for You Objectives • What we mean by software engineering • Software engineering’s track record • What we mean by good software • Why a system approach is important • How software engineering has changed since 1970s 1.1 What is Software Engineering Solving Problems • Software products are large and complex • Development requires analysis and synthesis – Analysis: decompose a large problem into smaller, understandable pieces • abstraction is the key – Synthesis: build (compose) a software from smaller building blocks • composition is challenging • The analysis process 5 • The synthesis process • Method: refers to a formal procedure; a formal “recipe” for accomplishing a goal that is typically independent of the tools used • Tool: an instrument or automated system for accomplishing something in a better way • Procedure: a combination of tools and techniques to produce a product • Paradigm: philosophy or approach for building a product (e.g., OO vs structured approaches) 6 Where Does the Software Engineer Fit In? • Computer science: focusing on computer hardware, compilers, operating systems, and programming languages • Software engineering: a discipline that uses computer and software technologies as a problem-solving tools • Relationship between computer science and software engineering 1.2 How Successful Have We Been? • Perform tasks more quickly and effectively – Word processing, spreadsheets, e-mail • Support advances in medicine, agriculture, transportation, multimedia education, and most other industries • Many good stories • However, software is not without problems Sidebar 1.1 Terminology for Describing Bugs • A fault: occurs when a human makes a mistake, called an error, in performing some software activities • A failure: is a departure from the system’s required behaviour 7 Examples of Software Failure • IRS hired Sperry Corporation to build an automated federal income tax form processing process – An extra $90 M was needed to enhance the original $103 product – IRS lost $40.2 M on interests and $22.3 M in overtime wages because refunds were not returned on time • Malfunctioning code in Therac-25 killed several people • Reliability constraints have caused cancellation of many safety critical systems – Safety-critical: something whose failure poses a threat to life or health Sidebar 1.2 Perspective on Quality • The transcendental view: quality is something we can recognize but not define • The user view: quality is fitness for purpose • The manufacturing view: quality is conformance to specification • The product view: quality tied to inherent product characteristics • The value-based view: depends on the amount the customers is willing to pay for it 1.3 What Is Good Software? • Good software engineering must always include a strategy for producing quality software • Three ways of considering quality – The quality of the product – The quality of the process – The quality of the product in the context of the business environment 8 The Quality of the Product • Users judge external characteristics (e.g., correct functionality, number of failures, type of failures) • Designers and maintainers judge internal characteristics (e.g., types of faults) • Thus different stakeholders may have different criteria • Need quality models to relate the user’s external view to developer’s internal view McCall’s quality model The Quality of the Process • Quality of the development and maintenance process is as important as the product quality • The development process needs to be modeled • Modeling will address questions such as – Where to find a particular kind of fault – How to find faults early – How to build in fault tolerance – What are alternative activities 9 • Models for process improvement – SEI’s Capability Maturity Model (CMM) – ISO 9000 – Software Process Improvement and Capability dEtermination (SPICE) The Quality in the Context of the Business Environment • Business value is as important as technical value • Business value (in relationship to technical value) must be quantified • A common approach: return on investment (ROI) – what is given up for other purposes • ROI is interpreted in different terms: reducing costs, predicting savings, improving productivity, and costs (efforts and resources) Industry’s definition of ROI 1.4 Who Does Software Engineering? • Customer: the company, organization, or person who pays for the software system • Developer: the company, organization, or person who is building the software system • User: the person or people who will actually use the system • Participants (stakeholders) in a software development project 10 1.5 System Approach • Hardware, software, interaction with people • Identify activities and objects • Define the system boundary • Consider nested systems, systems interrelationship The Element of a System • Activities and objects – An activity is an event initiated by a trigger – Objects or entities are the elements involved in the activities • Relationships and the system boundaries – A relationship defines the interaction among entities and activities – System boundaries determine the origin of input and destinations of the output • Example of systems: a human respiratory system 11 • A computer system must also be clearly described: System definition of a paycheck production 12 Interrelated Systems • Some systems are dependent to other systems – The interdependencies may be complex • It is possible for one system to exist inside anzgu\ • other system • If the boundary definitions are detailed, building a larger system from the smaller ones is relatively easy A layered system 1.6 Engineering Approach Building a System • Requirement analysis and definition • System design • Program design • Writing the programs • Unit testing • Integration testing • System testing • System delivery • Maintenance 13 1.7 Members of the Development Team • Requirement analysts: work with the customers to identify and document the requirements • Designers: generate a system-level description of what the system us supposed to do • Programmers: write lines of code to implement the design • Testers: catch faults • Trainers: show users how to use the system • Maintenance team: fix faults that show up later • Librarians: prepare and store documents such as software requirements • Configuration management team: maintain correspondence among various artifacts Typical roles played by the members of a development team 1.8 How Has Software Engineering Changed? The Nature of the Change • Before 1970s – Single processors: mainframes – Designed in one of two ways 14 • as a transformation: input was converted to output • as a transaction: input determined which function should be performed • After 1970s – Run on multiple systems – Perform multi-functions Wasserman's Seven Key Factors 1. Critically of time-to-market 2. Shifts in the economics of computing 3. Availability of powerful desktop computing 4. Extensive local-and wide-area networking 5. Availability and adoption of object-oriented technology 6. Graphical user interfaces 7. Unpredictability of the waterfall model of software development The key factors that have changed the software development Wasserman's Discipline of Software Engineering • Abstractions • Analysis and design methods and notations • User interface prototyping • Software architecture • Software process 15 • Reuse • Measurement • Tools and integrated environments Abstraction • A description of the problem at some level of generalization – Hide details Analysis and Design Methods and Notations • Provide documentation • Facilitate communication • Offer multiple views • Unify different views User Interface Prototyping • Prototyping: building a small version of a system – Help users identify key requirements of a system – Demonstrate feasibility • Develop good user interface 16 Software Architecture • A system’s architecture describes the system in terms of a set of architectural units and relationships between these units • Architectural decomposition techniques – Modular decomposition – Data-oriented decomposition – Event-driven decomposition – Outside-in-design decomposition – Object-oriented decomposition Software Process • Many variations • Different types of software need different processes – Enterprise-wide applications need a great deal of control – Departmental applications can take advantage of rapid development • Pictorial representation of differences in development processes 17 Software Reuse • Commonalities between applications may allow reusing artifacts from previous developments – Improve productivity – Reduce costs • Potential concerns – It may be faster to build a smaller application than searching for reusable components – Generalized components take more time to build – Must clarify who will be responsible for maintaining reusable components – Generality vs specificity: always a conflict Measurement • Objective: describe quality goals in a quantitative way Tools and Integrated Environments • Platform integration (on heterogeneous networks) • Presentation integration (commonality of user interface) • Process integration (linking tools and the development process) • Data integration (to share common data) 18 • Control integration (the ability of one tool to initiate action in another one) 1.9 Information Systems Example Piccadilly System • Piccadilly Television: regional British TV franchise • Advertising scheme has many constraints: – alcohol adverts only after 9 pm – if actor in show, no same actor in advert within 45 minutes – if advert in a class of products, no other advert in same class during same break – rates dependent on amount of time bought • Software to determine, track advertising time Piccadilly Television franchise area • Piccadilly system’s context diagram 19 1.10 Real Time Example • Ariane-5 rocket, from the European Space Agency • June 4, 1996: functioned well for 40 seconds, then veered off course and was destroyed • Contained four satellites: cost was $500 million • Reused code from Ariane-4 rocket Ariane-5 Definition of Quality • From the Lions et al report: – “… demonstrated the high quality of the Ariane-5 programme as regards engineering work in general and completeness and traceability of documents.” – “… the supplier of the SRI … was only following the specification given to it. … The exception which occurred was not due to random failure but a design error.” 1.11 What this Chapter Means for You • Given a problem to solve – Analyze it – Synthesize a solution • Understand that requirements may change • Must view quality from several different perspectives • Use fundamental software engineering concepts (e.g., abstractions and measurements) • Keep system boundary in mind 20 Chapter 2 Modeling the Process and Life Cycle Contents 2.1 The Meaning of Process 2.2 Software Process Models 2.3 Tools and Techniques for Process Modeling 2.4 Practical Process Modeling 2.5 Information System Example 2.6 Real Time Example 2.7 What this Chapter Means for You Objectives • What we mean by a “process” • Software development products, processes, and resources • Several models of the software development process • Tools and techniques for process modeling 2.1 The Meaning of Process • A process: a series of steps involving activities, constrains, and resources that produce an intended output of some kind • A process involves a set of tools and techniques Process Characteristics • Prescribes all major process activities • Uses resources, subject to set of constraints (such as schedule) • Produces intermediate and final products • May be composed of subprocesses with hierarchy or links • Each process activity has entry and exit criteria • Activities are organized in sequence, so timing is clear • Each process has guiding principles, including goals of each activity • Constraints may apply to an activity, resource or product 21 The Importance of Processes • Impose consistency and structure on a set of activities • Guide us to understand, control, examine, and improve the activities • Enable us to capture our experiences and pass them along 2.2 Software Process Models Reasons for Modeling a Process • To form a common understanding • To find inconsistencies, redundancies, omissions • To find and evaluate appropriate activities for reaching process goals • To tailor a general process for a particular situation in which it will be used Software Life Cycle • When a process involves building a software, the process may be referred to as software life cycle – Requirements analysis and definition – System (architecture) design – Program (detailed/procedural) design – Writing programs (coding/implementation) – Testing: unit, integration, system – System delivery (deployment) – Maintenance Software Development Process Models • Waterfall model • V model • Prototyping model • Operational specification • Transformational model • Phased development: increments and iteration • Spiral model • Agile methods 22 Waterfall Model • One of the first process development models proposed • Works for well understood problems with minimal or no changes in the requirements • Simple and easy to explain to customers • It presents – a very high-level view of the development process – sequence of process activities • Each major phase is marked by milestones and deliverables (artifacts) • There is no iteration in Waterfall model • Most software developments apply a great many iterations Drawbacks of The Waterfall Model • Provides no guidance for how to handle changes to products and activities during development (assumes requirements can be frozen) • Views software development as manufacturing process rather than as creative process 23 • There are no iterative activities that lead to creating a final product • Long wait before a final product Waterfall Model with Prototype • A prototype is a partially developed product • Prototyping helps – developers assess alternative design strategies (design prototype) – users understand what the system will be like (user interface prototype) • Prototyping is useful for verification and validation • Waterfall model with prototyping 24 V Model • A variation of the waterfall model • Uses unit testing to verify procedural design • Uses integration testing to verify architectural (system) design • Uses acceptance testing to validate the requirements • If problems are found during verification and validation, the left side of the V can be re-executed before testing on the right side is re-enacted 25 Prototyping Model • Allows repeated investigation of the requirements or design • Reduces risk and uncertainty in the development 26 Operational Specification Model • Requirements are executed (examined) and their implication evaluated early in the development process • Functionality and the design are allowed to be merged Transformational Model • Fewer major development steps • Applies a series of transformations to change a specification into a deliverable system – Change data representation – Select algorithms – Optimize – Compile • Relies on formalism • Requires formal specification (to allow transformations) 27 Phased Development: Increments and Iterations • Shorter cycle time • System delivered in pieces – enables customers to have some functionality while the rest is being developed • Allows two systems functioning in parallel – the production system (release n): currently being used – the development system (release n+1): the next version 28 • Incremental development: starts with small functional subsystem and adds functionality with each new release • Iterative development: starts with full system, then changes functionality of each subsystem with each new release • Phased development is desirable for several reasons – Training can begin early, even though some functions are missing 29 – Markets can be created early for functionality that has never before been offered – Frequent releases allow developers to fix unanticipated problems globally and quickly – The development team can focus on different areas of expertise with different releases Spiral Model • Suggested by Boehm (1988) • Combines development activities with risk management to minimize and control risks • The model is presented as a spiral in which each iteration is represented by a circuit around four major activities – Plan – Determine goals, alternatives and constraints – Evaluate alternatives and risks – Develop and test 30 Agile Methods • Emphasis on flexibility in producing software quickly and capably • Agile manifesto – Value individuals and interactions over process and tools – Prefer to invest time in producing working software rather than in producing comprehensive documentation – Focus on customer collaboration rather than contract negotiation – Concentrate on responding to change rather than on creating a plan and then following it Examples of Agile Process • Extreme programming (XP) • Crystal: a collection of approaches based on the notion that every project needs a unique set of policies and conventions • Scrum: 30-day iterations; multiple self-organizing teams; daily “scrum” coordination • Adaptive software development (ASD) Extreme Programming • Emphasis on four characteristics of agility – Communication: continual interchange between customers and developers – Simplicity: select the simplest design or implementation – Courage: commitment to delivering functionality early and often – Feedback: loops built into the various activities during the development process Twelve Facets of XP • The planning game (customer defines value) • Small release • Metaphor (common vision, common names) • Simple design • Writing tests first • Refactoring • Pair programming 31 • Collective ownership • Continuous integration (small increments) • Sustainable pace (40 hours/week) • On-site customer • Coding standard When is Extreme Too Extreme? • Extreme programming's practices are interdependent – A vulnerability if one of them is modified • Requirements expressed as a set of test cases must be passed by the software – System passes the tests but is not what the customer is paying for • Refactoring issue – Difficult to rework a system without degrading its architecture Collections of Process Models • Development process is a problem-solving activity • Curtis, Krasner, and Iscoe (1988) performed a field study to determine which problem-solving factors are captured in process model • The results suggest a layered behavioral model as supplement to the traditional model • Process model should not only describe series of tasks, but also should detail factors that contribute to a project's inherent uncertainty and risk 2.3 Tools and Techniques for Process Modeling • Notation depends on what we want to capture in the model • The two major notation categories – Static model: depicts the process – Dynamic model: enacts the process Static Modeling: Lai Notation • Element of a process are viewed in terms of seven types – Activity – Sequence – Process model 32 – Resource – Control – Policy – Organization • Several templates, such as an Artifact Definition Template • Artifact definition form for artifact CAR Name Car Synopsis This is the artifact that represents a class of cars. Complexity type Composite Data type (car_c, user-defined) Artifact-state list parked ((state_of(car.engine) = off) (state_of(car.gear) = park) (state_of(car.speed) = stand)) Car is not moving, and engine is not running. initiated ((state_of(car.engine) = on) (state_of(car.key_hole) = has-key) (state_of(car-driver(car.)) = in-car) (state_of(car.gear) = drive) (state_of(car.speed) = stand)) Car is not moving, but the engine is running moving ((state_of(car.engine) = on) (state_of(car.keyhole) = has-key) (state_of(car-driver(car.)) = driving) ((state_of(car.gear) = drive) or (state_of(car.gear) = reverse)) ((state_of(car.speed) = stand) or (state_of(car.speed) = slow) or (state_of(car.speed) = medium) or (state_of(car.speed) = high)) Car is moving forward or backward. Sub-artifact list doors The four doors of a car. engine The engine of a car. keyhole The ignition keyhole of a car. 33 • The process of starting a car • Transition diagram for a car 34 Dynamic Modeling • To enable enaction of a process to see what happens to resources and artifacts as activities occur • To simulate alternatives and make changes to improve the process • An example: use a dynamic process model to help decide how many testers are needed or when to initiate testing in order to finish on schedule • Model example: systems dynamics model System Dynamics • Introduced by Forrester in the 1950's • Abdel-Hamid and Madnick applied it to software development • One way to understand system dynamics is by exploring how software development process affects productivity • Pictorial presentation of factors affecting productivity • Arrows indicate how changes in one factor change another • A system dynamic model containing four major areas affecting productivity 35 Process Programming • A program to describe and enact the process Eliminate uncertainty Basis of an automated environment to produce software • Does not capture inherent variability of underlying development process Implementation environment, skill, experience, understanding the customer needs • Provides only a sequence of tasks • Gives no warning of impending problems 2.4 Practical Process Modeling Marvel Case Studies • Uses Marvel process language (MPL) • Three constructs: classes, rules, tool envelopes • Three-part process description  a rule-based specification of process behaviour  an object-oriented definition of model’s information process  a set of envelopes to interface between Marvel and external software tools • Involved two AT&T networks network carried phone calls signalling network responsible for routing calls and balancing the network load • Marvel was used to describe the signalling fault resolution • Signalling Fault Resolution Process 36 TICKET:: superclass ENTITY status: (initial, open, referred_out, referral_done, closed, fixed) = initial; diagnostics: (terminal, non_terminal, none) = none; level: integer; description: text; referred_to: link WORKCENTER; referrals: set_of link TICKET; process: link PROC_INST;enddiagnose [?t: TICKET]: (exists PROC_INST ?p suchthat (linkto [?t.process ?p])) : (and (?t.status = open}(?t.diagnostics = none)) {TICKET_UTIL diagnose ?t.Name} (and (?t.diagnostics = terminal)(?p.last_task = diagnose)(?p.next_task = refer_to_WC3)); (and (?t.diagnostics = non_terminal)(?p.last_task = diagnose)(?p.next_task = refer_to_WC2));Classdefinitionfor troubleticketsRule fordiagnosingticket 37 Desirable Properties of Process Modelling Tools and Techniques • Facilitates human understanding and communication • Supports process improvement • Supports process management • Provides automated guidance in performing the process • Supports automated process execution 2.5. Information System Example Piccadilly Television Advertising System • Needs a system that is easily maintained and changed • Requirements may change The Waterfall model is not applicable • User interface prototyping is an advantage • There is uncertainty in regulation and business constraints Need to manage risks • The Spiral model is the most appropriate model • Risk can be viewed in terms of two facets Probability: the likelihood that a particular problem may occur Severity: the impact it will have on the system • To manage risk, we needs to include a characterization of risks in the process model Lai Artifact Definition for “Risk” for Piccadilly System Name Risk (problemX) Synopsis This is the artifact that represents the risk that problem X will occur and have a negative affect on some aspect of the development process. Complexity type Composite Data type (risk_s, user_defined) Artifact-state list low ((state_of(probability.x) = low) (state_of(severity.x) = small)) Probability of problem is low, severity problem impact is small. high-medium ((state_of(probability.x) = low) (state_of(severity.x) = large)) Probability of problem is low, severity problem impact is large. low-medium ((state_of(probability.x) = high) (state_of(severity.x) = small)) Probability of problem is high, severity problem impact is small. high ((state_of(probability.x) = high) (state_of(severity.x) = large)) Probability of problem is high, severity problem impact is large. Sub-artifact list probability.x The probability that problem X will occur. severity.x The severity of the impact should problem X occur on the project. 38 2.6 Real Time Example Ariane-5 Software • Involved reuse of software from Ariane-4 • The reuse process model – Identify reusable sub processes, describe them and place them in a library – Examine the requirements for the new software and the reusable components from the library and when necessary, produce revised set of requirements – Use the revised requirements to design the software – Evaluate all reused design components to certify the correctness and consistency – Build or change the software • The reuse process model presentation 2.7 What this Chapter Means for You • Process development involves activities, resources, and product. • Process model includes organizational, functional, behavioral and other perspectives • A process model is useful for guiding team behavior, coordination and collaboration 39 Chapter 3 Planning and Managing the Project Contents 3.1 Tracking Progress 3.2 Project Personnel 3.3 Effort Estimation 3.4 Risk Management 3.5 The Project Plan 3.6 Process Models and Project Management 3.7 Information System Example 3.8 Real Time Example 3.9 What this Chapter Means for You Objectives • Tracking project progress • Project personnel and organization • Effort and schedule estimation • Risk management • Using process modelling with project planning 3.1 Tracking Progress • Do we understand customer’s needs? • Can we design a system to solve customer’s problems or satisfy customer’s needs? • How long will it take to develop the system? • How much will it cost to develop the system? Project Schedule • Describes the software-development cycle for a particular project by – enumerating the phases or stages of the project – breaking each phase into discrete tasks or activities to be completed • Portrays the interactions among the activities and estimates the times that each task or activity will take 40 Project Schedule: Approach • Understanding customer’s needs by listing all project deliverables – Documents – Demonstrations of function – Demonstrations of subsystems – Demonstrations of accuracy – Demonstrations of reliability, performance or security • Determining milestones and activities to produce the deliverables Milestones and activities • Activity: takes place over a period of time • Milestone: completion of an activity --a particular point in time • Precursor: event or set of events that must occur in order for an activity to start • Duration: length of time needed to complete an activity • Due date: date by which an activity must be completed Project Schedule • Project development can be separated into a succession of phases which are composed of steps, which are composed of activities • Table 3.1 shows the phases, steps and activities to build a house – landscaping phase 41 – building the house phase • Table 3.2 lists milestones for building the house phase Phases, Steps, and Activities in Building a House Phase 1: Landscaping the lot Phase 2: Building the house Step 1.1: Clearing and grubbing Step 2.1: Prepare the site Activity 1.1.1: Remove trees Activity 2.1.1: Survey the land Activity 1.1.2: Remove stumps Activity 2.1.2: Request permits Step 1.2: Seeding the turf Activity 2.1.3: Excavate for the foundation Activity 1.2.1: Aerate the soil Activity 2.1.4: Buy materials Activity 1.2.2: Disperse the seeds Step 2.2: Building the exterior Activity 1.2.3: Water and weed Activity 2.2.1: Lay the foundation Step 1.3: Planting shrubs and trees Activity 2.2.2: Build the outside walls Activity 1.3.1: Obtain shrubs and trees Activity 2.2.3: Install exterior plumbing Activity 1.3.2: Dig holes Activity 2.2.4: Exterior electrical work Activity 1.3.3: Plant shrubs and trees Activity 2.2.5: Exterior siding Activity 1.3.4: Anchor the trees and mulch around them Activity 2.2.6: Paint the exterior Activity 2.2.7: Install doors and fixtures Activity 2.2.8: Install roof Step 2.3: Finishing the interior Activity 2.3.1: Install the interior plumbing Activity 2.3.2: Install interior electrical work Activity 2.3.3: Install wallboard Activity 2.3.4: Paint the interior Activity 2.3.5: Install floor covering Activity 2.3.6: Install doors and fixtures 42 Milestones in Building a House Work Breakdown and Activity Graphs • Work breakdown structure depicts the project as a set of discrete pieces of work • Activity graphs depict the dependencies among activities – Nodes: project milestones – Lines: activities involved • Activity graph for building a house 1.1. Survey complete 1.2. Permits issued 1.3. Excavation complete 1.4. Materials on hand 2.1. Foundation laid 2.2. Outside walls complete 2.3. Exterior plumbing complete 2.4. Exterior electrical work complete 2.5. Exterior siding complete 2.6. Exterior painting complete 2.7. Doors and fixtures mounted 2.8. Roof complete 3.1. Interior plumbing complete 3.2. Interior electrical work complete 3.3. Wallboard in place 3.4. Interior painting complete 3.5. Floor covering laid 3.6. Doors and fixtures mounted 43 Estimating Completion • Adding estimated time in activity graph of each activity to be completed tells us more about the project's schedule 44 Estimating Completion for Building a House Critical Path Method (CPM) • Minimum amount of time it will take to complete a project – Reveals those activities that are most critical to completing the project on time • Real time (actual time): estimated amount of time required for the activity to be completed • Available time: amount of time available in the schedule for the activity's completion • Slack time: the difference between the available time and the real time for that activity • Critical path: the slack at every node is zero – can be more than one in a project schedule • Slack time = available time – real time = latest start time – earliest start time Activity Time estimate (in days) Step 1: Prepare the site Activity 1.1: Survey the land 3 Activity 1.2: Request permits 15 Activity 1.3: Excavate for the foundation 10 Activity 1.4: Buy materials 10 Step 2: Building the exterior Activity 2.1: Lay the foundation 15 Activity 2.2: Build the outside walls 20 Activity 2.3: Install exterior plumbing 10 Activity 2.4: Exterior electrical work 10 Activity 2.5: Exterior siding 8 Activity 2.6: Paint the exterior 5 Activity 2.7: Install doors and fixtures 6 Activity 2.8: Install roof 9 Step 3: Finishing the interior Activity 3.1: Install the interior plumbing 12 Activity 3.2: Install interior electrical work 15 Activity 3.3: Install wallboard 9 Activity 3.4: Paint the interior 18 Activity 3.5: Install floor covering 11 Activity 3.6: Install doors and fixtures 7 45 Slack Time for Activities of Building a House CPM Bar Chart • Including information about the early and late start dates • Asterisks indicate the critical path Activity Earliest start time Latest start time Slack 1.1 1 13 12 1.2 1 1 0 1.3 16 16 0 1.4 26 26 0 2.1 36 36 0 2.2 51 51 0 2.3 71 83 12 2.4 81 93 12 2.5 91 103 12 2.6 99 111 12 2.7 104 119 15 2.8 104 116 12 3.1 71 71 0 3.2 83 83 0 3.3 98 98 0 3.4 107 107 0 3.5 107 107 0 3.6 118 118 0 Finish 124 124 0 46 Tools to Track Progress • Example: to track progress of building a communication software Gantt Chart • Activities shown in parallel • helps understand which activities can be performed concurrently 47 Resource Histogram • Shows people assigned to the project and those needed for each stage of development 48 Expenditures Tracking • An example of how expenditures can be monitored 3.2 Project Personnel • Key activities requiring personnel – requirements analysis – system design – program design – program implementation – testing – training – maintenance – quality assurance • There is great advantage in assigning different responsibilities to different people Choosing Personnel • Ability to perform work • Interest in work • Experience with 49 – similar applications – similar tools, languages, or techniques – similar development environments • Training • Ability to communicate with others • Ability to share responsibility • Management skills Communication • A project's progress is affected by – degree of communication – ability of individuals to communicate their ideas • Software failures can result from breakdown in communication and understanding • Line of communication can grow quickly • If there is n worker in project, then there are n(n-1)/2 pairs of communication Sidebar 3.1 Make Meeting Enhance Project Progress • Common complains about meeting – the purpose is unclear – the attendees are unprepared 50 – essential people are late or absent – the conversation veers away from its purpose – participants do not discuss, instead argue – decisions are never enacted afterward • Ways to ensure a productive meeting – clearly decide who should be in the meeting – develop an agenda – have someone who tracks the discussion – have someone who ensures follow-up actions Work Styles • Extroverts: tell their thoughts • Introverts: ask for suggestions • Intuitives: base decisions on feelings • Rationals: base decisions on facts, options • Horizontal axis: communication styles • Vertical axis: decision styles • Work styles determine communication styles • Understanding work styles – help to be flexible 51 – give information based on other's priorities • Impacts interaction among customers, developers and users Project Organization • Depends on – backgrounds and work styles of team members – number of people on team – management styles of customers and developers • Examples: – Chief programmer team: one person totally responsible for a system's design and development – Egoless approach: hold everyone equally responsible Project Organization: Chief Programmer Team • Each team member must communicate often with chief, but not necessarily with other team members Project Organization • Characteristics of projects and the suggested organizational structure to address them 52 Sidebar 3.2 Structure vs. Creativity • • • Experiment by Sally Phillip examining two groups building a hotel – structured team: clearly defined responsibilities – unstructured team: no directions • The results are always the same – Structured teams finish a functional Days Inn – Unstructured teams build a creative, multistoried Taj Mahal and never complete • Good project management means finding a balance between structure and creativity 3.3 Effort Estimation • Estimating project costs is one of the crucial aspects of project planning and management • Estimating cost has to be done as early as possible during the project life cycle • Type of costs – facilities: hardware, space, furniture, telephone, etc – software tools for designing software – staff (effort): the biggest component of cost Estimation Should be Done Repeatedly • Uncertainty early in the project can affect the accuracy of cost and size estimations Highly structured Loosely structured High certainty Uncertainty Repetition New techniques or technology Large projects Small projects 53 Sidebar 3.3 Causes of Inaccurate Estimates • Key causes – Frequent request for change by users – Overlooked tasks – User's lack of understanding of the requirements – Insufficient analysis when developing estimates – Lack of coordination of system development, technical services, operations, data administration, and other functions during development – Lack of an adequate method or guidelines for estimating – Complexity of the proposed application system – Required integration with existing system – Complexity of the program in the system – Size of the system expressed as number of functions or programs – Capabilities of the project team members – Project team's experience with the application, the programming language, and hardware – Capabilities of the project team members – Database management system – Number of project team member – Extent of programming and documentation standards 54 Type of Estimation Methods • Expert judgment • Top-down or bottom-up • Analogy: pessimistic (x), optimistic (y), most likely (z); Estimate as (x + 4y + z)/6 – Delphi technique: based on the average of “secret” expert judgments • Algorithmic methods: E = (a + bSc) m(X) – Walston and Felix model: E = 5.25 S 0.91 – Bailey and Basili model: E = 5.5 + 0.73 S1.16 Expert Judgement: Wolverton Model • Two factors that affect difficulty – whether problem is old (O) or new (N) – whether it is easy (E) or moderate (M) Algorithmic Method: Watson and Felix Model • A productivity index is inlcuded in the equation • There are 29 factors that can affect productivity – 1 if increase the productivity – 0 if decrease the productivity Difficulty Type of software OE OM OH NE NM NH Control 21 27 30 33 40 49 Input/output 17 24 27 28 35 43 Pre/post processor 16 23 26 28 34 42 Algorithm 15 20 22 25 30 35 Data management 24 31 35 37 46 57 Time-critical 75 75 75 75 75 75 55 Watson and Felix Model Productivity Factors Algorithmic Method: Bailey-Basili technique • Minimize standard error estimate to produce an equation such as E = 5.5 + 0.73S1.16 • Adjust initial estimate based on the difference ratio – If R is the ratio between the actual effort, E, and the predicted effort, E’, then the effort adjustment is defined as – ERadj = R – 1 if R > 1 = 1 – 1/R if R < 1 • Adjust the initial effort estimate Eadj – Eadj = (1 + ERadj)E if R > 1 = E/(1 + ERadj) if R < 1 1. Customer interface complexity 16. Use of design and code inspections 2. User participation in requirements definition 17. Use of top-down development 3. Customer-originated program design changes 18. Use of a chief programmer team 4. Customer experience with the application area 19. Overall complexity of code 5. Overall personnel experience 20. Complexity of application processing 6. Percentage of development programmers who participated in the design of functional specifications 21. Complexity of program flow 7. Previous experience with the operational computer 22. Overall constraints on program’s design 8. Previous experience with the programming language 23. Design constraints on the program’s main storage 9. Previous experience with applications of similar size and complexity 24. Design constraints on the program’s timing 10. Ratio of average staff size to project duration (people per month) 25. Code for real-time or interactive operation or for execution under severe time constraints 11. Hardware under concurrent development 26. Percentage of code for delivery 12. Access to development computer open under special request 27. Code classified as nonmathematical application and input/output formatting programs 13. Access to development computer closed 28. Number of classes of items in the database per 1000 lines of code 14. Classified security environment for computer and at least 25% of programs and data 29. Number of pages of delivered documentation per 1000 lines of code 15. Use of structured programming 56 Agorithmic Method: Bailey-Basily Modifier COCOMO model • Introduced by Boehm • COCOMO II – updated version – include models of reuse • The basic models – E = bScm(X) – where • bSc is the initial size-based estimate • m(X) is the vector of cost driver information COCOMO II: Stages of Development • Application composition – prototyping to resolve high-risk user interface issues – size estimates in object points • Early design – to explore alternative architectures and concepts – size estimates in function points • Postarchitecture – development has begun Total methodology (METH) Cumulative complexity (CPLX) Cumulative experience (EXP) Tree charts Customer interface complexity Programmer qualifications Top-down design Application complexity Programmer machine experience Formal documentation Program flow complexity Programmer language experience Chief programmer teams Internal communication complexity Programmer application experience Formal training Database complexity Team experience Formal test plans External communication complexity Design formalisms Customer-initiated program design changes Code reading Unit development folders 57 – size estimates in lines of code Three Stages of COCOMO II COCOMO II: Estimate Application Points • To compute application points, first we need to count the number of screens, reports and programming language used to determine the complexity level Stage 1: Stage 2: Application Early Stage 3: Model Aspect Composition Design Post-architecture Size Application Function points (FP) FP and language or source lines points and language of code (SLOC) Reuse Implicit in Equivalent SLOC as Equivalent SLOC as function of model function of other other variables variables Requirements Implicit in % change expressed as % change expressed as a change model a cost factor cost factor Maintenance Application Function of ACT, software Function of ACT, software Point understanding, understanding, Annual unfamiliarity unfamiliarity Change Traffic Scale (c) in 1.0 0.91 to 1.23, depending 0.91 to 1.23, depending on nominal effort on precedentedness, precedentedness, conformity, equation conformity, early early architecture, risk resolution, architecture, risk team cohesion, and SEI process resolution, team maturity cohesion, and SEI process maturity Product cost None Complexity, required Reliability, database size, drivers reusability documentation needs, required reuse, and product complexity Platform cost None Platform difficulty Execution time constraints, main drivers storage constraints, and virtual machine volatility Personnel None Personnel capability Analyst capability, applications cost drivers and experience experience, programmer capability, programmer experience, language and tool experience, and personnel continuity Project cost None Required development Use of software tools, required drivers schedule, development development schedule, and environment multisite development 58 • Determine the relative effort required to implement a report or screen simple, medium or difficult • Calculate the productivity factor based on developer experience and capability • Determine the adjustment factors expressed as multipliers based on rating of the project Complexity Weights for Application Points Productivity Estimate Calculation Tool Use Categories Developers’ experience and capability Very low Low Nominal High Very high CASE maturity and capability Very low Low Nominal High Very high Productivity factor 4 7 13 25 50 Category Meaning Very low Edit, code, debug Low Simple front-end, back-end CASE, little integration Nominal Basic life-cycle tools, moderately integrated High Strong, mature life-cycle tools, moderately integrated Very high Strong, mature, proactive life-cycle tools, well-integrated with processes, methods, reuse 59 Machine Learning Techniques • Example: case-based reasoning (CBR) – user identifies new problem as a case – system retrieves similar cases from repository – system reuses knowledge from previous cases – system suggests solution for new case • Example: neural network – cause-effect network “trained” with data from past history Machine learning techniques: Neural Network • Neural network used by Shepperd to produce effort estimation Machine Learning Techniques: CBR • Involves four steps – the user identifies a new problem as a case – the system retrieves similar case from a repository of historical information – the system reuses knowledge from previous case – the system suggests a solution for the new case • Two big hurdles in creating successful CBR system – characterizing cases 60 – determining similarity Finding the Model for Your Situation • Mean magnitude of relative error (MMRE) – absolute value of mean of [(actual -estimate)/actual] – goal: should be .25 or less • Pred(x/100): percentage of projects for which estimate is within x% of the actual – goal: should be .75 or greater for x = .25 – 75% project estimates are within 25% of actual Evaluating Models • No model appears to have captured the essential charateristics and their relationships for all types of development • It is important to understand which types of effort are needed during development even when we have reasonably accurate estimate – Categorize and save the results • Two different reports of effort distribution from different researchers Model PRED(0.25) MMRE Walston-Felix 0.30 0.48 Basic COCOMO 0.27 0.60 Intermediate COCOMO 0.63 0.22 Intermediate COCOMO (variation) 0.76 0.19 Bailey-Basili 0.78 0.18 Pfleeger 0.50 0.29 SLIM 0.06-0.24 0.78-1.04 Jensen 0.06-0.33 0.70-1.01 COPMO 0.38-0.63 0.23-5.7 General COPMO 0.78 0.25 61 3.4 Risk Management what is a Risk? • Risk is an unwanted event that has negative consequences • Distinguish risks from other project events – Risk impact: the loss associated with the event – Risk probability: the likelihood that the event will occur • Quantify the effect of risks – Risk exposure = (risk probability) x (risk impact) • Risk sources: generic and project-specific 62 Risk Management Activities Risk Management Activities • Example of risk exposure calculation PU: prob. of unwanted outcome LU: lost assoc with unwanted outcome • Three strategies for risk reduction – Avoiding the risk: change requirements for performance or functionality – Transferring the risk: transfer to other system, or buy insurance – Assuming the risk: accept and control it • Cost of reducing risk – Risk leverage = (risk exposure before reduction – (risk exposure after reduction) /(cost of risk reduction) 63 Sidebar 3.4 Boehm’s Top Ten Risk Items • Personnel shortfalls • Unrealistic schedules and budgets • Developing the wrong functions • Developing the wrong user interfaces • Gold-plating • Continuing stream of requirements changes • Shortfalls in externally-performed tasks • Shortfalls in externally-furnished components • Real-time performance shortfalls • Straining computer science capabilities 3.5 Project Plan Project Plan Contents • Project scope • Project schedule • Project team organization • Technical description of system • Project standards and procedures 64 • Quality assurance plan • Configuration management plan • Documentation plan • Data management plan • Resource management plan • Test plan • Training plan • Security plan • Risk management plan • Maintenance plan Project Plan Lists • List of the people in development team • List of hardware and software • Standards and methods, such as – algorithms – tools – review or inspection techniques – design language or representations – coding languages – testing techniques 3.6 Process Models and Project Management Enrollment Management Model: Digital Alpha AXP • Establish an appropriately large shared vision • Delegate completely and elicit specific commitments from participants • Inspect vigorously and provide supportive feedback • Acknowledge every advance and learn as the program progresses • Vision: to “enroll” the related programs, so they all shared common goals 65 • An organization that allowed technical focus and project focus to contribute to the overall program Management Accountability modeling: Lockheed Martin • Matrix organization – Each engineer belongs to a functional unit based on type of skill • Integrated product development team 66 – Combines people from different functional units into interdisciplinary work unit • Each activity tracked using cost estimation, critical path analysis, schedule tracking – Earned value a common measure for progress • Accountability model used in F-16 Project • Teams had multiple, overlapping activities • An activity map used to illustrate progress on each activity • Each activitiy's progress was tracked using earned value chart 67 Process Models and Project Management Anchoring (Common) Milestones • Life cycle objectives • Objectives: Why is the system being developed? • Milestones and schedules: What will be done by when? • Responsibilities: Who is responsible for a function? • Approach: How will the job be done, technically and managerially? • Resources: How much of each resource is needed? • Feasibility: Can this be done, and is there a good business reason for doing it? • Life-cycle architecture: define the system and software architectures and address architectural choices and risks • Initial operational capability: readiness of software, deployment site, user training • The Win-Win spiral model suggested by Boehm is used as supplement to the milestones 68 3.7 Information System Example Piccadilly System • Using COCOMO II • Three screens and one report – Booking screen: complexity simple, weight 1 – Ratecard screen: complexity simple, weigth 1 – Availability screen: complexity medium, weight 2 – Sales report: complexity medium, weight 5 • Estimated effort = 182 person-month 3.8 Real Time Example Ariane-5 System • The Ariane-5 destruction might have been prevented had the project managers developed a risk management plan – Risk identification: possible problem with reuse of the Ariane-4) – Risk exposure: prioritization would have identified if the inertial reference system (SRI) did not work as planned – Risk control: assesment of the risk using reuse software – Risk avoidance: using SRI with two different designs 69 3.7 What this Chapter Means for You • Key concepts in project management – Project planning – Cost and schedule estimation – Risk management – Team Organization • Project planning involves input from all team members • Communication path grows as the size of the team increases and need to be taken into account when planning and estimating schedule 70 CHAPTER-4 CAPTURING THE REQUIREMENTS Contents 4.1 The Requirements Process 4.2 Requirements Elicitation 4.3 Types of Requirements 4.4 Characteristics of Requirements 4.5 Modelling Notations 4.6 Requirements and Specification Languages 4.7 Prototyping Requirements 4.8 Requirements Documentation 4.9 Validation and Verification 4.10 Measuring Requirements 4.11 Choosing a Specification Technique 4.12 Information System Example 4.13 Real Time Example Objectives • Eliciting requirements from the customers • Modelling requirements • Reviewing requirements to ensure their quality • Documenting requirements for use by the design and test teams 4.1 The Requirements Process • A requirement is an expression of desired behaviour • A requirement deals with – objects or entities – the state they can be in – functions that are performed to change states or object characteristics 71 • Requirements focus on the customer needs, not on the solution or implementation – designate what behaviour, without saying how that behaviour will be realized 4.1 Why Are Requirements Important? • Top factors that caused project to fail – Incomplete requirements – Lack of user involvement – Unrealistic expectations – Lack of executive support – Changing requirements and specifications – Lack of planning – System no longer needed • Some part of the requirements process is involved in almost all of these causes • Requirements error can be expensive if not detected early Process for Capturing Requirements • Performed by the req. analyst or system analyst • The final outcome is a Software Requirements Specification (SRS) document 72 4.2 Requirements Elicitation • Customers do not always understand what their needs and problems are • It is important to discuss the requirements with everyone who has a stake in the system • Come up with agreement on what the requirements are – If we cannot agree on what the requirements are, then the project is doomed to fail Stakeholders • Clients: pay for the software to be developed • Customers: buy the software after it is developed • Users: use the system • Domain experts: familiar with the problem that the software must automate • Market Researchers: conduct surveys to determine future trends and potential customers • Lawyers or auditors: familiar with government, safety, or legal requirements • Software engineers or other technology experts 4.2 Agile Requirements Modelling • If requirements are tightly coupled and complex, we may be better off with a “heavy” process that emphasizes up-front modelling • If the requirements are uncertain, agile methods are an alternative approach • Agile methods gather and implement the requirements in increments • Extreme Programming (XP) is an agile process – The requirements are defined as we build the system – No planning or designing for possible future requirements – Encodes the requirements as test cases that eventually implementation must pass 4.3 Types of Requirements • Functional requirement: describes required behaviour in terms of required activities • Quality requirement or non-functional requirement: describes some quality characteristic that the software must posses • Design constraint: a design decision such as choice of platform or interface components 73 • Process constraint: a restriction on the techniques or resources that can be used to build the system 4.4 Making Requirements Testable • Fit criteria form objective standards for judging whether a proposed solution satisfies the requirements – It is easy to set fit criteria for quantifiable requirements – It is hard for subjective quality requirements • Three ways to help make requirements testable – Specify a quantitative description for each adverb and adjective – Replace pronouns with specific names of entities – Make sure that every noun is defined in exactly one place in the requirements documents Resolving Conflicts • Different stakeholder has different set of requirements – potential conflicting ideas • Need to prioritize requirements • Prioritization might separate requirements into three categories – essential: absolutely must be met – desirable: highly desirable but not necessary – optional: possible but could be eliminated Two Kinds of Requirements Documents • Requirements definition: a complete listing of everything the customer wants to achieve – Describing the entities in the environment where the system will be installed • Requirements specification: restates the requirements as a specification of how the proposed system shall behave 74 • Requirements defined anywhere within the environment's domain, including the system's interface • Specification restricted only to the intersection between environment and system domain 4.3 Using Viewpoints to Manage Inconsistency • No need to resolve inconsistencies early in the requirements process (Easterbrook and Nuseibah, 1996) • Stakeholders' views documented and maintained as separate Viewpoints through the software development process – The requirements analyst defines consistency rules that should apply between Viewpoints – The Viewpoints are analyzed to see if they conform to the consistency requirements • Inconsistencies are highlighted but not addressed until there is sufficient information to make informed decision Means of Eliciting Requirements • Interviewing stake holders • Reviewing available documentations • Observing the current system (if one exists) • Apprenticing with users to learn about user's task in more details 75 • Interviewing user or stakeholders in groups • Using domain specific strategies, such as Joint Application Design, or PIECES • Brainstorming with current and potential users • The Volere requirements process model suggests some additional sources for requirements 4.4 Characteristics of Requirements • Correct • Consistent • Unambiguous • Complete • Feasible • Relevant • Testable • Traceable 4.5 Modelling Notations • It is important to have standard notations for modelling, documenting, and communicating decisions • Modelling helps us to understand requirements thoroughly – Holes in the models reveal unknown or ambiguous behaviour – Multiple, conflicting outputs to the same input reveal inconsistencies in the requirements Entity-Relationship Diagrams • A popular graphical notational paradigm for representing conceptual models • Has three core constructs – An entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behaviours – A relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying the type of relationship 76 – An attribute: an annotation on an entity that describes data or properties associated with the entity • Entity diagram of turnstile problem • ER diagrams are popular because – they provide an overview of the problem to be addressed – the view is relatively stable when changes are made to the problem's requirements • ER diagram is likely to be used to model a problem early in the requirements process ER Diagrams Example: UML Class Diagram • UML (Unified Modelling Language) is a collection of notations used to document software specifications and designs • It represents a system in terms of – objects: akin to entities, organized in classes that have an inheritance hierarchy – methods: actions on the object's variables • The class diagram is the flagship model in any UML specification – A sophisticated ER diagram relating the classes (entities) in the specification 77 UML Class Diagram of Library Problem • Attributes and operations may be associated with the class rather than instances of the class • A class-scope attribute represented as an underlined attribute, is a data value that is shared by all instances of the class • A class-scope operation written as underlined operation, is an operation performed by the abstract class rather than by class instances • An association, marked as a line between two classes, indicates a relationship between classes' entities • Aggregate association is an association that represents interaction, or events that involve objects in the association (marked with a white diamond) • “has-a” relationship • Composition association is a special type of aggregation, in which instances of the compound class are physically constructed from instances of component classes (marked with a black diamond) 78 Event Traces • A graphical description of a sequence of events that are exchanged between real-world entities – Vertical line: the timeline of a distinct entity whose name appears at the top of the line – Horizontal line: an event or interaction between the two entities bounding the line – Time progresses from top to bottom • Each graph depicts a single trace, representing one of several possible behaviours • Traces have a semantic that is relatively precise, simple and easy to understand • Graphical representation of two traces for the turnstile problem – traces on the left represent a typical behaviour – traces on the right show an exceptional behaviour Event Traces Example: Message Sequence Chart • An enhanced event-trace notation, with facilities for creating and destroying entities, specifying actions and timers, and composing traces – Vertical line represents a participating entity – A message is depicted as an arrow from the sending entity to the receiving entity – Actions are specified as labelled rectangles positioned on an entity's execution line 79 – Conditions are important states in an entity's evolution, represented with a labelled hexagon • Attributes and operations are associated with the class rather than instances of the class • A class-scope attribute represented as an underlined attribute, is a data value that is shared by all instances of the class • A class-scope operation written as underlined operation, is an operation performed by the abstract class rather than by class instances • An association, marked as a line between two classes, indicates a relationship between classes' entities • Aggregate association is an association that represents interaction, or events that involve objects in the associated (marked with white diamond) • “has-a” relationship • Composition association is a special type of aggregation, in which instances of the compound class are physically constructed from instances of component classes (marked with black diamond) 80 Event Traces • A graphical description of a sequence of events that are exchanged between real-world entities – Vertical line: the timeline of distinct entity, whose name appears at the top of the line – Horizontal line: an event or interaction between the two entities bounding the line – Time progresses from top to bottom • Each graph depicts a single trace, representing one of several possible behaviours • Traces have a semantic that is relatively precise, simple and easy to understand • Graphical representation of two traces for the turnstile problem – trace on the left represents typical behaviour trace on the right shows exceptional behaviour Event Traces Example: Message Sequence Chart • An enhanced event-trace notation, with facilities for creating and destroying entities, specifying actions and timers, and composing traces – Vertical line represents a participating entity – A message is depicted as an arrow from the sending entity to the receiving entity 81 – Actions are specified as labelled rectangles positioned on an entity's execution line – Conditions are important states in an entity's evolution, represented as labelled hexagon • Message sequence chart for library loan transaction State Machines • A graphical description of all dialog between the system and its environment – Node (state) represents a stable set of conditions that exists between event occurrences – Edge (transition) represents a change in behaviour or condition due to the occurrence of an event • Useful both for specifying dynamic behaviour and for describing how behaviour should change in response to the history of events that have already occurred • Finite state machine model of the turnstile problem • 82 • A path: starting from the machine's initial state and following transitions from state to state – A trace of observable events in the environment • Deterministic state machine: for every state and event there is a unique response State Machines Example: UML State chart Diagrams • A UML state chart diagram depicts the dynamic behaviour of the objects in a UML class – UML class diagram has no information about how the entities behave, how the behaviours change • A UML model is a collection of concurrently executing state charts • UML state chart diagram has a rich syntax, including state hierarchy, concurrency, and intermachine communication • State hierarchy is used to unclutter diagrams by collecting into super state those states with common transitions • A superstate can actually comprise multiple concurrent submachines, separated by dashed lines – The submachines are said to operate concurrently • The UML statechart diagram for the Publication class from the Library class model 83 • An equivalent statechart for Publication class that does not make use of state hierarchy or concurrency – comparatively messy and and repetitive 84 • The UML state chart diagram for Loan association class illustrates how states can be annotated with local variables, actions and activities State Machines: Ways of Thinking about State • Equivalence classes of possible future behaviour • Periods of time between consecutive event • Named control points in an object's evolution • Partition of an object's behaviour State Machines Example: Petri Nets • A form or state-transition notation that is used to model concurrent activities and their interaction – Circles (places) represent activities or conditions – Bars represents transitions – Arcs connect a transition with its input places and its output places – The places are populated with tokens, which act as enabling conditions for the transitions 85 – Each arc can be assigned a weight that specifies how many tokens are removed from arc's input place, when the transition fires • Petri net of book loan • A high level Petri net specification for the library problem 86 Data-Flow Diagrams • ER diagram, event trace, state machines depict only lower-level behaviours • A data-flow diagram (DFD) models functionality and the flow of data from one function to another – A bubble represents a process – An arrow represents data flow – A data store: a formal repository or database of information – Rectangles represent actors: entities that provide input data or receive the output result • A high-level data-flow diagram for the library problem • Advantage: – Provides an intuitive model of a proposed system's high-level functionality and of the data dependencies among various processes • Disadvantage: – Can be aggravatingly ambiguous to a software developer who is less familiar with the problem being modelled 87 Data-Flow Diagrams Example: Use Cases • Components – A large box: system boundary – Stick figures outside the box: actors, both human and systems – Each oval inside the box: a use case that represents some major required functionality and its variant – A line between an actor and use case: the actor participates in the use case • Use cases do not model all the tasks, instead they are used to specify user views of essential system behaviour • Library use cases including borrowing a book, returning a borrowed book, and paying a library fine Functions and Relations • Formal methods or approach: mathematically based specification and design techniques • Formal methods model requirements or software behaviouras a collection of mathematical functions or relations 88 – Functions specify the state of the system's execution, and output – A relation is used whenever an input value maps more than one ouput value • Functional method is consistent and complete • Example: representing turnstile problem using two functions – One function to keep track of the state – One function to specify the turnstile output Functions and Relations Example: Decision Tables • It is a tabular representation of a functional specification that maps events and conditions to appropriate responses or action • The specification is formal because the inputs (events and conditions) and outputs (actions) may be expressed in natural language • If there is n input conditions, there are 2n possible combinations of input conditions • Combinations map to the same set of results and can be combined into a single column • Decision table for library functions borrow, return, reserve, and unreserve unlocked s=locked AND e=coin NetState(s,e)= rotating s=unlocked AND e=push locked (s=rotating AND e=rotated) OR (s=locked AND e=slug) buzz s=locked AND e=slug Output(s,e) = Otherwise 89 Functions and Relations Example: Parnas Tables • Tabular representations of mathematical functions or relations – The column and row headers are predicates used to specify cases – The internal table entries store the possible function results – An entry “X” either could be invalid under the specified conditions or the combination of conditions is infeasible 90 Logic • An operational notation is a notation used to describe a problem or a proposed software solution in terms of situational behaviour – Model of case-based behaviour – Examples: state machine, event traces, data-flow diagram, functional method • A descriptive notation is a notation that describes a problem or a proposed solution in terms of its properties or its variant – Example: logic • A logic consists of a language for expressing properties and a set of inference rules for deriving new, consequent properties from the stated properties • In logic, a property specification represents only those values of the property's variables for which the property's expression evaluates to true • It is first-order logic, comprising typed variables, constants, functions, and predicates • Consider the following variables of the turnstile problem, with their initial value • • The first-order logic expressions • Temporal logic introduces additional logical connectives for constraining how variables can change value over time • The following connectives constrain future variable values, over a single execution – □f Ξ f is true now and throughout the rest of execution – ⋄f Ξ f is true now or at some future point in the execution num_coins : integer := 0; /* number of coins inserted */num_entries : integer := 0; /* number of half-rotations of turnstile */barrier :{locked, unlocked}:= locked;/* whether barrier is locked */may_enter : boolean := false; /* event of coin being inserted */push : boolean := false; /* turnstile is pushed sufficiently hard to rotate it one-half rotation*/91 – ○f Ξ f is true in the next point in the execution – f W g = f is true until a point where g is true, but g may never be true • Turnstile properties expressed in temporal logic □(insert_coin => ○ (may_enter W push)) □(∀n(insert_coin ∧ num_coins=n) => ○(num_coins=n+1)) Logic Example: Object Constrain Language (OCL) • A constrain language that is both mathematically precise and easy for non-mathematicians to read, write, and understand • Designed for expressing constrains on object models, and expressing queries on object type Library Classes Annotated with OCL Properties 92 Logic Example: Z • A formal requirements-specification language that – structures set-theoretic definitions of variables into a complete abstract-data-type model of problem – uses logic to express the pre-and post-conditions for each operation • Methods of abstractions are used to decompose a specification into manageable sized modules, called schemas Partial Z Specification for the Library Problem Algebraic Specifications • To specify the behaviourof operations by specifying interactions between pairs of operations rather than modeling individual operations • It is hard to define a set of axioms that is complete and consistent and that reflects the desired behavior 93 Algebraic Specifications Example: SDL Data 4.6 Requirements and Specification Languages Unified Modelling Language (UML) • Combines multiple notation paradigms • Eight graphical modelling notations, and the OCL constrain language, including – Use-case diagram (a high-level DFD) – Class diagram (an ER diagram) – Sequence diagram (an event trace) – Collaboration diagram (an event trace) – State chart diagram (a state-machine model) – OCL properties (logic) Specification and Description Language (SDL) • Standardized by the International Telecommunication Union • Specifies the behaviour of real-time, concurrent, distributed processes that communicate with each other via unbounded message queues • Comprises 94 – SDL system diagram (a DFD) – SDL block diagram (a DFD) – SDL process diagram (a state-machine model) – SDL data type (algebraic specification) • Often accompanied by a set of Message Sequence Chart (MSC) SDL System Diagram • The top-level blocks of the specification and communication channels that connect the blocks • Channels are directional and are labelled with the type of signals • Message is asynchronous • The top-level blocks of the specification and communication channels that connect the blocks • Channels are directional and are labelled with the type of signals • Message is asynchronous • SDL block diagram models a lower-level collection of blocks and the message-delaying channels that interconnect them • Figure depicts a collection of lowest-level processes that communicate via signal routes • Signal routes pass messages synchronously 95 SDL Process Diagram • It is a state-machine whose transitions are sequences of language constructs (input, decisions, tasks, outputs) that start and end at state constructs Software Cost Reduction (SCR) • Collection of techniques that were designed to encourage software developers to employ good software-engineering design principles • Models software requirements as a mathematical function, REQ, that maps monitored variables to controlled variables – monitored variables: environmental variables that are sensed by the system 96 – controlled variables: environmental variables that are set by the system • The function REQ is decomposed into a collection of tabular functions • REQ is the result of composing the tabular functions into network (a DFD) as shown in the picture. • Edges reflect the data dependencies among the functions • Execution steps start with a change in the value of one monitored variable, then propagate through the network, in a single syncronized step Other Features of Requirement Notations • Some techniques include notations – for the degree of uncertainty or risk with each requirement – for tracing requirements to other system documents such as design or code, or to other systems, such as when requirements are reused • Most specification techniques have been automated to some degree 4.7 Prototyping Requirements Building a Prototype • To elicit the details of proposed system • To solicit feedback from potential users about – which aspects they would like to see improve – which features are not so useful – what functionality is missing • Determine whether the customer's problem has a feasible solution • Assist in exploring options for optimizing quality requirements Prototyping Example • Prototype for building a tool to track how much a user exercises each day 97 • Graphical representation of first prototype, in which the user must type the day, month and year • Second prototype shows a more interesting and sophisticated interface involving a calendar – User uses a mouse to select the month and year – The system displays the chart for that month, and the user selects the appropriate date in the chart • Third prototype shows that instead of a calendar, the user is presented with three slide bars – User uses the mouse to slide each bar left or right 98 – The box at the bottom of the screen changes to show the selected day, month, and year Approaches to Prototyping • Throwaway approach – Developed to learn more about a problem or a proposed solution, and that is never intended to be part of the delivered software – Allow us to write “quick-and-dirty” • Evolutionary approach – Developed not only to help us answer questions but also to be incorporated into the final product – Prototype has to eventually exhibit the quality requirements of the final product, and these qualities cannot be retrofitted • Both techniques are sometimes called rapid prototyping Prototyping vs. Modelling • Prototyping – Good for answering questions about the user interfaces • Modelling – Quickly answer questions about constraints on the order in which events should occur, or about the synchronization of activities 99 4.8 Requirements Documentation Requirements Definition: Steps Documenting Process • Outline the general purpose and scope of the system, including relevant benefits, objectives, and goals • Describe the background and the rationale behind proposal for new system • Describe the essential characteristics of an acceptable solution • Describe the environment in which the system will operate • Outline a description of the proposal, if the customer has a proposal for solving the problem • List any assumptions we make about how the environment behaves Requirements Specification: Steps Documenting Process • Describe all inputs and outputs in detail, including – the sources of inputs – the destinations of outputs, – the value ranges – data format of inputs and outputs data – data protocols – window formats and organizations – timing constraint • Restate the required functionality in terms of the interfaces' inputs and outputs • Devise fit criteria for each of the customer's quality requirements Sidebar 4.6 Level of Specification • Survey shows that one of the problems with requirements specifications was the uneven level of specification – Different writing styles – Difference in experience – Different formats – Over specifying requirements 100 – Under specifying requirements • Recommendations to reduce unevenness – Write each clause so that it contains only one requirement – Avoid having one requirement refer to another requirement – Collect similar requirements together Sidebar 4.7 Hidden Assumptions • Two types of environmental behaviour of interest – desired behaviour to be realized by the proposed system – existing behaviour that is unchanged by the proposed system • often called assumptions or domain knowledge • Most requirements writers consider assumptions to be simply the conditions under which the system is guaranteed to operate correctly 101 IEEE Standard for SRS Organized by Objects Process Management and Requirements Traceability • Process management is a set of procedures that track – the requirements that define what the system should do – the design modules that are generated from the requirement – the program code that implements the design – the tests that verify the functionality of the system – the documents that describe the system • It provides the threads that tie the system parts together 102 Development Activities • Horizontal threads show the coordination between development activities 4.9 Validation and Verification • In requirements validation, we check that our requirements definition accurately reflects the customer's needs • In verification, we check that one document or artifact conforms to another • Verification ensures that we build the system right, whereas validation ensures that we build the right system 103 List of techniques to validate requirements Requirements Review • Review the stated goals and objectives of the system • Compare the requirements with the goals and objectives • Review the environment in which the system is to operate • Review the information flow and proposed functions • Assess and document the risk, discuss and compare alternatives • Testing the system: how the requirements will be revalidated as the requirements grow and change Validation Walkthroughs Reading Interviews Reviews Checklists Models to check functions and relationships Scenarios Prototypes Simulation Formal inspections Verification Checking Cross-referencing Simulation Consistency checks Completeness checks Check for unreachable states or transitions Model checking Mathematical proofs 104 Sidebar 4.8 Number of Requirements Faults • Jone and Thayes's studies show that – 35% of the faults to design activities for projects of 30,000-35,000 delivered source instructions – 10% of the faults to requirements activities and 55% of the faults to design activities for projects of 40,000-80,000 delivered source instructions – 8% to 10% of the faults to requirements activities and 40% to 55% of the faults to design activities for projects of 65,000-85,000 delivered source instructions • Basili and Perricone report – 48% of the faults observed in a medium-scale software project were attributed to “incorrect or misinterpreted functional specification or requirements” • Beizer attributes 8.12% of the faults in his samples to problems in functional requirements Verification • Check that the requirements-specification document corresponds to the requirements-definition • Make sure that if we implement a system that meets the specification, then the system will satisfy the customer's requirements • Ensure that each requirement in the definition document is traceable to the specification Sidebar 4.9 Computer-Aided Verification • Model checking is an exhaustive search for a specification's execution space, to determine whether some temporal-logic property holds of the execution – Atlee (1996) used the SMV model checker to verify five properties of an SCR specification of the A-7 naval aircraft • A theorem prover uses a collection of built-in theories, inference rules, and decision procedures for determining whether a set of asserted facts logically entails some unasserted fact – Dutertre and Stavridou (1997) used theorem prover PVS to verify some of the functional and safety requirements of an avionic system 105 4.10 Measuring Requirements • Measurements focus on three areas – product – process – resources • Number of requirements can give us a sense of the size of the developed system • Number of changes to requirements – Many changes indicate some instability or uncertainty in our understanding of the system • Requirement-size and change measurements should be recorded by requirements type Rating Scheme on Scale from 1 to 5 1. You understand this requirement completely, have designed systems from similar requirements, and have no trouble developing a design from this requirement 2. Some elements of this requirement are new, but they are not radically different from requirements that have been successfully designed in the past 3. Some elements of this requirement are very different from requirements in the past, but you understand the requirement and can develop a good design from it 4. You cannot understand some parts of this requirement, and are not sure that you can develop a good design 5. You do not understand this requirement at all, and can not develop a design Testers/Designers Profiles • Figure (a) shows profiles with mostly 1s and 2s – The requirements are in good shape • Figure (b) shows profiles with mostly 4s and 5s 106 – The requirements should be revised 4.11 Choosing a Specification Technique Criteria for Evaluating Specification Methods • Applicability • Implement ability • Testability/Simulation • Check ability • Maintainability • Modularity • Level of abstraction • Soundness • Verifiability • Run time safety • Tools maturity • Looseness • Learning curve • Technique maturity • Data modelling • Discipline 107 Steps • Determine which of the criteria are especially important • Evaluate each of the candidate techniques with respect to the criteria • Choose a specification technique that best supports the criteria that are most important to the problem Importance of Specification Criteria During Reactive-System Life Cyle • R=Requirements, D=Design, I=Implementation, T=Testing, M=Maintenance, O=Other 4.12 Information System Example Picadilly Television System • High-level diagram captures the essential functionality – Shows nothing about the ways in which each of these use cases might succeed or fail R D I T M O Criteria + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Applicability Implementability Testability Checkability Maintainability Modularity Level of abstraction Soundness Verifiability Runtime safety Tools maturity Looseness Learning curve Technique maturity Data modeling Discipline 108 Picadilly Television System: Message Sequence Chart 109 Partial UML Class Diagram 4.13 Real-Time Example • Ariane-5 failed due to requirement validation not done properly – Requirements validation could have played a crucial role in preventing the rocket's explosion • Two criteria that are especially important for specifying a system such as Ariane-5 – Testability/simulation and runtime safety – SDL was rated “strong” for testability/simulation and runtime safety SDL Model • SDL model for coin slot process that consists of several concurrent communicating process 110 4.14 What This Chapter Means for You • It is essential that the requirements definition and specification documents describe the problem, leaving solution selection to designer • There is a variety of sources and means for eliciting requirements • There are many different types of definition and specification techniques • The specification techniques also differ in terms of their tool support, maturity, understand ability, ease of use, and mathematical formality • Requirements questions can be answered using models or prototypes • Requirements must be validated to ensure that they accurately reflect the customer's expectations 111 Chapter 5 Designing the System Objectives • Conceptual design and technical design • Design styles, techniques, and tools • Characteristic of good design • Validating designs • Documenting the design 5.1 What Is Design? • Design is the creative process of transforming the problem into a solution • The description of a solution is also known as design – The requirements specification defines the problem – The design document specifies a particular solution to the problem • Design is a two-part interactive process – Conceptual design (system design) – Technical design 112 5.1 What Is Design? Conceptual Design • Tells the customer what the system will do – Where will the data come from? – What will happen to the data in the system? – What will the system look like to users? – What choices will be offered to users? – What is the timing of events? – What will the reports and screens look like? • Characteristics of good conceptual design – in customer’s language – no technical jargon – describes system functions – independent of implementation – linked to requirements 113 • Graphical representation of the differences in design documentation Technical Design • Tells the programmers what the system will do – major hardware components and their function – hierarchy and functions of software components – data structures – data flow 5.2 Decomposition and Modularity Five Ways to Create Designs • Modular decomposition • Data-oriented decomposition • Event-oriented decomposition • Outside-in design • Object-oriented design 114 Levels of Decomposition • System data description • High level functional descriptions • Creating a hierarchy of information with increasing details Modularity • Modules or components: composite parts of design • A system is modular when – each activity of the system is performed by exactly one component – inputs and outputs of each component are well-defined • all inputs to it are essential to its function • all outputs are produced by one of its actions • Graphical representation of the NIST/ECMA model for environment integration – a software architect uses a high level design to explain general characteristics without detail 115 5.3 Architectural Styles and Strategies Three Design Levels • Architecture: associates system components with capabilities • Code design: specifies algorithms and data structures for each component • Executable design: lowest level of design, including memory allocation, data formats, bit patterns Design Styles • Pipes and filters • Object-oriented design • Implicit invocation • Layering • Repositories • Interpreters • Process control • Client-server Pipes and Filters 116 • The system has – Streams of data (pipe) for input and output – Transformation of the data (filter) • Several important properties – The designer can understand the entire system's effect on input and output as the composition of the filters – The filters can be reused easily on other systems – System evolution is simple – Allow concurrent execution of filters • Drawbacks – Encourages batch processing – Not good for handling interactive application – Duplication in filters’ functions Object-Oriented Design • Must have two characteristics – the object must preserve the integrity of data representation – the data representation must be hidden from other objects 117 • easy to change the implementation without perturbing the rest of the system • One object must know the identity of other objects in order to interact Implicit Invocation • Event-driven, based on notation of broadcasting • Data exchange is through shared data in a repository • Applications – packet-switch networks – databases to ensure consistency – user interfaces • Useful for reusing design components from other system • Disadvantage: lack of assurance that a component will respond to an event Example of Implicit Invocation 118 Layering • Layers are hierarchical – Each layer provides service to the one outside it and acts as a client to the layer inside it • The design includes protocols – Explain how each pair of layers will interact • Advantages – High levels of abstraction – Relatively easy to add and modify a layer • Disadvantages – Not always easy to structure system layers – System performance may suffer from the extra coordination among layers Example of Layering System • A system to provide file security 119 Repositories • Two components – A central data store – A collection of components that operate on it to store, retrieve, and update information • The challenge is deciding how the components will interact – A traditional database: transactions trigger process execution – A blackboard: the central store controls the triggering process • Major advantage: openness – Data representation is made available to various programmers (vendors) so they can build tools to access the repository – But also a disadvantage: the data format must be acceptable to all components Interpreters • A virtual machine that “interprets” pseudo code in a way that makes it executable – Used not only to convert programming language, but also to convert any kind of encoding to a more explicit form • Composed of four components 120 – A memory to contain pseudo code to be interpreted – An interpretation engine – The current state of the interpretation engine – The current state of the program being simulated Example of an Interpreter Process Control • Characterized by – the type of component – the relationships that hold among components • Purpose: maintain specified properties of process outputs at or near specified reference values called set points • Issues in designing a process control system – What variables to monitor – What sensor to use 121 – How to calibrate them – How to deal with the timing of sensing and control • Software-based control system involves a closed loop in one of two forms, feedback and feedforward as illustrated in the picture Other Styles • Distributed system architecture: client-server – Advantage • Users get the information they need only when they need it – Disadvantage • Need more sophisticated security, system management, and application development • Domain-specific architecture – Take advantage of the commonalities afforded by the application domain (e.g., avionics) • Heterogeneous architectures 122 Client-Server • Distributed systems usually described in terms of the topology of their configuration. • They can be organized as a ring or as a star as shown in the picture Sidebar 5.1 The World Cup Client-Server System • Required both central control and distributed functions • The system built included a central database for ticket management, security, news service, and Internet link • The server also calculated games statistics, provided historical information, security photographs, and clips of video action • The clients ran on 1600 Sun workstations 123 Chapter 6 Considering Objects Contents 6.1 What is OO? 6.2 The OO Development Process 6.3 Use Cases 6.4 Representing OO: An Example Using UML 6.5 OO System Design 6.6 OO Program Design 6.7 OO Measurement 6.8 Information System Example 6.9 Real Time Example 6.10 What this Chapter Means for You Chapter 6 Objectives • The special nature of object-oriented development • Use cases • Using UML • Object-oriented system design • Object-oriented program design • Object-oriented measurement 6.1 What is OO? • Object-orientation is an approach to software development that organizes both the problem and its solution as a collection of discrete objects – Data structure – Behavior 124 6.1 What is OO? Sidebar 6.1 Royal Service Station Requirements • Royal Service station provides three types of services • The system must track bills, the product, and services • System to control inventory • The system to track credit history, and payments overdue • The system applies only to regular repeat customers • The system must handle the data requirements for interfacing with other systems • The system must record tax and related information • The station must be able to review tax record upon demand • The system will send periodic message to customers • Customers can rent parking space in the station parking lot • The system maintains a repository of account information • The station manager must be able to review accounting information upon demand • The system can report an analysis of prices and discounts • The system cannot be unavailable for more than 24 hours • The system must protect customer information from unauthorized access • The system will automatically notify the owners of dormant accounts Object-Orientation Characteristics • Identity • Abstraction • Classification • Encapsulation • Inheritance • Polymorphism • Persistence 125 Objects and Classes • Reference or handle: name of object • Objects can have – attributes (such as color, size, location) – operations or behaviors (such as takeoff, land, repair) • Each object is an instance of a class • Class: group of objects that have attributes and behaviors in common • Method: a specific implementation of an operation for a certain class • Examples of objects grouped into classes • We can represent a class using a box • Box represents – object’s name – attributes – behaviors 126 Classes Hierarchy • A class hierarchy is organized according to the sameness or differences among classes – Exhibits OO classes’ inheritance structure • A class is refined into subclasses • Subclasses may inherit the structure as well as the behavior and attributes of its super class • Abstract class is used to simplify the hierarchy – No objects of the abstract class may be defined except as instances of a subclass • Example of forming a hierarchy 127 6.2 The OO Development Process • One advantage of OO development is its consistency of language • Describing classes using OO representation requires three perspectives – Static views: descriptions of the object, attributes, behaviors, and relationships – Dynamic views: describe communication, control/timing, and the state and changes in state – Restrictions: describe constraints on the structure Tendency of Change when Using OO Paradigm Characteristic of Software Product/Project Probability for Change Objects derived from application Low Long-lived information structures Low Passive object’s attributes Medium Sequences of behavior Medium Interface with outside world High Functionality High OO Requirements • Usually done in user’s language and discusses the concepts and scenarios likely in the application domain • The concepts include information services and responsibilities • Domain knowledge enables the developers – to understand the context in which the system will be used – to describe the requirements in a way that the user will understand 128 OO Design • Usually uses an OO requirements representation • System design identifies and represents objects and classes, plus details of each object’s attributes and behaviors • System design also identifies interactions and relationships • Program design inserts computational features in the models • Program design inserts class library details • Program design considers nonfunctional requirements to enhance design OO Coding and Testing • Coding proceeds by translating the models to an OO programming language • It is necessary to refine the hierarchical structures and make adjustments as the requirements grow and mature • Testing involves some of the same activities that are performed when testing any kind of system • Graphical representation of how the abstraction level relates to various types of tests that are performed 129 6.3 Use Cases • Describes particular functionality that a system is supposed to perform or exhibit by modeling the dialog that a user, external system, or other entity will have with the system to be developed • Diagrams have four elements – actors – cases – extensions – uses Example of Use Cases • High-level view of Royal Service Station requirements • First extension part of the use case diagram of Royal Service Station requirements to include preventive maintenance 130 • Second extension of Royal Service Station diagram to include credit card system • Third extension of Royal Service Station diagram to include inventory and accounting 131 Identifying Participants • What users or groups use the system to perform a task? • What users or groups are needed so that the system can perform its functions? • What external systems use the system to perform a task? • What external systems, users, or groups send information to the system? • What external systems, users, or groups receive information from the system? 6.4 Representing OO: An Example Using UML UML in the OO Process • Workflow diagrams • Object model • Sequence diagrams • Collaboration diagrams • Package diagrams • Component diagrams • Deployment diagrams • How UML can be used in requirements specification, design, and coding 132 6.5 OO System Design First Cut at Object Classes • Structures • External systems • Devices • Roles • Operating procedures • Places • Organizations • Things that are manipulated by the system to be built Guidelines for Building Classes • What needs to be “processed” in some way? • What items have multiple attributes? • When do you have more than one object in a class? • What is based on the requirements themselves, not derived from your understanding of the requirements? • What attributes and operations are always applicable to a class or object? 133 First Grouping of Attributes and Classes: Step 1 Attributes Classes personal check customer tax maintenance price services cash parking credit card fuel discount bill purchase station manager First Grouping of Attributes and Classes: Step 2 Attributes Classes personal check tax price cash credit card discount birthdate name address customer maintenance services parking fuel bill purchase periodic message station manager 134 First Grouping of Attributes and Classes: Step 3 Attributes Classes personal check tax price cash credit card discount birthdate name address customer maintenance services parking fuel bill purchase periodic message station manager warning letter parts accounts inventory credit card system part-ordering system fuel-ordering system Guidelines for Identifying Behaviors • Imperative verbs • Passive verbs • Actions • Things or reminded events • Roles • Operating procedures 135 • Services provided by an organization UML Diagram • A UML box used to illustrate the component of a class UML Diagram to Describe Relationship • Inheritance relationship (is-a relationship): lower box inherits the attributes and behaviors of the upper box • Each order is associated with salesperson (associated) • The order item is part of the order (aggregation) 136 • Graphical representation of several other ways of denoting relationships between classes UML Notation for Notes and Qualifiers • The picture shows how class association can be enhanced with notes and qualifiers 137 First Cut at Royal Service Station Design Second Cut at Royal Service Station Design 138 Third and Final Cut at Royal Service Station Design A Class Description Template • Describes class in more detail • Tells us – the position of the class (in terms of inheritance) in the overall hierarchy – the export controls – the cardinality – association with other classes 139 • Specifies the operations in the class and the public interface to the class Example of a Class Description Template Package Diagram • View the system as a small collection of packages, which can be expanded to a larger set of classes • Show the dependencies among classes as they belong to different packages • Two items are dependent if changes to the definition of one may cause changes to the other 140 Package Diagram for the Royal Service Station • There are four major packages • The service package consists of five key classes Interaction Diagram • Describe how operations and behaviors are handled by the objects in the design • Two kinds of interaction diagrams – Sequence diagram: shows the sequence in which activities or behaviors occur – Collaboration diagram: shows how the objects are connected statically Sequence Diagram for the Royal Service Station • Showing the use case of the refuel class • Shows the parking use case 141 State Diagram • To document a dynamic model of the system • Shows – the possible states an object can take – the events that trigger the transition from one state to the next – the actions that result from each state change • Needed only for classes where the objects exhibit dynamic behavior, with many attribute values and messages State Diagram Example • Black dot: start node • Smaller black dot inside a white dot: end node • Rectangle: a state • Arrow: transition 142 State Diagram for the Royal Service Station System • State diagrams for the fuel and parts classes • State diagram for the inventory class, orders parts or fuel: a different condition triggers each state 143 Activity Diagram • To model the flow of procedures or activities in a class • A decision node is used to represent a choice of which activity to invoke Activity Diagram for the Royal Service Station • An activity diagram for the inventory class • It may have two decisions – to verify that there is enough fuel – to verify that a part is in stock 144 6.6 OO Program Design • Begins with the objects and classes from the system design • During program design – Make more detailed decisions about the data structures – Specify the features of each object’s interface – Need to know the operation signature • name each operation • the objects it takes as parameters • The values returned by the operation • An object’s interface: the collection of all its operation’s signature Program Design Considerations • Nonfunctional requirements • Reused components • Reusable components • User interface requirements • Data structure and management details 145 Construction Paradigms • White-box reuse: one class inherits properties from another class – Gives us a static view of the system at compile time – Modification is easier and more straightforward – The inheritance can not easily be changed at runtime • Black-box reuse: built up from component classes – Enforces the encapsulation built into the system design – Allows easy replacement of one component with other – Not always clear which objects reference to other objects Design Aids • A toolkit: a set of related, reusable classes • A pattern: a template of abstract architectural elements – Context: explains the situations in which pattern would be appropriate – Forces: elements of the context • A framework: a reuse part of a domain-specific design Sidebar 6.2 Approaches to Creating Patterns • Abstract factory • Builder • Factory method • Prototype • Singleton User Interface Design • Defining the humans who will interact with the system • Developing scenarios for each way that the system can perform a task • Designing hierarchy of user commands • Refining sequence of user interactions with the system 146 • Designing relevant classes in the hierarchy to implement the user interface design decision • Integrating the user interface classes in the overall system class hierarchy • The first step in user interface design is to lay out the interaction on paper • The left-hand side of the picture shows the paper bill, the right-hand side shows a screen of automated billing process User Interface Design Example • Possible design for new billing screen of the Royal Service Station system 147 Data Management Design • Four steps – Identify the data, data structure, and relationships among them – Design services to manage the data structures and relationships – Find tools, such as database management systems, to implement some of the data management tasks – Design classes and class hierarchies to oversee the data management functions • An OO solution can use conventional files or relational databases, but it interfaces most easily with OO databases Data Management Design: Using a Relational Database • Database to track vehicle maintenance and parts Task Management Design • A task: a process in the system – Event-driven task: initiated when a particular event occurs – Time-driven task: invoked at a particular time • Four steps – Identify the task to be performed – Determine priorities for the tasks – Create a task to coordinate all other tasks 148 – Design objects for each task, and define the relationships among them Task Management Design: A Task Definition Example Task name: order parts Description: Purpose is to order new parts automatically when there are not enough parts already in stock Priority: High. It must be activated when the inventory warns the parts in stock are low Included services: Verify inventory Managed by/Manager: Service Station System Communicates by: modem with the order_parts system Sidebar 6.3 Gamma et. al’s Pattern for Task Management • Chain of responsibility • Command • Interpreter • Iterator • Mediator • Memento • Observer • State • Strategy • Template Method • Visitor Task Management Design: The Observer Pattern • Useful when an abstraction has at least two aspects, and some are dependent on the others – One-to-many dependency • Involves four major constructs – Subject – Observer 149 – Concrete subject – Concrete observer The Observer Pattern • Graphical representation of relationship among observer pattern constructs • Sequence diagram to show how the four constructs interact 6.7 OO Measurement OO Size Measure • Pfleeger (1991): used objects and methods as a basic size measure • Lorenz and Kidd’s nine aspects of size – Number of scenario script (NSS) 150 – Number of key classes – Number of support classes – The average number of support classes per key classes – Number of subsystems – Class size – Number of operations overridden by a subclass (NOO) – Number of operations added by a subclass – Specialization index • SI = (NOO X level) /(total class methods) Lorenz and Kidd Metrics Collection in Different Phases of Development Metric Requirements Description System Design Program Design Coding Testing Number of scenario script X Number of key classes X X Number of support classes X Average number of support classes per key class X Number of subsystem X X Class size X X X Number of operations overridden by a subclass X X X X Number of operations added by a subclass X X X Specialization index X X X X 151 OO Size Measure of the Royal Service Station • Using Lorenz and Kidd’s metrics, the number of scenario scripts is equal to six Class Hierarchy for the Royal Service Station, plus Lorenz and Kidd Measures OO Design Measures • Chidamber and Kemerer have also devised a suite of metrics for object-oriented development – Weighted methods per class = nS ci i=1 – Depth of inheritance – Number of children 152 – Coupling between objects – Response for a class – Lack of cohesion of methods Chidamber and Kemerer Metrics Collection in Different Phases of Development Metric System Design Program Design Coding Testing Weighted methods per class X X X Depth of inheritance X X X Number of children X X X Coupling between objects X X Response for a class X X Lack of cohesion of methods X X X Chidamber-Kemerer Metrics Applied to the Royal Service Station’s System Design 153 Calculating the Lack of Cohesion • Given class C with n methods, M1 through Mn • Suppose {Ijj} is the set of instance variables used by the method M • We can define P to be collection of pairs (Ir , Is) where Ir and Is, share no common members – P = {(Ir , Is) | Ir ∩ Is = Ø} • Q is the collection of pairs (Ir , Is) where Ir and Is, share at least one common member – Q = {(Ir , Is) | Ir ∩ Is ≠ Ø} • Lack of cohesion in methods for C to be – |P|-|Q| if |P| > |Q| – Zero if otherwise 154 Chidamber-Kemerer Metrics applied to the Royal Service Station’s Program Design Other Metrics • Li and Henry (1993): metrics to predict the size of changes in classes during maintenance – Message-passing coupling – Data abstraction coupling • Travassos (1999) – The average operation size – The average number of parameters per operation 155 Travassos Metrics Applied to the Royal Service Station’s Sequence Diagram 156 Where to Do OO Measurement Metric Use cases Class diagram Interaction diagram Class description State diagram Package diagram Number of scenario scripts X Number of key classes X Number of support classes X Average number of support classes per key class X Number of subsystems X Class size X X Number of operation overridden by a subclass X Number of operation added by a subclass X Specialization index X Weighted methods in class X Depth of inheritance X Number of children X Coupling between objects X Response for a class X Lack of cohesion in methods X Average operation size X Average number of parameters per operation X Operation complexity X 157 Percent public and protected X Public access to data members X Number of root classes X Fan-in/fan-out X 6.8 Information System Example Data Flow Diagram as Basis for Use Cases for the Piccadilly System 158 Class Diagram for the Advertising Campaign • First cut at two classes to deal with ratings prediction 6.9 Real-Time Example • Had Ariane-5 been implemented using an object-oriented approach, the reuse would have been either in terms of composition or inheritance • In composition approach: the SRI is viewed as a black box and called from the main system • In inheritance approach: the SRI structure and behaviour are open to view, inheriting as much structure and behaviour from parent classes as possible 6.10 What This Chapter Means for You • Use cases are embellished to generate a system design, painting a high-level portrait of how the system will solve problem at hand • Program design implements nonfunctional requirements • UML is becoming a de facto standard way of describing OO system • There are several metrics that are commonly used to measure size and characteristic of OO artifacts 159 Chapter 7 Writing the Programs Contents 7.1 Programming Standards and Procedures 7.2 Programming Guidelines 7.3 Documentation 7.4 The Programming Process 7.5 Information System Example 7.6 Real Time Example 7.7 What this Chapter Means for You Objectives • Standards for programming • Guidelines for reuse • Using design to frame the code • Internal and external documentation 7.1 Programming Standards and Procedures • Standards for you – Methods of code documentation • Standards for others – Integrators, maintainers, testers – Prologue documentation – Automated tools to identify dependencies • Matching design with implementation – Low coupling, high cohesion, well-defined interfaces 160 Sidebar 7.1 Programming Standards at Microsoft • Allow flexibility to be creative and evolve product’s details in stages • Flexibility does not preclude standards 7.2 Programming Guidelines Control Structures • Make the code easy to read • Build the program from modular blocks • Make the code not too specific, and not too general • Use parameter names and comments to exhibit coupling among components • Make the dependency among components visible Example of Control Structures • Control skips around among the program’s statements benefit = minimum; if (age < 75) goto A; benefit = maximum; goto C; if (AGE < 65) goto B; if (AGE < 55) goto C; A: if (AGE < 65) goto B; benefit = benefit * 1.5 + bonus; goto C; B: if (age < 55) goto C; benefit = benefit * 1.5; C: next statement • Rearrange the code if (age < 55) benefit = minimum; elseif (AGE < 65) benefit = minimum + bonus; 161 elseif (AGE < 75) benefit = minimum * 1.5 + bonus; else benefit = maximum; Algorithms • Common objective and concern: performance (speed) • Efficiency may have hidden costs – cost to write the code faster – cost to test the code – cost to understand the code – cost to modify the code Data Structures • Several techniques that use the structure of data to organize the program – Keeping the program simple – Using a data structure to determine a program structure Keep the Program Simple Example: Determining Federal Income Tax 1. For the first $10,000 of income, the tax is 10% 2. For the next $10,000 of income above $10,000, the tax is 12 percent 3. For the next $10,000 of income above $20,000, the tax is 15 percent 4. For the next $10,000 of income above $30,000, the tax is 18 percent 5. For any income above $40,000, the tax is 20 percent tax = 0. if (taxable_income == 0) goto EXIT; if (taxable_income > 10000) tax = tax + 1000; else{ tax = tax + .10*taxable_income; goto EXIT; } if (taxable_income > 20000) tax = tax + 1200; 162 else{ tax = tax + .12*(taxable_income-10000): goto EXIT; } if (taxable_income > 30000) tax = tax + 1500; else{ tax = tax + .15*(taxable_income-20000); goto EXIT; } if (taxable_income < 40000){ tax = tax + .18*(taxable_income-30000); goto EXIT; } else tax = tax + 1800. + .20*(taxable_income-40000); EXIT; • Define a tax table for each “bracket” of tax liability Bracket Base Percent 0 0 10 10,000 1000 12 20,000 2200 15 30,000 3700 18 40,000 55000 20 • Simplified algorithm for (int i-2); level=1; i <= 5; i++) if (taxable_income > bracket[i]) 163 level = level + 1; tax = base[level]+percent[level]*(taxable_income-bracket[level]); Data Structures Example: Rooted Tree • Recursive data structure • Graph composed of nodes and lines – Exactly one node as root – If the lines emanating from the root are erased, the resulting graph is a rooted tree 164 General Guidelines to Preserve Quality • Localize input and output • Employ pseudo code • Revise and rewrite, rather than patch • Reuse – Producer reuse: create components designed to be reused in future applications – Consumer reuse: reuse components initially developed for other projects Example of Pseudo code • The design for a component of a text processing system states COMPONENT PARSE_LINE Read next eighty characters. IF this is a continuation of the previous line, Call CONTINUE ELSE determine command type ENDIF CASE of COMMAND_TYPE COMMAND_TYPE is paragraph: Call PARAGRAPH COMMAND_TYPE is indent : Call INDENT COMMAND_TYPE is skip line: Call SKIP_LINE COMMAND_TYPE is margin : Call MARGIN COMMAND_TYPE is new page : Call PAGE COMMAND_TYPE is double space : Call DOUBLE_SPACE COMMAND_TYPE is single space : Call SINGLE_SPACE COMMAND_TYPE is break : Call BREAK COMMAND_TYPE is anything else: Call ERROR ENDCASE • Intermediate pseudo code 165 PARAGRAPH: Break line, flush line buffer. Advance one line between paragraph. If fewer than 2 lines left on page, eject. Set line pointer to paragraph indent. INDENT: Break line, flush line buffer. Get indent parameter. Set line pointer to indent parameter, set left margin to indent. SKIP_LINE: Break line, flush line buffer. Get line parameter. Advance (parameter) lines or eject if not enough space left on current page. MARGIN: Break line, flush line buffer. Get margin parameter. Set line pointer to left margin. Set right margin to margin. PAGE: Break line, flush line buffer. Eject page. Set line pointer to left margin DOUBLE_SPACE: Set interline space to 2. SINGLE_SPACE: Set interline space to 1 BREAK: Break line, flush line buffer. Set pointer to left margin • Regrouped FIRST: PARAGRAPH, INDENT, SKIP_LINE, MARGIN, BREAK, PAGE: Break line, flush line buffer. DOUBLE_SPACE, SINGLE_SPACE : No break line, no flush line buffer. SECOND: INDENT, SKIP_LINE, MARGIN: Get parameter. 166 PARAGRAPH, BREAK, PAGE, DOUBLE_SPACE, SINGLE_SPACE: No parameter needed. THIRD: PARAGRAPH, INDENT, SKIP_LINE, MARGIN, BREAK, PAGE: Set new line pointer. DOUBLE_SPACE, SINGLE_SPACE: New line pointer unchanged. FOURTH: Individual action taken • Final pseudo code INITIAL: Get parameter for indent, skip_line, margin. Set left margin to parameter for indent. Set temporary line pointer to left margin for all but paragraph; for paragraph, set to paragraph indent. LINE_BREAKS: If not (DOUBLE_SPACE or SINGLE_SPACE), break line, flush line buffer and set line pointer to temporary line pointer If 0 lines left on page, eject page and print page header. INDIVIDUAL CASES: INDENT, BREAK: do nothing. SKIP_LINE: skip parameter lines or eject PARAGRAPH: advance 1 line; if < 2 lines or page, eject. MARGIN: right_margin = parameter. DOUBLE_SPACE: interline_space = 2. SINGLE_SPACE: interline_space = 1; PAGE: eject page, print page header 167 Consumer Reuse • Four key characteristics to check about components to reuse – Does the component perform the function or provide the data needed? – Is it less modification than building the component from scratch? – Is the component well-documented? – Is there a complete record of the component’s test and revision history? Producer Reuse • Several issues to keep in mind – Make the components general – Separate dependencies (to isolate sections likely to change) – Keep the component interface general and well-defined – Include information about any faults found and fixed – Use clear naming conventions – Document data structures and algorithms – Keep the communication and error-handling sections separate and easy to modify Sidebar 7.2 Selecting Components for Reuse at Lucent • Reuse Council – Created inventory of components – Formed matrix with the features of all past and planned projects – Met every week to make component selections, inspect design documentation, and monitor levels of reuse 7.3 Documentation • Internal documentation – header comment block – meaningful variable names and statement labels – other program comments 168 – format to enhance understanding – document data (data dictionary) • External documentation – describe the problem – describe the algorithm – describe the data Information Included in Header Comment Block • What the component is called • Who wrote the component • Where the component fits in the general system design • When the component was written and revised • Why the component exists • How the component uses its data structures, algorithms, and control 7.4 The Programming Process Programming as Problem-Solving • Polya’s (1957) four distinct stages of finding a good solution – understanding the problem – devising plan – carrying out the plan – looking back Extreme Programming • Two types of participants – customers: who define the features using stories, describe detailed tests, and assign priorities – programmers: who implement the stories 169 Pair Programming • The driver or pilot: controlling the computer and writing the code • The navigator: reviewing the driver’s code and providing feedback Whither Programming? • Documentation is still essential in agile-methods – Assists the developers in planning, as a roadmap – Helps describe key abstractions and defines system boundaries – Assists in communicating among team members 7.5 Information System Example Piccadilly System • Design Description Input: Opposition schedule For each Television company name, create Opposition company. For each Opposition schedule, Locate the Episode where Episode schedule date = Opposition transmission date AND Episode start time = Opposition transmission time Create instance of Opposition program Create the relationships Planning and Competing Output: List of Opposition programs • Data dictionary description Opposition schedule = * Data flow * Television company name + {Opposition transmission date + Opposition transmission time + Opposition program name + (Opposition predicted rating)} 170 Piccadilly System’s Implementation • Passing by value void Match:: calv(Episode episode_start_time) { first_advert = episode_start_time + increment; //The system makes a copy of Episode //and your program can use the values directly. } • Passing by pointer void Match:: calp(Episode* episode) { episode->setStart (episode->getStart()); //This example passes a pointer to an instance of Episode. //Then the routine can invoke the services (such as setStart //and getStart) of Episode using the -> operator. } • Passing by reference void Match:: calr(Episode& episode) { episode.setStart (episode.getStart()); //This example passes the address of Episode. //Then the routine can invoke the services (such as setStart //and getStart) of Episode using the . operator. } 171 7.6 Real-Time Example Ariane-5 • Should have included an exception handler try { } catch (…..) { //attempt to patch up state //either satisfy post condition or raise exception again } 7.7 What This Chapter Means for You • Things to consider when writing a code – organizational standards and guidelines – reusing code from other projects – writing code to make it reusable on future projects – using the low-level design as an initial framework, and moving in several iterations from design to code 172 Chapter 8 Testing the Programs Contents 8.1 Software Faults and Failures 8.2 Testing Issues 8.3 Unit Testing 8.4 Integration Testing 8.5 Testing Object-Oriented Systems 8.6 Test Planning 8.7 Automated Testing Tools 8.8 When to Stop Testing 8.9 Information System Example 8.10 Real Time Example 8.11 What this Chapter Means for You Objectives • Types of faults and how to classify them • The purpose of testing • Unit testing • Integration testing strategies • Test planning • When to stop testing 8.1 Software Faults and Failures Why Does Software Fail? • Wrong requirement: not what the customer wants • Missing requirement • Requirement impossible to implement • Faulty design 173 • Faulty code • Improperly implemented design Objective of Testing • Objective of testing: discover faults • A test is successful only when a fault is discovered – Fault identification is the process of determining what fault caused the failure – Fault correction is the process of making changes to the system so that the faults are removed Types of Faults • Algorithmic fault • Computation and precision fault – a formula’s implementation is wrong • Documentation fault – Documentation doesn’t match what program does • Capacity or boundary faults – System’s performance not acceptable when certain limits are reached • Timing or coordination faults • Performance faults – System does not perform at the speed prescribed • Standard and procedure faults Typical Algorithmic Faults • An algorithmic fault occurs when a component’s algorithm or logic does not produce proper output – Branching too soon – Branching too late – Testing for the wrong condition – Forgetting to initialize variable or set loop invariants 174 – Forgetting to test for a particular condition – Comparing variables of inappropriate data types • Syntax faults Orthogonal Defect Classification Fault Type Meaning Function Fault that affects capability, end-user interface, product interface with hardware architecture, or global data structure Interface Fault in interacting with other component or drivers via calls, macros, control blocks, or parameter lists Checking Fault in program logic that fails to validate data and values properly before they are used Assignment Fault in data structure or code block initialization Timing/serialization Fault in timing of shared and real-time resources Build/package/merge Fault that occurs because of problems in repositories, management changes, or version control Documentation Fault that affects publications and maintenance notes Algorithm Fault involving efficiency or correctness of algorithm or data structure but not design 175 Sidebar 8.1 Hewlett-Packard’s Fault Classification 176 Sidebar 8.1 Faults for one Hewlett-Packard Division 8.2 Testing Issues Testing Organization • Module testing, component testing, or unit testing • Integration testing • Function testing • Performance testing • Acceptance testing • Installation testing Testing Organization Illustrated 177 Attitude toward Testing • Egoless programming: programs are viewed as components of a larger system, not as the property of those who wrote them Who Performs the Test? • Independent test team – avoid conflict – improve objectivity – allow testing and coding concurrently Views of the Test Objects • Closed box or black box: functionality of the test objects • Clear box or white box: structure of the test objects White Box • Advantage – free of internal structure’s constraints • Disadvantage 178 – not possible to run a complete test Clear Box • Example of logic structure Sidebar 8.2 Box Structures • Black box: external behaviour description • State box: black box with state information • White box: state box with a procedure Factors Affecting the Choice of Test Philosophy • The number of possible logical paths • The nature of the input data • The amount of computation involved • The complexity of algorithms 179 8.3 Unit Testing Code Review • Code walkthrough • Code inspection Typical Inspection Preparation and Meeting Times Development Artifact Preparation Time Meeting Time Requirement Document 25 pages per hour 12 pages per hour Functional specification 45 pages per hour 15 pager per hour Logic specification 50 pages per hour 20 pages per hour Source code 150 lines of code per hour 75 lines of code per hour User documents 35 pages per hour 20 pages per hour Fault Discovery Rate Discovery Activity Faults Found per Thousand Lines of Code Requirements review 2.5 Design Review 5.0 Code inspection 10.0 Integration test 3.0 180 Acceptance test 2.0 Sidebar 8.3 The Best Team Size for Inspections • The preparation rate, not the team size, determines inspection effectiveness • The team’s effectiveness and efficiency depend on their familiarity with their product Proving Code Correct • Formal proof techniques • Symbolic execution • Automated theorem-proving Proving Code Correct: An Illustration 181 Testing versus Proving • Proving: hypothetical environment • Testing: actual operating environment Steps in Choosing Test Cases • Determining test objectives • Selecting test cases • Defining a test Test Thoroughness • Statement testing • Branch testing • Path testing • Definition-use testing • All-uses testing • All-predicate-uses/some-computational-uses testing • All-computational-uses/some-predicate-uses testing Relative Strengths of Test Strategies 182 Comparing Techniques • Fault discovery Percentages by Fault Origin Discovery Techniques Requirements Design Coding Documentation Prototyping 40 35 35 15 Requirements review 40 15 0 5 Design Review 15 55 0 15 Code inspection 20 40 65 25 Unit testing 1 5 20 0 183 • Effectiveness of fault-discovery techniques Requirements Faults Design Faults Code Faults Documentation Faults Reviews Fair Excellent Excellent Good Prototypes Good Fair Fair Not applicable Testing Poor Poor Good Fair Correctness Proofs Poor Poor Fair Fair Sidebar 8.4 Fault Discovery Efficiency at Contel IPC • 17.3% during inspections of the system design • 19.1% during component design inspection • 15.1% during code inspection • 29.4% during integration testing • 16.6% during system and regression testing • 0.1% after the system was placed in the field 8.4 Integration Testing • Bottom-up • Top-down • Big-bang • Sandwich testing • Modified top-down • Modified sandwich Terminology • Component Driver: a routine that calls a particular component and passes a test case to it • Stub: a special-purpose program to simulate the activity of the missing component 184 View of a System • System viewed as a hierarchy of components Bottom-Up Integration Example • The sequence of tests and their dependencies 185 Top-Down Integration Example • Only A is tested by itself Modified Top-Down Integration Example • Each level’s components individually tested before the merger takes place Big-Bang Integration Example • Requires both stubs and drivers to test the independent components 186 Sandwich Integration Example • Viewed system as three layers 187 Modified Sandwich Integration Example • Allows upper-level components to be tested before merging them with others 188 Comparison of Integration Strategies Bottom-up Top-down Modified top-down Big-bang Sandwich Modified sandwich Integration Early Early Early Late Early Early Time to basic working program Late Early Early Late Early Early Component drivers needed Yes No Yes Yes Yes Yes Stubs needed No Yes Yes Yes Yes Yes Work parallelism at beginning Medium Low Medium High Medium High Ability to test particular paths Easy Hard Easy Easy Medium Easy Ability to plan and control sequence Easy Hard Hard Easy Hard hard Sidebar 8.5 Builds at Microsoft • The feature teams synchronize their work by building the product and finding and fixing faults on a daily basis 189 8.5 Testing Object-Oriented Systems Questions at the Beginning of Testing OO System • Is there a path that generates a unique result? • Is there a way to select a unique result? • Are there useful cases that are not handled? Easier and Harder Parts of Testing OO Systems • OO unit testing is less difficult, but integration testing is more extensive 190 Differences Between OO and Traditional Testing • The farther the gray line is out, the more the difference 191 8.6 Test Planning • Establish test objectives • Design test cases • Write test cases • Test test cases • Execute tests • Evaluate test results Purpose of the Plan • Test plan explains – who does the testing – why the tests are performed – how tests are conducted – when the tests are scheduled Contents of the Plan • What the test objectives are • How the test will be run • What criteria will be used to determine when the testing is complete 8.7 Automated Testing Tools • Code analysis – Static analysis • code analyzer • structure checker • data analyzer • sequence checker • Output from static analysis 192 • Dynamic analysis – program monitors: watch and report program’s behavior • Test execution – Capture and replay – Stubs and drivers – Automated testing environments • Test case generators 8.8 When to Stop Testing More faulty? • Probability of finding faults during the development 193 Stopping Approaches • Coverage criteria • Fault seeding detected seeded faults = detected nonseeded faults total seeded faults total nonseeded faults • Confidence in the software, C = 1, if n >N = S/(S – N + 1) if n ≤ N Identifying Fault-Prone Code • Track the number of faults found in each component during the development • Collect measurements (e.g., size, number of decisions) about each component • Classification trees: a statistical technique that sorts through large arrays of measurement information and creates a decision tree to show best predictors – A tree helps in deciding the which components are likely to have a large number of errors An Example of a Classification Tree 194 8.9 Information System Example Piccadilly System • Using data-flow testing strategy rather than structural – Definition-use testing 8.10 Real-Time Example The Ariane-5 System • The Ariane-5’s flight control system was tested in four ways – equipment testing – on-board computer software testing – staged integration – system validation tests • The Ariane-5 developers relied on insufficient reviews and test coverage 195 8.11 What this Chapter Means for You • It is important to understand the difference between faults and failures • The goal of testing is to find faults, not to prove correctness 196 Chapter 9 Testing the System Contents 9.1 Principles of system testing 9.2 Function testing 9.3 Performance testing 9.4 Reliability, availability, and maintainability 9.5 Acceptance testing 9.6 Installation testing 9.7 Automated system testing 9.8 Test documentation 9.9 Testing safety-critical systems 9.10 Information System example 9.11 Real-time example 9.12 What this chapter means for you Chapter 9 Objectives • Function testing • Performance testing • Acceptance testing • Software reliability, availability, and maintainability • Installation testing • Test documentation • Testing safety-critical systems 9.1 Principles of System Testing Source of Software Faults During Development 197 System Testing Process • Function testing: does the integrated system perform as promised by the requirements specification? • Performance testing: are the non-functional requirements met? • Acceptance testing: is the system what the customer expects? • Installation testing: does the system run at the customer site(s)? • Pictorial representation of steps in testing process 198 Techniques Used in System Testing • Build or integration plan • Regression testing • Configuration management – versions and releases – production system vs. development system – deltas, separate files, and conditional compilation – change control Build or Integration Plan • Define the subsystems (spins) to be tested • Describe how, where, when, and by whom the tests will be conducted Example of Build Plan for Telecommunication System Spin Functions Test Start Test End 0 Exchange 1 September 15 September 1 Area code 30 September 15 October 199 2 State/province/district 25 October 5 November 3 Country 10 November 20 November 4 International 1 December 15 December Example Number of Spins for Star Network • Spin 0: test the central computer’s general functions • Spin 1: test the central computer’s message-translation function • Spin 2: test the central computer’s message-assimilation function • Spin 3: test each outlying computer in the stand alone mode • Spin 4: test the outlying computer’s message-sending function • Spin 5: test the central computer’s message-receiving function Regression Testing • Identifies new faults that may have been introduced as current ones are being corrected • Verifies a new version or release still performs the same functions in the same manner as an older version or release 200 Regression Testing Steps • Inserting the new code • Testing functions known to be affected by the new code • Testing essential function of m to verify that they still work properly • Continuing function testing m + 1 Sidebar 9.1 The Consequences of Not Doing Regression Testing • A fault in software upgrade to the DMS-100 telecom switch – 167,000 customers improperly billed $667,000 Configuration Management • Versions and releases • Production system vs. development system • Deltas, separate files, and conditional compilation • Change control Sidebar 9.2 Deltas and Separate Files • The Source Code Control System (SCCS) – uses delta approach – allows multiple versions and releases • Ada Language System (ALS) – stores revision as separate, distinct files – freezes all versions and releases except for the current one Sidebar 9.3 Microsoft’s Build Control • The developer checks out a private copy • The developer modifies the private copy • A private build with the new or changed features is tested • The code for the new or changed features is placed in master version • Regression test is performed 201 Test Team • Professional testers: organize and run the tests • Analysts: who created requirements • System designers: understand the proposed solution • Configuration management specialists: to help control fixes • Users: to evaluate issues that arise 9.2 Function Testing Purpose and Roles • Compares the system’s actual performance with its requirements • Develops test cases based on the requirements document Cause-and-Effect Graph • A Boolean graph reflecting logical relationships between inputs (causes), and the outputs (effects), or transformations (effects) Cause-and-Effect Graphs Example • INPUT: The syntax of the function is LEVEL(A,B) where A is the height in meters of the water behind the dam, and B is the number of centimeters of rain in the last 24-hour period • PROCESSING: The function calculates whether the water level is within a safe range, is too high, or is too low • OUTPUT: The screen shows one of the following messages 1. “LEVEL = SAFE” when the result is safe or low 2. “LEVEL = HIGH” when the result is high 3. “INVALID SYNTAX” Depending on the result of the calculation 202 Notation for Cause-and-Effect Graph • Causes 1. The first five characters of the command “LEVEL” 2. The command contains exactly two parameters separated by a comma and enclosed in parentheses 3. The parameters A and B are real numbers such that the water level is calculated to be LOW 4. The parameters A and B are real numbers such that the water level is calculated to be SAFE 5. The parameters A and B are real numbers such that the water level is calculated to be HIGH • Effects 1. The message “LEVEL = SAFE” is displayed on the screen 2. The message “LEVEL = HIGH” is displayed on the screen 203 1. The message “INVALID SYNTAX” is printed out • Intermediate nodes 1. The command is syntactically valid 2. The operands are syntactically valid Cause-and-Effect Graphs of LEVEL Function Example • Exactly one of a set of conditions can be invoked • At most one of a set of conditions can be invoked • At least one of a set of conditions can be invoked • One effect masks the observance of another effect • Invocation of one effect requires the invocation of another 204 Decision Table for Cause-and-Effect Graph of LEVEL Function Test 1 Test 2 Test 3 Test 4 Test 5 Cause 1 I I I S I Cause 2 I I I X S Cause 3 I S S X X Cause 4 S I S X X Cause 5 S S I X X Effect 1 P P A A A Effect 2 A A P A A Effect 3 A A A P P Additional Notation for Cause-and-Effect Graph 205 9.3 Performance Tests Purpose and Roles • Used to examine – the calculation – the speed of response – the accuracy of the result – the accessibility of the data • Designed and administrated by the test team Types of Performance Tests • Stress tests • Volume tests • Configuration tests • Compatibility tests • Regression tests • Security tests • Timing tests • Environmental tests • Quality tests • Recovery tests • Maintenance tests • Documentation tests • Human factors (usability) tests 9.4 Reliability, Availability, and Maintainability Definition • Software reliability: operating without failure under given condition for a given time interval • Software availability: operating successfully according to specification at a given point in time 206 • Software maintainability: for a given condition of use, a maintenance activity can be carried out within stated time interval, procedures and resources Different Levels of Failure Severity • Catastrophic: causes death or system loss • Critical: causes severe injury or major system damage • Marginal: causes minor injury or minor system damage • Minor: causes no injury or system damage Failure Data • Table of the execution time (in seconds) between successive failures of a command-and-control system Interfailure Times (Read left to right, in rows) 3 30 113 81 115 9 2 91 112 15 138 50 77 24 108 88 670 120 26 114 325 55 242 68 422 180 10 1146 600 15 36 55 242 68 227 65 176 58 457 300 97 263 452 255 197 193 6 79 816 1351 148 21 233 134 357 193 236 31 369 748 0 232 330 365 1222 543 10 16 529 379 44 129 810 290 300 529 281 160 828 1011 445 296 1755 1064 1783 860 983 707 33 868 724 2323 2930 1461 843 12 261 1800 865 1435 30 143 108 0 3110 1247 943 700 875 245 729 1897 447 386 446 122 990 948 1082 22 207 75 482 5509 100 10 1071 371 790 6150 3321 1045 648 5485 1160 1864 4116 • Graph of failure data from previous table Uncertainty Inherent from Failure Data • Type-1 uncertainty: how the system will be used • Type-2 uncertainty: lack of knowledge about the effect of fault removal Measuring Reliability, Availability, and Maintainability • Mean time to failure (MTTF) • Mean time to repair (MTTR) • Mean time between failures (MTBF) – MTBF = MTTF + MTTR • Reliability – R = MTTF/(1+MTTF) 208 • Availability – A = MTBF (1+MTBF) • Maintainability – M = 1/(1+MTTR) Reliability Stability and Growth • Probability density function f or time t, f (t): when the software is likely to fail • Distribution function: the probability of failure – F(t) = ∫ f (t) dt • Reliability Function: the probability that the software will function properly until time t – R(t) = 1-F(t) Uniformity Density Function • Uniform in the interval from t=0..86,400 because the function takes the same value in that interval Sidebar 9.4 Difference Between Hardware and Software Reliability • Complex hardware fails when a component breaks and no longer functions as specified • Software faults can exist in a product for long time, activated only when certain conditions exist that transform the fault into a failure 209 Reliability Prediction • Predicting next failure times from past history Elements of a Prediction System • A prediction model: gives a complete probability specification of the stochastic process • An inference procedure: for unknown parameters of the model based on values of t₁, t₂, …, ti-1 • A prediction procedure: combines the model and inference procedure to make predictions about future failure behavior Sidebar 9.5 Motorola’s Zero-Failure Testing • The number of failures to time t is equal to – a e-b(t) • a and b are constant • Zero-failure test hour – [ln ( failures/(0.5 + failures)] X (hours-to-last-failure) ln[(0.5 + failures)/(test-failures + failures) 210 Reliability Model • The Jelinski-Moranda model: assumes – no type-2 uncertainty – corrections are perfect – fixing any fault contributes equally to improving the reliability • The Littlewood model – treats each corrected fault’s contribution to reliability as independent variable – uses two source of uncertainty Successive Failure Times for Jelinski-Moranda I Mean Time to ith failure Simulated Time to ith Failure 1 22 11 2 24 41 3 26 13 4 28 4 5 30 30 6 33 77 7 37 11 8 42 64 9 48 54 10 56 34 11 67 183 12 83 83 211 13 111 17 14 167 190 15 333 436 Sidebar 9.6 Inappropriate Use of A Beta Version • Problem with the Pathfinder’s software – NASA used VxWorks operating system for PowerPC’s version to the R6000 processor • A beta version • Not fully tested Result of Acceptance Tests • List of requirements – are not satisfied – must be deleted – must be revised – must be added 9.5 Acceptance Tests Purpose and Roles • Enable the customers and users to determine if the built system meets their needs and expectations • Written, conducted, and evaluated by the customers Types of Acceptance Tests • Pilot test: install on experimental basis • Alpha test: in-house test • Beta test: customer pilot • Parallel testing: new system operates in parallel with old system 9.6 Installation Testing 212 • Before the testing – Configure the system – Attach proper number and kind of devices – Establish communication with other system • The testing – Regression tests: to verify that the system has been installed properly and works 9.7 Automated System Testing Simulator • Presents to a system all the characteristics of a device or system without actually having the device or system available • Looks like other systems with which the test system must interface • Provides the necessary information for testing without duplicating the entire other system Sidebar 9.7 Automated Testing of A Motor Insurance Quotation System • The system tracks 14 products on 10 insurance systems • The system needs large number of test cases • The testing process takes less than one week to complete by using automated testing 9.8 Test Documentation • Test plan: describes system and plan for exercising all functions and characteristics • Test specification and evaluation: details each test and defines criteria for evaluating each feature • Test description: test data and procedures for each test • Test analysis report: results of each test 213 Documents Produced During Testing Test Plan • The plan begins by stating its objectives, which should – guide the management of testing – guide the technical effort required during testing – establish test planning and scheduling – explain the nature and extent of each test – explain how the test will completely evaluate system function and performance – document test input, specific test procedures, and expected outcomes Parts of a Test Plan 214 Test-Requirement Correspondence Chart Test Requirement 2.4.1: Generate and Maintain Database Requirement 2.4.2: Selectively Retrieve Data Requirement 2.4.3: Produced Specialized Reports 1. Add new record X 2. Add field X 3. Change field X 4. Delete record X 5. Delete field X 215 6. Create index X Retrieve record with a requested 7. Cell number X 8. Water height X 9. Canopy height X 10. Ground cover X 11, Percolation rate X 12. Print full database X 13. Print directory X 14. Print keywords X 15. Print simulation summary X Sidebar 9.8 Measuring Test Effectiveness and Efficiency • Test effectiveness can be measured by dividing the number of faults found in a given test by the total number of faults found • Test efficiency is computed by dividing the number of faults found in testing by the effort needed to perform testing Test Description • Including – the means of control – the data – the procedures 216 Test Description Example Test Script for Testing The “change field” 217 Test Analysis Report • Documents the result of test • Provides information needed to duplicate the failure and to locate and fix the source of the problem • Provides information necessary to determine if the project is complete • Establish confidence in the system’s performance Problem Report Forms • Location: Where did the problem occur? • Timing: When did it occur? • Symptom: What was observed? • End result: What were the consequences? • Mechanism: How did it occur? • Cause: Why did it occur? • Severity: How much was the user or business affected? • Cost: How much did it cost? Example of Actual Problem Report Forms 218 Example of Actual Discrepancy Report Forms 9.9 Testing Safety-Critical Systems • Design diversity: use different kinds of designs, designers • Software safety cases: make explicit the ways the software addresses possible problems – failure modes and effects analysis – hazard and operability studies (HAZOPS) • Clean room: certifying software with respect to the specification Ultra-High Reliability Problem • Graph of failure data from a system in operational use 219 Sidebar 9.9 Software Quality Practices at Baltimore Gas and Electric • To ensure high reliability – checking the requirements definition thoroughly – performing quality reviews – testing carefully – documenting completely – performing thorough configuration control Sidebar 9.10 Suggestions for Building Safety-Critical Software • Recognize that testing cannot remove all faults or risks • Do not confuse safety, reliability, and security • Tightly link the organization’s software and safety organizations • Build and use a safety information system • Instill a management culture safety • Assume that every mistake users can make will be made 220 • Do not assume that low-probability, high-impact events will not happen • Emphasize requirements definition, testing, code and specification reviews, and configuration control • Do not let short-term considerations overshadow long-term risks and cost Perspective for Safety Analysis Known cause Unknown cause Known effect Description of system behavior Deductive analysis, including fault tree analysis Unknown effect Inductive analysis, including failures modes and effect analysis Exploratory analysis, including hazard and operability statistics Sidebar 9.11 Safety and the Therac-25 • Atomic Energy of Canada Limited (AECL) performed a safety analysis – identify single fault using a failure modes and effects analysis – identify multiple failures and quantify the results by performing a fault tree analysis – perform detailed code inspections • AECL recommended – 10 changes to the Therac-25 hardware, including interlocks to back up software control energy selection and electron-beam scanning HAZOP Guide Words Guide word Meaning No No data or control signal sent or received 221 More Data volume is too high or fast Less Data volume is too low or slow Part of Data or control signal is incomplete Other than Data or control signal has additional component Early Signal arrives too early for system clock Late Signal arrives too late for system clock Before Signal arrives earlier in sequence than expected After Signal arrives later in sequence than expected SHARD Guide Words Flow Provision Failure Categorization Timing Value Protocol Type Omission Commission Early Late Subtle Coarse Pool Boolean No update Unwanted Update N/A Old data Stuck at … N/A Value No update Unwanted Update N/A Old data Wrong tolerance Out of tolerance 222 Complete No update Unwanted Update N/A Old data Incorrect Inconsistent Channel Boolean No data Extra data Early Late Stuck at … N/A Value No data Extra data Early Late Wrong tolerance Out of tolerance Complete No data Extra data Early Late Incorrect inconsistent Clean room Control Structures and Correctness Conditions 223 A Program and Its Subproofs Sidebar 9.12 When Statistical Usage Testing Can Mislead • Consider fault occurs for each – saturated condition: 79% of the time – non saturated condition: 20% of the time – transitional condition: 1% of the time – probability of failures: 0.001 • To have a 50% chance of detecting each fault, we must run – non saturated: 2500 test cases – transitional : 500,000 test cases – saturated: 663 test cases • Thus, testing according to the operational profile will detect the most faults • However, transition situations are often the most complex and failure-prone • Using the operational profile would concentrate on testing the saturated mode, when in fact we should be concentrating on the transitional faults 224 9.10 Information System Example The Piccadilly System • Many variables, many different test cases to consider – An automated testing tool may be useful Things to Consider in Selecting a Test Tool • Capability • Reliability • Capacity • Learn ability • Operability • Performance • Compatibility • Nonintrusiveness Sidebar 9.13 Why Six-Sigma Efforts Do Not Apply to Software • A six-sigma quality constraint says that in a billion parts, we can expect only 3.4 to be outside the acceptable range • It is not apply to software because – People are variable, the software process inherently contains a large degree of uncontrollable variation – Software either conforms or it does not, there are no degrees of conformance – Software is not the result of a mass-production process 9.11 Real-Time Example Ariane-5 Failure • Simulation might have helped prevent the failure – Could have generated signals related to predicted flight parameters while turntable provided angular movement 225 9.12 What This Chapter Means for You • Should anticipate testing from the very beginning of the system life cycle • Should think about system functions during requirement analysis • Should use fault-tree analysis, failure modes and effect analysis during design • Should build safety case during design and code reviews • Should consider all possible test cases during testing 226 Chapter 11 Maintaining the System Contents 11.1 The Changing System 11.2 The Nature of Maintenance 11.3 Maintenance Problems 11.4 Measuring Maintenance Characteristics 11.5 Maintenance Techniques and Tools 11.6 Software Rejuvenation 11.7 Information System Example 11.8 Real Time Example 11.9 What this Chapter Means for You Objectives • System evolution • Legacy systems • Impact analysis • Software rejuvenation 11.1 The Changing System • Maintenance: any work done to change the system after it is in operation – Software does not degrade or require periodic maintenance – However, software is continually evolving • Maintenance process can be difficult Lehman’s System Types • S-system: formally defined, derivable from a specification • P-system: requirements based on approximate solution to a problem, but real-world remains stable • E-system: embedded in the real world and changes as the world does 227 S-System • Problem solved is related to the real world 228 P-System • The solution produces information that is compared with the problem 229 E-System • It is an integral part of the world it models – The changeability depends on its real-world context Changes During the System Life Cycle • S-system: un-change • P-system: incremental change • E-system: constant change 230 Examples of Change During Software Development Activity from which Initial change results Artifacts requiring consequent change Requirements analysis Requirements specification System design Architectural design specification Technical design specification Program design Program design specification Program implementation Program code Program documentation Unit testing Test plans Test scripts System testing Test plans Test scripts System delivery User documentation Operator documentation System guide Programmer’s guide Training classes The System Life Span • Will we need maintenance phase? – Development time vs. maintenance time • How much change can we expect? – System evolution vs. system decline 231 – Laws of software evolution Development Time Vs. Maintenance Time • Parikh and Zvegintzov (1983) – Development time: 2 years – Maintenance time: 5 to 6 years • Fjedstad and Hamlen (1979) – 39% of effort in development – 61% of effort in maintenance • 80-20 rule – 20% of effort in development – 80% of effort in maintenance System Evolution vs. Decline • Is the cost of maintenance too high? • Is the system reliability unacceptable? • Can the system no longer adapt to further change, and within a reasonable amount of time? • Is system performance still beyond prescribed constraints? • Are system functions of limited usefulness? • Can other systems do the same job better, faster, or cheaper? • Is the cost of maintaining the hardware great enough to justify replacing it with cheaper, newer hardware? Laws of Software Evolution • Continuing change: leads to less utility • Increasing complexity: structure deteriorates • Fundamental law of program evolution: program obeys statistically-determined trends and has invariants • Conservation of organizational stability: global activity rate is invariant • Conservation of familiarity: release content is invariant 232 Sidebar 11.1 Bell Atlantic Replaces Three Systems with One Evolving One • Sales Service Negotiation System (SSNS) – Replaced three legacy system – The goals of the system changed from order-taking to needs-based sales – Replaced archaic commands with plain English – Originally written in C and C++, the system was modified with Java 11.2 The Nature of Maintenance Types of Maintenance • Corrective: maintaining control over day-to-day functions • Adaptive: maintaining control over system modifications • Perfective: perfecting existing functions • Preventive: preventing system performance from degrading to unacceptable levels Who Performs Maintenance • Separate maintenance team – May be more objective – May find it easier to distinguish how a system should work from how it does work • Part of development team – Will build the system in a way that makes maintenance easier – May feel over-confident, and ignore the documentation to help maintenance effort Maintenance Team Responsibilities • Understanding the system • Locating information in system documentation • Keeping system documentation up-to-date • Extending existing functions to accommodate new or changing requirements • Adding new functions to the system • Finding the source of system failures or problems • Locating and correcting faults 233 • Answering questions about the way the system works • Restructuring design and code components • Rewriting design and code components • Deleting design and code components that are no longer useful • Managing changes to the system as they are made Use of Maintenance Time • Graphical representation of distribution of maintenance effort (Lientz and Swanson) 11.3 Maintenance Problems • Staff problems – Limited understanding – Management priorities – Morale • Technical problems – Artifacts and paradigms – Testing difficulties 234 Sidebar 11.2 The Benefits and Drawbacks of Maintaining OO System • Benefits – Maintenance changes to a single object class may not affect the rest of the program – Maintainers can reuse objects easily • Drawbacks – OO techniques may make programs more difficult to understand – Multiple parts can make it difficult to understand overall system behavior – Inheritance can make dependencies difficult to trace – Dynamic binding makes it impossible to determine which of several methods will be executed – By hiding the details of data structure, program function is often distributed across several classes The Need to Compromise • Balancing need for change with the need for keeping the system available to users – The complaint is usually brought by a user or operator • Fixing problem quick but inelegant solution, or more involved but elegant way – Solving problem involves only the immediate correction of a fault Sidebar 11.3 Balancing Management and Technical Needs at Chase Manhattan • Relationship Management System (RMS) – Developed by Chemical Bank, and then modified and merged with Global Management System – Combined with other systems to eliminate duplication and link hardware platforms and business office – Windows-based GUI was developed – Modified to allow it to run spreadsheets and print reports using Microsoft products – Incorporated Lotus Notes 235 Factors Affecting Maintenance Approach • The type of failure • The failure’s criticality or severity • The difficulty of the needed changes • The scope of the needed changes • The complexity of the components being changed • The number of physical locations at which the changes must be made Factors Affecting Maintenance Effort • Application type • System novelty • Turnover and maintenance staff ability • System life span • Dependence on a changing environment • Hardware characteristics • Design quality • Code quality • Documentation quality • Testing quality Modeling Maintenance Effort: Belady and Lehman • M = p + Kc-d – M : total maintenance effort – p : productive effort – c: complexity – d : degree of familiarity – K : empirical constant Modeling Maintenance Effort: COCOMO II 236 • Size = ASLOC (AA + SU + 0.4DM + 0.3CM + 0.3IM)/100 – ASLOC: number of source lines of code to be adapted – AA: assessment and assimilation effort – SU: amount of software understanding required – DM: percentage of design to be modified – CM: percentage of code to be modified – IM: percentage of external code to be integrated COCOMO II Rating for SU Very low Low Nominal High Very high Structure Very low cohesion, high coupling, spaghetti code Moderately low cohesion, high coupling Reasonably well structured, some weak areas High cohesion, low coupling Strong modularity, information hiding in data and control structure Application clarity No match between program and application worldviews Some correlation between program and application Moderate correlation between program and application Good correlation between program and application Clear match between program and application worldviews Self descriptiveness Obscure code; documentation missing, obscure, or obsolete Some code commentary headers; some useful documentation Moderate level of code commentary headers, and documentation Good code commentary and headers; useful documentation; some weak areas Self descriptive code; documentation up-to-date , well organized, with design rationale SU increment 50 40 30 20 10 237 COCOMO II Rating AA Effort Assessment and Assimilation Increment Level of Assessment and Assimilation Effort 0 None 2 Basic component search and documentation 4 Some component test and evaluation documentation 6 Considerable component test and evaluation documentation 8 Extensive component test and evaluation documentation 11.4 Measuring Maintenance Characteristics • Maintainability is not only restricted to code, but also including specification, design, and test plan documentations • Maintainability can be viewed in two ways – External view of the software – Internal view of the software External View of Maintainability • Necessary data – time at which problem is reported – time lost due to administrative delay – time required to analyze problem – time required to specify which changes are to be made – time needed to make the change – time needed to test the change – Time needed to document the change 238 • Desirable data – ratio of total change implementation time to total number of changes implemented – number of unresolved problems – time spent on unresolved problems – percentage of changes that introduce new faults – number of components modified to implement a change • Graph illustrates the mean time to repair the various subsystems for software at a large British firm Internal Attributes Affecting Maintainability • Cyclomatic number (McCabe, 1976) – The structural complexity of the source code • linearly independent path – Based on graph theoretic concept 239 Example for Calculating Cyclomatic Number • Consider the following code Scoreboard::drawscore(int n) { while(numdigits--> 0} { score[numdigits]->erase(); } //build new score in loop, each time update position numdigits = 0; //if score is 0, just display “0” if (n == 0) { delete score[numdigits]; score[numdigits] = new Displayable(digits[0]); score[numdigits]->move(Point((700-numdigits*18),40)); score[numdigits]->draw(); numdigits++; } while (n) { int rem = n % 10; delete score[numdigits]; score[numdigits] = new Displayable(digits[rem]); score[numdigits]->move(Point(700-numdigits*18),40)); score[numdigits]->draw(); n /= 10; numdigits++; } } 240 • Linearly independent path = e -n + 2 – e: edges, n : nodes Other Measures • Classification tree analysis – Identify product measures that are the best predictors of interface errors • Fog index: textual products, readability affects maintainability – F = 0.4 X (number of words/number of sentences) + percentage of words of three or more syllables • De Young and Kampen readability – R = 0.295a – 0.499b + 0.13c • a : the average normalized length of variable • b: number of lines containing statements • c : McCabe’s cyclomatic number 241 Sidebar 11.4 Models of Fault Behavior • Hatton and Hopkins (1989) studied the NAG Fortran scientific subroutine library – Smaller components contained proportionately more faults than larger ones • They notes similar evidence – at Siemens – Ada code at Unisys – Fortran products at NASA Goddard Sidebar 11.5 Maintenance Measures at Hewlett-Packard • Used maintainability index – Index was calibrated with a large number of metrics – A tailored polynomial index was calculated using extended cyclomatic number, lines of code, number of comments, and an effort measure – The polynomial was applied to 714 components containing 236,000 lines of C code developed by third party 11.5 Maintenance Techniques and Tools • Configuration management – Configuration control board – Change control • Impact analysis • Automated maintenance tools Configuration Control Process • Problem discovered by or change requested by user/customer/developer, and recorded • Change reported to the configuration control board • CCB discusses problem: determines nature of change, who should pay • CCB discusses source of problem, scope of change, time to fix; they assign severity/priority and analyst to fix • Analyst makes change on test copy 242 • Analyst works with librarian to control installation of change • Analyst files change report Change Control Issues • Synchronization: When was the change made? • Identification: Who made the change? • Naming: What components of the system were changed? • Authentication: Was the change made correctly? • Authorization: Who authorized that the change be made? • Routing: Who was notified of the change? • Cancellation: Who can cancel the request for change? • Delegation: Who is responsible for the change? • Valuation: What is the priority of the change? Impact Analysis • The evaluation of many risks associated with the change, including estimates of effects on resources, effort, and schedule • Helps control maintenance cost Software Maintenance Activities • Graph illustrates the activities performed when a change is requested 243 Measuring Impact of Change • Work product: any development artifact whose change is significant • Horizontal traceability: relationships of components across collections of workproducts • Vertical traceability: relationships among parts of a workproduct 244 Underlying Graph for Maintenance Sidebar 11.6 Applying Traceability to Real-World System • Five kinds of traceability – object-to-object – association-to-association – use case-to-use case – use case-to-object – two-dimensional object-to-object • How tracing is performed – Using explicit links – Using textual references to different documents – Using names and concepts that are the same and similar – Using knowledge and domain knowledge 245 Automated Maintenance Tools • Text editors • File comparators • Compilers and linkers • Debugging tools • Cross-reference generators • Static code analyzers • Configuration management repositories Sidebar 11.7 Panvalet • Incorporates the source code, object code, control language, and data files needed to run a system • Controls more than one version of a system – A single version is designated as the production version, and no one is allowed to alter it • Places the version number and date of last change on the compiler listing and object module automatically when a file is compiled • Has reporting, backup, and recovery features, plus three levels of security access 11.6 Software Rejuvenation • Redocumentation: static analysis adds more information • Restructuring: transform to improve code structure • Reverse engineering: recreate design and specification information from the code • Reengineering: reverse engineer and then make changes to specification and design to complete the logical model; then generate new system from revised specification and design Taxonomy • Graph illustrates the relationship among the four types of rejuvenation 246 Redocumentation • Begins by submitting the code to an analysis tool • Output may include: – component calling relationships – data-interface tables – data-dictionary information – data flow tables or diagrams – control flow tables or diagrams – pseudo code – test paths – component and variable cross-references 247 Redocumentation Process • Graph illustrates redocumentation process Restructuring Activities • Interpreting the source code and representing it internally • Simplifying the internal representation • Regenerating structured code • Graph illustrates the three major activities involved in restructuring 248 Reverse Engineering • Attempting to recover engineering information based on software specification and design methods • Obstacles remain before reverse engineering can be used universally – Real time system problem – Extremely complex system 249 Reverse Engineering Process • Graph depicts the reverse-engineering process Reengineering • An extension of reverse engineering – produces new software code without changing the overall system function • Reengineering steps – The system is reverse-engineered – The software system is corrected or completed – The new system is generated Reengineering Process • Graph illustrates the steps in reengineering process 250 Sidebar 11.8 Reengineering Effort • The U.S National Institute of Standard and Technology (NIST) studied the results of reengineering 13,131 lines of COBOL source statements using automatic translation – Entire reengineering effort took 35 person-month • Boehm point out that original COCOMO model estimated 152 person months for reengineering the same type of system, clearly unacceptable level of accuracy – COCOMO II has been revised to include a factor for automatic translation 11.7 Information System Example Piccadilly System • The software can not be an S-system – the problem may change dramatically • The software can not be a P-system – P-system requires a stable abstraction, while Piccadilly changes constantly • The software must be E-system 251 – The system is an integral part of the world it models 11.8 Real-Time Example Ariane-5 • Developers focused on mitigating random failure – The inertial reference system failed because of a design fault, not a result of a random failure • Needs to change the failure strategy and implement a series of preventive enhancements • Invokes change control and configuration management 11.9 What this Chapter Means for You • The more a system is linked to the real world, the more likely it will change and the more difficult it will be to maintain • Maintainers have many jobs in addition to software developers • Measuring maintainability is difficult • Impact analysis builds and tracks links among the requirements, design, code, and test cases • Software rejuvenation involves redocumenting , restructuring, reverse engineering, and reengineering