Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Software Reuse - PowerPoint by b1hRTASP

VIEWS: 94 PAGES: 67

									                            Software Reuse




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 1
                                        Objectives
           To explain the benefits of software reuse and
            some reuse problems
           To give an overview of the software reuse
            landscape
           To introduce component-based software
            engineering




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 2
                              Topics covered
           The reuse landscape
           Design patterns
           Generator based reuse
           Application frameworks
           Application system reuse
           Component-based software engineering




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 3
                               Software reuse

           In most engineering disciplines, systems are
            designed by composing existing reusable
            components.
           Software engineering has been more
            focused on custom development.
           To achieve better software, more quickly and
            at lower cost, we need to adopt a design
            process that is based on systematic software
            reuse.

Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 4
                            Reuse benefits 1


Increased dependability        Reused software, that has been tried and tested in working
                               systems, should be more dependable than new software. The
                               initial use of the software reveals any design and implementation
                               faults. These are then fixed, thus reducing the number of failures
                               when the software is reused.
Reduced process risk           If software exists, there is less uncertainty in the costs of reusing
                               that software than in the costs of development. This is an
                               important factor for project management as it reduces the margin
                               of error in project cost estimation. This is particularly true when
                               relatively large software components such as sub-systems are
                               reused.
Effective use of               Instead of application specialists doing the same work on
specialists                    different projects, these specialists can develop reusable
                               software that encapsulate their knowledge.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19     Slide 5
                            Reuse benefits 2

Standards compliance             Some standards, such as user interface standards, can be
                                 implemented as a set of standard reusable components. For
                                 example, if menus in a user interfaces are implemented using
                                 reusable components, all applications present the same
                                 menu formats to users. The use of standard user interfaces
                                 improves dependability as users are less likely to make
                                 mistakes when presented with a familiar interface.
Accelerated                      Bringing a system to market as early as possible is often
development                      more important than overall development costs. Reusing
                                 software can speed up system production because both
                                 development and validation time should be reduced.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 6
         Barriers to widespread reuse

Increased                    If the source code of a reused software system or component is
maintenance costs            not available then maintenance costs may be increased as the
                             reused elements of the system may become increasingly
                             incompatible with system changes.
Lack of tool support         CASE toolsets may not support development with reuse. It may
                             be difficult or impossible to integrate these tools with a
                             component library system. The software process assumed by
                             these tools may not take reuse into account.
Not-invented-here            Some software engineers sometimes prefer to re-write
(NIH) syndrome               components as they believe that they can improve on the
                             reusable component. This is partly to do with trust and partly to
                             do with the fact that writing original software is seen as more
                             challenging than reusing software from other people.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 7
          Barriers to widespread reuse


Creating and maintaining a         Populating a reusable component library and ensuring the software
component library                  developers can use this library can be expensive. Our current
                                   techniques for classifying, cataloguing and retrieving software
                                   components are immature.
Finding, understanding and         Software components have to be discovered in a library,
adapting reusable                  understood and, sometimes, adapted to work in a new environment.
components                         Engineers must be reasonably confident of finding a component in
                                   the library before they will make routinely include a component
                                   search as part of their normal development process.




 Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 8
                       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.

