Reusela nivel arhitectural

Copy-paste “reuse”P1 P2 P3 P4

Copy-paste Copy-paste+modificari

Dezavantaj: conduce la duplicare de cod => imposibil de intretinut, mai ales daca fiecare produs evolueaza ulterior independentExemplu: a fost copiat in P2, P3 si P4. In P2 si P4 a fost si modificat.La un moment ulterior, acest element trebuie actualizat, din diferite posibile motive (descoperire bug, evolutie platforma hw, inlocuire biblioteca de care depinde, etc.) => 4 proiecte diferite in care trebuie efectuata modificarea si testarea !

Observatie: La Tema2, aprox 60% dintre studenti au optat pentru aceasta modalitate de “reuse” !!!!

Product Line reuse

P1 P2 P3 P4

Reusable core assets

Software Product Lines

• Definitie: – “A set of software-intensive systems sharing a common,

managed set of features that satisfy the specific needs of a particular market segment or mission, and that are developed from a common set of core assets in a prescribed way. “ [Bass]

• Motivatie: – Pentru o familie de sisteme, avantajele sunt:

• Reducerea costului mediu de productie per produs din familie• Reducerea timpul mediu de lansare a unui nou produs din familie

– Exemple de succes cu Software Product Lines [Bass]:• Nokia: de 7 ori mai multe modele de telefoane noi pe an• HP: crestere a productivitatii de 6 ori, scaderea timpului mediu de

lansare a unui nou produs de 7 ori

Ce se reutilizeaza ?

Design Artifacts– Requirements– Architectural design– Elements (code)– Modeling and analysis– Testing

Project Artifacts– Project planning– Processes, methods,

and tools– People– Exemplar systems– Defect elimination

Reusable Core Assetsfor a Product Line

Scoping• Scope of a Product Line: defineste ce produse fac parte din familie si care nu• Scoping: bazat pe predictii: ce produse va dezvolta in viitorul previzibil• Strategii:

– Narrow scoping: numar redus de puncte de variabilitate– Broad scoping: numar mare de puncte de variabilitate

• Problema esentiala rezolvata de scoping: gasirea acelor elemente comune (commonalities) care pot contribui la reducerea costurilor de productie pentru intreaga familie

– Nu orice elemente comune merita sa fie facute parte din core: • Exemplu: Philips: linii de productie diferite pentru video electronic systems si digital video communication:

diferentele existente intre cerintele celor 2 categorii de clienti au condus la concluzia ca sunt mai eficiente abordari separate

Proiectarea arhitecturala pentru o Product Line

• Mai mult decat proiectarea arhitecturala a unui singur sistem:– arhitectura face parte din reusable core assets– Trebuie sa identifice asemanarile si diferentele intre membrii

familiei in urmatoarele aspecte: behavior, quality attributes, platform, network, physical configuration, middleware, scale factors, etc.

– Variation points: de regula, variabilitatea este limitata in cadrul unei familii la anumite puncte fixe unde se poate alege din mai multe alternative; Un membru al familiei este definit de combinatia de alternative selectate pentru toate variation points.

• Rolul proiectarii arhitecturale intr-o Product Line:– Identificarea de variation points– Suport pentru implementarea variation points– Evaluarea aspectelor care se preteaza pentru abiordare de tip

Software Product Line

Identificarea Variation Points

• Activitate continua, noi variation points pot apare si dupa ce o prima varianta a fost implementata

• Tipuri de variatii suportate:– Features, platforms, user interfaces, qualities, target markets

• Variation points: independente sau legate unele de altele (de ex: tipul de user interface poate depinde de platforma, care poate depinde de target market)

• Pentru identificarea si modelarea variation points: este util un model deasupra arhitecturii, model care tine de domeniul problemei rezolvate de familia de programe: Domain Engineering -> Feature Modelling

Variability & commonalityExample: Enchilada Product Line

Enchilada

Garnish Tortilla Sauce FillingTortilla

Sauce

Filling

Red Green Pork Beef Chicken

orxor

Mandatory features

Optional features

Alternative features

covered with

wrapped around

Domain engineering -> Feature tree:

Base architecture

Product engineering -> Core assets:•Base architecture•Common components

Suport pentru implementarea Variation Points

1. Suport arhitectural– Includerea sau omiterea unor elemente

