Object Oriented Software Engineering   Glossary   Help

!indicates logical NOTlink: chapter2section2.8.html#579, 2001-08-30 14:54:17.0
is a subtopic of The Basics of Java2001-08-30 14:54:17.0
is an instance of Java logical operator2001-08-30 14:54:17.0
!=is a subtopic of The Basics of Java2001-08-30 14:54:17.0
is an instance of Java identity comparison operator2001-08-30 14:54:17.0
%indicates moduluslink: chapter2section2.8.html#578, 2001-08-30 14:54:15.0
is a subtopic of The Basics of Java2001-08-30 14:54:15.0
is an instance of Java arithmetic operator2001-08-30 14:54:15.0
&&indicates logical ANDlink: chapter2section2.8.html#578, 2001-08-30 14:54:15.0
is a subtopic of The Basics of Java2001-08-30 14:54:15.0
is an instance of Java logical operator2001-08-30 14:54:16.0
is an instance of short circuit operator2001-08-30 14:54:16.0
*indicates multiplicationlink: chapter2section2.8.html#708, 2001-08-30 14:54:16.0
is a subtopic of The Basics of Java2001-08-30 14:54:16.0
is an instance of Java arithmetic operator2001-08-30 14:54:16.0
*=has example
example expressionequivalent longer expression
a*=b;a=a*b;
link: chapter2section2.8.html#692, 2001-08-30 14:54:16.0
is a subtopic of The Basics of Java2001-08-30 14:54:16.0
is an instance of Java special operator2001-08-30 14:54:16.0
*^2indicates the multiplicity many2001-08-30 14:54:16.0
is a subtopic of 5.3 - Associations and Multiplicity2001-08-30 14:54:16.0
is an instance of multiplicity symbol2001-08-30 14:54:16.0
+indicates additionlink: chapter2section2.8.html#578, 2001-08-30 14:54:18.0
is a subtopic of The Basics of Java2001-08-30 14:54:18.0
is an instance of Java arithmetic operator2001-08-30 14:54:18.0
++has example
example expressionequivalent longer expression
a++;
b=a++;
++a;
b=++a;
a=a+1;
b=a; a=a+1;
a=a+1;
a=a+1; b=a;
link: chapter2section2.8.html#669, 2001-08-30 14:54:18.0
is a subtopic of The Basics of Java2001-08-30 14:54:18.0
is an instance of Java special operator2001-08-30 14:54:18.0
can be used in prefix or postfix formlink: chapter2section2.8.html#669, 2001-08-30 14:54:18.0
+=has example
example expressionequivalent longer expression
a+=b;a=a+b;
link: chapter2section2.8.html#692, 2001-08-30 14:54:18.0
is a subtopic of The Basics of Java2001-08-30 14:54:18.0
is an instance of Java special operator2001-08-30 14:54:18.0
-indicates subtractionlink: chapter2section2.8.html#578, 2001-08-30 14:54:17.0
is a subtopic of The Basics of Java2001-08-30 14:54:17.0
is an instance of Java arithmetic operator2001-08-30 14:54:17.0
--has example
example expressionequivalent longer expression
a--;
b=a--;
--a;
b=--a;
a=a-1;
b=a; a=a-1;
a=a-1;
a=a-1; b=a;
link: chapter2section2.8.html#679, 2001-08-30 14:54:17.0
is a subtopic of The Basics of Java2001-08-30 14:54:17.0
is an instance of Java special operator2001-08-30 14:54:17.0
can be used in prefix or postfix formlink: chapter2section2.8.html#679, 2001-08-30 14:54:17.0
-=has example
example expressionequivalent longer expression
a-=b;a=a-b;
link: chapter2section2.8.html#695, 2001-08-30 14:54:17.0
is a subtopic of The Basics of Java2001-08-30 14:54:18.0
is an instance of Java special operator2001-08-30 14:54:18.0
.is a subtopic of The Basics of Java2001-08-30 14:54:16.0
is an instance of Java symbol2001-08-30 14:54:16.0
is used to access an instance variable of an object in Java, for example: b.variableNamelink: chapter2section2.8.html#543, 2001-08-30 14:54:16.0
/indicates divisionlink: chapter2section2.8.html#578, 2001-08-30 14:54:17.0
is a subtopic of The Basics of Java2001-08-30 14:54:17.0
is an instance of Java arithmetic operator2001-08-30 14:54:17.0
/=has example
example expressionequivalent longer expression
a/=b;a=/b;
link: chapter2section2.8.html#698, 2001-08-30 14:54:16.0
is a subtopic of The Basics of Java2001-08-30 14:54:16.0
is an instance of Java special operator2001-08-30 14:54:16.0
1.1 - The Nature of Softwareis a subtopic of Chapter 1 - Software and Software Engineering2001-08-30 14:54:19.0
1.10 - Software and Software Engineering - Referencesis a subtopic of Chapter 1 - Software and Software Engineering2001-08-30 14:54:19.0
1.2 - What is Software Engineering?is a subtopic of Chapter 1 - Software and Software Engineering2001-08-30 14:54:19.0
1.3 - Software Engineering as a Branch of the Engineering Professionis a subtopic of Chapter 1 - Software and Software Engineering2001-08-30 14:54:19.0
1.4 - Stakeholders in Software Engineeringis a subtopic of Chapter 1 - Software and Software Engineering2001-08-30 14:54:19.0
1.5 - Software Qualityis a subtopic of Chapter 1 - Software and Software Engineering2001-08-30 14:54:19.0
1.6 - Software Engineering Projectsis a subtopic of Chapter 1 - Software and Software Engineering2001-08-30 14:54:19.0
1.7 - Activities Common to Software Projectsis a subtopic of Chapter 1 - Software and Software Engineering2001-08-30 14:54:19.0
1.8 - The Eight Themes Emphasized in this Bookis a subtopic of Chapter 1 - Software and Software Engineering2001-08-30 14:54:19.0
1.9 - Difficulties And Risks In Software Engineering as a Wholeis a subtopic of Chapter 1 - Software and Software Engineering2001-08-30 14:54:19.0
10.1 - Basic Definitionsis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:19.0
10.10 - Inspectionsis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:19.0
10.11 - Quality Assurance in Generalis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:19.0
10.13 - Difficulties and Risks in Quality Assuranceis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:19.0
10.14 - Testing and Inspecting to Ensure High Quality - Referencesis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:19.0
10.2 - Effective and Efficient Testingis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:19.0
10.3 - Defects in Ordinary Algorithmsis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:19.0
10.4 - Defects in Numerical Algorithmsis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:19.0
10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Racesis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:20.0
10.6 - Defects in Handling Stress and Unusual Situationsis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:20.0
10.7 - Documentation Defectsis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:20.0
10.8 - Writing Formal Test Cases and Test Plansis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:20.0
10.9 - Strategies for Testing Large Systemsis a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality2001-08-30 14:54:20.0
11.1 - What is Project Management?is a subtopic of Chapter 11 - Managing the Software Process2001-08-30 14:54:20.0
11.2 - Software Process Modelsis a subtopic of Chapter 11 - Managing the Software Process2001-08-30 14:54:20.0
11.3 - Cost Estimationis a subtopic of Chapter 11 - Managing the Software Process2001-08-30 14:54:20.0
11.4 - Building Software Engineering Teamsis a subtopic of Chapter 11 - Managing the Software Process2001-08-30 14:54:20.0
11.5 - Project Scheduling and Trackingis a subtopic of Chapter 11 - Managing the Software Process2001-08-30 14:54:20.0
11.6 - Contents of a Project Planis a subtopic of Chapter 11 - Managing the Software Process2001-08-30 14:54:20.0
11.8 - Managing the Software Process - Referencesis a subtopic of Chapter 11 - Managing the Software Process2001-08-30 14:54:20.0
2.1 - What is Object Orientation?is a subtopic of Chapter 2 - Review of Object Orientation2001-08-30 14:54:20.0
2.10 - Difficulties and Risks in Programming Language Choice and Object-Oriented Programmingis a subtopic of Chapter 2 - Review of Object Orientation2001-08-30 14:54:20.0
2.11 - Review of Object Orientation and Java - Referencesis a subtopic of Chapter 2 - Review of Object Orientation2001-08-30 14:54:20.0
2.2 - Classes and Objectsis a subtopic of Chapter 2 - Review of Object Orientation2001-08-30 14:54:20.0
2.3 - Instance Variablesis a subtopic of Chapter 2 - Review of Object Orientation2001-08-30 14:54:20.0
2.4 - Methods, Operations and Polymorphismis a subtopic of Chapter 2 - Review of Object Orientation2001-08-30 14:54:20.0
2.5 - Organizing Classes Into Inheritance Hierarchiesis a subtopic of Chapter 2 - Review of Object Orientation2001-08-30 14:54:20.0
2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarationsis a subtopic of Chapter 2 - Review of Object Orientation2001-08-30 14:54:20.0
2.7 - Concepts that Define Object Orientationis a subtopic of Chapter 2 - Review of Object Orientation2001-08-30 14:54:20.0
3.1 - Reuse: Building on the Work and Experience of Othersis a subtopic of Chapter 3 - Basing Software Development on Reusable Technology2001-08-30 14:54:20.0
3.11 - Basing Software Development on Reusable Technology - Referencesis a subtopic of Chapter 3 - Basing Software Development on Reusable Technology2001-08-30 14:54:20.0
3.2 - Incorporating Reusability and Reuse Into Software Engineeringis a subtopic of Chapter 3 - Basing Software Development on Reusable Technology2001-08-30 14:54:20.0
3.3 - Frameworks: Reusable Subsystemsis a subtopic of Chapter 3 - Basing Software Development on Reusable Technology2001-08-30 14:54:21.0
3.4 - The Client-Server Architectureis a subtopic of Chapter 3 - Basing Software Development on Reusable Technology2001-08-30 14:54:21.0
3.5 - Technology Needed to Build Client-Server Systemsis a subtopic of Chapter 3 - Basing Software Development on Reusable Technology2001-08-30 14:54:21.0
3.7 - Basic Description of OCSF- Client Sideis a subtopic of Chapter 3 - Basing Software Development on Reusable Technology2001-08-30 14:54:21.0
4.1 - Domain Analysisis a subtopic of Chapter 4 - Developing Requirements2001-08-30 14:54:21.0
4.12 - Difficulties and Risks In Domain and Requirements Analysisis a subtopic of Chapter 4 - Developing Requirements2001-08-30 14:54:21.0
4.13 - Developing Requirements - Referencesis a subtopic of Chapter 4 - Developing Requirements2001-08-30 14:54:21.0
4.2 - The Starting Point for Software Projectsis a subtopic of Chapter 4 - Developing Requirements2001-08-30 14:54:21.0
4.3 - Defining The Problem and the Scopeis a subtopic of Chapter 4 - Developing Requirements2001-08-30 14:54:21.0
4.4 - What Is a Requirement?is a subtopic of Chapter 4 - Developing Requirements2001-08-30 14:54:21.0
4.5 - Types of Requirementsis a subtopic of Chapter 4 - Developing Requirements2001-08-30 14:54:21.0
4.6 - Some Techniques for Gathering and Analyzing Requirementsis a subtopic of Chapter 4 - Developing Requirements2001-08-30 14:54:21.0
4.7 - Types of Requirements Documentis a subtopic of Chapter 4 - Developing Requirements2001-08-30 14:54:21.0
4.8 - Reviewing Requirementsis a subtopic of Chapter 4 - Developing Requirements2001-08-30 14:54:21.0
4.9 - Managing Changing Requirementsis a subtopic of Chapter 4 - Developing Requirements2001-08-30 14:54:21.0
5.1 - What is UML?is a subtopic of Chapter 5 - Modelling With Classes2001-08-30 14:54:21.0
5.10 - Difficulties and Risks When Creating Class Diagramsis a subtopic of Chapter 5 - Modelling With Classes2001-08-30 14:54:21.0
5.11 - Modelling With Classes - Referencesis a subtopic of Chapter 5 - Modelling With Classes2001-08-30 14:54:21.0
5.2 - Essentials of UML Class Diagramsis a subtopic of Chapter 5 - Modelling With Classes2001-08-30 14:54:21.0
5.3 - Associations and Multiplicityis a subtopic of Chapter 5 - Modelling With Classes2001-08-30 14:54:21.0
5.4 - Generalizationis a subtopic of Chapter 5 - Modelling With Classes2001-08-30 14:54:21.0
5.5 - Instance Diagramsis a subtopic of Chapter 5 - Modelling With Classes2001-08-30 14:54:21.0
5.6 - More Advanced Features of Class Diagramsis a subtopic of Chapter 5 - Modelling With Classes2001-08-30 14:54:21.0
5.7 - Detailed Example: A Class Diagram for Genealogyis a subtopic of Chapter 5 - Modelling With Classes2001-08-30 14:54:21.0
5.8 - The Process Of Developing Class Diagramsis a subtopic of Chapter 5 - Modelling With Classes2001-08-30 14:54:22.0
5.9 - Implementing Class Diagrams in Javais a subtopic of Chapter 5 - Modelling With Classes2001-08-30 14:54:22.0
6.1 - Introduction to Patternsis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
6.10 - The Immutable Patternis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
6.11 - The Read-Only Interface Patternis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
6.12 - The Proxy Patternis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
6.15 - Using Design Patterns - Referencesis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
6.2 - The Abstraction-Occurrence Patternis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
6.3 - The General Hierarchy Patternis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
6.4 - The Player-Role Patternis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
6.5 - The Singleton Patternis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
6.6 - The Observer Patternis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
6.7 - The Delegation Patternis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
6.8 - The Adapter Patternis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
6.9 - The Facade Patternis a subtopic of Chapter 6 - Using Design Patterns2001-08-30 14:54:22.0
7.1 - User Centred Designis a subtopic of Chapter 7 - Focusing on Users and Their Tasks2001-08-30 14:54:22.0
7.3 - Developing Use Case Models of Systemsis a subtopic of Chapter 7 - Focusing on Users and Their Tasks2001-08-30 14:54:22.0
7.4 - The Basics of User Interface Designis a subtopic of Chapter 7 - Focusing on Users and Their Tasks2001-08-30 14:54:22.0
7.5 - Usability Principlesis a subtopic of Chapter 7 - Focusing on Users and Their Tasks2001-08-30 14:54:22.0
7.6 - Evaluating User Interfacesis a subtopic of Chapter 7 - Focusing on Users and Their Tasks2001-08-30 14:54:22.0
7.7 - Implementing a Simple GUI in Javais a subtopic of Chapter 7 - Focusing on Users and Their Tasks2001-08-30 14:54:22.0
7.9 - Focusing on Users and Their Tasks - Referencesis a subtopic of Chapter 7 - Focusing on Users and Their Tasks2001-08-30 14:54:23.0
8.1 - Interaction Diagramsis a subtopic of Chapter 8 - Modelling Interactions and Behaviour2001-08-30 14:54:23.0
8.2 - State Diagramsis a subtopic of Chapter 8 - Modelling Interactions and Behaviour2001-08-30 14:54:23.0
8.3 - Activity Diagramsis a subtopic of Chapter 8 - Modelling Interactions and Behaviour2001-08-30 14:54:23.0
8.5 - Modelling Interactions and Behaviour - Referencesis a subtopic of Chapter 8 - Modelling Interactions and Behaviour2001-08-30 14:54:23.0
80-20 rulehas definition A rule that states that 80% of the benefit can often be obtained with 20% of the work; the remaining 20% of the benefit then takes 80% of the work2001-08-30 14:54:23.0
has purpose to justify cutting less important requirements to significantly reduce costs2001-08-30 14:54:23.0
is a subtopic of 4.8 - Reviewing Requirements2001-08-30 14:54:23.0
is a synonym of Pareto principle2001-08-30 14:56:56.0
is an instance of rule2001-08-30 14:54:23.0
states that 80% of the benefit can often be obtained with 20% of the work; the remaining 20% of the benefit then takes 80% of the work2001-08-30 14:54:23.0
9.1 - The Process of Designis a subtopic of Chapter 9 - Architecting and designing software2001-08-30 14:54:23.0
9.2 - Principles Leading to Good Designis a subtopic of Chapter 9 - Architecting and designing software2001-08-30 14:54:23.0
9.3 - Techniques for Making Good Design Decisionsis a subtopic of Chapter 9 - Architecting and designing software2001-08-30 14:57:54.0
9.4 - Software Architectureis a subtopic of Chapter 9 - Architecting and designing software2001-08-30 14:54:24.0
9.5 - Architectural Patternsis a subtopic of Chapter 9 - Architecting and designing software2001-08-30 14:54:23.0
9.6 - Writing a Good Design Documentis a subtopic of Chapter 9 - Architecting and designing software2001-08-30 14:54:24.0
9.9 - Architecting and designing software - Referencesis a subtopic of Chapter 9 - Architecting and designing software2001-08-30 14:54:24.0
<is a subtopic of The Basics of Java2001-08-30 14:54:18.0
is an instance of Java relational comparison operator2001-08-30 14:54:18.0
<=is a subtopic of The Basics of Java2001-08-30 14:54:18.0
is an instance of Java relational comparison operator2001-08-30 14:54:18.0
=indicates assignmentlink: chapter2section2.8.html#534, 2001-08-30 14:54:18.0
is a subtopic of The Basics of Java2001-08-30 14:54:18.0
is an instance of Java operator2001-08-30 14:54:18.0
==has purpose to compare any two variables to test if they are identical, which means they either refer to the same objects or have the same primitive valueslink: chapter2section2.8.html#602, 2001-08-30 14:54:18.0
is a subtopic of The Basics of Java2001-08-30 14:54:18.0
is an instance of Java identity comparison operator2001-08-30 14:54:19.0
returns a booleanlink: chapter2section2.8.html#601, 2001-08-30 14:54:19.0
>is a subtopic of The Basics of Java2001-08-30 14:54:19.0
is an instance of Java relational comparison operator2001-08-30 14:54:19.0
>=is a subtopic of The Basics of Java2001-08-30 14:54:19.0
is an instance of Java relational comparison operator2001-08-30 14:54:19.0
?:has form
 result = (condition) ? doSomething() : doSomethingElse();
If condition is true, then result is set to the expression following the question mark, otherwise result is set to the expression following the colon
link: chapter2section2.8.html#731, 2001-08-30 14:54:16.0
has purpose to execute one of two alternative expressions, depending on the value of a conditionlink: chapter2section2.8.html#730, 2001-08-30 14:54:16.0
is a subtopic of The Basics of Java2001-08-30 14:54:17.0
is an instance of Java operator2001-08-30 14:54:17.0
can shorten code but can also make code harder to understandlink: chapter2section2.8.html#734, 2001-08-30 14:54:16.0
A Pattern Languagehas author C. Alexander2001-08-30 14:54:24.0
has ISBN number 0-19-501919-92001-08-30 14:54:24.0
is a subtopic of 6.15 - Using Design Patterns - References2001-08-30 14:54:24.0
is an instance of book about design patterns2001-08-30 14:54:24.0
was published by Oxford University Press2001-08-30 14:54:24.0
was published in 19772001-08-30 14:54:24.0
abbreviationis a kind of kbTop2001-08-30 14:54:24.0
abstractis a subtopic of The Basics of Java2001-08-30 14:54:24.0
is an instance of Java keyword2001-08-30 14:54:24.0
is used to declare abstract classlink: chapter2section2.8.html#943, 2001-08-30 14:54:24.0
is used to declare abstract methodlink: chapter2section2.8.html#940, 2001-08-30 14:54:24.0
abstract classhas definition A class that cannot have any instances2001-08-30 14:54:24.0
has part abstract method2001-08-30 14:54:24.0
has purpose to hold features that will be inherited by two or more subclasses2001-08-30 14:54:24.0
is a kind of class2001-08-30 14:54:24.0
is a subtopic of The Basics of Java2001-08-30 14:54:24.0
can have concrete methods or instance variableslink: chapter2section2.8.html#946, 2001-08-30 14:54:24.0
cannot have instances2001-08-30 14:54:24.0
abstract methodhas purpose to serve as a placeholder, indicating that subclasses must have concrete implementationslink: chapter2section2.8.html#942, 2001-08-30 14:54:24.0
is a kind of method2001-08-30 14:54:24.0
is a subtopic of The Basics of Java2001-08-30 14:54:24.0
abstract operationhas definition An operation in a class that makes logical sense for all subclasses, but that is not implemented in the class2001-08-30 14:54:24.0
is a kind of operation2001-08-30 14:54:25.0
is a subtopic of 2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarations2001-08-30 14:54:25.0
abstract soundhas advantages attracts attention rapidly even if the person is not looking at the screen2001-08-30 14:54:25.0
has example beep2001-08-30 14:54:25.0
has problems
  • can be distracting and annoying
  • can be hard to interpret
  • not usable by deaf people
