Systems development life cycles and methodologies guide the development of software, services, and other products and may serve other purposes within an organization. For example, t

Softw Syst Model (2013) 12:439–440 DOI 10.1007/s10270-013-0362-4

EDITORIAL

Model-based lifecycle management of software-intensive systems, applications, and services

Robert France · Bernhard Rumpe

Published online: 18 June 2013 © Springer-Verlag Berlin Heidelberg 2013

The lifecycle of a successful system is the time period that covers all activities associated with developing, configuring, deploying, operating, and retiring the system. Variations in system lifecycles can be expected, for example, differences may arise as a result of the inclusion of physical parts in the system and the number of installations. In addition, software retirement activities may extend over a long period of time, for example, in cases where access to data provided by a system may be required long after the system is terminated.

Lifecycle management has a lot to do with managing the available information about a system. A significant amount of this information can typically be found in the models pro- duced during various development. Software models can thus play a vital role in system lifecycle management. For exam- ple, requirement models can be used to support management of requirements, feature models can be used to manage sys- tem and user specific variabilities as well as commonalities, and architecture and design models can provide information that support management of deployment and validation activ- ities. The potential role that models can play in lifecycle man- agement raises the following questions: “To what extent do the models produced during software development help (or hinder) lifecycle management?” “Should the software mod- eling activity be integrated with the lifecycle management of systems, and, if yes, how can this be done?” “What tools are needed to better leverage the use of models in lifecycle man- agement?” “Does a model also have a lifecycle that needs to be managed?”

R. France Colorado State University, Fort Collins, Colorado, USA

B. Rumpe (B) RWTH Aachen University, Aachen, Germany e-mail: [email protected]

A variety of models may be needed to support lifecy- cle management, each describing a particular aspect of the system for particular lifecycle management purposes. In such situations, it is important to have an understanding of how the models relate to each other. Such an under- standing is needed, for example, to develop appropriate technologies for maintaining consistency across the models and for managing the propagation of changes across the models.

In various conferences, workshops and discussions, we have observed the following model and language integration trends:

• Integration of heterogeneous models and of their cor- responding modeling languages remain a challenging research problem. For example, the many semantic vari- ation points in the UML make it difficult to produce an integrated, semantically coherent language in which the variation points are resolved in a consistent manner. It may also be the case that the manner in which the UML notations are integrated vary, leading to the need to sup- port variations on the forms of integration.

• Providing effective support for model evolution is still a pressing problem. Some of the challenging problems include developing support for semantic differencing (diffing) and merging of models. For graphical model- ing languages, the lack of support of modularity and encapsulation in modeling languages, as well as their two-dimensional graphical nature, presents challenges; comparing text on a line basis is much easier than com- paring model elements arranged in graph structures.

• The need to provide support for tracing information through various models is widely appreciated, particu- larly in software evolution activities. We suspect that this problem is best tackled by developing language-specific

123

440 R. France, B. Rumpe

solutions, rather than general solutions that are language agnostic.

• Language and model integration is particularly chal- lenging when there is a need to model non-software aspects of a system. For example, in the domain of cyberphysical systems, language integration involves providing the means to integrate underlying “commu- nication” paradigms, namely calculi from control the- ory, physics, and engineering disciplines with the digital state based theory from computer science. Such integra- tion should lead to better model-based lifecycles of these systems.

• We anticipate that a variety of domain specific lan- guages will be more widely used in software development projects, and thus support for integrating DSLs with gen- eral purpose modeling and programming languages will be needed.

• Variability of hardware and software is often handled externally to modeling languages, but it may be more effective to provide support for such variability within the languages. An approach to managing variability in pro- duct lines that is built on top of modeling languages may help to some extent, but a language-integrated approach that leverages context conditions and language semantics may be more effective.

• Semantic integration of models is furthermore needed in situations in which integrated models are used as the basis for static or dynamic analysis (e.g., formal analysis of functional properties and simulation). Few integration techniques adequately address semantic issues.

• Recent research has focused on the use of models at run- time to support runtime adaptation of software. For exam- ple, in plant control systems an explicit representation of the controlled plant that faithfully captures monitored aspects of the plant can be used as the basis for adapt- ing the plant control software. Runtime models cannot be distinguished anymore from requirements and design models produced during development, in terms of the abstractions they embody. From this perspective, the life- cycle of requirements and design models extends beyond the development and maintenance phase into the ope- rational phases. In fact, using these models at runtime makes the models an integral part of the operation of the system, while at the same time, enables evolution of the running system through evolution of the runtime models. This integrated co-evolution can be viewed as a form of lifecycle management based on these models.

