Essentials of software engineering 4th edition pdf download

Essentials of software engineering 4th edition pdf download

Essentials of Software Engineering 4th Edition PDF,Essentials of Software Engineering 3rd Edition Pdf

WebBook description. Written for the undergraduate, one-term course, Essentials of Software Engineering, Fourth Edition provides students with a systematic engineering WebComprehensive, yet concise, the Fourth Edition includes new information on areas of high interest to computer scientists, including Big Data and developing in the cloud. In-depth WebESSENTIALS OF software engineering FOURTH EDITION Frank Tsui Orlando Karam Barbara Bernal All associated with Kennesaw State University World Headquarters WebThis book was released on with total page pages. Available in PDF, EPUB and Kindle. Book excerpt: Written for the undergraduate, one-term course, Essentials of WebUpdated with new case studies and content, the fully revised Third Edition of Essentials of Software Engineering offers a comprehensive, accessible, and concise introduction to ... read more

This will ensure that you do not introduce two conventions. For example, it is established practice in Java to start class names with uppercase letters and variable names with lowercase letters. If your name has more than one word, use capitalization to signal the word boundaries. This results in names such as FileClass and fileVariable. In C, the convention is to use lowercase almost exclusively and to separate with an underscore. Thus, when we program in C, we follow the C conventions. The choice of words for common operations is also dictated by convention.

For example, printing, displaying, showing, or echoing a variable are some of the terminologies meaning similar actions. Language conventions also provide hints as to default names for variables, preference for shorter or longer names, and other issues. Try to be as consistent as possible in your choice, and follow the conventions for your language. In addition to being consistent in naming, try to make sure names for functions and variables are descriptive. If the names are too cumbersome or if a good name cannot be easily found, that is usually a sign that there may be a problem in the design. Use short names for local references, which are used in a very limited scope such as local variables, private names, and so on.

Make sure that it works. That way if there are any errors, you know that they are in the module you are currently writing. Careful unit testing, with test cases written before or after the unit, will help you gain confidence in using that unit. In most modern programming languages, the standard library will implement many common functions, usually including sorting and collections of data, database access, utilities for web development, networking, and much more. Using the standard libraries will save extra work, make the code more understandable, and usually run faster with fewer errors, because the standard libraries are well debugged and optimized.

Keep in mind that many exercises in introductory programming classes involve solving classic problems and implementing well-known data structures and algorithms. Although they are a valuable learning exercise, that does not mean you should use your own implementations in real life. For our sample programming problem, Java has a sorting routine that is robust and fast. Using it instead of writing your own would save time and effort and produce a better implementation. We will still implement our own for the sake of illustration but will also provide the implementation using the Java sorting routine. Software reviews are one of the most effective methods for reducing defects in software.

Showing your code to other people will help detect not just functionality errors but also inconsistencies and bad naming. This is another habit that does not blend well with school projects. In most such projects, getting help from another student might be considered cheating. Perhaps the code can instead be reviewed after it is handed in. Reviews are good for school assignments as well as for real-world programs. We have a class, called StringSorter, that has four methods: 1 reading the strings from a file, 2 sorting the collection of strings, 3 writing the strings to a file, and 4 combining those three, taking the input and output file names. The different user interfaces will be implemented in separate classes. Given that StringSorter would not know what to do with exceptional conditions, such as errors when reading or writing streams, the exceptions pass through in the appropriate methods, with the user interface classes deciding what to do with them.

We also have a class with all our unit tests, taking advantage of the JUnit framework. Here we discuss JUnit in a very basic way; JUnit is discussed further in Chapter We just need to create a class that inherits from junit. TestCase, which defines public methods whose names start with test. Within each test method, assertEquals can be used to verify whether two values that should be equal are truly equal. We are assuming a certain fundamental background with Java programming, although familiarity with another object-oriented programming language should be enough to understand this section. Although the methods could have been developed in a different order, we present them in the order we developed them, which is Read, then Sort, then Write. This is also the order in which the final program will execute, thus making it easier to test. We import several namespaces, and declare the StringSorter class. The only instance variable is an ArrayList of lines.

ArrayList is a container that can grow dynamically, and supports indexed access to its elements. It roughly corresponds to a vector in other programming languages. It is part of the standard Java collections library and another example of how using the standard library saves time. Notice we are not declaring the variable as private in Figure 1. This provides a decent compromise. Further options will be discussed in Chapter Our first method involves reading lines from a file or stream, as seen in Figure 1. To make the method more general, we take a Reader, which is a class for reading text-based streams. A stream is a generalization of a file. By using a Reader rather than a class explicitly based on Files, we could use this same method for reading from standard input or even from the network.

Also, because we do not know how to deal with exceptions here, we will just let the IOException pass through. import java. add input ; } } Figure 1. We also define a utility method, called make, that creates an ArrayList with three strings—one, two, and three—inserted in that order in Figure 1. We then define our first method, testReadFromStream, in Figure 1. In this method we create an ArrayList and a StringSorter. We open a known file, and make the StringSorter read from it. Given that we know what is in the file, we know what the internal ArrayList in our StringSorter should be. We just assert that it should be equal to that known value. We can run JUnit after setting the classpath and compiling both classes, by typing java junit.

This will present us with a list of classes to choose from. When choosing our TestStringSorter class, we find a user interface like the one shown in Figure 1. Pressing the run button will rerun all tests, showing you how many tests were successful. If any test is unsuccessful, the bar will be red rather than green. Classes are reloaded by default, so you can leave that window open, modify, recompile, and just press run again. After we verify that our test is successful, we can begin the next method—building the sorting functionality. We decided on a simple algorithm: find the largest element in the array, then swap it with the last element, placing the largest element at the end of the array, then repeat with the rest of the array.

