WASE SQM

Lecture-3
Course No. : SEWP ZG661
Title : Software Quality
Management

DATE :09th August 2009

Prof.N.Prasanna Balaji
B.E(CSC),M.Tech(IT),MBA(OM),Ph.D(ERP)

LMCSI, LMISTE, MIEEE, MAIMA

email:[email protected]
Software process (simplified
view)

software configuration requirements engineering

management

assurance
quality
programming-in-the-large

programming-in-the-small
 Definitions
• An architecture is the set of significant decisions about the
organization of a software system, the selection of the structural
elements and their interfaces by which the system is composed,
together with their behavior as specified in the collaborations among
those elements, the composition of these structural and behavioral
elements into progressively larger subsystems, and the architectural
style that guides this organization.
[Booch, Rumbaugh, Jacobson 1999]
• Configuration management is the process of identifying
and defining the items in the system, controlling the changes
to these items throughout their life cycle, recording and reporting
the status of items and change requests, and verifying the
completeness and correctness of items.
[IEEE 1983]
Or: the discipline of controlling the evolution of complex software
systems
[Tichy 1988]
 Questions/goals
• Investigate the borderline between software architecture and
SCM
– Product space
– Version space
• Investigate the division of labor between ADL tools and SCM
systems
– To what extent may an ADL tool rely on services provided
by an SCM system?
– To what extent should an SCM system already incorporate
support for software architecture?
 Questions/goals
– From the perspective of an ADL tool builder:
• What are the requirements to SCM services?
• In what respects do current SCM systems not (or not
adequately) address these requirements?
Architectural Description Languages
(ADLs)
Architecture
Tool Support
Modeling Features
• Active
• Components
Specification
– Interface, Types,
Semantics, • Multiple Views
Constraints, • Analysis
Evolution
• Refinement
• Connectors
• Code Generation
– Interface, Types,
Semantics, • Dynamism
Constraints,
Evolution [Medvidovic and Taylor 1997]
Architectural Description Languages
(ADLs)
Architectural
Tool Support
Configurations
– Understandability, • Active
Compositionality, Specification
Heterogeneity, • Multiple Views
Constraints,
Refinement and
• Analysis
Traceability, • Refinement
Scalability, Evolution, • Code Generation
Dynamism
• Dynamism

[Medvidovic and Taylor 1997]

ADL Examples (1): UML ViewWindowManager
viewWindowNames : Array
viewWindowDescriptions : HashMap
viewWindowImplementations : HashMap
ReprElement
1..* openViewWindow()
removeViewWindow()
getViewWindowNames()
getViewWindowDescription()
retrieveInstalledViews()
SubRepresentation

getContentPane()

View -openViewWindows 0..*

viewName : String ViewWindow
getName() -openViews open()
incrementalUpdate()
close()
completeUpdate() 1..*
attachView()
closed()
detachView()
attach()
detach()

#unparser
<<Interface>>
GraphFilter Unparser
(from fil ters)
incrementalUpdate()
completeUpdate()
 ADL Examples (2): Acme
[Garlan et al. 1997] configuration
connector

component

representation representation
variant variant
ADL Examples (3): Wright [Allan
and Garlan 1997]
component Client =
port Request = ...
...

component Server =
port Provide = ...
...
specification
of semantics
connector Service =
role Client = request!x  result?y  Client  
role Server = invoke?x  return!y  Server  
glue = Client.request?x  Server.invoke!x
 Server.return?y  Client.result!y  glue

ADL Examples (4): Ménage
[van der Hoek et al. 1997]
revision
ADL Examples (4): Ménage
[van der Hoek et al. 1997]

variant
variant

optional
component
Software configuration management

• Deals with items = software objects

and their relationships,
objects are typed: source/derived,
atomic/composite, etc.
• Composition of these elements into
configurations
• Version control (evolution of objects,
relationships, and configurations)
Software configuration management

• Representation of software
architectures
– Make files
– System models dealing with
• design objects
• arbitrary software objects
 System models for design
objects (1):
Adele I [Estublier 1984]
manual m2_i2_v2
selimp
built-in m4-i2-v1.05
system selcond
modeling >*(syst = unix)
language >* (connect = pipe)
seldef
>* (type = debug)
attributes
type = debug
syst = unix
author = Jim
state = experimental
date = 84_05_13
end
 System models for design objects (2):
