The success of an XML application depends
on how the actual XML documents are used.They must not only
carry information that is needed for communication, but they
also need to be flexible enough to accommodate future requirements.
This section looks into the various factors that are to be
taken into account when designing XML document structures.
We will be concentrating on three areas
of design process namely Information modeling which is about
understanding the structure and meaning of information carried
in documents. Secondly, Document design that describes translating
information model into a set of rules or a schema for creating
actual documents. In the end, Schema notations that are the
techniques for recording the document design so that it is
accessible to both processing software and human users.
The first rule in information modeling is
to focus "real world" and not the technology. Information
model is the description of information used in an organization,
independent of any IT systems.
There are two objectives in an information
modeling exercise to achieve absolute precise information
and to communicate effectively with users.
| Static and Dynamic Models
There are two main types of information
model namely static model and dynamic model.
Static models describe the permissible states
of the system. They describe the types of objects in the system,
their properties and their relationships. They also define
the agreed names for these objects.
Dynamic models describe what happens to
information. These models describe a set of information exchanges
such as data that is sent from one place to another for a particular purpose.
In general, static models are related to
the design of a database where information is stored for long
periods to serve a variety of purposes, while dynamic models
are related to the design of messages that have only transient
existence and a very specific purpose.
The systematic approach in defining a static
information model is naming, organizing, finding and defining things or objects.
The first step, a good way to start any
information modeling is by establishing the names of things
in the system. The "things" are generally referred
to as Entities, Objects or Data objects. We will call them
Object Types. It would be better to understand all these with
the help of this HOLIDAY example. The definition of the term
"holiday" needs to ensure that we can recognize
a holiday when we see one and that there is no room for disputes
about whether something is a holiday or not.
One could begin by preparing a list of things
related to the system.
The next stage is to produce definitions
of the object types.
As well as naming the object types at this
stage, it is also worth thinking about the individual instances
and how they will identify the instances.
Having listed and named the object types,
we will now have to organize them into a hierarchical scheme.
Often these hierarchical relationships will emerge while we
are writing the definitions of the object types.
The key phrase is the "is a" test, as we always
use "is a" for the relationship between an individual
instance and its type. Identifying subtypes is useful in the
document design stage. Here is the figure showing the type
of hierarchy that we would use for the holiday business. It
uses the UML notation, in which an arrow points from a sub-type to its super-type.
Having named the object types, the next
stage in static information modeling is to determine relationships
that exist among them.
The cardinality of a relationship describes
how many of each kind of object can take part in the relationship.
||The most common kind is
the one-to-many relationship such as one chapter may have many paragraphs.
can also occur such as one author may write several books
or many authors may write one book.
||One-to-one relationship is
less common; one example is the relationship between a person and a job.
In modeling information, a particularly
important kind of relationship is the Contains relationship.
This is always one-to-one or one-to-many. There is no hard
and fast rule as to exactly what the constitution of the Contains relationship in.
There are two forms of Contains relationship
namely aggregation, which is a loose assembly of objects to
allow a group of things to be treated as a whole and composition,
which is a much stronger relationship where the subtypes have
no independent existence of their own.
As object types and relationship form the
static information model, properties put the flesh on the
bones. Properties are simply the values associated with the
objects. A person has height, weight, nationality and an occupation.
The main thing that is to be known is the
datatype - whether there is a fixed range of values, is it
numeric, in what units is it measured, is it mandatory and
is there a default value.
Instead of defining a step-a-step approach
as in static modeling, we will just outline some of the techniques
available. The techniques are Process and workflow models,
Data flow models, Object models, Object life histories, Use
cases and Object interaction diagrams.
The objective is to understand what the
system is supposed to be doing. We only need to model the
parts of the system that are causing difficulty, not the whole thing.
Process and Workflow models focus on the
roles of people and organizations in getting work done; while
the information stores and processing stages play a secondary role0.
The data flow models focus more on the information
system rather than the business.
This model describes data stores where the
information is stored, processors that manipulate the data
and data flows that transfer data from one processor or data
store to another. This relies very much on the static information model.
Object models have dynamic as well as static
content. The dynamic or behavioral part of an object definition
describes what each object can do as a set of operators or
methods that define its actions.
Object life histories focus on the individual objects. They
describe what happens to each object through its lifetime.
Use cases analyze how specific user tasks
are accomplished. Use cases can be useful both in modeling
the business and in describing the internal behavior of the IT system.
Object interaction diagrams analyze the
exchange of messages between objects at a finer level of detail
than the data flow model. While the data flow model might
simply identify that the online bookings system sends transaction
information to the credit card clearer and gets authorization
in response, the interaction diagram will describe all the
messages that make up this conversation in fine detail.
Copyrights : Layout Galaxy All Rights Reserved
No part of this tutorial may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, electrostatic, magnetic tape, mechanical or otherwise, without prior permission in writing from Layout Galaxy.