A Servicebased Requirements Model to Drive Component Selection and Constrain Composition

1
A Service-based Requirements Model to Drive
Component Selection and Constrain Composition
Predictable Assembly Workshop 20-21/5/04
John Hutchinson Lancaster University
Luigi Briguglio Engineering IngegnariaInformatica
Gerald Kotonya Lancaster University
2
Organisation

• CBSE challenges
• A view of CBD
• CBSE Process
• COMPOSE
• COREx requirements elicitation, ranking,
  modelling
• Design
• Component Selection
• ECO-ADM implementation
• Conclusions
• Questions

3
CBSE Challenges

• Many of the key benefits of component-based
  development rely on treating components as
  blackbox entities
• Productivity
• Reliability
• Shorter development time, etc.
• Treating components as blackboxes is one of the
  principle challenges that CBD faces
• Traditional development approaches are
  inappropriate
• Waterfall
• Evolutionary development

4
CBSE Challenges (2)

• Lack of tools/processes to support development
  with reuse
• Limited specifications
• Variability (of features, quality, etc. and
  context)
• Design assumptions of third party components
• Lack of methods for mapping functionality
• Identification of services
• Partitioning of services
• The requirements elicitation/specification aspect
  of CBD has been neglected
• We think our view of the main challenges helps to
  define our view of CBSE/SOC

5
A View of CBD

• Taken from the ECO-ADM Best Practices Manual

6
A View of CBD (2)

• Crucial to see that specification, design,
  architectures and implementations are driven by
  the requirements

7
A View of CBD (3)

• But also that requirements are dependent on the
  rest of the system

8
CBSE Process

• COMPOSE COMPonent-Oriented Software
  Engineering
• Extends notion of service to requirements
  definition to provide a framework for mapping
  requirements to a hybrid component/service-oriente
  d architecture
• Incorporates negotiation as a key process
  activity
• Focuses on system formulation and design
• Critically, the COMPOSE method is geared towards
  working with blackbox components

9
CBSE Process (2)

• Separate development cycles for creating and
  using components

10
CBSE Process (3)
11
CBSE Process (4)

• COREx (Component-Oriented Requirements
  Expression) - the requirements approach used in
  COMPOSE has 3 iterative steps interleaved with
  component verification, negotiation and planning
• Elicit requirements
• Rank/scope requirements
• Model requirements as services
• And these take place alongside component
  verification and selection activities.
• Services are mapped onto components

12
CBSE Process (5)

• Requirements Elicitation
• Based on the notion of viewpoints. Viewpoints
  correspond to requirements sources which comprise
  end-users, systems interfacing with the proposed
  system, organisation and external concerns

13
CBSE Process (6)

• Requirements ranking
• In COMPOSE benefit is used as a basis for ranking
  requirements and solution-dependent aspects such
  as effort and risk are deferred to the component
  verification stage.
• Requirement benefit is categorised as
• Essential features
• Important features
• Useful features

14
CBSE Process (7)

• Requirements modelling
• In COREx/COMPOSE, requirements modelled as
  services
• Service is characterised by
• at least one identifiable function
• a trigger by which the service commences
• a recipient (Actor viewpoint)
• service provider (proposed system/component)
• conditions for service delivery
• constraints on service provision
• Service descriptions are derived from viewpoint
  requirements and represent a level of abstraction
  in the requirement description
• Partitioned into abstract sub-systems during
  design phase

15
CBSE Process (8)

• Services Model

16
CBSE Process (9)

• Services and Constraints form a link between
  requirements and components
• Modelled at different levels of abstraction

17
CBSE Process (10)

• In COMPOSE the design process is driven by
  services identified as part of a requirements
  process ensuring traceability between
  requirements definition and architectural design
• The design starts with the partitioning of
  service descriptions into logical sub-systems as
  part of an iterative process

18
CBSE Process (11)

• A top-down process is used to partition the
  system by clustering services to reflect desired
  architectural and system properties
