Software Reuse

1
Software Reuse
2
Objectives

• To explain the benefits of software reuse and
  some reuse problems
• To discuss several different ways to implement
  software reuse
• To explain how reusable concepts can be
  represented as patterns or embedded in program
  generators
• To describe the development of software product
  lines
• To introduce component-based software engineering

3
Topics covered

• The reuse landscape
• Design patterns
• Generator based reuse
• Application frameworks
• Application system reuse
• Component-based software engineering

4
Software reuse

• In most engineering disciplines, systems are
  designed by composing existing components that
  have been used in other systems.
• Software engineering has been more focused on
  original development but it is now recognised
  that to achieve better software, more quickly and
  at lower cost, we need to adopt a design process
  that is based on systematic software reuse.

5
Reuse-based software engineering

• Application system reuse
• The whole of an application system may be reused
  either by incorporating it without change into
  other systems (COTS reuse) or by developing
  application families. (Chapter 18)
• Component reuse
• Components of an application from sub-systems to
  single objects may be reused. (Chapter 19)
• Object and function reuse
• Software components that implement a single
  well-defined object or function may be reused.

6
Reuse benefits 1
7
Reuse benefits 2
8
Reuse problems 1
9
Reuse problems 2
10
Ariane launcher failure

• In 1996, the 1st test flight of the Ariane 5
  rocket ended in disaster when the launcher went
  out of control 37 seconds after take off.
• The problem was due to a reused component from a
  previous version of the launcher that failed
  because assumptions made when that component was
  developed did not hold for Ariane 5.
• Floating point to integer conversion of thrust
  value caused overflow and triggered an unhandled
  exception that shut down the Inertial Navigation
  System. The value stored in Ariane 4 was never
  large enough to cause overflow.
• The functionality that failed in this component
  was not required in Ariane 5.

11
The reuse landscape

• Although reuse is often simply thought of as the
  reuse of system components, there are many
  different approaches to reuse that may be used.
• Reuse is possible at a range of levels from
  simple functions to complete application systems.
• The reuse landscape covers the range of possible
  reuse techniques.

12
The reuse landscape
13
Reuse approaches 1
14
Reuse approaches 2
15
Reuse planning factors

• The development schedule for the software.
• The expected software lifetime.
• The background, skills and experience of the
  development team.
• The criticality of the software and its
  non-functional requirements.
• The application domain.
• The execution platform for the software.

16
Topics covered

• The reuse landscape
• Design patterns
• Generator based reuse
• Application frameworks
• Application system reuse
• Component-based software engineering

17
Concept reuse

• When you reuse program or design components, you
  have to follow the design decisions made by the
  original developer of the component.
• This may limit the opportunities for reuse.
• However, a more abstract form of reuse is concept
  reuse when a particular approach is described in
  an implementation independent way and an
  implementation is then developed.
• The two main approaches to concept reuse are
• Design patterns
• Generative programming.

18
Design patterns

• A design pattern is a way of reusing abstract
  knowledge about a problem and its solution.
• A pattern is a description of the problem and the
  essence of its solution.
• It should be sufficiently abstract to be reused
  in different settings.
• Patterns often rely on object characteristics
  such as inheritance and polymorphism.

19
Pattern elements

• Name
• A meaningful pattern identifier.
• Problem description.
• Solution description.
• Not a concrete design but a template for a design
  solution that can be instantiated in different
  ways.
• Consequences
• The results and trade-offs of applying the
  pattern.

20
Multiple displays
21
The Observer pattern

• Name
• Observer.
• Description
• Separates the display of object state from the
  object itself.
• Problem description
• Used when multiple displays of state are needed.
• Solution description
• See slide with UML description.
• Consequences
• Optimisations to enhance display performance are
  impractical.

22
The Observer pattern
23
Other examples

• Structural Patterns
• Focus How objects are composed to form larger
  structures
• Examples composite, adapter, bridge, proxy
• Behavioral Patterns
• Focus Algorithms and the assignment of
  responsibilities to objects
• Examples command, observer, strategy
• Creational Patterns
• Focus Creation of complex objects
• Examples abstract factory, builder

24
Composite pattern

• Models tree structures that represent part-whole
  hierarchies with arbitrary depth and width.

