Hello.
I want to design an application and I don't know where to start. I know I can use UML to design the application, but I don't know the steps I must follow.
I've started doing the UML class diagram, but I suppose, I'm been doing the database model, not the class model for the application.
If I don't explain it well, tell me.
Is there any tutorial about how to design an application?
UPDATE:
I think this is a real question because is beginning of a good software.
Thank you.
There are many, many ways in which to approach the design of an application. Here are three:
For example, You can do it from a "bottom up" Data Driven perspective, as you have started to do so, where you think about the persistent entities first then you'd think about what basic operations you need to carry out on them (the CRUD functions for them), and build these into a data access layer with a family of DAL objects looking after tables, or sets of related tables. (You'll find that the 'Read' functions will gradually change into richer 'Query' functions as you progressively work up the stack.)
Having got these designed, you'll then start to think about the business layer where you start to design families of business objects that implement the operational rules of the application working across groups of the low level entities. You then have a think about the broad services that these business objects might offer to the end-user of the application and design a set of service layer objects that coordinate the activities of the underlying business objects (so you might have business objects that represent customers & accounts and a service that offers a function to transfer money between accounts notifying the associated customer if the balance drops into the red.)
For all of these things, you can draw UML diagrams showing how they interact, but don't get too hung up on it or you can suffer "analysis paralysis". Also, it's best to initially just work to interfaces, rather than concrete objects, giving you the flexibility to decide how to implement them later.
So now, having got your data model, data access layer, business layer and services designed it's "just" a case of putting a presentation layer and user interface layer over it. The UI Layer being just a set of relatively dumb views while objects in the presentation layer are responsible for getting elements from the UI views, maybe doing some syntactical checking on then, then bundling them up for submission to the functions offered by objects in the service layer.
Alternatively, you can opt for a sort of Behaviour Driven approach where essentially you start at the top and work on how the user/customer expects the application to look and behave, thinking about the services that the application will offer them first and how it will be presented to them. You then create services, etc. to support that behaviour - it's sort of recursive with "behaviour" being used to determine the contract between each layer. (I know that this isn't exactly what Dan North's BDD is about...)
Or, you can go for a Domain Driven approach where you design the objects in the domain of the application first, and then work upwards to the UI and downwards to the persistence layer. It's a sort of middle-out way of doing things. If you take this sort of approach you tend to end up with a richer set of objects in the business layer than you might otherwise. You'll find it easier if you've looked at some sort of object-oriented analysis framework such as Rumbaugh OMT or Booch.
In reality, application design become a little bit of a hybrid across all of these, you might start doing a Domain Driven approach initially to get a feel for the scope of the application, then think about how those objects might be persisted so you do a bit of Data Driven design. Then you start to look at how the users might interact with the application (as they want you to show them something now!) so you do some Behaviour Driven development and map the interface down onto the domain objects you've created.
Each way of looking at the application let's you learn a little bit more about how it needs to work and what compromises need to be made in order to deliver a working product on time and to the expected quality.
Alongside all of this, you'll be picking some sort of over-arching architecture for the actual implementation of each layer (which you can find Design Patterns for) and picking an actual working methodology for building them, such as Test Driven Development, which can complement each of the approaches I've mentioned.
Google around for the sort of things I've mentioned and you'll find lot of information. Taking this layered approach to designing applications might seem like a lot of overhead, but it pays off in maintainability for larger applications and even smaller applications can benefit from its principles though more compromises can be made in how layers might combine (for example, the DAL might be combined into the BL by making the domain objects implement the Active Record persistence pattern, which is generally how Ruby on Rails does it).
If your target is an object-oriented application, grab a copy of Craig Larman's "Applying UML and Patterns" from your nearest library. That'll take you through Object-Oriented Analysis and Design for your application. You'll find that there are lots of the things that you can/should consider, even on the specification level alone.
You can create the architecture of your application using UML (e.g classes and interfaces). This can be done with UML diagrams and live code and model synchronization. After this first stage you start to manually code your methods. Finally you add java annotations in your code in order to use a mapper such Hibernate to transform your object java code into a database. I did this java annotation methodology with EclipseUML Omondo. This is really easy and agile because the code is synchronized with the model, as well as java annotations and the database is then generated using Hibernate.
Model, code and database are developed in an incremental way using UML model. This is possible because of live synchronization of java annotation in order to generate the database. The MDD and logic is contained in the java annotation and this is really powerful.