3

I am trying to understand OOAD and UML. In this quest I came across some situations in which I felt if either of them are prerequisite for the other item. That is in some situations while reading OOAD i felt I should have prior knowledge of UML and at some situation vice-versa. Instead of keeping this confusion, I am seeking some inputs:

1) Should one first understand what OOAD is before exploring the `UML?

2) what is the relationship between OOAD and UML?

Any answers in simple words would be of great help in coming out of this confusing loop.

CuriousMind
  • 8,301
  • 22
  • 65
  • 134

4 Answers4

4

I would advise you to learn about proper OO before UML. It's more important to know how to do analysis and design properly than it is to know how to adhere to the UML syntax for expressing it. An analogy is that anyone can write a novel using correct syntax, but it will suck. It's hard to write well.

UML is one of many notations, but it happens to have been standardized by both the OMG and by ISO. I first learned from Rumbaugh's book on OMT, which I thought was a better notation, but it's been abandoned now because of the UML standard.

Jim L.
  • 6,177
  • 3
  • 21
  • 47
  • Thanks so much for your inputs.Any easy to understand book (I know OO basics, want to take it to next level) which you can suggest? Thanks again. – CuriousMind May 31 '16 at 06:01
  • 1
    I am biased towards Rumbaugh's Object Oriented Modeling and Design. That was from 1990ish. Other people will have to suggest other books for you, but StackOverflow doesn't tolerate that kind of question, unfortunately. – Jim L. May 31 '16 at 11:49
3

I guess you can do it hand in hand - if you take small steps. I concur with JimL. that you should first learn the basic concept of OO. I know it's hard if you come from a pure functional approach. But even the basic concept of OO is easy to grasp - once you got the right straw to hold on. Now, UML is a very complex beast - like OO would be in all its length and broad. But eating it in small slices, served on tiny UML plates (class notation), you may reach the state of being a connoisseur without getting fat. OOAD finally is just a nice dinner build from knowledge of OO and applying it the right way with a bit of UML.

N.B.: I myself learned OOAD the ICONIX way (you can google them). I found that a most practical approach which helped me a lot. Later I read Bittner/Spence about use cases and found that an even more valuable resource. Requirements (which are actually a fundament of any design) reached me only in a very late state. That wasn't too bad at all since dealing with them is extremely touchy!

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • Thanks so much for your insight on this, appreciate a lot. Do you suggest any easy to understand book on OOAD? – CuriousMind May 31 '16 at 06:00
  • Some 15 years ago, Doug Rosenberg from ICONIX had a very nice video tutorial which did help me a lot. He and his company are still alive, but I don't know whether there is any new material. – qwerty_so May 31 '16 at 08:55
1

I would say you should have a grasp of OO concepts before you try to get to grips with UML. Most importantly, the concept of a class encapsulating data/state and operations.

OO is a way of structuring design and implementation, while UML is a way of documenting both (and other things besides).

While there are aspects of UML which are not particularly object-oriented in their approach (use case and activity diagrams spring to mind), when you get to the implementation side of things you'll find that operations, for instance, can only exist within the context of an element (usually a Class), and that a file is not a fundamental concept but a class is.

So it's hard to document a collection of source code in classic C using out-of-the-box UML. If what you want to document is itself object-oriented, you'll have a much easier time.

Uffe
  • 10,396
  • 1
  • 33
  • 40
0

Well,both UML and OOAD serve different purposes.If you ask me about the priority I would rate more to OOAD rather then UML ,now to your question ,I would suggest you to have a high level idea for UML such as how to represent your class ,how to represent associations in UML ,how to represent composition etc and then give time to OOAD .