Chapter 1 Introduction

1
Chapter 1 Introduction
2
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

3
Component

• Dictionary definition
• A unit of, part of a model
• Hardware components
• Software components

• Differences?

4
What is a component? (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)

5
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)

6
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

7
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

8
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.

9
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

10
Implications of Szyperskis definition

• The following implications arise as a result of
  Szyperskis 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.

11
Implications of Councill Heinemans 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.

12
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

13
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!

14
Commonality and Difference

• SP (Structured Programming)
• OOP (Object-Oriented Programming)
• COP (Component-Oriented Programming)
• What are common?
• What are different?

15
(No Transcript)
16
COP vs OOP and SP

• Other differences?
• Identify at least one more difference.

17
Composability

• Software entity and its ability of being
  integrated with other entities
• SP functions, procedures low
• OOP classes, objects high
• COP components very high

18
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.

19
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

20
Component Goals

• Conquering complexity
• Managing change
• Reuse

21
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

22
(No Transcript)
23
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.

24
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

25
CBSE

• Component-Based Software Engineering
• CBSE COA COD COP COM
• Two key activities
• Development for reuse
• Development with reuse

26
Component Forms

• Component specification
• Component interface
• Component implementation
• Installed component
• Component object

27
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.

28
Component Interface

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

29
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.

30
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.

31
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).

32
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