We need two supporting functions, one for swapping the two elements in the array and another for finding the index of the largest element. The code for a swap is shown in Figure 1. readFromStream in ; assertEquals l,ss. lines ; } Figure 1. get i1 ; l. set i1, l. get i2 ; l. set i2, tmp ; } Figure 1. Because swap is a generic function that could be reused in many situations, we decided to build it without any knowledge of the StringSorter class. Given that, it makes sense to have it as a static method. Static methods are the closest technique in Java. We get as parameters a List, where List is the generic interface that ArrayList implements, and the indexes of the two elements. The test for this method is shown in the testSwap method of TestStringSorter class in Figure 1. The next method is the one that returns the index of the largest element on the list. Its name is findIdxBiggest, as shown in Figure 1. Idx as an abbreviation of index is ingrained in our minds.

After settling on biggest, we just made sure that we did not use the other two for naming the variables. swap l1,1,2 ; assertEquals l1,l2 ; } Figure 1. glue tokens are also the same as the superglue tokens. The weak and strong cohesion measures are as follows. Now, consider pulling out those instructions that contribute to computing minimum value and focus only on the maximum value. Then the data slice max, with 22 data tokens, becomes the whole set of data tokens. It would also be the set of glue tokens and the set of superglue tokens. Although this example uses actual code, the concept of strong cohesion is well demonstrated. Again, the term software unit may be a module or a class. Assuming that we are successful in designing highly cohesive software units in a system, it is most likely that these units would still need to interact through the process of coupling. The more complicated the interaction is, the 8.

A good example of why degree of interaction and interdependence between two software units. analysis of coupling is important is provided by Gamma, et al. That is, a class or a module that is highly dependent on other modules or classes would be very difficult to understand by itself. Thus it would be difficult to reuse, modify, or fix that module or class without understanding all the dependent modules and classes. Also, if there is an error in a module or class that is highly interdependent and is tightly connected with other modules or classes, then the probability of an error in one affecting the others is greatly increased.

Thus we can see that high coupling is not a desirable design attribute. Several research studies have shown the coupling attribute to be closely associated with factors such as proneness to error, maintainability, and testability of software; see Basili, Briand, and Melo and Wilkie and Kitchenham for more on these relationships. Coupling is defined as an attribute that specifies the interdependence between two software units. The amount or degree of coupling is generally divided into five distinct levels, listed from the worst to the best: „„Content coupling „„Common coupling „„Control coupling „„Stamp coupling „„Data coupling Content coupling is considered the worst coupling and data coupling is considered to be the best coupling.

What is not listed is the ideal situation of no coupling. Of course, not many problems are so simple that the solutions do not require some coupling. The common terminology used to describe heavy interdependence and light interdependence is tight coupling and loose coupling, respectively. Content coupling between two software units is the worst level. In this situation, almost any change to one unit will require a very careful review of the other, which means that the chance of creating an error in the other unit is very high.

The two units would almost have to be considered as a pair for any type of reuse of software component. Two software units are considered to be at the common-coupling level if they both refer to the same global variable. Such a variable may be used for various information exchanges, including controlling the logic of the other unit. It is not uncommon to see common coupling exhibited in large commercial applications where a record in the database may be used as a global variable. Common coupling is much better than content coupling. It still exhibits a fairly tight amount of coupling because of the permeating effects a change to the global variable or the shared database record would have on those that share this variable or record.

The where-used matrix is extensively used by both the integration team and the test team. The data that have been passed contain embedded control information that influences the behavior of the receiving software unit. The implicit semantics codified in the passed information between the sending and receiving modules force us to consider both modules as a pair. This level of coupling binds the two software units in such a manner that a single software unit reuse, separate from the others, is often hindered. Testing is also further complicated in that the number of test cases for interunit dependencies may increase dramatically when the embedded control information is deeply encoded.

In stamp coupling, a software unit passes a group of data to another software unit. Stamp coupling may be viewed as a lesser version of data coupling in that more than necessary data are passed between the two software units. An example would be passing a whole record or a whole data structure rather than only the needed, individual datum. Passing more information certainly increases the difficulty of comprehending what the precise interdependence between the two software units is. The best level of coupling is data coupling, where only the needed data are passed between software units. At the data-coupling level, the interdependence is low and the two software units are considered loosely coupled.

These coupling levels do not include every possible interdependence situation. For example, a plain invocation of another software unit with only a passing of control and not even requiring a return of control is not mentioned. There is also no distinction made between data passed from one software unit to another, which may include the return of data where the returning information would be at a different coupling level. We should view the levels of coupling, like the levels of cohesion, as a guideline for good design. That is, we should strive for simplicity via strong cohesion and loose coupling in our design and coding. Fenton and Melton provided a relatively simple example of measuring coupling between two software units, x and y, as follows: 1. Assign each level of coupling, from data coupling to content coupling, a numerical integer from 1 through 5, respectively.

Evaluate software units x and y by identifying the highest or the tightest level of coupling relationship between the x, y pair and assign it as i. Identify all the coupling relationships between the pair x and y, and assign it as n. For example, x passes y specific data that contain embedded control information that will influence the logic of y. Also x and y share a global variable. In this case, there are two coupling relationships between x and y. Of the two relationships, common coupling is worse, or tighter, than control coupling. So the highest coupling level between x and y is 4, which is common coupling. With this definition, the smaller the values of i and n are, the looser the coupling will be. If all the software units in a system are pairwise analyzed as this, we can get a feel for the overall software system coupling. In fact, Fenton and Melton define the overall global coupling of a system to be the median value of all the pairs.