Component
Client
Leaf Operation()
Composite Operation() AddComponent RemoveComponen
t() GetChild()
Children
25
Adapter pattern
ClientInterface Request()
Client
LegacyClass ExistingRequest()
adaptee

• Delegation is used tobind an Adapter and an
  Adaptee
• Inheritance is use to specify the interface of
  the Adapter class.
• ClientInterface and Adaptee (usually called
  legacy system) pre-exist the Adapter.
• ClientInterface may be realized as an interface
  in Java.

26
Bridge pattern

• Abstraction hides the actual implemented
  operations from Client
• Implementor is an interface to different
  implementations
• Useful when trying out different implementations

27
Proxy pattern

• Proxy patterns can be used for lazy evaluation
  and for remote invocation.

28
Command pattern
Invoker
Command execute()
Client
binds

• Client creates a ConcreteCommand and binds it
  with a Receiver.
• Client hands the ConcreteCommand over to the
  Invoker which stores it.
• The Invoker has the responsibility to do the
  command (execute or undo).

29
Observer pattern

observers
subject

• The Subject represents the actual state, the
  Observers represent different views of the state.
• Observer can be implemented as a Java interface.
• Subject is a super class (needs to store the
  observers vector) not an interface.

30
Strategy pattern
Policy
Context ContextInterface()

ConcreteStrategyC AlgorithmInterface()
ConcreteStrategyB AlgorithmInterface()
ConcreteStrategyA AlgorithmInterface()

• Policy decides which Strategy is best given the
  current Context

31
Abstract factory
AbstractProductA
AbstractFactory CreateProductA CreateProductB
Client
ProductA1
ProductA2
AbstractProductB
CreateProductA CreateProductB
ConcreteFactory1
ProductB1
ProductB2
CreateProductA CreateProductB
ConcreteFactory2
Initiation Assocation Class ConcreteFactory2
initiates the associated classes ProductB2 and
ProductA2
32
Builder pattern
BuildPart()
Construct()
Builder
Director
For all objects in Structure
Builder-gtBuildPart()
Represen- tation B
BuildPart() GetResult()
ConcreteBuilderB
BuildPart() GetResult()
ConcreteBuilderA
Represen- tation A
33
Reference book

• Design Patterns Elements of Reusable
  Object-Oriented Software
• Erich Gamma, Richard Helm, Ralph Johnson, John
  Vlissides
• Addison-Wesley, 1995

34
Topics covered

• The reuse landscape
• Design patterns
• Generator based reuse
• Application frameworks
• Application system reuse
• Component-based software engineering

35
Generator-based reuse

• Program generators involve the reuse of standard
  patterns and algorithms.
• These are embedded in the generator and
  parameterised by user commands. A program is
  then automatically generated.
• Generator-based reuse is possible when domain
  abstractions and their mapping to executable code
  can be identified.
• A domain specific language is used to compose and
  control these abstractions.

36
Examples of program generators

• Examples
• Application generators for business data
  processing
• Parser and lexical analyser generators for
  language processing
• Code generators in CASE tools.
• Generator-based reuse is very cost-effective but
  its applicability is limited to a relatively
  small number of application domains.
• It is easier for end-users to develop programs
  using generators compared to other
  component-based approaches to reuse.

37
Reuse through program generation
38
Aspect-oriented development

• Aspect-oriented programming can be seen as
  another example of generative programming
• Aspect-oriented development addresses a major
  software engineering problem - the separation of
  concerns.
• Concerns are often not simply associated with
  application functionality but are cross-cutting -
  e.g. all components may monitor their own
  operation, all components may have to maintain
  security, etc.
• Cross-cutting concerns are implemented as aspects
  and are dynamically woven into a program. The
  concern code is reuse and the new system is
  generated by the aspect weaver.

39
Aspect-oriented development
40
Topics covered

• The reuse landscape
• Design patterns
• Generator based reuse
• Application frameworks
• Application system reuse
• Component-based software engineering

41
Application frameworks

• Frameworks are a sub-system design made up of a
  collection of abstract and concrete classes and
  the interfaces between them.
• The sub-system is implemented by adding
  components to fill in parts of the design and by
  instantiating the abstract classes in the
  framework.
• Frameworks are moderately large entities that can
  be reused.

42
Framework classes

• System infrastructure frameworks
• Support the development of system infrastructures
  such as communications, user interfaces and
  compilers.
