13 Cbse

CBSE [email protected]

Coverage • Reuse • Motivation • CBSD/CBSE vs CBD • Terminology • Domain Engineering • Component Based Development • Economies of CBSE

Reuse • Historical aspect – Ad hoc – Experience

• Modern era – Locate scope of reuse and apply – Software Architecture, Design Patterns, Code reuse via libraries, Binary reuse…

Motivation

Players • OMG – CORBA

• Sun, Sunsoft – EJB

• Microsoft – COM, DCOM, ActiveX, COM+, etc.

Competition

CBSE/CBSD vs CBD • CBSE is about building software through composition. Assumes existence of components that can be readily employed under new development • CBD is about development of component • CBD is part of CBSE activity

CBSE definition – as per CMU • CBSE is concerned with the rapid assembly of systems from components where – Components and frameworks have certified properties – These certified properties provide the basis for predicting the properties of system build from components

Terminology • Components • Objects • Abstraction • Interfaces/Contracts • Component Model • Component Framework • COTS, Open Systems

Component – ECOOP workshop • A Software Component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties

Component – as per Szyperski – Component is a unit of independent deployment • Well separated from environment and other components

– Component is a unit of third party composition • Sufficiently self – contained

– Component has no persistent state • Cannot be distinguished from copies of itself

Component – as per CMU • Component is an opaque implementation of functionality – components will remain “black boxes” to consumers.

• Subject to third – party composition – Use should not depend upon tools or knowledge of the component that is in the possession of component provider

• Conformant with a component model – CM prescribe of how component interact with each other. Enforces design constraint

Object – as per Szyperski • Object is unit of instantiation. It has unique identity • An object has state (can be persistent) • Object encapsulates its state and behavior – Component may return Object to caller – Component need not be OO

Abstraction • Hide/expose required functionality • Base for reuse • Categories – Black box – White box – Grey box • Partial implementation details available

Interface • Mechanism for abstraction • Serve as contract between client and vendor – essentially functional requirement

• Means by which components connect – Technically, a set of named operations that can be invoked by client

• Direct (procedural) and Indirect (object) interfaces – Method dispatch.

Contract • States what client needs to do to use the interface • States what the provider has to implement to meet the services promised by the interface – Hoare triple {pre-condition} Operation {post-condition}

• Doesn’t capture non – functional service level requirements. But efforts are on.

Component Model • Standards and conventions imposed on developers of component • Purpose of CM – Enables uniform composition – Appropriate quality attribute – Deployment of components and applications

• Microsoft’s COM is an example of Component model

Component Framework • Implementations of services that support or enforces a component model • Analogous to OS in certain aspects – Components are to frameworks what processes are to OS

• For eg: EJB specifications defines framework of server and containers that support EJB Component model

Components Off The Shelf • A commercial off-the-shelf (COTS) product is a product, such as an item, material, component, subsystem, or system, sold or traded to the general public in the course of normal business operations at prices based on established catalog or market prices

Open Systems • An open system is a collection of interacting software, hardware, and human components – designed to satisfy stated needs – with interface specifications of its components that are • fully defined • available to the public • maintained according to group consensus

– in which the implementations of the components conform to the interface specifications

CBSE • Buy, do not build philosophy • Emphasis to composing software system. Focus on integration rather than implementation – Assembly line in engineering

• Assumption: sufficient commonality exist among large software systems to justify developing reusable components to exploit and satisfy commonality

CBSE Process model • Gather requirement • Establish architectural design • Examine requirements to determine what subsets are amenable to composition • Identify components required • Hunt for component (in-house or COTS)

Differences from other processes • Team attempts to modify or remove system requirements that cannot be implemented with COTS or in-house components • If requirement cannot be changed or deleted, then target component development (CBD)

CBD Model

Identify

Planning Customer Communication

Customer Evaluation

Risk Analysis

Search Lib Construct nth iteration Build Component

Engineering construction & Releases

Update Lib

Domain Analysis

Domain Engineering

Analysis

S/W Arch Development

Domain Model

Reusable Component Development

Structural Model

Repository Reusable Artifacts/ Components

Component Component Qualification Update Component Adaptation Architectural Application Component Design Software Adaptation

Component Based Development

Component Engineering

Testing

Domain engineering • Goes parallel to CBD in CBSE Process model • Intent is to identify, construct, catalogue and disseminate a set of software components that have applicability to existing and future software in a particular application domain • Paves path for future reuse

Domain Engineering activities • Analysis • Construction • Dissemination

Domain Analysis • Software Domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within same domain – Firesmith

Domain Analysis Technical Literature

Ttaxonomies

Existing app Sources of Domain Cust. Survey Knowledge Expert adv Current/Future Requirements

Reuse Std Domain Analysis

Domain Functional Analysis Model Model Domain Language

Analysis • Steps to identify and categorize – – – – – – – –

