Seldom are object relationships a 1 to 1 style. We need to denote when relationships have creation constraints that dictate the quantity of objects. In UML this is called multiplicity. Multiplicity is used to define the creation constraints that may exist between objects. Multiplicity is denoted on the connector adjacent to the object with the constraint.

Let’s see some examples.

In the image below (figure 1), we have building and door objects. Note the 1 adjacent next to the building object. This states that there must be 1 building object. The multiplicity values next to the door object state that the building can have 1 to many doors. The 1 depicts that it must have at least 1 door but the asterisk gives the possibility of having more than the 1 door. Had we not listed the 1, the asterisk alone would have given the possibility of 0 doors.

Figure 1

In figure 2 below, we now have deck and card objects. The 1 beside the deck tells us that there is only 1 deck and the 52, 54 next to the card object says that the deck object can only contain either 52 or 54 cards. Since the values are explicitly listed there is limited flexibility in the number of cards allowed in a deck. When two values are listed they are generally separated by “..”. Had we used a “-“ this would have denoted a range and allowed the possibility of 53 cards.

Figure 2

In figure 3, we extend the number of possible number of objects. We added comma separated values to denote a series of possible values. Our single truck object can contain one of four different wheel quantities.

Figure 3

Multiplicity allows us to display the constraints that exist between objects in a standard manner. In the absence of any multiplicity value it is assumed that the object can exist 0 to infinity times within the application.

I recently gave a presentation to the Little Rock .Net Users Group on Unified Modeling Language. This presentation covered the Use Case and Class Diagram models. I will most likely give future presentations on other UML models.

UML Presentation Slides

Now that the objects (classes) are created it is now time to define how each object relates to other objects. UML uses lines to connect related objects. These lines or connectors tell us a great deal of information on these related classes.

In the image below (Figure 1) we can see some of the different connector and their meaning.

Figure 1

Simple Relationship

In the simple relationship the objects are aware of each other but not dependent on each other. In the image below (Figure 2) the Man class knows about the Woman class and vise versa.

Figure 2

A relationship exists. However each class could exist without the other class.

Aggregated Relationship

In an aggregated relationship one class has the other class but the second class can exists without the first class. In figure 3, the car class has the wheel class but the wheel class does not require the car class to exist.

Figure 3

Composite Relationship

The composite relationship is similar to the aggregated relationship but in a composite relationship the second class cannot exist without the first class. In the image below (Figure 4) the company class consists of the department class but the department class cannot exist with the company class.

Figure 4

Inherited Relationship

The inherited relationship denotes the hierarchy of the classes. The second class is derived from the first class. In figure 5 the  checking account inherits the properties of the bank account.

Figure 5

Interface Relationship

This relationship indicates that the second class properties are driven by the first class. However the first class is only a template for the second class and the second class provides the functionality. In this case (Figure 6) person dictates the properties of student without implementing any itself.

Figure 6

Adding the relationship information to the classes we begin to see how to code the class arrangements in a logical order. In the next entry we will add even more detail to the relationships.

UML provides a very structured way to describe objects within an application.

A class model is a square diagram that displays the properties and methods of a given object. The layout of the class model helps the developer understands the different aspects of the object. In the Basic class model below (Figure 1)

Figure 1

The class model is divided into 3 sections. The top section is the name of the object. The middle section denotes the object properties and the bottom section defines the object’s methods.

Suppose our application is in need of a person object. What person properties would we need to implement? Most likely our person object would need to have a first and last name, birthday, title, etc. These properties of our object are now added to the class model (Figure 2)

Figure 2

The properties defined within the class model follow a structured format. This format allows the designer to specify name, type, visibility scope of each property. (Figure 3)

Figure 3

As we continue to work with the person class model we can add any methods for our object. (Figure 4)

Figure 4

The methods defined within the class model also follow a structured format. This format allows the designer to specify name, parameters, return type (if needed), and visibility scope of each property. (Figure 5)

Figure 5

The class diagram when completed can easily be turned into code. The beauty of class diagram is that all of the planning and design work is already done. Almost any developer of moderate skill and who understands UML can code the class about as fast as the person can type. Below is the representation of the class in visual basic.

Public Class Person

    Private _HadChanged As Boolean

    Private _firstName As String
    Public Property FirstName() As String
        Get
            Return _firstName
        End Get
        Set(ByVal Value As String)
            _firstName = Value
        End Set
    End Property

    Private _lastName As String
    Public Property LastName() As String
        Get
            Return _lastName
        End Get
        Set(ByVal Value As String)
            _lastName = Value
        End Set
    End Property

    Private _birthDate As Date
    Public Property BirthDate() As Date
        Get
            Return _birthDate
        End Get
        Set(ByVal Value As Date)
            _birthDate = Value
        End Set
    End Property

    Public Function Age() As Integer

    End Function

    Public Sub New(ByVal FirstName As String, ByVal LastName As String, ByVal Birthdate As Date)

    End Sub

End Class

With the class already defined it is a simple matter to code the class in the language of choice. While the developer would still need to flesh out the code for the methods the planning is already completed. Such is the goal of UML.

Key elements in a use case diagram

