Back | |
|
Glossary of terms This glossary has been arranged so that you can select an item quickly and access the appropriate definition. It is incomplete and will be extended over time. |
|
|
|
|
|
A series of processes designed to carry out a specific task(s) - also called a program A group of operational activities to support a business function - Information engineering definition
|
|
Application framework |
An environment based on a number of industry standards (including Java technology, XML, ActiveX, HTML and CORBA)
|
|
|
A 1st generation computer language which 'assembles' machine code
|
|
|
Auxiliary elements |
Defines additional constructs that extend the Core to support advanced concepts such as dependencies, templates, physical structures and view elements
|
|
|
|
|
An obstacle that stands in the way of progress
|
|
|
A high level activity which supports a number of information requirements An activity which supports a functional area - Information engineering definition
|
|
|
A grouping of things/artifacts/phenomenon that an organisation requires in order to operate effectively
|
|
|
|
|
|
An object oriented computer language based on C (a 2nd Generation computer language) which generates assembler code.
|
|
|
Computer assisted software environment/engineering
|
|
|
Computer assisted strategic planning and reasoning engine
|
|
Specifies a behavioral context for using model elements to accomplish a particular task
|
||
Specifies the core concepts required for behavioral elements.
|
||
|
Difficult to understand due to intricacy
|
|
|
Complex evolving object |
Any 'thing' whose end result(s) or goal(s) is/are indeterminable as they tend to change rapidly from one moment to the next
|
Core |
According to the UML approach the core specifies the basic concepts required for an elementary meta-model and defines an architectural backbone for attaching additional language constructs, such as meta-classes, meta-associations, and meta-attributes The heart or innermost and most essential part of anything (especially business functions and systems)
|
|
|
CSF |
Critical success factor - an important issue which provides a positive outcome
|
|
|
|
|
A graphical or textual description of the inter relationship and dependencies of facts of an Organisation's requirements.
|
|
Defines basic data structures for the language
|
||
|
Data Warehousing enables Users to extract and "granulise" their data requirements. These extracts are then placed in "yet another data base", thus requiring more disk space. A major problem is keeping the Data Warehouses synchronised with the operational data. Questions such as "what happens when a client's balance or address etc change?". A number of "data warehouse experts" agree that without a comprehensive Organisation wide Data Model, Data Warehousing will be just another expensive failure!
|
|
DBMS |
Data base management system - the physical technology driving the data base
|
|
|
|
|
Enterprise out |
These are applications that run in proprietary products (black box technology)
|
|
Entity |
A class of object with attributes that defines the knowledge component of the business requirements
|
|
|
To open and expand
|
|
Specifies how model elements are customized and extended with new semantics
|
||
|
|
|
Facet |
A grouping of Entities and their relationships to support a subject area
|
|
|
Functional Area |
A region, sector or zone of the Business
|
|
|
|
|
Any breach or misunderstanding between two or more parties
|
|
|
An objective. Ripose describes goals in a 1-4-11 structure. One purpose, 4 missions and 11 critical success factors (CSF)
|
|
|
|
|
|
A means of storing data in the form of a well structured chart (similar to an Organisation Chart). The problem with hierarchies is that it was virtually impossible to simply relate an element (or node) within the one hierarchy, to an element (or node) in another hierarchy. Hierarchical data basses required very special and complex programs to enable one to traverse, add nodes to and delete nodes from the "tree" like structures.
|
|
|
|
|
|
|
|
|
|
|
JAD |
Joint application development modeling = Develops the proof of logical
|
|
|
A Procedural language (not unlike C and C++) designed to be able to be deployed on various platforms (eg Intel, Macintosh, Sun) and run under various operating systems (Windows, Mac/Os, Sun/Os). The run time module is built into the numerous browsers available on the market today. The applications (or applets as they are better known as) resides on the host computer (or server) and are down loaded to the client computer. The code is then run on the client computer. The theory behind Java is that the applets are coded only once and can be run on multiple hardware and software platforms.
|
|
JEM |
Joint enterprise modeling - Develops the organisation's goals
|
|
|
JURM |
Joint user requirements modeling - Develops the organisation's proof of concept
|
|
|
|
KPI |
Any important pointer, gauge, measure or component which assists in the fulfillment of a task
|
|
|
|
|
|
Logical |
The means of describing reasoning. The advantage of a logical meta-model is that it emphasizes declarative semantics, and suppresses implementation details. The disadvantage of a logical model is that it lacks the imperative semantics required for accurate and efficient implementation. Consequently, the meta-model is accompanied with implementation notes for tool builders.
|
|
|
|
|
A low level language that a computer uses in order to carry out instructions.
|
|
Methodology |
A methodology is a documented set of formal procedures, rules and/or guidelines for a specific discipline. Depending on the nature of the task, the needs of the audience and the intentions of the authors, a methodology can be written at a detailed level (presenting step-by-step explanations of how to accomplish a process). It can also be at a general level (offering only suggestions and guidelines to support someone that already understands the basic steps of the process).
|
|
Missions |
An assignment that is undertaken to fulfil a purpose
|
|
Specifies how model elements are organized into models, packages and systems
|
||
|
|
|
|
Something having material existence
|
|
|
To understand Object Orientation Techniques one has to understand that every thing in life can be reduced to a thing (or an object). Hence a Field (example "customer name") on a Report (Customer List) is an object. The Report (Customer List) is itself an Object, made up of many other Objects. Etc.
|
|
Object-oriented analysis and design |
"An attempt to achieve mass reusability of object classes." It helps practitioners "model the world in terms of objects that have properties and behavior, as well as events that trigger operations that change the state of the objects" - Principles of object-oriented analysis and design - James Martin 1993
|
|
|
|
|
Pattern |
A design, figure or style corresponding in outlining to an object that is to be fabricated and serving as a guide for determining its shape and dimension
|
|
Physical framework |
The hardware, software and network environment
|
|
Program |
A series of instructions to create, read, update, delete and print the contents of the physical data bases A name given to a grouping of projects
|
|
Projects |
A grouping of operational activities (see system)
|
|
|
Prolog was developed at the University of Marseilles, France by Alain Colmerauer in the early 1970s as a tool for PROgramming in LOGic. It supposedly allows the programmer to model the logical relationships among objects and processes, complex problems are inherently easier to solve, and the resulting program is easier to maintain through its life-cycle.
|
|
Proof of concept |
High level specifications, describing the integrated functionality of a series of business ideas. It details 'what' the business needs and is independent of detailed logic. It provides a clear priority blueprint for future development - steps 1 through 3 of the Ripose Technique
|
|
Proof of logic |
Detailed specifications describing the data structures and program reasoning. It is totally independent of hardware and software constraints. It fully supports the proof of concept and shows 'how' the proof of concept can be implemented - step 4 of the Ripose Technique
|
|
Proof of physical |
A prototype/working model of the proof of logic. It enables business operatives to 'touch, feel and experience' objects identified in the proof of concept. It is independent of the final target hardware and software environment - step 5 of the Ripose Technique
|
|
Purpose |
The major reason for doing something or existing
|
|
|
|
|
|
|
|
|
|
|
RAD |
Rapid application modeling - Develops prototypes
|
|
|
A general-purpose series of modeling techniques designed to specify, visualize, construct and document the artifacts of a business from an idea to the detailed logic. It is an acronym for 'Rapid information processing oriented systems environment'. Ripose rapidly integrates prototypes of strategic elements. Ripose was designed to minimise effort (by improving efficiency and reducing redundancies) and maximise productivity (by using an improved set of tools)
|
|
Run time |
Provides the capability of executing an application on a number of platforms
|
|
|
|
|
|
Structured Query Language was developed in the late 1970's to overcome problems associated with hierarchical data bases. It is a means of interrogating relational files rather than hierarchical files.
|
|
Defines behavior using finite-state transition systems
|
||
Subject area |
A grouping of 'Facets'
|
|
SWOT |
Analysis of strengths, weaknesses, opportunities and threats
|
|
System |
A group of operational activities to support a business function A name given to a grouping of applications
|
|
|
|
|
Topology |
A high level abstraction giving insight into the detail
|
|
|
The process or result of changing from one form to another
|
|
|
|
|
|
UML |
A general-purpose visual modeling language that is designed to specify, visualize, construct and document the artifacts of a software system
|
Specifies behavior using actors and use cases. A use case is a sequence of transactions that yields a measurable result of value. A system will contain a collection of use cases. Ref Jacobson I., Christerson M., Jonsson P., Overgaard G. Object-Oriented Software Engineering - A Use Case Driven Approach. Addison Wesley - ACM Press. 1992
|
||
|
|
|
|
|
|
|
Web-up |
Addresses applications that run in an application called a 'browser' and accesses data bases
|