A UML diagram capturing the dynamic behavior of a system or sub-system. See Section 6.10, “Activity Diagrams (To be written)” for more information.

Behavior associated with States or Transitions in State Diagram. These actions are invocations of Methods and appear on Sequence and Collaboration Diagrams.

A representation of an agent (animate or inanimate) on a Use Case Diagram external to the system being designed.

Analysis is the process of taking the “customer” requirements and re-casting them in the language of, and from the perspective of, a putative solution.

A class that characterizes the association between two other classes.

A relationship between two classes in a Class Diagram or between Use Cases or Use Cases and Actors in a Use Case Diagram.

An attribute of a class or object is a specification of a data element encapsulated by that object.

Computer Aided Software Engineering.

The encapsulation of the data associated with a model element (its attributes) and the actions associated with the model element (its methods).

A class specifies the characteristics of a model element. An object represents an instance of the model element.

Classes and objects in UML are represented on Activity Diagrams, Class Diagrams, Collaboration Diagrams and Sequence Diagrams.

A UML Diagram showing the structural relationship between classes. See Section 5.2, “Class Diagrams (To be written)” for more information.

The process whereby several objects cooperate to provide some higher level behavior that is greater than the sum of the behaviors of the objects.

A UML Diagram showing the dynamic behavior as messages are passed between objects. Equivalent to a Sequence Diagram. Which representation is appropriate depends on the problem under consideration.

An object that participates in a Collaboration.

A design visualization theory within cognitive psychology. The theory notes that designers must bridge a gap between their mental model of the problem or situation and the formal model of a solution or system.

This theory suggests that programmers will benefit from:

A Class Diagram constructed during the Analysis Phase to show the main structural components of the problem identified in the Requirements Phase. See Chapter 5, Analysis for more information.

A process within ArgoUML that provides suggestions as to how the design might be improved. Suggestions are based on principles within three theories of cognitive psychology, reflection-in action, opportunistic design and comprehension and problem solving.

A relationship between two Use Cases, where the extended Use Case describes a special variant of the extending Use Case.

A relationship between one generalizing Use Cases and one or more generalized Use Cases, where the generalized Use Cases are particular examples of the generalizing Use Case.

Graphical User Interface.

A Statechart Diagram that contains subsidiary statechart diagrams within individual States.

A relationship between two Use Cases, where the included Use Case describes part of the functionality of the including Use Case.

A design process where each all phases (requirements, analysis, design, build, test) are tackled partially in a series of iterations. See Section 3.2.1, “Types of Process” for more information.

A fully object oriented programming language introduced by Sun Microsystems. More strongly typed than C++, it compiles to an interpreted code, the Java Virtual Machine (JVM). The JVM means that Java code should run on any machine that has implemented the JVM.

The most significant component of Java was integration of the JVM into web browsers, allowing code (Applets) to be download and run over the web.

ArgoUML is written in Java.

A Statechart Diagram where actions are associated with States.

A method of a class or object is a specification of behavior encapsulated by that object.

A Statechart Diagram where actions are associated with Transitions.

An instance of a Class.

Classes and objects in UML are represented on Activity Diagrams, Class Diagrams, Collaboration Diagrams and Sequence Diagrams.

Object Constraint Language. A language for describing constraints within UML.

The Object Management Group. An international industry standardization body. Best known for CORBA and UML.

Object Oriented Analysis and Design. An approach to software problem analysis and design based on objects, which encapsulate both data and code. See See Section 1.1.1, “Object Oriented Analysis and Design” or any standard textbook on Software Engineering.

UML is a notation to support OOA&D.

A theory within cognitive psychology suggesting that although designers plan and describe their work in an ordered, hierarchical fashion, in actuality, they choose successive tasks based on the criteria of cognitive cost. Simply stated, designers do not follow even their own plans in order, but choose steps that are mentally least expensive among alternatives.

A sub-window within the main window of the ArgoUML user interface.

A Use Case where the Use Case Diagram and Use Case Specification are in the language of the solution domain, rather than the problem domain.

A theory within cognitive psychology which observes that designers of complex systems do not conceive a design fully-formed. Instead, they must construct a partial design, evaluate, reflect on, and revise it, until they are ready to extend it further. As developers work hands-on with the design, their mental model of the problem situation improves, hence improving their design.

Requirement capturing is the process of identifying what the “customer” wants from the proposed system. See Chapter 4, Requirements Capture for a fuller description.

S ome behavior for which an object is held accountable. A responsibility denotes the obligation of an object to provide a certain behavior.

A specific sequence of actions that illustrates behavior.

A UML Diagram showing the dynamic behavior as messages are passed between objects. Equivalent to a Collaboration Diagram. Which representation is appropriate depends on the problem under consideration. See Section 5.4, “Sequence Diagrams (To be written)” for more information.

Standard Graphical Markup Language. Defined by ISO 8879:1986.

A procedural programming language intended for simulation. Noted for its introduction of objects and coroutines.

Within a Statechart Diagram a one of the possible configurations of the machine.

A UML Diagram showing the dynamic behavior of an active Object. See Section 5.6, “Statechart Diagrams (To be written)” for more information.

Any model element within UML can be given a stereotype to indicate its association with a particular role in the design. A stereotype spqr is generally indicated with the notation <<spqr>>.

A stereotype defines a Namespace within the design. Examples of stereotypes are <<business>> and <<realization>> for Use Cases, used to distinguish between Use Cases at the requirements phase defined in terms of the problem domain, and Use Cases at the analysis phase defined in terms of the solution domain.

The document capturing non-functional requirements that cannot be associated with Use Cases.

Scalable Vector Graphics format. A standard representation of graphics diagrams that use vectors. ArgoUML can export diagrams in SVG.

A Sequence Diagram used in the Analysis Phase showing the dynamic behavior of the overall system. See Chapter 5, Analysis for more information.

A Statechart Diagram used in the Analysis Phase showing the dynamic behavior of an active top level system objects. See Chapter 5, Analysis for more information.

A feature of ArgoUML allowing the user to record activities that are yet to be completed.

The change between States in a Statechart Diagram..

Universal Modeling Language. A graphical notation for OOA&D processes, standardized by the OMG. ArgoUML supports UML 1.4. UML 2.0 is in the final stages of standardization and should be complete during 2006.

A UML notation for capturing requirements of a system or sub-system. See Section 4.3, “Output of the Requirements Capture Process” for more information.

A UML diagram showing the relationships between Actors and Use Cases. See Section 4.3, “Output of the Requirements Capture Process” for more information.

The document capturing the detailed requirements behind a Use Case.

The top level document describing what the system being developed is to achieve.

The World Wide Web Consortium, www.w3c.org. An international standardization body for all things to do with the World Wide Web.

A design process where each phase (requirements, analysis, design, build, test) is completed before the next starts. See Section 3.2.1, “Types of Process” for more information.

XML Model Interchange format. A format for file storage of UML models. Currently incomplete, since it does not carry all graphical layout information, so must be supplemented by files carrying that information.

eXtensible Markup Language. A simplified derivative of SGML defined by W3C