10/13/2012

Targeted audience
Project leaders Systems analysts Software engineers Technical managers

with involvement in process improvement

activities.

Prerequisites:
knowledge and experience in software

engineering.

10/13/2012

Course contents

Module 1: Identification of reuse opportunities. Module 2: Domains and system families. Module 3: Component based engineering. Module 4: Reuse in an organizational context. Module 5: Evaluation of reuse costs, benefits and risks. Module 6: Development of a reuse strategic plan. Module 7: State of Practice in implementing reuse. Module 8: Conclusion.

Module1

10/13/2012

Why reuse?
Reuse is not an end in itself. Reuse motivation is ultimately economic (it is an investment). Reuse increases predictability in the software process, opening of new business opportunities and reduces costs and time-tomarket. Reuse is part of the natural industrialization process of software development. Reuse exploits the similarities in a domain.

Limitations of informal reuse

Success may not be repeatable Limited to inner-project reuse Only among a small number of developers and with small applications Very dependable on people initiative Limited life of reusable assets if there is no maintenance and support for them

10/13/2012

Systematic Reuse
Definition: The disciplined use of existing reusable assets in the development of new systems in a given business area or domain to achieve substantial benefits in business capability and performance.

Systematic reuse
Understanding contribution to achievement of business goals. Having a defined technical and management strategy to achieve those goals. Integration into the software process and part of process improvement initiative. Availability of resources (skilled staff, tools, etc.). Using adequate measurements to control reuse performance.

10/13/2012

Systematic Reuse & the Software Factory

Software factories are about reusing patterns, frameworks, tools, templates, requirements, tests, instrumentation, process guidance, and many other assets used throughout the software life cycle, in a systematic, rather than ad hoc fashion, not about stamping out endless copies of the same thing
Jack Greenfield, Microsoft

Systematic reuse is part of a natural and irreversible industrialization process in the software-intensive industry

What is an asset?

Oxford Dictionary definition: Assets are possessions having a value. In the context of a software organization:
A work product with a potential value for the

organization that can be used (and re-used) in its operations (software development). A software artifact explicitly intended to provide a return on investment through re-use*

Assets are products and must be managed as such. Can be re-engineered from legacy. Assets include all kind of work-products.

10/13/2012

Kinds of assets
Product assets: related with (partial) results of the software life-cycle. E.g., test cases, etc. Process assets: related with the software life-cycle itself.

e.g., process performance data, guidelines, adaptation

instructions, code generators, etc.

Asset base

An asset base is a structured collection of related assets. Assets are more effective when structured as an asset base. Examples:
A library of functions to read input data from different

sources, together with adaptation instructions for different platforms and a tutorial on how to use them.

A collection of guidelines, templates, photographs, icons, sounds and animated pictures to create slide-based presentations.

10/13/2012

Reuse benefits

Should be measured with respect to the established business goals. Benefits in performance (results):
Cost reduction. Quality improvement. Time-to-market reduction.

Benefits in business capability (enablers):

Increased process maturity. Increased production capacity. Better awareness of existing capability. More accurate estimations.

Domains

A conceptual area or field defined by a set of features that are shared between its members.
Problem domain: common requirements. Solution domain: common design/code.

From a reuse viewpoint a domain is of interest if it is more convenient to consider the solutions of the problems as a whole rather than individually. Establishes the scope of reuse.

10/13/2012

Critical reuse factors

Driven by business (not by technology). Treated as an investment. Focused on a domain. Integral part of process improvement.

Driven by business

10/13/2012

Treated as an investment

Reuse initiatives require a cost-benefit analysis. The analysis is similar to any other capital investment (e.g., RoI, NPV, etc.). It is necessary to take into account factors difficult to quantify, such as:
New business opportunities. Timing to be on the market. Competitive prices. etc.

Risk needs to be considered and controlled.

Domain-focused

10/13/2012

Changes in Life Cycle

Reuse processes
Two life-cycles with different but complementary objectives. Domain Engineering

It establishes a standardized and shared concept

within a given domain in the organization. It develops and maintains the needed infrastructure for developing applications in the domain.

