1. Software Reuse Course: # 605.703. The Johns-Hopkins University Montgomery County Campus Fall 2000 Session 4 Lecture # 3 - September 28, 2004

2. 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 domain. Specified the requirements for your domain engineering project. –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 1 st.

3. Tonight’s Lecture IDE ? Chapter 3: Object Oriented Software Engineering. 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

4. Which IDE are you using? Send to me via email, no later than 5:00 PM Wednesday, the following information: –Your name: –Your programming language: –Your Integrated Development Environment. –Send to prof@hisdomain.net

5. CH3: Object Oriented Software Engineering - 1 Software Engineering is a Series of Model Transformations –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 stage.

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

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

8. CH3: Object Oriented Software Engineering - 4 Use Case Model captures System Requirements Analysis Model shapes system architecture. Design Model (classes and objects) define what the implementation will be. The “code” is the implementation model.

9. 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 29 th ).

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

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

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

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

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

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

16. 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 design. –An application engineer’s “guidebook” explaining how to match application requirements and/or design features to DMEDP reusable software assets.

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

18. 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 applications. Each application should also reuse at least one implementation asset which is not shared bu both applications.

19. Sharing Reusable Assets Simple Reuse Library Mechanisms –Paper based catalogs. –Spread Sheet based catalogs. –Database based catalogs –Purpose Build catalog applications.

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

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

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

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

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