[Modeling] Class Diagram Specification

[Wagner, G.R.]

>> Obviously, a software agent (like other entities) has properties
>> that are represented by means of attributes (e.g. its name, its
>> GUID, etc.). In addition, it has beliefs (and possibly further
>> mental state components). As the name "mental state component"
>> suggests, its belief types may be modeled as (<<belief>> stereotyped)
>> object types and other agent types, which are attached to the agent
>> type under consideration by means of composition. They are
>> containers for beliefs about objects and agents in the environment
>> of this agent.
> 
> When you define your agents, what are you thinking first? I need an 
> attribute GUID with the visibility private and a method to access it 
> or I need to define a unique ID for my agent? 

Usually, we start with conceptual/domain modeling, where we use the
attribute concept (with implementation aspects such as visibility)
for modeling properterties.

> When you speak about stereotypes for beliefs,
> and objects and containers, you are too far involved in the design, 

No, that's not design, it's domain analysis (UML class diagrams can 
be used for domain modeling, for design modeling and for implementation 
modeling). In the domain, there are certain entities (beliefs about 
objects and agents), which I can model as <<belief>>-stereotyped classes.

> I want to go backward and say, I have to include my agent the belief
> (believe agent1 (is Melbourne sunny)) 

A belief is always expressed in some language defined by a schema
which may be expressed by a UML class model (or an RDF/OWL schema). 
So, in this example the belief refers to an instance of the object 
type City and attaches a special value ("sunny") to the attribute 
TodaysWeather.

-Gerd