Main Page | Alex's SSI references | Forum | Lecture Handouts
I should point out that the opinions expressed here are my own and that I accept no liability for mistakes and/or omissions: caveat lector. A Standard disclaimer applies.
Back

Honours | Calendar | References (Normal) (Formal) (Quick) (Links only) (Light Toggle)

Total of 95 records found.
Current page is: file:///C:/My Documents/Education/University/public_html/comp462.html?HTML=true&
File is: comp462_lite.html

Sort by Category, type, title, short_title, author, pub_date, read_date, rank. View rank.


Book[UMLD] Title: Chapter 3 from UML Distilled: Applying the Standard Object Modeling Language
Author(s): Martin Fowler
Publication Date: (1997, 2000) - Publisher: Addison-Wesley.
Remote: http://www.awl.com/cseng/titles/0-201-32563-2/umldist-chap3.html
Found/Read: 2002/02/26
Comments: An introduction to use cases. Covers user goals and system interactions, use case diagrams, actors, uses(includes) and extends, and when to use Use Cases.


Book[SSUC] Title: Structure and Style in Use Cases for User Interface Design from Object-Modeling and User Interface Design
Author(s): Larry Constantine and Lucy Lockwood, van Harmelen (ed.)
Publication Date: (2001) - Publisher: Addison-Wesley.
Local: http://www.foruse.com/Files/Papers/structurestyle2.pdf
Remote: http://www.foruse.com
Found/Read: 2002/02/26
Comments: How Essential Uses cases were created to focus on modeling the intentions of users rather than how the user interacts with the system (as with Use Cases [UC]).
"Describes the common notations for the use cases and proposes a new, more complex but better structured notation. Emphasises UI design above everything else." - Alex
See Also [EUC]


Paper[DON 01] Title: What's the Use of a Use Case
Author(s): Don Mills
Publication Date: (2001) - Publisher: ACM OOPSLA 2001 Workshop on Behavioural Semantics.
Local: http://www.foruse.com/Files/Papers/structurestyle2.pdf
Remote: http://www.foruse.com
Comments: The paper describes numerous problems with use cases. This includes the inability to use them to model properly and unusability for testing of the solution. The main reason is underspecification.
"Multiple conflicting defintions and interpretations of "use case" have been published since the term first appeared in print. Between them, they served to obscure the very purpose of creating a set of use cases."
"Use Cases do not lend themselves to OO development due to their nature as procudural descriptions of functional decomposition." - [OOSC2]
"Use Cases are poor input for Object Modelling. They can lead to poor definiton of classes from noun extraction as you may therwise be hoping to eliminate some of the domain terms used within the object model"
"Physical sequence of operations is normally a process restriction, not a true requirement, and when truely required can be defined more abstractly by preconditions."


Book[BEC 89] Title: A Laboratory for Teaching Object-Oriented Thinking
Author(s): Kent Beck and Ward Cunningham
Publication Date: (1989) - Publisher: Proceedings of OOPSLA 1989.
Remote: http://c2.com/doc/oopsla89/paper.html
Found/Read: 2002/03/05
Comments: Introduction and reflections on CRC [CRC] cards for object-oriented design.
"The class name of an object creates a vocabulary fo discussing a design."
"Distribution [DIST] of system intelligence is encouraged by splitting large/cluttered objects into smaller objects that collaborate."
"We stress the importance of creating objects not to meet mythical future needs [DD], but only under the demands of the moment."
"We speculate that because the designs are so much more concrete, and the logical relationship between objects explicit, it is easier to understand, evaluate, and modify a design."
See Also [RESP].


Book[BRO 89] Title: Object-Oriented Design: A Responsibility-Driven Approach
Author(s): Wirfs-Brock, Rebecca and Wilkerson, Brian
Publication Date: (1989) - Publisher: Proceedings of OOPSLA 1989.
Remote: http://c2.com/doc/oopsla89/paper.html
Found/Read: 2002/03/05
Comments: How RDD is superior to DDD. Including better encapsulation.
RDD can increase encapsulation by deferring implementation issues until a later stage [DD].


Book[BRO 90] Title: Designing Object-Oriented Software - Quick Reference(Appendix A) & Another Desing(Chapter 10)
Author(s): Rebecca Wirfs-Brock, Brain Wilkerson, and Lauren Wiener
Publication Date: (1990) - Publisher: Prentice-Hall.
Remote: http://c2.com/doc/oopsla89/paper.html
Found/Read: 2002/03/05
Comments: The Parts of a process for designing object-oriented software, from classes to collaborations.


Book[HDD] Title: How Designs Differ, Report on Object Analysis and Design, Volume 1, Number 4
Author(s): Rebbecca Wirfs-Brock
Remote: http//www.wirfs-brock.com/articles.htm
Found/Read: 2002/03/05
Comments: Lecture Notes: exploring where and exactly how RDD and DDD designs diverged, and what decisions might have caused these signaificant differences.
Arguments on how RDD is better than DDD, Modelling the data then the processes leads to problems and how the responsibility-driven approach produces a more integrated combination of behavior and data. Includes brewery system comparison of two approaches.


