UML DESIGNING

1

UML Overview

Introduction

Modeling is an activity that has been carried out over the years in software development. When writing applications by using the simplest languages to the most powerful and complex languages, you still need to model. Modeling can be as straightforward as drawing a flowchart listing the steps carried out by an application. Why do we use modeling? Defining a model makes it easier to break up a complex application or a huge system into simple, discrete pieces that can be individually studied. We can focus more easily on the smaller parts of a system and then understand the "big picture." Hence, the reasons behind modeling can be summed up in two words:

Readability Reusability

Readability brings clarity—ease of understanding. Understanding a system is the first step in either building or enhancing a system. This involves knowing what a system is made up of, how it behaves, and so forth. Modeling a system ensures that it becomes readable and, most importantly, easy to document. Depicting a system to make it readable involves capturing the structure of a system and the behavior of the system.

Reusability is the byproduct of making a system readable. After a system has been modeled to make it easy to understand, we tend to identify similarities or redundancy, be they in terms of functionality, features, or structure.

Even though there are many techniques and tools for modeling, in this article series, we will be concerning ourselves with modeling object-oriented systems and applications using the Unified Modeling Language. The Unified Modeling Language, or UML, as it is popularly known by its TLA (three-letter acronym!), is the language that can be used to model systems and make them readable. This essentially means that UML provides the ability to capture the characteristics of a system by using notations. UML provides a wide array of simple, easy to understand notations for documenting systems based on the object-oriented design principles. These notations are called the nine diagrams of UML.

So the question arises, Why is UML the preferred option that should be used for modeling? Well, the answer lies in one word: "standardization!" Different languages have been used for depicting systems using object-oriented methodology. The prominent among these were the Rumbaugh methodology, the Booch methodology, and the Jacobson methodology. The problem was that, although each methodology had its advantages, they were essentially disparate. Hence, if you had to work on different projects that used any of these methodologies, you had to be well versed with each of these methodologies. A very tall order indeed! The Unified Modeling Language is just that. It "unifies" the design principles of each of these methodologies into a single, standard, language that can be easily applied across the board for all object-oriented systems. But, unlike the different methodologies that tended more to the design and detailed design of systems, UML spans the realm of requirements, analysis, and design and, uniquely, implementation as well. The beauty of UML lies in the fact that any of the nine diagrams of UML can be used on an incremental basis as the need arises. For example, if you need to model requirements for a given system, you can use the use case diagrams only without using the other diagrams in UML. Considering all these reasons, it is no wonder that UML is considered "the" language of choice.UML does not have any dependencies with respect to any technologies or languages. This implies that you can use UML to model applications and systems based on either of

2

the current hot technologies; for example, J2EE and .NET. Every effort has been made to keep UML as a clear and concise modeling language without being tied down to any technologies.

This series aims to cover the basics of UML, including each of the nine diagrams of UML. In addition, you will get to learn about the tools available that support UML. At the end of each article, we will incrementally build each of the nine UML diagrams for a case study system in the coming weeks. We will wrap our study of UML by expanding into two different areas—Rational Unified Process and Design Patterns.

UML Diagrams

The underlying premise of UML is that no one diagram can capture the different elements of a system in its entirety. Hence, UML is made up of nine diagrams that can be used to model a system at different points of time in the software life cycle of a system. The nine UML diagrams are:

Use case diagram: The use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The use case diagram shows which actors interact with each use case.

Class diagram: The class diagram is used to refine the use case diagram and define a detailed design of the system. The class diagram classifies the actors defined in the use case diagram into a set of interrelated classes. The relationship or association between the classes can be either an "is-a" or "has-a" relationship. Each class in the class diagram may be capable of providing certain functionalities. These functionalities provided by the class are termed "methods" of the class. Apart from this, each class may have certain "attributes" that uniquely identify the class.

Object diagram: The object diagram is a special kind of class diagram. An object is an instance of a class. This essentially means that an object represents the state of a class at a given point of time while the system is running. The object diagram captures the state of different classes in the system and their relationships or associations at a given point of time.

State diagram: A state diagram, as the name suggests, represents the different states that objects in the system undergo during their life cycle. Objects in the system change states in response to events. In addition to this, a state diagram also captures the transition of the object's state from an initial state to a final state in response to events affecting the system.

Activity diagram: The process flows in the system are captured in the activity diagram. Similar to a state diagram, an activity diagram also consists of activities, actions, transitions, initial and final states, and guard conditions.

Sequence diagram: A sequence diagram represents the interaction between different objects in the system. The important aspect of a sequence diagram is that it is time-ordered. This means that the exact sequence of the interactions between the objects is represented step by step. Different objects in the sequence diagram interact with each other by passing "messages".

Collaboration diagram: A collaboration diagram groups together the interactions between different objects. The interactions are listed as numbered interactions

3

that help to trace the sequence of the interactions. The collaboration diagram helps to identify all the possible interactions that each object has with other objects.

Component diagram: The component diagram represents the high-level parts that make up the system. This diagram depicts, at a high level, what components form part of the system and how they are interrelated. A component diagram depicts the components culled after the system has undergone the development or construction phase.

Deployment diagram: The deployment diagram captures the configuration of the runtime elements of the application. This diagram is by far most useful when a system is built and ready to be deployed.

Now that we have an idea of the different UML diagrams, let us see if we can somehow group together these diagrams to enable us to further understand how to use them.

UML Diagram Classification—Static, Dynamic, and Implementation

A software system can be said to have two distinct characteristics: a structural, "static" part and a behavioral, "dynamic" part. In addition to these two characteristics, an additional characteristic that a software system possesses is related to implementation. Before we categorize UML diagrams into each of these three characteristics, let us take a quick look at exactly what these characteristics are.

Static: The static characteristic of a system is essentially the structural aspect of the system. The static characteristics define what parts the system is made up of.

Dynamic: The behavioral features of a system; for example, the ways a system behaves in response to certain events or actions are the dynamic characteristics of a system.

Implementation: The implementation characteristic of a system is an entirely new feature that describes the different elements required for deploying a system.

The UML diagrams that fall under each of these categories are:

Static

o Use case diagramo Class diagram

Dynamic

o Object diagramo State diagramo Activity diagramo Sequence diagramo Collaboration diagram

4

Implementation

o Component diagramo Deployment diagram

Finally, let us take a look at the 4+1 view of UML diagrams.

4+1 View of UML Diagrams

Considering that the UML diagrams can be used in different stages in the life cycle of a system, let us take a look at the "4+1 view" of UML diagrams. The 4+1 view offers a different perspective to classify and apply UML diagrams. The 4+1 view is essentially how a system can be viewed from a software life cycle perspective. Each of these views represents how a system can be modeled. This will enable us to understand where exactly the UML diagrams fit in and their applicability.

These different views are:

Design View: The design view of a system is the structural view of the system. This gives an idea of what a given system is made up of. Class diagrams and object diagrams form the design view of the system.

Process View: The dynamic behavior of a system can be seen using the process view. The different diagrams such as the state diagram, activity diagram, sequence diagram, and collaboration diagram are used in this view.

Component View: Next, you have the component view that shows the grouped modules of a given system modeled using the component diagram.

Deployment View: The deployment diagram of UML is used to identify the deployment modules for a given system. This is the deployment view of the

Use case View: Finally, we have the use case view. Use case diagrams of UML are used to view a system from this perspective as a set of discrete activities or transactions.

Summary

In the first article of this series, we took a quick background at what UML is and where it fits in the overall software life cycle. Each of the nine diagrams that make up UML will be covered step by step in the coming weeks. Before we start with our study of each of these nine diagrams, we will take a look at what UML tools are available in the market in the next article.

5

UML Tools

By Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy

In the previous article, we gained an overview of what the Unified Modeling Language stands for and what are the nine diagrams that make up UML. Because UML is essentially a set of diagrams, you can simply draw them by hand on a piece of paper. But, drawing UML diagrams on a piece of paper is certainly not a best practice to design systems. Software applications simplify the task of drawing diagrams of software designs. In addition, because the design is in an electronic format, archiving the design for future use, collaborating on the design becomes much easier. Also, routine tasks can be automated by using a UML tool. Hence, using a UML tool is by far the most preferred way for designing software applications.

Features in UML Tools

This takes us to an important question—what exactly should we look for in a UML tool?

Because the primary use of a UML tool is to enable you to draw diagrams, first and foremost, we need to see what types of UML diagrams the tool supports. But, is drawing UML diagrams all that you would expect from a UML tool? For example, wouldn't it be great if the class diagrams that you draw in the tool can somehow be used to generate the source code for actual Java classes or C++ classes?

Let us take a look at another scenario. Suppose you were given a large set of source code files with lots and lots of classes. Wouldn't it be a nightmare wading through the code trying to figure out how all the classes are interconnected? This is where UML tools step in to make things a lot easier by providing support for such features. Now, let's define these features in technical terms:

UML diagram support: The UML tool should support all the nine diagrams that make up UML. You should look for a tool that supports drawing use cases, designing the static view diagrams such as class diagrams and object diagrams, defining the dynamic view diagrams such as sequence, activity, state, and collaboration diagrams and the component and deployment diagrams that form the implementation view of the system.

Forward engineering: A UML tool should not have its use limited to just a pictorial depiction of diagrams. Because the structure of the system defined by the diagram is translated by a developer into actual source code (classes), the UML tool should bridge this step by generating the source code of the classes with the methods stubbed out. Developers can take up this stub code and fill in with the actual code. This characteristic of automating the generation of source code is called forward engineering. Forward engineering support by a UML tool is normally for a specific language or a set of languages. If you are a Java developer, verify that the UML tool that you want to use has forward engineering support for Java. Similarly, if you are a C++ developer, the UML tool should provide you forward engineering support for C++.

Reverse engineering: Reverse engineering is exactly the opposite of forward engineering. In reverse engineering, the UML tool loads all the files of the application/system, identifies dependencies between the various classes, and essentially reconstructs the entire application structure along with all the relationships between the classes. Reverse engineering is a feature normally provided by sophisticated and high-end UML tools.

6

Round-trip engineering: Another useful feature apart from forward and reverse engineering is round-trip engineering. Forward and reverse engineering are essentially one-off activities that take input and generate the required output. Round-trip engineering extends these features.

An important rule in software design is that no design remains unchanged. This is as true for small systems as it is for large systems. During development, the design structure defined in the UML model does undergo changes to incorporate physical differences in implementation that may not have been envisaged during design. It becomes very difficult to keep the design of the system updated with the changes in the source code. The round-trip engineering feature enables the UML tool to synchronize the model with the changes in the application code.