Adele II [Estublier 1994]
type Interface is Object;
common
system : {unix, hp, vms};
graphics : {x11, open_win};
user- modifiable
defined belong-to : Conf;
versioned bug-reports : set_of Document
object immutable
type header : File;
realization : versioned
Realization;
end;
System models for arbitrary
software objects:
PCL [Tryggeseth et al. 1995]
family foo
attributes os : {Unix, VMS, DOS};
...
end
parts
root  main;
files 
if os = Unix then unix_fs
elsif os = VMS then vms_fs
else dos_fs;
...
end
end
 Comparison of software
architecture and SCM
software architecture SCM

coverage programming-in-the-large whole lifecycle

(high-level design)
software components, modules, all kinds of software objects
objects classes, ...
relationships inheritance, import, port all kinds of relationships
connections, ...
semantic level high (syntactic or semantic fairly low
consistency)
granularity overall organization, but overall organization
also detailed interface (software objects as black
descriptions boxes)
versions variants variants and revisions

version selection usually hard-wired rule-based

 Thesis 1 Architectural design
vs. the whole lifecycle
Software architecture and SCM overlap since they both deal
with the overall organization of a software system. However,
while software architecture refers to programming-in-the-large,
SCM addresses the whole software lifecycle.
software configuration

requirements engineering
management

assurance
quality
programming-in-the-large

programming-in-the-small
 Thesis 2 Tool integration -
bottom-up or top-down
The relation between software architecture and SCM can be
studied under different assumptions concerning tool integration.
It makes a big difference whether we assume bottom-up or
top-down integration.

architectural SCM system 1

design tool 1

... ...

architectural SCM system n

design tool m
Thesis 3 Different system
description languages
Since there are many architectural description languages
with different syntax and semantics, an SCM system
must not prescribe a specific language for describing
software architectures.

In contrast, the software architecture description has to be

handled like any other document.
Thesis 4 Unavoidable redundancy in
system descriptions

Under the constraints of bottom-up integration, there is no hope

to unify software architectures and software configurations in the
sense that only a single, integrated description needs to be
maintained.

A certain amount of redundancy is therefore inevitable.

 Thesis 5 Planned evolution is
easy
Architectural design deals with architectural evolution at a
semantic level. In particular, variants can be represented within
the software architecture description (as realization variants,
subclasses, or instances of generic modules). In the way, planned
evolution may be taken care of.
 Thesis 6 Unplanned evolution is
hard
SCM offers general version control services for all kinds of
applications. These address not only variants, but also revisions.
Version control is performed at a fairly low semantic level. The
SCM system deals with versioning of the architecture, covering
in particular unplanned evolution.
 Thesis 7 Evolution at different
abstraction levels
Altogether, the evolution of software architectures has to be dealt
with at two levels: “structured” version control within the
architecture (planned changes) and “unstructured” version control
of the architecture (unplanned changes). These two levels
complement each other and cannot be unified easily.
 Summary: Spectrum of
modeling alternatives

• Standard design languages, such as

UML, SDL, etc.
• Make files (composition, dependencies,
derivation),
can be partly extracted from source
code
 Summary: Spectrum of
modeling alternatives
• Simple system modeling languages
from SCM systems:
Adele, PCL, DSEE, etc.
general objects/relationships, version
support
• Richer architectural languages:
Acme, Wright, Ménage, etc.
design objects, relationships, rich
semantics
 Interplay between software
architecture and SCM

• Redundancy cannot be avoided

– How to keep consistency between
architectural configurations and SCM
configurations?
– How to select the appropriate level of
granularity?
 Interplay between software
architecture and SCM
• Potential problems of current SCM
systems from the perspective of ADL
tool builders
– SCM version model does not match the
needs of an ADL tool
– SCM version control is performed at a low
semantic level
– SCM system enforces its own ADL
 Interplay between software
architecture and SCM
• Desired features of SCM systems:
– Customizable support for representing
design objects and their relationships
– More flexible version model
Raise the semantic level of version and
configuration control
 Source references

Software Architecture and

Software Configuration Management by
Bernhard Westfechtel and Reidar Conradi
RWTH Aachen, Germany/
NTNU Trondheim, Norway