Application Engineering
It mechanically derives applications and

instantiates them for specific customer needs.

10

10/13/2012

Integral part of process improvement

Reuse supports organizational process improvement but it also requires some level of process maturity in the organization

Integral part of process improvement (2)

Integral part of process improvement (2)

Reuse changes the software development

process Reuse adoption and process improvement are complementary to each other Reuse requires some level of process maturity in the organization

11

10/13/2012

Module 2

What do you develop?

Are you developing independent products or software product families? A product family may be:

A set of application systems for different

customers with similar needs A set of systems based on the similar architecture/technology

Most units developing software intensive systems may look at their products as a product family

12

10/13/2012

Families - Parnas
Practical and economical definition: We consider a set of programs to constitute a family whenever it is worthwhile to study programs from the set by first studying common properties of the set and then determining the special properties of the individual family members.

David L. Parnas.

Families - Dijkstra (1968)

Design guidelines for families: program structure should be such as to anticipate its adaptations and modifications. Our program should not only reflect (by structure) our understanding of it, but it should also be clear from its structure what sort of adaptations can be catered for smoothly. Thank goodness the two requirements go hand in hand.

Edsger Dijkstra - On program families.

13

10/13/2012

Domains
A domain is of interest if it is more convenient to consider the solutions of the problems as a whole rather than individually. Problem domain/Business domain/Vertical domain:

common requirements.

Solution domain/Technical domain/horizontal domain:

common design/code.

Product families & product-lines

Product-family
A group of systems built from a common set of

assets. Construction perspective: generally associated with a technical domain

Product-line
A collection of products sharing a common set of

features that address the specific needs of a given business area. Business perspective: generally associated with a business domain

14

10/13/2012

Systematic reuse and product families

A systematic approach to reuse requires that:

you conceive the production of a collection of

software products or systems (multi-system perspective) the collection constitutes a family, e.g. it is built from a common set of assets in a given domain (domain scope) you identify the commonality and variability across the family of systems to structure the reusable asset base (domain analysis) you establish how new members of the family are built from the common asset base (domain process)

Domain Scope: Defining the domain

Establishes a shared vision of the domain

Determines common characteristics of all

members of the domain Provides examples and exceptions Defines a way to determine whether a new application belongs to the domain.

Domain definition results in

domain name, synopsis and glossary, existing products and customers,

used technology.

15

10/13/2012

Domain Analysis

Defines the way in which domain members are similar to each other.
Understand what domain members have in

common. Identify the variabilities that distinguish the essential ways in which one member is different from the others

Domain analysis results in:

Commonalities and variabilities Decision model

Domain process

Describes how to engineer the applications using the common asset base. Establishes the requirements of an application for a given customer by setting the values of open decisions The development process includes binding the variabilities at different stages:

Analysis Design Code Deployment Run-time

16

10/13/2012

Metal processing lines: case study

A real case derived from the experience A company belonging to a big corporation and working in the sector of control and supervision systems for metal processing lines MPL require sophisticated software applications adapted to each specific installation.

The company business

The company works since long time on applications for supervision an control of metal processing lines It covers control machines from most known providers Paper processing lines, which have similar characteristics, are also covered.

17

10/13/2012

Metal processing line

The line is composed of a series of machines to process metal (steel) The metal is processed according to the needs markets needs form construction industry, automotive industry, agricultural industry, for applications such as guard rail and corrugated pipes etc. The processing line produces metal with various surface quality, formability and resistance requirements, etc.

Domain definition

Name, to be able to make reference to the domain Synopsis, a brief informal statement of the scope of the domain Products, a representative list of existing products (legacy products) as well as potential future products. Glossary, definitions for relevant terminology used by experts in the domain Customers, identification of the internal and/or external clients of the domain (i.e., those that will use the domain assets). Organizations involved, the internal departments or groups that have some interaction with the domain. Technology, on which the domain is based.

18

10/13/2012

Domain definition example

Domain name:
Metal Processing Lines

Domain synopsis:
SW applications for the supervision and control of metal

