source: Sophya/trunk/DocHFI_L2/L2L3_DMC_spec.html@ 1166

Last change on this file since 1166 was 1142, checked in by ansari, 25 years ago

DocL2 style file and example, work on WBS - Reza 25/8/2000
File size: 6.0 KB
Line 
1<HTML>
2<HEAD>
3<TITLE>L2/L3 DMC Requirements</TITLE>
4</HEAD>
5<BODY>
6<CENTER>
7<H1>DMC Specifications</H1>
8<H2>L2/L3 Requirements</H2>
9<H3>R&eacute;za Ansari, &Eacute;ric Aubourg, Floor van Leeuwen</H3>
10<H3>July 10, 2000 (draft)</H3>
11<H3>PL-HFI-SPP-SP-DMC002</H3>
12</CENTER>
13<SPACER TYPE="VERTICAL" SIZE="20">
14
15<H2>Introduction</H2>
16
17The Data Management Component (<ACRONYM>DMC</ACRONYM>) is a set of
18interfaces handling data persistence for Planck <ACRONYM>DPC</ACRONYM>'s
19(in the <ACRONYM>IDIS</ACRONYM> framework). It will be used by both
20consortia (<ACRONYM>HFI</ACRONYM> and <ACRONYM>LFI</ACRONYM>).
21
22<P>
23Since the <ACRONYM>DMC</ACRONYM> is a set of interfaces, different
24persistence mechanisms can be implemented in a transparent way. This
25insures some independance from the market (especially from the currently
26highly volatile market of object databases, O2 being virtually dead, Object
27Design appearing as the new leader as of June 2000).
28
29<P>
30Even if the two consortia choose the same implementation, which is not
31required, care must be taken to preserve this independence as the
32<ACRONYM>DMC</ACRONYM> interface is evolved.
33
34
35<H2>Object persistence mechanisms</H2>
36The <ACRONYM>DMC</ACRONYM> should provide object persistence, i.e. the
37fact that the internal state of an object is preserved after the end of
38the life of the application that created or modified it. The
39<ACRONYM>DPC</ACRONYM>'s will use this object persistence facility to store
40data, like maps, <ACRONYM>TOI</ACRONYM>'s, calibration information,
41pointing information, etc.
42
43<P>
44Data persistence can be achieved in several ways. For L2/L3
45<ACRONYM>DPC</ACRONYM>'s, one should keep in mind that
46
47<UL>
48 <LI><ACRONYM>DPC</ACRONYM> software should be independant of the
49 <ACRONYM>DMC</ACRONYM> implementation. In particular, it should be able to
50 run, for testing and development purposes, without any
51 <ACRONYM>DMC</ACRONYM> implementation (or a basic flat file
52 implementation).
53 <LI>Most objects handled during <ACRONYM>DPC</ACRONYM> processing will
54 be transient. Only input data and final products of a task will be
55 tagged persistent. Too tight a coupling between classes handled by
56 <ACRONYM>DPC</ACRONYM> software and <ACRONYM>DMC</ACRONYM> should be
57 avoided.
58</UL>
59One way to achieve this is by using the Bridge design pattern [Gamma 1995], to
60decouple interface and implementation inside the <ACRONYM>DMC</ACRONYM>.
61The <ACRONYM>DMC</ACRONYM> should probably be kept as a separate package providing
62persistence services, the science objects and classes having no explicit
63dependency to the <ACRONYM>DMC</ACRONYM>.
64
65<P>
66The <ACRONYM>DMC</ACRONYM> interface should moreover make minimal
67assumptions on the implementation layer functionalities.
68
69<H2>Data structure details, and opaque persistence</H2>
70
71<ACRONYM>DPC</ACRONYM> software will need to store complex objects, which
72structure can evolve. The precise internal data structure does not need to
73be handled by the DMC (semantically, although the DMC needs of course to know
74how the structure is built in terms of basic data types).
75
76<P>
77This facilitates schema evolution, since this provides skill separation
78between precise data structure definition (a physicist task) and data
79persistence (a database specialist task).
80
81<P>
82This also keeps the <ACRONYM>DMCI</ACRONYM> simple: it is a low-level
83software layer, that should not depend on higher-level (and thus more
84volatile) concepts.
85
86<P>
87Persistent data should be associated with tags and flags on which
88<ACRONYM>DMC</ACRONYM> requests can be based. A history of each object
89should also be kept, with support for versioning. Finer-grained searches
90should be handled by higher-level software layers.
91
92<H2>Use cases</H2> The data model specifications document should be
93complemented by use cases. A list of the kind of requests on each
94type of data will help determine the
95information that need to be
96accessible by the <ACRONYM>DMC</ACRONYM>, i.e.
97which classes of the
98data model have to be known by the
99<ACRONYM>DMC</ACRONYM>, and which
100tags should be associated with them.
101
102<H2>Requirements summary</H2>
103
104The <ACRONYM>DMCI</ACRONYM> should implement the
105following requirements:
106
107<UL>
108 <LI>The <ACRONYM>DMCI</ACRONYM> should
109provide a set of interfaces to handle persistence on any kind of
110data.
111 <LI>Software that uses <ACRONYM>DMCI</ACRONYM> facilities
112should be able to run without those facilities.
113 <LI>Making data
114persistent should not imply a hard-coded dependency between the data
115definition (in C++ or Java) and the <ACRONYM>DMCI</ACRONYM>.
116
117Persistence should in particular not be obtained by heritage, but by
118mechanisms like bridges and delegation.
119<LI>The <ACRONYM>DMCI</ACRONYM> should make persistent all basic data types
120(integers, floating point numbers, strings, and n-dimensional arrays
121of such data), as well as aggregates of those basic types. It should
122provide an <ACRONYM>API</ACRONYM> to define new data types as
123aggregates of already defined types. It should provide an
124<ACRONYM>API</ACRONYM> to define searchable fields and tags
125associated to data. <LI>The <ACRONYM>DMCI</ACRONYM> should associate
126to any persistent data the following characteristics: name, creation
127date, modification date, creator. It should handle version history:
128several versions of an object can be stored and retrieved.
129<LI>The <ACRONYM>DMCI</ACRONYM> should provide an <ACRONYM>API</ACRONYM> to
130
131locate an object based on searcheable fields and tags, and on version;
132to retrieve and store an object; and to lock an object while it is
133being processed.
134</UL>
135
136The <ACRONYM>DMCI</ACRONYM> could provide
137more functionalities for
138fundamental data structures like
139<ACRONYM>TOI</ACRONYM>'s and maps. This
140remains to be defined,
141keeping in particular in mind that, for instance,
142unforeseen pixelisation schemes could be used and that this should neither
143break the <ACRONYM>DMC</ACRONYM> nor imply major developments in a low
144software layer.
145
146<H3>Revisions</H3>
147<UL>
148<LI>0.1 &Eacute;ric Aubourg, 07/07/2000
149<LI>0.2 &Eacute;ric Aubourg, 10/07/2000
150</UL>
151</BODY>
152</HTML>
Note: See TracBrowser for help on using the repository browser.