P. 1
SWEng Course

SWEng Course

|Views: 83|Likes:
Published by s_arunmozhi02

More info:

Published by: s_arunmozhi02 on Nov 26, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

09/25/2012

pdf

text

original

Sections

  • 1. Introduction to software Engineering and project planning
  • 1.1 Product
  • Evolving role of software
  • Software
  • Software Characteristics
  • Software Components
  • Software Applications
  • 1.2 Process
  • Process, Methods and Tools
  • Software Process
  • Software Process Models
  • Linear Sequential Model
  • The Prototyping Model
  • The RAD Model
  • Evolutionary Models
  • 1.3 Project Management
  • People
  • The Problem
  • The Process
  • The Project
  • 1.4 Software Process and Project Metrics
  • Measures, Metrics, and Indicators
  • Software Measurement
  • Metrics for Software Quality
  • 1.5 Software Project Planning
  • Project Planning Objectives
  • Software Scope
  • 1.6 Risk Management
  • Software Risks
  • Risk Identification
  • Risk Projection
  • 2. Analysis and Requirement Specification
  • 2.1 Analysis Concepts and Principles
  • Requirement Analysis
  • Requirements Analysis
  • Communication Techniques
  • Analysis Principles
  • Software Prototyping
  • Specification
  • 2.2 Analysis Modeling
  • Data Modeling
  • Entity-Relationship Diagrams
  • Functional Modeling
  • Data Flow Diagrams
  • Behavioral Modeling
  • State-transition diagram
  • Data Dictionary
  • 3. Design
  • 3.1 Design Concepts and Principles
  • Software Design
  • Design Process
  • Design principles
  • Design Concepts
  • Abstraction
  • Refinement
  • Modularity
  • Software architecture
  • Information Hiding
  • 3.2 Design Methods
  • Data Design
  • Architectural Design
  • Transform Flow
  • Transaction flow
  • Transform flow
  • Transform Mapping
  • "Transform" mapping
  • Transaction Mapping
  • Interface Design
  • Interface Design Models
  • Procedural Design
  • Structured Programming
  • Graphical Design Notation
  • Tabular Design Notation
  • Program Design Language
  • 4. Software Configuration Management
  • Baselines
  • Software configuration items
  • SCM process
  • Identification of objects in the software configuration
  • Version control
  • Change control
  • Configuration audit
  • Status Reporting
  • SCM Standards
  • 5. Testing
  • 5.1 Software Testing Techniques
  • Software Testing Fundamentals
  • Testing Objectives
  • Testing principles
  • Testability
  • Test Case Design
  • White Box Testing
  • Basis Path Testing
  • Flow graph notation
  • Cyclomatic complexity
  • Deriving test cases
  • Graph matrices
  • Control Structure Testing
  • Loop testing
  • Black-Box Testing
  • Equivalence Partitioning
  • Boundary value analysis
  • Testing for Specialized environments
  • 5.2 Software Testing Strategies
  • A strategic Approach to software testing
  • Verification and validation
  • Organizing for software testing
  • A software testing strategy
  • Unit Testing
  • Unit test considerations
  • Unit test procedures
  • Integration Testing
  • Top-down Integration
  • Bottom-up integration
  • Regression testing
  • Validation Testing
  • Validation test criteria
  • Configuration Review
  • Alpha and Beta Testing
  • System Testing
  • 6. Debugging
  • Debugging Process
  • Debugging Approaches
  • Brute force approach
  • Backtracking approach
  • Cause elimination approach

Software Engineering

Courseware

©2002 Park Enhanced Research For Emerging Communications Technologies (P) Ltd.

EMBEDDED SYSTEMS Page 1 of 72

Software Engineering

Table of Contents
1. Introduction to software Engineering and project planning..................................................................5 1.1 Product...................................................................................................................................................5 Evolving role of software.........................................................................................................................5 Software....................................................................................................................................................5 Software Characteristics.......................................................................................................................5 Software Components...........................................................................................................................5 Software Applications..........................................................................................................................6 1.2 Process...................................................................................................................................................7 Process, Methods and Tools.....................................................................................................................7 Software Process.......................................................................................................................................7 Software Process Models..........................................................................................................................7 Linear Sequential Model.......................................................................................................................7 The Prototyping Model.........................................................................................................................8 The RAD Model...................................................................................................................................9 Evolutionary Models............................................................................................................................9 1.3 Project Management............................................................................................................................11 People.....................................................................................................................................................11 The Problem............................................................................................................................................11 The Process.............................................................................................................................................11 The Project..............................................................................................................................................11 1.4 Software Process and Project Metrics.................................................................................................12 Measures, Metrics, and Indicators..........................................................................................................12 Software Measurement...........................................................................................................................12 Metrics for Software Quality..................................................................................................................12 People.................................................................................................................................................12 1.5 Software Project Planning...................................................................................................................13 Project Planning Objectives....................................................................................................................13 Software Scope.......................................................................................................................................13 1.6 Risk Management.................................................................................................................................13 Software Risks........................................................................................................................................13 Risk Identification..................................................................................................................................13 Risk Projection........................................................................................................................................13 2. Analysis and Requirement Specification................................................................................................14 2.1 Analysis Concepts and Principles........................................................................................................14 Requirement Analysis.............................................................................................................................14 Communication Techniques...................................................................................................................15 Analysis Principles.................................................................................................................................17 Software Prototyping..............................................................................................................................19 Specification...........................................................................................................................................19 2.2 Analysis Modeling................................................................................................................................20 Data Modeling........................................................................................................................................21 Orders............................................................................................................................................................22 Entity-Relationship Diagrams............................................................................................................23

EMBEDDED SYSTEMS Page 2 of 72

Functional Modeling...............................................................................................................................24 Data Flow Diagrams...........................................................................................................................24 Behavioral Modeling..............................................................................................................................26 State-transition diagram .....................................................................................................................26 Data Dictionary.......................................................................................................................................26 3. Design.........................................................................................................................................................27 3.1 Design Concepts and Principles..........................................................................................................27 Software Design......................................................................................................................................27 Design Process........................................................................................................................................28 Design principles....................................................................................................................................28 Design Concepts.....................................................................................................................................29 Abstraction..........................................................................................................................................29 Refinement..........................................................................................................................................29 Modularity..........................................................................................................................................29 Software architecture..........................................................................................................................30 Information Hiding.............................................................................................................................32 3.2 Design Methods....................................................................................................................................33 Data Design............................................................................................................................................33 Architectural Design...............................................................................................................................33 Transform Flow..................................................................................................................................34 Transaction flow.................................................................................................................................34 Transform Mapping............................................................................................................................35 Transaction Mapping..........................................................................................................................36 Interface Design......................................................................................................................................37 Interface Design Models.....................................................................................................................37 Procedural Design...................................................................................................................................38 Structured Programming.....................................................................................................................38 Graphical Design Notation.................................................................................................................38 Tabular Design Notation.....................................................................................................................41 Program Design Language.................................................................................................................42 .....................................................................................................................................................................43 4. Software Configuration Management....................................................................................................44 Baselines.................................................................................................................................................44 Software configuration items..................................................................................................................46 SCM process...........................................................................................................................................46 Identification of objects in the software configuration.......................................................................46 Version control...................................................................................................................................47 Change control....................................................................................................................................48 Configuration audit.............................................................................................................................50 Status Reporting..................................................................................................................................50 SCM Standards.......................................................................................................................................51 5. Testing .......................................................................................................................................................51 5.1 Software Testing Techniques................................................................................................................51 Software Testing Fundamentals.............................................................................................................51 Testing Objectives..............................................................................................................................51 Testing principles................................................................................................................................51 Testability...........................................................................................................................................52 Test Case Design....................................................................................................................................52

EMBEDDED SYSTEMS Page 3 of 72

.....................................................67 Bottom-up integration.63 A strategic Approach to software testing...70 Debugging Process...............................................................................................................................65 Unit test procedures.............................................................................................................................................................................................................................................................White Box Testing.........................................................................................69 Configuration Review........................64 Verification and validation.................................................................................69 Alpha and Beta Testing..............................................................................................64 Organizing for software testing......................72 EMBEDDED SYSTEMS Page 4 of 72 ..........................................................................................................................................................................................................................................................................................61 Boundary value analysis.................................................................................55 Deriving test cases..........................................................................................................................................................................................................................52 Flow graph notation...................................................................58 Control Structure Testing..........................................................................................62 Testing for Specialized environments..................................................................67 Top-down Integration...............................................................64 Unit Testing...........................................69 Validation test criteria...........................................................................52 Basis Path Testing.........................................................................................66 Integration Testing......................69 6................................................................................................................................68 Regression testing............................................................ Debugging........................................................................2 Software Testing Strategies................................................................................................................................59 Loop testing............................................................................................................................................................................................................................71 Backtracking approach.....................................71 Brute force approach.............................................................................................................................59 Black-Box Testing.....................................53 Cyclomatic complexity....64 A software testing strategy..............................................................................................................................................................................................................................................................................................................................................................56 Graph matrices...........................................................................................................................................................................62 5.................................................................................................................65 Unit test considerations.........................................................................................................................................................................................61 Equivalence Partitioning....................................................................................................................................................................................................................................................................................................................................................................................................................69 System Testing....70 Debugging Approaches.........................................................................................................................................................................................................................................................................................68 Validation Testing................71 Cause elimination approach...................................................................................................................

Each of these items comprises a configuration that is created as part of the software engineering process. As a product. enabling the software engineer to create new applications from reusable parts. 2. or transmitting information that can be as simple as a single bit or as complex as a multimedia simulation. acquiring. rather than being assembled from existing components Software Components Reusability is an important characteristic of a high quality software component. managing. Most software is custom built. The intent of software engineering is to provide a framework for building software with higher quality. Software Software is: (1) instructions (computer programs) that when executed provide desired function and performance. software acts as the basis for the control of the computer (operating system). it is not manufactured in the classical sense. EMBEDDED SYSTEMS Page 5 of 72 . software has evolved from a specialized problemsolving and information analysis tool to an industry in itself. software takes on a dual role. and documents. Software is developed or engineered.1. software is an information transformer – producing. Software Characteristics 1. modifying. it delivers the computing potential represented by computer hardware. As the vehicle used to deliver the product. A software component should be designed and implemented so that can be used in many different programs. and the control of other programs. Software has become a limiting factor in the evolution of computer-based systems. 3. information. Whether it resides within a cellular phone or operates inside a mainframe computer. Software delivers most important product that is. (2) data structures that enable the programs to adequately manipulate information. Today. It is a product. and at the same time. data. the communication of information (networks). and (3) documents that describe the operation and use of the programs.1 Product Evolving role of software Software has become the key element in the evolution of computer-based system and products. Software is composed of programs. displaying. Over the past four decades. But early “programming culture and history have created a set of problems that persist today. Introduction to software Engineering and project planning 1. the vehicle for delivery of a product. Reusable components encapsulate both data and processing that is applied to the data. Software doesn’t wear out.

