MORALE Glossary

General Terms

Architecture - 1
An organization of automated system components that meets the requirements for the automated system and the affordances provided by its environment.
Architecture - 2
a system description, including system components and how they interact.
Domain
a recognized problem area characterized by a vocabulary, typical solution strategy (architecture), and literature.
Legacy system
An existing software system that is determined by a customer to be in need of improvement.
Reengineering
"the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form." (Source: Chikofsky and Cross)
Scenario
An imagined set of concrete system behaviors in response to a state of affairs.

Requirements Terms

Allocated requirement
A requirement that has been allocated to a total system (usually, automated system) component.
Achievement goal
A goal that is described in terms of a desired state of affairs that does not yet hold.
Architect
A developer who is responsible for analyzing the requirements for the automated system, and proposing and analyzing a solution architecture or modifications to an existing architecture. (Note: This definition cuts across traditional distinctions between systems and software engineers and between analysts and software designers.)
Architectural scenario
A scenario in which the roles are users and automated system components.
Architectural script
A script for an architectural scenario.
Automated system
A system in which one or more components are devices, software configuration items or other automated systems.
Component
A part of a system. A component may be regarded as a system in its own right or as an atomic agent.
Context
Concrete aspects of the system's environment that affect its likely success.
Customer
A stakeholder who represents the organization that is intended to benefit most from the total system. (Note: the contractual client may not be a customer in this sense).
Description
The activity of representing and documenting some aspect of a system.
Developer
A stakeholder who is a member of an organization responsible for the development and evolution of the automated system.
Discussion
The activity of discussing, analyzing or reviewing a description.
Environment
The totality of things not in a system that interact with or influence it.
Goal
A desired purpose of a system or component.
Goal web
A description of a collection of goals and their dependencies.
Human-Activity System (HAS)
A system in which the components are people, teams or organizations. These system components may use automated tools to help them meet their goals, but the system does not contain such tools as principal components.
Inquiry Cycle
A collection of three kinds of activity involved in designing and planning a system, viz.: description, discussion and refinement.
Maintenance goal
A goal described in terms of a desired state of affairs that already holds.
Obstacle
A state of affairs that can impede the fulfilment of a goal.
Operational requirement
A requirement that has been allocated to a software component and that is described in enough detail to be implemented in source code.
Owner
A stakeholder who defines the success or otherwise of the total system and has the authority to cancel its development.
Putative architecture
An architecture put forward by an architect as a viable design to meet the mission-oriented requirements or as an explanatory structure for the source code of a legacy system.
Quality goal
A goal described in terms of a trajectory of improvement in some criterion.
Refinement
The revision of one or more descriptions as a result of discussion. Refinements include the creation of new descriptions that are either subordinate to existing descriptions or otherwise dependent on them.
Requirement
A property of an automated system needed by a customer stakeholder.
Script
A description of a scenario in which the component's actions are represented in time-ordered sequence.
Software requirement
A requirement that has been allocated to a software system or component.
Software system
A system that is to be implemented in software components.
Stakeholder
A person, group of people or with a stake in the success of the total system.
System
A collection of active components whose coordinated behavior meets a set of goals.
Target system
A system that is to be implemented in software and hardware components.
Mission-oriented scenario
A scenario in which the structure of the scenario is related to the goals of the system or components in question.
Mission-oriented script
A script for a mission-oriented scenario.
Total System
A large, complex system including one or more human- activity systems and one or more automated systems.
User
A stakeholder who is a member of a human-activity system in the environment of the automated system who directly interacts with the automated system. Direct interaction may take the form of operating a computer worksation, but could equally involve interaction with ubiquitous or embedded automated system components or the consumption of reports or other information digests generated by the automated system. A user may perform a collection of activities that have no direct counterpart in the human-activity system that exists prior to the implementation of the automated system.

Reverse Engineering Terms

Architectural style
"defines a family of architectures constrained by component/connector vocabulary, topology, semantic constraints. (Source: Garland and Shaw tutorial)
Cliche (French)
a pattern describing salient features of a concept that supports recognition of that concept in some specified context by application of some specified comparison algorithm.
Cliche (as far as the Programmer's Apprentice is concerned)
a collection of related features or characteristics that provide a shared technical vocabulary, including inter-feature relationships.
Concept hierarchy
a hierarchically organized collection of domain concepts. The organizing relationship is "part-of".
Conceptual purpose token
a domain concept identifier
Delocalized plan
"pieces of code that are conceptually related [that] are physically located in non-contiguous parts of a program." (Source: Soloway, et al. CACM 11/88)
Design recovery
"a subject of reverse engineering in which domain knowledge, external information, and deduction or fuzzy reasoning are added to the observations of the subject system to identify meaningful higher level abstractions beyond those obtained directly by examining the system itself." (Source: Chikofsky and Cross)
Domain Specific Software Architecture
an architecture that denotes how problems in a specific domain are typically solved.
Interleaving
Model
a cognitive abstraction of a software system
Plan
"Knowledge structures that are schematic representation of stereotypical behavior patterns. ... Correspondingly, plans in programs are stereotypic action structures." (Source: Soloway, et al. CACM 11/88)
Program Comprehension
the process of acquiring knowledge about a computer program. (Source: Rugaber, Encyclopedia article)
Representation
tangible (non-cognitive) abstraction of a software system.
Restructuring
the transformation of one representation form to another at the same relative abstraction level, while preserving the subject system's external behaviour (functionality and semantics)." (Source: Chikofsky and Cross)
Reverse Engineering
"the process of analyzing a subject system to identify the system's components and their interrelationships and create representations of the system in another form or at a higher level of abstraction." (Source: Chikofsky and Cross)
Role
a relatively self contained subarchitecture (in the sense that a subsequence is related to a sequence).
Signature
The set of features (e.g., syntax, semantic, graphical) that together signal the occurrence of a specific concept. (Source: Biggerstaff, CACM)