Software Design Defects Detection and Classification - Literature review Example

? Software Design Defects Detection and ification Year: The software process is typically a translation of information from form to form. That is, from the user needs to functional requirements to structure to design and finally code. This process is predominantly human based and errors are likely to occur when progressing through the forms. Being a process run by humans, it is crucial to manage the software process to ensure success of the project. It follows that, the parameter to measure software success is software quality. This essentially refers to “fitness for use”. On a detailed elucidation of quality, software design defects come into the picture. Quality software not only meets the full user requirements, but is also usable for the purpose it was designed( Du Bois, Verelst and Demeyer 2004). Given the software process as earlier mentioned morphs the information from one form to another, errors are likely to occur in any of the forms (user needs, design, code etc.) of the product. This paper focuses on the design of software and the relation to the overall product. Generally, it ties software quality management to the success of the software process. In a more specific perspective, realised by careful examination of the models and frameworks of the software process, the paper reviews the software design defects are detected. The models reviewed are an indispensable part of software development and as such, it is important to examine how they help “clean up” the software process(Leszak, Perry and Stoll 2002). In addition, the paper classifies the software design defects “shortcomings” that stem from poor design of software. In software development, the writing of a defect free code is one of the major concerns. This concern is cuts across the e software development and object oriented programming community. The main objective of this paper is to analyse the design defects of software design and the classification of these. The major classes are the defects within a particular class, which are inter class and defects across other classes Research Problem Traditionally, the software quality management process was focussed on finding the defects in software and correcting them. This took place in two steps; developing software to completion and checking for defects in the end product. The shortcoming of this approach was that the same defects would still be realised in another software process(Moha and Gueheneuc 2005). It is important to consider the uniqueness, of each piece of software. They are designed as artefacts and meant to serve the user needs adequately. However, the process – individuals, tools, methodology- followed are is the same. This aspect of software development shows that the defects in the process are likely to be repeated. Applying quality management “control” on the software process is being adopted as a guarantee to achieve software quality. Total quality management of the software design aims at continuously improving the quality of the end product( Kessentini, Sahraoui and Boukadoum 2011 ). Managing the software design by controlling the end product at the design stage is a technique to curve out the causes of defects. This technique adopts a set of practices throughout the software process and is aimed at consistently meeting the end user needs. While focussing on the software design defects, it is important to note that poor customer requirements elicitation could contribute to poor design of the software (Moha 2007). The focus here is the practices of software management adopted to counter software defects and detect the defects. Most importantly, the main idea is using established processes to catch the software design defects. From this perspective, we are able to examine how total quality management – continuous management of the process – is effected using the design The development of code for software development is a practice that requires skill and experience, producing a design defect free code that does not have bugs is a hard task. There are many tools that assist the programmer with the development of code. These help in the detection and correction of these defects. To effectively perform maintenance, programmers need to accurately detect defects. The classification of these defects would also help formulate guidelines in correcting and avoiding them. Literature Review A walk-through involves a statement of objectives for the entire process, the software product, and any regulations, standards or guidelines. The process is considered successful when the entire software has been examined, and recommendations have been addressed (Riel 1990). A prominent feature of the walkthrough strategy in design is that it allows the designers to obtain early substantiation of the design decisions related to software. The scope of a walkthrough covers design of the GUI, treatment of content and elements of the software functionality. Walkthroughs are important to both the designer and the customer, in that they provide a way to access and identify whether the design addresses the project’s goal and meets the requirements. An effective walkthrough has to include specific components, in an effort to relay the design specifics to the customer. The developer guides members of the development team and other interested parties in through a segment of the Design. The aim of a walkthrough is to get a valid feedback from the client or peers – other developers. Usually the team comments on standards, errors or violations in the development process(Johnson and Opdyke 1993) Some aspects of walkthroughs pose as potential drawbacks to the process. First, the designer has to prepare for the meeting. This involves coordinating the effort and time of each participant and making sure that their personal work plans are synchronised with the project’s schedule(Beck 1999). Inadequate individual preparation may result into poor review, or misconception of the principles applied in the design. Another aspect of a walkthrough that may make it ineffective is the selection of the right participants. It is important to invite the participants with relevant knowledge background and skills to make the exercise meaningful for all. Inviting the right participants ensures that the walkthrough adds value and quality to the product and not to the participants learning (Berkhin 2002). The improvement of the project quality is of the utmost importance. This assists in increasing team morale and hence it enhances the development process. For a walkthrough to be successful and systematic, at least two members have to be involved. The walk-through leader serves as the author or recorder. A walk-through member should not hold a managerial post over other members. OBJECT ORIENTED DEFECT DETECTION Design defects originate from poor design choices. They degrade quality of the designs; therefore, they present opportunities for quality improvement. The design defects are defined as wrong solutions to regular problems in object-oriented design. Basically they come from UML class diagrams that encompass problems at different levels of complexity. Defects in object oriented applications arise as a result of poor design choices that cause degrading effects on the designs(D?Ambros, Bacchelli and Lanza 2010 ). Various tool and methods have been developed to aid in error detection and correction during software development. However, due to non-specification of design defects, there exist a few appropriate methods for detection. In object oriented designs, defects are defined as wrong solutions to recurring problems. Problems may occur at different levels of design, ranging from the architectural level; anti-patterns, to the low level such as code smells. A good example of a common defect in object oriented applications is “the spaghetti code”, which involves unstructured classes, thus declaring long methods with no parameters(Elamkulam et al. 2007). Defect detection and correction in object oriented programming is done early in software development, to reduce development costs for subsequent steps. Designs that are free from defects are easy to implement. These defect detection procedures may be time and resource consuming. Various approaches have been developed to detect and correct defects in object oriented designs. This method of design detection has some shortcomings where the design defects are not precisely specified. It only provides a systematic method to that can automatically detect and correct the errors. The size of the software applications makes it harder to achieve non defective design using this methodology. In addition, the object oriented method of defect detection is an expensive method to use. This is due to the complexities of software designs hence requiring professionals and experienced designers(Tokuda and Batory 1995). Defect detection and correction in object oriented programming is done early in software development, to reduce development costs for subsequent steps. Designs that are free from defects are easy to implement. These defect detection procedures may be time and resource consuming. Various approaches have been developed to detect and correct defects in object oriented designs. Discussed in this paper is a method by Naouel Moha, called the DECOR method (Beck 1999). DECOR Method DECOR stands for Defect Detection for Correction (Naouel et al 2001). It is applied to specify high level design defects, and determine correction algorithms based on defect specification. This method employs four main stages, from analysis of the defect, to detection and correction of defects: Specification is the first stage in this method. It entails characterisation of all the defects based on their characteristics and effect on the system. Taxonomy is established, describing terminology and classification of design defects related to theoretical descriptions, to avoid misinterpretation. From the specification of the system’s design goals, defects can be detected by comparing the system’s performance to its design goals. A model of the system is created for easy analysis of possible sources of defects. Detection from the specified areas follows. Techniques and algorithms are defined to detect design defects from the system model previously developed. These techniques are based on semantics, structure and metrics of the system. The system metrics define its size, complexity, coupling and cohesion (Nirmal et al 2011). Defects in a system are directly proportional to the magnitude description of the system’s metrics. Metric values are classified into five different levels; very low, low, medium, high and very high. Corrections are done sequentially while testing the system to determine proper system functionality. Improvements on the design are made to precisely with the intention to match the systems performance to the intended goals. After the correction of the detected defects in the design, the software is then validated. Validation involves a series of steps and experiments to evaluate system performance after having corrected the design defects of the system. The previous performance is compared to the current performance and functionality, to determine the effect after error correction. It is essential to specify the design defects in object oriented programming. This acts as a framework for generating detection algorithms of a system. There exist methods developed to generate detection algorithms automatically, based on specifications written using a domain-specific language (Basili 1993). Framework for SOA defect detection and classification This model has been realised from the need for an interdisciplinary and enhanced service modelling approach. The SOA model is an emerging architectural style that is instrumental in creating next-generation applications. In Service Oriented Architecture (SOA) software design, there two key principles for the entire process, pattern and anti-patterns. Patterns are guidance steps and best practices used in the design process. Anti-patterns are common design flaws in the process of coming up with a software product(Arcelli and Christina 2007). Recognizing anti patterns is a fundamental part of software development; it allows the developer to learn from previous mistakes. Specify quality goals. It is important to have a clear set of standards and goals when factoring services, models and other business processes. This should be done according to specified documentation and business events. Static program analysis is a way of data flow and its controls. These are used to generate dependency graphs. The dependency graphs are an important way of evaluating the programs metrics (Card and Glass 1990). Metric computation is a way of evaluating software’s capabilities in terms of size, cohesion or complexity. It is derived from quality goals in the documentation. Metrics in SOA software design involves the evaluation of models and business processes. The detection process involves correct identification of patterns and anti-patterns. This process may be fuzzy or inaccurate, but all possible design flaws can be identified by locating discontinuities in the patterns(Bass, Clements & Kazman 2003). Primitive rules may also suggest the presence of anti-patterns. A more accurate detection process can also be undertaken.Defect identification may seem impractical since one needs to identify each defect from the fuzzy analysis. Defect detection is, therefore, done manually so as to improve on the accuracy. Changes to the software are then suggested and implemented. The SOA defect detection method is not effective since optimal utilization of this choice calls for additional design and development attempts. In addition, it requires infrastructure that escalates the costs. This method is not recommended for the following applications Non distributed application without component integration e.g word processing Short lived applications that may be limited in scope. These are applications that are not intended for full functionality. Applications that require Graphical user interface functionality Besides the listed applications, the SOA technique also calls for intensive monitoring and auditing since the reuse feature shares many features of SOA. Semi-automated approach Model driven engineering requires a specific definition of models. The model definition includes domain-specific languages (DSLs) description in terms of UML profiles and metamodels. There arises a need to relate UML profiles to DSLs by the following ways: Having a specific UML profile that represents domain specific modelling concepts Creating model transformations to convert UML models to DSL models When defined Modelling may be seen as a time consuming and ineffective technique for analysis and testing, but it is also more reliable than fully automated testing tools. The industry enterprise software are complex(Gueheneuc and Naouel 2005).Modelling them together with other testing techniques may be seen as inefficient. Therefore, a balance between automation and manual evaluation is the best way. The semi-automatic approach introduces two aspects of the conversion of models. First, the designer uses a formal and explicit mapping model that is manually built. Second, there is a generator component that has the capability to generate required profiles and transform from the mapping models. This method requires a well-defined model that basically covers all the important areas needed to convert the model to required functionality(Brown et al. 1998) . Design Diagram Conversion In design conversion, designers often ignore the most important aspect of the mapping. It is majorly an automatic process and as such, any errors in design are taken to implementation. The inadequacy of modelling platforms such as Microsoft Visio and Visual Paradigm are potential drawbacks to design conversions (Gamma et al. 1994). This is realised from the dynamic nature of code. For instance, Visual .Net developers continually improve their code structure and semantics. Often, this is achieved with new operating and supporting platform. It becomes highly likely for the design generating software to generate code that is incompatible with the current platform. There are several Meta models in existence that are used to represent design patterns. These models though are not designed to be suitable for defect detection, which is specifically for codes (Munro 2005). They do not support code generation either. This creates the need to find alternative methods of converting these design diagrams to code.The Unified Modelling Language (UML) diagrams are the most commonly used methods of representing systems diagram in a software project. The diagrams represent different aspects of the project and the interaction between the classes (Marinescu 2004). Microsoft Vision as Design Conversion Tool One of the most basic approaches is using specialized software to achieve this. Microsoft Visio has the capability toconvert UML class diagrams to code.These diagrams, after conversion, can then be effectively inspected. This makes it easy to detect design defects. This is one of the most common methods used in Objected Oriented programming like java. The visual studio is another approach to code generation; this suite is mostly used for C and C++ programming languages. The suite has features that let the programmer convert UML diagrams to code. This is achieved through a command known as, Generate Code. The function generates a C# code by default, but other features for different codes are available. The feature gives the programmer freedom to choose which elements will be converted to code. This feature is essential if the programmer only wants to inspect a particulars feature of the code. With these tools, the conversion of diagrams to code can be achieved to facilitate defect detection. This improves the quality of the software developed(Fowler 1999). References Arcelli, F., & Christina, L. (2007). Enhancing Software Evolution through Design Pattern Detection. Software Evolvability 2007 Third International IEEE Workshop on, 7-14. Ieee. Bass, L, Clements, P& Kazman, R 2003, Software Architecture in Practice (2nded), Addison-Wesley, Boston, MA. Beck, K 1999, Extreme Programming Explained: Embrace Change, Addison-Wesley, Boston, MA. Berkhin, P 2002, Survey of Clustering Data Mining Techniques, Accrue Software, San Jose, CA. Brown, et al.(1998). Anti Patterns: Refactoring Software, Architectures, and Projects in Crisis. Card, D.N., & Glass, R.L. (1990).Measuring Software Design Quality, Prentice Hall, New Jersey. D?Ambros, M., Bacchelli, A., & Lanza, M. (2010). On the Impact of Design Flaws on Software Defects. Design, 23-31. Ieee. Retrieved from http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5562941 Du Bois,B., Verelst,J.,&Demeyer,S. (2004). “Refactoring –Improving Coupling and Cohesion ofExisting CodeDesignPatterns,” in Proceedings of the 11th WCRE Conference. Gamma,E., Helm, R., Johnson, R., &Vlissides, J. (1994). DesignPatterns – Elements of Reusable Object-Oriented Software. Gueheneuc, Y.-G., &Naouel Moha. (2005). On the Automatic Detection and Correction of Design Defects. In S. Demeyer, K. Mens, R. Wuyts, & S. Ducasse (Eds.), Proceedings of the 6th ECOOP workshop on ObjectOriented Reengineering WOOR. Springer Verlag. Elamkulam, J., Glazberg, Z., Rabinovitz, I., Kowlali, G., Gupta, S., Kohli, S., Dattathrani, S., et al. (2007). Detecting Design Flaws in UML State Charts for Embedded Software. Hardware and Software Verification and Testing. Fowler, M 1999,Refactoring - Improving the Design of Existing Code,Addison-Wesley, Boston, MA. Johnson , RE and Opdyke, WF 1993,‘Technical report’,Refactoring and aggregation, Department of Computer Science,University of Illinois, vol. 2, pp. 67-70. Kessentini, M., Sahraoui, H., & Boukadoum, M. (2011). Search-Based Design Defects Detection by Example. Design, 4(22), 401-415. Leszak, M., Perry, D. E., & Stoll, D. (2002). Classification and evaluation of defects in a project retrospective. Journal of Systems and Software, 61(3), 173-187. Elsevier. Moha, N. (2007). Decor: a tool for the detection of design defects. Proceedings of the twentysecond IEEEACM, 527-528. ACM. Moha, N., & Gueheneuc, Y. G. (2005). On the automatic detection and correction of software architectural defects in object-oriented designs. In S. Demeyer, K. Mens, R. Wuyts, & S. Ducasse (Eds.), 6th International Workshop on ObjectOriented Reengineering WOOR in conjunction with the 19th European Conference on ObjectOriented Programming ECOOP (pp. 1-7). Citeseer. M. Fowler . (1999), Refactoring – Improving the Design of Existing Code. M. J. Munro. (2005). “Product metrics for automatic identification of “bad smell” design problems in java source-code,” inProceedings of the 11th Metrics symposium. R. Marinescu. (2004). “Detection Strategies: Metrics-Based Rules for Detecting Design Flaws,” in Proceedings of the 20th ICSMConference, 2004. Riel, AJ 1996, Object-Oriented Design Heuristics, Addison-Wesley, Boston, MA. Tokuda, L., & Batory, D. (1995). Automated software evolution via design pattern transformations. Design, (October), 1-13. Citeseer. Read More