1 / 20

Change Management on Hybrid OMDoc Documents: A Case Study

Change Management on Hybrid OMDoc Documents: A Case Study. Sönke Holsten, Normen Müller. What is Change Management on Hybrid OMDoc Documents?. Change Management: Maintenance of relations Propagation of changes Hybrid OMDoc Documents:

bayard
Télécharger la présentation

Change Management on Hybrid OMDoc Documents: A Case Study

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. Change Management on Hybrid OMDoc Documents: A Case Study Sönke Holsten, Normen Müller

  2. What is Change Management on Hybrid OMDoc Documents? • Change Management: • Maintenance of relations • Propagation of changes • Hybrid OMDoc Documents: • self-contained structured compositions of information units hosted in various application domains with OMDoc as the top-level information unit

  3. Document-based Software Development • Markups constituting the software development process: • formal specifications: ZML, OMDoc • design diagram: XMI[UML] • source code: JavaML, CodeML

  4. Requirements Specification • The software should be able to manage phone numbers, i.e. represent a phonebook. Each entry in the phonebook should consist of a phone number and a name. It should be possible to: • add entries • delete entries • query for entries by name

  5. UML Diagram <UML:Model> <UML:Class name=“Phonebook”> <UML:Operation name=“addEntry”…/> <UML:Operation name=“delEntry” …/> <UML:Operation name=“searchEntry” …/> </UML:Class> <UML:Class name=“PhonebookEntry”> <UML:Attribute name=“number” …/> <UML:Attribute name=“name” …/> </UML:Class> <UML:Datatype name=“int”/> <UML:Datatype name=“string”/> <UML:Datatype name=“void”/> <UML:Association …/> </UML:Model>

  6. Source Code ... <ccdef export=“searchEntry"> <ccsym cd="cpp.dec" name="public-type-function"/> <apply> <ccsym cd="cpp.types“ name="funtype"/> <ccsym cd="cpp.types" name=“int"/> <ccsym cd="cpp.types" name="string"/> </apply> <bind> <ccsym cd="cpp.proc" name="function"/> <bvar> <ccv name="name"/> </bvar> ... </bind> </ccdef> ... /** * This is the class Phonebook, which * manages phonebook entries * consisting of a name and a number */ class Phonebook { Public: void addEntry(string name, int number); void delEntry(string name); int searchEntry(string name); /** * Phonebook class empty constructor. */ Phonebook(); /** * Phonebook class empty destructor. */ ~Phonebook(); ...

  7. Maintenance of relations Requirements Satisfied by • Explicit statingof relations • Deriving new relations UML Diagram Implemented by Verified by Source Code Tested by Test case

  8. Change Propagation • Software undergoes changes, e.g. new functionality is implemented: “It should be possible to query for entries by number” • Change step by step: • Programmer renames existing method searchEntry to searchEntryByName

  9. Requirements Specification • The software should be able to manage phone numbers, i.e. represent a phonebook. Each entry in the phonebook should consist of a phone number and a name. It should be possible to: • add entries • delete entries • query for entries by name

  10. UML Diagram <UML:Model> <UML:Class name=“Phonebook”> <UML:Operation name=“addEntry”…/> <UML:Operation name=“delEntry” …/> <UML:Operation name=“searchEntry” …/> </UML:Class> <UML:Class name=“PhonebookEntry”> <UML:Attribute name=“number” …/> <UML:Attribute name=“name” …/> </UML:Class> <UML:Datatype name=“int”/> <UML:Datatype name=“string”/> <UML:Datatype name=“void”/> <UML:Association …/> </UML:Model>

  11. Primitive Equivalence Relations <a> <b></b> <c><d/></c> </a> <a><b/><c><d/> </c></a> = a b c d XML

  12. Primitive Equivalence Relations (2) a a = b c c b d d XML Grammar

  13. Primitive Equivalence Relations (3) a a = b c b c d e XML Grammar DocModel

  14. Document Model • Equivalence Relations • Similarity Groups: • Groups elements that are considered equal under a certain equivalence relation • Dependencies: • What dependencies may exist • Rules to compute dependencies

  15. Classified Dependencies • 3-tuple <(a,b), R, eq>, where • a, b are information units • (a,b)  R • eq is a set of equivalence relations • CD’s react sensitive on eq

  16. Change Relation • 3-tuple <(a,b), R, eq>, where • a, b are information units • (a,b)  R • eq is a set of equivalence relations • CR’s preserve eq

  17. Outlook • Representation of: • differences (XUpdate/ XQuery Update Facility + RDF) • dependencies (RDF schema) • equivalence relations (?) • Extend Phonebook example step by step

  18. Questions I want to answer • Are primitive equivalence relations sufficient for change detection? • What information do we need to automatically propagate a change?

  19. Thank you for your attention!

  20. Any suggestions?

More Related