The Business Case for Components-Based Development (CBD)

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 MSIA715.03