component based development

28
- 1 - Component Based Development R&D SDM 1 2010 Theo Schouten

Upload: wright

Post on 19-Jan-2016

39 views

Category:

Documents


0 download

DESCRIPTION

Component Based Development. R&D SDM 1 2010 Theo Schouten. Content. Component Based Development, what is it Engineering of Component Based Software Development Domain Engineering Component Based Development Standard Software packages book chapter 30 Component-Based Software Engineering - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Component Based Development

- 1 -

Component Based Development

R&D SDM 1

2010Theo Schouten

Page 2: Component Based Development

- 2 -

Content• Component Based Development, what is it• Engineering of Component Based Software Development• Domain Engineering • Component Based Development• Standard Software packages

book

chapter 30 Component-Based Software Engineering

7th ch 10 Component level design

Page 3: Component Based Development

- 3 -

Elements of CBD

• Reuse of software components• Buy, don’t develop

– ‘Commercial off-the-shelf’ (COTS)• Shift of attention:

– From programming to composing– From design to selection

• Speed of development• Cost efficient

Page 4: Component Based Development

- 4 -

History• functions (subroutine) in first “high level” programming

languages, provided reuse in libraries– LINPACK, EISPACK (1970’s), LAPACK (1992-now)

• Object Oriented languages– reuse of classes and sets thereof

• 1968 Douglas McIlroy “Mass Produced Software Components”– leaded to pipes and filters in Unix

• 1986 Brad Cox Objective-C– strict superset of C with Smalltalk-style messaging– Steve Job, NEXT, Mac OS X, Cocoa API– became very popular last year (see TIOBE)

Page 5: Component Based Development

- 5 -

Origin CBD (or CBSE)

• Component-based software engineering (CBSE) is a general approach to software development that is based on software reuse.

• It emerged from the failure of object-oriented development to support effective reuse. Single object classes are too detailed and specific.

• Components are more abstract than object classes and can be considered to be stand-alone service providers.

Page 6: Component Based Development

- 6 -

Definitions‘Component Based Software Engineering (CBSE) is changing the way software systems

are developed. CBSE embodies the ‘buy, don’t build’ philosophy……

CBSE shifts the emphasis from programming software to composing software systems.

Implementation has given way to integration as the focus.

At its foundation is the assumption that there is sufficient commonality in many large software systems to justify developing reusable components to exploit and satisfy that commonality’

Clements 1995

Page 7: Component Based Development

- 7 -

What is a Component?• OMG Unified Modeling Language Specification [OMG01]

defines a component as – “… a modular, deployable, and replaceable part of a

system that encapsulates implementation and exposes a set of interfaces.””

• OO view: a component contains a set of collaborating classes

• Conventional view: a component contains processing logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it.

Page 8: Component Based Development

- 8 -

CBSE essentials• Independent components specified by their interfaces.• Component standards to facilitate component integration.• Middleware that provides support for component

interoperability.• A development process that is geared to reuse.

Page 9: Component Based Development

- 9 -

Design principles• Components are independent, no interference• Component implementations are hidden• Communication is through well-defined interfaces• Container: service provider for locating and getting

component interface

ContainerContainer

Component

Implementation

Interface

Page 10: Component Based Development

- 10 -

Component models• A component model is a definition of standards for

component implementation, documentation and deployment.

• Examples of component models– EJB model (Enterprise Java Beans)– COM+ model (.NET model)– OMG Corba Component Model

• The component model specifies how interfaces should be defined and the elements that should be included in an interface definition.

Page 11: Component Based Development

- 11 -

OMG/ CORBA• The Object Management Group has published a common object

request broker architecture (OMG/CORBA). • An object request broker (ORB) provides services that enable

reusable components (objects) to communicate with other components, regardless of their location within a system.

• Integration of CORBA components (without modification) within a system is assured if an interface definition language (IDL) interface is created for every component.

• Objects within the client application request one or more services from the ORB server. Requests are made via an IDL or dynamically at run time.

• An interface repository contains all necessary information about the service’s request and response formats.

Page 12: Component Based Development

- 12 -

Sun JavaBeans• The JavaBeans component system is a portable, platform

independent CBSE infrastructure developed using Java• It encompasses a set of tools, called the Bean Development

Kit (BDK), that allows developers to – analyze how existing Beans (components) work– customize their behavior and appearance– establish mechanisms for coordination and

communication– develop custom Beans for use in a specific application– test and evaluate Bean behavior.

Page 13: Component Based Development

- 13 -

Microsoft COM• The component object model (COM) provides a

specification for using components produced by various vendors within a single application running under the Windows operating system.

• COM encompasses two elements: – COM interfaces (implemented as COM objects)– a set of mechanisms for registering and passing

messages between COM interfaces.

Page 14: Component Based Development

- 14 -

Decision place in classical development

Phase 1Definition

Phase 1Definition

Phase 2Design

Phase 2Design

Phase 3Realize

Phase 3Realize

Phase 4Implement

Phase 4Implement

Ph

ase

sS

tep

sD

ocu

men

ts

VaststellenSysteem Behoeften

Definitie studie

Requirements Analysis

FunctioneelOntwerp

Functionele Specificatie

Haalbaarheids-studie

HaalbaarheidsRapport

Technisch Ontwerp

Technische Specificatie

No

Yes Component Based Development

Questions:- Is COTS available to fulfill the requirements ?- Are internally developed modules suitable?- Are the interfaces of the components compatiblewith the architecture?

Page 15: Component Based Development

- 15 -

Engineering of CBS

Make a formal difference between maintaining the ‘standard’ components and the implemented components. For updates the standard components are leading!