In summary, the use of models in system lifecycle manage- ment raises interesting and challenging research opportu- nities. Furthermore, we in the software and system model- ing community cannot ignore lifecycle management issues: As the use of models becomes more widespread, the need for lifecycle management of models will become necessary. Sound lifecycle management of development artifacts is a core competence of integrated software-intensive systems development and becomes even more pressing in the con- text of globalized software development environments.

123

Copyright of Software & Systems Modeling is the property of Springer Science & Business Media B.V. and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Software Development Practices and Software Quality: A Survey Kassab, Mohamad;Neill, Colin;Laplante, Phillip Software Quality Professional; Sep 2014; 16, 4; ProQuest Central pg. 36

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

The Journal of Systems and Software 68 (2003) 199–215

www.elsevier.com/locate/jss

Bridging models across the software lifecycle

Nenad Medvidovic a,*, Paul Gr€uunbacher b, Alexander Egyed c, Barry W. Boehm a

a Computer Science Department, University of Southern California, Los Angeles, CA 90089-0781, USA b Systems Engineering and Automation, Johannes Kepler University Linz, 4040 Linz, Austria c Teknowledge Corporation, 4640 Admiralty Way, Suite 231, Los Angeles, CA 90292, USA

Received 23 December 2002; accepted 27 December 2002

Abstract

Numerous notations, methodologies, and tools exist to support software system modeling. While individual models help to

clarify certain system aspects, the large number and heterogeneity of models may ultimately hamper the ability of stakeholders to

communicate about a system. A major reason for this is the discontinuity of information across different models. In this paper, we

present an approach for dealing with that discontinuity. We introduce a set of ‘‘connectors’’ to bridge models, both within and

across the ‘‘upstream’’ activities in the software development lifecycle (specifically, requirements, architecture, and design). While

the details of these connectors are dependent upon the source and destination models, they share a number of underlying char-

acteristics. These characteristics can be used as a starting point in providing a general understanding of software model connectors.

We illustrate our approach by applying it to a system we have designed and implemented in collaboration with a third-party or-

ganization.

� 2003 Elsevier Inc. All rights reserved.

Keywords: Software model; Software requirements; Software architecture; Software design; Refinement; Traceability; Model connector

1. Introduction

Software engineering researchers and practitioners

have developed a plethora of models that focus on dif- ferent aspects of a software system. These models fall into

five general categories: domain, success, process, product,

and property models. Numerous notations, methodolo-

gies, and tools exist to support models in each category.

For example, within the last decade, the heightened in-

terest in software architectures has resulted in several

product and property models based on architecture de-

scription languages (ADLs), architectural styles, and their supporting toolsets (Medvidovic and Taylor, 2000;

Perry and Wolf, 1992; Shaw and Garlan, 1996).

Models are an indispensable tool in software devel-

opment. They help developers curb system complexity;

they also help the many stakeholders in a project convey

their concerns to other stakeholders in a manner that is

* Corresponding author.

E-mail addresses: [email protected] (N. Medvidovic), [email protected]

uni-linz.ac.at (P. Gr€uunbacher), [email protected] (A. Egyed), [email protected]

sunset.usc.edu (B.W. Boehm).

0164-1212/$ – see front matter � 2003 Elsevier Inc. All rights reserved.

doi:10.1016/S0164-1212(03)00063-3

understandable and that will ensure the proper treat-

ment of those concerns. However, the preponderance of

models actually renders the ultimate goal of develop-

ment––implementing dependable software––more diffi- cult in many ways. The reason for this is the

discontinuity of information across different models. For

example, a system�s requirements might be described

using use-case scenarios and entity-relationship dia-

grams, while its design may be captured in class, object,

collaboration, and activity diagrams. The problem,

then, is twofold:

1. ensuring the consistency of information across mod-

els describing the same artifact (e.g., a class instance

in object and collaboration diagrams in a design), and

2. ensuring the consistency of information across mod-

els describing different artifacts (e.g., use-cases in a

system�s requirements and classes in its design).

In both cases, each model provides (different) infor- mation in different ways, making it very difficult to es-

tablish any properties of the modeled phenomena as a

whole.

200 N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215

In principle, this discontinuity among models can be

dealt with by employing synthesis and analysis. Synthe-

sis enables one to generate a new model (e.g., collabo-

ration diagram) from an existing model (e.g., class

diagram), while analysis provides mechanisms for en-

