How Can I Leverage UML Models Created by Others?

Database designers can take advantage of the benefits of UML, even if they are using something else to model their databases, because they can draw on the models created by others on the development team to understand the overall system that is being built.

UML models that you have seen previously in this book (and will continue to see through to the end) describe the things needed to build a well-architected system. The database designers can jump-start their database designs and ensure a common understanding amongst the team by taking advantage of other team members' work with the UML.

From the Real World—Taking Off with a Common Understanding A large airline organization needed to ensure that the people building their systems all were on the same page. They had business analysts gathering information about the business and modeling it. They had architects building application designs, developers acting on the designs by writing software, data analysts designing the logical and first cut physical database designs, and database administrators realizing the database design in code. However, each team had a different manager, and they weren't communicating with each other regarding what their teams were doing. This often resulted in architectures that had to be reworked late in the game. They first realized the problem when they were trying to integrate systems but were using different terms in different ways, including calling entities one thing in the database and something different in the application code. My first visit proved to be quite interesting. This multi-billion dollar airline was building software to run their business and was beginning to figure out the best way to communicate across teams involved in the software and system creation process. They recognized that the problems they were having stemmed very much from a lack of communication—not in terms of talking, but in terms of failing to work together to create the designs. They decided to combine the organizations and create a group that reported to the same management structure. They felt that by ensuring that all the teams were under the same management, the teams would be much more likely to work together. Next, they formed teams that included all the stakeholders in a project to work through the initial requirements together. Don't take this the wrong way. There weren't 50 people on these teams. Each group had representation so that the business, development, architecture, and data teams were all now working together in small, manageable teams that could work effectively with five or six people. These teams were responsible for creating the system requirements, including a common dictionary they called their conceptual data dictionary. They used the UML to define much of the work they were doing together so that everyone had a common language with which to communicate. The data analysts still used one of the non-UML notations for building the data models, but they all shared the rest in common. They really started to see the value when newer systems were being brought online and they didn't have to worry if in one system “agent” meant travel agent and in another it meant gate agent. Because they were working against a common set of requirements and using these common models to share information about the architecture, the teams knew that there were many types of agents, and if they were to use one in a design, they knew its meaning. This was the first time in a long time that I saw database teams working together with others to design a common architecture for an organization. They brought the different groups together to create a team that could understand the business' intentions to avoid conflicting solutions within the project.

Lessons Learned Common language leads to common understanding. Sometimes, even though you are working toward a common goal, if the organizations trying to achieve it are different, the organizations' structure can get in the way. When building a system, working together as a cross-functional team greatly increases the possibilities of success because you're sharing information and, maybe even more importantly, you're resolving the problems together.

We are not going to rehash all that you have read in the previous chapters about the different types of models. Instead, we'll provide some additional insight on how the models can be leveraged in your database designs.

Use Case Models

To start with, many organizations take advantage of use cases and actors as discussed in Chapter 2, “Business Models.” Use cases describe how the system will work, and actors are used to model people and systems that interact with the use cases. In this chapter, we will focus on these elements as they are used in the creation of database designs. Use case and business use case models can be very valuable to the data architects (database designers) to understand more about the data that will need to be captured and how they might optimize it based on who will access it and how.

As a designer of the database, you can get your first look into the initial components of a conceptual data model by using use cases. Even at this early point, you can see from the business use case model in Figure 6-4 that things such as Clinical Records, Residents, Physicians, and Accountants are important parts of the system. Based on this information, you can determine which things are needed in the logical data model when you are ready to design at the logical level.

Some access and processing information is also available—from the diagram, it's clear that the External Facility and Transport Service have access to the Clinical Records. [NAIB1]

Activity Models

Activity diagrams, which were initially discussed in Chapter 2, display the actual flows represented in the use case. They go into deeper detail on how the flow of the system will work. They use swimlanes (the vertical and sometimes horizontal lines) to help you understand who or what is responsible for performing the activity. When you understand the responsibilities, you can then use that information to determine classes you will need to capture as logical data elements. The things defined by swimlanes often require data to be captured when the system is put into place.

The activity diagram shown in Figure 6-5 provides more insight to the conceptual data. We now see that the External Care Provider can review (read), update, and return (send) the Clinical Records. The Facility Staff can provide (send) and receive the Clinical Records.

In Figure 6-6, the activity diagram demonstrates how we can find new conceptual data—Billing Records and Reimbursement Records. Also, note that eligibility might be a possible attribute of a treatment (another candidate data entity). As before, we also see which business actors can manipulate this data, providing additional insight on how to design the database for the best performance and usage. [NAIB2]

The activity diagram is often thought of as just showing the workflow, but as you can see in Figure 6-6, you can also use it to gain a greater understanding of how the system will be used and of the different entities that will be needed as the system evolves. Using structures such as swimlanes, the activity diagram provides the first set of elements needed to describe a complete logical database diagram. Yes, you can build a database design, either logical or physical, without use case and activity diagrams, but having them will help. Many of your organizations are already creating these diagrams, and the diagrams can help you build better database designs, so why not take advantage of them? Use these models to enhance your understanding of the overall system being created and what other team members have already discovered.

Class Models

Class diagrams and the elements used within them were introduced in Chapter 4 when we began talking about architecture. The database designers can leverage class models created by architects and developers to understand what the architecture of the application will look like and how they might translate the models into the logical data models. A database designer can also use the class models to create his own conceptual, logical, and physical data models. We will look closer at the data models later in this chapter. In this section, we will briefly cover how to take advantage of those models already created by others.

Class models are created by architects to design application architectures and by developers to visualize the pieces of the applications they are developing and the parts others have created so that they understand how to integrate with them. As described in Chapter 4, the architect will capture the designs of the application at a higher level, but these designs play very nicely into the creation of the conceptual and logical data models. Having the higher-level models provides the database team with guidance concerning entities and information about the data that they are going to need to capture.

Class diagrams created by developers show the planned and actual structure of the application. These diagrams show the business logic that will be implemented through the application class structures and the ways the application should interface with other software and the database. Database designers can take advantage of these diagrams to gain knowledge about how to implement business rules within the database and how to architect the database to best provide application access, and to ensure that the database provides the data storage for all the information to be supplied by the application.

All in all, being able to leverage information that's used by other teams will provide a database designer with additional input to building the database. A lot of work goes into building an overall system, and anything that can be shared will provide open communication among the team to help ensure that they are all working in a consistent direction. It isn't necessary that all the database designers be working in the UML, but having the team understand the UML will enable them to communicate with other teams about work that they have already done.