It is desired to build a suite of software tools to support the entry,
editing, and browsing of software documents.  Documents include source
code, textual documentation, diagrams (such as UML diagrams), and
graphs generated by program analysis tools (like call graphs).  All of
these kinds of documents may occur in multiple versions as a system
evolves.

All of the diagrams contain symbolic names (as examples, the names of
functions in the source code or call graph or the names of external
agents in the requirements documents or UML analysis model).  When the
user selects a name in one document, he/she should be able to easily
navigate to occurrences of that name in other documents.  For example,
clicking on a node of a call graph could take the user to the source
code for that node.  Users should also be able to search for one or
more names and have the matching results highlighted in the document
being queried.

Sometimes it is desirable to run a third-party program on a document,
producing another document.  The system should support the activation
of third-party tools and the inclusion of their results as accessible
documents.  For example, it might be desired to run a program on a
textual document to select frequently occurring words and phrases.

The tool suite should be able to deal with names in various ways.  For
example, a name may have synonyms, and a third-party tool may be
available to check whether two words are synonyms or to determine
candidate synonyms for a word.  The user should then be able to accept
or reject such matches.  Likewise, occurrences of words in a textual
document may correspond to a program identifier with a similar name,
such as "Flight Simulator" being related to "flghtSmltr".  Assuming the
existence of a third-party tool for checking such matches, the tool
suite should support linking among documents with these forms of name
manglings in both directions.  Finally, elements denoted by names may
be conceptually related to other elements or categories of elements.
For example, data types "car" and "truck" may both be in the category
"vehicle".  Assuming a third-party tool for doing this matching, the
tool suite should support the user doing categorical selections and
matches.

1. Construct a set of use cases for the tool suite.

2. Construct an analysis model expressed as a UML class diagram.

3. List and discuss important design issues that will complicate the
   construction of the system.

4. Where in the system do state and concurrency play a role?  Construct
   a state chart to indicate how these issues are handled.  Are all of
   your use cases handled correctly by the state chart?

5. Construct a dataflow diagram of the tool suite design indicating the
   major processes, agents, repositories and data flows.

6. Construct a design model of the system in the form of a UML class
   diagram.

7. What architectural style do you recommend for this suite of tools?  Why?

8. List opportunities for the use of design patterns for the construction
   of the tool suite.