Paper[CHI 91] Title: Towards a Metrics Suite for Object Oriented Design
Author(s): Shyam R. Chidamber, Chris F. Kemerer
Publication Date: (1991) - Publisher: Proceedings of OOPSLA 1991.
Found/Read: 2002/03/12
Comments: "Terrible and weird. Having a metric suite is useful but I doubt that this is enough. These six are too simplistic and the "math" in this paper is "kid's talk." Even though all of the above apply, this collection is useful." - Alex.

Metrics should have a solid theoretical base in measurement theory. This theory would aim to reflect the viewpoints of experienced OO software developers and evaluate the metrics themselves against software evaluation criteria.
See Also [MET].


Book[RIE 96a] Title: Extract (Preface) from Object-Oriented Design Heuristics
Author(s): Arthur Riel
Publication Date: (1996) - Publisher: Addison Wesley 1996..
Comments: Homemade guidelines for baking tasty object-oriented systems.
"The strength of a heuristics comes from the ramifications of violating it."
See Also [RIE 96b].


Book[RIE 96b] Title: Extract (Chapter 3) from Object-Oriented Design Heuristics
Author(s): Arthur Riel
Publication Date: (1996) - Publisher: Addison Wesley 1996.
Remote: http://www.cse.unsw.edu.au/~timm/pub/subjects/oois96/rules.html
Comments: Includes Heuristics to help detect:

"It is this decentralization of software that gives the object-oriented paradigm its ability to control essential complexity."
See Also [RIE 96a] [HEU]


Paper[CHE] Title: How to Conduct a Heuristic Evaluation
Author(s): Jacob Nielsen
Remote: http://www.useit.com
Comments: "Heuristic evaluation is about usability, not how users react to the interface. Performed by special evaluators, not users, based on a certain set of heuristics, not given in this paper." - Alex
See Also [EVAL].


Link[OOSC2] Title: Object Oriented Software Construction (2nd ed): The Use Case Principle
Author(s): Bertrand Meyer
Remote: http://www.elj.com/elj/v1/n2/bm/use-cases/


Paper[NOB 01] Title: Essential Use Cases and Responsibility in Object-Oriented Development
Author(s): James Noble, Robert Biddle, and Ewen Tempero
Publication Date: (2001) - Publisher: Victoria University of Wellington.
Local: http://www.mcs.vuw.ac.nz/comp/Research/object/Papers/euc-html
Remote: http://www.foruse.com/Files/Papers/euc-responsibility.pdf
Comments: A papers describing how "essential use cases can drive object-oriented development directly, without any intervening translation, allowing user interface development and object-oriented development to proceed in parallel."


Link[EOOD] Title: An Example of Object-Oriented Design: An ATM Simulation
Author(s): Russell C. Bjork
Remote: http://inprem.rug.ac.be/~gpremer/OOA/ATM_Example/default.html


Paper[DRC] Title: Designing Reuseable Classes
Author(s): Ralph E. Johnson, Brian Foote
Publication Date: (1988) - Publisher: University of Illinois.
Comments: Comments made by Robert: Starts with a general discussion of principles and then turns into a manual (a set of rules) of how to duo things. Quite a dated paper. Title does not line up with contents. The early discussioon of what turns out to be good ideas - object-oriented frameworks.


Book[JAC 92] Title: Object-Oriented Software Engineering: A Use Case Driven Approach
Author(s): Ivar Jacobson, Magnus Christerson, Patrik Jonsson and Gunnar Övergaard
Publication Date: (1992) - Publisher: Addison-Wesley, Wokingham (England).


Paper[HAM 97] Title: A Critique of Use Cases
Author(s): Luther Hampton, Robert C. Martin, Frank G. Pitt, Tim Ottinger
Publication Date: (9 July 1997)
Remote: http://ootips.org/use-cases-critique.html


Book[BRU 00] Title: Object-Oriented Software Engineering
Author(s): Bernd Bruegge and Allen H Dutiot
Publication Date: (2000) - Publisher: Prentice Hall.


Paper[USFAQ] Title: A Use Case FAQ(Frequently Asked Questions)
Author(s): Chandra Vemulapalli
Publisher: Advanced Software Technologies Group, WorldCom Inc..
Remote: http://www.unantes.univnantes.fr/usecase/Contributions/chandra.html


Paper[YOU 96] Title: Improving Object-Oriented Designs
Author(s): Warren Young
Publication Date: (October, 1996) - Publisher: Dr. Dobb's Journal.
Remote: http://www.ercb.com/ddj/1996/ddj.9610.html


Link[foldoc] Title: Free on-line dictionary of computing
Author(s): Denis Howe
Publication Date: (1993) - Publisher: Imperial College Department of Computing.
Remote: http://www.foldoc.org


Paper[FCP] Title: Frameworks = (Components + Patterns). How frameworks compare to other object-oriented reuse techniques.
Author(s): Ralph E. Johnson
Publication Date: (1997)
Comments: "Frameworks are an object-oriented reuse technique."


Paper[HOTSPT] Title: Systematic Framework Design By Generalization - How to deduce a hot spot implementation from is specification.
Author(s): Hans Albrecht Schmid
Publication Date: (1997) - Publisher: ACM.
Comments: "Identifying Hot Spots as a way to create frameworks." - Alex. An operational description of how its done.
A Hot Spot is a point of varibility in some software system - a point of rapid change.


