Traceability Maps as a Conceptual Tool for Managing Software Artifacts

Traceability Maps as a Conceptual Tool for Managing

Software Artifacts

Sven van der Meer1*, Joel Fleck2

1Waterford Institute of Technology, TSSG, Waterford, Ireland 2Hewlett Packard Company Office of Strategy and Technology, Murray Hill NJ, USA

1 [email protected], 2 [email protected]

Abstract. In this paper, we detail how integrated Traceability Maps for software systems can provide a tool improving change impact analysis and product lifecycle management. This work is based on previous publications on architectural artifacts and Traceability Maps for Contracts. Using the NGOSS Lifecycle, we show a simple language for Implementation View Contracts and use off-the-shelve analysis software to show the effects of a Traceability Map for static analysis. This work then provides the basis for runtime analysis of software systems. The paper concludes with a brief description of our current work on federation aspects, in other words maps of exposed parts of domains of software systems. This work is integrated into joint research on autonomic networks and systems, thus our use cases and examples are focusing on distributed, autonomic network management systems.

1 Problem Statement

Autonomic systems and networks provide a self-managed environment for business

services. This environment promises efficient control, focusing on challenges such as

increasing dynamicity, heterogeneity, reliability and scale. The capability of self-

management is bound to business goals, which the autonomic system or network has to

fulfill. Extensive research has been undertaken in the two areas of autonomic computing

(driven by the IBM paradigm) and autonomic communications (driven by several

communities, such as the Autonomic Communication Forum - ACF). Autonomic systems,

especially for application-aware network management, can benefit from both worlds, i.e.

control loop theory from computing and distributed management from communications.

Our work aims to optimize software systems that control and manage distributed

processes, namely communication networks. The problem here is twofold. First, business

goals need to be translated to network configurations, in order to allow an optimal usage,

control, adaptation and management of the business services. Second, the network

* This work is partially sponsored by Science Foundation Ireland under grant number 03/CE3/I405.

2 Sven van der Meer1 , Joel Fleck2

configuration needs to be related back to business goals in order to understand the impact

of the current configuration and other contextual information on the business goals. The

classic example, which is still very hard to realize, is that a management system should be

able to align an SNMP alarm to a customer’s SLA to understand if the Contract with the

customer has been violated or not, and to determine the proper actions to take.

2 Solution

Our solution targets the challenge of business-to-network and network-to-business

translation by specifying technological neutral, architectural artifacts; and describing the

relationships between artifacts of the same type and between types of artifacts [13]. The

resulting Traceability Map [12] facilitates the understanding of syntactical and structural

complexity of a software system. Analysis tools can then be used to detect equivalent

functionality, flaws in the design (static analysis) and impact of run-time events on

software artifacts (dynamic analysis) as well as impact of both configuration and context

changes in the runtime system. The result is an improved understanding of change impact

for the system design and deployment and an improved product lifecycle management.

Service ProviderSoftware Vendor

Physica

lLogica

l

Business

Run-time/Deployment Implementation

System

Business View Contracts(Concepts)

System View Contracts(Specifications)

Implementation View Contracts(Implementations)

Run-Time View Contracts(Instances)

1 to m

where m >= 0

1 to m

where m >=0

m to 1

where m >=1

m to 1

where m >=1

1 to m

where m >=1

m to 1

where m >=1

1 to m

where

m >=0

1 to m

where

m >=0

Fig. 1. Simple contract relationships used to generate a Traceability Map for Contracts. The figure

shows the (potential) relationships of Contracts between the NOSS Lifecycle Views.

The idea of a Traceability Map is developed from earlier work on the TM Forum’s

Next Generation Operations Software and Systems (NGOSS) Technological Neutral

Architecture (TNA) program [3]. The TNA identifies three main core Software Artifacts

(Contract, Policy, and Process) and aligns them with a Lifecycle supporting all aspects of

Traceability Maps as a Conceptual Tool for Managing Software Artifacts 3

a software system (Business, System, Implementation and Runtime/Deployment). Each

artifact can (and usually does) have a specific specification for each of the Lifecycle

dimensions. That means, a Contract has a Business dimension (user gets gold service), a

System dimension (the definition of what the system needs to do to provide gold service),

an Implementation dimension (how the system provides gold service) and a Runtime

dimension (services provide capabilities for user). Processes for each dimension sequence