2001-08-30 14:54:25.0
is a kind of coding technique2001-08-30 14:54:25.0
is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:54:25.0
abstractionhas definition A representation that captures only essential aspects of something, reducing the complexity apparent to the abstraction's user2001-08-30 14:54:25.0
hides details which can be shown 2001-08-30 14:54:25.0
is a kind of representation2001-08-30 14:54:25.0
is a subtopic of 2.1 - What is Object Orientation?2001-08-30 14:54:25.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:54:25.0
abstraction-occurrencehas antipatterns 2001-08-30 14:54:25.0
has context class diagrams that form part of a system domain model2001-08-30 14:54:25.0
has definition A pattern in which two classes are related by an association, and one of the classes represents an abstraction of the other2001-08-30 14:54:25.0
has forces
  • You want to represent the members of each set of occurrences without duplicating the common information
  • You want a solution that maximizes the flexibility of the system
2001-08-30 14:54:25.0
has problem What is the best way to represent sets of occurrences in a class diagram?2001-08-30 14:54:25.0
has references a generalization of the Title-Item pattern of Eriksson and Penker2001-08-30 14:54:25.0
has related patterns Abstraction-Occurrence Square pattern if the abstraction is an aggregate (and the occurrences are also aggregates)2001-08-30 14:54:25.0
has solution
  1. Create an «Abstraction» class that contains the data that is common to all the members of a set of occurrences.
  2. Then create an «Occurrence» class representing the occurrences of this abstraction.
  3. Connect these classes with a one-to-many association
2001-08-30 14:54:25.0
is a subtopic of 6.2 - The Abstraction-Occurrence Pattern2001-08-30 14:54:25.0
is an instance of design pattern2001-08-30 14:54:25.0
abstraction^2has definition The quality of software in which only the essential aspects of something are captured, reducing the complexity apparent to the user2001-08-30 14:54:25.0
is a kind of software quality2001-08-30 14:54:25.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:54:25.0
is increased by 2001-08-30 14:54:25.0
acceptabilityhas definition The extent to which customers and users like a system2001-08-30 14:54:26.0
is subjective2001-08-30 14:54:26.0
is a kind of measurement2001-08-30 14:54:26.0
is a kind of software quality2001-08-30 14:54:26.0
is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:54:26.0
is affected by many factors, including other aspects of usability, graphic design and various aesthetic issues2001-08-30 14:54:26.0
measures how much users like the system2001-08-30 14:54:26.0
acceptance testinghas definition Testing performed by customers, on their own initiative, to decide whether software is sufficiently acceptable to pay for2001-08-30 14:54:26.0
has purpose
  • to decide whether software is of sufficient quality either to purchase or to pay a custom developer
  • to choose between several competing generic products
2001-08-30 14:54:26.0
is a kind of testing performed by users and clients2001-08-30 14:54:26.0
is a subtopic of 10.9 - Strategies for Testing Large Systems2001-08-30 14:54:26.0
is performed by customers on their own initiative2001-08-30 14:54:26.0
ACMis a subtopic of 1.10 - Software and Software Engineering - References2001-08-30 14:54:26.0
is an abbreviation for The Association for Computing Machinery2001-08-30 14:54:26.0
is an instance of abbreviation2001-08-30 14:54:26.0
ACM/IEEE software engineering code of ethicshas URL www.acm.org/serving/se/code.htm    2001-08-30 14:54:26.0
is a subtopic of 1.10 - Software and Software Engineering - References2001-08-30 14:54:26.0
is an instance of software engineering web site2001-08-30 14:54:26.0
action2001-08-30 14:54:26.0
is a kind of subject2001-08-30 14:54:26.0
action symbolis a kind of symbol in state diagram2001-08-30 14:54:26.0
is a subtopic of 8.2 - State Diagrams2001-08-30 14:54:26.0
is drawn as a slash and the name of the action2001-08-30 14:54:26.0
is drawn as Enter/action or Exit/action in a box inside a state if the action is to be performed when entering or exiting the state2001-08-30 14:54:26.0
is drawn as event/action If the action is to be performed during a transition2001-08-30 14:54:26.0
action^2has definition Something that takes place effectively instantaneously when a transition occurs in a state diagram, or upon entry or exit from a state2001-08-30 14:54:27.0
has example as sending a message, starting a hardware device or setting a variable2001-08-30 14:54:27.0
is a kind of action2001-08-30 14:54:27.0
is a kind of computation2001-08-30 14:54:27.0
is a subtopic of 8.2 - State Diagrams2001-08-30 14:54:27.0
is caused by one of the following situations:2001-08-30 14:54:27.0
occurs instantaneously2001-08-30 14:54:27.0
must be simple because it should take place with no noticeable consumption of time2001-08-30 14:54:27.0
activation boxhas definition A box on a lifeline in a sequence diagram indicating the period of time during which an object is actively performing work2001-08-30 14:54:27.0
is a kind of symbol in sequence diagram2001-08-30 14:54:27.0
is a subtopic of 8.1 - Interaction Diagrams2001-08-30 14:54:27.0
is drawn as a rectangle2001-08-30 14:54:27.0
represents an object performing computations2001-08-30 14:54:27.0
activityhas definition Something that occurs over a period of time and takes place while the system is in a state2001-08-30 14:54:27.0
is a kind of computation2001-08-30 14:54:27.0
is a subtopic of 8.2 - State Diagrams2001-08-30 14:54:27.0
activity diagramhas advantage it can represent concurrent activities2001-08-30 14:54:27.0
has definition A UML diagram showing sequences of activities, typically for multiple threads2001-08-30 14:54:27.0
has part fork2001-08-30 14:54:27.0
has part join2001-08-30 14:54:27.0
has part rendezvous2001-08-30 14:54:27.0
is a kind of UML diagram2001-08-30 14:54:27.0
is a subtopic of 5.1 - What is UML?2001-08-30 14:54:27.0
is usually associated with several classes2001-08-30 14:54:27.0
shows how systems behave internally2001-08-30 14:54:27.0
shows the partition of activities among the existing classes using swimlanes2001-08-30 14:54:27.0
can represent 2001-08-30 14:54:27.0
activitymust be completed before the system leaves the current state as the result of some transition2001-08-30 14:54:27.0
activity symbolis a kind of symbol in state diagram2001-08-30 14:54:27.0
is a subtopic of 8.2 - State Diagrams2001-08-30 14:54:27.0
is drawn as a box within the state, containing the word 'do:' followed by a description of what is to be done2001-08-30 14:54:27.0
actorhas definition A role that a user or some other system plays when interacting with your system; a class of user of a system2001-08-30 14:54:28.0
has goals for using the system, and a given user may have different roles from time to time2001-08-30 14:54:28.0
is a kind of user2001-08-30 14:54:28.0
is a subtopic of 7.3 - Developing Use Case Models of Systems2001-08-30 14:54:28.0
actor symbolis a kind of symbol in UML diagram2001-08-30 14:54:28.0
is a kind of symbol in use case diagram2001-08-30 14:54:28.0
is a subtopic of 7.3 - Developing Use Case Models of Systems2001-08-30 14:54:28.0
is drawn as a stick man2001-08-30 14:54:28.0
adapterhas context 2001-08-30 14:54:28.0
has definition A pattern found in class diagrams in which you are able to reuse an 'adaptee' class by providing a class, (the adapter) that delegates to the adaptee2001-08-30 14:54:28.0
has forces You do not have access to multiple inheritance or you do not want to use it.2001-08-30 14:54:28.0
has problem How do you obtain the power of polymorphism when reusing a class whose methods have the same function but do not have the same signature as the other methods in the hierarchy?2001-08-30 14:54:28.0
has references one of the Gang of Four patterns.2001-08-30 14:54:28.0
has related patterns facade, read-only interface, proxy2001-08-30 14:54:28.0
has solution
  1. Rather than directly incorporating the reused class into your inheritance hierarchy, instead incorporate an «Adapter» class.
  2. The «Adapter»is connected by an association to the reused class, which we will call the «Adaptee».
  3. The polymorphic methods of the «Adapter» delegate to methods of the «Adaptee».
  4. The delegate method in the «Adaptee» may or may not have the same name as the delegating polymorphic method.
2001-08-30 14:54:28.0
is a subtopic of 6.8 - The Adapter Pattern2001-08-30 14:54:28.0
is an instance of design pattern2001-08-30 14:54:28.0
adaptive maintenancehas definition A type of maintenance performed to change software so that it will work in an altered environment, such as when an operating system, hardware platform, compiler, software library or database structure changes2001-08-30 14:54:28.0
is a kind of maintenance2001-08-30 14:54:28.0
is a subtopic of 1.6 - Software Engineering Projects2001-08-30 14:54:28.0
does not result in new capabilities for the user except the ability to operate the software in the changed environment2001-08-30 14:54:28.0
adaptive projectinvolves changing the system in response to changes in the environment in which the software runs2001-08-30 14:54:28.0
is a kind of evolutionary project2001-08-30 14:54:28.0
is a subtopic of 1.6 - Software Engineering Projects2001-08-30 14:54:28.0
adding and deleting links of associationsis complex since there is the need to collaborate with other classes to ensure the bi-directional nature of most associations is maintained properly2001-08-30 14:54:28.0
is a kind of responsibility2001-08-30 14:54:28.0
is a subtopic of 5.8 - The Process Of Developing Class Diagrams2001-08-30 14:54:28.0
is often omitted from a model because the presence of such responsibilities can largely be inferred from the class diagram2001-08-30 14:54:28.0
address formathas localization issues
  • You should almost never require a specific format for these items since they differ so widely and can change at any time
  • Allow free-form input of whatever the user wants to type
2001-08-30 14:54:29.0
is a kind of locale-dependent feature2001-08-30 14:54:29.0
is a subtopic of 7.5 - Usability Principles2001-08-30 14:54:29.0
affordancehas definition The set of operations that the user can do in a user interface at any given point in time2001-08-30 14:54:29.0
has example the set of typing into an input field, clicking on a button or selecting an item from a menu2001-08-30 14:54:29.0
is a kind of subject2001-08-30 14:54:29.0
is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:54:29.0
aggregatehas definition The class on the 'whole' side of an aggregation2001-08-30 14:54:29.0
is a kind of class2001-08-30 14:54:29.0
is a subtopic of 5.6 - More Advanced Features of Class Diagrams2001-08-30 14:54:29.0
is a synonym of assembly2001-08-30 14:54:35.0
aggregationhas definition An association, which specifies that instances of one class contain instances of the other class as parts2001-08-30 14:54:29.0
is a kind of association2001-08-30 14:54:29.0
is a subtopic of 5.6 - More Advanced Features of Class Diagrams2001-08-30 14:54:29.0
is drawn as a diamond next to the 'whole' end of the association in a UML class diagram2001-08-30 14:54:29.0
represents 'part-whole' relationships2001-08-30 14:54:29.0
can be drawn as a hierarchy but the use of such hierarchies in valid models is quite rare2001-08-30 14:54:29.0
algorithmis a kind of subject2001-08-30 14:54:29.0
is a subtopic of 10.4 - Defects in Numerical Algorithms2001-08-30 14:54:29.0
algorithm designhas definition The design of computational mechanisms2001-08-30 14:54:29.0
is a kind of design2001-08-30 14:54:29.0
is a subtopic of 9.1 - The Process of Design2001-08-30 14:54:29.0
algorithmic cost estimation modelhas definition An approach to cost estimation such as COCOMO or function points, that use mathematical formulas whose parameters are based on industrial experience2001-08-30 14:54:29.0
has example formula E = a + bNc
where
  • E is the effort estimate
  • N is the estimate or measure being used as the basis for the effort estimate (e.g. number of use cases or lines of code)
  • a, b and c are obtained by extensive analysis of past projects and comparisons with the current project
2001-08-30 14:54:29.0
is a kind of subject2001-08-30 14:54:30.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:54:29.0
provides provide formulas to compute anticipated cost of a project, taking into account various aspects of the project's size and complexity2001-08-30 14:54:30.0
uses formula2001-08-30 14:54:30.0
was developed by looking at a wide range of software development projects2001-08-30 14:54:30.0
All project managementhas URL www.allpm.com    2001-08-30 14:54:30.0
is a subtopic of 11.8 - Managing the Software Process - References2001-08-30 14:54:30.0
is an instance of web site about project management2001-08-30 14:54:30.0
allowance for maintainability and enhancementdescribes changes that are anticipated for subsequent releases2001-08-30 14:54:30.0
is a kind of non-functional requirement2001-08-30 14:54:30.0
is a subtopic of 4.5 - Types of Requirements2001-08-30 14:54:30.0
allowance for reusabilitydescribes the percentage of the system, measured in lines of code, that must be designed generically so that it can be reused2001-08-30 14:54:30.0
is a kind of non-functional requirement2001-08-30 14:54:30.0
is a subtopic of 4.5 - Types of Requirements2001-08-30 14:54:30.0
alpha testinghas advantage
  • you typically are able to have a much larger volume of testing performed
  • the users use the software in the same manner that they will use it when it is formally released
2001-08-30 14:54:30.0
has definition Testing performed by the user or client, under the supervision of the software development team2001-08-30 14:54:30.0
is a kind of testing performed by users and clients2001-08-30 14:54:30.0
is a subtopic of 10.9 - Strategies for Testing Large Systems2001-08-30 14:54:30.0
amount of elapsed timeis a kind of event2001-08-30 14:54:30.0
is a subtopic of 8.2 - State Diagrams2001-08-30 14:54:30.0
An Introduction to Object Oriented Programming with Javahas author C. Thomas Wu2001-08-30 14:54:30.0
has ISBN number 0-07-239684-92001-08-30 14:54:30.0
has URL www.drcaffeine.com/    2001-08-30 14:54:30.0
is a subtopic of 2.11 - Review of Object Orientation and Java - References2001-08-30 14:54:30.0
is an instance of book about Java programming2001-08-30 14:54:30.0
was published by McGraw Hill2001-08-30 14:54:30.0
was published in 20002001-08-30 14:54:30.0
An Investigation of the Therac-25 Accidenthas author N.G. Leveson and C.S. Turner2001-08-30 14:54:30.0
has date July 19932001-08-30 14:54:30.0
has publication IEEE Computer, Vol. 26, No. 72001-08-30 14:54:31.0
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:54:31.0
is an instance of article about software failures2001-08-30 14:54:31.0
analysisis a kind of process2001-08-30 14:54:31.0
is a subtopic of 2.2 - Classes and Objects2001-08-30 14:54:31.0
animationhas advantages
  • provides high impact communication of complex information
  • entertaining and hence attractive for users
2001-08-30 14:54:31.0
has problems
  • bandwidth-intensive, hence reduces response time
  • sequential, requiring replay
  • viewing consumes the user's time
  • not usable by blind and possibly deaf people
  • expensive to produce
  • may be annoying
2001-08-30 14:54:31.0
is a kind of coding technique2001-08-30 14:54:31.0
is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:54:31.0
anticipating obsolescenceassumes that changes will inevitably occur in the technology a software system uses and the environment in which it runs2001-08-30 14:54:31.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:54:31.0
is an instance of design principle2001-08-30 14:54:31.0
means planning for changes in the technology or environment so the software will continue to run or can be easily changed2001-08-30 14:54:31.0
can be accomplished by
  • Avoiding the use of early releases of technology
  • Avoiding the use of software libraries that are specific to particular environments
  • Avoiding the use of undocumented features or little-used features of software libraries
  • Avoiding the use of reusable software or special hardware from smaller companies, or from those that are less likely to provide long-term support
  • Using standard languages and technologies that are supported by multiple vendors
2001-08-30 14:54:31.0
antipatternhas definition A solution to a design problem that is inferior or does not work in this context2001-08-30 14:54:31.0
is a kind of design pattern2001-08-30 14:54:31.0
is a subtopic of 6.1 - Introduction to Patterns2001-08-30 14:54:31.0
is part of design pattern2001-08-30 14:54:31.0
Antipatterns: Refactoring Software, Architectures, and Projects in Crisishas author W.H. Brown, R.C. Malveau, H.W. McCormick III, T.J. Mowbray2001-08-30 14:54:31.0
has ISBN number 0-471-19713-02001-08-30 14:54:31.0
is a subtopic of 6.15 - Using Design Patterns - References2001-08-30 14:54:31.0
is an instance of book about design patterns2001-08-30 14:54:31.0
was published by Wiley2001-08-30 14:54:31.0
was published in 19982001-08-30 14:54:31.0
APIis a subtopic of 3.3 - Frameworks: Reusable Subsystems2001-08-30 14:54:31.0
is an abbreviation for Application Program Interface2001-08-30 14:54:31.0
is an instance of abbreviation2001-08-30 14:54:31.0
applicationhas definition A program used by an end-user, as opposed to one simply used by other programs2001-08-30 14:54:32.0
is a kind of program2001-08-30 14:54:32.0
application frameworkhas definition A framework that provides many of the functions needed by a particular class of applications, and which is designed to be reused in the development of such applications2001-08-30 14:54:32.0
is a synonym of vertical framework2001-08-30 14:54:32.0
Application Program Interfacehas definition The set of procedures or methods through which a layer provides its services2001-08-30 14:54:32.0
has specification that describes the protocol that higher-level layers use to access it, as well as the semantics of each service, including the side effects2001-08-30 14:54:32.0
is a kind of interface^22001-08-30 14:54:32.0
is a subtopic of 3.3 - Frameworks: Reusable Subsystems2001-08-30 14:54:32.0
is abbreviated as API2001-08-30 14:54:32.0
applicationtypically uses only a subset of the framework's services2001-08-30 14:54:32.0
Applied Software Architecturehas author Christine Hofmeister, Robert Nord, Dilip Soni2001-08-30 14:54:32.0
has ISBN number 0-201-32571-32001-08-30 14:54:32.0
is a subtopic of 9.9 - Architecting and designing software - References2001-08-30 14:54:32.0
is an instance of software architecture book2001-08-30 14:54:32.0
was published by Addison-Wesley2001-08-30 14:54:32.0
was published in 19992001-08-30 14:54:32.0
approach to identifying generalizationsis a kind of principle2001-08-30 14:54:32.0
is a subtopic of 5.8 - The Process Of Developing Class Diagrams2001-08-30 14:54:32.0
Aptest's software testing linkshas URL www.aptest.com/resources.html    2001-08-30 14:54:32.0
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:54:32.0
is an instance of web site about software testing2001-08-30 14:54:32.0
architecthas definition The person responsible for leading the decision-making about the architecture, and maintaining the architectural model2001-08-30 14:54:32.0
is a kind of software developer2001-08-30 14:54:33.0
is a subtopic of 11.4 - Building Software Engineering Teams2001-08-30 14:54:33.0
is a subtopic of 9.4 - Software Architecture2001-08-30 14:54:33.0
architectural modelassists with
  • integrating the work of individual people to form the final system
  • planning and co-ordination of the work of developing a complex software system which is distributed among a large number of people
  • planning the evolution of the system, such as subsystems that are envisioned to be part of a future release
