Component Oriented Programming 1 Introduction to COP.

Component Oriented Programming 1

Introduction to COP


Major Topics

• Define COP and its major objectives• Discuss the importance of COP• Define components and their characteristics• Distinguish hardware components and software

components• Investigate the differences between OOP and

COP• Introducing component-based software

engineering


Component

• Dictionary definition– A unit of, part of a model

• Hardware components• Software components

SD

1 2 3 4 5 6 7 8 9 10 11 12

• Differences?


What is a component? (1)1. A component is a nontrivial, nearly independent,

and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces. (Philippe Krutchen, Rational Software)

2. A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime. (Gartner Group)


What is a component? (2)3. 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 third-party composition. (Clemens Szyperski)

4. A business component represents the software implementation of an “autonomous” business concept or business process. It consists of the software artifacts necessary to express, implement, and deploy the concept as a reusable element of a larger business system. (Wojtek Kozaczynski, SSA)


What is a component? (3)

5. A reusable part of software, which is independently developed, and can be brought together with other components to build larger units. It may be adapted but may not be modified.

A component can be, for example, a compiled code without a program source, or a part of a model and/or design.

--- D'Souza and Wills


What is a component? (4)

6. A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard.

--- Councill and Heineman


What are in common?

• A piece of software• Independently deployable• Composable • Self-contained• Reusable

– A set of interfaces provided to, or required from the environment.

– An executable code, which can be coupled to the code of other components via interfaces.


What are the differences?

• These definitions begin from the consideration of CBSE from different viewpoints and focus on different aspects of software engineering such as: – Different phases (design, implementation and

run-time phases)– Business aspects– Executable or not– Architectural issues


Implications of Szyperski’s definition

• The following implications arise as a result of Szyperski’s definition:– For a component to be deployed

independently, a clear distinction from its environment and other components is required.

– A component must have clearly specified interfaces.

– The implementation must be encapsulated in the component and is not directly reachable from the environment.


Implications of Councill & Heineman’s definition

• A software component simply cannot be differentiated from other software elements by the programming language used to implement the component.

• The difference is in how software components are used.

• The definition of Software components depends on the underlined component model.


What is CBSE

• CBSE: Component-Based Software Engineering– How to create reusable components– How to create software products with reusable

components– Analysis, Design, Programming, Testing,

Maintenance of component-based software– Requirements, Specification, Provisioning, Assembly

of component-based software

• COP: Component-Oriented Programming


Why CBSE?• The simplest answer: components are the way to go

because all other engineering disciplines introduced components as they became mature & still use them.

• Use component paradigm to simulate “Software Integrated Circuit” to resolve software crisis.

• “Object orientation has failed but component software is succeeding” Udell, 1994 – Object technology does not include the notions of independence

or late composition, mostly used to construct monolithic application. Configuring and integrating an individual object into some given system is not normally possible.

– Object technology tends to ignore the aspects of economies and markets. Today only small amount of catalogs of class, class libraries, and frameworks exist.

• Components are independent units of deployment!


Commonality and Difference

• SP (Structured Programming)

• OOP (Object-Oriented Programming)

• COP (Component-Oriented Programming)

– What are common?– What are different?


SP OOP COP

Divide and conquer for managing complexity break a large problem down into smaller pieces

Yes Yes Yes

Unification of data and function a software entity combines data and the functions processing those data. improve cohesion

Yes Yes

Encapsulation The client of a software entity is insulated from how that software entity’s data is stored or how its functions are implemented. Reduce coupling

Yes Yes

Identity Each software entity has a unique identity

Yes Yes

Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency

Yes


COP vs OOP and SP

• Other differences?

• Identify at least one more difference.


Composability

– Software entity and its ability of being integrated with other entities

• SP – functions, procedures: low

• OOP – classes, objects: high

• COP – components: very high


The Interchangeability

• SP: Two different implementations can never be interchangeable.

• OOP: Two different objects implementing the same specification are interchangeable.

• COP: Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components.


Component Goals

• If you are asked to name three goals for using component technology, what are they?– Write down your wish list for CBD or COP


Component Goals

1. Conquering complexity

2. Managing change

3. Reuse


Conquering Complexity

• We are living in a complex world!• “The world produces between 1 and 2

exabytes of unique information per year, which is roughly 250 megabytes for every man, woman, and child on earth. An exabyte is a billion gigabytes, or 1018 bytes.”

• http://www.sims.berkeley.edu/research/projects/how-much-info/summary.html


Year AT&T BSD MINIX Linux Solaris Win NT

1976 V6 9K

1979 V7 21K

1980 4.1 38K

1982 Sys III 58K

1984 4.2 98K

1986 4.3 179K

1987 SVR3 92K 1.0 13K

1989 SVR4 280K

1991 0.01 10K

1993 Free 1.0 235K 5.3 850K 3.1 6M

1994 4.4 Lite 743K 1.0 165K 3.5 10M

1996 2.0 470K 4.0 16M

1997 2.0 62K 5.6 1.4M

1999 2.2 1M

2000 Free 4.0 1.4M 5.8 2.0M 2000 29M


Managing Change• Change is inherent in software engineering.• The user requirements change, specifications

change, personnel change, budgets change, technology change, etc. etc.

• This means building for change, design for change, is necessary.

• It is important to place primary emphasis during architecture and design on the dependencies between the components, and the management of those dependencies.


Reuse

• Design and implement something once and use it over and over again in different contexts.

• This will realize large productivity gains, taking advantage of best-in-class solutions, the consequent improved quality, and so forth.

• Develop for reuse, and develop with reuse


CBSE

• Component-Based Software Engineering

• CBSE = COA + COD + COP + COM

• Two key activities:– Development for reuse– Development with reuse


Component Forms

1. Component specification

2. Component interface

3. Component implementation

4. Installed component

5. Component object


Component Specification

• The specification of a unit of software that describes the behavior of a set of Component Objects and defines a unit of implementation.

• Behavior is defined as a set of Interfaces. A Component Specification is realized as a Component Implementation.


Component Interface

• A definition of a set of behaviors that can be offered by a Component Object .


Component Implementation

• A realization of Component Specification, which is independently deployable.

• This means it can be installed and replaced independently of other components. It does not mean that it is independent of other components – it may have many dependencies. It does not necessarily mean that it is a single physical item, such as a single file.


Installed Component

• An installed (or deployed) copy of a Component Implementation.

• A Component Implementation is deployed by registering it with the runtime environment. This enables the runtime environment to identify the Installed Component to use when creating an instance of the component, or when running one of its operations.


Component Object

• An instance of an Installed Component. • A runtime concept. • An object with its own data and a unique

identity. • The thing that performs the implemented

behavior. An Installed Component may have multiple Component Objects (which require explicit identification) or a single one (which may be implicit).


Summary

• A component is a reusable software element confirms to a component model

• Software engineering has gone through SP and OOP towards COP

• There are three goals for COP • Interface and independently deployable are the

unique features of COP comparing to OOP and SP

• There could have many different forms of components

Date post:	05-Jan-2016
Category:	Documents
Upload:	rebecca-porter
View:	234 times
Download:	1 times

Component Oriented Programming 1 Introduction to COP.

Documents