Software Development Problems Research Articles

From function design to system design in model-based software development

The amount of software in modern electronic control units (ECUs), and the degree of networking between them, has reached such proportions that they increasingly cause software development and maintenance problems for vehicle manufacturers and suppliers. To meet this challenge head on, dSpace, the leading supplier of tools for developing automotive software, has added System Desk to its tool chain. System Desk introduces a model-based development process at system level, allowing users to extend existing development processes

SmPL: A Domain-Specific Language for Specifying Collateral Evolutions in Linux Device Drivers

Collateral evolutions are a pervasive problem in large-scale software development. Such evolutions occur when an evolution that affects the interface of a generic library entails modifications, i.e., collateral evolutions, in all library clients. Performing these collateral evolutions requires identifying the affected files and modifying all of the code fragments in these files that in some way depend on the changed interface.We have studied the collateral evolution problem in the context of Linux device drivers. Currently, collateral evolutions in Linux are mostly done manually using a text editor, possibly with the help of tools such as grep. The large number of Linux drivers, however, implies that this approach is time-consuming and unreliable, leading to subtle errors when modifications are not done consistently.In this paper, we propose a transformation language, SmPL, to specify collateral evolutions. Because Linux programmers are accustomed to exchanging, reading, and manipulating program modifications in terms of patches, we build our language around the idea and syntax of a patch, extending patches to semantic patches.

A relationship-driven approach to view merging

A key problem in view-based software development is merging a set of disparate views into a single seamless view. To merge a set of views, we need to know how they are related. In this extended abstract, we discuss the methodological aspects of describing the relationships between views. We argue that view relationships should be treated as first-class artifacts in the merge problem and propose a general approach to view merging based on this argument. We illustrate the usefulness of our approach by instantiating it to the state-machine modelling domain and developing a flexible tool for merging state-machines.

Development of a human information processing model for cognitive task analysis and design

High costs and long cycle times of software development are factors hindering the analysis and design of the complete cognitive aspects related to task performances. Reusable software has been proposed as a solution to the problem of high software development and maintenance costs. One of the paradigms for reusable software, object-oriented modelling, has emerged as an important method for specifying, creating and reusing software modules. Using Unified Modelling Language, this paper develops an object-oriented cognitive task analysis and design (OOCTAD) model based on human information-processing theory. First, human task performance-related cognitive aspects are classified into modules and logically linked together; secondly, cognitive aspects within these modules were further decomposed into packages and classes based on object-oriented technology. Finally, one case study was presented to compare and contrast different cognitive analysis models to illustrate the advantages of the OOCTAD model developed in the current research over the other five cognitive task analysis models. These reusable classes in the OOCATD model were shown to be reused to reduce software development costs and cycle times for cognitive task analysis and design. The current research should be of use to both developers and users of cognitively based tasks, systems and tools and researchers and practitioners in the broader discipline of cognitive tasks design and analysis.

Discovering Architectures from Running Systems

One of the challenging problems for software developers is guaranteeing that a system as built is consistent with its architectural design. In this paper, we describe a technique that uses runtime observations about an executing system to construct an architectural view of the system. In this technique, we develop mappings that exploit regularities in system implementation and architectural style. These mappings describe how low-level system events can be interpreted as more abstract architectural operations and are formally defined using colored Petri nets. In this paper, we describe a system, called DiscoTect, that uses these mappings and we introduce the DiscoSTEP mapping language and its formal definition. Two case studies showing the application of DiscoTect suggest that the tool is practical to apply to legacy systems and can dynamically verify conformance to a preexisting architectural specification

Examining the role of iteration in the complete lifecycle of a traceability-oriented software development process

Software engineering methodologies have received considerable attention in the past few years, due to the ongoing crisis presented in the Standish Group's CHAOS Report. Royce's Waterfall Model correctly identifies the phases of software development (requirements capture, problem analysis, design, implementation, and testing), but it does not facilitate iteration between phases. Over the past several years numerous methodologies have been developed, which attempt to rectify this deficiency (e.g. the Spiral model, the Rational Unified Process (RUP), and Agile methodologies like eXtreme Programming (XP)). XP significantly differs from RUP's prescriptive approach by underemphasizing the role of explicit analysis and design artifacts, and focusing instead on techniques that quickly achieve a system. XP requires incremental augmentation of the features of a system--primarily by working at the code level, a.k.a. refactoring.

From Composition Filters to AspectJ: A Platform Specific Model Transformation

Both model driven architecture (MDA) and aspect oriented programming (AOP) are promising paradigms that are very attractive for the software engineering community. While the former is an approach to application design and implementation using models as first class entities, the latter advocates the separation of concerns as an approach to tackle most software development and maintenance problems. MDA and AOP can be related in various ways and their combination seems to be a promising issue. In this article, we focus on the transformation of two AOP approaches, composition filters (CF) and AspectJ, considered as platform specific metamodels within the MDA context. We propose a transformation of CF models into AspectJ models using a syntax directed translation and a set of transformation templates. In addition to being easy to implement, our transformation approach covers the most important concepts of CF.

