Software Reuse

1. Software Reuse Course: # 605.703. The Johns-Hopkins UniversityMontgomery County CampusFall 2004 Session 5 Lecture # 4 – October 5, 2004

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

3. Tonight’s Lecture • Chapter 4: Application and Component Systems • Discuss Assignment, Part One • Part Two (is due) • Sharing Reusable Artifacts • Simple Reuse Library Mechanisms

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

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

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

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

8. Commonality and Variability • Variation Points • Variability mechanisms • Inheritance • Extensions • Parameterization • Generative: • Templates • Macros

9. 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?

10. Discussion: Assignment 1, Part 1 • Did you bring in the hard copies?

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

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

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

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

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

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

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

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

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

20. 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?

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

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

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

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

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

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