2001-08-30 14:54:33.0
contains information about the interfaces and dynamic interactions among the subsystems2001-08-30 14:54:33.0
defines the terms that people use when they communicate with each other about lower-level details2001-08-30 14:54:33.0
has definition The document produced as a result of performing software architecture2001-08-30 14:54:33.0
has purpose 2001-08-30 14:54:33.0
is a kind of document2001-08-30 14:54:33.0
is a subtopic of 9.4 - Software Architecture2001-08-30 14:54:33.0
is a synonym of software architecture^32001-08-30 14:57:34.0
shows each system component, encouraging reuse2001-08-30 14:54:33.0
can be used to communicate with customers2001-08-30 14:54:33.0
may be expressed as several different views such as
  • The logical breakdown into subsystems, often shown using package diagrams
  • The dynamics of the interaction among components at run time, expressed using interaction or activity diagrams
  • The data that will be shared among the subsystems, expressed using class diagrams
  • The components that will exist at run time, and the machines or devices on which they will be located, expressed using component and deployment diagrams
2001-08-30 14:54:33.0
must be stable which means that the new features can be easily added with only small changes to the architecture2001-08-30 14:54:33.0
should be generic to ensure reusability2001-08-30 14:54:33.0
architectural modelleris a kind of modeller2001-08-30 14:54:33.0
is a subtopic of 9.4 - Software Architecture2001-08-30 14:54:33.0
performs architectural modelling2001-08-30 14:54:33.0
refines architectural model by following these steps iteratively:
  • Sketch an outline of the architecture, based on the principal requirements and use cases. Determine the main components that will be needed, such as databases, particular hardware devices and the main software subsystems
  • Refine the architecture by identifying the main ways in which the components will interact, and by identifying the interfaces between them. Decide how each piece of data and functionality will be distributed among the various components
  • Consider each use case and adjust the architecture to make it realizable
  • Mature the architecture as you define the final class diagrams and interaction diagrams
2001-08-30 14:54:33.0
uses UML diagrams2001-08-30 14:54:33.0
should apply design principles2001-08-30 14:54:33.0
should avoid circular dependencies among packages2001-08-30 14:54:33.0
should make the interface of a package as simple as possible to simplify its use and testing2001-08-30 14:54:33.0
architectural modellingfollows these steps iteratively:
  1. Sketch an outline of the architecture, based on the principal requirements and use cases. Determine the main components that will be needed, such as databases, particular hardware devices and the main software subsystems. Choose architectural patterns.
  2. Refine the architecture by identifying the main ways in which the components will interact, and by identifying the interfaces between them. Decide how each piece of data and functionality will be distributed among the various components. Determine if you can re-use an existing framework.
  3. Consider each use case and adjust the architecture to make it realizable
  4. Mature the architecture as you define the final class diagrams and interaction diagrams
2001-08-30 14:54:33.0
has challenge is to produce a relevant and synthetic picture of a large and complex system2001-08-30 14:54:33.0
is a kind of modelling2001-08-30 14:54:33.0
is a subtopic of 9.4 - Software Architecture2001-08-30 14:54:33.0
is performed by architectural modeller2001-08-30 14:54:33.0
uses UML diagrams2001-08-30 14:54:33.0
architectural patternallows you to design flexible systems using components that are as independent of each other as possible2001-08-30 14:54:33.0
has definition A pattern used in software architecture2001-08-30 14:54:33.0
is a kind of pattern2001-08-30 14:54:34.0
is a subtopic of 9.5 - Architectural Patterns2001-08-30 14:54:33.0
is a synonym of architectural style2001-08-30 14:54:34.0
architectural styleis a synonym of architectural pattern2001-08-30 14:54:34.0
architecture designis a kind of design2001-08-30 14:54:34.0
is a subtopic of 9.1 - The Process of Design2001-08-30 14:54:34.0
is a subtopic of 9.4 - Software Architecture2001-08-30 14:54:34.0
is a synonym of software architecture^22001-08-30 14:54:34.0
ArgoUMLhas URL argouml.tigris.org    2001-08-30 14:54:34.0
is an open source shareware project run by Tigris2001-08-30 14:54:34.0
is a subtopic of 5.11 - Modelling With Classes - References2001-08-30 14:54:34.0
is an instance of tool for drawing UML diagrams2001-08-30 14:54:34.0
ArrayListhas methods set, add and removelink: chapter2section2.8.html#845, 2001-08-30 14:54:34.0
has purpose to allow you to build collections of objects that grow as more objects are addedlink: chapter2section2.8.html#845, 2001-08-30 14:54:34.0
is a subtopic of The Basics of Java2001-08-30 14:54:34.0
is an instance of Java collection class2001-08-30 14:54:34.0
articleis a kind of publication2001-08-30 14:54:34.0
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:54:34.0
article about software failuresis a kind of article2001-08-30 14:54:34.0
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:54:34.0
ASCIIis a subtopic of The Basics of Java2001-08-30 14:54:34.0
is an instance of coding scheme2001-08-30 14:54:35.0
cannot represent all the symbols used in languages other than Englishlink: chapter2section2.8.html#815, 2001-08-30 14:54:34.0
assemblyis a synonym of aggregate2001-08-30 14:54:35.0
assertionhas definition A statement that must be true; if it becomes false then the software has encountered a failure2001-08-30 14:54:35.0
is a kind of statement2001-08-30 14:54:35.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:54:35.0
assignment statementhas purpose to assign a value to a variablelink: chapter2section2.8.html#534, 2001-08-30 14:54:35.0
is a kind of statement2001-08-30 14:54:35.0
is a subtopic of The Basics of Java2001-08-30 14:54:35.0
associationdescribes a relationship that will exist between instances at run time2001-08-30 14:54:35.0
has default name "has" if it has neither an association name nor a role name2001-08-30 14:54:35.0
has definition A relationship between two classes that represents the existence of a set of links between objects of the two classes2001-08-30 14:54:35.0
has example class Person in a business application might have the following relationships supervisor (association to class Manager) and tasksToDo (association to class Task)2001-08-30 14:54:35.0
has part association name2001-08-30 14:54:35.0
has part role name2001-08-30 14:54:35.0
is bi-directional unless it has an arrow at one end indicating directionality2001-08-30 14:54:35.0
is legitimate only if its links will survive beyond the execution of any particular operation2001-08-30 14:54:35.0
is a kind of data abstraction2001-08-30 14:54:35.0
is a subtopic of 2.2 - Classes and Objects2001-08-30 14:54:35.0
is a subtopic of 5.3 - Associations and Multiplicity2001-08-30 14:54:35.0
is drawn as a line, or set of connected lines, between two classes in a UML class diagram2001-08-30 14:54:35.0
is usually implemented using instance variables in Java: you divide each two-way association into two one-way associations - so each associated class has an instance variable2001-08-30 14:54:35.0
normally represents something that will be stored in a database2001-08-30 14:54:35.0
represents all the links between two classes that may ever exist2001-08-30 14:54:35.0
shows how two classes are related to each other2001-08-30 14:54:35.0
can have a label which is an association name or a role name2001-08-30 14:54:35.0
cannot be drawn as a hierarchy2001-08-30 14:54:35.0
association classhas definition A class whose instances are associated with links of a (usually many-to-many) association2001-08-30 14:54:35.0
is a kind of class2001-08-30 14:54:36.0
is a subtopic of 5.3 - Associations and Multiplicity2001-08-30 14:54:35.0
is attached to an association2001-08-30 14:54:35.0
should be named using a noun that reflects the meaning of the association2001-08-30 14:54:36.0
Association for Computing Machineryhas web site www.acm.org    2001-08-30 14:54:36.0
is a subtopic of 1.10 - Software and Software Engineering - References2001-08-30 14:54:36.0
is abbreviated as ACM2001-08-30 14:54:36.0
is an instance of organization2001-08-30 14:54:36.0
publishes Communications of the ACM2001-08-30 14:54:36.0
associationmay be implemented in several ways in Java2001-08-30 14:54:35.0
must not be added to a model unless it is relevant to the application - it will be needed to implement some requirement2001-08-30 14:54:35.0
association nameis a verb or verb phrase2001-08-30 14:54:36.0
is a kind of label2001-08-30 14:54:36.0
is a subtopic of 5.3 - Associations and Multiplicity2001-08-30 14:54:36.0
is placed next to the middle of the association in a UML diagram2001-08-30 14:54:36.0
may have an arrow next to it to indicate the direction in which to read the association2001-08-30 14:54:36.0
associationshould exist if a class possesses, controls, is connected to, is related to, is a part of, has as parts, is a member of, or has as members, some class in your model2001-08-30 14:54:35.0
should have sufficient names to make the association clear and unambiguous2001-08-30 14:54:35.0
association symbolis a kind of symbol in UML diagram2001-08-30 14:54:36.0
is a subtopic of 5.2 - Essentials of UML Class Diagrams2001-08-30 14:54:36.0
assuming a floating point value will be exactly equal to some other valuehas testing strategy standard boundary testing2001-08-30 14:54:36.0
is a kind of defect in a numerical algorithm2001-08-30 14:54:36.0
is a subtopic of 10.4 - Defects in Numerical Algorithms2001-08-30 14:54:36.0
asymmetric reflexive associationhas definition A reflexive association in which the roles at either end are different.2001-08-30 14:54:36.0
is a kind of reflexive association2001-08-30 14:54:36.0
is a subtopic of 5.3 - Associations and Multiplicity2001-08-30 14:54:36.0
should be labelled using role names instead of an association name2001-08-30 14:54:36.0
atomicityhas definition A property of a transaction that ensures it is completed entirely, or not at all2001-08-30 14:54:36.0
is a kind of quality2001-08-30 14:54:36.0
is a subtopic of 9.5 - Architectural Patterns2001-08-30 14:54:36.0
attributehas definition A simple data item present in all the instances of a class2001-08-30 14:54:36.0
is a kind of data abstraction2001-08-30 14:54:37.0
is a kind of variable2001-08-30 14:54:37.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:54:36.0
is implemented as an instance variable in Java2001-08-30 14:54:37.0
is used in the analysis and design stage before it is known how the attribute will be implemented2001-08-30 14:54:37.0
represents the properties of an object2001-08-30 14:54:37.0
can be identified by looking at the description of the system and searching for information that must be maintained about each class2001-08-30 14:54:36.0
must not be added to a model unless it is relevant to the application - it will be needed to implement some requirement2001-08-30 14:54:37.0
must not have a plural name2001-08-30 14:54:37.0
should be a simple variable - typically an integer or string, or a one-to-one composition2001-08-30 14:54:37.0
should be private2001-08-30 14:54:37.0
should not have an implicit internal structure2001-08-30 14:54:37.0
should not normally represent a variable number of things2001-08-30 14:54:37.0
should only be accessed through public methods so that attributes are only given valid values and so that you can change the internal design of the class without affecting how users of the class interact with it2001-08-30 14:54:37.0
attribute symbolis a kind of symbol in UML diagram2001-08-30 14:54:37.0
is a subtopic of 5.2 - Essentials of UML Class Diagrams2001-08-30 14:54:37.0
attribute^2has definition A detail in the requirements of a system2001-08-30 14:54:37.0
is a kind of subject2001-08-30 14:54:37.0
is a subtopic of 10.8 - Writing Formal Test Cases and Test Plans2001-08-30 14:54:37.0
can be found by circling all the important points in the requirements document2001-08-30 14:54:37.0
can be thought of as something that is testable2001-08-30 14:54:37.0
availabilityhas definition A quality that measures the amount of time that a system is running and able to provide services to its users2001-08-30 14:54:37.0
is a kind of measurement2001-08-30 14:54:37.0
is a kind of non-functional requirement2001-08-30 14:54:37.0
is a subtopic of 4.5 - Types of Requirements2001-08-30 14:54:37.0
measures the amount of time that a server is running and available to respond to users2001-08-30 14:54:37.0
average software projectexceeds its budget by 90% and its schedule by 120% according to the Standish Group    2001-08-30 14:54:37.0
is a kind of software project2001-08-30 14:54:37.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:54:37.0
is canceled before completion 30% of the time according to the Standish Group    2001-08-30 14:54:37.0
AWT componentis simpler than Java Beans or Swing components but more limited2001-08-30 14:54:37.0
is a kind of Java user interface component2001-08-30 14:54:38.0
is a subtopic of 7.7 - Implementing a Simple GUI in Java2001-08-30 14:54:37.0
bad project managementcauses the average software projects to exceed its budge by 90% and its schedule by 120%2001-08-30 14:54:38.0
is a kind of project management2001-08-30 14:54:38.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:54:38.0
bad softwareis difficult to understand and modify2001-08-30 14:54:38.0
is poorly designed2001-08-30 14:54:38.0
is a kind of software2001-08-30 14:54:38.0
is a subtopic of 1.1 - The Nature of Software2001-08-30 14:54:38.0
can be easily created by an inadequately trained software developer2001-08-30 14:54:38.0
may partly work2001-08-30 14:54:38.0
base classis the name for superclass in C++2001-08-30 14:54:38.0
is a kind of class2001-08-30 14:54:38.0
is a subtopic of 2.5 - Organizing Classes Into Inheritance Hierarchies2001-08-30 14:54:38.0
is a synonym of superclass2001-08-30 14:54:38.0
beginning useris a kind of user2001-08-30 14:54:38.0
is a kind of user2001-08-30 14:54:38.0
is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:54:38.0
perceives that a system is easier to learn if the complex features are hidden from them initially by having separate 'beginner' and 'expert' interfaces2001-08-30 14:54:38.0
behaviourhas definition The way an object or system acts and reacts, possibly changing its state2001-08-30 14:54:38.0
is a kind of subject2001-08-30 14:54:38.0
is a subtopic of 2.2 - Classes and Objects2001-08-30 14:54:38.0
benefitis a kind of subject2001-08-30 14:54:39.0
is a subtopic of 9.3 - Techniques for Making Good Design Decisions2001-08-30 14:54:39.0
beta testerbenefits by using the features of the software before others have access to them2001-08-30 14:54:39.0
has definition A person performing beta testing2001-08-30 14:54:39.0
is a kind of tester2001-08-30 14:54:39.0
is a subtopic of 10.9 - Strategies for Testing Large Systems2001-08-30 14:54:39.0
is given a pre-release version of the software2001-08-30 14:54:39.0
is recruited from the potential user population of a product2001-08-30 14:54:39.0
knows that the software will contain more defects than the final version2001-08-30 14:54:39.0
reports problems when he or she discovers them2001-08-30 14:54:39.0
beta testinghas advantage
  • you typically are able to have a much larger volume of testing performed
  • the users use the software in the same manner that they will use it when it is formally released
2001-08-30 14:54:39.0
has definition Testing performed by the user or client in a normal work environment2001-08-30 14:54:39.0
is a kind of testing performed by users and clients2001-08-30 14:54:39.0
is a subtopic of 10.9 - Strategies for Testing Large Systems2001-08-30 14:54:39.0
Beyond the Teamhas author R.M. Belbin2001-08-30 14:54:39.0
has ISBN number 0-585-23086-22001-08-30 14:54:39.0
has URL www.netlibrary.com/summary.asp?id=34027    2001-08-30 14:54:39.0
is a subtopic of 11.8 - Managing the Software Process - References2001-08-30 14:54:39.0
is an instance of book about project management2001-08-30 14:54:39.0
was published by Butterworth-Heinermann2001-08-30 14:54:39.0
was published in 20002001-08-30 14:54:39.0
big bang testinghas definition An inappropriate approach to integration testing in which you take the entire integrated system and test it as a unit2001-08-30 14:54:39.0
is a kind of integration testing2001-08-30 14:54:39.0
is a subtopic of 10.9 - Strategies for Testing Large Systems2001-08-30 14:54:39.0
can work well on small systems2001-08-30 14:54:39.0
may not work well on larger systems because it may be hard to tell in which subsystem the defect lies when a failure occurs2001-08-30 14:54:39.0
black-box testerhas definition A person performing black-box testing2001-08-30 14:54:39.0
is a kind of tester2001-08-30 14:54:40.0
is a subtopic of 10.2 - Effective and Efficient Testing2001-08-30 14:54:39.0
observes outputs from the system2001-08-30 14:54:40.0
performs black-box testing2001-08-30 14:54:40.0
provides inputs to the system2001-08-30 14:54:40.0
does not see the source code, the internal data, nor any of the design documentation describing the system's internals2001-08-30 14:54:39.0
black-box testinghas definition A form of testing in which you manipulate inputs and observe outputs, but cannot observe the internals of the entity being tested2001-08-30 14:54:40.0
involves providing the system with inputs and observing the outputs, without seeing what is going on inside2001-08-30 14:54:40.0
is less time consuming than glass-box testing2001-08-30 14:54:40.0
is a kind of testing2001-08-30 14:54:40.0
is a subtopic of 10.2 - Effective and Efficient Testing2001-08-30 14:54:40.0
blind useris a kind of user with a disability2001-08-30 14:54:40.0
is a subtopic of 7.5 - Usability Principles2001-08-30 14:54:40.0
needs a program that converts text to Braille or speech2001-08-30 14:54:40.0
blockis a kind of programming language construct2001-08-30 14:54:40.0
is a subtopic of The Basics of Java2001-08-30 14:54:40.0
Blue Dawn Corporation: Software Testing Linkshas URL www.bluedawncomp.com/stlinks.htm    2001-08-30 14:54:40.0
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:54:40.0
is an instance of web site about software testing2001-08-30 14:54:40.0
bookhas author2001-08-30 14:54:40.0
has ISBN number2001-08-30 14:54:40.0
is a kind of publication2001-08-30 14:54:40.0
was published by publisher2001-08-30 14:54:40.0
was published in2001-08-30 14:54:40.0
book about design patternsis a kind of book2001-08-30 14:54:40.0
is a subtopic of 6.15 - Using Design Patterns - References2001-08-30 14:54:40.0
book about frameworksis a kind of book2001-08-30 14:54:40.0
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References2001-08-30 14:54:40.0
book about Java programmingis a kind of book about programming2001-08-30 14:54:41.0
is a subtopic of 2.11 - Review of Object Orientation and Java - References2001-08-30 14:54:40.0
book about modelling interactions and behaviouris a kind of book2001-08-30 14:54:41.0
book about networkingis a kind of book2001-08-30 14:54:41.0
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References2001-08-30 14:54:41.0
book about object oriented development processesis a kind of book2001-08-30 14:54:41.0
is a subtopic of 5.11 - Modelling With Classes - References2001-08-30 14:54:41.0
book about process standardsis a kind of book2001-08-30 14:54:41.0
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:54:41.0
book about programmingis a kind of book2001-08-30 14:54:41.0
book about project managementis a kind of book2001-08-30 14:54:41.0
is a subtopic of 11.8 - Managing the Software Process - References2001-08-30 14:54:41.0
book about requirements analysisis a kind of book2001-08-30 14:54:41.0
is a subtopic of 4.13 - Developing Requirements - References2001-08-30 14:54:41.0
book about software inspectionis a kind of book2001-08-30 14:54:41.0
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:54:41.0
book about software quality assuranceis a kind of book2001-08-30 14:54:41.0
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:54:41.0
book about software reuseis a kind of book2001-08-30 14:54:41.0
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References2001-08-30 14:54:41.0
book about software testingis a kind of book2001-08-30 14:54:41.0
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:54:41.0
book about UMLis a kind of book2001-08-30 14:54:41.0
is a subtopic of 5.11 - Modelling With Classes - References2001-08-30 14:54:41.0
book about user interfaces and usabilityis a kind of book2001-08-30 14:54:41.0
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References2001-08-30 14:54:41.0
booleanis a subtopic of The Basics of Java2001-08-30 14:54:41.0
is an instance of Java primitive data type2001-08-30 14:54:42.0
see also Boolean class2001-08-30 14:54:42.0
see also boolean^22001-08-30 14:54:42.0
can use == operatorlink: chapter2section2.8.html#604, 2001-08-30 14:54:41.0
Boolean classis a subtopic of The Basics of Java2001-08-30 14:54:42.0
is an instance of Java wrapper class2001-08-30 14:54:42.0
see also boolean2001-08-30 14:54:42.0
boolean^2is a subtopic of The Basics of Java2001-08-30 14:54:42.0
is an instance of Java keyword2001-08-30 14:54:42.0
see also boolean2001-08-30 14:54:42.0
Borland JBuilderhas URL www.borland.com/    2001-08-30 14:54:42.0
is a subtopic of 2.11 - Review of Object Orientation and Java - References2001-08-30 14:54:42.0
is an instance of programming environment2001-08-30 14:54:42.0
bottom-up approach to identifying generalizationsgroups similar classes creating a new superclass2001-08-30 14:54:42.0
is a subtopic of 5.8 - The Process Of Developing Class Diagrams2001-08-30 14:54:42.0
is an instance of approach to identifying generalizations2001-08-30 14:54:42.0
is an instance of bottom-up design2001-08-30 14:54:42.0
bottom-up designhas advantage normally useful so that reusable components can be created; these can then be used in several places in the overall system2001-08-30 14:54:42.0
has definition An approach to design in which you start by designing the low-level details such as the utilities, and then decide how these will be put together to create successively higher-level components, and ultimately the entire system2001-08-30 14:54:42.0
is a kind of design2001-08-30 14:54:42.0
is a subtopic of 9.1 - The Process of Design2001-08-30 14:54:42.0
bottom-up testinghas definition A incremental testing strategy in which you start by testing the very lowest levels of the software using drivers, and then work upwards, as you integrate successive layers2001-08-30 14:54:42.0
has disadvantage the cost of writing the drivers2001-08-30 14:54:42.0
has procedure start by testing the very lowest levels of the software using a driver2001-08-30 14:54:42.0
is a kind of vertical incremental testing2001-08-30 14:54:42.0
is a subtopic of 10.9 - Strategies for Testing Large Systems2001-08-30 14:54:42.0
boundary testinghas definition A testing strategy based on testing at the boundaries of equivalence classes - since this is where most errors occur2001-08-30 14:54:42.0
is a kind of testing2001-08-30 14:54:43.0
is a subtopic of 10.3 - Defects in Ordinary Algorithms2001-08-30 14:54:43.0
Brad Appleton's description of patternshas URL www.enteract.com/~bradapp/docs/patterns-intro.html    2001-08-30 14:54:43.0
is a subtopic of 6.15 - Using Design Patterns - References2001-08-30 14:54:43.0
is an instance of web site about design patterns2001-08-30 14:54:43.0
brainstorminghas advantages
  • in a group session people are energized and tend to spontaneously invent many good ideas, stimulated by what others have said
  • introverted or timid people can have their say effectively since anonymity can be assured
