Jørn Hansen

UserPreferences

Let's explore this WikiWiki thing:

1. JørnsTodo?
2. JørnsRememberToUpdateCalendar
   1. Hmm

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

So I can have a
Table	Here

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!!

Ohh.. I think I get the point

What do ArneDoToday