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:
Multiple representations such as program syntactic decomposition, state transitions, control flow, and data flow. These allow the programmer to better identify elements and relationships in the problem and solution and thus more readily create a mapping between their situation models and working system models.
Familiar aspects of a situation model, which improve designers' abilities to formulate solutions.
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 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.
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 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.
Some 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.
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 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.