Software Reuse - PowerPoint PPT Presentation

1 / 121
About This Presentation
Title:

Software Reuse

Description:

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 ... – PowerPoint PPT presentation

Number of Views:294
Avg rating:3.0/5.0
Slides: 122
Provided by: csUnomah
Category:

less

Transcript and Presenter's Notes

Title: 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.
Write a Comment
User Comments (0)
About PowerShow.com