Differences between revisions 1 and 2
⇤ ← Revision 1 as of 2001-09-28 22:54:28 →
Size: 3304
Editor: anonymous
Comment: missing edit-log entry for this revision
← Revision 2 as of 2008-06-26 09:50:55 → ⇥
Size: 3306
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 56: Line 56:
  * Study design patterns [http://www.industriallogic.com/papers/learning.html A Learning Guide To Design Patterns]   * Study design patterns [[http://www.industriallogic.com/papers/learning.html|A Learning Guide To Design Patterns]]

See http://www.JornH.person.dk ... unfortunately only in Danish language at the moment, sorry! But at least my e-mail address is there.

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

So I can have a

Table

Here

The Programming Process

  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

JørnHansen (last edited 2008-06-26 09:50:55 by anonymous)