There are some attempts at humor here.[ HHOS ]
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.
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/ ]
See Also [ wiki?CrcCard ] [ CRC_cards ] [ 5123 ]
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.
Also see ontologies.
(DRY): principle
[ wiki?DryPrinciple ]
(DSDM: Dynamic Systems Development Method): methods
[ http://www.dsdm.org/ ]
(FAQ Comp.software-eng Archive): methods
[ http://www.qucis.queensu.ca/FAQs/SE/ ]
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.
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
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?
(Joke How EE and CS differ): methods
[ eecs-difference-explained.html ]
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.
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.
(Legacy Code and maintenance: Enterprise e-Publication Announcement): methods
[ http://www.aboutlegacycoding.com/ ]
Further common types of models (patterns) can be reused and published in books.
(Alloy analyzer for models from Daniel Jackson):
(Validator from Aspen Lake Software):
[ validator.html ]
(Reactive Systems and Model Checking):
[ http://www.docs.uu.se/docs/rsmc/ ]
See MDA.
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.
(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
)
By the end of the millennium it became clear that OO means:
Net
An architecture for many n-tier systems:
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.
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 ]
(Recursive Design): methods
[ http://www.projtech.com/ ]
(SPI Software Process Improvement): methods
[ index.html ]
(SR's Software Quality Hotlist ): methods
[ HotList ]
(Software Productivity Consortium): methods
[ http://www.software.org/ ]
SA/SD::= Structured Analysis and Structured Design.
---
| B |----.
--- |
^ --- ---
| | C |-->| D |
| --- ---
A
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.
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
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.
unit tests, acceptance tests, operational testing, white and black box testing,...
And they all lived happily ever after in the cave of the jolly blue giant.
There is an ASCII based Specification Language: VDM-SL
Also see Z_vs_VDM below.
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-rogramming.com): methods
[ http://www.xprogramming.com/ ]
(Extreme Programming Explained Embrace Change): methods
[ wiki?ExtremeProgrammingExplainedEmbraceChange ]
Z Extensions