Software Applications The following software areas indicate the breadth of potential applications: System software Real-time software Business software Engineering and scientific software Embedded software Personal computer software Artificial intelligence software EMBEDDED SYSTEMS Page 6 of 72 .

This system view is essential when software must interface with other elements such as hardware. sequential approach to software development that begins at system level and progresses through analysis. testing and maintenance. Software Process Models To solve actual problems in an industry setting. software configuration management. work begins by establishing requirements for all system elements and then allocating some subset of these requirements to software. The foundation for software engineering is the process layer. that is. Software engineering methods provide the technical “how to’s” for building software. Software requirement analysis The requirements gathering process is intensified and focused specifically on software. Process defines a framework for a set of key process areas that must be established for effective delivery of software engineering technology. project milestones. disciplined. and quality assurance points-enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team. design. Process. and measurement – overlay the process model. Software Process A common process framework is established by defining a small number of framework activities that are applicable to all software projects. people. To understand the nature of the program(s) to be built. Methods and Tools Software engineering is a layered technology. Software engineering tools provide automated or semi-automated support for the process and the methods. software work products and deliverables. Linear sequential model encompasses the following activities: System/information engineering and modeling Since software is always part of a larger system. a software engineer or a team of engineers must incorporate development strategy that encompasses the process. referred as process model. regardless of their size or complexity.1. coding. Linear Sequential Model The linear sequential model for software engineering is called the “classic life cycle” or the “waterfall model”. quantifiable approach to the development. This model suggests a systematic. and databases. Finally software quality assurance. (2) the study of approaches as in (1). the application of engineering to software.2 Process Software Engineering: (1) The application of a systematic. as well as EMBEDDED SYSTEMS Page 7 of 72 . methods and tools layers and the generic phases. It must rest on an organizational commitment to quality. operation and maintenance of software. A number of task sets – each a collection of software engineering work tasks. the software engineer called analyst in this role must understand the information domain for the software.

The design process translates requirements into a representation of the software that can be assessed for quality before code generation begins. behavior. that is. The linear sequential model System/information engineering analysis design code test The Prototyping Model This model is good to use when the customer has legitimate needs. the design is documented and becomes part of the software configuration. but is not able to articulate the details at the start of the project. interface representations. Maintenance Software is prone to changes after delivery to the customer. program testing begins. Design Software design is actually a multistep process that focuses on four distinct attributes of a program: data structure. conducting tests to uncover errors and ensure that defined input will produce actual results that agree with required results. accommodating changes in the external environment. performance. Software maintenance reapplies each of the preceding phases to an existing program rather than a new one. Testing Once code has been generated. or performance enhancements. assuring that all statements have been tested.required function. Like requirements. The testing process focuses on the logical internals of the software. software architecture. The code generation step performs this task. and interfacing. and on the functional externals. and procedural detail. A small mock-up of a working system is EMBEDDED SYSTEMS Page 8 of 72 . Changes may be due to errors. Requirements for both the system and the software are documented and reviewed with the customer. Code generation The design must be translated into a machine-readable form.

developed and presented to the customer.90 days Evolutionary Models The two most important models are the incremental model and the spiral model. Developers are often able to use component-based construction techniques to build a fully functional system in a short time period. listen to customer build/revise mock -up customer test -drives mock -up The RAD Model The rapid application deployment model is a high-speed adaptation of the linear sequential model. team #2 team #1 business modeling busine ss modelin g team #3 bu siness mod elin g d ata mo delin g pro cess m odel ing data modeling ap plication gener at ion testin g & t urn over data modeling pr oces s modeling applicat ion gene ration process modeling testing & tur nover application generation testing & turnover 60 . Sometimes this first system is discarded and sometimes it is extended based on the customer's feedback. Project requirements must be well understood and the project scope tightly constrained. The incremental model combines elements of the linear sequential model applied repetitively EMBEDDED SYSTEMS Page 9 of 72 .

benchmarks S/W requirements Product design Development plan Integration and test plan Plan next phase Code Unit test Integr ation test Acceptance test Develop. verify Service next-level product Design V&V Requirement validation Detailed design EMBEDDED SYSTEMS Page 10 of 72 . An essential component of the spiral model is that assessment of both management and technical risks is performed as each incremental release is completed. Each increment produces a working version of a software product with increasing functionality. models.with the iterative philosophy of the prototyping model. S seminfo mtio yt / r a n e gne ring ni e increment 1 co e d te t s a ay is nl s de ig sn Delivery of 1 increment st increment 2 an lysis a de i n sg c de o te t s Delivery of 2nd increment increment 3 a ayss nl i d sg ei n cd oe te t s Delivery of 3rd increment increment 4 a ay is nl s de i n sg c de o te t s delivery of 4th increment calendar time Determine objectives alternatives and constraints Risk analysis Risk analysis Risk analysis Evaluate alternatives identify. resolve risks REVIEW Requirements plan Life-cycle plan Risk a n ayl s i sPrototype 1 Concept of Operation Prototype 3 Prototype 2 Operational protoype Simulations. There is no throwaway code. The spiral model also combines the iterative nature of prototyping with the systematic control found in the linear sequential model.

Hierarchically organized teams can develop routine software applications without much communication among the team members. problem. it needs to be populated with the minimum set of work tasks and work products. but not the common process framework. Effective managers focus on problem solving and insist on high product quality. Avoid process overkill. Doing things right the first time and avoiding the temptation to cut corners to try to shorten the development cycle can avoid most failures. It is helpful to remind ourselves that unless developers and customers agree on the scope of the project there is no way to determine when it ends (or when they will get paid). It is important that framework activities are applied on every project. The Problem The first project management activity is the determination of software scope. and quality assurance checkpoints regardless of the project size.3 Project Management Project management focuses on four P's: people. This is essential to ensure the product developed is the product requested by the customer.1. To be effective the project team must be organized in a way that maximizes each person's skills and abilities. To avoid project failure. Skipping process steps often has the effect of lengthening the development time since the amount of work EMBEDDED SYSTEMS Page 11 of 72 . Process decomposition can occur simultaneously with product decomposition as the project plan evolves. process. The emphasize is that each the P's is important and it is the synergy of all four working together that yields the successful management of software products. and project. a problem must be decomposed along functional lines into smaller. developers need to react to warning signs and focus their attention on practices that are associated with good project management. Process framework activities are populated with tasks. The Process Once a process model is chosen. the greater the effort required to ensure effective communication and coordination of team member efforts. Teams having a more democratic style organization often develop novel applications more efficiently. Work tasks may vary. milestones. People Companies that manage their people wisely prosper in the long run. Regardless of the process model followed. work products. more easily managed sub problems. The Project Software engineers need to be on the watch for failing signals and take corrective action before failure occurs. Two keys factors in selecting a team organizational model are desired level of communication among its members and difficulty level of the problems to be solved. This also the time to remind that it is customer for whom the product is being developed. Software teams may be organized in many different ways. It is important to understand that the larger the team. no matter how small.

Metrics. An indicator is a metric or combination of metrics that provide insight into the software project. Function points were originally developed for information systems applications. usability) continue to define software quality today. Function points are a method of indirectly measuring functionality using other direct measures. A measure is established when a single data point is collected. Metrics for Software Quality Here we think about the role of measurement to assess product quality and process effectiveness during project development. Defect removal efficiency is an important software quality metric that can useful at both the process and project levels. or product.4 Software Process and Project Metrics Measures.usually increases. process. Product Customer Characteristics Business Conditions Process Technology Development Environment People EMBEDDED SYSTEMS Page 12 of 72 . and indicators are distinct (though related) entities. and Indicators The important point to get across is that measures. Function points can be used to normalize software. Software Measurement Size-oriented metrics are derived by normalizing quality or productivity measures over the product size (typically LOC or KLOC). integrity. Function point values (FP) are easier to compute (prior to implementation) than LOC for the projects. A software metric relates individual measures in a meaningful way. maintainability. metrics. It should also be noted that the factors that defined software quality in the 1970's (correctness. 1. Taking time to reflect on how things went once a project is over is a good habit to develop.

as the actual project costs and schedule become known as the project unfolds. EMBEDDED SYSTEMS Page 13 of 72 . some cannot. and reliability. interfaces. constraints. Function and performance allocated to software during system engineering should be assessed to establish a project scope that is un-ambiguous and understandable at management and technical levels. The planning objective is achieved through a process of information discovery that leads to reasonable estimates.5 Software Project Planning Project Planning Objectives The objective of software project planning is providing a framework that allows managers to make reasonable estimates of the resources. It is important that the more information an estimator has. Examining the project plan and the software statement of scope identifies product-specific risks. Constraints identify limits placed on the software by external hardware. cost and time required to build a software product. Software Scope The first activity in software project planning is the determination of the software scope. This is an important reason to update all estimates. Generic risks can be listed on a checklist to examine for every software product. Functions described in the statement of scope are evaluated and in some cases refined to provide more detail prior to the beginning of estimation. 1. Risk Identification Differences between identifying generic risks and product-specific risks.6 Risk Management Software Risks Risks involve areas of uncertainty in the software development process that have the potential to result in nontrivial losses to the project. available memory or other existing systems. some degree of decomposition is often useful. Software risks go beyond technical concerns and also include the economic uncertainties that come with marketing a piece of software. The fact remains that even if it is impossible to manage all risks any planning is better than no planning.1. Most software risks can be identified prior to beginning a project. performance. Software scope describes function. Because both cost and schedule estimates are functionally oriented. Performance considerations encompass processing and response time requirements. Risk Projection Risk projection (estimation) attempts to associate with each risk the likelihood (probability) of its occurrence and the consequences of the resulting problems if the risk should occur. the better his or her estimates will be.

The goal of the analyst is recognition of the basic problem elements as perceived by the customer/user. evaluate the flow and EMBEDDED SYSTEMS Page 14 of 72 . indicate software’s interface with other system elements and establish constraints that software must meet. Next. functional and behavioral domains that will be created by software.2. Analysis and Requirement Specification 2. Requirement analysis enables the system engineer to specify software functions and performance. Problem evaluation and solution synthesis is the next major area of effort for analysis. communication for analysis must be established so that problem recognition is ensured.1 Analysis Concepts and Principles Requirement Analysis Requirement analysis is a software engineering task that bridges the gap between system level software allocation and software design. Requirements analysis provides the software engineer (called analyst in this role) with models Software requirements analysis may be divided into five areas of effort: (1) problem recognition (2) evaluation and synthesis (3) modeling (4) specification and (5) review. System Engineering Software Requirements Analysis Software Design Requirements analysis allows the software engineer to refine the software allocation and build models of the data. It is important to understand software in a system context and to review the software scope that was used to generate planning estimates. The analyst must define all externally observable data objects. architectural interface and procedural design. Initially. the analyst studies the system specification and the software project plan. that can be translated into data.

