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: Subcomponents:
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 Clearly Identifiable Encapsulated
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: Assembly: Replaceable: Architecture:
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
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
MSIA715.03