Thus, if a software system, S, included x1,. Thus, we would want to strive toward a lower C S when designing a software system. Although there are several important concepts in OO, including class, inheritance, encapsulation, and polymorphism, there is really one central theme. That theme involves classes, how these classes are interrelated to each other, and how the classes interact with each other. A class is just a software entity that we want to, once again, keep simple through strong cohesion. The interrelationship and interaction among the classes should be kept simple through loose coupling.

Thus the good, desirable design attributes have not changed. In OO, there are, however, some extensions to the way we would measure these attributes. The desirable attributes of a good OO design may be measured by the six C-K metrics, which were identified by Chidamber and Kemerer : 1. Weighted methods per class WMC Depth of inheritance tree DIT Number of children NOC Coupling between object classes CBO Response for a class RFC Lack of cohesion in methods LCOM Studies by Basili, Briand, and Melo , Li and Henry , and Briand, et al. WMC is a weighted sum of all the methods in a class. SUM is the arithmetic summation function, and wi is the weight assigned to method mi. A simple situation is to just count the number of methods by uniformly assigning 1 as the weight for all the methods.

So a class with n methods will have its WMC equal to n. This metric is similar to counting the lines of code, where we find that the larger the size of the module, the more likely it will be prone to error. Larger classes, particularly those with larger WMCs, are associated with more error-proneness. It seems that the chance of error increases as we engage in inheritance and multiple inheritances. It is interesting to note that in the early days of OO, many organizations ignored inheritance features, designed their own unique classes, and never realized the desired productivity gain from reuse or inheritance. They thought it was simpler to design their own classes and not have to fully understand other, predefined classes. A class placed deep in the inheritance hierarchy was also difficult to even find, let alone fully comprehend. However, the various empirical tests have shown mixed results.

Some have shown large DIT is associated with high defect rates, and others have found results inconclusive. This OO metric has also had mixed empirical results. When the NOC of all the classes are added together, it would seem that a large NOC of the software system could influence the complexity of the system. As of the writing of this text, it is still uncertain how NOC influences the quality of the software. CBO represents the number of object classes to which it is coupled. This is intuitively the same as the traditional coupling concept. Tighter or more coupling among classes where they share some common services or where one inherits methods and variables from other classes certainly introduces complexity, error-proneness, and difficulty of maintenance.

RFC is the set of methods that will be involved in a response to a message to an object of this class. RFC is also related to the notion of coupling. It has been shown that this metric is highly correlated to CBO and WMC. Because both large CBO and large WMC are known to affect defects and complexity of the software system, large RFC is also correlated with high defects. LCOM is a count of the difference between the method pairs that are not similar and those that are similar within a given class. This metric characterizes the lack of cohesion of a class. It requires a bit more explanation and an example: Consider a class with the following characteristics: „„It has m1,.

Let P be the set of all the method pairs that have noncommon instance variables, and let Q be the set of all the method pairs that have common instance variables. Thus we can see that a class with a high LCOM value indicates that there is a high number of disparate methods. Therefore, classes with high LCOM values are less cohesive and may be more complex and difficult to understand. High LCOM value equates with weak cohesion. The I1 and I2 have {a, b} in common. I1 and I3 have nothing in common, and I2 and I3 also have nothing in common. In this case, P, the number of method pairs that are not similar or have nothing in common, is 2. The number of method pairs that are similar or have something in common, Q, is 1.

All of these six C-K design metrics, are related either directly or indirectly to the concepts of cohesion and coupling. These metrics should assist software designers in better understanding the complexity of their designs and help direct them to simplifying their work. As Figure 8. This approach is meant to provide more modular, cohesive, and well-defined interfaces or coupling in the design of a system. Central to 8. AOP is the notion of concerns that cross cut, which means that the methods related to the concerns intersect. It is believed that in OO programming these cross-cutting concerns are spread across the system. AOP would modularize the implementation of these cross-cutting concerns into a cohesive single unit. Kiczales, et al. This guideline limits the span of control of an object by restricting the message-sending structure of methods in a class.

The messaging restriction will reduce the coupling of objects and enhance the cohesion of an object. This is not a measurement but a guideline originating from the experience gained from the design and implementation of the Demeter System, an AOP project at Northeastern University, developed in the s. The Law of Demeter may be stated as follows. Consider the case of a software development vice president who wishes to enforce a design principle across the development organization. Clearly such an approach increases coupling and diffuses cohesion. This vice president has violated the Law of Demeter. In this section we will concentrate on user-interface UI design—the interactions between a human user and the software. Instead of worrying about reducing software defects, we must now worry about reducing human errors.

Although some designers may believe that having a GUI solves many of the user anxiety problems with computing systems, it is still important to understand what it is that makes the interface easier to understand, navigate, and use. What is user-friendliness, and what characterizes a good UI design? The important characteristic here is that the interface has more to do with people rather than software systems. In UI design, consistency is especially important because it contributes to many of the desirable characteristics that a human requires. Imagine a UI that has inconsistent headings or labels, inconsistent help texts, inconsistent messages, inconsistent response times, inconsistent usage of icons, or inconsistent navigation mechanisms.

Imagine an even worse situation where some of the inconsistencies lead to an actual conflict that a user is pressed to resolve; see Nielsen for an additional discussion of UI consistency. One of the main goals for UI design is to ensure that there is a consistent pattern across all the interfaces. These rules and principles all serve as good guidelines for UI design. Shneiderman and Plaisant have identified the following eight rules of interface design: 1. Strive for consistency Enable frequent users to use shortcuts Offer informative feedback Design dialogues to yield closure Offer error prevention and simple error handling Permit easy reversal of actions Support internal locus of control Reduce short-term memory Note that consistency, which we have already discussed, is the first on the list.

