SIGDOC Newsletter
March 2005
:: Volume 6, Number 1
Features
Modeling an information architecture
By Rob Pierce
robertp@us.ibm.com
Two of the six best practices of software development apply to the use
of visual modeling tools. The two best practices are:
- Use a component based architecture
- Model visually
These practices can help manage complexity for large projects of
many types, including information development projects. This article
provides
a description of how these practices can be applied to designing
and developing technical content just as software development projects
are
modeled.
Defining a component
A component can be described as a non-trivial, nearly independent,
and replaceable part of a system that fulfills a clear function in
the context
of a well-defined architecture. A component conforms to and provides
the physical realization of a set of interfaces.
A component can represent a physical, replaceable part of a system
that packages implementation, and conforms to and provides the realization
of a set of interfaces. A component represents a physical piece of
implementation
of a system, including software code (source, binary or executable)
or equivalents such as scripts or command files. Examples of technical
content
components might be a topic, a use case, a chapter.
Architecture is a part of design. Architecture is about making decisions
on how the system will be built. But it is not all of the design.
It stops at the major abstractions, the major elements; in other
words,
the elements that have some pervasive and long-lasting effect on
the qualities of the system, namely its ability to evolve and its
performance.
A software system’s architecture is perhaps the most important
aspect that can be used to control the iterative and incremental
development of a system throughout its lifecycle.
The most important property of an architecture is resilience - flexibility
in the face of change. To achieve this, architects must anticipate
evolution in both the problem domain and implementation technologies
to produce
a design that can gracefully accommodate such changes. Key techniques
are abstraction, encapsulation, and object-oriented analysis and
design. The result is that applications are fundamentally more maintainable
and
extensible. For the information architect, this might mean that the
information model is designed to accommodate new components being
added in the future
and how other changes to the system will be handled.
back to top Modeling as a best practice
Modeling is important because it helps the development team visualize,
specify, construct, and document the structure and behavior of a
system’s
architecture. UML - the unified modeling language -defines a modeling
terminology and methodology for designing and implementing an architectural
solution. By using a standard modeling language such as the UML,
different members of the development team can communicate their decisions
unambiguously
to one another.
Using visual modeling tools facilitates the management of these models,
letting you hide or expose details as necessary. Visual modeling
also helps you maintain consistency among a system’s artifacts - its
requirements, designs, and implementations. In short, visual modeling
helps improve a team’s ability to manage software complexity.
Visual modeling with the UML makes an application’s architecture
tangible, permitting a team to assess it in multiple dimensions.
How portable is it? Can it exploit expected advances in parallel
processing?
How might it be modified it to support a family of applications?
The UML enables you to evaluate these key characteristics during
early iterations
- at a point when design defects can be corrected before threatening
project success.
For software development projects, advances in forward and reverse
engineering techniques permit changes to an application’s model
to be automatically reflected in its source code, and changes to
its source code to be automatically
reflected in its model. This is critical when using an iterative
process, where such changes are to be expected with each iteration.
In building a visual model of a system, many different diagrams are
needed to represent different views of the system. The UML provides
a rich notation
for visualizing models. This includes the following types of diagrams:
- Use-Case diagrams to illustrate user interactions with the
system
- Class diagrams to illustrate logical structure
- Object diagrams to
illustrate objects and links
- State diagrams to illustrate behavior
- Component diagrams to illustrate
physical structure of the software
- Deployment diagrams to show the
mapping of software to hardware configurations
- Interaction diagrams
(i.e., collaboration and sequence diagrams) to illustrate behavior
- Activity diagrams to illustrate flows of events
back to top
Modeling can take place at different levels. For instance, business,
architecture, and design modeling are all valuable
but different aspects of developing a complete solution. For an information
architecture,
a business model might include the use cases of the deliverable,
which is likely the Help system. A business model would include
the primary use cases of how users would be using the system and the
flow or
order
of topics or tasks that a user might need to see. An architectural model might illustrate the topics as objects and include
their relationships in the overall hierarchy of topics and their locations.
A design model might be used to illustrate the collection of documentation
deliverables and all of the potential users or audience types. Each of
these model types would include components that comprise the entire model.
An example for an information model is the information in a Help system
for an Administrator role.
This information could be handled as a separate
component in an entire role-based Help system that you are modeling.
And each task for the Administrator role might be viewed as a sub-component
of the Administrator Help component. The level of granularity would
be determined by the design or development group doing the modeling.
One of the primary values of modeling is that software development is
extremely complex. Breaking a large project into independent sub-tasks
(as components), enables a group to work on pieces of the whole project
more independently without losing clarity on the overall scope of the
entire project. Modeling helps you to...
- visualize - it shows how system elements fit together
- specify -
it promotes unambiguous communication - UML: one language for all practitioners
- construct - it helps keep design and implementation consistent
- document - it illustrates the structure and behavior of a system’s
architecture
back to top Developing information as components
The practices of visual modeling and using a component-based architecture
fit well with developing an object oriented design for an application.
They also fit well with designing and implementing an information architecture.
An information architecture can be viewed as the hierarchy and flow
of topic-based documentation or technical content that comprises both
the
deliverables and the components that comprise different deliverables.
You can use a modeling tool to model topics as objects that have relationships
or associations with other topics. And just as in object oriented software
applications, there are different types of relationships. The concepts
of Parent, Child, and Peer relationships in an object oriented software
application can also apply to an information architecture of help topics.
As an information developer or architect, you can use a modeling tool
to design an information architecture that might apply to role-based
Help systems across an organization. Or, you might design topic-based
help for an existing product. In either example, you can use the modeling
tool to illustrate the use cases as use case diagrams that illustrate
the types of uses and the activities or tasks they will be performing.
There are different paths to follow as a user of an application and
thus different pieces of information the user might need to know. These
paths could be modeled as the flow from one topic to another of information
in your Help system. In elaborating these paths, you might start to determine
relationships between topics. Some topics may have dependencies on other
topics. Some topics might be similar but different options, and some
topics might trigger a return to some earlier perspective. These are
all different types of relationships and a modeling tool can be extremely
useful in managing complexity by illustrating the information hierarchy,
that is, the architecture of the topics.
Just as in object oriented software, the information model can be viewed
as a collection of objects. Topics can be viewed as classes. A chapter
or a use case could be viewed as a component. Books and Help systems
can be viewed as collections of components. And both classes and components
can have relationships to other classes and components.
Conclusion In summary, there are many benefits to modeling a solution and using
a component-based architecture and applying these practices for information
development. Components are independent, replaceable, and modular;
they can plug into existing frameworks and be used in different contexts
enabling
single-sourcing and reuse.
By designing and implementing independent components, a greater emphasis
is placed on architectural design for early validation. Developing
a system as a collection of components, can isolate potential issues
by
encapsulating system dependencies, and improves the development process
by helping manage complexity.
back to top |
