Reuse la 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 independent Exemplu: 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 P1P2P3P4 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 Assets for 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 & commonality Example: Enchilada Product Line Enchilada GarnishTortilla Sauce Filling Tortilla Sauce Filling RedGreenPork BeefChicken or xor 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 payoff Number of products cost payoff Proactive Product Line No Product Line Reactive Product Line No Product 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 scratchBuy/get components (design) (fit into a design) Control complet Flexibilitate Rezolvare imediata Timp Cost intretinere Evaluare/testare Licente 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 components 2.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 clientComp InterfBInterfA

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. CompBBridge InterfB CompA InterfA 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 Mediator InterfB Comp InterfA Client2 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 identify preliminary architecture identify potential places for reuse establish selection criteria functionalities, qualities, cost search for applicable components evaluate components select component update architecture