Comparing requirements analysis methods for developing reusable component libraries

Two approaches to requirements modelling are compared—the Domain Theory [Sutcliffe, A.G., 2002. The Domain Theory: Patterns for Knowledge and Software Reuse. Lawrence Erlbaum Associates, Mahwah, NJ.] and Problem Frames [Jackson, M., 2001. Problem Frames: Analysing and Structuring Software Development Problems, Pearson Education, Harlow.]—as a means of domain analysis for creating a reusable library of software components for constructing telemedicine applications. Experience of applying each approach as a domain analysis method to specify abstract components (object system models and Problem Frames) is reported. The two approaches produced detailed specifications although at different levels of abstraction: problems frames were better for monitoring, updating and data integrity requirements whereas the Domain Theory proved more useful for task support and user interface requirements. The lessons learned from using model-based approaches to requirements specification, and their merits for creating consistent specifications for reuse libraries, are discussed.

Coordination in software development

To systematize software development, many process models have been proposed over the years. These models focus on the sequence of steps used by developers to create reliable software. Though these process- models have helped companies to gain certification and attain global standards, they don't take into account interpersonal interactions and various other social aspects of software development organizations. In this paper we tackle one crucial part of the Coordination problem in Software Development, namely the problem of task assignment in a team. We propose a methodology to test a hypothesis based on how social networks can be used to improve coordination in Software Industry. In a pilot case study based on 4 teams of Masters Student working in a globally distributed environment (Holland and India), the social network structures along with the task distribution in each of the teams were analyzed. In each case we observed patterns, which could be used to test many hypotheses on team coordination and task allocation between them.

The mathematico-symbolic formulation of teleonic principles

Teleonics or the Biomatrix Approach is a systemic approach, the basic units of which are considered to be goal-oriented process systems called teleons. It has been developed during the last 20 odd years as a descriptive approach that can be utilized to analyse and design problems in different areas, including physiology, healthcare, development, psychology, education, organizational development and software development. The present paper aims at summarizing the most important formalized principles of teleonics in a mathematico-symbolic way. Copyright © 2005 John Wiley & Sons, Ltd.

Combining Usability Techniques to Design Geovisualization Tools for Epidemiology

Designing usable geovisualization tools is an emerging problem in GIScience software development. We are often satisfied that a new method provides an innovative window on our data, but functionality alone is insufficient assurance that a tool is applicable to a problem in situ. As extensions of the static methods they evolved from, geovisualization tools are bound to enable new knowledge creation. We have yet to learn how to adapt techniques from interaction designers and usability experts toward our tools in order to maximize this ability. This is especially challenging because there is limited existing guidance for the design of usable geovisualization tools. Their design requires knowledge about the context of work within which they will be used, and should involve user input at all stages, as is the practice in any human-centered design effort. Toward that goal, we have employed a wide range of techniques in the design of ESTAT, an exploratory geovisualization toolkit for epidemiology. These techniques include; verbal protocol analysis, card-sorting, focus groups, and an in-depth case study. This paper reports the design process and evaluation results from our experience with the ESTAT toolkit.

Architectural patterns for problem frames

Problem frames provide a characterisation and classification of software development problems. Fitting a problem to an appropriate problem frame should not only help to understand it, but also to solve the problem (the idea being that, once the adequate problem frame is identified, then the associated development method should be available). The authors propose software architectural patterns corresponding to the different problem frames that may serve as a starting point for the construction of the software solving the given problem. It is shown that these architectural patterns exactly reflect the properties of the problems fitting to a given frame, and that they can be combined in a modular way to solve multi-frame problems. Alternative architectures to cope with specific system characteristics (e.g. distribution) are also provided.

Design patterns as aspects: a quantitative assessment

Design patterns offer flexible solutions to common problems in software development. Recent studies have shown that several design patterns involve crosscutting concerns. Unfortunately, object-oriented (OO) abstractions are often not able to modularize those crosscutting concerns, which in turn decrease the system reusability and maintainability. Hence, it is important verifying whether aspect-oriented approaches support improved modularization of crosscutting concerns relative to design patterns. Ideally, quantitative studies should be performed to compare object-oriented and aspect-oriented implementations of classical patterns with respect to important software engineering attributes, such as coupling and cohesion. This paper presents a quantitative study that compares aspect-based and OO solutions for a representative set of design patterns. We have used stringent software engineering attributes as the assessment criteria. We have found that most aspect-oriented solutions improve separation of pattern-related concerns, although some aspect-oriented implementations of specific patterns resulted in higher coupling and more lines of code.

Design patterns as aspects: A quantitative assessment

