Designing Persistency Delos NoE, Preservation Cluster Workshop: Persistency in Digital Libraries 14. February 2006, Oxford Internet Institute.

Slides:



Advertisements
Similar presentations
MicroKernel Pattern Presented by Sahibzada Sami ud din Kashif Khurshid.
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Architecture Representation
System Modelling System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Different.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
T-FLEX DOCs PLM, Document and Workflow Management.
Object-Oriented Analysis and Design
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Formalizing the Design of Digital Libraries Based on UML Delos NoE, Preservation Cluster: Workshop: Persistency in Digital Libraries 13. February 2006,
Business Process Orchestration
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
Supplement 02CASE Tools1 Supplement 02 - Case Tools And Franchise Colleges By MANSHA NAWAZ.
Use Case Analysis – continued
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
CMPT 370: Information Systems Design Instructor: Curtis Cartmill, Simon Fraser University – Summer 2003 Lecture Topic: Layered Architecture Class Exercise:
Chapter 13: Process Specifications Service-Oriented Computing: Semantics, Processes, Agents – Munindar P. Singh and Michael N. Huhns, Wiley, 2005.
An Introduction to Rational Rose Real-Time
Department of Computer Science 1 CSS 496 Business Process Re-engineering for BS(CS)
Department of Computer Science 1 CSS 496 Business Process Re-engineering for BS(CS)
Process-oriented System Automation Executable Process Modeling & Process Automation.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
1 BTEC HNC Systems Support Castle College 2007/8 Systems Analysis Lecture 9 Introduction to Design.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
Lecture 9: Chapter 9 Architectural Design
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 09. Review Introduction to architectural styles Distributed architectures – Client Server Architecture – Multi-tier.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13.
Chapter 7 System models.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Systems Analysis and Design in a Changing World, 3rd Edition
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
CSC 480 Software Engineering Lecture 18 Nov 6, 2002.
Computing and SE II Chapter 9: Design Methods and Design Models Er-Yu Ding Software Institute, NJU.
SOFTWARE DESIGN. INTRODUCTION There are 3 distinct types of activities in design 1.External design 2.Architectural design 3.Detailed design Architectural.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Introduction to UML CS A470. What is UML? Unified Modeling Language –OMG Standard, Object Management Group –Based on work from Booch, Rumbaugh, Jacobson.
CSC480 Software Engineering Lecture 10 September 25, 2002.
SCAPE Rainer Schmidt SCAPE Training Event September 16 th – 17 th, 2013 The British Library Building Scalable Environments Technologies and SCAPE Platform.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
Dr. Rebhi S. Baraka Advanced Topics in Information Technology (SICT 4310) Department of Computer Science Faculty of Information Technology.
Slide 1 Service-centric Software Engineering. Slide 2 Objectives To explain the notion of a reusable service, based on web service standards, that provides.
OBJECT-ORIENTED TESTING. TESTING OOA AND OOD MODELS Analysis and design models cannot be tested in the conventional sense. However, formal technical reviews.
C. Mugnier, D. Lafarge, C. Perolini, R. Pilon, J. Ruiz-Cabezas
Topic 4: Distributed Objects Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine.
Introduction to DBMS Purpose of Database Systems View of Data
GRASP – Designing Objects with Responsibilities
7. Modular and structured design
Coupling and Cohesion Rajni Bhalla.
PLM, Document and Workflow Management
Abstract descriptions of systems whose requirements are being analysed
Service-centric Software Engineering
Software Architecture
Chapter 20 Object-Oriented Analysis and Design
Introduction to DBMS Purpose of Database Systems View of Data
Software Analysis.
Use Case Analysis – continued
Cohesion and Coupling.
Presentation transcript:

Designing Persistency Delos NoE, Preservation Cluster Workshop: Persistency in Digital Libraries 14. February 2006, Oxford Internet Institute

1 Digital Objects Digital objects are the core elements a digital library deals with. For long-term preservation they have to be kept persistent. Therefore we need DL systems that have the ability to keep digital objects persistent.

2 Digital Objects: Structure Digital objects are composed entities with a logical structure. Example:

3 Life-cycle of Entities Persistency appears in the life-cycle of any entity within a digital library.