• Example Java Swing
• Middleware integration frameworks
• Standards and classes that support component
  communication and information exchange.
• Example Enterprise Java Beans
• Enterprise application frameworks
• Support the development of specific types of
  application such as telecommunications or
  financial systems.

43
Extending frameworks

• Frameworks are generic and are extended to create
  a more specific application or sub-system.
• Extending the framework involves
• Adding concrete classes that inherit operations
  from abstract classes in the framework
• Adding methods that are called in response to
  events that are recognised by the framework.
• Problem with frameworks is their complexity which
  means that it takes a long time to use them
  effectively.

44
Model-view controller

• System infrastructure framework for GUI design.
• Allows for multiple presentations of an object
  and separate interactions with these
  presentations.
• MVC framework involves the instantiation of a
  number of patterns (as discussed earlier under
  concept reuse).

45
Model-view-controller
46
Topics covered

• The reuse landscape
• Design patterns
• Generator based reuse
• Application frameworks
• Application system reuse
• Component-based software engineering

47
Application system reuse

• Involves the reuse of entire application systems
  either by configuring a system for an environment
  or by integrating two or more systems to create a
  new application.
• Two types
• COTS product integration
• Product line development.

48
COTS product reuse

• COTS - Commercial Off-The-Shelf systems.
• COTS systems are usually complete application
  systems that offer an API (Application
  Programming Interface).
• Building large systems by integrating COTS
  systems is now a viable development strategy for
  some types of system such as E-commerce systems.
• The key benefit is faster application development
  and, usually, lower development costs.

49
COTS design choices

• Which COTS products offer the most appropriate
  functionality?
• There may be several similar products that may be
  used.
• How will data be exchanged?
• Individual products use their own data structures
  and formats.
• What features of the product will actually be
  used?
• Most products have more functionality than is
  needed. You should try to deny access to unused
  functionality.

50
E-procurement system
51
COTS products reused

• On the client, standard e-mail and web browsing
  programs are used.
• On the server, an e-commerce platform has to be
  integrated with an existing ordering system.
• This involves writing an adaptor so that they can
  exchange data.
• An e-mail system is also integrated to generate
  e-mail for clients. This also requires an adaptor
  to receive data from the ordering and invoicing
  system.

52
COTS system integration problems

• Lack of control over functionality and
  performance
• COTS systems may be less effective than they
  appear
• Problems with COTS system inter-operability
• Different COTS systems may make different
  assumptions that means integration is difficult
• No control over system evolution
• COTS vendors not system users control evolution
• Support from COTS vendors
• COTS vendors may not offer support over the
  lifetime of the product

53
Software product lines

• Software product lines or application families
  are applications with generic functionality that
  can be adapted and configured for use in a
  specific context.
• Adaptation may involve
• Component and system configuration
• Adding new components to the system
• Selecting from a library of existing components
• Modifying components to meet new requirements.

54
Product line specialisation

• Platform specialisation
• Different versions of the application are
  developed for different platforms.
• Environment specialisation
• Different versions of the application are created
  to handle different operating environments e.g.
  different types of communication equipment.
• Functional specialisation
• Different versions of the application are created
  for customers with different requirements.
• Process specialisation
• Different versions of the application are created
  to support different business processes.

55
Product line configuration

• Deployment time configuration
• A generic system is configured by embedding
  knowledge of the customers requirements and
  business processes during installation. The
  software itself is not changed.
• Example Enterprise Resource Planning (ERP)
  systems
• Design time configuration
• A common generic code is adapted and changed
  according to the requirements of particular
  customers.
• Example Customizing a generic appication
  architecture

56
ERP system organisation
57
ERP systems

• An Enterprise Resource Planning (ERP) system is a
  generic system that supports common business
  processes such as ordering and invoicing,
  manufacturing, etc.
• These are very widely used in large companies -
  they represent probably the most common form of
  software reuse.
• The generic core is adapted by including modules
  and by incorporating knowledge of business
  processes and rules.

58
Design time configuration

• Software product lines that are configured at
  design time are instantiations of generic
  application architectures as discussed in Chapter
  13.
• Generic products usually emerge after experience
  with specific products.

59
Product line architectures

• Product line architectures specialise existing
  application architectures for a domain-specific
  type of application.
