[Skip Navigation] [CSUSB] / [CNS] / [CSE] / [R J Botting] / [Samples] / methods
[Index] [Contents] [Source Text] [About] [Notation] [Copyright] [Comment/Contact] [Search ]
Tue Dec 11 14:50:40 PST 2012

Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).

Opening Microsoft files (winzip, word, excel, powerpoint) on this page may require you to download a special viewer. Or you can download and save the files and use your preferred office applications to view and edit them.


    A Glossary of Software Development methods processes and techniques


     There are some attempts at humor here.
    [ HHOS ]

    See also


  1. ADO::=Abstract data Object.
  2. ADV::=Abstract Data View. ADV/ADO::=An architecture for object oriented software that separates physical and logical structures, and connects objects in a more reusable way.

  3. ADT::="Abstract Data Type", Precursor to object-oriented thinking where data is encapsulated in modules and is accessible only by operations/functions/methods, but without any form of derivation/inheritance or polymorphism.

  4. ASM::="Abstract State Machines", (formerly Evolving Algebras) [ http://www.eecs.umich.edu/gasm/ ]

  5. ASD::="Adaptive Software Development", -- a nonmethod! More of a process and management concept than any specific steps for doing software well.

      Jim Highsmith developed this way of developing software for when the risks are high and the situation likely to change. He argues that managers should not prescribe particular methods or processes but only set objectives. The teams must do whatever is needed to meet managerial goals. He argues for an incremental or evolutionary approach so that as the developing software keeps pace with the changing requirements. He thinks that there is no way to guarantee success in highly risky and unstable projects but argues that a flexible and iterative and well motivated team gives the best chance. He believes in internal discipline, understanding and skill rather than forms, documentation, and preprogrammed process.

      ASD is an Agile process.

  6. Agile::="Allowing developers to do the right thing at the time".
      A group of methodologists who don't like rigid methods have formed an alliance promoting methods that let people adapt quickly to new circumstances. These methods are good when circumstances are changing or undefined. See ASD above and XP below. AGILE

      However XP is one of the most rigid processes... but with the absolute minimum of documentation...

      Here are some links from Scott W. Ambler via Software Development's Agile Modeling pages
      (Agile alliance home): page [ http://click.softwaredevelopment.email-publisher.com/maaafZQaaReXKa9GYH3b/ ] , mailing list [ http://click.softwaredevelopment.email-publisher.com/maaafZQaaReXLa9GYH3b/ ]

      (UML and Agile Modeling): [ http://click.softwaredevelopment.email-publisher.com/maaafZQaaReXMa9GYH3b/ ]
      (Kirk Knoernschild): [ http://click.softwaredevelopment.email-publisher.com/maaafZQaaReXQa9GYH3b/ ]
      (OPEN): [ http://click.softwaredevelopment.email-publisher.com/maaafZQaaReXRa9GYH3b/ ]
      (Software Productivity Research): [ http://click.softwaredevelopment.email-publisher.com/maaafZQaaReXSa9GYH3b/ ]

  7. aspect::="A cross cutting concern that impacts many different parts of a program".
  8. AOP::="Aspect Oriented Programming", An Aspect is some desirable property of a piece of software that can only be be implemented by code is many different places in the software. Aspect oriented tools allow these cross-cutting concerns to be written once and automatically propagated to all the places where they might be needed. aspect

  9. B::=a method developed by Jean-Raymond Abrial. Compare the Z specification language.
  10. Booch::=a method and a methodologist, See UML

  11. BON::=Business Object Notation. [ bon.html ] at [ http://www.eiffel.com/ ] (Interactive Software Engineering</A>)

  12. bottom_up::=attempting to create something by assembling components so that when connected together they satisfy the clients needs, also known as flying a kite. [ top_down ]

  13. catalysis::method=http://www.catalysis.org/.

  14. CLEANROOM::method=a rigorous quality controlled and structured method of software development and management distinguished by the idea that code must be shown to work before it is tested and code is then tested against a simulated sample of typical uses.

  15. Coad_method::=An object oriented method developed by Peter Coad of Object International, Now chief strategist at Borland. [ index.htm ]

  16. collaboration::=co_labor_ation: pertaining to working together.
  17. collaboration::=A relationship between two classes when an object in one class needs to make use of some member of an object of the other class in some way or other.
  18. collaborator::=something that takes part in a collaboration
  19. CRC::card=Class>->Responsibilities><Collaborators. A simple, manual way to record and develop an object oriented class structure that fits a set of use-cases or scenarios. A CRC card is a 3><5 index card labelled by the name of a Class. They are worked with using a table with actors playing the part of objects in a skit based on a scenario.
  20. Class::=a collection of responsibilities implemented by objects.
  21. Responsibillities::= N(responsibility).
  22. Collaborators::Responsibillities -> #Class.

    See Also [ wiki?CrcCard ] [ CRC_cards ] [ 5123 ]

  23. contracts::=plural of contract.
  24. contract::=a clear specification of what a piece of software is responsible for and what it assumes about the rest of the software. See design_by_contract.

  25. Counterpane::= See http://www.counterpane.com/labs.html

  26. data_structure::= A small transient data base.
  27. data_base::= A large persistent data structure.

  28. death_march::="Any project that has less than 50% of the time or resources rationally needed to complete."

  29. discrete_mathematics::=Computers and information systems are handling discrete objects and discrete mathematics studies their behavior. Discrete mathematics is essentially one step more complex than symbolic/formal logic. It is a weak technique that can be incorporated into any method or process. There are three problems: it's almost trivial mathematics so it is not taught well, it does take training to use, and the common notations do not fit with common computer technology. It has the advantage of abbreviating complex sentences into shorter forms with well-defined operations. See Z MATHS

  30. design::= look_and_feel | internal_structure. The word design is ambiguous and causes many useless discussions where the discussants have adopted different definitions.
      Because the interface with the outside world needs to be tuned to fit users and circumstances independently of changes in the internal logic of a piece of software it is worth separating these two concerns. This is the most obvious form of Parnas's information_hiding.
      (The ACM Classic of the month): [ http://www.acm.org/classics/may96/ ]

      Also see MVC and the UML Boundary+control+entity stereotypes and Ambler's Class type architecture

      Internal design is about splitting up software into structured subprograms(SP), functions(functional) or objects(object_oriented), or responsibilities(RDD) with or without contracts.

  31. design_by_contract::=following

      Design By Contract

    1. A direct application of information_hiding combined with techniques developed for assuring the correctness of algorithms. A contract specifies a set of rules for two parts of a program to work together. It states that if one part behaves in the correct manner then the other part will guarantee to also work in a specific (correct) manner. Implicitly, this means that one part doesn't have to worry about actions that don't fit the contract, or about how the contractual obligations are met. Both parts become simpler as a result. The technique has been embedded in the Eiffel OOPL and marketed by Bertrand Meyer. [ http://archive.eiffel.com/doc/manuals/technology/contract/ ]

    (End of Net)

  32. domain::buzz-phrase,
      Two meanings: (1) Looking for common reusable components and frameworks across several projects. (2) focusing on the properties of the software's environment. domain_model.
      (Product-Line Architecture Research Group): [ #tr-95-06 ]

      Also see ontologies.

  33. domain_model::="A model of the world outside the computer as seen by the stakeholders". Many methods (JSD, NORMALIZATION, SSADM, RUP, ... ) include the construction of a domain model of some sort or other.

    (DRY): principle [ wiki?DryPrinciple ]

    (DSDM: Dynamic Systems Development Method): methods [ http://www.dsdm.org/ ]


  34. ELECTRE::= Reactive language or method, RFP.

  35. Enterprise Modeling::= RFP.

  36. ESTEREL::= Reactive language or method, RFP.

  37. Equational_Logic::logic="Teaching Logic as a Tool", [ logicthetool.html ] by David Gries [ gries.html ]

  38. extreme::buzz_phrase="identifies a method, process, or sport as a late 1990's thing".

  39. Extreme_Programming::process=XP.

    (FAQ Comp.software-eng Archive): methods [ http://www.qucis.queensu.ca/FAQs/SE/ ]

  40. Fit::acronym="Framework for Integration Tests",
  41. Fit::= See http://fit.c2.com.
  42. FitLibrary::= See http://sourceforge.net/projects/fitlibrary/.
  43. FitNesse::= See http://www.fitness.org/. Also see [MartinMelnick08] [Mugridge08] Book: [MugridgeCunningham05]
  44. Possible syntax
    1. Fit_scenario::= #table.
    2. table:=user_input | rejection | simple_output | output_data | precondtion | postcondition | ....
    3. user_input:= O(time) "user:" datum #( tag ":" datum).
    4. output_data:=table.
    5. table:=table_heading #( column_heading) # row.
    6. row:=#(tag item).
    7. item:=datum | table.

    (End of Net)

  45. Formal_methods::= "Using math and logic in software development" | Fragile_process.
      Those who develop and use what they call Formal methods mean something different to those who reject what they call "Formal methods". Same name, two meanings. To the users, "Formal" means "Mathematical" and/or "Logical" and includes creativity. Others think that "Formal" means structured, "tidy", controlled, using lots of redundant paper, or following someone else's rules. For this meaning see Fragile_process below.

      Mathematical and Logical methods use a well defined set of formula and creativity to help express and solve problems. The solution to the problem can then be checked by applying a collection of clearly specified rules. In many cases the checking can be automated. As an elementary example: arithmetic and algebra are mathematical methods. Boolean algebra and symbolic logic are well known formal systems. There are now a set of mathematical methods that have been demonstrated to help good people do good work in some industries - saving money as a result. However mathematics and logic may not fit your project.

      Examples: CLEANROOM, NORMALIZATION , SDL, VDM, B, etc. in these notes. Also Model Checking, ...

      There are languages that support mathematics and logic: VDL, Z, MATHS, ...

      Tools: PVS, SMT, SMV, Alloy, ...

      See [ fm-what.html ] [ essi-ConForm.html ] [ http://eis.jpl.nasa.gov/quality/Formal_Methods/ ] [ fmlinks.html ] (Formal Methods pages).

      Teaching: David Gries and Equational Logic [ logicthetool.html ]

      There are also semi-formal methods, like JSP and JSD that hide their mathematical basis.

    (Formal Technical Review): SQA methods [ http://www2.ics.hawaii.edu/~johnson/FTR/ ]

  46. Fragile_process::= one_of following,
    1. A high ceremony process.
    2. A mature, rigid, and documented way of producing software that often use a mathematically ill-defined set of notations and ideas.
    3. Anything the restricts the programmer's freedom.
    4. A process that produces something other than executable code.

    Fragile_processes are often confused with Formal_methods.

  47. FTR::=Formal Technical Review.RFP

  48. functional::=one_of following
    1. Something that works.
    2. A thirty-year old method of software design that works if you believe in it. [Strachey66]
    3. Divided up into a set of functions.
    4. Pertaining to a set of functions.

  49. functions::=plural of function.
  50. function::=one_of following,
    1. (math) A many-to-one total relation between two sets.
    2. (business) Why they pay for the software.
    3. (C/C++) A subprogram.
    4. (Pascal/Ada) A subprogram that returns a value.

  51. Fusion::=HP's 2nd generation OO method. RIP? RFP

  52. GQM::acronym="Goal, Question, Metric", by Basili and friends, [ GQM] .

  53. GoF::jargon=The Gang of Four, from post-Mao china, and later adopted to tag the four authors {Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides} of the first software book of design patterns: [Gammaetal94]

  54. GRAFCET::=IEC standard 848, State Machine Diagram or Sequential Function Chart in English
      The Sequential Function Chart (also known as statechart) as defined in the IEC 848 Standard (Preparation of function charts for control systems International Electrotechnical Comission Publication 848) inherits the French term GRAFCET (GRAphe Fonctionnel de Commande des itapes et Transitions).

      In 1975, forty French-speaking researchers and industrial managers involved in complex discrete system control met every two months to investigate models and methods for sequential system control. They devised a custom state model, derived from State Machine or Petri Nets theory, which was suitable to complex system and particulary manufacturing systems. After two years, this team proposed a model called GRAFCET. The term came from graph (because the model had a graphical basis) and AFCET (Association frangaise de cybernitique iconomique et technique) from the scientific association which supported the work. The basic concepts of this discrete system model were clear and simple: the State, the Action, the Transition and the Condition associated with the transition.

      From: Gordon Finlay

  55. HHOS::Acronym="Ho Ho Only Serious", a common mode of communication and instruction among the computer literate. Born in the ealy mailing lists on Usenet.

  56. HOL::=Higher Order Logic, tools: [ index.html ]

  57. HOOD::= Hierarchical Object-Oriented Design. [ hood.html ] [RobinsonP92] [DelatteHeitzMuller93]


    (incose requirements working group ): methods [ http://www.incose.org/rwg/ ]

  58. information_hiding::=one_of following,
    1. (Parnas Information hiding): The doctrine that modules should be planned so that each design choice is placed inside a separate module in a way that makes it easy for the choice to be changed without effecting the rest of the code. Implementation is easier with OOT and AOP. See [ http://www.acm.org/classics/may96/ ] and ADV/ADO and DRY.
    2. (Popular information hiding): Not being allowed to read code.
    3. See design_by_contract.

  59. Intent_specifications::= See http://sunnyday.mit.edu/papers/intent-tse.pdf
  60. IP::= "Intentional Programming",
      Based on the harmfulness of syntax this method attempts to revolutionize programming(ho hum). In place of textual source code a program is expressed as a tree which contains definitions of the intent (why) and implementations (whats) of various ideas. The environment provides enzymes that manipulate the tree and so the program. One problem is to re-engineer existing source code into IP trees. One step that is available is to raise the intentional level of a program by replacing a chunk of code by a terser expression.

      The method seems to a combination of VDM/VDL trees with a touch of literate_programming.

      But IP comes from Microsoft, so how can it fail?

  61. iterate::=to repeatthe same process -- to iterate is human, recurse divine, See iteration and iterations.

  62. iteration::= timebox:=select(time); req:=select(requirements,timebox); req:=analyse(req), code_and_test(req).
  63. iterations::= do( iteration).

  64. Jackson::people=JacksonMichael | JacksonDaniel | JacksonK. Michael is the father of Daniel. JacksonK invented MASCOT.

  65. JacksonDaniel::computer_scientist= See http://sdg.lcs.mit.edu/~dnj.

  66. JacksonMichael::methodologist= See http://dspace.dial.pipex.com/jacksonma/, see JSD, JSP, ...

    (Joke How EE and CS differ): methods [ eecs-difference-explained.html ]

  67. JSD::=following,
      JSD is a strong semiformal method.

      A way of analyzing a situation into a set of independent but connected dynamic objects with a high degree of information hiding. JSD is unusual in that it was the first method to make heart of the design a simulation of a real system. It is largely independent of the current functions of the software. Additional control and reporting functions are added to the central simulation. It is suitable for MIS and Real Time systems.

      For more information see [ http://www.kcsl.btinternet.co.uk/ ] Keywood Computer Services Limited, UK user group, and [ index.html ] Stephen Ferg's Home page.

      JSD, JSP, and SSADM share a common diagrammatic notation for expressing the structure of events and data.

    (End of Net)

  68. JSP::="Jackson Structured programming". JSP is to Data Processing what "The Dragon Book" is to Programming Languages.
      A strong semiformal method suitable for problems that involve processing data. JSP involves describing the logical structure of the data in a diagrammatic set of context free grammars. These become the basis for a set of cooperating sequential processes with back-tracking. These are easy to code in COBOL, Assembler and other languages that permit goto statements.

      The ideas for 'JSP' came from Michael Jackson's work at a UK software house in the early 70's but they have a solid mathematical basis in grammar theory. They adopted the name 'JSP' because all methods in the 70's had to have the word 'structured' in them (private communication, Simpson's on the Strand, London, Circa 1980).

      Try [ http://www.kcsl.btinternet.co.uk/ ] Keywood Computer Services Limited, UK user group, and [ index.html ] Stephen Ferg's Home page.

      JSD, JSP, and SSADM share a common diagrammatic notation for expressing the structure of events and data.

  69. LARCH::= (Formal, ADT Specs) - from Jim Horning [ http://larch-www.lcs.mit.edu:8001/larch/ ] [ larch-interest.archive.html ] //larch.lcs.mit.edu/ [ handbook.ps ]

    (Legacy Code and maintenance: Enterprise e-Publication Announcement): methods [ http://www.aboutlegacycoding.com/ ]

  70. literate_programming::method="A weak method developed by Donald Knuth the solution is developed as a mathematical paper and translated into code and documentation."

  71. LOTOS::language= See http://cse.csusb.edu/dick/samples/languages.html#LOTOS.

  72. LUSTRE::= Reactive language or method, RFP.


  73. Maria::tool= See http://www.tcs.hut.fi/Software/maria/

  74. MartinR::methodologist="Robert C. Martin", [ http://objectmentor.com/ ]

  75. MATHS::=My personal web page and discrete mathematics language, [ maths ]

  76. MERISE::=a french method for business applications, RFP.

  77. methodologist::="A fully matured programmer",
      A programmer who is old enough to realize that life would be easier if they always did things the same way. There are several stages:
      1. they organize their own programming,
      2. they try to influence their friends,
      3. they try to change their organization,
      4. they try to change the world,
      5. they become consultants.

  78. methodology::=following,
    1. The last stage in the life cycle of a software development idea before it (if successful) vanishes and becomes what everybody does anyway.

    2. idea::= hack; trick; technique; pattern; method; (technology | methodology); practice.
    3. First comes a hack. If this is neat then it may be reused in a different piece of software and so becomes a trick. When used a third time, it becomes a a technique. If there are several similar techniques then a pattern(1990s) or cliche(1980s) may be abstracted. The application of the pattern or cliche in many (more than three, that is) projects leads to a method.
    4. Sometimes the method is embedded into technology ( a language or tool ) which effectively stops its growth and hastens its death by universal acceptance. If the method survives then at some point or other it becomes highly elaborated or moves across the Atlantic and so becomes a methodology.

    (End of Net)

  79. MDA::jargon="Model Driven Architecture",
    1. The Object Management Group (OMG) started hyping this in the 2000s. The idea is that an UML model can be used to directly generate the software, cutting out a lot of coding.

      Further common types of models (patterns) can be reused and published in books.

      [ http://www.omg.org/mda/ ]

    (End of Net)

  80. model::=following,
      3 meanings! (1) model of your software, (2) model of your systems, and (3) models of the environment and requirements of the software
      (Unified Modeling Language): (Local page) [ uml.html ] (Unified Modeling Language (UML) Dictionary): [ UML.htm ]
      (accurately modeling arithmetic): [ http://www.cli.com/ ]

      (Alloy analyzer for models from Daniel Jackson):

    1. Alloy::language=a formal first order relational logic expressed in ASCII with tools in Java.
    2. Alloy_book::= See http://softwareabstractions.org.
    3. Alloy_analyzer::= See http://alloy.mit.edu.

      (Validator from Aspen Lake Software): [ validator.html ]
      (Reactive Systems and Model Checking): [ http://www.docs.uu.se/docs/rsmc/ ]

      See MDA.

    (End of Net)

  81. modular::="Divided up into separated parts",
      This technique was first attempted by Julius Caesar, the dictator, to handle Gaul.

      Modular programming is a class of informal methods rigidly applied in the late 60's having been developed in the early 60's to correct the problems with complex unmaintainable programs of the 50's. During this time the word "modular" was an essential part of any method however its meaning depended on the methodologist. See SP and OOP. It was said that before modular programming a good programmer wrote good modular programs and a bad programmer wrote bad monolithic programs. Afterward the good programmer wrote good modular programs and the bad programmer wrote bad modular programs. This was an improvement.

  82. MOSES::= Method at the University of Technology, Sidney [ moses.html ]

  83. MVC::="Model, View, Controller", A SmallTalk technique which separates the appearance to the user from the internal model, and the control of the model from both.

  84. NIAM::=conceptual data modeling based on logic and natural language, [ lookup?from=methods&search=NIAM ] also see ORM.

  85. normalization::=a mathematical procedure for reducing certain anomalies that occur in badly design data structures and data bases. It removes all pointers, arrays, repeating groups, etc. and generates a list of simple tables of records each with a field that identifies one row in the table. Normalized data tends to be easy to understand, search, and update. Used in Shlaer_mellor_method, SSADM, and other methods. Normalized data has to be made abnormal to improve the performance on all but toy systems. However normalized data clearly and simply expresses the logical structure of the world that the data encodes.

  86. Object::English=a desirable goal.
  87. Object::=A part of a running program that has an independent identity+data+operations. If encapsulated then the data can not be accessed or changed except by the operations. [ objects.html ]

  88. Object_Role_Modeling::=a way to design a data base that models a universe of discourse in terms of objects and the roles they play in elementary facts. It is an improvement over NAIM, and is also known as ORM. The author is Terry Halpin [ halpin.html ] Also see [ http://www.orm.net/ ] the ORM web site. The method starts with faacts like these
    1. The Author with name 'Terry Halpin' developed the method 'ORM'.
    2. The method 'ORM' developed from the method 'NAIM'.
    3. ...

    1. In my hummble opinion the notation (better than Chen ERD) gets a bit over decorated and the method would benefit from the ability to import an ontology (an is a hierarchy for example) rather than re-inventing one on each project.
    2. On the other hand I am pleased to see formal logic in use and supported by MicroSoft!
    3. The stess on being able to verbalize and populate the models so that they can be checked with normal people one of the best things.

  89. OMT::="Object Modeling Technique", grew up to be [ UML ]

    (ontologies): FAQ [ what-is-an-ontology.html ]

    (ontology): example: WordNet [ http://www.certifiedchinesetranslation.com/WordNet/ ] (Thank you Samuel Xie, Assistant to Professor Xie 2011-12-02 Fri Dec 2 10:36 )

  90. OO::=object_oriented,
      A class of informal methods rigidly applied in the 90's having been developed 1990-92 to correct the problems with programming in the middle 80's. During 1990-2000 the phrase "object-oriented" was an essential part of any method however its meaning depended on the methodologist.

      By the end of the millennium it became clear that OO means:

      1. Classifying objects by their behavior as well as the associations.
      2. Being able to describe the typical behaviors of a class of objects without describing how they are implemented.
      3. Being able to supply many implementations for one type of behaviors. Compare ADT above.
      4. Defining new classes of objects in terms of previously defined classes.
      5. Allowing an object to be referred to be a name or variable associated with a more general class then object itself.
      6. Expecting objects to be smart enough to select their behavior even when referred to indirectly.

      (End of Net)

      See BON HOOD UML Unified Coad MartinRobert, The Object Agency (Ed Berard) [ http://www.toa.com/ ]
    1. which has a number of documents and reports for free downloading including "A Comparison of OO Development Methodologies" - a 70 page report comparing 10 different methodologies.

    2. Bibliographies [Graham94] [RobinsonBerrisford94] OBJECT

      An architecture for many n-tier systems:

    3. class_types::= See http://click.softwaredevelopment.email-publisher.com/maaafZQaaReXIa9GYH3b/.

  91. OOA::=Object-oriented Analysis.
  92. OOD::=Object oriented Design
  93. OOP::=Object oriented programming. OOP is a weak informal method that uses modules that are orthogonal to SP. SP and OOP were both invented close to 1970 but SP dominated until the late 1980's. OOP extends the ideas of ADT to include deriving new types from old ones, and allowing objects to behave as if they belonged to many types at one time:
    (Deconstruction of subtyping): methods [ subtyping.htm ]

  94. OOPL::=Object oriented programming language.
  95. OOT::=Object oriented technology. The technology that makes it easy to modularize software into objects rather than sequences and selections of procedures and functions. The technology lagged behind the theory for 15 years.

  96. object_oriented::=using objects+classes+inheritance+polymorphism+etc, see OO.
      Newbie asked "Master Li, what is the true nature of objects?" The master answered "What is the sound of one programmer coding" and Newbie said "Hack! Hack! Hack!". The master knocked him into a nearby pool of coffee. As Newbie climbed out he experienced satori and went off to market his own methodology.

  97. Object-Oriented::= Methods(Formal or informal, somewhat unstable), see OO above.

  98. Open_Source::process=
      It is said that if you put enough monkeys in a box with type writers then one of them would produce "Hamlet".

      In contrast, open source projects do not use monkeys but intelligent and expert users who are also the developers. Further they cooperate and correct each other's errors. Finally, open source projects often maintain high standards for coding.

      Open source is more about culture and process than about the particular languages and methods used by the programers/users/testers.

    (ORA Canada): methods [ http://www.ora.on.ca/ ]
    (ORM): a method derived from NAIM, [ Object_Role_Modeling ] above.

  99. OSA::= Object-Oriented Systems Analysis at Brigham-Young University , Utah [ OSA.html ]

  100. patterns::=plural of pattern, the better patterns form a pattern language (in theory).
  101. pattern::="Acceptable solutions to standard complex contextual problems"
      The first patterns were recorded by an architect called Alexander. They showed, for example that placing shelves around a room was good for adults (to put things down on) and for children (to hide under). Similarly, the best side of a building for a patio depends on the the lattitude: in cold latitudes make the patio face the sun but in hot areas put them in the shadow of the building.

      Then the software community got the idea as a way to organize objects. See GoF.

      A pattern must have a name, must describe where it applies and the conflicting forces that are involved. It should propose an acceptable resolution to the forces that has been applied at least three times. It should discuss the consequences of the proposal and give related patterns.

      A collection of related patterns defines a pattern-language.

      Every authority I have read has their own template for patterns. [ patterns.html ]

      Patterns evolve by a social writing and editting process. The are discovered in practice and documented for later reuse afterwards.

      We also have Anti-Patterns (they occur a lot but don't resolve the forces very well)

      There are business patterns, organizational patterns, process patterns, and so on.

      Craig Larman has 8 "General Responsibility Assignment Responsibility Patterns" which I teach as part of "Requirements Analysis" [ ../cs372/ ]

      (Design pattern index): wiki [ wiki?PatternIndex ]

      (hillside patterns): [ http://hillside.net/patterns/ ]
      (ObjectArchitects patterns): [ http://www.objectarchitects.de/ObjectArchitects/patterns/ ]
      (FPS - Functional Pattern System for Object-Oriented Design): methods [ http://www.mm.informatik.tu-darmstadt.de/staff/kuehne/fps/ ]
      (MFC patterns): [ http://www.cs.hut.fi/~kny/patterns/ ]
      (Patterns and Software: Essential Concepts and Terminology): [ patterns-intro.html ]

      There is a new pattern language from Ward Cunningham on
      (Portland Pattern Repository, ): [ ppr ]
      (Patterns Page): [ http://st-www.cs.uiuc.edu/users/patterns/ ]
      (Doug Schmidt patterns concurrent, parallel and distributive computing): [ patterns.html ]

    (End of Net)

  102. PSP::="Personal Software Process", Improvement thru statistics. [ wiki?ExtremePspExperience ]

  103. process::="a way to organize software development that is looser than a schedule and less detailed than a methodology."
    (ISO/IEC 12207): standard process [ processes.html ]

  104. Process_Pattern_Language::= See http://www.bell-labs.com/people/cope/Patterns/Process/index.html.

  105. Petri nets::technique=An originally over general theory of how a complex concurrent system of parts can work together this evolved into a special form of diagram which has been used to design operating systems, protocols, etc. Also known as marked directed graphs. More information in [ math_76_Concurency.html ] [ about.html ]

  106. Process Algebra Semantics::= The report "Process algebra semantics of \varphiSDL" [ SDL.html ]

  107. PVS::tool="Proof Verification System", [ pvs.html ]


  108. RAISE::=A formal method intended for industrial use. [ http://dream.dai.ed.ac.uk/raise/ ]

    (Recursive Design): methods [ http://www.projtech.com/ ]

  109. Refactoring::=a process of code improvement that works by a series of simple steps that leave a program operational.
  110. refactoring::=`technical method of improving code style without changing it;s behavior'. For example: Copying a piece of code into a function definition and then replacing the orginal code by a call to the function.
      Refactoring was born in a thesis: [Opdyke92] and has become an essential part of XP and many other methods: refactor

  111. Ravioli::="Tendency of OO programs to made of large numbers of very tiny and incomprehensible pieces", [ wiki?RavioliCode ]

  112. RDD::="Responsibility Driven Design", Rebecca Wirfs-Brock's way of of packaging the necessary operations in a piece of software into coherent modules. "Objects are citizen's with responsibilities and collaborators". This way of thinking works so well that it has been incorporated into several other methods. CRC cards are used to document classes, responsibilities, and collaborations. Designs a tested by a group of people acting out the the behavior of the objects.

  113. responsibility::=something that an object or class either maintains or knows how to do.

  114. reuse::=the holy grail of software development, to save time and money by not redoing previous work in every project.
    (Reuse Function Study): methods [ survey ]

  115. RPL::= rapid prototyping for requirements analysis with CASE & OO [ rpl.html ]

  116. RUP::process="Rational Unified Process", iterative process framework, [ wiki?ExtremeUnifiedProcess ]
    1. RUP is a framework that has to be adapted to particular projects.
    2. It lists a dozen disciplines, each of which can be used in any iteration.
      1. Business Modeling
      2. Requirements
      3. Analysis and Design
      4. Implementation
      5. Test
      6. Deployment
      7. Configuration and Change Management
      8. Project Management
      9. Environment (Tools, metadata,...)

    3. RUP has phases and each phase is a sequence of iterations and each iteration involves a mixture of disciplines. The phases do not have memorable names:
      1. Inception
      2. Elaboration
      3. Construction
      4. Transition

    4. RUP stresses the importance of tackling the critical risky features in a project early on.
    5. Typically RUP is presented by a picture like this [ rup_discipline.jpg ]

  117. SAD::="Structured Analysis and Design". RFP.

  118. Scrum::="Agile weak medium-scale process",
    1. The Scrum method seems to be inspired by the game of Rugby.
    2. This can be described as American football without the armor and ceremony.

    3. Two things seem to be special about Scrum:
      1. A 15 minute daily meeting -- where everybody must stand up, They report status, while managers listen and look for obstacles that need to be removed.
      2. The other special thing is that the software is produced in 30 day iterations called sprints.

  119. SEMAT::acronym="Software Engineering Method and Theory", an attempt to find a simple way to organize and think about what we have to do, and the things we have to do it to -- the "alphas". [ SEMAT ] (WikiPedia), [JacobsonEtAl13] (Text), [ http://www.ivarjacobson.com/SEMAT_Kernel_Cards_Download/ ] (Kernel on cards), [ http://semat.org/ ] (Web page).

  120. semiformal::=a method that has a hidden mathematical/logical theory. Examples: JSD, JSP, SSADM.

  121. SIGNAL::= Reactive language or method, RFP.

  122. skeletons::=an offshoot from generic functional programming.
    (Skeletons Home Page): [ skeletons.html ]
    (Skeletons Barry Jay): [ http://linus.socs.uts.edu.au/~cbj/ ]

    (SPI Software Process Improvement): methods [ index.html ]
    (SR's Software Quality Hotlist ): methods [ HotList ]

    (Software Productivity Consortium): methods [ http://www.software.org/ ]

  123. SQA::="Software Quality Assurance", any method, process, or technique that can ensure that a piece of software is good or at least good enough. [ sqasurvey.html ]
  124. ALD::=Advanced Logistics Development, SQA [ http://www.aldservice.com/ ]

  125. SSADM::=Structured Systems Analysis and Design Method. (semi-formal) Note. This is not SADT or SA/SD because it incorporated ideas such as dynamic entities(concurrent objects) and physical design control. An 'open' method and a registered trademark of CCTA, the UK Government Center for Information Systems. Google is a good place to find out about SSADM. It is still a popular heavyweight method in Europe.

    SA/SD::= Structured Analysis and Structured Design.

      A class of weak informal methods rigidly applied in the 80's having been developed in the 70's to correct the problems with modular programming and systems analysis in the 60's. During this time the word "structured" was an essential part of any method however its meaning depended on the methodologist. The two most rigorous methods were SSADM and SADT. Compare with OOA/OOD.

  126. SADT::=Structured Analysis and Design Technique. An interesting method of analysis and design that includes an unusual kind of chart for showing how parts of a system are related.
       		| B |----.
       		 ---     |
       		  ^     ---     ---
       		  |    | C |-->| D |
       		  |     ---     ---

    shows that that A is used to implement B, B controls C, and C supplies output that is input into D. Each box becomes a diagram at a lower level if it is at all complex. No more than 6 boxes per diagram! But any number of arrows. The diagrams are the SA part of SA+DT. The above diagram does not show that they are prepared like engineering drawings - names, indexed, signed,... and subjected to detailed technical reviews.

  127. DT::part_of(SADT)=Design Technique. The DT rules like: "Think about the arrows first" plus the discipline of of reviews make SADT the method work in just about everything except detailed design of code. (The above is my gloss on the method.... if you know of an Internet source that extends or contradicts it, tell me and I will make links here).

  128. SDL::=Formal specification languages used in telecommunications. Essentially the basis for UML message sequence charts. [ http://www.sdl-forum.org/ ]

  129. Shlaer_mellor_method::=recursive design - an object oriented method that includes normalization and dynamics and aims to automate much of the coding. See Project Technology: [ http://www.projtech.com/ ]

  130. source_code::=The coded version of a software that is translated into an executable form.
      As StarHacker flew over the Evil Empires's DOStar he wondered how he could destroy it. He heard a voice: "Use the source, Luke". [Core Wares, Episode 17.5]

      I don't know why, but programmers have always believed that time spent doing anything but working on code is a waste of time. This is rather like a civil engineer deciding that laying bricks is the only thing worth doing, or an electrical engineer focusing on soldering!

      Even famous methodologists are now elevating Source Code to the methodological pinnacle:

       The Code, The Whole Code, and Nothing but the Code!
      All diagrams are rejected and the only thinking is done at the machine.

      Code oriented methods tend to be weak methods. They need some kind of Quality Assurance to avoid maintenance nightmares. See testing, pair_programming, refactoring, smells, inspections, walkthroughs, peer_review, beta, debugging, etc.

  131. SP::=Structured Programming. Dividing code up using only sequence+selections+iterations.
      SP is a very weak method.

      Structured programming is a class of methods rigidly applied in the 70's having been developed in the late 60's to correct the problems with complex unmaintainable programs of the early 60's. During this time the word "structured" was an essential part of any method however its meaning depended on the methodologist. SP can have any degree of formality: For example "No gotos" has none, but the Dijkstra/Gries Discipline is based on logic. See SA/SD and OOP

  132. state::=A way of structuring behavior patterns by giving names to certain situations that can occur.
      Also known as "mode".

      A way of organizing or modeling a complex behavior. If something behaves in one way for a time and then behaves differently we say it has "changed state". When the number of different behaviors are small then a State Transition Diagram (STD) or table is often used to document the changes. David Harel has invented StateCharts to handle more complex systems. StateCharts have been adopted as part of OMT and so became part of UML. In essence StateCharts are a return to the Flowcharts of the 1950's!

      Many methods use states as a design technique. SDL, Shlaer-Mellor, ... But JSD explicitly avoids states by describing the patterns of behavior using regular expressions and grammars. The states are then derived from these patterns.

      States and modes in user interfaces are often a source of problems for the user but a solution for a harassed designer.

      Beware of states but seek them.

  133. Statestep::="a strong method aimed at uncovering unusual scenarios hidden in a specification", [ http://statestep.com/ ] has devolved to the point of having a tool to support it.

  134. SQA::=Software Quality Assurance. Any technique that reviews any document or product to see how good it is. These vary from formal inspections to pair programming. They are commonly applied to code, but pay off better if applied to user requirements and designs.

  135. STL::="The C++ Standard Template Library", [ stl.html ]

  136. strong::@methods=Methods that apply to such a small number of problems that they provided precise and powerful help in solving them., See weak, [VesseyGlass98] and [Jackson95c]

  137. Structured::= divided into pieces according to some set of rules based on a favored set of coding structures. Different methods favor different sets of coding structures.
  138. structured::= a popular buzz word in the 1960's and 1970's. See SP, SSADM, SADT, etc etc.
      The incredible Mullah Nazourdon often gave advice on methods to people in his village. This varied from year to year but the methods were always described as "structured". The villagers noticed this an asked him why. He replied that they wouldn't work unless they were called "structured". So the villagers asked him if he meant that his clients wouldn't work or that the methods would not work. And he said: "Yes".

  139. The_Tao_of_Programming::HHOS= See http://www.canonical.org/~kragen/tao-of-programming.html (submitted by Kyle Sweeney).

  140. testing::=finding out if a program works on a particular set of data.
      Testing give a feeling of false confidence unless a lot of time is spent on it.

      unit tests, acceptance tests, operational testing, white and black box testing,...

  141. TLA::=The Temporal Logic of actions [ TLA in methods ]

  142. top_down::=Attempting to design something by breaking a large problem into to smaller problems and solving each of these in turn. Also know as building castles in the air. [ bottom_up ]


    (UI Design News): methods [ http://www.uidesign.net/ ]

  143. UML::=Unified Modeling Language [ UML in uml ]
      Once three methodologist tried to define an elephant: One said it looked like a cloud, the next said it looked like an upside down tree, and the third said it was a suitcase.

      And they all lived happily ever after in the cave of the jolly blue giant.

  144. use_case::=following,
      A way of making sure that each set of requirements for software has some value given to at least one type of user. A use case describes several ways of attaining this value (or failing to) with a prime successful scenario and zero or more more complex and failed extensions.
      (Use Cases with Goals): [ usecases.htm ]
      (UseCases: Be Careful by Edward Berard): methods [ smnn?usecase.htm ]
      (Use Case Maps Web Page): methods [ http://www.usecasemaps.org/ ]

    (End of Net)

  145. VDM::=Vienna Development Method is based on a mathematical language (VDL) developed in the 1960's for defining the semantics of languages in terms of trees.
      The IBM Laboratory in Vienna once invented a language to define the precise mathematical semantics of programming languages. It was called VDL (Vienna Definition Language) In time Cliff Jones worked out some denotational semantics of VDL and it re-emerged as VDM: Vienna Definition Method.

      There is an ASCII based Specification Language: VDM-SL

      Also see Z_vs_VDM below.

    (Volere Requirements Specification): template [ Template.html ]

  146. weak::@methods=methods that apply to many problems but do not provide powerful and detailed help solving them, See strong.


  147. xml::markup_language= See http://cse.csusb.edu/dick/samples/xml.html.
  148. XP::=Extreme_Programming.
  149. XP::@method=a rigid informal code_centered Agile process.
      Just when I thought we'd seen the last of the (_)P (fill in the blank) methods along came XP. You might think that extreme programming offers the safety and stability of jumping off a cliff on a skate board while holding hands with a colleague. However, because the XP team shows what it can do, as quickly as possible, it can iterate to a solution that keeps the customer satisfied, even as the customer changes their minds.

      In fact, extreme programming offers more disciplined control of risk than many older methods. An eXtremely eXciting time is offered by Highsmith's Adaptive Software Development(ASD). The Scrum method claims to be a less disciplined process which fits the same situations as XP: small co-located team with a customer representative on site.

      XP has many techniques that evolved in practice and not got any respect in academe -- possibly because people in academe tried some of them 30 years ago. Some practices have a strong retro feel: the design is the code is a pure 1960s slogan(source_code).

      XP is also highly prescriptive. Kent Beck lists the critical components: { write test first, the planning game, short release cycle, pair programming, on-site customer, open workspace, yesterday's weather predicts tomorrow's, refactor code to say every thing once and only once, continuous integration, collective ownership of all code, sane hours, programmer's resist business pressure }, (Redacted from Kent Beck's article in the Cutter IT Journal [Beck00a] ).

      There is an excellent road map for XP at [ wiki?ExtremeProgrammingRoadmap ] and lots of discussion on the rest of the WikiWikiWeb site: [ wiki?WelcomeVisitors ]

      If the above links don't work I made a local ripoff of the [ XPRoadMap.html ] Extreme Programming Road Map.

      XP is an weak Agile process.

      (XP-rogramming.com): methods [ http://www.xprogramming.com/ ]
      (Extreme Programming Explained Embrace Change): methods [ wiki?ExtremeProgrammingExplainedEmbraceChange ]

  150. YSM::="Yourdon's Methods", These methods span from SP through to the start of the object-oriented revolution of the 1990s. Mike Brough was involved in this and has prepared an excellent page [ ysmhist.pdf ] describing the evolution of the methods. A fascinating process.

  151. Z::=a mathematical language designed for specifying complex pieces of software.
      [ z.html ] [ http://www.afm.sbu.ac.uk/z/ ] [ http://www.comlab.ox.ac.uk/archive/ ] [ index.html ]

      Z Extensions

      1. Z/Eves -- for mathematical specifications? RFP
      2. OOZE - object oriented? RFP

  152. Z_vs_VDM::= See http://www.comlab.ox.ac.uk/archive/z.html#vdm and [ UMCS-93-8-1.html ]

    Send me EMail

  153. RFP::=Request For Pointer. If you know of any URLs that I have missed for any methods/languages please send me EMail by selecting [Comment/Contact] at the top_of_page.

( End of document ) <<Contents | Top