Glossary

Activity Diagram: A special kind of state diagram. The diagram shows the decomposition of a system into activities. It begins with the start of an activity and often terminates at the end of that activity. This diagram refers to states as action states. Two stereotypes of action states can be used in the diagram, one for explicitly sending an event, and another for receiving an event. The diagram is also used to show forks, joins, guards, and states. Decision points are used here to show branch points, based on guards, for flow of logic. It is therefore useful in describing behaviour that has a lot of concurrent processing. It is useful for graphically representing where the threads are and for showing the synchronization points. It is also used for looking at behaviour across many use cases. It may also be used to show an implementation perspective of a method in a class as an activity. Swim lanes are used in this diagram to visually group states. Further, unlike state charts, here, the states do not all have to belong to a single object.

Applet: An applet is a Java program that is transported over the Internet and designed to live inside a web page or the applet viewer.

Applet Communication: The process where an applet sending messages to another applet usually through the means of AppletContext mechanism.

Black box testing: Testing that is concerned with matching expected results with actual results - not how the internals of the component being test works. Also known as functional testing or interface testing.

Component: A piece of software small enough to create and maintain, big enough to deploy and support, and with standard interfaces for interoperability (Jed Harris)

Deployment diagram A diagram used to show the physical placement, routing and movement of components and objects in a distributed system.

Events: Events cause a change from one state to another. From a modeling point of view, events have no duration. That is, they have either occurred or not occurred yet. We know that an event has occurred by observing the effect of an event in a model. We are only interested in some of the events in a system. These are events that cause our models to change its state.

Events are not objects. But, the model must include the memory of an event that has occurred if that event causes the model to change its state. We construct object models to record memories of events. In our system model, we describe the possible states of the system, the possible sequences of events, and how the state changes as a result of events. Several objects may change their state in response to a single event. We show the name of an event and parameter to the event in our OO model. A deposit event is described as follows: deposit(sum).

The parameters to an event can be object types and value types. If a parameter is an object type, the event knows the identity of that object. Objects use an event's parameters to decide whether they are interested in it. For example, in a TV/Remote operation, for an event: TVOn(on: RemoteControl), we show that RemoteControl is interested in that event. We can also invoke the event, TVOn by selecting a channel from the number of TV channels available. Selecting one channel causes another channel to be switched off. We show these behavioural details using a state chart.

Event Driven Program: A new approach of programming style, the application will spend most of its time waiting for user requests, such as menu selection, then process the request.

Inheritance: Deriving a new class from an existing class inheriting all the characteristics of the existing class

Interaction diagrams: The general term for sequences diagrams and collaboration diagrams. Sequence diagrams emphasize messages and their sequence, and show objects as vertical lines and horizontal directed lines as messages. Time flows from top to bottom of the diagram. Collaboration diagrams emphasize the static structure of the collaborating objects, and show message sequencing by numbering the messages.

Interface: A new technique to replace multiple inheritance in Java, it behaves like a class except it does not have data members nor the implementation of the methods. In other words, it only defines the signature of the methods.

Message Sequence Diagram: A diagram used to capture the behaviour of several objects within a single use case. This modeling diagram is used to show objects and the messages that flow between these objects in a single use case.

Object Request Broker (ORB): The CORBA object bus which brokers object communication with location transparency. ORB lets inter object calls within multiple processes on a single machine, or multiple processes across various platforms and networks. ORB can run on a single laptop or connected via Internet InterORB Protocol (IIOP) with CORBA 2.0 to other vendor ORBS across the world.

Orthogonal state charts: A state chart which is composed of independent state machines are shown by separating a chart into components using dashed lines. Harel's chart with this behaviour is called an orthogonal state machine. Parallel components may be classed as orthogonal machines and are "And charts". An instance of such a chart must all the time be in one state from each of the state machines that make up the orthogonal chart. For example, TV operations of sound and image are independent of each other. Using a remote control, one can toggle between teletext operation and channel 7 on TV. But this toggling or switching between teletext mode and TV mode does not affect the sound. We can show the "sound " and "image" as orthogonal components, include soundOff and soundOn as states of the sound component, and include TV mode and Teletext mode as states of the image component.

Regression testing: Testing to check that the functionality of a previously tested system still works after changes have been made to the system. It involves repeating a series of tests on the system to ensure that changes have not introduced any errors.

States: Events occur in a particular sequence. For example, a VCR object has two events : VCROn & VCROff . We need to know whether the VCR is in On or Off state to figure out which of the two events, VCROn or VCROff will occur next. The event, VCROff triggers the object to transition from On state to Off state. The possible event sequence is {VCROn, VCROff, VCROn, VCROff, …]. An object may have a number of states. We model only those states which are essential for showing the ordering of events relevant to our system behaviour.

State Charts: A single state machine for a complex system would be large and difficult to use. We describe each object's life cycle in terms of a separate state machine. This approach reduces the complexity inherent in finite state machines and enables a state model of a system to be composed of a number of state machines. Harel's chart introduced a visual formalism for state charts and supports orthogonal machines and nested states.

State charts include information on object creation, events of interest to this object type, actions associated with these events, and constraints associated with state transitions. A guarded transitions can occur only if the constraints included as logical predicates is true. Preconditions can be attached to events and postconditions can be attached to transitions to constrain the consequence of an event. Invariants can be specified in a state chart and are logical expressions to show the condition that must hold for all the possible states of an object.

State diagram: A diagram that shows the behaviour of a system by showing all the states that an object can be in and the transitions between states as a result of events, and the predicates that must be true for the transition to fire. State diagrams are usually drawn for a single class to show a single object's life cycle behaviour. Also known as a state transition diagram. The complexities of these diagrams increase as state explosion occurs for complex systems.

Structural testing: Testing that the internal structure works correctly by looking at the lines of code being executed. Also known as code-based testing, glass-box testing or white box testing.

Test coverage analysis: A check of the implementation under test (IUT) white box to determine which statements were executed by running the complete test sequence.

Test sequence: A list of test cases generated by traversing the state transition graph. The test sequence should start from the initial state, go through all the possible transitions, and return back to the initial state.