An activity performed by an object in a particular state.
Also see: object, state.

The narrow vertical rectangle to emphasize that an object is active only during part of a scenario for a sequence diagram.
Also see: lifeline, sequence diagram.

A step in a workflow used to represent where work is taking place within the system being modeled. The work continues until it is complete, or an event triggers a premature exit.
Also see: activity diagram

A means for describing workflows, and linking activities and states.
Also see: activity

A role played by a user of the system.
Also see: use case.

A relationship between an object and its parts.
Also see: cross link1, cross link 2.

A relationship between two or more classes that specifies the classes concerned collaborate with each other.
Also see: cross link1, cross link 2.

One piece of specific information about a thing.
Also see: identifier, object.

A description of behavior provided by a use case.
Also see: use case.

A process in which solutions to a complex problem are obtained through the composition (or symthesis) of previously developmed subsystems (or modules).

A technique that seeks to alter the nature of work done in a business function with the objective of radically improving performance.
Also see: cross link1, cross link 2.

The type or classification to which similar objects belong.
Also see: class diagram, object.

A graphical model that shows all of the classes of objects in the system in an object-oriented approach.
Also see: class, object-oriented approach.

A set of participants, objects or roles that work together to achieve some meaningful outcome in the context of a system.
Also see: collaboration diagram.

A diagram showing the objects that collaborate together to carry out a use case.
Also see: collaboration; use case diagram.

A physical element of a system (e.g., software or hardware).
Also see: ....

A more strict form of aggregation, there the "part" class has a lifetime co-incident with the "whole class."
Also see: aggregation.

A context diagram is a very quick and focussed representation of the system boundaries, entities that interact with the system, and the nature of this interaction. Because context diagrams have less formal structure than a use case diagram, they can be used very early on the the project development lifecycle.
Also see: use case.

The analysis to compare costs and benefits to see whether an investment in development of a new system will be more beneficial than costly.
Also see: cross link1, cross link 2.

A graphical model showing the inputs, processes, storage, and outputs of a system produced in structured analysis.
Also see: structured analysis.

A stereotype relationship between modeling elements. The stereotype indicates the nature of the relationship (e.g., <<actor>>).
Also see: stereotype.

In a graph and edge is a connection between nodes. In graph theory an edge is an abstract entity that represents a relationship between vertices.
Also see: link, node.

Covering or protecting each object so that it contains values for attributes and methods for operating on those attributes, making the object a self-contained (and protected) unit.
Also see: object.

A graphical model of the data needed by a system, including things about which information is stored and the relationship among them, produced in structured analysis.
Also see: structured analysis.

The process of dividing a system into components based on subsystems that in turn, are further divided into subsystems.
Also see: subsystem, system.

A true/false test to see whether a transition can be taken.
Also see: transition.

Insert material from ENSE 621 notes ....
Also see: layered structure; network structure.

A rule, procedure, approach or guideline for solving a problem that ususlly works. A heuristic is a a rule of thumb, strategy, trick, or simplification, or any other kind of device that drastically limits search for solutions in a large problem space. So what's the catch -- heuristics do not guaranteed optimal solutions. In fact, they don't guarantee solutions at all.
Also see: .....

An attribute that uniquely identifies a thing.
Also see: attribute, object.

An approach to system design that hides the details of implementation with a subsystem or modules border.
Also see: .....

A collection of interrelated components that collect, process, store and provide as output information needed to complete a decision (e.g., make a business or engineering decision).
Also see: system.

A concept that allows subclasses to share characteristics of their superclasses.
Also see: class.

An occurrence of a class.
Also see: class.

A way of organizing a set of operation signitures that can be implemented by a model, such as a class.
Also see: class.

Description of item coming soon ....
Also see: cross link1, cross link 2.

Description of item coming soon ....
Also see: cross link1, cross link 2.

Insert material from ENSE 621 notes ....
Also see: hierarchy structure; network strucure.

Description of lifecycle coming soon ....
Also see: systems engineering lifecycle, cross link 2.

The vertical line under an object on a sequence diagram to show the passage of time for the object.
Also see: activation lifeline.

An occurrence of an association. A relationship between two objects (rather than between two object classes).
Also see: association, class, object.

Any model that shows what the system is required to do, without committing to any one technology.
Also see: physical model.

The specification of a communication sent between objects or roles in a collaboration.
Also see: ........

A meta-model is a symbolic representation of what an engineering/systems model should look like. For systems engineers, meta-models are important because of the assistance they can provide in the integration of complex systems. When meta-models are combined with concepts of abstraction, the result can be a set of guidelines on how modules should be developed for reuse and integration with other modules.
Also see: model.

The behaviors all objects of the class are capable of.
Also see: class, object.

In the traditional approach to systems development, components and modules are connected by point-to-point custom-built interfaces. The complexity of interface development is O(n^2) . A framework-based interface reduces the interface complexity from O(n^2) to O(n) .

The use of framework-based interfaces, otherwise known as middleware, simplifies the development of systems. For example, software programmers need only learn a small number of functions -- middleware takes care of communication details, as shown in the adjacent figure.
Also see: .....