Documentation: Documentation is an integral aspect of a UML tool. Software designing, by nature, is an abstract process. Apart from a few syntax and semantic ground rules, there are no other rules. The thought process of a software architect who designs applications using UML can be lost if the reasons behind certain design decisions are not captured and well documented. This becomes painfully clear when large systems are maintained and no one has a clue to why a subsystem was designed in a certain way. Hence, a UML tool must necessarily provide some way for the designer to document design decisions in the diagrams by using simple things such as annotations or comments. In addition to this, the UML tool should support the generation of reports/listings of the different design elements of the diagram.

Apart from the above features, you should also identify a few features that would definitely be useful to have in the UML tool.

Version control: A very important feature that we want to have in the UML tool is either an integrated version control mechanism or connectivity to a standard version control system. Configuration management is an integral part in the building of software systems. Considering that the design of a system is a very important artefact of the software lifecycle, maintaining versions and baselines of the system design is a desirable feature to have in UML tools. In the absence of direct support for version control, it is the responsibility of the designer to maintain versions of the design.

Collaborative modeling environment: Enterprise systems are huge and their designs are quite complex. While designing complex systems, there may be different teams involved and may carry out design work on different subsystems in parallel. This collaborative design effort needs to be properly synchronized by the UML tool. The UML tool should provide support for a collaborative modeling environment with capability to compare different versions designs for differences or even merge different versions of a design. Collaborative modeling is always a nice feature to have in UML tools.

Integration with popular Integrated Development Environments (IDE): With the increasing use of iterative methodologies for building software systems, it becomes very difficult to keep the design of the system in sync with the developed code. Hence, it would be useful if the UML tool provides integration with popular IDEs. This feature would enable the UML tool to be updated with the changes in the source code made in the IDE.

7

Test script generation: The system or subsystem designed in a UML tool may represent a set of functional aspects as well. Hence, it would be really useful if, in addition to generating stub code, the tool also generates test scripts that can be used for testing how the generated class functions.

Model View Controller (MVC) modeling: Enterprise application architectures have increasingly begun to standardize and are based on the Model View Controller architecture. Hence, if you design n-tier, Web-enabled enterprise applications, you should look for a UML tool that supports designing applications based on the MVC architecture. Support for MVC modeling makes it easier to organize and clearly distinguish the design elements along the lines of the MVC layers. This will help in the long run in improving the readability of the model.

Template-driven modeling

Re-usability is the key to improving productivity. An application design may consist of several classes with relationships defined. Quite a few times, while designing applications, you encounter the same design problems or scenarios and end up defining the same design again and again. By using a modeling tool, you can define certain components or even subsystems that might potentially be reusable in the future. For example, design elements of an application used to define access to the database using, say, a ConnectionPool class are potentially reusable. You might need to define a similar database connection pool in another application as well. Hence, it would benefit us in the long run if we design the ConnectionPool class separately. We then can include the ConnectionPool design in any future subsystems and avoid the need of reinventing the wheel.

Such reusable designs or models are termed as templates and the entire modeling process involving the identification and use of templates is called template-driven modeling. The benefits of template-driven modeling are apparent in the savings in design time. You can consider model templates to be very similar to reusable code libraries used in application development.

Popular UML Tools

We will list here a few of the "movers and shakers" of vendors of UML tools. Please note that this list is by no means exhaustive and is not meant to provide any ranking for any UML tool.

Rational Rose: No discussion of UML tools is complete without the mention of the Rational Rose modeling tool from Rational Software Corporation. Rational Rose (the Rose stands for "Rational Object-oriented Software Engineering") is a visual modeling tool for UML. It comes in different versions suited to different requirements. Rational Rose provides support for all the standard features that we discussed in the previous section such as UML diagram support, forward and reverse engineering support, and documentation and round-trip engineering support. Apart from this, Rational Rose also provides support for version control, IDE integration, design pattern modeling, test script generation, and collaborative modeling environment. In addition, Rational Rose also supports the designing of data models within the same environment. An interesting feature of Rational Rose is the ability to publish the UML diagrams as a set of Web pages and images. This enables you to share and distribute your application design where the Rational Rose tool is not installed.

8

Together Control Center: Together Control Center (formerly from Togethersoft) from Borland is an entire suite of visual modeling tools for UML. Together Control Center supports UML diagrams, MVC modeling, forward and reverse engineering, and round-trip engineering, as well as integration with IDEs such as IBM WebSphere Studio.

It supports comprehensive documentation and a powerful collaborative modeling environment.

An added feature of Together Control Center is the pattern repository. The pattern repository (similar to the template-driven modeling concept discussed above) makes frequently used diagrams and design patterns readily available for reuse in modeling. Together Control Center supports the Rational Unified Process as well as the eXtreme Programming methodologies.

Poseidon: Poseidon from Gentleware has its roots in the ArgoUML open source project. The ArgoUML modeling tool evolved as an open source effort and is a useful, full-featured UML tool freely available under the Open Publication License. Gentleware has taken ArgoUML a step further and turned it into a good modeling tool. Poseidon comes in different flavors suited to different requirements. Poseidon supports forward and reverse engineering and documentation generation by using special-purpose plug-ins.

Gentleware has not forgotten its open source moorings and offers the Poseidon for UML Community Edition 1.5 free for individual software developers.

Integration of UML Tools with Integrated Development Environments (IDEs)

One interesting feature in UML tools that we discussed in the previous section was round-trip engineering. For round-trip engineering to be useful, we need to have the UML tool to be used in conjunction with an IDE. This integration of a UML tool with the IDE will help you to really benefit from round-trip engineering. Any changes in the application code that you make in the IDE are immediately reflected in the model in the UML tool and vice versa. For our discussion, we will be considering IDEs for the Java language.

Quite a few of the UML tools on the market can be integrated with the popular IDEs such as IBM's WebSphere Studio, Borland's JBuilder, WebGain's Visual Café, or Sun's Forte. For instance, Rational Rose (Java edition) provides integration with all of these popular IDEs. Together Control Center has a special version that integrates with IBM's WebSphere Studio.

The downside of UML tool integration is that the integration solution is proprietary to the UML tool vendor. Hence, you might not always find a UML tool providing integration with popular IDEs in the market. But all this is changing. (See box for details on the Eclipse project.)

9

Eclipse

Eclipse is an open source effort that has tool integration as the long-term goal. The interesting aspect of Eclipse is that the effort is supported by major tool vendors. Eclipse aims to define across-the-board integration standards that will enable vendors of different tools to seamlessly work together and provide a cohesive and single development environment. The beauty of Eclipse is that the integration between tools is not a proprietary solution. In layman's terms this means that, for example, you can buy an off-the-shelf UML tool and integrate it into your development environment without having to worry that you might be stuck with a particular vendor or group of vendors. Eclipse is definitely an area to watch out for in the near future! (www.eclipse.org)

Case Study

We will apply the UML concepts that we will be discussing through the coming weeks and design an entire real world application. Each session in the coming weeks will be rounded off with designing the case study application incrementally using each of the UML diagrams.

For our case study, we will be the architects assigned the task of constructing the design elements for a system that can be used to manage coursees/classes for an organization that specializes in providing training. Let us name the system that we will be designing as the Courseware Management System. The organization offers a variety of courses in a variety of areas such as learning management techniques and understanding different software languages and technologies. Each course is made up of a set of topics. Tutors in the organization are assigned courses to teach according to the area that they specialize in and their availability. The organization publishes and maintains a calendar of the different courses and the assigned tutors every year. There is a group of course administrators in the organization who manage the courses including course content, assign courses to tutors, and define the course schedule. The training organization aims to use the Courseware Management System to get a better control and visibility to the management of courses as also to streamline the process of generating and managing the schedule of the different courses.

Now that we have our problem statement defined, we can proceed to the next step—analyzing and elaborating on the requirements and then designing the Courseware Management System in the coming weeks.

Summary

UML tools will form the basis of our activities in the coming weeks. Each of the UML diagrams that we will cover will be built using any of the available UML tools in the market. Today's discussion helped us understand what features we should look for when selecting a UML tool. Apart from the "must-have" features, we also checked out a "wish list" of features that a UML tool could have. The classroom courseware case study application that we discussed will be designed using when we cover each of the UML diagrams in the coming weeks.

10

Creating Use Case Diagrams

Over the previous two articles, we took a brief look at the nine UML diagrams and what kind of tools you can use to model UML diagrams. Now that we have our basics clear, we will start our study of these nine UML diagrams. Today we will cover the Use case diagram. We will learn the basics of use case diagrams and try our hand at drawing a use case diagram. In addition, we will see what a use case specification is. Finally, we will attempt to apply what we have learned of use cases and model the use case diagrams for our case study application—the Courseware Management System.

Basics

Before we start off today's article, let us revisit the definition of use a case diagram, as described in the first article.

The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case.

The above statement pretty much sums up what a use case diagram is primarily made up of—actors and use cases.

A use case diagram captures the functional aspects of a system. More specifically, it captures the business processes carried out in the system. As you discuss the functionality and processes of the system, you discover significant characteristics of the system that you model in the use case diagram. Due to the simplicity of use case diagrams, and more importantly, because they are shorn of all technical jargon, use case diagrams are a great storyboard tool for user meetings. Use case diagrams have another important use. Use case diagrams define the requirements of the system being modeled and hence are used to write test scripts for the modeled system.

So who should normally be involved in the creation of use cases? Normally, domain experts and business analysts should be involved in writing use cases for a given system. Use cases are created when the requirements of a system need to be captured. Because, at this point no design or development activities are involved, technical experts should not be a part of the team responsible for creating use cases. Their expertise comes in use later in the software lifecycle.

Elements of a Use Case Diagram

A use case diagram is quite simple in nature and depicts two types of elements: one representing the business roles and the other representing the business processes. Let us take a closer look at use at what elements constitute a use case diagram.

Actors: An actor portrays any entity (or entities) that performs certain roles in a given system. The different roles the actor represents are the actual business roles of users in a given system. An actor in a use case diagram interacts with a use case. For example, for modeling a banking application, a customer entity represents an actor in the application. Similarly, the person who provides service at the counter is also an actor. But it is up to you to consider what actors make an impact on the functionality that you want to model. If an entity does not affect a certain piece of functionality that you are modeling, it makes no sense to represent it as an actor. An actor is shown as a stick figure in a use case diagram depicted "outside" the system boundary, as shown in Figure 3.1.

11

Figure 3.1: an actor in a use case diagram