Paper[DPAR] Title: Design Patterns: Abstraction and Reuse of Object-Oriented Design
Author(s): Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Found/Read: 2002/03/26
Comments: "The major contributions of this paper are: a definition of design patterns, a means to describe them, a system for their slassification, and most importantly, a catalog containing patterns we have discovered while building our own class libraries and patterns we have collected from the literature.""
"Design Patterns as a mechanism for expressing object-oriented design experience."


Book[DP-COMP] Title: Design Patterns - Elements of reusable OO software - Composite
Author(s): Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. (The "Gang of Four")
Publisher: Addison-Wesley.
Found/Read: 2002/03/26
Comments: "Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly."


Paper[DFP] Title: Documenting Frameworks using Patterns
Author(s): Ralph E. Johnson
Publication Date: (1992) - Publisher: OOPSLA.
Comments: "Patterns can describe the purpose of a framework, can let application programmers uase a framework without having to understand in detail how it works, and can teach many of the design details embodied in the framework."


Book[PAT] Title: A Pattern Language - Towns, Buildings, Construction
Author(s): Christopher Alexander
Publication Date: (1977)
Comments: Patterns can help make good design easier to identify and allow designers to take a more critical view of the world.


Paper[PAS] Title: Patterns as Signs
Author(s): James Noble and Robert Biddle
Publication Date: (2002) - Publisher: Victoria University of Wellington.
Comments: "Provides a semiotic of design patterns.


Paper[IPAL] Title: Idioms and Patterns as Architectural Literature
Author(s): James O. Coplien
Publication Date: (1997) - Publisher: Bell Laboratories / IEEE.
Found/Read: 2002/04/16
Comments: Argues that patterns are beyond everything, perhaps existing as meta-documentation (literature?).
"The human aspect of patterns displaces most software engineers from their comfort zones. Few software engineers are tooled in experimental psycology or sociometric science; to them, these areas are mysterious, nameless black holes of nonsense. These are disciplines of the right brain, of emotion, and of the soul. They defy the left brain's attempts at quantification: for most of us, such Qualities thrive unnamed [refer to the QWAN]. Bean counters can (and do) ascribe numbers to these properties: cyclomatic complexity and function points for: "this feels complicated," for example. But such numbers are only shadows of the gut feelings on the intuitions of accomplised architects, and most metric systems don't know how to measure "good guts." "


Paper[SP] Title: State Patterns
Author(s): Paul Dyson and Bruce Anderson
Found/Read: 2002/04/16
Comments: Seven patterns that extend and refine the State pattern by the GOF.


Paper[PDT] Title: Patterns for designing in teams
Author(s): Charles Weir
Publication Date: (June 1996) - Publisher: Object Designers Limited.
Found/Read: 2002/04/16
Comments: Software development is almost invariably a team process and these patterns help leverage the individual strengths of each development team member to geet better results than one single designer could achieve alone.


Paper[XPINT] Title: Extreme Programming: A gentle introduction
Author(s): Donovan J. Wells
Found/Read: 2002/04/23
Comments: Design process for coffee makers to be used by people who don't do overtime. Lots of prototyping and contact with the client required. Good ideas about not making the project more complex than it needs to be (avoids bloatware) and prototyping.


Paper[BBM] Title: Big Ball of Mud
Author(s): Brian Foote and Joseph Yoder
Publication Date: (2000) - Publisher: Addison-Wesley.
Remote: http://www.laputan.org/mud/mud.html
Found/Read: 2002/04/23
Comments: An outline of what actually happens in software engineering and patterns that can help designers deal with quagmires.


Paper[SUB] Title: Subclassing ? Subtyping ? Is-a
Author(s): Wilf LaLonde and John Pugh
Found/Read: 2002/04/30
Comments: "Subclassing (also called inheritance) is an implementation mechanism for sharping code and representation." E.g. of Professor subclassing Person. Java provides subclassing via the extends keyword.
"Subtyping is a substitutability relationship, i.e., an instance of a subtype can stand in for an instance of its supertype." Java provides subtyping via the implements keyword.
"Is-a is specialisation relationship, i.e., it descriges one kind of object as a special case of another. A dump truck is a special kind of truck that is a special kind of vehicle."


Book[GVSI] Title: Genericity versus Inheritance
Author(s): Bertrand Meyer
Found/Read: 2002/04/30
Comments: Examples of Genericity (like templates in C++) and Inheritance. Also demonstrates whats required for one to simulate the other.
Object-oriented software construction (2nd).
See Also [GEN] [INHER]


Paper[FMI] Title: Controversy: The Case For Multiple Inheritance in C++
Author(s): Jim Waldo
Publication Date: (1991)
Found/Read: 2002/04/30
Comments: The complexity monster rears it's ugly head. Includes arguments by T. A. Cargill againest.


Book[ST] Title: Extracts from Smalltalk (Chapters 3, 6, and 26)
Publisher: Prentice Hall.
Local: http://www.mcs.vuw.ac.nz/courses/COMP462/2002/handouts/lectures/l1-multi.ps
Found/Read: 2002/05/14
Comments: Includes syntax and the tangled mess that is the reflexive Metaclass hierarchy [MC]