• Negotiation in the design process is essential to
  achieve balance between competing needs (e.g.
  security and performance)
• The flexibility and implementation-independent
  nature of services means the engineer can explore
  different technologies to compose the system
• Allows for hybrid systems that combine components
  and services

19
CBSE Process (12)
20
CBSE Process (13)

• Services represent functional specifications
• Constraints may represent
• High-level constraints on the system
  (non-functional requirements)
• Constraints on particular services in a
  particular system context
• Component-imposed constraints
• Together, they can represent system requirements
  and the result of trade-offs appropriate to a
  particular system context
• Because CADL is used to model both elements of
  system design and components, it creates a direct
  link between requirements, design decisions and
  the composed system

21
Example - Requirements
22
Example (2) Modelling
23
Example (3) Modelling
24
Example (4) - Partitioning
25
Example (5) Identify interfaces
26
Component Selection

• Component selection can be achieved by
  formulating selection filters to match
  requirements to a checklist

27
Component Selection (2)

• ExampleGiven the set of candidates T1 C1,
  C2, C3, C4, S1 the filter ?c Ti
  ?(c.checklist(1) ? 1) gives T2 C2, C3, C4
  Or the filter ?c Ti ?(c.checklist(1) 2 ?
  (c.checklist(1)1 ? c.checklist(7) 2)) gives T3
  C2, C4 More complex examples are possible
  (low risk/low effort)?c Ti ?(c.checklist(1)
  2 ? c.checklist(2)2 ? c.checklist(4) 2 ?
  c.checklist(6) 2 ? c.checklist(10) 2 ?
  c.checklist(11) 2 )

28
CBSE Selection (3)

• Filters provide a means to capture dependencies
  and interactions (e.g. the example of requiring
  support if modification was required)
• Other tools and approaches can be used
• In COMPOSE, we have proposed the use of the
  multi-criteria decision analysis approach SMART
  (Simple Multi-Attribute Rating Technique)
• AHP (Analytic Hierarchy Process) could also be
  used
• Need to explore the degree to which these
  approaches can be used to support the required
  negotiation process
• We believe that negotiation is critical to CBD
  (esp. blackbox)

29
Summary
This is the layer that dictates what the system
must do we therefore need a requirements
engineering approach that takes account of
components
In this layer, we must match requirements with
components and negotiate trade-offs where
appropriate. For this, we require some sort of
common language for describing both, but we
also want to feed anything that we can down to
the design/composition.
CADL
At this layer, real components exist. They have
specifications (at different levels of detail),
interfaces, etc.
30
ECO-ADM

• How far have COMPOSE and COREx been tested?
• They are partially implemented in the ECO-ADM
  tools
• CADL is implemented as a means of representing
  abstract and concrete components, designs and
  composed systems
• Services and constraints are implemented as a
  means of modelling both requirements and
  components (although the service description
  facility is limited)
• Components can be searched/proposed on the basis
  of services supported and CADL represented
  properties

31
ECO-ADM (2)
Concrete Architecture (CADL)
Abstract Architecture (CADL)
ECO-ADM COMPOSER
ECO-ADM DESIGNER
D
C
32
ECO-ADM (3) Identifying services with
requirements
33
ECO-ADM (4) Selecting components to deliver
services
34
ECO-ADM (5) Selecting components to deliver
services existing pattern
35
ECO-ADM (6) Connector Model I
COTS A
COTS B
connector

• A link that enables communication between two or
  more instances. The link may be realized by
  something as simple as a pointer or by something
  as complex as a network connection.UML 2.0
  Superstructure Specifications (August 2003)

36
ECO-ADM (7) Connector Model II
Glue Code
Role A
Role B
37
Conclusions

• Development with off-the-shelf technologies IS
  the future (whether they be components or
  services)
• Challenges associated with blackbox development
  are central to realising the benefits of CBD
• They are significant and must be addressed
• COMPOSE begins to address some of the issues
• Partially implemented in ECO-ADM tools

38
Questions?