processing lines. The Metal Processing Lines includes the Programming Logic Control (PLC), the SCADA program (supervision), electric diagrams

Glossary example

METAL PROCESSING LINES:

set of machines and control devices (PLC-s and Drives) that compose a

system for metal transforming: the input to the line is a steel coil, whereas the output may be a set of sub-coils in the case of a slitting line, or a set of steel sheets in the case of a cut-to-length line.

CONTROL DEVICES or PLC (Programmable Logic Controller):

industrial electronic device for controlling the automatisms of a Metal

Processing Line.

SCADA:
Supervisory Control and Data Acquisition. SW for graphical applications for

HMI (Human to Machine Interface) communication, process control and supervision.

MACHINES: . STEEL COIL:

19

10/13/2012

Domain definition example

Customers:

Gonvarri (Spain-Barcelona) , Siderar (Argentina), Gonvauto (Spain-Navarra), Gonvarri (Brasil), Paper production companies, Iron Industries

Organizations involved:
Production department, Investigation and Development department

Technology:
Siemens PLC, Rockwell PLC, SCADA supervision, XML

Domain definition tips (1/2)

The domain definition must represent a shared vision and consensus among all involved persons and organizations. The domain has been limited to the metal processing line because:

This is the better known domain by the involved

departments within the project The company had already product orientation policy (generic program with manual derivation) The definition may include criteria to determine if a product belongs to a domain

20

10/13/2012

Domain definition tips (2/2)

Reasoning on legacy products can help in determining the domain characteristics. However, they are not the only source of information: it is necessary to look at the future and make forecasts
A generic product has been defined from the legacy

products to cover the most required products

Variability was not managed to every level Domain definition is an iterative process. It will not come out perfect the first time!
Domain definition required three iterations before it

was established

Commonality and Variability

Commonality: Common characteristics that are present in all members of a domain. Commonality characterizes the domain from other domains Variability: Characteristics that may be different for different members of the domain.

21

10/13/2012

Commonality examples

Variability examples

22

10/13/2012

Commonality and variability tips (1/2)

For commonalities
Compare existing legacy systems and look for

essential features, develop a list of features for each system, determine what is common

The commonality has been largely extracted from the generic program (legacy systems)
Do not go into much detail, ask yourself if the

commonalities correspond to essential needs of the target customers

Commonality and variability tips (2/2)

For variabilities
Derive variabilities from commonalities.

C01 and V01

Ask yourself if variabilities correspond to

distinguishing characteristic or options from which customers (developers) can select.

The number of machine can be selected as well as the types of machines

Limit the explosion of combinations of variabilities.

The decisions concerning each machine has been standardized even if some decisions are not applicable on every machines. In this way, combinatorial explosion can be avoided.

23

10/13/2012

Exercise 2-A: Identification

Decision model (DM)

A decision model collects all the open decision that characterize a domain The decision model is a formalization of the domain variabilities. It represents a dimension of variation in a system that is not closed at the domain level Each decision may be represented as a question (a variable) and a range of valid answers for it (the possible values that the variable may adopt) The decision model (DM) may be represented

As a table As a type declaration (e.g., DB schema) As a tree (e.g., FODA)

24

10/13/2012

Decision types

Simple decisions:
Decisions which are only restricted by the type of data that their

values will respect (string, numeric)

Restrictions on decisions:
There are two types of restriction that can constrain
the value of a simple decision: min-max, which establishes the

minimum and maximum values that determine the range of the decision; and list of values, which establishes the specific set of values that the decision may adopt. A list of values can be single choice or multiple choice.

Collection of decisions:
Set of decisions that can be made by the customer several

times.

Group of decisions:
Organizational element that allows to structure the decisions in

meaningful sets

Decision characteristics
A name identifying uniquely the decision A description describing the way to make the decision A range constraining the value of the open decision may or may not include the null value, meaning that the value of the decision is irrelevant or not applicable. Other elements are:

default value binding role that should assign a value, binding time, representing the latest time at which it must

be bound and
binding order, establishing in what order the decisions with

the same binding time should be bound.

25

10/13/2012

Dependency

Decision dependencies:
One decision D depends on a set of decisions SD if