term[MC] Title: Metaclass
Comments: See also [ST].


term[SMLT] Title: Smalltalk
Comments: From Lecture Notes - Alan Kay: ("The early History of Smalltalk", 1993)
- Everything is an object
-Objects communicate by sending and receiving messages (in terms of objects)
-Objects have thier own memory (in terms of objects)
----------------
- Every object is an instance of a class (which must be an object)
- The class holds the shared behaviour for its instance (in the form of objects in a program list)
- To evaluate a program list, control is passed to the first object and the remainder is treated as its message.


Paper[GSAJ] Title: Getting Started with AspectJ
Author(s): Gregor Kicales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm and William G. Griswold.
Publication Date: (2001) - Publisher: CACM.
Found/Read: 2002/05/14
Comments: Addresses how to adopt AOP as part of a development process. Is AOP symbiotic(A close, prolonged association between two or more different organisms of different species that may, but does not necessarily, benefit each member.) or parasitic(An organism that grows, feeds, and is sheltered on or in a different organism while contributing nothing to the survival of its host.) to the language which its attached?


Paper[OAJ] Title: An Overview of AspectJ
Author(s): Gregor Kicales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm and William G. Griswold
Publication Date: (2001) - Publisher: ECOOP.
Found/Read: 2002/05/14
Comments: Details of how AspectJ provides support for modular implementation of a range of crosscutting concersn


Paper[SOP] Title: Subject-Oriented Programming (A Critique of Pure Objects)
Author(s): William Harrison and Harold Ossher
Publication Date: (1993) - Publisher: OOPSLA.
ISBN: 0-89791-587-9/93/0009/0411
Found/Read: 2002/05/14
Comments: A technique where the authors believe that subjects will become higher order building blocks over classes and objects.


Book[PCLA] Title: Prototyping-Based Programming. Concepts, Languages and Applications
Author(s): James Noble, Antero Taivalsaari, Ivan Moore
Comments: Chapters 1, 3, 5.


Paper[CVSP] Title: Classes vs. Prototypes. Some Philosophical and Historical Observations
Author(s): Antero Taivalsaari
Publication Date: (1997) - Publisher: Journal of OOP.
Found/Read: 2002/05/21
Comments: [Chapter 1 of PCLA]


Paper[STP] Title: The Stripetalk Papers - Understandability as a Language Design Issue in Object-Oriented Programming Systems
Author(s): Thomas R.G. Green, Alan Borning, Tim O'Shea, Moina Minoughan, and Randall B. Smith
Publication Date: (1989) - Publisher: ECOOP.
Found/Read: 2002/05/21
Comments: [Chapter 3 of PCLA]
"Language features that influence the learnability and undestandability of Smalltalk (...) have motivated us to explore alternative language designs. We present a language space whose dimendiond correspond to the ways of dealing with these identified learnability-influencing features."


Paper[PAE] Title: Programming as an Experience: The Inspiration for Self
Author(s): Randall B. Smith and David Urgar
Publication Date: (1995) - Publisher: ECOOP.
Found/Read: 2002/05/21
Comments: [Chapter 5 of PCLA]
"The Self system attempts to integrate intellectual and non-intellectual aspects of programming to create an overall experience."


Paper[POISB] Title: Using Prototypical Objects to Implement Shared Behavior in Object Oriented Systems
Author(s): Henry Lieberman
Publication Date: (1986) - Publisher: OOPSLA.
Found/Read: 2002/05/21
Comments: Details of how delegation is more flexible than inheritance for combining behavior from multiple sources


term[OOS] Title: Object-oriented System
Local: http://www.mcs.vuw.ac.nz/courses/COMP462/2002/handouts/lectures/l1-multi.ps
Comments: What are the 5 most important distingusing characteristics of an object-oriented system:

  1. All thess giving to reuse and modularity:


term[UC] Title: (Concrete) Use case
Comments: Requirements elicitation.
An abstraction over a concrete set of scenarios [SCEN] that describe the (externally) functionality of the system. They help capture functionality required by the (future) users of the system and provide a reasonable way to reach an agreement with the client about what should be developed. They can however be ambiguous, with differing defintions. They may result in design drift to early stages of requirements elicitation.
Lecture Notes: "A use case describes a single interaction between a user and a system." It should be one complete case of system use from the actors point of view (system is a black box).
[UMLD] - "In essence, a use case is a (single) typical interaction between a user and a computer system." "Use cases are all about externally-required functionality."
[OOSC2] - "a complete course of events initiated by a (user of the future system) and (of) the interaction between (the user) and the system. "
[SSUC] (Jacobson's original definition) - "A use case is a specific way of using the system by using some part of functionality. (A use case) constitutes a complete course of interaction that takes place between an actor and the system."
[SSUC] (Developers of UML) - "The specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can perform by interacting with outside actors.
[SSUC] (M Fowler) - "A use case is a typical interaction between a user and a computer system … (that) captures some user-visible function … (and) achieves a discrete goal for the user ".
[USFAQ] (From Jacobson) - "a good use case as one, which performs some action in the system, that is of a measurable value for a particular actor".
[DON 01] (UML) "… this is to specify and define a sequence of interactions between a system (or a component of a system) and one or more of its users."
They can help define the scope of the system.
Using Natural Language analysis as a way to elicit class may produce may more nouns than relevant classes and the designers must be able to remove unnecessary domain terms from objects, attributes, and associations.
See also [EUC].
In [OOSC2](pg. 739), Bertrand Meyer is of the opinion that: "Except with a very experienced design team (having built successful systems of several thousand classes each in a pure O-O language), do not rely on use cases as a tool for object oriented analysis and design." His reasons for this opinion are based around arguments that inexperienced designers can introduce undesirable characteristics to a design when using use cases, or worse still, emulate functional programming concepts under the guise of OO design.
- Use cases emphasise ordering/sequencing and assume a sequential flow of control.
- Use cases favour a functional approach, based on processes (actions).
- Uses cases depict how the users envisage the system.
[UMLD] - "The uses (includes) relationship occurs when you have a chunk of behaviour that is similar across more than one use case and you don't want to keep copying the description of that behaviour."
[UMLD] - "Use extends when you are describing a variation on normal behaviour (exceptions)."
See Also [DON 01], [HAM 97].


term[EUC] Title: Essential Use case
Comments: Requirements elicitation.
[NOB 01] "Essential use cases are abstract, lightweight, technology-free dialogues of user intention and system responsibility, that effectively capture requirements for user interface design."
[SSUC] "… abstract, generalised, and technology-free descriptions of the essence of a problem."
[SSUC] "… a single, discrete, complete, meaningful, and well-defined task of interest to an external user in some specific role or roles in relationship to a system, comprising the user intentions and system responsibilities in the course of accomplishing that task, described in abstract, technology free, implementation-independent terms using the language of the application domain and of external users in role."
[SSUC] "… they model tasks in a form closest to the essential nature of a problem and do not intermingle design solutions with problem description."
Advantages over conventional (concrete [UC]) use cases ([SSUC] and lecture notes):


term[MET] Title: Metrics
Comments: Evaluation [EVAL].
[foldoc] "A measure of software quality which indicates the complexity, understandability, testability, description and intricacy of code."

Potential Uses (lecture notes):

From [CHI 91] and lecture notes:

Exam question (2000): Q5b) "Give one example of an object-oriented design heuristic."
Q5 c) "Describe a design situation where using metrics would be better than using heuristics."
See also [CHI 91]


term[HEU] Title: Heuristics
Local: misc/rules.html
Comments: Evaluation [EVAL].
[www.dictionary.com] "Relating to or using a problem-solving technique in which the most appropriate solution of several found by alternative methods is selected at successive stages of a program for use in the next step of the program."
[RIE 96a] "guidelines to help developers make proper decisions." "rules of thumb."
[YOU 96] "A heuristic is similar to a rule ("A class should capture one, and only one, key abstraction."), but isn't intended to be inviolate. Instead, it acts as a guideline that generally indicates the correct way to design something."
Heuristics "are not hard and fast rules that must be followed under penalty of heresy."

Exam question (2001): "Compare using heuristics with metrics [MET] as ways of evaluating an object-oriented design. Use at least one example of a heurustic from Riel [RIE 96a], and at least one example of a metric from Chidamber and Kemerer's paper [CHI 91]."
[RIE 96a] "The guru runs through a subconscious list of heuristics, built up through his or her design experience, over the design." The design will have the "it feels right" property if the heuristics pass.
Exam question (2000): Q5a) "Give one example of an object-oriented design heuristic."


term[EVAL] Title: Evaluations
Comments: Summative Evaluation: Summary information provided after completion.
Formative Evaluation: Helpful information provided to assist with further improvement. See Also [MET] [HEU] [CHE] [RIE 96a] [RIE 96b]


term[DPAT] Title: Design Patterns
Comments: From lecture notes: "A pattern describes a problem to be solved, a solution, and the context in which that solution works. It names a technique and describes its costs and benfits." A recurring solution that has stood the test of time.
There all about capturing good ideas in design. Reusable artifacts that could be: procedures, functions, classes, libraries, algorithms/control structures, data strucutres.
Being micro architectures they can be finer grained than frameworks.
They provide a commmon language with which to discuss a design concept.
[DPAR] - "In contrast to frameworks, design patterns allow only the resue of abstract micro-architectures without a concrete implementation." [DPAR] - "Patterns try to abstract design rather than programming techniques."
Patterns are only really useful once learned. In contrast, many users of frameworks want to know as little about the internal workings (blackbox).
"They capture an important structure, a central idea, a key technique long known to expert practitioners. ... What ties this body of literature together is that all patterns solve problems." - [IPAL]
Exam Question (2001): Q4a) "Explain why the Design Patterns do not form a pattern language [PAT]. Describe what would be required to turn them into a pattern language."
Q4b) "Imagining the Design Patterns could be turned into a pattern language, do you think this would be a good thing? why or why not?"
Exam Question (2000): "Design Patterns are often described as a solution to a problem in a context. Explain what this means, paying particular attention to the emphasised words."