• Architectures must be structured in such a way to
  separate different sub-systems and to allow them
  to be modified.
• The architecture should also separate entities
  and their descriptions and the higher levels in
  the system access entities through descriptions
  rather than directly.

60
A resource management system
61
Vehicle despatching

• A specialised resource management system where
  the aim is to allocate resources (vehicles) to
  handle incidents.
• Adaptations include
• At the UI level, there are components for
  operator display and communications
• At the I/O management level, there are components
  that handle authentication, reporting and route
  planning
• At the resource management level, there are
  components for vehicle location and despatch,
  managing vehicle status and incident logging
• The database includes equipment, vehicle and map
  databases.

62
A despatching system
63
Product instance development
64
Product instance development

• Elicit stakeholder requirements
• Use existing family member as a prototype
• Choose closest-fit family member
• Find the family member that best meets the
  requirements
• Re-negotiate requirements
• Adapt requirements as necessary to capabilities
  of the software
• Adapt existing system
• Develop new modules and make changes for family
  member
• Deliver new family member
• Document key features for further member
  development

65
Topics covered

• The reuse landscape
• Design patterns
• Generator based reuse
• Application frameworks
• Application system reuse
• Component-based software engineering

66
Component-based software engineering
67
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

68
Component-based software engineering (CBSE)

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

69
Component-based development

• Component-based software engineering (CBSE) is an
  approach to software development that relies on
  software reuse.
• Components are more abstract than object classes
  and can be considered to be stand-alone service
  providers.

70
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.

71
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.

72
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?

73
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
• Components are more abstract than object classes
  and can be considered to be stand-alone service
  providers.

74
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.

75
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.

76
Component characteristics 1
77
Component characteristics 2
78
Component interfaces

• Provides interface
• Defines the services that are provided by the
  component to other components.
• Requires interface
• Defines the services that specifies what services
  must be made available for the component to
  execute as specified.

79
Component interfaces
80
A data collector component
81
Components and objects

• Components are deployable entities.
• Components do not define types.
• Component implementations are opaque.
• Components are language-independent.
• Components are standardised.

82
Component models

• A component model is a definition of standards
  for component implementation, documentation and
  deployment.
• Usually associated with a middleware integration
  framework.
• Examples of component models
• EJB model (Enterprise Java Beans)
• COM model (.NET model)
• Corba Component Model
• The component model specifies how interfaces
  should be defined and the elements that should be
  included in an interface definition.

83
Elements of a component model
84
Middleware support

• Component models are the basis for middleware
  that provides support for executing components.
• Component model implementations provide
• Platform services that allow components written
  according to the model to communicate
• Horizontal services that are application-independe
  nt services used by different components.
• To use services provided by a model, components
  are deployed in a container. This is a set of
  interfaces used to access the service
  implementations.

85
Component model services
86
Component development for reuse

• Components developed for a specific application
  usually have to be generalised to make them
  reusable.
• A component is most likely to be reusable if it
  associated with a stable domain abstraction
  (business object).
• For example, in a hospital stable domain
  abstractions are associated with the fundamental
  purpose - nurses, patients, treatments, etc.

87
Component development for reuse

• Components for reuse may be specially constructed
  by generalising existing components.
• Component reusability
• Should reflect stable domain abstractions
• Should hide state representation
• Should be as independent as possible
• Should publish exceptions through the component
  interface.
• There is a trade-off between reusability and
  usability
• The more general the interface, the greater the
  reusability but it is then more complex and hence
  less usable.

88
Changes for reusability

• Remove application-specific methods.
• Change names to make them general.
• Add methods to broaden coverage.
• Make exception handling consistent.
• Add a configuration interface for component
  adaptation.
• Integrate required components to reduce
  dependencies.

89
Legacy system components

• Existing legacy systems that fulfill a useful
  business function can be re-packaged as
  components for reuse.
• This involves writing a wrapper component that
  implements provides and requires interfaces then
  accesses the legacy system.
• Although costly, this can be much less expensive
  than rewriting the legacy system.

90
Issues with reusable components

• The development cost of reusable components may
  be higher than the cost of specific equivalents.
  This extra reusability enhancement cost should be
  an organization rather than a project cost.
• Generic components may be less space-efficient
  and may have longer execution times than their
  specific equivalents.

91
Component-based software engineering (CBSE)

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

92
The CBSE process