2001-08-30 14:54:43.0
has definition The process of obtaining ideas, opinions, and answers to a question in a group environment in which all members of the group are given the opportunity to contribute2001-08-30 14:54:43.0
has procedure
  1. Call a meeting with representation from all stakeholders
  2. Appoint an experienced moderator
  3. Arrange the attendees around the periphery of a table and give them plenty of paper to work with
  4. Decide on a trigger question
  5. Ask each participant to follow these instructions:
    1. Think of an answer to the trigger question
    2. Write the answer down in one or two lines on a sheet of paper, one idea per sheet
    3. Pass the paper to the neighbour on your left to stimulate their thoughts
    4. Look at the answers passed from your neighbour to the right and pass these on to your left as well. Use the ideas you have read to stimulate your own ideas
    5. Continue step 5 until ideas stop flowing or a fixed time (5-15 minutes) passes
    6. Ask everybody to read out one of the ideas on the sheets that happens to be in front of them. The moderator writes the each idea on a flip chart
    7. Take a series of votes to prioritize the ideas
2001-08-30 14:54:43.0
has purpose to gather information from a group of people2001-08-30 14:54:43.0
is a kind of requirements gathering2001-08-30 14:54:43.0
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements2001-08-30 14:54:43.0
is related to Joint Application Development2001-08-30 14:54:43.0
uses a moderator (or facilitator) to lead the session2001-08-30 14:54:43.0
can help resolve conflicts over requirements2001-08-30 14:54:43.0
should be done with five to 20 people2001-08-30 14:54:43.0
breakis a subtopic of The Basics of Java2001-08-30 14:54:43.0
is an instance of Java keyword2001-08-30 14:54:43.0
Bredemeyer's resources for software architectshas URL www.bredemeyer.com    2001-08-30 14:54:43.0
is a subtopic of 9.9 - Architecting and designing software - References2001-08-30 14:54:43.0
is an instance of web site about software architecture2001-08-30 14:54:43.0
British Standard 7925covers Software Testing2001-08-30 14:54:43.0
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:54:43.0
is an instance of quality assurance and testing standard2001-08-30 14:54:44.0
brokerallows an object to call methods of another object without knowing that this object is remotely located2001-08-30 14:54:44.0
distributes aspects of the software system to different nodes2001-08-30 14:54:44.0
facilitates divide and conquer since the remote objects can be independently designed2001-08-30 14:54:44.0
has definition An architectural pattern in which parts of the system are transparently distributed to different nodes of a network2001-08-30 14:54:44.0
increases cohesion because the remote objects have strong communicational cohesion2001-08-30 14:54:44.0
increases reusability because it is often possible to design the remote objects so that other systems can use them too2001-08-30 14:54:44.0
increases reuse because you may be able to reuse remote objects that others have created2001-08-30 14:54:44.0
is a kind of architectural pattern2001-08-30 14:54:44.0
is a subtopic of 9.5 - Architectural Patterns2001-08-30 14:54:44.0
brute forceis pointless because any given defect is likely to cause failures with many different input values2001-08-30 14:54:44.0
is a kind of testing strategy2001-08-30 14:54:44.0
is a subtopic of 10.2 - Effective and Efficient Testing2001-08-30 14:54:44.0
takes such a huge amount of time so as to be impractical2001-08-30 14:54:44.0
tests a method using every possible value2001-08-30 14:54:44.0
budgeted cost of work performedis a synonym of earned value2001-08-30 14:54:44.0
bughas definition A colloquial term for defect or failure2001-08-30 14:54:44.0
is a synonym of defect2001-08-30 14:54:44.0
is a synonym of failure2001-08-30 14:54:44.0
buildhas definition The process of compiling and integrating all the components of the software, incorporating any changes since the last build2001-08-30 14:54:44.0
involves compiling and integrating all the components of the software, incorporating any changes since the last time this was done2001-08-30 14:54:44.0
is a kind of process2001-08-30 14:54:44.0
is a subtopic of 10.9 - Strategies for Testing Large Systems2001-08-30 14:54:44.0
may be done on a daily or weekly basis2001-08-30 14:54:45.0
burdened costis a synonym of weighted average cost2001-08-30 14:54:45.0
Business Modelling with UML: Business Patterns at Workhas author H-E. Eriksson and M. Penker2001-08-30 14:54:45.0
has ISBN number ISBN 0-471-29551-52001-08-30 14:54:45.0
is a subtopic of 6.15 - Using Design Patterns - References2001-08-30 14:54:45.0
is an instance of book about design patterns2001-08-30 14:54:45.0
was published by Wiley2001-08-30 14:54:45.0
was published in 20002001-08-30 14:54:45.0
business processhas definition A process performed by people in an organization2001-08-30 14:54:45.0
is a kind of process2001-08-30 14:54:45.0
is a subtopic of 4.9 - Managing Changing Requirements2001-08-30 14:54:45.0
business process changehas definition A change to the way a business does things2001-08-30 14:54:45.0
is common2001-08-30 14:54:45.0
is a kind of change2001-08-30 14:54:45.0
is a subtopic of 4.9 - Managing Changing Requirements2001-08-30 14:54:45.0
may be prompted by a desire to better compete in the market, experience, decisions to use alternative approaches, changes in laws, as well as growth or rearrangement of the company2001-08-30 14:54:45.0
may force changes in a requirement2001-08-30 14:54:45.0
business processmay be automated by software system2001-08-30 14:54:45.0
buttonaffords clicking if clicking on it would cause some action to occur.2001-08-30 14:54:45.0
is a kind of user interface component2001-08-30 14:54:45.0
is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:54:45.0
byteis a subtopic of The Basics of Java2001-08-30 14:54:45.0
is an instance of Java primitive data type2001-08-30 14:54:45.0
requires 8 bitslink: chapter2section2.8.html#566, 2001-08-30 14:54:45.0
see also Byte classlink: chapter2section2.8.html#615, 2001-08-30 14:54:45.0
see also byte^22001-08-30 14:54:45.0
can use basic arithmetic operators +, -, *, / and %link: chapter2section2.8.html#578, 2001-08-30 14:54:45.0
Byte classis a subtopic of The Basics of Java2001-08-30 14:54:46.0
is an instance of Java wrapper class2001-08-30 14:54:46.0
see also bytelink: chapter2section2.8.html#615, 2001-08-30 14:54:46.0
byteshould not be used for textual data which is to be exposed to the end userlink: chapter2section2.8.html#820, 2001-08-30 14:54:45.0
byte^2is a subtopic of The Basics of Java2001-08-30 14:54:46.0
is an instance of Java keyword2001-08-30 14:54:46.0
see also byte2001-08-30 14:54:46.0
bytecodeis like a universal machine languagelink: chapter2section2.8.html#508, 2001-08-30 14:54:46.0
is a kind of code2001-08-30 14:54:46.0
is a subtopic of The Basics of Java2001-08-30 14:54:46.0
is not designed to be read by human beingslink: chapter2section2.8.html#508, 2001-08-30 14:54:46.0
can run on any computer that has an interpreter called a virtual machinelink: chapter2section2.8.html#509, 2001-08-30 14:54:46.0
C compilercompiles source code into machine codelink: chapter2section2.8.html#521, 2001-08-30 14:54:46.0
is a kind of compiler2001-08-30 14:54:46.0
is a subtopic of The Basics of Java2001-08-30 14:54:46.0
C fileis a kind of C module2001-08-30 14:54:46.0
is a kind of file2001-08-30 14:54:46.0
is a subtopic of 9.1 - The Process of Design2001-08-30 14:54:46.0
C functionis a kind of C module2001-08-30 14:54:46.0
is a kind of function2001-08-30 14:54:46.0
is a subtopic of 9.1 - The Process of Design2001-08-30 14:54:46.0
C moduleis a kind of module2001-08-30 14:54:46.0
is a subtopic of 9.1 - The Process of Design2001-08-30 14:54:46.0
C++adds object oriented extensions to C2001-08-30 14:54:46.0
has much the same syntax as Clink: chapter2section2.8.html#500, 2001-08-30 14:54:46.0
has disadvantages
  • its syntax is quite complex
  • it is too easy to create code that has bugs
  • large C++ programs have thus been found to be hard to maintain - they deteriorate rapidly as many programmers make changes
2001-08-30 14:54:47.0
has feature macroslink: chapter2section2.8.html#514, 2001-08-30 14:54:47.0
has feature multiple inheritancelink: chapter2section2.8.html#492, 2001-08-30 14:54:47.0
has feature operator overloadinglink: chapter2section2.8.html#514, 2001-08-30 14:54:47.0
has feature pointer arithmeticlink: chapter2section2.8.html#514, 2001-08-30 14:54:47.0
is the most widely used object oriented language2001-08-30 14:54:47.0
is a subtopic of The Basics of Java2001-08-30 14:54:47.0
is an instance of object oriented language2001-08-30 14:54:47.0
was developed by Bjarne Stroustrup2001-08-30 14:54:47.0
C++ compilercompiles source code into machine codelink: chapter2section2.8.html#521, 2001-08-30 14:54:47.0
is a kind of compiler2001-08-30 14:54:47.0
is a subtopic of The Basics of Java2001-08-30 14:54:47.0
C++ source codeis a kind of source code2001-08-30 14:54:47.0
is a subtopic of The Basics of Java2001-08-30 14:54:47.0
may be placed outside a classlink: chapter2section2.8.html#757, 2001-08-30 14:54:47.0
Cadillac systemhas definition A system that does more than is needed2001-08-30 14:54:47.0
is a kind of software system2001-08-30 14:54:47.0
is a subtopic of 4.8 - Reviewing Requirements2001-08-30 14:54:47.0
calendarhas localization issues
  • although international business is based on the Gregorian calendar, the calendars of certain cultures and religions are also used in some places
2001-08-30 14:54:47.0
is a kind of locale-dependent feature2001-08-30 14:54:47.0
is a subtopic of 7.5 - Usability Principles2001-08-30 14:54:47.0
Calendar classallows for the use of calendars of specific cultures2001-08-30 14:54:47.0
is a subtopic of 7.5 - Usability Principles2001-08-30 14:54:47.0
is an instance of Java class2001-08-30 14:54:47.0
can-be-seen-as relationcharacterizes the relation between the implementing class and the interface2001-08-30 14:54:48.0
has example classes representing bank employees and automatic teller machines - both can be seen as a sort of cashier2001-08-30 14:54:48.0
is a kind of relation2001-08-30 14:54:48.0
is a subtopic of 5.6 - More Advanced Features of Class Diagrams2001-08-30 14:54:48.0
caseis a subtopic of The Basics of Java2001-08-30 14:54:48.0
is an instance of Java keyword2001-08-30 14:54:48.0
castinghas example
(String)i.next()
link: chapter2section2.8.html#870, 2001-08-30 14:54:48.0
has purpose to convert an instance of one data type into another which is a subclass of the original type2001-08-30 14:54:48.0
is a kind of process2001-08-30 14:54:48.0
is a subtopic of The Basics of Java2001-08-30 14:54:48.0
catalog of reusable componentscontains information about reusable components2001-08-30 14:54:48.0
is a kind of document2001-08-30 14:54:48.0
is a subtopic of 3.2 - Incorporating Reusability and Reuse Into Software Engineering2001-08-30 14:54:48.0
must be easy to search2001-08-30 14:54:48.0
must be kept up-to-date2001-08-30 14:54:48.0
must deprecate older components that have been found to be unreliable or have been superseded by better components2001-08-30 14:54:48.0
catchis a subtopic of The Basics of Java2001-08-30 14:54:48.0
is an instance of Java keyword2001-08-30 14:54:48.0
Cetus Links on UMLhas URL www.cetus-links.org/oo_uml.html    2001-08-30 14:54:48.0
is a subtopic of 5.11 - Modelling With Classes - References2001-08-30 14:54:48.0
is an instance of web site about UML2001-08-30 14:54:49.0
changeis a kind of subject2001-08-30 14:54:49.0
is a subtopic of 4.9 - Managing Changing Requirements2001-08-30 14:54:49.0
change to requirementshas unpredictable rate2001-08-30 14:54:49.0
is a kind of change2001-08-30 14:54:49.0
is a subtopic of 4.9 - Managing Changing Requirements2001-08-30 14:54:49.0
can be rapid2001-08-30 14:54:49.0
can cause requirements creep2001-08-30 14:54:49.0
can result in a deteriorating design if the original design did adequately anticipate the changes2001-08-30 14:54:49.0
can result in completed work being wasted2001-08-30 14:54:49.0
should not make the system bigger2001-08-30 14:54:49.0
should only be made if benefits exceed the costs2001-08-30 14:54:49.0
Chapter 1 - Software and Software Engineeringis a subtopic of kbTop2001-08-30 14:54:49.0
Chapter 10 - Testing and Inspecting to Ensure High Qualityis a subtopic of kbTop2001-08-30 14:54:49.0
Chapter 11 - Managing the Software Processis a subtopic of kbTop2001-08-30 14:54:49.0
Chapter 2 - Review of Object Orientationis a subtopic of kbTop2001-08-30 14:54:49.0
Chapter 3 - Basing Software Development on Reusable Technologyis a subtopic of kbTop2001-08-30 14:54:49.0
Chapter 4 - Developing Requirementsis a subtopic of kbTop2001-08-30 14:54:49.0
Chapter 5 - Modelling With Classesis a subtopic of kbTop2001-08-30 14:54:49.0
Chapter 6 - Using Design Patternsis a subtopic of kbTop2001-08-30 14:54:49.0
Chapter 7 - Focusing on Users and Their Tasksis a subtopic of kbTop2001-08-30 14:54:49.0
Chapter 8 - Modelling Interactions and Behaviouris a subtopic of kbTop2001-08-30 14:54:49.0
Chapter 9 - Architecting and designing softwareis a subtopic of kbTop2001-08-30 14:54:49.0
charis a subtopic of The Basics of Java2001-08-30 14:54:49.0
is an instance of Java primitive data type2001-08-30 14:54:49.0
see also char^22001-08-30 14:54:49.0
see also Character2001-08-30 14:54:49.0
can use basic arithmetic operators +, -, *, / and %link: chapter2section2.8.html#578, 2001-08-30 14:54:49.0
char^2is a subtopic of The Basics of Java2001-08-30 14:54:49.0
is an instance of Java keyword2001-08-30 14:54:49.0
see also char2001-08-30 14:54:49.0
Characteris a subtopic of The Basics of Java2001-08-30 14:54:50.0
is an instance of Java wrapper class2001-08-30 14:54:50.0
see also char2001-08-30 14:54:50.0
character sethas localization issues
  • Unicode can handle most world character sets, but you also have to ensure that appropriate fonts are available
2001-08-30 14:54:50.0
is a kind of locale-dependent feature2001-08-30 14:54:50.0
is a subtopic of 7.5 - Usability Principles2001-08-30 14:54:50.0
Chartered Engineerhas definition A term used in the United Kingdom, and certain other jurisdictions, that is equivalent to professional engineer2001-08-30 14:54:50.0
is a kind of engineer2001-08-30 14:54:50.0
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession2001-08-30 14:54:50.0
chemical engineeringis a kind of engineering2001-08-30 14:54:50.0
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession2001-08-30 14:54:50.0
chief programmer teamadvocates that the chief programmer leads and guides the project; however he consults with, and relies on, individual specialists2001-08-30 14:54:50.0
has definition A team structure midway between a hierarchical team and an egoless team, in which a chief programmer leads and guides the project, in consultation with experts in various specialties2001-08-30 14:54:50.0
is like a surgical team2001-08-30 14:54:50.0
is a kind of software engineering team model2001-08-30 14:54:50.0
is a subtopic of 11.4 - Building Software Engineering Teams2001-08-30 14:54:50.0
civil engineeringis a kind of engineering2001-08-30 14:54:50.0
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession2001-08-30 14:54:50.0
classcontains all of the code that relates to its objects including
  • code describing how the objects of the class are structured - i.e. the data stored in each object that implement the properties
  • The procedures, called methods, that implement the behaviour of the objects
