Software Reuse

Document Sample
Software Reuse Powered By Docstoc
					     Software Reuse

       Course: # 605.703.
 The Johns-Hopkins University
 Montgomery County Campus
      Fall 2000 Session 4
Lecture # 3 - September 28, 2004
                Review to Date
You should have accomplished since last week:
   – Completed reading chapter 3 of the text.
   – Completed part 1 of the first assignment.
      • Defined your engineering domain.
      • Defined your engineering domain project, within that
      • Specified the requirements for your domain engineering
   – If part one is not complete, or you would like to do
     additional work on it, please email it to me no later
     than 5:00 pm Friday October 1st.
            Tonight’s Lecture
• IDE ?
• Chapter 3: Object Oriented Software
• Review Assignment, Part One
• Part Two (due next week)
   – Implement your domain engineering project.
   – Implement two applications which reuse artifacts from
     your domain engineering project.
• Sharing Reusable Artifacts
   – Simple Reuse Library Mechanisms
      Which IDE are you using?
• Send to me via email, no later than 5:00
  PM Wednesday, the following
  –   Your name:
  –   Your programming language:
  –   Your Integrated Development Environment.
  –   Send to
 CH3: Object Oriented Software
       Engineering - 1
• Software Engineering is a Series of Model
   – Requirements transformed into designs.
   – Designs transformed into code.
   – Source code transformed into executable software.
• Object Oriented Software Engineering employs
  object based models in each transformational
 CH3: Object Oriented Software
       Engineering - 2
• OOSE does not require, but works well
  with an incremental, iterative engineering
  life cycle.
• Each iteration goes through the entire
  cycle, but with greater emphasis on
  different life cycle stages, in different
 CH3: Object Oriented Software
       Engineering – 3
• Objects (may) contain both behavior
  (functionality) and data (state).
• A Class is an Object Type.
• Objects have relationships with other objects:
      •   Generalization
      •   Specification (being more tightly specified)
      •   Association (including communicates with)
      •   Dependency (among the definitions, not the implementations)
 CH3: Object Oriented Software
       Engineering - 4
• Use Case Model captures System
• Analysis Model shapes system
• Design Model (classes and objects) define
  what the implementation will be.
• The “code” is the implementation model.
    Assignment One Part One
• Define your Engineering Domain
• Define a project within that domain
• Specify the requirements of that project

• If you have not already doe so, email your
  assignment one part one no later than Noon
  tomorrow (the 29th).
What is an Engineering Domain
• A domain defined by the kind of programming or
  software engineering being performed.
• Can be a generic engineering domain (most
  developers can reuse it): e.g. GUI development,
  database access, TCP/IP communication,
  CORBA development.
• Can be a specialty engineering domain (minority
  of developers can reuse it): e.g. complex math
  functions, multi-dimensional matrix operations,
  3-D graphics rendering.
      Defining an Engineering
         Domain (review)
• Defines what a development groups area of
  interest is, not just one projects requirements.
  What reusable software that development group
  can produce.
• Determine what software features and
  functionality are and are not within the
  engineering domain.
• Used to scope the requirements for all domain
  engineering projects to be performed by a
  development group.
  Example Engineering Domain
• Name of Domain: Document Management
• Domain Definition: The management of existing
  documents, not the creation of or editing of
  documents, but the management of existing
  documents and multiple versions of those
  documents. The basic services supplied by this
  domain include the storage, retrieval, indexing,
  and search for managed documents.
• Application Areas Supported: Knowledge
  Management, Document Archives, Library
  Management, Reuse Libraries can all make use
  of software assets from this engineering domain.
 What is a Domain Engineering
        Project (review)
• A single development project, meeting the
  following criteria:
  – Falls within the development group’s domain.
  – Has as a consumer not software users, but
    other software developers.
  – Meets requirements that are in common
    among three or more future application
    development projects.
Life Cycle Process for a Domain
  Engineering Project (review)
• Requirements analysis is replaced be domain
  analysis, describe not what one application must
  do, but a subset of the implementation of many
• Design and Implementation are somewhat similar
  to application development.
• Testing is via harnesses or wrappers, and testing
  within multiple application that reuse the
  engineering domains products.
  Specifying the Requirements of a
 Domain Engineering Project (review)
• Specified as commonality (what all
  applications that use these components
  require) and variability (what changes from
  application to application when each uses
  these components.)
• Requirements are always expressed in the
  context of the end user, and in this case
  those end users are application developers.
       Example Requirements
       Specification (part one)
• The Document Management Engineering
  Domain Project will consist of three primary
  work products:
   – A high level design of the sub-system which controls
     documents in an application.
   – A collection of reusable software assets that
     implement different variations of portions of that
   – An application engineer’s “guidebook” explaining
     how to match application requirements and/or design
     features to DMEDP reusable software assets.
       Example Requirements
       Specification (part two)
• The Document Management Engineering
  Domain Project reusable software assets will
  consist of components which perform the
  following services
   – Gather the correct metadata to index and classify each
     document being managed.
   – Store the metadata in a searchable and/or browsable
     structure and format.
   – Retrieve lists of assets, based on metadata
    Assignment One Part Two
• Due next week (10-5-04):
  – Implement your domain engineering project
     • At least two variations on each of two implementation
       (compilable and/or runnable) software asset.
  – Implement two application which reuse artifacts from
    your engineering domain project.
     • Each project should use at least two implementation assets.
     • One implementation asset should be reused in both
     • Each application should also reuse at least one
       implementation asset which is not shared bu both
       Sharing Reusable Assets
• Simple Reuse Library Mechanisms
  –   Paper based catalogs.
  –   Spread Sheet based catalogs.
  –   Database based catalogs
  –   Purpose Build catalog applications.
   Paper Based Reuse Catalogs
• More useful than you might think! (and cheap,
  fast, easy to get started)
• List what is available according to how it can be
   – What requirements does each software asset fulfill,
   – A simple sub-system or system generic design, and
     what role each asset fulfills in that design.
• Problems
   – Keeping it up to date can become difficult.
   – Searching a large asset collection is inefficient.
   – Sharing can be difficult.
   Spread Sheet Based Catalogs
• All the benefits (except not as cheap, fast and
  easy) of a paper based catalog.
• Additional benefits
   – Very basic search functionality
   – Easier to share (mount on a common LAN based
   – Easier to keep updated.
   – Contextual description (fielded descriptions)
• Problems
   – Lack of change control. Multiple editors can confuse
     the asset organization.
   – Multi-user synchronicity problems.
       Database Based Catalogs
• About the same benefits as spread sheet based catalog
  (except the cheaper and easy parts are starting to slip
• Additional Benefits
   – Easier to build population, search and retrieval functionality into
     service focused GUI’s.
   – RDBMS products are more likely to handle multi-user, with
     multiple roles.
• Problems:
   – Additional functionality is limited to what the database product
   – Deployment across multiple locations, servers, etc. can be
     expensive because of licensing issues.
   – Greater expense (purchase and training) and vendor of database
     product locks you in.
          Purpose Built Catalog
• All the benefits of Database Based Catalogs (except the
  cheap, fast easy is about gone).
• Additional Benefits
   – Complete control of functionality and user interface.
   – Ability to integrate the Catalog with other software engineering
     tools and utilities.
   – Ability to support business process and engineering process rules
     with the Catalog’s user interface and functionality.
• Problems
   – Cost of development and maintenance of the functionality of the
     catalog has now increased dramatically.
• Complete reading of text through chapter
  4: Application and Component Systems
• Complete work on Exercise 1 part two, due
  next week.
• Questions ?
• See you next week.

Shared By: