![]() |
! | indicates logical NOT | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java logical operator | ![]() | ||||||||||||||||||||||
!= | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java identity comparison operator | ![]() | ||||||||||||||||||||||
% | indicates modulus | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java arithmetic operator | ![]() | ||||||||||||||||||||||
&& | indicates logical AND | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java logical operator | ![]() | ||||||||||||||||||||||
is an instance of short circuit operator | ![]() | ||||||||||||||||||||||
* | indicates multiplication | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java arithmetic operator | ![]() | ||||||||||||||||||||||
*= | has example
| ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java special operator | ![]() | ||||||||||||||||||||||
*^2 | indicates the multiplicity many | ![]() | |||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is an instance of multiplicity symbol | ![]() | ||||||||||||||||||||||
+ | indicates addition | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java arithmetic operator | ![]() | ||||||||||||||||||||||
++ | has example
| ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java special operator | ![]() | ||||||||||||||||||||||
can be used in prefix or postfix form | ![]() | ||||||||||||||||||||||
+= | has example
| ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java special operator | ![]() | ||||||||||||||||||||||
- | indicates subtraction | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java arithmetic operator | ![]() | ||||||||||||||||||||||
-- | has example
| ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java special operator | ![]() | ||||||||||||||||||||||
can be used in prefix or postfix form | ![]() | ||||||||||||||||||||||
-= | has example
| ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java special operator | ![]() | ||||||||||||||||||||||
. | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java symbol | ![]() | ||||||||||||||||||||||
is used to access an instance variable of an object in Java, for example: b.variableName | ![]() | ||||||||||||||||||||||
/ | indicates division | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java arithmetic operator | ![]() | ||||||||||||||||||||||
/= | has example
| ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java special operator | ![]() | ||||||||||||||||||||||
1.1 - The Nature of Software | is a subtopic of Chapter 1 - Software and Software Engineering | ![]() | |||||||||||||||||||||
1.10 - Software and Software Engineering - References | is a subtopic of Chapter 1 - Software and Software Engineering | ![]() | |||||||||||||||||||||
1.2 - What is Software Engineering? | is a subtopic of Chapter 1 - Software and Software Engineering | ![]() | |||||||||||||||||||||
1.3 - Software Engineering as a Branch of the Engineering Profession | is a subtopic of Chapter 1 - Software and Software Engineering | ![]() | |||||||||||||||||||||
1.4 - Stakeholders in Software Engineering | is a subtopic of Chapter 1 - Software and Software Engineering | ![]() | |||||||||||||||||||||
1.5 - Software Quality | is a subtopic of Chapter 1 - Software and Software Engineering | ![]() | |||||||||||||||||||||
1.6 - Software Engineering Projects | is a subtopic of Chapter 1 - Software and Software Engineering | ![]() | |||||||||||||||||||||
1.7 - Activities Common to Software Projects | is a subtopic of Chapter 1 - Software and Software Engineering | ![]() | |||||||||||||||||||||
1.8 - The Eight Themes Emphasized in this Book | is a subtopic of Chapter 1 - Software and Software Engineering | ![]() | |||||||||||||||||||||
1.9 - Difficulties And Risks In Software Engineering as a Whole | is a subtopic of Chapter 1 - Software and Software Engineering | ![]() | |||||||||||||||||||||
10.1 - Basic Definitions | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
10.10 - Inspections | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
10.11 - Quality Assurance in General | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
10.13 - Difficulties and Risks in Quality Assurance | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
10.14 - Testing and Inspecting to Ensure High Quality - References | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
10.2 - Effective and Efficient Testing | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
10.3 - Defects in Ordinary Algorithms | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
10.4 - Defects in Numerical Algorithms | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
10.6 - Defects in Handling Stress and Unusual Situations | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
10.7 - Documentation Defects | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
10.8 - Writing Formal Test Cases and Test Plans | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
10.9 - Strategies for Testing Large Systems | is a subtopic of Chapter 10 - Testing and Inspecting to Ensure High Quality | ![]() | |||||||||||||||||||||
11.1 - What is Project Management? | is a subtopic of Chapter 11 - Managing the Software Process | ![]() | |||||||||||||||||||||
11.2 - Software Process Models | is a subtopic of Chapter 11 - Managing the Software Process | ![]() | |||||||||||||||||||||
11.3 - Cost Estimation | is a subtopic of Chapter 11 - Managing the Software Process | ![]() | |||||||||||||||||||||
11.4 - Building Software Engineering Teams | is a subtopic of Chapter 11 - Managing the Software Process | ![]() | |||||||||||||||||||||
11.5 - Project Scheduling and Tracking | is a subtopic of Chapter 11 - Managing the Software Process | ![]() | |||||||||||||||||||||
11.6 - Contents of a Project Plan | is a subtopic of Chapter 11 - Managing the Software Process | ![]() | |||||||||||||||||||||
11.8 - Managing the Software Process - References | is a subtopic of Chapter 11 - Managing the Software Process | ![]() | |||||||||||||||||||||
2.1 - What is Object Orientation? | is a subtopic of Chapter 2 - Review of Object Orientation | ![]() | |||||||||||||||||||||
2.10 - Difficulties and Risks in Programming Language Choice and Object-Oriented Programming | is a subtopic of Chapter 2 - Review of Object Orientation | ![]() | |||||||||||||||||||||
2.11 - Review of Object Orientation and Java - References | is a subtopic of Chapter 2 - Review of Object Orientation | ![]() | |||||||||||||||||||||
2.2 - Classes and Objects | is a subtopic of Chapter 2 - Review of Object Orientation | ![]() | |||||||||||||||||||||
2.3 - Instance Variables | is a subtopic of Chapter 2 - Review of Object Orientation | ![]() | |||||||||||||||||||||
2.4 - Methods, Operations and Polymorphism | is a subtopic of Chapter 2 - Review of Object Orientation | ![]() | |||||||||||||||||||||
2.5 - Organizing Classes Into Inheritance Hierarchies | is a subtopic of Chapter 2 - Review of Object Orientation | ![]() | |||||||||||||||||||||
2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarations | is a subtopic of Chapter 2 - Review of Object Orientation | ![]() | |||||||||||||||||||||
2.7 - Concepts that Define Object Orientation | is a subtopic of Chapter 2 - Review of Object Orientation | ![]() | |||||||||||||||||||||
3.1 - Reuse: Building on the Work and Experience of Others | is a subtopic of Chapter 3 - Basing Software Development on Reusable Technology | ![]() | |||||||||||||||||||||
3.11 - Basing Software Development on Reusable Technology - References | is a subtopic of Chapter 3 - Basing Software Development on Reusable Technology | ![]() | |||||||||||||||||||||
3.2 - Incorporating Reusability and Reuse Into Software Engineering | is a subtopic of Chapter 3 - Basing Software Development on Reusable Technology | ![]() | |||||||||||||||||||||
3.3 - Frameworks: Reusable Subsystems | is a subtopic of Chapter 3 - Basing Software Development on Reusable Technology | ![]() | |||||||||||||||||||||
3.4 - The Client-Server Architecture | is a subtopic of Chapter 3 - Basing Software Development on Reusable Technology | ![]() | |||||||||||||||||||||
3.5 - Technology Needed to Build Client-Server Systems | is a subtopic of Chapter 3 - Basing Software Development on Reusable Technology | ![]() | |||||||||||||||||||||
3.7 - Basic Description of OCSF- Client Side | is a subtopic of Chapter 3 - Basing Software Development on Reusable Technology | ![]() | |||||||||||||||||||||
4.1 - Domain Analysis | is a subtopic of Chapter 4 - Developing Requirements | ![]() | |||||||||||||||||||||
4.12 - Difficulties and Risks In Domain and Requirements Analysis | is a subtopic of Chapter 4 - Developing Requirements | ![]() | |||||||||||||||||||||
4.13 - Developing Requirements - References | is a subtopic of Chapter 4 - Developing Requirements | ![]() | |||||||||||||||||||||
4.2 - The Starting Point for Software Projects | is a subtopic of Chapter 4 - Developing Requirements | ![]() | |||||||||||||||||||||
4.3 - Defining The Problem and the Scope | is a subtopic of Chapter 4 - Developing Requirements | ![]() | |||||||||||||||||||||
4.4 - What Is a Requirement? | is a subtopic of Chapter 4 - Developing Requirements | ![]() | |||||||||||||||||||||
4.5 - Types of Requirements | is a subtopic of Chapter 4 - Developing Requirements | ![]() | |||||||||||||||||||||
4.6 - Some Techniques for Gathering and Analyzing Requirements | is a subtopic of Chapter 4 - Developing Requirements | ![]() | |||||||||||||||||||||
4.7 - Types of Requirements Document | is a subtopic of Chapter 4 - Developing Requirements | ![]() | |||||||||||||||||||||
4.8 - Reviewing Requirements | is a subtopic of Chapter 4 - Developing Requirements | ![]() | |||||||||||||||||||||
4.9 - Managing Changing Requirements | is a subtopic of Chapter 4 - Developing Requirements | ![]() | |||||||||||||||||||||
5.1 - What is UML? | is a subtopic of Chapter 5 - Modelling With Classes | ![]() | |||||||||||||||||||||
5.10 - Difficulties and Risks When Creating Class Diagrams | is a subtopic of Chapter 5 - Modelling With Classes | ![]() | |||||||||||||||||||||
5.11 - Modelling With Classes - References | is a subtopic of Chapter 5 - Modelling With Classes | ![]() | |||||||||||||||||||||
5.2 - Essentials of UML Class Diagrams | is a subtopic of Chapter 5 - Modelling With Classes | ![]() | |||||||||||||||||||||
5.3 - Associations and Multiplicity | is a subtopic of Chapter 5 - Modelling With Classes | ![]() | |||||||||||||||||||||
5.4 - Generalization | is a subtopic of Chapter 5 - Modelling With Classes | ![]() | |||||||||||||||||||||
5.5 - Instance Diagrams | is a subtopic of Chapter 5 - Modelling With Classes | ![]() | |||||||||||||||||||||
5.6 - More Advanced Features of Class Diagrams | is a subtopic of Chapter 5 - Modelling With Classes | ![]() | |||||||||||||||||||||
5.7 - Detailed Example: A Class Diagram for Genealogy | is a subtopic of Chapter 5 - Modelling With Classes | ![]() | |||||||||||||||||||||
5.8 - The Process Of Developing Class Diagrams | is a subtopic of Chapter 5 - Modelling With Classes | ![]() | |||||||||||||||||||||
5.9 - Implementing Class Diagrams in Java | is a subtopic of Chapter 5 - Modelling With Classes | ![]() | |||||||||||||||||||||
6.1 - Introduction to Patterns | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
6.10 - The Immutable Pattern | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
6.11 - The Read-Only Interface Pattern | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
6.12 - The Proxy Pattern | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
6.15 - Using Design Patterns - References | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
6.2 - The Abstraction-Occurrence Pattern | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
6.3 - The General Hierarchy Pattern | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
6.4 - The Player-Role Pattern | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
6.5 - The Singleton Pattern | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
6.6 - The Observer Pattern | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
6.7 - The Delegation Pattern | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
6.8 - The Adapter Pattern | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
6.9 - The Facade Pattern | is a subtopic of Chapter 6 - Using Design Patterns | ![]() | |||||||||||||||||||||
7.1 - User Centred Design | is a subtopic of Chapter 7 - Focusing on Users and Their Tasks | ![]() | |||||||||||||||||||||
7.3 - Developing Use Case Models of Systems | is a subtopic of Chapter 7 - Focusing on Users and Their Tasks | ![]() | |||||||||||||||||||||
7.4 - The Basics of User Interface Design | is a subtopic of Chapter 7 - Focusing on Users and Their Tasks | ![]() | |||||||||||||||||||||
7.5 - Usability Principles | is a subtopic of Chapter 7 - Focusing on Users and Their Tasks | ![]() | |||||||||||||||||||||
7.6 - Evaluating User Interfaces | is a subtopic of Chapter 7 - Focusing on Users and Their Tasks | ![]() | |||||||||||||||||||||
7.7 - Implementing a Simple GUI in Java | is a subtopic of Chapter 7 - Focusing on Users and Their Tasks | ![]() | |||||||||||||||||||||
7.9 - Focusing on Users and Their Tasks - References | is a subtopic of Chapter 7 - Focusing on Users and Their Tasks | ![]() | |||||||||||||||||||||
8.1 - Interaction Diagrams | is a subtopic of Chapter 8 - Modelling Interactions and Behaviour | ![]() | |||||||||||||||||||||
8.2 - State Diagrams | is a subtopic of Chapter 8 - Modelling Interactions and Behaviour | ![]() | |||||||||||||||||||||
8.3 - Activity Diagrams | is a subtopic of Chapter 8 - Modelling Interactions and Behaviour | ![]() | |||||||||||||||||||||
8.5 - Modelling Interactions and Behaviour - References | is a subtopic of Chapter 8 - Modelling Interactions and Behaviour | ![]() | |||||||||||||||||||||
80-20 rule | has 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 work | ![]() | |||||||||||||||||||||
has purpose to justify cutting less important requirements to significantly reduce costs | ![]() | ||||||||||||||||||||||
is a subtopic of 4.8 - Reviewing Requirements | ![]() | ||||||||||||||||||||||
is a synonym of Pareto principle | ![]() | ||||||||||||||||||||||
is an instance of rule | ![]() | ||||||||||||||||||||||
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 work | ![]() | ||||||||||||||||||||||
9.1 - The Process of Design | is a subtopic of Chapter 9 - Architecting and designing software | ![]() | |||||||||||||||||||||
9.2 - Principles Leading to Good Design | is a subtopic of Chapter 9 - Architecting and designing software | ![]() | |||||||||||||||||||||
9.3 - Techniques for Making Good Design Decisions | is a subtopic of Chapter 9 - Architecting and designing software | ![]() | |||||||||||||||||||||
9.4 - Software Architecture | is a subtopic of Chapter 9 - Architecting and designing software | ![]() | |||||||||||||||||||||
9.5 - Architectural Patterns | is a subtopic of Chapter 9 - Architecting and designing software | ![]() | |||||||||||||||||||||
9.6 - Writing a Good Design Document | is a subtopic of Chapter 9 - Architecting and designing software | ![]() | |||||||||||||||||||||
9.9 - Architecting and designing software - References | is a subtopic of Chapter 9 - Architecting and designing software | ![]() | |||||||||||||||||||||
< | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java relational comparison operator | ![]() | ||||||||||||||||||||||
<= | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java relational comparison operator | ![]() | ||||||||||||||||||||||
= | indicates assignment | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java operator | ![]() | ||||||||||||||||||||||
== | 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 values | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java identity comparison operator | ![]() | ||||||||||||||||||||||
returns a boolean | ![]() | ||||||||||||||||||||||
> | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java relational comparison operator | ![]() | ||||||||||||||||||||||
>= | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java relational comparison operator | ![]() | ||||||||||||||||||||||
?: | 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 | ![]() | |||||||||||||||||||||
has purpose to execute one of two alternative expressions, depending on the value of a condition | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java operator | ![]() | ||||||||||||||||||||||
can shorten code but can also make code harder to understand | ![]() | ||||||||||||||||||||||
A Pattern Language | has author C. Alexander | ![]() | |||||||||||||||||||||
has ISBN number 0-19-501919-9 | ![]() | ||||||||||||||||||||||
is a subtopic of 6.15 - Using Design Patterns - References | ![]() | ||||||||||||||||||||||
is an instance of book about design patterns | ![]() | ||||||||||||||||||||||
was published by Oxford University Press | ![]() | ||||||||||||||||||||||
was published in 1977 | ![]() | ||||||||||||||||||||||
abbreviation | is a kind of kbTop | ![]() | |||||||||||||||||||||
abstract | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
is used to declare abstract class | ![]() | ||||||||||||||||||||||
is used to declare abstract method | ![]() | ||||||||||||||||||||||
abstract class | has definition A class that cannot have any instances | ![]() | |||||||||||||||||||||
has part abstract method | ![]() | ||||||||||||||||||||||
has purpose to hold features that will be inherited by two or more subclasses | ![]() | ||||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can have concrete methods or instance variables | ![]() | ||||||||||||||||||||||
cannot have instances | ![]() | ||||||||||||||||||||||
abstract method | has purpose to serve as a placeholder, indicating that subclasses must have concrete implementations | ![]() | |||||||||||||||||||||
is a kind of method | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
abstract operation | has definition An operation in a class that makes logical sense for all subclasses, but that is not implemented in the class | ![]() | |||||||||||||||||||||
is a kind of operation | ![]() | ||||||||||||||||||||||
is a subtopic of 2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarations | ![]() | ||||||||||||||||||||||
abstract sound | has advantages attracts attention rapidly even if the person is not looking at the screen | ![]() | |||||||||||||||||||||
has example beep | ![]() | ||||||||||||||||||||||
has problems
| ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
abstraction | has definition A representation that captures only essential aspects of something, reducing the complexity apparent to the abstraction's user | ![]() | |||||||||||||||||||||
hides details which can be shown | ![]() | ||||||||||||||||||||||
is a kind of representation | ![]() | ||||||||||||||||||||||
is a subtopic of 2.1 - What is Object Orientation? | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
abstraction-occurrence | has antipatterns
| ![]() | |||||||||||||||||||||
has context class diagrams that form part of a system domain model | ![]() | ||||||||||||||||||||||
has definition A pattern in which two classes are related by an association, and one of the classes represents an abstraction of the other | ![]() | ||||||||||||||||||||||
has forces
| ![]() | ||||||||||||||||||||||
has problem What is the best way to represent sets of occurrences in a class diagram? | ![]() | ||||||||||||||||||||||
has references a generalization of the Title-Item pattern of Eriksson and Penker | ![]() | ||||||||||||||||||||||
has related patterns Abstraction-Occurrence Square pattern if the abstraction is an aggregate (and the occurrences are also aggregates) | ![]() | ||||||||||||||||||||||
has solution
| ![]() | ||||||||||||||||||||||
is a subtopic of 6.2 - The Abstraction-Occurrence Pattern | ![]() | ||||||||||||||||||||||
is an instance of design pattern | ![]() | ||||||||||||||||||||||
abstraction^2 | has definition The quality of software in which only the essential aspects of something are captured, reducing the complexity apparent to the user | ![]() | |||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is increased by | ![]() | ||||||||||||||||||||||
acceptability | has definition The extent to which customers and users like a system | ![]() | |||||||||||||||||||||
is subjective | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is affected by many factors, including other aspects of usability, graphic design and various aesthetic issues | ![]() | ||||||||||||||||||||||
measures how much users like the system | ![]() | ||||||||||||||||||||||
acceptance testing | has definition Testing performed by customers, on their own initiative, to decide whether software is sufficiently acceptable to pay for | ![]() | |||||||||||||||||||||
has purpose | ![]() | ||||||||||||||||||||||
is a kind of testing performed by users and clients | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
is performed by customers on their own initiative | ![]() | ||||||||||||||||||||||
ACM | is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | |||||||||||||||||||||
is an abbreviation for The Association for Computing Machinery | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
ACM/IEEE software engineering code of ethics | has URL www.acm.org/serving/se/code.htm ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of software engineering web site | ![]() | ||||||||||||||||||||||
action | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
action symbol | is a kind of symbol in state diagram | ![]() | |||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a slash and the name of the action | ![]() | ||||||||||||||||||||||
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 state | ![]() | ||||||||||||||||||||||
is drawn as event/action If the action is to be performed during a transition | ![]() | ||||||||||||||||||||||
action^2 | has definition Something that takes place effectively instantaneously when a transition occurs in a state diagram, or upon entry or exit from a state | ![]() | |||||||||||||||||||||
has example as sending a message, starting a hardware device or setting a variable | ![]() | ||||||||||||||||||||||
is a kind of action | ![]() | ||||||||||||||||||||||
is a kind of computation | ![]() | ||||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
is caused by one of the following situations:
| ![]() | ||||||||||||||||||||||
occurs instantaneously | ![]() | ||||||||||||||||||||||
must be simple because it should take place with no noticeable consumption of time | ![]() | ||||||||||||||||||||||
activation box | has definition A box on a lifeline in a sequence diagram indicating the period of time during which an object is actively performing work | ![]() | |||||||||||||||||||||
is a kind of symbol in sequence diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a rectangle | ![]() | ||||||||||||||||||||||
represents an object performing computations | ![]() | ||||||||||||||||||||||
activity | has definition Something that occurs over a period of time and takes place while the system is in a state | ![]() | |||||||||||||||||||||
is a kind of computation | ![]() | ||||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
activity diagram | has advantage it can represent concurrent activities | ![]() | |||||||||||||||||||||
has definition A UML diagram showing sequences of activities, typically for multiple threads | ![]() | ||||||||||||||||||||||
has part fork | ![]() | ||||||||||||||||||||||
has part join | ![]() | ||||||||||||||||||||||
has part rendezvous | ![]() | ||||||||||||||||||||||
is a kind of UML diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
is usually associated with several classes | ![]() | ||||||||||||||||||||||
shows how systems behave internally | ![]() | ||||||||||||||||||||||
shows the partition of activities among the existing classes using swimlanes | ![]() | ||||||||||||||||||||||
can represent
| ![]() | ||||||||||||||||||||||
activity | must be completed before the system leaves the current state as the result of some transition | ![]() | |||||||||||||||||||||
activity symbol | is a kind of symbol in state diagram | ![]() | |||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a box within the state, containing the word 'do:' followed by a description of what is to be done | ![]() | ||||||||||||||||||||||
actor | has definition A role that a user or some other system plays when interacting with your system; a class of user of a system | ![]() | |||||||||||||||||||||
has goals for using the system, and a given user may have different roles from time to time | ![]() | ||||||||||||||||||||||
is a kind of user | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
actor symbol | is a kind of symbol in UML diagram | ![]() | |||||||||||||||||||||
is a kind of symbol in use case diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
is drawn as a stick man | ![]() | ||||||||||||||||||||||
adapter | has context
| ![]() | |||||||||||||||||||||
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 adaptee | ![]() | ||||||||||||||||||||||
has forces You do not have access to multiple inheritance or you do not want to use it. | ![]() | ||||||||||||||||||||||
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? | ![]() | ||||||||||||||||||||||
has references one of the Gang of Four patterns. | ![]() | ||||||||||||||||||||||
has related patterns facade, read-only interface, proxy | ![]() | ||||||||||||||||||||||
has solution
| ![]() | ||||||||||||||||||||||
is a subtopic of 6.8 - The Adapter Pattern | ![]() | ||||||||||||||||||||||
is an instance of design pattern | ![]() | ||||||||||||||||||||||
adaptive maintenance | has 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 changes | ![]() | |||||||||||||||||||||
is a kind of maintenance | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
does not result in new capabilities for the user except the ability to operate the software in the changed environment | ![]() | ||||||||||||||||||||||
adaptive project | involves changing the system in response to changes in the environment in which the software runs | ![]() | |||||||||||||||||||||
is a kind of evolutionary project | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
adding and deleting links of associations | is complex since there is the need to collaborate with other classes to ensure the bi-directional nature of most associations is maintained properly | ![]() | |||||||||||||||||||||
is a kind of responsibility | ![]() | ||||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is often omitted from a model because the presence of such responsibilities can largely be inferred from the class diagram | ![]() | ||||||||||||||||||||||
address format | has localization issues | ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
affordance | has definition The set of operations that the user can do in a user interface at any given point in time | ![]() | |||||||||||||||||||||
has example the set of typing into an input field, clicking on a button or selecting an item from a menu | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
aggregate | has definition The class on the 'whole' side of an aggregation | ![]() | |||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
is a synonym of assembly | ![]() | ||||||||||||||||||||||
aggregation | has definition An association, which specifies that instances of one class contain instances of the other class as parts | ![]() | |||||||||||||||||||||
is a kind of association | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a diamond next to the 'whole' end of the association in a UML class diagram | ![]() | ||||||||||||||||||||||
represents 'part-whole' relationships | ![]() | ||||||||||||||||||||||
can be drawn as a hierarchy but the use of such hierarchies in valid models is quite rare | ![]() | ||||||||||||||||||||||
algorithm | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 10.4 - Defects in Numerical Algorithms | ![]() | ||||||||||||||||||||||
algorithm design | has definition The design of computational mechanisms | ![]() | |||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
algorithmic cost estimation model | has definition An approach to cost estimation such as COCOMO or function points, that use mathematical formulas whose parameters are based on industrial experience | ![]() | |||||||||||||||||||||
has example formula E = a + bNc where | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
provides provide formulas to compute anticipated cost of a project, taking into account various aspects of the project's size and complexity | ![]() | ||||||||||||||||||||||
uses formula | ![]() | ||||||||||||||||||||||
was developed by looking at a wide range of software development projects | ![]() | ||||||||||||||||||||||
All project management | has URL www.allpm.com ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of web site about project management | ![]() | ||||||||||||||||||||||
allowance for maintainability and enhancement | describes changes that are anticipated for subsequent releases | ![]() | |||||||||||||||||||||
is a kind of non-functional requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
allowance for reusability | describes the percentage of the system, measured in lines of code, that must be designed generically so that it can be reused | ![]() | |||||||||||||||||||||
is a kind of non-functional requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
alpha testing | has advantage | ![]() | |||||||||||||||||||||
has definition Testing performed by the user or client, under the supervision of the software development team | ![]() | ||||||||||||||||||||||
is a kind of testing performed by users and clients | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
amount of elapsed time | is a kind of event | ![]() | |||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
An Introduction to Object Oriented Programming with Java | has author C. Thomas Wu | ![]() | |||||||||||||||||||||
has ISBN number 0-07-239684-9 | ![]() | ||||||||||||||||||||||
has URL www.drcaffeine.com/ ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of book about Java programming | ![]() | ||||||||||||||||||||||
was published by McGraw Hill | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
An Investigation of the Therac-25 Accident | has author N.G. Leveson and C.S. Turner | ![]() | |||||||||||||||||||||
has date July 1993 | ![]() | ||||||||||||||||||||||
has publication IEEE Computer, Vol. 26, No. 7 | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of article about software failures | ![]() | ||||||||||||||||||||||
analysis | is a kind of process | ![]() | |||||||||||||||||||||
is a subtopic of 2.2 - Classes and Objects | ![]() | ||||||||||||||||||||||
animation | has advantages
| ![]() | |||||||||||||||||||||
has problems
| ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
anticipating obsolescence | assumes that changes will inevitably occur in the technology a software system uses and the environment in which it runs | ![]() | |||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is an instance of design principle | ![]() | ||||||||||||||||||||||
means planning for changes in the technology or environment so the software will continue to run or can be easily changed | ![]() | ||||||||||||||||||||||
can be accomplished by
| ![]() | ||||||||||||||||||||||
antipattern | has definition A solution to a design problem that is inferior or does not work in this context | ![]() | |||||||||||||||||||||
is a kind of design pattern | ![]() | ||||||||||||||||||||||
is a subtopic of 6.1 - Introduction to Patterns | ![]() | ||||||||||||||||||||||
is part of design pattern | ![]() | ||||||||||||||||||||||
Antipatterns: Refactoring Software, Architectures, and Projects in Crisis | has author W.H. Brown, R.C. Malveau, H.W. McCormick III, T.J. Mowbray | ![]() | |||||||||||||||||||||
has ISBN number 0-471-19713-0 | ![]() | ||||||||||||||||||||||
is a subtopic of 6.15 - Using Design Patterns - References | ![]() | ||||||||||||||||||||||
is an instance of book about design patterns | ![]() | ||||||||||||||||||||||
was published by Wiley | ![]() | ||||||||||||||||||||||
was published in 1998 | ![]() | ||||||||||||||||||||||
API | is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | |||||||||||||||||||||
is an abbreviation for Application Program Interface | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
application | has definition A program used by an end-user, as opposed to one simply used by other programs | ![]() | |||||||||||||||||||||
is a kind of program | ![]() | ||||||||||||||||||||||
application framework | has 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 applications | ![]() | |||||||||||||||||||||
is a synonym of vertical framework | ![]() | ||||||||||||||||||||||
Application Program Interface | has definition The set of procedures or methods through which a layer provides its services | ![]() | |||||||||||||||||||||
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 effects | ![]() | ||||||||||||||||||||||
is a kind of interface^2 | ![]() | ||||||||||||||||||||||
is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | ||||||||||||||||||||||
is abbreviated as API | ![]() | ||||||||||||||||||||||
application | typically uses only a subset of the framework's services | ![]() | |||||||||||||||||||||
Applied Software Architecture | has author Christine Hofmeister, Robert Nord, Dilip Soni | ![]() | |||||||||||||||||||||
has ISBN number 0-201-32571-3 | ![]() | ||||||||||||||||||||||
is a subtopic of 9.9 - Architecting and designing software - References | ![]() | ||||||||||||||||||||||
is an instance of software architecture book | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
approach to identifying generalizations | is a kind of principle | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
Aptest's software testing links | has URL www.aptest.com/resources.html ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of web site about software testing | ![]() | ||||||||||||||||||||||
architect | has definition The person responsible for leading the decision-making about the architecture, and maintaining the architectural model | ![]() | |||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 11.4 - Building Software Engineering Teams | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
architectural model | assists with
| ![]() | |||||||||||||||||||||
contains information about the interfaces and dynamic interactions among the subsystems | ![]() | ||||||||||||||||||||||
defines the terms that people use when they communicate with each other about lower-level details | ![]() | ||||||||||||||||||||||
has definition The document produced as a result of performing software architecture | ![]() | ||||||||||||||||||||||
has purpose | ![]() | ||||||||||||||||||||||
is a kind of document | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
is a synonym of software architecture^3 | ![]() | ||||||||||||||||||||||
shows each system component, encouraging reuse | ![]() | ||||||||||||||||||||||
can be used to communicate with customers | ![]() | ||||||||||||||||||||||
may be expressed as several different views such as
| ![]() | ||||||||||||||||||||||
must be stable which means that the new features can be easily added with only small changes to the architecture | ![]() | ||||||||||||||||||||||
should be generic to ensure reusability | ![]() | ||||||||||||||||||||||
architectural modeller | is a kind of modeller | ![]() | |||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
performs architectural modelling | ![]() | ||||||||||||||||||||||
refines architectural model by following these steps iteratively:
| ![]() | ||||||||||||||||||||||
uses UML diagrams | ![]() | ||||||||||||||||||||||
should apply design principles | ![]() | ||||||||||||||||||||||
should avoid circular dependencies among packages | ![]() | ||||||||||||||||||||||
should make the interface of a package as simple as possible to simplify its use and testing | ![]() | ||||||||||||||||||||||
architectural modelling | follows these steps iteratively:
| ![]() | |||||||||||||||||||||
has challenge is to produce a relevant and synthetic picture of a large and complex system | ![]() | ||||||||||||||||||||||
is a kind of modelling | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
is performed by architectural modeller | ![]() | ||||||||||||||||||||||
uses UML diagrams | ![]() | ||||||||||||||||||||||
architectural pattern | allows you to design flexible systems using components that are as independent of each other as possible | ![]() | |||||||||||||||||||||
has definition A pattern used in software architecture | ![]() | ||||||||||||||||||||||
is a kind of pattern | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
is a synonym of architectural style | ![]() | ||||||||||||||||||||||
architectural style | is a synonym of architectural pattern | ![]() | |||||||||||||||||||||
architecture design | is a kind of design | ![]() | |||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
is a synonym of software architecture^2 | ![]() | ||||||||||||||||||||||
ArgoUML | has URL argouml.tigris.org ![]() | ![]() | |||||||||||||||||||||
is an open source shareware project run by Tigris | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of tool for drawing UML diagrams | ![]() | ||||||||||||||||||||||
ArrayList | has methods set, add and remove | ![]() | |||||||||||||||||||||
has purpose to allow you to build collections of objects that grow as more objects are added | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java collection class | ![]() | ||||||||||||||||||||||
article | is a kind of publication | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
article about software failures | is a kind of article | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
ASCII | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of coding scheme | ![]() | ||||||||||||||||||||||
cannot represent all the symbols used in languages other than English | ![]() | ||||||||||||||||||||||
assembly | is a synonym of aggregate | ![]() | |||||||||||||||||||||
assertion | has definition A statement that must be true; if it becomes false then the software has encountered a failure | ![]() | |||||||||||||||||||||
is a kind of statement | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
assignment statement | has purpose to assign a value to a variable | ![]() | |||||||||||||||||||||
is a kind of statement | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
association | describes a relationship that will exist between instances at run time | ![]() | |||||||||||||||||||||
has default name "has" if it has neither an association name nor a role name | ![]() | ||||||||||||||||||||||
has definition A relationship between two classes that represents the existence of a set of links between objects of the two classes | ![]() | ||||||||||||||||||||||
has example class Person in a business application might have the following relationships supervisor (association to class Manager) and tasksToDo (association to class Task) | ![]() | ||||||||||||||||||||||
has part association name | ![]() | ||||||||||||||||||||||
has part role name | ![]() | ||||||||||||||||||||||
is bi-directional unless it has an arrow at one end indicating directionality | ![]() | ||||||||||||||||||||||
is legitimate only if its links will survive beyond the execution of any particular operation | ![]() | ||||||||||||||||||||||
is a kind of data abstraction | ![]() | ||||||||||||||||||||||
is a subtopic of 2.2 - Classes and Objects | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is drawn as a line, or set of connected lines, between two classes in a UML class diagram | ![]() | ||||||||||||||||||||||
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 variable | ![]() | ||||||||||||||||||||||
normally represents something that will be stored in a database | ![]() | ||||||||||||||||||||||
represents all the links between two classes that may ever exist | ![]() | ||||||||||||||||||||||
shows how two classes are related to each other | ![]() | ||||||||||||||||||||||
can have a label which is an association name or a role name | ![]() | ||||||||||||||||||||||
cannot be drawn as a hierarchy | ![]() | ||||||||||||||||||||||
association class | has definition A class whose instances are associated with links of a (usually many-to-many) association | ![]() | |||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is attached to an association | ![]() | ||||||||||||||||||||||
should be named using a noun that reflects the meaning of the association | ![]() | ||||||||||||||||||||||
Association for Computing Machinery | has web site www.acm.org ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is abbreviated as ACM | ![]() | ||||||||||||||||||||||
is an instance of organization | ![]() | ||||||||||||||||||||||
publishes Communications of the ACM | ![]() | ||||||||||||||||||||||
association | may be implemented in several ways in Java | ![]() | |||||||||||||||||||||
must not be added to a model unless it is relevant to the application - it will be needed to implement some requirement | ![]() | ||||||||||||||||||||||
association name | is a verb or verb phrase | ![]() | |||||||||||||||||||||
is a kind of label | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is placed next to the middle of the association in a UML diagram | ![]() | ||||||||||||||||||||||
may have an arrow next to it to indicate the direction in which to read the association | ![]() | ||||||||||||||||||||||
association | should 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 model | ![]() | |||||||||||||||||||||
should have sufficient names to make the association clear and unambiguous | ![]() | ||||||||||||||||||||||
association symbol | is a kind of symbol in UML diagram | ![]() | |||||||||||||||||||||
is a subtopic of 5.2 - Essentials of UML Class Diagrams | ![]() | ||||||||||||||||||||||
assuming a floating point value will be exactly equal to some other value | has testing strategy standard boundary testing | ![]() | |||||||||||||||||||||
is a kind of defect in a numerical algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.4 - Defects in Numerical Algorithms | ![]() | ||||||||||||||||||||||
asymmetric reflexive association | has definition A reflexive association in which the roles at either end are different. | ![]() | |||||||||||||||||||||
is a kind of reflexive association | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
should be labelled using role names instead of an association name | ![]() | ||||||||||||||||||||||
atomicity | has definition A property of a transaction that ensures it is completed entirely, or not at all | ![]() | |||||||||||||||||||||
is a kind of quality | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
attribute | has definition A simple data item present in all the instances of a class | ![]() | |||||||||||||||||||||
is a kind of data abstraction | ![]() | ||||||||||||||||||||||
is a kind of variable | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is implemented as an instance variable in Java | ![]() | ||||||||||||||||||||||
is used in the analysis and design stage before it is known how the attribute will be implemented | ![]() | ||||||||||||||||||||||
represents the properties of an object | ![]() | ||||||||||||||||||||||
can be identified by looking at the description of the system and searching for information that must be maintained about each class | ![]() | ||||||||||||||||||||||
must not be added to a model unless it is relevant to the application - it will be needed to implement some requirement | ![]() | ||||||||||||||||||||||
must not have a plural name | ![]() | ||||||||||||||||||||||
should be a simple variable - typically an integer or string, or a one-to-one composition | ![]() | ||||||||||||||||||||||
should be private | ![]() | ||||||||||||||||||||||
should not have an implicit internal structure | ![]() | ||||||||||||||||||||||
should not normally represent a variable number of things | ![]() | ||||||||||||||||||||||
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 it | ![]() | ||||||||||||||||||||||
attribute symbol | is a kind of symbol in UML diagram | ![]() | |||||||||||||||||||||
is a subtopic of 5.2 - Essentials of UML Class Diagrams | ![]() | ||||||||||||||||||||||
attribute^2 | has definition A detail in the requirements of a system | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 10.8 - Writing Formal Test Cases and Test Plans | ![]() | ||||||||||||||||||||||
can be found by circling all the important points in the requirements document | ![]() | ||||||||||||||||||||||
can be thought of as something that is testable | ![]() | ||||||||||||||||||||||
availability | has definition A quality that measures the amount of time that a system is running and able to provide services to its users | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of non-functional requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
measures the amount of time that a server is running and available to respond to users | ![]() | ||||||||||||||||||||||
average software project | exceeds its budget by 90% and its schedule by 120% according to the Standish Group ![]() | ![]() | |||||||||||||||||||||
is a kind of software project | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
is canceled before completion 30% of the time according to the Standish Group ![]() | ![]() | ||||||||||||||||||||||
AWT component | is simpler than Java Beans or Swing components but more limited | ![]() | |||||||||||||||||||||
is a kind of Java user interface component | ![]() | ||||||||||||||||||||||
is a subtopic of 7.7 - Implementing a Simple GUI in Java | ![]() | ||||||||||||||||||||||
bad project management | causes the average software projects to exceed its budge by 90% and its schedule by 120% | ![]() | |||||||||||||||||||||
is a kind of project management | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
bad software | is difficult to understand and modify | ![]() | |||||||||||||||||||||
is poorly designed | ![]() | ||||||||||||||||||||||
is a kind of software | ![]() | ||||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
can be easily created by an inadequately trained software developer | ![]() | ||||||||||||||||||||||
may partly work | ![]() | ||||||||||||||||||||||
base class | is the name for superclass in C++ | ![]() | |||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of 2.5 - Organizing Classes Into Inheritance Hierarchies | ![]() | ||||||||||||||||||||||
is a synonym of superclass | ![]() | ||||||||||||||||||||||
beginning user | is a kind of user | ![]() | |||||||||||||||||||||
is a kind of user | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
perceives that a system is easier to learn if the complex features are hidden from them initially by having separate 'beginner' and 'expert' interfaces | ![]() | ||||||||||||||||||||||
behaviour | has definition The way an object or system acts and reacts, possibly changing its state | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 2.2 - Classes and Objects | ![]() | ||||||||||||||||||||||
benefit | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 9.3 - Techniques for Making Good Design Decisions | ![]() | ||||||||||||||||||||||
beta tester | benefits by using the features of the software before others have access to them | ![]() | |||||||||||||||||||||
has definition A person performing beta testing | ![]() | ||||||||||||||||||||||
is a kind of tester | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
is given a pre-release version of the software | ![]() | ||||||||||||||||||||||
is recruited from the potential user population of a product | ![]() | ||||||||||||||||||||||
knows that the software will contain more defects than the final version | ![]() | ||||||||||||||||||||||
reports problems when he or she discovers them | ![]() | ||||||||||||||||||||||
beta testing | has advantage | ![]() | |||||||||||||||||||||
has definition Testing performed by the user or client in a normal work environment | ![]() | ||||||||||||||||||||||
is a kind of testing performed by users and clients | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
Beyond the Team | has author R.M. Belbin | ![]() | |||||||||||||||||||||
has ISBN number 0-585-23086-2 | ![]() | ||||||||||||||||||||||
has URL www.netlibrary.com/summary.asp?id=34027 ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of book about project management | ![]() | ||||||||||||||||||||||
was published by Butterworth-Heinermann | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
big bang testing | has definition An inappropriate approach to integration testing in which you take the entire integrated system and test it as a unit | ![]() | |||||||||||||||||||||
is a kind of integration testing | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
can work well on small systems | ![]() | ||||||||||||||||||||||
may not work well on larger systems because it may be hard to tell in which subsystem the defect lies when a failure occurs | ![]() | ||||||||||||||||||||||
black-box tester | has definition A person performing black-box testing | ![]() | |||||||||||||||||||||
is a kind of tester | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
observes outputs from the system | ![]() | ||||||||||||||||||||||
performs black-box testing | ![]() | ||||||||||||||||||||||
provides inputs to the system | ![]() | ||||||||||||||||||||||
does not see the source code, the internal data, nor any of the design documentation describing the system's internals | ![]() | ||||||||||||||||||||||
black-box testing | has definition A form of testing in which you manipulate inputs and observe outputs, but cannot observe the internals of the entity being tested | ![]() | |||||||||||||||||||||
involves providing the system with inputs and observing the outputs, without seeing what is going on inside | ![]() | ||||||||||||||||||||||
is less time consuming than glass-box testing | ![]() | ||||||||||||||||||||||
is a kind of testing | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
blind user | is a kind of user with a disability | ![]() | |||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
needs a program that converts text to Braille or speech | ![]() | ||||||||||||||||||||||
block | is a kind of programming language construct | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Blue Dawn Corporation: Software Testing Links | has URL www.bluedawncomp.com/stlinks.htm ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of web site about software testing | ![]() | ||||||||||||||||||||||
book | has author | ![]() | |||||||||||||||||||||
has ISBN number | ![]() | ||||||||||||||||||||||
is a kind of publication | ![]() | ||||||||||||||||||||||
was published by publisher | ![]() | ||||||||||||||||||||||
was published in | ![]() | ||||||||||||||||||||||
book about design patterns | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 6.15 - Using Design Patterns - References | ![]() | ||||||||||||||||||||||
book about frameworks | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
book about Java programming | is a kind of book about programming | ![]() | |||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
book about modelling interactions and behaviour | is a kind of book | ![]() | |||||||||||||||||||||
book about networking | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
book about object oriented development processes | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
book about process standards | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
book about programming | is a kind of book | ![]() | |||||||||||||||||||||
book about project management | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
book about requirements analysis | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 4.13 - Developing Requirements - References | ![]() | ||||||||||||||||||||||
book about software inspection | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
book about software quality assurance | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
book about software reuse | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
book about software testing | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
book about UML | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
book about user interfaces and usability | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
boolean | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java primitive data type | ![]() | ||||||||||||||||||||||
see also Boolean class | ![]() | ||||||||||||||||||||||
see also boolean^2 | ![]() | ||||||||||||||||||||||
can use == operator | ![]() | ||||||||||||||||||||||
Boolean class | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java wrapper class | ![]() | ||||||||||||||||||||||
see also boolean | ![]() | ||||||||||||||||||||||
boolean^2 | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
see also boolean | ![]() | ||||||||||||||||||||||
Borland JBuilder | has URL www.borland.com/ ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of programming environment | ![]() | ||||||||||||||||||||||
bottom-up approach to identifying generalizations | groups similar classes creating a new superclass | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is an instance of approach to identifying generalizations | ![]() | ||||||||||||||||||||||
is an instance of bottom-up design | ![]() | ||||||||||||||||||||||
bottom-up design | has advantage normally useful so that reusable components can be created; these can then be used in several places in the overall system | ![]() | |||||||||||||||||||||
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 system | ![]() | ||||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
bottom-up testing | has 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 layers | ![]() | |||||||||||||||||||||
has disadvantage the cost of writing the drivers | ![]() | ||||||||||||||||||||||
has procedure start by testing the very lowest levels of the software using a driver | ![]() | ||||||||||||||||||||||
is a kind of vertical incremental testing | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
boundary testing | has definition A testing strategy based on testing at the boundaries of equivalence classes - since this is where most errors occur | ![]() | |||||||||||||||||||||
is a kind of testing | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
Brad Appleton's description of patterns | has URL www.enteract.com/~bradapp/docs/patterns-intro.html ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 6.15 - Using Design Patterns - References | ![]() | ||||||||||||||||||||||
is an instance of web site about design patterns | ![]() | ||||||||||||||||||||||
brainstorming | has advantages
| ![]() | |||||||||||||||||||||
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 contribute | ![]() | ||||||||||||||||||||||
has procedure
| ![]() | ||||||||||||||||||||||
has purpose to gather information from a group of people | ![]() | ||||||||||||||||||||||
is a kind of requirements gathering | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
is related to Joint Application Development | ![]() | ||||||||||||||||||||||
uses a moderator (or facilitator) to lead the session | ![]() | ||||||||||||||||||||||
can help resolve conflicts over requirements | ![]() | ||||||||||||||||||||||
should be done with five to 20 people | ![]() | ||||||||||||||||||||||
break | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
Bredemeyer's resources for software architects | has URL www.bredemeyer.com ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 9.9 - Architecting and designing software - References | ![]() | ||||||||||||||||||||||
is an instance of web site about software architecture | ![]() | ||||||||||||||||||||||
British Standard 7925 | covers Software Testing | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of quality assurance and testing standard | ![]() | ||||||||||||||||||||||
broker | allows an object to call methods of another object without knowing that this object is remotely located | ![]() | |||||||||||||||||||||
distributes aspects of the software system to different nodes | ![]() | ||||||||||||||||||||||
facilitates divide and conquer since the remote objects can be independently designed | ![]() | ||||||||||||||||||||||
has definition An architectural pattern in which parts of the system are transparently distributed to different nodes of a network | ![]() | ||||||||||||||||||||||
increases cohesion because the remote objects have strong communicational cohesion | ![]() | ||||||||||||||||||||||
increases reusability because it is often possible to design the remote objects so that other systems can use them too | ![]() | ||||||||||||||||||||||
increases reuse because you may be able to reuse remote objects that others have created | ![]() | ||||||||||||||||||||||
is a kind of architectural pattern | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
brute force | is pointless because any given defect is likely to cause failures with many different input values | ![]() | |||||||||||||||||||||
is a kind of testing strategy | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
takes such a huge amount of time so as to be impractical | ![]() | ||||||||||||||||||||||
tests a method using every possible value | ![]() | ||||||||||||||||||||||
budgeted cost of work performed | is a synonym of earned value | ![]() | |||||||||||||||||||||
bug | has definition A colloquial term for defect or failure | ![]() | |||||||||||||||||||||
is a synonym of defect | ![]() | ||||||||||||||||||||||
is a synonym of failure | ![]() | ||||||||||||||||||||||
build | has definition The process of compiling and integrating all the components of the software, incorporating any changes since the last build | ![]() | |||||||||||||||||||||
involves compiling and integrating all the components of the software, incorporating any changes since the last time this was done | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
may be done on a daily or weekly basis | ![]() | ||||||||||||||||||||||
burdened cost | is a synonym of weighted average cost | ![]() | |||||||||||||||||||||
Business Modelling with UML: Business Patterns at Work | has author H-E. Eriksson and M. Penker | ![]() | |||||||||||||||||||||
has ISBN number ISBN 0-471-29551-5 | ![]() | ||||||||||||||||||||||
is a subtopic of 6.15 - Using Design Patterns - References | ![]() | ||||||||||||||||||||||
is an instance of book about design patterns | ![]() | ||||||||||||||||||||||
was published by Wiley | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
business process | has definition A process performed by people in an organization | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 4.9 - Managing Changing Requirements | ![]() | ||||||||||||||||||||||
business process change | has definition A change to the way a business does things | ![]() | |||||||||||||||||||||
is common | ![]() | ||||||||||||||||||||||
is a kind of change | ![]() | ||||||||||||||||||||||
is a subtopic of 4.9 - Managing Changing Requirements | ![]() | ||||||||||||||||||||||
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 company | ![]() | ||||||||||||||||||||||
may force changes in a requirement | ![]() | ||||||||||||||||||||||
business process | may be automated by software system | ![]() | |||||||||||||||||||||
button | affords clicking if clicking on it would cause some action to occur. | ![]() | |||||||||||||||||||||
is a kind of user interface component | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
byte | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java primitive data type | ![]() | ||||||||||||||||||||||
requires 8 bits | ![]() | ||||||||||||||||||||||
see also Byte class | ![]() | ||||||||||||||||||||||
see also byte^2 | ![]() | ||||||||||||||||||||||
can use basic arithmetic operators +, -, *, / and % | ![]() | ||||||||||||||||||||||
Byte class | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java wrapper class | ![]() | ||||||||||||||||||||||
see also byte | ![]() | ||||||||||||||||||||||
byte | should not be used for textual data which is to be exposed to the end user | ![]() | |||||||||||||||||||||
byte^2 | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
see also byte | ![]() | ||||||||||||||||||||||
bytecode | is like a universal machine language | ![]() | |||||||||||||||||||||
is a kind of code | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is not designed to be read by human beings | ![]() | ||||||||||||||||||||||
can run on any computer that has an interpreter called a virtual machine | ![]() | ||||||||||||||||||||||
C compiler | compiles source code into machine code | ![]() | |||||||||||||||||||||
is a kind of compiler | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
C file | is a kind of C module | ![]() | |||||||||||||||||||||
is a kind of file | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
C function | is a kind of C module | ![]() | |||||||||||||||||||||
is a kind of function | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
C module | is a kind of module | ![]() | |||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
C++ | adds object oriented extensions to C | ![]() | |||||||||||||||||||||
has much the same syntax as C | ![]() | ||||||||||||||||||||||
has disadvantages | ![]() | ||||||||||||||||||||||
has feature macros | ![]() | ||||||||||||||||||||||
has feature multiple inheritance | ![]() | ||||||||||||||||||||||
has feature operator overloading | ![]() | ||||||||||||||||||||||
has feature pointer arithmetic | ![]() | ||||||||||||||||||||||
is the most widely used object oriented language | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of object oriented language | ![]() | ||||||||||||||||||||||
was developed by Bjarne Stroustrup | ![]() | ||||||||||||||||||||||
C++ compiler | compiles source code into machine code | ![]() | |||||||||||||||||||||
is a kind of compiler | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
C++ source code | is a kind of source code | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
may be placed outside a class | ![]() | ||||||||||||||||||||||
Cadillac system | has definition A system that does more than is needed | ![]() | |||||||||||||||||||||
is a kind of software system | ![]() | ||||||||||||||||||||||
is a subtopic of 4.8 - Reviewing Requirements | ![]() | ||||||||||||||||||||||
calendar | has localization issues
| ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
Calendar class | allows for the use of calendars of specific cultures | ![]() | |||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
is an instance of Java class | ![]() | ||||||||||||||||||||||
can-be-seen-as relation | characterizes the relation between the implementing class and the interface | ![]() | |||||||||||||||||||||
has example classes representing bank employees and automatic teller machines - both can be seen as a sort of cashier | ![]() | ||||||||||||||||||||||
is a kind of relation | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
case | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
casting | has example (String)i.next() | ![]() | |||||||||||||||||||||
has purpose to convert an instance of one data type into another which is a subclass of the original type | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
catalog of reusable components | contains information about reusable components | ![]() | |||||||||||||||||||||
is a kind of document | ![]() | ||||||||||||||||||||||
is a subtopic of 3.2 - Incorporating Reusability and Reuse Into Software Engineering | ![]() | ||||||||||||||||||||||
must be easy to search | ![]() | ||||||||||||||||||||||
must be kept up-to-date | ![]() | ||||||||||||||||||||||
must deprecate older components that have been found to be unreliable or have been superseded by better components | ![]() | ||||||||||||||||||||||
catch | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
Cetus Links on UML | has URL www.cetus-links.org/oo_uml.html ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of web site about UML | ![]() | ||||||||||||||||||||||
change | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 4.9 - Managing Changing Requirements | ![]() | ||||||||||||||||||||||
change to requirements | has unpredictable rate | ![]() | |||||||||||||||||||||
is a kind of change | ![]() | ||||||||||||||||||||||
is a subtopic of 4.9 - Managing Changing Requirements | ![]() | ||||||||||||||||||||||
can be rapid | ![]() | ||||||||||||||||||||||
can cause requirements creep | ![]() | ||||||||||||||||||||||
can result in a deteriorating design if the original design did adequately anticipate the changes | ![]() | ||||||||||||||||||||||
can result in completed work being wasted | ![]() | ||||||||||||||||||||||
should not make the system bigger | ![]() | ||||||||||||||||||||||
should only be made if benefits exceed the costs | ![]() | ||||||||||||||||||||||
Chapter 1 - Software and Software Engineering | is a subtopic of kbTop | ![]() | |||||||||||||||||||||
Chapter 10 - Testing and Inspecting to Ensure High Quality | is a subtopic of kbTop | ![]() | |||||||||||||||||||||
Chapter 11 - Managing the Software Process | is a subtopic of kbTop | ![]() | |||||||||||||||||||||
Chapter 2 - Review of Object Orientation | is a subtopic of kbTop | ![]() | |||||||||||||||||||||
Chapter 3 - Basing Software Development on Reusable Technology | is a subtopic of kbTop | ![]() | |||||||||||||||||||||
Chapter 4 - Developing Requirements | is a subtopic of kbTop | ![]() | |||||||||||||||||||||
Chapter 5 - Modelling With Classes | is a subtopic of kbTop | ![]() | |||||||||||||||||||||
Chapter 6 - Using Design Patterns | is a subtopic of kbTop | ![]() | |||||||||||||||||||||
Chapter 7 - Focusing on Users and Their Tasks | is a subtopic of kbTop | ![]() | |||||||||||||||||||||
Chapter 8 - Modelling Interactions and Behaviour | is a subtopic of kbTop | ![]() | |||||||||||||||||||||
Chapter 9 - Architecting and designing software | is a subtopic of kbTop | ![]() | |||||||||||||||||||||
char | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java primitive data type | ![]() | ||||||||||||||||||||||
see also char^2 | ![]() | ||||||||||||||||||||||
see also Character | ![]() | ||||||||||||||||||||||
can use basic arithmetic operators +, -, *, / and % | ![]() | ||||||||||||||||||||||
char^2 | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
see also char | ![]() | ||||||||||||||||||||||
Character | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java wrapper class | ![]() | ||||||||||||||||||||||
see also char | ![]() | ||||||||||||||||||||||
character set | has localization issues | ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
Chartered Engineer | has definition A term used in the United Kingdom, and certain other jurisdictions, that is equivalent to professional engineer | ![]() | |||||||||||||||||||||
is a kind of engineer | ![]() | ||||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
chemical engineering | is a kind of engineering | ![]() | |||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
chief programmer team | advocates that the chief programmer leads and guides the project; however he consults with, and relies on, individual specialists | ![]() | |||||||||||||||||||||
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 specialties | ![]() | ||||||||||||||||||||||
is like a surgical team | ![]() | ||||||||||||||||||||||
is a kind of software engineering team model | ![]() | ||||||||||||||||||||||
is a subtopic of 11.4 - Building Software Engineering Teams | ![]() | ||||||||||||||||||||||
civil engineering | is a kind of engineering | ![]() | |||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
class | contains all of the code that relates to its objects including | ![]() | |||||||||||||||||||||
contains data associated with each object | ![]() | ||||||||||||||||||||||
declares a list of variables, called instance variables, corresponding to data that will be present in each instance | ![]() | ||||||||||||||||||||||
has definition A software module that provides both procedural and data abstraction. It describes a set of similar objects, called its instances | ![]() | ||||||||||||||||||||||
has part class name | ![]() | ||||||||||||||||||||||
has part class variable | ![]() | ||||||||||||||||||||||
has part code | ![]() | ||||||||||||||||||||||
has part constructor | ![]() | ||||||||||||||||||||||
has part instance variable | ![]() | ||||||||||||||||||||||
has part method | ![]() | ||||||||||||||||||||||
has part variables | ![]() | ||||||||||||||||||||||
is an abstract representation of all the instances of that class that may ever exist | ![]() | ||||||||||||||||||||||
is probably useless if it has no responsibilities attached to it | ![]() | ||||||||||||||||||||||
is the unit of data abstraction in an object-oriented program | ![]() | ||||||||||||||||||||||
is a kind of data abstraction | ![]() | ||||||||||||||||||||||
is a kind of programming language construct | ![]() | ||||||||||||||||||||||
is a subtopic of 2.2 - Classes and Objects | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is divided up into methods | ![]() | ||||||||||||||||||||||
is drawn as a box with the name of the class inside in a UML class diagram | ![]() | ||||||||||||||||||||||
is needed in a domain model if you have to store or manipulate instances of it in order to implement a requirement | ![]() | ||||||||||||||||||||||
represents several similar objects | ![]() | ||||||||||||||||||||||
see also class^2 | ![]() | ||||||||||||||||||||||
can have instances | ![]() | ||||||||||||||||||||||
class design | has definition The design of the various features of classes such as associations, attributes, interactions and states | ![]() | |||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
class diagram | describes the data found in a software system | ![]() | |||||||||||||||||||||
has definition A UML diagram that primarily indicates classes and the associations between those classes | ![]() | ||||||||||||||||||||||
has part OCL statement in a class diagram | ![]() | ||||||||||||||||||||||
is an important tool for requirements analysis and design of object oriented software systems | ![]() | ||||||||||||||||||||||
is a kind of UML diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
shows the services offered by components and the main data to be stored | ![]() | ||||||||||||||||||||||
can contain symbols for classes, associations, attributes, operations, generalizations | ![]() | ||||||||||||||||||||||
can generate an infinite number of instance diagrams | ![]() | ||||||||||||||||||||||
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. | ![]() | ||||||||||||||||||||||
may show that a class has no attributes or operations by showing an empty box | ![]() | ||||||||||||||||||||||
class method | has definition A method that, unlike an instance method, does not execute in the context of a particular instance of a class | ![]() | |||||||||||||||||||||
has purpose implementing functions such as initializing a class, or operating on the complete set of instances of a class | ![]() | ||||||||||||||||||||||
is a kind of method | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is a synonym of static method | ![]() | ||||||||||||||||||||||
should not be overused | ![]() | ||||||||||||||||||||||
class name | is a kind of name | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is written in the singular by convention | ![]() | ||||||||||||||||||||||
can be chosen from nouns or noun phrases in source material unless they are
| ![]() | ||||||||||||||||||||||
should be a noun by convention | ![]() | ||||||||||||||||||||||
should not be too general or too specific | ![]() | ||||||||||||||||||||||
class | should be created to hold a responsibility if the responsibility cannot be attributed to any of the existing classes | ![]() | |||||||||||||||||||||
should be named after things their instances represent in the real world | ![]() | ||||||||||||||||||||||
should have a comment at the top describing the purpose of the class, how it should be used, its authors and its history of modification | ![]() | ||||||||||||||||||||||
should not be named after the internals of a computer system such as 'Record', 'Table', 'Data', 'Structure', or 'Information' | ![]() | ||||||||||||||||||||||
class symbol | is a kind of symbol in UML diagram | ![]() | |||||||||||||||||||||
is a subtopic of 5.2 - Essentials of UML Class Diagrams | ![]() | ||||||||||||||||||||||
class variable | has a value that is shared by all instances of a class | ![]() | |||||||||||||||||||||
has definition A data item present in a class that is shared by all instances of that class | ![]() | ||||||||||||||||||||||
has purpose storing: | ![]() | ||||||||||||||||||||||
is a kind of variable | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is a synonym of static variable | ![]() | ||||||||||||||||||||||
is shared by all instances of the class | ![]() | ||||||||||||||||||||||
should not be overused | ![]() | ||||||||||||||||||||||
class^2 | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
see also class | ![]() | ||||||||||||||||||||||
Classical and Object Oriented Software Engineering, with UML and C++/Java | has author S. Schach | ![]() | |||||||||||||||||||||
has ISBN number 0-07-230226-7 | ![]() | ||||||||||||||||||||||
has web site www.mhhe.com/engcs/compsci/schach/ ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of software engineering book | ![]() | ||||||||||||||||||||||
was published by McGraw Hill | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
clicking a button | is a kind of command | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
client | is a synonym of customer | ![]() | |||||||||||||||||||||
see also client | ![]() | ||||||||||||||||||||||
client-server architecture | has advantages
| ![]() | |||||||||||||||||||||
has alternatives | ![]() | ||||||||||||||||||||||
has definition An architectural pattern in which the system is divided into clients and servers | ![]() | ||||||||||||||||||||||
is one of the most widely used ways of structuring software systems | ![]() | ||||||||||||||||||||||
is a kind of distributed architecture | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
client-server architecture in Webopedia | has URL webopedia.internet.com/TERM/c/client_server_architecture.html ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
is an instance of web site about the client-server architecture | ![]() | ||||||||||||||||||||||
client-server newsgroup | has address news:comp.client-server | ![]() | |||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
is an instance of newsgroup | ![]() | ||||||||||||||||||||||
client-server system | generally 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 input | ![]() | |||||||||||||||||||||
has interaction
| ![]() | ||||||||||||||||||||||
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 organizations | ![]() | ||||||||||||||||||||||
involves at least one server and one client | ![]() | ||||||||||||||||||||||
is inherently concurrent because the server runs concurrently with the clients, normally (but not necessarily) on different computers | ![]() | ||||||||||||||||||||||
is prone to security violations, due to the fact that information is transmitted over a network | ![]() | ||||||||||||||||||||||
is vulnerable to interruptions in communication or denial-of-service attacks | ![]() | ||||||||||||||||||||||
is a kind of distributed system | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
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 flexible | ![]() | ||||||||||||||||||||||
should incorporate encryption, firewalls and similar methods of ensuring security | ![]() | ||||||||||||||||||||||
client^2 | does concurrently | ![]() | |||||||||||||||||||||
handles the disconnection of the server, because the server crashed or the network failed or because either the client or server requested disconnection | ![]() | ||||||||||||||||||||||
has definition A program or process that connects to another program or process, using a communication channel, in order to request a service | ![]() | ||||||||||||||||||||||
initializes itself so it is able to communicate with the server | ![]() | ||||||||||||||||||||||
initiates a connection to a server | ![]() | ||||||||||||||||||||||
is a kind of process^2 | ![]() | ||||||||||||||||||||||
is a kind of program | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
reacts to messages coming from the server | ![]() | ||||||||||||||||||||||
see also client^2 | ![]() | ||||||||||||||||||||||
sends messages to the server to request services | ![]() | ||||||||||||||||||||||
terminates cleanly including includes disconnecting from a server if it is still connected | ![]() | ||||||||||||||||||||||
can also be a server at the same time | ![]() | ||||||||||||||||||||||
cannot connect with a server unless the server is listening | ![]() | ||||||||||||||||||||||
may access many servers to perform different functions | ![]() | ||||||||||||||||||||||
may be located on the same computer as its server or on a different computer | ![]() | ||||||||||||||||||||||
may try again to connect to the server if the server does not initially respond | ![]() | ||||||||||||||||||||||
must know the network address of the server | ![]() | ||||||||||||||||||||||
cloning | has definition The practice of duplicating chunks of code; considered bad practice except when copying just one or two lines of code | ![]() | |||||||||||||||||||||
is a synonym of duplication of code | ![]() | ||||||||||||||||||||||
CMM | is a subtopic of 10.11 - Quality Assurance in General | ![]() | |||||||||||||||||||||
is an abbreviation for Software Capability Maturity Model | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
CMM in Practice: Processes for Executing Software Projects at Infosys | has author P. Jalote | ![]() | |||||||||||||||||||||
has ISBN number 0-201-61626-2 | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of book about process standards | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
COCOMO | is a subtopic of 11.3 - Cost Estimation | ![]() | |||||||||||||||||||||
is an abbreviation for Constructive Cost Model | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
code | is a kind of representation | ![]() | |||||||||||||||||||||
code layout principle | is a kind of principle | ![]() | |||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
can be found at Sun ![]() | ![]() | ||||||||||||||||||||||
coder | has definition A programmer who limits their work to programming (i.e. who do no higher-level design or analysis) | ![]() | |||||||||||||||||||||
is a kind of programmer | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
does not do high-level analysis and design | ![]() | ||||||||||||||||||||||
CodeWarrior | has URL metrowerks.com ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of programming environment | ![]() | ||||||||||||||||||||||
coding scheme | is a kind of subject | ![]() | |||||||||||||||||||||
coding technique | has advantages | ![]() | |||||||||||||||||||||
has definition A way of representing information so as to communicate it to the user; e.g. using text, colour, icons, grouping, sound etc. | ![]() | ||||||||||||||||||||||
has problems | ![]() | ||||||||||||||||||||||
is a kind of representation | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is a synonym of encoding technique | ![]() | ||||||||||||||||||||||
cohesion | has 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 out | ![]() | |||||||||||||||||||||
has precedence table
| ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
cohesive module | is a kind of module | ![]() | |||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
can contain sub-modules with different types of cohesion | ![]() | ||||||||||||||||||||||
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 module | ![]() | ||||||||||||||||||||||
collaboration | is a kind of abstraction | ![]() | |||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
can be represented in a class diagram using a dashed ellipse | ![]() | ||||||||||||||||||||||
collaboration diagram | contains a communication link between each pair of objects involved in the sending of a message; the messages themselves are attached to this link | ![]() | |||||||||||||||||||||
has definition A UML interaction diagram showing a set of objects connected by communications links | ![]() | ||||||||||||||||||||||
has part communication link | ![]() | ||||||||||||||||||||||
is better than sequence diagram when you are deriving an interaction diagram from a class diagram | ![]() | ||||||||||||||||||||||
is similar to an instance diagram except that it does not show links of associations | ![]() | ||||||||||||||||||||||
is a kind of interaction diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
is drawn as as a graph with a set of objects and actors as the vertices | ![]() | ||||||||||||||||||||||
shows the relationships that exist among objects and actors | ![]() | ||||||||||||||||||||||
can help validate class diagrams | ![]() | ||||||||||||||||||||||
can represent aspects of a design pattern | ![]() | ||||||||||||||||||||||
collaboration symbol | is a kind of symbol in UML diagram | ![]() | |||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a dashed ellipse | ![]() | ||||||||||||||||||||||
is linked to classes that fulfill the various roles of the collaboration by dashed lines | ![]() | ||||||||||||||||||||||
collating sequence | has definition The order in which the letters of the alphabet are sorted | ![]() | |||||||||||||||||||||
has localization issues
| ![]() | ||||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
colour | has advantages
| ![]() | |||||||||||||||||||||
has problems
| ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
COM | is a subtopic of 9.5 - Architectural Patterns | ![]() | |||||||||||||||||||||
is an instance of broker | ![]() | ||||||||||||||||||||||
combinatorial explosion | has 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 increases | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
command | has definition An action that causes the system to perform some computations | ![]() | |||||||||||||||||||||
is a kind of action | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
comment | has 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 code | ![]() | |||||||||||||||||||||
is essential to give readers an overview and to help them understand its complexities quickly | ![]() | ||||||||||||||||||||||
is a kind of programming language construct | ![]() | ||||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
can be written before writing the code | ![]() | ||||||||||||||||||||||
should be between about 20% and 35% of the total length of the code | ![]() | ||||||||||||||||||||||
should be written to describe each non-obvious variable | ![]() | ||||||||||||||||||||||
should be written to describe loops and conditional statements inside complex algorithms | ![]() | ||||||||||||||||||||||
should be written at the head of each non-obvious method describing its function and usage | ![]() | ||||||||||||||||||||||
should be written at the top of each class | ![]() | ||||||||||||||||||||||
should describe the purpose of the class, how it should be used, its authors and its history of modification | ![]() | ||||||||||||||||||||||
should not be about obvious things since they add clutter | ![]() | ||||||||||||||||||||||
commenting | affects maintainability | ![]() | |||||||||||||||||||||
affects indirectly reliability | ![]() | ||||||||||||||||||||||
is a kind of internal software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
is measured as as the fraction of total lines in the source code that are comments | ![]() | ||||||||||||||||||||||
commercial off-the-shelf software | has definition A term for generic software, often abbreviated as COTS | ![]() | |||||||||||||||||||||
is a synonym of generic software | ![]() | ||||||||||||||||||||||
is abbreviated as COTS | ![]() | ||||||||||||||||||||||
common coupling | has definition A form of coupling in which components share data using a global variable and thus become dependent on each other | ![]() | |||||||||||||||||||||
is a kind of coupling | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
shares many of the disadvantages of content coupling | ![]() | ||||||||||||||||||||||
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 values | ![]() | ||||||||||||||||||||||
should be minimized | ![]() | ||||||||||||||||||||||
Common Object Request Broker Architecture | has definition A well-known standard broker architecture | ![]() | |||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
is abbreviated as CORBA | ![]() | ||||||||||||||||||||||
is an instance of broker | ![]() | ||||||||||||||||||||||
communication link | has definition In a collaboration diagram, a line drawn between each pair of objects involved in the sending of a message | ![]() | |||||||||||||||||||||
is a kind of symbol in collaboration diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
can exist between two objects whenever it is possible for one object to send a message to the other one, including the following situations:
| ![]() | ||||||||||||||||||||||
does not necessarily correspond to instances of associations (i.e. links) in a class diagram | ![]() | ||||||||||||||||||||||
communication system | contains layers in order from bottom to top
| ![]() | |||||||||||||||||||||
has clients a program that allows users to send a message or maintain a conversation with users on another computer | ![]() | ||||||||||||||||||||||
has server a program that routes messages and can have features such as 'forwarding' that people are familiar with from the telephone network | ![]() | ||||||||||||||||||||||
is a kind of client-server system | ![]() | ||||||||||||||||||||||
is a kind of multi-layer system | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
communicational cohesion | has definition A form of cohesion in which procedures that access the same data are kept together | ![]() | |||||||||||||||||||||
is more important than sequential cohesion | ![]() | ||||||||||||||||||||||
is a kind of cohesion | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is helped by the object oriented paradigm | ![]() | ||||||||||||||||||||||
Communications of the ACM | has web site www.acm.org ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of magazine | ![]() | ||||||||||||||||||||||
is published by the Association for Computing Machinery | ![]() | ||||||||||||||||||||||
Community for Software Engineers | has URL www.software-engineer.org ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of software engineering web site | ![]() | ||||||||||||||||||||||
compilation | has definition The process of translating source code into code that is executable by a computer | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
compiler | has purpose to translate source code into code that is executable by a computer | ![]() | |||||||||||||||||||||
is a kind of program | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
performs compilation | ![]() | ||||||||||||||||||||||
complex condition | is a kind of condition | ![]() | |||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
should be avoided because it is difficult to read | ![]() | ||||||||||||||||||||||
should be divided into several separate conditions on separate lines | ![]() | ||||||||||||||||||||||
complex Java condition | has example if(a==5 &&(b>40 \ c) && (d > a+2 \ e==5)) ... | ![]() | |||||||||||||||||||||
is a kind of complex condition | ![]() | ||||||||||||||||||||||
is a kind of Java condition | ![]() | ||||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
complexity of code | affects maintainability | ![]() | |||||||||||||||||||||
affects reliability | ![]() | ||||||||||||||||||||||
is a kind of internal software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
is measured in terms of the nesting depth, the number of branches and the use of certain complex programming constructs | ![]() | ||||||||||||||||||||||
component | has 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 functionality | ![]() | |||||||||||||||||||||
is reusable if it can be used in several different systems with little or no modification | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
component diagram | has definition A UML diagram showing components and their relationships | ![]() | |||||||||||||||||||||
is a kind of UML diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
shows how the various components of systems are arranged logically and physically | ![]() | ||||||||||||||||||||||
component | may perform a special-purpose function such as the user interface for a particular system | ![]() | |||||||||||||||||||||
component symbol | is a kind of symbol in UML diagram | ![]() | |||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
is drawn a box with two smaller boxes protruding from its left side | ![]() | ||||||||||||||||||||||
composite | has definition A specialization of the general hierarchy pattern, that uses an aggregation instead of an ordinary association | ![]() | |||||||||||||||||||||
is a subtopic of 6.3 - The General Hierarchy Pattern | ![]() | ||||||||||||||||||||||
is an instance of design pattern | ![]() | ||||||||||||||||||||||
composition | has definition A strong kind of aggregation in which if the aggregate is destroyed, then the parts are destroyed as well | ![]() | |||||||||||||||||||||
has example The rooms of a building cannot exist without the building | ![]() | ||||||||||||||||||||||
is a kind of aggregation | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a solid (filled-in) diamond in a UML diagram | ![]() | ||||||||||||||||||||||
computation | is a kind of event | ![]() | |||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
can be represented by a state diagram | ![]() | ||||||||||||||||||||||
computer engineering | developed in the 1980's | ![]() | |||||||||||||||||||||
is a kind of engineering | ![]() | ||||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
is concerned with the design of computer systems that involve both hardware and software components | ![]() | ||||||||||||||||||||||
computer science | is a kind of discipline | ![]() | |||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
computing numerical results | is a kind of responsibility | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
concrete class | has definition A class that can have instances | ![]() | |||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of 2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarations | ![]() | ||||||||||||||||||||||
concurrency | is a kind of quality | ![]() | |||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
concurrent engineering model | has definition A process model in which each team works on its own component, typically following a spiral or evolutionary approach | ![]() | |||||||||||||||||||||
is a kind of process model | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
uses the divide and conquer principle: Each team works on its own component, typically following a spiral or evolutionary approach | ![]() | ||||||||||||||||||||||
condition | is a kind of programming language construct | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
configuration management specialist | is responsible for ensuring that changes are made, no new problems are introduced and that documentation for each change is properly updated | ![]() | |||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 1.4 - Stakeholders in Software Engineering | ![]() | ||||||||||||||||||||||
is part of software development team | ![]() | ||||||||||||||||||||||
configuration management system | is a kind of tool | ![]() | |||||||||||||||||||||
is a subtopic of 4.9 - Managing Changing Requirements | ![]() | ||||||||||||||||||||||
keeps track of versions of requirements documents | ![]() | ||||||||||||||||||||||
connection | has definition The existence of a communications channel between two computers, typically a client and server | ![]() | |||||||||||||||||||||
has part socket in the client | ![]() | ||||||||||||||||||||||
has part socket in the server | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
const | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
constant | has part value | ![]() | |||||||||||||||||||||
has purpose to hold a value that does not change | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
constraint | expresses a logical statement that should evaluate to true | ![]() | |||||||||||||||||||||
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 computer | ![]() | ||||||||||||||||||||||
is a kind of criterion | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
is written in braces (curly brackets) in a UML diagram | ![]() | ||||||||||||||||||||||
can be written in in any language supported by a given tool | ![]() | ||||||||||||||||||||||
cannot compute a non-boolean result | ![]() | ||||||||||||||||||||||
cannot have any side-effects | ![]() | ||||||||||||||||||||||
cannot modify any data | ![]() | ||||||||||||||||||||||
construction | has 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 weak | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
is not like construction of buildings | ![]() | ||||||||||||||||||||||
Constructive Cost Model | computes effort, in person months, from an estimate of size, in lines of code | ![]() | |||||||||||||||||||||
has definition An algorithmic cost estimation method that computes effort, in person-months, from an estimate of size, measured in lines of code | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
is abbreviated as COCOMO | ![]() | ||||||||||||||||||||||
is an instance of algorithmic cost estimation model | ![]() | ||||||||||||||||||||||
constructor | has definition A procedure that is called whenever a new object is created | ![]() | |||||||||||||||||||||
has purpose to initialize the instance variables of a newly created object and perform any other needed initialization | ![]() | ||||||||||||||||||||||
is a kind of procedure | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is part of a class | ![]() | ||||||||||||||||||||||
content coupling | has definition An undesirable form of coupling in which a component surreptitiously modifies internal data of another component | ![]() | |||||||||||||||||||||
is a kind of coupling | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
content coupling in Java | is a kind of content coupling | ![]() | |||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
can be avoided by
| ![]() | ||||||||||||||||||||||
can occur when you directly modify an instance variable of an instance variable | ![]() | ||||||||||||||||||||||
can occur whenever you modify a public instance variable in a way that designers did not intend | ![]() | ||||||||||||||||||||||
content coupling | should be avoided since any modification of data should be easy to find and easy to understand | ![]() | |||||||||||||||||||||
context | has definition The general situation in which a design pattern applies | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 6.1 - Introduction to Patterns | ![]() | ||||||||||||||||||||||
is part of design pattern | ![]() | ||||||||||||||||||||||
continue | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
contracting-out | has definition Paying to have software (typically custom software) developed by some other organization | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
control | is a synonym of user interface component | ![]() | |||||||||||||||||||||
is a synonym of widget | ![]() | ||||||||||||||||||||||
control coupling | has definition A form of coupling in which one component affects the sequence of execution in another | ![]() | |||||||||||||||||||||
has example public routineX(String command) | ![]() | ||||||||||||||||||||||
is a kind of coupling | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is named after common blocks in the Fortran language which are used to hold global variables | ![]() | ||||||||||||||||||||||
occurs when one procedure calls another using a 'flag' or 'command' that explicitly controls what the second procedure does | ![]() | ||||||||||||||||||||||
can be reduced by | ![]() | ||||||||||||||||||||||
controller | contains the objects that control and handle the user's interaction with the view and the model | ![]() | |||||||||||||||||||||
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 model | ![]() | ||||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
copying, converting, transforming, transmitting or outputting | is a kind of responsibility | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is often omitted from a model because the presence of such responsibilities can largely be inferred from the class diagram | ![]() | ||||||||||||||||||||||
CORBA | is a subtopic of 9.5 - Architectural Patterns | ![]() | |||||||||||||||||||||
is an abbreviation for Common Object Request Broker Architecture | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
CORBA web site | has URL www.corba.com ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 9.9 - Architecting and designing software - References | ![]() | ||||||||||||||||||||||
is an instance of web site about software architecture | ![]() | ||||||||||||||||||||||
corrective maintenance | has definition A type of maintenance performed to correct a defect in software | ![]() | |||||||||||||||||||||
is a kind of maintenance | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
corrective project | involves fixing defects | ![]() | |||||||||||||||||||||
is a kind of evolutionary project | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
cost | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 9.3 - Techniques for Making Good Design Decisions | ![]() | ||||||||||||||||||||||
cost and delivery date | is a kind of non-functional requirement | ![]() | |||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
is often not included in the requirements document, but left to a separate project plan document | ![]() | ||||||||||||||||||||||
cost estimate | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
can be based on
| ![]() | ||||||||||||||||||||||
should be reported regularly to other members of the team, to management and to customers | ![]() | ||||||||||||||||||||||
cost estimation | has definition The process of estimating the effort and elapsed time of an activity or project | ![]() | |||||||||||||||||||||
is difficult | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
uses development effort | ![]() | ||||||||||||||||||||||
uses elapsed time | ![]() | ||||||||||||||||||||||
cost estimation principle | is a kind of principle | ![]() | |||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
cost estimation principle 1 | helps to make an estimate more accurate because | ![]() | |||||||||||||||||||||
is a kind of cost estimation principle | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
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 project | ![]() | ||||||||||||||||||||||
states divide and conquer | ![]() | ||||||||||||||||||||||
cost estimation principle 2 | is a kind of cost estimation principle | ![]() | |||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
states include all activities when making estimates | ![]() | ||||||||||||||||||||||
cost estimation principle 3 | has strategies | ![]() | |||||||||||||||||||||
is a kind of cost estimation principle | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
states base your estimates on past experience combined with what you can observe of the current project | ![]() | ||||||||||||||||||||||
cost estimation principle 4 | is a kind of cost estimation principle | ![]() | |||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
states be sure to account for differences when extrapolating from other projects | ![]() | ||||||||||||||||||||||
cost estimation principle 5 | is a kind of cost estimation principle | ![]() | |||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
states anticipate the worst case and plan for contingencies | ![]() | ||||||||||||||||||||||
cost estimation principle 6 | is a kind of cost estimation principle | ![]() | |||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
states combine multiple independent estimates | ![]() | ||||||||||||||||||||||
cost estimation principle 7 | is a kind of cost estimation principle | ![]() | |||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
states revise and refine estimates as work progresses | ![]() | ||||||||||||||||||||||
cost estimation | should be a continuous activity | ![]() | |||||||||||||||||||||
cost estimation technique | is a kind of process | ![]() | |||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
is used by cost estimator | ![]() | ||||||||||||||||||||||
cost estimator | is a kind of software developer | ![]() | |||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
makes inaccurate estimate if he or she tries to estimate the entire cost of a project as a single number | ![]() | ||||||||||||||||||||||
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 project | ![]() | ||||||||||||||||||||||
can use cost estimation technique | ![]() | ||||||||||||||||||||||
may underestimate the total amount of work required by not understanding the amount of work involved in certain activities or omitting them entirely | ![]() | ||||||||||||||||||||||
must include extra time into a time estimate to account for typical delays | ![]() | ||||||||||||||||||||||
should avoid making only a best-case estimate | ![]() | ||||||||||||||||||||||
should compare the results of several different cost estimation techniques | ![]() | ||||||||||||||||||||||
should consider differences when making an estimate for a new project:
| ![]() | ||||||||||||||||||||||
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 project | ![]() | ||||||||||||||||||||||
should revise estimates because
| ![]() | ||||||||||||||||||||||
should use cost estimation principles | ![]() | ||||||||||||||||||||||
cost of a software project | is a function of development effort | ![]() | |||||||||||||||||||||
is a kind of cost | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
cost-benefit analysis | has 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 costs | ![]() | |||||||||||||||||||||
has procedure add up estimates of the costs and compare this to the benefits | ![]() | ||||||||||||||||||||||
is a kind of analysis | ![]() | ||||||||||||||||||||||
is a subtopic of 9.3 - Techniques for Making Good Design Decisions | ![]() | ||||||||||||||||||||||
is taught in management courses | ![]() | ||||||||||||||||||||||
COTS | is a subtopic of 1.1 - The Nature of Software | ![]() | |||||||||||||||||||||
is an abbreviation for commercial off-the-shelf software | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
coupling | has definition A measure of the extent to which interdependencies exist between software modules | ![]() | |||||||||||||||||||||
implies that if you want to reuse one component, you will also have to import all the ones with which it is coupled | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
coverage | has definition A measure of the percentage of paths, statements or branches taken by a set of tests | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
crash | is a kind of failure | ![]() | |||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
creating and initializing new instances | is a kind of responsibility | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is often given to some other class | ![]() | ||||||||||||||||||||||
is often omitted from a model because the presence of such responsibilities can largely be inferred from the class diagram | ![]() | ||||||||||||||||||||||
credit card number format | has localization issues | ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
criterion | is a kind of subject | ![]() | |||||||||||||||||||||
critical path | has 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 project | ![]() | |||||||||||||||||||||
indicates the minimum time in which it is possible to complete the project | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 11.5 - Project Scheduling and Tracking | ![]() | ||||||||||||||||||||||
is computed by searching for the path through the PERT chart that has the greatest cumulative elapsed time | ![]() | ||||||||||||||||||||||
critical race | has black-box testing strategy
| ![]() | |||||||||||||||||||||
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 events | ![]() | ||||||||||||||||||||||
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 conditions | ![]() | ||||||||||||||||||||||
is a kind of timing and co-ordination defect | ![]() | ||||||||||||||||||||||
is a subtopic of 10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races | ![]() | ||||||||||||||||||||||
is a synonym of race condition | ![]() | ||||||||||||||||||||||
can be detected by glass-box testing since you can actually study the progress and states of the various threads | ![]() | ||||||||||||||||||||||
can be detected by inspection | ![]() | ||||||||||||||||||||||
currency | has localization issues
| ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
custom software | has definition Software developed to meet the needs of a particular customer | ![]() | |||||||||||||||||||||
has definition Software that is developed to meet the specific needs of a particular customer (in contrast to generic software) | ![]() | ||||||||||||||||||||||
has example web sites, air-traffic control systems and software for managing the finances of large organizations | ![]() | ||||||||||||||||||||||
has global CPU usage low | ![]() | ||||||||||||||||||||||
has global development effort high | ![]() | ||||||||||||||||||||||
has global number of copies low | ![]() | ||||||||||||||||||||||
is what most software developers work on | ![]() | ||||||||||||||||||||||
is a kind of software | ![]() | ||||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
is developed for a particular customer | ![]() | ||||||||||||||||||||||
is often developed in-house | ![]() | ||||||||||||||||||||||
is typically used by only a few people | ![]() | ||||||||||||||||||||||
can be made generic but this can be a complex process if the software was not designed in a flexible way | ![]() | ||||||||||||||||||||||
may be contracted-out to a consulting company | ![]() | ||||||||||||||||||||||
customer | demands new and updated software | ![]() | |||||||||||||||||||||
expects software to be of high quality and to be produced rapidly | ![]() | ||||||||||||||||||||||
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 software | ![]() | ||||||||||||||||||||||
has goal either to increase profits or to run their business more effectively | ![]() | ||||||||||||||||||||||
is a kind of person | ![]() | ||||||||||||||||||||||
is a kind of stakeholder | ![]() | ||||||||||||||||||||||
is a subtopic of 1.4 - Stakeholders in Software Engineering | ![]() | ||||||||||||||||||||||
is a synonym of client | ![]() | ||||||||||||||||||||||
is concerned with efficiency | ![]() | ||||||||||||||||||||||
is concerned with reliability | ![]() | ||||||||||||||||||||||
likes software that helps their organization save or make money, typically by making the users and the organization as a whole more productive | ![]() | ||||||||||||||||||||||
makes decisions about ordering and paying for the software | ![]() | ||||||||||||||||||||||
often want to understand the architecture so they can be confident the software is being designed well and can monitor development progress | ![]() | ||||||||||||||||||||||
wants software that solves problems at an acceptable cost in terms of money paid and resources used | ![]() | ||||||||||||||||||||||
may be a user of software | ![]() | ||||||||||||||||||||||
should be involved in requirements analysis, user interface design and deployment, and also may play a role in design, quality assurance and project management | ![]() | ||||||||||||||||||||||
should be made to feel involved in the software engineering process resulting in fewer mistakes being made and greater acceptance of the finished product | ![]() | ||||||||||||||||||||||
data abstraction | groups the pieces of data that describe some entity, so that programmers can manipulate that data as a unit | ![]() | |||||||||||||||||||||
helps a programmer to cope with the complexity of data | ![]() | ||||||||||||||||||||||
hides the details of data | ![]() | ||||||||||||||||||||||
is a kind of abstraction | ![]() | ||||||||||||||||||||||
is a subtopic of 2.1 - What is Object Orientation? | ![]() | ||||||||||||||||||||||
data coupling | has definition A form of coupling in which one component passes simple data to another as an argument | ![]() | |||||||||||||||||||||
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 meaning | ![]() | ||||||||||||||||||||||
is always present to some extent | ![]() | ||||||||||||||||||||||
is a kind of coupling | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
can be reduced by
| ![]() | ||||||||||||||||||||||
data item | is a kind of programming language construct | ![]() | |||||||||||||||||||||
is a subtopic of 2.2 - Classes and Objects | ![]() | ||||||||||||||||||||||
data member | is a synonym of instance variable | ![]() | |||||||||||||||||||||
data processing software | gathers data together in batches to be processed at a later time | ![]() | |||||||||||||||||||||
has concerns
| ![]() | ||||||||||||||||||||||
has definition Software used for running businesses, managing data such as payroll, purchases, sales, product inventory etc. | ![]() | ||||||||||||||||||||||
has design issue how to organize the data and provide useful information to the users so they can perform their work effectively | ![]() | ||||||||||||||||||||||
is a kind of software | ![]() | ||||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
is used to run businesses | ![]() | ||||||||||||||||||||||
performs functions recording sales, managing accounts, printing bills etc. | ![]() | ||||||||||||||||||||||
data type | is a kind of data abstraction | ![]() | |||||||||||||||||||||
is a kind of programming language construct | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
database | is a kind of component | ![]() | |||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
database design | has 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 time | ![]() | |||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
database specialist | is a kind of software developer | ![]() | |||||||||||||||||||||
is a subtopic of 1.4 - Stakeholders in Software Engineering | ![]() | ||||||||||||||||||||||
is part of software development team | ![]() | ||||||||||||||||||||||
database system | has clients any application program that wants to query a database | ![]() | |||||||||||||||||||||
has server A database management system that responds to requests to query or update the database | ![]() | ||||||||||||||||||||||
is a kind of client-server system | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
DataInputStream | allow programmer to exchange more sophisticated types of data than simple bytes without having to worry about how to translate them into a byte stream | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of filter | ![]() | ||||||||||||||||||||||
can contain Java primitive types such as int and double | ![]() | ||||||||||||||||||||||
DataOutputStream | allow a programmer to exchange more sophisticated types of data than simple bytes without having to worry about how to translate them into a byte stream | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of filter | ![]() | ||||||||||||||||||||||
can contain Java primitive types such as int and double | ![]() | ||||||||||||||||||||||
date format | has localization issues | ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
Dave Farthing's software project management page | has URL www.comp.glam.ac.uk/pages/staff/dwfarthi/projman.htm ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of web site about project management | ![]() | ||||||||||||||||||||||
deadlock | has definition A failure in which two or more threads are stopped, waiting for each other to do something | ![]() | |||||||||||||||||||||
has example
| ![]() | ||||||||||||||||||||||
has example in real life gridlock | ![]() | ||||||||||||||||||||||
is a kind of deadlock or livelock | ![]() | ||||||||||||||||||||||
is a subtopic of 10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races | ![]() | ||||||||||||||||||||||
can appear as a hung system where the system is not consuming CPU time | ![]() | ||||||||||||||||||||||
may not hang a system | ![]() | ||||||||||||||||||||||
deadlock or livelock | has black-box testing strategy
| ![]() | |||||||||||||||||||||
has testing strategy inspecting to detect such defects, rather than testing alone | ![]() | ||||||||||||||||||||||
is a kind of failure | ![]() | ||||||||||||||||||||||
is a subtopic of 10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races | ![]() | ||||||||||||||||||||||
can be caused by over-use of locking | ![]() | ||||||||||||||||||||||
can be detected by glass-box testing since you can actually study the progress and states of the various threads | ![]() | ||||||||||||||||||||||
may occur as a result of unusual combinations of conditions that are hard to anticipate or reproduce | ![]() | ||||||||||||||||||||||
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 defects | ![]() | ||||||||||||||||||||||
deaf user | is a kind of user with a disability | ![]() | |||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
needs a program that does not depend on sound output | ![]() | ||||||||||||||||||||||
decision-making statement | is a kind of statement | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
declaration | is a kind of programming language construct | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
decreasing coupling | is a subtopic of 9.4 - Software Architecture | ![]() | |||||||||||||||||||||
is an instance of design principle | ![]() | ||||||||||||||||||||||
means decreasing the number of dependencies between packages as much as possible | ![]() | ||||||||||||||||||||||
default | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
default multiplicity | is one in a UML diagram | ![]() | |||||||||||||||||||||
is a kind of multiplicity in a UML diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
does not require a symbol to be drawn in a UML diagram | ![]() | ||||||||||||||||||||||
defect | has 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 failures | ![]() | |||||||||||||||||||||
has example the absence of code to handle an exception | ![]() | ||||||||||||||||||||||
is a kind of problem | ![]() | ||||||||||||||||||||||
is a subtopic of 10.1 - Basic Definitions | ![]() | ||||||||||||||||||||||
is a synonym of bug | ![]() | ||||||||||||||||||||||
defect in a numerical algorithm | is a kind of defect | ![]() | |||||||||||||||||||||
is a subtopic of 10.4 - Defects in Numerical Algorithms | ![]() | ||||||||||||||||||||||
defect in an ordinary algorithm | is a kind of defect | ![]() | |||||||||||||||||||||
is a subtopic of 10.4 - Defects in Numerical Algorithms | ![]() | ||||||||||||||||||||||
defect in handling peak loads or missing resources | has definition A defect that occurs when a computer cannot gracefully handle peak loads or missing resources | ![]() | |||||||||||||||||||||
has testing strategy
| ![]() | ||||||||||||||||||||||
is a kind of defect in handling stress and unusual situations | ![]() | ||||||||||||||||||||||
is a subtopic of 10.6 - Defects in Handling Stress and Unusual Situations | ![]() | ||||||||||||||||||||||
occurs when | ![]() | ||||||||||||||||||||||
defect in handling stress and unusual situations | is a kind of defect | ![]() | |||||||||||||||||||||
is a subtopic of 10.6 - Defects in Handling Stress and Unusual Situations | ![]() | ||||||||||||||||||||||
is only encountered when a system is being heavily used, or forced to its limits in some other way | ![]() | ||||||||||||||||||||||
represents a lack of robustness | ![]() | ||||||||||||||||||||||
can be detected by | ![]() | ||||||||||||||||||||||
defect in the process of recovering from a crash | has definition A defect that occurs when a system does not deal with hardware failures, crashes of related systems or the power being turned off | ![]() | |||||||||||||||||||||
has testing strategy kill either your program or the programs with which it communicates, at various times during execution | ![]() | ||||||||||||||||||||||
is a kind of inappropriate management of resources | ![]() | ||||||||||||||||||||||
is a subtopic of 10.6 - Defects in Handling Stress and Unusual Situations | ![]() | ||||||||||||||||||||||
defensive design | has definition Design with awareness that other components cannot be trusted | ![]() | |||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
defining the problem | has definition A part of requirements and specification that involves narrowing down the scope of the system by determining the precise problem that needs solving | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
is part of requirements and specification | ![]() | ||||||||||||||||||||||
delegation | has antipatterns
| ![]() | |||||||||||||||||||||
has context
| ![]() | ||||||||||||||||||||||
has definition A pattern in which one procedure does nothing more than call another in a neighbouring class; this reduces total coupling in the system | ![]() | ||||||||||||||||||||||
has forces
| ![]() | ||||||||||||||||||||||
has problem How can you most effectively make use of a method that already exists in the other class? | ![]() | ||||||||||||||||||||||
has related patterns Adapter and Proxy patterns | ![]() | ||||||||||||||||||||||
has solution
| ![]() | ||||||||||||||||||||||
is a subtopic of 6.7 - The Delegation Pattern | ![]() | ||||||||||||||||||||||
is an instance of design pattern | ![]() | ||||||||||||||||||||||
Delphi technique | has definition An approach to cost estimation in which several individuals initially make cost estimates in private, and then share their estimates to discover the discrepancies | ![]() | |||||||||||||||||||||
has procedure | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
is an instance of cost estimation technique | ![]() | ||||||||||||||||||||||
departmental manager | is a kind of person | ![]() | |||||||||||||||||||||
is a subtopic of 11.1 - What is Project Management? | ![]() | ||||||||||||||||||||||
performs activities such as hiring, building morale, and issuing the final directions | ![]() | ||||||||||||||||||||||
deployment | has 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 system | ![]() | |||||||||||||||||||||
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 system | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
deployment diagram | contains links between nodes that show how communication takes place | ![]() | |||||||||||||||||||||
contains nodes which represent computational units such as a computer, a processing card, a sensor or a device | ![]() | ||||||||||||||||||||||
has definition A UML diagram showing hardware nodes, how they are interconnected, and what components will exist on them at run time | ![]() | ||||||||||||||||||||||
is a kind of UML diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
shows where various instances of components reside at run time | ![]() | ||||||||||||||||||||||
deprecate | has definition To declare that a component should not be used in subsequent designs, but remains available to support existing designs that incorporate it | ![]() | |||||||||||||||||||||
is a kind of action | ![]() | ||||||||||||||||||||||
is a subtopic of 3.2 - Incorporating Reusability and Reuse Into Software Engineering | ![]() | ||||||||||||||||||||||
derived class | is the name for subclass in C++ | ![]() | |||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of 2.5 - Organizing Classes Into Inheritance Hierarchies | ![]() | ||||||||||||||||||||||
is a synonym of subclass | ![]() | ||||||||||||||||||||||
design | determines how components will be implemented in a system | ![]() | |||||||||||||||||||||
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 quality | ![]() | ||||||||||||||||||||||
has goals
| ![]() | ||||||||||||||||||||||
has part detailed design | ![]() | ||||||||||||||||||||||
has part modelling | ![]() | ||||||||||||||||||||||
has part programming | ![]() | ||||||||||||||||||||||
has part software architecture^2 | ![]() | ||||||||||||||||||||||
has part systems engineering | ![]() | ||||||||||||||||||||||
has part user interface design | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
requires considerable experience | ![]() | ||||||||||||||||||||||
see also design^2 | ![]() | ||||||||||||||||||||||
Design and Use of Software Architectures | has author Jan Bosch | ![]() | |||||||||||||||||||||
has ISBN number 0-201-67494-7 | ![]() | ||||||||||||||||||||||
is a subtopic of 9.9 - Architecting and designing software - References | ![]() | ||||||||||||||||||||||
is an instance of software architecture book | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
design by contract | has definition An approach to design in which each method has a contract with its callers regarding preconditions, postconditions and invariants | ![]() | |||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
Design by Contract: The Lessons of Ariane | has author J-M. Jézéquel and B. Meyer | ![]() | |||||||||||||||||||||
has date January 1997 | ![]() | ||||||||||||||||||||||
has publication IEEE Computer, Vol. 30, No. 2 | ![]() | ||||||||||||||||||||||
has URL www.eiffel.com/doc/manuals/technology/contract/ariane/page.html ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of article about software failures | ![]() | ||||||||||||||||||||||
design decision | causes other new issues to be raised | ![]() | |||||||||||||||||||||
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-off | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
is made by the designer using all the knowledge at his or her disposal, including: | ![]() | ||||||||||||||||||||||
can be made by using these steps:
| ![]() | ||||||||||||||||||||||
design document | allows a group of people to review the design and therefore to improve it | ![]() | |||||||||||||||||||||
contains every design decision along with the reasoning that went into making the decision | ![]() | ||||||||||||||||||||||
describes the priorities used to guide the design process | ![]() | ||||||||||||||||||||||
describes what system or part of the system this design document describes | ![]() | ||||||||||||||||||||||
discusses the important issues that had to be resolved, the possible alternatives that were considered, the final decision and the rationale for the decision | ![]() | ||||||||||||||||||||||
ensures traceability by making reference to the requirements that are being implemented by this design | ![]() | ||||||||||||||||||||||
forces a designer to be explicit and to consider the important issues before starting implementation | ![]() | ||||||||||||||||||||||
has definition Documentation produced as a result of the design process | ![]() | ||||||||||||||||||||||
has purpose
| ![]() | ||||||||||||||||||||||
has suggested structure | ![]() | ||||||||||||||||||||||
includes a high-level description (or diagram) of the design that allows the reader to quickly get a general feeling for it | ![]() | ||||||||||||||||||||||
includes the information its readers need to learn | ![]() | ||||||||||||||||||||||
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 design | ![]() | ||||||||||||||||||||||
is a kind of document | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
makes reference to the requirements that are being implemented by this design | ![]() | ||||||||||||||||||||||
see also design | ![]() | ||||||||||||||||||||||
should be written for | ![]() | ||||||||||||||||||||||
should not include
| ![]() | ||||||||||||||||||||||
design issue | has definition A sub-problem of an overall design problem | ![]() | |||||||||||||||||||||
is a kind of problem | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
is resolved when the designer makes a design decision | ![]() | ||||||||||||||||||||||
may not have a single best alternative - several different alternatives may have opposite advantages and disadvantages | ![]() | ||||||||||||||||||||||
usually has several alternative solutions, also known as design options | ![]() | ||||||||||||||||||||||
design option | has definition An alternative solution to a design issue | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
design pattern | has antipatterns zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection | ![]() | |||||||||||||||||||||
has context a context | ![]() | ||||||||||||||||||||||
has definition A pattern useful for the design of software | ![]() | ||||||||||||||||||||||
has forces one or more forces | ![]() | ||||||||||||||||||||||
has name | ![]() | ||||||||||||||||||||||
has problem a sentence or two explaining the main difficulty being tackled | ![]() | ||||||||||||||||||||||
has references one or more references which indicate who developed or inspired a pattern | ![]() | ||||||||||||||||||||||
has related patterns zero or more related design patterns | ![]() | ||||||||||||||||||||||
is a kind of pattern | ![]() | ||||||||||||||||||||||
is a subtopic of 6.1 - Introduction to Patterns | ![]() | ||||||||||||||||||||||
design pattern developer | is a kind of software developer | ![]() | |||||||||||||||||||||
is a subtopic of 6.15 - Using Design Patterns - References | ![]() | ||||||||||||||||||||||
should not write patterns for others to use until he or she has considerable experience both in software design and in the use of patterns | ![]() | ||||||||||||||||||||||
should refine patterns iteratively and have then peer reviewed at each iteration | ![]() | ||||||||||||||||||||||
design pattern | should be illustrated using a simple diagram | ![]() | |||||||||||||||||||||
should be written using a narrative writing style | ![]() | ||||||||||||||||||||||
Design Patterns: Elements of Reusable Object-Oriented Software | has author E. Gamma, R. Helm, R. Johnson, and J. Vlissides | ![]() | |||||||||||||||||||||
has ISBN number 0-201-63361-2 | ![]() | ||||||||||||||||||||||
is a subtopic of 6.15 - Using Design Patterns - References | ![]() | ||||||||||||||||||||||
is an instance of book about design patterns | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1994 | ![]() | ||||||||||||||||||||||
design principle | is a kind of principle | ![]() | |||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
design space | has definition The space of possible design options | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
design specification | is a synonym of requirements specification | ![]() | |||||||||||||||||||||
designer | is a kind of software developer | ![]() | |||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
makes design decision | ![]() | ||||||||||||||||||||||
can create skeletons for the files that will contain the code | ![]() | ||||||||||||||||||||||
can learn from studying patterns | ![]() | ||||||||||||||||||||||
can use cost-benefit analysis to choose among alternatives | ![]() | ||||||||||||||||||||||
may also be a programmer | ![]() | ||||||||||||||||||||||
must find ways to reduce costs and increase benefits | ![]() | ||||||||||||||||||||||
should not design large systems until she has experienced a wide variety of software development projects | ![]() | ||||||||||||||||||||||
should study designs of other systems, including designs that have been found to be bad | ![]() | ||||||||||||||||||||||
designing for flexibility | involves actively anticipating changes that a design may have to undergo in the future and preparing for them | ![]() | |||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is an instance of design principle | ![]() | ||||||||||||||||||||||
can be accomplished by
| ![]() | ||||||||||||||||||||||
designing for portability | has goal the ability to have the software run on as many platforms as possible | ![]() | |||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is an instance of design principle | ![]() | ||||||||||||||||||||||
can be accomplished by avoiding the use of facilities that are specific to one particular environment | ![]() | ||||||||||||||||||||||
designing for testability | is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | |||||||||||||||||||||
is an instance of design principle | ![]() | ||||||||||||||||||||||
can be accomplished by ensuring that all the functionality of the code can by driven by an external program, bypassing a graphical user interface | ![]() | ||||||||||||||||||||||
Designing Maintainable Software | has author Dennis D. S | ![]() | |||||||||||||||||||||
has ISBN number 0-387-98783-5 | ![]() | ||||||||||||||||||||||
is a subtopic of 9.9 - Architecting and designing software - References | ![]() | ||||||||||||||||||||||
is an instance of software architecture book | ![]() | ||||||||||||||||||||||
was published by Springer Verlag | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
Designing Web Usability: The Practice of Simplicity | has author J. Nielsen | ![]() | |||||||||||||||||||||
has ISBN number 1-56205-810-X | ![]() | ||||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
is an instance of book about user interfaces and usability | ![]() | ||||||||||||||||||||||
was published by New Riders | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
destroying instances | is a kind of responsibility | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is often omitted from from a model because the presence of such responsibilities can largely be inferred from the class diagram | ![]() | ||||||||||||||||||||||
often requires collaboration with some other class | ![]() | ||||||||||||||||||||||
detailed design | has definition The design of the internals of individual subsystems | ![]() | |||||||||||||||||||||
involves deciding on data structures, classes, algorithms and procedures to be used | ![]() | ||||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
is part of design | ![]() | ||||||||||||||||||||||
deterioration | has definition The tendency of software to accumulate defects as time passes due to errors being made during maintenance | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
developer testing | has definition Preliminary testing performed by the people who do the design and programming | ![]() | |||||||||||||||||||||
is a kind of testing performed by software engineers | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
development | has definition A process used to develop software | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
is a synonym of software engineering process | ![]() | ||||||||||||||||||||||
development effort | is a synonym of effort | ![]() | |||||||||||||||||||||
development manager | is a synonym of project manager | ![]() | |||||||||||||||||||||
development process to be used | has example certain approaches to testing | ![]() | |||||||||||||||||||||
is a kind of non-functional requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
diagram | has advantages it conveys or summarizes complex concepts or mechanisms more easily than other techniques | ![]() | |||||||||||||||||||||
has problems | ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a kind of representation | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
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 it | ![]() | ||||||||||||||||||||||
dialog | has definition A specific window with which a user can interact, but which is not the main UI window | ![]() | |||||||||||||||||||||
is a kind of window | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is a synonym of dialog box | ![]() | ||||||||||||||||||||||
dialog box | is a synonym of dialog | ![]() | |||||||||||||||||||||
dialog^2 | has definition The back-and-forth interaction between user and computer | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
direction for reading text | has localization issues | ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
discipline | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 1.2 - What is Software Engineering? | ![]() | ||||||||||||||||||||||
discriminator | has definition A label on a generalization that describes the criteria used to specialize a superclass into two or more subclasses | ![]() | |||||||||||||||||||||
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. | ![]() | ||||||||||||||||||||||
is a kind of label | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
can be thought of as an attribute that will have a different value in each subclass | ![]() | ||||||||||||||||||||||
distributed architecture | facilitates 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 choice | ![]() | |||||||||||||||||||||
facilitates divide and conquer since dividing the system into processes is a very strong way to divide the system up | ![]() | ||||||||||||||||||||||
increases abstraction because separate distributed components are often good abstractions | ![]() | ||||||||||||||||||||||
increases reuse because it is often possible to find suitable frameworks on which to build good distributed systems | ![]() | ||||||||||||||||||||||
is a kind of software architecture | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
reduces coupling since there is usually only one communication channel between distributed components although you have to watch out for control coupling | ![]() | ||||||||||||||||||||||
distributed system | has definition A system in which computations are performed by separate programs that co-operate to perform the task of the system as a whole | ![]() | |||||||||||||||||||||
is vulnerable to privacy invasions of its users by gathering data about people as they use network-based programs or by actively intercepting communications | ![]() | ||||||||||||||||||||||
is a kind of system | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
is divided up into clients and servers | ![]() | ||||||||||||||||||||||
distributed system developer | is a kind of software developer | ![]() | |||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
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 information | ![]() | ||||||||||||||||||||||
should never develop harmful programs such as viruses or Trojan horses or hack into systems | ![]() | ||||||||||||||||||||||
divide and conquer | has benefits
| ![]() | |||||||||||||||||||||
has definition The principle of dividing something large into smaller units, so it can be dealt with more easily | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is an instance of design principle | ![]() | ||||||||||||||||||||||
DLL | is a subtopic of 9.1 - The Process of Design | ![]() | |||||||||||||||||||||
is an abbreviation for dynamic link library | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
DMOZ Open Directory on software testing | has URL dmoz.org/Computers/Programming/Software_Testing ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of web site about software testing | ![]() | ||||||||||||||||||||||
do | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
document | has definition Anything written that that describes software | ![]() | |||||||||||||||||||||
is a kind of representation | ![]() | ||||||||||||||||||||||
is a subtopic of 9.6 - Writing a Good Design Document | ![]() | ||||||||||||||||||||||
should be written for a particular audience | ![]() | ||||||||||||||||||||||
documentation | has purpose to document decisions and to communicate them to others | ![]() | |||||||||||||||||||||
includes requirements, designs, user documentation, instructions for testers and project plans | ![]() | ||||||||||||||||||||||
is a kind of representation | ![]() | ||||||||||||||||||||||
is a subtopic of 1.8 - The Eight Themes Emphasized in this Book | ![]() | ||||||||||||||||||||||
will not be read if it is excessively voluminous, poorly written or not made readily available | ![]() | ||||||||||||||||||||||
can be a source of rigidity in software development unless it is managed appropriately | ![]() | ||||||||||||||||||||||
can entrench poorly made decisions that are hard to change | ![]() | ||||||||||||||||||||||
can waste resources if it is never read | ![]() | ||||||||||||||||||||||
documentation defect | has 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 problem | ![]() | |||||||||||||||||||||
has testing strategy
| ![]() | ||||||||||||||||||||||
is a kind of defect | ![]() | ||||||||||||||||||||||
is a subtopic of 10.7 - Documentation Defects | ![]() | ||||||||||||||||||||||
documentation | must provide the information the readers will need, and must be organized in a way so that the readers can find what they need easily | ![]() | |||||||||||||||||||||
should adhere to standards for the company | ![]() | ||||||||||||||||||||||
should be as short and succinct as possible | ![]() | ||||||||||||||||||||||
should be written at all stages of development | ![]() | ||||||||||||||||||||||
should not be written prematurely just to meet specific deadlines because writing documents then becomes the objective, instead of solving problems | ![]() | ||||||||||||||||||||||
domain | has definition A named computer network | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
see also domain^2 | ![]() | ||||||||||||||||||||||
domain analysis | allows a software engineer to focus on the most important issues, to make fewer mistakes, and to follow accepted procedures and standards | ![]() | |||||||||||||||||||||
enables a software engineer to communicate with the stakeholders more effectively, so he will be able to establish requirements more quickly | ![]() | ||||||||||||||||||||||
has benefits
| ![]() | ||||||||||||||||||||||
has definition The process by which a software engineer learns enough background information so that he or she can understand the problem and make good decisions during requirements analysis and other stages of the software engineering process | ![]() | ||||||||||||||||||||||
has risk software developers may make invalid assumptions and hence create poor requirements or design | ![]() | ||||||||||||||||||||||
indicates opportunities for future development | ![]() | ||||||||||||||||||||||
is a kind of analysis | ![]() | ||||||||||||||||||||||
is a subtopic of 4.1 - Domain Analysis | ![]() | ||||||||||||||||||||||
is part of requirements and specification | ![]() | ||||||||||||||||||||||
is performed before requirements analysis | ![]() | ||||||||||||||||||||||
shows software engineer the subtleties of the domain, ensuring that the solutions adopted will more effectively solve the customer's problem | ![]() | ||||||||||||||||||||||
domain analysis document | has part
| ![]() | |||||||||||||||||||||
is a kind of document | ![]() | ||||||||||||||||||||||
is a subtopic of 4.1 - Domain Analysis | ![]() | ||||||||||||||||||||||
summarizes information found during domain analysis | ![]() | ||||||||||||||||||||||
can help educate other software engineers who join the team later | ![]() | ||||||||||||||||||||||
should contain a brief summary of the information you have found, along with references that will enable others to find that information | ![]() | ||||||||||||||||||||||
should not contain an excessive amount of detailed information | ![]() | ||||||||||||||||||||||
domain expert | has definition Somebody with expertise in a given domain, but who may or may not have expertise in software | ![]() | |||||||||||||||||||||
is a kind of person | ![]() | ||||||||||||||||||||||
is a subtopic of 4.1 - Domain Analysis | ![]() | ||||||||||||||||||||||
domain model | is a synonym of system domain model | ![]() | |||||||||||||||||||||
domain^2 | has definition A general field of business or technology in which users work, and which is learned by the software engineer during domain analysis | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 4.1 - Domain Analysis | ![]() | ||||||||||||||||||||||
see also domain | ![]() | ||||||||||||||||||||||
double | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java primitive data type | ![]() | ||||||||||||||||||||||
see also Double class | ![]() | ||||||||||||||||||||||
see also double^2 | ![]() | ||||||||||||||||||||||
stores a double-precision floating-point number | ![]() | ||||||||||||||||||||||
can use basic arithmetic operators +, -, *, / and % | ![]() | ||||||||||||||||||||||
Double class | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java wrapper class | ![]() | ||||||||||||||||||||||
see also double | ![]() | ||||||||||||||||||||||
double^2 | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
see also double | ![]() | ||||||||||||||||||||||
driver | calls lower layers of software | ![]() | |||||||||||||||||||||
has definition In the context of testing, a simple program that tests services of lower-level layers when performing bottom-up or sandwich testing | ![]() | ||||||||||||||||||||||
has disadvantage it is time-consuming to write | ![]() | ||||||||||||||||||||||
is a kind of program | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
duplication of code | has disadvantage when there are two or more occurrences of the same or similar code in the system, any changes made (e.g. to fix defects) will have to be made in all clones | ![]() | |||||||||||||||||||||
is a kind of practice | ![]() | ||||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
is a synonym of cloning | ![]() | ||||||||||||||||||||||
is not a kind of reuse | ![]() | ||||||||||||||||||||||
can be avoided by creating a common superclass if the duplication occurs in two separate classes | ![]() | ||||||||||||||||||||||
can be avoided by creating a separate method that has the common code, and calling it from the original location and any other needed locations | ![]() | ||||||||||||||||||||||
should be avoided because it increases the total volume of code and means that if you change the code in one place, then you might forget to change the code in the other places | ![]() | ||||||||||||||||||||||
dynamic binding | gives power to polymorphism | ![]() | |||||||||||||||||||||
has definition The process of binding a call to a particular method. This is performed dynamically at run-time due to the presence of polymorphism | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarations | ![]() | ||||||||||||||||||||||
is a synonym of late binding | ![]() | ||||||||||||||||||||||
is a synonym of virtual binding | ![]() | ||||||||||||||||||||||
is needed when the compiler determines that there more than one possible method that could be executed by a particular call | ![]() | ||||||||||||||||||||||
prevents programmers from having to write conditional statements to explicitly choose which code to run | ![]() | ||||||||||||||||||||||
dynamic link library | is a kind of component | ![]() | |||||||||||||||||||||
is a kind of software library | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
is abbreviated as DLL | ![]() | ||||||||||||||||||||||
dynamic modelling | has definition A type of modelling used to represent the internal states of the software and their changes | ![]() | |||||||||||||||||||||
involves representing such things as the states that the system can be in, the activities it can perform, and how its components interact | ![]() | ||||||||||||||||||||||
is difficult because in a large system there are a very large number of possible paths a system can take, and because it is hard to choose the classes to allocate each behaviour | ![]() | ||||||||||||||||||||||
is a kind of modelling | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
should be done iteratively | ![]() | ||||||||||||||||||||||
should be led by skilled developers | ![]() | ||||||||||||||||||||||
earned value | has definition The amount of work completed, measured according to the budgeted effort that the work was supposed to consume | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 11.5 - Project Scheduling and Tracking | ![]() | ||||||||||||||||||||||
is a synonym of budgeted cost of work performed | ![]() | ||||||||||||||||||||||
earned value chart | has curves
| ![]() | |||||||||||||||||||||
has definition A diagram used in project tracking, that allows you to compute the amount by which you are behind schedule and over budget; it shows elapsed time on one axis, and effort expended on the other axis | ![]() | ||||||||||||||||||||||
is useful for tracking | ![]() | ||||||||||||||||||||||
is a kind of diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 11.5 - Project Scheduling and Tracking | ![]() | ||||||||||||||||||||||
can be used to measure the extent to which a project is behind schedule by measuring the horizontal distance between the earned value curve and the budgeted cost of work scheduled | ![]() | ||||||||||||||||||||||
can be used to measure the extent to which you a project is over budget by measuring the vertical distance between the earned value curve and the actual cost curve | ![]() | ||||||||||||||||||||||
economies of scale | has definition Sub-linear growth in effort as size increases | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
do not happen in software engineering | ![]() | ||||||||||||||||||||||
EERD | is a subtopic of 5.7 - Detailed Example: A Class Diagram for Genealogy | ![]() | |||||||||||||||||||||
is an abbreviation for Extended Entity-Relationship diagram | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
Effective Requirements Practices | has author R. Young | ![]() | |||||||||||||||||||||
has ISBN number 0-201-70912-0 | ![]() | ||||||||||||||||||||||
is a subtopic of 4.13 - Developing Requirements - References | ![]() | ||||||||||||||||||||||
is an instance of book about requirements analysis | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 2001 | ![]() | ||||||||||||||||||||||
effective testing | is a kind of testing | ![]() | |||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
uses a strategy that uncovers as many defects as possible | ![]() | ||||||||||||||||||||||
effectiveness of a system at handling errors | has part effectiveness of error correction | ![]() | |||||||||||||||||||||
has part effectiveness of error detection | ![]() | ||||||||||||||||||||||
has part effectiveness of error prevention | ![]() | ||||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
effectiveness of error correction | is a kind of software quality | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is measured as the amount of time that elapses from the appearance of each error message, to the time when the user has corrected the error | ![]() | ||||||||||||||||||||||
effectiveness of error detection | is a kind of software quality | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is measured as the fraction of errors that users notice | ![]() | ||||||||||||||||||||||
effectiveness of error prevention | is a kind of software quality | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is measured by recording the frequency with which error messages appear | ![]() | ||||||||||||||||||||||
efficiency | has definition The extent to which a product or process can operate using the fewest possible resources | ![]() | |||||||||||||||||||||
is important to customers in order to reduce their costs of running the software | ![]() | ||||||||||||||||||||||
is a kind of external software quality | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
is constrained by software architecture | ![]() | ||||||||||||||||||||||
measures how much CPU-time, memory, disk-space, network bandwidth or other resources software uses | ![]() | ||||||||||||||||||||||
efficiency of use | has definition A measure of how fast an expert user can do their work using the system | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is concerned with ordinary use | ![]() | ||||||||||||||||||||||
is measured as the total number of instances of a small task that a user can do per hour, or the total time required to do a certain large task | ![]() | ||||||||||||||||||||||
measures how fast an expert user can do their work using the system | ![]() | ||||||||||||||||||||||
efficient testing | find the largest possible number of defects using the fewest possible tests | ![]() | |||||||||||||||||||||
is a kind of testing | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
effort | has definition The amount of labour used in a task or project, expressed in person-months or person-days | ![]() | |||||||||||||||||||||
is a kind of criterion | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
is a synonym of development effort | ![]() | ||||||||||||||||||||||
is measured in person-months or person-days | ![]() | ||||||||||||||||||||||
is used in cost estimation | ![]() | ||||||||||||||||||||||
can be converted into the cost of a software project by multiplying it by the weighted average cost of employing a software engineer for a month (or a day). | ![]() | ||||||||||||||||||||||
egoless team | advocates that decisions are made by consensus | ![]() | |||||||||||||||||||||
has (n2-n)/2 communication channels | ![]() | ||||||||||||||||||||||
has definition A team structure in which everybody is equal, decisions are made by consensus, and the team works together to achieve a common goal | ![]() | ||||||||||||||||||||||
has disadvantage it may run into trouble if personal conflicts arise | ![]() | ||||||||||||||||||||||
is dependent on the personalities of the individuals | ![]() | ||||||||||||||||||||||
is a kind of software engineering team model | ![]() | ||||||||||||||||||||||
is a subtopic of 11.4 - Building Software Engineering Teams | ![]() | ||||||||||||||||||||||
is suited to difficult projects with many technical challenges | ![]() | ||||||||||||||||||||||
recommends that everybody communicates with everybody else | ![]() | ||||||||||||||||||||||
can produce creative solutions since group members spontaneously get together to solve problems when they arise | ![]() | ||||||||||||||||||||||
elapsed time | has definition The difference in time from the start date to the end date of a software project | ![]() | |||||||||||||||||||||
is a kind of criterion | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
is used in cost estimation | ![]() | ||||||||||||||||||||||
elapsed-time transition | has definition A transition that occurs in a state diagram due to the passage of a period of time | ![]() | |||||||||||||||||||||
is a kind of transition | ![]() | ||||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
occurs as a result of a certain amount of elapsed time | ![]() | ||||||||||||||||||||||
electrical engineering | is a kind of engineering | ![]() | |||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
Electronic Software Reuse and Re-engineering Newsletter on the World Wide Web | has URL frakes.cs.vt.edu/renews.html ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
is an instance of newsgroup | ![]() | ||||||||||||||||||||||
else | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
has clients programs that read and send email such as Microsoft Outlook, Eudora | ![]() | ||||||||||||||||||||||
has server A post-office program that receives email from remote sites and holds it until an email-reading client is activated and that also forwards outgoing mail from the client to other sites. | ![]() | ||||||||||||||||||||||
is a kind of client-server system | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
embedded software | accounts for the bulk of software copies in existence | ![]() | |||||||||||||||||||||
has hard real-time characteristics and will fail completely if their real-time constraints are not met | ![]() | ||||||||||||||||||||||
has definition Software that is designed to run specific hardware devices, and thus is embedded in the devices, usually in a form of read-only memory (ROM) | ![]() | ||||||||||||||||||||||
has global CPU usage medium | ![]() | ||||||||||||||||||||||
has global development effort low | ![]() | ||||||||||||||||||||||
has global number of copies high | ![]() | ||||||||||||||||||||||
is a kind of software | ![]() | ||||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
runs hardware devices such as washing machines, VCRs, microwave ovens, or cars | ![]() | ||||||||||||||||||||||
cannot usually be replaced by the user without replacing the hardware | ![]() | ||||||||||||||||||||||
cannot usually be upgraded by the user without replacing the hardware | ![]() | ||||||||||||||||||||||
encapsulation | allows changes to code to be more easily made since one can be confident that 'outsiders' are not relying on too many details | ![]() | |||||||||||||||||||||
has definition Creating a module to contain some algorithm or data structure, thus hiding its details behind the module's interface | ![]() | ||||||||||||||||||||||
helps to achieve information hiding | ![]() | ||||||||||||||||||||||
is a kind of practice | ![]() | ||||||||||||||||||||||
is a subtopic of 2.7 - Concepts that Define Object Orientation | ![]() | ||||||||||||||||||||||
encoding technique | is a synonym of coding technique | ![]() | |||||||||||||||||||||
end state | has definition The final state reached by a system or object when it finishes working | ![]() | |||||||||||||||||||||
is a kind of state | ![]() | ||||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
is represented by end state symbol in a state diagram | ![]() | ||||||||||||||||||||||
end state symbol | is a kind of symbol in state diagram | ![]() | |||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a black circle with a ring around it | ![]() | ||||||||||||||||||||||
looks like a target | ![]() | ||||||||||||||||||||||
engineer | designs artefacts following well accepted practices which normally involve the application of science, mathematics and economics | ![]() | |||||||||||||||||||||
did not have to be licensed before the 1940's in most jurisdictions | ![]() | ||||||||||||||||||||||
has definition A person who performs engineering (in contrast to scientist). The term engineer is legally reserved, in many jurisdictions, for those who have obtained engineering education and experience, and perform engineering within a company or else have been granted a license, or some other form of certification, to offer engineering services to the public | ![]() | ||||||||||||||||||||||
has role to put knowledge to use in innovative ways to solve problems | ![]() | ||||||||||||||||||||||
is a kind of person | ![]() | ||||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
understands that omitting design documentation or documenting a design after it is complete is unacceptable, leads to serious mistakes, and makes planning for construction impossible | ![]() | ||||||||||||||||||||||
must adhere to a code of ethics | ![]() | ||||||||||||||||||||||
must be licensed in most countries in order to legally perform consulting or self-employed work where you call yourself an 'engineer' | ![]() | ||||||||||||||||||||||
must have sufficient engineering education and experience to be licensed | ![]() | ||||||||||||||||||||||
must take personal responsibility for work | ![]() | ||||||||||||||||||||||
should apply well-understood principles | ![]() | ||||||||||||||||||||||
should reuse established designs | ![]() | ||||||||||||||||||||||
engineering | has definition The process of solving problems by applying, in a disciplined, systematic and ethical way, scientific and economic knowledge and principles to the design and maintenance of products or processes | ![]() | |||||||||||||||||||||
has economic constraints | ![]() | ||||||||||||||||||||||
is a kind of discipline | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
engineering licensing agency | accredits educational institutions which they believe are providing a proper engineering education | ![]() | |||||||||||||||||||||
is a kind of organization | ![]() | ||||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
licenses engineers if they have sufficient background and have passed exams | ![]() | ||||||||||||||||||||||
engineering web site | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
enhancement | has definition A type of maintenance performed to add a new capability to software | ![]() | |||||||||||||||||||||
is a kind of maintenance | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
enhancement project | involves adding new features for the users | ![]() | |||||||||||||||||||||
is a kind of evolutionary project | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
Entity-Relationship diagram | is a kind of diagram | ![]() | |||||||||||||||||||||
is a subtopic of 5.7 - Detailed Example: A Class Diagram for Genealogy | ![]() | ||||||||||||||||||||||
is abbreviated as ERD | ![]() | ||||||||||||||||||||||
is used by database designers | ![]() | ||||||||||||||||||||||
does not show inheritance | ![]() | ||||||||||||||||||||||
does not show operations | ![]() | ||||||||||||||||||||||
enumerating attributes | is the first step when creating a set of test cases | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 10.8 - Writing Formal Test Cases and Test Plans | ![]() | ||||||||||||||||||||||
equals method | has example boolean b = aPostalCode.equals(anotherPostalCode); | ![]() | |||||||||||||||||||||
has purpose to test whether two objects are equal i.e. they contain the same data, but are not necessarily the same object | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java method | ![]() | ||||||||||||||||||||||
equivalence class | has benefit allows the tester to do efficient yet thorough black box testing | ![]() | |||||||||||||||||||||
has definition A set of inputs that a tester believes will be treated similarly by reasonable algorithms | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
equivalence class testing | has definition A testing strategy based on determining the possible equivalence classes and creating a test case for each | ![]() | |||||||||||||||||||||
is a kind of testing | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
ERD | is a subtopic of 5.7 - Detailed Example: A Class Diagram for Genealogy | ![]() | |||||||||||||||||||||
is an abbreviation for Entity-Relationship diagram | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
error | has definition A slip or inappropriate decision made by a software engineer that leads to the introduction of a defect into the system | ![]() | |||||||||||||||||||||
is a kind of mistake | ![]() | ||||||||||||||||||||||
is a subtopic of 10.1 - Basic Definitions | ![]() | ||||||||||||||||||||||
is more often made the boundaries of equivalence classes than in the middle | ![]() | ||||||||||||||||||||||
leads to a poor system | ![]() | ||||||||||||||||||||||
see also error^2 | ![]() | ||||||||||||||||||||||
can be made at any stage of the software development process, from requirements to implementation and maintenance | ![]() | ||||||||||||||||||||||
error handling | is better if the system effectively prevents the user from making errors, detects errors, and helps the user to correct errors | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is concerned with abnormal situations | ![]() | ||||||||||||||||||||||
measures how well the system prevents the user from making errors, detects errors, and helps the user to correct errors | ![]() | ||||||||||||||||||||||
error | may have root cause
| ![]() | |||||||||||||||||||||
error^2 | has definition A mistake made by a user | ![]() | |||||||||||||||||||||
is a kind of mistake | ![]() | ||||||||||||||||||||||
is a subtopic of 10.1 - Basic Definitions | ![]() | ||||||||||||||||||||||
see also error | ![]() | ||||||||||||||||||||||
error^3 | has definition An inaccuracy in a numerical computation | ![]() | |||||||||||||||||||||
is bad only if it is not anticipated and correctly handled | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 10.1 - Basic Definitions | ![]() | ||||||||||||||||||||||
ethical principle of usability evaluation | is a kind of principle | ![]() | |||||||||||||||||||||
is a subtopic of 7.6 - Evaluating User Interfaces | ![]() | ||||||||||||||||||||||
ethical principle of usability evaluation 1 | is a subtopic of 7.6 - Evaluating User Interfaces | ![]() | |||||||||||||||||||||
is an instance of ethical principle of usability evaluation | ![]() | ||||||||||||||||||||||
states that confidentiality of users must be respected | ![]() | ||||||||||||||||||||||
ethical principle of usability evaluation 2 | is a subtopic of 7.6 - Evaluating User Interfaces | ![]() | |||||||||||||||||||||
is an instance of ethical principle of usability evaluation | ![]() | ||||||||||||||||||||||
states that users must fully understand the purpose of the study and are made to feel at ease | ![]() | ||||||||||||||||||||||
evaluation by observation of users | has steps
| ![]() | |||||||||||||||||||||
is a kind of usability evaluation | ![]() | ||||||||||||||||||||||
is a subtopic of 7.6 - Evaluating User Interfaces | ![]() | ||||||||||||||||||||||
evaluator | is a kind of software developer | ![]() | |||||||||||||||||||||
is a subtopic of 7.6 - Evaluating User Interfaces | ![]() | ||||||||||||||||||||||
performs heuristic evaluation to test usability | ![]() | ||||||||||||||||||||||
event | has definition In a state diagram, something that causes a system or object to change state. May be a message, the passage of elapsed time, a condition becoming true, or completion of an activity | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
can cause a system or object to change from one state to another | ![]() | ||||||||||||||||||||||
evolution | has definition The process by which software is modified over the course of its lifetime to meet changing requirements and as problems are fixed or reengineering is performed | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
is part of software engineering | ![]() | ||||||||||||||||||||||
evolution of an existing system | is more common than green field development | ![]() | |||||||||||||||||||||
is a kind of development | ![]() | ||||||||||||||||||||||
is a subtopic of 4.2 - The Starting Point for Software Projects | ![]() | ||||||||||||||||||||||
may have the requirements already specified | ![]() | ||||||||||||||||||||||
evolutionary model | has definition A process model that views development as a series of hills, each representing a separate loop of the spiral model | ![]() | |||||||||||||||||||||
is a kind of process model | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
represents software development as a series of hills, each representing a separate loop of the spiral | ![]() | ||||||||||||||||||||||
shows that
| ![]() | ||||||||||||||||||||||
evolutionary project | has definition A software project to modify an existing system | ![]() | |||||||||||||||||||||
involves modifying an existing system | ![]() | ||||||||||||||||||||||
is more common than green field project | ![]() | ||||||||||||||||||||||
is a kind of software project | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
exception | has definition A situation that arises in a program requiring special handling, and hence deviation from the normal path of control | ![]() | |||||||||||||||||||||
is a kind of programming language construct | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is thrown when something goes wrong in the execution of a program | ![]() | ||||||||||||||||||||||
see also Exception class | ![]() | ||||||||||||||||||||||
Exception class | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java class | ![]() | ||||||||||||||||||||||
see also exception | ![]() | ||||||||||||||||||||||
executable file | is a kind of component | ![]() | |||||||||||||||||||||
is a kind of file | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
expert user | is a synonym of power user | ![]() | |||||||||||||||||||||
explicit attribute | has definition An attribute^2 that is stated in the requirements | ![]() | |||||||||||||||||||||
is a kind of attribute^2 | ![]() | ||||||||||||||||||||||
is a subtopic of 10.8 - Writing Formal Test Cases and Test Plans | ![]() | ||||||||||||||||||||||
can be found easily if the requirements are structured as a set of use cases | ![]() | ||||||||||||||||||||||
exploratory domain model | contains elements that represent things in the domain | ![]() | |||||||||||||||||||||
has part informal class diagram | ![]() | ||||||||||||||||||||||
helps in understanding the domain | ![]() | ||||||||||||||||||||||
is a kind of model | ![]() | ||||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is not usually concerned with operations and polymorphism, nor with modelling principles such as avoiding multiple inheritance. | ![]() | ||||||||||||||||||||||
does not contain elements that do not represent things in the domain, but are needed to build a complete system | ![]() | ||||||||||||||||||||||
may model things that will not be implemented | ![]() | ||||||||||||||||||||||
Extended Entity-Relationship diagram | is a kind of Entity-Relationship diagram | ![]() | |||||||||||||||||||||
is a subtopic of 5.7 - Detailed Example: A Class Diagram for Genealogy | ![]() | ||||||||||||||||||||||
is abbreviated as EERD | ![]() | ||||||||||||||||||||||
does show inheritance | ![]() | ||||||||||||||||||||||
extends | has example //Create a subclass | ![]() | |||||||||||||||||||||
has purpose to create a subclass | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
extension | has definition A use case that makes optional interactions explicit or handles exceptional cases | ![]() | |||||||||||||||||||||
has purpose to make optional interactions explicit or to handle exceptional cases, therefore allowing the description of the basic use case to remain simple | ![]() | ||||||||||||||||||||||
is a kind of use case | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
is related to the use case it extends | ![]() | ||||||||||||||||||||||
lists all the steps from the beginning of the use case to the end, including the handling of the unusual situation | ![]() | ||||||||||||||||||||||
external coupling | has definition A form of coupling in which a software component has a dependency to software written by a third party, or to a particular type of hardware | ![]() | |||||||||||||||||||||
is a kind of coupling | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
can be reduced by | ![]() | ||||||||||||||||||||||
external event | causes most transitions in a state diagram | ![]() | |||||||||||||||||||||
is a kind of event | ![]() | ||||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
external software quality | has a direct impact on stakeholders | ![]() | |||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
can be observed by stakeholders | ![]() | ||||||||||||||||||||||
extreme programming | has definition A process model and methodology that provides a disciplined approach to highly incremental and user-centred development of small projects | ![]() | |||||||||||||||||||||
has philosophy software developers should not need to be overworked, so overtime should not be needed | ![]() | ||||||||||||||||||||||
has principles
| ![]() | ||||||||||||||||||||||
has web site www.extremeprogramming.org ![]() | ![]() | ||||||||||||||||||||||
is popular for small projects that involve uncertain, changing requirements and other sources of high risk | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
is an instance of methodology | ![]() | ||||||||||||||||||||||
is an instance of process model | ![]() | ||||||||||||||||||||||
promotes the use of CRC cards, a focus on simplicity, creation of 'spike' throwaway prototypes when difficult technical issues are encountered, merciless restructuring of code, frequent integration, programming in pairs, and continual improvement | ![]() | ||||||||||||||||||||||
facade | has context html>
| ![]() | |||||||||||||||||||||
has definition A pattern in which you create a class that provides a simplified interface to a package | ![]() | ||||||||||||||||||||||
has forces html>
| ![]() | ||||||||||||||||||||||
has problem How do you simplify the view that programmers have of a complex package? | ![]() | ||||||||||||||||||||||
has references one of the Gang of Four patterns. | ![]() | ||||||||||||||||||||||
has solution
| ![]() | ||||||||||||||||||||||
is a subtopic of 6.9 - The Facade Pattern | ![]() | ||||||||||||||||||||||
is an instance of design pattern | ![]() | ||||||||||||||||||||||
facilitator | is a synonym of moderator | ![]() | |||||||||||||||||||||
failure | has definition An unacceptable behaviour exhibited by a system | ![]() | |||||||||||||||||||||
has example the production of incorrect outputs, the system running too slowly, or the user having trouble finding online help | ![]() | ||||||||||||||||||||||
is a kind of problem | ![]() | ||||||||||||||||||||||
is a subtopic of 10.1 - Basic Definitions | ![]() | ||||||||||||||||||||||
is a synonym of bug | ![]() | ||||||||||||||||||||||
is usually the result of a violation of those requirements that are stated explicitly in a requirements document | ![]() | ||||||||||||||||||||||
can be the result of a violation of an implicit requirement | ![]() | ||||||||||||||||||||||
may arise from violations of either functional requirements or non-functional requirements | ![]() | ||||||||||||||||||||||
may be cause by several defects working together | ![]() | ||||||||||||||||||||||
false | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
fat-client system | has advantage since more computations are distributed to the clients, better use is made of available computational resources; the server can therefore be smaller or can be made to handle more clients | ![]() | |||||||||||||||||||||
has definition A client-server system in which the client does a large amount of computation | ![]() | ||||||||||||||||||||||
is a kind of client-server system | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
feedback | has definition Any response in the system's user interface to a user's actions | ![]() | |||||||||||||||||||||
has example displaying a message, changing a colour or displaying a dialog | ![]() | ||||||||||||||||||||||
is a kind of event | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
field | is a synonym of instance variable | ![]() | |||||||||||||||||||||
file | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
filter | converts raw bytes of a message into other forms | ![]() | |||||||||||||||||||||
has definition A component in the pipe-and-filter architectural pattern that inputs simple data, from the pipeline, processes it and outputs data into the pipeline | ![]() | ||||||||||||||||||||||
is a kind of stream class | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
final | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
final software product | is a result of all the design decisions made during its design | ![]() | |||||||||||||||||||||
is a kind of program | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
will be different if different design decisions are made | ![]() | ||||||||||||||||||||||
final testing | is a kind of testing | ![]() | |||||||||||||||||||||
is a subtopic of 10.10 - Inspections | ![]() | ||||||||||||||||||||||
should be performed after inspecting | ![]() | ||||||||||||||||||||||
finally | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
financial benefit to user | is a kind of benefit | ![]() | |||||||||||||||||||||
is a subtopic of 9.3 - Techniques for Making Good Design Decisions | ![]() | ||||||||||||||||||||||
is measured by how much money the user can make or save if you implemented the alternative under consideration | ![]() | ||||||||||||||||||||||
first draft of architectural model | gives use case modellers guidance about the steps the user will need to perform | ![]() | |||||||||||||||||||||
is a kind of architectural model | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
can be created at the same time as the central use cases | ![]() | ||||||||||||||||||||||
flashing | has advantages it rapidly draws attention to items | ![]() | |||||||||||||||||||||
has problems
| ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
float | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java primitive data type | ![]() | ||||||||||||||||||||||
see also Float class | ![]() | ||||||||||||||||||||||
see also float^2 | ![]() | ||||||||||||||||||||||
stores a floating point number | ![]() | ||||||||||||||||||||||
can use basic arithmetic operators +, -, *, / and % | ![]() | ||||||||||||||||||||||
Float class | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java wrapper class | ![]() | ||||||||||||||||||||||
see also float | ![]() | ||||||||||||||||||||||
float^2 | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
see also float | ![]() | ||||||||||||||||||||||
flow graph | has definition A graph showing all possible paths through an algorithm | ![]() | |||||||||||||||||||||
is a kind of diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
font | has advantages it adds emphasis to text, and reinforces its structure, thus simplifying the information | ![]() | |||||||||||||||||||||
has localization issues | ![]() | ||||||||||||||||||||||
has problems
| ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
for | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
for loop | has advantage all the information about controlling the loop is kept in one place | ![]() | |||||||||||||||||||||
has disadvantage it can be slightly harder to read the code of a for loop than a while loop | ![]() | ||||||||||||||||||||||
has form for(initializer; condition; incrementer) | ![]() | ||||||||||||||||||||||
has part incrementer | ![]() | ||||||||||||||||||||||
has part initializer | ![]() | ||||||||||||||||||||||
is a kind of loop | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can be interchanged with a while loop | ![]() | ||||||||||||||||||||||
force | has definition In a pattern, an issue or concern that you need to consider when solving the problem, including, criteria for evaluating a good solution | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 6.1 - Introduction to Patterns | ![]() | ||||||||||||||||||||||
is part of design pattern | ![]() | ||||||||||||||||||||||
fork | causes execution to split into two concurrent threads | ![]() | |||||||||||||||||||||
has multiple outgoing transitions | ![]() | ||||||||||||||||||||||
has one incoming transition | ![]() | ||||||||||||||||||||||
has definition A symbol in an activity diagram indicating splitting of control into multiple threads | ![]() | ||||||||||||||||||||||
is a kind of symbol in activity diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 8.3 - Activity Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a short line at which transitions can start and end | ![]() | ||||||||||||||||||||||
formal language | has definition A language that uses mathematics for the purpose of modelling | ![]() | |||||||||||||||||||||
is a kind of language | ![]() | ||||||||||||||||||||||
is a subtopic of 4.8 - Reviewing Requirements | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
forward engineering | has definition Moving from requirements to design or design to implementation | ![]() | |||||||||||||||||||||
is a kind of software engineering | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
is part of reengineering | ![]() | ||||||||||||||||||||||
is performed during reverse engineering | ![]() | ||||||||||||||||||||||
fourth-generation language | has example applications like spreadsheets, word processors and database programs that come with built-in macro languages and have powerful reuse capabilities | ![]() | |||||||||||||||||||||
is a kind of programming language | ![]() | ||||||||||||||||||||||
is a subtopic of 3.1 - Reuse: Building on the Work and Experience of Others | ![]() | ||||||||||||||||||||||
provides many of the functions that a programmer may want to do (e.g. sorting, searching, displaying dialogs etc.) as basic language statements | ![]() | ||||||||||||||||||||||
framework | contains important functionality | ![]() | |||||||||||||||||||||
enables the reuse of both design and code | ![]() | ||||||||||||||||||||||
has definition A skeletal software component that performs functions needed by a class of systems, and which is intended to be incorporated into the design of such systems | ![]() | ||||||||||||||||||||||
has definition Reusable software that implements a generic solution to a generalized problem. It provides common facilities applicable to different application programs | ![]() | ||||||||||||||||||||||
has example A framework for a rental store could do such things as manage membership, handle deposits, process rentals and returns, and compute penalties for late returns | ![]() | ||||||||||||||||||||||
has part hook | ![]() | ||||||||||||||||||||||
has part slots | ![]() | ||||||||||||||||||||||
is incomplete | ![]() | ||||||||||||||||||||||
is a kind of component | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
provides common facilities applicable to different application programs | ![]() | ||||||||||||||||||||||
represents the structure of an entire application or subsystem | ![]() | ||||||||||||||||||||||
uses classes or methods that are missing | ![]() | ||||||||||||||||||||||
can be simple or complex | ![]() | ||||||||||||||||||||||
can be written in any programming language | ![]() | ||||||||||||||||||||||
framework developer | avoids divergent changes by designing the framework to be general enough | ![]() | |||||||||||||||||||||
implements design elements that are common to several applications | ![]() | ||||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | ||||||||||||||||||||||
should ensure that the framework is well tested and reviewed | ![]() | ||||||||||||||||||||||
framework | must be adapted to handle the requirements of particular customers | ![]() | |||||||||||||||||||||
framework with many slots | is complex to use | ![]() | |||||||||||||||||||||
is flexible | ![]() | ||||||||||||||||||||||
is more likely to be reused to create a wide range of applications across different domains | ![]() | ||||||||||||||||||||||
is a kind of framework | ![]() | ||||||||||||||||||||||
is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | ||||||||||||||||||||||
Framework-Based Software Development in C++ | has author G. Rogers | ![]() | |||||||||||||||||||||
has ISBN number 0-13-533365-2 | ![]() | ||||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
is an instance of book about frameworks | ![]() | ||||||||||||||||||||||
was published by Prentice Hall | ![]() | ||||||||||||||||||||||
was published in 1997 | ![]() | ||||||||||||||||||||||
function | is a kind of programming language construct | ![]() | |||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
Function Points | counts various features of the requirements and uses these to compute an estimate of the system's size | ![]() | |||||||||||||||||||||
has definition An algorithmic cost estimation method in which you count features of the requirements and use these to compute an estimate of the system's size | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
is an instance of algorithmic cost estimation model | ![]() | ||||||||||||||||||||||
functional cohesion | has advantages
| ![]() | |||||||||||||||||||||
has definition A form of cohesion in which modules which together perform a function (a computation that returns a result and has no side effects) are kept together, and everything else is kept out | ![]() | ||||||||||||||||||||||
is a kind of cohesion | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is achieved when a module only performs a single computation, and returns a result, without having side-effects | ![]() | ||||||||||||||||||||||
should be used if possible | ![]() | ||||||||||||||||||||||
functional requirement | describes what the system should do, i.e. the services provided for the users and for other systems | ![]() | |||||||||||||||||||||
has definition A requirement that describes a service provided by a system | ![]() | ||||||||||||||||||||||
is a kind of requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
should be consistent with non-functional requirements | ![]() | ||||||||||||||||||||||
should be consistent with project plan | ![]() | ||||||||||||||||||||||
functional requirements | contains
| ![]() | |||||||||||||||||||||
includes | ![]() | ||||||||||||||||||||||
is a kind of requirements document | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
do not describe particular algorithms to be used | ![]() | ||||||||||||||||||||||
functionally cohesive module | has example
| ![]() | |||||||||||||||||||||
has example a module that inputs meteorological data from weather stations and satellites and generates an atmospheric model that other systems can use to generate weather forecasts | ![]() | ||||||||||||||||||||||
has inputs function parameters, but they can also include files or some other stream of data | ![]() | ||||||||||||||||||||||
is a kind of cohesive module | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
returns a simple return value or a more complex data structure | ![]() | ||||||||||||||||||||||
can call the services of other modules, but the called modules must preserve the functional cohesion | ![]() | ||||||||||||||||||||||
does not have side effects such as updating a database or creating a new file | ![]() | ||||||||||||||||||||||
does not interact with the user | ![]() | ||||||||||||||||||||||
Game Architecture and Design | has author Andrew Rollings, Dave Morris | ![]() | |||||||||||||||||||||
has ISBN number 1-576-10425-7 | ![]() | ||||||||||||||||||||||
is a subtopic of 9.9 - Architecting and designing software - References | ![]() | ||||||||||||||||||||||
is an instance of software architecture book | ![]() | ||||||||||||||||||||||
was published by Coriolis Group | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
Gantt chart | contains one axis showing time and the other axis showing the activities that will be performed | ![]() | |||||||||||||||||||||
has definition A diagram used to graphically present the start and end dates of each software engineering task; it shows time on one axis, and tasks on the other | ![]() | ||||||||||||||||||||||
has purpose to graphically present the start and end dates of each software engineering task | ![]() | ||||||||||||||||||||||
is similar to a UML sequence chart | ![]() | ||||||||||||||||||||||
is a kind of diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 11.5 - Project Scheduling and Tracking | ![]() | ||||||||||||||||||||||
shows top-level tasks, subtasks and milestones | ![]() | ||||||||||||||||||||||
general hierarchy | has antipatterns modelling a hierarchy of categories using a hierarchy of classes | ![]() | |||||||||||||||||||||
has context many class diagrams where you often find a set of objects that have a naturally hierarchical relationship. | ![]() | ||||||||||||||||||||||
has definition A pattern in which two classes are related both by a generalization and by a one to many association, such that the generated graph of instances forms a hierarchy | ![]() | ||||||||||||||||||||||
has forces | ![]() | ||||||||||||||||||||||
has problem How do you draw a class diagram to represent a hierarchy of objects, in which some objects cannot have subordinates? | ![]() | ||||||||||||||||||||||
has related patterns the Reflexive Association pattern, the Composite pattern (a specialization of the General Hierarchy pattern) | ![]() | ||||||||||||||||||||||
has solution
| ![]() | ||||||||||||||||||||||
is a subtopic of 6.3 - The General Hierarchy Pattern | ![]() | ||||||||||||||||||||||
is an instance of design pattern | ![]() | ||||||||||||||||||||||
generalization | describes a relationship between classes in a class diagram | ![]() | |||||||||||||||||||||
groups classes into inheritance hierarchies | ![]() | ||||||||||||||||||||||
has definition The relationship between a set of similar entities and another entity that contains the common aspects of those entities | ![]() | ||||||||||||||||||||||
helps to avoid duplication of code | ![]() | ||||||||||||||||||||||
improves reuse | ![]() | ||||||||||||||||||||||
is a kind of hierarchy | ![]() | ||||||||||||||||||||||
is a subtopic of 5.4 - Generalization | ![]() | ||||||||||||||||||||||
is drawn as a small triangle pointing towards the superclass in a UML class diagram | ![]() | ||||||||||||||||||||||
is implemented using the extends keyword in Java | ![]() | ||||||||||||||||||||||
see also generalization^2, generalization^3 | ![]() | ||||||||||||||||||||||
does not appear in instance diagram | ![]() | ||||||||||||||||||||||
generalization hierarchy | is a synonym of inheritance hierarchy | ![]() | |||||||||||||||||||||
is a synonym of isa hierarchy | ![]() | ||||||||||||||||||||||
generalization symbol | is a kind of symbol in UML diagram | ![]() | |||||||||||||||||||||
is a subtopic of 5.2 - Essentials of UML Class Diagrams | ![]() | ||||||||||||||||||||||
generalization^2 | has definition The process of creating a relationship between a set of similar entities and another entity that contains the common aspects of those entities | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 5.4 - Generalization | ![]() | ||||||||||||||||||||||
see also generalization, generalization^3 | ![]() | ||||||||||||||||||||||
generalization^3 | has purpose to represent several similar use cases | ![]() | |||||||||||||||||||||
is a kind of use case | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
is used much like superclasses in a class diagram | ![]() | ||||||||||||||||||||||
see also generalization, generalization^2 | ![]() | ||||||||||||||||||||||
generic software | accounts for most of the software running today on general-purpose computers such as PCs; for example word processors, spreadsheets and games | ![]() | |||||||||||||||||||||
has requirements determined largely by market research | ![]() | ||||||||||||||||||||||
has soft real-time characteristics: when timing constraints are not met, such systems merely becomes sluggish to use | ![]() | ||||||||||||||||||||||
has definition Software designed to be sold on the open market and to perform functions on general-purpose computers that many people need (in contrast to custom software) | ![]() | ||||||||||||||||||||||
has example word processors, spreadsheets, compilers, web browsers, operating systems, computer games and accounting packages for small businesses | ![]() | ||||||||||||||||||||||
has global CPU usage high | ![]() | ||||||||||||||||||||||
has global development effort medium | ![]() | ||||||||||||||||||||||
has global number of copies medium | ![]() | ||||||||||||||||||||||
is a kind of software | ![]() | ||||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
is a synonym of commercial off-the-shelf software | ![]() | ||||||||||||||||||||||
is a synonym of shrink-wrapped software | ![]() | ||||||||||||||||||||||
is developed for potential customers | ![]() | ||||||||||||||||||||||
is often used by the business world instead of custom software because it can be far cheaper and more reliable | ![]() | ||||||||||||||||||||||
is sold on the open market | ![]() | ||||||||||||||||||||||
performs functions on general-purpose computers that many people need | ![]() | ||||||||||||||||||||||
can be cheaper and more reliable than custom software | ![]() | ||||||||||||||||||||||
can be customised but when a new release of the generic software is issued, the customization work may have to be re-done | ![]() | ||||||||||||||||||||||
may not meet an organization's specific needs | ![]() | ||||||||||||||||||||||
glass-box tester | designs design tests that will exercise all aspects of each algorithm and data structure | ![]() | |||||||||||||||||||||
examines the design documents and the code | ![]() | ||||||||||||||||||||||
is a kind of tester | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
observes the steps taken by algorithms and their internal data (at run time) | ![]() | ||||||||||||||||||||||
performs glass-box testing | ![]() | ||||||||||||||||||||||
can ensure that testing strategy has reached a targeted coverage of statements and branches | ![]() | ||||||||||||||||||||||
glass-box testing | allows the tester to be more thorough than black-box testing | ![]() | |||||||||||||||||||||
has definition A form of testing in which the tester can examine the design documents and the code, as well as analyze and possibly manipulate the internal state of the entity being tested | ![]() | ||||||||||||||||||||||
involves examining the design documents and the code, as well as observing at run time the steps taken by algorithms and their internal data | ![]() | ||||||||||||||||||||||
is more time consuming than black-box testing | ![]() | ||||||||||||||||||||||
is a kind of testing | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
is a synonym of structural testing | ![]() | ||||||||||||||||||||||
is a synonym of white-box testing | ![]() | ||||||||||||||||||||||
is part of a formal testing process only when testing critical or complex components | ![]() | ||||||||||||||||||||||
can detect deadlock and livelock | ![]() | ||||||||||||||||||||||
global variable | causes common coupling | ![]() | |||||||||||||||||||||
has definition A variable that is accessible from all procedures in the system, or in the scope of just a specific set of modules (e.g. a Java package). | ![]() | ||||||||||||||||||||||
is a kind of variable | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
were commonly used in older programming languages | ![]() | ||||||||||||||||||||||
glue code | has definition Code that is written to connect reused commercial off-the-shelf applications | ![]() | |||||||||||||||||||||
is a kind of code | ![]() | ||||||||||||||||||||||
is a subtopic of 3.1 - Reuse: Building on the Work and Experience of Others | ![]() | ||||||||||||||||||||||
is often written in a scripting language | ![]() | ||||||||||||||||||||||
goal | has definition What the user hopes to accomplish by using a system | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
gold-plating | has definition Building a list of requirements that does more than needed | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 4.8 - Reviewing Requirements | ![]() | ||||||||||||||||||||||
good software | is a kind of software | ![]() | |||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
is easy to modify | ![]() | ||||||||||||||||||||||
good user interface | allows the user to always get out, go back or undo an action | ![]() | |||||||||||||||||||||
allows the user to cancel out of a dialog box | ![]() | ||||||||||||||||||||||
allows the user to set system preferences so she always feels in control | ![]() | ||||||||||||||||||||||
allows the user to undo an action that may have changed data in the system | ![]() | ||||||||||||||||||||||
appears uncluttered | ![]() | ||||||||||||||||||||||
arranges elements in straight lines or several columns | ![]() | ||||||||||||||||||||||
asks the user to confirm an action if it can have serious consequences and cannot be undone | ![]() | ||||||||||||||||||||||
avoids technical jargon and acronyms in text | ![]() | ||||||||||||||||||||||
ensures that the user does not have to navigate anywhere to do subsequent steps of a task | ![]() | ||||||||||||||||||||||
explains a situation in adequate detail and helps the user to resolve a problem when something goes wrong | ![]() | ||||||||||||||||||||||
follows look-and-feel standards | ![]() | ||||||||||||||||||||||
follows usability principles | ![]() | ||||||||||||||||||||||
has different modes for beginners and power users if the system is complex | ![]() | ||||||||||||||||||||||
has easy-to-understand help | ![]() | ||||||||||||||||||||||
has informative error messages which tell the user the exact thing that has gone wrong and exactly how to correct the problem if possible | ![]() | ||||||||||||||||||||||
has response time of a second or less for operations such as saving most data, moving between windows, obtaining help, and obtaining the first feedback from any longer operation | ![]() | ||||||||||||||||||||||
has response time that appears instantaneous for operations such as tracking the cursor, popping up of menus and echoing of input | ![]() | ||||||||||||||||||||||
has adequate response time | ![]() | ||||||||||||||||||||||
informs the user about where they are located among the various windows and pages | ![]() | ||||||||||||||||||||||
informs users of the progress of operations, changes of state, and of their location as they navigate | ![]() | ||||||||||||||||||||||
is good enough that the user rarely needs to access the help system | ![]() | ||||||||||||||||||||||
is understandable by all users | ![]() | ||||||||||||||||||||||
is usable by people with disabilities | ![]() | ||||||||||||||||||||||
is a kind of user interface | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
is internationalized | ![]() | ||||||||||||||||||||||
mimics other applications, while avoiding copyright infringements and duplicating the weaknesses of other applications | ![]() | ||||||||||||||||||||||
only displays essential information, while allowing the user to request additional information by navigating to another dialog box, tab or page | ![]() | ||||||||||||||||||||||
provides adequate customization capabilities or preferences settings so that the user has the freedom to adapt the system to his or her needs | ![]() | ||||||||||||||||||||||
reduces the amount of reading and manipulation the user has to do | ![]() | ||||||||||||||||||||||
shows an indication of progress for operations that are time consuming | ![]() | ||||||||||||||||||||||
takes into account locale-dependent features | ![]() | ||||||||||||||||||||||
uses a progress bar to inform the user what is going on if an operation is taking more than a few seconds | ![]() | ||||||||||||||||||||||
uses appropriate coding techniques | ![]() | ||||||||||||||||||||||
uses good labels to ensure all coding techniques are fully understood by users | ![]() | ||||||||||||||||||||||
uses grouping, colour and fonts to help highlight the organization of information | ![]() | ||||||||||||||||||||||
uses similar layouts and graphic designs throughout the application | ![]() | ||||||||||||||||||||||
warns if the response time for an operation will be more than 15-20 seconds so that the user can do something else while waiting or choose not to perform the operation | ![]() | ||||||||||||||||||||||
warns the user, before they perform an action, if it cannot be undone | ![]() | ||||||||||||||||||||||
does not have too many pages, each with only a small amount of information, because the user will have to spend much time navigating and will become lost | ![]() | ||||||||||||||||||||||
does not use too many different colours, fonts or graphics | ![]() | ||||||||||||||||||||||
goto | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
graphical language | is a kind of language | ![]() | |||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
Greatest achievements of engineering | has URL www.greatachievements.org ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of engineering web site | ![]() | ||||||||||||||||||||||
green field development | forces the development team to determine the requirements for the software | ![]() | |||||||||||||||||||||
has definition Development of a completely new system, as opposed to modifying an existing system | ![]() | ||||||||||||||||||||||
is a kind of development | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
green field project | has definition A software project to develop an entirely new software system from scratch | ![]() | |||||||||||||||||||||
is less common than evolutionary project | ![]() | ||||||||||||||||||||||
is a kind of software project | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
is not constrained by the design decisions and errors made by predecessors | ![]() | ||||||||||||||||||||||
is often enjoyed by software developers because they have a wider freedom to be creative about the design | ![]() | ||||||||||||||||||||||
does not involve modifying an existing system | ![]() | ||||||||||||||||||||||
grouping and bordering | has advantages helps to convey the organization of information and reduce its perceived complexity | ![]() | |||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
guard condition | has definition A condition that determines whether a certain transition will occur in a state diagram when an event happens | ![]() | |||||||||||||||||||||
is a kind of condition | ![]() | ||||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
is evaluated only when its associated event occurs | ![]() | ||||||||||||||||||||||
occurs in a state diagram | ![]() | ||||||||||||||||||||||
GUI Design Handbook | has author S. Fowler | ![]() | |||||||||||||||||||||
has ISBN number 0-07-059274-8 | ![]() | ||||||||||||||||||||||
has URL www.books.mcgraw-hill.com/computing/authors/fowler.html ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
is an instance of book about user interfaces and usability | ![]() | ||||||||||||||||||||||
was published by McGraw Hill | ![]() | ||||||||||||||||||||||
was published in 1997 | ![]() | ||||||||||||||||||||||
Handbook of Software Quality Assurance | has editor G. Gordon Schulmeyer | ![]() | |||||||||||||||||||||
has ISBN number 0-130-10470-1 | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of book about software quality assurance | ![]() | ||||||||||||||||||||||
was published by Prentice Hall | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
hardware and third-party software specialist | is responsible for
| ![]() | |||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 11.4 - Building Software Engineering Teams | ![]() | ||||||||||||||||||||||
is part of software development team | ![]() | ||||||||||||||||||||||
heavyweight class | has definition A class which is time-consuming and complicated to create instances of | ![]() | |||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of 6.12 - The Proxy Pattern | ![]() | ||||||||||||||||||||||
help system | is a kind of software system | ![]() | |||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
provides help performing the steps of a task | ![]() | ||||||||||||||||||||||
does not explain all the details at once but gives the user an outline of the most important things he or she needs to know, with the opportunity to click on links that provide additional details | ![]() | ||||||||||||||||||||||
must be accurate and up-to-date | ![]() | ||||||||||||||||||||||
must be easily searchable | ![]() | ||||||||||||||||||||||
should be easy to understand | ![]() | ||||||||||||||||||||||
should be fast to access | ![]() | ||||||||||||||||||||||
should be integrated with the application, making it context sensitive | ![]() | ||||||||||||||||||||||
should explain error messages | ![]() | ||||||||||||||||||||||
should not increase user's frustration | ![]() | ||||||||||||||||||||||
heuristic evaluation | has definition The process of systematically looking for usability defects in a user interface, based on a set of usability guidelines or principles | ![]() | |||||||||||||||||||||
has steps
| ![]() | ||||||||||||||||||||||
is a kind of usability evaluation | ![]() | ||||||||||||||||||||||
is a subtopic of 7.6 - Evaluating User Interfaces | ![]() | ||||||||||||||||||||||
can be performed on a finished system or a prototype | ![]() | ||||||||||||||||||||||
hierarchical team | has n-1 communication channels | ![]() | |||||||||||||||||||||
has definition A rigid team structure in which each individual reports to a manager and is responsible for performing the tasks delegated by that manager | ![]() | ||||||||||||||||||||||
has disadvantage since everybody is responsible only for their own work, problems may go unnoticed | ![]() | ||||||||||||||||||||||
has risk important information will not be communicated | ![]() | ||||||||||||||||||||||
is like the military or a large bureaucratic organization | ![]() | ||||||||||||||||||||||
is a kind of software engineering team model | ![]() | ||||||||||||||||||||||
is a subtopic of 11.4 - Building Software Engineering Teams | ![]() | ||||||||||||||||||||||
is suited to large projects with a strict schedule and where everybody is well-trained and has a well-defined role | ![]() | ||||||||||||||||||||||
hierarchy | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 2.5 - Organizing Classes Into Inheritance Hierarchies | ![]() | ||||||||||||||||||||||
high efficiency | is a kind of efficiency | ![]() | |||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
may cause a design to be less easy to understand, which may reduce maintainability, which in turn leads to defects that reduce reliability | ![]() | ||||||||||||||||||||||
may require avoiding extra code to provide feedback to the users which reduces usability | ![]() | ||||||||||||||||||||||
may require not checking for errors and avoiding redundant computations which reduces reliability | ![]() | ||||||||||||||||||||||
high level language | comes with more basic libraries and APIs than low level language | ![]() | |||||||||||||||||||||
is a kind of programming language | ![]() | ||||||||||||||||||||||
is a subtopic of 3.1 - Reuse: Building on the Work and Experience of Others | ![]() | ||||||||||||||||||||||
high reliability | is the result of a very low failure rate | ![]() | |||||||||||||||||||||
is a kind of reliability | ![]() | ||||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
may require repeatedly checking for errors and adding redundant computations | ![]() | ||||||||||||||||||||||
high reusability | is a kind of reusability | ![]() | |||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
can reduce long-term costs faced by the development team | ![]() | ||||||||||||||||||||||
high usability | is a kind of usability | ![]() | |||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
may require adding extra code to provide feedback to the users, which might in turn reduce overall efficiency | ![]() | ||||||||||||||||||||||
high-yield testing | has definition A testing strategy that is both efficient and effective | ![]() | |||||||||||||||||||||
is a kind of testing strategy | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
holiday | has localization issues
| ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
hook | has definition An aspect of the design deliberately added to allow other designers to add additional functionality. It does nothing in the basic version of the system, but is designed to be implemented or overridden when the system is extended or reused | ![]() | |||||||||||||||||||||
is similar to a slot except that a hook represents functionality that it is optional for the developer to provide when they exploit the framework | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is part of system | ![]() | ||||||||||||||||||||||
hook method | has definition A method that does nothing other than returning to its caller, but is designed to be overridden in subclasses | ![]() | |||||||||||||||||||||
is a kind of method | ![]() | ||||||||||||||||||||||
is a subtopic of 3.7 - Basic Description of OCSF- Client Side | ![]() | ||||||||||||||||||||||
horizontal framework | has more slots and hooks than a vertical framework | ![]() | |||||||||||||||||||||
has definition A framework that provides facilities that many different types of applications will need | ![]() | ||||||||||||||||||||||
is a kind of framework | ![]() | ||||||||||||||||||||||
is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | ||||||||||||||||||||||
does not have as complete an implementation as a vertical framework | ![]() | ||||||||||||||||||||||
horizontal incremental testing | is a kind of incremental testing | ![]() | |||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
host | has definition A computer on a network | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is identified by prepending characters to the domain's name | ![]() | ||||||||||||||||||||||
must have a different number for each of its servers | ![]() | ||||||||||||||||||||||
host name | has definition An alphanumeric name given to a host, normally divided into several components separated by dots | ![]() | |||||||||||||||||||||
is a more human-readable form of IP address | ![]() | ||||||||||||||||||||||
is a kind of name | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
host name of a Unix or Linux computer | is a kind of host name | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
can be found by issuing the commands hostname or uname -n | ![]() | ||||||||||||||||||||||
can be found by using the command ypcat hosts | ![]() | ||||||||||||||||||||||
host name of a Windows 2000 computer | is a kind of host name | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
can be found by issuing the commands hostname and ipconfig /all | ![]() | ||||||||||||||||||||||
host name of a Windows 95 or 98 computer | is a kind of host name | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
can be found by issuing the command WINIPCFG and clicking on the 'more info' button or by looking in the 'identification' tab of the 'network' control panel | ![]() | ||||||||||||||||||||||
host name of a Windows NT computer | is a kind of host name | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
can be found by looking in the 'identification' tab of the 'network' control panel | ![]() | ||||||||||||||||||||||
hostname | has purpose to find the host name of a computer | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of Unix or Linux command | ![]() | ||||||||||||||||||||||
is an instance of Windows command | ![]() | ||||||||||||||||||||||
human language | has localization issues
| ![]() | |||||||||||||||||||||
is a kind of language | ![]() | ||||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
Human-Computer Interaction | has author A. Dix, J. Finlay, G. Abowd and R. Beale | ![]() | |||||||||||||||||||||
has ISBN number 0-13-239864-8 | ![]() | ||||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
is an instance of book about user interfaces and usability | ![]() | ||||||||||||||||||||||
was published by Prentice-Hall | ![]() | ||||||||||||||||||||||
was published in 1998 | ![]() | ||||||||||||||||||||||
hung system | has definition A system that appears to the user to not be doing anything, caused by such things as a crash, a deadlock, a livelock or an infinite loop | ![]() | |||||||||||||||||||||
is a kind of defect | ![]() | ||||||||||||||||||||||
is a kind of software system | ![]() | ||||||||||||||||||||||
is a subtopic of 10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races | ![]() | ||||||||||||||||||||||
may be caused by | ![]() | ||||||||||||||||||||||
IBM Java tutorials | has URL www.ibm.com/java/education/intro/courseoptions.htm ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of web site about Java | ![]() | ||||||||||||||||||||||
IBM VisualAge for Java | has URL www.ibm.com/visualage/vajava/ ![]() | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of programming environment | ![]() | ||||||||||||||||||||||
stores source code in a repository | ![]() | ||||||||||||||||||||||
icon | has advantages | ![]() | |||||||||||||||||||||
has localization issues
| ![]() | ||||||||||||||||||||||
has problems
| ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
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 it | ![]() | ||||||||||||||||||||||
identity | has definition The characteristic of having a distinct existence, such that each entity can be uniquely referred to | ![]() | |||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 2.7 - Concepts that Define Object Orientation | ![]() | ||||||||||||||||||||||
IEEE | is a subtopic of 1.2 - What is Software Engineering? | ![]() | |||||||||||||||||||||
is an instance of organization | ![]() | ||||||||||||||||||||||
standardizes software engineering practices | ![]() | ||||||||||||||||||||||
IEEE Computer Society | is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | |||||||||||||||||||||
is an instance of organization | ![]() | ||||||||||||||||||||||
publishes many software engineering publications, including IEEE Software | ![]() | ||||||||||||||||||||||
IEEE Software | has web site www.computer.org/software/ ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of software engineering magazine | ![]() | ||||||||||||||||||||||
is published by the IEEE Computer Society | ![]() | ||||||||||||||||||||||
IEEE Standard 1012 | covers Software Verification and Validation | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of quality assurance and testing standard | ![]() | ||||||||||||||||||||||
IEEE Standard 1028 | covers Software Reviews | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of quality assurance and testing standard | ![]() | ||||||||||||||||||||||
IEEE Standard 1219 | contains Software Maintenance ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of project management standard | ![]() | ||||||||||||||||||||||
IEEE Standard 1233 | contains Guide for Developing System Requirements Specifications | ![]() | |||||||||||||||||||||
is a subtopic of 4.13 - Developing Requirements - References | ![]() | ||||||||||||||||||||||
is an instance of standard | ![]() | ||||||||||||||||||||||
IEEE Standard 1490 | contains Adoption of the Project Management Institute's Project Management Body of Knowledge ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of project management standard | ![]() | ||||||||||||||||||||||
IEEE Standard 730 | covers Software Quality Assurance Plans | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of quality assurance and testing standard | ![]() | ||||||||||||||||||||||
IEEE Standard 828 | contains Software Configuration Management Plans | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of project management standard ![]() | ![]() | ||||||||||||||||||||||
IEEE Standard 830 | contains Recommended Practice for Software Requirements Specifications | ![]() | |||||||||||||||||||||
is a subtopic of 4.13 - Developing Requirements - References | ![]() | ||||||||||||||||||||||
is an instance of standard | ![]() | ||||||||||||||||||||||
IEEE standards web site | has URL www.standards.ieee.org/software/index.html ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of web site about standards | ![]() | ||||||||||||||||||||||
IEEE/ACM code of ethics | is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | |||||||||||||||||||||
is an instance of principle | ![]() | ||||||||||||||||||||||
states Software engineers shall:
| ![]() | ||||||||||||||||||||||
if | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
immutable | has context
| ![]() | |||||||||||||||||||||
has definition A pattern in which the instances of a class cannot change state after creation | ![]() | ||||||||||||||||||||||
has forces html>
| ![]() | ||||||||||||||||||||||
has problem How do you create a class whose instances are immutable? | ![]() | ||||||||||||||||||||||
has related patterns Read-Only Interface pattern provides the same capability as immutable, except that certain privileged classes are allowed to make changes to instances. | ![]() | ||||||||||||||||||||||
has solution | ![]() | ||||||||||||||||||||||
is a subtopic of 6.10 - The Immutable Pattern | ![]() | ||||||||||||||||||||||
is an instance of design pattern | ![]() | ||||||||||||||||||||||
immutable object | has definition an object that has a state which never changes after creation | ![]() | |||||||||||||||||||||
is a kind of object | ![]() | ||||||||||||||||||||||
is a subtopic of 6.10 - The Immutable Pattern | ![]() | ||||||||||||||||||||||
impact analysis | has definition The process of exploring and documenting all possible effects of a change | ![]() | |||||||||||||||||||||
is a kind of analysis | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
implementation | has definition The process of converting a design into an executable software system by programming and related activities | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
Implementing Application Frameworks: Object-Oriented Frameworks at Work | has author Mohamed E. Fayad, Douglas C. Schmidt and Ralph Johnson | ![]() | |||||||||||||||||||||
has ISBN number 0-471-25201-8 | ![]() | ||||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
is an instance of book about frameworks | ![]() | ||||||||||||||||||||||
was published by Wiley | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
implements | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
is used by implements clause in a class that indicates that the class contains methods for each of the operations specified by the interface | ![]() | ||||||||||||||||||||||
implicit attribute | has definition An attribute^2 that is implied rather than explicitly stated in the requirements | ![]() | |||||||||||||||||||||
is a kind of attribute^2 | ![]() | ||||||||||||||||||||||
is a subtopic of 10.8 - Writing Formal Test Cases and Test Plans | ![]() | ||||||||||||||||||||||
implicit requirement | has definition A requirement not stated explicitly in the requirements document | ![]() | |||||||||||||||||||||
is a kind of requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 10.1 - Basic Definitions | ![]() | ||||||||||||||||||||||
is discovered when a user or tester runs the system | ![]() | ||||||||||||||||||||||
import | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
import coupling | has definition A form of coupling in which one component declares that it imports (makes use of the definitions in) another | ![]() | |||||||||||||||||||||
has disadvantage if the imported component changes something on which the importer relies, or adds something that raises a conflict with something in the importer, then the importer must change | ![]() | ||||||||||||||||||||||
is a weaker form of inclusion coupling | ![]() | ||||||||||||||||||||||
is a kind of coupling | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is used by Java | ![]() | ||||||||||||||||||||||
can be reduced by not importing packages or classes which you do not need | ![]() | ||||||||||||||||||||||
can cause a system to suddenly fail if a new item is added to an imported file, and this new item has the same name as something you have already defined in your subsystem | ![]() | ||||||||||||||||||||||
inappropriate management of resources | has definition A defect that occurs when a program uses certain resources but does not make them available to other programs when it no longer needs them | ![]() | |||||||||||||||||||||
has testing strategy run the program intensively over a long period of time in such a way that it uses many resources, relinquishes them and then uses them again repeatedly | ![]() | ||||||||||||||||||||||
is a kind of defect in handling stress and unusual situations | ![]() | ||||||||||||||||||||||
is a subtopic of 10.6 - Defects in Handling Stress and Unusual Situations | ![]() | ||||||||||||||||||||||
inclusion | has definition A use case that captures commonality among a set of other use cases | ![]() | |||||||||||||||||||||
has purpose to allow you to express a part of a use case so you can capture commonality between several different use cases | ![]() | ||||||||||||||||||||||
is a kind of use case | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
is included in other use cases | ![]() | ||||||||||||||||||||||
represents a performing of a lower-level task with a lower-level goal | ![]() | ||||||||||||||||||||||
inclusion coupling | has definition A form of coupling in which one component includes the source code of another component. All the includers of a component are coupled to each other and to the included file | ![]() | |||||||||||||||||||||
has disadvantage if the included component changes something on which the includer relies, or adds something that raises a conflict with something in the includer, then the includer must change | ![]() | ||||||||||||||||||||||
is a stronger form of import coupling | ![]() | ||||||||||||||||||||||
is a kind of coupling | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is used by C and C++ | ![]() | ||||||||||||||||||||||
can be reduced by not including components which you do not need | ![]() | ||||||||||||||||||||||
incompatibility with specific configurations of hardware or software | has example a system might fail if a different graphics card is installed, if certain fonts are missing, or a newer or older version of a web browser is installed | ![]() | |||||||||||||||||||||
has testing strategy extensively execute the system with a wide variety of configurations that might be encountered by users | ![]() | ||||||||||||||||||||||
is a kind of defect in handling stress and unusual situations | ![]() | ||||||||||||||||||||||
is a subtopic of 10.6 - Defects in Handling Stress and Unusual Situations | ![]() | ||||||||||||||||||||||
incorrect logical conditions | has definition A common defect in which the logical conditions that govern looping and if-then-else statements are wrongly formulated | ![]() | |||||||||||||||||||||
has testing strategy using equivalence class and boundary testing - to compute the equivalence classes, consider as an input each variable used in a rule or logical condition | ![]() | ||||||||||||||||||||||
is a kind of defect in an ordinary algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
increased sales | is a kind of benefit | ![]() | |||||||||||||||||||||
is a subtopic of 9.3 - Techniques for Making Good Design Decisions | ![]() | ||||||||||||||||||||||
increasing cohesion | is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | |||||||||||||||||||||
is an instance of design principle | ![]() | ||||||||||||||||||||||
makes a module easier to understand and change | ![]() | ||||||||||||||||||||||
means ensuring that a package only has related classes | ![]() | ||||||||||||||||||||||
states that you should divide things into smaller chunks intelligently; divide things up, but keep things together that belong together | ![]() | ||||||||||||||||||||||
increasing reusability | is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | |||||||||||||||||||||
is an instance of design principle | ![]() | ||||||||||||||||||||||
can be accomplished by
| ![]() | ||||||||||||||||||||||
incremental cost of any development technology required | includes the cots of:
| ![]() | |||||||||||||||||||||
is a kind of cost | ![]() | ||||||||||||||||||||||
is a subtopic of 9.3 - Techniques for Making Good Design Decisions | ![]() | ||||||||||||||||||||||
incremental cost of software engineering work | includes the extra cost of work involved in
| ![]() | |||||||||||||||||||||
is a kind of cost | ![]() | ||||||||||||||||||||||
is a subtopic of 9.3 - Techniques for Making Good Design Decisions | ![]() | ||||||||||||||||||||||
is measured in person-days or person-months converted into monetary terms by multiplying by a factor that accounts for the average salary plus other costs associated with employing a person, such as their office space | ![]() | ||||||||||||||||||||||
incremental cost that end-users and product support personnel will experience | includes the cost of:
| ![]() | |||||||||||||||||||||
is a kind of cost | ![]() | ||||||||||||||||||||||
is a subtopic of 9.3 - Techniques for Making Good Design Decisions | ![]() | ||||||||||||||||||||||
incremental development | has definition A process model in which the software is developed in a series of releases | ![]() | |||||||||||||||||||||
is a kind of process model | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
incremental software engineering time saved | is a kind of benefit | ![]() | |||||||||||||||||||||
is a subtopic of 9.3 - Techniques for Making Good Design Decisions | ![]() | ||||||||||||||||||||||
incremental testing | has definition A integration testing strategy in which you test subsystems in isolation, and then continue testing as you integrate more and more subsystems | ![]() | |||||||||||||||||||||
is a kind of integration testing | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
independent testing | has advantage the testers do not have a vested interest in seeing as many test cases pass as possible | ![]() | |||||||||||||||||||||
has definition Testing performed by a separate group other than the people who do the design and programming | ![]() | ||||||||||||||||||||||
is a kind of testing performed by software engineers | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
independent testing group | has definition A testing group separate from those who designed and programmed the system | ![]() | |||||||||||||||||||||
is a kind of tester | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
independent testing | may be performed by a group that specializes in testing and has developed specific expertise in how to do good testing, and how to use testing tools | ![]() | |||||||||||||||||||||
informal class diagram | helps in understanding the domain | ![]() | |||||||||||||||||||||
is a kind of class diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is part of exploratory domain model | ![]() | ||||||||||||||||||||||
does not model software that will be developed | ![]() | ||||||||||||||||||||||
may be created while performing domain analysis | ![]() | ||||||||||||||||||||||
usually contains classes, associations and attributes that are outside the scope of the system | ![]() | ||||||||||||||||||||||
information hiding | has definition Hiding details so as to reduce complexity | ![]() | |||||||||||||||||||||
is a kind of practice | ![]() | ||||||||||||||||||||||
is a subtopic of 2.7 - Concepts that Define Object Orientation | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
information overload | causes the user to slow down, and makes learning the system harder | ![]() | |||||||||||||||||||||
distracts the user | ![]() | ||||||||||||||||||||||
has definition A situation that occurs when the user has too much to look at | ![]() | ||||||||||||||||||||||
is a common problem of user interfaces | ![]() | ||||||||||||||||||||||
is a kind of situation | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
inheritance | has definition The possession by one class of elements defined in another class, by virtue of the fact that the former class is defined to be a subclass of (to extend) the latter | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 2.5 - Organizing Classes Into Inheritance Hierarchies | ![]() | ||||||||||||||||||||||
occurs automatically once you have defined which classes are superclasses and which classes are their subclasses | ![]() | ||||||||||||||||||||||
inheritance hierarchy | has definition The hierarchy formed by the generalization relationships of a set of classes | ![]() | |||||||||||||||||||||
is a kind of hierarchy | ![]() | ||||||||||||||||||||||
is a subtopic of 2.5 - Organizing Classes Into Inheritance Hierarchies | ![]() | ||||||||||||||||||||||
is a synonym of generalization hierarchy | ![]() | ||||||||||||||||||||||
is a synonym of isa hierarchy | ![]() | ||||||||||||||||||||||
input field | is a kind of user interface component | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
InputStream | contains a message composed of bytes | ![]() | |||||||||||||||||||||
has example of instance creation input = clientSocket.getInputStream(); | ![]() | ||||||||||||||||||||||
is a member of the java.io package | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of stream class | ![]() | ||||||||||||||||||||||
inspecting | has definition A verification process that involves several people systematically proceeding through a document searching for defects | ![]() | |||||||||||||||||||||
involves understanding what would happen if the system were run | ![]() | ||||||||||||||||||||||
is complementary to testing | ![]() | ||||||||||||||||||||||
is mentally taxing | ![]() | ||||||||||||||||||||||
is a kind of verification | ![]() | ||||||||||||||||||||||
is a subtopic of 10.10 - Inspections | ![]() | ||||||||||||||||||||||
is normally performed in a meeting | ![]() | ||||||||||||||||||||||
is performed by inspection team | ![]() | ||||||||||||||||||||||
requires attention to detail | ![]() | ||||||||||||||||||||||
can find defects that relate to maintainability or efficiency that are not readily detectable when testing | ![]() | ||||||||||||||||||||||
can find defects whose consequences might be subtle, hence the tester might not have thought to test for them, but which become clear when reading the source code or design documents | ![]() | ||||||||||||||||||||||
does not normally include managers so that participants can express their criticisms more openly, not fearing repercussions from a manager but it may include managers if there are not enough people to perform inspections in a small organization | ![]() | ||||||||||||||||||||||
should be performed before extensive testing, perhaps before any testing | ![]() | ||||||||||||||||||||||
should not be done for more than two hours at a time or four hours a day | ![]() | ||||||||||||||||||||||
inspection | is a kind of verification | ![]() | |||||||||||||||||||||
is a subtopic of 10.10 - Inspections | ![]() | ||||||||||||||||||||||
see inspecting | ![]() | ||||||||||||||||||||||
inspection meeting | has procedure
| ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 10.10 - Inspections | ![]() | ||||||||||||||||||||||
inspection team | consists of software engineers with the following roles:
| ![]() | |||||||||||||||||||||
has only goal finding defects | ![]() | ||||||||||||||||||||||
includes experienced software engineers, who are more likely to uncover defects | ![]() | ||||||||||||||||||||||
is a kind of team | ![]() | ||||||||||||||||||||||
is a subtopic of 10.10 - Inspections | ![]() | ||||||||||||||||||||||
performs inspecting | ![]() | ||||||||||||||||||||||
can inspect about 200 lines of code per hour (including comments), or ten pages of text per hour | ![]() | ||||||||||||||||||||||
does not normally include manager so that participants can express their criticisms more openly, not fearing repercussions from the manager | ![]() | ||||||||||||||||||||||
may include a manager if there are not enough people to perform inspections in a small organization | ![]() | ||||||||||||||||||||||
should avoid discussing how to fix defects because this is a design issue that can be left to the author | ![]() | ||||||||||||||||||||||
should avoid discussing style issues | ![]() | ||||||||||||||||||||||
should avoid getting tired | ![]() | ||||||||||||||||||||||
should be effective and efficient | ![]() | ||||||||||||||||||||||
should consist of between two and five people (including the author) | ![]() | ||||||||||||||||||||||
should ensure that all the defects in the log are resolved | ![]() | ||||||||||||||||||||||
should feel that they are all working together to create a better document | ![]() | ||||||||||||||||||||||
should inspect all aspects of code should be considered, including the comments | ![]() | ||||||||||||||||||||||
should inspect code, design documents, test plans and requirements | ![]() | ||||||||||||||||||||||
should inspect the most important documents of all types, not necessarily every single piece of code or every document | ![]() | ||||||||||||||||||||||
should keep logs of inspections | ![]() | ||||||||||||||||||||||
should not inspect documents that are not ready | ![]() | ||||||||||||||||||||||
should not rush | ![]() | ||||||||||||||||||||||
should not work for more than two hours at a time, or for more than four hours a day | ![]() | ||||||||||||||||||||||
should prepare for inspections by studying the code or other documents prior to the meeting and coming prepared with a list of defects | ![]() | ||||||||||||||||||||||
should re-inspect documents or code that is changed more than 20% for any reason | ![]() | ||||||||||||||||||||||
instance | has synonym object | ![]() | |||||||||||||||||||||
is a single member of the set defined by a class | ![]() | ||||||||||||||||||||||
is a synonym of object | ![]() | ||||||||||||||||||||||
instance diagram | has definition A UML diagram that shows objects and the links between them | ![]() | |||||||||||||||||||||
is similar to collaboration diagram except that it shows links of associations | ![]() | ||||||||||||||||||||||
is a kind of UML diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.5 - Instance Diagrams | ![]() | ||||||||||||||||||||||
is generated by class diagram which means that it contains instances and links that are present in the class diagram, and are consistent with that class diagram | ![]() | ||||||||||||||||||||||
shows a link between two objects drawn as a simple line | ![]() | ||||||||||||||||||||||
shows an example configuration of objects and links that may exist at a particular point during execution of a program | ![]() | ||||||||||||||||||||||
shows an instance of both classes that are joined by an association in the associated class diagram | ![]() | ||||||||||||||||||||||
can contain only links generated by associations, not the associations themselves | ![]() | ||||||||||||||||||||||
cannot contain a generalization | ![]() | ||||||||||||||||||||||
instance method | has definition A method that executes in the context of a particular object; it has access to the instance variables of the given object, and can refer to the object itself using the 'this' keyword (in Java and C++) | ![]() | |||||||||||||||||||||
is a kind of method | ![]() | ||||||||||||||||||||||
is a subtopic of 2.4 - Methods, Operations and Polymorphism | ![]() | ||||||||||||||||||||||
instance method call | has example resultVariable = b.methodName(arguments);where b is the object containing instance method methodName | ![]() | |||||||||||||||||||||
is a kind of Java method call | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
instance of user interface class | is a kind of object | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is normally created when a program is started | ![]() | ||||||||||||||||||||||
is normally discarded when a program terminates | ![]() | ||||||||||||||||||||||
instance variable | has definition A data item present in all the instances of a class, normally used to implement associations and attributes | ![]() | |||||||||||||||||||||
implements an attribute or association | ![]() | ||||||||||||||||||||||
is a kind of variable | ![]() | ||||||||||||||||||||||
is a subtopic of 2.3 - Instance Variables | ![]() | ||||||||||||||||||||||
is a synonym of data member | ![]() | ||||||||||||||||||||||
is a synonym of field | ![]() | ||||||||||||||||||||||
should be as private as reasonably possible - almost never make them public | ![]() | ||||||||||||||||||||||
instanceof | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
insufficient throughput or response time on minimal configurations | has definition A defect that occurs when the system is tested on a minimal configuration and its throughput or response time fails to meet requirements | ![]() | |||||||||||||||||||||
has testing strategy
| ![]() | ||||||||||||||||||||||
is a kind of defect in handling stress and unusual situations | ![]() | ||||||||||||||||||||||
is a subtopic of 10.6 - Defects in Handling Stress and Unusual Situations | ![]() | ||||||||||||||||||||||
int | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java primitive data type | ![]() | ||||||||||||||||||||||
requires 32 bits | ![]() | ||||||||||||||||||||||
see also int^2 | ![]() | ||||||||||||||||||||||
see also Integer | ![]() | ||||||||||||||||||||||
can use basic arithmetic operators +, -, *, / and % | ![]() | ||||||||||||||||||||||
int^2 | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
see also int | ![]() | ||||||||||||||||||||||
Integer | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java wrapper class | ![]() | ||||||||||||||||||||||
see also int | ![]() | ||||||||||||||||||||||
integration testing | has advantage when you find a problem, you can find the defect more easily because you have a better idea in which subsystem to look | ![]() | |||||||||||||||||||||
has definition Testing a system in a phased approach - first testing individual subsystems, then testing the integrated system | ![]() | ||||||||||||||||||||||
has definition Testing during or following the process of integrating a system | ![]() | ||||||||||||||||||||||
is better than big bang testing for large systems | ![]() | ||||||||||||||||||||||
is a kind of testing performed by software engineers | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
interaction | has definition The set of steps in a use case or other piece of functionality | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
interaction diagram | has definition A sequence diagram or collaboration diagram used to model the dynamic aspects of a software system | ![]() | |||||||||||||||||||||
has part actor symbol | ![]() | ||||||||||||||||||||||
has part message symbol | ![]() | ||||||||||||||||||||||
has part object symbol | ![]() | ||||||||||||||||||||||
has purpose to better understand the sequence of messages | ![]() | ||||||||||||||||||||||
helps you to visualize how the system runs | ![]() | ||||||||||||||||||||||
is a kind of UML diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
models the dynamic aspects of a software system | ![]() | ||||||||||||||||||||||
shows the behaviour of systems in terms of how objects interact with each other | ![]() | ||||||||||||||||||||||
can be used to define the protocol used when two components communicate with each other | ![]() | ||||||||||||||||||||||
can contain more or less detail depending on what you wish to communicate | ![]() | ||||||||||||||||||||||
can show several different types of communication including:
| ![]() | ||||||||||||||||||||||
should be created after developing a class diagram and a use case model because you need to know the actors and objects involved in an interaction | ![]() | ||||||||||||||||||||||
interface | describes a portion of the visible behaviour of a set of objects | ![]() | |||||||||||||||||||||
has purpose to specify a set of methods that a variety of different classes can implement polymorphically | ![]() | ||||||||||||||||||||||
is like a class except that it does not have any executable statements - it only contains abstract methods and class variables | ![]() | ||||||||||||||||||||||
is a kind of data abstraction | ![]() | ||||||||||||||||||||||
is a subtopic of 2.7 - Concepts that Define Object Orientation | ![]() | ||||||||||||||||||||||
is created using superclasses containing only abstract methods in some languages | ![]() | ||||||||||||||||||||||
is drawn as a small circle (like a lollipop), labelled with the name of the interface or as a class rectangle, with the expression «interface» at the top, and (optionally) a list of supported operations in a UML diagram | ![]() | ||||||||||||||||||||||
is implemented using the implements keyword in Java | ![]() | ||||||||||||||||||||||
provides many of the same benefits as multiple inheritance | ![]() | ||||||||||||||||||||||
see also interface^2 | ![]() | ||||||||||||||||||||||
see also interface^3 | ![]() | ||||||||||||||||||||||
shows a can-be-seen-as relation between the implementing class and the interface | ![]() | ||||||||||||||||||||||
cannot have any concrete methods or instance variables | ![]() | ||||||||||||||||||||||
should not be confused with generalizations | ![]() | ||||||||||||||||||||||
interface^2 | has definition The operations provided by a module for other modules to use | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
see also interface | ![]() | ||||||||||||||||||||||
see also interface^3 | ![]() | ||||||||||||||||||||||
interface^3 | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
see also interface | ![]() | ||||||||||||||||||||||
see also interface^2 | ![]() | ||||||||||||||||||||||
internal event | causes most transitions in an activity diagram | ![]() | |||||||||||||||||||||
has definition An event caused within a component, such as completion of an activity | ![]() | ||||||||||||||||||||||
has example completion of an activity | ![]() | ||||||||||||||||||||||
is a kind of event | ![]() | ||||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
internal software quality | has an effect on external quality attributes | ![]() | |||||||||||||||||||||
has definition A software quality that characterize aspects of the design of the software | ![]() | ||||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
International Standards Association | is a subtopic of 1.2 - What is Software Engineering? | ![]() | |||||||||||||||||||||
is abbreviated as ISO | ![]() | ||||||||||||||||||||||
is an instance of organization | ![]() | ||||||||||||||||||||||
standardizes software engineering practices | ![]() | ||||||||||||||||||||||
internationalization | has definition The process of ensuring that a system can be easily adapted to different locales | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
interval | has example 1..3, 0..*, 1..* | ![]() | |||||||||||||||||||||
is a kind of multiplicity | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is be written as two dots between the lower and upper bound | ![]() | ||||||||||||||||||||||
interviewing | has purpose information gathering | ![]() | |||||||||||||||||||||
is widely used | ![]() | ||||||||||||||||||||||
is a kind of requirements gathering | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
should be well planned | ![]() | ||||||||||||||||||||||
should be performed by as many members of the software engineering team as possible | ![]() | ||||||||||||||||||||||
should be performed on as many stakeholders as possible, as well as users of competing products, marketing personnel, and people involved with other systems that may interact in any way with the proposed system | ![]() | ||||||||||||||||||||||
should not include analysis | ![]() | ||||||||||||||||||||||
Introduction to the Personal Software Process | has author W. Humphrey | ![]() | |||||||||||||||||||||
has ISBN number 0-201-54809-7 | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of book about process standards | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1996 | ![]() | ||||||||||||||||||||||
Introduction to the Team Software Process | has author W. Humphrey, M. Lovelace, R. Hoppes | ![]() | |||||||||||||||||||||
has ISBN number 0-201-47719-X | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of book about process standards | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
IOException | is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | |||||||||||||||||||||
is an instance of Java class | ![]() | ||||||||||||||||||||||
is thrown if communication in a client server system fails | ![]() | ||||||||||||||||||||||
IP | has definition Abbreviation for 'Internet Protocol', the low-level protocol used by all computers on the Internet, in which messages are divided into packets for delivery to a remote host | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an abbreviation for Internet Protocol | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
is an instance of protocol | ![]() | ||||||||||||||||||||||
IP address | consists of four numbers, each between 0 and 255 | ![]() | |||||||||||||||||||||
has current version IP version 4 | ![]() | ||||||||||||||||||||||
has definition The address of a computer (i.e. a host) connected to an IP network | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
IP address of a Macintosh computer | is a kind of IP address | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
can be found by opening the TCP/IP control panel or running the Apple System Profiler and looking under 'Network overview' and 'TCP/IP' | ![]() | ||||||||||||||||||||||
IP address of a Unix or Linux computer | is a kind of IP address | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
can be found by using the command ypcat hosts grep <hostname> | ![]() | ||||||||||||||||||||||
IP address of a Windows 95 or 98 computer | is a kind of IP address | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
can be found by issuing the command winipcfg | ![]() | ||||||||||||||||||||||
IP address of your computer | is a kind of IP address | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
can be found using tools at the web site privacy.net/analyze/ ![]() | ![]() | ||||||||||||||||||||||
ipconfig | has purpose to find the host name of a Windows 2000 computer | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of Windows command | ![]() | ||||||||||||||||||||||
isa hierarchy | is a synonym of generalization hierarchy | ![]() | |||||||||||||||||||||
is a synonym of inheritance hierarchy | ![]() | ||||||||||||||||||||||
isa relation | characterizes inheritance | ![]() | |||||||||||||||||||||
is a kind of relation | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
isa rule | is a subtopic of 2.5 - Organizing Classes Into Inheritance Hierarchies | ![]() | |||||||||||||||||||||
is an instance of rule | ![]() | ||||||||||||||||||||||
states that class A can only be a valid subclass of class B if it makes sense, in English, to say, "an A is a B" | ![]() | ||||||||||||||||||||||
isDigit | has example // tests if the character is a digit | ![]() | |||||||||||||||||||||
has purpose to test if a character is a digit | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java class method | ![]() | ||||||||||||||||||||||
ISO | is a subtopic of 1.2 - What is Software Engineering? | ![]() | |||||||||||||||||||||
is an abbreviation for International Standards Association | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
ISO 9000 Quality Systems Handbook | has author D. Hoyle | ![]() | |||||||||||||||||||||
has ISBN number 0-750-64451-6 | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of book about process standards | ![]() | ||||||||||||||||||||||
was published by Butterworth-Heinemann | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
ISO 9000-3 | has definition An international standard that lists a large number of things an organization should do to improve its overall software process | ![]() | |||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
is an instance of process standard | ![]() | ||||||||||||||||||||||
ISO Standard - British Standard - IEEE Standard 12207 | contains Software Lifecycle Processes | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of project management standard | ![]() | ||||||||||||||||||||||
ISO Standard - British Standard 15504 | contains Software Process Assessment | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of project management standard | ![]() | ||||||||||||||||||||||
ISO web site | has URL www.iso.ch ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of web site about standards | ![]() | ||||||||||||||||||||||
isolated component | is a kind of component | ![]() | |||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
can be replaced with a different component that has equivalent functionality | ![]() | ||||||||||||||||||||||
iteration expression | has definition An expression in an interaction diagram, used to indicate the set of objects (shown as a multiobject) to which a message will be sent | ![]() | |||||||||||||||||||||
is a kind of symbol in sequence diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
is contained in square brackets | ![]() | ||||||||||||||||||||||
is part of sequence diagram | ![]() | ||||||||||||||||||||||
represents the same message being sent to several objects of the same class | ![]() | ||||||||||||||||||||||
iterative development | has definition An approach to development by which software is developed in stages, with the first stage being very simple, and subsequent stages adding more features | ![]() | |||||||||||||||||||||
is a kind of development | ![]() | ||||||||||||||||||||||
is a subtopic of 1.8 - The Eight Themes Emphasized in this Book | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
Iterator | has example //counts the number of empty strings in a collection of strings | ![]() | |||||||||||||||||||||
has remove method that allows you to selectively delete elements of the underlying collection | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java interface | ![]() | ||||||||||||||||||||||
JAD | is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | |||||||||||||||||||||
is an abbreviation for Joint Application Development | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
Java | adopted many ideas from Smalltalk | ![]() | |||||||||||||||||||||
allows you to use CORBA facilities | ![]() | ||||||||||||||||||||||
avoids the worst kinds of content coupling (e.g. those involving manipulation of pointers) by making it hard to achieve. | ![]() | ||||||||||||||||||||||
contains extensive on-line documentation about each class and method | ![]() | ||||||||||||||||||||||
has much the same syntax as C | ![]() | ||||||||||||||||||||||
has feature single inheritance | ![]() | ||||||||||||||||||||||
has feature very easy-to-program networking capabilities | ![]() | ||||||||||||||||||||||
has order of operator precedence | ![]() | ||||||||||||||||||||||
is easier to program than C++ | ![]() | ||||||||||||||||||||||
is less efficient than C and C++ because it contains safety because it contains safety checks that slow down execution and because Java is interpreted which is slower than direct execution of machine code | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of object oriented language | ![]() | ||||||||||||||||||||||
is not the same as JavaScript | ![]() | ||||||||||||||||||||||
is run using a virtual machine | ![]() | ||||||||||||||||||||||
sets the default locale based on what is set in the operating system | ![]() | ||||||||||||||||||||||
uses Unicode | ![]() | ||||||||||||||||||||||
was originally called Oak | ![]() | ||||||||||||||||||||||
will not allow violations of certain security constraints when programs are downloaded over the Internet | ![]() | ||||||||||||||||||||||
Java abstract class | has one or more abstract methods | ![]() | |||||||||||||||||||||
is a kind of abstract class | ![]() | ||||||||||||||||||||||
is a kind of Java class | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is created by specifying the abstract keyword on the first line when you declare the class | ![]() | ||||||||||||||||||||||
Java abstract method | is a kind of abstract method | ![]() | |||||||||||||||||||||
is a kind of Java method | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is created by labelling it with the keyword abstract | ![]() | ||||||||||||||||||||||
must not contain any executable statements in its body | ![]() | ||||||||||||||||||||||
Java access control keyword | has purpose to control which other code can have access to a method or variable | ![]() | |||||||||||||||||||||
is a kind of Java keyword | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
precedes the definition of a method, instance variable or class variable | ![]() | ||||||||||||||||||||||
Java applet | has definition A small Java program | ![]() | |||||||||||||||||||||
is a kind of Java program | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is usually a thin-client so it will download rapidly | ![]() | ||||||||||||||||||||||
can be loaded directly into a web browser | ![]() | ||||||||||||||||||||||
Java application | is a kind of application | ![]() | |||||||||||||||||||||
is a kind of Java program | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java arithmetic operator | is a kind of Java operator | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java array | contains a fixed number of elements | ![]() | |||||||||||||||||||||
has example //the following sums all the elements of an integer array: | ![]() | ||||||||||||||||||||||
has length | ![]() | ||||||||||||||||||||||
is more efficient than specialized collection classes | ![]() | ||||||||||||||||||||||
is object-like but is not a true instance of a class | ![]() | ||||||||||||||||||||||
is zero-based which means the first element is element 0 | ![]() | ||||||||||||||||||||||
is a kind of Java data type | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is declared by array declaration | ![]() | ||||||||||||||||||||||
is not an instance of a class which you can subclass or for which you can write your own code | ![]() | ||||||||||||||||||||||
can be composed of primitive types and instances of classes | ![]() | ||||||||||||||||||||||
Java array declaration | has example int[] anIntArray = new int[25]; | ![]() | |||||||||||||||||||||
has form square brackets following the type | ![]() | ||||||||||||||||||||||
is a kind of Java declaration | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java array | should be avoided if you do not a-priori know the number of items it will contain | ![]() | |||||||||||||||||||||
should not be used to manipulate collections of objects | ![]() | ||||||||||||||||||||||
Java assignment statement | has example aVariable = 5; | ![]() | |||||||||||||||||||||
is a kind of assignment statement | ![]() | ||||||||||||||||||||||
is a kind of Java statement | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java Bean | is a kind of Java user interface component | ![]() | |||||||||||||||||||||
is a subtopic of 7.7 - Implementing a Simple GUI in Java | ![]() | ||||||||||||||||||||||
Java block | contains several statements surrounded by braces | ![]() | |||||||||||||||||||||
has example { | ![]() | ||||||||||||||||||||||
has layout example style preferred by Sun:if(condition) { | ![]() | ||||||||||||||||||||||
has layout example style preferred by the authors:if(condition) | ![]() | ||||||||||||||||||||||
is a kind of block | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is used as the body of classes, loops, conditional statements and for exception handling | ![]() | ||||||||||||||||||||||
Java built-in exception | is a kind of Java exception | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java bytecode | is a kind of bytecode | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is stored in Java class files ending with the .class suffix, or in libraries ending with .jar | ![]() | ||||||||||||||||||||||
Java class | has form class classname | ![]() | |||||||||||||||||||||
is abstract if it has one or more abstract methods | ![]() | ||||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a kind of Java module | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is stored in a file of the same name | ![]() | ||||||||||||||||||||||
uses an implements clause to declare that it contains methods for each of the operations specified by the interface | ![]() | ||||||||||||||||||||||
can extend only one superclass | ![]() | ||||||||||||||||||||||
can have more than one constructor each of which has different sets of arguments | ![]() | ||||||||||||||||||||||
can have the same name as another class if the two classes are not in the same package and their packages are never imported into the same file | ![]() | ||||||||||||||||||||||
can implement more than one interface | ![]() | ||||||||||||||||||||||
Java class file | contains Java bytecode | ![]() | |||||||||||||||||||||
is a kind of file | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java class in a package | is a kind of Java class | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
must be put into a directory with the same name as the package | ![]() | ||||||||||||||||||||||
Java class in an imported package | is a kind of Java class in a package | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can be referred to by name if the package is imported | ![]() | ||||||||||||||||||||||
Java class | may implement particular low-level subsystems | ![]() | |||||||||||||||||||||
Java class method | is a kind of class method | ![]() | |||||||||||||||||||||
is a kind of Java method | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is called by using the name of the class, followed by a dot, followed by the name of the method (the name of the class can be omitted when calling a class method in the current class) | ![]() | ||||||||||||||||||||||
is marked as static | ![]() | ||||||||||||||||||||||
does not have 'this' value when it is executing | ![]() | ||||||||||||||||||||||
Java class name | has first letter of each word capitalized by convention | ![]() | |||||||||||||||||||||
has example PartTimeEmployee | ![]() | ||||||||||||||||||||||
is a kind of class name | ![]() | ||||||||||||||||||||||
is a kind of name | ![]() | ||||||||||||||||||||||
is a subtopic of 2.2 - Classes and Objects | ![]() | ||||||||||||||||||||||
does not contain spaces | ![]() | ||||||||||||||||||||||
Java class | should be placed in its own source file | ![]() | |||||||||||||||||||||
should have a unique name since somebody in the future might want to import the packages containing both classes and hence create a name clash | ![]() | ||||||||||||||||||||||
should order elements as follows: | ![]() | ||||||||||||||||||||||
Java class that implements an interface | is a kind of Java class | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
does not have to be related to other classes that implement the same interface in any other way | ![]() | ||||||||||||||||||||||
Java class that imports a package | has access to methods and variables in the imported package that are not declared public | ![]() | |||||||||||||||||||||
is a kind of Java class | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java class variable | is a kind of class variable | ![]() | |||||||||||||||||||||
is a kind of Java variable | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is accessed by specifying the name of the class, followed by a dot, followed by the name of the variable | ![]() | ||||||||||||||||||||||
is declared in the body of the class (not inside a method) | ![]() | ||||||||||||||||||||||
is marked as static | ![]() | ||||||||||||||||||||||
can serve as a global variable | ![]() | ||||||||||||||||||||||
Java clause | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java client | is a kind of client | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
receives messages from the server using an instance of InputStream | ![]() | ||||||||||||||||||||||
sends messages to the server using an instance of OutputStream | ![]() | ||||||||||||||||||||||
sends stream of information to the server | ![]() | ||||||||||||||||||||||
may send messages to Java server at any time once a connection is established | ![]() | ||||||||||||||||||||||
must have an instance of Socket class in order to exchange information with the server | ![]() | ||||||||||||||||||||||
Java collection class | has part iterator method | ![]() | |||||||||||||||||||||
has purpose working with collections of objects | ![]() | ||||||||||||||||||||||
is a kind of Java class | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
uses iterator methods for doing something with every member of the collection | ![]() | ||||||||||||||||||||||
Java comment | has example executeMe(); // doNotExecuteMe | ![]() | |||||||||||||||||||||
has example executeMeToo(); /* This is to be ignored | ![]() | ||||||||||||||||||||||
has form '/*' comment '*/' or two slashes '//' indicating that the rest of the line is to be considered a comment | ![]() | ||||||||||||||||||||||
is a kind of comment | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java compiler | compiles source code into Java bytecode | ![]() | |||||||||||||||||||||
is a kind of compiler | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java condition | has definition A condition in Java is a statement that evaluates to a boolean value (true or false) | ![]() | |||||||||||||||||||||
has example aNumber > 5 | ![]() | ||||||||||||||||||||||
is a kind of condition | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java constant | is a kind of constant | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java constructor | has the same name as its class | ![]() | |||||||||||||||||||||
has example public Account(String accountHolder, float initialBalance) | ![]() | ||||||||||||||||||||||
is a kind of constructor | ![]() | ||||||||||||||||||||||
is a kind of Java method | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java data type | has part Java data type name | ![]() | |||||||||||||||||||||
is a kind of data type | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java data type name | is a kind of name | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
refers to a class if starts with a capital letter | ![]() | ||||||||||||||||||||||
refers to a primitive data type if it starts with a lower case letter | ![]() | ||||||||||||||||||||||
Java decision-making statement | is a kind of decision-making statement | ![]() | |||||||||||||||||||||
is a kind of Java statement | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java declaration | is a kind of declaration | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java | does not execute the next line of code in the program if an exception is thrown and Java looks for some code to handle the exception and executes that instead | ![]() | |||||||||||||||||||||
does not have features
| ![]() | ||||||||||||||||||||||
does not let programmers follow a invalid pointer | ![]() | ||||||||||||||||||||||
does not let programmers refer to information beyond the end of an array | ![]() | ||||||||||||||||||||||
Java else block | is a kind of Java block | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is part of Java if statement | ![]() | ||||||||||||||||||||||
can be omitted if there is nothing to do in the false case | ![]() | ||||||||||||||||||||||
Java exception | is a kind of exception | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is raised in a statement that is not in a try block with an appropriate catch statement, Java looks to see if the caller of the current method is within a try block that has an appropriate catch block, and Java look at callers right up to the main program and will report an error if it has not been able to find any suitable catch block | ![]() | ||||||||||||||||||||||
Java Gently: Programming Principles Explained | has author Judith Bishop | ![]() | |||||||||||||||||||||
has ISBN number 0-201-71050-1 | ![]() | ||||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of book about Java programming | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 2001 | ![]() | ||||||||||||||||||||||
Java identity comparison operator | is a kind of Java operator | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java if statement | has form if(condition) | ![]() | |||||||||||||||||||||
has part else block | ![]() | ||||||||||||||||||||||
is a kind of Java decision-making statement | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can omit curly brackets: if(condition)if it contains only a single statement | ![]() | ||||||||||||||||||||||
Java implements clause | has part implements | ![]() | |||||||||||||||||||||
indicates that a class contains methods for each of the operations specified by the interface | ![]() | ||||||||||||||||||||||
is a kind of Java clause | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java import statement | has example import finance.banking.accounts.*; | ![]() | |||||||||||||||||||||
has purpose to allow a class to use the facilities of another package | ![]() | ||||||||||||||||||||||
is a kind of Java statement | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java incrementer | has purpose to update a variable set in an initializer | ![]() | |||||||||||||||||||||
is a kind of Java statement | ![]() | ||||||||||||||||||||||
is part of loop | ![]() | ||||||||||||||||||||||
Java incrementor | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
Java initializer | has purpose to set up an initial condition for a loop, often initializing a variable | ![]() | |||||||||||||||||||||
is a kind of Java statement | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is part of loop | ![]() | ||||||||||||||||||||||
Java instance method | has example public float credit(float amountToCredit) | ![]() | |||||||||||||||||||||
has part return type | ![]() | ||||||||||||||||||||||
has return type void if it does not return anything | ![]() | ||||||||||||||||||||||
is a kind of instance method | ![]() | ||||||||||||||||||||||
is a kind of Java method | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can refer to the object itself using the 'this' keyword | ![]() | ||||||||||||||||||||||
may be declared public, protected or private | ![]() | ||||||||||||||||||||||
Java instance of exception class | is a kind of Java object | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is created that contains information about the problem causing the exception if an exception is raised | ![]() | ||||||||||||||||||||||
Java instance of wrapper class | contains an instance variable of the corresponding primitive data type | ![]() | |||||||||||||||||||||
is a kind of Java object | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
see also Java wrapper class | ![]() | ||||||||||||||||||||||
uses methods instead of ordinary arithmetic or logical operators | ![]() | ||||||||||||||||||||||
cannot use ordinary arithmetic or logical operators | ![]() | ||||||||||||||||||||||
Java instance variable | is a kind of instance variable | ![]() | |||||||||||||||||||||
is a kind of Java variable | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
should usually be declared private | ![]() | ||||||||||||||||||||||
Java interface | has definition In Java, a software module containing a description of a set of operations that certain classes must implement | ![]() | |||||||||||||||||||||
has example public interface Drawable | ![]() | ||||||||||||||||||||||
is a kind of interface | ![]() | ||||||||||||||||||||||
is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | ||||||||||||||||||||||
is implemented by a class | ![]() | ||||||||||||||||||||||
can be considered an extreme example of a horizontal framework: There is no implementation, and all the specified methods represent slots that must be filled | ![]() | ||||||||||||||||||||||
Java keyword | has definition A word that has special meaning in Java | ![]() | |||||||||||||||||||||
is a kind of keyword | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java logical operator | is a kind of Java operator | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
returns a boolean | ![]() | ||||||||||||||||||||||
Java method | is a kind of Java module | ![]() | |||||||||||||||||||||
is a kind of method | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
overrides a method in a superclass with the same name | ![]() | ||||||||||||||||||||||
Java method call | has example resultVariable = methodname(argument1, argument2); | ![]() | |||||||||||||||||||||
is a kind of method call | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java method call with no arguments | has example resultVariable = noArgumentMethod(); | ![]() | |||||||||||||||||||||
is a kind of Java method call | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java method | can be accessed by other methods and variables in any class in the same package by default | ![]() | |||||||||||||||||||||
should be as private as possible | ![]() | ||||||||||||||||||||||
should not be public except for those that will definitely need to be called from outside the package | ![]() | ||||||||||||||||||||||
should return to its caller from only one place which should be the last statement | ![]() | ||||||||||||||||||||||
Java module | is a kind of module | ![]() | |||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
Java name space | includes the names in the file's own package plus the names in all imported packages | ![]() | |||||||||||||||||||||
is a kind of name space | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java nested block | is a kind of Java block | ![]() | |||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
should be indented carefully | ![]() | ||||||||||||||||||||||
Java Network Programming: A Complete Guide to Networking, Streams, and Distributed Computing | has author M. Hughes, M. Shoffner and D. Hamner | ![]() | |||||||||||||||||||||
has ISBN number 1-884777-49-X | ![]() | ||||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
is an instance of book about networking | ![]() | ||||||||||||||||||||||
was published by Manning Publications | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
Java non-primitive data type | has name starting with a capital letter | ![]() | |||||||||||||||||||||
is a kind of Java data type | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java object | has example of creation String accountHolder = "Tim"; | ![]() | |||||||||||||||||||||
has example of creation Account anAccount; | ![]() | ||||||||||||||||||||||
is a kind of object | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can be converted into a string using the toString method | ![]() | ||||||||||||||||||||||
can be created by declaring and initializing it such that it is created whenever execution enters a particular block, or, in the case of an instance variable, when an instance is created or by declaring it and initializing it later using the new operator | ![]() | ||||||||||||||||||||||
can be serialized if it is an instance of a class that implements the interface java.io.Serializable, and if the data in its instance variables is also serializable | ![]() | ||||||||||||||||||||||
Java operator | is a kind of operator | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java order of operator precedence | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of rule | ![]() | ||||||||||||||||||||||
states that operators at the top take precedence over operators lower in the table. At the same level of the table, operators are evaluated from left to right.
| ![]() | ||||||||||||||||||||||
Java package | defines a name space | ![]() | |||||||||||||||||||||
has definition A collection of classes and interfaces | ![]() | ||||||||||||||||||||||
has part class in a package | ![]() | ||||||||||||||||||||||
has part Java package name | ![]() | ||||||||||||||||||||||
has purpose to group together related classes into a subsystem | ![]() | ||||||||||||||||||||||
implements subsystem | ![]() | ||||||||||||||||||||||
is a kind of Java module | ![]() | ||||||||||||||||||||||
is a kind of package^2 | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can be imported by using the import statement | ![]() | ||||||||||||||||||||||
Java package name | has example finance.banking.accounts | ![]() | |||||||||||||||||||||
is a kind of name | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is composed of a series of words separated by dots | ![]() | ||||||||||||||||||||||
should have the domain name of the organization (with the components inverted) prepended to the package name by convention to assure that each package name is unique in the world | ![]() | ||||||||||||||||||||||
Java primitive data type | has part Java primitive data type name | ![]() | |||||||||||||||||||||
is a kind of Java data type | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is normally used instead of wrapper class instances for arithmetic | ![]() | ||||||||||||||||||||||
Java primitive data type name | is a kind of name | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
starts with a lower-case letter | ![]() | ||||||||||||||||||||||
Java program | is portable because it is compiled into bytecode that can run on any computer with a VM | ![]() | |||||||||||||||||||||
is a kind of program | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java programmer | is a kind of programmer | ![]() | |||||||||||||||||||||
is a subtopic of 2.10 - Difficulties and Risks in Programming Language Choice and Object-Oriented Programming | ![]() | ||||||||||||||||||||||
should consider languages other than Java for number-crunching applications | ![]() | ||||||||||||||||||||||
should follow the specific conventions for commenting classes and methods that allow for documentation to be automatically generated using a program called 'javadoc' | ![]() | ||||||||||||||||||||||
should learn about about the different programming strategies that make a Java program run faster | ![]() | ||||||||||||||||||||||
Java programmer-created exception class | is a kind of Java exception | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java public class | is a kind of Java class | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can be accessed from outside its package | ![]() | ||||||||||||||||||||||
Java relational comparison operator | is a kind of Java operator | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java server | is a kind of server | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
receives messages from the client using an instance of InputStream | ![]() | ||||||||||||||||||||||
sends messages to the client using an instance of OutputStream | ![]() | ||||||||||||||||||||||
sends stream of information to the client | ![]() | ||||||||||||||||||||||
may send messages to Java client at any time once a connection is established | ![]() | ||||||||||||||||||||||
must have an instance of Socket class in order to exchange information with clients | ![]() | ||||||||||||||||||||||
Java source code | is a kind of source code | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is interpreted | ![]() | ||||||||||||||||||||||
is stored in files ending with the .java suffix | ![]() | ||||||||||||||||||||||
must be placed inside a class | ![]() | ||||||||||||||||||||||
Java source file | contains Java source code | ![]() | |||||||||||||||||||||
contains one class | ![]() | ||||||||||||||||||||||
is a kind of source file | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can use the import statement to use the facilities of another package | ![]() | ||||||||||||||||||||||
should declare the package to which its class belongs using the package keyword | ![]() | ||||||||||||||||||||||
Java special operator | has purpose to shorten certain expressions | ![]() | |||||||||||||||||||||
is a kind of Java operator | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java statement | is a kind of statement | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is terminated by a semicolon | ![]() | ||||||||||||||||||||||
Java string constant | is a kind of Java constant | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is defined by placing it in double quotes | ![]() | ||||||||||||||||||||||
Java subclass | is a kind of Java class | ![]() | |||||||||||||||||||||
is a kind of subclass | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is created using the extends keyword | ![]() | ||||||||||||||||||||||
Java switch statement | has form switch(primitiveVariable) | ![]() | |||||||||||||||||||||
is a kind of Java decision-making statement | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can be avoided by using polymorphism | ![]() | ||||||||||||||||||||||
Java symbol | is a kind of symbol | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java terminal I/O | has example
| ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java try catch statement | has example //Any division by zero that occurs when executing the | ![]() | |||||||||||||||||||||
is a kind of Java decision-making statement | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Java user interface component | is a kind of user interface component | ![]() | |||||||||||||||||||||
is a subtopic of 7.7 - Implementing a Simple GUI in Java | ![]() | ||||||||||||||||||||||
Java variable | is a kind of variable | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is declared by giving the data type followed by the name of the variable | ![]() | ||||||||||||||||||||||
can be accessed by other variables and methods in any class in the same package by default | ![]() | ||||||||||||||||||||||
can have an interface as its type which means that, with the variable, you can invoke any operation supported by the interface | ![]() | ||||||||||||||||||||||
Java variable declaration | has example int anInteger; | ![]() | |||||||||||||||||||||
is a kind of Java declaration | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can be placed practically anywhere in Java source code although it is good practice to only declare variables at the beginning of blocks | ![]() | ||||||||||||||||||||||
Java variable | should be as private as possible | ![]() | |||||||||||||||||||||
Java wrapper class | contains the methods parseInt, toHexString, isDigit | ![]() | |||||||||||||||||||||
contains useful class methods | ![]() | ||||||||||||||||||||||
corresponds to Java primitive data type | ![]() | ||||||||||||||||||||||
has purpose to allow you to do something with primitive values beyond what the basic operators can accomplish | ![]() | ||||||||||||||||||||||
is a kind of Java class | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
see also Java instance of wrapper class | ![]() | ||||||||||||||||||||||
java.io | has part InputStream | ![]() | |||||||||||||||||||||
has part OutputStream | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of Java package | ![]() | ||||||||||||||||||||||
java.lang | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java package | ![]() | ||||||||||||||||||||||
java.net | has purpose to permit the creation of a TCP/IP connection between two applications | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of Java package | ![]() | ||||||||||||||||||||||
javadoc | has purpose documenting Java programs | ![]() | |||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
is an instance of program | ![]() | ||||||||||||||||||||||
Javadoc pages | has URL java.sun.com/javadoc ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of web site about Java | ![]() | ||||||||||||||||||||||
JavaScript | has purpose to add functionality to web pages | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of scripting language | ![]() | ||||||||||||||||||||||
is not the same as Java | ![]() | ||||||||||||||||||||||
shares many of the same keywords with Java | ![]() | ||||||||||||||||||||||
shares much of the same syntax with Java | ![]() | ||||||||||||||||||||||
JavaWorld | has URL www.javaworld.com/javaworld ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of web site about Java | ![]() | ||||||||||||||||||||||
JITC | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an abbreviation for just-in-time compilation | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
join | has multiple incoming transitions that must be triggered in separate threads | ![]() | |||||||||||||||||||||
has one outgoing transition that will be taken when all incoming transitions have been triggered | ![]() | ||||||||||||||||||||||
has definition A symbol in an activity diagram indicating a point where several threads wait for each other. When all threads reach the join, control continues in a single thread | ![]() | ||||||||||||||||||||||
is a kind of symbol in activity diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 8.3 - Activity Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a short line at which transitions can start and end | ![]() | ||||||||||||||||||||||
Joint Application Development | has benefit the energy generated by intense JAD sessions can often shorten the period required to work out the requirements from several months to several days | ![]() | |||||||||||||||||||||
has definition An approach to defining requirements, in which all the stakeholders meet intensively for several days in a secluded location | ![]() | ||||||||||||||||||||||
has result a written requirements document | ![]() | ||||||||||||||||||||||
involves developers meeting with customers and users in a secluded location for a period of three to five days to define the requirements | ![]() | ||||||||||||||||||||||
is a kind of requirements gathering | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
is abbreviated as JAD | ![]() | ||||||||||||||||||||||
is related to brainstorming | ![]() | ||||||||||||||||||||||
takes place away from the offices of any of the participants so that nobody is interrupted by any other activity | ![]() | ||||||||||||||||||||||
may include regular brainstorming, and negotiation of specific wording | ![]() | ||||||||||||||||||||||
just-in-time compilation | has definition A kind of compilation that converts a method into machine code the first time it is executed and stores the machine code to save work on subsequent calls | ![]() | |||||||||||||||||||||
is a kind of compilation | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is abbreviated as JITC | ![]() | ||||||||||||||||||||||
keeping the level of abstraction high | has advantage it allows you to understand the essence of a subsystem and make important decisions without knowing unnecessary details | ![]() | |||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is an instance of design principle | ![]() | ||||||||||||||||||||||
kernel layer | handles such functions as process creation, swapping and scheduling | ![]() | |||||||||||||||||||||
is a kind of layer | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
keyword | is a kind of programming language construct | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
known bugs list | has definition A list of defects in a system that have not yet been fixed | ![]() | |||||||||||||||||||||
is a kind of document | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
label | is a kind of name | ![]() | |||||||||||||||||||||
is a subtopic of 5.4 - Generalization | ![]() | ||||||||||||||||||||||
language | is a kind of representation | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
see also language^2 | ![]() | ||||||||||||||||||||||
language^2 | has definition In the context of a client-server system, the messages that can be sent from one computer to another | ![]() | |||||||||||||||||||||
is a kind of language | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
see also language | ![]() | ||||||||||||||||||||||
large software development team | is a kind of software development team | ![]() | |||||||||||||||||||||
is a subtopic of 11.4 - Building Software Engineering Teams | ![]() | ||||||||||||||||||||||
can make development more complex and lead to designs that have higher coupling | ![]() | ||||||||||||||||||||||
large software project | is a kind of software project | ![]() | |||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
may be divided into many smaller software projects | ![]() | ||||||||||||||||||||||
large software system | has requirements document for a large system | ![]() | |||||||||||||||||||||
is hard to understand | ![]() | ||||||||||||||||||||||
is a kind of software system | ![]() | ||||||||||||||||||||||
is a subtopic of 1.2 - What is Software Engineering? | ![]() | ||||||||||||||||||||||
requires a software architecture^3 | ![]() | ||||||||||||||||||||||
cannot be understood by one person | ![]() | ||||||||||||||||||||||
must be developed by a software development team | ![]() | ||||||||||||||||||||||
must be developed using engineering discipline | ![]() | ||||||||||||||||||||||
large-scale change to system | is a kind of change | ![]() | |||||||||||||||||||||
is a subtopic of 4.9 - Managing Changing Requirements | ![]() | ||||||||||||||||||||||
must be carefully assessed before going ahead | ![]() | ||||||||||||||||||||||
late binding | is a synonym of dynamic binding | ![]() | |||||||||||||||||||||
law | has localization issues
| ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
law of conservation of bugs | is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | |||||||||||||||||||||
is an instance of rule | ![]() | ||||||||||||||||||||||
states the number of bugs remaining in a large system is proportional to the number of bugs already fixed | ![]() | ||||||||||||||||||||||
Law of Demeter | is a subtopic of 6.7 - The Delegation Pattern | ![]() | |||||||||||||||||||||
is an instance of rule | ![]() | ||||||||||||||||||||||
means that a method should only access data passed as arguments, linked via associations, or obtained via calls to operations on other neighbouring data in the context of software design | ![]() | ||||||||||||||||||||||
states only talk to your immediate friends | ![]() | ||||||||||||||||||||||
was formulated by a team from Northeastern University in Boston | ![]() | ||||||||||||||||||||||
should make incremental development much easier | ![]() | ||||||||||||||||||||||
layer | communicates using procedure calls or by inter-process communication where the lower layers can become servers and the higher layers can become clients | ![]() | |||||||||||||||||||||
has definition A subsystem that provides a set of services and has layer cohesion | ![]() | ||||||||||||||||||||||
has example The set of related services which could form a layer might include:
| ![]() | ||||||||||||||||||||||
has well-defined interface that is used by layer immediately above | ![]() | ||||||||||||||||||||||
is a kind of component | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is often divided into smaller subsystems | ![]() | ||||||||||||||||||||||
is part of multi-layer system | ![]() | ||||||||||||||||||||||
only communicates with the layer immediately below it | ![]() | ||||||||||||||||||||||
sees a lower layer as a set of services it can use | ![]() | ||||||||||||||||||||||
layer cohesion | allows side-effects | ![]() | |||||||||||||||||||||
has definition A form of cohesion in which the facilities for providing or accessing a set of services through an API or hardware interface are kept together. There must also be a strict hierarchy in which higher level layers can access only lower-level layers. In other words, the system is effectively divided into layers | ![]() | ||||||||||||||||||||||
has example The set of related services which could form a layer might include:
| ![]() | ||||||||||||||||||||||
is a kind of cohesion | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
requires that the layers must form a hierarchy - higher layers can access services of lower layers, but it is essential that the lower layers do not access higher layers | ![]() | ||||||||||||||||||||||
simplifies systems | ![]() | ||||||||||||||||||||||
layer | usually provides services through an API | ![]() | |||||||||||||||||||||
leaf class | has definition A class at the very bottom of an inheritance hierarchy | ![]() | |||||||||||||||||||||
is a kind of concrete class | ![]() | ||||||||||||||||||||||
is a subtopic of 2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarations | ![]() | ||||||||||||||||||||||
learnability | has definition The speed with which a new user can become proficient with the system | ![]() | |||||||||||||||||||||
has example a user might be able to learn the most important 20% of the system in 3 days if the system is simple and intuitive; 7 days if the system is simple but non-intuitive, and 11 days if the system is complex and non-intuitive | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is concerned with ordinary use | ![]() | ||||||||||||||||||||||
is reduced by information overload | ![]() | ||||||||||||||||||||||
measures how fast a new user can learn the system | ![]() | ||||||||||||||||||||||
can be described in terms of learning curves | ![]() | ||||||||||||||||||||||
can be improved by having fewer things to learn, or by making the learning process more intuitive | ![]() | ||||||||||||||||||||||
learning curve | describes the learnability of software | ![]() | |||||||||||||||||||||
has definition A curve on a diagram that plots the time spent learning on one axis, and the amount of functionality learned on the other axis | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
legacy system | has definition A software system which is still undergoing evolution, but on which some or all of the original developers are no longer working | ![]() | |||||||||||||||||||||
is a kind of software system | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
level 1 test case | is the most important | ![]() | |||||||||||||||||||||
is a kind of test case | ![]() | ||||||||||||||||||||||
is a subtopic of 10.8 - Writing Formal Test Cases and Test Plans | ![]() | ||||||||||||||||||||||
verifies that the system runs and is safe | ![]() | ||||||||||||||||||||||
level 2 test case | is a kind of test case | ![]() | |||||||||||||||||||||
is a subtopic of 10.8 - Writing Formal Test Cases and Test Plans | ![]() | ||||||||||||||||||||||
verifies that the system performs its day-to-day functions correctly and is therefore a 'success' | ![]() | ||||||||||||||||||||||
level 3 test case | is the least important | ![]() | |||||||||||||||||||||
is a kind of test case | ![]() | ||||||||||||||||||||||
is a subtopic of 10.8 - Writing Formal Test Cases and Test Plans | ![]() | ||||||||||||||||||||||
verifies that requirements of lesser importance are correct | ![]() | ||||||||||||||||||||||
can provide some redundancy - for example extra testing of additional combinations of input | ![]() | ||||||||||||||||||||||
license | has definition A legal document authorizing the holder to perform some activity | ![]() | |||||||||||||||||||||
is a kind of document | ![]() | ||||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
lifeline | becomes an activation box during the period of time that the object is performing computations | ![]() | |||||||||||||||||||||
has definition A dashed line in a sequence diagram indicating the period of time during which an object exists | ![]() | ||||||||||||||||||||||
is a kind of symbol in sequence diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
is attached to each object or actor in a sequence diagram | ![]() | ||||||||||||||||||||||
is drawn as a vertical dashed line | ![]() | ||||||||||||||||||||||
link | connects two objects - an instance of each of the two classes involved in the association | ![]() | |||||||||||||||||||||
has definition A reference from one object to another | ![]() | ||||||||||||||||||||||
is a kind of data abstraction | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is an instance of association | ![]() | ||||||||||||||||||||||
is drawn as a line connecting two objects in a UML instance diagram | ![]() | ||||||||||||||||||||||
never has multiplicity symbols | ![]() | ||||||||||||||||||||||
LinkedList | is less efficient than ArrayList and Vector for operations such as extracting an arbitrary element | ![]() | |||||||||||||||||||||
is more efficient than ArrayList and Vector for operations such as inserting an element in the middle | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java collection class | ![]() | ||||||||||||||||||||||
list | is a kind of user interface component | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
listening | has definition A state in which a server is waiting for clients to connect | ![]() | |||||||||||||||||||||
is a kind of state | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
live activation | has definition The period of time when an object is performing work | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
livelock | has definition A failure in which a system can never get out of a limited set of states, although it is not in deadlock | ![]() | |||||||||||||||||||||
is a kind of deadlock or livelock | ![]() | ||||||||||||||||||||||
is a subtopic of 10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races | ![]() | ||||||||||||||||||||||
can appear as a hung system where the system is still consuming CPU time | ![]() | ||||||||||||||||||||||
may not hang a system | ![]() | ||||||||||||||||||||||
loading to and saving from persistent storage | is a kind of responsibility | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is often omitted from from a model because the presence of such responsibilities can largely be inferred from the class diagram | ![]() | ||||||||||||||||||||||
locale | has definition An environment where the language, culture, laws, currency and many other factors may be different | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
Locale class | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of Java class | ![]() | ||||||||||||||||||||||
is used to format numbers | ![]() | ||||||||||||||||||||||
locale-dependent feature | has localization issues | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
localhost | has definition A special host name that always refers to the current computer | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of host name | ![]() | ||||||||||||||||||||||
localization | has definition The process of adapting a system to a particular locale | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
locking | has definition A mechanism for reserving a resource so as to avoid inappropriate concurrent access | ![]() | |||||||||||||||||||||
is a kind of practice | ![]() | ||||||||||||||||||||||
is a subtopic of 10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races | ![]() | ||||||||||||||||||||||
can prevent critical races | ![]() | ||||||||||||||||||||||
can slow performance since it takes a lot of extra work to manipulate and check the locks | ![]() | ||||||||||||||||||||||
may use a mechanism such as semaphores | ![]() | ||||||||||||||||||||||
long | is a kind of Java primitive data type | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
requires 64 bits | ![]() | ||||||||||||||||||||||
stores an integer | ![]() | ||||||||||||||||||||||
long method | contains more than 20 lines of code | ![]() | |||||||||||||||||||||
is a kind of method | ![]() | ||||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
should be avoided | ![]() | ||||||||||||||||||||||
should be divided into shorter methods | ![]() | ||||||||||||||||||||||
long statement | is a kind of statement | ![]() | |||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
should be divided into multiple lines such that the second and subsequent lines begin with an operator and are indented | ![]() | ||||||||||||||||||||||
long^2 | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
look and feel | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
is standardized for each operating system | ![]() | ||||||||||||||||||||||
loop | has identical syntax in Java, C and C++ | ![]() | |||||||||||||||||||||
has part condition | ![]() | ||||||||||||||||||||||
is a kind of statement | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
low coupling | has definition A kind of coupling in which the interconnections among parts of a system are reduced, making makes the resulting application easier to understand, modify and test | ![]() | |||||||||||||||||||||
is a kind of coupling | ![]() | ||||||||||||||||||||||
is a subtopic of 3.2 - Incorporating Reusability and Reuse Into Software Engineering | ![]() | ||||||||||||||||||||||
low maintainability | is a kind of maintainability | ![]() | |||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
may be caused by a highly efficient design that is hard to understand | ![]() | ||||||||||||||||||||||
may cause defects that reduce reliability | ![]() | ||||||||||||||||||||||
low reliability | is a kind of reliability | ![]() | |||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
may be caused by low maintainability | ![]() | ||||||||||||||||||||||
machine code | is a kind of code | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
magazine | is a kind of publication | ![]() | |||||||||||||||||||||
maintainability | describes the ease with which the software can be changed | ![]() | |||||||||||||||||||||
has definition An important quality of software that measures the extent to which the software can be modified at the lowest possible cost | ![]() | ||||||||||||||||||||||
is a kind of external software quality | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
is affected by commenting | ![]() | ||||||||||||||||||||||
is affected by complexity of code | ![]() | ||||||||||||||||||||||
is constrained by software architecture | ![]() | ||||||||||||||||||||||
is increased by the use of modularity | ![]() | ||||||||||||||||||||||
can reduce costs for both developers and customers | ![]() | ||||||||||||||||||||||
maintenance | has definition In the context of software, any process involving modifying software following its general release to users | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
is part of software engineering | ![]() | ||||||||||||||||||||||
maintenance project | is a kind of synonym | ![]() | |||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
is a synonym for evolutionary project | ![]() | ||||||||||||||||||||||
many | is a kind of multiplicity | ![]() | |||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is drawn as a star in a UML diagram | ![]() | ||||||||||||||||||||||
means any integer greater than or equal to zero | ![]() | ||||||||||||||||||||||
many-to-many | has example A secretary can work for many managers, and a manager can have many secretaries | ![]() | |||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is an instance of multiplicity pattern | ![]() | ||||||||||||||||||||||
many-to-many association | is a kind of association | ![]() | |||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
many-to-one | has example A company has many employees, but an employee can only work for one company | ![]() | |||||||||||||||||||||
is the most common multiplicity pattern | ![]() | ||||||||||||||||||||||
is the same as one-to-many | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is an instance of multiplicity pattern | ![]() | ||||||||||||||||||||||
many-to-one association | is a kind of association | ![]() | |||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
Mastering the Requirements Process | has author S. Robertson, J. Robertson | ![]() | |||||||||||||||||||||
has ISBN number 0-201-36046-2 | ![]() | ||||||||||||||||||||||
is a subtopic of 4.13 - Developing Requirements - References | ![]() | ||||||||||||||||||||||
is an instance of book about requirements analysis | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
measurement | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
mechanical engineering | is a kind of engineering | ![]() | |||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
mechanism | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
memory leak | has definition A situation in which a program requests memory but does not release it when it is no longer needed | ![]() | |||||||||||||||||||||
is a kind of inappropriate management of resources | ![]() | ||||||||||||||||||||||
is a subtopic of 10.6 - Defects in Handling Stress and Unusual Situations | ![]() | ||||||||||||||||||||||
can be detected by running a program for an extended period, and using a utility that indicates the amount of memory being used | ![]() | ||||||||||||||||||||||
can cause a computer to perform poorly or even run out of memory | ![]() | ||||||||||||||||||||||
can occur in programs written in C, C++ and certain other languages | ![]() | ||||||||||||||||||||||
mentor | is a kind of software developer | ![]() | |||||||||||||||||||||
is a subtopic of 1.9 - Difficulties And Risks In Software Engineering as a Whole | ![]() | ||||||||||||||||||||||
menu | is a kind of user interface component | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
message | has definition Any information sent as a component interacts with another, including using procedure calls, or network communication | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
can be represented by a message in sequence diagram | ![]() | ||||||||||||||||||||||
message in collaboration diagram | are ordered by a numbering scheme to indicate the order in which messages are sent | ![]() | |||||||||||||||||||||
is a kind of symbol in collaboration diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
is drawn as an arrow, labelled with the message name and optional arguments | ![]() | ||||||||||||||||||||||
message in interaction diagram | is a kind of symbol in interaction diagram | ![]() | |||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
message in sequence diagram | has optional part an argument list and a response | ![]() | |||||||||||||||||||||
has part label | ![]() | ||||||||||||||||||||||
has syntax response:=message(arg,...) | ![]() | ||||||||||||||||||||||
is a kind of symbol in sequence diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
is drawn as an arrow between activation boxes of the sender and receiver | ![]() | ||||||||||||||||||||||
is drawn as an arrow from actor to object, , or from object to object | ![]() | ||||||||||||||||||||||
metaphor | has localization issues
| ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
method | has definition A concrete implementation of an operation; a procedure in a class | ![]() | |||||||||||||||||||||
is equivalent to the terms "function member" or "member function" which are used in C++ | ![]() | ||||||||||||||||||||||
is equivalent to the terms "routine", "function" or "procedure" which are used in non object oriented languages | ![]() | ||||||||||||||||||||||
is a kind of procedural abstraction | ![]() | ||||||||||||||||||||||
is a kind of procedure | ![]() | ||||||||||||||||||||||
is a subtopic of 2.4 - Methods, Operations and Polymorphism | ![]() | ||||||||||||||||||||||
method call | is a kind of message | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
method | should have a comment at its head if the method is non-obvious | ![]() | |||||||||||||||||||||
methodology | describes detailed sequences of steps for performing analysis and design | ![]() | |||||||||||||||||||||
has definition A description of a process; it usually prescribes how to do things in a step by step manner | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
is often supported by tools developed by the author of the process, or others | ![]() | ||||||||||||||||||||||
usually describes aspects of project management | ![]() | ||||||||||||||||||||||
usually requires the use of a particular notation and the production of documentation in particular formats | ![]() | ||||||||||||||||||||||
metric | has definition A scale on which a software product or process may be measured | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
Microsoft Java tools | has URL microsoft.com/java ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of programming environment | ![]() | ||||||||||||||||||||||
milestone | has definition An important deadline date, at which a specific event may occur, and when a specific deliverable may be required | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 11.5 - Project Scheduling and Tracking | ![]() | ||||||||||||||||||||||
is drawn as a diamond in a Gantt chart | ![]() | ||||||||||||||||||||||
mistake | is a kind of problem | ![]() | |||||||||||||||||||||
is a subtopic of 10.1 - Basic Definitions | ![]() | ||||||||||||||||||||||
mixed testing | is a synonym of sandwich testing | ![]() | |||||||||||||||||||||
mobility impaired user | is a kind of user with a disability | ![]() | |||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
may not be able to use a mouse or keyboard | ![]() | ||||||||||||||||||||||
may prefer to use voice input | ![]() | ||||||||||||||||||||||
modal dialog | has definition A dialog that the user must dismiss before interacting with any other window | ![]() | |||||||||||||||||||||
is a kind of dialog | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
limits the user's options | ![]() | ||||||||||||||||||||||
prevents the user from interacting with any other window until he or she has dismissed the modal dialog | ![]() | ||||||||||||||||||||||
should be avoided because it forces the user to constantly press 'OK' or 'Cancel' to move on to the next step | ![]() | ||||||||||||||||||||||
mode | has definition A state in which the UI restricts the affordance | ![]() | |||||||||||||||||||||
has example if a dialog appears saying 'Do you really want to delete a file?' and all the user can do is click 'Cancel' or 'OK', then the system is in a mode | ![]() | ||||||||||||||||||||||
is a kind of state | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
model | becomes the core of documentation describing the system | ![]() | |||||||||||||||||||||
has definition An abstract representation of a system, that conveys a certain aspect of it in an understandable and analyzable way | ![]() | ||||||||||||||||||||||
is crucial in software development | ![]() | ||||||||||||||||||||||
is a kind of representation | ![]() | ||||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
is used to describe a software system | ![]() | ||||||||||||||||||||||
is used to validate a software system | ![]() | ||||||||||||||||||||||
see also model^2 | ![]() | ||||||||||||||||||||||
will contain classes from the original system if the system is an extension to an existing system | ![]() | ||||||||||||||||||||||
will contain many classes from the framework if the system is being built using a framework | ![]() | ||||||||||||||||||||||
should be understandable by clients and users so they can participate in the development process as much as possible | ![]() | ||||||||||||||||||||||
should be properly reviewed | ![]() | ||||||||||||||||||||||
should provide abstraction so that not all details are visible at once | ![]() | ||||||||||||||||||||||
should provide insights about the system when software engineers analyze it | ![]() | ||||||||||||||||||||||
should use a standard notation such as UML so that everybody who looks at it will interpret it the same way | ![]() | ||||||||||||||||||||||
Model-View-Controller | facilitates divide-and-conquer because the three components can be independently designed | ![]() | |||||||||||||||||||||
has definition A architectural pattern used to separate the functional layer of the system (the model) from two aspects of the user interface, the view and the controller | ![]() | ||||||||||||||||||||||
increases cohesion because the components have stronger layer cohesion than if the view and controller were together in a single UI layer | ![]() | ||||||||||||||||||||||
increases flexibility because it is usually quite easy to change the UI by changing the view, the controller, or both | ![]() | ||||||||||||||||||||||
increases layer cohesion of the user interface layer | ![]() | ||||||||||||||||||||||
increases reuse because the view and controller normally make extensive use of reusable components for various kinds of UI controls | ![]() | ||||||||||||||||||||||
is a kind of software architecture | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
is abbreviated as MVC | ![]() | ||||||||||||||||||||||
is related to the multi-layer architecture | ![]() | ||||||||||||||||||||||
reduces coupling because the communication channels between the three components are minimal and easy to find | ![]() | ||||||||||||||||||||||
reduces the coupling between the user interface layer and the rest of the system, as well as between different aspects of the UI itself | ![]() | ||||||||||||||||||||||
separates the functional layer of the system (the model) from two aspects of the user interface, the view and the controller | ![]() | ||||||||||||||||||||||
model^2 | contains contains the underlying classes whose instances are to be viewed and manipulated | ![]() | |||||||||||||||||||||
has definition The functional layer in the MVC architectural pattern - the underlying classes whose instances are to be viewed and manipulated | ![]() | ||||||||||||||||||||||
is a kind of layer | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
see also model | ![]() | ||||||||||||||||||||||
uses the observer design pattern to separate it from the view | ![]() | ||||||||||||||||||||||
does not know what view and controller are attached to it | ![]() | ||||||||||||||||||||||
Modeling Reactive Systems with Statecharts: The STATEMATE Approach | has author D. Harel and M. Politi | ![]() | |||||||||||||||||||||
has ISBN number 0-07-026205-5 | ![]() | ||||||||||||||||||||||
has URL www.wisdom.weizmann.ac.il/~harel/books/stm.html ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 8.5 - Modelling Interactions and Behaviour - References | ![]() | ||||||||||||||||||||||
is an instance of book about modelling interactions and behaviour | ![]() | ||||||||||||||||||||||
was published by McGraw-Hill | ![]() | ||||||||||||||||||||||
was published in 1998 | ![]() | ||||||||||||||||||||||
modeller | is a kind of software developer | ![]() | |||||||||||||||||||||
is a subtopic of 5.10 - Difficulties and Risks When Creating Class Diagrams | ![]() | ||||||||||||||||||||||
performs modelling | ![]() | ||||||||||||||||||||||
modelling | has definition The process of creating a model | ![]() | |||||||||||||||||||||
is a particularly difficult skill | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
is not emphasized as part of education programs | ![]() | ||||||||||||||||||||||
can be performed using
| ![]() | ||||||||||||||||||||||
modelling language | is a kind of language | ![]() | |||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
modelling | may be used during design | ![]() | |||||||||||||||||||||
may be used during requirements analysis | ![]() | ||||||||||||||||||||||
may use diagrams | ![]() | ||||||||||||||||||||||
may use formal languages | ![]() | ||||||||||||||||||||||
moderator | has definition A person who leads a brainstorming session | ![]() | |||||||||||||||||||||
is a kind of person | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
is a synonym of facilitator | ![]() | ||||||||||||||||||||||
may participate in brainstorming discussions if he or she wishes | ![]() | ||||||||||||||||||||||
modified software | is a kind of software | ![]() | |||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
may have to be completely redesigned after many changes to it have caused it to deteriorate significantly | ![]() | ||||||||||||||||||||||
modularity | contributes to maintainability | ![]() | |||||||||||||||||||||
has definition The extent to which software is divided into components, called modules, which have high internal cohesion, low coupling between each other, and simple interfaces | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 2.7 - Concepts that Define Object Orientation | ![]() | ||||||||||||||||||||||
module | has definition A component that is defined at the programming language level, such as file, method or package | ![]() | |||||||||||||||||||||
has high cohesion if related aspects of a system are kept together in this module, and unrelated aspects are kept out | ![]() | ||||||||||||||||||||||
is a kind of component | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
is implemented | ![]() | ||||||||||||||||||||||
lacks side effects if it does not modify any data, and does not leave behind any information, other than its result, that would have an effect on other computations | ![]() | ||||||||||||||||||||||
multi-layer | allows replacement of a layer by an improved version, or by one with a different set of capabilities | ![]() | |||||||||||||||||||||
anticipates obsolescence: databases and UI systems tend to change; by isolating these in separate layers, the system becomes more resistant to obsolescence | ![]() | ||||||||||||||||||||||
facilitates designing for portability because all the facilities that are dependent on a particular platform can be isolated in one of the lower layers | ![]() | ||||||||||||||||||||||
facilitates designing for testability because individual layers, particularly the UI layer, database layer and communications layer, can be tested independently | ![]() | ||||||||||||||||||||||
facilitates divide and conquer since the separate layers can be independently designed | ![]() | ||||||||||||||||||||||
has definition An architectural pattern in which a system is divided into layers | ![]() | ||||||||||||||||||||||
increases abstraction because when you design the higher layers, you do not need to know the details of how the lower layers are implemented | ![]() | ||||||||||||||||||||||
increases cohesion by facilitating independent designing of layers | ![]() | ||||||||||||||||||||||
increases reusability because the lower layers can often be designed generically so that they can be used to provide the same services for different systems | ![]() | ||||||||||||||||||||||
is a kind of architectural pattern | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
is used to build a multi-layer system | ![]() | ||||||||||||||||||||||
reduces coupling since well-designed lower layers do not know about the higher layers | ![]() | ||||||||||||||||||||||
can be used to produce a complex system can be built by superposing layers at increasing levels of abstraction | ![]() | ||||||||||||||||||||||
multi-layer system | contains
| ![]() | |||||||||||||||||||||
contains layers with each layer communicating only with the layer immediately below it | ![]() | ||||||||||||||||||||||
has part layer | ![]() | ||||||||||||||||||||||
is a kind of software system | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
uses multi-layer architectural pattern | ![]() | ||||||||||||||||||||||
multiobject | has definition A symbol in an interaction diagram showing several overlapping objects, which are the target of a set of messages defined by an iteration expression | ![]() | |||||||||||||||||||||
is a kind of symbol in interaction diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
is drawn as overlapping rectangles | ![]() | ||||||||||||||||||||||
represents the presence of multiple similar objects | ![]() | ||||||||||||||||||||||
multiple inheritance | has definition Inheritance from more than one superclass | ![]() | |||||||||||||||||||||
is a kind of inheritance | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can be avoided by using the player-role pattern | ![]() | ||||||||||||||||||||||
can result in more complex systems than single inheritance | ![]() | ||||||||||||||||||||||
should be avoided if possible | ![]() | ||||||||||||||||||||||
multiplicity | has definition Information placed at each end of an association indicating how many instances of one class can be related to instances of the other class | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is drawn as a range separated by two dots (e.g. 2..3) in a UML class diagram | ![]() | ||||||||||||||||||||||
can be written as a specific positive integer or as several multiplicity values or ranges separated by commas | ![]() | ||||||||||||||||||||||
multiplicity pattern | is a kind of pattern | ![]() | |||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
multiplicity | should be as least restrictive as possible so as not to reduce the flexibility of the system | ![]() | |||||||||||||||||||||
multiplicity symbol | is a kind of symbol in UML diagram | ![]() | |||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
music | has advantages
| ![]() | |||||||||||||||||||||
has problems
| ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
MVC | is a subtopic of 9.5 - Architectural Patterns | ![]() | |||||||||||||||||||||
is an abbreviation for Model-View-Controller | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
name | is a kind of representation | ![]() | |||||||||||||||||||||
name space | is a kind of programming language construct | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
Napster | is an instance of peer-to-peer system | ![]() | |||||||||||||||||||||
NASA's Guide to Software Quality Assurance | has URL satc.gsfc.nasa.gov/assure/assuregb.html ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of web site about software quality assurance | ![]() | ||||||||||||||||||||||
NASA's Software Assurance Technology Centre | has URL satc.gsfc.nasa.gov ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of web site about software quality assurance | ![]() | ||||||||||||||||||||||
National Society of Professional Engineers (US) | has URL www.nspe.org ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of engineering web site | ![]() | ||||||||||||||||||||||
native | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
navigating and searching | is a kind of responsibility | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
nesting | is a kind of practice | ![]() | |||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
should not be allowed to too many levels | ![]() | ||||||||||||||||||||||
Netscape's Software Engineering site | has URL directory.netscape.com/browse.psp?cp=nrpuswscwsc&id=5445 ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of software engineering web site | ![]() | ||||||||||||||||||||||
netstat | has example netstat -a -p TCP | ![]() | |||||||||||||||||||||
has purpose to find out which ports are in use | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of Windows command | ![]() | ||||||||||||||||||||||
network file system | has clients programs on any computer that access files that happen to be on other computers | ![]() | |||||||||||||||||||||
has server a program whose main purpose is to allow clients on other computers to access files such as Unix NFS and Novel NetWare | ![]() | ||||||||||||||||||||||
is a kind of client-server system | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
new | has purpose to create new objects | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
is an instance of Java operator | ![]() | ||||||||||||||||||||||
newsgroup | is a kind of publication | ![]() | |||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
non-functional requirement | describes a constraint that must be adhered to during development | ![]() | |||||||||||||||||||||
has definition A requirement that constrains design of a system, but does not describe a service that the system is to provide | ![]() | ||||||||||||||||||||||
is a kind of requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
restricts the freedom of software engineers as they make design decisions because it limits what resources can be used and sets bounds on aspects of the software's quality | ![]() | ||||||||||||||||||||||
must be verifiable by measuring various aspects of the system and seeing if the measurements conform with the requirement | ![]() | ||||||||||||||||||||||
non-functional requirements | describes constraints that must be adhered to during development | ![]() | |||||||||||||||||||||
is a kind of requirements document | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
non-modal dialog | allows the user to choose the sequence in which they work | ![]() | |||||||||||||||||||||
has definition A separate window that the user can choose to interact with, but does not have to | ![]() | ||||||||||||||||||||||
is a kind of dialog | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
non-singleton condition | is the inverse of singleton condition | ![]() | |||||||||||||||||||||
is a kind of situation | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
occurs when there is almost always one of something, but occasionally there can be more than one | ![]() | ||||||||||||||||||||||
not handling null conditions | has definition A common defect in which a program behaves abnormally when a null condition is encountered | ![]() | |||||||||||||||||||||
has testing strategy determine all possible null conditions and run test cases that would highlight any inappropriate behaviour | ![]() | ||||||||||||||||||||||
is a kind of defect in an ordinary algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
not handling singleton or non-singleton conditions | has definition A common defect in which a program does not properly handle singleton conditions or non-singleton conditions | ![]() | |||||||||||||||||||||
has testing strategy brainstorm to determine unusual conditions and run appropriate tests | ![]() | ||||||||||||||||||||||
is a kind of defect in an ordinary algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
not setting up the correct preconditions for an algorithm | has definition A common defect in which a program proceeds to do its work even when specifies preconditions, that state what must be true before the algorithm should be executed, are not satisfied | ![]() | |||||||||||||||||||||
has testing strategy run test cases in which each precondition is not satisfied - preferably its input values are just beyond what the algorithm can accept | ![]() | ||||||||||||||||||||||
is a kind of defect in an ordinary algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
not terminating a loop or recursion | has definition A common defect in which a loop or a recursion does not always terminate, i.e. it is 'infinite' | ![]() | |||||||||||||||||||||
has testing strategy
| ![]() | ||||||||||||||||||||||
is a kind of defect in an ordinary algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
not using enough bits or digits to store maximum values | has testing strategy test using very large numbers to ensure the system has a wide enough margin of error | ![]() | |||||||||||||||||||||
is a kind of defect in a numerical algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.4 - Defects in Numerical Algorithms | ![]() | ||||||||||||||||||||||
not using enough places after the decimal point | forces the system to round excessively, which can mean that data is stored inaccurately and can also lead to a build-up of errors | ![]() | |||||||||||||||||||||
has testing strategy perform calculations that involve many significant figures, and large differences in magnitude | ![]() | ||||||||||||||||||||||
is a kind of defect in a numerical algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.4 - Defects in Numerical Algorithms | ![]() | ||||||||||||||||||||||
not using enough significant figures | forces the system to round excessively, which can mean that data is stored inaccurately and can also lead to a build-up of errors | ![]() | |||||||||||||||||||||
has testing strategy perform calculations that involve many significant figures, and large differences in magnitude | ![]() | ||||||||||||||||||||||
is a kind of defect in a numerical algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.4 - Defects in Numerical Algorithms | ![]() | ||||||||||||||||||||||
note | has definition A small block of text embedded in a UML diagram | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
noun phrase | has definition A string of nouns, or a noun modified by one or more adjectives | ![]() | |||||||||||||||||||||
has example "small shiny car door handle" | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
novice programmer | is a kind of programmer | ![]() | |||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
can create a complex system that performs some useful function but is highly disorganized in terms of its design | ![]() | ||||||||||||||||||||||
null | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
null condition | has definition A situation where there normally exists one or more data items to process, but sometimes there are none | ![]() | |||||||||||||||||||||
is a kind of situation | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
number format | is a kind of locale-dependent feature | ![]() | |||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
number of bugs | is proportional to the number of bugs remaining | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 10.13 - Difficulties and Risks in Quality Assurance | ![]() | ||||||||||||||||||||||
number of completed use cases | indicates the progress of a project's development | ![]() | |||||||||||||||||||||
is a kind of number of use cases | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
number of defects found when inspecting a product | is a kind of measurement | ![]() | |||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
number of failures encountered by users | is a kind of measurement | ![]() | |||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
number of failures found when testing a product | is a kind of measurement | ![]() | |||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
number of questions posed by users to the help desk | is a kind of measurement | ![]() | |||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
number of use cases | indicates a project's complexity | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
object | has live activation while the object is performing computations in a sequence diagram | ![]() | |||||||||||||||||||||
has behaviour | ![]() | ||||||||||||||||||||||
has definition A data element in an object-oriented system, which has its own identity, belongs to a particular class, and has behaviour and properties | ![]() | ||||||||||||||||||||||
has state | ![]() | ||||||||||||||||||||||
has synonym instance: instance is used when you are talking about the role with respect to the class and object is used when talking in a more general way | ![]() | ||||||||||||||||||||||
is distinct from every other object even if they contain the same data | ![]() | ||||||||||||||||||||||
is in a state until an event occurs that causes it to change state | ![]() | ||||||||||||||||||||||
is a kind of data item | ![]() | ||||||||||||||||||||||
is a subtopic of 2.1 - What is Object Orientation? | ![]() | ||||||||||||||||||||||
is a synonym of instance | ![]() | ||||||||||||||||||||||
is drawn as a rectangle containing a colon and the underlined name of the class (optional if it is clear from the context), which may be preceded by an optional instance name in a UML instance diagram | ![]() | ||||||||||||||||||||||
is structured | ![]() | ||||||||||||||||||||||
can be referred to by several different variables at the same time | ![]() | ||||||||||||||||||||||
can be referred to without reference to the data (instance variables) contained in it | ![]() | ||||||||||||||||||||||
can represent any entity to which you can associate properties and behaviour | ![]() | ||||||||||||||||||||||
Object Constraint Language | contains many built-in keywords designed to formally specify constraints in software models | ![]() | |||||||||||||||||||||
has definition A language used to write Boolean constraints and assertions in UML | ![]() | ||||||||||||||||||||||
is the recommended language for writing constraints in a UML diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
is abbreviated as OCL | ![]() | ||||||||||||||||||||||
is an instance of specification language | ![]() | ||||||||||||||||||||||
is not related to Java | ![]() | ||||||||||||||||||||||
see also OCL expression | ![]() | ||||||||||||||||||||||
see also OCL statement | ![]() | ||||||||||||||||||||||
Object Lifecycles: Modelling the World in States | has author S. Shlaer, and S. Mellor | ![]() | |||||||||||||||||||||
has ISBN number 0-13-629940-7 | ![]() | ||||||||||||||||||||||
is a subtopic of 8.5 - Modelling Interactions and Behaviour - References | ![]() | ||||||||||||||||||||||
is an instance of book about modelling interactions and behaviour | ![]() | ||||||||||||||||||||||
was published by Yourdon Press | ![]() | ||||||||||||||||||||||
was published in 1992 | ![]() | ||||||||||||||||||||||
object orientation | has definition A near-synonym for the object-oriented paradigm | ![]() | |||||||||||||||||||||
is a kind of paradigm | ![]() | ||||||||||||||||||||||
is a subtopic of 2.1 - What is Object Orientation? | ![]() | ||||||||||||||||||||||
Object Oriented Analysis | has author P. Coad and E. Yourdon | ![]() | |||||||||||||||||||||
object oriented analysis | has definition The process of deciding which classes will be important to the users, and working out the structure, relationships and behaviour of these classes | ![]() | |||||||||||||||||||||
Object Oriented Analysis | has ISBN number | ![]() | |||||||||||||||||||||
object oriented analysis | is a kind of analysis | ![]() | |||||||||||||||||||||
is a subtopic of 2.2 - Classes and Objects | ![]() | ||||||||||||||||||||||
Object Oriented Analysis | is a subtopic of 5.11 - Modelling With Classes - References | ![]() | |||||||||||||||||||||
object oriented analysis | is abbreviated as OOA | ![]() | |||||||||||||||||||||
Object Oriented Analysis | is an instance of book about object oriented development processes | ![]() | |||||||||||||||||||||
was published by Yourdon Press | ![]() | ||||||||||||||||||||||
was published in 1991 | ![]() | ||||||||||||||||||||||
object oriented analysis | does not require an understanding of how objects are physically represented using a particular programming language | ![]() | |||||||||||||||||||||
does not require an understanding of whether objects are stored in random-access memory or on disk | ![]() | ||||||||||||||||||||||
object oriented design | follows object oriented analysis | ![]() | |||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 2.2 - Classes and Objects | ![]() | ||||||||||||||||||||||
is abbreviated as OOD | ![]() | ||||||||||||||||||||||
require an understanding of how objects are physically represented using a particular programming language | ![]() | ||||||||||||||||||||||
requires an understanding of whether objects are stored in random-access memory or on disk | ![]() | ||||||||||||||||||||||
requires the skill of organizing classes into inheritance hierarchies | ![]() | ||||||||||||||||||||||
object oriented framework | contains classes, some of which should be abstract | ![]() | |||||||||||||||||||||
contains methods in abstract classes which are the slots that are filled when concrete methods are created in the concrete subclasses | ![]() | ||||||||||||||||||||||
has API that is defined by the set of all public methods of the public classes | ![]() | ||||||||||||||||||||||
is a kind of framework | ![]() | ||||||||||||||||||||||
is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | ||||||||||||||||||||||
is composed of a library of classes | ![]() | ||||||||||||||||||||||
object oriented language | has features
| ![]() | |||||||||||||||||||||
has features abstraction, modularity and encapsulation | ![]() | ||||||||||||||||||||||
is a kind of programming language | ![]() | ||||||||||||||||||||||
is a subtopic of 2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarations | ![]() | ||||||||||||||||||||||
object oriented system | combines procedural abstraction with data abstraction | ![]() | |||||||||||||||||||||
is a kind of system | ![]() | ||||||||||||||||||||||
is a subtopic of 2.2 - Classes and Objects | ![]() | ||||||||||||||||||||||
makes use of abstraction in order to help make software less complex | ![]() | ||||||||||||||||||||||
object oriented testing | has example | ![]() | |||||||||||||||||||||
is a kind of testing performed by software engineers | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
object stream class | has example //creation output = new ObjectOutputStream(clientSocket.getOutputStream()); //sending an object output.writeObject(msg); //receiving an object (in a loop) msg = input.readObject(); | ![]() | |||||||||||||||||||||
is a kind of filter | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is wrapped around a binary stream | ![]() | ||||||||||||||||||||||
object symbol | is a kind of symbol in UML diagram | ![]() | |||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
Object-Oriented Analysis and Design With Applications | has author G. Booch | ![]() | |||||||||||||||||||||
has ISBN number | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of book about object oriented development processes | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1994 | ![]() | ||||||||||||||||||||||
Object-Oriented Modelling and Design | has author J. Rumbaugh, J. et al. | ![]() | |||||||||||||||||||||
has ISBN number | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of book about object oriented development processes | ![]() | ||||||||||||||||||||||
was published by Prentice Hall | ![]() | ||||||||||||||||||||||
was published in 1991 | ![]() | ||||||||||||||||||||||
object-oriented paradigm | has definition An approach to software design and programming in which software is primarily thought of as a collection of classes that each have responsibilities for various operations, and which are instantiated at run time to create objects | ![]() | |||||||||||||||||||||
has feature polymorphism | ![]() | ||||||||||||||||||||||
has fundamental units objects | ![]() | ||||||||||||||||||||||
helps to ensure communicational cohesion | ![]() | ||||||||||||||||||||||
is a kind of paradigm | ![]() | ||||||||||||||||||||||
is a subtopic of 2.1 - What is Object Orientation? | ![]() | ||||||||||||||||||||||
organizes code into classes that each contain procedures for manipulating instances of that class alone | ![]() | ||||||||||||||||||||||
Object-Oriented Software Engineering : A Use Case Driven Approach | has author I. Jacobson | ![]() | |||||||||||||||||||||
has ISBN number | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of book about object oriented development processes | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1994 | ![]() | ||||||||||||||||||||||
Object-Oriented Software Engineering: Conquering Complex and Changing Systems | has author Bernd Bruegge | ![]() | |||||||||||||||||||||
has ISBN number 0-13-489725-0 | ![]() | ||||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of software engineering book | ![]() | ||||||||||||||||||||||
was published by Prentice Hall | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
Object-Oriented Systems Analysis: Modelling the World in Data | has author S. Shlaer and S. Mellor | ![]() | |||||||||||||||||||||
has ISBN number | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of book about object oriented development processes | ![]() | ||||||||||||||||||||||
was published by Yourdon Press | ![]() | ||||||||||||||||||||||
was published in 1989 | ![]() | ||||||||||||||||||||||
object-oriented testing | has definition Testing that focuses on the specific properties of object oriented programs | ![]() | |||||||||||||||||||||
is a kind of testing | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
ObjectInputStream | contains Java objects | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of object stream class | ![]() | ||||||||||||||||||||||
uses serialization | ![]() | ||||||||||||||||||||||
objective | has definition A measurable value you wish to attain | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 9.3 - Techniques for Making Good Design Decisions | ![]() | ||||||||||||||||||||||
is influenced by memory efficiency, CPU efficiency, maintainability, portability and usability | ![]() | ||||||||||||||||||||||
should be obtained from non-functional requirements | ![]() | ||||||||||||||||||||||
Objective-C | is a subtopic of 2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarations | ![]() | |||||||||||||||||||||
is an instance of object oriented language | ![]() | ||||||||||||||||||||||
ObjectOutputStream | contains Java objects | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of object stream class | ![]() | ||||||||||||||||||||||
uses serialization | ![]() | ||||||||||||||||||||||
ObjectPlant | has URL www.arctaedius.com/ObjectPlant/ ![]() | ![]() | |||||||||||||||||||||
is a shareware tool for the Macintosh | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of tool for drawing UML diagrams | ![]() | ||||||||||||||||||||||
Objects By Design's list of UML modelling tools | has URL www.objectsbydesign.com/tools/umltools_byCompany.html ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of web site about UML | ![]() | ||||||||||||||||||||||
Objects Have Class!: An Introduction to Programming in Java | has author David A. Poplawski | ![]() | |||||||||||||||||||||
has ISBN number 0-07-242340-4 | ![]() | ||||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of book about Java programming | ![]() | ||||||||||||||||||||||
was published by McGraw Hill | ![]() | ||||||||||||||||||||||
was published in 2001 | ![]() | ||||||||||||||||||||||
observation | has purpose to gather subtle information that stakeholders may not think of telling you | ![]() | |||||||||||||||||||||
involves taking a notebook and 'shadowing' important potential users as they do their work, writing down everything they do, asking users to talk as they work and explain what they are doing, and perhaps videotaping the session so you can analyze it in more detail later | ![]() | ||||||||||||||||||||||
is a kind of requirements gathering | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
takes a lot of time | ![]() | ||||||||||||||||||||||
should only be done during the development of large systems, with which potential users will be performing complex tasks, because observation, and analysing the resulting information, can consume a large amount of time | ![]() | ||||||||||||||||||||||
observer | has antipatterns
| ![]() | |||||||||||||||||||||
has context
| ![]() | ||||||||||||||||||||||
has definition A pattern found in class diagrams in which instances of one class are informed of changes to instances of a second class | ![]() | ||||||||||||||||||||||
has forces
| ![]() | ||||||||||||||||||||||
has problem How do you reduce the interconnection between classes, especially between classes that belong to different modules or subsystems? | ![]() | ||||||||||||||||||||||
has references one of the Gang of Four patterns. | ![]() | ||||||||||||||||||||||
has solution
| ![]() | ||||||||||||||||||||||
is a subtopic of 6.6 - The Observer Pattern | ![]() | ||||||||||||||||||||||
is an instance of design pattern | ![]() | ||||||||||||||||||||||
can be used to separate the model^2 from the controller in the Model-View-Controller architecture | ![]() | ||||||||||||||||||||||
obsolescence | has definition The tendency for a technology to reach a state where it is no longer useful, is superseded by better technology or must be upgraded in order to continue to function correctly | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
occasional user | is a kind of user | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
occurrence | has definition An object that is a member of a set of classes that set share common information but also differ from each other in important ways | ![]() | |||||||||||||||||||||
has example a member of the set of all episodes of a television series - they have the same producer and the same series title, but different story-lines. | ![]() | ||||||||||||||||||||||
is a kind of object | ![]() | ||||||||||||||||||||||
is a subtopic of 6.2 - The Abstraction-Occurrence Pattern | ![]() | ||||||||||||||||||||||
OCL | is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | |||||||||||||||||||||
is an abbreviation for Object Constraint Language | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
OCL statement | has example {startPoint <> endPoint} constrains the two ends of a LineSegment to be different | ![]() | |||||||||||||||||||||
is a kind of statement | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
is not compiled | ![]() | ||||||||||||||||||||||
is not executed | ![]() | ||||||||||||||||||||||
specifies a logical fact (a constraint) about the system that must remain true | ![]() | ||||||||||||||||||||||
can be used for automatic code generation | ![]() | ||||||||||||||||||||||
can consist of
| ![]() | ||||||||||||||||||||||
can navigate from class to class using a dot to separate components. For example, in LinearShape, to refer to the length of the edges you can refer to edge.length. | ![]() | ||||||||||||||||||||||
can refer to all the values in a collection using the forall operator | ![]() | ||||||||||||||||||||||
can refer to special OCL properties of a collection itself using the -> operator | ![]() | ||||||||||||||||||||||
can use the implies operator which is true if either the left hand side is false or if both sizes are true | ![]() | ||||||||||||||||||||||
can use the {ordered} constraint to indicate that an OCL collection is a sequence, which allows you refer to special properties such as first and last | ![]() | ||||||||||||||||||||||
does not have to be written on a UML diagram but can be written separately with a context specified | ![]() | ||||||||||||||||||||||
OCL statement in a class diagram | is a kind of OCL statement | ![]() | |||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
can specify what the values of attributes and associations must be | ![]() | ||||||||||||||||||||||
can state the preconditions and postconditions of operations | ![]() | ||||||||||||||||||||||
off-by-one error | has definition A defect in which a program inappropriately adds or subtracts one, or inappropriately loops one too many times or one too few times | ![]() | |||||||||||||||||||||
has testing strategy develop boundary tests in which you verify that the program computes the correct numerical answer, or performs the correct number of iterations | ![]() | ||||||||||||||||||||||
is very common especially in graphical applications | ![]() | ||||||||||||||||||||||
is a kind of defect in an ordinary algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
one | indicates that that there must be exactly one instance linked to each object at the other end of the association in a UML diagram | ![]() | |||||||||||||||||||||
is a kind of multiplicity | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
one-to-many | is the most common multiplicity pattern | ![]() | |||||||||||||||||||||
is the same as many-to-one | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is an instance of multiplicity pattern | ![]() | ||||||||||||||||||||||
one-to-many association | is a kind of association | ![]() | |||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
one-to-one | has example For each company, there is exactly one board of directors | ![]() | |||||||||||||||||||||
is less common than other multiplicity patterns | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is an instance of multiplicity pattern | ![]() | ||||||||||||||||||||||
one-to-one association | is a kind of association | ![]() | |||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
one-to-one composition | is a kind of composition | ![]() | |||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
often corresponds to a complex attribute that can be shown as an attribute or, if you want to emphasize the details of the composed class, as a composition | ![]() | ||||||||||||||||||||||
one-way association | is a kind of association | ![]() | |||||||||||||||||||||
is a subtopic of 5.9 - Implementing Class Diagrams in Java | ![]() | ||||||||||||||||||||||
one-way association where the multiplicity at the other end is 'many' | is a kind of one-way association | ![]() | |||||||||||||||||||||
is a subtopic of 5.9 - Implementing Class Diagrams in Java | ![]() | ||||||||||||||||||||||
is implemented by using a collection class such as Vector in Java | ![]() | ||||||||||||||||||||||
one-way association where the multiplicity at the other end is 'one' or 'optional' | is a kind of one-way association | ![]() | |||||||||||||||||||||
is a subtopic of 5.9 - Implementing Class Diagrams in Java | ![]() | ||||||||||||||||||||||
is implemented by declaring an instance variable of that class in Java | ![]() | ||||||||||||||||||||||
OO | is a subtopic of 2.1 - What is Object Orientation? | ![]() | |||||||||||||||||||||
is an abbreviation for object oriented | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
OOA | is a subtopic of 2.2 - Classes and Objects | ![]() | |||||||||||||||||||||
is an abbreviation for object oriented analysis | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
OOD | is a subtopic of 2.2 - Classes and Objects | ![]() | |||||||||||||||||||||
is an abbreviation for object oriented design | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
OOP | is a subtopic of 2.1 - What is Object Orientation? | ![]() | |||||||||||||||||||||
is an abbreviation for object oriented programming | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
open beta release | has definition A version of a system released for beta testing by any member of the general public who wishes to participate | ![]() | |||||||||||||||||||||
is bad engineering practice because it results in wasted time on the part of the users, since many people will discover the same problems | ![]() | ||||||||||||||||||||||
is low quality | ![]() | ||||||||||||||||||||||
is a kind of release | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
relies on beta testing by users to discover problems | ![]() | ||||||||||||||||||||||
operating system | contains a kernel layer and higher level layers dealing with such functions as user account management, screen display, etc. | ![]() | |||||||||||||||||||||
is a kind of multi-layer system | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
operation | carries out a responsibility of a class | ![]() | |||||||||||||||||||||
has definition The abstract notion of something that can be done by one or more classes | ![]() | ||||||||||||||||||||||
is a kind of procedural abstraction | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is implemented as a set of methods | ![]() | ||||||||||||||||||||||
is used to discuss and specify a type of behaviour, independently of any code which implements that behaviour | ![]() | ||||||||||||||||||||||
operation symbol | is a kind of symbol in UML diagram | ![]() | |||||||||||||||||||||
is a subtopic of 5.2 - Essentials of UML Class Diagrams | ![]() | ||||||||||||||||||||||
operator | is a kind of programming language construct | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
operator precedence error | has definition A defect in which a programmer omits needed parentheses, or puts parentheses in the wrong place | ![]() | |||||||||||||||||||||
has testing strategy
| ![]() | ||||||||||||||||||||||
is a kind of defect in an ordinary algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
may be obvious | ![]() | ||||||||||||||||||||||
may be hidden until special conditions arise | ![]() | ||||||||||||||||||||||
opportunistic approach | has definition An unsatisfactory process model in which developers keep on modifying the software until they or their users are satisfied | ![]() | |||||||||||||||||||||
has weaknesses
| ![]() | ||||||||||||||||||||||
is a kind of process model | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
optimistic-likely-pessimistic estimation | has definition An approach to cost estimation in which you make three estimates for each task and for the project as a whole: An optimistic estimate, (in which everything goes well) the likely estimate and a pessimistic estimate (where you account for everything that could go wrong) | ![]() | |||||||||||||||||||||
is a kind of cost estimation | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
optional | is a kind of multiplicity | ![]() | |||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
is written as 0..1 | ![]() | ||||||||||||||||||||||
means there can be either zero or one object linked to an object at the other end of the association | ![]() | ||||||||||||||||||||||
ordering operations poorly so errors build up | has testing strategy
| ![]() | |||||||||||||||||||||
is a kind of defect in a numerical algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.4 - Defects in Numerical Algorithms | ![]() | ||||||||||||||||||||||
occurs when you do small operations on large floating point numbers, and excessive rounding or truncation errors build up | ![]() | ||||||||||||||||||||||
organization | is a kind of person or group | ![]() | |||||||||||||||||||||
OutputStream | contains a message composed of bytes | ![]() | |||||||||||||||||||||
has example of instance creation output = clientSocket.getOutputStream(); | ![]() | ||||||||||||||||||||||
is a member of the java.io package | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of stream class | ![]() | ||||||||||||||||||||||
over-constrain | has definition To make a decision that constrains future choices, with insufficient justification | ![]() | |||||||||||||||||||||
is a kind of action | ![]() | ||||||||||||||||||||||
is a subtopic of 4.8 - Reviewing Requirements | ![]() | ||||||||||||||||||||||
overriding | has definition The situation where a method local to a class is used in place of a method that otherwise would have been inherited | ![]() | |||||||||||||||||||||
is a kind of practice | ![]() | ||||||||||||||||||||||
is a subtopic of 2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarations | ![]() | ||||||||||||||||||||||
package | has definition A collection of modelling elements that are grouped together because they are logically related | ![]() | |||||||||||||||||||||
has dependency / with another package if there is a dependency between an element in one package and an element in another | ![]() | ||||||||||||||||||||||
is difficult to use if it depends on many other packages, since using it will also necessitate importing its dependent packages | ![]() | ||||||||||||||||||||||
is a kind of representation | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
is divided up into classes | ![]() | ||||||||||||||||||||||
is drawn as as a box, with a smaller box attached above its top left corner | ![]() | ||||||||||||||||||||||
is not the same as package^2 in Java | ![]() | ||||||||||||||||||||||
is often used to represent a Java package | ![]() | ||||||||||||||||||||||
see also package^2 | ![]() | ||||||||||||||||||||||
see also package^3 | ![]() | ||||||||||||||||||||||
package diagram | has definition A type of UML class diagram showing packages and their relationships | ![]() | |||||||||||||||||||||
is a kind of UML diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
package^2 | has definition A facility for grouping a set of classes | ![]() | |||||||||||||||||||||
is a kind of programming language construct | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
see also package | ![]() | ||||||||||||||||||||||
see also package^3 | ![]() | ||||||||||||||||||||||
package^3 | has example package finance.banking.accounts; | ![]() | |||||||||||||||||||||
has purpose to declare the package that a class belongs to | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
see also package | ![]() | ||||||||||||||||||||||
see also package^2 | ![]() | ||||||||||||||||||||||
palette | is a kind of non-modal dialog | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
paper prototype | has benefit can often be a very powerful tool for eliciting ideas and feedback | ![]() | |||||||||||||||||||||
has benefit very easy to create | ![]() | ||||||||||||||||||||||
has definition A set of pictures of a system used to demonstrate how the system would work if implemented | ![]() | ||||||||||||||||||||||
has purpose to show to customers and users in sequence, to explain what would happen when the system runs | ![]() | ||||||||||||||||||||||
is ideal for parallel development | ![]() | ||||||||||||||||||||||
is a kind of prototype | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
represents the user interface of a system | ![]() | ||||||||||||||||||||||
paradigm | has definition An approach to software design and programming | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 2.1 - What is Object Orientation? | ![]() | ||||||||||||||||||||||
parallel design | is a synonym of parallel development | ![]() | |||||||||||||||||||||
parallel development | has definition Independent development of a system or subsystem by several developers, with the objective of exploring design space and generating a variety of different design ideas; the best ideas are generally chosen for further development | ![]() | |||||||||||||||||||||
is a kind of development | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
is a synonym of parallel design | ![]() | ||||||||||||||||||||||
can be done using paper prototypes | ![]() | ||||||||||||||||||||||
paraphraser | has definition A person in an inspection who steps through the document explaining it in their own words | ![]() | |||||||||||||||||||||
is a kind of tester | ![]() | ||||||||||||||||||||||
is a subtopic of 10.10 - Inspections | ![]() | ||||||||||||||||||||||
Pareto principle | is a synonym of 80-20 rule | ![]() | |||||||||||||||||||||
parseInt | has example // converts aString to an int | ![]() | |||||||||||||||||||||
has purpose to convert a string to an int | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java class method | ![]() | ||||||||||||||||||||||
pattern | has definition A widely understood solution to a particular type of problem | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 6.1 - Introduction to Patterns | ![]() | ||||||||||||||||||||||
pattern language | has definition A group of interrelated design patterns | ![]() | |||||||||||||||||||||
is a kind of language | ![]() | ||||||||||||||||||||||
is a subtopic of 6.1 - Introduction to Patterns | ![]() | ||||||||||||||||||||||
pattern | should be as general as possible | ![]() | |||||||||||||||||||||
should be described in an easy-to-understand form so that people can determine when and how to use it | ![]() | ||||||||||||||||||||||
should contain a solution that has been proven to effectively solve the problem in the indicated context | ![]() | ||||||||||||||||||||||
patterns community | has definition A loose but large collection of people who believe in the usefulness of patterns in software engineering, as well as in certain philosophies regarding their development | ![]() | |||||||||||||||||||||
have philosophies
| ![]() | ||||||||||||||||||||||
is a kind of person or group | ![]() | ||||||||||||||||||||||
is a subtopic of 6.1 - Introduction to Patterns | ![]() | ||||||||||||||||||||||
Patterns in Java Volume 1: A Catalog of Reusable Design patterns Illustrated with UML | has author M. Grand | ![]() | |||||||||||||||||||||
has ISBN number 0-471-25839-3 | ![]() | ||||||||||||||||||||||
is a subtopic of 6.15 - Using Design Patterns - References | ![]() | ||||||||||||||||||||||
is an instance of book about design patterns | ![]() | ||||||||||||||||||||||
was published by Wiley | ![]() | ||||||||||||||||||||||
was published in 1998 | ![]() | ||||||||||||||||||||||
peer-to-peer | has definition A variant of the client-server architectural pattern in which components can serve as both servers and clients to each other | ![]() | |||||||||||||||||||||
is a kind of client-server architecture | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
peer-to-peer system | allows each program to function as both a client and a server | ![]() | |||||||||||||||||||||
contains software components that are distributed over several hosts and that can each be both a server and a client | ![]() | ||||||||||||||||||||||
has definition A client-server system in which each program can act as both a client and a server for all the other programs | ![]() | ||||||||||||||||||||||
is a kind of client-server system | ![]() | ||||||||||||||||||||||
is a kind of client-server system | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
percentage of code that is reused | is a kind of measurement | ![]() | |||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
perfective maintenance | has definition A type of maintenance that includes reengineering, and is sometimes applied more broadly to include enhancement | ![]() | |||||||||||||||||||||
is a kind of maintenance | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
perfective project | is a kind of synonym | ![]() | |||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
is a synonym for reengineering project | ![]() | ||||||||||||||||||||||
performing a calculation in the wrong part of a control construct | has definition A common defect in which the program performs an action when it should not, or does not perform an action when it should | ![]() | |||||||||||||||||||||
has testing strategy | ![]() | ||||||||||||||||||||||
is a kind of defect in an ordinary algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
is typically caused by inappropriately excluding the action from, or including the action in, a loop or if-then-else construct | ![]() | ||||||||||||||||||||||
may not be caught using black-box testing, so glass-box testing or inspections may be more effective | ![]() | ||||||||||||||||||||||
person | is a kind of person or group | ![]() | |||||||||||||||||||||
can understand requirements better if they are expressed in terms of use cases | ![]() | ||||||||||||||||||||||
person or group | is a kind of subject | ![]() | |||||||||||||||||||||
person's name | has localization issues
| ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a kind of name | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
person-month | has definition A measure of effort. One person month is the amount of work done by one person in one month if they are working full time | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
measures effort | ![]() | ||||||||||||||||||||||
Personal Software Process | defines A disciplined approach that an individual software developer can use to improve the quality and efficiency of his or her personal work | ![]() | |||||||||||||||||||||
has definition A disciplined approach that an individual software developer can use to improve the quality and efficiency of his or her personal work | ![]() | ||||||||||||||||||||||
has key tenet personally inspecting your own work | ![]() | ||||||||||||||||||||||
is a kind of process standard | ![]() | ||||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
is abbreviated as PSP | ![]() | ||||||||||||||||||||||
was developed at the Software Engineering Institute of Carnegie Mellon University | ![]() | ||||||||||||||||||||||
PERT | is a subtopic of 11.5 - Project Scheduling and Tracking | ![]() | |||||||||||||||||||||
is an abbreviation for Program Evaluation Review Technique | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
PERT chart | contains nodes, each of which shows the elapsed time and effort estimates | ![]() | |||||||||||||||||||||
forms a graph, whose nodes are tasks, and whose arcs are dependencies | ![]() | ||||||||||||||||||||||
has definition A diagram showing the sequence in which tasks must be completed | ![]() | ||||||||||||||||||||||
has purpose to determine the critical path | ![]() | ||||||||||||||||||||||
is a kind of diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 11.5 - Project Scheduling and Tracking | ![]() | ||||||||||||||||||||||
is used in Program Evaluation Review Technique | ![]() | ||||||||||||||||||||||
is used in project scheduling | ![]() | ||||||||||||||||||||||
represents activities, each of which has one or more predecessors on which it depends, and one or more successors, which depend on it | ![]() | ||||||||||||||||||||||
shows the sequence in which tasks must be completed | ![]() | ||||||||||||||||||||||
can show optimistic, likely and pessimistic estimates of time and effort | ![]() | ||||||||||||||||||||||
Peter G. Neumann's Risks Digest | contains numerous reports of software failures | ![]() | |||||||||||||||||||||
has URL catless.ncl.ac.uk/Risks/ ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of web site about software failures | ![]() | ||||||||||||||||||||||
Petri Nets World | has URL www.daimi.au.dk/PetriNets ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 8.5 - Modelling Interactions and Behaviour - References | ![]() | ||||||||||||||||||||||
is an instance of web site about modelling interactions and behaviour | ![]() | ||||||||||||||||||||||
phased-release model | corrects some, but not all, of the problems of the waterfall model | ![]() | |||||||||||||||||||||
has definition An approach to incremental development in which, after requirements gathering and planning, the project is broken into separate subprojects, or phases | ![]() | ||||||||||||||||||||||
has weaknesses
| ![]() | ||||||||||||||||||||||
is a kind of process model | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
recommends the use of incremental development | ![]() | ||||||||||||||||||||||
suggests that after requirements gathering and planning, the project should be broken into separate subprojects, or phases which can be released to customers when ready | ![]() | ||||||||||||||||||||||
photograph | has advantages helps users better appreciate reality | ![]() | |||||||||||||||||||||
has problems
| ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
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 it | ![]() | ||||||||||||||||||||||
pilot system | is a synonym of prototype | ![]() | |||||||||||||||||||||
pipe | has definition A connection between two filters in a pipe-and-filter architecture. It joins the output of one filter to the input to another | ![]() | |||||||||||||||||||||
is a kind of abstraction | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
pipe and filter | facilitates designing for testability because it is normally easy to test the individual processes | ![]() | |||||||||||||||||||||
has advantage the system can be modified easily by adding or changing the transformational processes | ![]() | ||||||||||||||||||||||
has definition An architectural pattern in which data in a standard format is passed through a series of processes (filters) that transform it in some way | ![]() | ||||||||||||||||||||||
increases cohesion because the processes have functional cohesion | ![]() | ||||||||||||||||||||||
increases flexibility | ![]() | ||||||||||||||||||||||
increases reusability because the processes can often be used in many different contexts | ![]() | ||||||||||||||||||||||
increases reuse because it is often possible to find reusable components to insert into a pipeline | ![]() | ||||||||||||||||||||||
is a kind of architectural pattern | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
is a synonym of transformational architectural pattern | ![]() | ||||||||||||||||||||||
is a synonym of transformational architecture | ![]() | ||||||||||||||||||||||
reduces coupling because the processes have only one input and one output, normally using a standard format | ![]() | ||||||||||||||||||||||
uses a pipeline | ![]() | ||||||||||||||||||||||
pipeline | has definition A series of processes that transform data in the pipe-and-filter architectural pattern | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
platform | describes what hardware and operating system the software must be able to work on | ![]() | |||||||||||||||||||||
is a kind of non-functional requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
normally specifies the least powerful platforms and declares that it must work on anything more recent or more powerful | ![]() | ||||||||||||||||||||||
player-role | has antipatterns merging all the properties and behaviours into the Player class which however, creates an overly complex class - much of the power of object orientation is lost | ![]() | |||||||||||||||||||||
has context | ![]() | ||||||||||||||||||||||
has definition A pattern in found in class diagrams in which one class (the player) has several associated role classes. Instances of the role classes can change over the lifetime of a player | ![]() | ||||||||||||||||||||||
has forces
| ![]() | ||||||||||||||||||||||
has problem How do you best model players and roles so that a player can change roles or possess multiple roles? | ![]() | ||||||||||||||||||||||
has related patterns Abstraction-Occurrence pattern | ![]() | ||||||||||||||||||||||
has solution
| ![]() | ||||||||||||||||||||||
is a subtopic of 6.4 - The Player-Role Pattern | ![]() | ||||||||||||||||||||||
is an instance of design pattern | ![]() | ||||||||||||||||||||||
polymorphic operation | is a kind of operation | ![]() | |||||||||||||||||||||
is a subtopic of 2.4 - Methods, Operations and Polymorphism | ![]() | ||||||||||||||||||||||
is implemented by several different methods | ![]() | ||||||||||||||||||||||
lets a running program decide, every time an operation is called, which of several identically-named methods to invoke | ![]() | ||||||||||||||||||||||
polymorphism | exists when several classes which each implement the operation either have a common superclass in which the operation exists, or else implement an interface that contains the operation | ![]() | |||||||||||||||||||||
gets power from dynamic binding | ![]() | ||||||||||||||||||||||
has definition A property of object oriented software by which an abstract operation may be performed in different ways in different classes | ![]() | ||||||||||||||||||||||
is one of the fundamental features of the object oriented paradigm | ![]() | ||||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 2.4 - Methods, Operations and Polymorphism | ![]() | ||||||||||||||||||||||
port | has definition A number associated with a server on a host, used by a client that wishes to connect to that server | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
portability | has definition The ability for software to be run in a variety of different hardware or software environments with no or minimal changes | ![]() | |||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
post-mortem analysis | has definition The process of looking back at a completed project's design and its development process, in order to identify those aspects where improvements can be made in future projects | ![]() | |||||||||||||||||||||
is a kind of analysis | ![]() | ||||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
postal code format | has localization issues | ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
postcondition | has definition A statement that is guaranteed to be true following the successful completion of some action | ![]() | |||||||||||||||||||||
is a kind of statement | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
power user | is a kind of user | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is a synonym of expert user | ![]() | ||||||||||||||||||||||
learns software of considerable complexity quickly | ![]() | ||||||||||||||||||||||
wants powerful features such as keyboard shortcuts | ![]() | ||||||||||||||||||||||
wants software that allows them to do their job as rapidly as possible | ![]() | ||||||||||||||||||||||
practice | is a kind of subject | ![]() | |||||||||||||||||||||
precondition | has definition A statement that must be true before some algorithm, method or use case is executed | ![]() | |||||||||||||||||||||
is a kind of statement | ![]() | ||||||||||||||||||||||
is a subtopic of 10.4 - Defects in Numerical Algorithms | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
principle | is a kind of criterion | ![]() | |||||||||||||||||||||
principle behind frameworks | is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | |||||||||||||||||||||
is an instance of principle | ![]() | ||||||||||||||||||||||
states that applications that do different but related things tend to have similar designs - in particular, the patterns of interactions among the components tend to be very similar | ![]() | ||||||||||||||||||||||
Principles and Guidelines in Software User Interface Design | has author D.J. Mayhew | ![]() | |||||||||||||||||||||
has ISBN number 0-13-721929-6 | ![]() | ||||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
is an instance of book about user interfaces and usability | ![]() | ||||||||||||||||||||||
was published by Prentice-Hall | ![]() | ||||||||||||||||||||||
was published in 1992 | ![]() | ||||||||||||||||||||||
Principles of Object Oriented Analysis and Design | has author J. Martin, and J. Odell | ![]() | |||||||||||||||||||||
has ISBN number | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of book about object oriented development processes | ![]() | ||||||||||||||||||||||
was published by Prentice Hall | ![]() | ||||||||||||||||||||||
was published in 1992 | ![]() | ||||||||||||||||||||||
println | has example System.out.println("This line will be printed"); | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java method | ![]() | ||||||||||||||||||||||
priority | has definition An ordering that states which qualities override others in those cases where you must make compromises | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 9.3 - Techniques for Making Good Design Decisions | ![]() | ||||||||||||||||||||||
is influenced by memory efficiency, CPU efficiency, maintainability, portability and usability | ![]() | ||||||||||||||||||||||
should be obtained from non-functional requirements | ![]() | ||||||||||||||||||||||
privacy | allows changes to code to be more easily made since one can be confident that 'outsiders' are not relying on too many details | ![]() | |||||||||||||||||||||
improves encapsulation by ensuring that only programmers working inside a class (or inside a package) can use all of its facilities | ![]() | ||||||||||||||||||||||
is a kind of practice | ![]() | ||||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
private | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java access control keyword | ![]() | ||||||||||||||||||||||
is used to declare private method | ![]() | ||||||||||||||||||||||
private method | is a kind of Java method | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can only be accessed by code in the same class | ![]() | ||||||||||||||||||||||
problem | has definition In the broad context of software engineering, a difficulty, challenge, need or desire faced by a customer that is to be solved by developing software | ![]() | |||||||||||||||||||||
has solution which will normally entail developing software, although you may decide that it is better to purchase software or to develop a non-software solution | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 1.2 - What is Software Engineering? | ![]() | ||||||||||||||||||||||
should be written as a simple problem statement in one or two sentences | ![]() | ||||||||||||||||||||||
problem statement | is a kind of document | ![]() | |||||||||||||||||||||
is a subtopic of 4.3 - Defining The Problem and the Scope | ![]() | ||||||||||||||||||||||
can be used to evaluate requirements based on the question: 'are we adequately solving the problem?' | ![]() | ||||||||||||||||||||||
may have to be refined several times | ![]() | ||||||||||||||||||||||
should be defined as early as possible | ![]() | ||||||||||||||||||||||
should depend on the user's ultimate high-level goal when they use the system, and the customers high-level goal for having it developed | ![]() | ||||||||||||||||||||||
problem^2 | is a kind of subject | ![]() | |||||||||||||||||||||
is part of design pattern | ![]() | ||||||||||||||||||||||
procedural abstraction | has advantage when using a certain procedure, a programmer does not need to worry about all the details of how it performs its computations; he or she only needs to know how to call it and what it computes | ![]() | |||||||||||||||||||||
hides the details of procedures | ![]() | ||||||||||||||||||||||
is a kind of abstraction | ![]() | ||||||||||||||||||||||
is a subtopic of 2.1 - What is Object Orientation? | ![]() | ||||||||||||||||||||||
procedural cohesion | has definition A form of cohesion in which procedures that are called one after another are kept together | ![]() | |||||||||||||||||||||
is weaker than sequential cohesion | ![]() | ||||||||||||||||||||||
is a kind of cohesion | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is achieved when you keep together several procedures that are used one after another, even though one does not necessarily provide input to the next | ![]() | ||||||||||||||||||||||
procedural paradigm | has definition An approach to software design and programming in which software is primarily thought of as a hierarchy of procedures - the root of the hierarchy is typically a main procedure, which calls other procedures, etc. (in contrast to the object-oriented paradigm) | ![]() | |||||||||||||||||||||
hides many of the details of computations | ![]() | ||||||||||||||||||||||
is a kind of paradigm | ![]() | ||||||||||||||||||||||
is a subtopic of 2.1 - What is Object Orientation? | ![]() | ||||||||||||||||||||||
organizes code into procedures that each manipulate different types of data | ![]() | ||||||||||||||||||||||
provides procedural abstraction | ![]() | ||||||||||||||||||||||
works badly if the program's purpose is to perform calculations on complex data | ![]() | ||||||||||||||||||||||
works well if the program's purpose is to perform complex calculations with relatively simple data | ![]() | ||||||||||||||||||||||
procedure | is a kind of programming language construct | ![]() | |||||||||||||||||||||
provides procedural abstraction | ![]() | ||||||||||||||||||||||
may have one or more preconditions | ![]() | ||||||||||||||||||||||
process | has definition Anything that operates for a period of time, normally consuming resources during that time and using them to create a useful result | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
see also process^2 | ![]() | ||||||||||||||||||||||
process model | functions as an aid to thinking, not as a rigid prescription of the way to do things | ![]() | |||||||||||||||||||||
has definition A general approach for organizing a project into activities; an aid to thinking, not a rigid prescription of the way to do things | ![]() | ||||||||||||||||||||||
helps the project manager and his or her team to decide what work should be done and in what sequence to perform the work | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
is a synonym of software process model | ![]() | ||||||||||||||||||||||
process standard | has definition A document describing a well-respected way of developing software | ![]() | |||||||||||||||||||||
is a kind of standard | ![]() | ||||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
process^2 | has definition A running thread of execution in a computer | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
see also process | ![]() | ||||||||||||||||||||||
professional engineer | has definition A person who has been issued a license, by some jurisdiction, to perform engineering | ![]() | |||||||||||||||||||||
is a kind of engineer | ![]() | ||||||||||||||||||||||
is a subtopic of 1.3 - Software Engineering as a Branch of the Engineering Profession | ![]() | ||||||||||||||||||||||
Professional Engineering Institutions (UK) | has URL www.pei.org.uk ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of engineering web site | ![]() | ||||||||||||||||||||||
Professional Engineers Ontario | has URL www.peo.on.ca ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of engineering web site | ![]() | ||||||||||||||||||||||
program | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
is written by programmer | ![]() | ||||||||||||||||||||||
program element name | is a kind of name | ![]() | |||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
can be very long if the length is justified because it adds clarity | ![]() | ||||||||||||||||||||||
should be highly descriptive of the purpose and function of the element | ![]() | ||||||||||||||||||||||
should not be less than about six characters except perhaps for loop counter variables, where i and j are commonly used | ![]() | ||||||||||||||||||||||
Program Evaluation Review Technique | is similar to techniques called the "Critical Path Method" and "Precedence Networks" | ![]() | |||||||||||||||||||||
is a subtopic of 11.5 - Project Scheduling and Tracking | ![]() | ||||||||||||||||||||||
is abbreviated as PERT | ![]() | ||||||||||||||||||||||
is an instance of project scheduling technique | ![]() | ||||||||||||||||||||||
uses PERT chart | ![]() | ||||||||||||||||||||||
program | must be readable by humans | ![]() | |||||||||||||||||||||
should follow consistent guidelines that make the program easy to read | ![]() | ||||||||||||||||||||||
programmer | is responsible for anticipating things that can go wrong and writing exception handling code in preparation | ![]() | |||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
often uses glass-box testing informally when he is verifying his own code | ![]() | ||||||||||||||||||||||
writes program | ![]() | ||||||||||||||||||||||
can write comments before writing the code | ![]() | ||||||||||||||||||||||
may also design the system | ![]() | ||||||||||||||||||||||
may have difficulty thinking at the level of abstraction needed to create effective models | ![]() | ||||||||||||||||||||||
must ensure that the code she writes based on a UML diagram always respects the constraints imposed by each OCL statement | ![]() | ||||||||||||||||||||||
must learn documentation navigation, which includes looking up the methods available to achieve some objective | ![]() | ||||||||||||||||||||||
should adhere to object oriented principles | ![]() | ||||||||||||||||||||||
should apply the 'isa' rule religiously | ![]() | ||||||||||||||||||||||
should avoid duplication of code | ![]() | ||||||||||||||||||||||
should avoid over-use of class variables or class methods | ![]() | ||||||||||||||||||||||
should choose alternative that makes code simpler over more complicated one | ![]() | ||||||||||||||||||||||
should comment any changes to the code so that it is easy to see what has changed from one version to the next | ![]() | ||||||||||||||||||||||
should comment whatever is non-obvious | ![]() | ||||||||||||||||||||||
should create several small classes, rather than one big, complex class | ![]() | ||||||||||||||||||||||
should ensure that anything that is true in a superclass is also true in its subclasses | ![]() | ||||||||||||||||||||||
should follow consistent guidelines that make programs easy to read when writing programs | ![]() | ||||||||||||||||||||||
should group classes into logical sections with a clear comment separating each section if a class has many methods | ![]() | ||||||||||||||||||||||
should keep related methods together inside a class | ![]() | ||||||||||||||||||||||
should keep the number of instance variables small. If this number exceeds 10, then consider splitting the class into separate classes - e.g. a superclass and a subclass | ![]() | ||||||||||||||||||||||
should not comment obvious things since they add clutter | ![]() | ||||||||||||||||||||||
should not use tab characters in code - use two spaces for indentation instead because when code is printed on certain printers, or displayed in certain editors, the width of the indentation resulting from the tab can vary and make the code hard to read | ![]() | ||||||||||||||||||||||
should pay attention to to the documentation describing which features of Java are deprecated | ![]() | ||||||||||||||||||||||
should reject 'clever' or 'cool' coding techniques unless they make the code simpler to understand | ![]() | ||||||||||||||||||||||
should remember that shorter code is not necessarily better code but unnecessarily long code is also bad | ![]() | ||||||||||||||||||||||
should restructure code to make it simpler if necessary | ![]() | ||||||||||||||||||||||
should take advantage of polymorphism, inheritance, abstract classes, and methods | ![]() | ||||||||||||||||||||||
should use consistent code layout style | ![]() | ||||||||||||||||||||||
should write comments at the same time as writing code , and perhaps even before writing the code | ![]() | ||||||||||||||||||||||
programming | is the final stage of design because it involves making decisions about programming language constructs, variable declarations etc. | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
is part of design | ![]() | ||||||||||||||||||||||
is part of software engineering | ![]() | ||||||||||||||||||||||
programming environment | is a kind of tool | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
programming language | comes with basic libraries and APIs | ![]() | |||||||||||||||||||||
has definition A language used to write computer programs | ![]() | ||||||||||||||||||||||
is a kind of language | ![]() | ||||||||||||||||||||||
programming language construct | is a kind of subject | ![]() | |||||||||||||||||||||
Programming Pearls | has author J. Bentley | ![]() | |||||||||||||||||||||
has ISBN number 0-201-65788-0 | ![]() | ||||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of book about programming | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
Programming Style Guidelines | is a subtopic of Chapter 2 - Review of Object Orientation | ![]() | |||||||||||||||||||||
progress bar | is a kind of user interface component | ![]() | |||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
project management | has definition All the activities needed to plan and execute a project. | ![]() | |||||||||||||||||||||
has difficulties
| ![]() | ||||||||||||||||||||||
includes all the activities needed to plan and execute a project | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of Chapter 11 - Managing the Software Process | ![]() | ||||||||||||||||||||||
is performed by project manager | ![]() | ||||||||||||||||||||||
is performed by software engineer | ![]() | ||||||||||||||||||||||
project management standard | is a kind of standard | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
project manager | acts as a mentor | ![]() | |||||||||||||||||||||
bases cost estimate on
| ![]() | ||||||||||||||||||||||
determines how the plans need to change, and takes action to keep the project on track | ![]() | ||||||||||||||||||||||
directs people to appropriate sources of information | ![]() | ||||||||||||||||||||||
directs subordinates and contractors | ![]() | ||||||||||||||||||||||
ensures that hardware and software is available | ![]() | ||||||||||||||||||||||
ensures that people always have somebody to talk to about problems | ![]() | ||||||||||||||||||||||
ensures that people feel rewarded, respected and motivated | ![]() | ||||||||||||||||||||||
ensures that people have the requisite security clearance | ![]() | ||||||||||||||||||||||
estimates the amount of time that will be required to complete the project | ![]() | ||||||||||||||||||||||
estimates the cost of the system which involves studying the requirements and determining how much effort they will take to design and implement | ![]() | ||||||||||||||||||||||
finds customers | ![]() | ||||||||||||||||||||||
finds office space | ![]() | ||||||||||||||||||||||
fires people who are not performing adequately | ![]() | ||||||||||||||||||||||
gives advice about engineering problems | ![]() | ||||||||||||||||||||||
gives people feedback to help them improve their work | ![]() | ||||||||||||||||||||||
has activities
| ![]() | ||||||||||||||||||||||
has definition The person responsible for performing project management tasks | ![]() | ||||||||||||||||||||||
has goal to please the customer or sell the most software, while spending the least money | ![]() | ||||||||||||||||||||||
helps employees resolve inter-personal conflicts | ![]() | ||||||||||||||||||||||
helps people solve problems by leading discussions | ![]() | ||||||||||||||||||||||
hires employees | ![]() | ||||||||||||||||||||||
initiates the paperwork involved in hiring or subcontracting | ![]() | ||||||||||||||||||||||
is a kind of stakeholder | ![]() | ||||||||||||||||||||||
is a subtopic of 11.1 - What is Project Management? | ![]() | ||||||||||||||||||||||
is a synonym of development manager | ![]() | ||||||||||||||||||||||
is part of software development team | ![]() | ||||||||||||||||||||||
makes high-level decisions about requirements and design | ![]() | ||||||||||||||||||||||
negotiates contracts | ![]() | ||||||||||||||||||||||
often has education in business administration | ![]() | ||||||||||||||||||||||
often uses lines of code to give an intermediate cost estimate that people can easily understand although you usually cannot accurately base cost estimates on lines of code until you have almost completed design | ![]() | ||||||||||||||||||||||
performs project management | ![]() | ||||||||||||||||||||||
plans work schedule | ![]() | ||||||||||||||||||||||
runs the organization that is developing the software | ![]() | ||||||||||||||||||||||
selects the overall processes that will be followed | ![]() | ||||||||||||||||||||||
sets up training courses | ![]() | ||||||||||||||||||||||
takes the ultimate legal responsibility for declaring that proper engineering practice has been followed, and that the manager believes the resulting system will be safe | ![]() | ||||||||||||||||||||||
tells customers and higher-level managers what they need or want to know | ![]() | ||||||||||||||||||||||
uses cost-benefit analysis to choose among alternatives | ![]() | ||||||||||||||||||||||
wants software that sells more and pleases customers while costing less to develop and maintain | ![]() | ||||||||||||||||||||||
works with customers to determine their problem and the scope of the project | ![]() | ||||||||||||||||||||||
does not perform activities such as hiring, building morale, and issuing the final directions if there is a departmental manager to do them instead | ![]() | ||||||||||||||||||||||
may be judged on when they deliver product, not on its quality level | ![]() | ||||||||||||||||||||||
may not be familiar with small details of the project | ![]() | ||||||||||||||||||||||
must have knowledge about how to manage software projects | ![]() | ||||||||||||||||||||||
must realize that the vicious circle of software reuse exists and costs money - in order to save money in the longer term, an investment in reusable code is justified | ![]() | ||||||||||||||||||||||
should allow time to re-engineer part or all of the system periodically | ![]() | ||||||||||||||||||||||
should be realistic in initial requirements gathering | ![]() | ||||||||||||||||||||||
should develop a close relationship with other members of the team so that he or she is more keenly aware at all times about the progress achieved, and the potential risks | ![]() | ||||||||||||||||||||||
should encourage all necessary communication between team members | ![]() | ||||||||||||||||||||||
should ensure that everybody understands the position of everybody else, the costs and benefits of each alternative, and the rationale behind any compromises | ![]() | ||||||||||||||||||||||
should ensure that everybody's proposed responsibility is clearly expressed | ![]() | ||||||||||||||||||||||
should follow an iterative approach | ![]() | ||||||||||||||||||||||
should improve cost estimation skills so as to account for the kinds of problems that may occur | ![]() | ||||||||||||||||||||||
should learn how to run effective meetings | ![]() | ||||||||||||||||||||||
should listen to everybody's opinion | ![]() | ||||||||||||||||||||||
should make sure that everybody has the information they need | ![]() | ||||||||||||||||||||||
should make sure that project information is readily available for browsing, e.g. using an Intranet web site | ![]() | ||||||||||||||||||||||
should monitor communication between team members | ![]() | ||||||||||||||||||||||
should realize that attention to quality of reusable components is essential so that potential re-users have confidence in them | ![]() | ||||||||||||||||||||||
should realize that developing and reusing reusable components improves reliability, and can foster a sense of confidence | ![]() | ||||||||||||||||||||||
should realize that developing reusable components will normally simplify the resulting design, independently of whether reuse actually occurs | ![]() | ||||||||||||||||||||||
should reward software developer for developing reusable components | ![]() | ||||||||||||||||||||||
should take assertive action, when needed, to ensure progress occurs | ![]() | ||||||||||||||||||||||
should take courses in negotiating skills, leadership, written and oral communication | ![]() | ||||||||||||||||||||||
should take into account a realistic assessment of the resources available when determining the requirements and the project plan | ![]() | ||||||||||||||||||||||
should use 'groupware' technology to help specific groups of people exchange the information they need to know | ![]() | ||||||||||||||||||||||
project plan | describes the overall process model | ![]() | |||||||||||||||||||||
describes the problem to be solved, as in the requirements document | ![]() | ||||||||||||||||||||||
describes the proposed team structure, the skills needed on that team, the plan for on-going training and the allocation of general responsibilities to team members | ![]() | ||||||||||||||||||||||
describes the risks and difficulties that are expected to be most critical to this project, or to specific subsystems and how they are to be monitored and resolved | ![]() | ||||||||||||||||||||||
describes the stakeholders | ![]() | ||||||||||||||||||||||
divides the system into subsystems and releases, that can be allocated to people or teams | ![]() | ||||||||||||||||||||||
gives a brief history of the project to date - you can update this as the project proceeds | ![]() | ||||||||||||||||||||||
gives references to related projects and any documents produced so far, such as requirements definitions | ![]() | ||||||||||||||||||||||
has definition A document used in project management describing all aspects of the project's process, including the process model, tasks, risks, cost estimates, team structure and schedule | ![]() | ||||||||||||||||||||||
includes Gantt and PERT charts showing the allocations of tasks to people, the periods of time they will work on each task, as well as the critical path(s) | ![]() | ||||||||||||||||||||||
includes the present cost estimates for the tasks and subsystems, showing all calculations, and including pessimistic and optimistic values | ![]() | ||||||||||||||||||||||
is a kind of document | ![]() | ||||||||||||||||||||||
is a subtopic of 11.6 - Contents of a Project Plan | ![]() | ||||||||||||||||||||||
lists the tasks to be completed for each subsystem and release | ![]() | ||||||||||||||||||||||
outlines the techniques to be employed for requirements gathering, design, implementation, quality assurance, change management; risk management, and ongoing project management; documents to be produced, including contents of these documents; ways to measure and track the project | ![]() | ||||||||||||||||||||||
states the business objectives for the project, including quantified anticipated benefits | ![]() | ||||||||||||||||||||||
should contain | ![]() | ||||||||||||||||||||||
project scheduling | has definition The process of deciding what sequence the various activities will be done, and when they should start and complete | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 11.4 - Building Software Engineering Teams | ![]() | ||||||||||||||||||||||
can use Gantt chart | ![]() | ||||||||||||||||||||||
can use PERT chart | ![]() | ||||||||||||||||||||||
project scheduling technique | is a kind of subject | ![]() | |||||||||||||||||||||
project that builds on framework or components | allows the developer to benefit from reusing software that has been shown to be reliable | ![]() | |||||||||||||||||||||
gives the developer much of the freedom to innovate that he or she would have if performing green field development | ![]() | ||||||||||||||||||||||
is a kind of software project | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
is becoming increasingly common | ![]() | ||||||||||||||||||||||
starts with a framework, or involves plugging together several components that are already developed and provide significant functionality | ![]() | ||||||||||||||||||||||
project where requirements have already been determined | is a kind of software project | ![]() | |||||||||||||||||||||
is a subtopic of 4.2 - The Starting Point for Software Projects | ![]() | ||||||||||||||||||||||
must be handled carefully because if the customer has not done a good job of analysis and specification, the requirements are likely to be poor | ![]() | ||||||||||||||||||||||
project where requirements must be determined | is a kind of software project | ![]() | |||||||||||||||||||||
is a subtopic of 4.2 - The Starting Point for Software Projects | ![]() | ||||||||||||||||||||||
propagation | has definition A mechanism whereby an operation in an aggregate is implemented by having the aggregate perform that operation on its parts - in other words, the operation is propagated to the parts | ![]() | |||||||||||||||||||||
has example the weight of an aggregate could be obtained by summing the weights of its parts | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
often occurs in aggregations | ![]() | ||||||||||||||||||||||
often results in the properties of the parts being propagated back to the aggregate | ![]() | ||||||||||||||||||||||
property | describes an object's current state | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 2.2 - Classes and Objects | ![]() | ||||||||||||||||||||||
protected | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java access control keyword | ![]() | ||||||||||||||||||||||
is used to declare protected method | ![]() | ||||||||||||||||||||||
protected method | is a kind of Java method | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can only be accessed by code in the same package as this class as well as code in any subclasses, even if they are not in the same package | ![]() | ||||||||||||||||||||||
protocol | has definition The languages and rules by which two programs or processes communicate, as in a client-server system | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
protocol design | has definition The design of communications protocols | ![]() | |||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
prototype | has benefit it is easily modified many times in response to feedback from users | ![]() | |||||||||||||||||||||
has definition A version of a system created primarily to learn more about the requirements, and not intended to be the final product | ![]() | ||||||||||||||||||||||
has purpose to gather requirements by allowing software engineers to obtain early feedback about their ideas | ![]() | ||||||||||||||||||||||
is a kind of system | ![]() | ||||||||||||||||||||||
is a subtopic of 1.8 - The Eight Themes Emphasized in this Book | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
is a synonym of pilot system | ![]() | ||||||||||||||||||||||
may be developed using a rapid prototyping language | ![]() | ||||||||||||||||||||||
may not perform any computations | ![]() | ||||||||||||||||||||||
should be produced early to get a view of potential problems | ![]() | ||||||||||||||||||||||
should not be turned into the final system since it will be hard to maintain, and will contain many bugs | ![]() | ||||||||||||||||||||||
usually contains part of the system's eventual functionality | ![]() | ||||||||||||||||||||||
prototyping | has definition The process of developing prototypes | ![]() | |||||||||||||||||||||
is a kind of requirements gathering | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
can help highlight potential ambiguities and misunderstandings in the requirements | ![]() | ||||||||||||||||||||||
can help resolve conflicts over requirements - when users actually use different prototypes they may change their preferences | ![]() | ||||||||||||||||||||||
can uncover invalid assumptions made in domain analysis or requirements analysis | ![]() | ||||||||||||||||||||||
proxy | has antipatterns Instead of using proxy objects, beginner designers often scatter complex code around their application to load objects from databases. A strategy that only works for very small systems is to load the whole database into memory when the program starts. | ![]() | |||||||||||||||||||||
has context
| ![]() | ||||||||||||||||||||||
has definition A pattern found in which a lightweight object stands in place of a heavyweight object that has the same interface. It transparently loads the heavyweight object when needed | ![]() | ||||||||||||||||||||||
has forces
| ![]() | ||||||||||||||||||||||
has problem How can you reduce the need to create instances of a heavyweight class? In particular, how can you reduce the need to load large numbers of them from a database or server, when not all of them will be needed? A related problem is this: If you load one object from a database or server, how can you avoid loading all the other objects that are linked to it. | ![]() | ||||||||||||||||||||||
has references one of the Gang of Four patterns | ![]() | ||||||||||||||||||||||
has related patterns several patterns that obtain their power from delegating responsibilities to other classes, hence it uses the Delegation pattern | ![]() | ||||||||||||||||||||||
has solution | ![]() | ||||||||||||||||||||||
is a subtopic of 6.12 - The Proxy Pattern | ![]() | ||||||||||||||||||||||
is an instance of design pattern | ![]() | ||||||||||||||||||||||
PSP | is a subtopic of 10.11 - Quality Assurance in General | ![]() | |||||||||||||||||||||
is an abbreviation for Personal Software Process | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
public | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java access control keyword | ![]() | ||||||||||||||||||||||
is used to declare a public class | ![]() | ||||||||||||||||||||||
is used to declare public method | ![]() | ||||||||||||||||||||||
public method | is a kind of Java method | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can be accessed by any code anywhere | ![]() | ||||||||||||||||||||||
publication | is a kind of subject | ![]() | |||||||||||||||||||||
pure virtual function | is a C++ abstract operation | ![]() | |||||||||||||||||||||
is a kind of operation | ![]() | ||||||||||||||||||||||
is a subtopic of 2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarations | ![]() | ||||||||||||||||||||||
purely decorative graphic | has advantages makes the interface more attractive and helps to emphasize its organization | ![]() | |||||||||||||||||||||
has problems
| ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
quality | has definition An attribute of a product or process that, if improved, would better satisfy one or more of the stakeholders of that product or service | ![]() | |||||||||||||||||||||
is a kind of criterion | ![]() | ||||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
quality assurance | has definition The process of ensuring that the quality of a product or process is sufficient to meet the needs of the stakeholders | ![]() | |||||||||||||||||||||
has part inspecting | ![]() | ||||||||||||||||||||||
has part reviewing | ![]() | ||||||||||||||||||||||
has part testing | ![]() | ||||||||||||||||||||||
has part validation | ![]() | ||||||||||||||||||||||
has part verification | ![]() | ||||||||||||||||||||||
has risk it is very easy to forget to test some aspects of a software system | ![]() | ||||||||||||||||||||||
has risk people have different abilities and knowledge when it comes to quality | ![]() | ||||||||||||||||||||||
has risk the conflict between achieving adequate quality levels, and 'getting the product out of the door' | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
is often seen as an overhead expense to be reduced | ![]() | ||||||||||||||||||||||
occurs throughout a project | ![]() | ||||||||||||||||||||||
quality assurance and testing standard | is a kind of standard | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
quality assurance | should be handled by a separate department | ![]() | |||||||||||||||||||||
race condition | has example one thread unexpectedly changes data that is being used by another thread, resulting in incorrect results | ![]() | |||||||||||||||||||||
has example two processes or threads normally work together to achieve some outcome; however if one is sped up or slowed down then the outcome is incorrect | ![]() | ||||||||||||||||||||||
is a synonym of critical race | ![]() | ||||||||||||||||||||||
can be prevented by using various mechanisms, such as semaphores, that allow data items to be locked so that they cannot be accessed by other threads when they are not ready | ![]() | ||||||||||||||||||||||
RAD | is a subtopic of 1.5 - Software Quality | ![]() | |||||||||||||||||||||
is an abbreviation for Rapid Applications Development | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
rapid prototyping language | has purpose to allows you to very quickly create code to display the important parts of a user interface, algorithm or database | ![]() | |||||||||||||||||||||
has weaknesses inefficiency, or limitations on your ability to create robust and flexible designs | ![]() | ||||||||||||||||||||||
is a kind of programming language | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
is not designed for creating the final version of complex systems | ![]() | ||||||||||||||||||||||
Rational Rose | has URL www.rational.com ![]() | ![]() | |||||||||||||||||||||
is the most widely used tool for drawing UML diagrams | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of tool for drawing UML diagrams | ![]() | ||||||||||||||||||||||
Rational Unified Process | is a subtopic of 5.1 - What is UML? | ![]() | |||||||||||||||||||||
is an instance of methodology | ![]() | ||||||||||||||||||||||
uses UML to represent models | ![]() | ||||||||||||||||||||||
rationale | has definition The reasoning underlying requirements or design decisions | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 4.8 - Reviewing Requirements | ![]() | ||||||||||||||||||||||
is a subtopic of 9.6 - Writing a Good Design Document | ![]() | ||||||||||||||||||||||
should be documented | ![]() | ||||||||||||||||||||||
read-only interface | has antipatterns making the read only class a subclass of the «Mutable» class, overriding all methods that modify properties, such that they throw an exception | ![]() | |||||||||||||||||||||
has context
| ![]() | ||||||||||||||||||||||
has definition A pattern in which an interface is used to restrict which classes have privileges to call update methods of a class | ![]() | ||||||||||||||||||||||
has forces | ![]() | ||||||||||||||||||||||
has problem How do you create a situation where some classes see a class as read-only (i.e. the class is immutable) whereas others are able to make modifications? | ![]() | ||||||||||||||||||||||
has solution
| ![]() | ||||||||||||||||||||||
is a subtopic of 6.11 - The Read-Only Interface Pattern | ![]() | ||||||||||||||||||||||
is an instance of design pattern | ![]() | ||||||||||||||||||||||
readObject | is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | |||||||||||||||||||||
is an instance of Java method | ![]() | ||||||||||||||||||||||
is used in client-server systems | ![]() | ||||||||||||||||||||||
waits until an object is received over the socket, or until an I/O error occurs, which will happen if the program at the other end of the connection is terminated | ![]() | ||||||||||||||||||||||
real-time software | has concern safety | ![]() | |||||||||||||||||||||
has definition Software that must react immediately to stimuli from the environment | ![]() | ||||||||||||||||||||||
has design issue responsiveness | ![]() | ||||||||||||||||||||||
has purpose to operate special-purpose hardware such as embedded systems, industrial plants and telephone networks | ![]() | ||||||||||||||||||||||
is a kind of software | ![]() | ||||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
is a subtopic of 10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races | ![]() | ||||||||||||||||||||||
realistic requirement | has definition A requirement that the development team has the expertise and technology to implement on the required platform within the budget and time available | ![]() | |||||||||||||||||||||
is a kind of requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.8 - Reviewing Requirements | ![]() | ||||||||||||||||||||||
record | is a kind of data abstraction | ![]() | |||||||||||||||||||||
is a subtopic of 2.1 - What is Object Orientation? | ![]() | ||||||||||||||||||||||
recovery from failure | has example for a word processing program: The system will allow users to continue their work after a failure with the loss of no more than 20 words of typing or 20 formatting commands | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of non-functional requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
is specified as the maximum-allowed impact of a failure | ![]() | ||||||||||||||||||||||
reducing coupling | is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | |||||||||||||||||||||
is an instance of design principle | ![]() | ||||||||||||||||||||||
reengineering | has definition A type of maintenance performed to improve the design of some part of a software system, in general so that it has higher maintainability. In general, no new features are added for users | ![]() | |||||||||||||||||||||
has part forward engineering | ![]() | ||||||||||||||||||||||
has part refactoring | ![]() | ||||||||||||||||||||||
has purpose to increase maintainability of a system | ![]() | ||||||||||||||||||||||
includes | ![]() | ||||||||||||||||||||||
is a kind of maintenance | ![]() | ||||||||||||||||||||||
is a kind of software engineering | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
reduces long-term costs | ![]() | ||||||||||||||||||||||
reengineering project | involves changing the system internally so that it is more maintainable, without making significant changes that the user will notice | ![]() | |||||||||||||||||||||
is a kind of evolutionary project | ![]() | ||||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
reengineering | should make the system more amenable to adding features in the future | ![]() | |||||||||||||||||||||
should not include adding any new features for users | ![]() | ||||||||||||||||||||||
refactoring | has definition Changing part of the design; performed as part of reengineering | ![]() | |||||||||||||||||||||
is a kind of maintenance | ![]() | ||||||||||||||||||||||
is a kind of software engineering | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
is part of reengineering | ![]() | ||||||||||||||||||||||
reference | has definition A variable that refers to an object | ![]() | |||||||||||||||||||||
is a kind of variable | ![]() | ||||||||||||||||||||||
is a subtopic of 2.3 - Instance Variables | ![]() | ||||||||||||||||||||||
reflexive association | has definition An association in which both ends connect to the same class | ![]() | |||||||||||||||||||||
is a kind of association | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
regression test case | is a kind of test case | ![]() | |||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
must cover as much of the system as possible | ![]() | ||||||||||||||||||||||
regression testing | has definition The process of re-testing the a system, using a selected subset of test cases, after changes are made | ![]() | |||||||||||||||||||||
has purpose to test software again once some defects have been fixed in case new defects have been inadvertently added | ![]() | ||||||||||||||||||||||
is a kind of testing performed by software engineers | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
tests a subset of the previously successful test cases because it tends to be far too expensive to re-run every single test case every time a change is made to software | ![]() | ||||||||||||||||||||||
related pattern | has definition A pattern that are similar to another pattern | ![]() | |||||||||||||||||||||
is a kind of design pattern | ![]() | ||||||||||||||||||||||
is a subtopic of 6.1 - Introduction to Patterns | ![]() | ||||||||||||||||||||||
is part of design pattern | ![]() | ||||||||||||||||||||||
relation | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
release | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
release notes | has definition A document describing a particular release of software, including a known bugs list | ![]() | |||||||||||||||||||||
is a kind of document | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
reliability | depends on the number of mistakes made by the software engineers who developed the software | ![]() | |||||||||||||||||||||
has definition An important quality of software that measures the frequency of failures, as encountered by testers and end-users | ![]() | ||||||||||||||||||||||
is more important than efficiency in a safety-critical system | ![]() | ||||||||||||||||||||||
is a kind of external software quality | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of non-functional requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
is a subtopic of 10.1 - Basic Definitions | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
is affected by complexity of code | ![]() | ||||||||||||||||||||||
is affected indirectly by commenting | ![]() | ||||||||||||||||||||||
is specified as the average amount of time between failures or the probability of a failure in a given period | ![]() | ||||||||||||||||||||||
can be improved by ensuring the software is easy to implement and change, and also ensuring that if failures occur, the system can handle them or can recover easily | ![]() | ||||||||||||||||||||||
remote display system | has clients programs that want to display information on the screen, such as X-Windows | ![]() | |||||||||||||||||||||
has server a program that manages the screen and allows applications, perhaps running on other computers, to display their output, such as a Unix X-Windows server | ![]() | ||||||||||||||||||||||
is a kind of client-server system | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
rendezvous | has multiple incoming transitions | ![]() | |||||||||||||||||||||
has multiple outgoing transitions that must be triggered in separate threads once all the incoming transitions are triggered | ![]() | ||||||||||||||||||||||
has definition In concurrent programming, a situation where several threads meet and wait for each other | ![]() | ||||||||||||||||||||||
is a kind of symbol in activity diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 8.3 - Activity Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a short line at which transitions can start and end | ![]() | ||||||||||||||||||||||
representation | is a kind of subject | ![]() | |||||||||||||||||||||
requirement | changes regularly | ![]() | |||||||||||||||||||||
has definition A statement about what the proposed system will do that all stakeholders agree must be made true in order for the customer's problem to be adequately solved | ![]() | ||||||||||||||||||||||
has part problem statement | ![]() | ||||||||||||||||||||||
indicates how the system is to behave | ![]() | ||||||||||||||||||||||
is concise | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 4.4 - What Is a Requirement? | ![]() | ||||||||||||||||||||||
is expressed as a fact | ![]() | ||||||||||||||||||||||
is grouped with other requirements into a requirements document | ![]() | ||||||||||||||||||||||
is normally expressed in a natural language such as English (using present tense and active voice), sometimes supplemented by a formal mathematical language, and often by some form of diagram | ![]() | ||||||||||||||||||||||
can be gathered from various stakeholders, other software systems and any documentation that might be available | ![]() | ||||||||||||||||||||||
does not describe how the system will be implemented | ![]() | ||||||||||||||||||||||
does not describe the domain | ![]() | ||||||||||||||||||||||
may be given a unique number for traceability | ![]() | ||||||||||||||||||||||
may be shown as a diagram | ![]() | ||||||||||||||||||||||
must be agreed upon by all stakeholders | ![]() | ||||||||||||||||||||||
should be important for the solution of the current problem | ![]() | ||||||||||||||||||||||
should be logically consistent | ![]() | ||||||||||||||||||||||
should be realistic with available resources | ![]() | ||||||||||||||||||||||
should be unambiguous | ![]() | ||||||||||||||||||||||
should be uniquely identifiable | ![]() | ||||||||||||||||||||||
should be verifiable | ![]() | ||||||||||||||||||||||
should be analysed if there is any doubt whether it is realistic | ![]() | ||||||||||||||||||||||
should be changed whenever the benefits of doing so outweigh the costs | ![]() | ||||||||||||||||||||||
should be cut if cost-benefit analysis shows that it will have minimum benefit but still cost a lot to develop | ![]() | ||||||||||||||||||||||
should be expressed using clear and consistent notation, using language that the customers can understand, and consistent with the other requirements | ![]() | ||||||||||||||||||||||
should have benefits that outweigh the costs of development | ![]() | ||||||||||||||||||||||
should help solve a customer's problem | ![]() | ||||||||||||||||||||||
should lead to a system of sufficient quality - one that is sufficiently usable, safe, efficient, reliable and maintainable | ![]() | ||||||||||||||||||||||
should not indicate how it will be implemented in order to give the designer as much freedom as possible to make decisions | ![]() | ||||||||||||||||||||||
should not over-constrain the design of the system | ![]() | ||||||||||||||||||||||
requirement stability | has definition A measure of the extent to which requirements are likely to change | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
requirements analysis | determines the responsibilities of a system | ![]() | |||||||||||||||||||||
has definition The process of deciding on the requirements of a software system | ![]() | ||||||||||||||||||||||
has part modelling | ![]() | ||||||||||||||||||||||
has part use case analysis | ![]() | ||||||||||||||||||||||
has risk
| ![]() | ||||||||||||||||||||||
has typical mistake over-constraint | ![]() | ||||||||||||||||||||||
includes defining the problem to be solved and what software will be created to solve it | ![]() | ||||||||||||||||||||||
is a kind of analysis | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
is part of requirements and specification | ![]() | ||||||||||||||||||||||
is performed after domain analysis | ![]() | ||||||||||||||||||||||
never stops | ![]() | ||||||||||||||||||||||
should continue throughout the life of a software system | ![]() | ||||||||||||||||||||||
requirements and specification | has part defining the problem | ![]() | |||||||||||||||||||||
has part domain analysis | ![]() | ||||||||||||||||||||||
has part requirements analysis | ![]() | ||||||||||||||||||||||
has part requirements gathering | ![]() | ||||||||||||||||||||||
has part requirements specification | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
requirements churn | is a kind of quality | ![]() | |||||||||||||||||||||
is a subtopic of 4.12 - Difficulties and Risks In Domain and Requirements Analysis | ![]() | ||||||||||||||||||||||
is caused by rapid changes in requirements | ![]() | ||||||||||||||||||||||
can be avoided by incremental development, building flexibility into the design, regular reviews of the requirements and, above all, always working with a respect for the inevitability of change | ![]() | ||||||||||||||||||||||
requirements creep | has definition The tendency for the set of requirements to relentlessly increase in size during the course of development, resulting in a system that is more expensive and complex than originally intended | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 4.9 - Managing Changing Requirements | ![]() | ||||||||||||||||||||||
occurs when changes to a system are really enhancements in disguise | ![]() | ||||||||||||||||||||||
can be avoided by
| ![]() | ||||||||||||||||||||||
may result in very significant cost overruns in projects | ![]() | ||||||||||||||||||||||
requirements definition | has definition A high-level requirements document that describes requirements using language understandable by customers and end users | ![]() | |||||||||||||||||||||
is a kind of requirements document | ![]() | ||||||||||||||||||||||
is a subtopic of 4.7 - Types of Requirements Document | ![]() | ||||||||||||||||||||||
requirements document | contains functional and non-functional requirements | ![]() | |||||||||||||||||||||
depends on
| ![]() | ||||||||||||||||||||||
forms the basis for testing the system | ![]() | ||||||||||||||||||||||
goes through several iterations of development and review | ![]() | ||||||||||||||||||||||
has version number | ![]() | ||||||||||||||||||||||
has definition Any document describing a set of requirements | ![]() | ||||||||||||||||||||||
has part functional requirements | ![]() | ||||||||||||||||||||||
has part non-functional requirements | ![]() | ||||||||||||||||||||||
has parts a clear title, and sections with meaningful headings and subheadings | ![]() | ||||||||||||||||||||||
is definitive only when all the stakeholders agree they are to be implemented | ![]() | ||||||||||||||||||||||
is a kind of document | ![]() | ||||||||||||||||||||||
is a subtopic of 4.7 - Types of Requirements Document | ![]() | ||||||||||||||||||||||
is subject to change caused by:
| ![]() | ||||||||||||||||||||||
requirements document derived from use cases | is a kind of requirements document | ![]() | |||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
tends to mirror mirror the way users worked before the software was developed | ![]() | ||||||||||||||||||||||
does not usually lead to innovative solutions | ![]() | ||||||||||||||||||||||
requirements document for a large system | consists of a series of documents arranged in a hierarchy | ![]() | |||||||||||||||||||||
is more detailed than the requirements document for a small system because there is more to say and because the system will need to be divided into subsystems so that different teams can work on each part | ![]() | ||||||||||||||||||||||
is a kind of requirements document | ![]() | ||||||||||||||||||||||
is a subtopic of 4.7 - Types of Requirements Document | ![]() | ||||||||||||||||||||||
requirements document | must be written at a high-enough level so that the potential users can read it | ![]() | |||||||||||||||||||||
must not be too large at an early stage in requirements gathering because the risk that these will have to be completely re-written is too great | ![]() | ||||||||||||||||||||||
should be sufficiently complete | ![]() | ||||||||||||||||||||||
should be well designed so its structure can be easily understood, so it can be quickly scanned and so any given requirement can be easily found | ![]() | ||||||||||||||||||||||
should be well organized | ![]() | ||||||||||||||||||||||
should be agreed to by all the stakeholders | ![]() | ||||||||||||||||||||||
should be reviewed by the author and stakeholders | ![]() | ||||||||||||||||||||||
should be updated when incremental changes are made to the system | ![]() | ||||||||||||||||||||||
should contain rationale for all requirements that involve a large amount of analysis, that are controversial or for which several alternatives are considered, so that software engineers in the future do not have to repeat your analysis when they make changes, the reader is convinced that you did in fact consider the alternatives, and the reader is alerted to the fact that the requirement may be controversial | ![]() | ||||||||||||||||||||||
should have sections
| ![]() | ||||||||||||||||||||||
should have changes in each new version highlighted for the reader using change bars | ![]() | ||||||||||||||||||||||
should not contain requirements in the introduction and conclusion to avoid the problem of changing the requirements in one place and forgetting to change them in another place | ![]() | ||||||||||||||||||||||
requirements elicitation | has definition The process of actively asking stakeholders to describe their view of the requirements; an important aspect of requirements gathering | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
is part of requirements gathering | ![]() | ||||||||||||||||||||||
Requirements Engineering and Rapid Development: An Object-Oriented Approach | has author I. Graham, L. Graham | ![]() | |||||||||||||||||||||
has ISBN number 0-201-36047-0 | ![]() | ||||||||||||||||||||||
is a subtopic of 4.13 - Developing Requirements - References | ![]() | ||||||||||||||||||||||
is an instance of book about requirements analysis | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1998 | ![]() | ||||||||||||||||||||||
Requirements Engineering Specialists Group of the British Computer Society | has URL www.resg.org.uk ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 4.13 - Developing Requirements - References | ![]() | ||||||||||||||||||||||
is an instance of web site about requirements analysis | ![]() | ||||||||||||||||||||||
requirements gathering | has definition A step in requirements analysis in which information is obtained that will form the basis of the requirements | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
is part of requirements and specification | ![]() | ||||||||||||||||||||||
requirements principle | is a kind of principle | ![]() | |||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
states separate the 'what' from the 'how'. The 'what' refers to the requirements - what is needed to solve the problem. The 'how' refers to how the solution will be designed and implemented. | ![]() | ||||||||||||||||||||||
requirements review | culminates in a formal requirements review meeting at which all stakeholders are present | ![]() | |||||||||||||||||||||
has definition The process of systematically evaluating a requirements document | ![]() | ||||||||||||||||||||||
is a kind of reviewing | ![]() | ||||||||||||||||||||||
is a subtopic of 4.7 - Types of Requirements Document | ![]() | ||||||||||||||||||||||
requirements specialist | is a kind of software developer | ![]() | |||||||||||||||||||||
is a subtopic of 1.4 - Stakeholders in Software Engineering | ![]() | ||||||||||||||||||||||
is part of software development team | ![]() | ||||||||||||||||||||||
requirements specification | consists of writing a precise set of instructions that define what the software should do, including how the software behaves from the perspective of the user, but no details of the implementation | ![]() | |||||||||||||||||||||
determines the interface of any component built to implement a system | ![]() | ||||||||||||||||||||||
has definition A specification of requirements; i.e. a requirements document that is more detailed than a requirements definition | ![]() | ||||||||||||||||||||||
is a kind of specification | ![]() | ||||||||||||||||||||||
is a subtopic of 4.7 - Types of Requirements Document | ![]() | ||||||||||||||||||||||
is a synonym of design specification | ![]() | ||||||||||||||||||||||
is part of requirements and specification | ![]() | ||||||||||||||||||||||
resource | has definition Anything consumed in the development, operation or maintenance of a product or process | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
resource usage | allows others to efficiently plan hardware upgrades | ![]() | |||||||||||||||||||||
has example you could specify that no more than a certain amount of memory is to be used by the system, and that the system must consume less than 10% of the CPU's time | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of non-functional requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
is specified in terms of the maximum amount of these resources that the system will consume | ![]() | ||||||||||||||||||||||
response time | has definition The time that elapses from when a user issues a command to when the system provides enough results so the user can continue his or her work | ![]() | |||||||||||||||||||||
is acceptable if it is at least as fast as other applications that users are accustomed to | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of non-functional requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
can be a problem due to the need to load information over a network or process large volumes of information | ![]() | ||||||||||||||||||||||
may be up to about 15-20 seconds for operations such as loading complex pages from the net over a modem-based connection if the user understands that they are naturally time-consuming and an indication of progress is shown | ![]() | ||||||||||||||||||||||
should appear instantaneous for some operations such as tracking the cursor, popping up of menus and echoing of input | ![]() | ||||||||||||||||||||||
should be a second or less for operations such as saving most data, moving between windows, obtaining help, and obtaining the first feedback from any longer operation | ![]() | ||||||||||||||||||||||
should be evaluated on the slowest hardware that end-users are likely to encounter | ![]() | ||||||||||||||||||||||
should not be more than 15-20 seconds unless the user interface warns the user so the user can do something else while waiting or choose not to perform the operation | ![]() | ||||||||||||||||||||||
responsibility | has definition Something a system is required to do that is allocated to a particular class | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is carried out by operation | ![]() | ||||||||||||||||||||||
can be found by looking for verbs and nouns describing actions in the system description | ![]() | ||||||||||||||||||||||
may require several operations but one public operation will be in charge, all others will be private | ![]() | ||||||||||||||||||||||
must be attributed to a class | ![]() | ||||||||||||||||||||||
responsibility of a class | is a kind of responsibility | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
should be related to all other responsibilities of that class | ![]() | ||||||||||||||||||||||
restricting access | controls access to methods, instance variables and class variables | ![]() | |||||||||||||||||||||
is good | ![]() | ||||||||||||||||||||||
is a kind of practice | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is part of encapsulation | ![]() | ||||||||||||||||||||||
makes code easier to understand and change | ![]() | ||||||||||||||||||||||
makes designs more flexible | ![]() | ||||||||||||||||||||||
reduces coupling | ![]() | ||||||||||||||||||||||
return | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
reusability | has definition A quality that measures of the extent to which a product or process can be used in different contexts from which it was originally designed | ![]() | |||||||||||||||||||||
is a kind of external software quality | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 3.2 - Incorporating Reusability and Reuse Into Software Engineering | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is constrained by software architecture | ![]() | ||||||||||||||||||||||
reusable component | has definition A piece of software, such as a library, command, framework or application that is reused in a software system | ![]() | |||||||||||||||||||||
is a kind of component | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
is usually more reliable than software not designed to be reused because it is tested in all the systems it is used in, and because it is used in different contexts, exposing any weak points | ![]() | ||||||||||||||||||||||
simplifies the design of software systems | ![]() | ||||||||||||||||||||||
will be of high quality if its designer followed the same steps as the development of complete applications: domain and requirements analysis, design, documentation, testing and inspection, and if a software engineer is available to properly maintain it | ![]() | ||||||||||||||||||||||
will be reused if it is of high quality | ![]() | ||||||||||||||||||||||
reusable component developer | builds confidence in the reusable technology by
| ![]() | |||||||||||||||||||||
develops software components that are intended to be reused | ![]() | ||||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 3.2 - Incorporating Reusability and Reuse Into Software Engineering | ![]() | ||||||||||||||||||||||
overcomes competition with other developers of reusable components by:
| ![]() | ||||||||||||||||||||||
uses a catalog of reusable components to find appropriate components | ![]() | ||||||||||||||||||||||
must catalog reusable components so that software engineers will be able to find them | ![]() | ||||||||||||||||||||||
must document reusable components so that software engineers will be able to use them easily | ![]() | ||||||||||||||||||||||
must follow good software engineering practices | ![]() | ||||||||||||||||||||||
must provide support for the components after they are developed | ![]() | ||||||||||||||||||||||
should follow the same steps as the development of complete applications: domain and requirements analysis, design, documentation, testing and inspection | ![]() | ||||||||||||||||||||||
should monitor the success or failure of the reusable software so you can improve your investment decisions in future projects | ![]() | ||||||||||||||||||||||
should plan the development of the reusable technology, in the same manner as if it were a product for a client | ![]() | ||||||||||||||||||||||
reusable component development | has benefits
| ![]() | |||||||||||||||||||||
has risks
| ![]() | ||||||||||||||||||||||
is a kind of development | ![]() | ||||||||||||||||||||||
is a subtopic of 3.2 - Incorporating Reusability and Reuse Into Software Engineering | ![]() | ||||||||||||||||||||||
should follow the same steps as the development of complete applications: domain and requirements analysis, design, documentation, testing and inspection | ![]() | ||||||||||||||||||||||
reusable component | must be cataloged | ![]() | |||||||||||||||||||||
must be documented | ![]() | ||||||||||||||||||||||
must have software engineer available to properly maintain it | ![]() | ||||||||||||||||||||||
reusable software | is flexible | ![]() | |||||||||||||||||||||
is understandable | ![]() | ||||||||||||||||||||||
is well documented | ![]() | ||||||||||||||||||||||
is a kind of program | ![]() | ||||||||||||||||||||||
is a subtopic of 3.1 - Reuse: Building on the Work and Experience of Others | ![]() | ||||||||||||||||||||||
was designed to facilitate reuse | ![]() | ||||||||||||||||||||||
can be used in a variety of different systems | ![]() | ||||||||||||||||||||||
reuse | has definition The practice of using the same code or design in more than one place | ![]() | |||||||||||||||||||||
has purpose to reduce the large cost associated with developing the same thing over and over again | ![]() | ||||||||||||||||||||||
has risks
| ![]() | ||||||||||||||||||||||
is one of the keys to successful software development | ![]() | ||||||||||||||||||||||
is a kind of practice | ![]() | ||||||||||||||||||||||
is a subtopic of 3.2 - Incorporating Reusability and Reuse Into Software Engineering | ![]() | ||||||||||||||||||||||
is not a strong part of the development culture of many organizations | ![]() | ||||||||||||||||||||||
is not as extensive in software engineering projects as might be desirable | ![]() | ||||||||||||||||||||||
can occur if software developers reuse existing good-quality components, and also contribute to reusable components that others can use | ![]() | ||||||||||||||||||||||
may be prevented because of a vicious circle: Developers do not develop high quality reusable components, so there is nothing to reuse. Since there is nothing to reuse, software developers take so much time to develop applications that they lack time to invest in reusable frameworks or libraries | ![]() | ||||||||||||||||||||||
may not be practised because
| ![]() | ||||||||||||||||||||||
reuse of applications | involves taking complete applications and adapting them to the needs of the client by adding a small amount of extra software that makes the applications behave in special ways the client wants | ![]() | |||||||||||||||||||||
is a kind of reuse | ![]() | ||||||||||||||||||||||
is a subtopic of 3.1 - Reuse: Building on the Work and Experience of Others | ![]() | ||||||||||||||||||||||
reuse of classes and commands | is a kind of reuse | ![]() | |||||||||||||||||||||
is a subtopic of 3.1 - Reuse: Building on the Work and Experience of Others | ![]() | ||||||||||||||||||||||
takes advantage of libraries of classes or procedures, or of powerful commands built into languages and operating systems which represent implemented algorithms, data structures and other facilities | ![]() | ||||||||||||||||||||||
reuse of commercial off-the-shelf software | has example take a standard email application and add a feature that would always update the 'address book' with data from the corporate employee and client databases | ![]() | |||||||||||||||||||||
is a kind of reuse of applications | ![]() | ||||||||||||||||||||||
is a subtopic of 3.1 - Reuse: Building on the Work and Experience of Others | ![]() | ||||||||||||||||||||||
reuse of expertise | is a kind of reuse | ![]() | |||||||||||||||||||||
is a subtopic of 3.1 - Reuse: Building on the Work and Experience of Others | ![]() | ||||||||||||||||||||||
takes advantage of software engineers who have many years of experience working on projects and who can often save considerable time when it comes to developing new systems because they do not need to re-think many issues: their past experience tells them what needs to be done | ![]() | ||||||||||||||||||||||
reuse of frameworks | is a kind of reuse | ![]() | |||||||||||||||||||||
is a subtopic of 3.1 - Reuse: Building on the Work and Experience of Others | ![]() | ||||||||||||||||||||||
reuse of standard designs and algorithms | is a kind of reuse | ![]() | |||||||||||||||||||||
is a subtopic of 3.1 - Reuse: Building on the Work and Experience of Others | ![]() | ||||||||||||||||||||||
takes advantage of algorithms and other aspects of designs described in various books, standards documents and articles | ![]() | ||||||||||||||||||||||
reusing existing designs and code where possible | has advantage it allows you to take advantage of the investment you or others have made in reusable components | ![]() | |||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is an instance of design principle | ![]() | ||||||||||||||||||||||
reviewing | has definition The process of systematically proceeding through a software document to perform a function such as validation, or verification | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 4.8 - Reviewing Requirements | ![]() | ||||||||||||||||||||||
ripple effect | has definition The situation in which removing defects causes new ones to be added | ![]() | |||||||||||||||||||||
is a kind of quality | ![]() | ||||||||||||||||||||||
risk management | has definition The process of evaluating risks and taking corrective action, including revising plans, on a regular basis | ![]() | |||||||||||||||||||||
has part risk analysis | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.8 - The Eight Themes Emphasized in this Book | ![]() | ||||||||||||||||||||||
role | acts as an alternative name for the class to which it is attached | ![]() | |||||||||||||||||||||
has definition A name given to one end of an association that acts as a synonym for the class at that end | ![]() | ||||||||||||||||||||||
is a kind of label | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
labels an association | ![]() | ||||||||||||||||||||||
can be attached to either or both ends of an association | ![]() | ||||||||||||||||||||||
role^2 | has definition A class in the player-role pattern whose instances can be attached to player objects | ![]() | |||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of 6.4 - The Player-Role Pattern | ![]() | ||||||||||||||||||||||
root cause analysis | has definition The process of determining the ultimate reason why a software engineer made the error introduced a defect | ![]() | |||||||||||||||||||||
has objective to determine why a software engineer made the error that resulted in a defect occurring | ![]() | ||||||||||||||||||||||
is a kind of analysis | ![]() | ||||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
routine call coupling | has definition A form of coupling in which one routine calls another | ![]() | |||||||||||||||||||||
is always present in an object oriented system | ![]() | ||||||||||||||||||||||
is a kind of coupling | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
can be reduced by reducing the total number of routines that a particular class or package calls: If you use a sequence of two or more methods to compute something, and this sequence is used in more than one place, then you can reduce routine call coupling by writing a single routine that encapsulates the sequence | ![]() | ||||||||||||||||||||||
rule | has definition A principle that should almost always be applied | ![]() | |||||||||||||||||||||
is a kind of principle | ![]() | ||||||||||||||||||||||
Runnable | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java interface | ![]() | ||||||||||||||||||||||
safety critical system | has example systems that control industrial processes, vehicles, telecommunications networks, medical equipment and many consumer devices | ![]() | |||||||||||||||||||||
is a kind of system | ![]() | ||||||||||||||||||||||
is a subtopic of 4.7 - Types of Requirements Document | ![]() | ||||||||||||||||||||||
must have its requirements subjected to rigorous analysis and review | ![]() | ||||||||||||||||||||||
should be precisely specified if it could jeopardize safety or the environment if it fails | ![]() | ||||||||||||||||||||||
sandwich testing | combines bottom-up testing and top-down testing | ![]() | |||||||||||||||||||||
has definition An incremental testing strategy in which you test the top layers and bottom layers, and finally test the integrated system | ![]() | ||||||||||||||||||||||
has procedure | ![]() | ||||||||||||||||||||||
is a kind of vertical incremental testing | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
is a synonym of mixed testing | ![]() | ||||||||||||||||||||||
may be the most effective form of integration testing for many systems | ![]() | ||||||||||||||||||||||
scenario | clarifies the associated use case | ![]() | |||||||||||||||||||||
has definition An instance of a use case that expresses a specific occurrence of the use case with a specific actor operating at a specific time and using specific data | ![]() | ||||||||||||||||||||||
is a kind of representation | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
schedule | has definition The allocation of tasks to time periods | ![]() | |||||||||||||||||||||
is a kind of representation | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
schedule^2 | has definition The total elapsed time of a project | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
scheduling | has definition Determining the sequence of tasks, plus deciding when the tasks should start, and setting deadlines for when they must be complete | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 11.1 - What is Project Management? | ![]() | ||||||||||||||||||||||
is a subtopic of 11.5 - Project Scheduling and Tracking | ![]() | ||||||||||||||||||||||
scientist | has definition A person who seeks new knowledge about nature (in contrast to engineer) | ![]() | |||||||||||||||||||||
has role to seek out new knowledge | ![]() | ||||||||||||||||||||||
is a kind of person | ![]() | ||||||||||||||||||||||
is a subtopic of 1.8 - The Eight Themes Emphasized in this Book | ![]() | ||||||||||||||||||||||
scope | has definition The region of a source text over which a declaration holds | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
scope of a Java class variable | is a kind of scope of a variable | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is defined by the public, private and protected keywords | ![]() | ||||||||||||||||||||||
scope of a Java instance variable | is a kind of scope of a variable | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is defined by the public, private and protected keywords | ![]() | ||||||||||||||||||||||
scope of a variable | consists of the parts of the source code in which reference to the variable can be made | ![]() | |||||||||||||||||||||
is a kind of scope | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
scope of a variable defined in a block | is a kind of scope of a variable | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is defined by the start and end of the block | ![]() | ||||||||||||||||||||||
scope^2 | has definition The extent of a software project | ![]() | |||||||||||||||||||||
is broad if the problem is broad or contains a long list of subproblems | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 4.3 - Defining The Problem and the Scope | ![]() | ||||||||||||||||||||||
can be narrowed by excluding subproblems | ![]() | ||||||||||||||||||||||
may be too narrow if the problem statement is inappropriate | ![]() | ||||||||||||||||||||||
may be wrong if the problem statement is inappropriate | ![]() | ||||||||||||||||||||||
should be defined as early as possible | ![]() | ||||||||||||||||||||||
scripting language | is a kind of programming language | ![]() | |||||||||||||||||||||
is a subtopic of 3.1 - Reuse: Building on the Work and Experience of Others | ![]() | ||||||||||||||||||||||
is interpreted | ![]() | ||||||||||||||||||||||
scroll bar | is a kind of user interface component | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
selecting a menu item | is a kind of command | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
semaphore | has definition A mechanism that allow data items to be locked so that they cannot be accessed by other threads when they are not ready | ![]() | |||||||||||||||||||||
is a kind of mechanism | ![]() | ||||||||||||||||||||||
is a subtopic of 10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races | ![]() | ||||||||||||||||||||||
can prevent race conditions | ![]() | ||||||||||||||||||||||
sequence diagram | arranges objects from left to right across the diagram with an actor that initiates the interaction often shown on the left | ![]() | |||||||||||||||||||||
has definition A UML interaction diagram showing the sequence of messages exchanged by the set of objects and optionally an actor. Actors and objects are on one axis, and time is on the other | ![]() | ||||||||||||||||||||||
has part activation box | ![]() | ||||||||||||||||||||||
has part iteration expression | ![]() | ||||||||||||||||||||||
has part lifeline | ![]() | ||||||||||||||||||||||
is better than collaboration diagram when:
| ![]() | ||||||||||||||||||||||
is a kind of interaction diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
represents iteration over objects by preceding the message name with an asterisk, and showing an iteration expression in square brackets | ![]() | ||||||||||||||||||||||
represents message as an arrow between activation boxes of the sender and receiver | ![]() | ||||||||||||||||||||||
represents time as the vertical dimension with time progressing downwards to the bottom of the diagram | ![]() | ||||||||||||||||||||||
shows the destruction of an object using a big 'X' symbol on a lifeline | ![]() | ||||||||||||||||||||||
shows the sequence of messages exchanged by the set of objects (and optionally an actor) performing a certain task | ![]() | ||||||||||||||||||||||
sequential cohesion | has definition A form of cohesion in which a series of procedures, where one provides input to the next, are kept together | ![]() | |||||||||||||||||||||
is a strong form of temporal cohesion | ![]() | ||||||||||||||||||||||
is less important than communicational cohesion since different data types may be involved in the different stages of a sequentially cohesive module | ![]() | ||||||||||||||||||||||
is stronger than procedural cohesion | ![]() | ||||||||||||||||||||||
is a kind of cohesion | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is achieved when a series of procedures, in which one procedure provides input to the next, are kept together - and everything else is kept out | ![]() | ||||||||||||||||||||||
sequentially cohesive module | contains nothing other than the set of procedures that co-operate with another module, where one provides input to the next | ![]() | |||||||||||||||||||||
is a kind of cohesive module | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
serialization | has definition A process in Java by which every object is converted by an ObjectOutputStream into a binary form for transmission, and then reconstructed when it is received by an ObjectInputStream | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is used to save objects into a binary file | ![]() | ||||||||||||||||||||||
server | accepts connections from clients, normally involving some form of validation to ensure that the client is allowed to connect. | ![]() | |||||||||||||||||||||
continues to serve currently connected clients after it has stopped listening | ![]() | ||||||||||||||||||||||
disconnects clients - the client may request disconnection by sending a message to the server, the client may just disappear suddenly due to the client crashing or the network connecting going down, or the server may force a client to disconnect if the client is not behaving well | ![]() | ||||||||||||||||||||||
does concurrently | ![]() | ||||||||||||||||||||||
has definition A program or process that, in response to requests from clients, provides some kind of service | ![]() | ||||||||||||||||||||||
is a kind of process^2 | ![]() | ||||||||||||||||||||||
is a kind of program | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
keeps a record of the connection while a client is connected | ![]() | ||||||||||||||||||||||
listens for clients attempting to connect | ![]() | ||||||||||||||||||||||
reacts to messages from connected clients: performing computations or obtaining information, and normally sending some information back to the requesting client and perhaps sending a message to another client or broadcasting messages to many clients at once. | ![]() | ||||||||||||||||||||||
stops listening if the number of connected clients becomes too high, or prior to shutting down | ![]() | ||||||||||||||||||||||
terminates when necessary, which involves such actions as notifying each client before terminating its connection | ![]() | ||||||||||||||||||||||
will not accept new client connections if it has stopped listening | ![]() | ||||||||||||||||||||||
can also be a client at the same time | ![]() | ||||||||||||||||||||||
may be accessed by many clients simultaneously | ![]() | ||||||||||||||||||||||
may be located on the same computer as its clients or on a different computer | ![]() | ||||||||||||||||||||||
must be able to handle connections from many clients | ![]() | ||||||||||||||||||||||
must be able to respond to messages from all the connected clients | ![]() | ||||||||||||||||||||||
must initialize itself so that it is able to provide the required service | ![]() | ||||||||||||||||||||||
server socket | ServerSocket class | ![]() | |||||||||||||||||||||
has definition Data in a server used to generate connections on a port | ![]() | ||||||||||||||||||||||
is a kind of socket | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
server | usually operates with at least two concurrent threads, and in general n+2, threads where n is the number of connected clients | ![]() | |||||||||||||||||||||
ServerSocket class | has example of accepting a connection the server must have a thread constantly listening for connections using a statement like the following, embedded in a loop: Socket clientSocket = serverSocket.accept(); The above statement will wait indefinitely in the accept method until a client tries to connect, then it will try to create an instance of Socket class to handle the new connection. If this is successful both client and server now have instances of Socket class and can communicate freely with each other. | ![]() | |||||||||||||||||||||
has example of connecting Socket clientSocket= new Socket(host, port); | ![]() | ||||||||||||||||||||||
has example of listening ServerSocket serverSocket = new ServerSocket(port); where port is the integer representing the port number on which the server should be listening | ![]() | ||||||||||||||||||||||
has purpose to allow a server to listen to a port | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of Java class | ![]() | ||||||||||||||||||||||
see also server socket | ![]() | ||||||||||||||||||||||
set of equivalence classes for a system | contains a number of equivalence classes equal to the product of the number of classes of the individual inputs | ![]() | |||||||||||||||||||||
has definition The set of all possible combinations of inputs to a system | ![]() | ||||||||||||||||||||||
has part one or more equivalence class | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
may be very large | ![]() | ||||||||||||||||||||||
setting and getting values of attributes | is a kind of responsibility | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is often omitted from a model because the presence of such responsibilities can largely be inferred from the class diagram | ![]() | ||||||||||||||||||||||
severity level | has definition A number given to a failure, defect or test case, indicating the amount of impact it has on the user or customer | ![]() | |||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 10.8 - Writing Formal Test Cases and Test Plans | ![]() | ||||||||||||||||||||||
shelfware | has definition Software that is not used | ![]() | |||||||||||||||||||||
is a kind of bad software | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
may be produced if the software engineer does not realize what customers and users consider to be their very basic needs | ![]() | ||||||||||||||||||||||
short | is a kind of Java primitive data type | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
requires 16 bits | ![]() | ||||||||||||||||||||||
stores an integer | ![]() | ||||||||||||||||||||||
short circuit operator | is a kind of Java operator | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
does not compute right hand side of an expression if the left hand side is not true | ![]() | ||||||||||||||||||||||
short^2 | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
shrink-wrapped software | has definition A term for generic software, so-called because it is often sold in boxes tightly wrapped in plastic | ![]() | |||||||||||||||||||||
is a synonym of generic software | ![]() | ||||||||||||||||||||||
side effect | has definition A change to the state of the system made by a procedure, other than merely returning a result | ![]() | |||||||||||||||||||||
is a kind of event | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
signature | has definition The format of an operation or message, including arguments and return value | ![]() | |||||||||||||||||||||
is a kind of model | ![]() | ||||||||||||||||||||||
is a subtopic of 5.2 - Essentials of UML Class Diagrams | ![]() | ||||||||||||||||||||||
simple collaboration diagram | is a kind of collaboration diagram | ![]() | |||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
can be converted into a sequence diagram | ![]() | ||||||||||||||||||||||
simple program | is easier to change than a complicated program | ![]() | |||||||||||||||||||||
is a kind of program | ![]() | ||||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
saves money because software developers are more likely to notice defects | ![]() | ||||||||||||||||||||||
should not be used when simplification requires a significant drop in efficiency | ![]() | ||||||||||||||||||||||
simple sequence diagram | is a kind of sequence diagram | ![]() | |||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
can be converted into a collaboration diagram | ![]() | ||||||||||||||||||||||
Simula-67 | is a subtopic of 2.6 - The Effect of Inheritance Hierarchies on Polymorphism and Variable Declarations | ![]() | |||||||||||||||||||||
is an instance of object oriented language | ![]() | ||||||||||||||||||||||
was the first object oriented language | ![]() | ||||||||||||||||||||||
was designed to allow programmers to write programs that simulate the way objects in the real world behave | ![]() | ||||||||||||||||||||||
single inheritance | is a kind of inheritance | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
results in simpler systems than multiple inheritance | ![]() | ||||||||||||||||||||||
singleton | has context | ![]() | |||||||||||||||||||||
has definition A pattern that ensures that a certain class can have only one instance | ![]() | ||||||||||||||||||||||
has example the Company or University classes in systems that run the business of that company or university | ![]() | ||||||||||||||||||||||
has forces | ![]() | ||||||||||||||||||||||
has problem How do you ensure that it is never possible to create more than one instance of a singleton class? | ![]() | ||||||||||||||||||||||
has references one of the Gang of Four patterns. | ![]() | ||||||||||||||||||||||
has solution In a singleton class, create the following:
| ![]() | ||||||||||||||||||||||
is a subtopic of 6.5 - The Singleton Pattern | ![]() | ||||||||||||||||||||||
is an instance of design pattern | ![]() | ||||||||||||||||||||||
singleton condition | has definition A situation in which there is normally more than one of something, but should be tested for the case where there is only one | ![]() | |||||||||||||||||||||
is the inverse of non-singleton condition | ![]() | ||||||||||||||||||||||
is a kind of situation | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
occurs when there is normally more than one of something, but sometimes there is only one | ![]() | ||||||||||||||||||||||
singleton^2 | has definition A class for which only one instance should exist | ![]() | |||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of 6.5 - The Singleton Pattern | ![]() | ||||||||||||||||||||||
situation | is a kind of subject | ![]() | |||||||||||||||||||||
skilled programmer | is a kind of programmer | ![]() | |||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
can be up to ten times as productive as a less skilled programmer | ![]() | ||||||||||||||||||||||
slot | has definition A missing part in a framework that is filled in by the application developer who is adapting the framework to suit his or her needs | ![]() | |||||||||||||||||||||
is similar to a hook except that a slot must be filled in | ![]() | ||||||||||||||||||||||
is a kind of representation | ![]() | ||||||||||||||||||||||
is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | ||||||||||||||||||||||
small software development team | is a kind of software development team | ![]() | |||||||||||||||||||||
is a subtopic of 11.4 - Building Software Engineering Teams | ![]() | ||||||||||||||||||||||
can make development more complex and lead to designs that have higher coupling | ![]() | ||||||||||||||||||||||
small software project | is a kind of software project | ![]() | |||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
may require a single team of three or four developers | ![]() | ||||||||||||||||||||||
small software system | is a kind of software system | ![]() | |||||||||||||||||||||
is a subtopic of 1.2 - What is Software Engineering? | ![]() | ||||||||||||||||||||||
can be developed by a programmer working alone | ![]() | ||||||||||||||||||||||
Smalltalk | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of object oriented language | ![]() | ||||||||||||||||||||||
uses a virtual machine | ![]() | ||||||||||||||||||||||
socket | has definition Data in a client or server that represents an end of a TCP/IP connection. A complete connection has two sockets, one in the client and one in the server | ![]() | |||||||||||||||||||||
is a kind of mechanism | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
see also Socket class | ![]() | ||||||||||||||||||||||
Socket class | has purpose to encapsulate information concerning TCP/IP connections between applications | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of Java class | ![]() | ||||||||||||||||||||||
see also socket | ![]() | ||||||||||||||||||||||
SoftSeeks's list of project management tools | has URL www.softseek.com/Business_and_Productivity/Project_Management ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of web site about project management | ![]() | ||||||||||||||||||||||
software | deteriorates as it is changed repeatedly | ![]() | |||||||||||||||||||||
has definition Programs and related data that run on a computer | ![]() | ||||||||||||||||||||||
has quality which is only as good as its lowest-quality reusable component | ![]() | ||||||||||||||||||||||
is hard to change correctly | ![]() | ||||||||||||||||||||||
is intangible | ![]() | ||||||||||||||||||||||
is more reliable if it has fewer failures | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
is designed usually for human beings to use | ![]() | ||||||||||||||||||||||
often has a poor design and is steadily becoming worse | ![]() | ||||||||||||||||||||||
software architect | is responsible for leading the decision-making about the architecture, and maintaining the documentation describing the architectural model | ![]() | |||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
is part of software development team | ![]() | ||||||||||||||||||||||
often leads a team of software engineers | ![]() | ||||||||||||||||||||||
software architecture | constrains the overall efficiency, reusability and maintainability of the system | ![]() | |||||||||||||||||||||
is a kind of pattern | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
is decided early in the design process, although it will continue to mature as iterative development proceeds | ![]() | ||||||||||||||||||||||
see also software architecture^2 | ![]() | ||||||||||||||||||||||
see also software architecture^3 | ![]() | ||||||||||||||||||||||
software architecture book | is a kind of book | ![]() | |||||||||||||||||||||
is a subtopic of 9.9 - Architecting and designing software - References | ![]() | ||||||||||||||||||||||
Software Architecture for Product Families: Principles and Practice | has author Mehdi Jazayeri, Alexander Ran, Frank Van Der Linden, Philip Van Der Linden | ![]() | |||||||||||||||||||||
has ISBN number 0-201-69967-2 | ![]() | ||||||||||||||||||||||
is a subtopic of 9.9 - Architecting and designing software - References | ![]() | ||||||||||||||||||||||
is an instance of software architecture book | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
Software Architecture in Practice | has author Len Bass, Paul Clements, Rick Kazman, Ken Bass | ![]() | |||||||||||||||||||||
has ISBN number 0-201-19930-0 | ![]() | ||||||||||||||||||||||
is a subtopic of 9.9 - Architecting and designing software - References | ![]() | ||||||||||||||||||||||
is an instance of software architecture book | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1998 | ![]() | ||||||||||||||||||||||
software architecture | must be understood by software engineers | ![]() | |||||||||||||||||||||
Software architecture resources on the web | has URL www.serc.nl/people/florijn/interests/arch.html ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 9.9 - Architecting and designing software - References | ![]() | ||||||||||||||||||||||
is an instance of web site about software architecture | ![]() | ||||||||||||||||||||||
software architecture^2 | has definition The process of designing the global organization of a software system, including dividing software into subsystems, deciding how these will interact, and determining their interfaces | ![]() | |||||||||||||||||||||
involves deciding how the software is to be divided into subsystems and how the subsystems are to interact | ![]() | ||||||||||||||||||||||
involves the development of a variety of high level views of the system | ![]() | ||||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
is a synonym of architecture design | ![]() | ||||||||||||||||||||||
plays a central role in software engineering | ![]() | ||||||||||||||||||||||
see also software architecture | ![]() | ||||||||||||||||||||||
see also software architecture^3 | ![]() | ||||||||||||||||||||||
software architecture^3 | is a synonym of architectural model | ![]() | |||||||||||||||||||||
software | can be easily duplicated | ![]() | |||||||||||||||||||||
can have usability without utility^2 | ![]() | ||||||||||||||||||||||
can have utility without usability | ![]() | ||||||||||||||||||||||
Software Capability Maturity Model | contains five levels: organizations start at level 1, and as their processes become better they can move up towards level 5. | ![]() | |||||||||||||||||||||
has definition A process standard containing five levels of maturity; developed at Carnegie Mellon University | ![]() | ||||||||||||||||||||||
is a kind of process standard | ![]() | ||||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
is abbreviated as CMM | ![]() | ||||||||||||||||||||||
was developed at the Software Engineering Institute of Carnegie Mellon University | ![]() | ||||||||||||||||||||||
software change | is a kind of process | ![]() | |||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
is often done without fully understanding the software design | ![]() | ||||||||||||||||||||||
tends to introduce new bugs | ![]() | ||||||||||||||||||||||
software crisis | has definition The situation that is said to have existed since a least the late 1970's, characterized by an inability of software developers to deliver good quality software on time and on budget | ![]() | |||||||||||||||||||||
is a kind of situation | ![]() | ||||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
software designer | is a kind of designer | ![]() | |||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
may have to propose that the requirements be changed if new issues raised by design decisions have no solutions | ![]() | ||||||||||||||||||||||
may have to revise previous decisions if new issues raised by design decisions have no solutions | ![]() | ||||||||||||||||||||||
may not propose the same solution to a design issue as another designer | ![]() | ||||||||||||||||||||||
should explore different paths through design space - investigating the consequences of choosing different alternatives when major issues arise | ![]() | ||||||||||||||||||||||
software developer | asks several evaluators to independently perform heuristic evaluations | ![]() | |||||||||||||||||||||
develops software | ![]() | ||||||||||||||||||||||
has definition A person involved in the development of software | ![]() | ||||||||||||||||||||||
has goal rewarding career, recognition, or the challenge of solving difficult problems or by being a well-respected 'guru' in a certain area of expertise | ![]() | ||||||||||||||||||||||
is a kind of stakeholder | ![]() | ||||||||||||||||||||||
is a subtopic of 1.4 - Stakeholders in Software Engineering | ![]() | ||||||||||||||||||||||
is part of software development team | ![]() | ||||||||||||||||||||||
maintains software | ![]() | ||||||||||||||||||||||
most often works on custom software | ![]() | ||||||||||||||||||||||
often fails to adequately involve users in the development process | ![]() | ||||||||||||||||||||||
often has significantly less knowledge about modelling than about design and programming | ![]() | ||||||||||||||||||||||
often underestimates software development time because it is very hard for people to assess the quality of software or to appreciate the amount of work involved in its development | ![]() | ||||||||||||||||||||||
performs cost estimation | ![]() | ||||||||||||||||||||||
reuses libraries and APIs delivered with a programming language | ![]() | ||||||||||||||||||||||
wants software that is easy to design and maintain and which has parts that are easy to reuse | ![]() | ||||||||||||||||||||||
can avoid creating design documents before starting to program but this is not a good idea and tends to result in an inflexible and overly-complex system | ![]() | ||||||||||||||||||||||
may be judged on when they deliver product, not on its quality level | ![]() | ||||||||||||||||||||||
may be reluctant to develop new libraries, APIs and frameworks because
| ![]() | ||||||||||||||||||||||
may refuse to reuse components in which they lack confidence | ![]() | ||||||||||||||||||||||
must ensure that the set of use cases is complete and that they are expressed consistently and unambiguously | ![]() | ||||||||||||||||||||||
must inform the project manager about any problems | ![]() | ||||||||||||||||||||||
must understand the customer's business environment, their problems and the available technology which can be used to solve the problems | ![]() | ||||||||||||||||||||||
software developer practising user centred design | designs software based on an understanding of the users' tasks | ![]() | |||||||||||||||||||||
designs the user interface following principles of good usability | ![]() | ||||||||||||||||||||||
involves users in the decision making process as much as possible throughout development | ![]() | ||||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 7.1 - User Centred Design | ![]() | ||||||||||||||||||||||
knows the characteristics of her users allows her to design a system that matches their level of knowledge, their abilities and their preferences | ![]() | ||||||||||||||||||||||
performs use case analysis | ![]() | ||||||||||||||||||||||
must develop an understanding of the users of a system | ![]() | ||||||||||||||||||||||
should ask users to work with and give their feedback about prototypes, on-line help and draft user manuals | ![]() | ||||||||||||||||||||||
software developer | should avoid the use of obscure features of technology because later versions of the technology might be changed in ways that are incompatible with how you have used it or the producer of the technology might go out of business or withdraw it from the market | ![]() | |||||||||||||||||||||
should be rewarded for developing reusable components | ![]() | ||||||||||||||||||||||
should emphasize the use case or use cases which are central to the system, which represent a high risk because of problematic implementation, or which have high political or commercial value | ![]() | ||||||||||||||||||||||
should identify all the use cases associated with the software product | ![]() | ||||||||||||||||||||||
should not document a design only after it is complete | ![]() | ||||||||||||||||||||||
should not omit design documentation | ![]() | ||||||||||||||||||||||
should not use a design pattern without understanding in depth the forces that need to be balanced, and if another pattern would better balance the forces | ![]() | ||||||||||||||||||||||
should only reuse technology that others are also reusing | ![]() | ||||||||||||||||||||||
should realize that attention to quality of reusable components is essential so that potential re-users have confidence in them | ![]() | ||||||||||||||||||||||
should realize that developing and reusing reusable components improves reliability, and can foster a sense of confidence | ![]() | ||||||||||||||||||||||
should realize that developing reusable components will normally simplify the resulting design, independently of whether reuse actually occurs | ![]() | ||||||||||||||||||||||
should work for several months on a testing team; this will heighten her awareness of quality problems she should avoid when she returns to designing software | ![]() | ||||||||||||||||||||||
software developer using a framework | fills in hooks and slots | ![]() | |||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | ||||||||||||||||||||||
reuses the overall design envisioned by the framework's designer, and also a body of code that implements that design | ![]() | ||||||||||||||||||||||
uses services that the framework provides, i.e. methods that perform useful functions, called the API | ![]() | ||||||||||||||||||||||
software developer using an object oriented framework | creates concrete classes that extend the abstract classes in the framework | ![]() | |||||||||||||||||||||
is a kind of software developer using a framework | ![]() | ||||||||||||||||||||||
is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | ||||||||||||||||||||||
software development | has challenge dividing up the work and ensuring that the teams communicate effectively and produce subsystems that properly connect with each other to produce a large but functioning system | ![]() | |||||||||||||||||||||
is labour-intensive | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.2 - What is Software Engineering? | ![]() | ||||||||||||||||||||||
cannot be automated like some other areas of engineering | ![]() | ||||||||||||||||||||||
software development company | is a kind of organization | ![]() | |||||||||||||||||||||
is a subtopic of 10.13 - Difficulties and Risks in Quality Assurance | ![]() | ||||||||||||||||||||||
may follow what is often called an opportunistic approach if it does not follow good software engineering practices | ![]() | ||||||||||||||||||||||
should consider Consider quality assurance to be an integral and on-going part of development | ![]() | ||||||||||||||||||||||
should encourage developers and maintainers to work for several months on a testing team; this will heighten their awareness of quality problems they should avoid when they return to designing software | ![]() | ||||||||||||||||||||||
should give people tasks that fit their natural personalities | ![]() | ||||||||||||||||||||||
should have a separate department to handle quality assurance | ![]() | ||||||||||||||||||||||
should not sacrifice those activities that can ensure quality are often sacrificed in order to meet deadlines | ![]() | ||||||||||||||||||||||
should provide developers with feedback about their performance in terms of producing quality software so they have something measurable to improve | ![]() | ||||||||||||||||||||||
should publish statistics about quality (within the organization) so people who ignore it will be embarrassed | ![]() | ||||||||||||||||||||||
should recognize the importance of quality | ![]() | ||||||||||||||||||||||
should schedule adequate time for all quality assurance activities | ![]() | ||||||||||||||||||||||
should train people in testing and inspecting techniques | ![]() | ||||||||||||||||||||||
software development team | has optimal team size for a given estimated development effort - doubling the size of a team will not halve the development time | ![]() | |||||||||||||||||||||
has part configuration management specialist | ![]() | ||||||||||||||||||||||
has part database specialist | ![]() | ||||||||||||||||||||||
has part hardware and third-party software specialist | ![]() | ||||||||||||||||||||||
has part modeller | ![]() | ||||||||||||||||||||||
has part project manager | ![]() | ||||||||||||||||||||||
has part requirements specialist | ![]() | ||||||||||||||||||||||
has part software architect | ![]() | ||||||||||||||||||||||
has part software developer | ![]() | ||||||||||||||||||||||
has part technical writer | ![]() | ||||||||||||||||||||||
has part technology specialist | ![]() | ||||||||||||||||||||||
has part tester | ![]() | ||||||||||||||||||||||
has part user interface designer | ![]() | ||||||||||||||||||||||
is a kind of team | ![]() | ||||||||||||||||||||||
is a subtopic of 1.4 - Stakeholders in Software Engineering | ![]() | ||||||||||||||||||||||
can be proud of evolving a high-quality product such that it continues to meet the needs of customers | ![]() | ||||||||||||||||||||||
can be assigned to one subsystem of a larger project | ![]() | ||||||||||||||||||||||
can be organized as a hierarchical manager-subordinate structure, as an egoless team, or somewhere in between | ![]() | ||||||||||||||||||||||
can be positively affected by a certain amount of deadline pressure | ![]() | ||||||||||||||||||||||
can work faster if
| ![]() | ||||||||||||||||||||||
can work more efficiently if it has skilled management and a mature development methodology that includes such things as quality assurance, risk management, and iterative development | ![]() | ||||||||||||||||||||||
does not have constant size | ![]() | ||||||||||||||||||||||
may be slowed down by
| ![]() | ||||||||||||||||||||||
may make mistakes if they are under intense pressure to deliver software by a certain date and these mistakes can actually end up delaying them | ![]() | ||||||||||||||||||||||
may often work on legacy system | ![]() | ||||||||||||||||||||||
must coordinate with other software development teams working on the same project | ![]() | ||||||||||||||||||||||
must understand only the overall software architecture, the details of its own subsystem, plus the interfaces to related subsystems | ![]() | ||||||||||||||||||||||
should be sized such that the total amount of required knowledge and exchange of information is reduced | ![]() | ||||||||||||||||||||||
should follow guidelines found in process standards | ![]() | ||||||||||||||||||||||
should include an experienced modeller | ![]() | ||||||||||||||||||||||
should include at least two people capable of performing each role, so that if somebody leaves or is sick, the project is not paralyzed | ![]() | ||||||||||||||||||||||
should not add people to a team if it gets behind schedule, in the hope of catching up because the new people will take time to learn what has been done, and will require support from the other people in the meantime, slowing them down | ![]() | ||||||||||||||||||||||
software | does not wear out with use like other engineering artefacts | ![]() | |||||||||||||||||||||
software engineer | applies well-understood techniques in an organized and disciplined way | ![]() | |||||||||||||||||||||
assists the manager of the development team | ![]() | ||||||||||||||||||||||
checks for valid generalizations by checking that:
| ![]() | ||||||||||||||||||||||
communicates with other software engineers orally and in writing | ![]() | ||||||||||||||||||||||
designs software systems | ![]() | ||||||||||||||||||||||
fills in certain missing details of a framework to complete the application or subsystem it represents | ![]() | ||||||||||||||||||||||
has definition A person who has education in, and experience performing software engineering; an engineer who specializes in software | ![]() | ||||||||||||||||||||||
has purpose to solve problems economically by developing high quality software | ![]() | ||||||||||||||||||||||
is a kind of engineer | ![]() | ||||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 1.1 - The Nature of Software | ![]() | ||||||||||||||||||||||
is often not educated as an engineer | ![]() | ||||||||||||||||||||||
is rarely taught interviewing skills | ![]() | ||||||||||||||||||||||
makes design decision by using all the knowledge at his or her disposal, including: | ![]() | ||||||||||||||||||||||
performs domain analysis by gathering information from domain experts, books, software and its documentation, and any other available documents | ![]() | ||||||||||||||||||||||
performs interviewing as part of requirements gathering | ![]() | ||||||||||||||||||||||
performs observation as part of requirements gathering | ![]() | ||||||||||||||||||||||
reuses commercial off-the-shelf software by adding extra code called glue code which is often written using scripting languages which run using an interpreter | ![]() | ||||||||||||||||||||||
reuses complete applications and adapts them to the needs of the client by adding a small amount of extra software that makes the applications behave in special ways the client wants | ![]() | ||||||||||||||||||||||
reuses expertise when they have many years of experience working on projects and can often save considerable time when it comes to developing new systems because they do not need to re-think many issues: their past experience tells them what needs to be done | ![]() | ||||||||||||||||||||||
reuses frameworks | ![]() | ||||||||||||||||||||||
reuses implemented algorithms, data structures and other facilities contained in libraries of classes or procedures, or of powerful commands built into languages and operating systems | ![]() | ||||||||||||||||||||||
reuses standard designs and algorithms described in books, standards documents and articles by implementing them if they are appropriate to the current task | ![]() | ||||||||||||||||||||||
uses use case analysis to help define the tasks that the user interface must help the user perform | ![]() | ||||||||||||||||||||||
can design highly maintainable software by anticipating future changes and adding flexibility | ![]() | ||||||||||||||||||||||
can write detailed requirements before starting to design the system only if he or she is developing software in a well-known domain and using well-known technology | ![]() | ||||||||||||||||||||||
cannot develop a perfect user interface without the input of users | ![]() | ||||||||||||||||||||||
cannot know whether a system meets the customer's needs until it is delivered and in use | ![]() | ||||||||||||||||||||||
does not have to become an expert in the domain to do domain analysis | ![]() | ||||||||||||||||||||||
does not need to exceed quality objectives which helps them avoid spending more effort than is necessary | ![]() | ||||||||||||||||||||||
software engineer doing interviewing | asks
| ![]() | |||||||||||||||||||||
is a kind of software engineer | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
prepares an extensive list of questions | ![]() | ||||||||||||||||||||||
must develop listening skills and empathy for users and customers | ![]() | ||||||||||||||||||||||
should allow several hours for each interview | ![]() | ||||||||||||||||||||||
should hold a series of interviews with the most important stakeholders | ![]() | ||||||||||||||||||||||
should interview as many stakeholders as possible, as well as users of competing products, marketing personnel, and people involved with other systems that may interact in any way with the proposed system | ![]() | ||||||||||||||||||||||
software engineer | may become the manager of a development team at some point in her career | ![]() | |||||||||||||||||||||
may have to optimize certain aspects of designs - achieving the best possible levels of certain qualities, while not exceeding a certain budget and at the same time meeting objectives for the other qualities | ![]() | ||||||||||||||||||||||
may not reuse software because there are no reusable components available to reuse, or because they do not feel confident about reusing whatever is available | ![]() | ||||||||||||||||||||||
may perform project management | ![]() | ||||||||||||||||||||||
must be able to find reusable components | ![]() | ||||||||||||||||||||||
must be able to write clear documentation | ![]() | ||||||||||||||||||||||
must be understand the software architecture of a system they are working on | ![]() | ||||||||||||||||||||||
must effectively communicate with people, to understand how they work and to understand what impact any proposed software may have on these people's productivity | ![]() | ||||||||||||||||||||||
must ensure that his systems can be produced within a limited budget and by a certain due date | ![]() | ||||||||||||||||||||||
must have sufficient general education, plus training in the technology to be used | ![]() | ||||||||||||||||||||||
must plan budget and schedule which requires a great deal of knowledge about what is required to produce a system, and how long each activity should take | ![]() | ||||||||||||||||||||||
must realize that the vicious circle of software reuse exists and costs money - in order to save money in the longer term, an investment in reusable code is justified | ![]() | ||||||||||||||||||||||
should adjust the requirements or design as soon as important changes are discovered | ![]() | ||||||||||||||||||||||
should avoid duplication of requirements so as to help ensure consistency | ![]() | ||||||||||||||||||||||
should avoid obscure features of any technology | ![]() | ||||||||||||||||||||||
should avoid requirements creep | ![]() | ||||||||||||||||||||||
should avoid technology sold by just a single vendor and which has relatively few other customers | ![]() | ||||||||||||||||||||||
should balance the benefits of the use of third-party technology with the risks of problems | ![]() | ||||||||||||||||||||||
should be aware of things which may change | ![]() | ||||||||||||||||||||||
should be able to use cost-benefit analysis to choose among alternatives | ![]() | ||||||||||||||||||||||
should build flexibility and other aspects of maintainability into the software from the start so that changes are easier to make | ![]() | ||||||||||||||||||||||
should check the consistency of requirements with any standards, with other requirements in the document, with higher-level requirements and with the requirements for other subsystems | ![]() | ||||||||||||||||||||||
should combine the best features of each process model | ![]() | ||||||||||||||||||||||
should continually interact with users and clients to keep up-to-date on their needs | ![]() | ||||||||||||||||||||||
should create prototypes to try out the technology you will be using | ![]() | ||||||||||||||||||||||
should design system to meet quality objectives | ![]() | ||||||||||||||||||||||
should design user interface after doing some domain analysis and defining the problem | ![]() | ||||||||||||||||||||||
should design for flexibility to accommodate potential changes | ![]() | ||||||||||||||||||||||
should design with change in mind | ![]() | ||||||||||||||||||||||
should develop negotiating and other 'people' skills | ![]() | ||||||||||||||||||||||
should develop prototypes based on rough requirements to check out the validity of the ideas or the reliability of the technology before writing detailed requirements | ![]() | ||||||||||||||||||||||
should divide a system into smaller subsystems, so that each one is naturally simpler | ![]() | ||||||||||||||||||||||
should evaluate the requirements in a project where requirements have already been determined to ensure that the requirements on which is based are of good quality | ![]() | ||||||||||||||||||||||
should follow a good requirements gathering and analysis process | ![]() | ||||||||||||||||||||||
should follow the IEEE/ACM code of ethics | ![]() | ||||||||||||||||||||||
should have a mentor | ![]() | ||||||||||||||||||||||
should have user interface design skills | ![]() | ||||||||||||||||||||||
should learn how users and customers think and behave so it will be easier to produce software that meets their needs | ![]() | ||||||||||||||||||||||
should make their designs reusable by designing and documenting software so that it is understandable and flexible enough be used in a variety of different systems | ![]() | ||||||||||||||||||||||
should narrow the scope^2 of a system if possible by defining a more precise problem | ![]() | ||||||||||||||||||||||
should not accept a contract where she is required to implement requirements with no changes allowed | ![]() | ||||||||||||||||||||||
should not add unnecessary new features | ![]() | ||||||||||||||||||||||
should not ignore long-term needs of the customers | ![]() | ||||||||||||||||||||||
should not rush changes | ![]() | ||||||||||||||||||||||
should not undertake a serious software project without doing domain analysis | ![]() | ||||||||||||||||||||||
should participate in promoting and marketing the project | ![]() | ||||||||||||||||||||||
should perform quality assurance activities on each change in a system | ![]() | ||||||||||||||||||||||
should practice on prototypes or systems that are of lesser importance in order to gain sufficient experience in a particular technology | ![]() | ||||||||||||||||||||||
should prototype the system early, especially those parts that involve complex algorithms, in order to determine whether performance will be satisfactory | ![]() | ||||||||||||||||||||||
should recognize activities that are not consistent with the goal of solving customers' problems, such as adding unnecessary features, and situations when it would be most cost effective not to develop software at all, to develop simpler software or to purchase existing software | ![]() | ||||||||||||||||||||||
should redesign parts of an over-complex system as necessary | ![]() | ||||||||||||||||||||||
should regularly evaluate how the system will impact all the stakeholders, and work closely with them to foster increased understanding of issues | ![]() | ||||||||||||||||||||||
should remove features that are not needed | ![]() | ||||||||||||||||||||||
should reuse others' work, rather than re-developing software that others have already developed | ![]() | ||||||||||||||||||||||
should set objectives for quality when starting a project | ![]() | ||||||||||||||||||||||
should study Peter G. Neumann's Risks Digest to ensure they do not recreate the failures listed in it | ![]() | ||||||||||||||||||||||
should take time to understand software before making changes | ![]() | ||||||||||||||||||||||
should understand process standards | ![]() | ||||||||||||||||||||||
should understand the application domain so he or she can communicate effectively with clients and users | ![]() | ||||||||||||||||||||||
should understand basically how their managers run projects | ![]() | ||||||||||||||||||||||
should use tools that aid in understanding the structure of a software system | ![]() | ||||||||||||||||||||||
should use widely used technology because it is more likely to be supported and have had its defects removed | ![]() | ||||||||||||||||||||||
should work with the customer to resolve any problems with requirements in a project where requirements have already been determined | ![]() | ||||||||||||||||||||||
software engineering | has challenge accurately forecasting how much time it will take either to develop a system, or to make a specific set of changes | ![]() | |||||||||||||||||||||
has definition from the Canadian Standards Association The systematic activities involved in the design, implementation and testing of software to optimize its production and support | ![]() | ||||||||||||||||||||||
has definition from the IEEE (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1) | ![]() | ||||||||||||||||||||||
has definition The process of solving customers problems by the systematic development and evolution of large, high-quality software systems within cost, time and other constraints. The application of engineering to software systems of any kind | ![]() | ||||||||||||||||||||||
has goal solving customers' problems | ![]() | ||||||||||||||||||||||
has part ensuring that maintenance and evolution of software is done in a systematic way | ![]() | ||||||||||||||||||||||
has part evolution | ![]() | ||||||||||||||||||||||
has part maintenance | ![]() | ||||||||||||||||||||||
has part managing software projects | ![]() | ||||||||||||||||||||||
has part programming | ![]() | ||||||||||||||||||||||
has part programming | ![]() | ||||||||||||||||||||||
has part project management | ![]() | ||||||||||||||||||||||
involves applying well-understood techniques in an organized and disciplined way | ![]() | ||||||||||||||||||||||
involves the translation of higher-level designs into particular programming languages | ![]() | ||||||||||||||||||||||
is / labour-intensive | ![]() | ||||||||||||||||||||||
is highly iterative | ![]() | ||||||||||||||||||||||
is undergoing development in its technology and techniques | ![]() | ||||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.2 - What is Software Engineering? | ![]() | ||||||||||||||||||||||
is normally organized into software projects | ![]() | ||||||||||||||||||||||
sometimes consists of developing completely new software | ![]() | ||||||||||||||||||||||
uses resources such as the time and money of the stakeholders, and the CPU-time and memory of computers | ![]() | ||||||||||||||||||||||
Software Engineering Body of Knowledge | has URL www.swebok.org ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of software engineering web site | ![]() | ||||||||||||||||||||||
software engineering book | is a kind of book | ![]() | |||||||||||||||||||||
Software Engineering Institute at Carnegie Mellon University | has web site www.sei.cmu.edu ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of organization | ![]() | ||||||||||||||||||||||
software engineering magazine | is a kind of magazine | ![]() | |||||||||||||||||||||
software engineering process | has definition A process used by software engineers Normally refers to specific approaches to performing software engineering or specific software engineering activities such as requirements analysis or testing | ![]() | |||||||||||||||||||||
is a synonym of development | ![]() | ||||||||||||||||||||||
software engineering team model | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 11.4 - Building Software Engineering Teams | ![]() | ||||||||||||||||||||||
software engineering | usually consists of modifying software that has been already written - this is because software is normally continually changed over a period of years until it becomes obsolete | ![]() | |||||||||||||||||||||
software engineering web site | is a kind of engineering web site | ![]() | |||||||||||||||||||||
Software Engineering, a Practitioner's Approach | has author R. Pressman | ![]() | |||||||||||||||||||||
has ISBN number 0-07-365578-3 | ![]() | ||||||||||||||||||||||
has web site www.mhhe.com/engcs/compsci/pressman ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of software engineering book | ![]() | ||||||||||||||||||||||
was published by McGraw Hill | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
Software Engineering: Theory and Practice | has author Shari Lawrence Pfleeger | ![]() | |||||||||||||||||||||
has ISBN number ISBN 0-13-624842-X | ![]() | ||||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of software engineering book | ![]() | ||||||||||||||||||||||
was published by Prentice Hall | ![]() | ||||||||||||||||||||||
was published in 1998 | ![]() | ||||||||||||||||||||||
software engineering^2 | developed out of computer science | ![]() | |||||||||||||||||||||
has been recognized since the mid 1990s as a distinct branch of the engineering profession | ![]() | ||||||||||||||||||||||
has definition The field of study of how to effectively do the process of software engineering | ![]() | ||||||||||||||||||||||
is a kind of engineering | ![]() | ||||||||||||||||||||||
is a subtopic of 1.2 - What is Software Engineering? | ![]() | ||||||||||||||||||||||
is taught in universities as distinct from programs in computer science and computer engineering | ![]() | ||||||||||||||||||||||
Software Engineering^3 | has author Ian Sommerville | ![]() | |||||||||||||||||||||
has ISBN number 0-201-39815-X | ![]() | ||||||||||||||||||||||
is a subtopic of 1.10 - Software and Software Engineering - References | ![]() | ||||||||||||||||||||||
is an instance of software engineering book | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
Software Inspection | has author T. Gilb, D. Graham, S. Finzi | ![]() | |||||||||||||||||||||
has ISBN number 0-201-63181-4 | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of book about software inspection | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1993 | ![]() | ||||||||||||||||||||||
Software Inspection An Industry Best Practice | has editor D.A. Wheeler, B. Brykczynski, and R.N. Meeson, Jr. | ![]() | |||||||||||||||||||||
has ISBN number 0-818-67340-0 | ![]() | ||||||||||||||||||||||
has URL www.computer.org/cspress/catalog/bp07340.htm ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of book about software inspection | ![]() | ||||||||||||||||||||||
was published by IEEE CS Press | ![]() | ||||||||||||||||||||||
was published in 1996 | ![]() | ||||||||||||||||||||||
software library | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 1.9 - Difficulties And Risks In Software Engineering as a Whole | ![]() | ||||||||||||||||||||||
may have bugs and incompatibilities | ![]() | ||||||||||||||||||||||
software | must be designed with users' input otherwise it may not be usable | ![]() | |||||||||||||||||||||
software process model | is a synonym of process model | ![]() | |||||||||||||||||||||
software project | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of 1.6 - Software Engineering Projects | ![]() | ||||||||||||||||||||||
is often completed behind schedule and over budget, or are not completed at all | ![]() | ||||||||||||||||||||||
often has problem failure to stick to cost and time because of the inherent complexity of software, the relative immaturity of software engineering and its technologies, lack of knowledge and experience on the part of software engineers, the inherent human tendency towards over-confidence, , and pressure to offer excessively low prices and short development times in order to obtain contracts or make sales | ![]() | ||||||||||||||||||||||
does not have economy of scale as it gets larger due to the increasingly large amount of co-ordination involved | ![]() | ||||||||||||||||||||||
Software Project Management | has author B. Hughes and M. Cotterell | ![]() | |||||||||||||||||||||
has ISBN number 0-07-709505-7 | ![]() | ||||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of book about project management | ![]() | ||||||||||||||||||||||
was published by McGraw-Hill ![]() | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
software project | may be at risk from models that are incomplete, incorrect or not flexible enough | ![]() | |||||||||||||||||||||
should not be undertaken without a sound domain analysis | ![]() | ||||||||||||||||||||||
Software Project Survival Guide | has author S. McConnell | ![]() | |||||||||||||||||||||
has ISBN number 1-57231-621- | ![]() | ||||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of book about project management | ![]() | ||||||||||||||||||||||
was published by Microsoft Press | ![]() | ||||||||||||||||||||||
was published in 1997 | ![]() | ||||||||||||||||||||||
software project | usually involves modifying an existing system | ![]() | |||||||||||||||||||||
software quality | is hard to assess | ![]() | |||||||||||||||||||||
is a kind of quality | ![]() | ||||||||||||||||||||||
is a subtopic of 1.5 - Software Quality | ![]() | ||||||||||||||||||||||
Software Requirements Engineering, Second Edition | has editor R. Thayer, M. Dorfman and S. Bailin | ![]() | |||||||||||||||||||||
has ISBN number 0-8186-7738-4 | ![]() | ||||||||||||||||||||||
is a subtopic of 4.13 - Developing Requirements - References | ![]() | ||||||||||||||||||||||
is an instance of book about requirements analysis | ![]() | ||||||||||||||||||||||
was published by IEEE CS Press | ![]() | ||||||||||||||||||||||
was published in 1997 | ![]() | ||||||||||||||||||||||
Software Reuse | has author I. Jacobson | ![]() | |||||||||||||||||||||
has ISBN number 0-201-92476-5 | ![]() | ||||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
is an instance of book about software reuse | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1993 | ![]() | ||||||||||||||||||||||
Software Reuse Techniques: Adding Reuse to the System Development Process | has author C. McClure | ![]() | |||||||||||||||||||||
has ISBN number 0-136-61000-5 | ![]() | ||||||||||||||||||||||
has web site www.reusability.com ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
is an instance of book about software reuse | ![]() | ||||||||||||||||||||||
was published by Prentice-Hall | ![]() | ||||||||||||||||||||||
was published in 1997 | ![]() | ||||||||||||||||||||||
software reuse web site | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
Software Runaways | has author R.L. Glass | ![]() | |||||||||||||||||||||
has ISBN number 1-57231-621-7 | ![]() | ||||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of book about project management | ![]() | ||||||||||||||||||||||
was published by Prentice Hall | ![]() | ||||||||||||||||||||||
was published in 1998 | ![]() | ||||||||||||||||||||||
software system | becomes complex because it is easy to add new features and because software engineers typically add features without fully understanding a system, which may not have been originally designed to accommodate the features | ![]() | |||||||||||||||||||||
is better at error handling if it effectively prevents the user from making errors, detects errors, and helps the user to correct errors | ![]() | ||||||||||||||||||||||
is a kind of system | ![]() | ||||||||||||||||||||||
is a subtopic of 1.9 - Difficulties And Risks In Software Engineering as a Whole | ![]() | ||||||||||||||||||||||
is typically initially developed as a prototype | ![]() | ||||||||||||||||||||||
undergoes evolution over its life-span | ![]() | ||||||||||||||||||||||
can automate business process | ![]() | ||||||||||||||||||||||
can be divided in many ways:
| ![]() | ||||||||||||||||||||||
must have well-described requirements if other systems or subsystems are going to use its services or communicate with it | ![]() | ||||||||||||||||||||||
should be designed for flexibility right from the start | ![]() | ||||||||||||||||||||||
Software Testing and Continuous Quality Improvement | has author W.E. Lewis | ![]() | |||||||||||||||||||||
has ISBN number 0-84939-833-9 | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of book about software testing | ![]() | ||||||||||||||||||||||
was published by CRC Press | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
software testing hotlist | has author Bret Pettichord | ![]() | |||||||||||||||||||||
has URL www.io.com/~wazmo/qa ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of web site about software testing | ![]() | ||||||||||||||||||||||
software testing newsgroup | has address news:comp. software.testing | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of newsgroup | ![]() | ||||||||||||||||||||||
software testing newsgroup FAQ | has URL www.faqs.org/faqs/software-eng/testing-faq ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of web site about software testing | ![]() | ||||||||||||||||||||||
software testing online resources | has author Roland Untch | ![]() | |||||||||||||||||||||
has URL www.mtsu.edu/~storm ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of web site about software testing | ![]() | ||||||||||||||||||||||
source code | has part comment | ![]() | |||||||||||||||||||||
has part line of code | ![]() | ||||||||||||||||||||||
is a kind of code | ![]() | ||||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is stored in source file | ![]() | ||||||||||||||||||||||
cannot always be made completely obvious without comments | ![]() | ||||||||||||||||||||||
should be written in lines no longer than 80 characters so that readers do not have to scroll right, and so that the code always prints correctly | ![]() | ||||||||||||||||||||||
should consist of between about 25% and 50% comments | ![]() | ||||||||||||||||||||||
should use consistent layout style | ![]() | ||||||||||||||||||||||
source file | contains source code | ![]() | |||||||||||||||||||||
is a kind of component | ![]() | ||||||||||||||||||||||
is a kind of file | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
specialization | has definition The inverse of generalization | ![]() | |||||||||||||||||||||
has purpose to provide details of a particular use case in a group of use cases that are described in a generalization | ![]() | ||||||||||||||||||||||
is a kind of use case | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
is used much like subclasses in a class diagram | ![]() | ||||||||||||||||||||||
specification | has definition A document that gives complete detail about something. Normally implicitly means requirements specification, but the term design specification is sometimes also used to mean a detailed and precise design document | ![]() | |||||||||||||||||||||
is a kind of document | ![]() | ||||||||||||||||||||||
is a subtopic of 4.7 - Types of Requirements Document | ![]() | ||||||||||||||||||||||
specification language | is a kind of language | ![]() | |||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
spiral model | follows principles:
| ![]() | |||||||||||||||||||||
has definition An incremental process model that explicitly embraces prototyping and an iterative approach to software development | ![]() | ||||||||||||||||||||||
has steps | ![]() | ||||||||||||||||||||||
is a kind of process model | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
suggests that the first thing to do before embarking on each new loop of the spiral is to decide what are the major difficulties to be handled | ![]() | ||||||||||||||||||||||
spoken word | has advantages | ![]() | |||||||||||||||||||||
has problems | ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
stable architecture | has definition An architecture that permits changes to a system to be made without the architecture having to change | ![]() | |||||||||||||||||||||
is a kind of software architecture | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
stable sort | has definition A sort algorithm that leaves items, as much as possible, in the same order they were in prior to sorting | ![]() | |||||||||||||||||||||
is a kind of algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.4 - Defects in Numerical Algorithms | ![]() | ||||||||||||||||||||||
stakeholder | has definition A person or organization that may be affected by the success or failure of a project or organization | ![]() | |||||||||||||||||||||
is a kind of person | ![]() | ||||||||||||||||||||||
is a subtopic of 1.4 - Stakeholders in Software Engineering | ![]() | ||||||||||||||||||||||
must agree on requirements | ![]() | ||||||||||||||||||||||
stamp coupling | has definition A form of coupling in which two components modify or access data in the same object | ![]() | |||||||||||||||||||||
has disadvantage if the shared class changes, then all the classes that access its variables will likely have to change | ![]() | ||||||||||||||||||||||
is a kind of coupling | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
can be reduced by requiring that all variables of the shared class only be accessible via methods | ![]() | ||||||||||||||||||||||
standard | has definition A document describing a body of well-respected information that engineers should conform to in order to ensure they are following best-practice, and will consistently produce good-quality products | ![]() | |||||||||||||||||||||
is a kind of criterion | ![]() | ||||||||||||||||||||||
is a kind of document | ![]() | ||||||||||||||||||||||
is a subtopic of 4.13 - Developing Requirements - References | ![]() | ||||||||||||||||||||||
start state | changes to a regular state when the system or object starts running | ![]() | |||||||||||||||||||||
contains one unlabelled transition pointing out of it | ![]() | ||||||||||||||||||||||
has definition The state a system or object is in when it starts running | ![]() | ||||||||||||||||||||||
is a kind of state | ![]() | ||||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
is represented by start state symbol in a state diagram | ![]() | ||||||||||||||||||||||
start state symbol | is a kind of symbol in state diagram | ![]() | |||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a black circle | ![]() | ||||||||||||||||||||||
state | determines the way an object or system behaves in response to any events that occur | ![]() | |||||||||||||||||||||
has definition A situation in which a system or object behaves in a specific way in response to any events that occur | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
is represented by state symbol in a state diagram | ![]() | ||||||||||||||||||||||
state diagram | contains one or more end states | ![]() | |||||||||||||||||||||
contains only one start state | ![]() | ||||||||||||||||||||||
describes the externally visible behaviour of a system or of an individual object | ![]() | ||||||||||||||||||||||
has definition A UML diagram showing states and transitions, used to describe the externally visible behaviour of a system or of an individual object | ![]() | ||||||||||||||||||||||
has part action symbol | ![]() | ||||||||||||||||||||||
has part activity symbol | ![]() | ||||||||||||||||||||||
has part end state | ![]() | ||||||||||||||||||||||
has part guard condition | ![]() | ||||||||||||||||||||||
has part start state | ![]() | ||||||||||||||||||||||
is a kind of UML diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
shows how systems behave internally | ![]() | ||||||||||||||||||||||
can be nested inside a state of another state diagram | ![]() | ||||||||||||||||||||||
usually shows states and events concerning only one class | ![]() | ||||||||||||||||||||||
state symbol | is a kind of symbol in state diagram | ![]() | |||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a rounded rectangle that contains the name of the state | ![]() | ||||||||||||||||||||||
statement | is a kind of programming language construct | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
should be not more than one line long if possible | ![]() | ||||||||||||||||||||||
static | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
is used to mark a class variable or class method | ![]() | ||||||||||||||||||||||
static method | has definition A synonym for class method, so named because one declares a method to be a class method in Java and C++ using the 'static' keyword' | ![]() | |||||||||||||||||||||
is a synonym of class method | ![]() | ||||||||||||||||||||||
static variable | is a synonym of class variable | ![]() | |||||||||||||||||||||
stereotype | has definition A way to use some of the standard UML notation to represent something special | ![]() | |||||||||||||||||||||
has example the «interface» notation for indicating an interface in a UML diagram by drawing it as a class rectangle, with the expression «interface» at the top, and (optionally) a list of supported operations | ![]() | ||||||||||||||||||||||
is a kind of representation | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
stream class | is a kind of Java class | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
stress testing | has definition Testing on minimal configurations and at peak loads or with missing resources | ![]() | |||||||||||||||||||||
is a kind of testing | ![]() | ||||||||||||||||||||||
is a subtopic of 10.6 - Defects in Handling Stress and Unusual Situations | ![]() | ||||||||||||||||||||||
String | consists of a collection of characters | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java collection class | ![]() | ||||||||||||||||||||||
uses zero-based indexing | ![]() | ||||||||||||||||||||||
structural modelling | has definition A type of modelling used to represent the data or architecture of software | ![]() | |||||||||||||||||||||
involves representing such things as the classes and objects present in the domain or in the software | ![]() | ||||||||||||||||||||||
is a kind of modelling | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
structural testing | is a synonym of glass-box testing | ![]() | |||||||||||||||||||||
structure | is a kind of data abstraction | ![]() | |||||||||||||||||||||
is a subtopic of 2.1 - What is Object Orientation? | ![]() | ||||||||||||||||||||||
stub | has definition A piece of code that has the same interface (i.e. API) as the lower level layers, but which does not perform any real computations or manipulate any real data | ![]() | |||||||||||||||||||||
is a kind of procedural abstraction | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
is used in top-down testing | ![]() | ||||||||||||||||||||||
returns a fixed default value | ![]() | ||||||||||||||||||||||
subclass | has definition A class that is an extension of another class, and hence inherits from the other class | ![]() | |||||||||||||||||||||
inherits all instance variables and methods defined in its ancestor classes | ![]() | ||||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of 2.5 - Organizing Classes Into Inheritance Hierarchies | ![]() | ||||||||||||||||||||||
is a synonym of derived class | ![]() | ||||||||||||||||||||||
subject | is a kind of kbTop | ![]() | |||||||||||||||||||||
substate | has definition A state within a state | ![]() | |||||||||||||||||||||
is a kind of state | ![]() | ||||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
substring | has arguments starting position and ending position + 1 | ![]() | |||||||||||||||||||||
has example String sub = "submariner".substring(0,3); // = "sub" | ![]() | ||||||||||||||||||||||
has purpose to extract part of a string | ![]() | ||||||||||||||||||||||
has result a new String with a sequence of characters from the original string | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java method | ![]() | ||||||||||||||||||||||
subsystem | has definition A system that is part of a larger system, and which has a definite interface | ![]() | |||||||||||||||||||||
is a kind of system | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
can be divided up into one or more packages | ![]() | ||||||||||||||||||||||
subsystem diagram | has definition A UML diagram showing details of a subsystem, including aspects of its operations, its specification and its realization | ![]() | |||||||||||||||||||||
is a kind of UML diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 9.4 - Software Architecture | ![]() | ||||||||||||||||||||||
Sun's official web site | has URL java.sun.com ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of web site about Java | ![]() | ||||||||||||||||||||||
super | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
superclass | has definition A class of which another class is an extension, and hence defines properties that are inherited by the other class | ![]() | |||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of 2.5 - Organizing Classes Into Inheritance Hierarchies | ![]() | ||||||||||||||||||||||
is a synonym of base class | ![]() | ||||||||||||||||||||||
swimlane | has definition A division in a UML activity diagram showing the activities performed by a particular object | ![]() | |||||||||||||||||||||
is a kind of symbol in activity diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 8.3 - Activity Diagrams | ![]() | ||||||||||||||||||||||
is drawn as a box that form a column, containing activities associated with one class | ![]() | ||||||||||||||||||||||
Swing component | is a kind of Java user interface component | ![]() | |||||||||||||||||||||
is a subtopic of 7.7 - Implementing a Simple GUI in Java | ![]() | ||||||||||||||||||||||
switch | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
symbol | is a kind of subject | ![]() | |||||||||||||||||||||
symbol in activity diagram | is a kind of symbol | ![]() | |||||||||||||||||||||
is a subtopic of 8.3 - Activity Diagrams | ![]() | ||||||||||||||||||||||
symbol in collaboration diagram | is a kind of symbol | ![]() | |||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
symbol in interaction diagram | is a kind of symbol | ![]() | |||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
symbol in sequence diagram | is a kind of symbol | ![]() | |||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
symbol in state diagram | is a kind of symbol | ![]() | |||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
symbol in UML diagram | is a kind of symbol | ![]() | |||||||||||||||||||||
is a subtopic of 5.2 - Essentials of UML Class Diagrams | ![]() | ||||||||||||||||||||||
symbol in use case diagram | is a kind of symbol | ![]() | |||||||||||||||||||||
is a subtopic of 8.1 - Interaction Diagrams | ![]() | ||||||||||||||||||||||
symmetric connection | has definition A connection in which the client communicates with the server in the same way as the server communicates with the client | ![]() | |||||||||||||||||||||
is a kind of connection | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
symmetric reflexive association | has definition A reflexive association in which the roles at either end are identical | ![]() | |||||||||||||||||||||
is a kind of reflexive association | ![]() | ||||||||||||||||||||||
is a subtopic of 5.3 - Associations and Multiplicity | ![]() | ||||||||||||||||||||||
synchronization | has definition A mechanism to guarantee that only one thread can access an object at a time | ![]() | |||||||||||||||||||||
has purpose to avoid problems that can arise when two threads can both modify the same object at the same time | ![]() | ||||||||||||||||||||||
is a kind of mechanism | ![]() | ||||||||||||||||||||||
is a kind of practice | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
synchronized | has purpose to ensure that no other thread can access an object until the synchronized method terminates | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
synonym | is a kind of kbTop | ![]() | |||||||||||||||||||||
system | exists even if its components change over the course of time, or are replaced by equivalent components | ![]() | |||||||||||||||||||||
has definition A logical entity, having a set of definable responsibilities or objectives, and consisting of hardware, software or both | ![]() | ||||||||||||||||||||||
has part component | ![]() | ||||||||||||||||||||||
has part hardware | ![]() | ||||||||||||||||||||||
has part module | ![]() | ||||||||||||||||||||||
has part software | ![]() | ||||||||||||||||||||||
has part subsystem | ![]() | ||||||||||||||||||||||
has scope | ![]() | ||||||||||||||||||||||
is complex if its scope is broad | ![]() | ||||||||||||||||||||||
is in a state until an event occurs that causes it to change state | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is divided up into subsystems | ![]() | ||||||||||||||||||||||
can have specification which is then implemented by a collection of components | ![]() | ||||||||||||||||||||||
system domain model | contains domain classes, associations and attributes | ![]() | |||||||||||||||||||||
contains elements that represent things in the domain | ![]() | ||||||||||||||||||||||
is a kind of model | ![]() | ||||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is a synonym of domain model | ![]() | ||||||||||||||||||||||
is developed during requirements analysis, or the early stages of design | ![]() | ||||||||||||||||||||||
omits many classes that are needed to build a complete system; in fact it can contain less than half the classes of the system | ![]() | ||||||||||||||||||||||
only models things that will actually be implemented | ![]() | ||||||||||||||||||||||
does not contain elements that do not represent things in the domain, but are needed to build a complete system | ![]() | ||||||||||||||||||||||
system model | contains
| ![]() | |||||||||||||||||||||
contains elements that do not represent things in the domain, but are needed to build a complete system | ![]() | ||||||||||||||||||||||
contains elements that represent things in the domain | ![]() | ||||||||||||||||||||||
is a kind of model | ![]() | ||||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
only models things that will actually be implemented | ![]() | ||||||||||||||||||||||
system model class diagram | is a kind of class diagram | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
should be developed in such a way that it can be used independently of a particular set of user interface classes or architectural classes | ![]() | ||||||||||||||||||||||
systems engineering | has definition A type of design that involves deciding which requirements should be implemented using hardware, and which using software | ![]() | |||||||||||||||||||||
is normally only necessary for embedded and other real-time systems | ![]() | ||||||||||||||||||||||
is a kind of engineering | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
is part of design | ![]() | ||||||||||||||||||||||
tabbed dialog | allows the user to quickly enter several different types of information | ![]() | |||||||||||||||||||||
is a kind of dialog | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
task analysis | has definition The process of determining the detailed steps needed to perform a task effectively and efficiently | ![]() | |||||||||||||||||||||
is a kind of analysis | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
TCP | has definition An important protocol used to establish and manage connections between computers | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an abbreviation for Transport Control Protocol | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
is an instance of protocol | ![]() | ||||||||||||||||||||||
TCP/IP | has definition An important pair of protocols used to establish connections and send data between computers | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an abbreviation for Transport Control Protocol / Internet Protocol | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
is an instance of protocol | ![]() | ||||||||||||||||||||||
team | is a kind of person or group | ![]() | |||||||||||||||||||||
is a subtopic of 10.10 - Inspections | ![]() | ||||||||||||||||||||||
Team Software Process | describes how teams of software engineers can work together effectively | ![]() | |||||||||||||||||||||
is a kind of process standard | ![]() | ||||||||||||||||||||||
is a subtopic of 10.11 - Quality Assurance in General | ![]() | ||||||||||||||||||||||
is abbreviated as TSP | ![]() | ||||||||||||||||||||||
was developed at the Software Engineering Institute of Carnegie Mellon University | ![]() | ||||||||||||||||||||||
technical writer | is responsible for ensuring that on-line help and user manuals are well written | ![]() | |||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 1.4 - Stakeholders in Software Engineering | ![]() | ||||||||||||||||||||||
is part of software development team | ![]() | ||||||||||||||||||||||
technique for prototyping class diagrams | has procedure
| ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
uses CRC (Class-Responsibility-Collaboration) cards | ![]() | ||||||||||||||||||||||
technology change | has example a new release of the operating system | ![]() | |||||||||||||||||||||
is a kind of change | ![]() | ||||||||||||||||||||||
is a subtopic of 4.9 - Managing Changing Requirements | ![]() | ||||||||||||||||||||||
may force changes in a requirement | ![]() | ||||||||||||||||||||||
technology specialist | is responsible for specialized knowledge and expertise in a technology such as databases, networking, operating systems etc. | ![]() | |||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 11.4 - Building Software Engineering Teams | ![]() | ||||||||||||||||||||||
is part of software development team | ![]() | ||||||||||||||||||||||
technology to be used | has example the programming language or database system | ![]() | |||||||||||||||||||||
is a kind of non-functional requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
is specified to ensure that all systems in an organization use the same technology | ![]() | ||||||||||||||||||||||
telephone number format | has localization issues | ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
temporal cohesion | has definition A form of cohesion in which aspects of a system are grouped together which are used during the same phase of execution of a program, i.e. execute close together in time | ![]() | |||||||||||||||||||||
has example a designer would achieve temporal cohesion by placing together all the code used during system start-up or initialization | ![]() | ||||||||||||||||||||||
is weaker than procedural cohesion | ![]() | ||||||||||||||||||||||
is a kind of cohesion | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
is achieved when operations that are performed during the same phase of the execution of the program are kept together, and everything else is kept out | ![]() | ||||||||||||||||||||||
should be sought only if the other types of cohesion have been achieved | ![]() | ||||||||||||||||||||||
test | has definition A particular run of a test case on a particular version of the system | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 10.8 - Writing Formal Test Cases and Test Plans | ![]() | ||||||||||||||||||||||
test case | contains | ![]() | |||||||||||||||||||||
has definition An explicit set of instructions designed to detect a particular class of defect in a software system, by bringing about a failure | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 10.8 - Writing Formal Test Cases and Test Plans | ![]() | ||||||||||||||||||||||
can give rise to many tests | ![]() | ||||||||||||||||||||||
test case pass target | depends on the cost of failures vs. the cost of continued testing and fixing of defects | ![]() | |||||||||||||||||||||
has definition The desired percentage of test cases that will pass testing | ![]() | ||||||||||||||||||||||
has example | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
test case | should be classified according to importance, or severity level, so that the most important test cases are executed first, and are designed to detect the most severe classes of defect | ![]() | |||||||||||||||||||||
test harness | has definition A program that automates testing of a system | ![]() | |||||||||||||||||||||
is a kind of program | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
test plan | has definition A document that contains a complete set of test cases for a system, along with other information about the testing process | ![]() | |||||||||||||||||||||
is a kind of document | ![]() | ||||||||||||||||||||||
is a subtopic of 10.8 - Writing Formal Test Cases and Test Plans | ![]() | ||||||||||||||||||||||
tests explicit and explicit attributes | ![]() | ||||||||||||||||||||||
can be based on use cases | ![]() | ||||||||||||||||||||||
can be started once the requirements are developed | ![]() | ||||||||||||||||||||||
must test every aspect of the requirements | ![]() | ||||||||||||||||||||||
should be written long before the testing starts | ![]() | ||||||||||||||||||||||
Test Process Improvement: A Practical Step-by-Step Guide to Structured Testing | has author T. Koomen, M. Pol, H.W. Broeders, H. Voorthuyzen | ![]() | |||||||||||||||||||||
has ISBN number 0-201-59624-2 | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of book about software testing | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
test-fix-test cycle | has definition The cycle in which software developers repeatedly run tests, discover and fix defects, and then retest. This continues until quality objectives are met | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
may cause new defects to be added when the software is fixed either because the maintainer tried to fix the problem without fully understanding the ramifications of the change, or because the maintainer made an ordinary human error | ![]() | ||||||||||||||||||||||
testability | has definition The ability for software to be instrumented so that it can be automatically tested using a test harness | ![]() | |||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
tester | finds defects by
| ![]() | |||||||||||||||||||||
is responsible for the first stage of testing | ![]() | ||||||||||||||||||||||
is a kind of software developer | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
is part of software development team | ![]() | ||||||||||||||||||||||
knows that software developers tend to have certain habits that can lead to errors, and hence to defects | ![]() | ||||||||||||||||||||||
needs knowledge of software design to determine the equivalence classes of inputs | ![]() | ||||||||||||||||||||||
can stop testing when | ![]() | ||||||||||||||||||||||
cannot test every possible system-wide equivalence class because of the combinatorial explosion of the space of test cases | ![]() | ||||||||||||||||||||||
cannot test software until all the test cases have passed because it is too expensive, and perhaps futile, to try to remove every last bug from most systems | ![]() | ||||||||||||||||||||||
must be suspicious | ![]() | ||||||||||||||||||||||
must design tests that explicitly try to catch a range of specific types of defects that commonly occur | ![]() | ||||||||||||||||||||||
must pay attention to detail | ![]() | ||||||||||||||||||||||
must try to understand how programmers. designers and users think, so as to better find defects | ![]() | ||||||||||||||||||||||
should complete basic testing before inspecting software | ![]() | ||||||||||||||||||||||
should measure the quality of both the product and the process which This allows you to plot the quality over a period of time and determine whether it is improving or not | ![]() | ||||||||||||||||||||||
should not stop testing just when money or time runs out - the result is low quality software that fails often when users start to use it | ![]() | ||||||||||||||||||||||
should only run one test per equivalence class using a representative member of that equivalence class as input | ![]() | ||||||||||||||||||||||
should test
| ![]() | ||||||||||||||||||||||
testing | has definition An approach to verification that involves systematically executing software to detect defects | ![]() | |||||||||||||||||||||
involves thinking of what could go wrong without actually studying the software | ![]() | ||||||||||||||||||||||
is complementary to inspecting | ![]() | ||||||||||||||||||||||
is a kind of verification | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
requires attention to detail | ![]() | ||||||||||||||||||||||
can find defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting | ![]() | ||||||||||||||||||||||
Testing Computer Software | has author C. Kaner, H.Q. Nguyen, J. Falk | ![]() | |||||||||||||||||||||
has ISBN number 0-471-35846-0 | ![]() | ||||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
is an instance of book about software testing | ![]() | ||||||||||||||||||||||
was published by Wiley | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
testing performed by software engineers | is a kind of testing | ![]() | |||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
testing performed by users and clients | is a kind of testing | ![]() | |||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
should occur when the developers believe that the software has reached a sufficient level of quality (e.g. it is approaching the quality targets) | ![]() | ||||||||||||||||||||||
testing strategy | is a kind of practice | ![]() | |||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
text | has advantages
| ![]() | |||||||||||||||||||||
has problems
| ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
The Basics of Java | is a subtopic of Chapter 2 - Review of Object Orientation | ![]() | |||||||||||||||||||||
The Java Lobby | has URL www.javalobby.org ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of web site about Java | ![]() | ||||||||||||||||||||||
The Java Programming Language | has author Ken Arnold, James Gosling, David Holmes | ![]() | |||||||||||||||||||||
has ISBN number 0-201-70433-1 | ![]() | ||||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of book about Java programming | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
The Java Tutorial | has URL java.sun.com/docs/books/tutorial ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of web site about Java | ![]() | ||||||||||||||||||||||
The Living Internet | contains an excellent overview about the Internet, including a discussion of IP addresses etc. | ![]() | |||||||||||||||||||||
has URL livinginternet.com ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
is an instance of web site about the Internet | ![]() | ||||||||||||||||||||||
The Mythical Man-Month, 20th Anniversary Edition | has author F. Brooks | ![]() | |||||||||||||||||||||
has ISBN number 0-201-83595-9 | ![]() | ||||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of book about project management | ![]() | ||||||||||||||||||||||
was published by Addison Wesley | ![]() | ||||||||||||||||||||||
was published in 1995 | ![]() | ||||||||||||||||||||||
The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill | has author J. Carroll | ![]() | |||||||||||||||||||||
has ISBN number 0-262-03163-9 | ![]() | ||||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
is an instance of book about user interfaces and usability | ![]() | ||||||||||||||||||||||
was published by MIT Press | ![]() | ||||||||||||||||||||||
was published in 1990 | ![]() | ||||||||||||||||||||||
The Object Management Group | has URL www.omg.org ![]() | ![]() | |||||||||||||||||||||
is the home of the UML Specification | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of web site about UML | ![]() | ||||||||||||||||||||||
The Patterns Home Page | has URL hillside.net/patterns/patterns.html ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 6.15 - Using Design Patterns - References | ![]() | ||||||||||||||||||||||
is an instance of web site about design patterns | ![]() | ||||||||||||||||||||||
The project management institute's body of knowledge | has URL www.pmi.org ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of web site about project management | ![]() | ||||||||||||||||||||||
The SDL Forum Society | has web site The SDL Forum Society web site ![]() | ![]() | |||||||||||||||||||||
is the custodian of SDL (Specification and Description Language) as well as Message Sequence Charts, which are similar to sequence charts | ![]() | ||||||||||||||||||||||
is a subtopic of 8.5 - Modelling Interactions and Behaviour - References | ![]() | ||||||||||||||||||||||
is an instance of organization | ![]() | ||||||||||||||||||||||
The SDL Forum Society web site | has URL www.sdl-forum.org ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 8.5 - Modelling Interactions and Behaviour - References | ![]() | ||||||||||||||||||||||
is an instance of web site about modelling interactions and behaviour | ![]() | ||||||||||||||||||||||
The Standish Group | has URL standishgroup.com ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
is an instance of web site about project management | ![]() | ||||||||||||||||||||||
The UML Bibliography | has URL www.db.informatik.uni-bremen.de/umlbib ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of web site about UML | ![]() | ||||||||||||||||||||||
The Unified Modelling Language Reference Manual | has author J. Rumbaugh, I. Jacobson, G. Booch | ![]() | |||||||||||||||||||||
has ISBN number 0-20130998-X | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of book about UML | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1998 | ![]() | ||||||||||||||||||||||
The Unified Modelling Language User Guide | has author G. Booch, J. Rumbaugh, I. Jacobson | ![]() | |||||||||||||||||||||
has ISBN number 0-201-57168-4 | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of book about UML | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1998 | ![]() | ||||||||||||||||||||||
The Unified Software Development Process | has author I. Jacobson, G. Booch, J. Rumbaugh | ![]() | |||||||||||||||||||||
has ISBN number 0-201-57169-2 | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of book about UML | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design | has author D.J. Mayhew | ![]() | |||||||||||||||||||||
has ISBN number 1-55860-561-4 | ![]() | ||||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
is an instance of book about user interfaces and usability | ![]() | ||||||||||||||||||||||
was published by Morgan Kaufmann | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
The Usability Professionals Association web site | has URL www.UPAssoc.org ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
is an instance of web site about usability | ![]() | ||||||||||||||||||||||
The User Interface Hall of Shame | has URL www.iarchitect.com/shame.htm ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
is an instance of web site about usability | ![]() | ||||||||||||||||||||||
thin-client system | has advantage it is easy to download the client program over the network and to launch it | ![]() | |||||||||||||||||||||
has definition A client-server system in which the client is as small as possible and the server does most of the computation | ![]() | ||||||||||||||||||||||
is a kind of client-server system | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
Thinking in Java | has author Bruce Eckel | ![]() | |||||||||||||||||||||
has ISBN number 0-13-027363-5 | ![]() | ||||||||||||||||||||||
has URL http://www.bruceeckel.com/Books ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
is an instance of book about Java programming | ![]() | ||||||||||||||||||||||
was published by Prentice Hall | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
this | has example this.accountHolder = accountHolder; | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
represents the current object | ![]() | ||||||||||||||||||||||
thread | has definition A path of execution that can run concurrently with other paths of execution | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is supported by many operating systems and programming languages | ![]() | ||||||||||||||||||||||
see also Thread class | ![]() | ||||||||||||||||||||||
see also thread in Java | ![]() | ||||||||||||||||||||||
can run at the same time as another thread | ![]() | ||||||||||||||||||||||
Thread class | has definition A Java class that implements the general concept of a thread | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java class | ![]() | ||||||||||||||||||||||
thread in Java | has example public class ThreadExample implements Runnable | ![]() | |||||||||||||||||||||
is a kind of thread | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is created by
| ![]() | ||||||||||||||||||||||
three-tier model of client-server architecture | has definition A model in which a server communicates with both a client (usually through the Internet) and with a database (usually within an intranet, for security reasons) | ![]() | |||||||||||||||||||||
is a kind of client-server architecture | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
is used to design three-tier systems | ![]() | ||||||||||||||||||||||
three-tier system | contains a server which communicates with both a client (usually through the Internet) and with a database (usually within an intranet, for security reasons) and which acts as a client when accessing the database server | ![]() | |||||||||||||||||||||
is a kind of client-server system | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
uses three-tier model of client-server architecture | ![]() | ||||||||||||||||||||||
throughput | is a kind of measurement | ![]() | |||||||||||||||||||||
is a kind of non-functional requirement | ![]() | ||||||||||||||||||||||
is a subtopic of 4.5 - Types of Requirements | ![]() | ||||||||||||||||||||||
is specified in terms of computations or transactions per minute | ![]() | ||||||||||||||||||||||
throw | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
throws | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
tight coupling | causes a system to be hard to understand and change because
| ![]() | |||||||||||||||||||||
is a kind of coupling | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
time format | has localization issues
| ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
time zone | has localization issues
| ![]() | |||||||||||||||||||||
is a kind of locale-dependent feature | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
see also TimeZone class | ![]() | ||||||||||||||||||||||
TimeZone class | deals with the difference between Universal Time Coordinated (UTC or GMT) and local time | ![]() | |||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
is an instance of Java class | ![]() | ||||||||||||||||||||||
see also time zone | ![]() | ||||||||||||||||||||||
timing and co-ordination defect | is a kind of defect | ![]() | |||||||||||||||||||||
is a subtopic of 10.5 - Defects in Timing and Co-Ordination: Deadlock, Livelocks and Critical Races | ![]() | ||||||||||||||||||||||
occur when several threads or processes interact in inappropriate ways | ![]() | ||||||||||||||||||||||
only occurs in a situation involving some form of concurrency | ![]() | ||||||||||||||||||||||
toHexString | has example // converts to hexadecimal | ![]() | |||||||||||||||||||||
has purpose to convert an int to hexadecimal | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java class method | ![]() | ||||||||||||||||||||||
tool | is a kind of subject | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
tool for drawing UML diagrams | is a kind of tool | ![]() | |||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
toolbar | is a kind of non-modal dialog | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
top-down approach to identifying generalizations | divides up a complex class, creating new subclasses | ![]() | |||||||||||||||||||||
is a subtopic of 5.8 - The Process Of Developing Class Diagrams | ![]() | ||||||||||||||||||||||
is an instance of approach to identifying generalizations | ![]() | ||||||||||||||||||||||
is an instance of top-down design | ![]() | ||||||||||||||||||||||
top-down design | has advantage gives the system being designed a good structure | ![]() | |||||||||||||||||||||
has definition An approach to design in which one starts with the high-level architecture of the system, then elaborates the design of subsystems until finally designing the low-level details such as the structure of individual classes | ![]() | ||||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 9.1 - The Process of Design | ![]() | ||||||||||||||||||||||
top-down testing | finds defects in the layer that was most recently integrated | ![]() | |||||||||||||||||||||
has definition An incremental testing strategy in which you start by testing only the user interface, with the underlying functionality simulated by stubs, then you work downwards, integrating lower and lower layers | ![]() | ||||||||||||||||||||||
has disadvantage the cost of writing the stubs | ![]() | ||||||||||||||||||||||
has procedure
| ![]() | ||||||||||||||||||||||
is a kind of vertical incremental testing | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
toString | has default implementation the name of the class followed by a hexadecimal code that distinguishes one instance from another | ![]() | |||||||||||||||||||||
has purpose to convert any kind of object into a string | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java method | ![]() | ||||||||||||||||||||||
should be written for every class you create | ![]() | ||||||||||||||||||||||
traceability | has definition The ability to determine the information that led to a decision being made | ![]() | |||||||||||||||||||||
is important because design documents to be able to say which requirement is being implemented by a given aspect of the design | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a kind of software quality | ![]() | ||||||||||||||||||||||
is a subtopic of 4.8 - Reviewing Requirements | ![]() | ||||||||||||||||||||||
tracking | has definition In the context of project management, he process of determining how well you are sticking to the cost estimate and schedule | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 11.5 - Project Scheduling and Tracking | ![]() | ||||||||||||||||||||||
uses earned value chart | ![]() | ||||||||||||||||||||||
transaction | changes data stored by the system | ![]() | |||||||||||||||||||||
has example in the airline system transactions might be used to add a new flight, add a booking, change a booking or delete a booking | ![]() | ||||||||||||||||||||||
is a kind of command | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
is part of transaction-processing architectural pattern | ![]() | ||||||||||||||||||||||
transaction handler | has example the dynamic binding and dispatching of polymorphic methods | ![]() | |||||||||||||||||||||
is a kind of component | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
transaction-processing | contains a process which reads a series of inputs describing a transaction one by one, and a transaction handler that decides what to do with each transaction, and which dispatches a procedure call or message to a component that will handle the transaction | ![]() | |||||||||||||||||||||
facilitates divide-and-conquer since the design of each handler can be given to separate software engineers | ![]() | ||||||||||||||||||||||
has definition An architectural pattern in which a transaction dispatcher inputs transactions and dispatches them to handlers | ![]() | ||||||||||||||||||||||
is a kind of architectural pattern | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
transaction-processing system | has clients programs that send specific requests to perform some kind of transaction, such as debiting a bank account or booking an airline ticket | ![]() | |||||||||||||||||||||
has server a program that centralizes all the functions of some business and processes transactions when they arrive | ![]() | ||||||||||||||||||||||
is a kind of client-server system | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
transformational architectural pattern | is a synonym of pipe and filter | ![]() | |||||||||||||||||||||
transformational architecture | is a synonym of pipe and filter | ![]() | |||||||||||||||||||||
transient | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
transition | has definition A change of state in response to an event | ![]() | |||||||||||||||||||||
is a kind of event | ![]() | ||||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
is represented by transition symbol in a state diagram | ![]() | ||||||||||||||||||||||
occurs instantaneously | ![]() | ||||||||||||||||||||||
represents a change of state in response to an event | ![]() | ||||||||||||||||||||||
transition in a state diagram | is a kind of transition | ![]() | |||||||||||||||||||||
is a subtopic of 8.3 - Activity Diagrams | ![]() | ||||||||||||||||||||||
is usually caused by an external event | ![]() | ||||||||||||||||||||||
transition in an activity diagram | is a kind of transition | ![]() | |||||||||||||||||||||
is a subtopic of 8.3 - Activity Diagrams | ![]() | ||||||||||||||||||||||
is usually caused by an internal event | ![]() | ||||||||||||||||||||||
transition | may be triggered by a condition becoming true | ![]() | |||||||||||||||||||||
may be triggered by an event | ![]() | ||||||||||||||||||||||
transition symbol | is a kind of symbol in state diagram | ![]() | |||||||||||||||||||||
is a subtopic of 8.2 - State Diagrams | ![]() | ||||||||||||||||||||||
is drawn as an arrow connecting two states, with a label representing the event that causes the change of state | ![]() | ||||||||||||||||||||||
trigger question | has definition A question in a brainstorming session for which the participants can provide simple one-line answers that are more than just numbers or yes/no responses | ![]() | |||||||||||||||||||||
has example
| ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 4.6 - Some Techniques for Gathering and Analyzing Requirements | ![]() | ||||||||||||||||||||||
can be determined by the person who called the meeting, by the moderator, by a quick discussion, or by brainstorming, followed by a vote | ![]() | ||||||||||||||||||||||
true | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
try | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
TSP | is a subtopic of 10.11 - Quality Assurance in General | ![]() | |||||||||||||||||||||
is an abbreviation for Team Software Process | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
type use coupling | has definition A form of coupling in which several components make use of the same globally-defined data type | ![]() | |||||||||||||||||||||
has disadvantage if the type definition changes, then the users of the type may well have to change. | ![]() | ||||||||||||||||||||||
is less problematic than common coupling | ![]() | ||||||||||||||||||||||
is similar to common coupling, but instead of data being shared, only data types are shared | ![]() | ||||||||||||||||||||||
is a kind of coupling | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
occurs when a class declares a variable as having another class as its type | ![]() | ||||||||||||||||||||||
occurs in typed languages such as Java | ![]() | ||||||||||||||||||||||
can be reduced by | ![]() | ||||||||||||||||||||||
cannot be avoided | ![]() | ||||||||||||||||||||||
UCD | is an abbreviation for user centred design | ![]() | |||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
UI | is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | |||||||||||||||||||||
is an abbreviation for user interface | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
UML | is a subtopic of 5.1 - What is UML? | ![]() | |||||||||||||||||||||
is an abbreviation for Unified Modelling Language | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
UML diagram | describes aspects of the architectural model | ![]() | |||||||||||||||||||||
has part constraint | ![]() | ||||||||||||||||||||||
has part note | ![]() | ||||||||||||||||||||||
is a kind of diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 5.6 - More Advanced Features of Class Diagrams | ![]() | ||||||||||||||||||||||
see also Unified Modelling Language | ![]() | ||||||||||||||||||||||
shows classes, their attributes and operations as well as the various types of relationships that exist among the classes | ![]() | ||||||||||||||||||||||
UML diagram designer | discovers classes in source material such as requirements descriptions, interview notes, or the results of brainstorming sessions | ![]() | |||||||||||||||||||||
identifies associations and attributes once a good initial list of classes has been identified, starting with the most important classes and working outwards towards the classes that are less important | ![]() | ||||||||||||||||||||||
invents classes that are needed to solve a particular design problem | ![]() | ||||||||||||||||||||||
is a kind of designer | ![]() | ||||||||||||||||||||||
is a subtopic of 5.2 - Essentials of UML Class Diagrams | ![]() | ||||||||||||||||||||||
can find classes by extracting the nouns and noun phrases from source materials | ![]() | ||||||||||||||||||||||
can hide part objects inside the aggregate object to improve the encapsulation of the system so that methods in the system would be able to perform most operations on the aggregate, without needing to know about the existence of the parts | ![]() | ||||||||||||||||||||||
can identify generalizations using a bottom-up approach to identifying generalizations or a top-down approach to identifying generalizations | ![]() | ||||||||||||||||||||||
should ask herself whether a less restrictive multiplicity could also makes sense in some circumstances | ![]() | ||||||||||||||||||||||
should avoid overdoing generalization | ![]() | ||||||||||||||||||||||
should be concerned with reuse when identifying classes | ![]() | ||||||||||||||||||||||
should create an interface instead of a superclass if you will sometimes need to declare a variable that can contain instances of several classes, yet: | ![]() | ||||||||||||||||||||||
should create a distinct class if a subset of a class's attributes form a coherent group | ![]() | ||||||||||||||||||||||
should defer decisions about directionality to later phases of development, when the detailed design is created because although making associations one-directional can improve efficiency and reduce complexity, it might also limit the flexibility of the system. | ![]() | ||||||||||||||||||||||
should distribute responsibilities among the classes so no one class has an unfair share, and hence becomes unduly complex | ![]() | ||||||||||||||||||||||
should mark an association as an aggregation if the following are true: | ![]() | ||||||||||||||||||||||
should not represent actions as if they were associations | ![]() | ||||||||||||||||||||||
should not think of generalizations as special associations, a common misconception which arises because both generalizations and associations connect classes together in a class diagram | ![]() | ||||||||||||||||||||||
should read every association in both directions to verify that it makes sense because it is very common to make errors when creating associations - it is particularly easy to get the multiplicity wrong | ![]() | ||||||||||||||||||||||
should split a class into several distinct classes if it has too many responsibilities | ![]() | ||||||||||||||||||||||
should work in the following sequence
| ![]() | ||||||||||||||||||||||
UML Distilled | has author M. Fowler | ![]() | |||||||||||||||||||||
has ISBN number ISBN 0-201-65783-X | ![]() | ||||||||||||||||||||||
is a subtopic of 9.9 - Architecting and designing software - References | ![]() | ||||||||||||||||||||||
is an instance of software architecture book | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
UML distilled: A Brief Guide to the Standard Object Modeling Language | has author Martin Fowler | ![]() | |||||||||||||||||||||
has ISBN number 0-201-65783-X | ![]() | ||||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
is an instance of book about UML | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 1999 | ![]() | ||||||||||||||||||||||
uname | has example uname -n | ![]() | |||||||||||||||||||||
has purpose to find the host name of a computer | ![]() | ||||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of Unix or Linux command | ![]() | ||||||||||||||||||||||
unexpected exception | causes failure | ![]() | |||||||||||||||||||||
is a kind of exception | ![]() | ||||||||||||||||||||||
is a subtopic of 10.2 - Effective and Efficient Testing | ![]() | ||||||||||||||||||||||
occurs in a situation that was not anticipated by the programmer | ![]() | ||||||||||||||||||||||
Unicode | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of coding scheme | ![]() | ||||||||||||||||||||||
can represent all the symbols used in English and other languages | ![]() | ||||||||||||||||||||||
Unified Modelling Language | has custodian Object Management Group (OMG) | ![]() | |||||||||||||||||||||
has definition A standard language for modelling various aspects of software, which includes, among other things, a set of diagrammatic notations | ![]() | ||||||||||||||||||||||
has extension mechanisms which allow software designers to represent concepts that are not part of the core of UML | ![]() | ||||||||||||||||||||||
has objective to assist in software development | ![]() | ||||||||||||||||||||||
has semantics which describe the meaning of the various notations | ![]() | ||||||||||||||||||||||
is a kind of graphical language | ![]() | ||||||||||||||||||||||
is a subtopic of 5.1 - What is UML? | ![]() | ||||||||||||||||||||||
is abbreviated as UML | ![]() | ||||||||||||||||||||||
is accepted as the standard approach to representing many aspects of software | ![]() | ||||||||||||||||||||||
is an instance of modelling language | ![]() | ||||||||||||||||||||||
is associated with Object Constraint Language (OCL), a textual language that allows you to state various facts about the elements of the diagrams | ![]() | ||||||||||||||||||||||
is not a methodology because it does not describe in a step-by-step way how to do things | ![]() | ||||||||||||||||||||||
is used to create visual models of a software system | ![]() | ||||||||||||||||||||||
was invented by Booch, Rumbaugh and Jacobson in the 1990's | ![]() | ||||||||||||||||||||||
uninitialized object | has value null | ![]() | |||||||||||||||||||||
is a kind of Java object | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
unit testing | has definition Testing an individual module or component in isolation | ![]() | |||||||||||||||||||||
is a kind of testing performed by software engineers | ![]() | ||||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
Unix or Linux command | is a kind of command | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
usability | has definition An important quality of software that measures the extent to which a product or process is learnable, enables users to be productive and avoid errors, and also subjectively satisfies them (in contrast to utility^2) | ![]() | |||||||||||||||||||||
has part acceptability | ![]() | ||||||||||||||||||||||
has part efficiency of use | ![]() | ||||||||||||||||||||||
has part error handling | ![]() | ||||||||||||||||||||||
has part learnability | ![]() | ||||||||||||||||||||||
is important | ![]() | ||||||||||||||||||||||
is a kind of usefulness | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
Usability Engineering | has author J. Nielsen | ![]() | |||||||||||||||||||||
has ISBN number 0-12-518406-9 | ![]() | ||||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
is an instance of book about user interfaces and usability | ![]() | ||||||||||||||||||||||
was published by Academic Press Professional | ![]() | ||||||||||||||||||||||
was published in 1994 | ![]() | ||||||||||||||||||||||
usability evaluation | is a kind of verification | ![]() | |||||||||||||||||||||
is a subtopic of 7.6 - Evaluating User Interfaces | ![]() | ||||||||||||||||||||||
must adhere to ethical principle of usability evaluation | ![]() | ||||||||||||||||||||||
usability principle | is a kind of principle | ![]() | |||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
usability principle 1 | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of usability principle | ![]() | ||||||||||||||||||||||
states Do not rely only on usability guidelines - always test with users | ![]() | ||||||||||||||||||||||
can be followed by testing a user interface on users | ![]() | ||||||||||||||||||||||
usability principle 10 | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of usability principle | ![]() | ||||||||||||||||||||||
states Consider the needs of different groups of users | ![]() | ||||||||||||||||||||||
can be followed by
| ![]() | ||||||||||||||||||||||
usability principle 11 | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of usability principle | ![]() | ||||||||||||||||||||||
states Provide all necessary help | ![]() | ||||||||||||||||||||||
can be followed by
| ![]() | ||||||||||||||||||||||
usability principle 12 | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of usability principle | ![]() | ||||||||||||||||||||||
states Be consistent within the application and between applications | ![]() | ||||||||||||||||||||||
can be followed by
| ![]() | ||||||||||||||||||||||
usability principle 2 | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of usability principle | ![]() | ||||||||||||||||||||||
states Base UI designs on users' tasks as expressed in use cases | ![]() | ||||||||||||||||||||||
can be followed by
| ![]() | ||||||||||||||||||||||
usability principle 3 | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of usability principle | ![]() | ||||||||||||||||||||||
states Ensure that the sequences of actions to achieve a task are as simple as possible | ![]() | ||||||||||||||||||||||
can be followed by
| ![]() | ||||||||||||||||||||||
usability principle 4 | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of usability principle | ![]() | ||||||||||||||||||||||
states Ensure that the user always knows what he or she can and should do next, and what will happen when he or she does it | ![]() | ||||||||||||||||||||||
can be followed by
| ![]() | ||||||||||||||||||||||
usability principle 5 | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of usability principle | ![]() | ||||||||||||||||||||||
states Provide good feedback including effective error messages | ![]() | ||||||||||||||||||||||
can be followed by | ![]() | ||||||||||||||||||||||
usability principle 6 | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of usability principle | ![]() | ||||||||||||||||||||||
states Ensure that the user can always get out, go back or undo an action | ![]() | ||||||||||||||||||||||
can be followed by ensuring that all operations can be done and that it is easy for the user to navigate back to where they came from | ![]() | ||||||||||||||||||||||
usability principle 7 | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of usability principle | ![]() | ||||||||||||||||||||||
states Ensure that response time is adequate | ![]() | ||||||||||||||||||||||
can be followed by
| ![]() | ||||||||||||||||||||||
usability principle 8 | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of usability principle | ![]() | ||||||||||||||||||||||
states Ensure that the user always feels in control | ![]() | ||||||||||||||||||||||
can be followed by
| ![]() | ||||||||||||||||||||||
usability principle 9 | is a subtopic of 7.5 - Usability Principles | ![]() | |||||||||||||||||||||
is an instance of usability principle | ![]() | ||||||||||||||||||||||
states Ensure that the UI's appearance is uncluttered | ![]() | ||||||||||||||||||||||
can be followed by
| ![]() | ||||||||||||||||||||||
Usable Web | has URL www.usableweb.com ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
is an instance of web site about usability | ![]() | ||||||||||||||||||||||
use case | assists an architect with the first draft of the architectural model | ![]() | |||||||||||||||||||||
describes the user's interaction with the system | ![]() | ||||||||||||||||||||||
give an architect an idea about which components will be needed and how they will interact | ![]() | ||||||||||||||||||||||
has a use case name | ![]() | ||||||||||||||||||||||
has actors the actors or actor who can perform this use case (optional) | ![]() | ||||||||||||||||||||||
has definition A way in which a system can be used, described as a step-by-step sequence of actions, along with the system's response and certain other information | ![]() | ||||||||||||||||||||||
has goals zero or more goals | ![]() | ||||||||||||||||||||||
has postconditions zero or more postconditions | ![]() | ||||||||||||||||||||||
has preconditions zero or more preconditions which describe the state of the system before the use case occurs | ![]() | ||||||||||||||||||||||
has related use cases zero or more use cases that may be generalizations, specializations, extensions or inclusions of this one | ![]() | ||||||||||||||||||||||
has steps each step of the use case using a two column format, with the left column showing the actions taken by the actor, and the right column showing the system responses | ![]() | ||||||||||||||||||||||
has summary | ![]() | ||||||||||||||||||||||
includes only actions in which the actor interacts with the computer | ![]() | ||||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
is used to develop requirements | ![]() | ||||||||||||||||||||||
is used to validate requirements | ![]() | ||||||||||||||||||||||
normally includes only actions in which the actor interacts with the system | ![]() | ||||||||||||||||||||||
use case analysis | assists a software engineer to define the tasks that the user interface must help the user perform | ![]() | |||||||||||||||||||||
has definition The process of dividing up the functionality of the system into use cases, and determining the relationships among those use cases | ![]() | ||||||||||||||||||||||
has procedure | ![]() | ||||||||||||||||||||||
has purpose to model the system from the point of view of how users or other systems interact with this system when trying to achieve their objectives | ![]() | ||||||||||||||||||||||
helps developers model different user roles | ![]() | ||||||||||||||||||||||
is an intuitive way to understand and organize what the system should do, since it is based on user tasks and expresses the tasks in natural language | ![]() | ||||||||||||||||||||||
is similar to task analysis | ![]() | ||||||||||||||||||||||
is useful for requirements analysis | ![]() | ||||||||||||||||||||||
is a kind of analysis | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
can be used to determine responsibilities | ![]() | ||||||||||||||||||||||
can be used to eliminate proposed functionality if the functionality does not support any use case | ![]() | ||||||||||||||||||||||
can help define the scope of the system, i.e. what the system must do and does not have to do | ![]() | ||||||||||||||||||||||
does not cover all aspects of software, such as an activity that is internal to a system | ![]() | ||||||||||||||||||||||
use case | can be used to plan the development process | ![]() | |||||||||||||||||||||
can be used to structure user manuals | ![]() | ||||||||||||||||||||||
can form the basis for the definition of test cases | ![]() | ||||||||||||||||||||||
can serve as as part of the contract between the customers and the developer | ![]() | ||||||||||||||||||||||
use case diagram | contains actor symbols and use case symbols with arrows indicating which actors perform which use cases | ![]() | |||||||||||||||||||||
has definition A UML diagram showing actors, use cases and their relationships | ![]() | ||||||||||||||||||||||
has purpose to show the relationships among a set of use cases and actors | ![]() | ||||||||||||||||||||||
helps a software engineer to convey a high level picture of the functionality of a system | ![]() | ||||||||||||||||||||||
is a kind of UML diagram | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
summarize the system from the user's perspective | ![]() | ||||||||||||||||||||||
use case | does not describe the computations the system performs | ![]() | |||||||||||||||||||||
Use Case Maps for Object-Oriented Systems | has author R.J.A. Buhr, and R. Casselman | ![]() | |||||||||||||||||||||
has ISBN number 0-13-456542-8 | ![]() | ||||||||||||||||||||||
is a subtopic of 8.5 - Modelling Interactions and Behaviour - References | ![]() | ||||||||||||||||||||||
is an instance of book about modelling interactions and behaviour | ![]() | ||||||||||||||||||||||
was published by Prentice Hall | ![]() | ||||||||||||||||||||||
was published in 1996 | ![]() | ||||||||||||||||||||||
use case | may have high political or commercial value | ![]() | |||||||||||||||||||||
may have one or more preconditions | ![]() | ||||||||||||||||||||||
may represent a high risk because for some reason their implementation is problematic. | ![]() | ||||||||||||||||||||||
use case model | consists of a set of use cases, and an optional description or diagram indicating how they are related | ![]() | |||||||||||||||||||||
has part description or diagram indicating how use cases are related | ![]() | ||||||||||||||||||||||
has part use case | ![]() | ||||||||||||||||||||||
is a kind of model | ![]() | ||||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
use case modelling | has definition Representing the sequences of actions performed by users of software. | ![]() | |||||||||||||||||||||
is a kind of modelling | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
see also use case | ![]() | ||||||||||||||||||||||
use case | must be validated using requirements validation methods | ![]() | |||||||||||||||||||||
use case name | is a kind of name | ![]() | |||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
use case | should be independent of any particular user interface design | ![]() | |||||||||||||||||||||
use case symbol | is a kind of symbol in UML diagram | ![]() | |||||||||||||||||||||
is a subtopic of 7.3 - Developing Use Case Models of Systems | ![]() | ||||||||||||||||||||||
is drawn as an ellipse | ![]() | ||||||||||||||||||||||
Use Cases: Requirements in Context | has author D. Kulak and E. Guiney | ![]() | |||||||||||||||||||||
has ISBN number 0-201-65767-8 | ![]() | ||||||||||||||||||||||
is a subtopic of 4.13 - Developing Requirements - References | ![]() | ||||||||||||||||||||||
is an instance of book about requirements analysis | ![]() | ||||||||||||||||||||||
was published by Addison-Wesley | ![]() | ||||||||||||||||||||||
was published in 2000 | ![]() | ||||||||||||||||||||||
use of a non-stable sort | has testing strategy deliberately run an experiment to see if the results are as expected | ![]() | |||||||||||||||||||||
is a kind of use of an inappropriate standard algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
use of a search or sort that is case sensitive when it should not be | has testing strategy test algorithms with mixed-case data to see if the algorithm behaves as expected | ![]() | |||||||||||||||||||||
is a kind of use of an inappropriate standard algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
use of a search or sort that is not case sensitive when it should be | has testing strategy test algorithms with mixed-case data to see if the algorithm behaves as expected | ![]() | |||||||||||||||||||||
is a kind of use of an inappropriate standard algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
use of an inappropriate standard algorithm | has definition A common defect in which an unnecessarily inefficient or otherwise inappropriate algorithm is used | ![]() | |||||||||||||||||||||
has testing strategy design tests that highlight the properties of inappropriate algorithms such as execution time | ![]() | ||||||||||||||||||||||
is a kind of defect in an ordinary algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
use of an inefficient search algorithm | has testing strategy
| ![]() | |||||||||||||||||||||
is a kind of use of an inappropriate standard algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
use of an inefficient sort algorithm | has example using a 'bubble sort' instead of a more efficient approach to sorting | ![]() | |||||||||||||||||||||
has testing strategy | ![]() | ||||||||||||||||||||||
is a kind of use of an inappropriate standard algorithm | ![]() | ||||||||||||||||||||||
is a subtopic of 10.3 - Defects in Ordinary Algorithms | ![]() | ||||||||||||||||||||||
usefulness | consists of utility^2 and usability | ![]() | |||||||||||||||||||||
has definition The extent to which a system can be used to perform a task; combines usability and utility^2 | ![]() | ||||||||||||||||||||||
is essential | ![]() | ||||||||||||||||||||||
is a kind of external software quality | ![]() | ||||||||||||||||||||||
is a kind of measurement | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is measured in the context of particular types of users | ![]() | ||||||||||||||||||||||
Useit.com | has author Jakob Nielsen | ![]() | |||||||||||||||||||||
has URL www.useit.com ![]() | ![]() | ||||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
is an instance of web site about usability | ![]() | ||||||||||||||||||||||
user | feels that he or she has enough information to make decisions if the system informs her of what it is doing, has done and is about to do | ![]() | |||||||||||||||||||||
has a perception of acceptable response time based on the other applications she uses | ![]() | ||||||||||||||||||||||
has characteristics that vary from one user to another including: | ![]() | ||||||||||||||||||||||
has definition A person who uses software (in contrast to customer) | ![]() | ||||||||||||||||||||||
has goal doing enjoyable or interesting work, and gaining recognition for the work they have done | ![]() | ||||||||||||||||||||||
is a kind of stakeholder | ![]() | ||||||||||||||||||||||
is a subtopic of 1.4 - Stakeholders in Software Engineering | ![]() | ||||||||||||||||||||||
is concerned with efficiency | ![]() | ||||||||||||||||||||||
is concerned with reliability | ![]() | ||||||||||||||||||||||
likes software that is easy to learn and use, makes their life easier, helps them achieve more, or allows them to have fun | ![]() | ||||||||||||||||||||||
makes mistakes | ![]() | ||||||||||||||||||||||
often welcomes new or improved software | ![]() | ||||||||||||||||||||||
wants software that is easy to learn | ![]() | ||||||||||||||||||||||
wants software that is easy to learn, efficient to use, and which helps get work done | ![]() | ||||||||||||||||||||||
can learn an application quickly if it is similar to an application they already know | ![]() | ||||||||||||||||||||||
can notice a single small spot of red or orange on an entire screen | ![]() | ||||||||||||||||||||||
user centred design | has definition An approach to software engineering using techniques that focus on users and their needs | ![]() | |||||||||||||||||||||
helps developers prioritize their work so that the most important features reach the users sooner | ![]() | ||||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 7.1 - User Centred Design | ![]() | ||||||||||||||||||||||
is abbreviated as UCD | ![]() | ||||||||||||||||||||||
requires developers to understand users | ![]() | ||||||||||||||||||||||
can be accomplished if developers follow certain guidelines including: | ![]() | ||||||||||||||||||||||
can ensure that unnecessary features and functions are not added to the software | ![]() | ||||||||||||||||||||||
can improve the quality of software | ![]() | ||||||||||||||||||||||
can improve the system's efficiency of use | ![]() | ||||||||||||||||||||||
can make the system more attractive so users may be more willing to buy and use it | ![]() | ||||||||||||||||||||||
can reduce costs associated with changing the system later | ![]() | ||||||||||||||||||||||
can reduce costs by only developing features that are needed | ![]() | ||||||||||||||||||||||
can reduce the cost to produce, operate and maintain software | ![]() | ||||||||||||||||||||||
can reduce the time needed to learn the system | ![]() | ||||||||||||||||||||||
can reduce training and support costs | ![]() | ||||||||||||||||||||||
user community for use case maps | has URL www.usecasemaps.org ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 8.5 - Modelling Interactions and Behaviour - References | ![]() | ||||||||||||||||||||||
is an instance of web site about modelling interactions and behaviour | ![]() | ||||||||||||||||||||||
user | does not fear bad consequences of what he does if he can undo any action | ![]() | |||||||||||||||||||||
does not feel that the computer is in control of her time if response time is adequate | ![]() | ||||||||||||||||||||||
user interface | is the part of a system that is most likely to cause users to perceive a lack of quality. | ![]() | |||||||||||||||||||||
is a kind of subject | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is abbreviated as UI | ![]() | ||||||||||||||||||||||
is often the most complex part of the system to design, and the part that is most likely to cause users to perceive a lack of quality | ![]() | ||||||||||||||||||||||
was simpler in the early days of computing | ![]() | ||||||||||||||||||||||
can take over half of all development effort | ![]() | ||||||||||||||||||||||
user interface component | has definition A component used to create the user interface such as a menu, list, input field etc. | ![]() | |||||||||||||||||||||
is a kind of component | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is a synonym of control | ![]() | ||||||||||||||||||||||
is a synonym of widget | ![]() | ||||||||||||||||||||||
user interface design | has been historically seen as separate from software engineering | ![]() | |||||||||||||||||||||
has definition The design of the user interface of a software system | ![]() | ||||||||||||||||||||||
involves deciding in detail how the user is to interact with the system | ![]() | ||||||||||||||||||||||
is a kind of design | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is part of design | ![]() | ||||||||||||||||||||||
should be done in conjunction with other software engineering activities | ![]() | ||||||||||||||||||||||
should be performed after domain analysis and problem definition | ![]() | ||||||||||||||||||||||
should be understood by all software engineers | ![]() | ||||||||||||||||||||||
user interface designer | asks user's opinions | ![]() | |||||||||||||||||||||
avoids modal dialogs because they force the user to constantly press 'OK' or 'Cancel' to move on to the next step | ![]() | ||||||||||||||||||||||
avoids technical jargon and acronyms in text | ![]() | ||||||||||||||||||||||
bases user interface design on user's tasks | ![]() | ||||||||||||||||||||||
chooses coding techniques with care | ![]() | ||||||||||||||||||||||
employs a skilled writer to write the text and a skilled graphical designer to create graphics | ![]() | ||||||||||||||||||||||
ensure that the user interface appears uncluttered | ![]() | ||||||||||||||||||||||
ensures that everything that appears on the screen is understandable by all users | ![]() | ||||||||||||||||||||||
ensures that good labels are used so that all coding techniques are fully understood by users | ![]() | ||||||||||||||||||||||
ensures that if operations take up to 15-20 seconds, such as loading complex pages from the net over a modem-based connection, the user understands that they are naturally time-consuming and an indication of progress is shown | ![]() | ||||||||||||||||||||||
ensures that response time is adequate | ![]() | ||||||||||||||||||||||
ensures that response times are a second or less for operations such as saving most data, moving between windows, obtaining help, and obtaining the first feedback from any longer operation | ![]() | ||||||||||||||||||||||
ensures that the application mimics other applications | ![]() | ||||||||||||||||||||||
ensures that the system has different modes for beginners and power users if the system is complex | ![]() | ||||||||||||||||||||||
ensures that the system is usable by people with disabilities | ![]() | ||||||||||||||||||||||
ensures that the user always feels in control by being allowed to set system preferences | ![]() | ||||||||||||||||||||||
ensures that the user can always get out, go back or undo an action | ![]() | ||||||||||||||||||||||
ensures that the user can see what commands are available and are not available | ![]() | ||||||||||||||||||||||
ensures that the user can undo an action that may have changed data in the system | ![]() | ||||||||||||||||||||||
ensures that the user does not have to navigate anywhere to do subsequent steps of a task | ![]() | ||||||||||||||||||||||
ensures that the user interface does not have too many pages, each with only a small amount of information, because the user will have to spend much time navigating and will become lost | ![]() | ||||||||||||||||||||||
ensures that the user interface does not use too many different colours, fonts or graphics | ![]() | ||||||||||||||||||||||
ensures that the user interface informs users of the progress of operations, changes of state, and of their location as they navigate | ![]() | ||||||||||||||||||||||
ensures that the user interface only displays essential information, while allowing the user to request additional information by navigating to another dialog box, tab or page | ![]() | ||||||||||||||||||||||
ensures that the user interface warns the user if the response time for an operation will be more than 15-20 seconds so the user can do something else while waiting or choose not to perform the operation | ![]() | ||||||||||||||||||||||
ensures that the user is not affected by information overload | ![]() | ||||||||||||||||||||||
ensures that the user is warned before they perform an action, if the action cannot be undone and asks the user to confirm an action if it can have serious consequences and cannot be undone | ![]() | ||||||||||||||||||||||
ensures that when something goes wrong, the user interface explains the situation in adequate detail and helps the user to resolve the problem | ![]() | ||||||||||||||||||||||
evaluates how users use prototypes of user interfaces | ![]() | ||||||||||||||||||||||
evaluates response time by testing on the slowest hardware that end-users are likely to encounter | ![]() | ||||||||||||||||||||||
follows look-and-feel standards | ![]() | ||||||||||||||||||||||
follows usability principles but not rely solely on them | ![]() | ||||||||||||||||||||||
internationalizes the user interface | ![]() | ||||||||||||||||||||||
is aware of locale-dependent features | ![]() | ||||||||||||||||||||||
is responsible for making sure that usability is kept at the forefront of the design process | ![]() | ||||||||||||||||||||||
is a kind of designer | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is part of software development team | ![]() | ||||||||||||||||||||||
makes the most important commands stand out by using large buttons, by being the first item in a menu or by being the leftmost icon in a toolbar | ![]() | ||||||||||||||||||||||
makes sure that elements are arranged in straight lines or several columns | ![]() | ||||||||||||||||||||||
performs use case analysis and designs the user interface based on this | ![]() | ||||||||||||||||||||||
provides good help system | ![]() | ||||||||||||||||||||||
reduces the amount of reading and manipulation the user has to do | ![]() | ||||||||||||||||||||||
thinks about the sequence of activities the user will want to perform to get their job done | ![]() | ||||||||||||||||||||||
uses grouping, colour and fonts to help highlight the organization of information | ![]() | ||||||||||||||||||||||
uses similar layouts and graphic designs throughout the application | ![]() | ||||||||||||||||||||||
always defers to users by both asking their opinions and evaluating how they use prototypes | ![]() | ||||||||||||||||||||||
should avoid fancy and unusual UI designs, and especially the design of new controls, because they will be more sensitive to changes | ![]() | ||||||||||||||||||||||
should not focus on the commands, fields and icons etc. that are needed because this approach tends to result in systems that do not fit the users' tasks | ![]() | ||||||||||||||||||||||
should not give the user too much to look at | ![]() | ||||||||||||||||||||||
should not invent new user interface controls because users will have to figure them out | ![]() | ||||||||||||||||||||||
should use simpler UI frameworks that are widely used by others | ![]() | ||||||||||||||||||||||
user interface layer | handles the user interface | ![]() | |||||||||||||||||||||
is a kind of layer | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
must be independent because there will often be several different UIs for the application | ![]() | ||||||||||||||||||||||
should be at the top of a multi-layer system | ![]() | ||||||||||||||||||||||
user interface prototyping | involves extensive discussion with, and evaluation by, both users and other user interface designers | ![]() | |||||||||||||||||||||
is iterative | ![]() | ||||||||||||||||||||||
is a kind of prototyping | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
user interface | should always be tested on users | ![]() | |||||||||||||||||||||
user interface state | changes if the user issues a command, or if the system itself notifies the user of some happening, such as the completion of an earlier command or the arrival of a message | ![]() | |||||||||||||||||||||
has definition At any point in time, the information displayed in widgets and the user interface's affordance | ![]() | ||||||||||||||||||||||
is a kind of state | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
user interface statement | is a kind of statement | ![]() | |||||||||||||||||||||
is a subtopic of Programming Style Guidelines | ![]() | ||||||||||||||||||||||
should be restricted to specifically designed classes | ![]() | ||||||||||||||||||||||
user | may be affected by information overload | ![]() | |||||||||||||||||||||
may be frustrated when they seek help | ![]() | ||||||||||||||||||||||
may fear that new software could jeopardize their job | ![]() | ||||||||||||||||||||||
may judge utility^2 and usability differently from another user depending on her level of computer experience and the tasks she is performing | ![]() | ||||||||||||||||||||||
may work for customer | ![]() | ||||||||||||||||||||||
must be involved in the development of software | ![]() | ||||||||||||||||||||||
must like a system or they will not use it, even if it has high learnability and efficiency of use | ![]() | ||||||||||||||||||||||
should be able to understand everything that appears on the screen | ![]() | ||||||||||||||||||||||
should be involved in all decision-making that relates to the requirements and to the user interface design and to a limited extent in requirements analysis | ![]() | ||||||||||||||||||||||
should be involved in requirements analysis, user interface design and deployment, and also may play a role in design, quality assurance and project management | ![]() | ||||||||||||||||||||||
should be made to feel involved in the software engineering process resulting in fewer mistakes being made and greater acceptance of the finished product | ![]() | ||||||||||||||||||||||
should feel in control of the computer, not the other way around | ![]() | ||||||||||||||||||||||
should give feedback on prototypes, on-line help and draft user manuals | ![]() | ||||||||||||||||||||||
should not be expected to participate in detailed low-level internal design decisions | ![]() | ||||||||||||||||||||||
user with a disability | is a kind of user | ![]() | |||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
utility | has definition A method or class that has wide applicability to many different subsystems and is designed to be reusable | ![]() | |||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a kind of method | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
see also utility^2 | ![]() | ||||||||||||||||||||||
utility cohesion | has definition A form of cohesion in which utilities which cannot be logically placed in other cohesive units are kept together | ![]() | |||||||||||||||||||||
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 | ![]() | ||||||||||||||||||||||
is a kind of cohesion | ![]() | ||||||||||||||||||||||
is a subtopic of 9.2 - Principles Leading to Good Design | ![]() | ||||||||||||||||||||||
utility^2 | has definition The extent to which, independent of usability, a product or process provides capabilities needed to solve a customer's problem | ![]() | |||||||||||||||||||||
is a kind of usefulness | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
see also utility | ![]() | ||||||||||||||||||||||
valid generalization | contains only features that must make sense in each subclass | ![]() | |||||||||||||||||||||
is a kind of generalization | ![]() | ||||||||||||||||||||||
is a subtopic of 2.5 - Organizing Classes Into Inheritance Hierarchies | ![]() | ||||||||||||||||||||||
validation | has definition The process of ensuring that requirements and designs solve the customer's problem | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
variable | has definition A place where you can put data | ![]() | |||||||||||||||||||||
has scope | ![]() | ||||||||||||||||||||||
has type | ![]() | ||||||||||||||||||||||
is a kind of data item | ![]() | ||||||||||||||||||||||
is a subtopic of 2.3 - Instance Variables | ![]() | ||||||||||||||||||||||
can contain different classes of objects depending on the type of the variable | ![]() | ||||||||||||||||||||||
can refer to a particular object, several different objects during the execution of a program, or no object at all | ![]() | ||||||||||||||||||||||
variable declared as a non-primitive data type | contains an instance of a class | ![]() | |||||||||||||||||||||
is a kind of variable | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is used by calling methods or accessing the object's instance variables | ![]() | ||||||||||||||||||||||
uses the name of a class as their type | ![]() | ||||||||||||||||||||||
variable declared as primitive data type | is a kind of variable | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
does not contain object in the sense that its contents is not an instance of any class | ![]() | ||||||||||||||||||||||
variable | should have comment if it is non-obvious | ![]() | |||||||||||||||||||||
Vector | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java collection class | ![]() | ||||||||||||||||||||||
verification | has definition The process of ensuring that the design or implementation conforms to the requirements; the process of ascertaining that the software has no defects | ![]() | |||||||||||||||||||||
is a kind of process | ![]() | ||||||||||||||||||||||
is a subtopic of 1.7 - Activities Common to Software Projects | ![]() | ||||||||||||||||||||||
vertical framework | has fewer slots and hooks than a horizontal framework | ![]() | |||||||||||||||||||||
has more complete implementation than a horizontal framework | ![]() | ||||||||||||||||||||||
has definition A complete framework for a particular class of applications. A near-synonym for application framework | ![]() | ||||||||||||||||||||||
is a kind of framework | ![]() | ||||||||||||||||||||||
is a subtopic of 3.3 - Frameworks: Reusable Subsystems | ![]() | ||||||||||||||||||||||
is a synonym of application framework | ![]() | ||||||||||||||||||||||
vertical incremental testing | is a kind of incremental testing | ![]() | |||||||||||||||||||||
is a subtopic of 10.9 - Strategies for Testing Large Systems | ![]() | ||||||||||||||||||||||
video | has advantages
| ![]() | |||||||||||||||||||||
has problems
| ![]() | ||||||||||||||||||||||
is a kind of coding technique | ![]() | ||||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
view | contains objects used to render the appearance of the data from the model in the user interface | ![]() | |||||||||||||||||||||
displays the various controls with which the user can interact | ![]() | ||||||||||||||||||||||
has definition In the MVC architecture, the class or classes used to render the appearance of the data from the model in the user interface | ![]() | ||||||||||||||||||||||
is a kind of class | ![]() | ||||||||||||||||||||||
is a subtopic of 9.5 - Architectural Patterns | ![]() | ||||||||||||||||||||||
virtual binding | is a synonym of dynamic binding | ![]() | |||||||||||||||||||||
virtual machine | is a kind of component | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is abbreviated as VM | ![]() | ||||||||||||||||||||||
usually uses just-in-time compilation | ![]() | ||||||||||||||||||||||
VM | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an abbreviation for virtual machine | ![]() | ||||||||||||||||||||||
is an instance of abbreviation | ![]() | ||||||||||||||||||||||
void | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
volatile | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
waterfall model | forms the foundation of many software development methodologies in use today | ![]() | |||||||||||||||||||||
has definition A process model in which the software engineer works in a series of stages | ![]() | ||||||||||||||||||||||
has principles
| ![]() | ||||||||||||||||||||||
has some limitations | ![]() | ||||||||||||||||||||||
has weaknesses if followed too closely:
| ![]() | ||||||||||||||||||||||
is better than the opportunistic approach | ![]() | ||||||||||||||||||||||
is a kind of process model | ![]() | ||||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
is named because diagrams of it tend to look like cascading waterfalls | ![]() | ||||||||||||||||||||||
recognizes the importance of requirements, design and quality assurance | ![]() | ||||||||||||||||||||||
web site | is a kind of publication | ![]() | |||||||||||||||||||||
web site about British standards | has URL bsonline.techindex.co.uk ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
is an instance of web site about standards | ![]() | ||||||||||||||||||||||
web site about design patterns | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 6.15 - Using Design Patterns - References | ![]() | ||||||||||||||||||||||
web site about extreme programming | has URL www.extremeprogramming.org ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 11.2 - Software Process Models | ![]() | ||||||||||||||||||||||
is an instance of web site | ![]() | ||||||||||||||||||||||
web site about Java | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 2.11 - Review of Object Orientation and Java - References | ![]() | ||||||||||||||||||||||
web site about modelling interactions and behaviour | is a kind of web site | ![]() | |||||||||||||||||||||
web site about project management | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
web site about requirements analysis | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 4.13 - Developing Requirements - References | ![]() | ||||||||||||||||||||||
web site about software architecture | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 9.9 - Architecting and designing software - References | ![]() | ||||||||||||||||||||||
web site about software failures | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
web site about software quality assurance | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
web site about software testing | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 10.14 - Testing and Inspecting to Ensure High Quality - References | ![]() | ||||||||||||||||||||||
web site about standards | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 11.8 - Managing the Software Process - References | ![]() | ||||||||||||||||||||||
web site about the client-server architecture | is a kind of web site about software architecture | ![]() | |||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
web site about the Internet | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
web site about UML | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 5.11 - Modelling With Classes - References | ![]() | ||||||||||||||||||||||
web site about usability | is a kind of web site | ![]() | |||||||||||||||||||||
is a subtopic of 7.9 - Focusing on Users and Their Tasks - References | ![]() | ||||||||||||||||||||||
weighted average cost | equals two to three times average salary | ![]() | |||||||||||||||||||||
has definition The cost of employing a person, including the cost of benefits, office and management support | ![]() | ||||||||||||||||||||||
includes the average salary of a software engineer and the cost of providing that person with benefits, an office, a desk, a computer as well as technical and managerial support | ![]() | ||||||||||||||||||||||
is a kind of cost | ![]() | ||||||||||||||||||||||
is a subtopic of 11.3 - Cost Estimation | ![]() | ||||||||||||||||||||||
is a synonym of burdened cost | ![]() | ||||||||||||||||||||||
while | is a subtopic of The Basics of Java | ![]() | |||||||||||||||||||||
is an instance of Java keyword | ![]() | ||||||||||||||||||||||
while loop | has form while(condition) | ![]() | |||||||||||||||||||||
is a kind of loop | ![]() | ||||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
can be interchanged with a for loop | ![]() | ||||||||||||||||||||||
white-box testing | is a synonym of glass-box testing | ![]() | |||||||||||||||||||||
widget | is a synonym of control | ![]() | |||||||||||||||||||||
is a synonym of user interface component | ![]() | ||||||||||||||||||||||
window | is a kind of user interface component | ![]() | |||||||||||||||||||||
is a subtopic of 7.4 - The Basics of User Interface Design | ![]() | ||||||||||||||||||||||
Windows command | is a kind of command | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
winipcfg | has purpose to find the host name of a Windows 95 or 98 computer | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of Windows command | ![]() | ||||||||||||||||||||||
wizard | guides the user from one step to the next | ![]() | |||||||||||||||||||||
is a kind of user interface | ![]() | ||||||||||||||||||||||
is a subtopic of 7.5 - Usability Principles | ![]() | ||||||||||||||||||||||
world wide web | has clients browsers that display web pages and post forms, e.g. Netscape Navigator or Microsoft Internet Explorer | ![]() | |||||||||||||||||||||
has server web servers that manage sets of web pages and CGI programs, and send information to browsers when sent a URL | ![]() | ||||||||||||||||||||||
is a subtopic of 3.4 - The Client-Server Architecture | ![]() | ||||||||||||||||||||||
is an instance of client-server system | ![]() | ||||||||||||||||||||||
Yahoo software reuse page | has URL ca.yahoo.com/Computers_and_Internet/Software/Programming_Tools/Software_Engineering/Software_Reuse ![]() | ![]() | |||||||||||||||||||||
is a subtopic of 3.11 - Basing Software Development on Reusable Technology - References | ![]() | ||||||||||||||||||||||
is an instance of software reuse web site | ![]() | ||||||||||||||||||||||
ypcat hosts | has purpose to find the IP address of a Unix or Linux computer corresponding to a host name, or to find the host name corresponding to an IP address | ![]() | |||||||||||||||||||||
is a subtopic of 3.5 - Technology Needed to Build Client-Server Systems | ![]() | ||||||||||||||||||||||
is an instance of Unix or Linux command | ![]() | ||||||||||||||||||||||
|| | indicates logical OR | ![]() | |||||||||||||||||||||
is a subtopic of The Basics of Java | ![]() | ||||||||||||||||||||||
is an instance of Java logical operator | ![]() | ||||||||||||||||||||||
is an instance of short circuit operator | ![]() |