| A |
|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| |
| Abstract |
1. adj. property of a model element which prevents it from being instantiated, commonly applied to a class - 2. v. to create a view of some aspect of a whole |
| Abstract Class |
n. class which has no direct instance |
| Abstraction |
n. reduction of an artefact to its contextually essential elements, the view thus created |
| Action |
n. operation to be performed on the occurrence of a transition between states on a statechart |
| Activation |
n. symbol on the lifeline of an object in a sequence diagram that indicates the period during which an operation is active |
| Active Verb |
n. verb which demands action |
| Activity |
1. n. a node on an activity diagram which defines procedure or part thereof - 2. n. property of a state (statechart) which define a procedure that is active while in that state |
| Activity Diagram |
n. diagram defining the order in which activities are performed |
| Actor |
n. role of an object outside the system being modelled that interacts with the system |
| Adornment |
n. property of a model element, often visible on a diagram |
| Aggregation |
n. adornment of the end of an association (association role) that indicates containment, visible on a diagram as a diamond shape |
| Alias |
n. model element that duplicates another model element |
| Alternate Flow |
n. use case flow which defines an alternative to another use case flow, often use to handle exceptions |
| Ambiguous |
adj. interpretable in more than one way |
| Analysis |
1. n. process of defining all aspects of the system that are not to be changed - 2 n. the product of such a process |
| Analysis Pattern |
n. example of a model construct often encountered during analysis |
| Analyst |
n. role of a person who performs analysis |
| Anchor |
n. link between a diagram note and the occurrence of a model element on a diagram |
| Architecture |
See 'System Architecture' |
| Architectural Layer |
n. arbitrary partition of the top level of the logical view using packages |
| Architectural Pattern |
n. example model of a common way of implementing a particular detail of software technology |
| Association |
n. structural relationship between classifiers, e.g. used on class diagrams to indicate potential references between the objects of classes |
| Association Class |
n. class that has an instance for each link between the objects of two other class, used in analysis to represent a mapping class |
| Association Name |
n. property of an association describing the semantics of the association |
| 'As Is' Model |
n. business model describing the current business process and business structure |
| Attribute |
n. data member of a class |
| Attribute Type |
n. normally primitive type of an attribute, can also be defined by a class |
| Attribute Visibility |
n. accessibility of an attribute from outside of the class |
| B |
|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| |
| Basic Flow |
n. main flow of a use case describing the normal course of events |
| Bi-Directional Association |
n. association with references in both directions |
| Binary Association |
n. association with two ends (roles), shown as a solid line between classifiers on a diagram |
| Black Box |
n. used as adj. system whose internal functionality is only visible via interactions across its boundary |
| Business Actor |
n. role of an object outside the business or part of the business being modelled |
| Business Analysis |
n. process of creating a model of the business |
| Business Analyst |
n. role of a person who performs business analysis |
| Business Attribute |
n. attribute of business data entity |
| Business Data Model |
n. model of the information recorded within the business |
| Business Domain |
n. concepts and facts associated with the business rather than any particular computer system |
| Business Event |
n. event that occurs within the business, often described as a condition on control flow on an activity diagram |
| Business Outcome |
n. result of an activity within the business, often modelled as a condition on control flow on an activity diagram |
| Business Model |
n. model of a business or part of one or more businesses |
| Business Process |
n. procedure by which a business fulfils its goals |
| Business Process Improvement |
n. incremental procedure by which a business process is improved |
| Business Process Model |
n. part of a business model that describes business process |
| Business Process Re-engineering |
n. radical re-structuring of a business along the lines of the flow of work that produces value for the customer |
| Business Relationship |
n. normally a association between business data entities in business data model |
| Business Requirements |
n. requirements of the business for the business, not of the business for a computer system which are 'System Requirements' |
| Business Rules |
n. succinct declarative statements of business constraints, computations or actions |
| Business Step |
n. one part of a primitive business process described on an activity diagram with an activity |
| Business Structure |
n. organisation of a business by organisation unit e.g. department, division, and the roles that people take on within those units |
| Business Structure Model |
n. model of business structure within a business model |
| Business Trigger |
n. business event that causes a use case to start |
| Business Use Case |
n. business process modelled as a use case on a use case diagram |
| Business Use Case Diagram |
n. diagram containing business actors, business use cases and their relationships |
| Business Worker |
n. role taken on by a person working in a business |
| Business Worker Relationship |
n. relationship between business workers modelled on a class diagram |
| Business Worker Responsibilities |
n. collection of primitive business processes carried out by a business worker and modelled as operations on the business worker class |
| C |
|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| |
| Canonical Representation |
n. presentation of a model element on a diagram using the normal symbol |
| Change |
n. unit of system development work of less than two weeks in length that produces increased or changed functionality to the system |
| Change Log |
n. written record of changes made to a document in the document |
| Change Request |
n. request from a stakeholder for a change to the functionality of the system |
| Child |
n. subservient part of parent-child relationship between model elements and/or diagrams |
| Child Diagram |
n. diagram associated with a model element (the parent) that appears on another diagram |
| Class |
n. definition of the properties of one or more objects |
| Class Attribute |
n. definition of a data property of one or more objects |
| Class Instance |
n. data space associated with the class rather than the object of the class such that the value of attributes held there is the same for all objects of the class, see 'Class Scope' and 'Static Member' |
| Class Scope |
n. property of a property of a class which defines that it can be accessed on the class instance rather than on the object of the class |
| Classifier |
n. model element superclass of various model elements in the UML meta-model that define the properties of instances in the model |
| Client-Server |
n. master-slave relationship between two elements with uni-directional dependency |
| Code |
n. model of computer software at anywhere between 'high-level' language and machine code levels |
| Coding |
n. stage of the software development process that produces code |
| Column |
n. property of a table, usually in a relational database defining a primitive member of a set of data record |
| Collaboration |
n. model element representing a collection of model elements which collaborate in order to implement some functionality |
| Collection |
n. group of objects, or references to objects, of the same class |
| Collection Class |
n. class defining a collection |
| Common Process |
n. group level or primitive level process that is common across and modelled separately from hi-level or group level processes respectively |
| Complete |
n. property of a generalisation which indicates that the generalisation hierarchy may not be extended horizontally or vertically downwards |
| Component |
n. piece of code that runs, usually inside an operating system process |
| Component Diagram |
n. diagram of components, component interfaces and their relationships |
| Component Test |
n. procedure by which the conformance of a component to the specification defined by one of its interfaces is checked |
| Component View |
n. part of the system model defining components, component interfaces and their relationships |
| Composition |
n. adornment of the end of an association (association role) that indicates physical containment, visible on a diagram as a solid diamond shape |
| Complex Attribute |
n. attribute containing complex data defined by a class |
| Complex Hierarchy |
n. hierarchy in which some or all nodes have more than one parent |
| Component Test |
n. test for a component executed via its interfaces |
| Composite State |
n. state in a statechart containing sub-states and regions |
| Computation |
n. type of business rule defining an algorithm or calculation |
| Conceptual Data Model |
n. Business Data Model showing business terms (entities) and facts (relationships) |
| Concrete |
adj. property of a model element which allows it to be instantiated, commonly applied to a class |
| Concurrent Activities |
n. activities which may run at the same time |
| Concurrent States |
n. states in which an object may exist at the same time |
| Condition |
n. statement which evaluates to true or false |
| Consensus |
n. common understanding whereby all participants accept a decision whether they agree with it or not |
| Constraint |
1. n. non-functional requirement of the system - 2. n. property of a model element defining limits - 3. n. type of business rule defining limits |
| Contiguous |
adj. connecting without a break |
| Control Class |
n. class defining mostly dynamic behaviour rather than data properties or interface behaviour |
| Control Flow |
n. relationship between nodes on an activity diagram which defines the order of execution |
| Control Object |
n. instance of a control class |
| Control Relationship |
n. uni-directional client-server relationship allowing model element to control another, often between classes |
| Configuration |
See 'Process Configuration' and 'Project Configuration' |
| Cost Value |
n. variable containing the proportional value of estimation elements |
| Cyclic Dependency |
n. relationship between model elements whereby each depends on the other |
| D |
|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| |
| Data |
n. factual information in a form suitable for processing by a computer or for use in making decisions |
| Database |
n. persistent store of information |
| Data Action |
n. type of business rule defining the processing of data |
| Data Dictionary |
n. requirements document or model of the information to be stored in the system |
| Data Entity |
n. object or record whose primary purpose is the storage of information |
| Data Entity Class |
n. class defining one or more data entities |
| Data Entity Object |
n. instance of a data entity class |
| Data Member |
n. data property of a object or class |
| Data Model |
n. model of information to be held, or to be held, in a business, system or database |
| Data Relationship |
n. bi-directional relationship between data elements held as part of a data model, often between classes or data tables |
| Data Return |
n. result of execution of an operation |
| Decision |
n. node on an activity diagram defining exclusive alternate control flows |
| Deliverable |
n. product of the completion of a software development project or increment |
| Dependency |
n. relationship between model elements noting the use of one model element by another |
| Deployment Diagram |
n. diagram of processors, devices and communication path instances upon and over which the software will operate |
| Deployment View |
n. part of the system model defining processors, devices and communication paths |
| Derived Attribute |
n. attribute whose value is calculated from other attributes |
| Derived Data |
n. data whose value is calculated from other data |
| Design |
see 'System Design' |
| Design Pattern |
n. example of a model construct previously successfully used to solve a particular design problem |
| Developer |
n. role of a person who performs software development |
| Development |
see 'Software Development' |
| Development Phase |
n. phase of the software development process during which a stable architecture for the system is developed |
| Diagram |
n. two-dimensional graphical representation of a related set of model elements, a view of one part of a model |
| Directed Association |
n. association with a reference in one direction only, also 'Uni-Directional Association' |
| Discriminator |
n. property of a generalisation which defines the basis for discrimination between sub-classes |
| Disjoint |
1. n. property of a generalisation which forbids multiple inheritance between sub-classes - 2. adj. non-overlapping |
| Document |
n. linear product of a task, substantially in written form |
| Documentation Field |
n. ASCII text string property of a model element for the purpose of adding comments |
| Domain |
n. area of relevant concern or responsibility, e.g. problem domain, business domain, solution domain |
| Dynamic Behaviour |
See State Dependent Behaviour |
| Dynamic Model |
See State Model |
| E |
|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| |
| Element |
n. one part of a whole |
| Engineering Increment |
n. increment that will not go live in its target environment |
| Entity |
n. object or record whose primary purpose is the storage of information |
| Entity Class |
n. class defining one or more entities |
| Enumerated Type |
n. user-defined type with a limited number of specific values |
| Estimation Element |
n. metric for use in the estimation model, e.g. the number of lines in a use case description |
| Estimation Model |
n. mathematical calculation used to produce an estimate |
| Event |
n. something that happens at a particular point in time |
| Event/Action Block |
n. specification of a transition between or within states, includes an event, optional condition and nought or more actions |
| Exception |
n. occurrence of an unwelcome event |
| Exception Table |
See 'Screen Entry Exception Table' |
| Execute Action |
n. type of business rule which executes a process when an event occurs or a condition is satisfied |
| Executable |
n. component in machine code that is ready to be run |
| Extend Relationship |
n. relationship between use cases which defines one to be an extension of another, modelled as a dependency with the stereotype 'extend' |
| Extensibility |
n. measure of how easy it is to extend the functionality of a system |
| External Development |
n. software development performed outside of the organisation running the project |
| External Increment |
n. increment that will go live in its target environment |
| F |
|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| |
| Facade |
n. object that presents a view of the functionality of a subsystem |
| Facade Class |
n. class of a facade |
| Fact |
n. relationship in the conceptual data model describing a truth about the business |
| Final Node |
n. node on an activity or state diagram denoting the completion of activity or the destruction of an object respectively |
| Flow |
1. n. sequence of events - 2. n. connection between nodes on a diagram |
| Flowchart |
n. common name for an activity diagram |
| Flow of Control |
n. the order in which activities are performed on an activity diagram |
| Foreign Key |
n. unique key property of an entity in a relational database that belongs to another entity and implements a relationship with it |
| Fork |
n. node on an activity diagram that splits the flow of control so that activities can be performed concurrently |
| Framework |
n. software structure that implements a specific aspect of technology |
| Functional Requirement |
n. element of system specification that defines an aspect of what the system will do |
| Function Point |
n. arbitrary unit of functional complexity used in estimation |
| G |
|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| |
| Generalisation |
n. classifier in a generalisation hierarchy that defines common semantics, usually a superclass defining common attributes and operations |
| Generalisation Relationship |
n. relationship between classifiers which defines a one classifier to be a generalization of another, an 'is a' style relationship usually between classes |
| Global Dependency |
n. dependency of class upon a global variable |
| Global Visibility |
n. property of a model element which defines it to be accessible from all parts of the model |
| Glossary |
n. list of specialised words or phrases together with their definitions |
| Glossary Term |
n. entry in a glossary |
| Group Level Process |
n. process that is the parent of a collection of primitive processes and the child of a hi-level or another group level process |
| Guard Condition |
n. condition on a transition in a statechart |
| Guidelines |
See 'Task Guidelines' |
| H |
|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| |
| Hardware |
n. computer and associated physical equipment directly involved in the performance of data-processing, control or communications functions |
| Hi-Level Process |
n. top level business process that produces a revenue stream for the organisation |
| Hierarchy |
n. structure consisting of parent child relationships between nodes |
| Hierarchic State |
n. state with sub-states which inherit the behaviour of their parent |
| Historical Data |
n. estimation metrics derived from prior developments |
| History Symbol |
n. node inside a hierarchic or composite state representing the stored history of sub-states |
| Hurrys |
n. fictional retailer of electrical goods used in examples |
| I |
|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| |
| Iconic Representation |
n. graphical symbol associated with a stereotype |
| Implement |
v. produce a solution which provides the answer to a problem |
| Implementation |
n. solution at code or model level to a problem defined by a model, see also 'Realisation' |
| Include Relationship |
n. relationship between use cases which defines one to logically, but not physically, include another, modelled as a dependency with the stereotype 'include' |
| Incomplete |
n. property of a generalisation which indicates that the generalisation hierarchy may be extended either horizontally or vertically downwards |
| Increment |
n. one pass through all process stages which produces properly engineering, tested software |
| Infrastructure |
n. computing environment in which the software will run |
| Inheritance |
n. mechanism by which the specification and implementation of functionality and data is shared among model elements, usually classes |
| Initial Class List |
n. list of nouns annotated to define which will become the names of classes |
| Initial Node |
n. node on an activity or state diagram denoting the start of activity or the creation of an object respectively |
| Inputs |
n. source material, information or events used by a development task or business process |
| Installation |
n. the process of installing the software on the system infrastructure and making it run as designed |
| Instance |
n. an occurrence of a classifier, usually an object |
| Instance Name |
n. property of an instance which distinguishes it from another instance |
| Instance Scope |
n. property of an attribute or operation which defines its location to be with the instance |
| Instantiate |
v. create an instance of a model element e.g. create an object according to the definition provided by its class |
| Interface |
n. abstract class with the stereotype 'interface' which defines pure functionality but no implementation |
| Internal Development |
n. software development performed inside the organisation running the project |
| Internal Exception |
n. system error |
| Internal Increment |
n. increment that will not go live in its target environment |
| Interface Element |
n. object on the user interface |
| Interface Implementation |
n. model of how the functionality defined by a subsystem interface will be implemented inside the subsystem, mostly sequence diagrams |
| Interaction |
n. message sent from a specific source to a specific target |
| Iteration |
n. repetition of the whole or part of a procedure |
| Iteration Condition |
n. condition which specifies the criteria for the exit from an iteration |
| J |
|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| |
| Join |
n. node on an activity diagram that synchronises flow of control of concurrent activities |
| K |
|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| |
| Keyword |
n. word with strongly defined semantics, used in a business rule |
| Key |
n. data element used to identify a record in a table in a relational database |
| Key Feature |
n. high level requirement defined in the project overview document |
| L |
|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| |
| Layer |
n. top-level package in the object model with the stereotype 'layer' |
| Layered Architecture |
n. decomposition of the object model into layers |
| Library |
n. collection of model or code elements or patterns designed for reuse |
| Lifeline |
See 'Object Lifeline' |
| Line Management Relationship |
n. relationship between business workers indicating the management of one business worker by another |
| Link |
n. reference between objects that exists as an instance of an association |
| Legacy System |
n. existing system to which the new system will be connected or which will be changed as part of the current project |
| Local Dependency |
n. dependency resulting from the creation of a local object |
| Local Object |
n. temporary object created inside the address space of an operation |
| Local Variable |
n. temporary variable created inside the address space of an operation |
| Logical Data Model |
n. implementation free model of the information that will be held persistently inside the system |
| M |
|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| |
| Maintainability |
n. measure of how easy it is to maintain system |
| Many-to-Many Relationship |
n. relationship connecting one or two classes or tables in which each instance or record at either end of the relationship can be connected to many instances or records at the other end |
| Mandatory |
adj. required |
| Mapping Table |
n. table in a relational schema that implements a many-to-many relationship |
| Merge |
n. node on an activity diagram combining control flows without synchronising them |
| Message |
n. command, optionally with data parameters, or data sent as part of an interaction |
| Meta-Model |
n. a model of a model |
| Method |
n. hidden implementation of an operation |
| Metric |
n. measurement |
| Mitigate |
v. reduce to an inconsequential level |
| Model |
n. multi-dimensional abstraction of a business or system, or part thereof, resulting from the execution of a task |
| Model Element |
n. instance of a construct available in a modelling language |
| Multiple Inheritance |
n. inheritance from multiple model elements |
| Multiplicity |
n. constraint property of an association role defining the relative quantity of instances across the relationship over the lifetime of the objects at each end, known as 'cardinality' in traditional entity models |
| N |
|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| |
| Non-Functional Requirement |
n. constraint on the implementation of one or more functional requirements |
| Node |
1. n. model element connected by one or more relationships to other model elements - 2. n. model element in the deployment model representing a processor or device |
| Normalisation |
n. procedure that breaks down data into record groups for efficient processing and storage, reducing the duplication of data elements to zero |
| Note |
n. diagram adornment for the purpose of presenting text |
| Noun |
n. a word that can serve as the subject or object of a verb |
| O |
|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| |
| Object |
n. unique identifiable instance of a class that holds data |
| Object Lifeline |
n. graphical representation on a sequence diagram of an the existence of an object |
| Object Lifetime |
n. period from the creation to the destruction of an object |
| Object Model |
n. model of the objects in a system consisting of classes, packages, relationships and class diagrams |
| Object Oriented |
adj. performed or constructed on the premise that all things can be expressed in terms of objects, relationships and their properties |
| One-to-Many Relationship |
n. relationship connecting two classes or tables in which each instance or record at one end only of the relationship can be connected to many instances or records at the other end |
| Operation |
n. class property defining the signature and semantics of an allowable function |
| Operation Name |
n. operation identifier |
| Operation Description |
n. textual definition of the semantics of an operation held in the textual notes or documentation field of the operation |
| Operation Signature |
n. sum of the operation name, parameter names, parameter types, return type and their related properties of the operation |
| Operational Relationship |
n. relationship between business workers defining a lines of communication needed to implement part of all of a business process |
| Organisation Structure |
See 'Business Structure' |
| Organisation Unit |
n. package in the business structure model with the stereotype 'organisation unit' |
| Orthogonal |
adj. non-overlapping, at right angles |
| Outputs |
n. material, information or events created or updated as the product of a development task or business process |
| Overriding |
n. redefining in a sub-class a property of a superclass |
| P |
|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| |
| Package |
n. model element for containing an non-overlapping set of model elements and diagrams |
| Package Dependency |
n. dependency between packages indicating dependency between their contents |
| Package Diagram |
n. diagram showing packages and their dependencies |
| Parent |
n. superservient part of parent-child relationship between model elements and/or diagrams |
| Paradigm |
n. set of assumptions, concepts, values, and practices that constitutes a way of viewing reality for the community that shares them |
| Parameter |
n. data value passed as part of a call to an operation |
| Parameterised Class |
n. incomplete class requiring the supply of parameter values to become complete |
| Parametric Dependency |
n. dependency upon the type of the parameters in an operation signature |
| Parent Activity |
n. activity which owns an activity diagram as a child |
| Passive Actor |
n. an actor involved in a use case but not starting it |
| Pattern |
n. example of a model construct previously successfully used |
| Pedant |
n. annoying person who insists on defining everything in great detail |
| Persistent Data |
n. data that will be retained even if the power fails |
| Phase |
n. collection of increments with a goal used as part of project planning |
| Physical Data Model |
n. model of how data will be stored in a relational database |
| Pointer |
n. identifier that indicates the location of a data item, object or function |
| Polymorphism |
n. the ability to specify an operation which responds differently depending on the class of the target object |
| Post-Condition |
n. relevant state of the system on the completion of a use case |
| Pre-Condition |
n. condition which must be true for a use case to begin |
| Presentation Action |
n. type of business rule which defines the way in which something must be presented to a business worker |
| Primary Success Scenario |
n. alternative name for a basic flow |
| Primitive Attribute |
n. attribute incapable of further decomposition |
| Primitive Process |
n. procedure by which one person does several things over a short contiguous period of time |
| Primitive Type |
n. type incapable of further decomposition |
| Private |
adj. invisible from outside of its container |
| Problem Domain |
n. area of concern relating to defining what a computer system will do rather than how it will do it |
| Problem Statement |
n. short succinct statement at the start of the project overview document describing what business problem is to be addressed by the project |
| Process |
1. procedure by which a goal is achieved - 2. protected address space provided by an operating system to one or more component instances |
| Process Configuration |
n. customisation of the software development process by defining which tasks will be performed and which not performed and adding or modifying tasks to fit a particular project |
| Process Flow |
n. the order in which processes are performed |
| Process Owner |
n. person responsible for defining the business process |
| Production Phase |
n. phase of the software development process producing working tested software that covers all the functionality defined in the system requirements |
| Project |
n. extensive undertaking by one or more people to achieve a goal |
| Project Assessment |
n. evaluation of the progress of the project based on the task assessments |
| Project Configuration |
n. choice of phases and increments defined in the project plan |
| Project Dependency |
n. dependency of the success of the project upon factors outside the control of those working on the project |
| Project Estimate |
n. expected cost and time to complete the project, product of the estimate project task |
| Project Failure |
n. going over budget, going over schedule or not providing the functionality defined by the requirements at the end of the scoping phase |
| Project Management |
n. stage of the software development process concerned with estimating, planning and assessing the progress of the project towards its goal |
| Project Overview |
n. document produced at the start of the project to set the goals and broad scope for the project |
| Project Plan |
n. document defining which members of the project team will perform which stages and tasks of the process upon which parts of the system under development and when they will do so |
| Project Role |
n. role of a person working on a project defined by the tasks that they will perform |
| Project Support |
n. software development process stage concerned with process configuration, version control, tool support, metrics gathering and project website management |
| Project Website |
n. central point of reference making a copy of the latest version of every project document and model easily available to all team members |
| Proof of Concept Prototype |
n. rough visualisation of a user interface, not a working piece of software |
| Prose |
n. text in a natural language e.g. English |
| Protected |
adj. visible from inside its containing and to subclasses |
| Public |
adj. visible from outside of its container |
| Q |
|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| |
| R |
|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| |
| Realisation |
n. model of a solution to a problem, can be represented on a diagram by a collaboration |
| Realisation Relationship |
n. relationship between model elements in which a concrete model element implements functionality defined by an abstract model element |
| Recursive Aggregate |
n. commonly occurring pattern which produces either a simple or a complex hierarchy of similar objects |
| Reference |
n. unique identifier of an instance of a model element, often an object |
| Reference System |
n. source of historical data used in estimation |
| Reflexive Association |
n. association attached to the same class at both roles |
| Region |
n. division within a composite state |
| Regression Test |
n. reduced test used check that previously developed and tested functionality still works |
| Relationship |
n. model element defining a connection between other model elements, seen on a diagram as a flow connecting nodes |
| Relational Database |
n. database which stores information across multiple tables indexed by keys and connected together by referring to the keys of other tables |
| Requirement |
n. some aspect of the system that may not be changed |
| Requirements Decision Making Board |
n. collection of stakeholder representatives who decide development priorities |
| Requirements Gathering |
n. the process of gathering requirements from stakeholders and creating an outside-in black box definition of required system functionality and constraints |
| Return Type |
n. type of the data returned when an operation completes |
| Re-use |
n. organisation of model elements, models and code such that one part can be used in multiple locations by reference and without duplication |
| Reusability |
n. measure of how easy it is to re-use the elements of a system |
| Reverse Engineering |
n. abstraction of a higher level model from a lower level model |
| Risk |
n. anything that might cause a project to fail, see 'Project Failure' |
| Risk Avoidance |
n. re-arranging the project so the risk no longer exists |
| Risk List |
n. project management model for the purpose of risk management |
| Risk Mitigation |
n. action taken to reduce the risk |
| Risk Transfer |
n. re-arranging the project so that some person, organisation or department outside of the project domain bears the risk |
| Role |
1. n. one end of an association - 2. n. Collection of responsibilities that can be allocated to an person or artefact |
| Role Name |
n. property of an association role describing the role of the object in its relationship with the object at the other end of the association |
| Roll-down Superclasses |
v. merge two adjacent levels of a generalisation hierarchy by duplicating the properties of the superclass in the sub-classes |
| Rollout |
n. phase and stage of the software development process in which the software is prepared for the users and the users for the software such that the users accept the software |
| Rollup Subclasses |
v. merge two adjacent levels of a generalisation hierarchy by duplicating moving the properties of the all the sub-classes into the superclass |
| S |
|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| |
| Scalability |
n. measure of how easy it is to increase the scale of the system, usually by decomposing the components to run on more tiers in a multi-tier client-server environment and add more clients |
| Scenario |
n. one path through a use case |
| Schema |
n. diagrammatic representation or model |
| Scope |
1. n. area in which something acts or operates or has power or control 2. n. property of a model element defining visibility from outside of its container |
| Scoping |
n. phase in the software development phase whose goal is to estimate and plan the project based an agreed scope for the system development |
| Screen Entry Exception Table |
n. table defining the system response to simple data entry errors at the user interface |
| Shared Aggregation |
n. aggregation with a multiplicity greater than one at the same end of the association as the aggregation |
| Simple Hierarchy |
n. hierarchy in which each node has only one parent or none |
| Simple State |
n. state that does not decompose into sub-states |
| Semantics |
n. meaning of things |
| Sequence Diagram |
n. diagram showing interactions between objects in the order in which they will occur |
| Software |
n. programs, routines, components and symbolic languages that control the functioning of the system hardware and direct its operation |
| Software Development |
n. the evolution of a set of system requirements into working, tested software |
| Solution Statement |
n. short succinct statement at the start of the project overview document describing how the system to be developed will address the business problem defined in the problem statement |
| Source Code |
n. computer code written in a programming language |
| Specialisation |
n. sub-class derived from a superclass with a generalisation relationship |
| Specification |
n. definition of requirements |
| SQL |
n. Structured Query Language, specialised language for interrogating and manipulating a relational database |
| Stable |
adj. unchanging |
| Stage |
n. collection of tasks in the software development process performed once per increment in an incremental process and once only in a waterfall process, generally relates to a role or discipline taken on by a team member |
| Stakeholder |
n. person affected by the software development |
| Stakeholder Meeting |
n. meeting of several stakeholder representatives or one-on-one meeting between an analyst and a stakeholder |
| Stakeholder Need |
n. one of the top three needs expressed by a stakeholder during a one-on-one stakeholder meeting |
| Stakeholder Needs List |
n. prioritised list of expressed stakeholder needs |
| Stakeholder Representative |
n. chosen to represent stakeholders of a particular type including users with specific problem domain experience |
| Stakeholder Type |
n. classification of a group of stakeholders with similar roles |
| State |
n. node on a statechart indicating a stable, passive state of objects of the parent class, product of the value of object attributes and links |
| State Dependent Behaviour |
n. behaviour of an instance that changes when the state of the instance changes |
| State Model |
n. sum of the model elements and diagrams defining the state dependent behaviour of the elements of a system |
| Statechart |
n. diagram containing model elements that define the state dependent behaviour of the instance of its parent classifier |
| Static Member |
n. property of a class that is held on the class instance rather than the object of the class such that its value is the same for all objects of the class |
| Static Structure |
n. the invariant arrangement of the model elements and their relationships as opposed to their behaviour |
| Status Variable |
n. enumerated type defining the current state of an object or record |
| Step |
n. element of procedure of a software development process task |
| Step Flow |
n. order in which steps are performed as part of a software development process task |
| Stereotype |
n. user-defined property of a model element extending its semantics |
| Structured Activity |
n. hierarchic activity owning child activities that may appear on a child activity diagram |
| Sub-machine State |
n. hierarchic state with sub-states that may appear on a child statechart |
| Sub-flow |
n. use case flow which can be invoked from anywhere in the use case description |
| Sub-type Relationship |
n. relationship used in the business data model to indicate that one business data entity is the sub-type of another |
| Substitution Principle |
n. principle which states that an object of a sub-class should always be capable of replacing the object of any of its superclasses without any detectable change in its externally visible behaviour |
| Subsystem |
n. design of a component or part of a component that realises one or more interfaces |
| Sub-class |
n. specialisation of a superclass in a generalisation relationship defining additional properties to those inherited from the superclass |
| Superclass |
n. generalisation of one or more sub-classes in a generalisation relationship defining properties common to all sub-classes |
| Swimlane |
n. partition in an activity diagram containing activities allocated to the role, a business worker in the business process model, defined by the name of the swimlane |
| Switch Action |
n. business rule that turns a process or another business rule on or off when an event occurs or a condition is satisfied |
| Synchronous Message |
n. message calling a function which returns a value |
| Synchronous Paradigm |
n. pattern for developing a sequence of messages that assumes that all messages will be either function calls or returns from function call |
| Syntax |
n. pattern of formation of a model or code from model or code elements |
| System |
1. n. in this software development process: the functionality defined by the system use cases 2. n. general: group of interacting, interrelated, or interdependent elements forming a complex whole |
| System Action |
n. function performed by the system which may or may not cross the system boundary |
| System Actor |
n. role of a person or system out side the system under development in terms of its interaction with the system, part of the system use case model |
| System Analysis |
n. stage in the software development process in which a detailed analysis of system requirements produces three orthogonal views which together define everything that the system will do |
| System Analyst |
n. role of a person performing system analysis |
| System Architecture |
1. n. structure of the system design defined by layers, sub-systems, interfaces, libraries, architectural patterns, component and deployment models - 2. n procedure by which such a structure is produced |
| System Boundary |
n. the extent of the system domain defined by the relationships between actors and use cases on a use case diagram |
| System Design |
n. development of the subsystems, interfaces, classes and relationships in preparation for the coding of components |
| System Interface |
n. object in the system model which enables interaction between a system actor and the system |
| System Interface Class |
n. class which defines a system interface |
| System Interface Object |
n. instance of a system interface class |
| System Level Exception |
n. event occurring in the problem domain which requires that the system perform some sequence of actions alternate to the normal sequence |
| System Model |
n. model of system functionality and/or implementation |
| System Requirements |
n. requirements of the business for a computer system |
| System Test |
n. procedure by which the conformance of the system to a part of the system specification is checked |
| T |
|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| |
| Table |
1. n. specification of a data record held in a relational database - 2. n. two dimensional presentation of related information using lines for separators |
| Tagged Value |
n. user definable property of a model element |
| Task |
n. piece of work carried out by a team member as part of a software development process stage, normally to develop a document or model - 2. n representation of a process or thread in a task model |
| Task Assessment |
n. the assessment of the quality of a document or model produced or changed by the performance of a task |
| Task Flow |
n. order in which tasks are performed as part of a software development process stage |
| Task Guidelines |
n. document describing best practise for a software development process task |
| Task Model |
n. model of processes and threads to be provided by the operating system and the model elements that will run within them |
| Technical Complexity Factor |
n. variable used in estimation to express the relative complexity of estimation elements |
| Term |
1. n. word or phrase - 2. entry in a dictionary or a glossary |
| Test |
n. procedure by which conformance to a specification is checked |
| Test Developer |
n. one who develops a test |
| Test Script |
n. document defining the procedure by which a test is to be conducted |
| Test Strategy |
n. approach to testing defining what types of test will be used and the mechanisms for implementing them |
| Testing |
n. stage in the software development process in which a test strategy is defined and tests are developed and performed |
| Template |
n. document or model defining the structure of a document or model to be developed by the performance of a task |
| Textual Note |
n. string property of a model element describing semantics or constraints of the model element |
| Thread |
1. n. contiguous flow of operation that can run independently of and concurrently with other threads |
| Tool |
n. software program used by a team member to aid the performance of a task |
| 'To Be' Model |
n. business model describing the intended business process and business structure |
| Traceability |
n. path of traces from a requirement to the elements of its implementation |
| Trace |
n. dependency relationship with a 'trace' stereotype connecting model elements from different models in order to show the dependency of one upon the other |
| Transition |
n. relationship between states indicating a possible change of state |
| Type |
n. model element classifier using one or more constructs available in a particular programming or modelling language |
| U |
|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| |
| UML |
n. Unified Modelling Language, language specification for the modelling of computer software maintained by the Object Management Group |
| Uni-Directional Association |
n. association with a reference in one direction only, also 'Directed Association' |
| Unique |
adj. without an equivalent within a particular domain |
| Unique Key |
n. sole data element required to identify a record in a table |
| Use Case |
n. procedure by which an actor interacts with a system in order to achieve a goal |
| Use Case Controller |
n. object used to control the overall flow of a use case implementation |
| Use Case Class Diagram |
n. class diagram showing all classes and relationships involved in the implementation of a use case |
| Use Case Diagram |
n. diagram showing an outside-in view of system functionality containing actors, use cases and relationships |
| Use Case Document |
n. system requirements document describing all the flows of a use case together with relevant constraints |
| Use Case Flow |
n. generalised description of one contiguous part of a use case |
| Use Case Implementation |
n. model of how the system will implement a particular use case |
| Use Case Model |
n. model of system functionality defined by actors, use cases, relationships, use case diagrams and use case documents |
| User |
n. person who uses the system |
| User Acceptance |
n. state in which the representatives of the proposed users of the system accept that it conforms to the system requirements |
| User Documentation |
n. description of all aspects of the system that need to be understood in order for the users of the system to use it successfully |
| User Representative |
n. person assigned to represent the concerns of the proposed users of the system |
| User Training |
n. training in all aspects of the system that need to be understood in order for the users of the system to use it successfully |
| V |
|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| |
| Verb |
n. word that expresses existence, action or occurrence |
| Version |
n. particular form or variation of an earlier or original type |
| Version Control |
n. management and maintenance of different versions of documents, models and code |
| View |
n. abstraction of an artefact seen from a particular position or angle, e.g. a diagram is a view of a model |
| Visibility |
n. accessibility of a model element from outside of its container |
| W |
|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| |
| Waterfall Process |
n. process in which all the work done in one stage must be completed before the next stage is begun |
| White Box |
n. used as adj. system whose internal functionality is visible other than just via interactions across its boundary |
| Workshop |
n. meeting in which model elements are developed |
| Wrapper |
n. class which obscures the technological implementation of an object, particularly used to refer to classes which hide the technology of persistence |
| X |
|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| |
| XMI |
n. XML-based metadata interchange format, model driven XML integration framework for defining, interchanging, manipulating and integrating XML data and objects |
| Y |
|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| |
| Z |
|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| |