• Actors – A person, system, organization or external source that interacts with your software. These are depicted as a “stick person” within the diagram regardless of the actual source type.
• Use Cases – These are the actions performed. These are depicted as an ellipse.
• Associations – These are the interactions between the actor and the use case.  These are depicted as a solid line connecting the actor and the use case. However there are certain situation where the association may connect two actors or two use cases.

We will use the process of creating a bank account to demonstrate the use case diagram. See figure 1.

Figure 1

Actors are generally referred to by nouns (i.e. Customer, Dealer, etc. ) and a use case are described by verbs/actions (i.e. Open Account, Sells Car, etc.) . When combined with the associations these become “sentences” describing an action. (i.e. “Customer Opens Account”,  “Dealer Sells Car”). When viewing a use case diagram each association is read to give the developer an idea of the actions depicted in the use case.

In the use case example (figure 1) we can read the actions in the diagram and help determine what may be needed within our software to accomplish these actions.

Also depicted in our use case diagram is the arrow association between the customer actor and the open account use case. This arrow denotes the create account association must take place before the other “non arrowed” associations can be utilized. A use case generally only has one of these types of associations, if at all, in a use case diagram.

A use case on one diagram may be detailed on another use case. Such as the open account use case on this diagram may have its actions detailed on another use case diagram. An application may have dozens or even hundreds of use case diagrams describing the actions at varying detail of a given software application.

In construction, before concrete is laid, materials are ordered or even cost estimates there is a plan. A set of documents outlining the complete construction process are created and reviewed. These documents are created in a very standard way and because of the standardization, a construction worker can walk onto a construction site review these documents and become instantly productive. 

As developers we need methods of conveying behaviors, problems and solutions within our code in the same standard way as in construction. UML was designed to address that need. UML makes its easy for others to collaborate even if they did not attend any of the planning meetings or have talked with a single user. I guarantee that if spend the time necessary to learn and then implement the UML design process you will be a better developer.  

What is UML?

UML (Unified Modeling Language) is a standard way of visualizing and documenting software design. In my opinion, it is absolutely crucial component of any moderately complex object oriented design process. UML can help developers communicate and conceptualize the code without specifying or even knowing the language the development code.

Advantages

• Provides a visual model the development code
• Independent of the final development language
• Allows developers familiar in UML to understand application process
• Forces a more complete planning process prior to coding

Disadvantages

• Can take time to learn
• Takes time to implement

UML consist of several diagrams used to express the application in different perspectives. These diagrams are:

• Use Case Diagram – Displays the relationship between the application and internal/external interaction
• Class Diagram – Displays the classes and objects of the application and thier relationship to each other
• Sequence Diagram – Displays the sequence of of objects based on time.
• State Diagram – Displays the different states that an object becomes during its life

There are other diagrams within UML but these are the most common and in this series we will discuss and implement each of these diagrams.

No one knows everything.

This is especially true in programming. With technology and techniques changing so fast it is impossible to be expert in everything. However, as programmers, we are expected to at least know about new technology. Being at least familiar with technology gives options you might not have had when asked to provide a solution.

Joining a user group can help.

Most user groups meet once a month in the evening for a few hours and provide presentations related to programming. Sometimes the presentations are presented by the members of the group who want to share experiences and techniques while others may be presented by experts/authors in the field. If you begin attending meetings regularly I guarantee you will learn something new and be a better programmer because of it.

User groups are free, provide food, and allow you the opportunity to meet other programmers. Establishing these types of connections with other programmers can payoff tremendously when you need to bounce an idea or have a problem and would like other input.

Sound good?

To locate a user group near you please visit INETA (International .Net Association) and click on the user group tab.

Whether you are an expert or novice or somewhere in between, I cannot emphasize benefits of joining and participating in a user group.

If you have worked with SQL databases any length of time, you have certainly had to make your share of schema changes to meet the needs of your software.  And since you are ever diligent in protecting your data from corruptions you utilize stored procedures to perform CRUD (Create Read Update Delete) methods on your data.Occasionally, I make changes to my table schemas to keep the balance between normalization and accessibility. This can lead to a problem.

I can have several hundred stored procedures and views in a good size database. Which of these utilize the table I am about to change? How can I be sure the table or view I am about to drop is not being utilized somewhere?

Fortunately, there is a solution.

The query below utilizes the Information_Schema which maintains the meta-data or data dictionary about the database.  The “routines” section maintains the information regarding stored procedures.

Select ROUTINE_NAME, ROUTINE_DEFINITION
From INFORMATION_SCHEMA.ROUTINES
Where ROUTINE_DEFINITION LIKE ‘%myTable%’
AND ROUTINE_TYPE=’PROCEDURE’

Replace myTable with the desired table to reference and the result will contain every stored procedure
To perform the same search against views run the following:

Select TABLE_NAME, VIEW_DEFINITION
From INFORMATION_SCHEMA.VIEWS
Where VIEW_DEFINITION LIKE ‘%myTable%’

Again, replace myTable with the desire table.

Any time I begin any database design changes I keep these handy.

 I hope you find them as useful.

My name is Larry Taylor and I am software developer consultant in central Arkansas.

I have been programming for about 20 years and been consulting for almost half that time.

In this blog I will detail some of the tips, tricks and thoughts I have learned in the developer consulting business. I hope you find them useful.