COMPONENT-BASED SOFTWARE ENGINEERING (CBSE) is an approach to software development that relies on the reuse of entities called SOFTWARE COMPONENTS. It emerged from the failure of object-oriented development to support effective reuse: single object classes are TOO DETAILED AND SPECIFIC to reuse widely. A COMPONENT is an independent executable entity that can be made up of one or more executable objects. The component interface is published, and all interactions are through the published interface. COUNCILL AND HEINEMAN'S DEFINITION: "a software element that conforms to a standard component model and can be independently deployed and composed without modification according to a composition standard." SZYPERSKI'S DEFINITION: "a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties." THE ESSENTIAL PROPERTIES of a component: STANDARDISED conforms to a standard component model (interfaces, metadata, documentation, composition, deployment) INDEPENDENT composable without needing other specific components; dependencies are stated as required interfaces COMPOSABLE all external interactions through publicly defined interfaces; provides access to its own information (methods and attributes) — REFLECTION DEPLOYABLE self-contained, able to operate as a stand-alone entity on a platform implementing the component model. BINARY, not compiled from source. DOCUMENTED fully documented so potential users can decide whether it meets their needs TWO KINDS OF INTERFACE — this distinction is the heart of the component model: PROVIDES INTERFACE defines the services provided BY the component. It is the component's API. Drawn as a "lollipop" —○ REQUIRES INTERFACE specifies what services must be provided by OTHER components in the system for this component to work. Drawn as a socket —( Component ─○ provides: printDocument, queueStatus ─( requires: fileSystem, networkTransport WHY THE REQUIRES INTERFACE MATTERS: it makes the component's dependencies EXPLICIT AND CHECKABLE. A component whose dependencies are hidden inside its code cannot be independently deployed, because you cannot tell what else it needs. "Explicit context dependencies only" in Szyperski's definition is precisely this requirement. COMPONENT MODELS — a definition of standards for component implementation, documentation and deployment. Examples: EJB, COM+/.NET, CORBA Component Model, OSGi. A model specifies: · how INTERFACES should be defined and the elements included in their definition · how components are NAMED and how names are globally unique · component METADATA — information about the component itself, accessible through reflection · how components are CUSTOMISED for a deployment · how components are COMPOSED · how components are PACKAGED for DEPLOYMENT And it usually provides MIDDLEWARE SERVICES: platform services (addressing, component discovery) and horizontal services (transactions, concurrency, persistence, security).

CBSE PROCESSES support component-based development. Two types: DEVELOPMENT FOR REUSE — developing components that will be reused in other applications; usually involves generalising an existing component. DEVELOPMENT WITH REUSE — developing new applications using existing components. THE KEY PROCESS DIFFERENCE FROM CONVENTIONAL DEVELOPMENT: requirements are REFINED AND MODIFIED according to the components available. Rather than specifying and then building, you specify, search, and then TRADE the specification against what exists. This is a real change in how requirements are treated, and it can be uncomfortable for customers. THE CBSE-WITH-REUSE PROCESS: 1. outline system requirements 2. identify candidate components 3. modify requirements according to discovered components 4. architectural design 5. identify components again (the architecture reveals more needs) 6. compose components to create the system DEVELOPMENT FOR REUSE — making a component reusable requires work, and the work has a cost: · remove application-specific methods · change names to make them general · add methods to broaden coverage · make exception handling consistent, and remove exception handling where the caller should decide · add a configuration interface so the component can be adapted · integrate required components to reduce dependencies THE ECONOMICS: the reusable version costs MORE than the specific one — commonly quoted at 1.5× to 2× — and pays back only across several uses. This is the same break-even logic as a software product line. COMPONENT COMPOSITION — the process of assembling components to create a system. Three types: SEQUENTIAL the composed components are executed in sequence; combines their provides interfaces. A new interface is needed, because the composition is used as a unit. HIERARCHICAL one component calls on the services of another; the provides interface of one is composed with the requires interface of the other. ADDITIVE two or more components are put together side by side, so their interfaces are put together to create a new component with the union of their functionality. INTERFACE INCOMPATIBILITY — the practical problem of composition. Three kinds: PARAMETER operations have the same name but different numbers or types of parameters OPERATION the names of the operations in the composed interfaces are different OPERATION the component you have does not include all INCOMPLETENESS the operations required by the composition THE SOLUTION: an ADAPTOR component that reconciles the interfaces of the components being composed. It translates one interface into another — the same idea as the Adapter design pattern.

CBSE's benefits are real and so are its costs. This section is what distinguishes an understanding of CBSE from a recitation. BENEFITS · reduced development TIME and COST · higher QUALITY, because a widely used component has been tested by many users in many contexts — genuinely more testing than you could afford · reduced RISK, because the component's behaviour is known · you get the benefit of expertise you do not have (crypto, compression, PDF rendering, timezone handling — all areas where a home-grown version is almost certainly wrong) PROBLEMS — Sommerville's list, each with the reality behind it: COMPONENT TRUSTWORTHINESS Components are black boxes; there is no source code, so you cannot inspect what it does. How do you know it is trustworthy? Certification schemes have been proposed and have not really taken hold. → and the modern form of this problem is worse: a transitive dependency you never chose runs with your application's full privileges. COMPONENT CERTIFICATION Who certifies the quality of components? There is no accepted authority. EMERGENT PROPERTY PREDICTION Because components are opaque, predicting their emergent properties — especially non-functional ones like performance and reliability — is difficult. Two components each meeting their spec can compose into a system that misses yours: recall from the previous topic that availabilities MULTIPLY. REQUIREMENTS TRADE-OFFS Making trade-offs between the requirements as specified and what the available components can do. This means the customer does not get exactly what was asked for, and that conversation must be had honestly. THE COSTS NOT ON SOMMERVILLE'S LIST BUT VISIBLE TODAY: · MAINTENANCE COUPLING — you now upgrade on someone else's schedule. A security patch in a dependency is your emergency. · ABANDONMENT — the component's author may stop maintaining it, leaving you to fork or replace it. · LICENCE OBLIGATIONS — a copyleft licence in a transitive dependency can impose obligations on your product that nobody intended. · SIZE AND SURFACE — pulling a large library for one function carries the whole attack surface, as the left-pad and Log4Shell incidents demonstrated at scale. A QUANTIFIED VIEW OF THE BUILD-OR-REUSE DECISION: Suppose a PDF-generation capability. BUILD: 60 person-days to write, 15 person-days/year to maintain, and you own every bug REUSE: 3 person-days to integrate, plus an upgrade cost of ~2 person-days/year, plus the risk of a forced urgent upgrade over 5 years: build = 60 + 5 × 15 = 135 person-days reuse = 3 + 5 × 2 = 13 person-days A 10× saving, which is why nobody writes their own PDF library. The decision inverts, however, when the capability IS your product — a company whose value is its rendering engine should not outsource rendering. THE DECIDING QUESTION: is this capability a DIFFERENTIATOR or a COMMODITY? Reuse commodities aggressively; build differentiators yourself. That single test resolves most build-or-buy arguments.