6 Replies - 3872 Views - Last Post: 14 July 2012 - 11:25 AM

#1 m4l490n  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 3
  • Joined: 01-July 12

UML Help

Posted 01 July 2012 - 07:10 PM

Hi everybody

I'm new at software architecture and I need some help. I'm studying OOP and UML and I'm a bit confused. Once I have all the requirements for a project. How do I start modeling? I mean, which diagram goes first and how is the workflow generally?

Thanks for your help!!

Regards.
Is This A Good Question/Topic? 0
  • +

Replies To: UML Help

#2 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 3579
  • View blog
  • Posts: 11,130
  • Joined: 05-May 12

Re: UML Help

Posted 02 July 2012 - 08:00 AM

Different people have different thinking styles.

Personally, I start with use cases to make sure that I didn't miss any requirements, and then work my way into state diagrams, then the class diagrams, and finally the component and deployment diagrams.

Others start with class diagrams or component diagrams first to partition their N-tier architectures early (and subdivide the work to sub-teams).

My best advice is irregardless which diagram you start with, start high level first, and then on succeeding iterations do more an more details as you go down the levels. This way, if your project gets rushed, you have a general roadmap. (At least for me,) it's easy to get sucked into the minutae if I start with low level diagrams and work my way up to the higher levels.
Was This Post Helpful? 0
  • +
  • -

#3 m4l490n  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 3
  • Joined: 01-July 12

Re: UML Help

Posted 02 July 2012 - 08:51 AM

View PostSkydiver, on 02 July 2012 - 08:00 AM, said:

Different people have different thinking styles.

Personally, I start with use cases to make sure that I didn't miss any requirements, and then work my way into state diagrams, then the class diagrams, and finally the component and deployment diagrams.

Others start with class diagrams or component diagrams first to partition their N-tier architectures early (and subdivide the work to sub-teams).

My best advice is irregardless which diagram you start with, start high level first, and then on succeeding iterations do more an more details as you go down the levels. This way, if your project gets rushed, you have a general roadmap. (At least for me,) it's easy to get sucked into the minutae if I start with low level diagrams and work my way up to the higher levels.


So, there in no order as long as I start from a high level of abstraction? I mean, is not a requirement to start whit an specific diagram and then follow and order?

In your opinion, how would you categorize the diagrams in order from the higher level of abstraction that can be represented to the lower? I think that use cases is the higher and the state chart the lower but I'm not really sure about this
Was This Post Helpful? 0
  • +
  • -

#4 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 3579
  • View blog
  • Posts: 11,130
  • Joined: 05-May 12

Re: UML Help

Posted 02 July 2012 - 09:53 AM

Unless you are creating UML diagrams to satisfy some ISO requirements, or make your manager or teacher happy, or have paid some consultant a couple thousand dollars to teach you how to do it "The Rational Way™" treat UML as tool that helps you think about your project in various dimensions. Only do just enough so that you get clarity on problem. Anymore is busy work. (But if you get paid for it, why not?)

Some purists say that there is a specific order to doing the diagrams, but I tend to take a cynical view of such things. The ones I've listened to in the past put out well oiled demos and pre-planned lesson plans. When I've engaged them in conversation and present a brand new problem they'd not seen before, I see them taking stabs at several diagrams in parallel anyway instead of their blessed order.

As for levels of abstraction, it's the amount of detailed information that goes into the diagram that really determines that. You as the UML designer can go an high or as deep as you please. (I'm sorry for the non-answer.)
Was This Post Helpful? 0
  • +
  • -

#5 DaneAU  Icon User is offline

  • Great::Southern::Land
  • member icon

Reputation: 284
  • View blog
  • Posts: 1,617
  • Joined: 15-May 08

Re: UML Help

Posted 03 July 2012 - 10:59 PM

Definitely start with Use Cases, stick to the core initially then refine your use cases. From that you may be able to extrapolate some distinct objects and start developing up some classes in UML. From then perhaps an activity diagram to model your relationships between objects. You could then perhaps go on to essentially implementing your use cases utilising sequence diagrams to get an idea how everything should come together. Despite the tedium of UML it can help to quickly identify potential issues in a project and it really depends on how your mind best operates and develops an idea as to the order you undertake the planning. There is of course convention, however these things are always reviewed and adapted to suit differing environments and requirements. UML is not unified in my opinion and i rarely see it in a singular use, it can be adapted to so many industries, as such so long as things are clear and make sense other people will be able to interpret ideas graphically.
Was This Post Helpful? 1
  • +
  • -

#6 m4l490n  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 3
  • Joined: 01-July 12

Re: UML Help

Posted 04 July 2012 - 04:29 AM

View PostDaneAU, on 03 July 2012 - 10:59 PM, said:

Definitely start with Use Cases, stick to the core initially then refine your use cases. From that you may be able to extrapolate some distinct objects and start developing up some classes in UML. From then perhaps an activity diagram to model your relationships between objects. You could then perhaps go on to essentially implementing your use cases utilising sequence diagrams to get an idea how everything should come together. Despite the tedium of UML it can help to quickly identify potential issues in a project and it really depends on how your mind best operates and develops an idea as to the order you undertake the planning. There is of course convention, however these things are always reviewed and adapted to suit differing environments and requirements. UML is not unified in my opinion and i rarely see it in a singular use, it can be adapted to so many industries, as such so long as things are clear and make sense other people will be able to interpret ideas graphically.


Thank you very much!! This is something I had thought of but I wasn't really sure. I'm not going to take it as a "recipe" but is a good guidance.
Was This Post Helpful? 0
  • +
  • -

#7 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: UML Help

Posted 14 July 2012 - 11:25 AM

Start with requirements, diagram them with Use cases. Put use case narratives in the use cases (describes formally what the use case does), use activity diagrams to diagram the narratives. Use case scenarios are single paths through use cases, use sequence diagrams to diagram those.

The UML Bible by Tom Pender is a great UML book. Since I have a tech editor credit in it, I'm biased, but it's still a great book. A lot of people like Fowler's UML Distilled, too. I never could follow Fowler very well, personally, but then, a lot of people say the same about me. :)

This post has been edited by BobRodes: 14 July 2012 - 11:28 AM

Was This Post Helpful? 0
  • +
  • -

Page 1 of 1