• This should fill in the following aspects:– Identifying the components which are candidates for implementation– Qualifying the interfaces of the components– Adapting of the components to the architecture– Updating of the components due to changes in the requirements.

• CBSE Process:– Domain Engineering: Library Function– Component Based Development: Implementation Function

Page 16: Component Based Development

- 16 -

Domain Engineering

Domain Analysis

Domain Analysis

SoftwareArchitectureDevelopment

SoftwareArchitectureDevelopment

ReUsableComponent

Development

ReUsableComponent

Development

DomainModel

DomainModel

StructuralModel

StructuralModel

Component

LibraryRepositoryReUsable

Components

Component Based Development

AnalysisAnalysis Architecture Design

Architecture Design

ComponentComposition

ComponentComposition

ComponentUpdate

ComponentUpdate

ComponentAdaptation

ComponentAdaptation

ComponentQualification

ComponentQualification

ComponentEngineering

ComponentEngineering

TestingTesting

ApplicationSoftware

Component

Implementatio

n

CBSEAnalysis Construction Dissemination

Page 17: Component Based Development

- 17 -

Domain Engineering

• identify, construct, catalog and disseminate a set of software components

• that can be applied to existing and future software for a particular domain

• Most important functions:– Analysis, Construction and Dissemination

Page 18: Component Based Development

- 18 -

Domain Engineering Analysis

• Define the domain to be investigated• Representative sample of applications in the domain

– business rules, best practices• Develop a model for the domain

Page 19: Component Based Development

- 19 -

Domain Engineering Construction• Selection of function or object

• Reuse?:

– Is the functionality needed for future implementations?

– What is the degree of reusability (commonality)?

– Is there a duplication of the functions in the domain?

– Is the component hardware dependent?

– Is the design optimal for future implementations?

– Can a non-reusable component be re-parameterized such that it becomes reusable?

– Is it useful to decompose or re-parameterize a component for reuse?

• construct a structural model

Page 20: Component Based Development

- 20 -

Domain Engineering: Dissemination

Product/Technology- Requirements Stability- Concurrent Software- Memory Constraints- Application Size- User Interface Complexity- Programming Languages- Safety/Reliability- Lifetime Requirements- Product Quality- Product Reliability

Product/Technology- Requirements Stability- Concurrent Software- Memory Constraints- Application Size- User Interface Complexity- Programming Languages- Safety/Reliability- Lifetime Requirements- Product Quality- Product Reliability

Process- Process Model- Process Conformance- Project Environment- Schedule Constraints- Budget Constraints- Productivity

Process- Process Model- Process Conformance- Project Environment- Schedule Constraints- Budget Constraints- Productivity

People- Motivation- Education- Experience/Training

- Application domain- Process- Platform- Language

- Development Team- Productivity

People- Motivation- Education- Experience/Training

- Application domain- Process- Platform- Language

- Development Team- Productivity

• Library of components

• characterization for possible reuse

• looking to various aspects for it

Page 21: Component Based Development

- 21 -

Component Based Development

• Analysis of the particular application– referring to the domain model

• Architectural design– referring to the structural model

• Component qualification, adaption, composition– possible engineer another component

• testing

Page 22: Component Based Development

- 22 -

Component qualification

• can a selected component effectively be reused?• its interface• development and integration tools required• runtime requirements : resources, speed, network protocol• services requirements like OS interfaces and support of

other components• security features like access control and authentication

protocols

Page 23: Component Based Development

- 23 -

Component adaption

• Assure that the component integrates easily in the architecture:

• consistent methods for resource management for all components;

• common activities for e.g. data management for all components;

• interfaces between components and the outside world have been developed in a consistent way.

• use component wrapping or custom component?

Page 24: Component Based Development

- 24 -

Component composition

• assembling of qualified, adapted or engineered components• Common architecture environment, elements:

– Data Exchange model: human-to-software, between components, among system resources

– Automation, tools macro’s and scripts– Structured Storage, accessing heterogeneous data in a

single data structure– Underlying Object Model, assures interoperability

Page 25: Component Based Development

- 25 -

CBSE problems• Component trustworthiness - how can a component with no

available source code be trusted?• Component certification - who will certify the quality of

components?• Emergent property prediction - how can the emergent

properties of component compositions be predicted?• Requirements trade-offs - how do we do trade-off analysis

between the features of one component and another?

Page 26: Component Based Development

- 26 -

Ariane launcher failure• In 1996, the 1st test flight of the Ariane 5 rocket ended in

disaster when the launcher went out of control 37 seconds after take off.

• The problem was due to a reused component from a previous version of the launcher (the Inertial Navigation System) that failed because assumptions made when that component was developed did not hold for Ariane 5.

• The functionality that failed in this component was not required in Ariane 5.

Page 27: Component Based Development

- 27 -

Standard packages• SAP, Oracle, Peoplesoft, etc.• developed for specific business processes;• Strong development in the last years (shift from custom made to

standard packages);• ‘Enabler’ of working in a process way (BPR);• ‘Best practice’ business processes build in;• Started in the ERP environment (‘Enterprise Resource Planning’) =

primary business processes, extended to many other environments• large changes in methodology for implementation of software systems.

Page 28: Component Based Development

- 28 -

Final remarks• CBSE and standard packages change an implementation from ‘programming to

composing’ and from ‘design to select’;• Integration of modules in existing architectures becomes more and more important:

interfaces;• Custom made around the standard applications cq. modules becomes complex and

has to be integrated;• Aspects with relation to what is leading, my ‘requirement’ or the ‘package’

become important issues;• Management and ‘human factors’ stay the most important aspects for the success

of a implementation.