2001-08-30 14:54:50.0
contains data associated with each object2001-08-30 14:54:50.0
declares a list of variables, called instance variables, corresponding to data that will be present in each instance2001-08-30 14:54:50.0
has definition A software module that provides both procedural and data abstraction. It describes a set of similar objects, called its instances2001-08-30 14:54:50.0
has part class name2001-08-30 14:54:50.0
has part class variable2001-08-30 14:54:50.0
has part code2001-08-30 14:54:50.0
has part constructorlink: chapter2section2.8.html#761, 2001-08-30 14:54:50.0
has part instance variable2001-08-30 14:54:50.0
has part method2001-08-30 14:54:51.0
has part variables2001-08-30 14:54:51.0
is an abstract representation of all the instances of that class that may ever exist2001-08-30 14:54:51.0
is probably useless if it has no responsibilities attached to it2001-08-30 14:54:51.0
is the unit of data abstraction in an object-oriented program2001-08-30 14:54:51.0
is a kind of data abstraction2001-08-30 14:54:51.0
is a kind of programming language construct2001-08-30 14:54:51.0
is a subtopic of 2.2 - Classes and Objects2001-08-30 14:54:51.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:54:51.0
is divided up into methods2001-08-30 14:54:51.0
is drawn as a box with the name of the class inside in a UML class diagram2001-08-30 14:54:51.0
is needed in a domain model if you have to store or manipulate instances of it in order to implement a requirement2001-08-30 14:54:51.0
represents several similar objects2001-08-30 14:54:51.0
see also class^22001-08-30 14:54:51.0
can have instances2001-08-30 14:54:50.0
class designhas definition The design of the various features of classes such as associations, attributes, interactions and states2001-08-30 14:54:51.0
is a kind of design2001-08-30 14:54:51.0
is a subtopic of 9.1 - The Process of Design2001-08-30 14:54:51.0
class diagramdescribes the data found in a software system2001-08-30 14:54:51.0
has definition A UML diagram that primarily indicates classes and the associations between those classes2001-08-30 14:54:51.0
has part OCL statement in a class diagram2001-08-30 14:54:51.0
is an important tool for requirements analysis and design of object oriented software systems2001-08-30 14:54:51.0
is a kind of UML diagram2001-08-30 14:54:51.0
is a subtopic of 5.1 - What is UML?2001-08-30 14:54:51.0
shows the services offered by components and the main data to be stored2001-08-30 14:54:51.0
can contain symbols for classes, associations, attributes, operations, generalizations2001-08-30 14:54:51.0
can generate an infinite number of instance diagrams2001-08-30 14:54:51.0
may show attributes and operations contained in each class by dividing a class box into three smaller boxes: the top box contains the class name, the middle box lists the attributes, and the bottom box lists operations.2001-08-30 14:54:51.0
may show that a class has no attributes or operations by showing an empty box2001-08-30 14:54:51.0
class methodhas definition A method that, unlike an instance method, does not execute in the context of a particular instance of a class2001-08-30 14:54:51.0
has purpose implementing functions such as initializing a class, or operating on the complete set of instances of a class2001-08-30 14:54:51.0
is a kind of method2001-08-30 14:54:52.0
is a subtopic of The Basics of Java2001-08-30 14:54:51.0
is a synonym of static method2001-08-30 14:57:47.0
should not be overused2001-08-30 14:54:52.0
class nameis a kind of name2001-08-30 14:54:52.0
is a subtopic of 5.8 - The Process Of Developing Class Diagrams2001-08-30 14:54:52.0
is written in the singular by convention2001-08-30 14:54:52.0
can be chosen from nouns or noun phrases in source material unless they are
  1. redundant
  2. represent instances
  3. are vague or general
  4. correspond to classes that are not needed for this application or this type of model
2001-08-30 14:54:52.0
should be a noun by convention2001-08-30 14:54:52.0
should not be too general or too specific2001-08-30 14:54:52.0
classshould be created to hold a responsibility if the responsibility cannot be attributed to any of the existing classes2001-08-30 14:54:51.0
should be named after things their instances represent in the real world2001-08-30 14:54:51.0
should have a comment at the top describing the purpose of the class, how it should be used, its authors and its history of modification2001-08-30 14:54:51.0
should not be named after the internals of a computer system such as 'Record', 'Table', 'Data', 'Structure', or 'Information'2001-08-30 14:54:51.0
class symbolis a kind of symbol in UML diagram2001-08-30 14:54:52.0
is a subtopic of 5.2 - Essentials of UML Class Diagrams2001-08-30 14:54:52.0
class variablehas a value that is shared by all instances of a class2001-08-30 14:54:52.0
has definition A data item present in a class that is shared by all instances of that class2001-08-30 14:54:52.0
has purpose storing:
  • Default or 'constant' values that are widely used by methods in a class
  • Lookup tables and similar structures used by algorithms inside a particular class
2001-08-30 14:54:52.0
is a kind of variable2001-08-30 14:54:52.0
is a subtopic of The Basics of Java2001-08-30 14:54:52.0
is a synonym of static variable2001-08-30 14:57:47.0
is shared by all instances of the class2001-08-30 14:54:52.0
should not be overused2001-08-30 14:54:52.0
class^2is a subtopic of The Basics of Java2001-08-30 14:54:52.0
is an instance of Java keyword2001-08-30 14:54:52.0
see also class2001-08-30 14:54:52.0
Classical and Object Oriented Software Engineering, with UML and C++/Javahas author S. Schach2001-08-30 14:54:52.0
has ISBN number 0-07-230226-72001-08-30 14:54:52.0
has web site www.mhhe.com/engcs/compsci/schach/    2001-08-30 14:54:52.0
is a subtopic of 1.10 - Software and Software Engineering - References2001-08-30 14:54:52.0
is an instance of software engineering book2001-08-30 14:54:52.0
was published by McGraw Hill2001-08-30 14:54:52.0
was published in 19992001-08-30 14:54:52.0
clicking a buttonis a kind of command2001-08-30 14:54:52.0
is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:54:52.0
clientis a synonym of customer2001-08-30 14:54:52.0
see also client2001-08-30 14:54:52.0
client-server architecturehas advantages
  • The computational work can be distributed among different machines
  • The clients can access the server's functionality from a distance
  • The client and server can be designed separately, so they can both be simpler than a program that does everything
  • All the data can be kept centrally at the server, thus making it easier to assure its reliability
  • Conversely, distributing data among many different geographically-distributed clients or servers can mean that if a disaster occurs in one place, the loss of data is minimized
  • The server can be accessed simultaneously by many clients
  • Competing clients can be written to communicate with the same server, and vice-versa
2001-08-30 14:54:53.0
has alternatives
  • Have a single program on one computer that does everything
  • Avoid having any communication and have each computer perform the work separately
  • Have some mechanism other than client-server communication for exchanging information
2001-08-30 14:54:53.0
has definition An architectural pattern in which the system is divided into clients and servers2001-08-30 14:54:53.0
is one of the most widely used ways of structuring software systems2001-08-30 14:54:53.0
is a kind of distributed architecture2001-08-30 14:54:53.0
is a subtopic of 3.4 - The Client-Server Architecture2001-08-30 14:54:53.0
is a subtopic of 9.5 - Architectural Patterns2001-08-30 14:54:53.0
client-server architecture in Webopediahas URL webopedia.internet.com/TERM/c/client_server_architecture.html    2001-08-30 14:54:53.0
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References2001-08-30 14:54:53.0
is an instance of web site about the client-server architecture2001-08-30 14:54:53.0
client-server newsgrouphas address news:comp.client-server2001-08-30 14:54:53.0
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References2001-08-30 14:54:53.0
is an instance of newsgroup2001-08-30 14:54:53.0
client-server systemgenerally uses multiple threads of control that can be concurrently executed to implement concurrent operations, otherwise when the client is waiting for one kind of input, it will not be able to respond to the other kind of input2001-08-30 14:54:53.0
has interaction
  1. The server starts running
  2. The server listens for clients wanting to connect
  3. Clients start running and perform various operations, some of which require connecting to the server to request a service
  4. When a client attempts to connect, the server accepts the connection if it is willing
  5. The server waits for messages to arrive from connected clients
  6. When a message from a client arrives, the server takes some action in response, such as sending a message back to the client, then resumes waiting
  7. Clients and servers continue functioning in this manner until one of them decides to shut down
2001-08-30 14:54:53.0
has problem developers of clients are frequently forced to upgrade their clients whenever the server is changed if clients and servers are developed by different organizations2001-08-30 14:54:54.0
involves at least one server and one client2001-08-30 14:54:54.0
is inherently concurrent because the server runs concurrently with the clients, normally (but not necessarily) on different computers2001-08-30 14:54:54.0
is prone to security violations, due to the fact that information is transmitted over a network2001-08-30 14:54:54.0
is vulnerable to interruptions in communication or denial-of-service attacks2001-08-30 14:54:54.0
is a kind of distributed system2001-08-30 14:54:54.0
is a subtopic of 3.4 - The Client-Server Architecture2001-08-30 14:54:54.0
should be forward-compatible and backward-compatible with other versions of clients and servers by designing the client-server protocols to be very general and flexible2001-08-30 14:54:54.0
should incorporate encryption, firewalls and similar methods of ensuring security2001-08-30 14:54:54.0
client^2does concurrently
  • Waiting for interactions with the end-user, and responding when interactions occur
  • Waiting for messages coming from the server, and responding when messages arrive
2001-08-30 14:54:52.0
handles the disconnection of the server, because the server crashed or the network failed or because either the client or server requested disconnection2001-08-30 14:54:52.0
has definition A program or process that connects to another program or process, using a communication channel, in order to request a service2001-08-30 14:54:52.0
initializes itself so it is able to communicate with the server2001-08-30 14:54:53.0
initiates a connection to a server2001-08-30 14:54:53.0
is a kind of process^22001-08-30 14:54:53.0
is a kind of program2001-08-30 14:54:53.0
is a subtopic of 3.4 - The Client-Server Architecture2001-08-30 14:54:53.0
reacts to messages coming from the server2001-08-30 14:54:53.0
see also client^22001-08-30 14:54:53.0
sends messages to the server to request services2001-08-30 14:54:53.0
terminates cleanly including includes disconnecting from a server if it is still connected2001-08-30 14:54:53.0
can also be a server at the same time2001-08-30 14:54:52.0
cannot connect with a server unless the server is listening2001-08-30 14:54:52.0
may access many servers to perform different functions2001-08-30 14:54:53.0
may be located on the same computer as its server or on a different computer2001-08-30 14:54:53.0
may try again to connect to the server if the server does not initially respond2001-08-30 14:54:53.0
must know the network address of the server2001-08-30 14:54:53.0
cloninghas definition The practice of duplicating chunks of code; considered bad practice except when copying just one or two lines of code2001-08-30 14:54:54.0
is a synonym of duplication of code2001-08-30 14:54:54.0
CMMis a subtopic of 10.11 - Quality Assurance in General2001-08-30 14:54:54.0
is an abbreviation for Software Capability Maturity Model2001-08-30 14:54:54.0
is an instance of abbreviation2001-08-30 14:54:54.0
CMM in Practice: Processes for Executing Software Projects at Infosyshas author P. Jalote2001-08-30 14:54:54.0
has ISBN number 0-201-61626-22001-08-30 14:54:54.0
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:54:54.0
is an instance of book about process standards2001-08-30 14:54:54.0
was published by Addison-Wesley2001-08-30 14:54:54.0
was published in 19992001-08-30 14:54:54.0
COCOMOis a subtopic of 11.3 - Cost Estimation2001-08-30 14:54:55.0
is an abbreviation for Constructive Cost Model2001-08-30 14:54:54.0
is an instance of abbreviation2001-08-30 14:54:55.0
codeis a kind of representation2001-08-30 14:54:55.0
code layout principleis a kind of principle2001-08-30 14:54:55.0
is a subtopic of Programming Style Guidelines2001-08-30 14:54:55.0
can be found at Sun    2001-08-30 14:54:55.0
coderhas definition A programmer who limits their work to programming (i.e. who do no higher-level design or analysis)2001-08-30 14:54:55.0
is a kind of programmer2001-08-30 14:54:55.0
is a subtopic of 1.7 - Activities Common to Software Projects2001-08-30 14:54:55.0
does not do high-level analysis and design2001-08-30 14:54:55.0
CodeWarriorhas URL metrowerks.com    2001-08-30 14:54:55.0
is a subtopic of 2.11 - Review of Object Orientation and Java - References2001-08-30 14:54:55.0
is an instance of programming environment2001-08-30 14:54:55.0
coding schemeis a kind of subject2001-08-30 14:54:55.0
coding techniquehas advantages2001-08-30 14:54:55.0
has definition A way of representing information so as to communicate it to the user; e.g. using text, colour, icons, grouping, sound etc.2001-08-30 14:54:55.0
has problems2001-08-30 14:54:55.0
is a kind of representation2001-08-30 14:54:55.0
is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:54:55.0
is a synonym of encoding technique2001-08-30 14:55:28.0
cohesionhas definition A measure of the extent to which related aspects of a system are kept together in the same module, and unrelated aspects are kept out2001-08-30 14:54:55.0
has precedence table
Cohesion typeComments
functional cohesionIf an aspect of a design can be achieved using a functionally cohesive module then it is normally best to do so.
layer cohesionLayer cohesion should typically have higher priority. Dividing systems into layers has been shown to considerably simplify systems.
communicational cohesionCommunicational cohesion, as embodied in the classes of an object oriented system, should have high priority. Here we list it below layer cohesion since modules may access the same kind of data in different layers.
sequential cohesionSequential cohesion is effectively a strong form of temporal cohesion, but is weaker than communicational cohesion since different data types may be involved in the different stages of a sequentially cohesive module.
temporal cohesionTemporal cohesion should typically be considered weaker than other types of cohesion. It is important, but only if the other types of cohesion have been achieved.
utility cohesionUtility cohesion is the weakest kind of cohesion since it serves to group together those parts of the system that do not seem to logically belong anywhere else.
2001-08-30 14:54:55.0
is a kind of measurement2001-08-30 14:54:55.0
is a kind of software quality2001-08-30 14:54:56.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:54:55.0
cohesive moduleis a kind of module2001-08-30 14:54:56.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:54:56.0
can contain sub-modules with different types of cohesion2001-08-30 14:54:56.0
can use the services of other modules without reducing cohesion, as long as the services of the other modules are not doing things that should be in the cohesive module2001-08-30 14:54:56.0
collaborationis a kind of abstraction2001-08-30 14:54:56.0
is a subtopic of 8.1 - Interaction Diagrams2001-08-30 14:54:56.0
can be represented in a class diagram using a dashed ellipse2001-08-30 14:54:56.0
collaboration diagramcontains a communication link between each pair of objects involved in the sending of a message; the messages themselves are attached to this link2001-08-30 14:54:56.0
has definition A UML interaction diagram showing a set of objects connected by communications links2001-08-30 14:54:56.0
has part communication link2001-08-30 14:54:56.0
is better than sequence diagram when you are deriving an interaction diagram from a class diagram2001-08-30 14:54:56.0
is similar to an instance diagram except that it does not show links of associations2001-08-30 14:54:56.0
is a kind of interaction diagram2001-08-30 14:54:56.0
is a subtopic of 5.1 - What is UML?2001-08-30 14:54:56.0
is drawn as as a graph with a set of objects and actors as the vertices2001-08-30 14:54:56.0
shows the relationships that exist among objects and actors2001-08-30 14:54:56.0
can help validate class diagrams2001-08-30 14:54:56.0
can represent aspects of a design pattern2001-08-30 14:54:56.0
collaboration symbolis a kind of symbol in UML diagram2001-08-30 14:54:56.0
is a subtopic of 8.1 - Interaction Diagrams2001-08-30 14:54:56.0
is drawn as a dashed ellipse2001-08-30 14:54:56.0
is linked to classes that fulfill the various roles of the collaboration by dashed lines2001-08-30 14:54:56.0
collating sequencehas definition The order in which the letters of the alphabet are sorted2001-08-30 14:54:56.0
has localization issues
  • Some languages place accented versions of characters at the end of an alphabet, whereas others consider that they should appear in the same place as unaccented characters in the sort order
2001-08-30 14:54:56.0
is a kind of locale-dependent feature2001-08-30 14:54:56.0
is a subtopic of 7.5 - Usability Principles2001-08-30 14:54:56.0
colourhas advantages
  • draws attention to specific items
  • conveys organization (items coloured similarly are related)
  • makes the UI more attractive
2001-08-30 14:54:56.0
has problems
  • users cannot distinguish among large numbers of colours
  • some colour combinations clash
  • colour-blind people cannot see differences in hue
  • some colours (e.g. bright red) can be distracting if overused
  • colours may have unexpected emotional meanings to users (e.g. a sickly shade of green)
2001-08-30 14:54:56.0
is a kind of coding technique2001-08-30 14:54:56.0
is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:54:56.0
COMis a subtopic of 9.5 - Architectural Patterns2001-08-30 14:54:57.0
is an instance of broker2001-08-30 14:54:57.0
combinatorial explosionhas definition In the context of testing, the observation that the number of required tests for exhaustive testing will increase exponentially as the number of inputs increases2001-08-30 14:54:57.0
is a kind of subject2001-08-30 14:54:57.0
is a subtopic of 10.3 - Defects in Ordinary Algorithms2001-08-30 14:54:57.0
commandhas definition An action that causes the system to perform some computations2001-08-30 14:54:57.0
is a kind of action2001-08-30 14:54:57.0
is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:54:57.0
commenthas purpose to describe the purpose of each class, method and variable along with any difficult-to-understand statements inside methods, and to indicated any changes to the code2001-08-30 14:54:57.0
is essential to give readers an overview and to help them understand its complexities quickly2001-08-30 14:54:57.0
is a kind of programming language construct2001-08-30 14:54:57.0
is a subtopic of Programming Style Guidelines2001-08-30 14:54:57.0
can be written before writing the code2001-08-30 14:54:57.0
should be between about 20% and 35% of the total length of the code2001-08-30 14:54:57.0
should be written to describe each non-obvious variable2001-08-30 14:54:57.0
should be written to describe loops and conditional statements inside complex algorithms2001-08-30 14:54:57.0
should be written at the head of each non-obvious method describing its function and usage2001-08-30 14:54:57.0
should be written at the top of each class2001-08-30 14:54:57.0
should describe the purpose of the class, how it should be used, its authors and its history of modification2001-08-30 14:54:57.0
should not be about obvious things since they add clutter2001-08-30 14:54:57.0
commentingaffects maintainability2001-08-30 14:54:57.0
affects indirectly reliability2001-08-30 14:54:57.0
is a kind of internal software quality2001-08-30 14:54:57.0
is a subtopic of 1.5 - Software Quality2001-08-30 14:54:57.0
is measured as as the fraction of total lines in the source code that are comments2001-08-30 14:54:57.0
commercial off-the-shelf softwarehas definition A term for generic software, often abbreviated as COTS2001-08-30 14:54:57.0
is a synonym of generic software2001-08-30 14:54:57.0
is abbreviated as COTS2001-08-30 14:54:57.0
common couplinghas definition A form of coupling in which components share data using a global variable and thus become dependent on each other2001-08-30 14:54:57.0
is a kind of coupling2001-08-30 14:54:58.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:54:58.0
shares many of the disadvantages of content coupling2001-08-30 14:54:58.0
can be avoided by creating a module that has specially-designated public methods, which can be called to obtain or modify the system-wide default values2001-08-30 14:54:57.0
should be minimized2001-08-30 14:54:58.0
Common Object Request Broker Architecturehas definition A well-known standard broker architecture2001-08-30 14:54:58.0
is a subtopic of 9.5 - Architectural Patterns2001-08-30 14:54:58.0
is abbreviated as CORBA2001-08-30 14:54:58.0
is an instance of broker2001-08-30 14:54:58.0
communication linkhas definition In a collaboration diagram, a line drawn between each pair of objects involved in the sending of a message2001-08-30 14:54:58.0
is a kind of symbol in collaboration diagram2001-08-30 14:54:58.0
is a subtopic of 8.1 - Interaction Diagrams2001-08-30 14:54:58.0
can exist between two objects whenever it is possible for one object to send a message to the other one, including the following situations:
  • The classes of the two objects are joined by an association
  • The receiving object is stored in a local variable of the sending method (but the objects are not yet joined by an association)
  • A reference to the receiving object has been received as a parameter of an earlier message to the sender
  • The receiving object is global
  • The objects communicate over a network
2001-08-30 14:54:58.0
does not necessarily correspond to instances of associations (i.e. links) in a class diagram2001-08-30 14:54:58.0
communication systemcontains layers in order from bottom to top
  • facilities for transmitting and receiving signals
  • is a layer that deals with splitting messages into packets and reconstructing messages that are received
  • a layer that deals with handling ongoing connections with a remote host
  • a layer that handles various protocols used by application programs such as http