• When reusing components, it is essential to make
  trade-offs between ideal requirements and the
  services actually provided by available
  components.
• This involves
• Developing outline requirements
• Searching for components then modifying
  requirements according to available
  functionality.
• Searching again to find if there are better
  components that meet the revised requirements.

93
The CBSE process
94
The component identification process
95
Component identification issues

• Trust. You need to be able to trust the supplier
  of a component. At best, an untrusted component
  may not operate as advertised at worst, it can
  breach your security.
• Requirements. Different groups of components will
  satisfy different requirements.
• Validation.
• The component specification may not be detailed
  enough to allow comprehensive tests to be
  developed.
• Components may have unwanted functionality. How
  can you test this will not interfere with your
  application?

96
Component-based software engineering (CBSE)

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

97
Component composition

• The process of assembling components to create a
  system.
• Composition involves integrating components with
  each other and with the component infrastructure.
• Normally you have to write glue code to
  integrate components.

98
Types of composition

• Sequential composition where the composed
  components are executed in sequence. This
  involves composing the provides interfaces of
  each component.
• Hierarchical composition where one component
  calls on the services of another. The provides
  interface of one component is composed with the
  requires interface of another.
• Additive composition where the interfaces of two
  components are put together to create a new
  component.

99
Types of composition
100
Interface incompatibility

• Parameter incompatibility where operations have
  the same name but are of different types.
• Operation incompatibility where the names of
  operations in the composed interfaces are
  different.
• Operation incompleteness where the provides
  interface of one component is a subset of the
  requires interface of another.

101
Incompatible components
102
Adaptor components

• Address the problem of component incompatibility
  by reconciling the interfaces of the components
  that are composed.
• Different types of adaptor are required depending
  on the type of composition.
• An addressFinder and a mapper component may be
  composed through an adaptor that strips the
  postal code from an address and passes this to
  the mapper component.

103
Composition through an adaptor

• The component postCodeStripper is the adaptor
  that facilitates the sequential composition of
  addressFinder and mapper components.

104
Adaptor for data collector
105
Composition trade-offs

• When composing components, you may find conflicts
  between functional and non-functional
  requirements, and conflicts between the need for
  rapid delivery and system evolution.
• You need to make decisions such as
• What composition of components is effective for
  delivering the functional requirements?
• What composition of components allows for future
  change?
• What will be the emergent properties of the
  composed system?

106
Data collection and report generation
107
Component-based software engineering (CBSE)

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

108
Interface semantics

• You have to rely on component documentation to
  decide if interfaces that are syntactically
  compatible are actually compatible.
• Consider an interface for a PhotoLibrary
  component

109
Photo library composition
110
Photo Library documentation
This method adds a photograph to the library and
associates the photograph identifier and
catalogue descriptor with the photograph.
what happens if the photograph identifier is
already associated with a photograph in the
library? is the photograph descriptor
associated with the catalogue entry as well as
the photograph i.e. if I delete the photograph,
do I also delete the catalogue information?
111
The Object Constraint Language

• The Object Constraint Language (OCL) has been
  designed to define constraints that are
  associated with UML models.
• Can be used to specify interfaces for objects or
  components.
• It is based around the notion of pre and post
  condition specification - similar to the approach
  used in Z (Chapter 10).

112
Formal description of photo library
113
Photo library conditions

• As specified, the OCL associated with the Photo
  Library component states that
• There must not be a photograph in the library
  with the same identifier as the photograph to be
  entered
• The library must exist - assume that creating a
  library adds a single item to it
• Each new entry increases the size of the library
  by 1
• If you retrieve using the same identifier then
  you get back the photo that you added
• If you look up the catalogue using that
  identifier, then you get back the catalogue entry
  that you made.

114
Interface contracts

• Contracts on a class enable caller and callee to
  share the same assumptions about the component.
• Contracts include three types of constraints
• Invariant
• A predicate that is always true for all instances
  of a component. Invariants are constraints
  associated with components rather than
  operations.
• Precondition
• Preconditions are predicates associated with a
  specific operation and must be true before the
  operation is invoked. Preconditions are used to
  specify constraints that a caller must meet
  before calling an operation.
• Postcondition
• Postconditions are predicates associated with a
  specific operation and must be true after an
  operation is invoked. Postconditions are used to
  specify constraints that the object must ensure
  after the invocation of the operation.

