MSIA715.03 1

The Business Case for Components-Based Development (CBD)

• Time to Market for the entire product is less, because components can be developed simultaneously.

• Quality

• Reliability

• Cost: reduced development effort lowers cost

• Maintenance: re-use results in fewer defects

• Flexibility: adding new functionality may be easier; components can be re-assembled in different ways.

MSIA715.03 2

What is a Component?

• “A self-contained recognizable thing that does something useful and well understood. It does it largely by itself, but can be combined with other components using known interfaces to build something complex.”

• No firm definition- components should be defined by their characteristics.

MSIA715.03 3

What do we design first - the system or the components?

• Chicken or the Egg Tautology?

• Is this the right question to ask?

• Customer requirements = endstate; system designed to achieve the endstate, and the components are designed to contribute to the system.

• Therefore, the system comes first, but before designing the system, what does the customer require? Style, or price/performance, or both?

MSIA715.03 4

Component Newspeak

• Bits:– Material: raw materials– Parts:

• items usually bought-in that are assembled into components, subcomponents, assemblies, or systems. They have limited function and low added value. They may be considered as very simple, low-level components.

– Subcomponents: • parts that have significant function and added value.

– Components: • self-contained, recognizable entities that perform a well-understood

function and can be assembled via known interfaces.

– Assemblies: parts and components fitted together.

MSIA715.03 5

Component Newspeak - Structures

• Logical components: conceptual decompositions of a design.

• Patterns: recurring structures in the use of components.

• Framework: partial product assembly that is scalable and extendable.

• Design: detailed description of a system showing how it should be assembled from parts, assemblies, and total components.

• Product Line: series of designs showing how a family of related products are to be build from common components.

• Architecture: high-level conceptual representation

• Domain: well-understood area of common interest

• Environment: set of conditions in which a system or component is designed to operate.

• Technology: particular method or material used to manufacture parts and components which determines the detail of how they are assembled.

MSIA715.03 6

Component Newspeak- Usage

• Local reuse– reuse of components within a product, product line, or by a small

team in several products.

• Domain reuse– systematic reuse of well-understood common components across a

specific area of interest, often in specific environments.

• Global reuse– Widespread reuse across domains, organizations, environments,

and geography. All the knowledge needed to use the component has to be made explicit.

MSIA715.03 7

Views of Components

• Software components, defined:– “The big difference between software and the other domains we

have discussed is the richness of the function provided.”

– “. . .a component is a self-contained, clearly identifiable, physically realizable, pre-defined entity that provides a well-understood function and is intended to be assembled, using a well-defined architecture and interfaces, with other components to provide more complex functions.”

– “A component is not so much a specific thing, but more a label that can be applied to types of things that meet certain criteria about how they can be used.

MSIA715.03 8

Component Attributes

• Self-contained– The component must deliver its function in its entirety without the

need to access other components or parts.

• Clearly Identifiable– The component’s functions should be clearly identifiable and well

understood within the domain or which it is intended.

• Encapsulated– The component’s function should be completely independent from

its implementation, both in terms of design and technology.

MSIA715.03 9

Component Attributes

• Physically Realizable:– The component must be capable of being used “in its own right”

and being assembled with other components. Thus, a component must be one of the following:

• physically in existence and be available for assembly into a larger entity (e.g., a software module or class library in a repository).

• Automatically generated, on demand, from a preexisting design.

• Pre-instantiated, within an operating system or network and can be accessed at run-time.

• Instantiated on-demand, and accessed within an OS or network.

• Embedded function within larger system, accessed via pre-defined interface without knowingly interacting with embedded system.

• Logical representation of a physical component; activates it.

MSIA715.03 10

Component Attributes

• Pre-defined:– prior to use and fit within the architectural and functional

definitions of the domain.

• Assembly:– can be assembled into a larger structure of components either

creating a single larger entity or a network of comm components.

• Replaceable:– by an alternative component with an equivalent specification

• Architecture:– the component is defined to be assembled within a known

architecture or structure.

MSIA715.03 11

Component Attributes

• Interface:– Component designed to make use of a specific interface.

• Status: component has an owner and defined status.

• Reusable one of the following ways– Compositional reuse: unmodified reuse (black box - BB)

– Configuration: unmodified reuse, software-defined function (BB)

– Generative reuse: reuse of generation process rather than particular components (white box - WB)

– Adaptive reuse: reuse by modifying existing components (WB)

– Integrated: existing components modified and integrated using newly-developed interfaces (WB).

MSIA715.03 12

Generic Types of Software Components

• Black Box Components:– Specified entirely by function and interface, and used exactly in