2001-08-30 14:54:58.0
has clients a program that allows users to send a message or maintain a conversation with users on another computer2001-08-30 14:54:58.0
has server a program that routes messages and can have features such as 'forwarding' that people are familiar with from the telephone network2001-08-30 14:54:58.0
is a kind of client-server system2001-08-30 14:54:58.0
is a kind of multi-layer system2001-08-30 14:54:58.0
is a subtopic of 3.4 - The Client-Server Architecture2001-08-30 14:54:58.0
is a subtopic of 9.5 - Architectural Patterns2001-08-30 14:54:58.0
communicational cohesionhas definition A form of cohesion in which procedures that access the same data are kept together2001-08-30 14:54:58.0
is more important than sequential cohesion2001-08-30 14:54:58.0
is a kind of cohesion2001-08-30 14:54:58.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:54:58.0
is helped by the object oriented paradigm2001-08-30 14:54:58.0
Communications of the ACMhas web site www.acm.org    2001-08-30 14:54:58.0
is a subtopic of 1.10 - Software and Software Engineering - References2001-08-30 14:54:58.0
is an instance of magazine2001-08-30 14:54:59.0
is published by the Association for Computing Machinery2001-08-30 14:54:59.0
Community for Software Engineershas URL www.software-engineer.org    2001-08-30 14:54:59.0
is a subtopic of 1.10 - Software and Software Engineering - References2001-08-30 14:54:59.0
is an instance of software engineering web site2001-08-30 14:54:59.0
compilationhas definition The process of translating source code into code that is executable by a computer2001-08-30 14:54:59.0
is a kind of process2001-08-30 14:54:59.0
is a subtopic of The Basics of Java2001-08-30 14:54:59.0
compilerhas purpose to translate source code into code that is executable by a computer2001-08-30 14:54:59.0
is a kind of program2001-08-30 14:54:59.0
is a subtopic of The Basics of Java2001-08-30 14:54:59.0
performs compilation2001-08-30 14:54:59.0
complex conditionis a kind of condition2001-08-30 14:54:59.0
is a subtopic of Programming Style Guidelines2001-08-30 14:54:59.0
should be avoided because it is difficult to read2001-08-30 14:54:59.0
should be divided into several separate conditions on separate lines2001-08-30 14:54:59.0
complex Java conditionhas example
 if(a==5 &&(b>40 \ c) && (d > a+2 \ e==5)) ...