term[FW] Title: Frameworks
Comments: Structure based: "a framework is a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact."
Purpose based: "a framework is a skeleton of an application that can be customized by an application developer."
Unlike patterns, they are more than just ideas and can contain code. [DPAR] - "A framework is a codified architecture for a problem domain that can be apapted to solve specific problems."
[DFP] - "A framework is a reusable design of a program or a part of a program expressed as a set of classes."
Exam Question (2001): Q3a) "Explain the difference between a class library and an objert-oriented framework."
Q3B) "Describe Hans Albrecht Schmid's approach [HOTSPT] to the development of object-oriented frameworks. Suggest a role for one of the Gang of Four (...) patterns [DFP] that supports this approach."


term[PBOOP] Title: Prototype-Based Object-Oriented Programming
Comments: Exam Question (2000): Q10) "Explain, with examples, what a "prototype"-based language (such as Self) is, and how it differs from a class-based language."


term[CRC] Title: CRC (Class, responsibility, and collaboration) card
Remote: http://c2.com/doc/pages.html
Comments: System Design.
A card which records the class name, Responsibilities [RESP] to be fulfilled by the class, and Collaborators (Helper Objects to the class). Collaborators [COLL] are objects which will send or be sent messages in the course of satisfying responsibilities.
The design is guided by an overall set of responsibilities the system must satisfy.
CRC cards use responsibilties associatied with objects to represent the problems to be solved.
[BEC 89] "… characterise objects by class name, responsibilities, and collaborators, …"
[BRO 90] "… used to capture information about the classes and subsystems in a design."
[BEC 89] "CRC cards place the designer's focus on the motivation for collaboration by representing (potentially) many messages as a phrase in English text"
Advantages:

Exam Question (2000): Q4a) "Sketch one example of a CRC Card, labelling your sketch to describe each part of your card."
Q4b) "Describe one main advantage of CRC Cards."


term[MI] Title: Multiple Inheritance
Comments: [RIE 96a] (From List of Heuristics) "6.1: If you have an example of multiple inheritance in your design, assume you have made a mistake and prove otherwise."
"Exam question (2000): Q6) "Java does not have mulitple inheritance, but it does have the interface mechanism. Explain how thismechanism can be used to provide one of the benefits of multiple inheritance.."


term[AOP] Title: Aspect-Oriented Programming
Comments: Join Point - Well defined points of interest/execution in the program.
Point Cut - A set/collection of join points that need to be true for an advice to occur
Advice - special method-like constructs that can be attached to pointcuts


term[RDD] Title: Responsibility-Driven Design
Remote: http://www.wirfs-brock.com/
Comments: System design.
RDD uses responsibilities to represent the knowledge an object maintains or actions it can perform.
Structure of objects is ignored as designers focus on the contractual responsibilties of each object. Changes in the system become easier without the structure to consider. The strucutre does not become part of the definition (and then part of the interface) - degraded encapsulation.
Lifting out abstractions is easier with RDD (compared to DDD [DDD]) due to the greater encapsulation and lack of implementation stage structure.
[BRO 89] "Responsibility-driven design is inspired by the client/server model [CSM]. It focuses on the contract by asking: * What actions is this object responsible for? And * What information does this object share?" "Information shared may or may not be part of the object. First focus on fully specifying the desired behaviour and associated sets of responsibilities for each object. We focus on structure during implementation."
[BRO 89] "Responsibilty-driven designs maximise encapsulation when the desinger intentionally ignores" the structural details of an object.
[BRO 89] "Responsiblity-driven design specifies object behaviour before object structure and other implementation considerations are determined."
[BRO 89] "Designing classes without a knowledge of their structure encourages the design of the inheritance hierarchy to follow a type hierarchy, because only the types of the classes are known. Advantages:
* improves encapsulation with respect to sub-class clients, ensuring that all inherited behaviour is part of the cintract of the class.
* makes abstract classes easier to identify."
Inheritance hierarchy is encouraged to follow a type hierachy as only types are known.
See Also [CSM] [RESP].


term[RESP] Title: Responsibility
Comments: [BEC 89] (On CRC cards)"Responsibilities identify problems to be solved." "Serves as a handle for discussing potential solutions." Often short phrases with an action verb (things to do)
Exam question (2001): "Explain what is meant by a "responsibility" in Responsibility-Driven Design, and outline the case for how it leads to a good design."
See also [CRC] [RDD]


term[CSM] Title: Client-server model
Comments: Client: makes request of the server to perform services.
Server: provides a set of services upon request.
Contract: a list of requests that can be made of the server by the client.
The client-server model focuses on WHAT the server does for the client, rather than HOW the server does it.
See Also [RDD].


term[XP] Title: Extreme Programming
Comments: Exam Question (2001): Q6) "Doing Extreme Programming using a prototype-based [PBOOP] reflexive language will result in a Big Ball of Mud [BBMUD]."
Exam Question (2000): Q9) "The 12 practices of XP are: Planning Game, Frequent Releases, System Metaphor, Simple Design, Testing, Refactor Mercilessly, Pair Programming, Collective Code Ownership, Continuous Integration, Forty Hour Week, Onsite Customer, Coding Standards.
Choose two XP Practices. For each practice:
(a). Briefly describe what it involves - what people do.
(b). Explain how it contributes to the goals of XP."


term[BBMUD] Title: Big Ball of Mud
Comments: The Big Bang method of development may lead to big balls of mud...