the Contracts; and Policies govern the behavior of all Software Artifacts. The advantage

of this approach is that it provides traceability from the business definition and

understanding of the solution through its architecture, implementation and deployment

definition stages. Figure 1 shows the simple traceability relationships in the NGOSS

Lifecycle for the TNA Contract Software Artifact [14]. Recognizing that not only are

there traceability relationships between Lifecycle dimensions, but also within dimensions

(e.g., a Business View Contract may depend on numerous other Business View Contracts

and in turn may be depended on by others), a Traceability Map for Contracts throughout

the Lifecycle is constructed as illustrated in Figure 2 [15].

Business Run-time/DeploymentImplementationSystem

B1

B2

B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

System Contract Specifications

Dependencies (from SCs)

Dependencies (to SCs)

Derivations (from BCs)

Contract Implementations

Dependencies (from ICs)

Dependencies (to ICs)

Derivations (from SCs)

Run-Time/Deployment Contracts

Dependencies (from R-TDCs)

Dependencies (to R-TDCs)

Derivations (from ICs)

Notes: Solid Lines represent full derivations, Dashed lines partial derivations, Superscripted N Represents Normalized Contract Spec.

Fig. 2. Simple contract relationships, which are used to generate a Traceability Map for Contracts.

The figure shows the (potential) relationships of Contracts between the NOSS Lifecycle Views.

Although the initial work focused on the development of Traceability Maps for

Contract (actions), it was quickly recognized that similar maps could be constructed for

other core Software Artifacts (Policies and Processes) [16]. Taken individually, each of

these Traceability Maps is helpful in documenting and understanding relationships within

each Software Artifact type as well as identifying functional equivalencies. Autonomic

management, however, also requires an understanding of the relationships between

Software Artifacts. Thus we suggest constructing a linked Traceability Map, building on

the following observations about the core Software Artifact and use cases:


• use cases reference Policies, Processes and Contracts,

• core Software Artifacts reference other Software Artifacts (e.g., Contracts reference

Policies the govern them, Policies reference Policies, Processes and Contracts that

they govern, and Processes reference Contracts that they sequence), and

• no core Software Artifact is “stand-alone” (i.e., does not refer to or is not referenced

by another Software Artifact),

The resulting map additional provides a view of the relationships between core Software

Artifacts as illustrated in Figure 3.

Policy

ContractProcess

reference

reference

Software Artifact Traceability Map

Fig. 3. Linked Software Artifact Traceability Map, combining maps for each of the Software

Artifacts and providing an understanding of the inter-relationships between them.

The concept of a Traceability Map provides the tool to manage the end-to-end lifecycle

traceability while maintaining the linkage to traditional functional programming

interfaces. It employs use cases to describe the end-to-end problematic. A use case defines

a sequence of actions that describe an agreement between stakeholders (anyone with an

interest in or who is affected by the system) of the system. The agreement can be seen as a

description of the expected behavior of the system.

Use Case(s)

Specific Use CaseSpecific Use CaseSpecific Use Case Specific Use Case

Specific Use CaseSpecific Use Case

Specific Use CaseSpecific Use CaseSpecific Use Case

Policy

ContractProcess

referencereference

Software Artifact Traceability Map

reference to use cases and/ordeployed system (not shown here)

Fig. 4. Use cases linked with the Traceability Maps. The complete maps are associated to use cases

(and potentially deployed systems), allowing to relate to dynamic aspects of a software system.

Use cases can be nested into a hierarchy, which allows for the description of different

scenarios. Stakeholders are identified by means of roles. A use case should always


distinguish between a primary actor (stakeholder initiating an interaction) and other

stakeholders. System behavior is always focused on realizing the goals of all involved

stakeholders. Using the use cases as a grounding point, core Software Artifacts (Contracts,

Policies, and Processes) are defined and their relationships established. The resulting

Traceability Map with linkages/references to use cases is shown in Figure 4.

Of course, the core Software Artifacts are rarely managed or packaged individually, but

rather, to facilitate distribution, maintenance and composibility, Software Artifact

containers package (or encapsulate) related (at the container specifier’s discretion) core

Software Artifacts. The following encapsulations have been identified:

• Services, defined by software vendors or service providers, encapsulating Contracts,

• Components, defined by software vendors, which encapsulate Contracts (or

Services) and Policies,