To identify an actor, search in the problem statement for business terms that portray roles in the system. For example, in the statement "patients visit the doctor in the clinic for medical tests," "doctor" and "patients" are the business roles and can be easily identified as actors in the system.

Use case: A use case in a use case diagram is a visual representation of a distinct business functionality in a system. The key term here is "distinct business functionality." To choose a business process as a likely candidate for modeling as a use case, you need to ensure that the business process is discrete in nature. As the first step in identifying use cases, you should list the discrete business functions in your problem statement. Each of these business functions can be classified as a potential use case. Remember that identifying use cases is a discovery rather than a creation. As business functionality becomes clearer, the underlying use cases become more easily evident. A use case is shown as an ellipse in a use case diagram (see Figure 3.2).

Figure 3.2: use cases in a use case diagram

Figure 3.2 shows two uses cases: "Make appointment" and "Perform medical tests" in the use case diagram of a clinic system. As another example, consider that a business process such as "manage patient records" can in turn have sub-processes like "manage patient's personal information" and "manage patient's medical information." Discovering such implicit use cases is possible only with a thorough understanding of all the business processes of the system through discussions with potential users of the system and relevant domain knowledge.

System boundary: A system boundary defines the scope of what a system will be. A system cannot have infinite functionality. So, it follows that use cases also need to have definitive limits defined. A system boundary of a use case diagram defines the limits of the system. The system boundary is shown as a rectangle spanning all the use cases in the system.

12

Figure 3.3: a use case diagram depicting the system boundary of a clinic application

Figure 3.3 shows the system boundary of the clinic application. The use cases of this system are enclosed in a rectangle. Note that the actors in the system are outside the system boundary.

The system boundary is potentially the entire system as defined in the problem statement. But this is not always the case. For large and complex systems, each of the modules may be the system boundary. For example, for an ERP system for an organization, each of the modules such as personnel, payroll, accounting, and so forth, can form the system boundary for use cases specific to each of these business functions. The entire system can span all of these modules depicting the overall system boundary.

Relationships in Use Cases

Use cases share different kinds of relationships. A relationship between two use cases is basically a dependency between the two use cases. Defining a relationship between two use cases is the decision of the modeler of the use case diagram. This reuse of an existing use case using different types of relationships reduces the overall effort required in defining use cases in a system. A similar reuse established using relationships, will be apparent in the other UML diagrams as well. Use case relationships can be one of the following:

Include: When a use case is depicted as using the functionality of another use case in a diagram, this relationship between the use cases is named as an include relationship. Literally speaking, in an include relationship, a use case includes the functionality described in the another use case as a part of its business process flow. An include relationship is depicted with a directed arrow having a dotted shaft. The tip of the arrowhead points to the parent use case and the child use case is connected at the base of the arrow. The stereotype "<<include>>" identifies the relationship as an include relationship.

Figure 3.4: an example of an include relationship

13

For example, in Figure 3.4, you can see that the functionality defined by the "Validate patient records" use case is contained within the "Make appointment" use case. Hence, whenever the "Make appointment" use case executes, the business steps defined in the "Validate patient records" use case are also executed.

Extend: In an extend relationship between two use cases, the child use case adds to the existing functionality and characteristics of the parent use case. An extend relationship is depicted with a directed arrow having a dotted shaft, similar to the include relationship. The tip of the arrowhead points to the parent use case and the child use case is connected at the base of the arrow. The stereotype "<<extend>>" identifies the relationship as an extend relationship, as shown in Figure 3.5.

Figure 3.5: an example of an extend relationship

Figure 3.5 shows an example of an extend relationship between the "Perform medical tests" (parent) and "Perform Pathological Tests" (child) use cases. The "Perform Pathological Tests" use case enhances the functionality of the "Perform medical tests" use case. Essentially, the "Perform Pathological Tests" use case is a specialized version of the generic "Perform medical tests" use case.

Generalizations: A generalization relationship is also a parent-child relationship between use cases. The child use case in the generalization relationship has the underlying business process meaning, but is an enhancement of the parent use case. In a use case diagram, generalization is shown as a directed arrow with a triangle arrowhead (see Figure 3.6). The child use case is connected at the base of the arrow. The tip of the arrow is connected to the parent use case.

Figure 3.6: an example of a generalization relationship

On the face of it, both generalizations and extends appear to be more or less similar. But there is a subtle difference between a generalization relationship and an extend relationship. When you establish a generalization relationship between use cases, this implies that the parent use case can be replaced by the child use case without breaking

14

the business flow. On the other hand, an extend relationship between use cases implies that the child use case enhances the functionality of the parent use case into a specialized functionality. The parent use case in an extend relationship cannot be replaced by the child use case.

Let us see if we understand things better with an example. From the diagram of a generalization relationship (refer to Figure 3.6), you can see that "Store patient records (paper file)" (parent) use case is depicted as a generalized version of the "Store patient records (computerized file)" (child) use case. Defining a generalization relationship between the two implies that you can replace any occurrence of the "Store patient records (paper file)" use case in the business flow of your system with the "Store patient records (computerized file)" use case without impacting any business flow. This would mean that in future you might choose to store patient records in a computerized file instead of as paper documents without impacting other business actions.

Now, if we had defined this as an extend relationship between the two use cases, this would imply that the "Store patient records (computerized file)" use case is a specialized version of the "Store patient records (paper file)" use case. Hence, you would not be able to seamlessly replace the occurrence of the "Store patient records (paper file)" use case with the "Store patient records (computerized file)" use case.

Creating the Use Case Diagram

For drawing use case diagrams, you need to use any tool that supports use case diagrams. We will be using the Poseidon Community Edition tool for drawing the use case diagram, as shown in Figure 3.7. You can use any tool that you are comfortable with. A use case modeling tool provides a palette of options to draw actors and use cases and to define relationships between the use cases.

.

Figure 3.7: a screen shot of the Poseidon tool

Take a look at the screen shot of the Poseidon tool. You can see the different options it provides to draw the use case diagram elements. In addition to drawing the use case diagram elements such as actors and use cases, you also can define relationships between use cases. Apart from this, the tool also provides capability to document the different elements that we draw. This documentation can be viewed as a consolidated report for future reference.

15

An additional feature that you can check in your modeling tool is support for generating test scripts from the use case diagram. A comprehensive use case diagram provides a good foundation for basing test cases for the system that you model.

Writing a Use Case Specification

A use case diagram, as we have seen, is a visual depiction of the different scenarios of interaction between an actor and a use case. The usefulness of use case diagrams is more as a tool of communication between the requirements capture team and the user group. The next step after finalizing of use case diagrams is to document the business functionality into clear-cut and detailed use case specifications. Because use cases are used as an input to the other project phases such as design, development, and testing, we need to ensure that the visual depiction of the business requirements is translated into clear and well-defined requirements in the form of use case specifications. Elaborate use case specifications are used as an input for design and development and for writing test cases (unit, system, and regression tests, as the case may be).

A use case specification document should enable us to easily document the business flow. Information that you document in a use case specification includes what actors are involved, the steps that the use case performs, business rules, and so forth. A use case specification document should cover the following areas:

Actors: List the actors that interact and participate in this use case.

Pre-conditions: Pre-conditions that need to be satisfied for the use case to perform.

Post-conditions: Define the different states in which you expect the system to be in, after the use case executes.

Basic Flow: List the basic events that will occur when this use case is executed. Include all the primary activities that the use case will perform. Be fairly descriptive when defining the actions performed by the actor and the response of the use case to those actions. This description of actions and responses are your functional requirements. These will form the basis for writing the test case scenarios for the system.

Alternative flows: Any subsidiary events that can occur in the use case should be listed separately. Each such event should be completed in itself to be listed as an alternative flow. A use case can have as many alternative flows as required. But remember, if there are too many alternative flows, you need to revisit your use case design to make it simpler and, if required, break the use case into smaller discrete units.

Special Requirements: Business rules for the basic and alternative flows should be listed as special requirements in the use case narration. These business rules will also be used for writing test cases. Both success and failure scenarios should be described here.

Use case relationships: For complex systems, it is recommended that you document the relationships between use cases. If this use case extends from other use cases or includes the functionality of other use cases, these

16

relationships should be listed here. Listing the relationships between use cases also provides a mechanism for traceability.

Dos and Don'ts

Use cases should not be used to capture all the details of a system. The granularity to which you define use cases in a diagram should be enough to keep the use case diagram uncluttered and readable, yet, be complete without missing significant aspects of the required functionality. You will encounter such decision points of the level of granularity that you need to define when you build any of the UML diagrams.

An important rule that gets forgotten during use creation is the creeping in of design issues. Use cases are meant to capture "what" the system is, not "how" the system will be designed or built. Use cases should be free of any design characteristics. If you end up defining design characteristics in a use case, you need to go back to the drawing board and start again.

Case study—Courseware Management System

Use case modeling, as we have learnt today, involves analyzing the problem statement to determine the business processes of the system. We will now design the use case model for the Courseware Management System case study.

Let us analyze the problem statement to identify the potential actors and use cases of the system. First, let us list the potential actors. A quick look at the problem statement shows up the following terms and entities specific to the system:

Courses and Topics that make up a course Tutors who teach courses Course administrators who mange the assignment of the courses to tutors Calendar or Course Schedule is generated as a result of the Students who refer to the Course schedule or Calendar to decide which courses

they wish to take up for study

Identifying Actors of the Courseware Management System

Out of the preceding list, one thing is clear. There are certain terms and entities in the list that identify that they perform certain roles or business processes. We will discuss what these business processes are after we complete our analysis for identifying actors. For now, we focus on identifying the actors in the system. From the preceding list, we can see that there are some entities that perform an action and some that form the target for the action. The entities that perform action will be the actors for the Courseware Management System. In the above list, the actors that we can identify are:

Tutors Course administrators Students

But, because students are not the potential active participants for this system, we will drop them from the list of actors. Similarly, tutors are not active participants from our system's perspective, and hence, we will exclude tutors from our list if roles. Yet, we will still record them in our use case model since we do not wish to lose this business information. Our final list of primary actors has now come down to only one:

Course administrators

17

Identifying Use Cases of the Courseware Management System

Next, let us identify the potential business processes in the Courseware Management System. The primary business flows in the system are:

Manage courses Manage course assignments

As we analyze the problem statement further, we can determine some discrete processes within these primary business flows. To manage courses, the actor needs to have the ability to view existing courses, manage the course information for a course, such as duration and so forth, and also manage the addition or removal of topics for a course. So, within the "Manage courses" use case, we can identify the following sub processes:

View courses Manage topics for a course Manage course information

And similarly, the "Manage course assignment" use case can be refined into smaller discrete processes such as viewing the course calendar, viewing tutors, managing the tutor information of tutors working for the organization, and of course, assigning courses to tutors. Now, the use cases that we have identified within the "Manage course assignment" use case are:

View course calendar View tutors Manage tutor information Assign courses to tutors

Our final list of use cases for the courseware management system will now be:

View courses Manage topics for a course Manage course information View course calendar View tutors Manage tutor information Assign courses to tutors

If you were analyzing a sentence in English, the subject in the sentence can be identified as a potential actor and the verb part of the sentence can be a potential use case. Remember, this may or may not apply to the problem at hand, but is a good starting point for use case modeling.

18

Use Case Diagram

Figure 3.8: the use case diagram for the Courseware Management System

We have completed identifying potential use cases and actors. Take a look at the use case diagram for the Courseware Management System in Figure 3.7. The use case diagram of the Courseware Management System includes all the actors and use cases that we identified during our analysis of the problem statement.

Summary

Use case diagrams were the starting point of our journey in exploring each of the UML diagrams. Business functionality can be quickly represented in a simple and lucid fashion by using use case diagrams. Once the groundwork for depicting use cases is completed, the next step, as we learnt today, is writing detailed use case scenarios that will be used as the base functional requirements for the system. Our exercise in defining the use case diagram for the Courseware Management System case study was useful and enabled us to get a hands-on experience in applying what we learnt today.

The UML Class Diagram: Part 1

In the last article, we saw what use cases were, and how to identify and create use cases. Taking the series ahead, in this article, we will see what class diagrams are, what the elements of a class diagram are, what each of these elements signify, and how to identify them. In our next article, a sequel to this one, we will see how to create class diagrams for our case study—Courseware Management System. By the end of the second article, you will be able to define classes for a system and read and create class diagrams.

19

Basics

So, what is a class diagram? Imagine you were given a task of drawing a family tree. The steps you would take would be:

Identify the main members of the family Determine how they are related to each other Identify the characteristics of each family member Find relations among family members Decide the inheritance of personal traits and characters

A class diagram is similar to a family tree. A class diagram consists of a group of classes and interfaces reflecting important entities of the business domain of the system being modeled, and the relationships between these classes and interfaces. The classes and interfaces in the diagram represent the members of a family tree and the relationships between the classes are analogous to relationships between members in a family tree. Interestingly, classes in a class diagram are interconnected in a hierarchical fashion, like a set of parent classes (the grand patriarch or matriarch of the family, as the case may be) and related child classes under the parent classes.

Similarly, a software application is comprised of classes and a diagram depicting the relationship between each of these classes would be the class diagram.

By definition, a class diagram is a diagram showing a collection of classes and interfaces, along with the collaborations and relationships among classes and interfaces.

A class diagram is a pictorial representation of the detailed system design. Design experts who understand the rules of modeling and designing systems design the system's class diagrams. A thing to remember is that a class diagram is a static view of a system. The structure of a system is represented using class diagrams. Class diagrams are referenced time and again by the developers while implementing the system.

Now you now know what a class diagram is. But, how does a class diagram relate to the use case diagrams that you read about in the earlier article? When you designed the use cases, you must have realized that the use cases talk about "what are the requirements" of a system. The aim of designing classes is to convert this "what" to a "how" for each requirement. Each use case is further analyzed and broken up into atomic components that form the basis for the classes that need to be designed.

However, besides use cases, the artifacts of a project, such as stakeholder requests, (signed off) requirement documents, functional specifications, and a glossary of terms for the project serve as other important inputs to the discovery of classes.

We will now see what the components of a class diagram are, and how to create a class diagram.

Elements of a Class Diagram

A class diagram is composed primarily of the following elements that represent the system's business entities:

Class: A class represents an entity of a given system that provides an encapsulated implementation of certain functionality of a given entity. These are exposed by the class to other classes as methods. Apart from business functionality, a class also has properties that reflect unique features of a class.

20

The properties of a class are called attributes. Simply put, individual members of a family of our family tree example are analogous to classes in a class diagram.

As an example, let us take a class named Student. A Student class represents student entities in a system. The Student class encapsulates student information such as student id #, student name, and so forth. Student id, student name, and so on are the attributes of the Student class. The Student class also exposes functionality to other classes by using methods such as getStudentName(), getStudentId(), and the like. Let us take a look at how a class is represented in a class diagram.

A class is represented by a rectangle. The following diagram shows a typical class in a class diagram:

Figure 4.1.1—the structure of a class

If you are familiar with object-oriented concepts, you will be aware of the concept of access modifiers. You can apply access modifiers such as public access, protected access, and private access applied to methods and attributes of a class—even to a class as well, if required. These access modifiers determine the scope of visibility of the class and its methods and attributes.

You also can add documentation information to a class. Notes and constraints can be added to a list of attributes. Notes contain additional information for reference while developing the system, whereas constraints are the business rules that the class must follow, and are text included in curly brace brackets.

During the early phase of the system design conception, classes called Analysis classes are created. Analysis classes are also called stereotypes. In the UML context, stereotypes are UML models that that represent an existing UML element, while showing additional characteristics that are common across the classes to be used for that application. Only one stereotype can be created for any UML element in the same system.

Analysis classes are of the following types as per their behavior, as shown in the following table:

Class Behavior

Boundary In an ideal multi tier system, the user interacts only with the boundary classes. For example, JSPs in a typical MVC architecture form the boundary classes.

Control These classes typically don't contain any business functionality. However, their main task is to transfer control to the appropriate business logic class, depending on a few inputs received from the

21

boundary classes.

Entity These classes are those that contain the business functionality. Any interactions with back-end systems are generally done through these classes.

Interface: An interface is a variation of a class. As we saw from the previous point, a class provides an encapsulated implementation of certain business functionality of a system. An interface on the other hand provides only a definition of business functionality of a system. A separate class implements the actual business functionality.

So, why would a class not suffice? You can define an abstract class that declares business functionality as abstract methods. A child class can provide the actual implementation of the business functionality. The problem with such an approach is that your design elements get tied together in a hierarchy of classes. So, even though you may not have intended to connect your design elements representing drastically different business entities, that is what might result. Hence, the use of the interface design construct in class diagrams. Different classes belonging to different and discrete hierarchies can maintain their distinct hierarchies and still realize the functionality defined in the methods of the interface.

An interface shares the same features as a class; in other words, it contains attributes and methods. The only difference is that that the methods are only declared in the interface and will be implemented by the class implementing the interface.

In addition to the above, there is one more element used in class diagrams:

Package: A package provides the ability to group together classes and/or interfaces that are either similar in nature or related. Grouping these design elements in a package element provides for better readability of class diagrams, especially complex class diagrams.

Figure 4.1.2—a package

From Figure 4.1.2, you can see a package is represented as a tabbed folder. A package can also have relationships with other packages similar to relationships between classes and interfaces.

Relationships Between Classes

In a class diagram, obviously you can't have classes just floating around; you need to see the relationship between them. The following table shows the kinds of relationships between classes, their notation, and what they mean.

22

Sr. No. Relation Symbol Description

1 Association When two classes are connected to each other in any way, an association relation is established. For example: A "student studies in a college" association can be shown as:

1 a. Multiplicity An example of this kind of association is many students belonging to the same college. Hence, the relation shows a star sign near the student class (one to many, many to many, and so forth kind of relations).

1 b. Directed Association

Association between classes is bi-directional by default. You can define the flow of the association by using a directed association. The arrowhead identifies the container-contained relationship.

1 c. Reflexive Association

No separate symbol. However, the relation will point back at the

same class.

An example of this kind of relation is when a class has a variety of responsibilities. For example, an employee of a college can be a professor, a housekeeper, or an administrative assistant.

2 Aggregation When a class is formed as a collection of other classes, it is called an aggregation relationship between these classes. It is also called a "has a" relationship.

2 a. Composition Composition is a variation of the

23

aggregation relationship. Composition connotes that a strong life cycle is associated between the classes.

3 Inheritance/Generalization

Also called an "is a" relationship, because the child class is a type of the parent class. Generalization is the basic type of relationship used to define reusable elements in the class diagram. Literally, the child classes "inherit" the common functionality defined in the parent class.

4 Realization In a realization relationship, one entity (normally an interface) defines a set of functionalities as a contract and the other entity (normally a class) "realizes" the contract by implementing the functionality defined in the contract.

A Few Terms

Here are a few terms that we will be using to annotate our class diagrams. You should be familiar with them:

1. Responsibility of a class: It is the statement defining what the class is expected to provide.

2. Stereotypes: It is an extension of the existing UML elements; it allows you to define new elements modeled on the existing UML elements. Only one stereotype per element in a system is allowed.

3. Vocabulary: The scope of a system is defined as its vocabulary.

4. Analysis class: It is a kind of a stereotype.

5. Boundary class: This is the first type of an analysis class. In a system consisting of a boundary class, the users interact with the system through the boundary classes.

24

6. Control class: This is the second type of an analysis class. A control class typically does not perform any business functions, but only redirects to the appropriate business function class depending on the function requested by the boundary class or the user.

7. Entity class: This is the third type of an analysis class. An entity class consists of all the business logic and interactions with databases.

Creating a Class Diagram

Class diagrams can be modeled by using any UML tool that supports class diagrams. We will be using the Poseidon Community Edition tool to draw the class diagram. You can use any tool that you are comfortable with.

Figure 4.1.3—a screen shot of the Poseidon tool

The screen shot of the Poseidon tool in Figure 4.1.3 shows the different options to model class diagrams and establish relationships among the packages, classes, and interfaces.

Some additional features that you can check in your modeling tool are:

Support for forward and reverse engineering for class diagrams. A few sophisticated modeling tools also integrate with standard IDEs with support for round-trip engineering.

Documentation and report generation features

25

Dos and Don'ts

Classes in a class diagram should be descriptive and must be named after business entities. Using business entities as names ensures greater readability of class diagrams.

Relationships between classes may not be apparent in the first iteration. Revise and refine your class diagrams to determine possible relationships during each iteration.

Designing is an incremental process and class diagrams are updated as the system gets built. Hence, do not try to capture and freeze the class diagrams of a system in the first pass.

Summary

Class diagrams are the basic building block used to define the design of a system. Today, we learned about the elements of a class diagram—classes, interfaces, and packages—and the different types of relationships among these elements such as association, aggregation, composition, generalization, and realization.

