Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am starting a big database-oriented software project to develop. I have full picture of the software in mind. I need to do the designing using UML. As there are various tools in UML such as usecase, class diagram, statechart, component diagram, deployment diagram, activity diagram and so on, where should I start my designing. Should it be from Usecase or from Class Diagram, or from State Chart? Which approach will help me to put my mind's picture in to design?

share|improve this question

closed as too broad by gnat, Kilian Foth, MichaelT, Dan Pichelman, jwenting Aug 20 '14 at 12:34

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Do you have a requirements spec? If it's DB related, why not an E-R diagram? – a1210 Mar 31 '12 at 13:24
I have only the abstraction of the high level of the complete system. Need to discover the internal process and objects. – Muneer Mar 31 '12 at 13:27
recommended reading: Where to start? – gnat Aug 20 '14 at 6:16
up vote 3 down vote accepted

When you state that you have the full picture of the software in mind, do you actually mean you're keeping all of the ideas in your head, or have you actually sat down and created a requirements document.

It's been my experience that when you start worrying about your database before you've got all of your ideas out on the table, you're going to risk creating scheduling bottlenecks and redesign problems later on.

Where to start in terms of analysis and design should be to list all of the key features of your system. You don't need to go into the absolute finest detail at first. It doesn't really matter how well defined your features are to start with, but you do need to have an idea of the overall scope of your project. You need to understand what the problem is that you are trying to solve, and you need to determine which features are crucial to the success of your project. Once you have this, you can set a few priorities, and start to break down complex features into a more simplified set of features, and then perhaps prioritize those also. Each level you drill down will provide you with opportunities to learn more about the overall architectural shape your product is likely to take.

So what about the database? Well, with your requirements specification available to you, even in a rough form you will have a better idea of the type of data storage you might need. Will a simple text file do, or will you need a full relational database, or something in between? Will an N-Tier model be more appropriate or will a local database suffice? The point that I am trying to make here is that the requirements gathering exercise provides you with a great opportunity to raise the questions that you really should be asking up front, before committing yourself to a major decision that could cost you big later on, and more importantly, it allows you to prioritize the questions themselves, so that you can defer some of the big decisions for as long as possible, so that you only need to commit when you have all of the answers, and not before you're completely ready to answer them.

It may be that you can write your software, and mock out all of your data access requirements. Once you have established the design of your software, and possibly even coded most of the really important features, then you will be in a better position to decide what the shape of your database might be, and you'll be in a position to do so without second-guessing an earlier decision.

Asking questions about the problem domain and about the features and their priorities is really what you are doing when you say your are doing the analysis. The design takes shape as a result of answering these questions and defining your list of features, their priorities, and determining the relationship between the features themselves. It is from all of this that you would want to develop your UML and ER diagrams if you are so inclined, or you could opt to build everything based on the outcome of your requirements gathering and use a tool to generate your UML/ERD's after the fact, to capture the state of your finished product.

If it were me, I would focus on a higher-level view when diagramming. Start with your use cases, and work down to your class/state/entity diagrams, then use Sequence diagrams to explain difficult to picture processes in greater detail. There is usually no need to diagram your project in it's entirety. The effort required to maintain these diagrams can be very expensive as your software changes over time, so you want to be able to present your best "big picture" overview such that if your design does need to change, your documentation effort is kept to a minimum, while still giving a good impression about what it is that your software does.

share|improve this answer
+1 for promoting analysis. – NoChance Apr 1 '12 at 10:19
well, what I mean by "I have the full picture of the software in mind" is all about "I have understand the requirement & scope". It is not mean that I have created the requirement document. Ok, What I am familiar to do is drawing the UseCase diagram first. It seems easy for me to find out the interaction between the system and human. Then I am confused,, how to go deep into the system from that UseCase. Here only I am getting sucked, which make me think that, my starting point is right or wrong? – Muneer Apr 1 '12 at 12:37
What often happens when you start with a diagram is that you usually capture an idea about architecture, but fail to account for behaviours. You get halfway through your coding based on your diagram, and then realize that something needs to change. Because you have committed too early to an incomplete idea, you end up having to redo your diagrams, and refactoring your code. So yes, I would say that your starting point shouldn't be the diagram, but should be to commit your understanding of requirement and scope to documentation first, as per the answer I posted. :-) – S.Robins Apr 1 '12 at 21:35

Seems you don't want to know "where to start", but what UML tools to use. For a high level modeling of processes, I would recommend to start with use cases and data flow. Use cases can be modeled obviously by using UML use case diagrams. For data flow, UML misses good tools, but I would not hesitate to use some kind of data flow diagram even it is not UML.

Class diagrams and state diagrams are most often more useful on a lower level of abstraction.

share|improve this answer

I'd suggest -

  1. Component diagram - This will help isolate logically independent functional blocks.

  2. Use case diagrams and activity diagrams - To get idea of which modules 'play' in certain use-case. This will also help identify layers if any. (e.g. Modules A, B, C require help from D to create useful information for E. So D stands on lowest layer, then A,B,C and then E.)

  3. Sequence diagrams and State machine diagram - These are helpful in many ways.
    To find out what all services components require from each other;which helps outline APIs between components.
    To rearrange functional components if required.
    To identify state machine.

Then components can be individually dealt with using class diagrams and so on.

Diagrams definitions as per wiki

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.