both are worried that what they do say will be misinterpreted. both are thinking about where it might lead. both want to get the thing over with. the analyst might ask: • Who is behind the request for this work? • Who will use the solution? • Is there another source for the solution that you need? The next set of questions enables the analyst to gain a better understanding of the problem and the customer to voice his or her perceptions about a solution: • How would you characterize “good” output that would be generated by a successful solution? • What problem(s) will this solution address? • Can you show me (or describe) the environment in which the solution will be used? • Are there special performance issues or constraints that will affect the way the solution is approached? EMBEDDED SYSTEMS Page 15 of 72 . Throughout evaluation and solution synthesis. what functions must the system perform. a set of questions that will lead to a basic understanding of the problem. functional processing and behavioral operation. and information content.content of information. both want it to be a success. define and elaborate all software functions. Communication Techniques Software requirements analysis always begins with communication between two or more parties. For example. A developer responds to the customer’s request for help. establish system interface characteristics. A customer has problem that may be amenable to a computer-based solution. The analyst should start by asking context free questions. the nature of the solution that is desired.” not “how. what interfaces are defined and what constraints apply? During the evaluation and solution synthesis activity. the analyst creates models of the system in an effort to better understand data and control flow.” What data does the system produce and consume. Neither person knows what to say or ask. The steps in analysis process are: (1) Initiating the process (2) Facilitated Application specification techniques (3) quality function deployment Initiating the process The most commonly used analysis technique to bridge the communication gap between the customer and developer and to get the communication process started is to conduct a preliminary meeting or interview. These tasks serve to describe the problem so that overall approach or solution may be synthesized. The model serves as a foundation for software design and as the basis for the creation of a specification for the software. but at the same time. understand software behavior in the context of events that affect the system. the people who want a solution. and uncover additional design constraints. The first set of context free questions focus on the customer. and the effectiveness of the first encounter itself. and benefits. the analyst’s focus should be on “what. overall goals. That is.

EMBEDDED SYSTEMS Page 16 of 72 . Basic guidelines are as follows: • A meeting is conducted at a neutral site and attended by both developers and customers. negotiate different approaches. a developer or an outsider) controls the meeting. QFD identifies three types of requirements: Normal requirements. • A “facilitator”(who can be a customer. Objectives and goals are stated for a product or system during meetings with the customer. These are called meta-questions and propose the following list: • • • • • Are you the right person to answer these questions? Are your answers “official”? Are my questions relevant to the problem that you have? Am I asking too many questions? Is there anyone else who can provide additional information? Is there anything else that I should be asking you? These questions will help to “ break the ice” and initiate the communication that is essential to successful analysis. who work together to identify the problem. the customer is satisfied. propose elements of the solution. • The goal is to identify the problems. and specify a preliminary set of solution requirements. If these requirements are present. or a wall board) is used. propose elements of the solution. To accomplish this. • An agenda is suggested that is formal enough to cover all-important points but informal enough to encourage the free flow of ideas. Quality function deployment (QFD) Quality function deployment is a quality management technique that translates the needs of the customer into technical requirements for the software. It concentrates on maximizing the customer satisfaction. and specify a preliminary set of solution requirements in an atmosphere that is conducive to the accomplishment of the goal. Today FAST is predominantly used. QFD emphasizes understanding of what is valuable to the customer and then deploying these values throughout the engineering process. Facilitated Application specification techniques (FAST) This approach encourages the creation of a joint team of customers and developers. • A “definition mechanism”(which can be work sheets. negotiate different approaches.The final set of questions focus on the effectiveness of the meeting. flip charts. • Rules for preparation and participation are established.

manipulate it in some way. Information structure. An event represents some aspect of system control and is really nothing more than Boolean data-it is either off or on. true or false. (4) The models that depict information. It is also important software also processes events. Information content and relationships. • Record the origin of and the reason for every requirement. that is. (3) The behavior of the software (as a consequence of external events) must be represented. 3. • Work to eliminate ambiguity. a set of guiding principles for requirements engineering has been proposed as follows: • Understand the problem before you begin to create the analysis model. • Develop prototypes that enable a user to understand how human-machine interaction will occur. (5) The analysis process should move from essential information toward implementation detail. Software is built to process data. function and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) function. • Prioritize requirements. to accept input.Expected requirements. The Information Domain All software applications can be collectively called data processing. These features go beyond the customer’s expectations and prove to be very satisfying when present Analysis Principles Analysis should be based on a set of operational principles: (1) The information domain of a problem must be represented and understood. (2) The functions that the software is to perform must be defined. The first operational analysis principle requires an examination of the information domain. Their absence will be cause for significant dissatisfaction. The information domain contains three different views of the data and control as a computer program processes each: 1. • Use multiple views of requirements. These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. transform data from one form to another. EMBEDDED SYSTEMS Page 17 of 72 . In addition to the operational principles. 2. Information flow. Exciting requirements. and produce output. This is true whether we build software for payroll system or real-time embedded software to control fuel flow in an automobile.

and output to transform information. Functional models: Software should perform three generic functions. Input object Transfo rm #1 Intermediate data and Control Transfo rm #2 output object Data/control store Information structure represents the internal organization of various data and control items. When the entity to be built is software. we create models of the system to be built. The second and third analysis principles require that we build models of function and behavior. Thee functional model EMBEDDED SYSTEMS Page 18 of 72 . The models focus on what the system must do. it must be capable of modeling the information that software transforms. and the behavior of the system as the transformation is taking place. Functional models are problem-specific. Information flow represents the manner in which data and control change as each moves through a system. processing. not on how it does it. input. Data and control objects can be related to other data and control objects. Modeling Models are created to gain better understanding of the actual entity to be built.Information content represents the individual data and control objects that comprise some larger collection of information that is transformed by the software. the functions (and sub functions) that enable the transformation to occur. During software requirements analysis.

• The model becomes the foundation for the design. Models created during requirements analysis serve a number of important roles: • The model aids the analyst in understanding the information. A computer program always exists in some state – an externally observable mode of behavior that is changed only when some event occurs. until thorough delineation of all system functionality is represented. function. A number of specification principles proposed are: (1) Separate functionality from implementation (2) Develop a model of the desired behavior of a system that encompasses data and the functional responses of a system to various stimuli from the environment. Regardless of the mode it should be viewed as a representation process and requirements should be represented in a manner that leads to successful software implementation. In many cases. Over a series of iterations. more and more functional detail is provided. providing the designer with an essential representation of software that can be translated into an implementation context.begins with a single context level model (i. The modeling activity is fundamental to good analysis work. there by making the requirements analysis task easier and more systematic. EMBEDDED SYSTEMS Page 19 of 72 . Behavioral models: Most software responds to events from the outside world. (3) Establish the context in which the system operates by specifying the manner in which other system components interact with software. the name of the software to be built). and accuracy of the specification. and behavior of a system. consistency. (4) Define the environment in which the system operates and indicate how “a highly intertwined collection of agents react to stimuli in the environment produced by these agents. The stimulus-response characteristic forms the basis of the behavioral model. is constructed for customer and developer assessment. called a prototype. (5) Create a cognitive model rather than a design or implementation model.e. possibly coupled with systematic analysis methods. A behavioral model creates a representation of the states of the software and events that cause software to change state. • The model becomes the focal point for review and therefore the key to a determination of completeness. In some situations a model of the software to be built. Software Prototyping Analysis should be conducted regardless of the software engineering paradigm that is applied. Specification The mode of specification has much to do with the quality of solution. is an effective approach to software engineering. (6) Recognize that “the specification must be tolerant of completeness and augmentable”. the construction of a prototype.

a detailed functional and behavioral description. and other data pertinent to requirements refines the function and performance allocated to software as part of the system engineering. Establishing a complete information description. The software Requirements Specification The software Requirements Specification is produced after the completion of the analysis task.2 Analysis Modeling A model is a symbolic or abstract representation of something real or imagined.(7) Establish the content and structure of a specification in a way that will enable it to be amenable to change. The analysis model must achieve three primary objectives: (1) to describe what the customer requires (2) To establish a basis for the creation of a software design and (3) to define a set of requirements that can be validated once the software is built. To accomplish these objectives. 2. an indication of performance requirements and design constraints. the analysis model derived during analysis takes the following form: EMBEDDED SYSTEMS Page 20 of 72 .

We can EMBEDDED SYSTEMS Page 21 of 72 . reliable. The entity-relationship diagram (ERD) depicts relationships between data objects. and only secondarily on process analysis. The STD serves as the basis for behavioral modeling. adaptable. and economic. the STD represents the various modes of behavior (called states) of the system and the manner in which transitions are made from state to state. The state-transition diagram (STD) indicates how the system behaves as a consequence of external events. To accomplish this. Data Modeling For an information system to be useful.The structure of the analysis model Entity Relationship Diagram Data Flow Diagram Data Dictionary State -Transition Diagram (CSPEC) At the core of the model lies the data dictionary – a repository that contains descriptions of all data objects consumed or produced by the software. The ERD is the notation that is used to conduct the data modeling activity. A description of each function presented in the DFD is contained in a process specification (PSPEC). The data flow diagram (DFD) serves two purposes: (1) to provide an indication of how data are transferred as they move through the system and (2) to depict the functions that transform the data flow. The DFD provides additional information that is used during the analysis of the information domain and serves as a basis for the modeling of function. it must be based first on sound data modelling. The attributes of each data object noted in the ERD can be described using a data object description. Additional information about control aspects of the software is contained in the control specification (CSPEC).

a role (salesperson). The relationship always defined by context of the problem that is being analyzed. Relationships indicate connectedness. whereas process is about technique. device. a fact that must be remembered by the system. the relationships between these entities and the entity attributes. Entity-relationship diagram (ERD) sets out the entities in the system. They can be used to name an instance of the data object. Data models are used to describe the logical structure of data processed by the system. Composite information means something that has a number of different properties or attributes. or a structure (a file). Data objects are related to one another. Cardinality is usually expressed as simply ‘one’ or many.  It is important to recognize that any entity (person. Data objects are connected to one another in many different ways. Let us consider the relationship between data objects book and bookstore. or software product) that produces or consumes data needs to appear in the data model. a thing (report or a display). A data object is a representation of almost any composite information that must be understood by software.make this categorical statement because the structure of data is inherently about truth. a place(house). Cardinality is the specification of the number of occurrence of one object that can be related to the number of occurrence of another object. For example “width” is not a valid data object because it is a single value. an occurrence (telephone call) or event (alarm). Orders Displays Book Sells It is important to note that object-relationship pairs are bi-directional that they can be read in either direction. and the relationships that connect data objects to one another. Two objects can be related as: Bookstore EMBEDDED SYSTEMS Page 22 of 72 . describe the instance. Attributes define the properties of a data object and take on one of three different characteristics. The data model consists of three interrelated pieces of information: the data object. the attributes that describe the data object. an organizational unit(department). where as “dimension” could be defined as an object because it incorporates height. width. A data object can be an external entity (any thing that produces or consumes information). It is not computed or derived mechanically. and depth. or make reference to another instance.

