Download presentation
Presentation is loading. Please wait.
1
1 CBSE Process: issues and Challenges Gerald Kotonya Computing Department Lancaster University United Kingdom Gerald Kotonya Computing Department Lancaster University United Kingdom
2
www.comp.lancs.ac.uk 2 OrganisationOrganisation Background CBSE Process Elements of CBSE Process ConclusionsBackground CBSE Process Elements of CBSE Process Conclusions
3
www.comp.lancs.ac.uk 3 BackgroundBackground CBSE is the process of building software systems from pre-fabricated software components Motivation Improving software quality and Reducing development costs However software component technology is still immature and poses many challenges for organisations intending to adopt it Poorly documented components Vulnerability risk Limited adaptability of components Limited interoperability across component technologies Component volatility Many of these problems can be mitigated by a better appreciation of the processes for developing component-based systems CBSE is the process of building software systems from pre-fabricated software components Motivation Improving software quality and Reducing development costs However software component technology is still immature and poses many challenges for organisations intending to adopt it Poorly documented components Vulnerability risk Limited adaptability of components Limited interoperability across component technologies Component volatility Many of these problems can be mitigated by a better appreciation of the processes for developing component-based systems
4
www.comp.lancs.ac.uk 4 CBSE Processes
5
www.comp.lancs.ac.uk 5 Development with reuse
6
www.comp.lancs.ac.uk 6 Development process The planning phase sets out: Justification, objectives, strategies (methods and and resources to achieve the development objectives) Tactics ( start and end dates, tasks with duration) for the development project The development phase implements the agenda set out in the planning phase The verification phase is intended to verify the extent of “fitness” of various component solutions The negotiation phase attempts to find an acceptable trade-off between the software components and system being built The planning phase sets out: Justification, objectives, strategies (methods and and resources to achieve the development objectives) Tactics ( start and end dates, tasks with duration) for the development project The development phase implements the agenda set out in the planning phase The verification phase is intended to verify the extent of “fitness” of various component solutions The negotiation phase attempts to find an acceptable trade-off between the software components and system being built
7
www.comp.lancs.ac.uk 7 RE for development with reuse Good requirements engineering is essential for successful component-based system development (Ncube and Maiden, ’99) Basis for component specification Basis for initial system design Critical for understanding change impact Challenge To develop requirements models and methods that allow us make the best use of the available component technology By balancing aspects of requirements with the capabilities offered by software components, and the architectural assumptions embodied in the software components Good requirements engineering is essential for successful component-based system development (Ncube and Maiden, ’99) Basis for component specification Basis for initial system design Critical for understanding change impact Challenge To develop requirements models and methods that allow us make the best use of the available component technology By balancing aspects of requirements with the capabilities offered by software components, and the architectural assumptions embodied in the software components
8
www.comp.lancs.ac.uk 8 Requirements engineering Need to understand the system requirements from ‘external perspectives’ (Kotonya ’99, Nuseibeh ’98) Component-based systems development is primarily a problem of integrating black-box components rather than creating components Need for mechanisms that allow us to model the behavioural and non-behavioural properties Most requirement methods are concerned with functional properties of system Service modelling? Analysis by contract? etc… Need to provide a mechanism for evaluating and ranking requirements Cost-value analysis (criticality, effort, risk, stability etc) Need to understand the system requirements from ‘external perspectives’ (Kotonya ’99, Nuseibeh ’98) Component-based systems development is primarily a problem of integrating black-box components rather than creating components Need for mechanisms that allow us to model the behavioural and non-behavioural properties Most requirement methods are concerned with functional properties of system Service modelling? Analysis by contract? etc… Need to provide a mechanism for evaluating and ranking requirements Cost-value analysis (criticality, effort, risk, stability etc)
9
www.comp.lancs.ac.uk 9 Requirements engineering (contd.) Need for schemes that support negotiation (PORE, AHP, SMART) In practice the desired level of component software capability and quality is rarely achieved Early evaluation is useful for establishing the availability and broad capabilities of off-the-shelf software components For certain critical requirements, a component (COTS) solution may not be adequate or even appropriate Need requirements schemes that reflect the changing ‘face’ of software component technology Component as a leased service Component as an off-the-shelf black-box software Need for schemes that support negotiation (PORE, AHP, SMART) In practice the desired level of component software capability and quality is rarely achieved Early evaluation is useful for establishing the availability and broad capabilities of off-the-shelf software components For certain critical requirements, a component (COTS) solution may not be adequate or even appropriate Need requirements schemes that reflect the changing ‘face’ of software component technology Component as a leased service Component as an off-the-shelf black-box software
10
www.comp.lancs.ac.uk 10 Design for development with reuse Component-based system design Describes how the components that make up the system interact to deliver the desired functionality and, the appropriateness of particular components and services in different contexts Provides a good basis for performing impact analysis Component-based system design Describes how the components that make up the system interact to deliver the desired functionality and, the appropriateness of particular components and services in different contexts Provides a good basis for performing impact analysis
11
www.comp.lancs.ac.uk 11 Design process Need for formal mechanisms that allow the designer to define architectural elements and their relationships and to support their evolution through levels of abstraction (UML 2.0?, Catalysis, D’Souza ’98; ADLs Shaw, ‘96; Medvidovic ‘00) The design process starts with the partitioning of the system requirements (services and associated constraints) into logical “components” or “sub- systems” The initial partitioning is driven by architectural considerations (possibly supported by design patterns that lend themselves to those properties) Subsequent partitioning is subject to a negotiation process that must take into account business concerns, architectural considerations and software component considerations Need for formal mechanisms that allow the designer to define architectural elements and their relationships and to support their evolution through levels of abstraction (UML 2.0?, Catalysis, D’Souza ’98; ADLs Shaw, ‘96; Medvidovic ‘00) The design process starts with the partitioning of the system requirements (services and associated constraints) into logical “components” or “sub- systems” The initial partitioning is driven by architectural considerations (possibly supported by design patterns that lend themselves to those properties) Subsequent partitioning is subject to a negotiation process that must take into account business concerns, architectural considerations and software component considerations
12
www.comp.lancs.ac.uk 12 Design process (contd.) Need for mechanisms that allow the designer to evaluate the extent of “fitness” of a component or group of components in a context The main objective of designer is to achieve “fitness for use” Fitness is a property which is achieved when a component has an acceptable match with the context in which it is going to operate. Need for mechanisms that allow the designer to evaluate the extent of “fitness” of a component or group of components in a context The main objective of designer is to achieve “fitness for use” Fitness is a property which is achieved when a component has an acceptable match with the context in which it is going to operate.
13
www.comp.lancs.ac.uk 13 CompositionComposition Need for formal mechanisms to support system composition System composition proceeds by replacing abstract design level components with concrete ‘equivalents’ and integrating them Concrete components might be required to fulfil certain constraints (cost, architectural, resource etc ) before a replacement is allowed to proceed Support for adaptation For many systems there is need to repair a design “misfit” The accompanying integration process may make use of some "gluing technology", which may be unrelated to the components: To provide an interface between components To adapt incompatible components Need for formal mechanisms to support system composition System composition proceeds by replacing abstract design level components with concrete ‘equivalents’ and integrating them Concrete components might be required to fulfil certain constraints (cost, architectural, resource etc ) before a replacement is allowed to proceed Support for adaptation For many systems there is need to repair a design “misfit” The accompanying integration process may make use of some "gluing technology", which may be unrelated to the components: To provide an interface between components To adapt incompatible components
14
www.comp.lancs.ac.uk 14 VerificationVerification Component and system testing is a critical aspect of component-based development Black-box nature of components Perception of quality may vary Extraneous features Component and system testing is a critical aspect of component-based development Black-box nature of components Perception of quality may vary Extraneous features
15
www.comp.lancs.ac.uk 15 ComplicationsComplications Poor specification The lack of detailed component specification diminishes the quality of testing that can be done. Enterprise heterogeneity Different, possibly competing vendors may supply components Technological heterogeneity In a distributed environment, different components may be developed for different hardware and operating system platforms Test adequacy assessment A major problem with testing component-based systems is the lack of a sufficient theoretical basis for assessing the adequacy of the tests Inability to perform ‘direct’ tests As in the case of web services Poor specification The lack of detailed component specification diminishes the quality of testing that can be done. Enterprise heterogeneity Different, possibly competing vendors may supply components Technological heterogeneity In a distributed environment, different components may be developed for different hardware and operating system platforms Test adequacy assessment A major problem with testing component-based systems is the lack of a sufficient theoretical basis for assessing the adequacy of the tests Inability to perform ‘direct’ tests As in the case of web services
16
www.comp.lancs.ac.uk 16 Suggested solutions Voas (Voas, ‘98) the risk posed by unreliable components should lead developers to think in terms of disposable software systems Dean (Dean ’99) independent certification of components is the way to address the problem, particularly for critical systems Harrold (Harrold ’99) the component vendor should make a summary of the test and analysis information available with the component Others have suggested that components have built in tests (e.g. IST COMPONENT+) Voas (Voas, ‘98) the risk posed by unreliable components should lead developers to think in terms of disposable software systems Dean (Dean ’99) independent certification of components is the way to address the problem, particularly for critical systems Harrold (Harrold ’99) the component vendor should make a summary of the test and analysis information available with the component Others have suggested that components have built in tests (e.g. IST COMPONENT+)
17
www.comp.lancs.ac.uk 17 Testing regimes To address these problems, component- testing regimes should serve the following aims: DiscoveryVerification Fitness for purpose MaskingAdequacy To address these problems, component- testing regimes should serve the following aims: DiscoveryVerification Fitness for purpose MaskingAdequacy
18
www.comp.lancs.ac.uk 18 Trust as mechanism for verification Models of trust Contractual schemes are intended to provide cover against the effects of unsatisfactory or unexpected performance of a particular product Certification schemes are based on the belief that certified products have undergone rigorous testing and found to be fit for use (conform to certain quality standards) Experience-based schemes rely on reputed trust Local evaluation schemes strive to establish ‘demonstrated trust’. May be based on Detailed evaluation Self certification Models of trust Contractual schemes are intended to provide cover against the effects of unsatisfactory or unexpected performance of a particular product Certification schemes are based on the belief that certified products have undergone rigorous testing and found to be fit for use (conform to certain quality standards) Experience-based schemes rely on reputed trust Local evaluation schemes strive to establish ‘demonstrated trust’. May be based on Detailed evaluation Self certification
19
www.comp.lancs.ac.uk 19 Management: Maintenance and extended development The maintenance and extended development of a component-based application poses many risks to the customer (Dean and Vidger ’99) Nature of the development process Application domain System design characteristics Choice of software components used Choice of software components used The maintenance and extended development of a component-based application poses many risks to the customer (Dean and Vidger ’99) Nature of the development process Application domain System design characteristics Choice of software components used Choice of software components used
20
www.comp.lancs.ac.uk 20 Elements of risk Different vendor-customer evolution cycles Funding risk Vulnerability risk Upgrade risk Hidden incompatibilities New data formats that may require that the contents of existing files and databases be modified Changes in the quality attributes Additional capabilities that may have to be suppressed or restricted due to security concerns Incompatibility with the existing hardware or operating platform Changes in system resource requirements may be incompatible with the existing hardware and operating system Different vendor-customer evolution cycles Funding risk Vulnerability risk Upgrade risk Hidden incompatibilities New data formats that may require that the contents of existing files and databases be modified Changes in the quality attributes Additional capabilities that may have to be suppressed or restricted due to security concerns Incompatibility with the existing hardware or operating platform Changes in system resource requirements may be incompatible with the existing hardware and operating system
21
www.comp.lancs.ac.uk 21 Addressing the risks Asset management Need for mechanisms for managing and tracking the acquisition, usage and evolution software components impact analysis Need for impact analysis techniques. The system management process must consider the different ways that a component might cause changes to the operational system Quality control Need for cost-effective quality control methods that address the problem of the fault identification, repair, and the tracking of system fixes. Configuration management Need for a framework for tracking and controlling the versions of components and custom software installed at all sites Market research Asset management Need for mechanisms for managing and tracking the acquisition, usage and evolution software components impact analysis Need for impact analysis techniques. The system management process must consider the different ways that a component might cause changes to the operational system Quality control Need for cost-effective quality control methods that address the problem of the fault identification, repair, and the tracking of system fixes. Configuration management Need for a framework for tracking and controlling the versions of components and custom software installed at all sites Market research
22
www.comp.lancs.ac.uk 22 SummarySummary Component-based system development is a highly iterative process requiring simultaneous consideration of: The system context (system characteristics such as requirements, cost, schedule, operating and support environments), Capabilities of software components in the marketplace Viable architectures and designs We have identified the challenges and problems likely to be faced by component-based system developers The importance of verification has been emphasised and a discussion of the management challenges of component-based systems provided We have highlighted the importance of the process in mitigating the problems posed by CBD Component-based system development is a highly iterative process requiring simultaneous consideration of: The system context (system characteristics such as requirements, cost, schedule, operating and support environments), Capabilities of software components in the marketplace Viable architectures and designs We have identified the challenges and problems likely to be faced by component-based system developers The importance of verification has been emphasised and a discussion of the management challenges of component-based systems provided We have highlighted the importance of the process in mitigating the problems posed by CBD
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.