Are the steps involved in OOAD well-established? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 11 months ago.

Improve this question

There is a number of books written about OOAD (object-oriented analysis and design). A few of them can probably be considered good books, written by people with a lot of experience in the field.

One could say there is reasonable agreement on what OOAD is, to the point he/she could read a few books and not find (very) disparate elements.

So far on that subject I've read Larman (Applying UML and Patterns: an introduction to OOAD and the iterative process).

It begins with the functional requirements (because the non-functional ones are not the book's focus), then goes on to elaborate the use cases and then models the domain across a number of iterations. Somewhere else I've seen activity diagrams being used at an early stage but maybe they didn't fit the examples mentioned in the book. Also the user interface is not defined early (not the book's focus and is postponed to later iterations).

Can we say:

a) activity diagrams can optionally be used at the early stages of OOAD?

b) user interface is meant to be defined in later stages?

c) are the steps/activities in OOAD mostly well established?

or:

a) the steps are not well established, to the point activities cannot be reasonably defined and applied depending on the necessity.

Answer 1

The terms OOA and OOD were created at the beginning of the 1990s, with the (debateable) mindset of having separate "phases" analysis, design and implemention in the development process, and the idea of "extending" object orientation from the "implementation phase" to the "former phases". Peter Coad and Edward Yourdon wrote two books about it with exactly those titles "Object Oriented Analysis" and "Object Oriented Design". You will find an introduction to their ideas here. These methods tried to distinguish themselves from older techniques like structured analysis.

OOA and OOD describe tools for making analysis and design with OO means (like objects & classes, attributes & associations), but not the order in which they are applied. The way I understand these terms they are quite orthogonal to the specific software development process (like waterfall model, iterative model, spiral model).

At the time when the terms were becoming popular, there were some competing graphical notations for modeling classes and business processes. This lead finally to the UML standard. I am pretty sure today the terms "OOA/OOD" will be used synonymously to "doing analysis/design using UML" by most people.

Now, when does one make a certain analysis or design activity during a development (like scetching an UI, or drawing an activity diagram)? That depends on

• what the development process model dictates (at least in a waterfall model)

• what makes sense for the specific kind of software and/or the specific iteration (in some reasonable development model)

but it does not depend on if you are using OO and/or UML means for this.

Let me give some examples:

• when you are creating a new version of a software where the only task is to implement a new "coorporate look" at the UI, your first and foremost analysis activitiy will be to create the new UI, nothing else.

• when you design a software like a specific purpose library without any user interface, the question of when to apply the activity "user interface design" is pointless.

• when you have build a system over a certain time period in several iterations, and for the last iteration it will be necessary to change some behaviour in the order in which some files are processes, and you think an activity diagram is well suited to describe this change, then you will use this kind of diagram at a very late phase of your development. An UI design will probably not be necessary here.

So "Object Oriented Analysis and Design" is not a process model, but it is nethertheless reasonably defined (at least, to some degree - surely they are differences between different authors). And software development (object oriented or not) is not like a conveyor-belt process where you just

• shovel some requirements into,

• follow a step-by-step-list in a fixed oorder like "first draw an activity diagram, then scetch an UI, then make a class diagram, then write some code"

to finally get some business application as a result. It is activity where you need to use your brain and think what steps makes most sense next, for your current situation.