In the next part in this article, we will take up a practical example, the Courseware Management system, and create the class diagrams for the system.

UML DIAGRAM PART II

Introduction

In the last article of this series, we saw what class diagrams were, and how to create class diagrams. In today's article, we will see a practical example building on our Courseware Management system case study.

Case study—Courseware Management System

The class diagram of our Courseware Management System case study can be built after a careful analysis of the requirements. In the previous article, we identified the primary actors and use cases in the use case model of the case study. Because we did much of the groundwork of our analysis while building the use case model, we will use those analysis steps as the basis for identifying the classes and interfaces of this system.

Let us recap our analysis that we had performed when we designed the use case model. The following terms and entities specific to the system were identified from the problem statement:

Courses and Topics that make up a course

Tutors who teach courses

Course administrators who mange the assignment of the courses to tutors

Calendar or Course Schedule is generated as a result of the

Students who refer to the Course schedule or Calendar to decide which courses for which they wish to sign up

The potential actors of the system were:

26

Tutors

Course administrators

Students

And the use cases of the system were:

View courses

Manage topics for a course

Manage course information

View course calendar

View tutors

Manage tutor information

Assign courses to tutors

Identifying classes of the Courseware Management System

As we did in use case modeling, we will identify the classes and interfaces using an incremental approach.

1. Identify the "active" entities in the system

The basic rule that we learned until now for identifying classes and interfaces is that classes and interfaces reflect important entities of the business domain of the system being modeled. We will apply this rule to determine classes and interfaces of the case study system. At first glance, the actors identified in the use case appear to be prime candidates for being listed as potential classes. Even though we had excluded Students and Tutors from our final list of actors, we will still include them in our list as potential classes. So, our first list of classes in the system appears to be:

o Course administratorso Tutorso Students

2. Identify business domain ("passive") entities in the system

But these are the "active" entities of the system. We had also identified "passive" elements in the system as well in the analysis for our use case model. These entities reflect the business domain and hence are potential classes for our system.

o Courseso Topics that make up a courseo Course calendar generated

27

Entities that reflect the business terms are also called business domain classes or just "domain classes." Some of the business domain classes hold transient data and some hold persistent data for the application. Normally, such business domain classes map to either one or many database tables.

For example, in our case study, the Course class can be modeled as a database table cms_course. The data in this table for a particular course will be represented by an instance of the Course class and made available to the rest of the application.

Our two-step process has definitely yielded promising results! We have covered all the relevant items in our analysis. So, let us list the list of classes and interfaces that we have identified in the Courseware Management System.

o CourseAdministratoro Tutoro Studento Courseo Topico CourseCalendar

3. Categorize and map the use cases and any relevant business functionality to either the passive or active entities. These will become the business methods of the classes in the system.

Classes encapsulate functionality. The classes that we have identified for the Courseware Management System also provide business functionality related to the application. The functionality encapsulated by these classes is distinct in nature and differs from each class. Recall from our use case model, that, along with actors, we had identified a set of use cases that the actors interacted with. Let us try to associate them with our classes. Because our primary actor is the course administrator and the use cases were related to this actor, we can directly map the use cases to the CourseAdministrator class as methods.

ClassName Methods

CourseAdministrator viewCourses()manageCourse()manageTopic()viewCourseCalendar()viewTutors()manageTutorInformation()assignTutorToCourse()

28

In addition to this, we also can determine some implicit functionality of classes that reflect business entities. For example, what functionality should the Course class provide? Intuitively, we would define the Course class to provide functionality to view all courses in the system, ability to create new courses or modify information of existing courses, view the details of a particular course, or even remove a course from the system. We expect the Course class to provide such business functionality because the Course class reflects a business entity in the system. Hence, these become the methods exposed by the Course class. So, we can now refine the class diagram and add methods to each of these classes.

To cut a long story short, each of the classes that reflect business entities will provide similar implicit business functionality. Let us list all such "implicit" functionality for each of these classes.

ClassName Methods

Course viewAllCourses()viewCourseInformation()createCourse()modifyCourse()removeCourse()

Topic viewAllTopics()viewTopicInformation()createTopic()modifyTopic()removeTopic()

Tutor viewTutorInformation()createTutor()modifyTutor()removeTutor()

CourseCalendar viewCourseCalendar()

Student viewAllStudents()viewStudentInformation()

Refine and revise the list of classes and interfaces

Revisit the class diagram and revise it by identifying shared features and/or common functionality between classes or interfaces. These will translate into reusable pieces of code for your system. To some extent, we can say that CourseAdministrator, Tutor, and Student are essentially users of the system. Hence, we can define a shared parent class named User and define basic functionality like for example, authentication, in the User class that can be inherited by the CourseAdministrator, Tutor, and Student classes. It is left to the design expertise to identify reusable classes/functionality.

This completes our analysis of the problem statement to define the classes for the Courseware Management System.

29

Identifying relationships between the classes of the Courseware Management System

The next step after defining the classes of the Courseware Management System is to define the relationships and dependencies between these classes and interfaces. To define the relationships between the classes, we need to analyze the interconnections between the classes—whether implicit or explicit. Relationship analysis can be broken up into three steps:

1. Identify relationships between "active" entities

Active entities normally share generalization relationships ("is-a"). Essentially, the common attributes and functionality between classes are defined in a common parent class. All the related child classes inherit functionality from the parent class. Apart from generalization, a few active entities can also be interconnected by a realization relationship. Recall that elements in a realization relationship implement declared functionality as a "contract." For example, a set of classes may implement functionality declared as methods in an interface, and this can be modeled as a realization relationship between the interface and the classes implementing the interface.

In our case study, we do not find an example of inheritance relationship between the active entities such as Student, Tutor, and CourseAdministrator or any realization relationships.

2. Identify relationships between "passive" business entities

Passive business entities frequently share plain association or aggregation relationships ("has-a"). This is especially true because these business entities are non-transactional in nature and reflect data more than behavior. It is by far quite intuitive to identify aggregation as well as its variations—composition relationships for passive business entities.

Some of the classes in our case study do exhibit aggregation relationships. Because a set of topics makes up a course, we can define an aggregation relationship between the Course and Topic classes. Moreover, we can define this as a directed aggregation, meaning that you can check for the topics of a course but not vice versa. Similarly, we can define a plain association relationship between the Course and Tutor classes and Course and Student classes.

Identify relationships between "active" and "passive" entities

Relationships between active and passive entities can easily be represented using directed association. The directed association, a variation of the "vanilla" association relationship, provides easy identification of which is the container class and which is the contained class. The CourseAdministrator class can be modeled to have a directed association with the Course class. This association can be named as "manages" because the course administrator manages courses as a business activity. In addition to this, because the course administrator also manages the tutor information and topic information, we can model a directed relationship named as "manages" between the CourseAdministrator and the Course and Topic classes, respectively. We can enhance the readability of the association between CourseAdministrator and the Course, Tutor, and Topic classes by defining the multiplicity for the association—one to many, one to one, many to many, and so forth.

30

Class diagram

Figure 4.2.1 shows the class diagram for the Courseware Management System

We have completed identifying the classes for the Courseware Management System and established the relationships among the classes. Take a look at the class diagram in Figure 4.2.1. The class diagram of the Courseware Management System includes all the classes and their relationships that we identified during our analysis of the problem statement.

Model View Controller DesignThe class diagram that we designed for the Courseware Management System defined the basic classes necessary for representing the basic structure of the system. But this is by no means a complete design if the architecture of your system is to be based on the Model View Controller (MVC) architecture. Because an MVC model defines clear separation of classes among the three layers—business, presentation, and flow control—you need to define additional classes and revise your design to include them. In case your UML tool does not support explicit partitioning of classes, you can mark classes in each of the layers using stereotypes such as <<entity>>, <<boundary>>, <<control>>, and so forth.

For example, in our case study application, we can revise the class diagram to define a new CMSController class that manages the flow of the application. The model layer primarily consists of classes relevant to the business domain. Next, the classes that we had defined can be categorized as transactional and persistent classes. The CourseAdministrator class performs most of the activities in the system. Hence, this class can be designated as a transaction class of the model layer. Similarly, the Course, Topic, Tutor, CourseCalendar, and Student classes represent persistent business data. Hence, these can be categorized as persistent classes of the model layer. Finally, you can define a set of classes that represent the presentation layer; in other words, the user interface of the system.

31

Forward Engineering from Class Diagrams

Forward engineering is the process of generating source code (in a specific language) from a class diagram model. The extent to which a UML class diagram can be used to generate source code depends upon the limitations of the source code language. Because UML is pictorial, and can depict a lot of details, these details could be lost in the code. Hence, before creating a complete class model, it is a good idea to be aware of the language that is going to be used, to limit the class model accordingly. Typically, the association relationships between classes are generated as member variables between the related classes in the source code. Generalization relationships are generated as inheritance relationships in the source code.

Figure 4.2.2 shows forward engineering a class diagram

The above screenshot shows the source code file generated for the CourseAdministrator Java source code file as a result of forward engineering the class diagram of the Courseware Management System case study. You need to check how forward engineering works in the tool that you use.

Reverse Engineering of Class Diagrams

Obtaining a class model from existing source code is called reverse engineering. This is generally done when it is required to understand the architecture of an existing system, either for re-engineering, or for maintenance. Reverse engineering is of great use especially when trying to figure out the static structure and organization of a complex system. Typically, classes defined as member variables in the source code are modeled as association relationships between the classes. Inheritance relationships in the source code are generated as generalization relationships between the classes.

32

Figure 4.2.3 shows reverse engineering a sample source code file

The above screenshot shows a class diagram generated as a result of reverse engineering a sample source code file. You need to check how reverse engineering works in the tool that you use.

Summary

In the last article, we saw how class diagrams are the basic building blocks that define the design of a system. We learned about the elements of a class diagram—classes, interfaces, and packages—and the different types of relationships among these elements, such as association, aggregation, composition, generalization, and realization.

Today, we defined a few steps to identify classes and interfaces of a system from a problem statement for designing the class diagram for the Courseware Management System case study.

Object Diagrams in UML

Introduction

In the last article, you saw how your application could be represented in a class diagram. A class diagram is a static representation of your system. It shows the types of classes, and how these classes are linked to each other. In this edition of our series we introduce the object diagram.

33

Basics

Although we design and define classes, in a live application classes are not directly used, but instances or objects of these classes are used for executing the business logic. A pictorial representation of the relationships between these instantiated classes at any point of time (called objects) is called an "Object diagram." It looks very similar to a class diagram, and uses the similar notations to denote relationships.

