1. Software Reuse Course: # 605.703. The Johns-Hopkins University Montgomery County Campus Fall 2000 Lecture # 2 - September 14, 2004

2. Review You should have accomplished since last week: –Completed reading the preface, chapter 1 and chapter 2 of the text. –Completed setting up an IDE to be used for class exercise, and be ready to let me know what IDE that is.

3. Tonight’s Lecture Opportunistic Reuse and Reuse of Source Code. –Opportunistic Reuse (ad hoc) –Source Code (Implementation) Reuse (managed) –Defining an Engineering Domain. –Specifying a Domain Engineering Project. –Implementing a Domain Engineering Project.

4. Opportunistic Reuse Using what you can find. Looking for reusable software assets at the time you need to employ them. Not supported by a process. Not rewarded. Not scheduled. Of limited financial benefit.

5. Opportunistic Reuse Benefits Whatever you reuse, you don’t have to create. When maintainers of one system that uses the reusable asset fix a bug or add an enhancement: there is the opportunity to other systems to benefit from it. The number of end users of the reused asset increases, increasing the potential testing and maintenance resources for all systems using that asset.

6. Opportunistic Reuse Problems Can not plan for reuse. No plan for notifying reuser’s of asset bug fixes and improvements. Reusers are not rewarded, therefore they have no incentive to reuse. Late decision making: Requirements and designs can not choose to pick the design features that can be implemented with reuseable components.

7. Managed Source Code Reuse Manage the use of, and maintenance of source code assets. Allow developers to look for software assets based on what LLD (low level design) features they implement. Manage the (one or more of): configuration changes to the asset, notification of users that there is a change, usage of assets, training in usage, reward of reusers.

8. Application Domains Application Domain – The domain of all software applications that serve a set of similar users performing similar tasks, described by the common end user functionality, or common requirements that might be satisfied in that domain. (e.g. word processors, web browsers, and spread sheets are each application domains)

9. Engineering Domains Engineering Domain – The domain of all software components that can be reused to create multiple software applications, described by the common engineering functionality, or common design features that might be applied to that domain. (e.g. Graphical User Interface components, TCP/IP protocol components, math libraries and matrix operations are each engineering domains)

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

11. Defining an Engineering Domain 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.

12. What is a Domain Engineering Project 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.

13. Life Cycle Process for a Domain Engineering Project Requirements analysis is replaced be domain analysis, describe not what one application must do, but a subset of the implementation of many applications. 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.

14. Specifying the Requirements of a Domain Engineering Project 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.

15. Implementing a Domain Engineering Project Develop domain scope (requirements and integration contracts, APUI’s) Design reusable module(s) including their commonality, and variability. Users documentation describes how to match variability to specific current needs. Define/Implement test harnesses and identify candidate reuser applications Implement reusable components. Test against harnesses and candidate reuser apps.

16. Assignment 1 Week 1: –Define your engineering domain. –Define your domain engineering project in that domain. –Specify the requirements for your domain engineering project. Week 2 (or earlier): –Implement your domain engineering project –Implement two application which reuse artifacts from your engineering domain project.

17. Reading Assignments Complete reading of text through chapter 3: Object Oriented Software Engineering. Start working on Exercise 1, due in two weeks Questions ? See you next week.