• Mecanisme: controlul procesului de build, compilare conditionata– Includerea unui numar diferit de elemente replicat

• Mecanisme: de ex, pentru o versiune high-capacity a unui produs, la build se vor include automat mai multe replici ale unui anumit server

– Selectia unor versiuni diferite de elemente care au aceleasi interfete dar realizeaza diferite nivele ale atributelor de calitate• Mecanisme: Compile / build / runtime

2. Modificari in codul sursa– Specializarea sau generalizarea unor clase

3. Suport general pentru variabilitate la runtime– Parametrii deconfigurare– Reflection – Overloading

Strategii de adoptare a unei Software Product Line

• Direction of adoption:– Top Down: managerial decision first– Bottom Up: developers use this approach

• Growth of product line:– Proactive

• Se porneste de la definirea domeniului familiei de produse (scoping)

• Necesita o buna cunoastere a stadiului actual si tendintelor in: application domain si marketing

– Reactive • Se construieste un nou membru al familiei, pornind de la cei

existenti • Arhitectura este extinsa incremental si core assets sunt stabiliti in

urma a ceea ce rezulta a fi comun (nu planificat)• making

Comparatie strategii

• Proactive: – Investitie mare initial, dar

apoi nu mai necesita multe modificari

• Reactive:– Investitie mica initial,

modificari continue

Number of products

cost

payoffNumber of products

cost

payoff

Proactive Product LineNo P

roduct

Line

Reactive Product LineNo P

roduct

Line

Categorii de reuse arhitectural

• In cadrul aceleiasi organizatii: “eu scriu, eu reutilizez”– Software Product Lines (Product Families)– re-utilizarea sistematica a arhitecturii software, a unor

componente si a altor artefacte pentru producerea planificata a unei familii de sisteme asemanatoare.

• Intre organizatii: “eu scriu, altii (poate) reutilizeaza” sau “eu reutilizez ce au scris altii (necunoscuti)”– Components (Off-the-Shelf) – Proiectarea unui sistem nou se face prin cautarea de

componente existente, produse independent de catre terti, si integrarea acestora

Component Based Development

Build from scratch Buy/get components(design) (fit into a design)

Control completFlexibilitate Rezolvare imediata

TimpCostintretinere

Evaluare/testareLicente

Lipsa de flexibilitate

Avem de construit un sistem cu functionalitatile {F} si calitatile {Q}.

Cum procedam ?

Avantaje

Dezavantaje

Ce este o componenta?

• “A software component is a unit of composition with contractually specified interfaces and explicit context dependencies. A software component can be deployed independently and is subject to composition by third parties”

Clemens Szyperski

Ce este o componenta ?

• O componenta este un element de program care:– Poate fi utilizata de alte elemente de program

(denumite clienti)– Autorii componentei nu cunosc care vor fi

clientii– Autorii clientilor trebuie sa poata utiliza

componenta doar pe baza informatiilor furnizate de autorii acesteia (specificatii de interfete si dependente externe)

Architectural Mismatch• Not all components work together !• Architectural mismatch: stems from mismatched assumptions a reusable

component makes about the system structure of which it is part• Types of assumptions:

– Provides assumptions: describe the services a component provides to its clients– Requires assumptions: describe the services that a component must have in

order to function correctly– ALL assumptions should be specified in order to avoid mismatch !

• Mismatching assumptions may refer to:

• Components– interfaces

– infrastructure

– control model

– data model

• Connectors– protocols

– data model

[ Garlan, Allen, Ockerbloom: Architectural mismatch or Why it’s hard to buid systems out of existing parts ?]

• System topology• Construction

– dependencies

– initialization

Architectural mismatch

• What can you do about interface mismatch? [Bass]– Avoid it by carefully specifying and inspecting

the components for your system.– Detect those cases you have not avoided, by

careful qualification of the components.– Repair those cases you have detected by

adapting the components.

Detecting architectural mismatch

• Component qualification : the process of determining whether a commercial component satisfies various "fitness for use" criteria.

• Possible component qualification processes: prototype integration of candidate components as an essential step in qualifying a component. This integration step discovers subtle forms of interface mismatch that are difficult to detect, such as resource contention.

• Carrying out this evaluation starts with the observation that, for each service offered by a component, a set of requires assumptions must be satisfied in order to provide that service.

• Qualification: is the process of– discovering all of the requires assumptions of the component for each of

