What are some common methods of Object-Oriented Analysis and Design? How do they work? - null_pointer Sabre Multimedia

quote: Original post by null_pointer

What are some common methods of Object-Oriented Analysis and Design? How do they work?

I think the most common method right now is "The Unified Software Developement Process" by the guys behind the UML (Unified Modelling Language) standard (Ivar Jacobson, Grady Booch and James Rumbaugh).

The 3 authors had each their own methods (ie. the Booch method) which was "unified" into a single method. Regretfully I don''t know much about these previos methods, how they works or if anyone still uses them.

I have also heard of a method called "Octupussy" or something like that. But I know it only by name and don''t realy know anything on how it works.

Alternative I know only of a danish method simply called "Object Analysis and Design" (title translated into english). But its not really that interesting as it is not widely used (most for teaching in danish universities I believe).

The Unified Process goes somewhat simplified like this (but not as steps but rather iterative until you believe you have it right):

REQUIREMENTS PHASE:

1. Write down list of requirements.

2. Examine requirement and find ''actors'' (anyone who interacts with the system acting a role) and ''use cases'' (what the actors do to the system).

3. Describe the actors and the use cases as seen from outside the system in a ''use case model'' of the system

ANALYSIS PHASE:

4. Refine the use cases in a ''analysis - use case realization''. In this phase the use cases are seen from a point more "inside" the system and data flow between objects is sketched.

5. Describe the objects and sketch the initial distribution of the systems behaviour on the behaviour of these objects

6. End up with an ''Analysis model'' including the results of step 4 & 5 organised into an overall architecture of the system.

DESIGN PHASE:

7. Define the static structures of the system in terms of subsystems, classes and interfaces.
8. Refine the use cases even further into a ''design - use case realization'' which realises the use cases as colaborations between the subsystems, classes and interfaces.
9. Write it all down in a ''design model''

IMPLEMENTATION PHASE:

10. Produce an ''Implementation model'' (code of the application)
11. Produce a ''Deployment model'' which describes how the application must be distributed on hardware (for example for client server systems).
12. Produce a ''Test model'' describing testing of the system


The whole process uses heavy UML and lots of papper work and even include lot of stuff about identifying needed workers (such as ''use case engineer'' and ''architect'') and distributing tasks amongst these workers (which in fact may be an abstraction for a group of people instead of a single person).

I am in no way an expert in this method as I have only self study and very little experience with the "Unified Process". I must admit that I have only worked with the first two phases on a small one-man project (my BSc project). The single class (course?) I took in Object Oriented Analysis and Design unfortunaltely used the before mentioned danish method instead.

Still I hope that this have given you a slight idea of the "Unified Process" and I hope I haven''t frightened you completely by the mention of all this abstraction and papper work. The method is not intended to be followed step-by-step but rather used in a itterative/recursive manner where you critically selects the items valid for your project.

Regards

nicba

heh heh not at all! I''d rather write a design document than spend weeks working with poorly designed code...I mean if you can''t design, how can you code?

Anyway, I''m thinking of writing my own methodology (a simple one, of course ).

Thanks for your help!



- null_pointer
Sabre Multimedia