The second rule, which involves shortcuts to achieve an end goal, indicates that there may need to be 8. The feedback from the system to the user should be informative and understandable so that the user will know what follow-up action to perform, if any. The user activities should be grouped in such a manner that there is a start and an end; the user should experience a sense of accomplishment at the end of the series of activities. The fifth and sixth rules deal with human fallibility. The system should be designed to prevent the user from making mistakes.

But if an error is made, there needs to be a mechanism that allows the user to reverse or handle the mistake. The seventh rule addresses the human need for control. That is, the users should not be made to respond to the software system. Instead, the system should be made to respond to user-initiated actions. The eighth rule recognizes the limitations of human memory, and that information should be kept simple. Wherever possible, information should be provided to the users in the form of defaults or in the form of preassigned lists of choices. In addition to the preceding rules, there are also various UI guideline standards. Large corporations such as IBM, Microsoft, and Apple have their own UI guidelines.

The International Standards Organization ISO has several standards related to user interfaces, including ISO , which has multiple parts that can be acquired from the ISO website at www. Usability testing became a new task that was introduced into software development. In its early state, the UI design was of low fidelity in that the interfaces were mocked up with paper boards and diagrams. As the technology and tools improved, UI design became high fidelity in that real screens were developed as design prototypes. Some of these prototypes were introduced during the requirements phase. With the high-fidelity UI design, more in-depth evaluation was performed. Users, or subjects, were carefully profiled and chosen for the usability tests. Some of the key factors in analyzing application interfaces included the following: „„Number of subjects who completed the tasks without any help „„Length of time, on the average, required to complete each task „„Average number of times that the help function was evoked „„Number of tasks completed within some predefined time interval „„Places where subjects had to redo a task, and the number of times this needed to be done „„Number of times shortcuts were used These and other types of information were recorded and analyzed.

In the early days of usability testing, this activity was grouped as a type of postsystem testing and was conducted late in the development cycle. As a result of placing usability testing late in the testing cycle, only the most severe problems were fixed. Today, UI evaluation is moved up to the requirements and design phases. Many of the problems are resolved early, and the solutions are integrated into the software product in time for the current product release. The goal is to attain the following: „„Strong cohesion „„Weak coupling A specific example, using techniques from Bieman and Ott , is also shown to clarify the notion of cohesion.

The six C-K metrics for OO design are shown to be also closely tied to the notion of cohesion and coupling: „„Weighted methods per class WMC „„Depth of the inheritance tree DIT „„Number of children NOC „„Coupling between object classes CBO „„Response for a class RFC „„Lack of cohesion in methods LCOM Finally, with the advent of graphical interface and the Internet, the characteristics of good UI design are discussed. UI design should focus on the human rather than on the system side. What are the two general characteristics of a good design that naturally evolve from requirements? What is the cyclomatic complexity of the design flow shown in Figure 8. What are glue tokens and superglue tokens? Which contributes more to cohesion and why? What are the levels of cohesion? What are the levels of coupling?

What are the six C-K metric for OO design? What is a depth of inheritance tree DIT in C-K metrics, and why may a large DIT be bad for design? In contrast to general design, what is of the most interest in UI design? List four of the eight rules of interface design presented by Shneiderman and Plaisant. Discuss the difference between a good design and what we are trying to achieve as a result of a good design. In gauging design, one of the concepts involves fan-in and fan-out. Discuss the concept of fan-in and fan-out in a design. Instead of multiplying fan-in and fan-out, discuss the effect if you change the operator to addition, especially for the situation when the number of fan-in or fan-out values increases. Why do you suppose Card and Glass focused more on the fan-out value rather than on the number of fan-ins?

Define cohesion in your own words. Define coupling in your own words. The notion of an entity relationship ER diagram was evolved into a database design, as discussed in Chapter 7. If various components use the same database table to update records and query records, what type of coupling is involved? Is there any conflict between strong cohesion and weak coupling? Does the cyclomatic measure have anything to do with the concept of cohesion or coupling? Explain how it does or does not. Arisholm, L. Briand, and A. Basili, L. Briand, and W. Bieman and L. Briand, J. Daly, and J. Wüst, J. Daly, and D. Card and R. Glass, Measuring Software Design Quality Upper Saddle River, NJ: Prentice Hall, Chidamber, D. Darcy, and C. Chidamber and C.

Colyer and A. Elrad, R. Filman, and A. Emam, et al. Fenton and A. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software Reading, MA: Addison-Wesley, Halstead, Elements of Software Science New York: Elsevier, Henry and D. Henry and C. Hix and H. Hartson, Developing User Interface: Ensuring Usability Through Product and Process New York: Wiley, Lauesen, User Interface Design: A Software Engineering Perspective Reading, MA: Addison-Wesley, Lethbridge and R. Laganiere, Object-Oriented Software Engineering: Practical Software Development Using UML and Java, 2nd ed. New York: McGraw-Hill, Li and S. Lieberherr and I. Lorenz and J.

