PROPUESTA DE TEXTO ARTICULADO DE LA LECRIM DE

In any software project, software analysis and design phases are meant for defining the architecture and help meet the needs of customers. They are achieved through building models. Models help us visualize a complex system under a controlled environment; it is a simplification of reality. There are a number of methodologies pushing software analysis and design. Of late, Object-Oriented Analysis and Design (OOAD) is particularly popular. Of these, Objectory (by Ivar Jacobson), the Object Modelling Technique (OMT by James Rambaugh) and the Booch Methodology (by Grady Booch) are widely used and successful ones. More recently, a global effort pioneered by these 3 veterans, crystallized their expertize and experiences into a standard known as the Unified Modelling Language (UML) [37].

The UML is a standard language for visualizing, specifying, constructing and documenting a software product. It is methodology neutral and can be used to doc- ument a wide variety of software intelligent systems. A methodology will use this expressive language in producing a software blueprint. One example of such use is the CommonKADS Methodology (a complete methodological framework for devel- oping knowledge-based systems). It uses UML notations.

2.2.1

Diagrams

Central to UML is a wide choice of diagrams, which are graphical presentations of connected elements and their inter-relationships. They are particularly useful for the visualization and construction of software components. Table 2.1 shows the choice of diagrams.

Note that the component and deployment diagrams exist in UML to help docu- ment the organization and dependencies of software components, and how the sys- tem is physically deployed. We find that they are not necessary in documenting agent-based systems per se but will be required to document the software implemen- tation of the system.

2.2.2

Relationships

There are basically 4 types of relationships in object-oriented modelling. These are:

dependencies, which offer a loose coupling link within one class, using the services of another.

15

Number Diagrams Descriptions

1. Activity diagrams Activity diagrams show the flow of control within a system or sub-system. They are particularly effective in showing concurrent activity. Using swimlanes, ownership of an object can be clearly shown. Activity diagrams can be potentially used to show how various software agents interact concurrently with one another. 2. Sequence diagrams Sequence diagrams display how object interacts

in a time sequence.

3. Collaboration diagrams Collaboration diagrams display object interactions organized around objects and their links to one another.

4. Class diagrams A class diagram is a collection of objects with common structure, behaviour, relationship and semantics. The class diagram is static by nature. In agent-based systems, classes can be used to represent agents as well. Stereotypes can be used to mark the distinction for agent classes. 5. State transition A state transition diagram (STD) shows

diagrams the life history of a given class. It shows the events that cause a class to transit from one state to another. State transition diagrams can be nested; this allow us to effectively manage the complexity. In agent-based systems, the states of each agent could be represented by STD.

Table 2.1: Diagrams for software design.

associations represent structural links among objects. generalization for the derivation of inheritance relationships.

2.2.2.1 Dependency

This is the relationship of one class depending on another class [37]. For example, when the object of a class appears in the argument list of a method of another class, the latter is using the former to do something. If the used class changes, there is a high chance that the user class is affected. So the user class depends on the used class. The example in Figure 2.1 shows that class A is dependent on class B to perform some services.

2.2.2.2 Aggregation

This relationship is useful to show that an object contains other objects, in what is widely called the part-whole relationship. The container class, which is also called the owner class, typically creates and destroys the owned object. In Figure 2.2, the

16

B

A

Figure 2.1: Dependency relationship.

IAinNet class really is made up of an array of layers; each of these layers is itself an IAinObj. In UML notation, a diamond shape at the container end pointing towards the contained-object end shows an aggregation through reference. The multiplicity shown indicates that ‘1’ IAinNet object could contain 0 or more IAinObj objects.

The strong form of aggregation is known as composition. This is in cases when the owned object cannot be shared across different owners. Furthermore, the owned object forms an important component within the owner class. For example, a neuron class is composed of an identification tag (could be an integer or string) and weights (could be floats or doubles) among other things. Figure 2.3 shows an example of composition relationship.

2.2.2.3 Association

This is a structural relationship between 2 objects permitting the exchange of prede- fined messages between them (see Figure 2.4). The message flow can be unidirec- tional or bidirectional. For example, the Layer class could maintain a bidirectional relationship with a neuron class. This relationship offers a general relationship be- tween 2 classes, and is used whenever a class uses the services of another class. An aggregation can be seen as an association.

2.2.2.4 Generalization

This is an inheritance relationship, where the derived class has all the characteristics exposed by the parent classes. They are more widely called ‘is-a’ relationship. For example, an InputNeuron class may inherit from a Neuron class because the former ‘is-a’ neuron with more specific roles serving within the input layer. In Figure 2.5, the class ‘Vehicle’ is a root class; derived from it are the car, bus or van classes. This relationship is particularly useful for extending software capabilities. A class hier-

17

+<<virtual>> set(const int param, const int value):bool +<<virtual>> get(cont IAinObj*, IAinObj*):bool +<<virtual>> get(const int param, int &value):bool

+<<virtual>> IterateOneEpoch():bool +<<virtual>> Propagate():bool -Layers:IAinObj* -NumLayers:int +<<virtual>> set(const int param, IAinObj*):bool

+<<virtual>> get(const int param, IAinObj*):bool

IAinNet IAinObj

AinLayer

-NumNeurons:int -Neurons: AinNeuron*

+<<virtual>> set(const IAinObj*, IAinObj*):bool

0..*

1

Figure 2.2: Aggregation relationship.

archy almost always leverages on polymorphism to extend the behaviour of derived classes. In the example, the vehicle may provide a default drive method, which is polymorphic (using keyword virtual). But in reality, driving a car may be slightly different from driving a bus. So the drive method in the bus is defined so as to over- ride the default operation defined in the vehicle class. The power of a class hierarchy and polymorphism are further explored in a number of design pattern books.