Select specific functions/ objects Abstract functions/objects Define a taxonomy Identify common features Identify specific relationships Abstract relationships Derive a functional model Define a domain language

Analysis – considerations • Is the component functionality required on future implementation • How common is the component’s function within the domain • Is there duplication of the component’s function within the domain • Is the component hardware dependent

Cont… • Does the H/W remain unchanged between implementations • Can the H/W specifics be removed to another components • Is the design optimized enough for the next implementations • Can we parameterize a non – reusable components so that it becomes reusable

Cont… • Is the component reusable in may implementations with only minor changes • Is reuse through modification feasible • Can a non – reusable component be decomposed to yield reusable components • How valid is component decomposition for reuse

Domain characteristics • Sometimes difficult to determine whether a potential candidate component is applicable in particular situation. – Need to define set of domain characteristics that are shared by all software in this domain

• A domain characteristic defines some generic attribute of all products that exist within the domain

Domain Characteristics • A set of Domain Characteristics can be represented by {Dp} where each item Dpi, in the set represents a specific domain characteristics. • Value assigned to Dpi represents an ordinal scale that is an indication of the relevance of the characteristics for component p – Eg: Not Relevant, Relevant under circumstances, Relevant but need adaptation, Clearly relevant, etc

Domain Characteristics • When new software, w, is to be built within the application domain, a set of domain characteristics are derived for it. A comparison between Dpi and Dwi is made to determine whether component p can be effectively used in application W. • Eg of Domain Characteristics – Wrt to Product: Requirement stability, memory constraints, saftey/ reliability etc.

Structural modeling • Structural modeling is a patternbased domain engineering approach that works under the assumption that every application domain has repeating patterns that have reuse potential

Structural Model • Consist of a small number of structural elements manifesting clear pattern of interaction. • Architecture of systems using structural model are characterised by multiple ensembles that are composed from these model elements. • Many architectural units emerge from simple patterns of interaction among this small number of elements – Pollak and Rissman

Structure points • Structure point is an abstraction that should have limited number of instances. The abstraction should recur throughout applications in the domain. Otherwise cost to verify, document and disseminate structure points cannot be justified • Rules to govern structure points should be easily understood. In addition, the interface to structure point should be simple

Cont… • Structure point should implement information hiding by isolating all complexity contained within the structure point itself. This reduces the perceived complexity of the overall system • Eg of Structure points – Application front end, Database, editor etc – Domain specific: in case of alarm system, Structure points may be sensor mgmt mechanism, response mechanism etc.

Component Engineering • Activities to do if component available against requirement – – – –

Component Component Component Component

qualification adaptation composition update

Component Qualification • System requirements and architecture define the components that will be required • Components understood by characteristic of their interfaces. – Interfaces provide limited knowledge about degree of fit for component within system architecture against requirements

• Those that qualify functional requirement should further be assessed for performance, reliability, usability etc (non-functional) requirements

Component Qualification – definition • Component qualification ensures that a candidate component – Will perform the function required – Will properly fit into the architectural style specified for the system – Will exhibit the quality characteristics required for the application

Component Qualifications – Factors • Application Programming interface • Development and integration tools required • Runtime Resource usage – Memory, storage etc

• Service requirements – Dependencies on OS, other components

Cont… • Security features – Access control, authentication protocol

• Exception handling • Misc – Design assumption by vendor. For eg. Use of certain algorithm (grey box)

Component adaptation • Software architecture represents design pattern that are composed of component connections, and coordination. • Component that mismatch against architecture design rules, must be adapted to meet the needs of architecture – Parameterised. Customizable – Wrapper

Component adaptation • Ideally, domain engineering creates library of components that can be easily integrated into application architecture – Consistency in interfacing with architecture, environment etc – Data management included etc

• However conflicts, incompatibilities may arise

Component wrapping • White box wrapping – Assumes knowledge of code. Modify code (may lead to maintenance probs)

• Grey box wrapping – Depends more on component library, model for provision of extension language. Seek facility to mask or disable conflict

• Black box wrapping – Add “in house” Pre and post

Wrapping • Generally wrapping means maintenance issues in case of new releases • Trade off issue – Effort to wrap component – Effort to create custom component – Manage variants, versions

Component Composition • Architectural style decide rules for integration of components to form a working system – Identifies connection and coordination mechanisms

Component Composition • Integration of available components (qualified, adapted, engineered) to populate the architecture established for the system • Infrastructural requirements – Component Model, Framework – Service requirements • Data exchange model, Automation, structured storage, underlying object model

Composition • Industrial standards for Model and Framework – – – – –

J2EE architecture .NET Framework CORBA OpenDoc SOM

Component update • Replace existing software as new version of components become available – CM issues

• When systems are implemented with COTS, update is complicated by the imposition of third party. The organization that developed the reusable component may be outside the immediate control of the software engineering organisation

Component Engineering • Building of components • Development issues are identical to traditional mode, except – Essence on reusability • Abstraction, functional independence

– Shift concern from domain to generic modules

