| |
There are many types of UML diagrams available to help database designers do their jobs. These diagrams can be used for capturing requirements, depicting deployment, and everything in between. The different UML diagram types are listed in Table 2-1.
| Diagram | Description |
|---|---|
| Use case | The use case diagram is a model of the system's intended functions and its environment that supports the business processes. This model serves as a contract between the customer and the developers. |
| Interaction | Interaction diagrams are either sequence or collaboration diagrams, both of which show the interaction of objects within the system. They can be used to understand queries that will affect the database and even help build indexes based on the information modeled. |
| Activity | Activity diagrams show the flow of a process. They can be used to show a high-level view of the business and how it operates. |
| Statechart | Statecharts capture the dynamic behavior of the system or objects within the system. |
| Class | Class diagrams are logical models that show the basic structure of the system. |
| Database | The database diagram depicts the structure of the database including tables, columns, constraints, and so on. |
| Component | Component diagrams show the physical storage of the database, including the database management system, tablespaces, and partitions. They can also include applications and their interfaces used to access a database. |
| Deployment | Deployment diagrams show the hardware configuration that is used for the database and applications. |
UML modeling has come into mainstream use through the pathway of object-oriented analysis and design (OOAD), but it can be used for many different types of analysis and design modeling without ever building object-oriented applications. Development of the language was driven by the need to understand object-oriented development and how the architecture of a project affects the outcome. However, don't exclude the use of the UML just because you are not building object-oriented applications梩he UML can be used for basically any type of analysis and design project, whether or not the database or systems are object oriented, even outside of software. An example of this is an auto manufacturer that models the way its cars are assembled, particularly the specifications of the parts that third-party vendors supply. The company uses these UML models for quality control and to provide the models to prospective vendors who are bidding to build a specific part.
Being able to visualize the requirements helps the development team understand more easily and quickly the impacts of changes. Having models like use cases and activity diagrams helps the teams examine such questions as, 揥hat will happen if ???It is much easier for people to understand a quick picture that shows who will do activity x, then y, then z, rather than trying to read numerous paragraphs of text that describe the same information. Textual descriptions can be interpreted differently by the different people who are reading them.
The goal of using the UML for business processes, application development, and database modeling is to tie development teams together and make sure that organizations no longer build enterprise architectures without involving all teams that are important to the process. Building a team that is cross functional with the specific areas of expertise helps create an architecture that can be built and supported by all parties involved. If the different teams work in isolated silos, they eventually lose touch with the rest of the project. In many situations, individuals uncover new requirements, but often this information is not fed back into the overall project. As changes occur throughout the project life cycle, the UML diagrams can be updated so that everyone involved can understand the changes impacting their respective areas.
Sometimes just the diagrams are not enough. Metadata is very important to describe what has been modeled. Making sure, for example, that the word customer means the same to all groups and isn't used in different ways is critical. You need to do a very good job of capturing this ancillary information. Again, this is where having everybody working in one language and notation helps. From the beginning, you can all get together to build the initial requirements and develop an early understanding of what customer means before breaking off into separate teams to begin deeper analysis and design in your specific areas.
Also, with the use of stereotypes, you can extend the UML to fit your needs even more specifically. A stereotype is a UML modeling element that extends the existing elements within the UML metamodel without directly changing the metamodel. Stereotyping a UML element causes it to act as something else, and by acting as that new element it has specific properties. To put it in database terms, for example, consider a table as the base element. When you stereotype it as an entity, this table now behaves as an entity and has attributes instead of columns. However, in the metamodel they are mapped to the same place. You may also add some additional tagged values based on the stereotype, which are then added to the metamodel.
| |