| ! | 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 | example expression | equivalent longer expression |
|---|
| a*=b; | a=a*b; |
|  |
| 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 | example expression | equivalent longer expression |
|---|
a++; b=a++; ++a; b=++a; | a=a+1; b=a; a=a+1; a=a+1; a=a+1; b=a; |
|  |
| 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 | example expression | equivalent longer expression |
|---|
| a+=b; | a=a+b; |
|  |
| 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 | example expression | equivalent longer expression |
|---|
a--; b=a--; --a; b=--a; | a=a-1; b=a; a=a-1; a=a-1; a=a-1; b=a; |
|  |
| 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 | example expression | equivalent longer expression |
|---|
| a-=b; | a=a-b; |
|  |
| 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 | example expression | equivalent longer expression |
|---|
| a/=b; | a=/b; |
|  |
| 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 - can be distracting and annoying
- can be hard to interpret
- not usable by deaf people
|  |
| 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 - You want to represent the members of each set of occurrences without duplicating the common information
- You want a solution that maximizes the flexibility of the system
|  |
| 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 - Create an «Abstraction» class that contains the data that is common to all the members of a set of occurrences.
- Then create an «Occurrence» class representing the occurrences of this abstraction.
- Connect these classes with a one-to-many association
|  |
| 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 - to decide whether software is of sufficient quality either to purchase or to pay a custom developer
- to choose between several competing generic products
|  |
| 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 - Rather than directly incorporating the reused class into your inheritance hierarchy, instead incorporate an «Adapter» class.
- The «Adapter»is connected by an association to the reused class, which we will call the «Adaptee».
- The polymorphic methods of the «Adapter» delegate to methods of the «Adaptee».
- The delegate method in the «Adaptee» may or may not have the same name as the delegating polymorphic method.
|  |
| 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 - You should almost never require a specific format for these items since they differ so widely and can change at any time
- Allow free-form input of whatever the user wants to type
|  |
| 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 - E is the effort estimate
- N is the estimate or measure being used as the basis for the effort estimate (e.g. number of use cases or lines of code)
- a, b and c are obtained by extensive analysis of past projects and comparisons with the current project
|  |
| 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 - you typically are able to have a much larger volume of testing performed
- the users use the software in the same manner that they will use it when it is formally released
|  |
| 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 - provides high impact communication of complex information
- entertaining and hence attractive for users
|  |
has problems - bandwidth-intensive, hence reduces response time
- sequential, requiring replay
- viewing consumes the user's time
- not usable by blind and possibly deaf people
- expensive to produce
- may be annoying
|  |
| 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 - Avoiding the use of early releases of technology
- Avoiding the use of software libraries that are specific to particular environments
- Avoiding the use of undocumented features or little-used features of software libraries
- Avoiding the use of reusable software or special hardware from smaller companies, or from those that are less likely to provide long-term support
- Using standard languages and technologies that are supported by multiple vendors
|  |
| 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 - integrating the work of individual people to form the final system
- planning and co-ordination of the work of developing a complex software system which is distributed among a large number of people
- planning the evolution of the system, such as subsystems that are envisioned to be part of a future release
|  |
| 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- The logical breakdown into subsystems, often shown using package diagrams
- The dynamics of the interaction among components at run time, expressed using interaction or activity diagrams
- The data that will be shared among the subsystems, expressed using class diagrams
- The components that will exist at run time, and the machines or devices on which they will be located, expressed using component and deployment diagrams
|  |
| 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: - Sketch an outline of the architecture, based on the principal requirements and use cases. Determine the main components that will be needed, such as databases, particular hardware devices and the main software subsystems
- Refine the architecture by identifying the main ways in which the components will interact, and by identifying the interfaces between them. Decide how each piece of data and functionality will be distributed among the various components
- Consider each use case and adjust the architecture to make it realizable
- Mature the architecture as you define the final class diagrams and interaction diagrams
|  |
| 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: - Sketch an outline of the architecture, based on the principal requirements and use cases. Determine the main components that will be needed, such as databases, particular hardware devices and the main software subsystems. Choose architectural patterns.
- Refine the architecture by identifying the main ways in which the components will interact, and by identifying the interfaces between them. Decide how each piece of data and functionality will be distributed among the various components. Determine if you can re-use an existing framework.
- Consider each use case and adjust the architecture to make it realizable
- Mature the architecture as you define the final class diagrams and interaction diagrams
|  |
| 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 - you typically are able to have a much larger volume of testing performed
- the users use the software in the same manner that they will use it when it is formally released
|  |
| 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 - in a group session people are energized and tend to spontaneously invent many good ideas, stimulated by what others have said
- introverted or timid people can have their say effectively since anonymity can be assured
|  |
| 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 - Call a meeting with representation from all stakeholders
- Appoint an experienced moderator
- Arrange the attendees around the periphery of a table and give them plenty of paper to work with
- Decide on a trigger question
- Ask each participant to follow these instructions:
- Think of an answer to the trigger question
- Write the answer down in one or two lines on a sheet of paper, one idea per sheet
- Pass the paper to the neighbour on your left to stimulate their thoughts
- Look at the answers passed from your neighbour to the right and pass these on to your left as well. Use the ideas you have read to stimulate your own ideas
- Continue step 5 until ideas stop flowing or a fixed time (5-15 minutes) passes
- Ask everybody to read out one of the ideas on the sheets that happens to be in front of them. The moderator writes the each idea on a flip chart
- Take a series of votes to prioritize the ideas
|  |
| 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 - its syntax is quite complex
- it is too easy to create code that has bugs
- large C++ programs have thus been found to be hard to maintain - they deteriorate rapidly as many programmers make changes
|  |
| 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 - although international business is based on the Gregorian calendar, the calendars of certain cultures and religions are also used in some places
|  |
| 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 - Unicode can handle most world character sets, but you also have to ensure that appropriate fonts are available
|  |
| 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 - code describing how the objects of the class are structured - i.e. the data stored in each object that implement the properties
- The procedures, called methods, that implement the behaviour of the objects
|  |
| 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 - redundant
- represent instances
- are vague or general
- correspond to classes that are not needed for this application or this type of model
|  |
| 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: - Default or 'constant' values that are widely used by methods in a class
- Lookup tables and similar structures used by algorithms inside a particular class
|  |
| 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 - The computational work can be distributed among different machines
- The clients can access the server's functionality from a distance
- The client and server can be designed separately, so they can both be simpler than a program that does everything
- All the data can be kept centrally at the server, thus making it easier to assure its reliability
- Conversely, distributing data among many different geographically-distributed clients or servers can mean that if a disaster occurs in one place, the loss of data is minimized
- The server can be accessed simultaneously by many clients
- Competing clients can be written to communicate with the same server, and vice-versa
|  |
has alternatives - Have a single program on one computer that does everything
- Avoid having any communication and have each computer perform the work separately
- Have some mechanism other than client-server communication for exchanging information
|  |
| 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 - The server starts running
- The server listens for clients wanting to connect
- Clients start running and perform various operations, some of which require connecting to the server to request a service
- When a client attempts to connect, the server accepts the connection if it is willing
- The server waits for messages to arrive from connected clients
- When a message from a client arrives, the server takes some action in response, such as sending a message back to the client, then resumes waiting
- Clients and servers continue functioning in this manner until one of them decides to shut down
|  |
| 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 - Waiting for interactions with the end-user, and responding when interactions occur
- Waiting for messages coming from the server, and responding when messages arrive
|  |
| 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 - Some languages place accented versions of characters at the end of an alphabet, whereas others consider that they should appear in the same place as unaccented characters in the sort order
|  |
| is a kind of locale-dependent feature |  |
| is a subtopic of 7.5 - Usability Principles |  |
| colour | has advantages - draws attention to specific items
- conveys organization (items coloured similarly are related)
- makes the UI more attractive
|  |
has problems - users cannot distinguish among large numbers of colours
- some colour combinations clash
- colour-blind people cannot see differences in hue
- some colours (e.g. bright red) can be distracting if overused
- colours may have unexpected emotional meanings to users (e.g. a sickly shade of green)
|  |
| 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:- The classes of the two objects are joined by an association
- The receiving object is stored in a local variable of the sending method (but the objects are not yet joined by an association)
- A reference to the receiving object has been received as a parameter of an earlier message to the sender
- The receiving object is global
- The objects communicate over a network
|  |
| 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- facilities for transmitting and receiving signals
- is a layer that deals with splitting messages into packets and reconstructing messages that are received
- a layer that deals with handling ongoing connections with a remote host
- a layer that handles various protocols used by application programs such as http
|  |
| 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) { //routineX will have to change whenever any of its callers adds a new command if (command.equals("drawCircle") { drawCircle(); } else { drawRectangle(); } } |  |
| 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 - having the callers of the routine directly call the methods called in the second routine
- the use of polymorphic operations
- using a look-up table that maps a command to a method that should be called when that command is issued
|  |
| 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- you will be more likely to account for all the subsystems and activities
- if you under-estimate the time required for some subsystems or activities, this should be at least partly compensated for by over-estimates in other places
|  |
| 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 - base your estimates purely on the personal judgement of experts within your team
- use algorithmic models that have been developed in the software industry as a whole
|  |
| 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:- different software developers with different skill levels
- different development processes and maturity levels
- different types of customers and users
- different schedule demands
- different technology
- different technical complexity of the requirements
- Different domains
- Different levels of requirement stability
|  |
| 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- As you gather requirements and begin specifying details, you will be able to increase the accuracy of your estimate
- As you move into the design phase, you can again increase the accuracy of your estimates
- You will adjust your estimates as requirements change, or features are dropped in order to meet a budget or deadline
- As you encounter problems during design and implementation, you will be able to adjust your estimates to take these into account
|  |
| 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 - You should almost never require a specific format for these items since they differ so widely and can change at any time
- Allow free-form input of whatever the user wants to type
|  |
| 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 - Vary the time consumption of different threads by giving them differing amounts of input, or running them on hardware that varies in speed
- Run a large number of threads concurrently
- Deliberately deny resources to one or more threads (e.g. temporarily cut a network connection, or make a file unreadable)
|  |
| 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 - Users may be using more than one currency at once
- The number of decimal places and the magnitude of values may differ dramatically
- The currency symbol itself may come before or after the numeric value
- The language somebody is using does not necessarily dictate the currency they are using; they may be visiting a foreign country or residing in one of several countries that use the same language
|  |
| 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 - not passing unnecessary arguments
- passing few arguments, each containing more abstract information
|  |
| 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 - accuracy of the data
- security of the data
- privacy of the information gathered about people
|  |
| 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 - There are many ways of writing dates. Even though the international standard is YYYY/MM/DD, this is often not followed
|  |
| 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 - thread A is waiting to access object O
- object O is locked by thread B
- thread B, however might be waiting to access object P
- object P is locked by thread A
Neither thread can ever progress unless some outside thread forces a break in the deadlock |  |
| 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 - Vary the time consumption of different threads by giving them differing amounts of input, or running them on hardware that varies in speed
- Run a large number of threads concurrently
- Deliberately deny resources to one or more threads (e.g. temporarily cut a network connection, or make a file unreadable)
|  |
| 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 - deny the program under test the resources it normally uses, by employing such methods as deleting files, concurrently running other resource-hungry programs, making less memory available, or disconnecting the system from the network
- run a very large number of copies of the program being tested, all at the same time
|  |
| 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 - a computer becomes short of resources such as memory, disk space or network bandwidth
- files or data are missing
- the system is not permitted to perform certain operations
- the system cannot start new threads
- the system runs out of space in a fixed size data structure
|  |
| 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 - running the system intensively
- suppling the system with a very large amount of input
- running many copies of the system
- running the system on a computer or network that is busy running other systems
- running the system in atypical environments
|  |
| 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 - Overusing generalization and inheriting the method that is to be reused
- Instead of creating a single method in the «Delegator» that does nothing other than call a method in the «Delegate», you might consider having many different methods in the «Delegator» call the delegate's method? It would be better to ensure that only one method in the «Delegator» calls the method in the «Delegate». If many methods access the method in the «Delegate», then when it changes, you may have to change every method that accesses it
- a method must only accesses neighbouring classes
|  |
| 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 - You want to minimize development cost and complexity by reusing methods
- You want to reduce the linkages between classes
- You want to ensure that work is done in the most appropriate class
|  |
| 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 - Create a method in the «Delegator» class that does only one thing: it calls a method in a neighbouring «Delegate» class, allowing reuse of the method for which the «Delegate» has responsibility
- By 'neighbouring', we mean the «Delegate» is connected to the «Delegator» by an association.
- Normally, in order to use delegation an association should already exist between the «Delegator» and the «Delegate».
- This association needs only to be unidirectional from «Delegator» to «Delegate».
- However it may sometimes be appropriate to create a new association just so you can use delegation - provided this does not increase the overall complexity of the system.
|  |
| 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 - several individuals initially make cost estimates in private
- they then share their estimates to discover the discrepancies
- each individual repeatedly adjusts his or her estimates until a consensus is reached
|  |
| 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 - Increasing profit by reducing cost and increasing revenue
- Ensuring that we actually conform with the requirements, thus solving the customers' problems
- Accelerating development, which helps reduce short-term costs, and may also ensure the software reaches the market soon enough to effectively compete
- Increasing qualities such as usability, efficiency, reliability, maintainability, and reusability which can help reduce costs and also increase revenues
|  |
| 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:- Knowledge of the requirements
- Knowledge of the design as created so far
- Knowledge of the technology available
- Knowledge of software design principles and 'best practices'
- Knowledge about what has worked well in the past
|  |
can be made by using these steps:- List and describe the alternatives for the design decision
- List the advantages and disadvantages of each alternative with respect to your objectives and priorities
- Determine whether any of the alternatives prevents you from meeting one or more of the objectives. If it does, you may have to rule it out. However, if none of the alternatives permits you to meet your objectives, you may have to adjust your objectives or else go back to earlier design decisions
- Choose the alternative that helps you to best meet your objectives. If several alternatives seems equally good in terms of the objectives, then use the priorities to decide among them
- Adjust your priorities for subsequent decision making. If you know you have already met your objectives for some aspects of quality, then you can increase the priority of the other qualities, for which you have not met your objectives
|  |
| 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 - to encourage designers to make good design decisions
- to communicate the design to others
|  |
has suggested structure - purpose
- general priorities
- outline of the design
- major design issues
- other details of the design
|  |
| 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 - Those who will be implementing the design, i.e. the programmers
- Those who will need, in the future, to modify the design
- Those who need to create systems or subsystems that interface with the system being designed
|  |
| 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 - can be hard for users to interact with or interpret
- not usable by blind people
- it can be expensive to program diagram drawing software
|  |
| 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 - Text in some languages runs left to right or top to bottom. Laying out screens so they can automatically accommodate this is a challenge
|  |
| 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 - Separate people can work on each part. The original development work can therefore be done in parallel
- An individual software engineer can specialize in his or her component and become expert at it
- Each individual component is smaller, and therefore easier to understand
- When one part needs to be replaced or changed, it can hopefully be done without having to replace or extensively change other parts
|  |
| 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 - Examine all the end-user documentation (in both paper and on-line forms), making sure it is correct
- Make sure it has correct solutions to problems that users might encounter, and correct instructions to help beginners learn how to use the software
- Work through the use cases, making sure that each of then is adequately explained to the user
|  |
| is a kind of defect |  |
| is
|