This chapter discusses different ways that components and services can be supplied, including reusing existing functionality, renting functionality from external sources, buying functionality externally, or building new functionality. It covers making supply decisions based on identifying functional units and whether they will be components or services. The main part discusses the component delivery workflow, including defining specifications, designing components, constructing them, testing, and rolling them out. It also discusses maintaining components over time.

1. Chapter Three
Supply

2. Introduction
• Supply is about the provisioning of components and services,
whether these are reused, rented, bought, or built.
• This chapter outlines the different ways in which components and
services can be supplied and gives more detail on the activities
for designing and constructing components.
• The normal approach to supplying components is to build them,
and this is covered in detail in the later component delivery
workflow.
• With the rise of web services, however, other options to building
are now available, e.g. renting a service.

3. Cont.
• From a straightforward development point of view, there is little
difference between using a component and a web service; each is
a black box that provides a certain type of functionality exposed
through one or more interfaces.
• Regardless of whether the functionality will be implemented as a
component or a service, certain choices about how to obtain the
required functionality must be made:-
– reuse existing functionality that is available within your organization;
– rent the functionality from an external source;
– buy the functionality in from an external source;
– build your own functionality.
• For more detail see Table 3.1 on your text book

4. Making the supply decisions
• Supply decisions can be made once you have defined your
units of functionality then identified and allocated these to an
architectural layer.
• These decisions consider whether each functional unit should
be a component or a web service and whether they can be
reused/rented/bought/built.
• The issue of provenance is important to the utilization of
services as opposed to components.
• In addition to its functionality, certain quality and cost
judgments must be made about a service that are not
necessarily required for a component.

5. key factors to consider while making a supply
decision
• Will the service provider or the specific service still be here next
year, i.e. for the anticipated lifetime of the application?
• What is the cost model of the service?
• Use of a service may increase the cost of the application over the
life cycle.
• Does the service provide the appropriate level of systemic
quality? If the service is accessed across the public internet, what
impact will this have in terms of scalability and availability?
• For more explanation see table 3.2 on your text book

6. Component delivery
• The main development process on the supply side of the supply–
manage–consume approach to component-based development is
component delivery.
• These activities define the component services, specify the
internal architecture in terms of its classes, and combine with the
technical infrastructure to deliver an executable package for the
component.
• This is a view of the component based on concepts that are
meaningful to analysts, developers, and programmers.

7. Cont.
• Component delivery is a generic workflow that covers the different
types of component: business, technical, and data.
• Each type of component has the same set of activities within the
workflow, but each will have its own specialist developers,
techniques, and mindset that deliver the component model, and
the executable.

9. Basic workflow

10. Define component specification
• An agreed component specification includes:-
– Details of the service interfaces, including each service signature.
– The environment in which the component is going to be used and
deployed.
– A black-box test specification, which is used to determine whether the
delivered component meets the requirements defined in the component
specification.
• To help to achieve agreement on the specification, a component
management tool is used to publish each iteration so that
comments and feedback from the component’s user community
can be reviewed and any issues arising resolved.

11. Design component
• This step in component delivery provides a model of the internal
architecture of the component in terms of its classes, defines the
data services required, and may produce or update the persistent
data model.
• UML analysis techniques are used to model the component’s
internal structure to deliver the required component services.
• This means identifying candidate classes and their attributes,
assigning class responsibilities, and identifying class
relationships.

12. Cont.
• During all stages, it is recommended that any design decisions be
documented.
• Finally, the component’s object model is reviewed by others in the
component delivery team.
• Once the classes have been agreed, the next step is to identify
their behavior (class methods).
• This involves producing object interaction diagrams for each
component service and, perhaps, state diagrams for key classes.

13. Cont.
• As each class will have data requirements, it is important at this
point to identify the services required from data components.
• Data components are used to separate the database technology
from the business components.

14. Construct component
• Constructing the component involves realizing the design of the
component combined with the technical infrastructure to deliver a
tested set of services.
• Scheduling the parts in the component that are to be constructed
is determined by the use case priority, i.e. ‘build only what you
need now’.
• Therefore, for each component, service to be implemented, only
those operations on classes involved in delivering the service
need be constructed.

15. Cont.
• This may be a very small part of the overall component, so we are
not spending time on unnecessary items. This activity has slight
differences in the early steps for each type of component:-
– Business components require data and technical components to realize
the solution.
– Data components deliver a set of services for the given data component
specification.
– Technical components such as base classes and facility components
such as an error handler may require data component services and their
own base classes.

16. Test and rollout component
• Execute tests means running test scripts defined for this increment as well as
running those scripts for previous increments to ensure that the latest
changes have not broken existing services.
• All tests need to be performed under black-box conditions to verify the
external behavior of the component.
• If the tests fail, then the component developer must identify and fix the
problem; it is not the test team’s responsibility to fix the component, as there
may be errors in the OO analysis, the design or the code.
• All test results – good and bad – are documented. When the tests are
passed, then rollout means publication of the tested component
executable/package to the component user community.

17. Componentization of legacy systems
• In order to maximize the investment in current applications, it may
be necessary to use the existing functionality by providing a set of
services for new applications.
• In providing these services, various levels of effort and approach
are required to integrate the application.

18. Cont.
• These efforts can deliver wrapper components, which:-
– Encapsulate unchanged functionality in the legacy application.
– Component specifications containing the functional requirements extracted for the
existing legacy application through reverse engineering.
– Components that encapsulate the re-engineered functionality extracted from the legacy
application.
• The initial step is to define the integration strategy by assessing the
application architecture.
• After assessment, stakeholder must be agreed to ensure the feasibility of an
appropriate componentization strategy, as more than one approach can be
applied in any situation: wrapping, re-engineering, and reverse engineering.

19. Cont.
• Wrapping:-
– A wrapper is a component that provides a message-based interface to
non-object-oriented software such as the functionality within a legacy
application.
• Re-engineering:-
– Re-engineering the legacy application means altering the existing
functionality or interfaces to meet the new business needs.
• Reverse engineering
– Reverse engineering means using the existing logic and data descriptions
as specifications for new components, i.e. recreating the same
functionality within a new environment.

20. Cont.
• Whichever approach is taken, you must be aware of the risks
involved in integrating new and old systems:-
– changes to legacy code may impact the wrapper component.
– the required functionality may be inaccessible.
– the level of complexity and dependencies may be too high.
– changes to the legacy application may affect the new system.
– legacy code may be too hard to understand.
– there may be no sources of expertise in the legacy application.

21. Maintain component
• To resolve a defect first update the defect log, then recreate the
incident and determine a candidate solution.
• An agreed solution is used to update the component specification
and issue it to the component delivery team.
• To resolve change requests first identify the affected items, and
determine the impact and feasibility of change before scheduling
the change.

22. • Whenever changes are planned, it is useful to update the risk
register to reflect the increased risk of doing the change (ripple
effect) and for not doing the change (reduced functionality).
• The updated component specification is then issued ready for the
start of the scheduled component delivery process to incorporate
the changes.

23. Technical architecture
• Components must guarantee that they can ‘inter-operate’, i.e.
coexisting and cooperating within a common technical
environment.
• Therefore, supplying a technical architecture is key to the
successful delivery of component- or service-based solutions.
• Delivery of the technical architecture is achieved in two stages.
– The initial technical architecture is assembled and delivered.
– The technical architecture is applied to multiple development projects.