If an object diagram and a class diagram look so similar, what is an object diagram actually used for? Well, if you looked at a class diagram, you would not get the picture of how these classes interact with each other at runtime, and in the actual system, how the objects created at runtime are related to the classes. An object diagram shows this relation between the instantiated classes and the defined class, and the relation between these objects, in the logical view of the system. These are very useful to explain smaller portions of your system, when your system class diagram is very complex, and also sometimes recursive.

Let us now see what the components of an object diagram are. After this, we will build an object diagram for our case study—Courseware Management system.

Elements of an Object Diagram

Because an object diagram shows how specific instances of a class are linked to each other at runtime, at any moment in time it consists of the same elements as a class diagram; in other words, it contains classes and links showing the relationships. However, there is one minor difference. The class diagram shows a class with attributes and methods declared. However, in an object diagram, these attributes and method parameters are allocated values.

As an example, in the last article, a class diagram for a multiplicity relation between college and students was shown, as you cam see in Figure 5.1:

Figure 5.1—an example College-Student class diagram

This class diagram shows that many students can study in a single college. Now, if we were to add attributes to the classes "College" and "Student," we would have a diagram as shown in Figure 5.2:

Figure 5.2—the class diagram with attributes

34

Now, when an application with the class diagram as shown above is run, instances of College and Student class will be created, with values of the attributes initialized. The object diagram for such a scenario will be represented as shown in Figure 5.3:

Figure 5.3—the object diagram for the College-Student class diagram