One-to one (1:1) - An occurrence of object ‘A’ can relate to one and only one occurrence of object ‘B’ and an occurrence of ‘B’ can relate to only one occurrence of ‘A’. • One-to-many (1:N) – One occurrence of object ‘A’ can relate to one or many occurrence of object ‘B’, but an occurrence of ‘B’ can relate to only one occurrence of ‘A’. • Many-to-many (M:N) – An occurrence of object ‘A’ can relate to one or more occurrences of object ’B’ while an occurrence of ‘B’ can relate to one or more occurrences of object ‘A’. Modality of a relationship provides an indication of whether or not a particular data object must participate in the relationship. The modality of a relationship is zero if there is no explicit need for the relationship to occur or the relationship is optional. The modality of a relationship is 1 if an occurrence of the relationship mandatory.

Entity-Relationship Diagrams
The object-relationship pairs can be represented graphically using the entity-relationship diagram (ERD). Data objects are represented by a labeled rectangle. Relationships are indicated with a labeled line connecting objects or in some cases connecting line contains a diamond that is labeled with the relationship.

Manufacturer

Builds

Car

Creating an Entity-Relationship Diagram The entity-relationship diagram enables a software engineer to fully specify the data objects that are input and output from a system, the attributes that define the properties of these objects, and the relationships between objects. Like most elements of the analysis model, the ERD is constructed in an iterative manner. The following approach is taken: 1. During requirements gathering, customers are asked to list the “things” that the application or business process addresses. These “things” evolve into a list of input and output data objects as well as external entities that produce or consume information. 2. Taking the objects one at a time, the analyst and customer define whether or not a connection (unnamed at this stage) exists between the data object and other objects. 3. Where a connection exists, the analyst and customer create one or more objectrelationship pairs.
EMBEDDED SYSTEMS Page 23 of 72

4. For each object-relationship pair, cardinality and modality are explored. 5. Steps 2 through 4 are continued iteratively until all object-relationship pairs have been defined. 6. The attributes of each entity are defined. 7. An entity-relationship diagram is formalized and reviewed. 8. Steps 1 through 7 are repeated until data modeling is complete.

Functional Modeling
Information is transformed as it flows through a computer-based system. The system accepts input in a variety of forms, applies hardware, software, and human elements to transform input into output and produces output in a variety of forms. Input may be, a control signal transmitted by a transducer, a series of numbers typed by a human operator, or a packet of information transmitted over a network link. The transform may comprise a logical comparison, a numerical algorithm or an rule-inference system for an expert system. Output may produce a report or light an LED. We can create flow models for any computer-based system regardless of size and complexity. Overall function of the system is represented as single information transform i.e. a single bubble. base

height

compute triangle area

area

Data Flow Diagrams
A data flow diagram (DFD) is a graphical technique that depicts information flow and the transforms that are applied as data move from input to output. DFD’s may be used to represent a system or software at any level of abstraction. Also DFD’s may be partitioned into levels that represent increasing information flow and functional detail. Therefore, the DFD provides a mechanism for functional modeling as well as information flow modeling. A level 0 DFD, also called a fundamental system model or a context model, represents the entire software element as a single bubble with input and output data indicated by incoming and outgoing arrows. Additional processes and information flow paths are represented as the level 0 DFD is partitioned to reveal more detail. The basic notation used to create a DFD is illustrated here:
EMBEDDED SYSTEMS Page 24 of 72

external entity

process

data flow

data store

An external entity is a producer or consumer of information that resides outside the bounds of the system to be modeled (hardware, a person, another program), a process is a transformer of information (a function) that resides within the bounds of the system to be modeled, a data object, the arrowhead indicates the direction of flow, and a data store is a repository of data that is to be stored for use by one or more processes (may be as simple as a buffer or as sophisticated as a relational database). The graphical notations represented above must be augmented with descriptive text. A processing specification (PSPEC) can be used to specify the processing details implied by a bubble within a DFD. The PSPEC describes the input to a function, the algorithm that is applied to the input and the output that is produced. In addition the PSPEC indicates restrictions and limitations imposed on the process, and design constraints that may influence the way in which the process will be implemented. Creating a Data Flow Model The DFD enables the software engineer to develop models of the information domain and functional domain at the same time. As the DFD is refined into greater levels of detail, the corresponding data is refined as it moves through the processes that represent the application. A few guidelines, which can aid us in building DFD, are: 1. The level 0 DFD should depict the software/system as a single bubble.
EMBEDDED SYSTEMS Page 25 of 72

State-transition diagram Represents the behavior of a system by depicting its states. Refinement should begin by isolating candidate processes. One bubble at a time should be refined. • An action is a process that occurs as a consequence of making a transition. • State transition is the movement of the system from one state to another. rigorous definitions so that both user and system analyst will have a common understanding of inputs. All arrows and bubbles should be labeled with meaningful names. 6. Behavioral Modeling The behavioral model of a system depicts its states and the events that cause the system to change state. data objects. EMBEDDED SYSTEMS Page 26 of 72 . components of stores and intermediate calculations. 3.2. state event causing transition action that occurs new state Data Dictionary The data dictionary has been proposed as a quasi-formal grammar for describing the content of objects defined during structured analysis. • An event is an occurrence that causes the system to exhibit some predictable form of behavior. Primary input and output should be carefully noted. and stores to be represented at the next level. events and corresponding actions. outputs. • A state is any observable mode of behavior. The data dictionary is an organized listing of all data elements that are pertinent to the system. Information flow continuity must be maintained from level to level. with precise. 4. 5.

function. to systems that interoperate with it. an interface design. Each of the elements of the analysis model provides information that is required to create a design model. and a procedural design. feed the design steps.3. Once software requirements have been analyzed and specified. and behavioral methods.1 Design Concepts and Principles Software Design Software design sits at the technical kernel of the software engineering process and is applied regardless of the software process model that is used. The interface design describes how the software communicates within itself. Software requirements manifested by the data. code generation and testing – that are required to build and verify the software. An interface implies a flow of EMBEDDED SYSTEMS Page 27 of 72 . an architectural design. software design is the first of three technical activities – design. Data Object Description EntityRelationship Diagram Process Specification (PSPEC) Data Flow Diagram procedural design Data Dictionary interface design architectural design data design State-Transition Diagram Control Specification (CSPEC) THE ANALYSIS MODEL THE DESIGN MODEL The data design transforms the information domain model created during analysis into the data structures that will be required to implement the software. Design 3. The architectural design defines the relationship among major structured elements of the program. The data objects and relationships defined in the entity-relationship diagram and the detailed data content depicted in the data dictionary provide the basis for the data design. and with humans who use it. Using one of a number of design.