Photos from: Wikipedia and http://www3.imperial.ac.uk/spat/research/space_missions/cluster/history

    Modified from Sommerville’s originals    Software Engineering, 7th edition. Chapters 18 & 19     Slide 9
                   Ariane launcher failure

           The problem was due to a reused component from
            Ariane 4.
              •      Component failed because assumptions made for Ariane
                     4 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.


Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 10
                     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.

Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 11
                     The reuse landscape

                                                  Design
                                                 patterns


                             Co mp onent             Ap plication
                             framework s            pro duct lines                As pect-oriented
                                                                             s oftw are d ev elop men t
   Co mp onent-based                                             COTS                           Prog ram
      developmen t                                            integ ration                     generators
                              Legacy sy stem
                                wrap ping
                                                      Co nfigurable v er tical
                                                           applicatio ns
                 Service-o riented
                     s ys tems
                                                 Prog ram
                                                 lib raries




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19               Slide 12
                      Reuse approaches 1

    Design patterns              Generic abstractions that occur across applications are
                                 represented as design patterns that show abstract and
                                 concrete objects and interactions.
    Component-based              Systems are developed by integrating components
    development                  (collections of objects) that conform to component-
                                 model standards. This is covered in Chapter 19.
    Application                  Collections of abstract and concrete classes that can be
    frameworks                   adapted and extended to create application systems.
    Legacy system                Legacy systems (see Chapter 2) that can be wrapped
    wrapping                     by defining a set of interfaces and providing access to
                                 these legacy systems through these interfaces.
    Service-oriented             Systems are developed by linking shared services that
    systems                      may be externally provided.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 13
                      Reuse approaches 2

     Application product         An application type is generalised around a common
     lines                       architecture so that it can be adapted in different ways
                                 for different customers.
     COTS integration            Systems are developed by integrating existing
                                 application systems. (Special case of CBSE.)
     Configurable vertical       A generic system is designed so that it can be
     applications                configured to the needs of specific system customers.
     Program libraries           Class and function libraries implementing commonly-
                                 used abstractions are available for reuse.
     Program generators          A generator system embeds knowledge of a particular
                                 types of application and can generate systems or
                                 system fragments in that domain.
     Aspect-oriented             Shared components are woven into an application at
     software                    different places when the program is compiled.
     development




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 14
                              Topics covered
           The reuse landscape
           Design patterns
           Generator based reuse
           Application frameworks
           Application system reuse
           Component-based software engineering




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 16
                               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.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 17
                              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.


Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 18
                            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.


Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 19
                            Multiple displays




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 20
                     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.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 21
                     The Observer pattern




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 22
                             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




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 23
                              Topics covered
           The reuse landscape
           Design patterns
           Generator based reuse
           Application frameworks
           Application system reuse
           Component-based software engineering




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 34
                  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.


Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 35
  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.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 36
Reuse through program generation


         Application
                                                     a
                                        Program gener tor                        a      o
                                                                             Gener ted pr g ram
         description




                                        Application domain
                                                                                    Database
                                           knowledge




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19    Slide 37
         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.
              •      Crosscutting concerns – functionality that cuts across
                     multiple components, e.g., logging, security checking, etc.
              •      Cross-cutting concerns are implemented as reusable
                     aspects.
              •      The new system is generated by an aspect weaver.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 38
        Aspect-oriented development




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 39
                              Topics covered
           The reuse landscape
           Design patterns
           Generator based reuse
           Application frameworks
           Application system reuse
           Component-based software engineering




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 40
                  Application frameworks

           Frameworks are (incomplete) sub-system
            designs made up of a collection of abstract
            and concrete classes and the interfaces
            between them.
           Frameworks are moderately large entities
            that can be reused.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 41
               Examples of frameworks
           System infrastructure frameworks
              •      Support the development of system infrastructures such
                     as communications, user interfaces and compilers.
              •      Most generic.
              •      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.
              •      Most domain-specific.



Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 42
                   Extending frameworks

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

Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 43
                              Topics covered
           The reuse landscape
           Design patterns
           Generator based reuse
           Application frameworks
           Application system reuse
           Component-based software engineering




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 46
               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.


Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 47
                              Topics covered
           The reuse landscape
           Design patterns
           Generator based reuse
           Application frameworks
           Application system reuse
           Component-based software engineering




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 65
          Component-based software
             engineering (CBSE)
           Components and component models
           The CBSE process
           Component composition
           Interface specification




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 68
                            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.


Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 70
          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.



Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 71
                             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?


Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 72
                                  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.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 73
                    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.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 78
                    Component interfaces


              Requires interface                                     Provides interface
