Re: check funtion and password show in UML
Date: Wed, 31 Jul 2002 17:45:47 GMT
Message-ID: <3D4822E2.80700_at_verizon.net>
Responding to Coates...
>>One also does the same sort of subsystem isolation thing with >>persistence mechanisms. So the way your Registration is represented in >>the application solution may be quite different than in the DB schema >>(though unlikely in this simple case). >>
>
> An overall logical mismatch like that between the Data storage model (DB
> schema) and the Object role model is an error in most cases.
They will usually be similar but they will almost always differ in detail. For example, in an RDB relationship navigation *must* work with embedded keys in the data and the location of foreign keys is predefined (except in unconditional 1:1 relationships). That is not true for class interactions, which will be implemented to minimize searches.
>
> In OO software development we want the Data storage model to follow the
> skeletal logical guidelines of the Object role model. We want the Data
> storage model to be *subordinate* to the Object role model.
While the second sentence is true, what one wants and what one gets are not always the same thing. Today's applications often deal with data that is shared with other applications that may not have the same view. In addition, the common access mechanisms for multi-user databases require optimization of the DB for the mix of applications rather than specific applications. That is, the priorities of the DBA are likely to be different than any particular application.
>
> System design with logical leadership and dominance by objects and
> collaborating networks of objects, as responsible role abstractions, is
> the core and essence of the OO software development paradigm.
Quite true at the individual application level, but not necessarily true at the enterprise DB level.
>
> Pragmatic alliance/xp hacking and slavishness to E/R modelling
> notwithstanding.
After all these years you still can't seem to grasp the facts that (a) model based software engineering is on the opposite end of the development spectrum from the OOP-based agile processes like XP and (b) that the abstraction employed for translation OOA is much further from E/R modeling than that employed by the elaboration OO methodologies.
There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman
hsl_at_pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH
Received on Wed Jul 31 2002 - 19:45:47 CEST