Systematic Software Reuse
It Isn’t What It Used to Be
Martin Griss, PhD
Principal Research Scientist
Carnegie Mellon University, Silicon Valley Campus
&
Principal, Martin Griss Associates
(C) - MARTIN GRISS - ICSR 2015
1
Agenda
•
•
•
•
•
Background
From Libraries to Factories
Generative Reuse
Agile Reuse
Conclusions
(C) - MARTIN GRISS - ICSR 2015
2
40 Years Evolving Reuse Practice
• Software portability, LISP compilers, languages - U of Utah
• HP Reuse libraries, corporate reuse program, process
• Software Reuse: From Library to Factory
• (Hybrid) Domain Specific Kits
• UML 1.0 standards committee
• Reuse advice to HP divisions & customers
• RSEB: Software Reuse: Architecture, Process,
& Organization for Business Success
• FeatureRSEB, Product Lines
• LogicLibrary, Flashline and TopCoder consulting
• Reuse Comes in Several Flavors
• Study of TopCoder crowdsourcing
• Agile Reuse
(C) - MARTIN GRISS - ICSR 2015
3
Systematic Software Reuse
Component-oriented software engineering
A simple idea
Use previously developed components, frameworks, other artifacts
... with complex execution ...
New component & framework & generator technology & methods
Architecture, process, organization, economics, cultural changes
... but with major benefits!
AT&T, GTE, Ericsson, HP, IBM, NEC, Rolls-Royce, Toshiba, Volvo,…
Significant cost and time reductions
Improved agility
(C) - MARTIN GRISS - ICSR 2015
4
Reuse Body of Knowledge
Many books & conferences on reuse & related topics
– Architecture, aspects, patterns, frameworks, components, product lines,
generators, domain engineering, management, organization
(C) - MARTIN GRISS - ICSR 2015
5
Many Reuse Technologies
• Aspects
• Patterns
• Templates
• Parameters
• Components
• Frameworks
• Domain-specific languages
• Generators
• Services/SOA
• Agents
(C) - MARTIN GRISS - ICSR 2015
• Library system(s)
• Horizontal vs Vertical reuse
• Domain Engineering
• Variability Analysis
• Reuse-oriented Architecture
• Model-Driven Development
• Product Line Engineering
• Open Source/Corporate Source
• Crowd Source
6
Many Reuse Questions
• What kind of reuse should we do?
• What strategy of marketing, incentives for reuse?
• What is an appropriate organization model?
• Should we do full scale product line reuse?
• Should we do model-driven development
• Should we use generators and domain-specific languages
• What technologies and tools to focus on?
• How are assets and support funded?
• What kind of reuse pilots to do?
• How and when to scale up?
• How is reuse connected to other software initiatives: architecture,
SOA, process improvement, quality, metrics, open source, crowd
source, …
(C) - MARTIN GRISS - ICSR 2015
7
(Staged) Adoption of Reuse
Reuse Benefits
Improved time to market, costs, quality
Rapid custom product development business
Interoperability
high reuse levels
Broader coverage
Reduced
maintenance costs
Reduced
development time
Informal
code salvaging
Planned
black-box
code reuse
Significant
management
support.
Code, other
workproducts
Architected
reuse, process
metrics
Pervasive
domain-
specific reuse
No reuse
Investment, experience, time
(C) - MARTIN GRISS - ICSR 2015
8
Reuse May Vary Across Organization
• Ad hoc, random reuse
Components, Libraries
Architecture, Frameworks
Platform, Services
(C) - MARTIN GRISS - ICSR 2015
• Powerful enablers and
process enhancements
• Strategic to company
success
9
Reuse “Flavors”
4. Reuse-Driven Business – Reuse central to
all decisions
3. Architected Reuse – Architect, domain engineer
assets for reuse, domain
2. Managed Reuse - Require, enforce, control
participation, use of assets
1. Facilitated – Encourage, support, enable
individual or team choice
ad hoc reuse - NONE
(C) - MARTIN GRISS - ICSR 2015
10
Governance/Process/ Roles/ Tools Mixing Reuse Flavors
Managed Reuse Reuse Driven Business Faciliated Reuse (C) - MARTIN GRISS - ICSR 2015
Architected Reuse 11
Agenda
•
•
•
•
•
Background
From Libraries to Factories
Generative reuse
Agile reuse
Conclusions
(C) - MARTIN GRISS - ICSR 2015
12
From LEGO “components” to “kits”
(C) - MARTIN GRISS – ICSR 2015
13
(Hybrid) Domain-Specific “Kit”
Combine compatible asset types
I!
C1!
D1! P!
I!
Framework
Components
Glue
Tools
Procedures
A3!
P!
B1!
(C) - MARTIN GRISS – ICSR 2015
C2!
14
RSEB
Application Family
Engineering
Business
Models
Customer
&
User
Requirements
Standards
Technology
Trends
Existing
Systems
Existing
Components
Layered
System
Component System
Engineering
Component
System
ApplicationSystem
Engineering
Application
System
(C) - MARTIN GRISS - ICSR 2015
15
Product Lines
Product 4a
Product 3a
Product 4b
Product 2a
Product 3b
Product 1
High end
Market
Product 4c
Product 2b
Mid-market/
SOHO
Product 3c
Product 4d
Personal
time
• A set of products sharing common set of
requirements (or features), with significant
variability
• Feature = product characteristic users,
customers & developers use in describing/
distinguishing members of product-line.
(C) - MARTIN GRISS - ICSR 2015
16
Expressing Variability
Component
Components have
Variation Points where they
can be customized with
variants using various
mechanisms
variant
VP1
Component
Variation Points
VP1
...
Component
Operation()
...
A
b
….
«variation point»
«bind» {VP1=variant}
variant
VP1
(C) - MARTIN GRISS - ICSR 2015
17
RSEB
Product Line Engineering
Business Model
• Business processes
Applications
• Business
priorities
• Application
roadmap
• Standards
• Technology trends
• Application priorities
• Customer trends
Domain
Experts
Existing
Applications
Application Family
Engineering
Ranking/Prioritizing
- Business use cases
- Application use cases
- Component systems
Layered Architecture
Component System
Engineering
Component
Systems
Exemplers
Domain
Analysis
Reengineering
(C) - MARTIN GRISS - ICSR 2015
Domain Model
• Feature Model
• Domain Architecture
Candidate
Components
18
Developing for Application Family
Domain-specific, architected, product-line
Domain
Engineering
Provide: Develop For Reuse
• scope domain
• variability
• architecture
• components & frameworks
• DSL & generators
(C) - MARTIN GRISS - ICSR 2015
Application
Engineering
Utilize: Develop With Reuse
• match to domain
• delta analysis
• select, adapt, integrate
19
FeatuRSEB
Combine
RSEB,For
FODA,
UML
Feature Model
Telecom
Optional
Vpfeature
Phone Service
Dialing mode
exchange
type
PABX
Mandatory Vp-feature,
use time_bound
pulse
video
individual
conference
billing
called
tone
voice
Variant feature
caller
T1
entry
Caller
off-hook
ISDN
POTS
action
PTP
Route
Call
800number
line quality
Play
dial
tone
input
Called
off-hook
Announcement
Optional
feature
P.I.N.
Variable
Decision
Time of
Day
Routing
Day of
Week
Routing
Date of
Year
Routing
Holiday
Schedule
Announcements
Re-route
if busy
Legend
Composed of
Vp- feature (XOR)
Optional feature
Vp-feature , use time
bound (OR)
(C) - MARTIN GRISS - ICSR 2015
Software Reuse - X.75
© 1996, 1997,1998 Hewlett-Packard & Rational Software Corporation
20
FeatuRSEB
(C) - MARTIN GRISS - ICSR 2015
21
Agenda
•
•
•
•
•
Background
From Libraries to Factories
Generative reuse
Agile reuse
Conclusions
(C) - MARTIN GRISS - ICSR 2015
22
Generative Approaches
• Built-in to Language
• C/C++ macros, LISP macros, C++ templates, Java Generics, …
• General Purpose Macro Preprocessor
• GPM, STAGE2, M4, Basset Frames (NETRON), XVCL, VCL, ..
• Extensible Languages
• LISP, BALM/MBALM, Algol-68, EL1, …
• Domain Specific Languages/Kits
• Via YACC, MetaLISP, BALM ,,,. (e.g., PictureBALM), Visual
Programming kit, OO Instrument Kits)
• Model-driven Generators
• GenVOCA; MetaCASE; OMG MDA (UML for PSM/PIM), …
• Aspects, …
(C) - MARTIN GRISS - ICSR 2015
23
me, processing of the current x-frame is suspended and the processor
ssing the <adapt>ed x-frame. Once processing of the <adapt>ed xted, the processor
resumes processing of
the current
x-frame. When the
XVCL/Bassett
Frame
Generator
r reaches the end of the SPC - the processing is completed. Figures 1a
• XML-based generator
an x-framework and the processing • flow.
Template-based DSL
x-frame B
BBB before
<adapt D />
BBB
<adapt E />
BBB after
x-frame D
DDD
x-frame A
AAA before
<adapt B />
AAA
<adapt C />
AAA after
•
•
•
•
x-frame E
EEE
(C) - MARTIN GRISS - ICSR 2015
amework (B, C, D, E and F) and SPC (A)
Easy to layer onto existing software
Manage commonality and variability
Weaves code fragments (“aspects”)
Used for code reuse and product lines
x-frame C
CCC before
<adapt E />
CCC
<adapt F />
CCC after
x-frame F
FFF
24
Aspect-Oriented MDD
AOP, SOP, FOP, XVCL
Cashier Interface
Withdraw Money
Withdraw
Deposit Money
Account
Dispenser
Deposit
Slot
Component
Component
(C) - MARTIN GRISS - ICSR 2015
Component
Component
Component
25
independent models to produce platform-specific models using mappings. Within the system developme
process, the MDA applies platform-independent models and platform-specific models to sustain and leverage i
in requirements, technologies, and the lifecycle that bridges the gap between them as they independently ch
an approach generally leads to long-term flexibility of implementations, integration, maintenance, testing and
as well as portability, interoperability and reusability. The MDA emerged from the efforts of the OMG and its
members to culminate in 2000. Currently, MDA 1.0 is proliferating in the industry.
OMG/UML Model Driven Architecture
The OMG has various Technology Committees (TCs) for providing standardization guidance and recommendatio
Domain Technology Committees (DTCs) focus on vertical markets such as Healthcare, Finance, Telecomm
Manufacturing, Transportation, and so forth to capture standard domain-specific models that form the fou
platform-independent models. Various Platform Technology Committees (PTCs) focus on horizontal technolog
Web Services to capture standard technology-specific models that form the foundation for platform-specific m
the OMG has an Architecture Board (AB) that oversees the standardization in order to ensure coherence and
of the standards.
• Use UML + <<stereotypes>> + OCL
• Create
• Problem Independent Foundation
Model (PIM)
• Generate
Figure 2 shows the foundational concepts of what generally constitutes the MDA.
• Problem Specific Model (PSM)
• Transformation rules
(C) - MARTIN GRISS - ICSR 2015
Figure 2: Foundational Concepts of the MDA
26
Systems, Models, and Model-Driven Approaches
A system (or physical system) is a collection of elements organized together for a specific purpose. A model of
Agenda
•
•
•
•
•
Background
From Libraries to Factories
Generative reuse
Agile reuse
Conclusions
(C) - MARTIN GRISS - ICSR 2015
27
Agile in the Enterprise
Plan-driven vs Agile vs Hybrid
• Conventional plan-driven process
Requ.
Spec.
Arch.
Design
Implement
Test
Deploy
– Large teams
– Standardized models, architecture,
documents and process
Approaches to Software Development
• Feature-oriented agile process
–
–
–
–
–
Small teams
Rapid development
Customer-oriented release and evolution
Expertise and tacit knowledge
The Engineering Perspective
Emergent architecture
• Hybrid approaches
The Agile Perspective
Does Scale Really Matter?: ULS Systems Seven Years Later
22
Linda Northrop: May 24, 2013
© 2013 Carnegie Mellon University
– Address scale, reuse, architecture
(C) - MARTIN GRISS - ICSR 2015
28
Approaches to “Agile” Reuse
Oxymoron? - YAGNI
Incremental Feature-Oriented Reuse
• Leverage agile feature/story cards, SCRUM backlog
• Feed incremental Feature-Oriented Domain
Engineering (FODA, FeatuRSEB)
Leverage Management of Technical Debt
• Technical Debt accumulates with deferred decisions
and work, coding shortcuts
• Incrementally pay off debt by re-factoring, reengineering, re-architecting
• Economic/metrics models to help make decisions
Domain Specific Languages
• Various levels of model-driven development
(C) - MARTIN GRISS - ICSR 2015
29
Manage Technical Debt
New Requirement
New Requirement
Story
Points
Reuse
Burn Down
Learning
Refactor
Refactor
Technical Debt
Velocity
Iteration
(C) - MARTIN GRISS - ICSR 2015
30
(New) Sourcing Models
Code
4
• Open Source
Internal QA
3
2
Contribution
1
• Varying community and process
management
Project
leadership
Testing
• Corporate Source
• Foster open source “style”
in companies
Working
practices
SPGF
• Crowd Source
• Deliberate engagement
of community
(C) - MARTIN GRISS - ICSR 2015
31
Agenda
•
•
•
•
•
Background
From Libraries to Factories
Generative reuse
Agile reuse
Conclusions
(C) - MARTIN GRISS - ICSR 2015
32
Assess Reuse Readiness
1. Business goals that motivate reuse
– Time, cost, quality, integration, agility, standards, …
– Urgency, importance, champion …
2. Domain(s) readiness for reuse
– Stability and variability, standards
– Obvious, pervasive product line
3. Organizational readiness
– Culture, process maturity, autonomy, standards
– Conflicting initiatives, prior history, technology shifts,
4. Reuse experience
– Current stage or flavor of (systematic) reuse
– Reuse level, technology use, library use
(C) - MARTIN GRISS - ICSR 2015
33
Conclusions
• Software reuse approaches keep evolving
• Assess reuse readiness before selecting
reuse goal and flavors
• Identify opportunities for small DSL/MDD,
generators and product-lines
• More work on agile reuse,
SEMAT/reuse,
open source/crowd source
(C) - MARTIN GRISS - ICSR 2015
34
© Copyright 2024 ExpyDoc