the services that will be used by the system.• Might be documented by the component provider or might need to be

discovered by component evaluator– making sure that each requires assumption is satisfied by some

provides assumption in the system.

Repairing architectural mismatch

• What can you do to repair mismatch: 1. Change the code of one or both mismatched components –

usually not possible in blackbox components2. Drop mismatching component and write your own 3. Insert code that reconciles their interaction in a way that fixes

the mismatch:• Wrappers• Bridges• Mediators

• Choosing between 2 and 3: from case to case, decide what is easier (cheaper)

Wrappers• The term wrapper implies a form of encapsulation whereby some

component is encased within an alternative abstraction. It simply means that clients access the wrapped component services only through an alternative interface provided by the wrapper.

• Wrapping can be thought of as yielding an alternative interface to the component. We can interpret interface translation as including:

– Translating an element of a component interface into an alternative element– Hiding an element of a component interface– Preserving an element of a component's base interface without change

client CompInterfB InterfA

Wrapper - example

• Component: provides access to graphics-rendering services, where the programmatic services are made available as Fortran libraries and the graphics rendering is done in terms of custom graphics primitives.

• Client: wants to access Component as a CORBA object• Wrapper: CORBA's interface description language (IDL)

can be used to specify the new interface that makes the component services available to CORBA clients rather than through linking with Fortran libraries. The repair code for the "provides assumptions" interface is the C++ skeleton code automatically generated by an IDL compiler. Also included in the repair code is hand-written code to tie the skeleton into component functionality.

Bridges• A bridge translates some requires assumptions of one arbitrary

component to some provides assumptions of another. • The key difference between a bridge and a wrapper is that the

repair code constituting a bridge is independent of any particular component. Also, the bridge must be explicitly invoked by some external agent—possibly but not necessarily by one of the components the bridge spans. This last point should convey the idea that bridges are usually transient and that the specific translation is defined at the time of bridge construction (e.g., bridge compile time).

• Bridges typically focus on a narrower range of interface translations than do wrappers because bridges address specific assumptions.

CompB Bridge

InterfB

CompAInterfA

Glue Code (external agent)

Bridge - example• Assume that we have two legacy components, one that produces PostScript

output for design documents and another that displays PDF (Portable Document Format) documents. We wish to integrate these components so that the display component can be invoked on design documents.

• Bridge: translates PostScript to PDF. The bridge can be written independently of specific features of the two hypothetical components—for example, the mechanisms used to extract data from one component and feed it to another. This brings to mind the use of UNIX filters, although this is not the only mechanism that can be used.

• A script could be written to execute the bridge. It would need to address component-specific interface peculiarities for both integrated components. Thus, the external agent/shell script would not be a wrapper, by our definition, since it would address the interfaces of both end points of the integration relation.

• Alternatively, either component could launch the filter. In this case, the repair mechanism would include a hybrid wrapper and filter: The wrapper would involve the repair code necessary to detect the need to launch the bridge and to initiate the launch.

Mediators• Mediators exhibit properties of both bridges and wrappers. The major

distinction between bridges and mediators, however, is that mediators incorporate a planning function that in effect results in runtime determination of the translation (recall that bridges establish this translation at bridge construction time).

• A mediator is also similar to a wrapper insofar as it becomes a more explicit component in the overall system architecture. That is, semantically primitive, often transient bridges can be thought of as incidental repair mechanisms whose role in a design can remain implicit; in contrast, mediators have sufficient semantic complexity and runtime autonomy (persistence) to play more of a first-class role in a software architecture. To illustrate mediators, we focus on their runtime planning function since this is the key distinction between mediators and bridges.

Client1

MediatorInterfB

CompInterfAClient2

InterfC

Mediators example

• Intelligent data fusion: • Component: a sensor that generates a high volume of

high-fidelity data. At runtime, different information consumers may arise that have different operating assumptions about data fidelity.

• Client1: a low-fidelity consumer requires that some information be "stripped" from the data stream.

• Client2: Another consumer may have similar fidelity requirements but different throughput characteristics that require temporary buffering of data.

• In each case, a mediator can accommodate the differences between the sensor and its consumers.

Component Based Development Process

identifypreliminaryarchitecture

identifypotential

places forreuse

establishselectioncriteria

functionalities, qualities, cost

search forapplicable

components

evaluatecomponents

selectcomponent

updatearchitecture