term[AOD] Title: Action-oriented design
Comments: "AOD focuses largely on a centralized control mechanism controlling a functionally decomposed set of tasks, while object-oriented development focuses on a decentralized collection of cooperating entities." - [RIE 96a]
"While action-oriented software developement is involved with the funcitonal decomposition through a very centralized control mechanism, the object-oriented paradigm focuses more on the decomposition of data with its cossesponding functionality in a very decentralized setting."-[RIE 96b]


term[DDD] Title: Data driven design
Comments: Here the design begins with existing records/files (e.g. Bank account records). The software structure follows/reflects the structure of thae data. Control becomes secondary.
[BRO 89] - DDD "is the result of adapting abstract data type design methods to object-oriented programming. The adaptation is straightforward because classes closely resemble abstract data types."
"An abstract data type is the encapsulation of data and the algorithms that operate on that data."
"The primary focus is on the strucuture of the data being represented in the system."
Strength: "it is a familiar process for programmers experienced with traditional procedural languages."
Weakness: "it inerently violates the encapsulation by making the structure oa an obkect part of the definition of the object. This in turn leads to the definition of operations that reflect that structure ... This is the antithesis of encapsulation."
It's common to find a centralized control architecture with DDD.


term[ABS] Title: Abstraction
Comments: [foldoc] "Generalisation; ignoring or hiding details to capture some kind of commonality between different instances."
[DRC] "Data abstraction encourages modular systems that are easy to understand."
[SSUC] "We have long argued that abstraction encourages creavtive innovation,..."
[BRO 89] "The most effective tool available for dealing with complexity is abstraction. Many types of abstraction can be used, but encapsulation [ENCAP] is the main form of abstraction by which complexity is managed in object-oriented programming."
[RIE 96a] "The more complex systems require a greater level of abstraction, which the object-oriented paradigm provides. This is no revolution is software development; it is simply an evolution."


term[ENCAP] Title: Encapsulation
Comments: [foldoc] "The ability to provide users with a well-defined interface to a set of functions in a way which hides their internal workings. In object-oriented programming, the technique of keeping together data structures and the methods (procedures) which act on them."
[BRO 90] "The ability to provide users with a well-defined interface to a set of functions in a way which hides their internal workings."
[BRO 90] "Encapsulation supports system modification, reusabilty, traceability, error detection."
[BRO 90] "OO programming languages support encapsulation, thereby improving the ability of software to be reused, refined, tested, maintained, and extended."
[BRO 89] "Encapsulation is compromised when the structural details of an object become part of the interface on the object." [DDD]
The maximum benefit/leverage of encapsulation comes from the design phase.


term[INHER] Title: Inheritance
Comments: [foldoc] "Methods or code in one class can be passed down the hierarchy to a subclass or inherited from a superclass."
Does code inheritance violate encapsulaiton? [BRO 89] "In most object-oriented languages, subclasses inherit not only the behavior but also the structure defined by thier superclass. This is unfortunate, as it tends to encourage programmers to violate encapsulation in order to increase the amount of code reused."


term[POLY] Title: Polymorphism
Comments: [foldoc] "In object-oriented programming, the term is used to describe variables which may refer at run time to objects of different classes."
[DRC] "Polymorphism makes it easier for a given component to work correctly in a wide range of new contexts."

[BRO 89] - "Polymorphism increases encapsulation, because the client of an object does not need to know noy only how the object implements the service being requested, but neither which class (type) is responding to the request. The responsibilty-driven approach can help a designer identify standard protocols (message names) by encouraging the designer to focus on the responsibilites independently of implentation. This facilitates polymorphism."
See Also [comp432 POLY]


term[GEN] Title: Generics
Comments: See Also [POLY]


term[MOD] Title: Modularity
Comments: [www.dictionary.com] "Designed with standardised units or dimensions, as for easy assembly and repair or flexible arrangement and use: modular furniture; modular homes."
The program/design is divided into components, each component is complete in itself and with its own function.


term[REUSE] Title: Reusability
Comments: [foldoc] "Using code developed for one application program in another application. Traditionally achieved using program libraries. Object-oriented programming offers reusability of code via its techniques of inheritance and genericity."


term[DIST] Title: Distribution
Comments: Distribution of system intelligence intellagence is desirable in OO systems.


term[UML] Title: Unified modelling language (UML)
Author(s): Grady Booch, Ivar Jacobson, James Rumbaugh (the "three amigos")
Remote: http://www.rational.com/uml/index.jtmpl
Comments: A graphical notation for the visualisation of designs.
Use case [UC] diagrams can help facilitate conversation of what the system is surposed to do (including identifying use cases outside the system).


term[SCEN] Title: Scenario
Comments: Requirements elicitation.
The primary artifacts before abstraction.
[SSUC] "Scenarios are typically extended narratives forming a plausible vignette or story-line. They tend to be rich, realistic, concrete, and specific, often replete with gratuitous detail for enhanced verisimilitude."
[BRU 00] "Instance of a use case. A scenario represents a concrete sequence of interactions between one or more actors and the system."


term[UCGOL] Title: Use case goal (user goal)
Comments: [SSUC] "A goal is the desired end state of the system, and as such it is correctly described in static terms as the state and features of objects." "the destination"
[SSUC] "Goals, being static, place the focus on objects or nouns,…"
[UMLD] - User goals are "real goals the user is trying to achieve" and help find "alternative ways to satisfy the goals". They are generally more abstract than system interactions, that are "better for planning purposes".