2001-08-30 14:54:59.0
is a kind of complex condition2001-08-30 14:54:59.0
is a kind of Java condition2001-08-30 14:54:59.0
is a subtopic of Programming Style Guidelines2001-08-30 14:54:59.0
complexity of codeaffects maintainability2001-08-30 14:54:59.0
affects reliability2001-08-30 14:54:59.0
is a kind of internal software quality2001-08-30 14:54:59.0
is a subtopic of 1.5 - Software Quality2001-08-30 14:54:59.0
is measured in terms of the nesting depth, the number of branches and the use of certain complex programming constructs2001-08-30 14:54:59.0
componenthas definition Any piece of software or hardware that has a clear role and can be isolated, allowing you to replace it with a different component with equivalent functionality2001-08-30 14:55:00.0
is reusable if it can be used in several different systems with little or no modification2001-08-30 14:55:00.0
is a kind of subject2001-08-30 14:55:00.0
is a subtopic of 9.1 - The Process of Design2001-08-30 14:55:00.0
component diagramhas definition A UML diagram showing components and their relationships2001-08-30 14:55:00.0
is a kind of UML diagram2001-08-30 14:55:00.0
is a subtopic of 5.1 - What is UML?2001-08-30 14:55:00.0
shows how the various components of systems are arranged logically and physically2001-08-30 14:55:00.0
componentmay perform a special-purpose function such as the user interface for a particular system2001-08-30 14:55:00.0
component symbolis a kind of symbol in UML diagram2001-08-30 14:55:00.0
is a subtopic of 9.4 - Software Architecture2001-08-30 14:55:00.0
is drawn a box with two smaller boxes protruding from its left side2001-08-30 14:55:00.0
compositehas definition A specialization of the general hierarchy pattern, that uses an aggregation instead of an ordinary association2001-08-30 14:55:00.0
is a subtopic of 6.3 - The General Hierarchy Pattern2001-08-30 14:55:00.0
is an instance of design pattern2001-08-30 14:55:00.0
compositionhas definition A strong kind of aggregation in which if the aggregate is destroyed, then the parts are destroyed as well2001-08-30 14:55:00.0
has example The rooms of a building cannot exist without the building2001-08-30 14:55:00.0
is a kind of aggregation2001-08-30 14:55:00.0
is a subtopic of 5.6 - More Advanced Features of Class Diagrams2001-08-30 14:55:00.0
is drawn as a solid (filled-in) diamond in a UML diagram2001-08-30 14:55:00.0
computationis a kind of event2001-08-30 14:55:01.0
is a subtopic of 8.2 - State Diagrams2001-08-30 14:55:00.0
can be represented by a state diagram2001-08-30 14:55:00.0
computer engineeringdeveloped in the 1980's2001-08-30 14:55:01.0
is a kind of engineering2001-08-30 14:55:01.0
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession2001-08-30 14:55:01.0
is concerned with the design of computer systems that involve both hardware and software components2001-08-30 14:55:01.0
computer scienceis a kind of discipline2001-08-30 14:55:01.0
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession2001-08-30 14:55:01.0
computing numerical resultsis a kind of responsibility2001-08-30 14:55:01.0
is a subtopic of 5.8 - The Process Of Developing Class Diagrams2001-08-30 14:55:01.0
concrete classhas definition A class that can have instances2001-08-30 14:55:01.0
is a kind of class2001-08-30 14:55:01.0
is a subtopic of 2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarations2001-08-30 14:55:01.0
concurrencyis a kind of quality2001-08-30 14:55:01.0
is a subtopic of 3.4 - The Client-Server Architecture2001-08-30 14:55:01.0
concurrent engineering modelhas definition A process model in which each team works on its own component, typically following a spiral or evolutionary approach2001-08-30 14:55:01.0
is a kind of process model2001-08-30 14:55:01.0
is a subtopic of 11.2 - Software Process Models2001-08-30 14:55:01.0
uses the divide and conquer principle: Each team works on its own component, typically following a spiral or evolutionary approach2001-08-30 14:55:01.0
conditionis a kind of programming language construct2001-08-30 14:55:01.0
is a subtopic of The Basics of Java2001-08-30 14:55:01.0
configuration management specialistis responsible for ensuring that changes are made, no new problems are introduced and that documentation for each change is properly updated2001-08-30 14:55:01.0
is a kind of software developer2001-08-30 14:55:01.0
is a subtopic of 1.4 - Stakeholders in Software Engineering2001-08-30 14:55:01.0
is part of software development team2001-08-30 14:55:01.0
configuration management systemis a kind of tool2001-08-30 14:55:02.0
is a subtopic of 4.9 - Managing Changing Requirements2001-08-30 14:55:02.0
keeps track of versions of requirements documents2001-08-30 14:55:02.0
connectionhas definition The existence of a communications channel between two computers, typically a client and server2001-08-30 14:55:02.0
has part socket in the client2001-08-30 14:55:02.0
has part socket in the server2001-08-30 14:55:02.0
is a kind of subject2001-08-30 14:55:02.0
is a subtopic of 3.4 - The Client-Server Architecture2001-08-30 14:55:02.0
constis a subtopic of The Basics of Java2001-08-30 14:55:02.0
is an instance of Java keyword2001-08-30 14:55:02.0
constanthas part value2001-08-30 14:55:02.0
has purpose to hold a value that does not change2001-08-30 14:55:02.0
is a kind of subject2001-08-30 14:55:02.0
is a subtopic of The Basics of Java2001-08-30 14:55:02.0
constraintexpresses a logical statement that should evaluate to true2001-08-30 14:55:02.0
has definition A small block of text in curly brackets embedded in a UML diagram. It is normally written in a formal language which can be interpreted by a computer2001-08-30 14:55:02.0
is a kind of criterion2001-08-30 14:55:02.0
is a subtopic of 5.6 - More Advanced Features of Class Diagrams2001-08-30 14:55:02.0
is written in braces (curly brackets) in a UML diagram2001-08-30 14:55:02.0
can be written in in any language supported by a given tool2001-08-30 14:55:02.0
cannot compute a non-boolean result2001-08-30 14:55:02.0
cannot have any side-effects2001-08-30 14:55:02.0
cannot modify any data2001-08-30 14:55:02.0
constructionhas definition A term often applied to the latter stages of design and to programming, even though the analogy with construction in other areas of engineering is weak2001-08-30 14:55:02.0
is a kind of process2001-08-30 14:55:02.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:02.0
is not like construction of buildings2001-08-30 14:55:02.0
Constructive Cost Modelcomputes effort, in person months, from an estimate of size, in lines of code2001-08-30 14:55:03.0
has definition An algorithmic cost estimation method that computes effort, in person-months, from an estimate of size, measured in lines of code2001-08-30 14:55:03.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:03.0
is abbreviated as COCOMO2001-08-30 14:55:03.0
is an instance of algorithmic cost estimation model2001-08-30 14:55:03.0
constructorhas definition A procedure that is called whenever a new object is createdlink: chapter2section2.8.html#764, 2001-08-30 14:55:03.0
has purpose to initialize the instance variables of a newly created object and perform any other needed initializationlink: chapter2section2.8.html#766, 2001-08-30 14:55:03.0
is a kind of procedure2001-08-30 14:55:03.0
is a subtopic of The Basics of Java2001-08-30 14:55:03.0
is part of a classlink: chapter2section2.8.html#761, 2001-08-30 14:55:03.0
content couplinghas definition An undesirable form of coupling in which a component surreptitiously modifies internal data of another component2001-08-30 14:55:03.0
is a kind of coupling2001-08-30 14:55:03.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:55:03.0
content coupling in Javais a kind of content coupling2001-08-30 14:55:03.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:55:03.0
can be avoided by 2001-08-30 14:55:03.0
can occur when you directly modify an instance variable of an instance variable2001-08-30 14:55:03.0
can occur whenever you modify a public instance variable in a way that designers did not intend2001-08-30 14:55:03.0
content couplingshould be avoided since any modification of data should be easy to find and easy to understand2001-08-30 14:55:03.0
contexthas definition The general situation in which a design pattern applies2001-08-30 14:55:03.0
is a kind of subject2001-08-30 14:55:03.0
is a subtopic of 6.1 - Introduction to Patterns2001-08-30 14:55:03.0
is part of design pattern2001-08-30 14:55:03.0
continueis a subtopic of The Basics of Java2001-08-30 14:55:03.0
is an instance of Java keyword2001-08-30 14:55:04.0
contracting-outhas definition Paying to have software (typically custom software) developed by some other organization2001-08-30 14:55:04.0
is a kind of process2001-08-30 14:55:04.0
is a subtopic of 1.1 - The Nature of Software2001-08-30 14:55:04.0
controlis a synonym of user interface component2001-08-30 14:55:04.0
is a synonym of widget2001-08-30 14:55:04.0
control couplinghas definition A form of coupling in which one component affects the sequence of execution in another2001-08-30 14:55:04.0
has example
public routineX(String command)
{
//routineX will have to change whenever any of its callers adds a new command
if (command.equals("drawCircle")
{
drawCircle();
}
else
{
drawRectangle();
}
}
2001-08-30 14:55:04.0
is a kind of coupling2001-08-30 14:55:04.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:55:04.0
is named after common blocks in the Fortran language which are used to hold global variables2001-08-30 14:55:04.0
occurs when one procedure calls another using a 'flag' or 'command' that explicitly controls what the second procedure does2001-08-30 14:55:04.0
can be reduced by
  • having the callers of the routine directly call the methods called in the second routine
  • the use of polymorphic operations
  • using a look-up table that maps a command to a method that should be called when that command is issued
2001-08-30 14:55:04.0
controllercontains the objects that control and handle the user's interaction with the view and the model2001-08-30 14:55:04.0
has definition In the MVC architectural pattern, the class or classes used to control and handle the user's interaction with the view and the model2001-08-30 14:55:04.0
is a kind of class2001-08-30 14:55:04.0
is a subtopic of 9.5 - Architectural Patterns2001-08-30 14:55:04.0
copying, converting, transforming, transmitting or outputtingis a kind of responsibility2001-08-30 14:55:04.0
is a subtopic of 5.8 - The Process Of Developing Class Diagrams2001-08-30 14:55:04.0
is often omitted from a model because the presence of such responsibilities can largely be inferred from the class diagram2001-08-30 14:55:04.0
CORBAis a subtopic of 9.5 - Architectural Patterns2001-08-30 14:55:04.0
is an abbreviation for Common Object Request Broker Architecture2001-08-30 14:55:04.0
is an instance of abbreviation2001-08-30 14:55:05.0
CORBA web sitehas URL www.corba.com    2001-08-30 14:55:05.0
is a subtopic of 9.9 - Architecting and designing software - References2001-08-30 14:55:05.0
is an instance of web site about software architecture2001-08-30 14:55:05.0
corrective maintenancehas definition A type of maintenance performed to correct a defect in software2001-08-30 14:55:05.0
is a kind of maintenance2001-08-30 14:55:05.0
is a subtopic of 1.6 - Software Engineering Projects2001-08-30 14:55:05.0
corrective projectinvolves fixing defects2001-08-30 14:55:05.0
is a kind of evolutionary project2001-08-30 14:55:05.0
is a subtopic of 1.6 - Software Engineering Projects2001-08-30 14:55:05.0
costis a kind of subject2001-08-30 14:55:05.0
is a subtopic of 9.3 - Techniques for Making Good Design Decisions2001-08-30 14:55:05.0
cost and delivery dateis a kind of non-functional requirement2001-08-30 14:55:05.0
is a subtopic of 4.5 - Types of Requirements2001-08-30 14:55:05.0
is often not included in the requirements document, but left to a separate project plan document2001-08-30 14:55:05.0
cost estimateis a kind of subject2001-08-30 14:55:05.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:05.0
can be based on 2001-08-30 14:55:05.0
should be reported regularly to other members of the team, to management and to customers2001-08-30 14:55:05.0
cost estimationhas definition The process of estimating the effort and elapsed time of an activity or project2001-08-30 14:55:05.0
is difficult2001-08-30 14:55:05.0
is a kind of process2001-08-30 14:55:05.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:05.0
uses development effort2001-08-30 14:55:06.0
uses elapsed time2001-08-30 14:55:06.0
cost estimation principleis a kind of principle2001-08-30 14:55:06.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:06.0
cost estimation principle 1helps to make an estimate more accurate because
  • you will be more likely to account for all the subsystems and activities
  • if you under-estimate the time required for some subsystems or activities, this should be at least partly compensated for by over-estimates in other places
2001-08-30 14:55:06.0
is a kind of cost estimation principle2001-08-30 14:55:06.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:06.0
recommends dividing the project up into individual subsystems, and then dividing each subsystem further into the activities that will be required to develop it, then making a series of detailed estimates for each individual activity, and summing the results to arrive at the grand total estimate for the project2001-08-30 14:55:06.0
states divide and conquer2001-08-30 14:55:06.0
cost estimation principle 2is a kind of cost estimation principle2001-08-30 14:55:06.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:06.0
states include all activities when making estimates2001-08-30 14:55:06.0
cost estimation principle 3has strategies
  • base your estimates purely on the personal judgement of experts within your team
  • use algorithmic models that have been developed in the software industry as a whole
2001-08-30 14:55:06.0
is a kind of cost estimation principle2001-08-30 14:55:06.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:06.0
states base your estimates on past experience combined with what you can observe of the current project2001-08-30 14:55:06.0
cost estimation principle 4is a kind of cost estimation principle2001-08-30 14:55:06.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:06.0
states be sure to account for differences when extrapolating from other projects2001-08-30 14:55:06.0
cost estimation principle 5is a kind of cost estimation principle2001-08-30 14:55:06.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:06.0
states anticipate the worst case and plan for contingencies2001-08-30 14:55:06.0
cost estimation principle 6is a kind of cost estimation principle2001-08-30 14:55:06.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:06.0
states combine multiple independent estimates2001-08-30 14:55:06.0
cost estimation principle 7is a kind of cost estimation principle2001-08-30 14:55:06.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:06.0
states revise and refine estimates as work progresses2001-08-30 14:55:06.0
cost estimationshould be a continuous activity2001-08-30 14:55:05.0
cost estimation techniqueis a kind of process2001-08-30 14:55:06.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:06.0
is used by cost estimator2001-08-30 14:55:06.0
cost estimatoris a kind of software developer2001-08-30 14:55:07.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:07.0
makes inaccurate estimate if he or she tries to estimate the entire cost of a project as a single number2001-08-30 14:55:07.0
can estimate time by making 3 separate estimates - optimistic, likely and pessimistic - to come up with a global estimates of the best-case, typical case and worst-case cost for the project2001-08-30 14:55:06.0
can use cost estimation technique2001-08-30 14:55:06.0
may underestimate the total amount of work required by not understanding the amount of work involved in certain activities or omitting them entirely2001-08-30 14:55:07.0
must include extra time into a time estimate to account for typical delays2001-08-30 14:55:07.0
should avoid making only a best-case estimate2001-08-30 14:55:07.0
should compare the results of several different cost estimation techniques2001-08-30 14:55:07.0
should consider differences when making an estimate for a new project:
  • different software developers with different skill levels
  • different development processes and maturity levels
  • different types of customers and users
  • different schedule demands
  • different technology
  • different technical complexity of the requirements
  • Different domains
  • Different levels of requirement stability
2001-08-30 14:55:07.0
should divide the project up into individual subsystems, and then divide each subsystem further into the activities that will be required to develop it, then make a series of detailed estimates for each individual activity, and sum the results to arrive at the grand total estimate for the project2001-08-30 14:55:07.0
should revise estimates because
  • As you gather requirements and begin specifying details, you will be able to increase the accuracy of your estimate
  • As you move into the design phase, you can again increase the accuracy of your estimates
  • You will adjust your estimates as requirements change, or features are dropped in order to meet a budget or deadline
  • As you encounter problems during design and implementation, you will be able to adjust your estimates to take these into account
2001-08-30 14:55:07.0
should use cost estimation principles2001-08-30 14:55:07.0
cost of a software projectis a function of development effort2001-08-30 14:55:07.0
is a kind of cost2001-08-30 14:55:07.0
is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:07.0
cost-benefit analysishas definition The process of deciding whether to do something by evaluating the costs of doing it and the benefits of doing it, and then choosing to do it if the benefits sufficiently exceed the costs2001-08-30 14:55:07.0
has procedure add up estimates of the costs and compare this to the benefits2001-08-30 14:55:07.0
is a kind of analysis2001-08-30 14:55:07.0
is a subtopic of 9.3 - Techniques for Making Good Design Decisions2001-08-30 14:55:07.0
is taught in management courses2001-08-30 14:55:07.0
COTSis a subtopic of 1.1 - The Nature of Software2001-08-30 14:55:07.0
is an abbreviation for commercial off-the-shelf software2001-08-30 14:55:07.0
is an instance of abbreviation2001-08-30 14:55:07.0
couplinghas definition A measure of the extent to which interdependencies exist between software modules2001-08-30 14:55:07.0
implies that if you want to reuse one component, you will also have to import all the ones with which it is coupled2001-08-30 14:55:07.0
is a kind of measurement2001-08-30 14:55:07.0
is a kind of software quality2001-08-30 14:55:07.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:55:07.0
coveragehas definition A measure of the percentage of paths, statements or branches taken by a set of tests2001-08-30 14:55:07.0
is a kind of measurement2001-08-30 14:55:07.0
is a subtopic of 10.3 - Defects in Ordinary Algorithms2001-08-30 14:55:07.0
crashis a kind of failure2001-08-30 14:55:08.0
is a subtopic of 10.2 - Effective and Efficient Testing2001-08-30 14:55:08.0
creating and initializing new instancesis a kind of responsibility2001-08-30 14:55:08.0
is a subtopic of 5.8 - The Process Of Developing Class Diagrams2001-08-30 14:55:08.0
is often given to some other class2001-08-30 14:55:08.0
is often omitted from a model because the presence of such responsibilities can largely be inferred from the class diagram2001-08-30 14:55:08.0
credit card number formathas localization issues
  • You should almost never require a specific format for these items since they differ so widely and can change at any time
  • Allow free-form input of whatever the user wants to type
2001-08-30 14:55:08.0
is a kind of locale-dependent feature2001-08-30 14:55:08.0
is a subtopic of 7.5 - Usability Principles2001-08-30 14:55:08.0
criterionis a kind of subject2001-08-30 14:55:08.0
critical pathhas definition A path through a PERT chart indicating the minimum time in which it is possible to complete a project, and the tasks that, if delayed, will delay the whole project2001-08-30 14:55:08.0
indicates the minimum time in which it is possible to complete the project2001-08-30 14:55:08.0
is a kind of subject2001-08-30 14:55:08.0
is a subtopic of 11.5 - Project Scheduling and Tracking2001-08-30 14:55:08.0
is computed by searching for the path through the PERT chart that has the greatest cumulative elapsed time2001-08-30 14:55:08.0
critical racehas black-box testing strategy
  • Vary the time consumption of different threads by giving them differing amounts of input, or running them on hardware that varies in speed
  • Run a large number of threads concurrently
  • Deliberately deny resources to one or more threads (e.g. temporarily cut a network connection, or make a file unreadable)
2001-08-30 14:55:08.0
has definition A defect in which one thread or process can sometimes experience a failure because another thread or process interferes with the 'normal' sequence of events2001-08-30 14:55:08.0
is hard to detect with black box testing alone since you often don't know the extent of the concurrency going on inside the system, and can not always manipulate the various threads to cause race conditions2001-08-30 14:55:08.0
is a kind of timing and co-ordination defect2001-08-30 14:55:08.0
is a subtopic of 10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races2001-08-30 14:55:08.0
is a synonym of race condition2001-08-30 14:57:12.0
can be detected by glass-box testing since you can actually study the progress and states of the various threads2001-08-30 14:55:08.0
can be detected by inspection2001-08-30 14:55:08.0
currencyhas localization issues
  • Users may be using more than one currency at once
  • The number of decimal places and the magnitude of values may differ dramatically
  • The currency symbol itself may come before or after the numeric value
  • The language somebody is using does not necessarily dictate the currency they are using; they may be visiting a foreign country or residing in one of several countries that use the same language
2001-08-30 14:55:08.0
is a kind of locale-dependent feature2001-08-30 14:55:08.0
is a subtopic of 7.5 - Usability Principles2001-08-30 14:55:08.0
custom softwarehas definition Software developed to meet the needs of a particular customer2001-08-30 14:55:08.0
has definition Software that is developed to meet the specific needs of a particular customer (in contrast to generic software)2001-08-30 14:55:08.0
has example web sites, air-traffic control systems and software for managing the finances of large organizations2001-08-30 14:55:08.0
has global CPU usage low2001-08-30 14:55:08.0
has global development effort high2001-08-30 14:55:08.0
has global number of copies low2001-08-30 14:55:08.0
is what most software developers work on2001-08-30 14:55:09.0
is a kind of software2001-08-30 14:55:09.0
is a subtopic of 1.1 - The Nature of Software2001-08-30 14:55:09.0
is developed for a particular customer2001-08-30 14:55:09.0
is often developed in-house2001-08-30 14:55:09.0
is typically used by only a few people2001-08-30 14:55:09.0
can be made generic but this can be a complex process if the software was not designed in a flexible way2001-08-30 14:55:08.0
may be contracted-out to a consulting company2001-08-30 14:55:09.0
customerdemands new and updated software2001-08-30 14:55:09.0
expects software to be of high quality and to be produced rapidly2001-08-30 14:55:09.0
has definition A person who make decisions about ordering and paying for software (in contrast to user); customers are those who have the problem that is being solved by the development of software2001-08-30 14:55:09.0
has goal either to increase profits or to run their business more effectively2001-08-30 14:55:09.0
is a kind of person2001-08-30 14:55:09.0
is a kind of stakeholder2001-08-30 14:55:09.0
is a subtopic of 1.4 - Stakeholders in Software Engineering2001-08-30 14:55:09.0
is a synonym of client2001-08-30 14:54:52.0
is concerned with efficiency2001-08-30 14:55:09.0
is concerned with reliability2001-08-30 14:55:09.0
likes software that helps their organization save or make money, typically by making the users and the organization as a whole more productive2001-08-30 14:55:09.0
makes decisions about ordering and paying for the software2001-08-30 14:55:09.0
often want to understand the architecture so they can be confident the software is being designed well and can monitor development progress2001-08-30 14:55:09.0
wants software that solves problems at an acceptable cost in terms of money paid and resources used2001-08-30 14:55:09.0
may be a user of software2001-08-30 14:55:09.0
should be involved in requirements analysis, user interface design and deployment, and also may play a role in design, quality assurance and project management2001-08-30 14:55:09.0
should be made to feel involved in the software engineering process resulting in fewer mistakes being made and greater acceptance of the finished product2001-08-30 14:55:09.0
data abstractiongroups the pieces of data that describe some entity, so that programmers can manipulate that data as a unit2001-08-30 14:55:09.0
helps a programmer to cope with the complexity of data2001-08-30 14:55:09.0
hides the details of data2001-08-30 14:55:09.0
is a kind of abstraction2001-08-30 14:55:09.0
is a subtopic of 2.1 - What is Object Orientation?2001-08-30 14:55:09.0
data couplinghas definition A form of coupling in which one component passes simple data to another as an argument2001-08-30 14:55:09.0
has disadvantage components become coupled because they are dependent on each other's interpretation of the meaning of the arguments; if that meaning changes in one component, then the other component may have to change to accommodate the new meaning2001-08-30 14:55:09.0
is always present to some extent2001-08-30 14:55:09.0
is a kind of coupling2001-08-30 14:55:09.0
is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:55:09.0
can be reduced by
  • not passing unnecessary arguments
  • passing few arguments, each containing more abstract information
    2001-08-30 14:55:09.0
    data itemis a kind of programming language construct2001-08-30 14:55:09.0
    is a subtopic of 2.2 - Classes and Objects2001-08-30 14:55:09.0
    data memberis a synonym of instance variable2001-08-30 14:55:09.0
    data processing softwaregathers data together in batches to be processed at a later time2001-08-30 14:55:10.0
    has concerns
    • accuracy of the data
    • security of the data
    • privacy of the information gathered about people
    2001-08-30 14:55:10.0
    has definition Software used for running businesses, managing data such as payroll, purchases, sales, product inventory etc.2001-08-30 14:55:10.0
    has design issue how to organize the data and provide useful information to the users so they can perform their work effectively2001-08-30 14:55:10.0
    is a kind of software2001-08-30 14:55:10.0
    is a subtopic of 1.1 - The Nature of Software2001-08-30 14:55:10.0
    is used to run businesses2001-08-30 14:55:10.0
    performs functions recording sales, managing accounts, printing bills etc.2001-08-30 14:55:10.0
    data typeis a kind of data abstraction2001-08-30 14:55:10.0
    is a kind of programming language construct2001-08-30 14:55:10.0
    is a subtopic of The Basics of Java2001-08-30 14:55:10.0
    databaseis a kind of component2001-08-30 14:55:10.0
    is a subtopic of 9.1 - The Process of Design2001-08-30 14:55:10.0
    database designhas definition The design of how data is persistently stored so that it may be accessed by many programs and users, over an indefinite period of time2001-08-30 14:55:10.0
    is a kind of design2001-08-30 14:55:10.0
    is a subtopic of 9.1 - The Process of Design2001-08-30 14:55:10.0
    database specialistis a kind of software developer2001-08-30 14:55:10.0
    is a subtopic of 1.4 - Stakeholders in Software Engineering2001-08-30 14:55:10.0
    is part of software development team2001-08-30 14:55:10.0
    database systemhas clients any application program that wants to query a database2001-08-30 14:55:10.0
    has server A database management system that responds to requests to query or update the database2001-08-30 14:55:10.0
    is a kind of client-server system2001-08-30 14:55:10.0
    is a subtopic of 3.4 - The Client-Server Architecture2001-08-30 14:55:10.0
    DataInputStreamallow programmer to exchange more sophisticated types of data than simple bytes without having to worry about how to translate them into a byte stream2001-08-30 14:55:10.0
    is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems2001-08-30 14:55:10.0
    is an instance of filter2001-08-30 14:55:10.0
    can contain Java primitive types such as int and double2001-08-30 14:55:10.0
    DataOutputStreamallow a programmer to exchange more sophisticated types of data than simple bytes without having to worry about how to translate them into a byte stream2001-08-30 14:55:10.0
    is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems2001-08-30 14:55:10.0
    is an instance of filter2001-08-30 14:55:11.0
    can contain Java primitive types such as int and double2001-08-30 14:55:10.0
    date formathas localization issues
    • There are many ways of writing dates. Even though the international standard is YYYY/MM/DD, this is often not followed
    2001-08-30 14:55:11.0
    is a kind of locale-dependent feature2001-08-30 14:55:11.0
    is a subtopic of 7.5 - Usability Principles2001-08-30 14:55:11.0
    Dave Farthing's software project management pagehas URL www.comp.glam.ac.uk/pages/staff/dwfarthi/projman.htm    2001-08-30 14:55:11.0
    is a subtopic of 11.8 - Managing the Software Process - References2001-08-30 14:55:11.0
    is an instance of web site about project management2001-08-30 14:55:11.0
    deadlockhas definition A failure in which two or more threads are stopped, waiting for each other to do something2001-08-30 14:55:11.0
    has example
    1. thread A is waiting to access object O
    2. object O is locked by thread B
    3. thread B, however might be waiting to access object P
    4. object P is locked by thread A
    Neither thread can ever progress unless some outside thread forces a break in the deadlock
    2001-08-30 14:55:11.0
    has example in real life gridlock2001-08-30 14:55:11.0
    is a kind of deadlock or livelock2001-08-30 14:55:11.0
    is a subtopic of 10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races2001-08-30 14:55:11.0
    can appear as a hung system where the system is not consuming CPU time2001-08-30 14:55:11.0
    may not hang a system2001-08-30 14:55:11.0
    deadlock or livelockhas black-box testing strategy
    • Vary the time consumption of different threads by giving them differing amounts of input, or running them on hardware that varies in speed
    • Run a large number of threads concurrently
    • Deliberately deny resources to one or more threads (e.g. temporarily cut a network connection, or make a file unreadable)
    2001-08-30 14:55:11.0
    has testing strategy inspecting to detect such defects, rather than testing alone2001-08-30 14:55:11.0
    is a kind of failure2001-08-30 14:55:11.0
    is a subtopic of 10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races2001-08-30 14:55:11.0
    can be caused by over-use of locking2001-08-30 14:55:11.0
    can be detected by glass-box testing since you can actually study the progress and states of the various threads2001-08-30 14:55:11.0
    may occur as a result of unusual combinations of conditions that are hard to anticipate or reproduce2001-08-30 14:55:11.0
    should be tested for by a person with a background in real-time systems who can apply his or her knowledge and experience to best anticipate typical defects2001-08-30 14:55:11.0
    deaf useris a kind of user with a disability2001-08-30 14:55:11.0
    is a subtopic of 7.5 - Usability Principles2001-08-30 14:55:11.0
    needs a program that does not depend on sound output2001-08-30 14:55:11.0
    decision-making statementis a kind of statement2001-08-30 14:55:11.0
    is a subtopic of The Basics of Java2001-08-30 14:55:11.0
    declarationis a kind of programming language construct2001-08-30 14:55:11.0
    is a subtopic of The Basics of Java2001-08-30 14:55:11.0
    decreasing couplingis a subtopic of 9.4 - Software Architecture2001-08-30 14:55:12.0
    is an instance of design principle2001-08-30 14:55:12.0
    means decreasing the number of dependencies between packages as much as possible2001-08-30 14:55:12.0
    defaultis a subtopic of The Basics of Java2001-08-30 14:55:12.0
    is an instance of Java keyword2001-08-30 14:55:12.0
    default multiplicityis one in a UML diagram2001-08-30 14:55:12.0
    is a kind of multiplicity in a UML diagram2001-08-30 14:55:12.0
    is a subtopic of 5.3 - Associations and Multiplicity2001-08-30 14:55:12.0
    does not require a symbol to be drawn in a UML diagram2001-08-30 14:55:12.0
    defecthas definition A flaw in any aspect of the system including the requirements, the design or the code, that contributes, or may potentially contribute, to the occurrence of one or more failures2001-08-30 14:55:12.0
    has example the absence of code to handle an exception2001-08-30 14:55:12.0
    is a kind of problem2001-08-30 14:55:12.0
    is a subtopic of 10.1 - Basic Definitions2001-08-30 14:55:12.0
    is a synonym of bug2001-08-30 14:54:44.0
    defect in a numerical algorithmis a kind of defect2001-08-30 14:55:12.0
    is a subtopic of 10.4 - Defects in Numerical Algorithms2001-08-30 14:55:12.0
    defect in an ordinary algorithmis a kind of defect2001-08-30 14:55:12.0
    is a subtopic of 10.4 - Defects in Numerical Algorithms2001-08-30 14:55:12.0
    defect in handling peak loads or missing resourceshas definition A defect that occurs when a computer cannot gracefully handle peak loads or missing resources2001-08-30 14:55:12.0
    has testing strategy
    • deny the program under test the resources it normally uses, by employing such methods as deleting files, concurrently running other resource-hungry programs, making less memory available, or disconnecting the system from the network
    • run a very large number of copies of the program being tested, all at the same time
    2001-08-30 14:55:12.0
    is a kind of defect in handling stress and unusual situations2001-08-30 14:55:12.0
    is a subtopic of 10.6 - Defects in Handling Stress and Unusual Situations2001-08-30 14:55:12.0
    occurs when
    • a computer becomes short of resources such as memory, disk space or network bandwidth
    • files or data are missing
    • the system is not permitted to perform certain operations
    • the system cannot start new threads
    • the system runs out of space in a fixed size data structure
    2001-08-30 14:55:12.0
    defect in handling stress and unusual situationsis a kind of defect2001-08-30 14:55:12.0
    is a subtopic of 10.6 - Defects in Handling Stress and Unusual Situations2001-08-30 14:55:12.0
    is only encountered when a system is being heavily used, or forced to its limits in some other way2001-08-30 14:55:12.0
    represents a lack of robustness2001-08-30 14:55:12.0
    can be detected by
    • running the system intensively
    • suppling the system with a very large amount of input
    • running many copies of the system
    • running the system on a computer or network that is busy running other systems
    • running the system in atypical environments
    2001-08-30 14:55:12.0
    defect in the process of recovering from a crashhas definition A defect that occurs when a system does not deal with hardware failures, crashes of related systems or the power being turned off2001-08-30 14:55:13.0
    has testing strategy kill either your program or the programs with which it communicates, at various times during execution2001-08-30 14:55:13.0
    is a kind of inappropriate management of resources2001-08-30 14:55:13.0
    is a subtopic of 10.6 - Defects in Handling Stress and Unusual Situations2001-08-30 14:55:13.0
    defensive designhas definition Design with awareness that other components cannot be trusted2001-08-30 14:55:13.0
    is a kind of design2001-08-30 14:55:13.0
    is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:55:13.0
    defining the problemhas definition A part of requirements and specification that involves narrowing down the scope of the system by determining the precise problem that needs solving2001-08-30 14:55:13.0
    is a kind of process2001-08-30 14:55:13.0
    is a subtopic of 1.6 - Software Engineering Projects2001-08-30 14:55:13.0
    is part of requirements and specification2001-08-30 14:55:13.0
    delegationhas antipatterns
    • Overusing generalization and inheriting the method that is to be reused
    • Instead of creating a single method in the «Delegator» that does nothing other than call a method in the «Delegate», you might consider having many different methods in the «Delegator» call the delegate's method? It would be better to ensure that only one method in the «Delegator» calls the method in the «Delegate». If many methods access the method in the «Delegate», then when it changes, you may have to change every method that accesses it
    • a method must only accesses neighbouring classes
    2001-08-30 14:55:13.0
    has context 2001-08-30 14:55:13.0
    has definition A pattern in which one procedure does nothing more than call another in a neighbouring class; this reduces total coupling in the system2001-08-30 14:55:13.0
    has forces
    • You want to minimize development cost and complexity by reusing methods
    • You want to reduce the linkages between classes
    • You want to ensure that work is done in the most appropriate class
    2001-08-30 14:55:13.0
    has problem How can you most effectively make use of a method that already exists in the other class?2001-08-30 14:55:13.0
    has related patterns Adapter and Proxy patterns2001-08-30 14:55:13.0
    has solution
    1. Create a method in the «Delegator» class that does only one thing: it calls a method in a neighbouring «Delegate» class, allowing reuse of the method for which the «Delegate» has responsibility
    2. By 'neighbouring', we mean the «Delegate» is connected to the «Delegator» by an association.
    3. Normally, in order to use delegation an association should already exist between the «Delegator» and the «Delegate».
    4. This association needs only to be unidirectional from «Delegator» to «Delegate».
    5. However it may sometimes be appropriate to create a new association just so you can use delegation - provided this does not increase the overall complexity of the system.
    2001-08-30 14:55:13.0
    is a subtopic of 6.7 - The Delegation Pattern2001-08-30 14:55:13.0
    is an instance of design pattern2001-08-30 14:55:13.0
    Delphi techniquehas definition An approach to cost estimation in which several individuals initially make cost estimates in private, and then share their estimates to discover the discrepancies2001-08-30 14:55:13.0
    has procedure
    • several individuals initially make cost estimates in private
    • they then share their estimates to discover the discrepancies
    • each individual repeatedly adjusts his or her estimates until a consensus is reached
    2001-08-30 14:55:13.0
    is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:13.0
    is an instance of cost estimation technique2001-08-30 14:55:13.0
    departmental manageris a kind of person2001-08-30 14:55:13.0
    is a subtopic of 11.1 - What is Project Management?2001-08-30 14:55:13.0
    performs activities such as hiring, building morale, and issuing the final directions2001-08-30 14:55:14.0
    deploymenthas definition The process of distributing and installing software as well as any other components of a system; deployment also includes managing the transition from any previous system2001-08-30 14:55:14.0
    has definition The process of distributing and installing the software and any other components of the system such as databases, special hardware etc. It also involves managing the transition from any previous system2001-08-30 14:55:14.0
    is a kind of process2001-08-30 14:55:14.0
    is a kind of process2001-08-30 14:55:14.0
    is a subtopic of 1.7 - Activities Common to Software Projects2001-08-30 14:55:14.0
    is a subtopic of 9.4 - Software Architecture2001-08-30 14:55:14.0
    deployment diagramcontains links between nodes that show how communication takes place2001-08-30 14:55:14.0
    contains nodes which represent computational units such as a computer, a processing card, a sensor or a device2001-08-30 14:55:14.0
    has definition A UML diagram showing hardware nodes, how they are interconnected, and what components will exist on them at run time2001-08-30 14:55:14.0
    is a kind of UML diagram2001-08-30 14:55:14.0
    is a subtopic of 5.1 - What is UML?2001-08-30 14:55:14.0
    shows where various instances of components reside at run time2001-08-30 14:55:14.0
    deprecatehas definition To declare that a component should not be used in subsequent designs, but remains available to support existing designs that incorporate it2001-08-30 14:55:14.0
    is a kind of action2001-08-30 14:55:14.0
    is a subtopic of 3.2 - Incorporating Reusability and Reuse Into Software Engineering2001-08-30 14:55:14.0
    derived classis the name for subclass in C++2001-08-30 14:55:14.0
    is a kind of class2001-08-30 14:55:14.0
    is a subtopic of 2.5 - Organizing Classes Into Inheritance Hierarchies2001-08-30 14:55:14.0
    is a synonym of subclass2001-08-30 14:55:14.0
    designdetermines how components will be implemented in a system2001-08-30 14:55:14.0
    has definition The problem-solving process whose objective is to find and describe a way to implement the system's functional requirements, while respecting the constraints imposed by the non-functional requirements, and while adhering to general principles of good quality2001-08-30 14:55:14.0
    has goals
    • Increasing profit by reducing cost and increasing revenue
    • Ensuring that we actually conform with the requirements, thus solving the customers' problems
    • Accelerating development, which helps reduce short-term costs, and may also ensure the software reaches the market soon enough to effectively compete
    • Increasing qualities such as usability, efficiency, reliability, maintainability, and reusability which can help reduce costs and also increase revenues
    2001-08-30 14:55:14.0
    has part detailed design2001-08-30 14:55:14.0
    has part modelling2001-08-30 14:55:14.0
    has part programming2001-08-30 14:55:14.0
    has part software architecture^22001-08-30 14:55:14.0
    has part systems engineering2001-08-30 14:55:14.0
    has part user interface design2001-08-30 14:55:14.0
    is a kind of process2001-08-30 14:55:15.0
    is a subtopic of 9.1 - The Process of Design2001-08-30 14:55:14.0
    requires considerable experience2001-08-30 14:55:15.0
    see also design^22001-08-30 14:55:15.0
    Design and Use of Software Architectureshas author Jan Bosch2001-08-30 14:55:15.0
    has ISBN number 0-201-67494-72001-08-30 14:55:15.0
    is a subtopic of 9.9 - Architecting and designing software - References2001-08-30 14:55:15.0
    is an instance of software architecture book2001-08-30 14:55:15.0
    was published by Addison-Wesley2001-08-30 14:55:15.0
    was published in 20002001-08-30 14:55:15.0
    design by contracthas definition An approach to design in which each method has a contract with its callers regarding preconditions, postconditions and invariants2001-08-30 14:55:15.0
    is a kind of design2001-08-30 14:55:15.0
    is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:55:15.0
    Design by Contract: The Lessons of Arianehas author J-M. Jézéquel and B. Meyer2001-08-30 14:55:15.0
    has date January 19972001-08-30 14:55:15.0
    has publication IEEE Computer, Vol. 30, No. 22001-08-30 14:55:15.0
    has URL www.eiffel.com/doc/manuals/technology/contract/ariane/page.html    2001-08-30 14:55:15.0
    is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:55:15.0
    is an instance of article about software failures2001-08-30 14:55:15.0
    design decisioncauses other new issues to be raised2001-08-30 14:55:15.0
    has definition A decision made in the process of design which involves listing design options, evaluating them according to pre-determined criteria, and choosing the alternative that has the best cost-benefit trade-off2001-08-30 14:55:15.0
    is a kind of subject2001-08-30 14:55:16.0
    is a subtopic of 9.1 - The Process of Design2001-08-30 14:55:15.0
    is made by the designer using all the knowledge at his or her disposal, including:
    • Knowledge of the requirements
    • Knowledge of the design as created so far
    • Knowledge of the technology available
    • Knowledge of software design principles and 'best practices'
    • Knowledge about what has worked well in the past
    2001-08-30 14:55:15.0
    can be made by using these steps:
    1. List and describe the alternatives for the design decision
    2. List the advantages and disadvantages of each alternative with respect to your objectives and priorities
    3. Determine whether any of the alternatives prevents you from meeting one or more of the objectives. If it does, you may have to rule it out. However, if none of the alternatives permits you to meet your objectives, you may have to adjust your objectives or else go back to earlier design decisions
    4. Choose the alternative that helps you to best meet your objectives. If several alternatives seems equally good in terms of the objectives, then use the priorities to decide among them
    5. Adjust your priorities for subsequent decision making. If you know you have already met your objectives for some aspects of quality, then you can increase the priority of the other qualities, for which you have not met your objectives
    2001-08-30 14:55:15.0
    design documentallows a group of people to review the design and therefore to improve it2001-08-30 14:55:16.0
    contains every design decision along with the reasoning that went into making the decision2001-08-30 14:55:16.0
    describes the priorities used to guide the design process2001-08-30 14:55:16.0
    describes what system or part of the system this design document describes2001-08-30 14:55:16.0
    discusses the important issues that had to be resolved, the possible alternatives that were considered, the final decision and the rationale for the decision2001-08-30 14:55:16.0
    ensures traceability by making reference to the requirements that are being implemented by this design2001-08-30 14:55:16.0
    forces a designer to be explicit and to consider the important issues before starting implementation2001-08-30 14:55:16.0
    has definition Documentation produced as a result of the design process2001-08-30 14:55:16.0
    has purpose
    • to encourage designers to make good design decisions
    • to communicate the design to others
    2001-08-30 14:55:16.0
    has suggested structure
    1. purpose
    2. general priorities
    3. outline of the design
    4. major design issues
    5. other details of the design
    2001-08-30 14:55:16.0
    includes a high-level description (or diagram) of the design that allows the reader to quickly get a general feeling for it2001-08-30 14:55:16.0
    includes the information its readers need to learn2001-08-30 14:55:16.0
    includes the rationale for the design which allows the reader to better understand the design, helps reviewers to determine whether good decisions were made, and helps the maintainers determine how to change the design2001-08-30 14:55:16.0
    is a kind of document2001-08-30 14:55:16.0
    is a subtopic of 9.1 - The Process of Design2001-08-30 14:55:16.0
    makes reference to the requirements that are being implemented by this design2001-08-30 14:55:16.0
    see also design2001-08-30 14:55:16.0
    should be written for
    • Those who will be implementing the design, i.e. the programmers
    • Those who will need, in the future, to modify the design
    • Those who need to create systems or subsystems that interface with the system being designed
    2001-08-30 14:55:16.0
    should not include 2001-08-30 14:55:16.0
    design issuehas definition A sub-problem of an overall design problem2001-08-30 14:55:16.0
    is a kind of problem2001-08-30 14:55:16.0
    is a subtopic of 9.1 - The Process of Design2001-08-30 14:55:16.0
    is resolved when the designer makes a design decision2001-08-30 14:55:16.0
    may not have a single best alternative - several different alternatives may have opposite advantages and disadvantages2001-08-30 14:55:16.0
    usually has several alternative solutions, also known as design options2001-08-30 14:55:16.0
    design optionhas definition An alternative solution to a design issue2001-08-30 14:55:16.0
    is a kind of subject2001-08-30 14:55:16.0
    is a subtopic of 9.1 - The Process of Design2001-08-30 14:55:16.0
    design patternhas antipatterns zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection2001-08-30 14:55:16.0
    has context a context2001-08-30 14:55:16.0
    has definition A pattern useful for the design of software2001-08-30 14:55:16.0
    has forces one or more forces2001-08-30 14:55:16.0
    has name2001-08-30 14:55:16.0
    has problem a sentence or two explaining the main difficulty being tackled2001-08-30 14:55:16.0
    has references one or more references which indicate who developed or inspired a pattern2001-08-30 14:55:16.0
    has related patterns zero or more related design patterns2001-08-30 14:55:16.0
    is a kind of pattern2001-08-30 14:55:16.0
    is a subtopic of 6.1 - Introduction to Patterns2001-08-30 14:55:16.0
    design pattern developeris a kind of software developer2001-08-30 14:55:17.0
    is a subtopic of 6.15 - Using Design Patterns - References2001-08-30 14:55:17.0
    should not write patterns for others to use until he or she has considerable experience both in software design and in the use of patterns2001-08-30 14:55:17.0
    should refine patterns iteratively and have then peer reviewed at each iteration2001-08-30 14:55:17.0
    design patternshould be illustrated using a simple diagram2001-08-30 14:55:16.0
    should be written using a narrative writing style2001-08-30 14:55:16.0
    Design Patterns: Elements of Reusable Object-Oriented Softwarehas author E. Gamma, R. Helm, R. Johnson, and J. Vlissides2001-08-30 14:55:17.0
    has ISBN number 0-201-63361-22001-08-30 14:55:17.0
    is a subtopic of 6.15 - Using Design Patterns - References2001-08-30 14:55:17.0
    is an instance of book about design patterns2001-08-30 14:55:17.0
    was published by Addison-Wesley2001-08-30 14:55:17.0
    was published in 19942001-08-30 14:55:17.0
    design principleis a kind of principle2001-08-30 14:55:17.0
    is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:55:17.0
    design spacehas definition The space of possible design options2001-08-30 14:55:17.0
    is a kind of subject2001-08-30 14:55:17.0
    is a subtopic of 9.1 - The Process of Design2001-08-30 14:55:17.0
    design specificationis a synonym of requirements specification2001-08-30 14:55:17.0
    designeris a kind of software developer2001-08-30 14:55:17.0
    is a subtopic of 1.7 - Activities Common to Software Projects2001-08-30 14:55:17.0
    makes design decision2001-08-30 14:55:17.0
    can create skeletons for the files that will contain the code2001-08-30 14:55:17.0
    can learn from studying patterns2001-08-30 14:55:17.0
    can use cost-benefit analysis to choose among alternatives2001-08-30 14:55:17.0
    may also be a programmer2001-08-30 14:55:17.0
    must find ways to reduce costs and increase benefits2001-08-30 14:55:17.0
    should not design large systems until she has experienced a wide variety of software development projects2001-08-30 14:55:17.0
    should study designs of other systems, including designs that have been found to be bad2001-08-30 14:55:17.0
    designing for flexibilityinvolves actively anticipating changes that a design may have to undergo in the future and preparing for them2001-08-30 14:55:17.0
    is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:55:17.0
    is an instance of design principle2001-08-30 14:55:17.0
    can be accomplished by 2001-08-30 14:55:17.0
    designing for portabilityhas goal the ability to have the software run on as many platforms as possible2001-08-30 14:55:17.0
    is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:55:18.0
    is an instance of design principle2001-08-30 14:55:18.0
    can be accomplished by avoiding the use of facilities that are specific to one particular environment2001-08-30 14:55:17.0
    designing for testabilityis a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:55:18.0
    is an instance of design principle2001-08-30 14:55:18.0
    can be accomplished by ensuring that all the functionality of the code can by driven by an external program, bypassing a graphical user interface2001-08-30 14:55:18.0
    Designing Maintainable Softwarehas author Dennis D. S2001-08-30 14:55:18.0
    has ISBN number 0-387-98783-52001-08-30 14:55:18.0
    is a subtopic of 9.9 - Architecting and designing software - References2001-08-30 14:55:18.0
    is an instance of software architecture book2001-08-30 14:55:18.0
    was published by Springer Verlag2001-08-30 14:55:18.0
    was published in 19992001-08-30 14:55:18.0
    Designing Web Usability: The Practice of Simplicityhas author J. Nielsen2001-08-30 14:55:18.0
    has ISBN number 1-56205-810-X2001-08-30 14:55:18.0
    is a subtopic of 7.9 - Focusing on Users and Their Tasks - References2001-08-30 14:55:18.0
    is an instance of book about user interfaces and usability2001-08-30 14:55:18.0
    was published by New Riders2001-08-30 14:55:18.0
    was published in 20002001-08-30 14:55:18.0
    destroying instancesis a kind of responsibility2001-08-30 14:55:18.0
    is a subtopic of 5.8 - The Process Of Developing Class Diagrams2001-08-30 14:55:18.0
    is often omitted from from a model because the presence of such responsibilities can largely be inferred from the class diagram2001-08-30 14:55:18.0
    often requires collaboration with some other class2001-08-30 14:55:18.0
    detailed designhas definition The design of the internals of individual subsystems2001-08-30 14:55:18.0
    involves deciding on data structures, classes, algorithms and procedures to be used2001-08-30 14:55:18.0
    is a kind of design2001-08-30 14:55:18.0
    is a subtopic of 1.7 - Activities Common to Software Projects2001-08-30 14:55:18.0
    is part of design2001-08-30 14:55:18.0
    deteriorationhas definition The tendency of software to accumulate defects as time passes due to errors being made during maintenance2001-08-30 14:55:18.0
    is a kind of process2001-08-30 14:55:19.0
    is a subtopic of 1.1 - The Nature of Software2001-08-30 14:55:18.0
    developer testinghas definition Preliminary testing performed by the people who do the design and programming2001-08-30 14:55:19.0
    is a kind of testing performed by software engineers2001-08-30 14:55:19.0
    is a subtopic of 10.9 - Strategies for Testing Large Systems2001-08-30 14:55:19.0
    developmenthas definition A process used to develop software2001-08-30 14:55:19.0
    is a kind of process2001-08-30 14:55:19.0
    is a subtopic of 11.2 - Software Process Models2001-08-30 14:55:19.0
    is a subtopic of 4.5 - Types of Requirements2001-08-30 14:55:19.0
    is a synonym of software engineering process2001-08-30 14:57:40.0
    development effortis a synonym of effort2001-08-30 14:55:19.0
    development manageris a synonym of project manager2001-08-30 14:55:19.0
    development process to be usedhas example certain approaches to testing2001-08-30 14:55:19.0
    is a kind of non-functional requirement2001-08-30 14:55:19.0
    is a subtopic of 4.5 - Types of Requirements2001-08-30 14:55:19.0
    diagramhas advantages it conveys or summarizes complex concepts or mechanisms more easily than other techniques2001-08-30 14:55:19.0
    has problems
    • can be hard for users to interact with or interpret
    • not usable by blind people
    • it can be expensive to program diagram drawing software
    2001-08-30 14:55:19.0
    is a kind of coding technique2001-08-30 14:55:19.0
    is a kind of representation2001-08-30 14:55:19.0
    is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:55:19.0
    should have a label if its meaning is not obvious, using a caption or pop-up label that appears when the user moves the mouse over it2001-08-30 14:55:19.0
    dialoghas definition A specific window with which a user can interact, but which is not the main UI window2001-08-30 14:55:19.0
    is a kind of window2001-08-30 14:55:20.0
    is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:55:19.0
    is a synonym of dialog box2001-08-30 14:55:20.0
    dialog boxis a synonym of dialog2001-08-30 14:55:20.0
    dialog^2has definition The back-and-forth interaction between user and computer2001-08-30 14:55:20.0
    is a kind of subject2001-08-30 14:55:20.0
    is a subtopic of 7.4 - The Basics of User Interface Design2001-08-30 14:55:20.0
    direction for reading texthas localization issues
    • Text in some languages runs left to right or top to bottom. Laying out screens so they can automatically accommodate this is a challenge
    2001-08-30 14:55:20.0
    is a kind of locale-dependent feature2001-08-30 14:55:20.0
    is a subtopic of 7.5 - Usability Principles2001-08-30 14:55:20.0
    disciplineis a kind of subject2001-08-30 14:55:20.0
    is a subtopic of 1.2 - What is Software Engineering?2001-08-30 14:55:20.0
    discriminatorhas definition A label on a generalization that describes the criteria used to specialize a superclass into two or more subclasses2001-08-30 14:55:20.0
    has example in a zoology program, animals can be divided up by habitat into aquatic and land ones, or by type of food, into carnivores and herbivores.2001-08-30 14:55:20.0
    is a kind of label2001-08-30 14:55:20.0
    is a subtopic of 5.3 - Associations and Multiplicity2001-08-30 14:55:20.0
    can be thought of as an attribute that will have a different value in each subclass2001-08-30 14:55:20.0
    distributed architecturefacilitates designing for flexibility because distributed systems can often be easily reconfigured by adding extra servers or clients and clients and servers can be developed by competing organizations, giving the customer a choice2001-08-30 14:55:20.0
    facilitates divide and conquer since dividing the system into processes is a very strong way to divide the system up2001-08-30 14:55:20.0
    increases abstraction because separate distributed components are often good abstractions2001-08-30 14:55:20.0
    increases reuse because it is often possible to find suitable frameworks on which to build good distributed systems2001-08-30 14:55:20.0
    is a kind of software architecture2001-08-30 14:55:20.0
    is a subtopic of 9.5 - Architectural Patterns2001-08-30 14:55:20.0
    reduces coupling since there is usually only one communication channel between distributed components although you have to watch out for control coupling2001-08-30 14:55:20.0
    distributed systemhas definition A system in which computations are performed by separate programs that co-operate to perform the task of the system as a whole2001-08-30 14:55:20.0
    is vulnerable to privacy invasions of its users by gathering data about people as they use network-based programs or by actively intercepting communications2001-08-30 14:55:20.0
    is a kind of system2001-08-30 14:55:20.0
    is a subtopic of 3.4 - The Client-Server Architecture2001-08-30 14:55:20.0
    is divided up into clients and servers2001-08-30 14:55:20.0
    distributed system developeris a kind of software developer2001-08-30 14:55:21.0
    is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References2001-08-30 14:55:20.0
    must not violate the privacy of users by gathering data about people as they use network-based programs or by actively intercepting communications unless users have consented to the release of their private information2001-08-30 14:55:21.0
    should never develop harmful programs such as viruses or Trojan horses or hack into systems2001-08-30 14:55:21.0
    divide and conquerhas benefits
    • Separate people can work on each part. The original development work can therefore be done in parallel
    • An individual software engineer can specialize in his or her component and become expert at it
    • Each individual component is smaller, and therefore easier to understand
    • When one part needs to be replaced or changed, it can hopefully be done without having to replace or extensively change other parts
    2001-08-30 14:55:21.0
    has definition The principle of dividing something large into smaller units, so it can be dealt with more easily2001-08-30 14:55:21.0
    is a subtopic of 11.3 - Cost Estimation2001-08-30 14:55:21.0
    is a subtopic of 9.2 - Principles Leading to Good Design2001-08-30 14:55:21.0
    is an instance of design principle2001-08-30 14:55:21.0
    DLLis a subtopic of 9.1 - The Process of Design2001-08-30 14:55:21.0
    is an abbreviation for dynamic link library2001-08-30 14:55:21.0
    is an instance of abbreviation2001-08-30 14:55:21.0
    DMOZ Open Directory on software testinghas URL dmoz.org/Computers/Programming/Software_Testing    2001-08-30 14:55:21.0
    is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References2001-08-30 14:55:21.0
    is an instance of web site about software testing2001-08-30 14:55:21.0
    dois a subtopic of The Basics of Java2001-08-30 14:55:21.0
    is an instance of Java keyword2001-08-30 14:55:21.0
    documenthas definition Anything written that that describes software2001-08-30 14:55:21.0
    is a kind of representation2001-08-30 14:55:21.0
    is a subtopic of 9.6 - Writing a Good Design Document2001-08-30 14:55:21.0
    should be written for a particular audience2001-08-30 14:55:21.0
    documentationhas purpose to document decisions and to communicate them to others2001-08-30 14:55:21.0
    includes requirements, designs, user documentation, instructions for testers and project plans2001-08-30 14:55:21.0
    is a kind of representation2001-08-30 14:55:21.0
    is a subtopic of 1.8 - The Eight Themes Emphasized in this Book2001-08-30 14:55:21.0
    will not be read if it is excessively voluminous, poorly written or not made readily available2001-08-30 14:55:22.0
    can be a source of rigidity in software development unless it is managed appropriately2001-08-30 14:55:21.0
    can entrench poorly made decisions that are hard to change2001-08-30 14:55:21.0
    can waste resources if it is never read2001-08-30 14:55:21.0
    documentation defecthas definition A defect in a user manual, reference manual or on-line help that gives incorrect information or fails to give information relevant to a problem2001-08-30 14:55:22.0
    has testing strategy
    • Examine all the end-user documentation (in both paper and on-line forms), making sure it is correct
    • Make sure it has correct solutions to problems that users might encounter, and correct instructions to help beginners learn how to use the software
    • Work through the use cases, making sure that each of then is adequately explained to the user
    2001-08-30 14:55:22.0
    is a kind of defect2001-08-30 14:55:22.0
    is