AbstractDesign patterns offer flexible solutions to common problems in software development. Recent studies have shown that several design patterns involve crosscutting concerns. Unfortunately, object-oriented (OO) abstractions are often not able to modularize those crosscutting concerns, which in turn decrease the system reusability and maintainability. Hence, it is important verifying whether aspect-oriented approaches support improved modularization of crosscutting concerns relative to design patterns. Ideally, quantitative studies should be performed to compare object-oriented and aspect-oriented implementations of classical patterns with respect to important software engineering attributes, such as coupling and cohesion. This paper presents a quantitative study that compares aspect-based and OO solutions for a representative set of design patterns. We have used stringent software engineering attributes as the assessment criteria. We have found that most aspect-oriented solutions improve separation of pattern-related concerns, although some aspect-oriented implementations of specific patterns resulted in higher coupling and more lines of code.

A comparison of cohesion metrics for object-oriented systems

Cohesion is the degree to which the elements of a class or object belong together. Many different object-oriented cohesion metrics have been developed; many of them are based on the notion of degree of similarity of methods. No consensus has yet arisen as to which of these metrics best measures cohesion; this is a problem for software developers since there are so many suggested metrics, it is difficult to make an informed choice. This research compares various cohesion metrics with ratings of two separate teams of experts over two software packages, to determine which of these metrics best match human-oriented views of cohesion. Additionally, the metrics are compared statistically, to determine which tend to measure the same kinds of cohesion. Differences in results for different object-oriented metrics tools are discussed.

Fuzzy logic-based object-oriented methods to reduce quantization error and contextual bias problems in software development

During the last several years, a considerable number of software development methods have been introduced to produce robust, reusable and adaptable software systems. Methods create software artifacts through the application of a large number of heuristic rules. These rules are generally expressed in two-valued logic. In object-oriented methods, for instance, candidate classes are identified by applying the following intuitive rule: “If an entity in a requirement specification is relevant and can exist autonomously in the application domain, then select it as a class”. In this paper, we identify and define two major problems regarding how rules are defined and applied in current methods. First, two-valued logic cannot effectively express the approximate and inexact nature of a typical software development process. Although software engineers can perceive partial relevance of an entity and possibly select the entity as a partial candidate class, they are constrained by two-valued logic to quantize relevance into relevant and irrelevant. Second, the influence of contextual factors on rules is generally not modelled explicitly. We term these problems as quantization error and contextual bias problems, respectively. To reduce these problems, we propose to express heuristic rules using fuzzy logic. We illustrate formally how fuzzy logic-based methodological rules can help in lowering the effects of quantization error and contextual bias problems.

Static analysis of Lyee requirements

Software development has been suffering, for many decades, from the lack of simple and powerful methodologies and tools. Despite the tremendous advances in this research field, the crisis has still not been overcome and the proposed remedies are far from resolving the problems of software development and maintenance. Lately, a new and very promising methodology, called Lyee, has been proposed. It aims to automatically generate programs from simple user requirements. The purpose of this paper is, on the one hand, to provide a short and technical introduction to the Lyee methodology, and on the other hand, to show how some classical static analysis techniques (execution time and memory space optimization, typing, slicing, etc.) can considerably improve many aspects of this new methodology.

Structural analysis of the impact of knowledge creation and knowledge embedding on software process capability

Improving the capability of the development process has emerged as an important strategy for addressing recurring problems in software development, such as poor quality, high development costs, and long delivery lead times. While a number of normative software process models have been proposed, limited theory development has occurred. This study adopts a knowledge management perspective to examine the antecedents of software process capability. Synthesizing prior research in total quality management (TQM), software engineering and knowledge management, it is posited that creation of process knowledge and embedding the knowledge in the process are important antecedents of software process capability. Two models that relate these antecedents to software process capability are tested using data collected from information systems (IS) units in Fortune 1000 firms. The first model is a direct-impact model, which posits that both knowledge creation and knowledge embedding have a direct and positive impact on software process capability. The second model is a mediated-impact model, which posits that knowledge embedding completely mediates the relationships between knowledge creation and software process capability. The results provide strong support to the mediated-impact model suggesting that the extent to which knowledge is embedded in the process has a significant positive effect on software process capability. The results also suggest that the stock of knowledge embedded in the process is influenced by the extent to which knowledge is created in the context of the development process. Implications of these findings for IS research, theory, and practice are discussed.

An overview of program slicing

AbstractMARK HARMAN and ROBERT HIERONS review three semantic paradigms for slicing — static, dynamic and conditioned; and two syntactic paradigms — syntax‐preserving and amorphous. Slicing has been applied to many software development problems including testing, reuse, maintenance and evolution. This paper describes the main forms of program slice and some of the applications to which slicing has been put. Copyright © 2001 John Wiley & Sons, Ltd.

Informatics and professional responsibility.

Many problems in software development can be traced to a narrow understanding of professional responsibility. The author examines ways in which software developers have tried to avoid accepting responsibility for their work. After cataloguing various types of responsibility avoidance, the author introduces an expanded concept of positive responsibility. It is argued that the adoption of this sense of positive responsibility will reduce many problems in software development.