This document presents a design for classifying and cataloging software design smells. It begins with background on the importance of design quality and discusses limitations of existing smell catalogs. The proposed approach involves developing a principle-based classification scheme for smells based on four fundamental OO design principles: abstraction, encapsulation, hierarchy, and modularity. Over 500 potential smells were identified and 272 micro-architectural design smells were focused on. Each smell is documented with details like name, description, examples, violated principles, and suggested refactoring. An initial evaluation involved architects using the catalog and providing feedback via questionnaire. The document discusses challenges like comparative evaluation and outlines future work.
This document discusses team structures and dynamics in project management. It describes the typical stages a team goes through in forming and performing its tasks: forming, storming, norming, performing, and adjourning. It also discusses different team roles individuals may take on, such as the chair, plant, sharper, and completer. The document outlines various department structures like functional, project, and matrix formats and different team structures including democratic, chief programmer, and mixed control structures.
Refactoring for Software Design Smells - 1 day Workshop Ganesh Samarthyam
The document discusses various design smells that negatively impact software quality attributes like reusability, changeability, understandability and extensibility. It covers different categories of design smells including abstraction smells, encapsulation smells and modularization smells. Some examples of specific smells discussed are missing abstraction, leaky encapsulation, broken modularization etc. The document emphasizes the importance of addressing design smells through refactoring to improve design quality and reduce technical debt.
The document provides an overview of design patterns, including what they are, why they are used, how to apply them, examples of common patterns, and an example application to expense reporting. Design patterns solve common programming problems by describing core solutions that can be reused in different situations, with the intent of increasing code reuse and flexibility. The document discusses several fundamental design patterns including creational, structural, and behavioral patterns, provides UML diagrams to illustrate the relationships between pattern participants, and gives a detailed example of how patterns could be applied to validate expense reports against business policies.
This document provides an introduction to design patterns, including definitions of what patterns are, why they are used, and common types of patterns. It describes the Observer pattern, which allows objects to notify dependents of state changes, defining a one-to-many relationship between a subject and observer objects so that observers are automatically notified of changes. The Observer pattern establishes a publish-subscribe mechanism between the subject and observer objects.
This document discusses testing off-the-shelf (COTS) components. It defines COTS components as independently developed and reusable parts that are selected from a repository and assembled to build software systems. While COTS components reduce development costs and time, they present challenges to testing due to being treated as black boxes without access to requirements or development processes. The document outlines types of COTS component testing, including black-box testing of inputs/outputs, fault injection to evaluate error handling, operational testing in integrated systems, and interface propagation analysis to observe impacts of faults between components.
This document discusses various design smells related to object-oriented design principles like abstraction, encapsulation, modularization, and hierarchy. It provides examples of smells from OpenJDK code like incomplete abstraction in MutableTreeNode class, missing abstraction by using strings for stack traces before StackTraceElement class, and multifaceted abstraction in DataTruncation class. It also discusses smells like lenient encapsulation in Rectangle class, insufficient modularization in huge Component class, cyclic dependencies, polygonal hierarchies, and complex class hierarchies. The document aims to help readers understand different types of design smells and how to identify and refactor them.
The document discusses important concepts for effective software project management including focusing on people, product, process, and project. It emphasizes that defining project scope and establishing clear objectives at the beginning of a project are critical first steps. Finally, it outlines factors for selecting an appropriate software development process model and adapting it to the specific project.
Resource Allocation In Software Project ManagementSyed Hassan Ali
Resource Allocation In Software Project Management
what is Resource Allocation In Software Project Management
define Resource Allocation In Software Project Management
how to allocate resource in software project management
This document discusses team structures and dynamics in project management. It describes the typical stages a team goes through in forming and performing its tasks: forming, storming, norming, performing, and adjourning. It also discusses different team roles individuals may take on, such as the chair, plant, sharper, and completer. The document outlines various department structures like functional, project, and matrix formats and different team structures including democratic, chief programmer, and mixed control structures.
Refactoring for Software Design Smells - 1 day Workshop Ganesh Samarthyam
The document discusses various design smells that negatively impact software quality attributes like reusability, changeability, understandability and extensibility. It covers different categories of design smells including abstraction smells, encapsulation smells and modularization smells. Some examples of specific smells discussed are missing abstraction, leaky encapsulation, broken modularization etc. The document emphasizes the importance of addressing design smells through refactoring to improve design quality and reduce technical debt.
The document provides an overview of design patterns, including what they are, why they are used, how to apply them, examples of common patterns, and an example application to expense reporting. Design patterns solve common programming problems by describing core solutions that can be reused in different situations, with the intent of increasing code reuse and flexibility. The document discusses several fundamental design patterns including creational, structural, and behavioral patterns, provides UML diagrams to illustrate the relationships between pattern participants, and gives a detailed example of how patterns could be applied to validate expense reports against business policies.
This document provides an introduction to design patterns, including definitions of what patterns are, why they are used, and common types of patterns. It describes the Observer pattern, which allows objects to notify dependents of state changes, defining a one-to-many relationship between a subject and observer objects so that observers are automatically notified of changes. The Observer pattern establishes a publish-subscribe mechanism between the subject and observer objects.
This document discusses testing off-the-shelf (COTS) components. It defines COTS components as independently developed and reusable parts that are selected from a repository and assembled to build software systems. While COTS components reduce development costs and time, they present challenges to testing due to being treated as black boxes without access to requirements or development processes. The document outlines types of COTS component testing, including black-box testing of inputs/outputs, fault injection to evaluate error handling, operational testing in integrated systems, and interface propagation analysis to observe impacts of faults between components.
This document discusses various design smells related to object-oriented design principles like abstraction, encapsulation, modularization, and hierarchy. It provides examples of smells from OpenJDK code like incomplete abstraction in MutableTreeNode class, missing abstraction by using strings for stack traces before StackTraceElement class, and multifaceted abstraction in DataTruncation class. It also discusses smells like lenient encapsulation in Rectangle class, insufficient modularization in huge Component class, cyclic dependencies, polygonal hierarchies, and complex class hierarchies. The document aims to help readers understand different types of design smells and how to identify and refactor them.
The document discusses important concepts for effective software project management including focusing on people, product, process, and project. It emphasizes that defining project scope and establishing clear objectives at the beginning of a project are critical first steps. Finally, it outlines factors for selecting an appropriate software development process model and adapting it to the specific project.
Resource Allocation In Software Project ManagementSyed Hassan Ali
Resource Allocation In Software Project Management
what is Resource Allocation In Software Project Management
define Resource Allocation In Software Project Management
how to allocate resource in software project management
This document discusses different types of design rules for interaction design including principles, standards, and guidelines. Principles for usability include learnability, flexibility, and robustness. Standards have high authority but limited application, while guidelines have lower authority but more general application. Common standards and guidelines like Nielsen's heuristics and Shneiderman's Golden Rules are presented. Design patterns capture reusable design knowledge, originating from architecture.
The document discusses software requirements and requirements engineering. It introduces concepts like user requirements, system requirements, functional requirements, and non-functional requirements. It explains how requirements can be organized in a requirements document and the different types of stakeholders who read requirements. The document also discusses challenges in writing requirements precisely and provides examples of requirements specification for a library system called LIBSYS.
This document discusses various techniques for evaluating projects, including:
- Strategic assessment to evaluate how projects align with organizational goals and strategies.
- Technical assessment to evaluate functionality against available hardware, software, and solutions.
- Cost-benefit analysis to compare expected project costs and benefits in monetary terms over time.
- Cash flow forecasting to estimate costs and benefits over the project lifecycle.
- Risk evaluation to assess potential risks and their impacts.
Project evaluation is important for determining progress, outcomes, effectiveness, and justification of project inputs and results. The challenges include commitment, establishing baselines, identifying indicators, and allocating time for monitoring and evaluation.
The document discusses architectural design for software systems. It covers topics such as software architecture, data design, architectural styles, analyzing architectural alternatives, and mapping requirements to architectural designs. The key aspects are:
1) Architectural design represents the structure of data and program components to build a computer system. It begins with data design and derives architectural representations.
2) Software architecture allows analysis of design effectiveness and consideration of alternatives to reduce risks.
3) Common architectural styles include data-centered, data flow, call-and-return, object-oriented, and layered styles.
4) Requirements are mapped to architectural designs through techniques like transform mapping and transaction mapping. The resulting design is then refined.
The document discusses the structure of file systems. It explains that a file system provides mechanisms for storing and accessing files and data. It uses a layered approach, with each layer responsible for specific tasks related to file management. The logical file system contains metadata and verifies permissions and paths. It maps logical file blocks to physical disk blocks using a file organization module, which also manages free space. The basic file system then issues I/O commands to access those physical blocks via device drivers, with I/O controls handling interrupts.
This document discusses human-computer interaction (HCI) and usability engineering. It covers HCI in the software development process, including design rules, evaluation techniques, and universal design. Specific topics covered include the software life cycle, usability engineering, iterative design and prototyping, design rationale, and evaluation methods. Prototyping techniques like storyboards and simulations are also discussed. The goal of the document is to provide an overview of how usability and user experience is incorporated into the software engineering process.
PHP is a server-side scripting language used for web development. It allows developers to add dynamic content and functionality to websites. Some key points about PHP from the document:
- PHP code is embedded into HTML and executed on the server to create dynamic web page content. It can be used to connect to databases, process forms, and more.
- PHP has many data types including strings, integers, floats, booleans, arrays, objects, null values and resources. Variables, operators, and conditional statements allow for control flow and data manipulation.
- Common PHP structures include if/else statements for conditional logic, loops like for/while/foreach for iteration, and functions for reusability. Ar
The document discusses various string handling, mathematical, and random number generation functions available in C++ library. It provides examples of functions like strlen(), strcpy(), strcmp(), sqrt(), pow(), randomize(), random(). It also provides programs to demonstrate the use of these functions for tasks like checking palindromes, searching strings, toggling case, generating random numbers in a given range.
This document discusses swap space in Linux systems. It explains that swap space uses disk space as virtual memory to hold process images when physical RAM is full. Swap space can be located in a separate disk partition or within the normal file system. Linux uses a swap map data structure to track which pages are stored in swap space. The goal of swap space is to make RAM usage more efficient and prevent the system from slowing down or crashing when physical memory is exhausted.
This document outlines various artifact sets produced during the software engineering process, including requirement, design, implementation, deployment, test, and management artifacts. It discusses the artifacts in each set and how they evolve over the software lifecycle. The key artifact sets are the requirement set containing the engineering context, the design set representing different abstraction levels, the implementation set with source code, and the deployment set for delivering the software to users. Test artifacts must also be developed concurrently and documented similarly. Management artifacts include documents for planning, tracking status and releases, and defining the development environment.
This lecture discusses the different techniques used to install, uninstall and upgrade software packages in Linux and the associated tools
Video for this lecture on youtube:
http://www.youtube.com/watch?v=pFqdupd9wKk
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
Ahmed ElArabawy
- https://www.linkedin.com/in/ahmedelarabawy
This document discusses superscalar and super pipeline approaches to improving processor performance. Superscalar processors execute multiple independent instructions in parallel using multiple pipelines. Super pipelines break pipeline stages into smaller stages to reduce clock period and increase instruction throughput. While superscalar utilizes multiple parallel pipelines, super pipelines perform multiple stages per clock cycle in each pipeline. Super pipelines benefit from higher parallelism but also increase potential stalls from dependencies. Both approaches aim to maximize parallel instruction execution but face limitations from true data and other dependencies.
This document discusses multiprocessor and multicomputer systems. It defines multiprocessors as computer systems with multiple CPUs that share resources like memory, clock and I/O devices. Multiprocessor operating systems can be symmetric, with equal access for all CPUs, or master-slave with one CPU controlling others. Shared memory multiprocessors allow CPUs to access a common RAM while message passing multicomputers do not share memory between CPUs. Multiprocessor systems provide benefits like reliability, enhanced throughput and lower costs but require more complex operating systems and larger memory. Multicomputers are made up of separate computers while multiprocessors have multiple CPUs on a single motherboard sharing resources.
This document discusses team structure and development. It describes what a team is and different types of teams. It outlines the stages of team development from forming to adjourning. It also discusses effective team communication styles, building agreement within a team, and successful team meetings and presentations. The key aspects covered are forming, storming, norming, and performing as the stages of team development, as well as the importance of understanding goals, roles, and having cohesion within effective teams.
The document discusses software process models for different project scenarios:
1. For building a larger, more complex application similar to previous projects where requirements are documented, the prototype model would be used to develop the application in increments and allow additions as needed.
2. For integrating departments within a university onto one system to accommodate all processes, the component model would be chosen to reuse existing components, modify requirements, and design the system to incorporate components while developing new software as needed to meet the timeline.
3. For developing the next version of word processing software with tight deadlines, the RAD (Rapid Application Development) model would be selected to allow parallel team work on components to meet the schedule.
4.
Maintenance involves keeping software or assets in working condition. There are four main types of maintenance: corrective, adaptive, preventive, and perfective. Maintenance is needed to fix problems, adapt to new environments, prevent issues, and improve performance. While necessary, maintenance is costly due to the work required to modify existing software. Efforts like designing for change and documentation can help reduce these costs. Overall, maintenance plays a critical role in maximizing the usefulness of software over its lifetime.
Virtual memory allows a program to use more memory than the physical RAM installed on a computer. It works by storing portions of programs and data that are not actively being used on the hard disk, freeing up RAM for active portions. This gives the illusion to the user and programs that they have access to more memory than is physically present. Virtual memory provides advantages like allowing more programs to run at once and not requiring additional RAM purchases, but can reduce performance due to the need to access the hard disk.
Towards a Principle-based Classification of Structural Design SmellsTushar Sharma
This is our paper published in JOT (Journal of Object Technology) based on our initial work. In this paper, we present our (early) catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.
Refactoring guided by design principles driven by technical debtGanesh Samarthyam
Refactoring has come a long way from Opdyke’s thesis way back in 1992 which described refactoring as “behavior preserving transformations”. Today, software developers use refactoring as a weapon against increasing complexity within their software system. There are various books, tools, and other resources available to aid the developers. Popular IDEs such as Eclipse, Visual Studio, and IntelliJ IDEA support automated refactoring. So, why another book on refactoring? Let us understand it by taking a deeper look at the concept.
This document discusses different types of design rules for interaction design including principles, standards, and guidelines. Principles for usability include learnability, flexibility, and robustness. Standards have high authority but limited application, while guidelines have lower authority but more general application. Common standards and guidelines like Nielsen's heuristics and Shneiderman's Golden Rules are presented. Design patterns capture reusable design knowledge, originating from architecture.
The document discusses software requirements and requirements engineering. It introduces concepts like user requirements, system requirements, functional requirements, and non-functional requirements. It explains how requirements can be organized in a requirements document and the different types of stakeholders who read requirements. The document also discusses challenges in writing requirements precisely and provides examples of requirements specification for a library system called LIBSYS.
This document discusses various techniques for evaluating projects, including:
- Strategic assessment to evaluate how projects align with organizational goals and strategies.
- Technical assessment to evaluate functionality against available hardware, software, and solutions.
- Cost-benefit analysis to compare expected project costs and benefits in monetary terms over time.
- Cash flow forecasting to estimate costs and benefits over the project lifecycle.
- Risk evaluation to assess potential risks and their impacts.
Project evaluation is important for determining progress, outcomes, effectiveness, and justification of project inputs and results. The challenges include commitment, establishing baselines, identifying indicators, and allocating time for monitoring and evaluation.
The document discusses architectural design for software systems. It covers topics such as software architecture, data design, architectural styles, analyzing architectural alternatives, and mapping requirements to architectural designs. The key aspects are:
1) Architectural design represents the structure of data and program components to build a computer system. It begins with data design and derives architectural representations.
2) Software architecture allows analysis of design effectiveness and consideration of alternatives to reduce risks.
3) Common architectural styles include data-centered, data flow, call-and-return, object-oriented, and layered styles.
4) Requirements are mapped to architectural designs through techniques like transform mapping and transaction mapping. The resulting design is then refined.
The document discusses the structure of file systems. It explains that a file system provides mechanisms for storing and accessing files and data. It uses a layered approach, with each layer responsible for specific tasks related to file management. The logical file system contains metadata and verifies permissions and paths. It maps logical file blocks to physical disk blocks using a file organization module, which also manages free space. The basic file system then issues I/O commands to access those physical blocks via device drivers, with I/O controls handling interrupts.
This document discusses human-computer interaction (HCI) and usability engineering. It covers HCI in the software development process, including design rules, evaluation techniques, and universal design. Specific topics covered include the software life cycle, usability engineering, iterative design and prototyping, design rationale, and evaluation methods. Prototyping techniques like storyboards and simulations are also discussed. The goal of the document is to provide an overview of how usability and user experience is incorporated into the software engineering process.
PHP is a server-side scripting language used for web development. It allows developers to add dynamic content and functionality to websites. Some key points about PHP from the document:
- PHP code is embedded into HTML and executed on the server to create dynamic web page content. It can be used to connect to databases, process forms, and more.
- PHP has many data types including strings, integers, floats, booleans, arrays, objects, null values and resources. Variables, operators, and conditional statements allow for control flow and data manipulation.
- Common PHP structures include if/else statements for conditional logic, loops like for/while/foreach for iteration, and functions for reusability. Ar
The document discusses various string handling, mathematical, and random number generation functions available in C++ library. It provides examples of functions like strlen(), strcpy(), strcmp(), sqrt(), pow(), randomize(), random(). It also provides programs to demonstrate the use of these functions for tasks like checking palindromes, searching strings, toggling case, generating random numbers in a given range.
This document discusses swap space in Linux systems. It explains that swap space uses disk space as virtual memory to hold process images when physical RAM is full. Swap space can be located in a separate disk partition or within the normal file system. Linux uses a swap map data structure to track which pages are stored in swap space. The goal of swap space is to make RAM usage more efficient and prevent the system from slowing down or crashing when physical memory is exhausted.
This document outlines various artifact sets produced during the software engineering process, including requirement, design, implementation, deployment, test, and management artifacts. It discusses the artifacts in each set and how they evolve over the software lifecycle. The key artifact sets are the requirement set containing the engineering context, the design set representing different abstraction levels, the implementation set with source code, and the deployment set for delivering the software to users. Test artifacts must also be developed concurrently and documented similarly. Management artifacts include documents for planning, tracking status and releases, and defining the development environment.
This lecture discusses the different techniques used to install, uninstall and upgrade software packages in Linux and the associated tools
Video for this lecture on youtube:
http://www.youtube.com/watch?v=pFqdupd9wKk
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
Ahmed ElArabawy
- https://www.linkedin.com/in/ahmedelarabawy
This document discusses superscalar and super pipeline approaches to improving processor performance. Superscalar processors execute multiple independent instructions in parallel using multiple pipelines. Super pipelines break pipeline stages into smaller stages to reduce clock period and increase instruction throughput. While superscalar utilizes multiple parallel pipelines, super pipelines perform multiple stages per clock cycle in each pipeline. Super pipelines benefit from higher parallelism but also increase potential stalls from dependencies. Both approaches aim to maximize parallel instruction execution but face limitations from true data and other dependencies.
This document discusses multiprocessor and multicomputer systems. It defines multiprocessors as computer systems with multiple CPUs that share resources like memory, clock and I/O devices. Multiprocessor operating systems can be symmetric, with equal access for all CPUs, or master-slave with one CPU controlling others. Shared memory multiprocessors allow CPUs to access a common RAM while message passing multicomputers do not share memory between CPUs. Multiprocessor systems provide benefits like reliability, enhanced throughput and lower costs but require more complex operating systems and larger memory. Multicomputers are made up of separate computers while multiprocessors have multiple CPUs on a single motherboard sharing resources.
This document discusses team structure and development. It describes what a team is and different types of teams. It outlines the stages of team development from forming to adjourning. It also discusses effective team communication styles, building agreement within a team, and successful team meetings and presentations. The key aspects covered are forming, storming, norming, and performing as the stages of team development, as well as the importance of understanding goals, roles, and having cohesion within effective teams.
The document discusses software process models for different project scenarios:
1. For building a larger, more complex application similar to previous projects where requirements are documented, the prototype model would be used to develop the application in increments and allow additions as needed.
2. For integrating departments within a university onto one system to accommodate all processes, the component model would be chosen to reuse existing components, modify requirements, and design the system to incorporate components while developing new software as needed to meet the timeline.
3. For developing the next version of word processing software with tight deadlines, the RAD (Rapid Application Development) model would be selected to allow parallel team work on components to meet the schedule.
4.
Maintenance involves keeping software or assets in working condition. There are four main types of maintenance: corrective, adaptive, preventive, and perfective. Maintenance is needed to fix problems, adapt to new environments, prevent issues, and improve performance. While necessary, maintenance is costly due to the work required to modify existing software. Efforts like designing for change and documentation can help reduce these costs. Overall, maintenance plays a critical role in maximizing the usefulness of software over its lifetime.
Virtual memory allows a program to use more memory than the physical RAM installed on a computer. It works by storing portions of programs and data that are not actively being used on the hard disk, freeing up RAM for active portions. This gives the illusion to the user and programs that they have access to more memory than is physically present. Virtual memory provides advantages like allowing more programs to run at once and not requiring additional RAM purchases, but can reduce performance due to the need to access the hard disk.
Towards a Principle-based Classification of Structural Design SmellsTushar Sharma
This is our paper published in JOT (Journal of Object Technology) based on our initial work. In this paper, we present our (early) catalog, classification, and naming scheme for design smells and also highlight several interesting observations and insights that result from our work.
Refactoring guided by design principles driven by technical debtGanesh Samarthyam
Refactoring has come a long way from Opdyke’s thesis way back in 1992 which described refactoring as “behavior preserving transformations”. Today, software developers use refactoring as a weapon against increasing complexity within their software system. There are various books, tools, and other resources available to aid the developers. Popular IDEs such as Eclipse, Visual Studio, and IntelliJ IDEA support automated refactoring. So, why another book on refactoring? Let us understand it by taking a deeper look at the concept.
A Study on Code Smell Detection with Refactoring Tools in Object Oriented Lan...ijcnes
A code smell is an indication in the source code that hypothetically indicates a design problem in the equivalent software. The Code smells are certain code lines which makes problems in source code. It also means that code lines are bad design shape or any code made by bad coding practices. Code smells are structural characteristics of software that may indicates a code or drawing problem that makes software hard to evolve and maintain, and may trigger refactoring of code. In this paper, we proposed some success issues for smell detection tools which can assistance to develop the user experience and therefore the acceptance of such tools. The process of detecting and removing code smells with refactoring can be overwhelming.
Refactoring for Design Smells - ICSE 2014 TutorialTushar Sharma
This document discusses design smells in software and their impact on quality. It begins with an introduction to design quality, technical debt, and design smells. It then provides a catalog of various design smells organized by principles of abstraction, encapsulation, modularization, and hierarchy. For each smell, it provides examples from code and discusses corresponding refactoring techniques. It also discusses how smells are interrelated and how understanding their ecosystem is important for improving design quality in practice. The key takeaways are repaying technical debt through refactoring design smells to improve changeability, understandability and other quality attributes.
This document surveys the current state of research on software smells. It discusses five key aspects: (1) definitions of software smells, (2) causes of smells, (3) impacts of smells, (4) detection methods for smells, and (5) open challenges. The survey is based on a systematic review of over 400 primary studies published between 1999-2016. The results provide a consolidated overview of the research on software smells to date and identify opportunities for future work.
Refactoring for software design smells - icse 2014 tutorialGanesh Samarthyam
This document discusses design quality and technical debt in software engineering. It introduces the concept of "design smells", which are certain structures in code that suggest the need for refactoring to improve design quality. The document outlines various principles of good software design, such as abstraction, encapsulation, modularization and hierarchy. It then presents examples of different categories of design smells that violate these principles, such as incomplete abstraction, leaky encapsulation, insufficient modularization, and broken hierarchy. The document explains how identifying such smells can help improve code quality, and provides approaches for refactoring code to address various design smells.
This document discusses how to write effective abstracts for technical papers and other documents. It provides examples of good abstracts, including one for a paper on classifying design smells based on principles and another for a paper on a method called MIDAS for assessing software design quality. The examples show how to structure an abstract by addressing the problem/gap being addressed, the contribution, evidence that the approach works, and what the paper covers. Guidelines are also given for writing catchy titles that reflect the content.
How to Write Abstracts (for White Papers, Research Papers, ...)Ganesh Samarthyam
Recently I presented to software developers / techies on writing papers and abstract in an IT company. I though this might be useful for other techies & geeks so making it publicly available.
DETECTION AND REFACTORING OF BAD SMELL CAUSED BY LARGE SCALEijseajournal
Bad smells are signs of potential problems in code. Detecting bad smells, however, remains time
consuming for software engineers despite proposals on bad smell detection and refactoring tools. Large
Class is a kind of bad smells caused by large scale, and the detection is hard to achieve automatically. In
this paper, a Large Class bad smell detection approach based on class length distribution model and
cohesion metrics is proposed. In programs, the lengths of classes are confirmed according to the certain
distributions. The class length distribution model is generalized to detect programs after grouping.
Meanwhile, cohesion metrics are analyzed for bad smell detection. The bad smell detection experiments of
open source programs show that Large Class bad smell can be detected effectively and accurately with this
approach, and refactoring scheme can be proposed for design quality improvements of programs.
The document discusses detecting and removing bad code smells from source code. It describes a tool called HIST that uses change history information to detect code smells. The tool extracts change history from version control logs, analyzes the code changes, and uses the information to detect five types of code smells: divergent change, shotgun surgery, parallel inheritance, blob, and feature envy. An evaluation of HIST shows it improves on static code analysis techniques in detecting these code smells, with F-measure scores for detection ranging from 64-92% compared to 0-48% for static analysis alone. The document concludes by discussing some of the researcher's ongoing and future work related to code smells and refactoring.
Software Refactoring Under Uncertainty: A Robust Multi-Objective ApproachWiem Mkaouer
This document describes a multi-objective robust optimization approach for software refactoring that accounts for uncertainty in code smell severity levels and class importance. The approach formulates refactoring as a multi-objective problem to find solutions that maximize both quality, by correcting code smells, and robustness to changes in severity levels and importance. An evaluation on six open source projects found the approach generates refactoring solutions comparable in quality to existing approaches but with significantly better robustness across different scenarios.
The document discusses refactoring code to improve its design. It defines refactoring as improving code design without changing its external behavior. Refactoring involves identifying "design smells" - symptoms of poor design quality like rigidity, fragility, and opacity. Common smells include long methods, large classes, primitive obsessions, and duplicate code. The document outlines different categories of smells like "bloaters", "object-orientation abusers", and "couplers" that increase coupling between classes. It advises using refactoring tools and techniques to address smells one by one in a refactoring cycle to continuously improve code quality.
This document discusses refactoring code to improve its structure and quality. It defines refactoring as changing code without changing its external behavior to improve non-functional properties like readability. Code smells are hints that refactoring may be needed, like duplicate code or large classes. Code smiles are aspects that make code easy to maintain, like clear naming. The document suggests identifying common issues through lessons learned and implementing prefactors to prevent future problems.
This document provides an overview of the C programming language. It discusses that C was created in the 1970s and has influenced many other popular languages. C is commonly used for writing system software and applications. It allows close control over the program while allowing optimizations for specific platforms, allowing code to run efficiently on limited hardware.
An ontology is a "cousin" of a thesaurus: a controlled vocabulary, enriched with a rich network of terms and relationships. Like a thesaurus, ontologies are useful for such implementations as document classification and data indexing. Marjorie M.K. Hlava, President and founder of Access Innovations, Inc. with Bob Kasenchak, a project manager of this company, outline a new feature of Data Harmony in development: Ontology Master, a module designed specifically to build and manage ontological networks.
This document discusses refactoring code to improve its structure and quality. It defines refactoring as changing code without changing its external behavior to improve non-functional properties like readability. Code smells are hints that refactoring is needed, like duplicate code or large classes. Code smiles are aspects that make code easy to maintain, like clear naming. The document advocates identifying problems early through lessons learned and prefactoring to prevent issues.
The document provides a checklist of topics for a code quality training agenda, including: TDD/automated tests, continuous delivery, refactoring, design patterns, emergent design, SOLID principles, SOA, paired programming, UML/object modeling, and miscellaneous code craftsmanship best practices. It notes that the list is not comprehensive and the goal is to help organizations determine which topics would be most valuable for their teams. Descriptions are provided for some of the highlighted topics.
This is a tutorial that was presented at: The 20th International Conference on Software and Systems Reuse (ICSR'22)
Date of Conference: 15-17 June 2022
Conference Location: Virtual
Conference website: https://icsr2022v2.wp.imt.fr/
A Mono- and Multi-objective Approach for Recommending Software RefactoringAli Ouni
This document outlines Ali Ouni's Ph.D. defense presentation on recommending software refactoring using mono-objective and multi-objective approaches. The presentation includes the following key points:
1. It provides context on the need for automated software refactoring recommendation systems to address challenges in manually refactoring code.
2. It describes Ouni's research methodology which involves detecting code smells, generating refactoring recommendations using mono-objective and multi-objective search-based techniques, and evaluating the approaches.
3. It covers code smell detection including generating detection rules using genetic programming from code smell examples, and evaluating the detection approach on several systems.
4. It outlines the presentation including discussing
Functional over related classes bad smell detection and refactoring suggestionsijseajournal
Bad phenomena about functional over-related classes and confused inheritances in programs will cause
difficulty in programs comprehension, extension and maintenance. In this paper it is defined as a new bad
smell Functional over-Related Classes. After the analysis, the characteristics of this new smell are
transformed to the large number of entities dependency relationships between classes. So after entities
dependency information collection and analysis, the bad smell is detected in programs, and corresponding
refactoring suggestions are provided based on detection results. The experiments results of open source
programs show that the proposed bad smell cannot be detected by current detection methods. The proposed
detection method in this paper behaves well on refactoring evaluation, and the refactoring suggestions
improve the quality of programs.
Similar to Principle based classification of design smells (20)
The document provides an overview of various sea life found underwater, including creatures with fins and tails that feed on seaweed or prey, colorful coral reefs and plants on the ocean floor, sea turtles that lay eggs on beaches, schools of fish that swim together, colorful but sometimes poisonous fish like lionfish, giant whales larger than ships, pink krill that swarm in great numbers, glow in the dark plankton and fish, and sea horses where males give birth to about 150 babies that emerge from their stomachs. The concluding message is that the ocean is vast and should be protected from pollution to celebrate its freedom.
Technical debt refers to design decisions that are suboptimal or incorrect, accruing debt that must be paid back later. It includes code debt from violations of coding standards and design debt from design smells or violations of architecture rules. Refactoring is restructuring code without changing behavior to improve design quality and make future changes easier. A variety of tools can help explore code structure and detect technical debt to prioritize refactoring.
Please check out the workshop "AI meets Blockchain" at HIPC 2018, in Bangalore: http://hipc.org/ai-blockchain/
HIPC is a premier conference and hence getting a paper accepted in HIPC workshop would be quite an accomplishment for any blockchain/AI enthusiast. Check out the details in this poster on submissions.
I have been fortunate to have worked with some geeks with incredible coding skills. I felt amazed at how they can play games with compilers, perform magic with their incantations on the shell, and solve some insanely complex algorithm problems with ease. I naively assumed that they are going to achieve greatness in near future. Alas, I was wrong. Really wrong. [Read the rest of the article ... ]
Many students reach out to me asking for project ideas they can do as a summer project for learning. Here is an interesting project idea - implement your own java disassembler (and expand it to a VM later).
The document discusses various techniques for writing clean code, including formatting code consistently, using meaningful names, writing comments to explain intent, keeping functions focused on single tasks, limiting class and method complexity, and avoiding hardcoded values. It emphasizes habits like adhering to coding standards as a team and writing unit tests. Specific techniques mentioned include consistent formatting, searchable names, avoiding comments as a crutch, limiting function parameters and nesting depth, and preferring classes with cohesive responsibilities. The document recommends several coding standards and style guides.
Design Patterns - Compiler Case Study - Hands-on ExamplesGanesh Samarthyam
This presentation takes a case-study based approach to design patterns. A purposefully simplified example of expression trees is used to explain how different design patterns can be used in practice. Examples are in C#, but is relevant for anyone who is from object oriented background.
This presentation provides an overview of recently concluded Bangalore Container Conference (07-April-2017). See www.containerconf.in for more details.
Bangalore Container Conference 2017 (BCC '17) is the first conference on container technologies in India happening on 07th April. Organizations are increasingly adopting containers and related technologies in production.Hence, the main focus of this conference is “Containers in Production”. This one-day conference sets the perfect stage for container enthusiasts, developers, users and experts to meet together and learn from each others experiences.
Presented in Bangalore Open Java User Group on 21st Jan 2017
Awareness of design smells - Design comes before code. A care at design level can solve lot of problems.
Indicators of common design problems - helps developers or software engineers understand mistakes made while designing and apply design principles for creating high-quality designs. This presentation provides insights gained from performing refactoring in real-world projects to improve refactoring and reduce the time and costs of managing software projects. The talk also presents insightful anecdotes and case studies drawn from the trenches of real-world projects. By attending this talk, you will know pragmatic techniques for refactoring design smells to manage technical debt and to create and maintain high-quality software in practice. All the examples in this talk are in Java.
Bangalore Container Conference 2017 (BCC '17) is the first conference on container technologies in India. Organizations are increasingly adopting containers and related technologies in production. Hence, the main focus of this conference is “Containers in Production”. This one-day conference sets the perfect stage for container enthusiasts, developers, users and experts to meet together and learn from each others experiences.
Let's Go: Introduction to Google's Go Programming LanguageGanesh Samarthyam
This document introduces the Go programming language, which was announced by Google in 2009. It summarizes Go's key features, including being a concurrent, garbage-collected systems programming language. It also provides instructions on installing Go and a simple "Hello World" program example. The document highlights some of Go's novel features like interfaces and goroutines and concludes that Go shows promise as a useful systems language.
This document contains 5 quiz questions about Java generics with the corresponding answers. It was created by Ganesh Samarthyam from CodeOps to test knowledge of Java generics. Additional contact information for Ganesh and CodeOps is provided at the bottom, including email, social media profiles, phone number and website links.
This document provides an overview of Java generics through examples. It begins with simple examples demonstrating how generics can be used to define container classes (BoxPrinter) and pair classes (Pair). It discusses benefits like type safety and avoiding duplication. Further examples show generics with methods and limitations like erasure. Wildcard types are presented as a way to address subtyping issues. In general, generics provide flexibility in coding but their syntax can sometimes be complex to read.
The document describes an application with a pipe-and-filter architecture pattern where sensor data flows through multiple components that each transform the data before passing it to the next component and finally to a modeling and visualization unit. It then asks questions about software architecture patterns and styles like pipe-and-filter, lambda architecture, decorator pattern, Conway's law, architecture drift, REST, event sourcing, and recommends architecture refactoring when dependency analysis finds numerous cycles and tangles.
This presentation covers quiz questions prepared for the Core Java meetup on 1st October in Accion Labs. It has questions from "Java best practices", "bytecodes", and "elastic search".
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
Cosa hanno in comune un mattoncino Lego e la backdoor XZ?Speck&Tech
ABSTRACT: A prima vista, un mattoncino Lego e la backdoor XZ potrebbero avere in comune il fatto di essere entrambi blocchi di costruzione, o dipendenze di progetti creativi e software. La realtà è che un mattoncino Lego e il caso della backdoor XZ hanno molto di più di tutto ciò in comune.
Partecipate alla presentazione per immergervi in una storia di interoperabilità, standard e formati aperti, per poi discutere del ruolo importante che i contributori hanno in una comunità open source sostenibile.
BIO: Sostenitrice del software libero e dei formati standard e aperti. È stata un membro attivo dei progetti Fedora e openSUSE e ha co-fondato l'Associazione LibreItalia dove è stata coinvolta in diversi eventi, migrazioni e formazione relativi a LibreOffice. In precedenza ha lavorato a migrazioni e corsi di formazione su LibreOffice per diverse amministrazioni pubbliche e privati. Da gennaio 2020 lavora in SUSE come Software Release Engineer per Uyuni e SUSE Manager e quando non segue la sua passione per i computer e per Geeko coltiva la sua curiosità per l'astronomia (da cui deriva il suo nickname deneb_alpha).
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdfMalak Abu Hammad
Discover how MongoDB Atlas and vector search technology can revolutionize your application's search capabilities. This comprehensive presentation covers:
* What is Vector Search?
* Importance and benefits of vector search
* Practical use cases across various industries
* Step-by-step implementation guide
* Live demos with code snippets
* Enhancing LLM capabilities with vector search
* Best practices and optimization strategies
Perfect for developers, AI enthusiasts, and tech leaders. Learn how to leverage MongoDB Atlas to deliver highly relevant, context-aware search results, transforming your data retrieval process. Stay ahead in tech innovation and maximize the potential of your applications.
#MongoDB #VectorSearch #AI #SemanticSearch #TechInnovation #DataScience #LLM #MachineLearning #SearchTechnology
UiPath Test Automation using UiPath Test Suite series, part 6DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 6. In this session, we will cover Test Automation with generative AI and Open AI.
UiPath Test Automation with generative AI and Open AI webinar offers an in-depth exploration of leveraging cutting-edge technologies for test automation within the UiPath platform. Attendees will delve into the integration of generative AI, a test automation solution, with Open AI advanced natural language processing capabilities.
Throughout the session, participants will discover how this synergy empowers testers to automate repetitive tasks, enhance testing accuracy, and expedite the software testing life cycle. Topics covered include the seamless integration process, practical use cases, and the benefits of harnessing AI-driven automation for UiPath testing initiatives. By attending this webinar, testers, and automation professionals can gain valuable insights into harnessing the power of AI to optimize their test automation workflows within the UiPath ecosystem, ultimately driving efficiency and quality in software development processes.
What will you get from this session?
1. Insights into integrating generative AI.
2. Understanding how this integration enhances test automation within the UiPath platform
3. Practical demonstrations
4. Exploration of real-world use cases illustrating the benefits of AI-driven test automation for UiPath
Topics covered:
What is generative AI
Test Automation with generative AI and Open AI.
UiPath integration with generative AI
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Why You Should Replace Windows 11 with Nitrux Linux 3.5.0 for enhanced perfor...SOFTTECHHUB
The choice of an operating system plays a pivotal role in shaping our computing experience. For decades, Microsoft's Windows has dominated the market, offering a familiar and widely adopted platform for personal and professional use. However, as technological advancements continue to push the boundaries of innovation, alternative operating systems have emerged, challenging the status quo and offering users a fresh perspective on computing.
One such alternative that has garnered significant attention and acclaim is Nitrux Linux 3.5.0, a sleek, powerful, and user-friendly Linux distribution that promises to redefine the way we interact with our devices. With its focus on performance, security, and customization, Nitrux Linux presents a compelling case for those seeking to break free from the constraints of proprietary software and embrace the freedom and flexibility of open-source computing.
Let's Integrate MuleSoft RPA, COMPOSER, APM with AWS IDP along with Slackshyamraj55
Discover the seamless integration of RPA (Robotic Process Automation), COMPOSER, and APM with AWS IDP enhanced with Slack notifications. Explore how these technologies converge to streamline workflows, optimize performance, and ensure secure access, all while leveraging the power of AWS IDP and real-time communication via Slack notifications.
Dr. Sean Tan, Head of Data Science, Changi Airport Group
Discover how Changi Airport Group (CAG) leverages graph technologies and generative AI to revolutionize their search capabilities. This session delves into the unique search needs of CAG’s diverse passengers and customers, showcasing how graph data structures enhance the accuracy and relevance of AI-generated search results, mitigating the risk of “hallucinations” and improving the overall customer journey.
GraphRAG for Life Science to increase LLM accuracyTomaz Bratanic
GraphRAG for life science domain, where you retriever information from biomedical knowledge graphs using LLMs to increase the accuracy and performance of generated answers
Driving Business Innovation: Latest Generative AI Advancements & Success StorySafe Software
Are you ready to revolutionize how you handle data? Join us for a webinar where we’ll bring you up to speed with the latest advancements in Generative AI technology and discover how leveraging FME with tools from giants like Google Gemini, Amazon, and Microsoft OpenAI can supercharge your workflow efficiency.
During the hour, we’ll take you through:
Guest Speaker Segment with Hannah Barrington: Dive into the world of dynamic real estate marketing with Hannah, the Marketing Manager at Workspace Group. Hear firsthand how their team generates engaging descriptions for thousands of office units by integrating diverse data sources—from PDF floorplans to web pages—using FME transformers, like OpenAIVisionConnector and AnthropicVisionConnector. This use case will show you how GenAI can streamline content creation for marketing across the board.
Ollama Use Case: Learn how Scenario Specialist Dmitri Bagh has utilized Ollama within FME to input data, create custom models, and enhance security protocols. This segment will include demos to illustrate the full capabilities of FME in AI-driven processes.
Custom AI Models: Discover how to leverage FME to build personalized AI models using your data. Whether it’s populating a model with local data for added security or integrating public AI tools, find out how FME facilitates a versatile and secure approach to AI.
We’ll wrap up with a live Q&A session where you can engage with our experts on your specific use cases, and learn more about optimizing your data workflows with AI.
This webinar is ideal for professionals seeking to harness the power of AI within their data management systems while ensuring high levels of customization and security. Whether you're a novice or an expert, gain actionable insights and strategies to elevate your data processes. Join us to see how FME and AI can revolutionize how you work with data!
For the full video of this presentation, please visit: https://www.edge-ai-vision.com/2024/06/building-and-scaling-ai-applications-with-the-nx-ai-manager-a-presentation-from-network-optix/
Robin van Emden, Senior Director of Data Science at Network Optix, presents the “Building and Scaling AI Applications with the Nx AI Manager,” tutorial at the May 2024 Embedded Vision Summit.
In this presentation, van Emden covers the basics of scaling edge AI solutions using the Nx tool kit. He emphasizes the process of developing AI models and deploying them globally. He also showcases the conversion of AI models and the creation of effective edge AI pipelines, with a focus on pre-processing, model conversion, selecting the appropriate inference engine for the target hardware and post-processing.
van Emden shows how Nx can simplify the developer’s life and facilitate a rapid transition from concept to production-ready applications.He provides valuable insights into developing scalable and efficient edge AI solutions, with a strong focus on practical implementation.
GraphSummit Singapore | The Future of Agility: Supercharging Digital Transfor...Neo4j
Leonard Jayamohan, Partner & Generative AI Lead, Deloitte
This keynote will reveal how Deloitte leverages Neo4j’s graph power for groundbreaking digital twin solutions, achieving a staggering 100x performance boost. Discover the essential role knowledge graphs play in successful generative AI implementations. Plus, get an exclusive look at an innovative Neo4j + Generative AI solution Deloitte is developing in-house.
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc
How does your privacy program stack up against your peers? What challenges are privacy teams tackling and prioritizing in 2024?
In the fifth annual Global Privacy Benchmarks Survey, we asked over 1,800 global privacy professionals and business executives to share their perspectives on the current state of privacy inside and outside of their organizations. This year’s report focused on emerging areas of importance for privacy and compliance professionals, including considerations and implications of Artificial Intelligence (AI) technologies, building brand trust, and different approaches for achieving higher privacy competence scores.
See how organizational priorities and strategic approaches to data security and privacy are evolving around the globe.
This webinar will review:
- The top 10 privacy insights from the fifth annual Global Privacy Benchmarks Survey
- The top challenges for privacy leaders, practitioners, and organizations in 2024
- Key themes to consider in developing and maintaining your privacy program
3. * http://sqgne.org/presentations/2012-13/Jones-Sep-2012.pdf
Design quality is important
• Organizations develop critical, large,
and/or reusable software
Design errors are costly
• Capers Jones*: Up to 64% of software
defects can be traced back to errors in
software design in enterprise
software!
Good design practices
needs to be followed.
A designer/developer should
aware of and address
“design smells” in his
software design.
Design quality means: flexibility,
extensibility, understandability,
reusability,...
4. Smells have been defined differently
We embrace all the following definitions!
“We suggest that, like any living creature, system designs are subject to diseases, which are
design smells (code smells and anti-patterns). Design smells are conjectured in the literature to
impact the quality and life of systems.” – Hassaine et al. [HKGH10]
“Smells are certain structures in the
code that suggest (sometimes they
scream for) the possibility of
refactoring.” – M. Fowler [Fow99]
“Code and design smells are poor
solutions to recurring implementation
and design problems.” – Moha et. al.
[MGDM10]
“Design smells are the odors of rotting software.” – R C Martin [Mar03]
7. Many catalogs of smells exist; e.g.:
Design rules by Garzas et al.
[Gar07]
Bad smells by Fowler [Fow99]
Problem patterns by Frank et al.
[SSM06]
Existing catalogs fail to provide a
coherent structure
This tends to limit the
usefulness of these catalogs
An example: “problem patterns” by
Frank et al. [SSM06]
Architectural level
God package
Cyclic dependency
between packages
Micro-architectural level
Knows of derived
Polymorphism placebo
Implementation level
Improper name length
Variables having constant
value
Mixes different kinds of
concerns and addresses
different target audience
Insight 1: For a catalog to be useful, it needs to
clearly separate design smells at different levels of
abstractions and focus on smells at one specific level
8. Some catalogs also classify
smells
Impact based classification of
Fowler’s smells by Mantyla
Design property based
classification by InFusion tool
Moha’s smell classification based
on how smells can be detected
Existing classifications suffer from
numerous limitations
Mantyla [MVL03] classified Fowler’s code
smells [Fow99] as “encapsulators”, “bloaters”,
“couplers”, “OO abusers”, “change preventers”,
“dispensables”, and “others”.
Lacks maturity
Even in the Fowler’s small list
of 22 smells, 2 are classified in
“others” category
Though useful, there are
numerous shortcomings in
this classification scheme
Insight 2: A classification scheme will be more
useful when it provides high-level hints on
understanding the cause of the smell as well as
what needs to be done to fix the smell.
Inconsistent
“Encapsulators” does not have
negative connotation like
other categories
9. During our extensive literature
survey, we found 500+ smells!
However, we did not find any
attempt towards creating a
consistent naming scheme to
unambiguously distinguish design
smells.
Insight 3: Creating a consistent naming scheme
to unambiguously distinguish design smells can
provide an effective vocabulary for discussing
design smells.
Rose is a rose is a rose is a rose …
How to differentiate roses?
There are at least 135 rose
species – how do you
differentiate one from another
without separate names?
Using common names
for design smells leads
to confusion
Need to use scientific names
Using common names for
roses will lead to confusion
12. smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
To address Insight 2, we needed a
classification that can indicate both
the cause of the smell and potential
refactoring
A deeper reflection revealed that a
classification approach based on
fundamental design principles
(relevant to OO) would help
practitioners
If a practitioner could easily trace
the cause of smells to violated
design principles, it would better
guide him in addressing that smell
13. We attempted using numerous catalogs of fundamental software
engineering design principles
Of them, we found that Booch’s classification best suited our needs
14. smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
smell
These concise set of 4 principles are
fundamental principles and well-
known
Aids easy recall
Almost all smells in our catalog could
be traced back to violation of these
principles
Each principle is a single word. A
smell can be named by prefixing a
suitable adjective to the principle
name
Name = (adjective + principle)
Uniform naming scheme!
abstraction encapsulation
hierarchy
modularity
20. Element Short Description
Name A concise, intuitive name based on our naming scheme
Short Description A short description of the design smell to explain the smell concisely
Long Description A detailed description about the design smell to explain the design smell (with
optional discussion on potential causes of the smell, or its e ect on design)
Rationale A rationale to justify why the identi ed issue indicates a bad smell in design
Example(s) One or more illustrative examples (including from open source software)
Violated Principles OO design principles (out of the four) whose violations can lead to this smell, the
speci c object oriented enabling techniques that have been violated, and the
justification for why the design smell is classi ed under a particular principle.
Impacted quality
attributes
The design quality attributes (reusability, exibility, understandability, functionality,
extendibility, and e ectiveness ) that are negatively impacted due to this smell.
Also known as Alternative names documented in literature that are used to describe the smell.
Variants Design smells documented in literature that are fundamentally identical to and yet
exhibit a slight variation from the smell. The variation may include a special form, or a
more general form of the design smell.
Exceptions Contexts or situations where the smell is likely to be not considered a problem.
Detection Strategy High-level hints on how the design smell can be detected from design or code artifacts.
Suggested Refactoring Generic high-level suggestions and steps to refactor the design smell.
21. Short description:
This design smell arises when a supertype directly or indirectly refers to one of its subtypes,
forming a cycle in the hierarchy [Ber04, BNL05, Gar07, Rie96, DMTS10a, WCKD11].
Long description:
This smell arises when a supertype refers to any of its subtypes. Here the term ``reference''
means:
a) a supertype contains an object of one of its subtypes
b) a supertype refers to the type name of one of its subtypes
c) a supertype accesses data members, or calls methods from one of its subtypes.
Such a reference can be either direct or indirect. Since subtype knowledge introduces a cycle
in the inheritance graph annotated with class relationships, this smell is termed as ``cyclic
hierarchy''.
22. Rationale:
It is undesirable for a supertype to have knowledge about its subtype(s) for the following
reasons:
• Supertypes and subtypes can be thought of as separating the interface and the
implementation aspects of an abstraction. An interface should specify a contract and
should not know anything about the implementation, and hence a supertype should not
have any knowledge of its subtypes.
• A supertype needs to be agnostic of any of its subtypes; only then, it is possible to compile
it, use it and reuse it independent of its subtypes. With subtype knowledge, changes to
subtypes can potentially affect the supertype, which is undesirable.
23. Example:
The example in above figure shows inheritance relationship between MutableBigInteger
and SignedMutableBigInteger from JDK; these classes were introduced in Java from version
1.3 and are part of java.math package.
The private modInverse() method in MutableBigInteger class implements an algorithm that
requires the use of signed integer and hence it creates instances of
SignedMutableBigInteger; this instance creation introduces a reference from the supertype
method to the subtype resulting in cyclic hierarchy smell.
One potential refactoring for addressing this smell is to re-implement the modInverse()
method (say, using an alternative algorithm if available) in such a way that it does not
require creating instances of SignedMutableBigInteger.
24. Violated principles:
Abstraction: A forward reference to the subtype likely indicates ineffective abstraction of
the problem domain [Mil99]. Thus the principle of abstraction is violated.
Modularity: Cyclic dependencies create tight coupling and thus violate the principle of
modularity. Specifically, cyclic dependencies indicate the violation of the Acyclic
Dependencies Principle (ADP) [Mar03]. Further, changes to subtype might require re-
compilation of the supertype affecting independent module compilability [SRK07].
Hierarchy: Ideally, inheritance should model a generalization/specialization hierarchy and
the hierarchy specializations should have dependencies that are directed towards
generalizations. A forward association from the supertype to subtype violates Dependency
Inversion Principle [Mar03], and this changing of dependency direction towards
specializations violates the principle of hierarchy.
This smell can only manifest in the context of a hierarchy. We, therefore, classify it
under the principle of hierarchy.
25. Impacted quality attributes:
• Flexibility: Changes to or removal of subtypes affect supertype, hence flexibility is
impacted.
• Understandability: In order to understand the supertype, one has to understand the
subtype also. This increases the cognitive load, affecting understandability.
• Extendability: Adding a new subtype may require changes in supertype, thus impacting
extendability of the design.
Also known as: ``Knows of derived'' [CIU99, SSM06], ``subtype knowledge'' [DTMS10b],
``subclass knowledge‘’ [BNL05], ``curious superclasses'' [BNL05], ``inheritance/reference
cycles'' [SSC96], ``base class depends on derived classes‘’ [CWZ00], ``forward associations in
a hierarchy'' [Mil99].
Variants: ``Inheritance loops'' [Bin99].
26. Exceptions:
This design smell might be acceptable if it is known that the supertype and subtype(s) are
not going to change in future [SSC96]. Sometimes, to support unanticipated changes, when
inheritance is used as registration mechanism or factory where the client should always
refer to the supertype, it is acceptable for supertypes to refer to their subtypes. Examples
(both from [DMTS10a]): Returning instance of a subtype as the default instance in Singleton
pattern and installing global default factory in case of Abstract Factory pattern.
Detection Strategy:
Check if the inheritance graph annotated with class relationships is a Directed Acyclic Graph
(DAG).
Suggested refactoring:
If the reference from supertype to subtype is accidental or incidental, refactor the
supertype to eliminate such references. If the supertype requires the services of its
subtypes, consider applying State or Strategy patterns [Gar07].
27. Degraded Hierarchy:
This design smell arises when the hierarchy tends to be more concrete towards the root and
more abstract towards the leaves. This smell includes the case where a supertype is declared
concrete and its subtype is declared abstract.
Also known as:
``Illegal abstract inheritance'' [Ber04], ``super class is a concrete class'' [Gar07], ``illegal
abstract inheritance'' [Ber04], ``abstract leaf classes'' [Mil99].
Variants:
``Abstracting concrete methods'' [ADGN10], ``inflexible root class'' [Mil99], ``inverse
abstraction hierarchies'' [Mil99].
29. In order to draw reasonable comparisons between our work and other well-
known catalogs/classifications, an extensive set-up would be required
In an organizational context, this is difficult to achieve
Comparative evaluation
Is our classification scheme more useful than other classification schemes?
Is our naming scheme simpler or easier to remember?
Is our catalog more complete than other catalogs?
…
Non-comparative evaluation relies on opinion of experts
Is our classification scheme useful?
Is our naming scheme simple or easy to remember?
Is our catalog complete?
…
30. As an initial step, we decided to elicit feedback
from CT DC AA practitioners
We created a design smells-centric assignment
for CT DC AA architects participating in an
advanced design and architecture training
Task: “Find design smells in your project using
our catalog as a reference”
Duration of the assignment was 1.5 months
Next, the participants were requested to provide
feedback on the usefulness of the catalog/classification
via a questionnaire
Questionnaire consisted of 10 rating-based
questions
Ratings were on a scale of 0 to 5
31. Received responses from all the 12 participants
Experience in IT industry: 10.8 years (average)
Experience as an architect: 2.9 years (average)
Objectives
How useful is the catalog
and classification to
practitioners?
How complete is the
catalog?
Is the “principle-based
classification scheme”
correct?
Is the naming scheme
useful and intuitive?
32. Knowledge improvement
by a factor of two!
Catalog “very useful”
Catalog “reasonably
comprehensive”
Question [note in square brackets] Responses:
Mean/Summary
1 Rate your knowledge in design smells before
this assignment on design smells. [0 - no
knowledge; 5 - "expert" level knowledge]
1.9
2 Rate your knowledge in design smells after this
assignment on design smells. [0 - no knowledge; 5
- "expert" level knowledge]
3.7
4 Have you come across any design smells you’ve
never seen before but was provided in this
catalog? [Yes/No] If yes, please list them.
Yes - 9
No - 2
No response - 1
5 Did you nd any design smells in your project
that were not covered in this catalog? [Yes / No.]
If yes, please list them.
Yes - 3
No - 6
No response - 3
3 How useful was the design smells catalog to
understand the kind and extent of design
problems in your project? [0 - the catalog was of no
use; 5 - the catalog was extremely useful.]
4
33. Respondents
mentioned other
factors, but they trace
back to violation of
principles
Naming scheme
reasonably useful and
intuitive
Design smells work has
been received mostly
positively
Question [note in square brackets] Responses:
Mean/Summary
6 Rate the extent to which you believe that the smells
found in your project (during the assignment) actually
resulted from a violation of the corresponding design
principles. [0 - none of the design smells resulted from
violation of the corresponding design principle; 5 - all of the
design smells resulted from violation of the design principle]
3.7
9 Would you use the design smell catalog to identify
smells in the future for your project(s)? [Yes / No]
Yes - 11
No - 1
10 Would you recommend this design smell catalog to
be used by architects in other projects that you
know? [Yes / No]
Yes - 11
No - 1
7 How useful is the naming scheme in the design
smells catalog to understand the cause of design
smell? [0 - not at all understandable; 5- very easy to
understand]
3.8
8 How intuitive is the naming scheme in the design
smells catalog? [0 - not at all intuitive; 5 - very intuitive]
3.9
34. Overall feedback
All the three aspects of our design smells work - the catalog, the classification,
and the naming scheme - has been received positively by the practitioners.
“Except a few [design smells], most of
them were new to me.”
“Generally I use my experience to identify the design
smells. But the catalog provided in the assignment
gave me a good reference about the different types of
design smells that can exist such that identifying the
design smells becomes much easy.”
“Very difficult to identify smells … due
to lack of tools.”
“I personally felt this assignment to be
very challenging …”
“Need to go through it [design smells in the catalog]
again and understand them in more depth so that next
time when designing, we would be careful about these
design problems/smells”
36. We found it difficult to name smells related to modularity.
Perhaps because modularity is more of a “design property” than a
principle.
We could attempt using alternative terms such as
“modularization” but that would entail deviating from principles
proposed by Booch.
Or, use alternative naming scheme with different principle names.
We believe it is perhaps not be possible to have a “perfect solution” to
naming smells.
37. Overall, most names created using our naming scheme are intuitive
As supported by the initial evaluation results.
However, our naming scheme needs to adhere to the following criteria
Violated principle should be part of the name.
Simple and easy to remember names.
Uniform and consistent names.
Sometimes, it is difficult to satisfy all these criteria, resulting in unintuitive
names
For example, just from the name “unrestrained encapsulation”, it is not
evident that it arises when an abstraction depends on global state
Again, we believe it is perhaps not possible to have a “perfect solution” to
naming smells.
39. Augment the catalog with smells undocumented in literature
Include a larger set of principles to classify more smells
Introduce enabling techniques to the classification scheme
Specify smells in formal/semi-formal notation
Categorize architectural and code smells
Expand the smell template (e.g. include detailed refactoring steps)
Explore relationships between smells
Develop tool support for detecting smells
Comprehensively evaluate the classification and naming scheme
40. In this work, we limited ourselves to cataloging, classifying and naming known or
“documented” smells.
Based on our industry experience, we find some smells are not
documented.
Perhaps because the focus has not been on identifying the cause of smells –
i.e. the specific sub-principles that are violated.
We believe it is possible “discover” smells! How?
Approach: Map each high-level principle to criteria or sub-principles.
If the criteria/sub-principle is violated, it could result in one or more smells
– check if these are documented.
Example: Consider the criterion offered by Booch for abstraction –
sufficiency, primitiveness, and completeness.
If we violate any one of this criteria, we may get smells such as “insufficient
abstraction” and “non-primitive abstraction”.
41. Published in Journal of Object Technology (Vol. 12, No. 2, 2013)
S.G. Ganesh, Tushar Sharma, Girish Suryanarayana, “Towards a Principle-based
Classification of Structural Design Smells”, Journal of Object Technology, Volume
12, no. 2 (June 2013), pp. 1:1-29, doi:10.5381/jot.2013.12.2.a1.
URL: http://www.jot.fm/issues/issue_2013_06/article1.pdf (open access)
“… a really comprehensive
catalog about design
smells organizing what is
found in relevant
literature...”
“The paper presents a novel idea for identifying, specifying, name and classifying design smells.
The proposal contains an extensive classification of almost 300 design smell references.”
“I really like this paper.
Excellent work! This paper can
be a key reference in the field.”
“The paper presents a
good classification and I
clearly think that it is
necessary. ”