Using UML To Define XML Document Types W. Eliot Kimber John D. Heintz
Agenda <ul><li>Problem Definition </li></ul><ul><ul><li>What we are and are not building </li></ul></ul><ul><ul><li>Genera...
Transcend Syntax
Problem Definition How do we  integrate traditional system engineering modeling practice with traditional SGML and XML doc...
What Are We Building <ul><li>We build standards-based information management systems, primarily SGML and XML-based </li></...
Typical System Requirements <ul><li>Must support many document types: </li></ul><ul><ul><li>Reflect complex (and often arc...
What We Are Not Building <ul><li>Not using XML just for simple object marshalling </li></ul><ul><li>Not using XML just for...
System and Document Modeling <ul><li>Want to use UML-based data and object modeling to define our systems </li></ul><ul><l...
Mapping from DTDs to Object Models <ul><li>This approach is problematic: </li></ul><ul><ul><li>DTDs are not really data mo...
Practical Difficulties of DTD Development <ul><li>Tools for developing DTDs not integrated with other system design tools ...
We Had To Reject Traditional Approach <ul><li>We wanted to apply formal system modeling to XML-based systems </li></ul><ul...
Solution: Map Object Models to XML Document Types Where we realize that DTDs are just implementation refinements of higher...
Mapping Objects to Document Type Definitions <ul><li>DTD becomes implementation view of higher-level abstractions… </li></...
Refinement: Relating Layers of Abstraction <ul><li>A complete system model will have several layers of abstraction: </li><...
Refinement from High to Low Abstraction A B Abstract System Design System Implementation 1 A B D C Refinement A->A,C,D B->...
Problem: How To Bind Types to XML Syntax? <ul><li>UML data models define types </li></ul><ul><li>Must have formal, compute...
Solution: UML Stereotypes <ul><li>Stereotypes characterize UML syntactic components to add specialized semantics: </li></u...
Components of Our Solution <ul><li>We had to define the set of stereotypes needed to enable mapping to XML DTD syntax </li...
Document Analysis Produces Business Object Design <ul><li>Document analysis now results in document business object models...
Document Analysis (cont) <ul><li>Focus of document analysis stays on business requirements, not syntax details </li></ul><...
Simple Example A trivial but representative example of an abstract information model and an implementation refinement
Document Business Object Model
XML Implementation Model Top Level
<P> Element Type
Re-Use of Oasis Table Model
Full DTD View
Summary
Benefits for System Design and Implementation <ul><li>Offers traceability from abstract system modeling to XML implementat...
Benefits for XML Practitioner <ul><li>XML design completely integrated into larger system design </li></ul><ul><li>Can use...
Work to Be Done <ul><li>Implement DTD syntax output generators </li></ul><ul><li>Better understand how UML packages, Catal...
Contact Info <ul><li>W. Eliot Kimber [email_address] </li></ul><ul><li>John Heintz [email_address] </li></ul>
Upcoming SlideShare
Loading in …5
×

Using UML to define XML document types

647 views
587 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
647
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Using UML to define XML document types

  1. 1. Using UML To Define XML Document Types W. Eliot Kimber John D. Heintz
  2. 2. Agenda <ul><li>Problem Definition </li></ul><ul><ul><li>What we are and are not building </li></ul></ul><ul><ul><li>General system and document modeling </li></ul></ul><ul><ul><li>Modeling information structures (e.g, DTDs) </li></ul></ul><ul><ul><li>Difficult to Integrate DTDs with rest of system model </li></ul></ul><ul><li>Solution </li></ul><ul><ul><li>Catalysis-style refinement </li></ul></ul><ul><ul><li>DTD models as implementation refinement of abstract business objects </li></ul></ul><ul><ul><li>Types and Stereotypes </li></ul></ul><ul><li>Simple Example </li></ul><ul><li>Summary </li></ul><ul><li>Future Work </li></ul>
  3. 3. Transcend Syntax
  4. 4. Problem Definition How do we integrate traditional system engineering modeling practice with traditional SGML and XML document analysis and modeling?
  5. 5. What Are We Building <ul><li>We build standards-based information management systems, primarily SGML and XML-based </li></ul><ul><li>E.g., documentation authoring, production, and delivery </li></ul><ul><li>Often integrated with other core business processes: </li></ul><ul><ul><li>Product engineering </li></ul></ul><ul><ul><li>Marketing support </li></ul></ul><ul><ul><li>Legislation </li></ul></ul><ul><li>XML-based data is primary work product of system users </li></ul>
  6. 6. Typical System Requirements <ul><li>Must support many document types: </li></ul><ul><ul><li>Reflect complex (and often arcane) business rules </li></ul></ul><ul><ul><li>Reflect distinct cultures and practices of authors </li></ul></ul><ul><ul><li>Form families of related document types </li></ul></ul><ul><ul><li>May need to integrate with industry standards (ATA 2100, Docbook, etc.) </li></ul></ul><ul><li>Tens or hundreds of thousands of individual documents </li></ul><ul><li>Hyperlinking and use by reference </li></ul><ul><li>Must integrate with other information systems and business processes </li></ul><ul><li>Multiple outputs from a single source: print, HTML, etc. </li></ul><ul><li>Long life cycle documents (20-100+ years) </li></ul>
  7. 7. What We Are Not Building <ul><li>Not using XML just for simple object marshalling </li></ul><ul><li>Not using XML just for messaging among system components </li></ul>
  8. 8. System and Document Modeling <ul><li>Want to use UML-based data and object modeling to define our systems </li></ul><ul><li>Traditional document analysis does not use formal data modeling </li></ul><ul><li>Impedence mismatch similar to storing a program in a relational database </li></ul><ul><li>Two ways to solve: </li></ul><ul><ul><li>Define mapping mechanism from DTDs to object models </li></ul></ul><ul><ul><li>Define mapping mechanism from object models to DTDs </li></ul></ul>
  9. 9. Mapping from DTDs to Object Models <ul><li>This approach is problematic: </li></ul><ul><ul><li>DTDs are not really data models… </li></ul></ul><ul><ul><li>… only weak syntax constraints </li></ul></ul><ul><ul><li>DTDs provide no way to capture abstraction across models </li></ul></ul><ul><ul><li>DTDs are implementation views of some higher-level abstraction </li></ul></ul><ul><ul><li>May be many ways to interpret a given XML structure as objects </li></ul></ul><ul><ul><li>May need multiple related DTDs for the same business object </li></ul></ul><ul><ul><ul><li>Authoring vs. delivery, different languages or cultures, etc. </li></ul></ul></ul>
  10. 10. Practical Difficulties of DTD Development <ul><li>Tools for developing DTDs not integrated with other system design tools </li></ul><ul><li>No standard graphical representation </li></ul><ul><li>Difficult to engineer system objects and models from DTDs </li></ul><ul><li>Difficult to integrate DTD documentation with DTD definition </li></ul><ul><li>DTDs are not modular, making management of related DTDs difficult… </li></ul><ul><li>… DTDs are not inherently shareable. </li></ul>
  11. 11. We Had To Reject Traditional Approach <ul><li>We wanted to apply formal system modeling to XML-based systems </li></ul><ul><li>With focus on DTDs, XML document type components could be bound to implementation definition only through documentation strings </li></ul><ul><li>No automated tracability from requirements to XML rules: </li></ul><ul><ul><li>Difficult to define relationships among XML data and related code objects </li></ul></ul><ul><ul><li>Difficult to define relationships among different XML components (architectures provide some but not all) </li></ul></ul><ul><li>Difficult to capture re-usable XML parts of designs </li></ul><ul><li>DTD documentation became unmanagable </li></ul>
  12. 12. Solution: Map Object Models to XML Document Types Where we realize that DTDs are just implementation refinements of higher-level abstractions
  13. 13. Mapping Objects to Document Type Definitions <ul><li>DTD becomes implementation view of higher-level abstractions… </li></ul><ul><li>… Design focus is on business objects not data representation details </li></ul><ul><li>Traceability from system objects and formal requirements to DTD implementation </li></ul><ul><li>Can use facilities of modeling language not available in DTDs </li></ul><ul><li>Can bind documentation directly to model </li></ul><ul><li>Can use formal constraints to define semantic and syntactic constraints </li></ul>
  14. 14. Refinement: Relating Layers of Abstraction <ul><li>A complete system model will have several layers of abstraction: </li></ul><ul><ul><li>High-level system model </li></ul></ul><ul><ul><li>Functional requirements model </li></ul></ul><ul><ul><li>Implementation design model </li></ul></ul><ul><li>Objects in one level will be reflected in other levels, but not necessarily directly </li></ul><ul><li>Design tracability requires formal mapping from objects in one level to objects in the adjacent models </li></ul><ul><li>Any number of implementation models can refine a given functional model </li></ul>
  15. 15. Refinement from High to Low Abstraction A B Abstract System Design System Implementation 1 A B D C Refinement A->A,C,D B->B B E F System Implementation 2 Refinement A->E,F B->B
  16. 16. Problem: How To Bind Types to XML Syntax? <ul><li>UML data models define types </li></ul><ul><li>Must have formal, computer-sensible way to map UML types to XML DTD syntactic constructs: elements, attributes, content models, notations </li></ul><ul><li>A fixed mapping from UML graphical components to XML components won’t work: </li></ul><ul><ul><li>Some types will be element types </li></ul></ul><ul><ul><li>Some types will be attributes </li></ul></ul><ul><ul><li>Some types will be notations </li></ul></ul><ul><li>No direct analog of content models in UML language </li></ul>
  17. 17. Solution: UML Stereotypes <ul><li>Stereotypes characterize UML syntactic components to add specialized semantics: </li></ul><ul><li>UML does not define how a set of stereotypes is formally defined </li></ul><<element>> Book <<attribute>> Author
  18. 18. Components of Our Solution <ul><li>We had to define the set of stereotypes needed to enable mapping to XML DTD syntax </li></ul><ul><li>Had to define the semantics of those stereotypes: </li></ul><ul><ul><li>Defined the stereotypes as UML types in their own package </li></ul></ul><ul><ul><li>Formal constraints on these types plus prose documentation defines the semantics </li></ul></ul><ul><ul><li>The XML stereotypes in turn map back to the formal models for XML as defined by ISO and/or W3C </li></ul></ul><ul><li>The stereotypes reflect the abstract model for XML DTD declarations (element type, attribute, notation, etc.)… </li></ul><ul><li>… therefore, can map to any XML DTD representation syntax (markup declarations, XML Schema, etc.) </li></ul>
  19. 19. Document Analysis Produces Business Object Design <ul><li>Document analysis now results in document business object models </li></ul><ul><li>For us, document analysis is part of the larger system analysis task… </li></ul><ul><li>…documents are just another kind of business object… </li></ul><ul><li>…may or may not be represented in XML in implementation. </li></ul>
  20. 20. Document Analysis (cont) <ul><li>Focus of document analysis stays on business requirements, not syntax details </li></ul><ul><li>Document analysis results in abstract information model for business objects that are documents (in the everyday sense) </li></ul><ul><li>From this model, multiple implementations (“DTDs”) may be refined </li></ul><ul><li>XML syntax details defined as part of implementation task, not system analysis task </li></ul><ul><li>Can have multiple XML or non-XML implementations of same document business objects with full design traceability </li></ul>
  21. 21. Simple Example A trivial but representative example of an abstract information model and an implementation refinement
  22. 22. Document Business Object Model
  23. 23. XML Implementation Model Top Level
  24. 24. <P> Element Type
  25. 25. Re-Use of Oasis Table Model
  26. 26. Full DTD View
  27. 27. Summary
  28. 28. Benefits for System Design and Implementation <ul><li>Offers traceability from abstract system modeling to XML implementation </li></ul><ul><li>Offers rich set of features for managing DTD definitions: </li></ul><ul><ul><li>Provides modularity through UML packages </li></ul></ul><ul><ul><li>Provides all of UML’s typing to XML components </li></ul></ul><ul><ul><li>Provides formal syntactic and semantic constraints through UML object constraint language (or equivalent) </li></ul></ul><ul><li>Focus of document analysis is on business objects, not on implementation technology or representation syntax </li></ul><ul><li>Same business models can be refined into XML, CORBA IDL, Java objects, RDBMS tables, etc…. </li></ul>
  29. 29. Benefits for XML Practitioner <ul><li>XML design completely integrated into larger system design </li></ul><ul><li>Can use existing tools to develop and maintain DTD definition (e.g., Rose, ObjectDomain, etc.) </li></ul><ul><li>Provides design documentation in form easily understood by implementors </li></ul><ul><li>Get graphical representations of DTDs for free </li></ul><ul><li>Documentation can be bound directly to model </li></ul><ul><li>Elevates XML to first-class citizen in system design </li></ul><ul><li>No need to choose a particular DTD representation syntax (e.g., DTD declarations vs. XML Schema)… </li></ul><ul><li>… both are simply generated from UML model </li></ul>
  30. 30. Work to Be Done <ul><li>Implement DTD syntax output generators </li></ul><ul><li>Better understand how UML packages, Catalysis refinement, OO frameworks, and SGML architectures interact </li></ul><ul><li>Understand how to map these models to groves at different levels of abstraction (e.g., groves that reflect the business object model, not the XML syntax model) </li></ul><ul><li>Expand model to include hyperlink representation </li></ul><ul><li>Apply approach in practice </li></ul>
  31. 31. Contact Info <ul><li>W. Eliot Kimber [email_address] </li></ul><ul><li>John Heintz [email_address] </li></ul>

×