• Applications, defined by service providers which encapsulate Contracts (or

Services), Policies, and Processes.

These Container Artifacts are, to some degree, present throughout the Lifecycle phases.

For example, an application takes the following manifestation in the Lifecycle phases;

application requirements (in Business View), application specification (in System View),

application implementation (or mapping to implemented Components, Policies and

Processes in the Implementation View), and application instantiation (or realization by

Contract instances and activated Policies and Processes in Run-time/Deployment View).

Container Software Artifact (Application, Component, Service)

Business ImplementationSystem

Runtime/

Dep loyment

Policy

Business ImplementationSystemRuntime/

Deployment

Contract

Business ImplementationSystemRuntime/

D eployment

Process

referencereference

map between Container fingerprintand core software artifact fingerprints

reference to use cases and/ordeployed system (not shown here)

Fig. 5. Management of Software Artifacts with Traceability Maps. This final figure shows the

complete concept of the Traceability Map for all considered Software Artifacts (Contract, Policy,

Process and Containers).

Combining all of these relationships, a Traceability Map providing the relationships

between all Software Artifacts (both container and core) and use cases and be developed

as shown in Figure 5.


The Traceability Map illustrated in Figure 5 provides sufficient information for

software designed in siloed, undistributed environments, but needs additional extensions

to cover both today’s distributed environments and the emerging world of Cloud

Computing or Software as a Service (SaaS). Building Traceability Maps for solutions

destined for these environments requires that the Traceability Maps also account for

federated domains across which these solutions might operate. A Federation is an

agreement (actually two agreements; an outx/iny and an iny/outx) between a Domainx and

an external actor (another Domainy) on the behavior between the two Domains. Therefore

the Federation can be described as a Use Case (actually two, one for each in/out pair). The

Federation Use Cases are realized by:

• Contracts exposed by Federation,

• Exposed Data (via the Contracts),

• Policies which govern behavior of Federation.

Domain

2

Domain

1

Domain

4

Domain

5

Domain

3

Federation(d1,d3)

Federation(d1,d2)

Federation(d2,d4)

Federation(d5,d4)

Federation(d1,d5)


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

PolicyBusiness Run-time/DeploymentImplementationSystem

B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference

referencereference

Federation Use Case

in1/ out2

Federation Use Case

in1/ out2


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference

referencereference

Federation Use Case

out1/ in2

Federation Use Case

out1/ in2

Federation Traceability Map


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference

referencereference

Federation Use Case

in1/ out2

Federation Use Case

in1/ out2


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference

referencereference

Federation Use Case

out1/ in2

Federation Use Case

out1/ in2



B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference

referencereference

Federation Use Case

in1/ out2

Federation Use Case

in1/ out2


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference

referencereference

Federation Use Case

out1/ in2

Federation Use Case

out1/ in2



B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference

referencereference

Federation Use Case

in1/ out2

Federation Use Case

in1/ out2


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference

referencereference

Federation Use Case

out1/ in2

Federation Use Case

out1/ in2



B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference

referencereference

Federation Use Case

in1/ out2

Federation Use Case

in1/ out2


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract

reference

referencereference

Federation Use Case

out1/ in2

Federation Use Case

out1/ in2


Business Run -time/DeploymentIm plementat ionSystem

B 1

B2

B 3

B4

B5

B 6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Business Run -time/DeploymentIm plementat ionSystem

B 1

B2

B 3

B4

B5

B 6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

NGOSS Container Software Artifacts

(Service, Component & Appl ication)

Map between Container DNA Fingerprint

and Core NGOSS Arti facts ’ DNA Fingerprints

NGOSS Use Case(s)NGOSS Use Case(s)


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Policy


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Process

reference

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Policy


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Process

reference

reference

referencereference

reference

NGOSS Detai led Case(s)NGOSS Detai led Case(s) NGOSS Detai led Case(s)NGOSS Detai led Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s)

Bu siness Run- time/De ploymentImplem entationSystem

B 1

B2

B 3

B4

B5

B 6

S1

S 2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1


B 1

B2

B 3

B4

B5

B 6

S1

S 2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1




and Core NGOSS Artifacts’ DNA Fingerprints



B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Pol icy


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Process

refe rence

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Pol icy


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Process

refe rence

reference

referencereference

reference

NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s)


B 1

B2

B 3

B4

B5

B 6

S1

S 2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1


