Hi,

Never mind my old static and thus unupdated homepage. It's easier to just give my email address here <JornH AT person.dk>

Let's explore this WikiWiki thing:

1. JørnsTodo?

2. JørnsRememberToUpdateCalendar

   1. Hmm

A Learning Guide To Design Patterns - http://www.industriallogic.com/papers/learning.html

System Testing Patterns - http://www.agcs.com/patterns/papers/systestp.htm

The Programming Process

'...or a one page guide to OO SW development'

1. Introduction
2. Object-oriented Software Engineering
   • History: OMT (Rumbaugh) - Booch - Coad/Yourdon - Shlaer/Mellor - OOSE (Jacobson)
   • Now: UML 3 Amigos
3. Why Object-oriented?
   1. Route Planning - an Allegory (på dansk: analogi)
      • Turn, left, right, left, left - not good solution if going on a different trip tomorrow - better to give a map and teach how to use it (a short term cost - but pays off in the long run)!

      • [Same problem with Exbert's first ShowBoat solution]

   2. Problem Domains

      • Base your design on problem domain = context for particular problem => more robust solution

      • Problem domain for route planning is e.g. maps, route planning, travelling and strategies for moving around

      • SA/SD based on top-down => leads to solution based on specific problem => rigid structure with centralized control

      • OO based on middle-out => details based on abstractions

        • - core: problem domain abstractions - stable! - downward: code in classes [handling of class responsibility] - upward: overall structure developed using associations and interitance
4. Writing programs
   1. An Overview
      • RUP: Inception (2) - Elaboration (3-4) - Implementation (5) - Testing and Delivery (6)

      • Design tries to predict the future - be prepared to get it wrong.

   2. User Requirements Gathering
      • Scenarios (or more rigorious - Use Cases)
   3. Analysis
      • UML notation for class and object diagrams
      • CRC [User Stories]
   4. Design, Implementation and Testing

      • Tip: Be proud of your code. Let others read it. When they find errors don't be upset - just fix them.

   5. Review and Iterate
      • Add subsets of full requirements - review work so far [refactoring?]

      • Common pitfall: Procedural design partitioned in classes (linear sequence of events) => create objects that encapsulate data and provide services

      • Tip: Throw away design/code that doesn't work or is going nowhere.

   6. Program Testing and Delivery
   7. Debugging
5. Maintenance
6. Practice and Experience

   • Learn to judge the quality of programs. (Good structures that exhibit good abstraction, flexibility, modularity and elegance )

   • Study design patterns A Learning Guide To Design Patterns

   • Tip: Spend a significant amount of time reading the literature [TBD ladder]

     • - aim to read one text book a month along with 2-3 journals!!

BTW, if you create personal pages, do prefix them somehow, like JørnsTodo. Because maybe other people would like to have a todo page too?

Ohh.. I think I get the point

What do ArneDoToday

CategoryHomepage

Hello Jørn!!... saw your comment about MojnMojn in south Jutland (sorry I cant remember exactly how to spell that in Danish - is it Sønderjyllands??) when I was about say the same thing. People really used to crack me up saying that when I lived there! In England there's a football team called West Bromwich Albion (WBA) who's fans, for some reason, shout "boing boing" during the games and jump up and down. So whenever anyone said MojnMojn to me I just said BoingBoing back while doing one quick jump! PS your name sounds a bit familiar...do (or did) you work for Infocom??