Skip navigation
Help

software engineering

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

VISSOFT 2011, the 6th IEEE International Workshop on Visualizing Software for Understanding and Analysis, took place in Williamsburg, Virginia, USA, September 29-30, 2011 and was co-located with ICSM 2011. The proceedings are available in the IEEE Xplore Digital Library. Of the 21 full papers submitted to the workshop, nine were accepted (acceptance rate: 42%).

This post is by Fabian Beck a new contributor to the SoftVis blog and presents the nine full papers of VISSOFT 2011 in form of a structured review.

Code Dependencies

Dependencies between source code artifacts provide insights in the structure of a software system. Visualizing them is challenging because of the sheer quantity of dependencies usually included in a system. Often the hierarchical organization of the system (e.g., a hierarchical package structure) helps to structure or simplify these dependencies. Among the papers presented at VISSOFT 2011, many involve the visualization of code dependencies, the following three, however, having them in particular focus.

Caserta et al. use the hierarchical organization to map the source code artifacts to a two-dimensional plane exploiting a city metaphor. On top of this plane, in the third dimension, they draw the dependencies that link the artifacts. The authors reduce the visual complexity of the diagram by bundling the dependencies, again using the hierarchical structure of the artifacts. Such hierarchical edge bundling is also used in the approach by Beck F. et al., which focuses on comparing different types of code dependencies. They arrange the hierarchically structured artifacts linearly from top to bottom. Each type of dependency is depicted in a narrow stripe. By arranging the stripes side-by-side these types can be visually compared. The idea of depicting different types of dependencies is also present in the approach by Erdemir et al. They link those dependencies to different quality metrics by encoding them in the shape, color, texture, etc., of the nodes. A distinguishing feature of their approach is the intuitive mapping between metrics and visual attributes.

Dynamic Program Behavior

The analysis of the dynamic behavior of software systems is usually facing even larger sets of data than the analysis of static code dependencies. Visualization approaches depicting such dynamic data, hence, have to apply some form of aggregation to handle the data. As the following two examples show, this aggregation can be realized in different ways.

Code Dependencies can be enriched by dynamic information, for instance, as demonstrated by Deng et al.: They enforce structural dependencies if the connected code entities are covered by the same set of test cases. This dynamic relational information is only used to arrange a large set of code entities onto a two-dimensional plane. For reasons of scalability, their visualization shows these entities as color-coded dots, but does not depict dependencies. Choudhury and Rosen introduce an animated visualization technique for representing runtime memory transactions of a program. Elements of accessed data, visually encoded as glyphs, move between levels of a simulated cache. These glyphs form abstract visual structures that provide insights into the composition and eviction of the cache. The authors suggest that their approach fosters program comprehension with respect to the dynamic behavior of the program.

Visual Analytics Tools & Case Studies

Over the last decade, many software visualization approaches have been proposed, but only very few of them reached wide impact in practice. A reason could be that academia did not sufficiently embed those visualizations into real-world scenarios and development processes. The following analytics tools and case studies might lessen this gap.

When gaining information by visually analyzing a software system, a software developer wants to react to these new insights. Beck M. et al. introduce a tool for planning the reengineering of a software system, that is, changing the software design at a high level. Their tool is also based on a visualization of code dependencies attached with a hierarchy. The innovative features of their approach are the flexible interaction techniques for changing the hierarchy (i.e., the software design). Also Broeksema and Telea target at supporting developers in changing a software system: They investigate the effort to port a system from an older version of a library to a newer one. Their visualization, which they implemented as an IDE plug-in for KDevelop, provides an overview on the necessary changes and guide the developer to realize them.

Neu et al. study not only single software projects, but the ecosystems the individual projects are embedded in. They developed a web application that visualizes the evolution of such ecosystems. As an extensive case study, the GNOME project is analyzed. Long practiced but only recently considered as a serious development method, sketches are explored by Walny et al. In semi-structured interviews they evaluated how software developers in academia use these ad-hoc software visualizations. The interviews reveal that sketches are applied in a broad spectrum of scenarios and are often saved and reused in later stages of development.