suring the preservation of certain properties across (in- dependently created) models. Software engineers

extensively employ both kinds of techniques. For ex-

ample, program compilation involves both the analysis

of the syntactic and semantic correctness of one model

(source code) and the synthesis of another model from it

(executable image).

Synthesis and analysis techniques span a spectrum

from manual to fully automated. Manual techniques tend to be error prone, while fully automated techniques are

often infeasible (Partsch and Steinbruggen, 1983). Fur-

thermore, in some cases one technique (e.g., analysis) is

easier to perform than another (synthesis). For this rea-

son, one typically must resort to using some combination

of synthesis and analysis techniques of varying degrees of

automation when ensuring inter-model consistency.

The focus of our previous work was on identifying and classifying different categories of models and pro-

viding support for specific models within each category

(e.g., requirements models (Boehm et al., 1998), archi-

tecture models (Medvidovic et al., 1999), and design

models (Egyed and Medvidovic, 2000)). This paper dis-

cusses a set of techniques we have developed to bridge the

information gap created by such heterogeneous models.

In many ways, we view the problem of bridging het- erogeneous models as similar to the one that has recently

generated much interest in the software architecture

community: a software architecture can be conceptual-

ized as a diagram consisting of ‘‘boxes,’’ representing

components, and ‘‘lines,’’ representing component rela-

tionships (i.e., connectors); while we may have a more

complete understanding of the components, many of the

critical properties of a software system are hidden within its connectors (Mehta et al., 2000; Shaw, 1993). Similarly,

the individual models produced during a software sys-

tem�s lifecycle comprise the ‘‘lifecycle architecture’’

boxes; the properties of these individual models are typ-

ically well understood. Much more challenging is the

problem of understanding and providing the necessary

support for the lines between the boxes, i.e., the model

‘‘connectors.’’ The work described in this paper focuses on model

connectors traditionally associated with the ‘‘upstream’’

activities in the software lifecycle: requirements, archi-

tecture, and design. In particular, we have devised a set

of techniques for bridging

1. requirements and architecture models,

2. architecture and design models, and 3. different design models, both at the same level and

across levels of abstraction.

As this paper will demonstrate, each of the three cases

introduces its own issues and challenges. Moreover, for

practical reasons, our investigation to date has focused

on a limited number of models. Nevertheless, we have

been able to successfully develop and combine a set of

model connectors that allow us to start with a high-level requirements negotiation and arrive at a low-level ap-

plication design in a principled manner. In the process,

we have developed a novel, light-weight technique for

transferring requirements into architectural decisions.

We have also introduced a model transformation

framework that supports multiple views of a system�s design.

The results outlined above are specific to our ap- proaches to requirements, architecture, and design

modeling. However, we have leveraged this experience,

along with existing literature on software model trans-

formations, to devise a set of shared principles we be-

lieve to be model-independent. In particular, we classify

the properties of model connectors and relationships

among individual elements of different models. We il-

lustrate these properties and relationships both via ex- amples drawn from our work and from well-understood

software transformation techniques (e.g. compilation).

The remainder of the paper is organized as follows.

Section 2 introduces the notion and properties of model

connectors. Section 3 outlines the example application

we will use for illustration throughout the paper. Sec-

tions 4–6 briefly introduce the requirements, architec-

ture, and design modeling approaches we developed in the past and used as the basis of this work, and then

provide in-depth discussions of the model connectors we

have developed for bridging them. Due to the scope of

our work and number of model connectors we have

developed, at times we are forced to omit some of the

techniques� details and convey their general flavor to the

reader instead. Section 7 revisits the general properties

of software model connectors we have identified and ties them to the examples discussed throughout the paper. A

discussion of related work and conclusions round out

the paper. It is important to note that our approach does

not assume any particular lifecycle model (e.g., waterfall

or spiral) or software development process. The se-

quential ordering of lifecycle activities implied by the

paper�s organization (Sections 4–6 in particular) was

adopted for presentation purposes only.

2. Connecting the software lifecycle

When we speak of models, diagrams, or views, we

mean any form of graphical or textual depiction that

describes the software system itself and/or decisions

about the system made along the way. Models may be described separately, but they are not independent of

one another. Models may be created individually and

N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215 201

validated for syntactic and even semantic correctness

within a given context. However, models are interde-

pendent because they must somehow reflect the general

objectives of the software system under development.

Successful modeling thus requires more than generating

and validating individual models––it is also about en- suring the consistency of all models with the general

objectives of the software system.

This paper discusses ways of bridging information

