This file describes how to do specific tasks in extending Argo and applying it to new domains. These descriptions are inteded for programmers who have some knowledge of Java(tm), and have read the Argo Overview, are considering making modifications to Argo.
Table of contents:
Background: Cookbooks are intented to help people accomplish specific structured tasks. They mainly provide process information in the form of a sequence of steps, and domain-specific knowledge in the form of brief descriptions and links to background materials. The format of each cookbook entry (recipe) is similiar to this one.
Applicability: You should use a cookbook when there is a specific task you want to accomplish and there is a recipe in the cookbook that supports that specific task. Also, browse the cookbook to see what tasks are supported.
Ingredients: Each recipe lists the matierals that you may need to accomplish the task. Not all matierals are needed in all cases.
Steps:
Results: Each recipe lists the
results that you can expect and how to verify that the task was
completed successfully.
Background: Argo provides a
domain-independent infrastructure for building domain-dependent design
environments. The Argo infrastructure provides general support for
design representation, critics, the ToDoList, the decision model, and
domain-independent user interfaces. It is the task of a domain
engineer to specialize the Argo infrastructure to a particular domain.
We have defined domain models for C2 style software architecture, a
simple design decision process model, and a very simple
object-oriented design (eventually we may support UML). We will also
be applying Argo to a requirements specification domain.
Applicability: Use this recipe
when you want to apply Argo to a new domain.
Ingredients: A general
understanding of the domain and of the Argo infrastructure. As you
learn more about the domain you can modify the domain model. You
should find it easy to start small and add more incrementally.
Steps:
Results: An initial version of
a domain-modeling extension to Argo's infrastructure.
Background: Design materials
are the types of design elements that can be used in a given domain.
For example, software components in a software architecture domain, or
funiture in a office floorplan domain. In Argo design materials are
objects that are defined in subclasses of class
jargo.kernel.DesignMaterial.
Applicability: Add a new
DesignMaterial when you want to extend the domain model to a new type
of design element.
Ingredients: An understanding
of the design element to be modeled.
Steps:
For more information on developing the binding between an Argo
model and a GEF diagram, see the GEF documentation.
Results: A new kind of
domain-specific design matieral that can be selected from the palette,
placed in a design, edited via the property sheet, shown in different
perspectives, and related to other design materials.
Background: Expert designers
consider a wide range of design issues, and they use multiple mental
models of the design to address those diverse design issues. Argo
provides design perspectives to allow designers to visualize the
design in multiple ways that "match" their multiple mental models.
Most of Argo's support for design perspectives is actually implemented
in GEF.
Applicability: Define a new
design perspective when you are ready to extend your domain model to
address a new set of design issues that need to be visualized
together. As a short-cut in defining a domain, design perspectives
can be made overly broad, causing multiple unrelated issues can be
visualized together. The need for a new design perspective often
becomes clear when existing design perspectives become too hard to
visualize (because they are crowded, large, or too non-planar).
Ingredients: Knowledge of the design issues of concern in
this domain. Knowledge of what design materials and relationships are
related to the design issues being supported by this perspective.
Visualizations for design materials and relationships that are
appropriate for use in this design perspective.
Steps:
Results: A new design
perspective that the design can use to visualize design elements
related to specific design issues.
Background: Decision categories
make up Argo's decision model. The decision model lists decision
categories that the designer is currently considering. This
information is used to enable or disable critics so that they are
timely to decisions being considered by the designer. When defining a
new domain the domain engineer must define a decision model and relate
critics to specific decision types. Decision categories currently are
not modeled in great detail, they are simply descriptive strings.
Applicability: Use this recipe
when you are defining or extending a domain and you have a broad
understanding of the decisions that must be made by designers in that
domain.
Ingredients: A place to put
code that will be executed before critics will be activated, a name
for a domain-specific decision category. Since Argo uses only decision
categories, instead of modeling specific decisions, the domain
engineer need not know everything about the decisions in great detail.
Steps:
Results: A new decision
category in the decision process model that can control critics to
keep them timely.
Background: Critics
continuously evaluate the design to identify potential problems and
opportunities for improvement. Critics can check correctness,
completeness, consistency, and proper use of notation. They can also
identify places in the design where good alternatives exist but have
not been considered, or situations in which the knowledge of other
people in the design comunity have be useful to the designer. When a
critic's analysis predicate evaluates to true, it produces a piece of
design feedback to be presented to the designer.
Applicability: Use this recipe
when you want to add a critic.
Ingredients: A subclass of
DesignMaterial, a analysis predicate written in terms of
properties of DesignMaterials, a short piece of text describing the
issue and possible soultions, the URL of background information
relevant to the issue, the email address of a person who authored or
will maintain the critic, knowledge of which design decision category
this critic supports.
Steps:
Results: A functioning critic
that is automatically loaded and applied to DesignMaterials
as needed.
How to define a new domain
How to define a domain-specific design
material
How to define a domain-specific design
perspective
How to define a domain-specific decision
category
How to define a critic
Argo Home Page |
Available documentation