B 1

B2

B 3

B4

B5

B 6

S1

S 2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1




and Core NGOSS Arti facts ’ DNA Fingerprints



B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Policy


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Process

reference

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Policy


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

Process

reference

reference

referencereference

reference

NGOSS Detai led Case(s)NGOSS Detai led Case(s) NGOSS Detai led Case(s)NGOSS Detai led Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s)


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

NGOSS Con tainer So ftware Artifacts

(Service , Comp onen t & Application)

Ma p b etween Co ntaine r DNA Fin gerprint

a nd Core NGOSS Art ifa cts’ DNA Finge rprints



B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Policy


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Pro cess

ref erence

ref erence


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Policy


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Pro cess

ref erence

ref erence

re ferencerefe ren ce

refere nce

NGOSS Detailed Ca se (s)NGOSS Detailed Ca se (s) NGOSS Detailed Case (s)NGOSS Detailed Case (s) NGOSS Detailed Case (s)NGOSS Detailed Case (s)


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

NGOS S Conta in er Sof twa re Artif acts

(Se rvice, Com po nen t & Ap plica tion)

M ap betwee n Conta in er DNA Fing erp rint

a nd Co re NGOS S Artifacts’ DNA Fing erprin ts



B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Po licy

Business Run-time/DeploymentImplementationSystemB1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Con tra ct


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

P ro ce ss

reference

reference


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Po licy

Business Run-time/DeploymentImplementationSystemB1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

Con tra ct


B1

B2B3

B4

B5

B6

S1

S2

S3SN4

SN5I3

I4

I2

I1

D4

D3

D2

D1

P ro ce ss

reference

reference

ref ere ncere ference

re ference

NGOSS Deta iled Ca se(s)NGOSS Deta iled Ca se(s) NGOSS Det aile d Case(s)NGOSS Det aile d Case(s) NGOSS De tailed Case(s)NGOSS De tailed Case(s)

Control Coordination

Fig. 6. Full Traceability Map for a distributed multi-domain solution. This figure emphasizes the use

of maps to understand, monitor and direct the federation of domains.

The Federation Artifact relationships are similar (lacking the Process Software Artifact) to

those of a Domain. Thus, each federation can also be represented by a Traceability Map

(similar to Figure 3.)

Full Domain Traceability Maps for each domain can then be constructed through the

Union of the Domain Traceability Map with the Intersections of the Domain Traceability

Map with each Federation Traceability Map for all Domain with which the selected

Domain is federated. The following algebra illustrates the Traceability Maps for a simple

five domain federated solution (Note: DVTMDomainx is a Full Domain View Traceability


Map for Domain x, TMDx is the Traceability Map for Domain x and TMF(Dx,Dy) is the

Traceability Map for the Federation of Domain x and Domain y):

DVTMDomain1 = TMD1 ∪ (TMD1 • TMF(D1,D2)) ∪ (TMD1 • TMF(D1,D3)) ∪ (TMD1 • TMF(D1,D5)) DVTMDomain2 = TMD2 ∪ (TMD2 • TMF(D1,D2)) ∪ (TMD2 • TMF(D2,D4)) DVTMDomain3 = TMD3 ∪ (TMD3 • TMF(D1,D3)) DVTMDomain4 = TMD4 ∪ (TMD4 • TMF(D2,D4)) ∪ (TMD4 • TMF(D4,D5)) DVTMDomain5 = TMD5 ∪ (TMD5 • TMF(D1,D5)) ∪ (TMD5 • TMF(D4,D5))

Using the above notation, a Traceability Map for the full multi-domain solution can be

defined the union of each of the Domain View Traceability Maps or:

FMDSTM = DVTMDomain1 ∪ DVTMDomain2 ∪ DVTMDomain3 ∪ DVTMDomain4 ∪ DVTMDomain5

Finally, a complex system of this type requires some type of centralized control to manage

and coordinate the Federations as illustrated in Figure 6. In addition the Control

Coordination function facilitates the management of policies that are common to a number

of different Federations.

The complete Traceability Map can then be defined as:

CTM = CCTM ∪ FMDSTM

(Note: CCTM is the Traceability Map for the Control Coordination capability.)

3 Experiment

We are at the very start of practical experiments with the above introduced concept of

Traceability Maps. The first experiment we carried out focused on a very simple case:

take a simple descriptive language, define a simple software system with it, generate code

