To load the document into Argo do one of the following:
Relevant screenshots of Argo are included in the discussion below. Each screenshot is less than 20Kb.
The example document shows a partially specified architecture for a video game system. The object of the game is to catch colored tiles that fall from the top of the window and drop them so that the form matching rows, columns, or diagnols. Software components implement the various parts of the game:
We have implemented this example system in both Java and C++. The internals of the components are not of concern in this example. Here we focus only on how these components are combined to make a complete product.
The main Argo window has tabs for each of four design perspectives on the system under design.
Critics are composed of domain-specific rules and feedback to present to the designer. Argo currently provides about 20 critics as examples of various things that critics can do. Critics can check the correctness and completeness of the design based on the syntactic and semantic rules of the domain. Critics can also apply rules of thumb to remind designers of standards practices. Critics can also be specific to individual software components (or other design materials) to inform the designer of the implications of using them. The feedback critics provide may directly aid the designer in fixing a problem, or may remind the designer of unexplored alternatives, or people in the development organization who hold a stake in the design decision at hand.
When the designer selects an item of design feedback from the ToDoList window, Argo attempts to give the designer the information needed to resolve the issue: (1) presents a brief explanation of the problem and possible solutions, (2) highlight the "offending" design elements, (3) allow the designer to jump to background information about the domain and this issue, (4) allow the designer to contact the person who authored or maintains the critic thus providing an entry into the organizational context [screenshot].
The Clock component has a critic that is specific to it that informs the designer that the component is unreliable on certain platforms and gives contact information for a person in the development organization who has had experience with this issue in the past. [screenshot] [screenshot]
Some critics identify problems that can be fixed automatically. For example when a host does not have enough memory, the critic that identifies the problem is willing to fix it [screenshot]. In this example it fixes the problem by adding more memory, ideally it might bring up a wizard to step the designer through several options.
With a large number of critics in the system, the designer can be innuncated with too much feedback. To address this problem Argo uses a variety of criticism control mechanisms. The simplest is "hushing" the critic which puts it to sleep for a short time, after which it wakes up and may raise the same issue. The most powerful is uses a model of the decision categories that the designer is considering at any given point. This model is based on the infomation supplied in the decision process model. Designers may inspect and manipulate critics through the "Critics" window [screenshot].
[Needs-More-Work: Am I describing the example design, or starting on a (poorly organized) users guide? ]