You may not have a great deal of choice. If for example, you are following a method like SSADM, you may have to produce certain models as deliverables. Similarly, if you are following one of the more formal object-oriented methods you will have to produce certain standard models. However, you will still have to make some decisions, and there's nothing to stop you using additional techniques if they give you a useful view on the problem that the standard techniques don't.
Alternatively, you may have much greater freedom over the techniques you employ (or even the method you follow). In this case, you need to be confident that you have chosen an appropriate set of techniques.
The first choice is probably whether to follow the object-oriented route, the data analysis route, or something different. If, for example, you're working in a real-time environment there are specialist methods and techniques which are much more suitable, and I wouldn't presume to try to advise you about them! If you're working in a standard commercial data processing environment, the choices are quite clear:
^ If you're working in an object-oriented development environment, then you will almost certainly use UML and object-oriented analysis (OOA). However, you might decide to supplement it with entity-relationship modelling if you also have to design a back-end database.
^ Even if you're not working in a mainly object-oriented environment, you might want to follow the OOA route. For example, you may have a few central objects with very complex behaviour (such as financial instruments), and you may want to encapsulate their data and processing in order to present a cleaner interface to the outside world. Or you might be working in a client-server environment where different layers of the system will be developed separately. An OOA approach is valid in any of these cases, even if you don't use OO tools.
^ Otherwise, if you're working with standard third or fourth-generation languages and databases, you will probably want to stick to traditional methods of data and functional analysis.
Make sure that you have a set of methods which complement each other. Fve already mentioned the "Three degrees of freedom" for a system's behaviour. You need to make sure that the chosen methods will define the system's functions, data structure, and the way in which the data changes over time or in response to events. There are cases where one or other of these is fairly trivial, but in most cases if s better to be safe than sorry and make sure you have understood all three aspects of the requirements.
You must develop the different views together in a balanced way. If you focus on one dimension to the exclusion of the others you will end up with a very poor design. Take the UML methods as an example:
£ If you record all you know about the business domain in a class model before going through the discipline of use case analysis, this may lead to a very data-centric model. It is better to think first about goals, then object responsibilities, and then the attributes needed to support these,
£ If you focus on use case analysis without developing the class and process models at the same time, you may split the business objects up across lots of small classes with only a few methods each. Such a class model will lead to an inefficient and inflexible design, and more difficult development than necessary.
A related group of techniques (such as UML) provides for cross-checks between the techniques, to ensure that the various views of the system are consistent. For example every message in each scenario should correspond to a method on a class, and every state transition should correspond to a use case scenario. You should also check how each class's state is populated before it is used.
The trick is to get to a reasonable state of completion, then switch to another technique and do a lot of cross-checking, with the aim of finding omissions and going back to update the other diagrams as required. Don't try to get one diagram "perfect" before starting the others: you'll find a situation of diminishing returns where extra effort on the first technique won't deliver much extra detail. Switching to another technique and then applying the effort in cross-checking will be much more productive.
Remember that the models are there to be used - they're not just deliverables you have to crank out to keep the QA people happy. The most important use is to communicate your understanding of the system to each other, and to the users. This means lots of discussion, and using reviews with the intention of checking the detail of the models, and finding errors to correct. Don't try to get the models signed off on the nod by people who don't understand them - this doesn't achieve anything!
If you have access to CASE tools, then start using them early. It s much easier to build, check and modify your models if you use such tools. If you don't have such tools, you must apply standards and change control to keep the paper model under control.
You may have several analysts or architects working on different parts of the system, or you may have interfaces to other systems which are being developed at the same time. If so, you need to make sure that all the work is consistent. To do this, you will build the individual models up into one overall model, under shared or central control.
Was this article helpful?