The Design Critic Components

See Also: Critic Framework Overview.

High-Level Description: The various design critics in ArchStudio 3 have different behaviors and emit different kinds of messages, although they tend to follow a fairly regular pattern, which is described here. Of course, any particular critic may deviate from the pattern, but the basic pattern is described here. Note that many of these behaviors have good default implementations in the archstudio.critics.AbstractCritic base class, which is the superclass for many of the critic components included in the ArchStudio 3 distribution.

Top Interface Requests: (The following are requests sent out by this component to components above).

• archstudio.critics.CriticStatusMessage: Whenever this critic changes status, it is obligated to send out a CriticStatusMessage upward with one of the following statuses: {Active, Inactive, Busy, Unavailable}. The waiting status is handled exclusively and completely by the Critic Manager component. This is sent upwards as a request primarily so that the CriticADT component can process it. A notification of this must also be sent downward at the same time; see below.
• archstudio.critics.CriticIssueMessage: These messages represent a change in status of an issue that this critic has identified with some open architecture. See the Javadoc description of both the CriticIssue and CriticIssueMessage classes for more information about the contents of these objects. When a critic needs to report a change in status for a particular issue, it sends a CriticIssueMessage request upward. If it needs to replace the status of several issues at once, then it can send a CriticReplaceIssuesMessage; see below.
• archstudio.critics.CriticReplaceIssuesMessage: These requests are sent upward when the critic wants to replace a set of its open issues with a new set. The scopes of the set may be "all open issues from this critic" or "all open issues from this critic with regard to a particular open document." See the documentation for archstudio.critics.CriticReplaceIssuesMessage for more details.

Top Interface Notifications: (The following are notifications handled by this component from components above).

• edu.uci.ics.xarchutils.XArchFileEvent: These events, which usually come from xArchADT, indicate when a new file has been opened or closed. Critics do not have to remove their open issues in response to file-closed events; the Critic ADT will take care of that automatically. However, Critics should respond to file-open requests by checking the opened documents for any errors.
• edu.uci.ics.xarchutils.XArchFlatEvent: These events, which ususally come from xArchADT, indicate a change to an open file. Critics should examine these events to determine if they need to recheck part or all of a document and respond accordingly.

Bottom Interface Requests: (The following are requests handled by this component).

• archstudio.critics.CriticSetStatusMessage: This message is a request to change a critic's status. Critics should only respond to CriticSetStatusMessages where the approved flag is set, meaning it came from the Critic Manager and not some other component. Critics should also ignore the message unless their ID is included in the array of critic IDs in the message. The status from an approved message will always be one of {Active, Inactive}. Inactive critics should cease processing whenever practical and not do any processing while inactive. They do not have to remove their issues from the Critic ADT when going inactive; this will be done automatically.
• archstudio.critics.CriticGetStatusMessage: These messages usually come from the Critic Manager, and are requests for critics to emit their state. Critics should respond to these notifications if their ID is listed in the request's list of critic IDs by emitting a CriticStatusMessage notification downward.

Bottom Interface Notifications: (The following are notifications sent out by this component).

• archstudio.critics.CriticStatusMessage: These messages, indicating the current status of the critic, are sent out in response to changes in state or CriticGetStatusMessage requests. The status returned must be one of {Active, Busy, Inactive}. When a critic is being unwelded (i.e. in its end() method), it should send out one CriticStatusMessage with a state of {Unavailable}.

Required EBI Service Interfaces: (The following are interfaces used by this component via the EBI Wrapper Mechanism and should be made available by a component above this one).

• This varies, but most critics monitor something inside xArchADT, so they usually require the edu.uci.ics.xarchutils.XArchFlatInterface to be available above them.

Provided EBI Service Interfaces: (The following are interfaces implemented by this component via the EBI Wrapper Mechanism and are made available to components below this one).

• Again, this varies, but since most critics monitor something inside xArchADT, they will respond to edu.uci.ics.xarchutils.XArchFlatEvents.