Kidd, Object-Oriented Software Metrics: A Practical Guide Upper Saddle River, NJ: Prentice Hall, Mandel, The Elements of User Interface Design New York: Wiley, McCabe and B. Nielsen, Coordinating User Interfaces for Consistency New York, NY: Academic Press, ; reprint by Morgan Kaufman Publishers, com, accessed Offutt, M. Harrold, and P. Shneiderman and C. Plaisant, Designing the User Interface: Strategies for Effective Human-Computer Interaction, 5th ed. Reading, MA: Addison-Wesley, Subramanyam and M. Tsui, O. Karam, S. Duggins, and C. Wilkie and B. Yourdon and L. Constantine, Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design Upper Saddle River, NJ: Prentice Hall, The act of transforming the detailed design into a valid program in some programming language, together with all its supporting activities, is referred to as implementation.

To simplify matters in this chapter, we assume a traditional software engineering life cycle, with an explicit, detailed design being produced. In many cases the detailed design is not done explicitly but is left as part of the implementation. Chapter 7 discussed techniques for software design, and Chapter 8 described how to evaluate good designs. Doing the detailed design as part of the implementation is usually faster, but it may result in a less cohesive and less organized design, because the detailed design of each module will usually be done by a different person. In small projects, the detailed design is usually left as part of the implementation. In larger projects, or when the programmers are inexperienced, the detailed design will be done by a separate person.

Of course, this decision does not have to be the same for all modules. The most important modules may be explicitly designed by the most experienced personnel, with the less important ones left to other programmers. The implementation phase involves more than just writing code. Code also needs to be tested and debugged as well as compiled and built into a complete executable product. We usually need to utilize configuration management in order to keep track of different versions of the code. In this chapter, we cover all aspects of implementation except testing, which is covered in Chapter 10, and building and configuration management, which is covered in Chapter The code can be easily modified and maintained.

Note that this is related to readability, but it is not exactly the same; for example, this involves the use of Hungarian notation, first put forward by Charles Simonyi of Microsoft Simonyi, , in which variable names include abbreviations for the type of variable. Code can be traced back to design and design to requirements. For many software engineers engaged in large, multiple-release software projects, maintainability is as important as correctness or even more important , and performance is of lesser importance in most cases. Readability usually helps maintainability, and both of these usually help achieve correctness. Performance optimizations often reduce readability and maintainability, sometimes even performance. The code changes generated by optimizers can increase program size, which then causes the code to run slower. Another example is when speed is gained from eliminating function calls but is lost to the memory swapping needed. The elimination of the function calls also affects the readability and maintainability of the program.

These guidelines usually specify issues such as naming, indentation, and commenting styles, issues that may be contentious for many programming teams. Notice that there are many tools that will automatically indent and reformat your code, so such issues do not need to be as contentious as might be expected. The most important thing to realize is that most of those issues—especially those dealing more with syntax such as capitalization and indentation guidelines —are not terribly important, and basically are simply a matter of getting accustomed to a particular style. However, we strongly recommend that you be consistent in your notation to avoid confusion when others are debugging or maintaining your code later.

In large software projects, there are usually some programming conventions. These conventions may seem to be of little value at first, but they may become extremely helpful in the build and integration cycle when, for example, all the parts with a prefix of a need to be compiled together, where the a prefix signifies a certain component. A similar scheme is used for issuing error messages. For example, you want to write a message to users that is informative and clear, but along with that you can prefix the message with some identifier that allows the programmers to identify, for debugging purposes, where the message was issued from. Another point usually made in coding guidelines is the recommendation of banning certain language features and practices that have proved, for the organization, error-prone.

For example, many organizations will ban the use of pointers or multiple inheritance in languages that support them, and of course, almost all organizations will require the code to compile without any warnings and without using any deprecated language features. The most important issues for maintaining a good coding style are to be consistent and to try to highlight the meaning of your code. The following recommendations are related to the issues that affect coding style: „„Naming: This refers to choosing names for classes, methods, variables, and other programming entities. Naming is mainly a semantic issue about choosing good names. It is also one of the most important issues in improving readability and maintainability. A well-chosen name that conveys the intent of a module will make the code immediately understandable, while a badly chosen name will necessitate a comment, or even mislead the reader. We and many others have noticed a strong correlation between good names and understanding.

In many cases, if you cannot think of a good name for a module, then you do not understand it well enough. Another key issue with naming is consistency. Always use the same word or abbreviation for a given concept, and avoid using the same word for two different concepts, even in a different context. When choosing among available words for a concept, we recommend that you choose one that is consistent with external standards, following the convention of your particular programming language or platform. Naming may become a more complex issue when dealing with multicultural and multiple language teams. In this case, deciding in advance to take the names from one particular human language is a good idea. In human languages, we use spaces to separate words, but most programming languages will not allow us to do so. Different programming languages have used different conventions for how to combine several words into one identifier.

