Glossary | Blogosphere: Best of Blogs

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

activity: A unit of work that a role performs . An activity may be decomposed into steps. Activities produce or modify artifacts.

actor: Someone or something outside the system or business that interacts with 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.

base: See [RUP Base]

baseline: A reviewed and approved release of artifacts that constitutes an agreed-on basis ”a reference ”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.

builder: See [RUP Builder]

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 have 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.; See also [process component]

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 ”that results in a product release.

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 artifact of the process that has a value, material or otherwise , to a customer.

deployment: A core discipline 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 on a given project. It is developed as a configuration of the Rational Unified Process product adapted to the project's needs.

discipline: A logical grouping of roles, activities, artifacts, and other elements of guidance in the description of a process.

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 supporting discipline 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.

extended help: A RUP feature that allows associated software development tools to provide a context to the RUP, which will make the RUP display appropriate topics based on the given context.

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

implementation: A discipline 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 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 plan and evaluation criteria that result 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 discipline in the software engineering process whose purpose is to plan and manage the development project.

measure: A numeric attribute of an entity.

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.

metrics: (obsolete) Replaced by measure or measurement in RUP 2003.

milestone: The point at which an iteration or phase 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 .

modeler: See [RUP Modeler]

MyRUP: The RUP browser used to view the process, search, use the index, navigate graphically, and create personalized process views of a RUP Process Configuration.

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.

organizer: See [RUP Organizer]

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.

plug-in: A RUP Plug-In is a deployable unit for one or several RUP Process Components that can be readily "dropped" onto a RUP Base to extend it. A RUP Plug-In can be compiled into a physical file, allowing it to be moved around and added to a RUP Library with a compatible RUP Base.

process component: A RUP Process Component is a coherent , quasi-independent " chunk " or module of process knowledge that can be named, packaged, exchanged, and assembled with other process components.

process configuration: A RUP Process Configuration is a browsable set of RUP Process Components that constitute a complete process ("complete" from the perspective of a particular user). It is a Web site that sits on the user's machine or a server. RUP Process Configurations are compiled with RUP Builder.

Process View: A feature of MyRUP that allows you to customize the parts of the RUP Process Configuration, as well as external links, you want to see in your MyRUP tree browser. Process views can be role-based (for example, analyst, developer, tester) or personalized for the needs of a specific user.

prototype: A release that is not necessarily subject to change management and configuration control. A prototype may be throwaway or may evolve into becoming the final system.

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.

Rational Process Workbench ( RPW ): A process authoring toolkit. It is a combination of tools, processes, and other assets that allow a process engineer to develop RUP Plug-Ins. The RPW includes RUP Modeler, RUP Organizer, a RUP Library, and process guidance for process authoring.

release: A subset of the end product that is the object of evaluation at a milestone. A release is a stable, executable version of the product, together with any artifacts necessary to use this release, such as release notes or installation instructions. A release can be internal or external. An internal release is used only by the development organization, as part of a milestone or for a demonstration to users or customers. An external release (or delivery) is delivered to end users.

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 discipline: A core discipline 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: A definition of the behavior and responsibilities of an individual or a set of individuals working together as a team.

RPW: See [Rational Process Workbench]

RUP Base: A collection of RUP Process Components meant to be extended by applying plug-ins to generate RUP Process Configurations. It resides in a RUP Library.

RUP Builder: A tool within the RUP product used to create RUP Process Configurations out of a RUP Base and any number of RUP Plug-Ins.

RUP Exchange: A place on the Rational Developer Network where RUP Plug-Ins together with other process-related material are made available to the user community.

RUP Library: A collection of Process Components out of which a set of RUP Process Configurations may be compiled with RUP Builder. New process components can be added to a RUP Library through the means of RUP Plug-Ins.

RUP Modeler: A component of Rational Process Workbench. It allows a process engineer to visually model process elements such as activities, artifacts, roles, disciplines, and tool mentors, and their relationships; assemble them into RUP Process Components; and compile them into RUP Plug-Ins. RUP Modeler is an add-in to Rational XDE and works in conjunction with RUP Organizer.

RUP Organizer: A component of Rational Process Workbench. It allows you to associate content files with process elements such as activities, artifacts, roles, disciplines, and tool mentors and to compile these RUP Process Components to create a RUP Plug-In with the new or modified files. The files can be examples, guidelines, or reusable assets. RUP Organizer also allows you to modify Extended Help.

scenario: A described use-case instance or 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.

step: A subset of an activity. Not all steps needs to be performed each time an activity is invoked.

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 discipline in the software engineering process whose purpose is to integrate and test the system.

tool mentor: A description that provides practical guidance on how to perform specific process activities or steps using a specific software tool.

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

use case: 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: (obsolete) Renamed role starting with RUP 2000.

workflow: The sequence of activities performed in a business that produces a result of observable value to an individual actor of the business. Core workflows as containers of process descriptions were renamed disciplines starting with RUP 2000.