4 Life-cycle of Entities The nature of instability of entities appears in the life-cycle of any entity within a digital library.

5 Requirements for the Design of a Persistent DL System The system should be able to react according to the transient and composite nature of digital library‘s entities. Entities in digital libraries can be of different nature. E.g., the system should also be able to keep the structure of a collection as well as of a digital object persistent.

6 Requirements for the Design of a Persistent DL System It also should be able to react as to the common failures which can occur in a complex system. It should cope with different preservation strategies. Implementation: The design should be expressed in way that makes implementation of the system and maintenance of it as easy as possible.

7 This includes for example: –We need a flexibel system that is able to deal with digital objects of any structure. –The overall processing of the changes to the digital object needs to be strictly controlled. –The individual processing steps need to be bundled in line with their functional similarity.

8 –All events that may have an impact on the longevity of digital objects need to be recorded. –Modifying access on digital objects (external or internal) need to be „announced“ to the preservation system. –The design of the system need to be expressed in a flexible, extensible, standardised and widely accepted language.

9 Prerequisites for this Approach We decided to use the UML for modelling persistent digital library systems. Therefore, the systems which adopt the Preservation Module, must be expressed in UML notation. The approach suggested here is focused on the implementation of the system, that is a digital library as a software system.

10 Preservation Module

11 Preservation Module

12 Preservation Module

13 Preservation Module

14 Preservation Module

15 Preservation Module

16 Registering Interface Core tasks: Receiving and forwarding messages that represent a potentially persistency-sensitive scenario.

17 Preservation Module

18 Persistency Agent Core tasks: Interface between the processing units of the Preservation Module and the DL system (‚Gate‘); Delegation of messages; Controlling the message flow to the surrounding system components. Additional tasks could be: Producing logfiles on activation of the Preservation Module, statistical issues

19 Processing Controller Heart of the core unit. Unit at the top level of control. Coordination of the particular over-all processing steps. Connected to the other functional units of the Preservation Module.

20 Persistency Memory Unit that encapsulates all preservation-sensitive parameters. Keeps and administrates a machine-readable list of preservation-sensitive parameters. Could be realised as a database.

21 Persistency Guard Unit that controls the execution of basic preservation actions (internal ones, ‚routines‘), like checking if a digital object is physically in good order. Initiation and controlling of modifications to the Persistency Memory.

22 Object Handler Interface between the core unit of the Preservation Module and the system unit that is responsible for the storage of the digital objects (repository). Controls all processing steps which are related to the repository.

23 Core Unit with exemplary functionality

24 MHU

25 Message Handling Unit Message Handler: – Pre-processing of the message: Obtaining its semantic content. –Deciding whether or not a message is preservation-sensitive. External Message Handler: Exact semantic interpretation of messages which are forwarded from external units. Internal Message Handler: Exact semantic interpretation of messages that are forwarded from the inside.

26 Message Handling Unit Message Handling Unit with exemplary functionality

27 PWPU

28 Persistency Workflow Processing Unit Unit of the Preservation Module that controls all actions which concern the modification of the object (workflow). A workflow is composed of a sequence of smaller workflow units that are encapsulated in the Persistency Workflow class.

29 Persistency Workflow Processing Unit The Persistency Workflow Handler initiates the workflow process. It also composes the over-all workflow that has to be carried out, according to the messages previously interpreted and forwarded to it. The Persistency Workflow Controller is responsible for the control of the particular workflow steps.

30 Persistency Workflow Processing Unit PWPU with exemplary functionality

31 Integration of the PM into Existing Systems The PM is conceived as a software module that has only two interfaces which have to be connected to the DL system. The first interface, linking the PM via PA to the DL system is called Message Gate, the second, linking the PM to a repository is called Object Gate.

32

33 Integration of the PM into Existing Systems Step 1: Specification of the interfaces

34 Depending on the analysis of the existing model, there are various possibilities :

35 Step 2: Adding the core unit

36 Step 3: Adding the Message Handling Unit

37 Step 4: Modelling the PWPU

38 Integration of the PM into the conceptual models: EF

39 Integration of the PM into the conceptual models: 5S