OO Development

Monday, 16 October 2000
These questions come back in every project. This week I'll answer them with my personal point of view.

Input for OO software development

  1. Conceptual model

    Logical Design The conceptual model is the result of modelling effort, on a logical level.
    • An ERD with one box for each entity.
    • Relations between entities with one-to-many relations that run top-to-bottom. One-to-one and many-to-many relations must have reasons to exist, at a logical level.
    • A description of attributes (name, data type, length, optionality)
    • Expected number of occurrences per entity (required for technical optimisation of the database).
    • Description of anything special, like triangular relations or attributes that are mandatory under condition.
  2. GUI design

    Paper sketch, a prototype For a web application this can be an HTML prototype.
    • with the exact layout, look & feel, and with the right cascaded style sheet. For an internet application the HTML code must be able to cope with a variable screen size.
    • with entity and attribute name at the spot of variable information and a description of derived data.
    • a description of anything special, such as complex access paths or complex logic.
    • a user that supports the design, after a Discount Usability Test.
Iteration, a well known concept in Rapid Application Develoment Both conceptual model as well as the GUI design must be stable for an efficient development cycle. Rapid Application Development is known for iteration, various design versions, where one version builds on the previous one.

A good designer will make sure to fine tune the design in design phase, before programming starts. Of course it's always possible to adapt software later, but that's relatively expensive and time consuming. Better do it right the first time.

Steps in OO software development

The following diagram shows a very efficient approach with minimal dependencies between the steps.

An OO approach, with a three layer architecture offers more possibilities to develop in parallel.

  1. Start with object modelling of the Classes, and in parallel with design of the physical database model.
  2. The Object classes get dummy methods. The GUI programmers can use these to start coding. They need not worry about the implementation of the methods. That implementation will come later. This is a nice example how encapsulation can help to minimise dependencies.
  3. The database specialist and OO specialist reach agreement on an interface, to map data from the database layer to instances of objects. An example of such an interface is an alias for column in a SQL result set, or an XML type of hierarchical tree structure.
  4. The database and object layer will now get the real coding, replacing the dummy methods. This does not change anything in the GUI-layer. Yet, the system starts to work for real, data element by data element, screen by screen.
When all methods are finished, integrated system test can commence.

The software developers have tested every method, and every screen already. So the test of the application focuses more on the whole. Does the combination of screen work as it should do?

Till next week!