1 / 23

CS 501: Software Engineering Fall 1999

Explore the detailed process of creating a repository system for the Library of Congress, analyzing the requirements, and discussing the challenges faced during the implementation phase.

terryr
Télécharger la présentation

CS 501: Software Engineering Fall 1999

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 501: Software EngineeringFall 1999 Lecture 3 Requirements Definition

  2. Administration Web site: Additional project descriptions, recitation sessions. Project team formation: Newsgroup, Monday recitation session. Project: What is a client? Tools for managing large programs.

  3. Requirements Definition and Analysis Requirements Definition System and Software design Implementation and Unit Testing Integration and System Testing Operation and Maintenance

  4. Example: Library of Congress(A Partial Failure) Outline Description The Library of Congress requires a repository system to store and make accessible very large amounts of highly varied material over long periods of time.

  5. Chronology 1993-94 CNRI carries out research on architectures for digital libraries 1995-97 CNRI implements prototype repository for Library of Congress 1998 CNRI and Library of Congress carry out requirements definition

  6. The Repository Repository Users Search System Handle System

  7. The Repository Network Based Storage and Access to Digital Objects • All information stored as typed data in digital objects. • A single digital object has both data and meta-data. • Identification of digital objects is by location independent, persistent URNs. • Accessmanagement built into methods for accessing digital objects.

  8. Repository Access Protocol (RAP) RAP: A simple protocol with two main groups of commands: • Deposit digital object • Verify digital object • Delete digital object • Edit digital object • Access digital object • Access metadata A CORBA-based repository • RAP is a set of classes defined by a CORBA IDL • Protocol is Internet Inter-Object Protocol (IIOP)

  9. Access Management Digital material Attributes User Policies Operations Roles

  10. Structural Metadata for Complex Objects Data Several representations: thumbnail image reference image archival image Metadata Each representation may have its own metadata

  11. object-md Structural Type: pix1 Identifier loc.ndlp/amrlp.1234567 Data thumbnail gif reference jpg archive jpg pix1 Metadata

  12. Repository: Research Achievements 1. CORBA implementation of repository access protocol. 2. Integration of persistent naming through handle system. 3. Use of structural metadata to describe complex objects, elementary typology. 4. Access management framework and implementation. 5. Applet-based middleware for user interfaces. 6. Information visualization program to view the structure of large collections.

  13. Good Discoveries During Prototype  Structuring complex information in digital libraries  Data driven digital library interfaces  Comparison of object-oriented, relational, and file based storage systems  Naming and identification of library objects  Boundaries of required repository system

  14. Bad Discoveries During Prototype  Resistance to change within Library of Congress  Technical weakness of Library of Congress  Gaps in CNRI architecture

  15. Mistakes  Confusion of objectives (research and implementation)  Failure to involve all stakeholders  Over ambitious (no proper feasibility study)

  16. Feasibility Study Requirements Analysis Requirements Specification Requirements Definition The Requirements Process Feasibility Report System Models Definition of Requirements Specification of Requirements Requirements Document

  17. Requirements Definition High-level abstract description of requirements:  Specifies external system behavior  Comprehensible by customer, management and users Should reflect accurately what the customer wants:  Services that the system will provide  Constraints under which it will operate

  18. Library of Congress Requirements Study Team (all experienced): Librarian, Software Engineer (CNRI), Computing Project Leader (Library of Congress), + 2 others Advisors: Mailing list of about 20 knowledgeable stakeholders. Timetable: Preliminary report (2 months). Final report (1 month).

  19. Functional Requirements  Support for complex digital objects  Access management  Identification  Information hiding  Open protocols and formats

  20. DRAFT OVERVIEW OF ITS SUPPORT FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY NDLP collections already released Coolidge collection (for repository test) NDLP collections in conversion Future NDLP collections Other applications and materials NDLP Workflow Tracking Support Current Storage Structure (in Unix files, by aggregate) Object Administration System ILS Repository Index Generation (including pre-processing) American Memory User Interface (retrieval, navigation, & display) AM user interface plus access management for objects/collections Other User Interfaces (e.g. RLG, OCLC, DLF partners) ILS OPAC Interface Supporting infrastructure Handle assignment & registration Handle resolution Handle-server NOW FUTURE

  21. Non-functional Requirements Environment:  Estimates of sizes, numbers of users, etc.  Reliability and performance measures and targets Preferred:  Hardware and software systems (IBM/Unix)  Database systems (Oracle)  Programming languages (C and C++)

  22. Evolution of Requirements  If the requirements definition is wrong, the system will be a failure.  With complex systems, understanding of requirements always continues to improve. Therefore...  The requirements definition must evolve.  Its documentation must be kept current (but clearly identify versions).

  23. Reading Before next class, read and be ready to discuss: Sommerville: Chapters 4, 5, 6 and 7, pages 63 to 136.

More Related