data and/or control). These can still be traced to requirements. A program should be designed to accommodate unusual circumstances. That is. • The design should be structured to degrade gently. and if it must terminate processing. as it exists in the real world. and behavioral requirements. The following basic design principles enable the software engineer to navigate the design process: • The design process should not suffer from “tunnel vision”. a sense of what makes “good” software. that the design process is not simply a cookbook. That is design structure should be same as the problem structure. subsequent refinement leads to design representations at much lower levels of abstraction. Good designer should consider alternative approaches based on requirements of the problem. events. A design is uniform if it appears that one person developed the entire thing. • The design should minimize the “intellectual distance” between the software and the problem. Creative skill. • Design is not coding. • The design should be traceable to the analysis model. Therefore. coding is not design. but the connection is subtler. the level of abstraction • Of the design model is higher than source code. past experience. It is important to note.g. Even when detailed procedural designs are created for program components. and an overall commitment to quality are critical success factors for a competent design. however. EMBEDDED SYSTEMS Page 28 of 72 . or operating conditions are encountered. The design process is a set of iterative steps that enable the designer to describe all aspects of software to be built. even when aberrant data. • The design should exhibit uniformity and integration. it is necessary to have a means for tracking how the design model has satisfied requirements. the blueprint depicts a holistic view of software. the design is represented at a high level of abstraction .information (e. the data and control flow diagrams provide the information required for interface design.a level that can be directly traced to specific data. The procedural design transforms structural elements of the program architecture into a procedural description of software components. • The design should not reinvent the wheel. As design iterations occur. Reusable design components should always be chosen as an alternative to reinvention. Since a single element of the design model often relate to multiple requirements. functional. Design principles Software design is both a process and a model. do so in a graceful manner. Since time is short and resources are limited design time should be invested in representing truly new ideas. Initially. Design Process Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the software.

etc Data abstraction is a named collection of data that describes a data object. A reader cannot easily grasp monolithic software. and dimensions. E. Synchronization semaphore used to coordinate activities in an operating system.Design Concepts Many significant design concepts have evolved over a period of time. opening mechanism. weight. Like any data object. refinement. Refinement helps the designer to reveal low-level details as design progresses. providing more and more detail as each successive refinement occurs. modularity. we can classify them into procedural.g. EMBEDDED SYSTEMS Page 29 of 72 . Modularity allows software to be manageable. the data abstraction for door would consists of a set of attributes that describe the door. As we move through different levels of abstraction.g. Both concepts aid the designer in creating a complete design model as the design evolves. Modularity Software is divided into separately named and addressable components. called modules that are integrated to satisfy problem requirements. In the procedural abstraction “open” we can define a data abstraction called door. data and control abstractions respectively. It causes the designer to elaborate on the original statement. Each concept provides the software designer with a foundation from which more sophisticated design methods can be applied. software architecture. Abstraction. Word “open” on a door. E. It is obvious that the procedural abstraction open would use of information contained in the attributes of the data abstraction door. Procedural abstraction is a named sequence of instructions that has a specific and limited function. Refinement Refinement is a process of elaboration. “Open” implies a long sequence of procedural steps like walk to the door. turn knob and pull door. and information hiding are the concepts we will be discussing. E. Control abstraction implies a program control mechanism without specifying internal details. Abstraction enables a designer to specify procedure and data and yet suppress low-level details. door type. Abstraction and refinement are complimentary concepts. reach out and grasp knob. Use of abstraction permits one to work with concepts and terms that are familiar in the problem environment without having to transform them to an unfamiliar structure.g. Abstraction The notion of abstraction permits one to concentrate on a problem at some level of generalization without regard to irrelevant low-level details. swing direction. Each step in the software engineering process is a refinement in the level of abstraction of the software solution.

other forces come into play.. effort associated with integrating the modules increases. it is easier to solve a complex problem when it is broken down into manageable pieces. filters) and the manner in which those components are packaged and interact with one another.g. This rendering serves as a framework from which more detailed design activities are conducted. Hence.This leads to a divide-and-conquer strategy. This aspect of the architectural design representation defines the components of a system (e. objects. the manner in which these components interact. In its simplest form. modules. One goal of software design is to derive an architectural rendering of a system. Unfortunately. If we subdivide software indefinitely. module development cost cost of software module integration cost optimal number of modules number of modules Software architecture It refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. EMBEDDED SYSTEMS Page 30 of 72 . we should modularize but optimally. For example. and the structure of the data that are used by the components. objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods. architecture is the hierarchical structure of program components (modules). The set of properties that should be specified as part of an architectural design: Structural properties. the effort required to develop it will become negligibly small.

are used to coordinate communication between and execution of program functions. Top-level modules should perform control functions and do little processing work. security. represented in a lighter shade.Extra-functional properties. Families of related systems. reliability. performing all input. The architectural design description should address how the design architecture achieves requirements for performance. Modules that reside low in the architecture should be workers. and other system characteristics. In essence. Horizontal partitioning defines separate branches of the modular hierarchy for each major program function. adaptability. function 1 function 3 function 2 Control modules. Vertical partitioning often called factoring. decision-makers EMBEDDED SYSTEMS Page 31 of 72 . The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. suggests that control and work should be distributed top-down in the program architecture. Structural Partitioning The program structure should be partitioned both horizontally and vertically. capacity. computational. the design should have the ability to reuse architectural building blocks. and output tasks.

inadvertent errors introduced during modification are less likely to propagate to other locations within the software. during software maintenance. EMBEDDED SYSTEMS Page 32 of 72 . Hiding defines and enforces access constraints to both procedural detail within a module and any local data structure used by the module. Because most data and procedure are hidden from other parts of the software.workers Information Hiding Modules should be specified and designed so that information (procedure and data) contained within a module is inaccessible to other modules that have no need for such information. The use of information hiding as a design criterion for modular systems provides its greatest benefits when modifications are required during testing and later.

Data Design The primary activity during data design is to select logical representations of data objects (data structures) identified during the requirements definition and specification phase. Architectural Design The primary objective of architectural design is to develop a modular program structure and represent the control relationships between modules. (3) The DFD is mapped into program structure. well-designed data can lead to better program structure and modularity. (4) Low-level data design decisions should be deferred until late in the design process. (3) A data dictionary should be established and used to define both data and program design.3. (5) The representation of data structures should be known only to those modules that must make direct use of the data contained within the structure. The selection process may involve algorithmic analysis of alternative structures in order to determine the most efficient design or may simply involve the use of a set of modules (package) that provide the desired operations upon some representation of an object. (2) Flow boundaries are indicated. (5) The resultant structure is refined using design measures and heuristics. The transition from information flow (represented as data flow diagram) to structure is accomplished as part of a five-step process: (1) The type of information flow is established. interface characteristics and procedural detail are synthesized from information requirements. (6) A library of useful data structures and the operations that may be applied to them should be developed. and reduced procedural complexity.2 Design Methods Design has been described as a multistep process in which representations of data structure. Consider the following set of principles: (1) The systematic analysis principles applied to function and behavior should also be applied to data. (7) A software design and programming language should support the specification and realization of abstract data types. (2) All data structures and the operations to be performed on each should be identified. (4) Control hierarchy is defined by factoring. Regardless of the design techniques to be used. EMBEDDED SYSTEMS Page 33 of 72 . program structure. Data flow-oriented design is an architectural design method that allows a convenient transition from the analysis model to a design description of program structure.

that triggers other data flow along one of many paths.The information flow type is the driver for the mapping approach required in step 3. it is possible to characterize all data flow in this category. called transaction. When a segment of a data flow diagram exhibits these characteristics. When a DFD takes this form. etc) into an internal form and will be identified as incoming flow. Data moving along these paths are called out going flow. However. Incoming data are passed through a transform center and begin to move along paths that now lead “out” of the software. “straight line” paths. transaction flow is present. pictures on a computer graphics display. There are two flow types: Transform Flow In level 0 data flow diagram (fundamental system model) information enters the system along paths that transform external data (data typed on a keyboard. transform flow is present. or only a few. a transition occurs. The overall flow of data occurs in a sequential manner and follows one. information flow is often characterized by a single data item. At the kernel of the software. Transaction flow n EMBEDDED SYSTEMS Page 34 of 72 . Transform flow Transaction flow The fundamental system model implies transform flow. therefore.

Perform “second-level factoring” 7. Review the fundamental system model. and output work and middle-level modules perform some control and do moderate amounts of work). 3. computational. Perform “first-level factoring”. 2. Refine the first iteration program structure using design heuristics for improved software quality. and output along three separately factored module hierarchies The design steps are as follows: 1. (Factoring results in a program structure in which top-level modules perform decision-making and low-level modules perform most input. Isolate the transform center by specifying incoming and outgoing flow boundaries. Review and refine data flow diagrams for the software.Transform Mapping A set of design steps that allows a DFD with transform flow characteristics to be mapped into a predefined template for program structure. Determine whether the DFD has transform or transaction flow characteristics. processing. 6. Transform mapping is applied to an information flow that exhibits distinct boundaries between incoming and outgoing data. a b d c e f g i h j data flow model x1 x2 b a c d x3 e f g h x4 i j "Transform" mapping EMBEDDED SYSTEMS Page 35 of 72 . 4. The DFD is mapped into a structure that allocates control to input. 5.

6. a b t l m d g e i h j n f k data flow model x1 b a d x2 e f g Mapping x4 t x3 h i k EMBEDDED SYSTEMS Page 36 of 72 x3.1 j l m n . The design steps are as follows: 1. Factor and refine the transaction structure and the structure of each action path. Map the DFD in a program structure amenable to transaction processing. 3. 7. Review the fundamental system model. 5. Refine the first iteration program structure using design heuristics for improved software quality. Identify the transaction center and the flow characteristics along each of the action paths. 2. Review and refine data flow diagrams for the software. 4. The DFD is mapped into a structure that allocates control to a substructure that acquires and evaluates a transaction. Another substructure controls all potential processing actions based on a transaction.Transaction Mapping It is applied when a single information item causes flow to branch along one of many paths. Determine whether the DFD has transform or transaction flow characteristics.

The software engineer creates a design model. and procedural representations of the software. The design model of the entire system incorporates data. To build an effective user interface.e. including profiles of their age. The system perception is the image of the system that an end user carries in his\her head. Interface Design Models When a human-computer interface (HCI) is to be designed four different models come into picture. It is driven by the communication between human and machine. These are only a few of the many questions that must be asked and answered as part of user interface design. interface. The system image couples the outward manifestation of the computer-based system (the look. Task Analysis and Modeling It can be applied to understand the tasks that people currently perform. (3) The design of the interface between a human (i. a software engineer establishes a user model. education. External interface design begins with an evaluation of each external entity represented in the DFDs of the analysis model. and feel of the interface) with all supporting information (books.e. and the implementers of the system create a system image. architectural. The user model depicts the profile of end users of the system. the analysis model contains much of the information required for intermodular interface design. physical abilities.Interface Design Interface design focuses on three areas of concern: (1) The design of interfaces between software modules. is driven by the data that must flow between modules and the characteristics of the programming language in which the software is to be implemented. When the system image and the system perception are coincident. all design should begin with an understanding of the intended users. The data and control requirements of the external entity are determined and appropriate external interfaces are designed. (when using a manual or semi automated approach) and then map these into a similar (but not identical) EMBEDDED SYSTEMS Page 37 of 72 . who is the user. (2) The design of interfaces between the software and other non-human producers and consumers of information (i. other external entities). sometimes called intermodular interface design. the end user develops a mental image that is called system perception. users generally feel comfortable with the software and use it effectively. In general. User interface design begins with the creation of different models of system function as perceived from the outside. goals and personality. the user) and the computer. manuals. User interface design is concerned with the study of people as it does with technology issues like. The design of internal program interfaces. how does the user learn to interact with a new computerbased system. What will the user expect of the system. video tapes) that describes system syntax and semantics. sex.

EMBEDDED SYSTEMS Page 38 of 72 . It occurs after data. using natural language we can write procedural steps in too many ways. 6. 2. Indicate how the user interprets the state of the system from information provided through the interface. procedural design must be specify procedural detail unambiguously. This can be accomplished by observation or by studying an existing specification for a computer-based solution and deriving a set of user tasks that will accommodate the user model. condition provides the facility for selected processing based on some logical occurrence. and exited at the bottom. Define control mechanisms. condition. 7.set of tasks that are implemented in the context of the HCI. enabling a reader to follow procedural flow more easily. Map each goal/intention to a sequence of specific actions. Specify the action sequence.e. i. Show how control mechanisms affect the state of the system. as it will be executed at the interface level.e. and repetition. The structured constructs were proposed to limit the procedural design of software to a small number of predictable operations. and repetition provides for looping. architectural and interface design have been established the procedural specification required to define algorithmic details would be stated in a natural language such as English. The structured constructs are logical chunks that allow a reader to recognize procedural elements of a module rather than read the design or code line by line. was entered at the top. Also use of limited number of logical constructs contributes to a human understanding process called chunking. But there is a small problem. what does the interface look like at the time that an action in the sequence is performed? 5. the devices and actions available to the user to alter the system state. Once each task or action has been defined. Graphical Design Notation We know that pictures convey more than the words. 4. and maintainability. That is. Each construct has a predictable logical structure. testability. Structured Programming The three fundamental constructs of structured programming are sequence. i. the design model. Procedural Design The closest design activity to coding is procedural design. Establish the goals and intentions of the task. 3. Indicate the state of the system. and the system perception. Use of structured constructs reduce program complexity and thereby enhances readability. The first steps in the interface design process can be accomplished using the following approach: 1. and lack of ambiguity in a natural language is not natural. interface design begins. Sequence implements processing steps that are essential in the specification of any algorithm. Hence a more constrained mode for representing procedural detail must be used. Graphical tools like flowchart or box diagram provide excellent pictorial patterns that readily depict procedural detail.

A box is used to indicate a processing step. Flowchart constructs F First task T Next task Sequence Condition T F F T Repeat . and arrows show the flow of control.The flowchart is quite simple pictorially.until EMBEDDED SYSTEMS Page 39 of 72 Do-while . A diamond represents a logical condition.

Box diagram constructs First task Condition Condition Condition F F F T Else.part T T Then .part EMBEDDED SYSTEMS Page 40 of 72 .

The table is difficult to misinterpret and may even be used as a machine-readable input to a table driven algorithm.Next task Next task Next+1task Next+1 task If-then-else Sequence Loop condition Repeat-until part Do. The table is divided into four sections.while part Loop condition Repetition In case of box diagram. a condition box is followed by a then-part box and else-part box. To represent an if-then-else. The lower left hand quadrant contains a list of all actions that are possible EMBEDDED SYSTEMS Page 41 of 72 . Tabular Design Notation Decision tables provide a notation that translates actions and conditions (described in a processing narrative) into tabular form. Repetition is depicted with bounding pattern that encloses the process to be repeated. two boxes are connected bottom to top to represent sequence. The upper left hand quadrant contains a list of all conditions.

Because narrative text is embedded directly into a syntactical structure. Define rules by indicating what action or actions occur for a set of conditions. also called structured English or pseudocode. However. 4. The following steps are applied to develop a decision table: 1.e. 2. EMBEDDED SYSTEMS Page 42 of 72 .e. a structured programming language). alternatively. List all conditions (or decisions made) during execution of the procedure. eliminating impossible combinations of conditions. each column of the matrix may be interpreted as a processing rule. The right hand quadrant form a matrix that indicates condition combinations and the corresponding actions will occur for a specific combination. PDL looks something like any modern programming language at first glance. List all actions that can be associated with a specific procedure (or module). A PDL for a procedure average is depicted here. it narrative text is embedded directly within PDL statements. Rule numbers 1 2 3 4 5 6 Condition rows Action rows Rules Program Design Language Program Design Language (PDL). Therefore. 3. Associate specific sets of conditions with specific actions. is a language that uses the vocabulary of one language (i. English) and the overall syntax of another (i. develop every possible permutation of conditions. PDL cannot be compiled.based on combinations of conditions.

IF value [i] >= minimum and value [ i ] <= maximum THEN increment total.valid. maximum.valid by 1. Sum = sum + value [ i] ELSE skip ENDIF increment i by 1. total. minimum. TYPE i IS INTEGER.input <100 increment total. total.valid >0 THEN average = sum /total. total.PROCEDURE average. DO WHILE value [i] < > -999 and total. total.valid. sum = 0. sum IS SCALAR. *This procedure computes the average of 100 or fewer numbers that lie between bounding values.valid. it also computes the sum and the total number valid. TYPE value[1:100] IS SCALAR ARRAY.input by 1. INTERFACE RETURNS average. TYPE average. ENDDO IF total. INTERFACE RETURNS value.input = total. total. ELSE average = -999. minimum.input.input. maximum. ENDIF END average EMBEDDED SYSTEMS Page 43 of 72 . i=1.valid = 0.

that causes a redefinition of the system or product. In the context of software engineering. As the software process progresses. and that can be changed only through formal change control procedures”. confusion prevails. Because change can occur at any time. a base line is a milestone in the development of software that is marked by the delivery of one or more software configuration items and the approval of these SCI’s that is obtained through a formal technical review. or services delivered by a computer-based system. Data (contained within the program or external to it) The items that comprise all information produced as part of the software process are collectively called a software configuration. functionality delivered by products. Baselines A baseline is a software configuration management concept that helps us to control change without seriously impeding justifiable change. Computer programs (both source level and executable forms) 2. Report change. The four fundamental sources of change are • New business or market conditions that dictate changes in product requirements or business rules. Unfortunately another variable enters the process change. Software configuration management is a set of activities that have been developed to manage change throughout the lifecycle of computer software. Documents that describe the computer programs 3. for any reason and the desire to change persists throughout the life cycle. Software Configuration Management Software Configuration Management (SCM) is an umbrella activity that is applied throughout software process. Controlling modifications iv. If each SCI simply spawned other SCI’s. EMBEDDED SYSTEMS Page 44 of 72 . Change may occur at any time. These in turn spawn other documents to create a hierarchy of information. SCM activities are developed to i. The definition of a baseline is “A specification or product that has been formally reviewed and agreed upon. Identify change ii. A system specification spawns a software project plan and software requirements specification. Control Change iii. • New customer needs that demand modification of data produced by information systems. • Reorganization and /or business downsizing that cause changes in project priorities or software engineering team structure. • Budgetary or scheduling constraints. the number of software configuration items (SCI-information that is created as part of the software engineering process) grow rapidly. The output of a software process is information that may be divided into three broad categories 1. that thereafter serves as the basis for further development.4.

The progression of event that leads to a baseline is given below. System Specification Software Requirements Specification Design Specification Source Code Test Plans/Procedures/Data Operational System EMBEDDED SYSTEMS Page 45 of 72 .

configuration auditing and reporting.Software configuration items The following SCIs become the target for configuration management techniques and form a set of baselines: • System specification • Software project plan • Software requirement specification • Preliminary user manual • Design specification • Source code listing • Test Specification • Operation and Installation Manuals • Executable program • Database description • Maintenance documents • Standard and Procedures for software engineering SCM process Software configuration management is an important element of software quality assurance. and the reporting of all changes applied to the configuration. In the figure given below design specification is an aggregate object. the auditing of the software configuration to ensure that it has been properly developed. EMBEDDED SYSTEMS Page 46 of 72 . change control. design. However. Conceptually. Identification of objects in the software configuration To control and manage software configuration items. each must be separately named and then organized using an object-oriented approach. coding or testing. An aggregate object is a collection of basic objects and other aggregate objects. For example. Its primary responsibility is the control of change. Two types of objects can be identified: basic objects and aggregate objects. The five SCM tasks are: identification. version control. a basic object might be a section of a requirements specification. SCM is also responsible for the identification of individual SCIs and various versions of the software. A basic object is a “unit of text” that has been created by a software engineer during analysis. a source listing for a module or a suite of test cases. it can be viewed as a list of pointers that specify basic objects such as data model and module N.

Therefore.Configuration objects Design specification data design architectural design module design interface design Data model Module N interface description algorithmic description PDL Test specification test plan test procedure test cases Source code Version control Version control combines procedures and tools to manage different versions of configuration objects that are created during software engineering process. A component is composed of a collection of objects at the same revision level. consider a version of a simple program that is composed of components 1. To illustrate this concept consider the figure below.3. A variant is a different collection of objects at the same revision level and therefore EMBEDDED SYSTEMS Page 47 of 72 . Each version of the software is a collection of SCIs (source code. and 5. and 4. Component 4 is used only when the software is implemented using color displays. Component 5 is used when monochrome displays are available. documents and data) and each version may be composed of different variants.4. 2) 1.2. two variants of the version can be defined: 1) components 1.3. and 5.2.3.2.