As can be seen from Figure 5.3, the object diagram shows how objects are instantiated in the running system represented by the College-Student class diagram. The class diagram shows that a single college has many students, and defines the variables. The object diagram for the same system shows instantiated classes of Student (Student #1 and Student #2) enrolled in College (Graduate School of Business).

The object diagram shows the name of the instantiated object, separated from the class name by a ":", and underlined, to show an instantiation.

Eg: Graduate School of Business: College

In the diagram, values are assigned to variables and represented using the notation variable name=variable value.

This example was the representation of the relation of only two classes with each other. However, in a real application system, there will be multiple classes. An object diagram then shows the relation between the instantiations of these classes. We shall see this in our case study.

A class that defines the flow of the system is called as an active class. This class instance in the object diagram is represented by thick border. In an MVC application architecture, the controller servlet is the action class, and is denoted by a thicker border. Also, multiple instances of the same class, as in a factory pattern, if the attributes of the individual objects are not important, or are not different, these can be represented by a single symbol of overlapping rectangles (see Figure 5.4):

Figure 5.4—the object diagram for a Factory class

35

A class that performs more than one role, and is self-linked, is represented by a curve starting and ending on itself, as illustrated in Figure 5.5:

Figure 5.5—the object diagram for a self-linked class

Creating an Object Diagram in Poseidon

In Poseidon, you will find the option to create object diagrams clubbed with the option to create deployment and component diagrams. Presently, Poseidon does not support display of attributes and methods in the object diagram; in other words, you can as of now only define an object of class, its type, and the linked objects. Hence, for our case study, we will use Microsoft Word to create an object diagram.

The steps for creating an object diagram in Poseidon are as follows:

1. Open your Poseidon project file (the .zargo file) in which you created your class diagram earlier.

2. Make sure you are viewing your class diagram in the "Package centric," "Diagram centric," or "Inheritance centric" modes to view the deployment diagram. See Figure 5.6.

the creation of an object diagram in Poseidon(objdiagram1)

Click on Create diagram -> Deployment/Object/Component diagram (or Ctrl+D) in the menu bar above.

Click on the object icon (shown in the black circle) in the icon menu bar on the top, to create an object. See Figure 5.7.

Fill in the Name of the Object instantiated, in the properties bar below. Select the class of which this object is an instance, in the area titled "Type."

After creating all the objects, click on the icon for "link" (shown in the red circle in Figure 5.7) to link the objects. Give the name of the link.

In case of our Case study, if we show an object diagram for the Course Administrator managing the Courses scenario, we get a diagram as shown in Figure 5.7.

objectdiagram2—the object diagram in Poseidon for the case study Courseware management system

Dos and Don'ts

Dos

1. Use the object diagram as a means of debugging the functionality of your system.

36

2. Object diagrams can also be used to check whether the system has been designed as per the requirements, and behaves how the business functionality needs the system to respond.

3. Show associations of any kind between objects as linkages (for example, a single segment joining two objects, without arrows), and not as a dependency or any other specific type of association. An object diagram only shows the linkages, but not the type of association.

Don'ts

1. Avoid representing all the objects of your system in an object diagram. Because an object diagram represents the state of objects, it can become quite complex if you try to represent all the objects. Hence, it is always better to represent the state of objects in certain important/critical flows in your application using an object diagram. This will keep your object diagram readable, yet useful enough to capture the state of objects that are important.

2. Because object diagrams represent the state of objects, forward engineering of object diagrams does not make sense.

Case Study: Courseware Management System

Now, we shall create an object diagram for the courseware system. To do this, we will first build up on our class diagram, and include the possible attributes and define the parameters of to the classes defined earlier.

We will follow the following convention for the variable names:

Names starting with "s_" are of the String data type

Names starting with "i_" are of the int data type

Names starting with "v_" are of the Vector data type

The following table outlines the attributes, methods, and their return types for each of the classes:

Class Name Attributes Methods

CourseAdministrator s_adminId

v_courses

s_courseId

v_tutors

v_tutorInfo

s_tutorId

v_topics

s_topicId

Vector viewCourses()

Vector manageCourse(s_courseId)

Vector manageTopic(s_topicId)

Vector viewCourseCalendar(s_courseId)

Vector viewTutors()

Vector manageTutorInformation(s_tutorId)

Boolean assignCourseToTutor(s_courseId, s_tutorId)

37

Student s_studentId

v_studentInfo

v_studentList

Vector viewAllStudents()

Vector viewStudentInformation(s_studentId)

Tutor s_tutorId

v_tutorInfo

v_tutorList

Vector viewTutorInformation(s_tutorId)

String createTutor(v_tutorInfo)

Boolean modifyTutor(v_newTutorInfo)

Boolean removeTutor(s_tutorId)

Course s_courseId

v_courseList

v_courseInfo

Vector viewAllCourses()

Vector viewCourseInfo(s_courseId)

Boolean createCourse(v_courseInfo)

Boolean modifyCourse(v_newCourseInfo)

Boolean removeCourse(s_courseId)

Topic s_topicId

v_topicList

v_topicInfo

Vector viewAllTopics()

Vector viewTopicInformation(s_topicId)

Boolean createTopic(v_topicInfo)

Boolean modifyTopic(v_newTopicInfo)

Boolean removeTopic(s_topicId)

CourseCalender v_courseCalendar Vector viewCourseCalendar(s_courseId)

To follow a logical sequence now, let us consider that the course administrator, courses, tutors, and topics already exist. Let us now make an object diagram for the case where the administrator with user id "admin" wishes to access the course calendar of a course with course id "Math_Course_001."

Hence, the following will be the attribute values, and method calls:

CourseAdministrator

Attributes: s_adminId = admin

s_courseId = Math_Course_001

Methods: viewCourseCalendar("Math_Course_001")

This method will call the method viewCourseInfo of class Course, which returns a Vector object populated with all the details of the course "MathCourse_001" (see Figure 5.8)

38

Course

Methods: viewCourseInfo("Math_Course_001")

Figure 5.8—the object diagram for the courseware management system, for a simple scenario of the course administrator managing a math course.

In Figure 5.8, for the single case where the flow is from Course Administrator to Course, when the CourseAdministrator is requesting the course information for a particular course.

Summary

In the last article, we saw how to make class diagrams, and made a class diagram for the case study—the Courseware Management system. In this article, we saw:

What an object diagram is

Notation used in an object diagram

What the significance and use of an object diagram is

How to make an object diagram in Poseidon

The object diagram for a simple scenario in our Courseware Management system

In the next article of this series, we will study the state diagram.

State Diagram in UML

In the previous article, we saw what Object diagrams are, the notations to be used in Object diagrams, their significance, and how to make an Object diagram using Poseidon. We then made an Object diagram for our Courseware Management System. By the end of this article, you will know what a State diagram is, what its elements are, and you will be able to create State diagrams for your system.

The Basics

Until now, we have seen Use Cases, Class diagrams, and Object diagrams. These diagrams give an architectural and high-level view of a system. In a typical software life cycle, the business or functional domain experts define Use Case diagrams. The Class diagrams and Object diagrams are made by senior-level developers, with the help of system architects. Once this has been accomplished, and the system design and architecture is in place, these artifacts are passed on to the developer, who actually codes the system. All the above diagrams are static diagrams, which means that they help in visualizing what the elements of the complete system would be, but do not say

39

anything about the flows any object of the system can have when an event occurs. Structural elements are used to depict static diagrams.

While coding, it is necessary to understand the details of the modes an Object of a Class can go through and its transitions at time intervals with the occurrence of any event or action.

State diagrams (also called State Chart diagrams) are used to help the developer better understand any complex/unusual functionalities or business flows of specialized areas of the system. In short, State diagrams depict the dynamic behavior of the entire system, or a sub-system, or even a single object in a system. This is done with the help of Behavioral elements.

It is important to note that having a State diagram for your system is not a compulsion, but must be defined only on a need basis.

Defining a State diagram

Just as we define classes for a Class diagram, it is necessary to define the elements of a State diagram. Let us first see what the elements of a State diagram are.

Elements of a State diagram

A State diagram consists of the following behavioral elements:

Element and its Description Symbol

Initial State: This shows the starting point or first activity of the flow. Denoted by a solid circle. This is also called as a "pseudo state," where the state has no variables describing it further and no activities.

State: Represents the state of object at an instant of time. In a state diagram, there will be multiple of such symbols, one for each state of the Object we are discussing. Denoted by a rectangle with rounded corners and compartments (such as a class with rounded corners to denote an Object). We will describe this symbol in detail a little later.

Transition: An arrow indicating the Object to transition from one state to the other. The actual trigger event and action causing the transition are written beside the arrow, separated by a slash. Transitions that occur because the state completed an activity are called "triggerless" transitions. If an event has to occur after the completion of some event or action, the event or action is called the guard condition. The transition takes place after the guard condition occurs. This guard condition/event/action is depicted by square brackets around the description of the event/action (in other words, in the form of a Boolean expression).

History States: A flow may require that the object go into a trance, or wait state, and on the occurrence of a certain event, go back to the state it was in when it went into a wait state—its last active state. This is shown in a State diagram with the help of a letter H enclosed within a circle.

40

Event and Action: A trigger that causes a transition to occur is called as an event or action. Every transition need not occur due to the occurrence of an event or action directly related to the state that transitioned from one state to another. As described above, an event/action is written above a transition that it causes.

Signal: When an event causes a message/trigger to be sent to a state, that causes the transition; then, that message sent by the event is called a signal. Represented as a class with the <<Signal>> icon above the action/event.

Final State: The end of the state diagram is shown by a bull's eye symbol, also called a final state. A final state is another example of a pseudo state because it does not have any variable or action described.

Note: Changes in the system that occur, such as a background thread while the main process is running, are called "sub states." Even though it affects the main state, a sub state is not shown as a part of the main state. Hence, it is depicted as contained within the main state flow.

As you saw above, a state is represented by a rectangle with rounded edges. Within a state, its Name, variables, and Activities can be listed as shown in Figure 6.1.

Figure 6.1: the structure of the state element

Creating a State Diagram

Let us consider the scenario of traveling from station A to station B by the subway. Figure 6.2 would be a state diagram for such a scenario. It represents the normal flow. It does not show the sub states for this scenario.

Figure 6.2: an example flow in a state diagram

41

Things to Remember

Create state diagrams when the business logic for a particular flow is very complex, or needs greater understanding by the developer to be coded perfectly.

Arrange the states and transitions to ensure that the lines that cross each other are minimal. Criss-crossing lines are potential sources of confusion in conveying the diagram's meaning.

Case Study—Courseware Management System

Because our Courseware Management System case study does not undergo any noticeable state changes, we will drill down our attention to the Course object in the system. Recall that a state diagram can be defined not only for a system or subsystem, but also for an object in the system.

Identifying states and events of the Course object

The Course object does undergo state changes during its lifecycle, right from course creation to deleting a course. Let us depict the Course object's lifecycle by using a state diagram to understand it better. The events that occur in the lifecycle of the Course object are listed below:

Create new course—add information for the course or update an existing course; update information for the course

Add topics—add topics to the course

Assign tutors—assign the available tutors for the course

Close—finished adding or updating the course

Consider the event of adding a new course to the Courseware Management System by the course administrator. The course administrator fills in the course information, thus initiating the creation of the Course object.

This event kicks off two events that change the state of the Course object, but are part of the new course event. These two events contained within the new course creation event are adding topics to the Course object and assigning tutors for the course. This results in the Topic objects getting associated with the Course object. Next, the course administrator may wish to assign tutors to teach the course by identifying the tutors that teach this course (based on their specialty/preferences) and checking the availability of the tutors for a given period of time.

This completes the lifecycle Course object until the time an update course event occurs.

Figure 6.3 shows the state diagram for the Course object. The state diagram depicts the changes in the state of the Course object as it transitions through the various events in its lifecycle.

42

Figure 6.3: the state diagram of the Course object

Summary

This article covered the first of the series of dynamic diagrams in UML. The state diagram is one of the simplest ways to represent the lifecycle of an entire system or a subsystem or even an object of a system. In the next article of this series, we will learn about Activity diagrams.

Activity Diagram in UML

In the previous article, we learned about State diagrams, the notations to be used in State diagrams, their significance, and how to build a State diagram for a specific scenario in our Courseware Management system.

In this article, we will cover the next dynamic diagram—the Activity diagram. By the end of this article, you will know what an Activity diagram is, what its elements are, and you will be able to create Activity diagrams for your system.

Basics

The easiest way to visualize an Activity diagram is to think of a flowchart of a code. The flowchart is used to depict the business logic flow and the events that cause decisions and actions in the code to take place.

Activity diagrams represent the business and operational workflows of a system. An Activity diagram is a dynamic diagram that shows the activity and the event that causes the object to be in the particular state.

So, what is the importance of an Activity diagram, as opposed to a State diagram? A State diagram shows the different states an object is in during the lifecycle of its existence in the system, and the transitions in the states of the objects. These transitions depict the activities causing these transitions, shown by arrows.

An Activity diagram talks more about these transitions and activities causing the changes in the object states.

43

Defining an Activity diagram

et us take a look at the building blocks of an Activity diagram.

Elements of an Activity diagram

An Activity diagram consists of the following behavioral elements:

Element and its description Symbol

Initial Activity: This shows the starting point or first activity of the flow. Denoted by a solid circle. This is similar to the notation used for Initial State.

Activity: Represented by a rectangle with rounded (almost oval) edges.

Decisions: Similar to flowcharts, a logic where a decision is to be made is depicted by a diamond, with the options written on either sides of the arrows emerging from the diamond, within box brackets.

Signal: When an activity sends or receives a message, that activity is called a signal. Signals are of two types: Input signal (Message receiving activity) shown by a concave polygon and Output signal (Message sending activity) shown by a convex polygon.

Concurrent Activities: Some activities occur simultaneously or in parallel. Such activities are called concurrent activities. For example, listening to the lecturer and looking at the blackboard is a parallel activity. This is represented by a horizontal split (thick dark line) and the two concurrent activities next to each other, and the horizontal line again to show the end of the parallel activity.

Final Activity: The end of the Activity diagram is shown by a bull's eye symbol, also called as a final activity.

Creating an Activity Diagram

Let us consider the example of attending a course lecture, at 8 am.

44

Figure 7.1—an example Activity diagram

As you can see in Figure 7.1, the first activity is to get dressed to leave for the lecture. A decision then has to be made, depending on the time available for the lecture to start, and the timings of the public trains (metra). If there is sufficient time to catch the train, then take the train; else, flag down a cab to the University. The final activity is to actually attend the lecture, after which the Activity diagram terminates.

Swim Lanes

Activity diagrams provide another ability, to clarify which actor performs which activity. Consider the Activity diagram in Figure 7.1. Were we to break down the activities further, we can break up the activity of taking the metra to "wait for the train to arrive at the station," alight train, wait for train to arrive at destination, and so forth. The activity of hailing a cab would involve hail cab, wait for cab driver to stop, inform driver of your destination, and finally alight. In this, you can see that two more actors are involved, one is the metra driver, and the other is the cab driver. If you wish to distinguish in an Activity diagram the activities carried out by individual actors, vertical columns are first made, separated by thick vertical black lines, termed "swim lanes," and name each of these columns with the name of the actor involved. You place each of the activities below the actor performing these activities and then show how these activities are connected.

Case Study—Courseware Management System

Let us now apply the information that we have gained from the previous sections to our Courseware Management System case study application. An Activity diagram depicts different workflows in a system. In Article 3, we had defined the following use cases for the Courseware Management System:

View courses Manage topics for a course Manage course information View course calendar View tutors Manage tutor information Assign courses to tutors

45

Each of these use cases is actually a workflow. Hence, we can easily depict these use cases by using the Activity diagram. Ideally, you should use an Activity diagram to model a workflow by basing it on the different business entities (classes) involved in the workflow.

Hence, we will take a candidate use case and model it to gain a hands-on understanding of creating an Activity diagram. In this instance, we will model the "Manage course information" use case in the system using the Activity diagram.

Identifying the activities and transitions for managing course information

The course administrator is responsible for managing course information in the Courseware Management System. As part of managing the course information, the course administrator carries out the following activities:

Check if course exists If course is new, proceed to the "Create Course" step If course exists, check what operation is desired—whether to modify the course

or remove the course If the modify course operation is selected by the course administrator, the "Modify

Course" activity is performed If the remove course operation is selected by the course administrator, the

"Remove Course" activity is performed

In the first step in this Activity diagram, the system determines whether the course that is to be managed is a new course or an existing course. For managing a new course, a separate activity, "Create Course," is performed. On the other hand, if a course exists, the course administrator can perform two different activities—modify an existing course or remove an existing course. Hence, the system checks the type of operation desired based on which two separate activities can be performed—"Modify Course" or "Remove Course".

This completes the activities involved in managing course information carried out by the course administrator.

46

Activity diagram

Figure 7.2—Activity diagram for the "Manage course information" use case

Figure 7.2 shows the Activity diagram for the "Manage course information" use case. The Activity diagram depicts the steps involved in this workflow. At the end of each of the activities in the "Manage course information" workflow, the Course object is the one that is affected and, hence, we have included this in the Activity diagram.

Summary

The Activity diagram is a simple way to represent the workflows and their steps of an entire system or a subsystem. In the next article of this series, we will learn about Sequence diagrams.

Sequence Diagram in UML

In the last article, we saw Activity diagrams, the notations to be used in Activity diagrams, their significance, and how to build an Activity diagram. We then made an Activity diagram for a specific scenario in our Courseware Management system. One of the most widely used dynamic diagrams in UML is the Sequence diagram, which is the topic of our discussion today. By the end of this article, you will know what a Sequence diagram is, what its elements are, and, you will be able to create Sequence diagrams for your system.

47

Basics

A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of methods in each object, and the order in which the invocation occurs is captured in a Sequence diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic behavior of a system.

A Sequence diagram is two-dimensional in nature. On the horizontal axis, it shows the life of the object that it represents, while on the vertical axis, it shows the sequence of the creation or invocation of these objects.

Because it uses class name and object name references, the Sequence diagram is very useful in elaborating and detailing the dynamic design and the sequence and origin of invocation of objects. Hence, the Sequence diagram is one of the most widely used dynamic diagrams in UML.

Defining a Sequence diagram

A sequence diagram is made up of objects and messages. Objects are represented exactly how they have been represented in all UML diagrams—as rectangles with the underlined class name within the rectangle. A skeleton sequence diagram is shown in Figure 8.1. We shall discuss each of these elements in the next section:

.

Figure 8.1: Sample Sequence diagram, showing the general elements of a sequence diagram

An object can call itself recursively. An arrow commencing and ending at itself denotes this.

Defining a Sequence diagram

Let us take a look at the building blocks of a Sequence diagram.

Elements of a Sequence diagram

A Sequence diagram consists of the following behavioral elements:

48

Element and its description Symbol

Object: The primary element involved in a sequence diagram is an Object—an instance of a class. A Sequence diagram consists of sequences of interaction among different objects over a period of time. An object is represented by a named rectangle. The name to the left of the ":" is the object name and to its right is the class name.

Message: The interaction between different objects in a sequence diagram is represented as messages. A message is denoted by a directed arrow. Depending on the type of message, the notation differs. In a Sequence diagram, you can represent simple messages, special messages to create or destroy objects, and message responses.

Creating a Sequence Diagram

If your UML tool supports modeling class diagrams, you should be able to model Sequence diagrams as well. We will be using the Poseidon Community Edition tool to draw the class diagram. You can use any tool that you are comfortable with.

Figure 8.2: a screen shot of the Poseidon tool.

The screen shot of the Poseidon tool in Figure 8.2 shows the different options to model Sequence diagrams and define interactions between objects participating in these interactions.

49

Case Study—Courseware Management System

From the discussion in the previous section, we are clear on the different notations that are used in Sequence diagrams. Armed with this knowledge, we will proceed to design a Sequence diagram for our Courseware Management System case study application. Because a Sequence diagram represents the dynamic flows in an application, we will aim to represent one of the flows using a Sequence diagram. In Article 3, we had defined the following use cases for the Courseware Management System:

View courses Manage topics for a course Manage course information View course calendar View tutors Manage tutor information Assign courses to tutors

For these use cases, we had modeled the classes and interfaces using the class diagram in Article 4 (parts 1 and 2). Now, we will combine the flow defined by the use cases and the classes involved in the use cases together to represent the different flows in the Courseware Management System.

As an example, we will represent the "Manage course information" flow using a Sequence diagram.

Identifying the activities and transitions for managing course information

The "Manage course information" flow contains one participant: the Course Administrator. Apart from this, there are a few entities with which the course administrator interacts in this flow—Course, Topic, and Tutor. The sequence of steps carried out in the "Manage course information" flow are:

A user who is a course administrator invokes the manage course functionality. The manage course functionality of the course administrator invokes either the

course creation or course modification functionality of a course. After the course is either created or modified, the manage topic functionality of

the course administrator calls the topic creation or modification functionality of a topic.

Finally, the user invokes the assign tutor to course functionality of the course administrator to assign a tutor to the selected course.

Now, let us model these steps into a Sequence diagram for the "Manage course information" functionality.

Sequence diagram

50

Figure 8.3: Activity diagram for the "Manage course information" flow

Figure 8.3 shows the Sequence diagram for the "Manage course information" flow. The Sequence diagram uses the CourseAdministrator, Course, Topic, and Tutor classes that we had defined earlier (see Article 4, parts 1 and 2) when we modeled the different classes in the Courseware Management System. The methods used in the Sequence diagram are the same methods that we had defined for these classes previously.

Summary

A Sequence diagram, as we saw today, represents the interaction among the different objects of a system. In the next article of this series, we will learn about Collaboration diagrams that are similar to Sequence diagrams, but represented as a set of graphs.

Collaboration Diagram in UML

In the last article, we saw what Sequence diagrams are, the notations to be used in Sequence diagrams, their significance, and how to make a Sequence diagram using Poseidon. We then made a Sequence diagram for our Courseware Management System. The next in the dynamic diagrams in UML that we will cover is the Collaboration Diagram.

Basics

In the previous article, we covered the basics of a Sequence diagram. A Sequence diagram is dynamic, and, more importantly, is time ordered. A Collaboration diagram is very similar to a Sequence diagram in the purpose it achieves; in other words, it shows the dynamic interaction of the objects in a system. A distinguishing feature of a Collaboration diagram is that it shows the objects and their association with other objects in the system apart from how they interact with each other. The association between objects is not represented in a Sequence diagram.

A Collaboration diagram is easily represented by modeling objects in a system and representing the associations between the objects as links. The interaction between the objects is denoted by arrows. To identify the sequence of invocation of these objects, a number is placed next to each of these arrows.

Defining a Collaboration diagram

A sophisticated modeling tool can easily convert a collaboration diagram into a sequence diagram and the vice versa. Hence, the elements of a Collaboration diagram are essentially the same as that of a Sequence diagram.

51

Let us see in detail what the elements of Collaboration diagram are.

Elements of a Collaboration diagram

A Collaboration diagram consists of the following elements:

Element and its description Symbol

Object: The objects interacting with each other in the system. Depicted by a rectangle with the name of the object in it, preceded by a colon and underlined.

Relation/Association: A link connecting the associated objects. Qualifiers can be placed on either end of the association to depict cardinality.

Messages: An arrow pointing from the commencing object to the destination object shows the interaction between the objects. The number represents the order/sequence of this interaction.

Creating a Collaboration diagram

Figure 9.1: Screen shot of the Poseidon tool

The screen shot of the Poseidon tool in Figure 9.1 shows the different options to model Collaboration diagrams and define associations and interactions between objects. Since a Collaboration diagram is very similar to a Sequence diagram, a few sophisticated UML tools provide automatic generation of Collaboration diagrams from Sequence diagrams.

52

Case Study—Courseware Management System

In the Sequence diagram in the previous article, we had modeled the interaction for the "Manage course information" scenario. The static model of the Courseware Management System was built as a Class diagram (see Article 4, Part II). We will use these as the basis for modeling the Collaboration diagram of the "Manage course information" scenario.

Identifying states and events of the Course object

Per our Class diagram (see Article 4, Part II), we had defined that the primary (active) entity in the model is the Course Administrator. The Course Administrator interacted with different entities in the system, such as Course, Topic, and Tutor. The following associations were modeled:

The "User" entity interacted with the system as a Course Administrator The Course Administrator entity has a "manages" association with the Course,

Topic, and Tutor entities The Course entity can contain 0 or more Topics

The interactions between these entities for the "manage course information" scenario upon which we modeled the sequence diagram (see Article 8) were as under:

A user who is a course administrator invokes the manage course functionality. The manage course functionality of the course administrator invokes either the

course creation or course modification functionality of a course. After the course is either created or modified, the manage topic functionality of

the course administrator calls the topic creation or modification functionality of a topic.

Finally, the user invokes the assign tutor to course functionality of the course administrator to assign a tutor to the selected course.

Based on this, we will now model these associations and interactions in the Collaboration diagram for the "Manage course information" scenario.

Collaboration diagram

Figure 9.2: Collaboration diagram for the "Manage course information" flow

Figure 9.2 shows the Collaboration diagram for the "Manage course information" flow. The Collaboration diagram uses the CourseAdministrator, Course, Topic, and Tutor

53

classes that we had defined earlier and used to defined the sequence of events in the Sequence diagram in the previous article. Notice that, in addition to the messages that we had represented for the sequence diagrams, we also represent the association between these entities in the Collaboration diagram.

Summary

After this overview of Collaboration diagrams, we will cover the Component diagrams in UML in the next article.

Component Diagrams in UML

The previous articles covered two of the three primary areas in which the UML diagrams are categorized (see Article 1)—Static and Dynamic. The remaining two UML diagrams that fall under the category of Implementation are the Component and Deployment diagrams. In this article, we will discuss the Component diagram.

Basics

The different high-level reusable parts of a system are represented in a Component diagram. A component is one such constituent part of a system. In addition to representing the high-level parts, the Component diagram also captures the inter-relationships between these parts.

So, how are component diagrams different from the previous UML diagrams that we have seen? The primary difference is that Component diagrams represent the implementation perspective of a system. Hence, components in a Component diagram reflect grouping of the different design elements of a system, for example, classes of the system.

Let us briefly understand what criteria to apply to model a component. First and foremost, a component should be substitutable as is. Secondly, a component must provide an interface to enable other components to interact and use the services provided by the component. So, why would not a design element like an interface suffice? An interface provides only the service but not the implementation. Implementation is normally provided by a class that implements the interface. In complex systems, the physical implementation of a defined service is provided by a group of classes rather than a single class. A component is an easy way to represent the grouping together of such implementation classes.

You can model different types of components based on their use and applicability in a system. Components that you can model in a system can be simple executable components or library components that represent system and application libraries used in a system. You also can have file components that represent the source code files of an application or document files that represent, for example, the user interface files such as HTML or JSP files. Finally, you can use components to represent even the database tables of a system as well!

Now that we understand the concepts of a component in a Component diagram, let us see what notations to use to draw a Component diagram.

Elements of a Component Diagram

A Component diagram consists of the following elements:

54

Element and its description Symbol

Component: The objects interacting with each other in the system. Depicted by a rectangle with the name of the object in it, preceded by a colon and underlined.

Class/Interface/Object: Similar to the notations used in class and object diagrams

Relation/Association: Similar to the relation/association used in class diagrams

Creating a Component Diagram

Figure 1 Screen shot of the Poseidon tool

The screen shot of the Poseidon tool in Figure 1 shows the different options to model components in a Component diagram and define interactions between these components.

Case Study—Courseware Management System

From our above discussion of the Component diagram, we will apply the criteria for identifying components to the Courseware Management System. In the first instance, the application may seem to be too simplistic to contain components. But wait! The Courseware Management System has its own share of components, some implicit in the design.

Before we move to identifying the components, let us recap a quick discussion that we had regarding the Model View Controller architecture in the UML Class Diagram Part II article. In this article we had mentioned that the different classes in the class diagram can be partitioned along the lines of the three layers of this architecture viz. Model, View, and Controller. This partitioning of the different classes of the application poses its own

55

challenges, the primary one being how do the classes in one layer interact with the classes in the other layers. Let us elaborate this by reviewing the classes in the Courseware Management System.

Identifying Components in the Courseware Management System

The different classes that we have modeled for the Courseware Management System, such as CourseAdministrator, Course, Topic, CourseCalendar, and Student that fall in the Model layer need to provide a consistent interface to enable other classes and components to interact with them and utilize their services. We can as well define our own set of simple interface methods to access these services. But, to enable our application components to be used by external applications, we can consider basing the components on well-defined component standards.

Hence, based on the technology that you use, you would model these as, maybe Enterprise JavaBeans (EJBs) or Component Object Model/Distributed Component Object Model (COM/DCOM) components. EJB and COM/DCOM are nothing but industry-standard component models that you can base your application component design on. This becomes the "physical" implementation of the logical class diagram. An added advantage of basing your application components on these component models is that your components become "reusable!"

So, if we had introduced a controller class for the application named CMSController, it would interact with the components in the Model layer via the EJB or the COM/DCOM interfaces.

Based on this, let us now draw the components in the Model layer for the Courseware Management System.

Component Diagram

Figure 2 Component diagram for the Courseware Management System

Figure 2 shows the Component diagram for the Model layer of the Courseware Management System. The diagram shows the different components, such as CourseAdministrator, Course, Topic, Tutor, and so forth in the Model layer and how the Controller layer component interacts with these components. The diagram also depicts a

56

database access component that represents a library component that the Model layer components will use to interact with a database.

Summary

In this article, we briefly discussed Component diagrams. In the next article, we will cover the last UML diagram—the Deployment diagram.

57