0
Your rating: None

Organizational anti-patterns

  • Analysis paralysis: Devoting disproportionate effort to the analysis phase of a project
  • Cash cow: A profitable legacy product that often leads to complacency about new products
  • Design by committee: The result of having many contributors to a design, but no unifying vision
  • Escalation of commitment: Failing to revoke a decision when it proves wrong
  • Management by perkele: Authoritarian style of management with no tolerance of dissent
  • Management by objectives: Management by numbers, focus exclusively on quantitative management criteria, when these are non-essential or cost too much to acquire.
  • Moral hazard: Insulating a decision-maker from the consequences of his or her decision
  • Mushroom management: Keeping employees uninformed and misinformed; employees are described as being kept in the dark and fed manure, left to stew, and finally canned.
  • Stovepipe or Silos: A structure that supports mostly up-down flow of data but inhibits cross organizational communication
  • Vendor lock-in: Making a system excessively dependent on an externally supplied component[4]

Project management anti-patterns

  • Avalanche: An inappropriate mashup of the Waterfall model and Agile Development techniques
  • Death march: Everyone knows that the project is going to be a disaster – except the CEO – so the truth is hidden to prevent immediate cancellation of the project - (although the CEO often knows and does it anyway to maximize profit). However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes ("Big Bang"). Alternative definition: Employees are pressured to work late nights and weekends on a project with an unreasonable deadline.
  • Groupthink: During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking
  • Overengineering: Spending resources making a project more robust and complex than is needed
  • Smoke and mirrors: Demonstrating unimplemented functions as if they were already implemented
  • Software bloat: Allowing successive versions of a system to demand ever more resources
  • Waterfall model: An older method of software development that inadequately deals with unanticipated change

Analysis anti-patterns

  • Bystander apathy: When a requirement or design decision is wrong, but the people who notice this do nothing because it affects a larger number of people

Software design anti-patterns

Object-oriented design anti-patterns

  • Anemic Domain Model: The use of domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
  • BaseBean: Inheriting functionality from a utility class rather than delegating to it
  • Call super: Requiring subclasses to call a superclass's overridden method
  • Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
  • Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
  • Constant interface: Using interfaces to define constants
  • God object: Concentrating too many functions in a single part of the design (class)
  • Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
  • Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
  • Poltergeists: Objects whose sole purpose is to pass information to another object
  • Sequential coupling: A class that requires its methods to be called in a particular order
  • Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

Programming anti-patterns

  • Accidental complexity: Introducing unnecessary complexity into a solution
  • Action at a distance: Unexpected interaction between widely separated parts of a system
  • Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine
  • Boat anchor: Retaining a part of a system that no longer has any use
  • Busy waiting: Consuming CPU while waiting for something to happen, usually by repeated checking instead of messaging
  • Caching failure: Forgetting to reset an error flag when an error has been corrected
  • Cargo cult programming: Using patterns and methods without understanding why
  • Coding by exception: Adding new code to handle each special case as it is recognized
  • Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message
  • Hard code: Embedding assumptions about the environment of a system in its implementation
  • Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences[5][6]
  • Loop-switch sequence: Encoding a set of sequential steps using a switch within a loop statement
  • Magic numbers: Including unexplained numbers in algorithms
  • Magic strings: Including literal strings in code, for comparisons, as event types etc.
  • Repeating yourself: Writing code which contains repetitive patterns and substrings over again; avoid with once and only once (abstraction principle)
  • Soft code: Storing business logic in configuration files rather than source code[7]
  • Spaghetti code: Programs whose structure is barely comprehensible, especially because of misuse of code structures
  • Shotgun surgery: Developer adds features to an application codebase which span a multiplicity of implementors or implementations in a single change.

Methodological anti-patterns

Configuration management anti-patterns

See also

0
Your rating: None