Defines the services                                                          Defines the services
from the component’s                       Component                          that are provided
environment that it                                                           by the component
uses                                                                          to other components




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 79
           A data collector component


                 Requires int erf ace                                        Provides int erf ace

                                                                                        addSen so r
                                                                                        removeSens or
      s en sorManagement
                                                                                        s tartSens or
                                                 Data co llector                        s to pSens or
                 s en sorData                                                           tes tSen so r
                                                                                        initialise
                                                                                        rep or t
                                                                                        lis tAll




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19        Slide 80
 Issues with reusable components
           Higher cost of developing reusable
            components.
              •      This extra cost should be an organization rather
                     than a project cost.
           Performance issues.
              •      Generic components may be less
                     space-efficient and may have longer execution
                     times than their specific equivalents.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 90
          Component-based software
             engineering (CBSE)
           Components and component models
           The CBSE process
           Component composition
           Interface specification




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 91
                        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.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 92
                        The CBSE process




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 93
 The component identification process




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 94
    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?




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 95
          Component-based software
             engineering (CBSE)
           Components and component models
           The CBSE process
           Component composition
           Interface specification




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 96
                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.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 97
                     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.



Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 98
                     Types of composition


             A                             A



                                                                         A                    B



            B                              B


            (a)                             (b)                                   (c)



Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19       Slide 99
                 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.

Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 100
              Incompatible components


                                                                       s tring location (s tring p n)
  ph on eDatab as e (strin g co mmand )
                                                                       s tring o wner (strin g pn )
                                               address Find er
                                                                                          yp
                                                                       s tring p ro pertyT e (strin g pn )



                                                                     dis play Map (s tring p os tCod e, scale)
            mapDB (s tring command)

                                                   mapp er           printMap (s tring p os tCod e, scale)




Modified from Sommerville’s originals     Software Engineering, 7th edition. Chapters 18 & 19           Slide 101
                      Adaptor components

           Address the problem of component
            incompatibility by reconciling the interfaces
            of the components that are composed.
           Different types of adaptors are required
            depending on the type of composition.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 102
   Composition through an adaptor

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

 address = addressFinder.location (phonenumber) ;
 postCode = postCodeStripper.getPostCode (address) ;
 mapper.displayMap(postCode, 10000) ;




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 103
                Adaptor for data collector



                              s en sorManagement                                          addSen so r
                s tart                                                                    removeSens or
                                                                                          s tartSens or
                s to p
    s en sor             Ad ap ter                        Data co llector                 s to pSens or
                                                                                          tes tSen so r
                                        s en sorData
               getdata                                                                    initialise
                                                                                          rep or t
                                                                                          lis tAll




Modified from Sommerville’s originals     Software Engineering, 7th edition. Chapters 18 & 19          Slide 104
          Component-based software
             engineering (CBSE)
           Components and component models
           The CBSE process
           Component composition
           Interface specification




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 107
                        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:

      public void addItem (Identifier pid ; Photograph p; CatalogEntry photodesc) ;
      public Photograph retrieve (Identifier pid) ;
      public CatalogEntry catEntry (Identifier pid) ;




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 108
              Photo library composition


                         addItem                                    getImag e
                                                                                     Image
                                               adaptor                              Manager
         Ph oto          retrieve
         Library
                         catEntry                     getCatalo gEn try

                                               Us er
                                             Inter face




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 109
         Photo Library documentation

           Informal specification:
              •      “This method adds a photograph to the library and
                     associates the photograph identifier and catalogue
                     descriptor with the photograph.”
           Questions:
              •      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?




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 110
   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).



Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 111
      Formal description of photo library

           -- The context keyword names the component to which the conditions apply
           context addItem

           -- The preconditions specify what must be true before execution of addItem
           pre:    PhotoLibrary.libSize() > 0
                   PhotoLibrary.retrieve(pid) = null

           -- The postconditions specify what is true after execution
           post: libSize () = libSize()@pre + 1
                   PhotoLibrary.retrieve(pid) = p
                   PhotoLibrary.catEntry(pid) = photodesc

           context delete

           pre: PhotoLibrary.retrieve(pid) <> null ;

           post: PhotoLibrary.retrieve(pid) = null
                  PhotoLibrary.catEntry(pid) = PhotoLibrary.catEntry(pid)@pre
                  PhotoLibrary.libSize() = libSize()@pre - 1



Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 112
                  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.



Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 113
                                        Key points
           Software reuse is more than just reusing code.
           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.
           CBSE components have well-defined and specified interfaces.
           CBSE involves identification and composition of components.




Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 132
                                        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.
Modified from Sommerville’s originals   Software Engineering, 7th edition. Chapters 18 & 19   Slide 133

								
To top