"Programming languages are not at a high enough level of abstraction to facilitate discussion about design" (1)
"... conceptual perspective ... we are building a vocabulary to talk about a particular domain" (5)
"(there are) three modes in which people use the UML: sketch, blueprint and programming language ... the most common is UML as sketch" (2)
"The essence of sketching is selectivity ... use the sketches to help communicate ideas and alternatives about what you're about to do ... only important issues that you want to run past colleagues or sections of the design that you want to visualze before you begin programming" (2)
"... sketches are explorative, while blueprints are definitive" (3)
"sketchers, see the essence of UML to be the diagrams ... however, (for) the creators ... the essence of UML is the meta-model" (6)
The author favours UML as sketch approach. He believes that blueprints are too difficult to do well and slow down development. WRT UML as programming language ... he's not convinced that graphical forms are more productive than textual forms (6)
UML Diagrams. On page 12 there is a table showing 13 different types of UML diagrams:
- Class
- Sequence
- Object
- Package
- Deployment
- Use case
- State machine
- Activity
- Communication
- Composite structure
- Component
- Interaction overview
- Timing
They can be divided into Structure diagrams (eg. Class) and Behaviour diagrams (eg. Sequence) (12). He suggests to start out with those two - Class and Sequence diagrams (16).
UML is Not Enough
"... you shouldn't hesitate to use a non-UML diagram if no UML diagram suits your purpose." (15)
"Now that the methods war is over, patterns are where most of the interesting material about analysis and design appears." (17)
Iterative and Waterfall Processes
Both processes use the (four part) software life cycle: requirements analysis, design, coding and testing
Waterfall style: Attempt to finish one part of software life cycle completely before moving onto next part (20)
Critique of waterfall approach: "... it's very difficult to tell whether the project is truly on track with a waterfall process." (21)
Iterative style: Break down the project into subsets of functionality. Then do the complete software life cycle for each part. Each iteration should produce production ready integrated software.
Some think they are doing iterative but they are not (pseudos), eg. "This iteraction's code is very buggy, but we'll clean it up at the end" (21)
Other names for iterative development: incremental, spiral, evolutionary, jacuzzi (21)
Predictive and Adaptive Planning
Prediction is v. hard to achieve due to requirements churn. If you freeze requirements then you run the risk of delivering software that no longer meets the needs of its users. (23)
Adaptive planners "... contends that requirements churn is unavoidable ... predictivity is an illusion ... we should face the reality of constant change and use a planning approach that treats change as constant in a software project" (23)
"You can't say "according to plan" in an adaptive environment , because the plan is always changing" (24)
"An adaptive plan ... requires an iterative process"
Agile Processes
Examples (other names): Extreme Programming XP), Scrum, Feature Driven Development (FDD), Crystal and DSDM (Dynamic Systems Development Method)
Agile approaches are strongly adaptive (dynamic) and also people-oriented (meaning they work best with high quality people)
Most use UML in sketch mode
Agile process are low in ceremony, they minimise documentation and control points. Ceremony makes it harder to make changes and works against the grain of talented people.
"... the lack of ceremony is a consequence of adaptivity and people orientation rather than a fundamental property" (25)
My comment: One implication here is that mediocre programmers may need more ceremony, more structure, more check points, more documentation.
Patterns (27)
Experts document patterns, common design themes, so that those not so expert can learn and apply it
This is Zone of Proximal Development applies to software development (my comment)
Patterns are more useful than methods like UML. Diagrams (UML) are useful but discussing experiences is more useful.
"A pattern is much more than a model. A pattern must also include the reason why it is the way it is. ... a pattern is a solution to a problem. The pattern must identify the problem clearly, explain why it solves the problem, and also explains the circumstances under which the pattern works and doesn't work ... they are the next stage beyond understanding the basics of a language or a modelling technique."
This reinforces what I have been thinking - that patterns are the way to go in teaching programming / Game Making with Game Maker.
What about UML? I'm not sure you really need UML, patterns might be enough? Nevertheless, I like the idea of using UML sketches to discuss programming concepts. I see that as a current problem in my (lack of) programming discussions. We currently discuss programs through chunks of code and file attachments. The contrary view is that UML is a step removed from coding and learner programmers need to learn how to program before they move on and learning to program might take ten years. Jack Reeves says, "code is design", that the way to go is through comments within code.
Fowler supports a dynamic (adaptive, iterative) approach to software development but this still operates within a software development cycle: analysis, design, coding, testing (simpler than the Systems Development Life Cycle). I strongly support the dynamic conception of software development, rather than the top down predictive approaches. This fits my philosophy of how all things develop in the real world, through contradiction and struggle. We shouldn't be demanding extensive documentation from young programmers, it will make things boring and tedious for them.
I intend to write more about patterns
Other references about software design styles:
Jack Reeves, Code as Design
Brian Harvey, Symbolic Programming versus the AP Curriculum
Paul Graham, On LISP
Philip Armour, Five Orders of Ignorance
2 comments:
I enjoyed the clarity of analysis Bill - thanks - is something I have never really considered before - we have had some calls for programming languages to be taught in NZ schools but the discussion and critique is not at this level.
I enjoyed the reference to the five orders of ignorance from Philip Armour's "Of Jet Planes and Zeppelins" - I have been teaching and using this structure with students for a number of years now - we call it "ignorance logging" and base our epistemological breakdown of "ignorance" on Marlys Witte and Ann Kerwins work. Check out the Q-cubed programs at the University of Arizona to see how this has been used with great success in education.
thanks arti,
here is the correct link to the Q-cubed program at Uni of Arizona
From that page I found their ignorance map (unfortunately v. small and hard to read) and their domains of ignorance:
Known unknowns
Unknown unknowns
Errors
Unknown knowns
Taboos
Denials
I like this extension from Philip Armour's categories because it brings in the emotional aspect (taboos, denials) as well as the cognitive aspect
I hope to follow up on this
I'm still yet to google for Marlys Witte and Ann Kerwins work
Post a Comment