Software Models (Cont.)

1
Software Models (Cont.)

• Component-based software engineering
• Formal Development Model

2
Objectives

• To explain that CBSE is concerned with developing
  standardised components and composing these into
  applications
• To describe components and component models
• To show the principal activities in the CBSE
  process
• To discuss approaches to component composition
  and problems that may arise

3
Topics covered

• Components and component models
• The CBSE process
• Component composition

4
Component-based development

• Component-based software engineering (CBSE) is an
  approach to software development that relies on
  software reuse.
• It emerged from the failure of object-oriented
  development to support effective reuse. Single
  object classes are too detailed and specific.
• Components are more abstract than object classes
  and can be considered to be stand-alone service
  providers.

5
CBSE essentials

• Independent components specified by their
  interfaces.
• Component standards to facilitate component
  integration.
• Middleware that provides support for component
  inter-operability.
• A development process that is geared to reuse.

6
CBSE and design principles

• Apart from the benefits of reuse, CBSE is based
  on sound software engineering design principles
• Components are independent so do not interfere
  with each other
• Component implementations are hidden
• Communication is through well-defined interfaces
• Component platforms are shared and reduce
  development costs.

7
CBSE problems

• Component trustworthiness - how can a component
  with no available source code be trusted?
• Component certification - who will certify the
  quality of components?
• Emergent property prediction - how can the
  emergent properties of component compositions be
  predicted?
• Requirements trade-offs - how do we do trade-off
  analysis between the features of one component
  and another?

8
Components

• Components provide a service without regard to
  where the component is executing or its
  programming language
• 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

9
Component definitions

• Councill and Heinmann
• A software component is a software element that
  conforms to a component model and can be
  independently deployed and composed without
  modification according to a composition standard.
• Szyperski
• A software component is 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.

10
Component as a service provider

• The component is an independent, executable
  entity. It does not have to be compiled before it
  is used with other components.
• The services offered by a component are made
  available through an interface and all component
  interactions take place through that interface.

11
Component characteristics 1
12
Component characteristics 2
13
Formal Specification
14
Objectives

• To explain why formal specification techniques
  help discover problems in system requirements

15
Topics covered

• Formal specification in the software process

16
Formal methods

• Formal specification is part of a more general
  collection of techniques that are known as
  formal methods.
• These are all based on mathematical
  representation and analysis of software.
• Formal methods include
• Formal specification
• Specification analysis and proof
• Transformational development
• Program verification.

17
Acceptance of formal methods

• Formal methods have not become mainstream
  software development techniques as was once
  predicted
• Other software engineering techniques have been
  successful at increasing system quality. Hence
  the need for formal methods has been reduced
• Market changes have made time-to-market rather
  than software with a low error count the key
  factor. Formal methods do not reduce time to
  market
• The scope of formal methods is limited. They are
  not well-suited to specifying and analysing user
  interfaces and user interaction
• Formal methods are still hard to scale up to
  large systems.

18
Use of formal methods

• The principal benefits of formal methods are in
  reducing the number of faults in systems.
• Consequently, their main area of applicability is
  in critical systems engineering. There have been
  several successful projects where formal methods
  have been used in this area.
• In this area, the use of formal methods is most
  likely to be cost-effective because high system
  failure costs must be avoided.

19
Specification in the software process

• Specification and design are inextricably
  intermingled.
• Architectural design is essential to structure a
  specification and the specification process.
• Formal specifications are expressed in a
  mathematical notation with precisely defined
  vocabulary, syntax and semantics.

20
Specification and design
21
Specification in the software process
22
Use of formal specification

• Formal specification involves investing more
  effort in the early phases of software
  development.
• This reduces requirements errors as it forces a
  detailed analysis of the requirements.
• Incompleteness and inconsistencies can be
  discovered and resolved.
• Hence, savings as made as the amount of rework
  due to requirements problems is reduced.

23
Cost profile

• The use of formal specification means that the
  cost profile of a project changes
• There are greater up front costs as more time and
  effort are spent developing the specification
• However, implementation and validation costs
  should be reduced as the specification process
  reduces errors and ambiguities in the
  requirements.

24
Development costs with formal specification
25
Specification techniques

• Algebraic specification
• The system is specified in terms of its
  operations and their relationships.
• Model-based specification
• The system is specified in terms of a state model
  that is constructed using mathematical constructs
  such as sets and sequences. Operations are
  defined by modifications to the systems state.

26
Formal specification languages