Back to Root Glossary

System Design Glossary

A	B	C	D	E
F	G	H	I	J
K	L	M	N	O
P	Q	R	S	T
U	V	W	X	Y
Z

Our world consists of objects. These objects exist everywhere, in nature, in our work place and in the products that we use. These objects can be created, destroyed, categorized, organized and manipulated. Perhaps, it is due to all pervasiveness of objects in our real world that an object-oriented view was proposed for the creation of computer software. This approach enables us to model our real world into the computer world in ways that helps us to understand and navigate it better than perhaps, other approaches.

Abstract class: A class that cannot be instantiated because a complete implementation has not been specified for all operations of the class.
Abstract data type: A class created to encapsulate a type of information common to an application. Often used for items such as addresses, which contain a number of individual fields combined in a specific way and edited according specific rules unique to that combination.
Abstract operation: An operation signature without an associated implementation.
Abstraction: A unique representation of a real-world entity. The intent of the representation is not a comprehensive description, but rather a description that is useful for a specific application or purpose.
Action: A response to an event in a statechart diagram, typically part of the transition from one state to another and typically atomic (cannot be broken into subtasks).
Action state: An object state that represents the execution of an action, typically the invocation of an operation.
Activation: The execution of an operation on an object or other call to an object to initiate a behavior on that object.
Active object: An object in control of a thread or process that can initiate control activity. In a sequence diagram, this is identified by widening the vertical timeline into a narrow rectangle. In an object diagram, this is signified by making the object icon bold.
Activity: Processing that an object performs particular to a specific state. An activity is typically nonatomic, that is, it may be composed of any number of subtasks.
Activity diagram: The UML version of a flowchart with added features to model concurrent activities.
Actor: A person, system, or device that interacts with a system in a use case diagram.
Agent: An object that can be the source and destination of an interaction.
Aggregate: A class that represents the whole in a whole-part relationship. See also: Composite
Aggregation: An asymmetric type association used to model a whole-part relationship between classes. Usually used to model assemblies of objects to create new objects. See also: Composition
Ancestor: Any class that resides higher than the reference class in a generalization hierarchy. See also: Superclass
Architectural analysis: The first phase of design in which the system is partitioned functionally and strategic decisions are made regarding the choice of technology and the distribution of functionality in that technology.
Architectural partitioning: Assigns technological layers to a domain partition
Architecture: Architecture refers to the way in which components fit together. Can be used to describe any complex system, for example, "software architecture", or "network architecture"
ARP cache: Known hardware address mappings. These can be static (lasting until re-start) or dynamic (lasting between 2 and 10 minutes).
Association: A relationship between classes that specifies the type of links that may be created between objects of the associated classes.
Association class: Information about an association that has been abstracted into its own class.
Assumptions: Behaviors that must be handled by another use case prior to allowing anyone access to the use case in question.
Asynchronous event or action: A type of message that does not require a response and does not require the sending object to wait.
Attribute: A class member used to define a unit of information owned by the containing class, including such details as type and domain of values.
Automatic transition: A transition triggered by the completion or termination of a state activity. See also: Transition
Balking event: A message type in which the client can pass a message only if the supplier is immediately ready to accept the message. The client abandons the message if the supplier is not ready.
Base class: A root class in a generalization hierarchy.
Bound element: A class resulting from the specification of parameters in a template class.
Category: A form of package in a logical view; a category encapsulates classes.
Class: An abstraction of a set of related information, behaviors, and relationships that describes an entity. A definition used to create objects. See also: Object
Class method: An operation/method that is specific to a class rather than to objects of the class.
Class variable: An attribute that is specific to a class rather than to objects of the class.
Classification: The process of finding common information, behaviors, and relationships among objects. See also: Class and Object
Client: An object that initiates a request.
Cohesion: Cohesion is a measure of the degree to which all the parts of an object support a single purpose. High cohesion means that all the elements in the object support the same purpose. Low cohesion means that different elements support different purposes.
Collaboration: An interaction between objects.
Collaboration diagram: One of the two UML standard interaction diagrams designed to model the communication between objects.
Component: A physical unit of software that may reside in memory on a processor and realizes (implements) a set of interfaces.
Component view: A view dedicated to the description of software implementation units; may be used in combination with the deployment view.
Composite: A whole in composition type whole-part relationship between classes.
Composite state: See also: Superstate
Composition: A special case of the whole-part relationship between classes where the life span of the part is dependent on the life of the whole. When the whole is terminated, the part no longer exists.
Concrete class: A class that may be instantiated because an implementation (method) has been specified for every operation inherited or owned by the class. See also: Abstract class
Concurrency: The occurrence of multiple activities at the same time either by executing multiple threads or by multiple processes.
Constraint: The UML extension of the definition of a model element that allows you to add new rules or modify existing ones.
Context: The set of model elements that defines the frame of reference for the interpretation and implementation of a particular model element.
Contract: An agreement between classes regarding the handling of responsibilities and implementation in the class definitions.
Coupling: A measure of the degree of dependency between model elements.
Data dictionary: A data dictionary defines the vocabulary of the problem domain. Entries in the data dictionary can and will change over the course of a project, but they should change only when everyone involved in the project agrees to the change. Use a data dictionary to ensure consistent, high-quality communication.
Data type: The format of information allowed for an attribute, for example, integer, address, character.
Decomposition: Separating an entity or process into smaller functional units.
Delegation: Passing responsibility for a task to another entity, typically hiding the implementation of the task from the requestor.
Dependency: A relationship between two model entities in which a change to one (the independent model element) will affect the other (the dependent model element).
Deployment diagram: The UML diagram used to model the hardware of the implementation environment.
Deployment view: A view dedicated to the description of hardware architectures; may be used in combination with the component view.
Derived association: An association created by shortcutting a series of associations.
Derived attribute: An attribute whose value can be determined by examining one or more other attribute values.
Domain: A subject area with an associated vocabulary and semantics.
Domain partitioning: The first of two activities during architectural analysis when the system is partitioned according to the functionality that it must provide.
Element: A unit of information used to build a model.
Encapsulation: The ability to provide users with a well-defined interface to a set of functions in a way which hides their internal workings. In object-oriented programming, the technique of keeping together data structures and the methods (procedures) which act on them.
Event: A system stimulus, often in the form of a message from one object to another.
Exceptional flow of events: A condition that changes the normal flow of control in a system.
Factorization: The process of finding and extracting common elements between classes. See also: Generalization
Factory pattern: A design pattern that addresses that need to de-couple client objects from the knowledge of how to construct the objects that they want to use.
Generalization: 1. The process of factoring classes to define a hierarchy of shared elements organized into classes. 2. The class hierarchy that is the end result of the factoring process. 3. A type of association used to relate classes in a class hierarchy. See also: Inheritance
Guard condition: A condition associated with a state transition and that must test true before the transition may take place.
Implementation inheritance: The sharing of both the interface and the implementation of a method. See also: Interface inheritance
Import: A dependency between packages where one package obtains access to the other's contents by adding the imported package contents to its own.
Inheritance: A relationship between classes that allows the sharing of elements. See also: Generalization
Instance: The implementation of a class as an object.
Instance method: A method that is unique to an object. See also: Class method
Instance variable: An attribute that is unique to an object.
Interaction diagram: A generic term referring to the two UML diagrams that model object interaction (communication), namely the sequence and collaboration diagrams.
Interface: The visible part of a class. Typically used to describe the public signatures of operations in a class.
Interface inheritance: The sharing of only the interface or declaration of an element, not the implementation.
Iteration: To perform a function or set of functions more than once. The repetition may be used on a value, a count, time, completion of a task, or any other type of condition.
Link: A relationship between two objects. See also: Association
Link attribute: A unit of information about a link. See also: Association class
Logical view: A view dedicated to the description of design options for a software solution.
Main flow of events: The normal flow of control in a system.
Merge of control: To synchronize or coordinate the completion of multiple threads or processes and pass control to a single thread or process. Merge of control does not require the completion of all threads or processes. Merge may be conditional on the completion of one or more of a set of threads, time, or other conditions.
Message: A communication between objects.
Metamodel: 1. The specification of a language for describing object-oriented models. 2. A model that describes the elements, and the relationships between those elements, that make up a specified domain.
Method: The implementation of an operation.
Methodology: An organised, documented set of procedures and guidelines for one or more phases of the software life cycle, such as analysis or.design. Many methodologies include a diagramming notation for documenting the results of the procedure; a step-by-step "cookbook" approach for carrying out the procedure; and an objective (ideally quantified) set of criteria for determining whether the results of the procedure are of acceptable quality.
Model: A representation of a domain in another form, usually designed to simplify and facilitate understanding of the domain.
Model element: The smallest unit of semantic definition in a model. The same model element may appear in multiple diagrams. For example, an event appears in sequence diagrams, collaboration diagrams and statechart diagrams. In all three contexts it provides the same semantic information.
Model-View-Controller (MVC) pattern: One of the first patterns documented. Its purpose was to de-couple the different functions found in many applications, thus improving overall design. The pattern distinguishes between three fundamental types of functionality: Model - the representation of and access to the data; View - the presentation of the data to a user or another system; and the Controller - the logic that decides how to direct the behavior of the application.
Multiplicity: A constraint on the number of objects that may participate in one end of an association.
N-tier architecture: The application of multiple technological layers of technology to support the distribution of the technological and functional responsibilities within an application, typically found in distributed systems.
Navigability: A specification of the allowed direction of communication along an association.
Node: A single unit of hardware capable of containing and executing software. See also: Deployment view
Notation: Any particular system of characters, symbols, or abbreviated expressions used in art or science, to express briefly technical facts, quantities, etc. Esp., the system of figures, letters, and signs used in arithmetic and algebra to express number, quantity, or operations.
Object: A uniquely identifiable entity composed of information, behaviors, and relationships with other entities.
Object activation: An object in control of a thread or process that can initiate control activity. In a sequence diagram, this is identified by widening the vertical timeline into a narrow rectangle. In an object diagram, this is signified by making the object icon bold. See also: Active object
Object Constraint Language: A formal language used to express side effects from constraints in the UML models.
Object design: The fourth phase of the project life cycle in which the objects that represent the software are added to the analysis-level model to support the functionality expected by the use cases.
Object Management Group: The standards group currently overseeing the development and acceptance standards related to object-oriented software development.
Object model: For many people this phrase is synonymous with class diagram. However, the model in a larger sense also includes the object diagram and package diagram.
Object termination: The end of an object's lifecycle, usually denoting object destruction. Identified by a large X at the bottom of a sequence diagram timeline for the specified object.
Object-Oriented Analysis and Design Task Force: The group assigned by the OMG to generate and oversee the RFP for a metamodel for object design.
Operation: The declaration of unit of behavior within a class. See also: Method
Overloading: Used to describe methods where a method name is shared but the arguments vary in number and/or type. See also: Polymorphism
Package: A general-purpose mechanism for grouping models and model elements, typically by similar functions or uses within the context of a system. See also: Component
Pattern: A recurring design solution containing a set of cooperating classes.
Polymorphism: Use to refer to methods where the method signature is the same but the implementation is different. See also: Overloading
Post-condition: A condition that must test true at completion of the owning task.
Pre-condition: A condition that must test true before execution of the owning task.
Primitive data type: The smallest unit of data definition provided by the implementation environment. See also: Abstract data type
Private: A form of visibility constraint that prevents access to a model element from outside of the owning class. See also: Public
Problem analysis: This is the second phase of the project life cycle in which the analyst researches the resources of the problem domain and defines their purpose and interfaces.
Problem domain: The area of the business that is under evaluation during a discussion or project.
Problem statement: A concise description of the project problem or challenge.
Process: A particular course of action intended to achieve a result.
Project initiation: The first phase of the project life cycle in which the clients establish their expectations for the system.
Property: A named value describing a characteristic of an element.
Protected: A type of model element visibility that allows only subclasses to have access to the protected model element, for example, operation or attribute.
Public: A form of visibility constraint that allows access to a model element from outside the owning class. See also: Private
Qualifier: An association modeling element that identifies a descriptive attribute(s) used to navigate an association. Synonymous with keys or indexes in a database or data modeling domain.
Realization: When a class implements an interface specified by another class (or interface, as in Java).
Refactoring: Process for (1) evaluating a model or process in terms of the problems that it causes, and (2) applying common solutions to mitigate those problems. The solutions are revisions to the models or processes themselves.
Reflexive association: An association that relates objects within the same class to one another. See also: Association
Reverse engineering: The process of translating code into modeling elements.
Role: A way of specifying the nature of the participation of an object in an association.
Scenario: A single logical path through a use case, often used as a test case. See also: Use case view
Send event: A message or signal sent to another object from within a statechart diagram.
Sequence diagram: The UML diagram designed to model the interaction between objects overtime. The scope of the diagram is typically a single scenario.
Server: An object that acts only as a respondent in an interaction. Note that the same object may act as a client in another interaction.
Signal: An asynchronous stimulus sent from one object to another.
Signature: The interface of an operation described as the name, number, type, and order of arguments, sometimes the return data type (implementation languages vary on their interpretation). See also: Polymorphism, Overloading, and Interface
Specialization: The opposite of generalization. See also: Generalization and Factorization
Split of control: To initiate multiple threads or processes from a single thread or process.
State: The condition of an object at a point in time.
State design pattern: A design pattern that addresses the need to control an object's behavior differently depending on the state of the object.
Statechart diagram: The UML diagram used to model object states, state transitions, and the behavior of an object during the state changes and during each state.
Stereotype: A UML extension that provides a means of further describing or qualifying a model element without defining its implementation.
Strategy pattern: A design pattern that addresses the need to provide multiple ways to control the behavior of an application or system.
Subclass: A specialized class connected to a more general class or "parent class" in a generalization class hierarchy.
Substate: A state that is part of or inside another state (composite or superstate).
Superclass: A generalized class connected to a more specialized class or "child class" in a generalization class hierarchy.
Superstate: A state that contains other states, for instance, a state defined at a higher level of abstraction.
Synchronous event or action: A form of communication that requires an acknowledgement of receipt of the request.
System: System refers to the set of all functions and resources that supports the goal of the users.
Tagged value: An extension of the properties of a UML element that allows you to add new information to an element's specification.
Technological partitioning: The distribution of software behavior across different technologies within an application design.
Template or template class: A parameterized class that serves as a model for building other classes.
Three-tier architecture: A partitioning within a system that corresponds to the distribution of presentation, business logic, and data access.
Time event: An event that specifies an amount of time elapsed since the current state was entered.
Transition: A change from one state to another state within an object.
Triggering event: Event that initiates the use case. The event could be a point in time (for example, month's end), a condition in the system (for example, account is overdrawn), or a request by an actor (for example, selecting an option).
Try it: Each time you click a glossary term, you'll see a window like this displaying the term and its definition. To see the entire glossary, click Show All Terms.
UML: The Unified Modeling Language is used to specify, visualise, construct and document the components comprising an object-oriented system under development.
Use case: A use case is a goal that a system must achieve to be considered successful.
Use case model: The UML model used to represent clients' expectations about how they will interact with the system.
Use case view: A view dedicated to the description of user requirements.
View: A grouping of diagrams for a particular function in the overall process for developing software.
Visibility: A constraint on the access to attributes and operations within a class specifying the scope of use by objects of other classes. See also: Public, Private, Protected, and Package