and appropriate SQA activities are applied. The ECO describes the change to be made.3 Obj 1. Source safe (WinNT).1 Obj 1. Obj 1. Change control Change control combines human procedures and automated tools to provide a mechanism for the control of change.1 Obj 1.0 Obj 1. SCCS (Unix). The object is checked in EMBEDDED SYSTEMS Page 48 of 72 .2 Obj 2. A new version is defined when major changes are made to one or more objects. potential side effects. overall impact on other configuration objects and system functions.1. The results of the evaluation are presented as a change report that is used by a change control authority (CCA).coexists in parallel with other variants. and the projected cost of the change.2 1 2 Variants 3 4 5 Components Some of SCM tools are: Rational Rose. the constraints that must be respected and the criteria for review and audit. A change request is submitted and evaluated to assess technical merit. the change is made.0 Obj 1.1. An engineering change order (ECO) is generated for each approved change.4 Obj 2. RCS (Linux).1 Obj 1. The object to be changed is “checked out” of the project database.

to the database and appropriate version control mechanisms are used to create the next Need for change is recognized version of the software. Change request from user Developer evaluates Change report is generated Change control authority decides Request is queued for action Assign people to SCIs Check-out SCIs Make the change Change request is denied User is informed EMBEDDED SYSTEMS Page 49 of 72 .

Have software engineering standards been properly followed? 4. Have SCM procedures for noting the change. version control and change control help the software developer to maintain order in what would be a chaotic and fluid situation. Has a formal technical review been conducted to assess technical correctness? 3. Have all related SCI’s been properly updated? Status Reporting Configuration status reporting answers the following questions: 1. and reporting it been followed? 6. Has the change specified in the ECO been made? Have any additional modifications been incorporated? 2. The software configuration audit complements the formal technical review by assessing a configuration object for characteristics that are generally not considered during review. Who did it? EMBEDDED SYSTEMS Page 50 of 72 . What happened? 2. recording it. There are two methods to ensure that the change has been properly implemented: (1) formal technical reviews (2) the software configuration audit. Has the change been “highlighted” in the SCI? Have the change date and change author been specified? Do the attributes of the configuration object reflect the change? 5. The formal technical review focuses on the technical correctness of the configuration object that has been modified.Review/audit the change Establish a “baseline” for testing Perform SQA and testing activities Check-in the changed SCIs Promote SCI for inclusion in next release Rebuild appropriate version Review/audit the change Configuration audit Include all changes in release Identification. The audit asks and answers the following questions: 1.

The Pareto principle applies to software testing: That is 80% of all errors uncovered during testing will likely be traceable to 20% of all program modules. Testing Objectives 1. Testing is a process of executing a program with the intent of finding an error 2.1 Software Testing Techniques Software testing is a critical element of software quality assurance and represents the ultimate review of specification. More recent ANSI/IEEE standards are applicable for commercial software and are recommended for both large and small software engineering organizations. Testing should begin “in the small” and progress toward testing “in the large”. Exhaustive testing is not possible. 5. a software engineer must understand the basic principles that guide software testing. Testing principles Before applying methods to design effective test cases. Software Testing Fundamentals In the testing phase. A successful test is one that uncovers an as-yet undiscovered error. What else will be affected? Status reporting provides information about each change to those with a need to know. 5. 3. All tests should be traceable to customer requirements. Following are the principles that guide software testing: 1. SCM Standards Over the past two decades a number of software configuration management standards have been proposed. Tests should be planned long before testing begins. 2. EMBEDDED SYSTEMS Page 51 of 72 . Testing 5.3. A good test case is one that has a high probability of finding an as-yet undiscovered error. a series of test cases are created that are intended to “demolish” the software that has been built. 3. When did it happen? 4. 4. MIL-STD 483 focused on software developed for military standard. design and coding.

Understandability – The more information we have. (4) Exercise internal data structures to assure their validity. the more the testing can be automated and optimized. A good test should be neither too simple nor too complex. sometimes called glass-box testing is a test case design method that uses the control structure of the procedural design to derive test cases that. tests can be conducted that demonstrate each function is fully operational. The following checklist provides a set of characteristics that lead to testable software: 1. that internal operation performs according to specification and all internal components have been adequately exercised. 5. 4. A good test is not redundant 3. A good test has high probability of finding an error 2. Testability Software testability is simply how easily a computer program can be tested. (3) Execute all loops at their boundaries and with in their operational bounds. that is.6. The first test approach is called black-box testing and the second. an independent third party should conduct testing. (2) Knowing the internal workings of a product. 3. Controllability – The better we can control the software. To be most effective. The attributes of both testing can be combined to provide an approach that validates the software interface and selectively assures that the internal workings of the software are correct. Test Case Design The design of tests for software products can be as challenging as the initial design of the product itself. The basis path method enables the test case designer to derive a logical complexity measure of a procedural design and use the measure as a EMBEDDED SYSTEMS Page 52 of 72 . Observability – What you see is what you test. Operability – The better it works. 2. we can more quickly isolate problems and perform smarter retesting. 6. (2) Exercise all logical decisions on their true and false sides. tests can be conducted to ensure that “all gears mesh”. at the same time searching for errors in each function. the more efficiently it can be tested. White Box Testing White-box testing. Basis Path Testing It is a white-box testing method. Stability – The fewer the changes. Simplicity – The less there is to test. Decomposability – By controlling the scope of testing. the fewer the disruptions to testing. Any engineered product can be tested in one of the two ways: (1) knowing the specified function that a product has been designed to perform. the more quickly we can test it. 7. A good test should be “best of breed” 4. white-box testing. The following are the attributes of a “good” test: 1. (1) Guarantee that all independent paths within a module have been exercised at least once. the smarter we will test.

