7 - Architetture Software - Software product line
-
Upload
majong-devjfu -
Category
Technology
-
view
1.881 -
download
2
Transcript of 7 - Architetture Software - Software product line
![Page 1: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/1.jpg)
Software Product Lines Paolo Ciancarini
![Page 2: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/2.jpg)
Agenda • Design for reuse • Software product lines • Organizational strategies
![Page 3: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/3.jpg)
Motivation Complexity, size, and number of software-intensive systems a major problem for software companies • routine functionality is custom-written repeatedly
from scratch, over and over • a quagmire of data formats and applications • ambiguities and interoperability conflicts not only
across different companies but even among groups within the same company
![Page 4: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/4.jpg)
Family of systems There is a need to • reduce the development effort • increase productivity moving from designing single products to producing engineering families of products • identifying generic solutions to common problems • building related products by assembling components • providing universal platforms • synthesizing systems automatically
![Page 5: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/5.jpg)
Product Line Architecture (PLA) Product Line Architecture: a common design framework that • standardizes & maximizes reuse potential of all
software artifacts generated during development - these artifacts include requirements, designs and
patterns, and, of course, actual code components • specifies common functionality across systems • clearly identifies variation points
![Page 6: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/6.jpg)
Capturing PLA • Common core: features common to all products • FA: features specific to product A • FB: features specific to product B • Product A = Common core + FA • Product B = Common core + FB
Common core
FA Common core
FB
Product A Product B
![Page 7: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/7.jpg)
Lessons from other industries
• Any customer can have a car painted any colour that he wants so long as it is black” - Henry Ford
Any customer can have a car painted any colour that he wants so long as it is black” Henry Ford
![Page 8: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/8.jpg)
Architecture and standard components
Architecture was simple and flexible Built from standard parts
![Page 9: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/9.jpg)
Standards and diversity What varied? Use features to satisfy diversity of needs Why it worked? Standard architecture and common parts What resulted? Product and assembly lines
![Page 10: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/10.jpg)
The role of architecture in sw
![Page 11: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/11.jpg)
Component based development Software factories exploit component-based development (CBD) • They engineer applications by composing
prefabricated components in the hope that this will increase software reuse
• Strategy: building software systematically and opportunistically exploting reference architectures about a domain and competitive knowledge for systems in that domain
![Page 12: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/12.jpg)
Domain What is a domain? • Area of expertise with specialized particular tasks • Populated by products with reusable structures
Example: software for a car • Console • Engine • Brakes • …
![Page 13: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/13.jpg)
Domains vs product lines
• Domain • Consumer electronics • Avionics • Compilers • Videogames
• Product line • Philips Digital TVs • Boeing 747 Family • GNU compiler suite • Games using the
same “engine”
Domains are in the problem space, product lines are in the solution space
![Page 14: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/14.jpg)
VCR Features:"• Play Tape"• Rewind Tape"• Forward Tape"• Button Control"• Signal Handling"
Answering machine Features:"• Play Announcement"• Record Announcement"• Rewind Announcement"• Play Message"• Record Message"• Rewind Message"• Forward Message"• Display Messages"• Button Control"• Signal Handling"
Audio Player Features "• Play Tape"• Record Tape"• Rewind Tape"• Forward Tape"• Button Control"• Signal Handling"
Multimedia Product Line
![Page 15: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/15.jpg)
Product lines
• Product line technology builds families of products exploiting some common core assets and managing their variability
• Ex.: Boeing 757 e 767 share 60% of components • Ex.: Mercedes Benz class E models share 70% • Scale economies and efficiency • Integrating rather than creating
![Page 16: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/16.jpg)
Software reuse Why is software reuse critical? • provides predictable behavior (better testing) • enables shorter delivery timeframes • reduces repeated building from scratch of
common functionality
History of the concept dated back to 1950’s • subroutine libraries • standardized class libraries
![Page 17: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/17.jpg)
Old ways to reusing software Old definitions of sw reuse include: • “Re-use is considered as a means to support the
construction of new programs using in a systematical way existing designs, design fragments, program texts, documentation, or other forms of program representation.”
• “Reusability is the extent to which a software component can be used (with or without adaptation) in multiple problem solutions.”
![Page 18: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/18.jpg)
Reusable assets
Reference Architecture
Architectural Style
Architectural Pattern
Design Pattern
Programming Pattern
Packaged Application
Application Framework
Architectural Mechanism
Legacy Application
Component Library
Component
Pattern Language
Development Method
Reference Model
Architectural Decision
Pattern
![Page 19: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/19.jpg)
Reuse Reuse aspects • It is not an end in itself but a means to increase
productivity and improve quality • Reusable components are not limited to code • Software components may need adaptation
- Adaptive design - Variant design
• Horizontal and vertical reuse
Community & Enterprise Information Portals
Distributed Run-time Middleware
HealthCare Financial Insurance
Metamodel Interoperability
E-Business facilities(Appl. dev., Intelligence, Integration, …)
••• other vertical domains
••• otherfacilities
•••
![Page 20: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/20.jpg)
Benefits By planning ahead in support of families of multiple systems, an organization • reduces the development time and cost of new
products • reduces risk and improves quality • manages its legacy assets more efficiently • evolves a common marketing strategy • makes decisions based on the (value of) the
asset base and the strategic goals
![Page 21: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/21.jpg)
Software product lines (SPL) Definition by Clemens and Northrop (SEI, 2002): • A set of software-intensive systems that share a
common, managed set of features satisfying the specific needs of a particular market segment
• They are developed from a common set of core assets in a prescribed way
• Example: software for TV sets (Philips)
![Page 22: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/22.jpg)
SPL metamodel
Product lines - Exploit commonality - Bound variability
![Page 23: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/23.jpg)
Why SPL work? Product lines amortize the investment in these core assets: • requirements (and requirements analysis) • domain models • software architecture (and design) • performance engineering • documentation • test plans, test cases, and test data • people: their knowledge and skills • processes, methods, and tools • budgets, schedules, and work plans • components and services
![Page 24: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/24.jpg)
A few success stories • Celsius tech: family of naval command and control systems
• Ericsson AXE: family of telecommunications switches
• Lucent Technologies: 5ESS telecom switch
• US Naval Undersea Warfare Center: A-7°
• SALION: Acquisition Management Systems
• Toshiba: Electric Power Generation Plant
• BOEING: Bold Stroke Avionics SW Family
• BOSCH: Gasoline Systems
• CUMMINS Inc.: Diesel SPL
• LSI: RAID controller firmware SPL
• GM: General Motors Powertrain (GMPT)
• PHILIPS: Medical Systems
• Nokia: mobile phones
![Page 25: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/25.jpg)
SPL issues • ROI: when are they convenient? • Organization of work • Domain engineering and scoping • Design for reuse of commonality • Control of variability
![Page 26: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/26.jpg)
ROI of SPL
ROI
![Page 27: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/27.jpg)
ROI of SPL
![Page 28: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/28.jpg)
![Page 29: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/29.jpg)
Convenience of Product Lines
29
![Page 30: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/30.jpg)
Key concepts
![Page 31: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/31.jpg)
Organization by product lines
(from Krueger 2009)
![Page 32: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/32.jpg)
![Page 33: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/33.jpg)
Single system perspective
(from Krueger 2009)
![Page 34: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/34.jpg)
![Page 35: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/35.jpg)
![Page 36: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/36.jpg)
![Page 37: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/37.jpg)
Product Line Engineering PL Engineering uses domain-driven, model-based methodology for building software • Two complementary processes
- Modeling (domain engineering) - Development (applications engineering)
![Page 38: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/38.jpg)
"Solution models"
Product Line Engineering
1. Modeling (Domain Engineering, a.k.a Design-for-Reuse)"
Refers to original design, i.e.,the use of first principles"
"Technology"
Domain knowledge"
Dom
ain
Expe
rts &
Dom
ain
Engi
neer
ing
Expe
rts
2. Development (Application Engineering, a.k.a design-with-Reuse)"
refers to routine practice, i.e., the use of known solutions"
Product"
Dom
ain
Expe
rts &
IT te
chni
cian
s Domain Expert New requirements"
![Page 39: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/39.jpg)
![Page 40: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/40.jpg)
Reusable assets Reuse in general needs to be planned for • create a reusable asset, i.e. one that is fully
documented, has good code and robust scripts; is verified independently with high confidence
• create a usable asset, i.e. one that is adaptable and that is usable in a variety of simulators
Design for reuse/use involves • analysis to identify explicitly variations to
anticipate adaptations, and • design for adaptability, engineered a priori to
create assets for future developments
![Page 41: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/41.jpg)
Problems Design for commonality • standardizing assets by encapsulating common
features
Analysis of variation • must explicitly identify variations that anticipate
adaptations
Control of variability • provide assets flexibility without compromising
commonality
![Page 42: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/42.jpg)
Levels of reuse • Domain-independent components
- Designed for reuse to fit any product (e.g., general purpose class libraries)
• Domain-specific components - Designed for reuse to fit several different products in a
given market (e.g., multi-media, jpeg encoders, data communications, digital signal processing, ...)
• Product-specific components - Designed for reuse within a specific “application” (to
generate various instances or products)
![Page 43: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/43.jpg)
SPL: main issues There are several issues to consider • Scoping the SPL (i.e. identify domain and
assets) • Define a reference architecture • Define a PLA • Identification of reusable components at the
appropriate level of abstraction • Variability management • Architectural compliance • SPL maintenance
![Page 44: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/44.jpg)
What is SPL scoping? • the initial phase of a SPL, aims to identify
products, features, potential of the market domain and reusable assets
• determines the viability of the SPL • maximizes the economical value of the SPL • Essential factors in SPL: - Investment - Management - Planning - Business strategy } scoping
![Page 45: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/45.jpg)
Domains!
Systems!
Assets!
Traditional Engineering Model
Individual !domains!
Individual !applications!
Individualimplementations!
![Page 46: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/46.jpg)
Domains!
Systems!
Assets!
SPL Model
•••"
Cn Cn
Cn Cn
Cn
ArchitecturalFramework!
Reusable Component! • F
eatu
res!
• Var
iabi
lity
anal
ysis!
Operator!Plant!
Startup!
Shutdown!
Local! Remote!
Start compressor!
Alarm detected!
Remote!Shutdown!
Local Shutdown!
<<includes>>!
<<extends>>!
<<includes>>!
<<extends>>!
Stop compressor!
<<includes>>!
Operate!
<<includes>>!
<<includes>>!<<extends>>!
<<includes>>!
CapsuleACapsuleB CapsuleC2 2
:CapsuleB
:CapsuleB CapsuleC
CapsuleC
:CapsuleA
conn
ection
netw
ork
Class Diagram (domain model)
Colla
bora
tion
Diag
ram
(role
mod
el)
Domain models!
![Page 47: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/47.jpg)
Product Lines and UML Domain Analysis
Identify the “entities” and their relations in the applications domain"
Problem Analysis
Specify basic problem overall functionality, and identify and specify system features"
Solution Analysis
Describe implementation of the solution in terms of interactions between classes and permitted (expected) overall system behavior"
Domain Model (class diagram)
Problem Model (Activity diagram)
Requirements Model (Use Case diagram)
Implementation Model (Collaboration diagram)
Behavioral Model (traces + constraints)
![Page 48: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/48.jpg)
![Page 49: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/49.jpg)
![Page 50: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/50.jpg)
Variability in requirements Optional requirements Cross-cutting aspects Optional scenarios Varying flow of events
![Page 51: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/51.jpg)
Eriksson, Börstler, Borg, Software product line modeling made practical CACM, Dec. 2006
![Page 52: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/52.jpg)
A reference domain for automotive From Bak, Exemplar of Automotive Architecture with Variability, 2010
![Page 53: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/53.jpg)
Software Defined Radios
• Variation points in radio configuration, board configuration, software configuration
![Page 54: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/54.jpg)
SDRs PL • By applying product line techniques to
SDRs • Can manage different configurations of the radio - Deploying components on alternative hosts - Deployments with
– No waveforms – One waveform – Different combinations of waveforms
• Can show radio in different states as radio starts up or transitions from one waveform to another
![Page 55: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/55.jpg)
SPL according to SEI (5th framework, 2007)
![Page 56: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/56.jpg)
SPL according to SEI
![Page 57: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/57.jpg)
SPL according to SEI
![Page 58: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/58.jpg)
Two approaches to start a SPL • Proactive: Develop the core assets first
• Develop the scope first and use it as a “mission” statement. • Products come to market quickly with minimum code writing. • Requires upfront investment and predictive knowledge
• Reactive: Start with one or more products • From them, generate the product line core assets and then the future
products; the scope evolves more dramatically • Much lower cost of entry • The architecture and other core assets must be robust, extensible, and
appropriate to future product line needs
![Page 59: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/59.jpg)
Summary Product Line Architectures, rather than single-product architectures, support systematic reuse • represent recurrent requirements and
architectures (i.e., components and interfaces) suitable for solving typical problems in a domain
• depict structures for design related products and provide models for integrating optional/alternative components
• allow engineers to come up with the “right” solutions quickly and effectively
![Page 60: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/60.jpg)
Architecture-Centric Development Activities
Architecture-specific activities for SPL include: • creating the business case for the system • understanding the requirements • creating and/or selecting the architecture • documenting and communicating the architecture • analyzing or evaluating the architecture • implementing the system based on the architecture • ensuring that the implementation conforms to the
architecture
![Page 61: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/61.jpg)
From SA to PLA • Of all a product line’s core assets, the product
line architecture is the most important one for ensuring technical success.
• If an organization already uses disciplined practices to develop single-product software under the aegis of a software architecture, it is well poised to
• define a product line architecture • Identify the core assets • Build products from those core assets.
![Page 62: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/62.jpg)
Test questions • What is a software product line? • What is a product line architecture? • What is variability management?
![Page 63: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/63.jpg)
References • Clemens & Northrop, Software Product Lines, Addison Wesley, 2002
• Gomaa, Designing SPL with UML, Addison Wesley, 2005
• Pohl & Böckle, SPL Engineering: foundations, principles, and techniques, Springer 2005
• vanderLinden & Schmid & Rommes, SPL in action, Springer, 2007
• van Gurp & Bosch & Svahnberg, On the notion of variability in SPL, Conf. on Sw Architecture, 2001
• Eriksson, Bostler, Borg, Software product line modeling made practical. An example from the Swedish defense industry, CACM 2006
• Krueger & Jackson, Requirements engineering for systems and software product lines, White paper IBM Rationa,l 2009
![Page 64: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/64.jpg)
Conferences • SPLC 2011, Munich, Germany • Workshop on Variability in Software Product Line
Architectures • Wokshop on Product LinE Approaches in Software
Engineering (PLEASE)
![Page 65: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/65.jpg)
Sites • www.sei.cmu.edu/productlines • www.biglever.com
![Page 66: 7 - Architetture Software - Software product line](https://reader034.fdocuments.net/reader034/viewer/2022052618/554f6cf9b4c9058a148b5014/html5/thumbnails/66.jpg)
Questions?