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?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
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.
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.
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.
I'd suggest -
Then components can be individually dealt with using class diagrams and so on.
Diagrams definitions as per wiki