Sequence If While Until To illustrate the use if flow graph. consider the procedural design representation. that is the flow chart given below. Flow graph uses the following notations to depict control flow.guide for defining a basis set of execution paths. a simple notation for the representation of control flow called flow graph has to be known. EMBEDDED SYSTEMS Page 53 of 72 . which depict program control structure. Flow graph notation Before the basis path method can be implemented. Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing.

5 R2 7 R3 Region 8 R1 R4 9 10 11 EMBEDDED SYSTEMS Page 54 of 72 .3 6 4.1 2 3 6 4 7 9 8 5 10 11 Edges 1 Nodes 2.

Cyclomatic complexity It is a software metric that provides a quantitative measure of the logical complexity of a program. In terms of flow graph. An edge must terminate at a node. every statement in the program will be executed at least one time and every condition will have been executed on its true and false side.2. Cyclomatic complexity is computed in one of three ways: 1. Any procedural design representation can be translated into a flow graph. called a flow graph node. When counting regions we include the area outside the graph and count it as a region. The number of regions of the flow graph corresponds to the Cyclomatic complexity. For example. Paths 1. an independent path must move along at least one edge that has not been traversed before the path is defined. represents one or more procedural statements. 2. EMBEDDED SYSTEMS Page 55 of 72 . represent flow of control and are analogous to flowchart arrows.The above figure maps the flowchart into a corresponding flow graph. The arrows on the flow graph. Cyclomatic complexity. Areas bounded by edges and nodes are called regions. and 4 defined above comprise basis set for the above flow graph. It should be noted that the basis set is not unique. An independent path is any path through the program that introduces at least one new set of processing statements or a new condition. How do we know how many paths to look for? The computation of Cyclomatic complexity provides the answer. When this metric is used in the context of the basis path testing method. A sequence of process boxes and a decision diamond can map into a single node. for a flow graph is defined as V (G)= E – N + 2 where E is the number of flow graph edges and N is the number of flow graph nodes. Each circle. The path 1-2-3-4-5-10-1-2-3-6-8-9-10-111 is not considered to be an independent path because it is simply a combination of already specified paths and does not traverse any new edges. if tests can be designed to force execution of these paths (a basis set). even if the node does not represent any procedural statements. That is. the value computed for Cyclomatic complexity defines the number of independent paths in the basis set of a program and provides an upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once. any number of different basis sets cab derived for a given procedural design. V (G). called edges or links. In fact.3. a set of independent paths for the above flow graph is: Path1: 1-11 Path2: 1-2-3-4-5-10-1-11 Path3: 1-2-3-6-8-9-10-1-11 Path4: 1-2-3-6-7-9-10-1-11 Note that each new path introduces a new edge.

DO WHILE value [i] < > -999 and total.input <100 increment total.valid = 0. minimum. Cyclomatic complexity. ENDDO IF total. TYPE value[1:100] IS SCALAR ARRAY. sum IS SCALAR. 2. PROCEDURE average. V (G).input = total.input by 1. depicted in PDL will be mapped to a flow graph and each step in the test case design will be illustrated. maximum.input. ENDIF END average The PDL average though simple contains compound conditions and loops. where P is the number of predicate nodes contained in the flow graph G. EMBEDDED SYSTEMS Page 56 of 72 . minimum. Deriving test cases The procedure average. total. for basis path testing. two or more edges emanate from it. IF value [i] >= minimum and value [ i ] <= maximum THEN increment total. it also computes the sum and the total number valid. Sum = sum + value [ i] ELSE skip ENDIF increment i by 1.valid. 1. ELSE average = -999. INTERFACE RETURNS average. (Nodes that contain a condition. total.Using the design or code as a foundation. 3.valid. 1. total. total.valid.valid by 1. TYPE average. INTERFACE RETURNS value. total. maximum. draw a corresponding flow graph. *This procedure computes the average of 100 or fewer numbers that lie between bounding values.3.) for the above flow graph can be computed using the three The flow graph has 4 regions V (G) = 11 edges – 9 nodes +2 = 4 V (G) = 3 predicate nodes + 1 = 4 The Cyclomatic complexity methods discussed here. is also defined as V (G) = P+1. TYPE i IS INTEGER.valid >0 THEN average = sum /total. sum = 0. i=1.input.

