We are sure that a few of our readers will now give a mental sigh and say, 揊inally, we're getting to the good part梑uilding the system. All that other stuff is fluff.?We do understand that many people feel that way. After all, what we focus on shapes our perceptions. When a mail carrier is delivering the mail, he is 搘orking.?When a carpenter is driving those nails, she is 搘orking.?When a system architect is designing a system, he is 搘orking.?When a coder is coding, she is 搘orking.?So any activity that falls outside their 搘ork?is, by default, 搉ot working?and therefore is perceived to be not valuable or important. Given that these people chose the area in which they wanted to work, not only are these other activities 搉ot work,?they are also perceived as not interesting. Not valuable, not work, not important, not interesting equals not needed.
Not so! You see, you will do all of these activities eventually. You must. It's all part of understanding what the problem is and what you need to do. For example, Bob recalls numerous times when he was working as a programmer when he would stop and think, 揥hat should the system do in this case??If he hadn't been given requirements that specified what to do, he'd think it over, come up with a solution, and continue coding. The system designer hadn't done his job. He hadn't given Bob complete requirements, so Bob had to do the designer's job in addition to his own. If you think that bypassing the preliminary work in favor of a 揜eady. Set. Code!?approach will save you time, you are fooling yourself. You will do this work anyway. It will merely be hidden in with the work for which you are primarily responsible. In other words, your predecessors in the software life cycle have shifted their workload onto your back梐nd they probably didn't give you more time and personnel to handle the extra load. Could this be why the coding phase traditionally consumes the largest amount of time and effort versus any other phase of the software life cycle?
Also, for every ad hoc solution a coder creates because of poor requirements and for every ad hoc solution a system architect creates because of poor understanding of the business user needs, an opportunity is created for more defects to be introduced into the system. Not because the developers are bad but merely because the solution they choose may not be the solution that was desired.
Our goals in analysis and preliminary design are to
Establish a system design that will be able to meet the expressed business needs and requirements
Establish a common blueprint for all members of the development team
One caveat梬e are not going to get into the often heated argument over analysis versus design. Whether you wish to perform analysis and then perform design, or intermix them, or go straight to design, we will leave that choice to you without prejudice. Your development culture, process (if any), project characteristics, and business needs will likely be significant drivers for your decision in this area.
The major artifact that results from this activity will be the class diagrams of the system. The class diagram, which shows the static structure of the system, has always been a key, if not the central, diagram in many UML or object-oriented methodologies. But now, with the advent of using the UML for database design, the class diagram becomes even more important. The class diagram now becomes the common, centerpiece diagram that both the application and database developers will use as the foundation for their designs.
Not only does the class diagram establish the main entities in the system and their relationships with each other but it now also does this for both application and database entities. As both groups work together to establish the system design, the database designers will be able to provide the details needed for the persistent classes in the system, rather than the application designers assuming what data is available. This item is particularly challenging as turnover in personnel affects your projects. Does that new Web developer you hired two weeks ago really understand the Accounts table that exists in your legacy database? Does she understand that you even have a legacy Accounts table?
The often-contentious area of 揵usiness rules?can now be brought into the open via this common model. What implements the business rules梩he applications, separate business logic, or the database? With this shared diagram both application and database developers can see, understand, and establish whose responsibility it is to implement a given rule. With both groups working with the same design, these critical rules can be implemented in the most appropriate, nonconflicting manner.
Having this common blueprint and having a common language (that is, the UML) also facilitates change management. There will come a point when the logical model, represented in class diagrams, is sufficiently developed and then the two teams will separate to complete their respective designs (application and database). Application designers will continue to develop the common class diagrams to sufficient detail that the application can be coded (exactly where the cutover to coding happens is particular to the organization, culture, staff skill level, and so on). The database designers will take the common diagram, once most of the attributes are sufficiently established, and transform it into a data model. They will then continue with their detailed design using this data model. When changes occur (whether driven by the business, the application design, the database design, or other project aspects) the impact can be established on the common class model and then rippled down into both the detailed application and database models more simply since they all use one language. (The UML, as a notation alone, will not be sufficient for systems of any substantial size. A configuration-management system and a change-management system will also be required.)
Not only is there an advantage to using the models to track changes while moving forward but using the same base artifacts from the early requirements through to the analysis phases also helps to ensure that the different teams are using the same information as they move forward. When starting in different environments or not even beginning with a combined requirements phase, it is very likely that you will end up with multiple entities with the same definition or similar entities with very different definitions.
The class diagrams will not stand alone. There should be sequence diagrams to establish or support the class diagrams. These may be new sequences or old sequences that need to be further elaborated. Looking back, the use cases or sequence diagrams that seemed to be sufficient for business modeling or requirements definition may be of insufficient detail for analysis and design. Even they may be revisited and refined. (Not to worry since this is an iterative development cycle.) Also, for more complex behavior, statechart diagrams, activity diagrams, and others may be needed.