Software Reuse

Software Reuse

Course: # 605.703. The Johns-Hopkins UniversityMontgomery County Campus

Fall 2004 Session 5

Lecture # 4 – October 5, 2004

Review to Date

You should have accomplished since last week:– Completed reading chapter 4 of the text.– Completed part 2 of the first assignment.

• Four components. Two implementations of each of two different ‘types’ of reusable assets.

• Defined your engineering domain project, within that domain.

• Specified the requirements for your domain engineering project.

– If part two is not complete, or you would like to do additional work on it, please speak to me on the break or after class.

Tonight’s Lecture

• Chapter 4: Application and Component Systems

• Discuss Assignment, Part One

• Part Two (is due)

• Sharing Reusable Artifacts– Simple Reuse Library Mechanisms

Ch 4: Application and Component Systems

• Extend OOSE modeling language to directly support reuse.

• Reuse organizations engineer both applications and reusable components (assets)

• To support reuse, Use Cases will emphasize commonality and variability.

Applications versus Reuse Assets

• Applications are delivered outside the engineering organization.

• Reuse Assets are delivered to the engineering organization.

• Application Families– Allow significant reuse– Indicate reuse opportunities– Scope and define reuse projects.

Reuse Based Development Life Cycle

• Domain Analysis• Domain Engineering• Requirements Analysis (of an application)

– Reuse Potential analysis

• …• Analysis of new domain engineering

opportunities.More on this later in the lecture.

More Chapter 4

• Components and Component Systems • Facades encapsulate and abstract groups of

components, including:– Operating system services

– COTS components

– Facades and components systems are a different kind of package.

– Sometimes you reuse as is, sometimes specialization is required.

Commonality and Variability

• Variation Points

• Variability mechanisms– Inheritance– Extensions– Parameterization– Generative:

• Templates

• Macros

Packaging and Documentation

• How will an application developer use a reusable asset?

• How will an application developer know that a reusable asset is available?

• How will an application developer know whether the reusable asset will meet the project’s performance requirements?

• How will an application developer know how to integrate an asset into their application?

Discussion: Assignment 1, Part 1

• Did you bring in the hard copies?

What is an Engineering Domain (review)

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

Reuse Driven Process

• Component Based Software Assembly model’s process.

• Changing the Software Development Life Cycle to Support Reuse: Requirements, Design, Implementation, and Deployment– Domain Analysis– Domain Engineering– Requirements Analysis (of an application)

• Reuse Potential analysis

– …– Analysis of new domain engineering opportunities.

Domain Analysis

• Analyze a family of applications.– Analogous to requirements analysis.

• Commonality: The requirements, traits, features, constraints shared by all members of the families.

• Variability: What features, etc. are shared by some members of the family but not all, in fact not even most.

Domain Engineering

• Building the framework that engineers the commonality of the application domain, aka family of applications.

• Variation Points are engineered as well:– Parameters on components, framework or

generator.– Multiple implementations of common

interfaces or facades.

Requirements Analysis (of an application)

• Reuse Potential analysis – potential for engineering this application via reusable assets.

• Not just determining what the customer/user wants/needs.• Determine the scope of what the user needs, then within

that scope you can determine whether within that variability you have reusable assets to apply to the project.

• A little like psychotherapy for software engineering, especially Rogerian therapy. You help guide the user to determine what their real needs and desires are; and then move forward to help them realize them.

Implementation

• Unless we are applying opportunistic reuse…• The choice of where and what to reuse have

already been decided (for the most part)• During requirements,

– The user/customer was “guided” toward reusable assets, we just need to reuse them during implementation, etc.

– Requirements and/or design feature tracability point to the latter life cycle assets (e.g. code and test suites) are mapped to the reusable requirements/design features of the new project.

Analysis of new domain engineering opportunities.

• What “new” stuff was produced that might be used again in future projects.

• Is there something new the user/customer wanted that we have seen before?– Was it similar to an existing reusable asset, but not

simlar enough (maybe an existing asset needs additional variability)?

– Was it similar to another “Custom” requirement that has been seen before, but we did not yet recognize it as reusable?

Sharing Reusable Assets

(left over from last session)

• 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

reused.– What requirements does each software asset fulfill, or…– 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

folder)– 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 away.)

• 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

offers.– 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 Applications

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

Assignments

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