We strongly recommend using the standard conventions for your language, and making sure you follow it in every case. Java also has some rules about when to start a name with an uppercase or lowercase letter. See the References and Suggested Readings section at the end of this chapter for more resources on this topic. Spacing refers to both spaces and blank lines inserted in the code. As an example, try to understand the following fragment, which is not indented: public static int largest int arr[] { assert arr. And finally look at this version, with correct indentation: public static int largest int arr[] { assert arr. A common indentation style should be defined, and all programmers should follow it. The most important issue here is consistency, because programmers will rapidly grow accustomed to a given indentation style. Many times a de facto indentation standard style for a language exists, usually the one used in the primary language reference.

We strongly suggest using it, as most programmers will be familiar with it. Up to a certain point, actually, very small methods will have more errors on average; see Hatton [] for more details. The size issue has been studied since the s and the days of structured programming by the likes of Harlan Mills and Edsgar Dijkstra see the two articles by Dijkstra in the References and Suggested Readings section. Practical considerations also affect method size; only a certain number of lines can fit in a string or on a printed page, and having the ability to look at the whole method is important in readability and maintainability.

We recommend limiting the size of each method to around 50 lines whenever possible, which can comfortably fit on a screen or a page. You could have a separate document specifying what modules go in which files, but having a file-naming convention can make things much easier. Examples of features considered dangerous are the GOTO keyword and multiple inheritance. As an extreme case, C provides the functions setjmp and longjmp, which allow for a kind of global GOTO; see Dijkstra , a transcription of a letter he wrote to the ACM editor in Most of these constructs were included in languages for a reason, and they have their applications. We recommend that dangerous constructs be banned by default, with the programmers being able to get authorization for particular uses if they can demonstrate that the benefits outweigh the dangers. There are two main problems with comments: 1 they may distract from the actual code and make the program more difficult to read, and 2 they may be wrong.

Comments may become outdated as the code changes, or they may be wrong the first time they are written because they are not executable and cannot be tested. We classify comments into six different types, of which the first five correspond to those defined by McConnell : 1. Repeat of the code: These kinds of comments tend to be done by novice programmers and should be avoided. Misguided coding guidelines often require programmers to create these kinds of comments by mandating a comment block for each function, with a line for each parameter.

For the most part, these comments will only be wasted effort and distract the reader. Explanation of the code: Sometimes, when the code is complex, programmers are 3. tempted to explain what the code does in human language. We strongly believe that in almost every case, if the code is so complex that it requires an explanation, then it should be rewritten. Marker in the code: It is common practice to put markers in the code to indicate incomplete items, opportunities for improvement, and other similar information. We recommend using a consistent notation for these markers, and eliminating all of them before the code is in production. Sometimes programmers put markers in the code to keep track of changes and who made them.

We believe that information is better tracked with version management software, and recommend doing so. Summary of the code: Comments that summarize what the code does, rather than just repeating it, are very helpful in understanding the code, but they need to be kept up to date. It is important to ensure that these comments are really summarizing the code, not just repeating or explaining it. In many cases, the code that is being summarized can be abstracted into its own function, which, if named correctly, will eliminate the need for the comment. Description of the code intent: These are the most useful kinds of comments; they describe what the code is supposed to do rather than what it does. These are the only kinds of comments that override the code. If the code does not fulfill its intent, then the code is wrong.

External references: These are comments that link the code to external entities, usually books or other programs. There may also be external prerequisites and corequisites for the code, such as the existence of initializing data in the database tables. Comments can help clarify code and relate it to other sources, but they also represent some level of duplication of the code. Effort is invested in their creation and, above all, in their maintenance. A comment that does not correspond to the actual code that it accompanies can cause errors that are very hard to find and correct. Another danger comments present is that they can be used to justify bad coding practices. Many times programmers will be tempted to produce code that is too complicated or too hard to maintain, and add comments to it, rather than rewrite it to good standards.

We strongly encourage programmers to use good names and good programming practices and reserve comments mainly for external references and statements of intent. If the code cannot be abstracted and it is still complex, summary comments may be appropriate. Code explanations and markers should only be used as temporary measures, and repetitions of the code should always be avoided. A problem with comments is that most programming books and tutorials, because they are geared for beginners or at least for people who do not know a particular technique or library , tend to provide too many comments, usually repeating or explaining the code. Many programmers will either imitate this style, or go to the other extreme and avoid comments at all costs.

McConnell and Kernighan and Pike provide examples of good commenting practices. The creation of the needed programming is discussed starting with code debugging and four debugging phases. The use of assertions to promote defensive programming is explored along with the implementation activities of planning, building, projecting, tracking, reviewing and updating the code. These activities enable the realization of the system. The implementation practices chosen in this section cover some of the pressing challenges in this important phase and address the needed understanding of processes supporting implementation. The errors are usually discovered through testing, but they can be found by other means, including code inspections and through normal use of the program. We can identify four phases in the debugging process besides discovering the error, which we do not consider part of debugging.

These phases will need to occur in almost every case. Keep in mind that debugging is a highly iterative process, in which you will be creating a hypothesis about what causes the errors, writing test cases to prove or disprove the hypothesis, and changing the code to try to fix the problem. The four phases in the debugging process can be summarized as follows: 1. We do not need to look at the code at all in this phase; we just need to identify which input conditions, combined with which program states, produce the error. The output of the stabilization phase is a series of test cases that produce the error, and possibly some cases that perform correctly. Stabilization also involves minimization of the conditions that led to the error.

After you write a test case that reproduces the error, try to write a simpler one that also fails. Although stabilization is a trivial task in many cases, it can be very difficult sometimes. Many errors will appear to occur at random, and testing the program twice with the same input will sometimes produce different results, depending on the state the program is in. Variables that are not initialized, dangling pointers, and the interaction of several threads tend to produce errors that appear to be random. Localization: The process of localization involves finding the sections of the code that led to the error. This is usually the hardest part, although, if the stabilization phase produces a very simple test case, it may make the problem obvious.

Correction: The process of correction involves changing the code to fix the errors. Hopefully, if you understand what caused the error, you have a good chance of fixing the problem. A common mistake is to try to correct the problem without having really stabilized it or located it within the source code, which leads to random changes that do not fix the code and may introduce new errors. Verification: The process of verification involves making sure the error is fixed, and no other errors were introduced with the changes in the code. Many times, a change in the code will not fix the error or may introduce new errors. Errors in a program can be broadly categorized into syntax and logic errors. Syntax errors in compiled languages tend to be easy to find, as the compiler will detect them and can provide some information about its source. Although compiler error messages are not usually examples of clarity, programmers will quickly learn to use them to find and solve the problem.

Although debugging is a very complicated task, there are several rules of thumb that tell you where to find errors. It is important to realize that many routines will have a high number of errors, either because of complexity, bad design, or problems introduced by their creator. Some indications may be there from the design or code inspections. Routines with more than one error will tend to have even more errors. Newly created code tends to have more errors as it has not been exercised and so tested as much as the old code. You will also need to learn your own heuristics about which parts of your program, language features, or particular programs, are error-prone and in which ways.

The following tools can help with the debugging process: „„Source code comparators that can help you quickly find changes to the code. They can highlight error-prone code and many times find errors before they are detected by 9. The classic example of this kind of tool is lint, used to check C programs. Interactive debuggers can help greatly, but they are commonly misused, especially by beginner programmers, who try to use them as a substitute for understanding the code. A precondition is a condition that your module requires in order to produce correct results. A postcondition is a condition that should hold true after executing your code, if the preconditions were met. It is a good practice to make your preconditions explicit by the use of assertions—that is, statements that check a condition and produce an error if the condition is not met. Most modern programming languages have specific facilities for assertions. By making your assertions explicit and executable, you can catch many errors.

Preconditions and postconditions can also be used with formal methods to prove that a code actually executes correctly. Optimizing for performance usually but not always affects maintainability and readability for the worse. Keep in mind that correctness is obviously more important than performance, and maintainability is as well, because it helps future correctness. The only possible exception to this rule is in real-time systems, in which performing an action within certain time limits is a part of being correct. One of the most common mistakes programmers make is to worry too early about performance. The first goal is to make a program that is correct and easy to maintain.

After the program is finished, if the performance is unsatisfactory, then it is time to worry about it. In many cases, the performance will not be a problem, saving substantial effort. Another common mistake is to optimize all the code for performance, without measuring first. Most pieces of a program will be executed only a few times and will not impact performance significantly. There are only a few pieces of a program that will impact performance and that need to be optimized. A profiler is a tool that runs a program and calculates how much time it spends on each part. It will help you find the performance bottlenecks and the modules that need to be optimized.

Armed with this information, you can then review and optimize only those modules that will have a sizable impact on performance. After making the changes, measure and profile again to make sure the changes actually improve performance. In a few cases, bad performance is a symptom of a bad design or bad coding, and making code simpler and clearer will also result in better performance. A good optimizing compiler can also take care of many performance optimizations without the programmer sacrificing any clarity. As with most other activities, a cost-benefit analysis should be done before undergoing performance optimization. This warning about performance optimization should not be construed as a recommendation to produce bloated code.

Good programming practices and judicious design choices can go a long way in producing code that is correct, maintainable, and fast. One of the best practices is to reuse as much existing high-quality code as possible. Most of the standard data structures and algorithms that can substantially increase performance of an application have already been implemented and are available, in many cases, as part of the standard library included with your language compiler. Know your library and which other high-quality code is available, and use such code rather than reimplement it in new code. You will be learning more about programming, software engineering practices, and about the particular problem you are working on as you go. Programming is, in many ways, similar to writing in a natural language; after all, a program communicates a process to the computer, and, more importantly, to other programmers. In the same way that written documents can be improved and polished after writing them, programs can also be improved for style.

Modelling Software Development Life Cycle 3. Software Requirement Analysis and Specification 4. Software Project Management Framework 5. Software Project Analysis and Design 6. Object-Oriented Analysis and Design 7. Coding and Debugging 9. Software Testing System Implementation and Maintenance Reliability Software Quality CASE and Reuse Recent Trends and Development in Software Engineering Model Questions with Answers. In-depth coverage of key issues, combined with a strong focus on software quality, makes Essentials of Software Engineering, Fourth Edition the perfect text for students entering the fast-growing and lucrative field of software development.

The text includes thorough overviews of programming concepts, system analysis and design, principles of software engineering, development and support processes, methodologies, software testing and quality, and product management, while incorporating real-world examples throughout. Previous page. Publication date. December 19, Print length. See all details. Next page. Frequently bought together. Total price:. To see our price, add these items to your cart. One of these items ships sooner than the other. Show details Hide details. Choose items to buy together. This item: Essentials of Software Engineering. Get it as soon as Wednesday, Dec Essentials of Computer Organization and Architecture. Customers who viewed this item also viewed. Page 1 of 1 Start over Page 1 of 1.

Intro To Java Programming, Comprehensive Version. Daniel Liang. Essentials of Software Engineering. Frank Tsui. Database Processing: Fundamentals, Design, and Implementation 13th Edition. David M. Linda Null. About the Author Professor Tsui has more than 30 years of experience in the Software and IT industry. He is currently a full time faculty member of the School of Computing and Software Engineering at SPSU. He has also been an adjunct faculty at both Georgia Tech and Kennesaw State University. Frank's formal education includes a PhD in computer science from Georgia Tech, MS from Indiana State University and a BS from Purdue.

His experience includes compiler writing for RCA, business applications programming for BlueCross BlueShield, operating system development and software product management with IBM Corp. He is actively involved with the software industry and is especially interested in: Development Processes, Configuration Management, Product and Service Quality, Measurements and Metrics, Testing and Validation. Orlando Karam's experiences are in Agile development and open source environment. He has also developed software for the Yucatan State Government and several companies in Mexico. Orlando holds a PhD in computer science from Tulane University and is a faculty member of Kennesaw State UniversityOrlando. Orlando is also actively involved in the studies of complexities of software. Barbara is a professor of software egnineering at Kennesaw State University. Her expertise is in the area of user interfaces and user centered design. The authors, building off their 25 years of experience, present the complete life cycle of a software system, from inception to release and through support.

The text is broken into six distinct sections, covering programming concepts, system analysis and design, principles of software engineering, development and support processes, methodologies, and product management. Presenting topics emphasized by the IEEE Computer Society sponsored Software Engineering Body of Knowledge SWEBOK and by the Software Engineering Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering, Essentials of Software Engineering is the ideal text for students entering the world of software development. Winner of a Alpha Sigma Nu Book Award, Software Essentials: Design and Construction explicitly defines and illustrates the basic elements of software design and construction, providing a solid understanding of control flow, abstract data types ADTs , memory, type relationships, and dynamic behavior. This text evaluates the benefits and overhead of object-oriented design OOD and analyzes software design options.

About the Cover: Although capacity may be a problem for a doghouse, other requirements are usually minimal. Unlike skyscrapers, doghouses are simple units. They do not require plumbing, electricity, fire alarms, elevators, or ventilation systems, and they do not need to be built to code or pass inspections. The range of complexity in software design is similar. Given available software tools and libraries—many of which are free—hobbyists can build small or short-lived computer apps. Yet, design for software longevity, security, and efficiency can be intricate—as is the design of large-scale systems. How can a software developer prepare to manage such complexity? By understanding the essential building blocks of software design and construction.

Home Engineering Essentials of Software Engineering 4th Edition PDF by admin. Essentials of Software Engineering 4th Edition PDF Download for Free In this post, you will get Essentials of Software Engineering 4th Edition PDF eBook to download for free. This is a must read book for computer lovers and software engineers as it covers many important concepts in depth. Essentials of Software Engineering 4th Edition PDF. Essentials of Software Engineering was born from our experiences in teaching introductory material on software engineering. Although there are many books on this topic available in the market, few serve the purpose of introducing only the core material for a 1-semester course that meets approximately 3 hours a week for 16 weeks. With the proliferation of small web applications, many new information technology personnel have entered the field of software engineering without fully understanding what it entails. This book is intended to serve both new students with limited experience as well as experienced information technology professionals who are contemplating a new career in the software engineering discipline.

The complete life cycle of a software system is covered in this book, from inception to release and through support. The content of this book has also been shaped by our personal experiences and backgrounds one author has more than 25 years in building, supporting, and managing large and complex mission-critical software with companies such as IBM, Blue Cross Blue Shield, MARCAM, and RCA; another author has experience involving extensive expertise in constructing smaller software with Agile methods at companies such as Microsoft and Amazon; and the third author is bilingual and has broad software engineering teaching experiences with both U. college students and non-U. Spanish-speaking students. Although new ideas and technology will continue to emerge and some of the principles introduced in this book may have to be updated, we believe that the underlying and fundamental concepts we present here will remain.

If you can afford the book, please check the prices on Amazon from the above link. The book is currently on a heavy discount. Support the authors and publishers by buying the original work! Note - This book was neither created nor scanned by Internshipslive. We provide the links already available online. If the content causes any problems, please contact us here. Thank you very much! How to download the Essentials of Software Engineering 4th Edition PDF? Simply, tap on the above link of your preferred chapter, all links are provided above and you will be directed to the PDF download page. Verify that you're not a robot and follow the on-screen instructions. Study and revise thoroughly! Most of the college and university students found the book very useful for college examinations and B. Sc, M. Sc, CSIR NET, GATE, TIFR, BARK, JEST, IIT-JEE and related Exams. I hope this eBook, Essentials of Software Engineering 4th Edition PDF helps you in the journey of your exams preparation.

If you have any doubts, please ask in the comments below and do share with your friends. Tags: Engineering international notes. Facebook Twitter. Please do not add external links. Previous Post Next Post. Contact Form. find ". seopro-pro-mobile-menu ul li. hasClass "show"? removeClass "show". addClass "show". children ". scrollTop ;a s? addClass "is-fixed" :a t? removeClass "show" :e. attr "src". match "www.

Essentials Of Software Engineering,Account Options

WebComprehensive, yet concise, the Fourth Edition includes new information on areas of high interest to computer scientists, including Big Data and developing in the cloud. In-depth WebFeb 20,  · In this post, you will get Essentials of Software Engineering 4th Edition PDF eBook to download for free. The book is published by Jones & Bartlett Learning WebJan 14,  · WebEssentials of Software Engineering 4th Edition PDF Download for Free In this post, you will get Essentials of Software Engineering 4th Edition PDF WebESSENTIALS OF software engineering FOURTH EDITION Frank Tsui Orlando Karam Barbara Bernal All associated with Kennesaw State University World Headquarters WebDec 25,  · Updated with new case studies and content, the fully revised Third Edition of Essentials of Software Engineering offers a comprehensive, accessible, and WebUpdated with new case studies and content, the fully revised Third Edition of Essentials of Software Engineering offers a comprehensive, accessible, and concise introduction to ... read more

If your name has more than one word, use capitalization to signal the word boundaries. Smartphones and tablets. Code explanations and markers should only be used as temporary measures, and repetitions of the code should always be avoided. Programming is, in many ways, similar to writing in a natural language; after all, a program communicates a process to the computer, and, more importantly, to other programmers. addClass "is-fixed" :a t?

However, the various empirical tests have shown mixed results. It includes developing, designing, researching, operating and compiling system-level software. You will also need to learn your own heuristics about which parts of your program, language features, or particular programs, are error-prone and in which ways. Syntax errors in compiled languages tend to be easy to find, as the compiler will detect them and can provide some information about its source. Managing Systems and IT Projects.