across models. Connectors between models satisfy two

primary goals:

1. they are able to transform model information (a form

of model synthesis) or 2. they are able to compare model information (a form

of model analysis).

In both cases, model connectors maintain consistency

by helping to transform or compare the information two

or more models have in common. When we talk about

model transformation and comparison in the context of

this work, we really mean ‘‘inter-model’’ transformation and comparison, that is, transformation and compari-

son between separate models, diagrams, or views with

the primary goal of ensuring a common objective. Al-

though this paper discusses various instances of bridging

model information across the software lifecycle, we must

emphasize that the key contribution of this work is not

those instances, but rather their combined, collective

properties. The most generic property of a model con- nector is that it re-interprets information. Re-interpre-

tation is a fundamental requirement for model

connectors in order to baseline the relationships between

models to overcome syntactic and semantic differences

between them.

This paper will show that model connectors can have

very unique implementations. However, we will also

show that there are some common ways of categorizing their differences by using a set of properties. In partic-

ular, model connectors may be directional in that one

type of model can be transformed into another type of

model, but perhaps not vice versa; model connectors

may also only be partially automatable or reliable (i.e.,

‘‘trustworthy’’). We will discuss in this paper that some

of those properties apply to model connectors directly

whereas other properties apply to the modeling elements they bridge. For instance, modeling elements belonging

to different models may complement or outright con-

tradict one another. Sometimes, one modeling element

may relate to exactly one element in another model (1-

to-1 mapping); or the mappings may be more complex

(i.e., many-to-many mappings). In creating and vali-

dating model connectors, one has to define and analyze

these properties. As an illustration of these properties, the next section will introduce an example. The follow-

ing sections will then outline some connectors between

different models developed in the context of this exam-

ple. We will then revisit the general properties of model

connectors.

3. Example application

We use an example application to illustrate the con-

cepts introduced in this paper. The application is moti-

vated by the scenario we developed in the context of a

US Defense Advanced Research Project Agency

(DARPA) project demonstration and recently refined in

collaboration with a major US software development

organization. The scenario postulates a natural disaster that results in extensive material destruction and casu-

alties. In response to the situation, an international

humanitarian relief effort is initiated, causing several

challenges from a software engineering perspective.

These challenges include efficient routing and delivery of

large amounts of material aid; wide distribution of

participating personnel, equipment, and infrastructure;

rapid response to changing circumstances in the field; using existing software for tasks for which it was not

intended; and enabling the interoperation of numerous,

heterogeneous systems employed by the participating

countries.

We have performed a thorough requirements, archi-

tecture, and design modeling exercise to address these

concerns. We have also provided a partial implementa-

tion for the resulting system (referred to as ‘‘cargo router’’). This implementation is an extension of the

logistics applications discussed in Medvidovic et al.

(1999).

4. Software requirements model connectors

4.1. Modeling software requirements

During requirements engineering, the needs, expec-

tations, constraints, and goals of a project�s stakeholders

have to be gathered, communicated, and negotiated to

achieve a mutually satisfactory solution. We have de-

veloped the WinWin approach for collaborative re-

quirements negotiation and successfully applied it in

over 100 real-client projects (Boehm et al., 1998; Boehm et al., 2001). WinWin defines a model guiding the ne-

gotiation process: stakeholder objectives and goals are

expressed as win conditions; known constraints, prob-

lems, and conflicts among win conditions are captured as

issues; options describe possible alternative solutions to

overcome the issues; if a consensus is achieved among

stakeholders, agreements are created. We have re-

cently enhanced the WinWin approach and have used a COTS groupware environment as its implemen-

tation substrate (GroupSystems, 2001). The result,

202 N. Medvidovic et al. / The Journal of Systems and Software 68 (2003) 199–215

‘‘EasyWinWin,’’ supports brainstorming, categoriza-

tion, and prioritization of win conditions, identification

and resolution of conflicts, as well as collaborative

characterization of application domain properties (Bo-

ehm et al., 2001; Gr€uunbacher and Briggs, 2001).

A team of stakeholders used EasyWinWin to gather, negotiate, and elaborate requirements for the cargo

router system. In the first round of requirements nego-

tiation the team came up with 64 win conditions, which

provided a starting point for further negotiation and

architectural refinements. Fig. 1 shows a snapshot of the

EasyWinWin negotiation tool: WinWin artifacts are

organized in a tree and marked with artifact type and

stakeholder tags (top pane); a voting tool is used to aid the transformation of software requirements into an

architecture, as discussed