the set of valid values of D is restricted in some way by the values that the decisions in SD may assume.

Cyclic decision dependencies are not allowed. A decision is fully dependent if its value is determined by some of the values of other decisions. Fully dependent decisions for all of the values of other decisions are actually derived decisions and should not be main part of the decision model

Dependency example
The value of some decisions depend on the value of other decisions: if Speed Line = 2 then

Uncoil Machine Reductor = yes

else
Uncoil Machine Reductor = no

It is useful to specify the dependency between elements of the decision model

26

10/13/2012

Domain definition

Problems:
Domain too large
Domain very difficulty to analyze Analysis over-sized

Solution
Partition the domain into smaller sub-domains

Commonality & variability definition

Problems:
Difficulty to identify what is common and what is

variable Difficulty to stop the analysis to the appropriate level (most of the time people go so deeper) Difficulty to structure the identified variability Strong work to write the documentation dealing with the C&V

Solution
Standardization of the products help considerably to

identify the commonality Provide small examples of C&V identification for a sub-domain well know by the involved people in this activity

27

10/13/2012

DM definition

Problems:
Big number of decisions become unmanageable
Too many dependencies among decisions

Solution
Classify and group decisions Concentrate on user-relevant decisions Iterate the process: not everything will be right the

very first time

Exercise 2-B: Decision Model

28

10/13/2012

Tree Structure
Variability 1 Domain Compone nt 1 Subsystem Domain Compone nt 2
Commonaliti es Commonaliti es

Client Type 1 Client Type 2 Client Type 1 Client Type 2 Variability 1.1 Variability 1.2 Client Type 1 Client Type 2

Variability 2 Variability 0 (WO) Variability 1 (WT)

Table Structure
Subsystem 001
Domain Comp. Dec. ID Name Descriptio n Type Depende ncy Client Type/ Cat/Nam e Role Time Range Default Order

29

10/13/2012

Decisions impact in all work-products

Decision model: collects all decisions Different values in decisions lead to variations in work-products

Variability in all kinds of workproducts

Offers, proposals Project plans Requirements Architectures Design Source code etc

30

10/13/2012

Decisions and Variation points

Decisions in the decision model are associated with variation points in a domain asset The contents of an asset in a variation point depends on the actual value of the decision

Variation point

Variation point:
Identifies a point in a domain asset in which there is a difference

among the application components that may be derived from it.

The variation point may be of the following types:

Use value:
the variation consists in using a value calculated as the result of

an expression involving the actual value of the associated set of variation parameters.
Condition:
the variation depends on a Boolean value calculated as the result

of an expression involving the actual values of the associated set of variation parameters.
Repetition:
the variation consists in repeating a section a number of times

calculated as the result of an expression involving the actual values of the associated set of variation parameters

31

10/13/2012

Techniques for capturing variability Techniques may depend on the kind of asset

Requirements level
Template documents Multiple-choice documents

Architecture & Design level

Modular design Design patterns

Implementation level (code)

Pre-processor macros (e.g. C language #define ) Parameters coding guidelines

Design principle

Structure your asset in components to minimize the impact of variations. Localize the differences in variation points, using abstraction and information hiding. Examples
Layered architecture: layer n+1 is independent of the

decisions affecting layer n. Components hiding implementation details.

Source components Binary (compiled) components

Client-server architectures: presentation independent

from business logic.

32

10/13/2012

Flexible components

A flexible component is the representation of a family of components.

Flexible component concept

Flexible component: a representation of a set of similar software components in one single source using variation points. A flexible component is defined by the following elements:
An interface with a set of variation parameters A declaration with a set of used (elementary) flexible

components An implementation

Variation parameters: they univocally specify one single application component among the set of similar components represented by the flexible component

33

10/13/2012

Capturing variability

Building domain assets

Flexible component approach may be applied to any non sw document. Domain assets may be hierarchically structured No need to build domain assets for the complete domain No need to specify completely how the variation impacts on the work-product Question: How should we deal with the decision regarding the language in a natural language document?

34

10/13/2012

Exercise: Variation Points

35