These questions come back in every project.
This week I'll answer them with my personal point of view.
Conceptual model
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.
GUI design
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.
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.
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.
- Start with
object modelling of the Classes,
and in parallel with
design of the physical database model.
- 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.
- 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.
- 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!
Nut
|