Software engineering note


Published on

It is covering all the details about the software engineering principles ,Which is strictly according to BPUT syllabus

Published in: Education, Technology, Business
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software engineering note

  1. 1. Principle & Practices Of Software Engineering PRINCIPLES & PRACTICES OF SOFTWARE ENGINEERINGLecture -1History Of Software Engineering:Objectives : • Identify the scope and necessity of software engineering. • Identify the causes of and solutions for software crisis. • Differentiate a piece of program from a software product.Scope and necessity of software engineering Software engineering is an engineering approach for software development. We can alternatively view itas a systematic collection of past experience. The experience is arranged in the form of methodologiesand guidelines. A small program can be written without using software engineering principles. But if onewants to develop a large software product, then software engineering principles are indispensable toachieve a good quality software cost effectively. These definitions can be elaborated with the help of abuilding construction analogy.Suppose you have a friend who asked you to build a small wall as shown in fig. 1.1. You would be able todo that using your common sense. You will get building materials like bricks; cement etc. and you willthen build the wall. Fig 1.1 A Small WallBut what would happen if the same friend asked you to build a large multistoried building as shown infig. 1.2? Fig. 1.2: A Multistoried Building Page | 1Prepared By Neelamani Samal
  2. 2. Principle & Practices Of Software EngineeringYou dont have a very good idea about building such a huge complex. It would be very difficult to extendyour idea about a small wall construction into constructing a large building. Even if you tried to build alarge building, it would collapse because you would not have the requisite knowledge about the strengthof materials, testing, planning, architectural design, etc. Building a small wall and building a largebuilding are entirely different ball games. You can use your intuition and still be successful in building asmall wall, but building a large building requires knowledge of civil, architectural and other engineeringprinciples. Without using software engineering principles it would be difficult to develop large programs. Inindustry it is usually needed to develop large programs to accommodate multiple functions. A problemwith developing such large commercial programs is that the complexity and difficulty levels of theprograms increase exponentially with their sizes as shown in fig. 1.3. Fig. 1.3: Increase in development time and effort with problem sizeSoftware crisisSoftware engineering appears to be among the few options available to tackle the present software crisis. To explain the present software crisis in simple words, consider the following. The expenses thatorganizations all around the world are incurring on software purchases compared to those on hardwarepurchases have been showing a worrying trend over the years (as shown in fig. 1.4) Page | 2Prepared By Neelamani Samal
  3. 3. Principle & Practices Of Software Engineering Organizations are spending larger and larger portions of their budget on software. The cost we aretalking of here is not on account of increased features, but due to ineffective development of the productcharacterized by inefficient resource usage, and time and cost over-runs. There are many factors that have contributed to the making of the present software crisis. Factorsare larger problem sizes, lack of adequate training in software engineering, increasing skill shortage, andlow productivity improvements. This can be solved with proper use of Principles of software engineering.Program vs. software product Programs are developed by individuals for their personal use. They are therefore, small in sizeand have limited functionality. In case of a program, a single developer is involved. The user interfacemay not be very important, because the programmer is the sole user. In case of program very littledocumentation is expected. A program can be developed according to the programmer’s individual styleof development. Software products are extremely large; most users are not involved with the development. And alarge number of developers are involved. For a software product, user interface must be carefullydesigned and implemented because developers of that product and users of that product are totallydifferent. Software product must be well documented. Software Product must be developed using theaccepted software engineering principles.Exploratory style vs. Modern style of Software development The exploratory software development style is based on error correction. In the exploratory style,errors are detected only during the final product testing. In the exploratory style, coding was consideredsynonymous with software development. For instance, exploratory programming style believed indeveloping a working system as quickly as possible and then successively modifying it until it performedsatisfactorily. The Modern Software Engineering principles are primarily based on error prevention. Inherent inthe software engineering principles is the realization that it is much more cost-effective to prevent errorsfrom occurring than to correct them as and when they are detected. Even when errors occur, softwareengineering principles emphasize detection of errors as close to the point where the errors are committedas possible. The modern practice of software development is to develop the software through severalwell-defined stages such as requirements specification, design, coding, testing, etc., and attempts aremade to detect and fix as many errors as possible in the same phase in which they occur. In the modernsoftware development style, coding is regarded as only a small part of the overall software developmentactivities. There are several development activities such as design and testing which typically requiremuch more effort than coding. Page | 3Prepared By Neelamani Samal
  4. 4. Principle & Practices Of Software EngineeringLecture -2Objectives • Explain what a life cycle model is. • Explain what problems would occur if no life cycle model is followed. • Identify the different software life cycle models. • Identify the different phases of the classical waterfall model. • Identify the activities undertaken in each phase. • Identify the shortcomings of the classical waterfall model. • Identify the phase-entry and phase-exit criteria of each phase.Life cycle model: Definition:A software life cycle model (also called process model) is a descriptive and diagrammaticrepresentation of the software life cycle. A life cycle model represents all the activities required to make a software product transit throughits life cycle phases. It also captures the order in which these activities are to be undertaken. In otherwords, a life cycle model maps the different activities performed on a software product from its inceptionto retirement. During any life cycle phase, more than one activity may also be carried out.Need for a software life cycle Model: The development team must identify a suitable life cycle model for the particular project and thenadhere to it. Without using of a particular life cycle model the development of a software product wouldnot be in a systematic and disciplined manner. A software life cycle model defines entry and exit criteria for every phase. A phase can start onlyif its phase-entry criteria have been satisfied. So without software life cycle model the entry and exitcriteria for a phase cannot be recognized. Without software life cycle models it becomes difficult forsoftware project managers to monitor the progress of the project. Without using of a particular life cycle model the development of a software product would notbe in a systematic and disciplined manner. When a software product is being developed by a team theremust be a clear understanding among team members about when and what to do. Otherwise it would leadto chaos and project failure.Different software life cycle modelsMany life cycle models have been proposed so far. Each of them has some advantages as well as somedisadvantages. A few important and commonly used life cycle models are as follows:  Classical Waterfall Model  Iterative Waterfall Model  Prototyping Model  Evolutionary Model  Spiral Model Page | 4Prepared By Neelamani Samal
  5. 5. Principle & Practices Of Software EngineeringClassical waterfall Model: The classical waterfall model is intuitively the most obvious way to develop software. This modelcan be considered to be a theoretical way of developing software. But all other life cycle models areessentially derived from the classical waterfall model.Classical waterfall model divides the life cycle into the following phases as shown in fig.2.1:  Feasibility Study  Requirements Analysis and Specification ƒ Design  Coding and Unit Testing  Integration and System Testing  Maintenance Fig 2.1: Classical Waterfall Model Page | 5Prepared By Neelamani Samal
  6. 6. Principle & Practices Of Software EngineeringFeasibility Study: - The main aim of feasibility study is to determine whether it would be financially and technicallyfeasible to develop the product. i) At first project managers or team leaders try to have a rough understanding of what is required to be done by visiting the client side. They study different input data to the system and output data to be produced by the system. ii) After they have an overall understanding of the problem they investigate the different solutions that are possible. iii) Based on this analysis they pick the best solution and determine whether the solution is feasible financially and technically. They check whether the customer budget would meet the cost of the product and whether they have sufficient technical expertise in the area of development.Analysis and Specification: - The aim of the requirements analysis and specification phase is to understand the exactrequirements of the customer and to document them properly. This phase consists of two distinct activities, namely  Requirements gathering and analysis, and  Requirements specification The goal of the requirements gathering activity is to collect all relevant information from thecustomer regarding the product to be developed. This is done to clearly understand the customerrequirements so that incompleteness and inconsistencies are removed. The requirements analysis activity is begun by collecting all relevant data regarding the productto be developed from the users of the product and from the customer through interviews and discussions. After all ambiguities, inconsistencies, and incompleteness have been resolved and all therequirements properly understood, the requirements specification activity can start. During this activity,the user requirements are systematically organized into a Software Requirements Specification (SRS)document.Design: - The goal of the design phase is to transform the requirements specified in the SRS document intoa structure that is suitable for implementation in some programming language.Two distinctly different approaches are available: the traditional design approach and the object-orienteddesign approach. i) Traditional design approachTraditional design consists of two different activities; first a structured analysis of the requirementsspecification is carried out where the detailed structure of the problem is examined. This is followed by aStructured design activity. During structured design, the results of structured analysis are transformed intothe software design. Page | 6Prepared By Neelamani Samal
  7. 7. Principle & Practices Of Software Engineering ii) Object-oriented design approachIn this technique, various objects that occur in the problem domain and the solution domain are firstidentified, and the different relationships that exist among these objects are identified. The objectstructure is further refined to obtain the detailed design.Coding and Unit Testing:- The purpose of the coding and unit testing phase (sometimes called the implementation phase) ofsoftware development is to translate the software design into source code. Each component of the designis implemented as a program module. The end-product of this phase is a set of program modules that havebeen individually tested. During this phase, each module is unit tested to determine the correct working of all theindividual modules. It involves testing each module in isolation as this is the most efficient way to debugthe errors identified at this stage.Integration and System Testing: - Integration of different modules is undertaken once they have been coded and unit tested. Duringthe integration and system testing phase, the modules are integrated in a planned manner. The differentmodules making up a software product are almost never integrated in one shot. Integration is normallycarried out incrementally over a number of steps. Finally, when all the modules have been successfullyintegrated and tested, system testing is carried out. The goal of system testing is to ensure that thedeveloped system conforms to its requirements laid out in the SRS document.System testing usually consists of three different kinds of testing activities:-  α – testing: It is the system testing performed by the development team.  β – testing: It is the system testing performed by a friendly set of customers.  Acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product.Maintenance: - Maintenance of a typical software product requires much more than the effort necessary todevelop the product itself. Many studies carried out in the past confirm this and indicate that the relativeeffort of development of a typical software product to its maintenance effort is roughly in the 40:60 ratio.Maintenance involves performing any one or more of the following three kinds of activities: i) Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. ii) Improving the implementation of the system, and enhancing the functionalities of the system according to the customer’s requirements. This is called perfective maintenance. iii) Porting the software to work in a new environment. For exampleporting may be required to get the software to work on a new computer platform or with a new operating system. This is called adaptive maintenance. Page | 7Prepared By Neelamani Samal
  8. 8. Principle & Practices Of Software EngineeringShortcomings of the classical waterfall model :  Error of any phase is detected at the end of the entire lifecycle.  It does not allow for very much Iteration.  Hard dates on phases. The dates set for completing Analysis and Design are major milestones thatdevelopers are measured againstIterative Waterfall Model: Iterative development is the heart of a cyclic software development process developed inresponse to the weaknesses of the waterfall model. It starts with an initial planning and ends withdeployment with the cyclic interactions in between i.e. it provide feedback paths from every phase to itspreceding phases. The feedback paths allow for correction of the errors committed during a phase .Therest of the phases of development are same as classical water fall model. The model is pictorially shownin fig 2.2 Fig 2.2 Iterative Waterfall modelShortcomings: i) It cannot effectively handle the different types of risks that are in real life software project. ii) Once a developer completes his work, he idles waiting the phase to get over. i.e. wastage of time due to waiting for the job. Page | 8Prepared By Neelamani Samal
  9. 9. Principle & Practices Of Software EngineeringLecture 3Prototyping Model:Objectives• Explain what a prototype is.• Explain why and when a prototype needs to be developed during software development.• Identify the situations in which one would prefer to build a prototype.• State the activities carried out during each phase of a spiral model.• Identify circumstances under which spiral model should be used for software development.• Tailor a development process to a specific prototype.Prototype A prototype is a toy implementation of the system. A prototype usually exhibits limitedfunctional capabilities, low reliability, and inefficient performance compared to the actual software. Aprototype is usually built using several shortcuts. A prototype usually turns out to be a very crude versionof the actual system.Need for a prototype in software development There are several uses of a prototype. An important purpose is to illustrate the input data formats,messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism for gainingbetter understanding of the customer’s needs i.e. • How the screens might look like • How the user interface would behave • How the system would produce outputsThis is something similar to what the architectural designers of a building do; they show a prototype ofthe building to their customer. The customer can evaluate whether he likes it or not. A similar thinghappens in the case of a software product and its prototyping model. Another reason for developing a prototype is that it is impossible to get the perfect product in thefirst attempt. The experience gained in developing the prototype can be used to develop the final product.A prototyping model can be used when technical solutions are unclear to the development team.Where to use Prototype ModelA prototype of the actual product is preferred in situations such as: • User requirements are not complete • Technical issues are not clear Page | 9Prepared By Neelamani Samal
  10. 10. Principle & Practices Of Software Engineering Fig 3.1 Prototyping Model The prototyping model of software is shown in fig 3.1. In this model a prototyping starts with aninitial requirement and gathering phase .A quick design is carried out and a prototype is build. Thedeveloped prototype is submitted to the customer for evaluation. Based on the customer feedback we maygo for development or again go for the redesign as per customer demand. The code for the prototype is usually thrown away, but the experience gained while developingthe prototype helps for actual development. The rest of the phases of development are similar to thewaterfall model. Page | 10Prepared By Neelamani Samal
  11. 11. Principle & Practices Of Software EngineeringLecture 4Evolutionary Model: This life cycle model is also referred to as the successive versions model and sometimes as theincremental model. In this lifecycle model the software is first broken down into several module whichcan be incrementally constructed and delivered. The development team first develops the core modules ofthe system. Each evolutionary version may be developed using an iterative waterfall model ofdevelopment. The development model is shown in fig 4.1. C B A B A A Fig 4.1. Evolutionary model (A,B,C are modules of the software model)Each successive version of the product is fully functioning capable of performing more useful work thanthe previous version. In this model the user gets a chance to experiment with a particularly developedsoftware much before the complete version of the software is ready.This model is useful only for verylarge products.Spiral ModelThe Spiral model of software development is shown in fig. 4.2. The diagrammatic representation of thismodel appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Eachloop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study. The next loop withrequirements specification, the next one with design, and so on. Each phase in this model is split into foursectors (or quadrants) as shown in fig. 4.2. The following activities are carried out during each phase of aspiral model. Fig 4.2 Spiral Model Page | 11Prepared By Neelamani Samal
  12. 12. Principle & Practices Of Software EngineeringFirst quadrant (Objective Setting) • During the first quadrant, it is needed to identify the objectives of the phase. • Examine the risks associated with these objectives.Second Quadrant (Risk Assessment and Reduction) • A detailed analysis is carried out for each identified project risk. • Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed.Third Quadrant (Development and Validation) • Develop and validate the next level of the product after resolving the identified risks.Fourth Quadrant (Review and Planning) • Review the results achieved so far with the customer and plan the next iteration around the spiral. • Progressively more complete version of the software gets built with each iteration around the spiral.Where to use spiral model ? The spiral model is called a meta model since it encompasses all other life cycle models. Riskhandling is inherently built into this model. The spiral model is suitable for development of technicallychallenging software products that are prone to several kinds of risks. However, this model is much morecomplex than the other models – this is probably a factor deterring its use in ordinary projects. Page | 12Prepared By Neelamani Samal
  13. 13. Principle & Practices Of Software EngineeringLecture 5:Comparison of different life-cycle models The classical waterfall model can be considered as the basic model and all other life cycle modelsas embellishments of this model. However, the classical waterfall model can not be used in practicaldevelopment projects, since this model supports no mechanism to handle the errors committed during anyof the phases. This problem is overcome in the iterative waterfall model. The iterative waterfall model isprobably the most widely used software development model evolved so far. This model is simple tounderstand and use. However, this model is suitable only for well-understood problems; it is not suitablefor very largeprojects and for projects that are subject to many risks.The prototyping model is suitable for projects for which either the user requirements or the underlyingtechnical aspects are not well understood. This model is especially popular for development of the user-interface part of the projects. The evolutionary approach is suitable for large problems which can be decomposed into a set ofmodules for incremental development and delivery. This model is also widely used for object-orienteddevelopment projects. Of course, this model can only be used if the incremental delivery of the system isacceptable to the customer. The spiral model is called a meta model since it encompasses all other life cycle models. Riskhandling is inherently built into this model. The spiral model is suitable for development of technicallychallenging software products that are prone to several kinds of risks. However, this model is much morecomplex than the other models – this is probably a factor deterring its use in ordinary projects. Page | 13Prepared By Neelamani Samal
  14. 14. Principle & Practices Of Software EngineeringLecture 6Case Study of software development process. A mining company named Galaxy Mining Company Ltd. (GMC) has mines located at variousplaces in India. It has about fifty different mine sites spread across eight states. The company employs alarge number of mines at each mine site. Mining being a risky profession,the company intends to operate a special provident fund, which would exist in addition to the standardprovident fund that the miners already enjoy. The main objective of having the special provident fund(SPF) would be quickly distribute some compensation before the standardprovident amount is paid. According to this scheme, each mine site would deduct SPF installments fromeach miner every month and deposit the same with the CSPFC (Central Special Provident FundCommissioner). The CSPFC will maintain all details regarding the SPF installments collected from theminers. GMC employed a reputed software vendor Adventure Software Inc. to undertake the task ofdeveloping the software for automating the maintenance of SPF records of all employees. GMC realizedthat besides saving manpower on bookkeeping work, the software would help in speedy settlement ofclaim cases. GMC indicated that the amount it can afford for thissoftware to be developed and installed is Rs. 1 million. Adventure Software Inc. deputed their projectmanager to carry out the feasibility study. The project manager discussed the matter with the topmanagers of GMC to get an overview of the project. He also discussed the issues involved with theseveral field PF officers at various mine sites to determine the exact details of the project. The projectmanager identified two broad approaches to solve the problem. One was tohave a central database which could be accessed and updated via a satellite connection to various minesites. The other approach was to have local databases at each mine site and to update the central databaseperiodically through a dial-up connection. These periodic updates could be done on a daily or hourlybasis depending on the delay acceptable to GMC in invoking various functions of the software. Theproject manager found that the second approach was very affordable and more fault-tolerant as the localmine sites could still operate even when the communication link to the central database temporarilyfailed. The project manager quickly analyzed the database functionalities required, the user-interfaceissues, and the software handling communication with the mine sites. He arrived at a cost to develop fromthe analysis. He found that the solution involving maintenance of local databases at the mine sites andperiodic updating of a central database was financially and technically feasible. The project managerdiscussed his solution with the GMC management and found that the solution was acceptable to them aswell. Page | 14Prepared By Neelamani Samal
  15. 15. Principle & Practices Of Software EngineeringLecture 7 and 8Doubt Clearing Class and question discussion.1. Identify the definite stages through which a software product undergoes during its lifetime.Ans.: - The definite stages through which a software product undergoes during its lifetime are asfollows:ƒ Feasibility Studyƒ Requirements Analysis and Specificationƒ Designƒ Coding and Unit Testingƒ Integration and System Testing, andƒ Maintenance2. Differentiate between structured analysis and structured design.Ans.: - Traditional design consists of two different activities; first a structured analysis of therequirements specification is carried out where the detailed structure of the problem is examined. This isfollowed by a structured design activity. During structured design, the results of structured analysis aretransformed into the software design.3. Identify at least three activities undertaken in an object-oriented softwaredesign approach.Ans.: - In this technique, various objects that occur in the problem domain and the solution domain arefirst identified, and the different relationships that exist among these objects are identified. The objectstructure is further refined to obtain the detailed design.4. Identify three reasons for the necessity of developing a prototypeduring software development.Ans.: - There are several uses of a prototype. An important purpose is to illustrate the input data formats,messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism forgaining better understanding of the customer’s needs:  how screens might look like  how the user interface would behave  how the system would produce outputsWrite whether true of false. Justify your answer.1. Evolutionary life cycle model is ideally suited for development of very small software productstypically requiring a few months of development effort.Ans.: - False. Page | 15Prepared By Neelamani Samal
  16. 16. Principle & Practices Of Software EngineeringExplanation: - The Evolutionary model is very useful for very large problems where it becomes easier tofind modules for incremental implementation.2. Prototyping life cycle model is the most suitable one for undertaking a software development projectsusceptible to schedule slippage.Ans.: - False.Explanation: - The prototype model is suitable for projects whose user requirements or the underlyingtechnical aspects are not well understood.3. Spiral life cycle model is not suitable for products that are vulnerable to large number of risks.Ans.: - False.Explanation: - The spiral model is suitable for development of technically challenging software productsthat are prone to several kinds of risks. Page | 16Prepared By Neelamani Samal
  17. 17. Principle & Practices Of Software EngineeringModule 2Basic issues in software designObjectivesTo understand the different design approaches and how the entire program is broken down intodifferent modules ,and how they are related to each other. What standards we need to followwhile designing and coding.Lecture 9Software designObjective: • Identify the software design activities. • Identify the primary differences between analysis and design activities • Identify the important items developed during the software design phase. • State the important desirable characteristics of a good software design. Software design deals with transforming the customer requirements, as described in the SRSdocument, into a form (a set of documents) that is suitable for implementation in a programminglanguage. A good software design is seldom arrived by using a single step procedure but rather throughseveral iterations through a series of steps. Design activities can be broadly classified into two importantparts: • Preliminary (or high-level) design and • Detailed design.Difference between analysis and design The aim of analysis is to understand the problem with a view to eliminate any deficiencies in therequirement specification such as incompleteness, inconsistencies, etc. The model which we are trying tobuild may be or may not be ready. The aim of design is to produce a model that will provide a seamless transition to the codingphase, i.e. once the requirements are analyzed and found to be satisfactory, a design model is createdwhich can be easily implemented.Items developed during the software design phase For a design to be easily implemented in a conventional programming language, the followingitems must be designed during the design phase. • Different modules required to implement the design solution. • Control relationship among the identified modules. The relationship is also known as the call relationship or invocation relationship among modules. • Interface among different modules. The interface among different modules identifies the exact data items exchanged among the modules. • Data structures of the individual modules. • Algorithms required to implement each individual module. Page | 17Prepared By Neelamani Samal
  18. 18. Principle & Practices Of Software EngineeringCharacteristics of a good software designThe characteristics are listed below: • Correctness: A good design should correctly implement all the functionalities identified in the SRS document. • Understandability: A good design is easily understandable. • Efficiency: It should be efficient. • Maintainability: It should be easily amenable to change. Page | 18Prepared By Neelamani Samal
  19. 19. Principle & Practices Of Software EngineeringLecture 10Objective  To know the terms associated with software developmentCohesionMost researchers and engineers agree that a good software design implies clean decomposition of theproblem into modules, and the neat arrangement of these modules in a hierarchy. The primarycharacteristics of neat module decomposition are high cohesion and low coupling. Cohesion is a measureof functional strength of a module. A module having high cohesion and low coupling is said to befunctionally independent of other modules. By the term functional independence, we mean that a cohesivemodule performs a single task or function. A functionally independent module has minimal interactionwith other modules.Classification of cohesionThe different classes of cohesion that a module may possess are as followsCoincidental cohesion: A module is said to have coincidental cohesion, if it performs a set of tasks that relate to eachother very loosely, if at all. In this case, the module contains a random collection of functions. It is likelythat the functions have been put in the module out of pure coincidence without any thought or design. Forexample, in a transaction processing system (TPS), the get-input, print-error, and summarize-membersfunctions are grouped into one module. The grouping does not have any relevance to the structure of theproblem.Logical cohesion: A module is said to be logically cohesive, if all elements of the module perform similaroperations, e.g. error handling, data input, data output, etc. An example of logical cohesion is the casewhere a set of print functions generating different output reports are arranged into a single module.Temporal cohesion: When a module contains functions that are related by the fact that all the functions must beexecuted in the same time span, the module is said to exhibit temporal cohesion. The set of functionsresponsible for initialization, start-up, shutdown of some process, etc. exhibit temporal cohesion.Procedural cohesion: A module is said to possess procedural cohesion, if the set of functions of the module are all partof a procedure (algorithm) in which certain sequence of steps have to be carried out for achieving an Page | 19Prepared By Neelamani Samal
  20. 20. Principle & Practices Of Software Engineeringobjective, e.g. the algorithm for decoding a message.Communicational cohesion: A module is said to have communicational cohesion, if all functions of the module refer to orupdate the same data structure, e.g. the set of functions defined on an array or a stack.Sequential cohesion: A module is said to possess sequential cohesion, if the elements of a module form the parts ofsequence, where the output from one element of the sequence is input to the next. For example, in a TPS,the get-input, validate-input, sort-input functions are grouped intoone module.Functional cohesion: Functional cohesion is said to exist, if different elements of a module cooperate to achieve asingle function. For example, a module containing all the functions required to manage employees’ pay-roll exhibits functional cohesion. Suppose a module exhibits functional cohesion and we are asked todescribe what the module does, then we would be able to describe it using a single sentence.Coupling Coupling between two modules is a measure of the degree of interdependence or interactionbetween the two modules. A module having high cohesion and low coupling is said to be functionallyindependent of other modules. If two modules interchange large amounts of data, then they are highlyinterdependent. The degree of coupling between two modules depends on their interface complexity.The interface complexity is basically determined by the number of types of parameters that areinterchanged while invoking the functions of the module.Classification of Coupling Even if there are no techniques to precisely and quantitatively estimate the coupling between twomodules, classification of the different types of coupling will help to quantitatively estimate the degree ofcoupling between two modules. Five types of coupling can occur between any two modules. This isshown belowData coupling: Two modules are data coupled, if they communicate through a parameter. An example is anelementary data item passed as a parameter between two modules, e.g. an integer, a float, a character, etc.This data item should be problem related and not used for the control purpose. Page | 20Prepared By Neelamani Samal
  21. 21. Principle & Practices Of Software EngineeringStamp coupling: Two modules are stamp coupled, if they communicate using a composite data item such as arecord in PASCAL or a structure in C.Control coupling: Control coupling exists between two modules, if data from one module is used to direct theorder of instructions execution in another. An example of control coupling is a flag set in one module andtested in another module.Common coupling: Two modules are common coupled, if they share data through some global data items.Content coupling: Content coupling exists between two modules, if they share code, e.g. a branch from one moduleinto another module. Page | 21Prepared By Neelamani Samal
  22. 22. Principle & Practices Of Software EngineeringLecture 11Objective  To Know different types of design strategyFunction-oriented design The following are the salient features of a typical function-oriented design approach: 1. A system is viewed as something that performs a set of functions. Starting at this high-level view ofthe system, each function is successively refined into more detailed functions. For example, consider afunction create-new-library-member which essentially creates the record for a new member, assigns aunique membership number to him, and prints a bill towards his membership charge. This function mayconsist of the following sub-functions: • assign-membership-number • create-member-record • print-billEach of these sub-functions may be split into more detailed sub functions and so on.2. The system state is centralized and shared among different functions, such as member-recordsis available for reference and updating to several functions such as: • create-new-member • delete-member • update-member-recordObject-oriented design In the object-oriented design approach, the system is viewed as collection of objects (i.e.entities). The state is decentralized among the objects and each object manages its own state information.For example, in a Library Automation Software, each library member may be a separate object with itsown data and functions to operate on these data. In fact, the functions defined for one object cannot referor change data of other objects. Objects have their own internal data which define their state. Similarobjects constitute a class. In other words, each object is a member of some class. Classes may inheritfeatures from super class. Conceptually, objects communicate by message passing.Function-oriented vs. object-oriented design approach The following are some of the important differences between function-orientedand object-oriented design. • Unlike function-oriented design methods, in OOD, the basic abstraction are not real-worldfunctions such as sort, display, track, etc, but real-world entities such as employee, picture, machine,radar system, etc. For example in OOD, an employee pay-roll software is not developed by designingfuntions such as update-employee-record, get-employee-address, etc. but by designing objects such as Page | 22Prepared By Neelamani Samal
  23. 23. Principle & Practices Of Software Engineeringemployees, departments, etc. Grady Booch sums up this difference as “identify verbs if you are afterprocedural design and nouns if you are afterobject-oriented design” • In OOD, state information is not represented in a centralized shared memory but is distributedamong the objects of the system. For example, while developing an employee pay-roll system, theemployee data such as the names of the employees, their code numbers, basic salaries, etc. are usuallyimplemented as global data in a traditional programming system; whereas in an object-oriented systemthese data are distributed among different employee objects of the system. Objects communicate bymessage passing. Therefore, one object may discover the state information of another object byinterrogating it. Of course, somewhere or other the real-world functions must be implemented. In OOD,the functions are usually associated with specific real-world entities (objects); they directly access onlypart of the system state information. Page | 23Prepared By Neelamani Samal
  24. 24. Principle & Practices Of Software EngineeringLecture 12Objectives • Explain what a model is. • Explain how models are useful. • Explain what UML means. • Explain the origin and the acceptance of UML in industry. • Identify different types of views captured by UML diagrams.Model A model captures aspects important for some application while omitting (or abstracting) the rest.A model in the context of software development can be graphical, textual, mathematical, or programcode-based. Models are very useful in documenting the design and analysis results. Models also facilitatethe analysis and design procedures themselves. Graphical models are very popular because they are easyto understand and construct. UML is primarily a graphical modeling tool. However, it often requires textexplanations to accompany the graphical models.Why We Need a Model An important reason behind constructing a model is that it helps manage complexity. Oncemodels of a system have been constructed, these can be used for a variety of purposes duringsoftware development, including the following: • Analysis • Specification • Code generation • Design • Visualize and understand the problem and the working of a system • Testing, etc. It is a good idea to explicitly mention the purpose for which a model has been developed, alongwith the model.Unified Modeling Language (UML) UML, as the name implies, is a modeling language. It may be used to visualize, specify,construct, and document the artifacts of a software system. It provides a set of notations (e.g. rectangles,lines, ellipses, etc.) to create a visual model of the system. Like any other language, UML has its ownsyntax (symbols and sentence formation rules) and semantics (meanings of symbols and sentences). Also,we should clearly understand that UML is not a system design or development methodology, but can beused to document object-oriented and analysis results obtained using some methodology. UML was developed to standardize the large number of object-oriented modeling notations thatexisted and were used extensively in the early 1990s. The principles ones in use were: • Object Management Technology [Rumbaugh 1991] • Booch’s methodology [Booch 1991] • Object-Oriented Software Engineering [Jacobson 1992] • Odell’s methodology [Odell 1992] • Shaler and Mellor methodology [Shaler 1992] Page | 24Prepared By Neelamani Samal
  25. 25. Principle & Practices Of Software EngineeringUML diagrams UML can be used to construct nine different types of diagrams to capture five different views of asystem. Just as a building can be modeled from several views (or perspectives) such as ventilationperspective, electrical perspective, lighting perspective, heating perspective, etc.; the different UMLdiagrams provide different perspectives of the software system to be developed and facilitate acomprehensive understanding of the system. Such models can be refined to get the actual implementationof the system.The UML diagrams can capture the following five views of a system: • User’s view • Structural view • Behavioral view • Implementation view • Environmental view Fig 12.1 Different Types of Diagram and view supported in UMLUser’s view: This view defines the functionalities (facilities) made available by the system to its users. Theusers’ view captures the external users’ view of the system in terms of the functionalities offered by thesystem. The users’ view is a black-box view of the system where the internal structure, the dynamicbehavior of different system components, the implementation etc. are not visible. The users’ view is verydifferent from all other views in the sense that it is a functional model compared to the object model of allother views. The users’ view can be considered as the central view and all other views are expected toconform to this view. This thinking is in fact the crux of any user centric development style. Page | 25Prepared By Neelamani Samal
  26. 26. Principle & Practices Of Software EngineeringStructural view: The structural view defines the kinds of objects (classes) important to the understandingof the working of a system and to its implementation. It also captures the relationships among theclasses (objects). The structural model is also called the static model, since the structure of asystem does not change with time.Behavioral view: The behavioral view captures how objects interact with each other to realize the systembehavior. The system behavior captures the time-dependent (dynamic) behavior of the system.Implementation view: This view captures the important components of the system and their dependencies.Environmental view: This view models how the different components are implemented on different pieces ofhardware.Use Case ModelObjectives • Identify different use cases of a system. • Identify the purpose of use cases. • Represent use cases for a particular system. • Explain the utility of the use case diagram. • Factorize use cases into different component use cases. • Explain the organization of use cases. The use case model for any system consists of a set of “use cases”. Intuitively, use casesrepresent the different ways in which a system can be used by the users. A simple way to find all the usecases of a system is to ask the question: “What the users can do using the system?” Thus for the LibraryInformation System (LIS), the use cases could be: • issue-book • query-book • return-book • create-member • add-book, etcPurpose of use cases The purpose of a use case is to define a piece of coherent behavior without revealing the internalstructure of the system. The use cases do not mention any specific algorithm to be used or the internaldata representation, internal structure of the software, etc. A use case typically represents a sequence ofinteractions between the user and the system. These interactions consist of one mainline sequence. Page | 26Prepared By Neelamani Samal
  27. 27. Principle & Practices Of Software EngineeringHow to represent Use Case Diagram Use cases can be represented by drawing a use case diagram and writing an accompanying textelaborating the drawing. In the use case diagram, each use case is represented by an ellipse with the name of the use casewritten inside the ellipse. All the ellipses (i.e. use cases) of a system are enclosed within a rectanglewhich represents the system boundary. The name of the system being modeled (such as Library Information System) appears inside therectangle. The different users of the system are represented by using the stick person icon. Each stick personicon is normally referred to as an actor. An actor is a role played by a user with respect to the system use.Example : The use case model for the Supermarket Prize Scheme is shown in fig. 12.2.The use casescorrespond to the high-level functional requirements. From the problem description and the contextdiagram, we can identify three use cases: “register-customer”, “register-sales”, and “select-winners”.As a sample, the text description for the use case “register-customer” is shown. Fig 12.2 Example of Supermarket prize Scheme. Page | 27Prepared By Neelamani Samal
  28. 28. Principle & Practices Of Software Engineering Text description U1: register-customer: Using this use case, the customer can register himself by providing the necessary details. Scenario 1: Mainline sequence 1. Customer: select register customer option. 2. System: display prompt to enter name, address, and telephone number. 3. Customer: enter the necessary values. 4. System: display the generated id and the message that the customer has been successfully registered. Scenario 2: at step 4 of mainline sequence 1. System: displays the message that the customer has already registered. Scenario 2: at step 4 of mainline sequence 1. System: displays the message that some input information has not been entered. The system display a prompt to enter the missing value.The description for other use cases is written in a similar fashion. Page | 28Prepared By Neelamani Samal
  29. 29. Principle & Practices Of Software EngineeringLecture 13Class diagramsObjectives : • Explain the features represented by a class diagram. • Explain the relationships among different types of classes by means of association. • Explain the relationships among different types of classes by means of aggregation. • Explain the relationships among different types of classes by means of composition. • Draw interaction diagrams for any given problem. • Explain the tradeoff between inheritance and aggregation/ composition • Bring out a comparison of the three relationships: association, aggregation and composition A class diagram describes the static structure of a system. It shows how a system is structuredrather than how it behaves. The static structure of a system comprises of a number of class diagrams andtheir dependencies. The main constituents of a class diagram are classes and their relationships:generalization, aggregation, association, and various kinds of dependencies.Classes The classes represent entities with common features, i.e. attributes and operations. Classes arerepresented as solid outline rectangles with compartments. Classes have a mandatory name compartmentwhere the name is written centered in boldface. The class name is usually written using mixed caseconvention and begins with an uppercase. The class names are usually chosen to be singular nouns.Classes have optional attributes and operations compartments. A class may appear on several diagrams.Its attributes and operations are suppressed on all but one diagram.Attributes An attribute is a named property of a class. It represents the kind of data that an object mightcontain. Attributes are listed with their names, and may optionally contain specification of their type, aninitial value, and constraints. The type of the attribute is written by appending a colon and the type nameafter the attribute name. Typically, the first letter of a class name is a small letter. An example for anattribute is given. bookName : StringAssociation Associations are needed to enable objects to communicate with each other. An associationdescribes a connection between classes. The association relation between two objects is called objectconnection or link. Links are instances of associations. A link is a physical or conceptual connectionbetween object instances.Aggregation Aggregation is a special type of association where the involved classes represent a whole-partrelationship. The aggregate takes the responsibility of forwarding messages to the appropriate parts. Thus,the aggregate takes the responsibility of delegation and leadership. When an instance of one objectcontains instances of some other objects, then aggregation (or composition) relationship exists betweenthe composite object and the component object. Aggregation is represented by the diamond symbol at thecomposite end of a relationship. Page | 29Prepared By Neelamani Samal
  30. 30. Principle & Practices Of Software EngineeringComposition Composition is a stricter form of aggregation, in which the parts are existence-dependent on thewhole. This means that the life of the parts closely ties to the life of the whole. When the whole is created,the parts are created and when the whole is destroyed, the parts are destroyed.The example of class Diagram is shown Fig 13.1 Fig 13.1 Class Diagram for Student Information systemSequence Diagram : A sequence diagram shows interaction among objects as a two dimensional chart. The chart isread from top to bottom. The objects participating in the interaction are shown at the top of the chart asboxes attached to a vertical dashed line. Inside the box the name of the object is written with a colonseparating it from the name of the class and both the name of the object and the class are underlined. Theobjects appearing at the top signify that the object already existed when the use case execution wasinitiated. The vertical dashed line is called the object’s lifeline. The lifeline indicates the existence of theobject at any particular point of time. The rectangle drawn on the lifetime is called the activation symboland indicates that the object is active as long as the rectangle exists. Each message is indicated as anarrow between the lifeline of two objects. The messages are shown in chronological order from the top tothe bottom. That is, reading the diagram from the top to the bottom would show the sequence in which themessages occur. Each message is labeled with the message name. Some control information can also beincluded.Two types of control information are particularly valuable. • A condition indicates that a message is sent, only if the condition is true. • An iteration marker shows the message is sent many times to multiple receiver objects as would happen when a collection or the elements of an array are being iterated. Page | 30Prepared By Neelamani Samal
  31. 31. Principle & Practices Of Software Engineering The sequence diagram for the book renewal use case for the Library Automation Software isshown in fig. 13.2 the development of the sequence diagram in the development methodology would helpus in determining the responsibilities of the different classes; i.e. what methods should be supported byeach class.Fig 13.2 Sequence Diagram for book renewal use case for the Library Automation Software Page | 31Prepared By Neelamani Samal
  32. 32. Principle & Practices Of Software EngineeringCollaboration Diagram A collaboration diagram shows both structural and behavioral aspects explicitly. This is unlike asequence diagram which shows only the behavioral aspects. The structural aspect of a collaborationdiagram consists of objects and the links existing between them. In this diagram, an object is also called aCollaborator .The behavioral aspect is described by the set of messages exchanged among the differentcollaborators. The link between objects is shown as a solid line and can be used to send messages between twoobjects. The message is shown as a labeled arrow placed near the link. Messages are prefixed withsequence numbers because they are only way to describe the relative sequencing of the messages in thisdiagram. The use of the collaboration diagrams in our development process helps us to determine whichClasses are associated with which other classes.Fig 13.3 Collaboration Diagram for book renew use case Page | 32Prepared By Neelamani Samal
  33. 33. Principle & Practices Of Software EngineeringLecture 14Objectives• Draw activity diagrams & State chat diagram for any given problem.• Compare activity diagrams with state chart diagrams.Activity diagrams The activity diagram is possibly one modeling element which was not present in any of thepredecessors of UML. No such diagrams were present either in the works of Booch, Jacobson, orRumbaugh. The activity diagram focuses on representing activities or chunks of processing which may ormay not correspond to the methods of classes. An activity is a state with an internal action and one ormore outgoing transitions which automatically follow the termination of the internal activity. If anactivity has more than one outgoing transitions, then these must be identified through conditions. An interesting feature of the activity diagrams is the swim lanes.Swim lanes enable you to groupactivities based on who is performing them, e.g. academic department vs. hostel office. Thus swim lanessubdivide activities based on the responsibilities of some components. The activities in a swim lane canbe assigned to some model elements, e.g. classes or some component, etc.Where Activity Diagram Find Use o Activity diagrams are normally employed in business process modeling. o This is carried out during the initial stages of requirements analysis and specification. o Activity diagrams can be very useful to understand complex processing activities involving many components. Fig 14.1 Activity diagram for student admission process in IIT The student admission process in IIT is shown as an activity diagram in fig. 14.1. This shows thepart played by different components of the Institute in the admission procedure. After the fees arereceived at the account section, parallel activities start at the hostel office, hospital, and the Department. Page | 33Prepared By Neelamani Samal
  34. 34. Principle & Practices Of Software EngineeringAfter all these activities complete (this synchronization is represented as a horizontal line), the identitycard can be issued to a student by the Academic section.State chart diagram A state chart diagram is normally used to model how the state of an object changes in its lifetime.State chart diagrams are good at describing how the behavior of an object changes across several use caseexecutions. However, if we are interested in modeling some behavior that involves several objectscollaborating with each other, state chart diagram is not appropriate. State chart diagrams are based on thefinite state machine (FSM) formalism. An FSM consists of a finite number of states corresponding to those of the object being modeled.The object undergoes state changes when specific events occur. The FSM formalism existed long beforethe object-oriented technology and has been used for a wide variety of applications. Apart from modeling,it has even been used in theoretical computer science as a generator for regular languages. A major disadvantage of the FSM formalism is the state explosion problem. The number of statesbecomes too many and the model too complex when used to model practical systems. This problem isovercome in UML by using state charts. A state chart is a hierarchical model of a system and introduces the concept of a composite stateActions are associated with transitions and are considered to be processes that occur quickly and are notinterruptible. Activities are associated with states and can take longer. An activity can be interrupted byan event.The basic elements of the state chart diagram are as follows: • Initial state. This is represented as a filled circle. • Final state. This is represented by a filled circle inside a larger circle. • State. These are represented by rectangles with rounded corners. • Transition. A transition is shown as an arrow between two states.Normally, the name of the event which causes the transition is places alongside the arrow. The transitioncan take place only if the grade evaluates to true. An example state chart for the order object of the TradeHouse Automation software is shown in fig. 14.2. Page | 34Prepared By Neelamani Samal
  35. 35. Principle & Practices Of Software Engineering Fig 14.2 State Chat Diagram of Trade House Automation softwareActivity diagram vs. State chart diagram • Both activity and state chart diagrams model the dynamic behavior of the system. Activitydiagram is essentially a flowchart showing flow of control from activity to activity. A state chart diagramshows a state machine emphasizing the flow of control from state to state. • An activity diagram is a special case of a state chart diagram in which all or most of the statesare activity states and all or most of the transitions are triggered by completion of activities in the sourcestate • Activity diagrams may stand alone to visualize, specify, and document the dynamics of asociety of objects or they may be used to model the flow of control of an operation. State chart diagramsmay be attached to classes, use cases, or entire systems in order to visualize, specify, and document thedynamics of an individual object. Page | 35Prepared By Neelamani Samal
  36. 36. Principle & Practices Of Software EngineeringLecture 15Objectives• Identify the basic difference between object-oriented analysis (OOA) and object-oriented design (OOD).• Explain what are design patterns..• Explain expert pattern and circumstances when it can be used.Difference between object-oriented analysis (OOA) and object-oriented design (OOD). The term object-oriented analysis (OOA) refers to a method of developing an initial model of thesoftware from the requirements specification. The analysis model is refined into a design model. Thedesign model can be implemented using a programming language. The term object-oriented programmingrefers to the implementation of programs using object-oriented concepts. In contrast, object-oriented design (OOD) paradigm suggests that the natural objects (i.e. theentities) occurring in a problem should be identified first and then implemented. Object-oriented design(OOD) techniques not only identify objects but also identify the internal details of these identified objects.Also, the relationships existing among different objects are identified and represented in such a way thatthe objects can be easily implemented using a programming language.Explain what design patterns are. Design patterns are very useful in creating good software design solutions. In addition toproviding the model of a good solution, design patterns include a clear specification of the problem, andalso explain the circumstances in which the solution would and would not work. Thus, a design patternhas four important parts: • The problem. • The context in which the problem occurs. • The solution. • The context within which the solution works.Explain creator pattern and circumstances when it can be used.Creator PatternProblem: Which class should be responsible for creating a new instance of some class?Solution: Assign a class C1 the responsibility to create an instance of class C2, if one or more of thefollowing are true:• C1 is an aggregation of objects of type C2.• C1 contains objects of type C2.• C1 closely uses objects of type C2.• C1 has the data that would be required to initialize the objects of type C2, when they are created. Page | 36Prepared By Neelamani Samal
  37. 37. Principle & Practices Of Software EngineeringDomain ModelingExplain what is meant by domain modeling. Domain modeling is known as conceptual modeling. A domain model is a representation of theconcepts or objects appearing in the problem domain. It also captures the obvious relationships amongthese objects. Examples of such conceptual objects are the Book,BookRegister,MemeberRegister,LibraryMember, etc. The recommended strategy is to quickly create a rough conceptual model where theemphasis is in finding the obvious concepts expressed in the requirements while deferring a detailedinvestigation. Later during the development process, the conceptual model is incrementally refinedand extended.Types of objects identified during domain analysis.The objects identified during domain analysis can be classified into three types:• Boundary objects• Controller objects• Entity objects The boundary and controller objects can be systematically identified from the use case diagramwhereas identification of entity objects requires practice. So, the importance of the domain modelingactivity is to identify the entity models.Purpose of different types of objects identified during domain analysis. The different kinds of objects identified during domain analysis and their relationships are asfollows:  Boundary objects: The boundary objects are those with which the actors interact. These include screens, menus, forms, dialogs, etc. The boundary objects are mainly responsible for user interaction. Therefore, they normally do not include any processing logic. However, they may be responsible for validating inputs, formatting, outputs, etc. The boundary objects were earlier being called as the interface objects. A recommendation for the initial identification of the boundary classes is to define one boundary class per actor/use case pair.  Entity objects: These normally hold information such as data tables and files that need to outlive use case execution, e.g. Book, BookRegister, LibraryMember, etc. Many of the entity objects are “dumb servers”. They are normally responsible for storing data, fetching data, and doing some fundamental kinds of operation that do not change often.  Controller objects: The controller objects coordinate the activities of a set of entity objects and interface with the boundary objects to provide the overall behavior of the system. The responsibilities assigned to a controller object are closely related to the realization of a specific use case. The controller objects effectively decouple the boundary and entity objects from one another making the system tolerant to changes of the user interface and processing logic.Booch’s Object Identification Method Booch’s object identification approach requires a processing narrative of the given problem to befirst developed. The processing narrative describes the problem and discusses how it can be solved. Theobjects are identified by noting down the nouns in the processing narrative. Synonym of a noun must be Page | 37Prepared By Neelamani Samal
  38. 38. Principle & Practices Of Software Engineeringeliminated. If an object is required to implement a solution, then it is said to be part of the solution space.Otherwise, if an object is necessary only to describe the problem, then it is said to be a part of the problemspace. However, several of the nouns may not be objects. An imperative procedure name, i.e., nounform of a verb actually represents an action and should not be considered as an object. A potential objectfound after lexical analysis is usually considered legitimate, only if it satisfies the following criteria: Retained information. Some information about the object should be remembered for the systemto function. If an object does not contain any private data, it can not be expected to play any importantrole in the system. Multiple attributes. Usually objects have multiple attributes and support multiple methods. It isvery rare to find useful objects which store only a single data element or support only a single method,because an object having only a single data element or method is usually implemented as apart of another object. Common operations. A set of operations can be defined for potential objects. If these operationsapply to all occurrences of the object, then a class can be defined. An attribute or operation defined for aclass must apply to each instance of the class. If some of the attributes or operations apply only to somespecific instances of the class, then one or more subclasses can be needed for these special objects. Although the grammatical approach is simple and intuitively appealing, yet through a naive useof the approach, it is very difficult to achieve high quality results. In particular, it is very difficult to comeup with useful abstractions simply by doing grammatical analysis of the problem description. Usefulabstractions usually result from clever factoring of the problem description into independent andintuitively correct elements.Two goals of interaction modeling.The primary goal of interaction modeling are the following: • To allocate the responsibility of a use case realization among the boundary, entity, andcontroller objects. The responsibilities for each class is reflected as an operation to be supported by thatclass. • To show the detailed interaction that occur over time among the objects associated with eachuse case. Page | 38Prepared By Neelamani Samal
  39. 39. Principle & Practices Of Software EngineeringLecture 16Objectives• Identify five desirable characteristics of a user interface.• Differentiate between user guidance and online help system.• Differentiate between a mode-based interface and the modeless interface.• Compare various characteristics of a GUI with those of a text-based user interface.Characteristics of a user interface It is very important to identify the characteristics desired of a good user interface.Because unlesswe are aware of these, it is very much difficult to design a good user interface. A few importantcharacteristics of a good user interface are the following: • Speed of learning. A good user interface should be easy to learn. Speed of learning ishampered by complex syntax and semantics of the command issue procedures. A good user interfaceshould not require its users to memorize commands.ƒ • Speed of use. Speed of use of a user interface is determined by the time and user effortnecessary to initiate and execute different commands. This characteristic of the interface is some timesreferred to as productivity support of the interface. It indicates how fast the users can perform theirintended tasks. The time and user effort necessary to initiate and execute different commands should beminimal. • Speed of recall. Once users learn how to use an interface, the speed with which they canrecall the command issue procedure should be maximized. This characteristic is very important forintermittent users. • Error prevention. A good user interface should minimize the scope of committing errorswhile initiating different commands. The error rate of an interface can be easily determined by monitoringthe errors committed by average users while using the interface. • Attractiveness. A good user interface should be attractive to use. An attractive user interfacecatches user attention and fancy. In this respect, graphics-based user interfaces have a definite advantageover text-based interfaces. • Consistency. The commands supported by a user interface should be consistent. The basicpurpose of consistency is to allow users to generalize the knowledge about aspects of the interface fromone part to another. Thus, consistency facilitates speed of learning, speed of recall, and also helps inreduction of error rate. • Feedback. A good user interface must provide feedback to various user actions. Especially, ifany user request takes more than few seconds to process, the user should be informed about the state ofthe processing of his request • Support for multiple skill levels. A good user interface should support multiple levels ofsophistication of command issue procedure for different categories of users. • Error recovery (undo facility). While issuing commands, even the expert users cancommit errors. Therefore, a good user interface should allow a user to undo a mistake committed by himwhile using the interface. • User guidance and on-line help. Users seek guidance and on-line help when they eitherforget a command or are unaware of some features of the software. Whenever users need guidance orseek help from the system, they should be provided with the appropriate guidance and help. Page | 39Prepared By Neelamani Samal
  40. 40. Principle & Practices Of Software EngineeringGraphical User Interface vs. Text-based User Interface The following comparisons are based on various characteristics of a GUI with those of a text-based user interface. In a GUI multiple windows with different information can simultaneously be displayed on theuser screen. This is perhaps one of the biggest advantages of GUI over text-based interfaces since the userhas the flexibility to simultaneously interact with several related items at any time and can have access todifferent system information displayed in different windows. Iconic information representation and symbolic information manipulation is possible in a GUI.Symbolic information manipulation such as dragging an icon representing a file to a trash can be deletingis intuitively very appealing and the user can instantly remember it. A GUI usually supports command selection using an attractive and user-friendly menu selection system. In a GUI, a pointing device such as a mouse or a light pen can be used for issuing commands.The use of a pointing device increases the efficacy issue procedureWhereas a Text based interface can be implemented even on a cheap alphanumeric display terminal.Types of user interfacesUser interfaces can be classified into the following three categories:• Command language based interfaces• Menu-based interfaces• Direct manipulation interfacesCommand Language-based Interface A command language-based interface – as the name itself suggests, is based on designing acommand language which the user can use to issue the commands. The user is expected to frame theappropriate commands in the language and type them in appropriately whenever required. A simplecommand language-based interface might simply assign unique names to the different commands.However, a more sophisticated command language-based interface may allow users to compose complexcommands by using a set of primitive commands. Such a facility to compose commands dramaticallyreduces the number of command names one would have to remember. Thus, a command language-basedinterface can be made concise requiring minimal typing by the user. Command language-based interfacesallow fast interaction with the computer and simplify the input of complex commands.Menu-based Interface An important advantage of a menu-based interface over a command language-based interface isthat a menu-based interface does not require the users to remember the exact syntax of the commands. Amenu-based interface is based on recognition of the command names, rather than recollection. Further, ina menu-based interface the typing effort is minimal as most interactions are carried out through menuselections using a pointing device. This factor is an important consideration for the occasional user whocannot type fast.Direct Manipulation Interfaces Direct manipulation interfaces present the interface to the user in the form of visual models (i.e.icons or objects). For this reason, direct manipulation interfaces are sometimes called as iconic interface.In this type of interface, the user issues commands by performing actions on the visual representations ofthe objects, e.g. pull an icon representing a file into an icon representing a trash box, for deleting the file.Important advantages of iconic interfaces include the fact that the icons can be recognized by the usersvery easily, and that icons are language-independent. However, direct manipulation interfaces can beconsidered slow for experienced users. Also, it is difficult to give complex commands using a directManipulation interface. Page | 40Prepared By Neelamani Samal
  41. 41. Principle & Practices Of Software EngineeringLecture 17Objectives• Identify the necessity of coding standards.• Differentiate between coding standards and coding guidelines.• State what code review isCoding Good software development organizations normally require their programmers to adhere to somewell-defined and standard style of coding called coding standards. Most software developmentorganizations formulate their own coding standards that suit them most, and require their engineers tofollow these standards rigorously. The purpose of requiring all engineers of an organization to adhere to astandard style of coding is the following: • A coding standard gives a uniform appearance to the codes written by different engineers. • It enhances code understanding. • It encourages good programming practices.A coding standard lists several rules to be followed during coding, such as the way variables are to benamed, the way the code is to be laid out, error return conventions, etc.Coding standards and guidelines Good software development organizations usually develop their own coding standards andguidelines depending on what best suits their organization and the type of products they develop.The following are some representative coding standards.Rules for limiting the use of global:These rules list what types of data can be declared global and whatcannot.Contents of the headers preceding codes for different modules: The information contained in theheaders of different modules should be standard for an organization. The exact format in which the headerinformation is organized in the header can also be specified. The following are some standard headerdata: • Name of the module. • Date on which the module was created. • Author’s name. • Modification history. • Synopsis of the module. • Different functions supported, along with their input/output parameters. • Global variables accessed/modified by the module.Naming conventions for global variables, local variables, and constant identifiers: A possiblenaming convention can be that global variable names always start with a capital letter, local variablenames are made of small letters, and constant names are always capital letters.Error return conventions and exception handling mechanisms: The way error conditions arereported by different functions in a program are handled should be standard within an organization. Forexample, different functions while encountering an error condition should either return a 0 or 1consistently. Page | 41Prepared By Neelamani Samal
  42. 42. Principle & Practices Of Software EngineeringThe following are some representative coding guidelines recommended by many software developmentorganizations.Do not use a coding style that is too clever or too difficult to understand: Code should be easy tounderstand. Many inexperienced engineers actually take pride in writing cryptic and incomprehensiblecode. Clever coding can obscure meaning of the code and hamper understanding. It also makesmaintenance difficult.Avoid obscure side effects: The side effects of a function call include modification of parameterspassed by reference, modification of global variables, and I/O operations. An obscure side effect is onethat is not obvious from a casual examination of the code. Obscure side effects make it difficult tounderstand a piece of code. For example, if a global variable is changed obscurely in a called module orsome file I/O is performed which is difficult to infer from the function’s name and header information, itbecomes difficult for anybody trying to understand the code.Do not use an identifier for multiple purposes: Programmers often use the same identifier to denoteseveral temporary entities. For example, some programmers use a temporary loop variable for computingand a storing the final result. The rationale that is usually given by these programmers for such multipleuses of variables is memory efficiency, e.g. three variables use up three memory locations, whereas thesame variable used in three different ways uses just one memory location. However, there are severalthings wrong with this approach and hence should be avoided. Some of the problems caused by use ofvariables for multiple purposes as follows:• Each variable should be given a descriptive name indicating its purpose. This is not possible if anidentifier is used for multiple purposes. Use of a variable for multiple purposes can lead to confusion andmake it difficult for somebody trying to read and understand the code.• Use of variables for multiple purposes usually makes future enhancements more difficult.The code should be well-documented: As a rule of thumb, there must be at least one comment line onthe average for every three-source line.The length of any function should not exceed 10 source lines: A function that is very lengthy isusually very difficult to understand as it probably carries out many different functions. For the samereason, lengthy functions are likely to have disproportionately larger number of bugs.Do not use goto statements: Use of goto statements makes a program unstructured and makes it verydifficult to understand.Code review Code review for a model is carried out after the module is successfully compiled and the all thesyntax errors have been eliminated. Code reviews are extremely cost-effective strategies for reduction incoding errors and to produce high quality code. Normally, two types of reviews are carried out on thecode of a module. These two types code review techniques are code inspection and code walk through.Code Walk ThroughsCode walk through is an informal code analysis technique. In this technique, after a module has beencoded, successfully compiled and all syntax errors eliminated. A few members of the development teamare given the code few days before the walk through meeting to read and understand code. Each member Page | 42Prepared By Neelamani Samal
  43. 43. Principle & Practices Of Software Engineeringselects some test cases and simulates execution of the code by hand .The main objectives of the walkthrough are to discover the algorithmic and logical errors in the code. The members note down theirfindings to discuss these in a walk through meeting where the coder of the module is present.Code Inspection In contrast to code walk through, the aim of code inspection is to discover some common types oferrors caused due to oversight and improper programming. In other words, during code inspection thecode is examined for the presence of certain kinds of errors, in contrast to the hand simulation of codeexecution done in code walk through. For instance, consider the classical error of writing a procedure thatmodifies a formal parameter while the calling routine calls that procedure with a constant actualparameter. It is more likely that such an error will be discovered by looking for these kinds of mistakes inthe code, rather than by simply hand simulating execution of the procedure. In addition to the commonlymade errors, adherence to coding standards is also checked during code inspection. Good softwaredevelopment companies collect statistics regarding different types of errors commonly committed by theirengineers and identify the type of errors most frequently committed. Such a list of commonly committederrors can be used during code inspection to look out for possible errors.Following is a list of some classical programming errors which can be checked during code inspection:• Use of uninitialized variables.• Jumps into loops.• Nonterminating loops.• Incompatible assignments.• Array indices out of bounds.• Improper storage allocation and DE allocation.• Mismatches between actual and formal parameter in procedure calls.• Use of incorrect logical operators or incorrect precedence among operators.• Improper modification of loop variables.• Comparison of equally of floating point variables, etc. Page | 43Prepared By Neelamani Samal
  44. 44. Principle & Practices Of Software EngineeringLecture 18 1. What are the different ways of documenting program code? Which of these is usually the most useful while understanding a piece of code? 2. What is a coding standard? Identify the problems that might occur if the engineers of an organization do not adhere to any coding standard. 3. What is the difference between coding standards and coding guidelines? Why are these considered as important in a software development organization? 4. Write down five important coding standards. 5. Write down five important coding guidelines.Mark all options which are true.1. The side effects of a function call include □ modification of parameters passed by reference □ modification of global variables □ modification of I/O operations □ all of the above2. Code review for a module is carried out □ as soon as skeletal code written □ before the module is successfully compiled □ after the module is successfully compiled and all the syntax errors have been eliminated □ before the module is successfully compiled and all the syntax errors have been eliminated Page | 44Prepared By Neelamani Samal
  45. 45. Principle & Practices Of Software EngineeringModule 3Objective:To understand how a software product is tested and which standards are followed in the softwareindustry to develop a software product.Lecture 19  Explain what is Testing  And What are The Types of TestingAim of Testing The aim of the testing process is to identify all defects existing in a software product. Howeverfor most practical systems, even after satisfactorily carrying out the testing phase, it is not possible toguarantee that the software is error free. This is because of the fact that the input data domain of mostsoftware products is very large. It is not practical to test the software exhaustively with respect to eachvalue that the input data may assume. Even with this practical limitation of the testing process, theimportance of testing should not be underestimated. It must be remembered that testing does expose manydefects existing in a software product. Thus testing provides a practical way of reducing defects in asystem and increasing the users’ confidence in a developed system.What Exactly is Testing Testing a program consists of providing the program with a set of test inputs (or test cases) andobserving if the program behaves as expected. If the program fails to behave as expected, then theconditions under which failure occurs are noted for later debugging and correction. Some commonly used terms associated with testing are: • Failure: This is a manifestation of an error (or defect or bug). But, the mere presence of an error may not necessarily lead to a failure. • Test case: This is the triplet [I,S,O], where I is the data input to the system, S is the state of the system at which the data is input, and O is the expected output of the system. • Test suite: This is the set of all test cases with which a given software product is to be tested.Approaches to Testing There are essentially two main approaches to systematically designing test cases. They are  Black-box Testing  White-box TestingIn the black-box testing approach, test cases are designed using only the functional specification of thesoftware, i.e. without any knowledge of the internal structure of the software. For this reason, black-boxtesting is known as functional testing. On the other hand, in the white-box testing approach, designing test cases requires thoroughknowledge about the internal structure of software, and therefore the white-box testing is called structuraltesting.Unit testing Unit testing is undertaken after a module has been coded and successfully reviewed. Unit testing(or module testing) is the testing of different units (or modules) of a system in isolation. Page | 45Prepared By Neelamani Samal
  46. 46. Principle & Practices Of Software EngineeringBlack box testing In the black-box testing, test cases are designed from an examination of the input/output valuesonly and no knowledge of design, or code is required. The following are the two main approaches todesigning black box test cases. • Equivalence class portioning • Boundary value analysisEquivalence Class Partitioning In this approach, the domain of input values to a program is partitioned into a set of equivalenceclasses. This partitioning is done such that the behavior of the program is similar for every input databelonging to the same equivalence class. The main idea behind defining the equivalence classes is that testing the code with any one valuebelonging to an equivalence class is as good as testing the software with any other value belonging to thatequivalence class. Equivalence classes for a software can be designed by examining the input data andoutput data. The following are some general guidelines for designing the equivalence classes: 1. If the input data values to a system can be specified by a range of values, then one valid and two invalid equivalence classes should be defined. 2. If the input data assumes values from a set of discrete members of some domain, then oneequivalence class for valid input values and another equivalence class for invalid input values should bedefined.Example : Design the black-box test suite for the following program. The program computes theintersection point of two straight lines and displays the result. It reads two integer pairs (m1, c1) and(m2, c2) defining the two straight lines of the form y=mx + c.The equivalence classes are the following: • Parallel lines (m1=m2, c1≠c2) • Intersecting lines (m1≠m2) • Coincident lines (m1=m2, c1=c2)Now, selecting one representative value from each equivalence class, the test suit (2, 2) (2, 5), (5, 5)(7, 7), (10, 10) (10, 10) are obtained.Boundary Value Analysis A type of programming error frequently occurs at the boundaries of different equivalence classesof inputs. The reason behind such errors might purely be due to psychological factors. Programmers oftenfail to see the special processing required by the input values that lie at the boundary of the differentequivalence classes.Example: For a function that computes the square root of integer values in the range of 0 and 5000, thetest cases must include the following values: {0, -1, 5000, and 5001}. Page | 46Prepared By Neelamani Samal