term[UCINT] Title: Use case intention (system interaction)
Comments: [SSUC] "An intention is dynamic and represents direction or progress rather than an end state." "represent the journey - the interaction"
[SSUC] "…intentions, being dynamic, bring the actions and verbs to the foreground, …"


term[ENTITY] Title: Entity objects
Comments: [BRU 00] - "Represent the persistent information in the system."


term[CONTRL] Title: Control objects
Comments: [BRU 00] - "Represent the user tasks the system supports."


term[BOUND] Title: Boundary objects
Comments: [BRU 00] - "represent system/actor interactions."


term[ACTOR] Title: Actor
Comments: [BRU 00] "External entity that needs to exchange information with the system. An actor can represent either a user role or another system."
[UMLD] "An actor is a role that a user plays with respect to the system."
Lecture notes: "System actors represent other systems (legacy or future) with which the system we are designing must interact.
An actor is a category or kind of user that interacts with the system."


term[COLL] Title: Collaborators
Comments: [BEC 89] objects that "will send or be sent messages in the course of satisfying responsibilities." Helper objects.
See also [CRC]


term[COUP] Title: Coupling
Comments: [CHI 91] "The degree to which an object acts upon the other."
Minimal amount of coupling between objects is desirable. Promotes encapsulation.


term[COHES] Title: Cohesion
Comments: [CHI 91] "The degree of similarity of methods relates both to the conventional notion of cohesion in software engineering, (i.e., keeping related things together) as well as encapsulation of objects, that is, the bundling of methods and instance variables in an object. Cohesion of methods can be defined to be the degree of similarity of methods. The higher the degree of similarity of methods, the greater the cohesiveness of the methods and the higher the degree of encapsulation of the object."
Strong cohesion within an object is desirable. Promotes encapsulation. Lower cohesion increases complexity.


term[OOD] Title: Object-Oriented Design/Paradigm (OOD)
Comments: [CHI 91] "Booch (1986) defines object oriented design to be the process of identifying objects and their attributes, identifying operations suffered by and required of each object and establishing interfaces between objects."
[RIE 96a] "object-oriented development focuses on a decentralised collection of co-operating entities."
[RIE 96b] "It is this decentralisation of software that gives the object-oriented paradigm its ability to control essential complexity."


term[CLASS] Title: Class
Comments: [RIE 96b] "the bi-directional relationship between data and behaviour, namely, a class, in object-oriented terminology."
[foldoc] "A set of objects which share a common structure and behaviour."
From Lecture notes: A class is a set of objects with the same interface and behaviour. Classes allow modeling of simple classification in the real world, and simplify design.
A class is a specialisation of its superclass (which is a generalisation of a set of classes). The class inherits the interface of it's superclass as well as any implementation (which may be overriden).


term[FOREN] Title: Forward engineering
Comments: [CHI 91] - "… the traditional process of moving from high-levels abstractions and logical, implementation-independent designs to the physical implementation of a system."


term[REVEN] Title: Reverse engineering
Comments: [CHI 91] - "… to gain a sufficient design-level understanding to aid maintenance, strengthen enhancement, or support replacement."
- "Reverse engineering is the process of analysing a subject system to identify the system's components and their interrelationships and create representations of the system in another form or at a higher level of abstraction."
[STO 97] - "the process of analysing an existing system to identify its components and their interrelationships, and to create representations of the system in another form or at a higher level of abstraction."


term[REENG] Title: Reengineering
Comments: [CHI 91] - "Reengineering, also known as both renovation and reclamation, is the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form. It generally includes some form of reverse engineering (to achieve a more abstract definition) followed by some form of forward engineering or restructuring. This may include modifications with respect to new requirements not met by the original system."


term[METAM] Title: Metamodel
Remote: http://c2.com/cgi/wiki?MetaModel
Comments: "A MetaModel is a model that describes a model -- the class variables of a particular kind of model or a way of discovering a model." - RaySchneider


term[OBJT] Title: Object
Comments: Objects have/are:
implementation
- memory and behaviour (the inside view of an object)
interface - how to communicate with it via messages that may carry information in the form of other objects.
encapsulation [ENCAP] - the internal implementation is invisible and inaccessible from the outside.
identity - Every object can be distinguished from other objects
association - objects work together to accomplish taks, by sending messages to each other (distribution of system intelligence [DIST]).


term[AGGR] Title: Aggregation
Comments: From Lecture notes: An object is used as "part of" another object.


term[COMP] Title: Composition
Comments: From Lecture notes: An object is used only as a "part of" another object.


term[DD] Title: Design Drift
Author(s): Daniel Ballinger
Comments: The process where by elements of the next stage of design are practiced (brought forward) in to the current stage of design. Hence putting unnecessary restrictions on future work. This can also involve guessing at mythical future needs, rather than focusing on the demands of the moment (Premature complexity [BEC 89])
Are programming and design really seperate concerns or should the be carried out together?.


^Top^

Honours | Calendar | References (Normal) (Formal) (Quick) (Links only) (Light Toggle)