. V (G) = 6 regions V (G) = 18 edges – 14 nodes + 2 = 6 V (G) = 5 predicates nodes + 1 = 6 3.6.. . . and 10.5. Path6: 1-2-3-4-5-6-7-8-9-2. Determine a basis set of linearly independent paths. ) following paths 4. In this case. Determine the Cyclomatic complexity of the resultant flow graph. The value of V (G) provides the number of linearly independent paths through the program control structure. EMBEDDED SYSTEMS Page 57 of 72 .. . Path5: 1-2-3-4-5-6-8-9-2. . For procedure average.3. the set of independent paths are: Path1: 1-2-10-11-13 Path2: 1-2-10-12-13 Path3: 1-2-3-10-11-13 Path4: 1-2-3-4-5-8-9-2-. The ellipsis (. which will aid in deriving test cases.1 2 3 10 4 12 13 6 11 5 8 9 7 2.5. . nodes 2. . . and 6 indicates that any path through the remainder of the control structure is acceptable. . It is helpful to identify the predicate nodes.

where i < 100 Expected results: correct average based on n values and proper totals Each test case is executed and compared to expected results.g. other totals at initial values Path 3 test case: attempt to process 101 or more values first 100 values should be valid expected results: same a test case 1 Path 4 test case: Value (i) = valid input. Note: Path 1 cannot be tested standalone but must be tested as part of path 4. and matrix entries correspond to connections (edges) between nodes. EMBEDDED SYSTEMS Page 58 of 72 . Graph matrices To develop a software tool that assists in basis path testing. Test cases that satisfy the basis set described above are: Path 1 test case: Value (k) = valid input.4. path 1 in this case) cannot be tested in standalone fashion. and 6 tests. the combination of data required to traverse the path cannot be achieved in the normal flow of the program. Prepare test cases that will force execution of each path in the basis set. where i < 100 Value (k) < minimum. where k < i Expected results: correct average based on k values and proper totals Path 5 test case: Value (i) = valid input. these paths are tested as part of another path test. where i < 100 Value (k) > minimum. where 2 ≤ i ≤ 100 Expected results: correct average based on k values and proper totals. where k < i defined below Value (i) = -999. a data structure called graph matrix. Data should be chosen so that conditions at the predicate nodes are appropriately set as each path is tested. It is important to note that some independent paths (e. A graph matrix is a square matrix whose size is equal to the number of nodes on the flow graph. can be quite useful. That is. where k ≤ i Expected results: correct average based on n values and proper totals Path 6 test case: Value (i) = valid input. In such cases. Each row and column corresponds to an identified node. Path 2 test case: Value(1) = -999 Expected results: average = -999.5.

This white-box testing method focuses exclusively on the validity of loop constructs. In the figures below a flow graph and its corresponding graph matrix with link weight is depicted. to make graph matrix more powerful tool for evaluating program control structure. a e f 10 g 7 2 b 9 c 1 d Connected to node Node 1 2 3 4 1 1 2 3 1 4 5 connections 1-1=0 1 1 1 2-1=1 2-1=1 Cyclomatic 2 – 1 = 1 complexity 1 5 1 Control Structure Testing Control structure testing broadens testing coverage and improves 3 + 1 = 4of white box quality testing: (1) Condition testing (2) Data flow testing (3) Loop Testing Loop testing Loops are the foundation for most algorithms implemented in software. and unstructured loops. nested loops. simple loops. Four different classes of loops can be defined. If link weight is 1 it means a connection exists or 0 means no connection exists.We can add a link weight to each matrix entry. EMBEDDED SYSTEMS Page 59 of 72 . Each row with two or more entries of 1 represents predicate node.

(n-1). 1. where n is the maximum number of allowable passes through the loop. Add other tests for out-of-range or excluded values. and (n+1) passes through the loop Nested loops – 1. 2. m passes through the loop m < n 5. Two passes through the loop 4. Start at the innermost loop. n. Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter values. Skip the loop entirely 2. EMBEDDED SYSTEMS Page 60 of 72 .Simple Loop Nested Loops Concatenated loops Unstructured loops Simple loops –The following set of tests should be applied to simple loops. Only one pass through the loop 3. Set all other loops to minimum values.

one valid and two invalid equivalence classes are defined. then the loops are not independent. That is black box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. Concatenated loops – Concatenated loops can be tested using approach defined for simple loops. If a set of objects can be linked by relationships that are symmetric. Typically. If two loops are concatenated and the loop counter for loop 1 is used as the initial value for loop 2. An ideal test case uncovers a class of errors that might otherwise require many cases to be executed. and reflexive. 4. if each of the loops is independent of the other. an input condition is either a specific numeric value. the input domain of the program is divided into classes of data from which test cases can be derived. Test case design for equivalence partitioning is based on an evaluation of equivalence classes for an input condition. Continue until all loops have been tested. Equivalence classes may be defined according to the following guidelines: 1. Graph-Based Testing Methods 2. Equivalence Partitioning 3. a range of values. EMBEDDED SYSTEMS Page 61 of 72 . Boundary value analysis 4. or a Boolean condition. Work outward. Unstructured loops – Whenever possible this type of loops should be redesigned to reflect the use of structured programming constructs. approach applied to nested loops is applied. Comparison Testing Equivalence Partitioning In this black-box testing method. An equivalence class represents a set of valid or invalid states for input conditions. conducting tests for the next loop. and (5) Initialization and termination errors. Black-Box Testing Black-box testing focuses on the functional requirements of the software. Some of Black-box testing methods are: 1. but keeping all other outer loops at minimum values and other nested loops to “typical” values. a set of related values. Black-box testing attempts to find errors in the following categories: (1) Incorrect or missing functions (2) Interface errors (3) Errors in data structures or external data base access (4) Performance errors. an equivalence class is present.3. If an input condition specifies a range. transitive.

For example. 4. Guidelines for BVA are similar in many respects to those provided for equivalence partitioning: 1. 3. architectures. If internal program data structures have prescribed boundaries (e. Rather than selecting any element of an equivalence class. one valid and one invalid class are defined. test cases should be designed with values a and b. If an input condition specifies a number of values.. Test cases should be designed to create an output report that produces the maximum (and minimum) allowable number of table entries.g. Testing for Specialized environments Testing for specialized environments. boundary value analysis (BVA) leads to the selection of test cases at the “edges” of the class. pressure table is required as output from an engineering analysis program. 2. 4. an array has a defined limit of 100 entries). Boundary value analysis It is a test case design technique that compliments equivalence partitioning. just above and just below a and b. one valid and two invalid equivalence classes are defined. 2. respectively. BVA derives test cases from the output domain as well. assume that a temperature vs. If an input condition is Boolean. 3.If an input condition requires a specific value. test cases should be developed that exercise the minimum and maximum numbers. and applications that are commonly encountered by software engineers are: (1) Testing GUIs (2) Testing of Client/Server Architecture (3) Testing documentation and Help facilities (4) Testing for real time systems EMBEDDED SYSTEMS Page 62 of 72 . Values just above and below minimum and maximum are also tested. be certain to design a test case to exercise the data structure at its boundary. If an input condition specifies a range bounded by values a and b. Guidelines 1 and 2 are applied to output conditions. If an input condition specifies a member of a set. one valid and one invalid equivalence class are defined.

5.2 Software Testing Strategies A strategy for software testing integrates software test case design methods into a wellplanned series of steps that result in the successful construction of software. test execution and resultant data collection and evaluation. Any testing strategy must incorporate test planning. EMBEDDED SYSTEMS Page 63 of 72 . test case design.

EMBEDDED SYSTEMS Page 64 of 72 . For this reason a template for software testing. Validation refers to a different set of activities that ensures that the software that has been built is traceable to customer requirements. performance. does an independent test group become involved. Moving inward along the spiral. Verification and validation Software testing is one element of a broader topic that is often referred to as verification and validation (V&V). In many cases developer also conducts integration testing – a testing step that leads to the construction of the complete program structure. system engineering defines the role of software and leads to software requirement analysis. The template has following generic characteristics: • Testing begins at the module level and works “outward: toward the integration of entire compute based system. but debugging must be accommodated in any testing strategy. Only after the software architecture is complete. A software testing strategy The software engineering process may be viewed as a spiral. function.a set of steps into which we can place specific test case design methods should be designed for the software engineering process. • Different testing techniques are appropriate at different points in time • Testing is conducted by the developer of the software and (for large projects) an independent test group. where the information domain. To develop computer software. behavior. • Testing and debugging are different activities. constraints and validation criteria for software are established. we come to design and finally to coding. Verification: “Are we building the product right?” Validation: “Are we building the right product?” Organizing for software testing The software engineer is always responsible for testing the individual units (modules) of the program. Initially. Verification refers to the set of activities that ensure that software currently implements a specific function. we spiral in along streamlines that decrease the level of abstraction on each turn.A strategic Approach to software testing Testing is a set of activities that can be planned in advance and conducted systematically. ensuring that each performs the function for which it was designed.

the module. important control paths are tested to uncover errors within the boundary of the module. Boundary conditions are tested to ensure that the module operates properly at boundaries established to limit or restrict processing. Using the procedural design description as a guide. All independent paths (basis paths) through the control structure are exercised to ensure that all statements in a module have been executed at least once. EMBEDDED SYSTEMS Page 65 of 72 .Testing strategy System engineering S Requirements Design R D C U I V ST code Unit test Integration test Validation test System test Unit Testing Unit testing focuses verification effort on the smallest unit of software design. And. Unit test considerations The module interface is tested to ensure that information properly flows into and out of the program unit under test. finally all error-handling paths are tested. The local data structure is examined to ensure that data stored temporarily maintains its integrity during all steps in an algorithm’s execution.

passes such data to the module (to be tested) and prints relevant results. Because a module is not a standalone program. interface driver local data structures Module boundary conditions independent paths stub stub error handling paths test cases RESULTS EMBEDDED SYSTEMS Page 66 of 72 . unit test case design begins. driver and/or stub software must be developed for each unit test. reviewed and verified for correct syntax.module to be tested interface local data structures boundary conditions independent paths error handling paths test cases Unit test procedures Unit testing is normally considered as an adjunct to the coding step. In most applications a driver is nothing more than a “main program” that accepts test case data. After the source level code has been developed. A stub or “dummy subprogram” uses the subordinate module’s interface may be minimal data manipulation. Stubs serve to replace modules that are subordinate to (called by) the module to be tested. prints verification of entry and returns.

Often we attempt to construct the program using a “big bang” approach that is all modules are combined in advance. the entire program is tested as a whole. interfaces are more likely tested completely. where errors are easier to isolate and correct. (3) Tests are conducted as each module is integrated.e.or breadth first) subordinate stubs is replaced one at time with actual modules. another stub is replaced with the real module. Correction is difficult because isolation of causes is complicated by the vast expanse of the entire program. Incremental integration is the approach where the program is constructed and tested in small segments. The integration process is performed in a series of five steps: (1) The main control module is used as test driver. and a systematic test approach may be applied. Modules are integrated by moving downward through the control hierarchy. top module is tested with stubs A B C F G stubs are replaced one at a time. (2) Depending on the integration approach selected (i. (5) Regression testing may be conducted to ensure that new errors have not been introduced.Integration Testing Integration testing is a systematic technique for constructing the program structure while conducting tests to uncover errors associated with interfacing. "depth first" D E as new modules are integrated. (4) On completion of each set of tests. Usually a set of errors is encountered. new ones appear and the process continues in a seemingly endless loop. beginning with the main control module (main program). and stubs are substituted for all modules directly subordinate to the main control module. Modules subordinate to the main control module are incorporated into the structure in either a depth-first or breadth-first manner. depth. some subset of tests is re-run EMBEDDED SYSTEMS Page 67 of 72 . The objective is to take unit tested modules and build a program structure that has been dictated by design. Once these errors are corrected. Top-down Integration Top-down integration is an incremental approach to construction of program structure.

e. (2) A driver (i. its documentation. The regression test suite contains three different classes of test cases: • A representative sample of tests that will exercise all software functions EMBEDDED SYSTEMS Page 68 of 72 . A bottom-up integration strategy may be implemented with the following steps: (1) Low-level modules are combined into clusters (sometimes called builds) that perform a specific software sub-function. drivers are replaced one at a time.Bottom-up integration Bottom-up integration testing begins construction and testing with atomic modules (i. "depth first" MA D1 D2 D3 MC cluster1 MD ME MG MF MH cluster2 worker modules are grouped into builds and integrated Regression testing Whenever software is corrected. Regression testing is the activity that helps to ensure that changes (due to testing or for other reasons) do not introduce unintended behavior or additional errors. or the data that support it) is changed. (3) The cluster is tested (4) Drivers are removed and clusters are combined moving upward in the program structure. modules at lowest levels in the program structure). some aspect of the software configuration (the program.e. control program for testing) is written to coordinate test case input and output.

Alpha and Beta Testing When custom software is built for one customer.• • Additional tests that focus on software functions that are likely to be affected by the change Tests that focus on the software components that have been changed. Therefore the beta test is a “live” application of the software. and a final series of software tests – validation testing – may begin. interfacing errors have been uncovered and corrected. Deviation or error discovered at this stage in a project can rarely be corrected prior to scheduled completion. Validation test criteria Software validation is achieved through a series of black-box tests that demonstrate conformity with requirements. The intent of the review is to ensure that all elements of the software configuration have been properly developed. Although each test has a different purpose. the developer is generally not present. or (2) a deviation from specification is uncovered and a deficiency list is created. System Testing System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system. Unlike alpha testing. Configuration Review An important element of the validation process is configuration review. one of two possible conditions exist: (1) The function or performance characteristics conform to specification and are accepted. a process called alpha and beta testing is used to uncover errors that only the end user seems able to find. The alpha test is conducted at the developer’s site by a customer in a controlled environment. After each validation test case has been conducted. all work to verify that all system elements have been properly integrated and perform allocated functions. software is completely assembled as a package. Validation Testing At the culmination of integration testing. and have necessary detail to support the maintenance phase of the software life cycle. The following systems tests are conducted: (1) Recovery Testing (2) Security Testing (3) Stress testing (4) Performance Testing EMBEDDED SYSTEMS Page 69 of 72 . If software is developed as a product to be used by many customers. a series of acceptance tests are conducted to enable the customer to validate all requirements. The beta test is conducted at one or more customer sites by the end users(s) of the software.

thereby leading to error correction. or (2) The cause will not be found. The debugging process will always have one of two outcomes: (1) The cause will be found. the non-corresponding data is a symptom of an underlying cause as yet hidden. In many cases. Results are assessed and a lack of correspondence between expected and actual is encountered. The debugging process attempts to match symptoms with cause. when a test case uncovers an error.6. In the latter case. Debugging Debugging occurs as a consequence of successful testing. Debugging Process The debugging process begins with the execution of a test case. That is. the person performing debugging may suspect a cause. corrected and removed. and work toward error correction in an iterative fashion. Symptoms & Causes Symptom and cause may be geographically separated Symptom may disappear when another problem is fixed Cause may be due to a combination of non-errors Cause may be due to a system or compiler error Cause may be due to assumptions that everyone believes Symptom may be intermittent symptom cause EMBEDDED SYSTEMS Page 70 of 72 . design a test case to help validate his or her suspicion. debugging is the process that results in the removal of the error.

Memory dumps are taken. Beginning at the site where a symptom has been uncovered. we hope that somewhere in the information produced we will find a clue that can lead to the cause of the error. most frequently leads to wasted effort and time.Debugging Effort time required to correct the error and conduct regression tests time required to diagnose the symptom and determine the cause Debugging Approaches Regardless of the approach that is taken. that can be used in small programs. intuition. The objective is realized by a combination of systematic evaluation. Backtracking approach This approach is a fairly common. and the program is loaded with WRITE statements. the source code is traced backward (manually) EMBEDDED SYSTEMS Page 71 of 72 . Although the huge information produced may lead to success. This method is applied when all else fails. run-time traces are invoked. debugging has one overriding objective: to find and correct the cause of a software error. By doing this. and luck. In general three categories for debugging approaches may be proposed:  Brute force  Backtracking  Cause elimination Brute force approach The brute force category of debugging is probably the most common and least efficient method for isolating the cause of a software error.

the number of potential backward path may become unmanageably large. However. tools are not a substitute for careful evaluation based on a complete software design document and clear source code.until the site of the cause is found. and memory dumps. dynamic debugging aids (tracers). A “cause hypothesis” is devised and the data are used to prove or disprove the hypothesis. Alternatively. Cause elimination approach This approach introduces the concept of binary partitioning. If initial tests indicate that a particular cause hypothesis shows promise. We can apply a wide variety of debugging compilers. a list of all possible causes is developed and tests are conducted to eliminate each. automatic test case generators. the data are refined in an attempt to isolate the bug. EMBEDDED SYSTEMS Page 72 of 72 . Data related to the error occurrence are organized to isolate potential causes. Each of the above debugging approaches can be supplemented with debugging tools. As the code lines increases.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->