115
Expressing contracts with OCL

• OCL allows constraints to be formally specified
  on single model elements or groups of model
  elements
• OCL was created to specify interfaces for classes
  and objects (but can be used for components as
  well)
• A constraint is expressed as an OCL expression
  returning the value true or false.
• OCL expressions for Hashtable operation put()
• Invariant
• context Hashtable inv numElements gt 0
• Precondition
• context Hashtableput(key, entry) pre
  !containsKey(key)
• Post-condition
• context Hashtableput(key, entry) post
  containsKey(key) and get(key) entry

116
Real and integer operators
117
String operators
118
Boolean operators
119
Other special keywords

• self
• An instance of the context.
• result
• In postconditions, it refers to the return value
  of the context method.
• _at_pre
• A value before the execution of the operation.

120
Inter-object constraints
How do we specify constraints on more than one
class?
121
3 types of navigation
1. Local attribute
2. Directly related class
3. Indirectly related class



Tournament.start
Player

League.player

League.tournament.player
122
Association navigation in OCL

• Association navigation is realized using the
  opposite rolename.
• object.rolename the set of objects on the other
  side of the association
• If the rolename is missing, then the name of the
  class with lowercase first letter is used.
• If there are multiple types of associations
  between two classes, then rolenames are required.

From context of League self.tournaments refers to
the set of objects of class Tournament associated
with this league. From context of
Tournament self.player refers to the set of
objects of class Player associated with this
tournament
tournaments



123
Specifying the Model Constraints

• Local attribute navigation
• context Tournament inv
• end - start lt Calendar.WEEK
• Directly related class navigation
• context TournamentacceptPlayer(p) pre
• league.players-gtincludes(p)
• Indirectly related class navigation
• context LeaguegetActivePlayers post
• result tournaments.players-gtasSet

124
Collection hierarchy
Collection
Set
Bag
Sequence
minussymmetricDifferenceasSequenceasBag
firstlastat(int)appendprependasBagasSet
asSequenceasSet
125
OCL collections

• OCL supports operations on collections of
  components
• Sets
• Unique elements
• Sequences
• Sets with ordered elements
• Bags
• Unlike sets, bags can contain the same element

126
Operations on collections
127
OCL examples Room assignment

• Assuming you have this relationship between
  Attendee and Room
• Write OCL expressions from the context of Room
  for the following postconditions after adding an
  attendee to a room

128
OCL example

• The number of occupants in the Room is one more
  than what it was before the method was executed
• context RoomAddMember(attendee) post
• occupants?size occupants_at_pre?size 1

129
OCL example

• The maximum occupancy (an attribute of Room) has
  not been exceeded
• context RoomAddMember(attendee) post
• occupants?size lt getMaxOccupancy()
• Note that this can also be written as an
  invariant of class Room
• context Room inv
• occupants?size lt getMaxOccupancy()

130
OCL example

• The gender of all occupants (gender is an
  attribute of Attendee) are the same
• context RoomAddMember(attendee) post
• occupants?forall(o1,o2 Attendee
  o1.getGender() o2.getGender())

131
OCL example

• There is at least one adult over 25 years old
  (age is an attribute of Attendee) in the room
• context RoomAddMember(attendee) post
• occupants?exists(o Attendee o.getAge() gt 25)
• Note that this can also be written as an
  invariant
• context Room inv
• occupants ?size gt 0 implies
• occupants?exists(o Attendee o.getAge() gt
  25)

132
Key points

• Advantages of reuse are lower costs, faster
  software development and lower risks.
• Design patterns are high-level abstractions that
  document successful design solutions.
• Program generators are also concerned with
  software reuse - the reusable concepts are
  embedded in a generator system.
• Application frameworks are collections of
  concrete and abstract objects that are designed
  for reuse through specialisation.
• Software product lines are related applications
  developed around a common core of shared
  functionality.

133
Key points

• A component is a software unit whose
  functionality and dependencies are completely
  defined by its interfaces.
• A component model defines a set of standards that
  component providers and composers should follow.
• During the CBSE process, the processes of
  requirements engineering and system design are
  interleaved.
• Component composition is the process of wiring
  components together to create a system.
• Formal specification of interface semantics helps
  the component user anticipate the behavior of the
  component.