the form in which it is provided.

• White Box Components:– Provided with all the source codes so that all details of its structure

and implementation are visible to the end user.

• Glass Box Components:– A White Box component which is used unmodified.

• Grey Box Components:– A White Box component with only minor modifications.

MSIA715.03 13

Examples of Specific Types of Software Components

• Procedures, subroutines, objects and class libraries– Structured decomposition techniques programmed into software

– Good programmers structure code into functional blocks that are easily understood and frequently reused.

• Objects and class libraries– Objects are not necessarily components.

– Typical objects provide very low-level functions that are not clearly recognizable

– Strong commercial market in class libraries (particular GUI libraries), good for software reuse but fall short of becoming components.

MSIA715.03 14

Examples of Specific Types of Software Components, continued

• Operating Systems:– Among the most widely reused elements in software

– Author characterizes them as “frameworks” as opposed to components, because they “come to life” and “extend” when applications run on top of them.

• Databases and Spreadsheets– Software components that are intended to be configured and

extended by the users.

– They are made to do something useful by the user configuring or programming them to work in a specific way that meets their requirements.

MSIA715.03 15

Examples of Specific Types of Software Components, continued

• Plugable Components– Self-contained, but never intended to be assembled with other

components. Instead, they are plugged into existing operating system or component frameworks.

– Akin to plug-ins for internet browsers, which can add significant extra functions to the basic browser.

MSIA715.03 16

Logical and Physical Components

• Logical:– Defined: the conceptual compositions of a design or architecture

into components that may or may not exist as physical components

– To implement, one must map the logical view of the world onto a physical realization, using a data model to map the physical systems that manipulate data entries to the logical components in which the data resides.

• Physical:– Evolve components into common function, and group by

functional blocks.

– Convert logical to physical, and concentrate on the physical view of the world.

MSIA715.03 17

A Layered Model of Components

• Components in a typical business enterprise hierarchy, from top to bottom:– Enterprise components (processes and business rules)

– Business components (business objects and frameworks)

– Systems components (legacy systems and applications)

– Mid-tier components (3-tier servers, legacy wrappers)

– Software components (objects and subroutines)

– Component technology (DCOM, CORBA, . . .).

MSIA715.03 18

A Layered Model of Components

• Component Object Model (COM)/Distributed COM (DCOM)– Main characteristic: its interfaces; there are basic interfaces, but

beyond that, the user can have any number of interfaces.

– “Inherited interfaces” create new interfaces by allowing new interfaces to be subclassed.

• Component Technologies:– MS COM, CORBA, and Enterprise Java Beans (EJB) are

component technologies.

MSIA715.03 19

A Layered Model of Components

• Common Object Request Broker Architecture (CORBA)– Unlike COM, which is vendor-specific

– Allows interoperability between component from any vendor, on any type of machine, or across a network.

– Not so much a component as it is middleware.

• Enterprise JAVA Beans: “write once, run anywhere.”– Launched to support the server components of Java Beans

– Operate in a “container” or thread environment

– CORBA and EJB are merging.

• Software Components:– Includes subroutines, function libraries, and Visual Basic.

MSIA715.03 20

A Layered Model of Components

• Mid-tier Components:– Three - tier model (top down): presentation layer, mid-tier, and

data storage.

– The third (mid) tier has to overcome initial problems:• Structure could start to resemble another data storage monolith

• Performance issues related to UNIX

• Migration to PCs at the presentation level

• Most enterprises had significant business value locked up in their mainframes, which were difficult to migrate and separate.

MSIA715.03 21

A Layered Model of Components

• System-Level Components:– Legacy components = embedded components

– Function is embedded in the legacy system and accessed through the interface via the client stub.

– The stub, the interface, and the legacy function are collectively the component.

– Further approach: three-tier client/server architecture

MSIA715.03 22

A Layered Model of Components

• Business-level components– Deployable component that represents a well-understood business

function.

– Typically generic, representing common entities as “customer” or “domain specific.”

– Enterprise Resource Planning (ERP) applications migrating to a component architecture.

• Enterprise components– High-level business models, process definitions, or architectures,

unique and not reused, typically.

MSIA715.03 23

A Layered Model of Components

• Commercial Off-The-Shelf (COTS)– Cost-effective; standards bodies such as the Object Management

Group (OMG) want to define a common set of objects to build common business applications.

– Risks involved with COTS:• Commercial viability of suppliers

• Implications of different standards bodies

• Feature interaction

• Quality, reliability, certification

• Tailorability, configurability

• Maintenance, enforced upgrades, obsolescence

• Whole life cycle costs and design methods