Glossary

abstraction: The essential characteristics of an entity that distinguish it from all other kinds of entities and thus provide crisply defined boundaries relative to the perspective of the viewer.

activity: A unit of work that a worker may be asked to perform.

actor (instance): Someone or something outside the system or business that interacts with the system or business.

actor class: A class that defines a set of actor instances in which each actor instance plays the same role in relation to the system or business.

architectural baseline: The baseline at the end of the elaboration phase, at which time the foundation structure and behavior of the system are stabilized.

architectural pattern: A description of an archetypal solution to a recurrent design problem that reflects well-proved design experience

architectural view: A view of the system architecture from a given perspective; focuses primarily on structure, modularity, essential components , and the main control flows. See also view.

architecture: See software architecture.

artifact: A piece of information that is produced, modified, or used by a process, defines an area of responsibility, and is subject to version control. An artifact can be a model, a model element, or a document.

baseline: A reviewed and approved release of artifacts that constitutes an agreed-on -basis for evolution or development and that can be changed only through a formal procedure, such as change and configuration control.

build: An operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the final product.

change control board (CCB): The role of the CCB is to provide a central control mechanism to ensure that every change request is considered , authorized, and coordinated properly.

change management: The activity of controlling and tracking changes to artifacts.

change request (CR): A request to change an artifact or process. Documented in the CR is information on the origin and impact of the current problem, the proposed solution, and its cost.

class: A description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics.

component: A nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces.

component-based development (CBD): The creation and deployment of software- intensive systems assembled from components as well as the development and harvesting of such components.

configuration: (1) General: The arrangement of a system or network as defined by the nature, number, and chief characteristics of its functional units; applies to both hardware and software.(2) The requirements, design, and implementation that define a version of a system or system component.

configuration management (CM): A supporting process workflow whose purpose is to identify, define, and baseline items; control modifications and releases of these items; report and record status of the items and modification requests ; ensure completeness, consistency, and correctness of the items; and control storage, handling, and delivery of the items. (ISO)

construction: The third phase of the Rational Unified Process, in which the software is brought from an executable architectural baseline to the point at which it is ready to be transitioned to the user community.

cycle: One complete pass through the four phases: inception, elaboration, construction, and transition; the span of time between the beginning of the inception phase and the end of the transition phase.

defect: A product anomaly; examples include omissions and imperfections found during early lifecycle phases and symptoms of faults contained in software sufficiently mature for test or operation. A defect can be any kind of issue you want tracked and resolved.

deliverable: An output from a process that has a value, material or otherwise , to a customer.

deployment: A core process workflow in the software engineering process whose purpose is to ensure a successful transition of the developed system to its users. Included are artifacts such as training materials and installation procedures.

deployment view: An architectural view that describes one or several system configurations; the mapping of software components ( tasks , modules) to the computing nodes in these configurations.

design: The part of the software development process whose primary purpose is to decide how the system will be implemented. During design, strategic and tactical decisions are made to meet the required functional and quality requirements of a system.

design model: An object model that describes the realization of use cases; serves as an abstraction of the implementation model and its source code.

development case: The software engineering process used by the performing organization. It is developed as a configuration or customization of the Rational Unified Process product and adapted to the project's needs.

domain: An area of knowledge or activity characterized by a family of related systems.

elaboration: The second phase of the process, in which the product vision and its architecture are defined.

environment: A core supporting workflow in the software engineering process whose purpose is to define and manage the environment in which the system is being developed. Includes process descriptions, configuration management, and development tools.

evolution: The life of the software after its initial development cycle; any subsequent -cycle during which the product evolves.

framework: A micro-architecture that provides an incomplete template for applications within a specific domain.

implementation: A core process workflow in the software engineering process whose purpose is to implement and unit test the classes.

implementation model: A collection of components and the implementation subsystems that contain them.

implementation subsystem: A collection of components and other implementation subsystems; used to structure the implementation model by dividing it into smaller parts .

implementation view: An architectural view that describes the organization of the static software elements (code, data, and other accompanying artifacts) of the development environment, in terms of packaging, layering, and configuration management (ownership, release strategy, and so on). In the Rational Unified Process, it is a view on the implementation model.

inception: The first phase of the Rational Unified Process, in which the initial impetus for developing software ”an idea, a prototype, a Request for Proposal (RFP), an evolution over a previous generation ”is brought to the point of being funded (at least internally) to enter the elaboration phase.

increment: The difference (delta) between two releases at the end of subsequent -iterations.

integration: The software development activity in which software components are combined into an executable whole.