An abstract representation of some aspect of the real world.
Also see: meta-model.

multiplicity corresponds to the range of occurrences that may be found in the model element (e.g., how many instances of a class could be associated with the source class).
Also see: .....

An association that links three or more classes.
Also see: .....

Insert material from ENSE 621 notes ....
Also see: hierarchy structure; layered structure.

A thing in a system that can respond to messages.
Also see: class, object-oriented approach.

A formal language for the expression of constraints.
Also see: ....

Defining all of the types of objects that do the work in the system and showing how the objects interact to complete tasks.
Also see: object.

An approach to systems development that views a system as a collection of interacting objects that work together to accomplish the system's tasks.
Also see: object.

Defining all the types of objects necessary to communicate with people and devices in the system and refining the definition of each type of object so that it can be implemented with a specific technology (e.g., computer language in the case of software).

An ontology is an explicit and precise description of concepts and relations that exist in a particular domain (e.g., an organization; an application area ... etc). For systems engineers, ontologies are concerned with the relationship between a model and the system the model is supposed to represent.
Also see: meta-model.

Description of pattern hatching coming soon ....
Also see: design pattern, pattern hatching

Description of pattern hatching coming soon ....
Also see: cross link1, cross link 2.

Description of pattern languages coming soon ....
Also see: cross link1, cross link 2.

An attribute or object passed as argument to an operation.
Also see: .....

Any model that shows how the system will be implemented, including choices of technology.
Also see: logical model.

A condition that must be true in an operation or use case has been legally operated.
Also see: pre-condition.

A condition that must be true for an operation to be legally executed, or for a use case to be legally applied.
Also see: post-condition.

The area of a user's business (or area of interest) for which a system (or problem solution) is being developed.
Also see: cross link1, cross link 2.

Description of process planning coming soon ....
Also see: cross link1, cross link 2.

A planned undertaking that has a beginning and an end, and which produces a predetermined result or product (i.e., projects tend to be goal-oriented).
Also see: cross link1, cross link 2.

A group of related products that share common features, components and subsystems, but may be customized to satisfy a variety of market niches. A product family comprises:

    -- A set of variables, features or components that remain constant from
       product to product (i.e., this is the product platform), and
    -- Other variables, features or components that vary from product to
       product.

The set of parameters (common parameters), features or components that remain constant from product to product.

Description of item coming soon ....
Also see: cross link1, cross link 2.

In UML, a generic name for some kind of semantic and notational join between two model elements. Associations, generalizations and dependencies are all examples of relationships.
Also see: association, generalization, dependency.

A named behavior of a model element in a particular context, typically the part played object in an association or a collaboration.
Also see:

A particular sequence of activities with a use case. A use case may have several difference scenarios.
Also see: use case.

Description of item coming soon ....
Also see: cross link1, cross link 2.

A diagram showing the sequence of messages between objects during a use case.
Also see: message, use case diagram.

Lifecycle model with heavy iteration that breaks each project into a series of smaller pieces, together with explicit consideration of risks involved in completing each phase of the project.
Also see: waterfall model.

A condition of being for an object.
Also see: statechart

A diagram showing the life of an object in states and transitions.
Also see: state, transition.

In UML, a stereotype is a means of specifying that a modeled element conforms to the well understood pattern of behavior (or existence) or the specified stereotype. Stereotypes are graphically represented as guillemets (i.e., between <<....>>).
Also see: dependency.

A process in which executives try to answer questions about the company such as where they are now, where they want to be, and what needs to be done to get there.
Also see: process planning.

A technique that helps the developer define that the system needs to do (i.e., the functional or processing requirements), what data the system needs to store and use (i.e., data requirements), what inputs and outputs are needed, and the the functions will work together overall to accomplish the system goals.
Also see: structured approach.

System development using structured programming (i.e., functional decomposition), structured analysis, and structured design techniques.
Also see: functional decomposition.

A system that is part of a larger system.
Also see: system.

A column in an activity diagram use to indicate and area of responsibilities for the activities.
Also see: ....

A point in an activity diagram, or a statechart, where either a transition may split into multiple parallel flows, or multiple parallel flows can be synchronized to meet and fire a single transition.
Also see: ....

A collection of interrelated components that function together to achieve an outcome.
Also see: information system, subsystem, system lifecycle,

The fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviors.
Also see: system design.

The separation between a system and its environment that inputs and outputs cross.
Also see: system.

An assemblage of realizable system elements and sub-elements and their interfaces.
Also see: system architecture.

Comprehensive guidelines to follow for completing every activity in the system development lifecycle, including models, tools and techniques.
Also see: lifecycle.

Description of item coming soon ....
Also see: cross link1, cross link 2.

Strategies for completing specific system development activities.
Also see: cross link1, cross link 2.

A mechanism for attaching (name, value) pairs to model elements.
Also see: cross link1, cross link 2.

Analytical and software products used to help develop analysis and design specifications and complete system components.
Also see: cross link1, cross link 2.

A process in which solutions to a complex problem are obtained through decomposition into a hierarchy of simplier problems.

Material coming soon .....