On Quality Attribute Based Software Engineering

For a software system to be perceived as a success, or even just as properly functioning, many quality attributes, besides functionality, need to be at an acceptable level. However, current software development processes focus on the functional aspects of a system to be developed. They hardly help to systematically engineer for quality attributes other than functionality. It is a system`s architecture by which such quality requirements are satisfied. In particular, software components are an incarnation of architectural means, which have come into being to better cope with the variety of quality aspects of software systems. Unfortunately, architectural artifacts appear somewhat magically sometimes, and so do components. Hence, components are not a major extension to OO in the programming language or conceptual modeling sense, but a basis to address many of the quality requirements, be they discernable or non-discernable at system runtime. CBSE, being the discipline of engineering with components, is a promising basis to more explicitly and systematically design with and for quality attributes. After defining the context and classifying quality attributes, we first illustrate the important relationship of quality attributes to use case realizations. Second, we argue for components as the fulcrum point for the realization of functional and extra-functional roles. Third, we identify ongoing research directions that we consider conducive towards a software engineering process that supports the design for functional and extra-functional requirements.

Foundations of systems and properties

Otto Preiss

Engineering of software-intensive systems is concerned with the creation and evolution of systems that shall exhibit desired properties in their execution as well as development environment. In this context, the motivation of this thesis, derived from current development practice, was twofold. Firstly, software development methods are increasingly required to extend their scope of applicability towards systems engineering. As a consequence, their modeling approaches must be able to cope with a larger diversity of systems and consequently a larger diversity of properties. But these approaches still need to provide a smooth transition to software modeling. Secondly, non-functional properties, which are largely a result of this implicit systems scope, play a major role in the way we design our software-intensive systems. The conceptual aids of current development methods, however, are still less mature in their explicit support for non-functional properties compared with their ability to support functional ones. The principal objective of this thesis is to contribute toward an improved model-based treatment of non-functional properties in development methods. Because we cannot discuss properties independently of the objects they are ascribed to, this objective amounts to a progression from modeling of software and its properties to modeling of interrelated systems and their properties. To address this aim a philosophy of properties and systems is proposed. The philosophy is expressed as a holistic conceptual model of properties and/of systems. It is complemented with some basic rules, which we call tenets. Tenets formulate how we use the philosophical knowledge. The conceptual model offers the foundations for a more generalized understanding of those fundamentally different types of systems and different types of properties that are relevant in software-intensive systems engineering. The generality of our holistic model draws the benefits from our investigations in the areas of systems science, cognitive science, and basic philosophy. The model helps to scrutinize and make sense of the large amount of data in the literature about "non-functional" issues in software engineering. The model is applicable in the derivation of methodological building blocks that can be incorporated into development methods. The building blocks include (a) a general model to discover stakeholders and properties for a given system, (b) a principled manner to trace the fundamentally different types of properties through hierarchies of systems, and (c) a proposal for the representation of systems, their properties and property traces in the UML. The concrete application of the gained knowledge to software engineering results in a proposal for a context-sensitive, customizable quality attribute model. It also results in a proposal on how to structure quality descriptions of software components. In order for such descriptions to be standardized and possibly tool-automated, this thesis proposes to utilize the Reusable Asset Specification and suggests alternatives for its XML-based representation.

EPFL2004

A Systems Perspective on the Quality Description of Software Components

Otto Preiss, Alain Wegmann

In this paper we present our motivations for proposing of a generic model for the description of quality attributes of software artifacts, in particular suited to software components. The conceptual ideas for our quality description model are derived from researching systems science for its value to software engineering. In this work we realized that software engineering is concerned with a number of different systems, e.g., a development project as a concrete, human activity, system, a software product in the form of programming code as a conceptual system, a software system running in its execution environment as a concrete system. Each of these systems exhibits the basic system theoretic principles and in the context of this paper is strongly related to certain types of qualities. Such qualities receive particular attention in the context of large software systems, where systems are typically a combination of in-house and third party products and are increasingly integrated by means of software component technology. Consequently, quality related information (in the form of a quality data sheet) is needed by component users to gain trust in and to evaluate the possible employment of a candidate component. Interestingly, the concept of a software component appears in most of the aforementioned different types of systems. Hence, they can be an excellent means to carry quality related information that belonged to different spheres up to now. The qualities range from those related to the development economics to those related to the execution performance.

2002

Modelling global behaviour with scenarios in object-oriented analysis

The first object-oriented analysis methods focused on the specification of the classes of a system and on the static relationships between them. Dynamic relationships between classes and the functional view of the system as a whole were neglected, and no models were offered for capturing system requirements. This changed with the publication of use case driven approaches such as OOSE (1992) and Fusion (1994). Modelling global behaviour by scenarios in both requirements analysis and design has since been adopted by many object-oriented methods. Scenarios are also called use cases, system operations or business processes, and they are modelled using different notations. Some of the analysis methods that use scenarios have common characteristics, namely i) the similarity of the relationship between the entities of a data model and the scenarios of a flat scenario model with a matrix, and ii) the assumption that the externally visible behaviour of the system can be subdivided into more or less independent scenario types. In the following, we will refer to these characteristics by the term matrix approach. While in many projects the matrix approach has been used successfully, several difficulties arise when more complex systems are modelled: relationships and similarities between different scenario types cannot be expressed, the dependencies between scenario types are not modelled, only one abstraction level can be represented, and the apparently seamless transition from the analysis to the design model may result in a low quality object model with a strong bias towards data modelling. These difficulties lead us to propose an enhanced scenario modelling technique (called SEAM) which overcomes some of the weaknesses of the matrix approach. This modelling technique includes composition, aggregation, specialisation and extension hierarchies of services, and is based on the paradigm of interacting objects (which can be atomic objects, subsystems or systems) offering services. Scenario types, showing the possible interaction sequences for a specific service, can be modelled on several abstraction levels, and can describe the services of any kind of object (and thus also the global behaviour of a whole system) from both an internal and external point of view. We describe the concepts and the notation of SEAM, and we show how it can be integrated into the Fusion method. The difficulties that may arise in projects using methods based on the matrix approach are not only due to the limitations of scenario modelling techniques. A major factor is the often contradictory definition of the analysis model goals, which leads to clashes of intent. Therefore we discuss the nature of such intent clashes and analyse how the different software development methods deal with them. Finally we give an overview of the various notations and basic concepts used by different scenario modelling techniques, and we provide summaries of current, mostly objectoriented, approaches to modelling global behaviour.

EPFL1997

Modelling global behaviour with scenarios in object-oriented analysis

EPFL1997

Foundations of systems and properties

Otto Preiss

EPFL2004