in a programming language and finally analyze the complexity of the generated code with

off-the-shelf software.

We have used a descriptive language and a simple software system specified in it,

based on [17] and used as the basis for a meta-modeling approach in [18]. The language,

called Application Definition Language (ADL), allows to describe a software system with

combined middleware and management capabilities. Beside basic elements (such as

package, class, interface, action, parameter and attribute), the language introduces

property as a concept allowing to describe syntactical and semantic documentation for all

its elements. We have extended this property definition (originating in [17] to capture the

basic aspects of a Contract, resulting in the following BNF definition:

adlPropertySpec: PROPERTY IDENT ':'


AT_TYPE '(' base_type array? '=' const_value ')' ',' AT_ALTERABLE '(' (boolean_value) ')' ',' AT_SCOPE '(' propertyScope (',' propertyScope)* ')' ',' AT_APPLICABILITY '(' propertyApplicability ')' ',' (AT_DEPENDS_ON '(' IDENT (',' IDENT)* ')' ',')? (AT_NEGOTIABLE '(' boolean_value ')' ',')? (AT_PRIORITY '(' base_type '=' const_value ')' ',')? (AT_EVALUATE '(' propertyEvaluate ')' ',')* AT_DESCRIPTION '(' string_value ')'';'; propertyScope: '[' propertyScopeElem ',' propertyScopeRank ']'; propertyScopeElem: (PACKAGE | CLASS | INTERFACE | ACTION | ATTRIBUTE | PARAMETER); propertyScopeRank: (AT_REQUIRED | AT_MANDATORY | AT_OPTIONAL | AT_NOT_DEF); propertyApplicability: AT_PRE? AT_POST? AT_INVARIANT?; propertyEvaluate: AT_APPLICABILITY '(' propertyApplicability ')' ',' AT_LANGUAGE '=' IDENT ',' AT_CODE '=' string_value;

This allows to associate semantic information for each language element, otherwise

known as Contract. The following code segment shows three examples for defined

properties, Contact being descriptive, MinValue allowing to further constrain the usage of

language elements and Units providing additional information for a specific language

element:

property Contact: @type(string = NULL), @alterable(FALSE), @scope([package, @mandatory]), @description("… "); property MinValue: @type(long = 0), @alterable(TRUE), @scope([attribute, @optional], [parameter, @optional]), @description("…"); property Units: @type(string = NULL), @alterable(FALSE), @scope([attribute, @optional], [parameter, @optional]), @description("…");

The defined software system is based on the specification of the Middleware and

Application Management Architecture (MAMA), which was originally specified in [17]

and later used as foundation for a meta model for network management in the Celtic

project Madeira [18] and as an example for a Distributed Interface-oriented Architecture

(DIOA) in [3]. The definition includes basic managed elements, platform services and

specific management services.


Fig. 7. Dependency Graph, Composition and Slice Perspective

We have taken extended the original specification of a property by capabilities for

negotiation and design-by-contract-based evaluation. Next, we developed a parser and

applied technology specific transformation rules to generate JAVA code, and for testing

purpose also C++ code segments. For the JAVA code, we integrated that into a runtime

environment that is currently under development within WIT/TSSG. We then did feed the

generated JAVA code into a commercial software package that analyses the structure of

software systems (Structure 101 developed by Headway [19]). Our experimental system

comprises 34 specified properties, 1000 lines of ADL code specifying the software system

including 7 packages, 15 classes, 17 interfaces, 10 attributes (class variables), 99 actions

(function calls), 40 type definitions and 17 structures (a special type of type definitions,

very similar to C/C++ structures). The JAVA code generated is about 15,000. Overall, this

experiment focuses on the analysis of the complexity of the implementation view of a

fairly simple software system.

Figure 7 shows partial screen shots of the dependency graph. The upper part of Figure

7 shows the composition perspective, which allows to partition the system into clusters

and then analyze the clusters themselves and well as the dependencies between them. The


lower part of Figure 7 shows the slice perspective, which provides details on dependencies

between any instantiated object and interface of our system. Detailed information, i.e.

categories of references such as is_type, calls, references, are provided by the tool as well.

The analysis of the generated JAVA code shows that of the specified 34 properties,

only 28 are actually used. However, these 28 used properties are used roughly 2,500

times. The lower part of Figure 7 shows the complexity table with the specified properties

as columns and their instantiation per element of the software system in the rows. The

overall software system is structured by the tool into 9 partitions (using classes and

interfaces only) with between 2 and 446 properties being used between these partitions. In

other words, a very small set of specified properties results in a very large set of defined

(instantiated) properties, even for a relatively simple software system (with 28 to 2,500,

which means that every property is in average instantiated 90 times). Given that a realistic

software system would comprise much more than just 15 classes and 17 interfaces, the

manageability of Contracts clearly becomes an issue.

3.1 Limitations of the Experiment

Our experiment used a specific declarative language, extended the existing concept of a

property of that language, and developed a code generator for generating JAVA code. The

used specification of the software system is very specific to a distributed middleware

management system. The generated JAVA code is very specific to a particular runtime

platform. Other specifications and other constrains by the runtime platform will produce

different results. Furthermore, our experiment uses only the Software Artifact of Contract,

and this one only for the Implementation View. However, we can show that even with

these given limitations, the resulting software reaches a complexity that is difficult to

manage. The introduced concept of a Traceability Map will be a significant tool to

understand the specification and definition (implementation) and the instantiation and

association (runtime) of Software Artifacts.

4 Related Work

Our work was inspired by the original Design by Contract concept of Bertrand Meyer [1]

and the application of that concept within the NGOSS architecture [2,3]. Contracts as an

artifact have been widely used in software engineering since the introduction of the

concept. Beside adding contract facility to programming languages (as in Eiffel, or as

assertions and annotations), interesting work has been published on using the Design by

Contract concept to model and test software systems. Gupta et al. [4] describes a practical

approach for contract methods, using an object’s annotated structural representation

(based on a UML class diagram). Ramkarthik et al. [5] shows how Java contract code can


be generated from a formal notation, in this case Object Z. Giese [6] developed an

approach that “provides mechanism to achieve a higher degree of independence, to

exclude implicit implementation dependencies and make requirements and the provided

behavior of components more concrete”. In his approach, behavior is handled by external

specifications. With regard to the quality of a software system, Baudry et al. have

developed quality criteria (such as robustness and diagnosability in [7]) and approaches

for the detection of erroneous runtime states of executable contracts in [8]. The resulting

quality parameter is called vigilance and allows measuring the impact of contracts on a

software system. On a similar level of abstraction, Enselme et al. [9] studied the analysis

of hidden dependencies and the interactions of contracts. Lohmann et al. [11] demonstrate

how the concept of contract can be used on the level of modeling (as compared to code

level) and how visual mechanisms can help in the design of robust executable contracts.

Within communication systems, the NGOSS architecture has stimulated investigations

and studies focusing on contracts. Liu et al. [10] have identified non-functional

requirements for contract specifications, mainly focusing on quality management and

product evaluation. The concept of contracts and the NGOSS meta-model have been

adapted for peer-to-peer management systems in European efforts, such as [18].

5 Current Status and Next Steps

Our work focuses on the manageability of distributed software systems from a

technology-neutral, architectural perspective. Starting with the Software Artifact Contract

and applying ‘fingerprints’ to it [14], we have fine-tuned our approach and extended it to

cover multiple types of Software Artifacts within a single system and federations of

multiple systems. Beside the architectural sketch, we have started practical experiments

with descriptive languages and code generation to understand the practical impact.

The work we presented in this paper needs further work in three main directions. First,

the federation aspect of the Traceability Maps needs to be specified thoroughly. Second,

we are working on finalizing the language and the experimental code generation system,

to provide tools for the specification of Traceability Maps and the transformation of these

specifications into a runtime and deployment environment. Third we are investigating the

application of statistical and graph analysis [21] to build analysis tools allowing us to

manage the complexity of software systems using statistical analysis to identify domains

(also know as scope of control) and extending the models to cover the federation of

domains and enterprises. While our main focus has been directed on the Software Artifact

Contract, we clearly need to fully integrate the other core Artifacts (Policy, Process) and

the Container Artifacts (Application, Component and Service) into our work to provide an

analysis and management capability throughout linked Traceability Maps.

Last, but not least, we are actively engaging with the ACF and European research

projects [20] to disseminate the concept of Traceability Maps as a potential standard (in

the ACF) and as a hopefully valuable tool for communication systems.


References

1. Bertrand Meyer: Applying Design by Contract. IEEE Computer, 1992

2. TM Forum: NGOSS Architecture Technology Neutral Specification - Contract Description:

Business and System Views. TMF053B, TNA 6.3, November, 2006

3. TM Forum: NGOSS Technological Neutral Architecture. TMF053, TNA 6.3, November, 2006

4. Atul Gupta, Amit Raj: Strengthening Method Contracts for Objects, APSEC, 2006

5. Sowmia Ramkarthik, Cui Zhang: Generating Java Skeletal Code with Design Contracts from

Specifications in a Subset of Object Z, ICIS COMSAR, 2006

6. Holger Giese: Contract – based Component System Design, ICSS, 2000

7. Benoit Baudry, Yves le Traon, Jean-Marc Jézéquel: Robustness and Diagnosability of OO

Systems Designed by Contracts, METRICS, 2001

8. Yves le Traon, Benoit Baudry, Jean-Marc Jézéquel: Design by Contract to Improve Software

Vigilance. IEEE Transactions on Software Engineering, Vol. 32, Nr. 8, 2006

9. D. Enselme, G. Florin, F. Legond-Aubry: Design by contracts Analysis of hidden dependencies

in component based applications. Journal of Object Technology, Vol. 3, Nr. 4, 2004

10. Xiaoqing Liu, Manooch Azmoodeh, Nektarios Georgalas: Specification of Non-functional

Requirements for Contract Specification in the NGOSS Framework for Quality Management and

Product Evaluation, IEEE Fifth International Workshop on Software Quality (WoSQ'07), 2007

11. Marc Lohmann, Stefan Sauer, Gregor Engels: Executable_Visual_Contracts. Proceedings of the

2005 IEEE Symposiumon Visual Languages and Human-Centric Computing (VL/HCC), 2005

12. Sven van der Meer, Joel J. Fleck II, Martin Huddleston, David Raymer, John Strassner, William

Donnelly: Manageability of Autonomic Software Artifacts using Contracts and Traceability. in

Proc. of 2nd IEEE International Workshop on Modelling Autonomic Communications

Environments (MACE 2007), San José, United States, October 29-30, 2007

13. Sven van der Meer, Joel J. Fleck II, Martin Huddleston, David Raymer, John Strassner, William

Donnelly: Technology Neutral Principles and Concepts for Autonomic Networking. in Book:

Advanced Autonomic Networking and Communication, Birkhäuser: 2008

14. Joel J. Fleck II, Sven van der Meer: NGOSS Contracts (TMF053B) - LifeCycle and Fingerprint

Specifications. TM Forum Team Meeting, Waterford, Ireland, March 21-24, 2006

15. Joel J. Fleck II, Sven van der Meer: NGOSS Contracts (TMF053B) - Contract Architectural

Specifications. Team Action Week America 2006, Boston, United States, July 16-20, 2006

16. Joel J. Fleck II, Sven van der Meer, Martin Huddleston: NGOSS Contract Fingerprints - A Tool

for Identifying and Facilitating Re-Use of NGOSS Contracts. TeleManagement World Americas

2006, Dallas, United States, December 4-7, 2006

17. Sven van der Meer: Middleware and Application Management Architecture. Multicon, Technical

University Berlin: September, 2002, ISBN 3930736020

<http://edocs.tu-berlin.de/diss/2002/vandermeer_sven.htm>

18. R. Carroll, E. Lehtihet, C. Fahy, S. van der Meer, N. Georgalas, D. Cleary: Applying the P2P

paradigm to management of large-scale distributed networks using a Model Driven Approach. in

10th IEEE/IFIP NOMS 2006, Vancouver, Canada, April 3-7, 2006

19. Headway Software: Structure 101. <http://www.headwaysoftware.com>

20. Joel J. Fleck II, Sven van der Meer: Traceability Maps: Their Construction and Application to

Autonomic Systems. Joint ACF, AUTOI, EMANICS Workshop on Autonomic Management in

the Future Internet, Barcelona, Spain, May 14, 2008

21. Réka Albert, Albert-Lészló Barabási: Statistical mechanics of complex networks. The American

Physical Society, Reviews of Modern Physics, Vol. 74, January 2002

Date post:	10-Nov-2023
Category:	Documents
Upload:	independent
View:	0 times
Download:	0 times

Traceability Maps as a Conceptual Tool for Managing Software Artifacts

Documents