iteration: A distinct sequence of activities with a baselined plan and valuation criteria resulting in a release (internal or external).

layer: A specific way of grouping packages in a model at the same level of abstraction.

logical view: An architectural view that describes the main classes in the design of the system: major business-related classes and the classes that define key behavioral and structural mechanisms (persistency, communications, fault tolerance, and user interface). In the Rational Unified Process, the logical view is a view of the design model.

management: A supporting workflow in the software engineering process whose purpose is to plan and manage the development project.

method: (1) A regular and systematic way of accomplishing something; the detailed, logically ordered plans or procedures followed to accomplish a task or attain a goal. (2) UML 1.2: The implementation of an operation; the algorithm or procedure that affects the results of an operation.

milestone: The point at which an iteration formally ends; corresponds to a release point.

model: A semantically closed abstraction of a system. In the Rational Unified Process, a complete description of a system from a perspective ”"complete" meaning that you don't need additional information to understand the system from that perspective; a set of model elements.

model element: An element that is an abstraction drawn from the system being - modeled .

node: A runtime physical object that represents a computational resource, generally having at least a memory and often processing capability. Runtime objects and components may reside on nodes.

object: An entity with a well-defined boundary and identity that encapsulates state and behavior. State is represented by attributes and relationships, and behavior is represented by operations and methods . An object is an instance of a class.

object model: An abstraction of a system's implementation.

operation: A service that can be requested from an object to affect behavior.

phase: The time between two major project milestones during which a well-defined set of objectives is met, artifacts are completed, and decisions are made to move or not to move into the next phase.

prototype: A release that is not necessarily subject to change management and configuration control.

quality: The characteristic of an artifact that satisfies or exceeds a defined and accepted set of requirements, is assessed using defined and accepted measures and criteria, and is produced using a defined and accepted process.

release: A subset of the end product that is the object of evaluation at a major milestone.

report: An automatically generated description that describes one or several artifacts. A report is not in itself an artifact. A report is in most cases a transitory product of the development process and a vehicle to communicate certain aspects of the -evolving system; it is a snapshot description of artifacts that are not themselves -documents.

requirement: A description of a condition or capability of a system; either derived directly from user needs or stated in a contract, standard, specification, or other formally imposed document.

requirements workflow: A core process workflow in the software engineering process whose purpose is to define what the system should do. The most significant activity is to develop a use-case model.

risk: An ongoing or impending concern that has a significant probability of adversely affecting the success of major milestones.

role: See worker.

scenario: A described use-case instance; a subset of a use case.

sequence diagram: A diagram that describes a pattern of interaction among objects arranged in chronological order; it shows the objects participating in the interaction by their "lifelines" and the messages that they send to one another.

software architecture

Software architecture encompasses the following:

The significant decisions about the organization of a software system
The selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements
The composition of these elements into progressively larger subsystems; the architectural style that guides this organization, these elements, and their interfaces, their collaborations, and their composition

Software architecture is concerned with not only structure and behavior, but also usage, functionality, performance, resilience, reuse, comprehensibility, economic and technologic constraints and trade-offs, and aesthetic issues.

stakeholder: Any person or representative of an organization who has a stake ”a vested interest ”in the outcome of a project or whose opinion must be accommodated. A stakeholder can be an end user, a purchaser, a contractor, a developer, or a project manager.

stub: A dummy or skeletal implementation of a piece of code used temporarily to develop or test another piece of code that depends on it.

test: A core process workflow in the software engineering process whose purpose is to integrate and test the system.

transition: The fourth phase of the process in which the software is turned over to the user community.

use case (class): A sequence of actions a system performs that yields an observable result of value to a particular actor. A use-case class contains all main, alternate, and exception flows of events related to producing the observable result of value. Technically, a use case is a class whose instances are scenarios.

use-case model: A model of what the system is supposed to do and the system -environment.

use-case realization: A description of the way a particular use case is realized within the design model, in terms of collaborating objects.

use-case view: An architectural view that describes how critical use cases are performed in the system, focusing on architecturally significant components (objects, tasks, nodes). In the Rational Unified Process, it is a view of the use-case model.

version: A variant of an artifact; later versions of an artifact typically expand on earlier versions.

view: A simplified description (an abstraction) of a model that is seen from a given perspective or vantage point and omits entities that are not relevant to this perspective. See also architectural view.

vision: The user's or customer's view of the product to be developed.

worker: A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a software engineering organization. The worker represents a role played by individuals on a project and defines how they carry out work.

workflow: The sequence of activities performed in a business that produces a result of observable value to an individual actor of the business.