Analysis and Design for reuse • Standard data – Application domain should be investigated and standard global data structures should be identified. All design components can be characterized to make use of standard DS

• Standard interface protocols – Intra modular interfaces – External interfaces • Human • Non – human

Got interfaces. Now what? • Interfaces would define set of operations required by client (modules, human, non – human) • Team identifies service provider. In this case component • Direct Interfaces - Directly provide procedural interface to traditional libraries • Indirect interfaces – indirection involved when using class libraries

Interfaces as contract • What clients needs to do to use “interface” • What provider has to implement to meet the services promised by “interface” • Client establish precondition before calling operation – Provider relies on precondition.

• Provider establish post condition – Client relies on post condition

Describing reuse components • Describe using 3Cs – Concept, Content and Context

• Concept – Description of what component does. Learn interface

• Content – Describes how concept is realised

• Context – Places component within domain of applicability

Comp Repository • Maintain library of component available by transforming 3C model into concrete schema • Three methodologies – Library and information science – Artificial intelligence method – Hypertext system

Library and Information Science method • Commonly used • Further three classification – Enumerated classification – Faceted Classification – Attribute – value classification

Enumerated Classification • Component described by a defined hierarchical structure in which classes and varying levels of subclasses are defined. Components would be at leaf node • Easy to understand and use but lacks flexibility

Faceted Classification • Domain area is analyzed and a set of basic descriptive features is identified. These features, facets, are then prioritized by importance and connected to a component • Set of facets describing a component is called facet descriptor

Facet Description • Facet can describe – Function of component – Data manipulated – Context in which component can be applied

• Facet Descriptor: {Function, object type, system type} – Eg {DeviceControl, C++, Real Time System}

Facet benefits • Keywords can be linked – Thesaurus building

• Searching is intelligent than the enumerated classification search

Attribute – value classification • Variant of faceted classification – A set of attributes is defined for all components in domain area. Values are then assigned to these attributes in same way in faceted classification

• It differs from faceted by – No limit on number of attributes – Attributes are not assigned priorities – Thesaurus functions not used

Economies of CBSE • Cost/benefit analysis for component reuse – Estimate cost metrics by comparing/ estimating when reused

• Alternate methodologies – Cost analysis using structure points – Reuse metrics

Impact on quality, productivity, cost • Quality – Reduction in defect rate considering that component is improvised iteratively – Measured in defects per KLOC

• Productivity – Less time spent on creating plan, model, develop (one time job per version) – 30 – 50% reuse can result in 25 – 40% productivity improvement

Cont… • Cost associated with re use include domain analysis, domain architecture development, etc. – Cs Cost if developed from scratch – Cr Cost associated with reuse – Cd Actual cost of S/W as delivered

Cost analysis using structure points • Structure points are reusable but their qualification, adaptation, integration and maintenance cost is nontrivial • Assess historical data – Collect cost for each instance of usage

• Overall effort = Enew + Equal + Eadapt + Eint – New (new comp), qual (qualify comp), adapt (adapt comp), int(integrate comp)

Reuse Metrics • Rb(S) = [Cnoreuse – Creuse] / Cnoreuse – Rb is benefit associated with reuse within System S – Cost no reuse/reuse cost of developing system S with no reuse/reuse

0 ≤ Rb(S) ≤ 1 • For OO Systems, reuse leverage is – Rlev = OBJreused / OBJbuilt – OBJ Reuse/built is number of object reused/built

Reuse Metrics • Commonality of a Component • Reuse Threshold of a Component – (minimum number of times a reusable component must be reused for ROI)

• Reuse Merit of a Component – (reusability of a component relative to the average reusability of a similar component)

• Reuse Creation Cost of a Component – (cost of purchasing the component + identifying it via domain analysis + preparing it for reuse)

Reuse metrics • Reuse Usage Costs of a Component – (costs of finding, understanding, modifying/specializing and integrating the reusable component)

• Reuse Maintenance Cost of a Component – (costs of supporting a reusable component)

• Degree of Commonality of a System or Business Area – (proportion of a system's / Business Area's common components)

Reuse Metrics Reuse metrics • Degree of Reusability of a System or Business Area – (proportion of a system's / Business Area's components are reusable)

• Reuse Target Level of a System (Business Area or Corporation) – minimum proportion of a system that is reusable.

• Reuse Merit of a System (or Business Area) – the proportion of a system (or Business Area's components) that is reusable relative to the avg. proportion for a system in one

References • Component Software. Beyond OO Programming – Clemens Syzperski

• Software Reusability – Volume I & II – Ted Biggerstaff & Alan Perlis

• Software Engineering. Practitioner approach – Pressman

Web References • SEI, CMU articles

– http://www.sei.cmu.edu/publications/docum – http://www.sei.cmu.edu/opensystems/faq.h – http://www.sei.cmu.edu/cbs/index.html

• Misc – CACM June 2003 and Oct 2002 issue