You are on page 1of 17

1997 to be exact the Object Management Group (OMG) released the Unified Modeling Language (UML).

. One of the purposes of UML was to provide the development community with a stable and common design language that could be used to develop and build computer applications.. Using UML, IT professionals could now read and disseminate system structure and design plans

A LITTLE BACKGROUND
UML was meant to be a unifying language enabling IT professionals to MODEL computer applications. The primary authors were Jim Rumbaugh, Ivar Jacobson, and Grady Booch, One reason UML has become a standard modeling language is that it is programming-language independent. Also, the UML notation set is a language and not a methodology. This is important, because a language, as opposed to a methodology, can easily fit into any company's way of conducting business without requiring change. Since UML is not a methodology, it does not require any formal work products (i.e., "artifacts" in IBM Rational Unified Process lingo). Yet it does provide several types of diagrams that, when used within a given methodology, increase the ease of understanding an application under development. There is more to UML than these diagrams, but for our purposes here, the diagrams offer a good introduction to the language and the principles behind its use.

By placing standard UML diagrams in your methodology's work products, you make it easier for join your project and quickly become productive for UMLproficient people . The most useful, standard UML diagrams are:
1. 2. 3. 4. 5.

USE CASE DIAGRAM, CLASS DIAGRAM, SEQUENCE DIAGRAM, STATECHART DIAGRAM, ACTIVITY DIAGRAM,

6. 7.

COMPONENT DIAGRAM, DEPLOYMENT DIAGRAM.

USE-CASE DIAGRAM
A use case illustrates a UNIT OF FUNCTIONALITY provided by the system. The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system, including the relationship of "actors" (human beings who will interact with the system) to essential processes, as well as the relationships among different use cases. Use-case diagrams generally show groups of use cases either all use cases for the complete system, or a breakout of a particular group of use cases with related functionality (e.g., all security administration-related use cases). To show a use case on a use-case diagram, you draw an oval in the middle of the diagram and put the name of the use case in the center of, or below, the oval. To draw an actor (indicating a system user) on a use-case diagram, you draw a stick person to the left or right of your diagram (and just in case you're wondering, some people draw prettier stick people than others). Use simple lines to depict relationships between actors and use cases, as shown in Figure 1.

Figure 1: Sample use-case diagram

A use-case diagram is typically used to communicate the high-level functions of the system and the system's scope. By looking at our use-case diagram in Figure 1, you can easily tell the functions that our example system provides.
1.

This system lets the band manager view a sales statistics report and the Billboard 200 report for the band's CDs. It also lets the record manager view a sales statistics report and the Billboard 200 report for a particular CD. The diagram also tells us that our system delivers Billboard reports from an external system called Billboard Reporting Service. In addition, the absence of use cases in this diagram shows what the system doesn't do. For example, it does not provide a way for a band manager to listen to songs from the different albums on the Billboard 200 i.e., we see no reference to a use case called Listen to Songs from Billboard 200.

2.

3.

4.

5.

With clear and simple use-case descriptions provided on such a diagram, a project sponsor can easily see if needed functionality is present or not present in the system.

CLASS DIAGRAM The class diagram shows how the different entities (people, things, and data) relate to each other; in other words, it shows the static structures of the system. A class diagram can be used to display logical classes, which are typically the kinds of things the business people in an organization talk about rock bands, CDs, radio play; or loans, home mortgages, car loans, and interest rates. Class diagrams can also be used to show implementation classes, which are the things that programmers typically deal with. An implementation class diagram will probably show some of the same classes as the logical classes diagram. The implementation class diagram won't be drawn with the same attributes, however, because it will most likely have references to things like Vectors and HashMaps. A class is depicted on the class diagram as a rectangle with three horizontal sections, as shown in Figure 2.
1. 2. 3.

The upper section shows the class's name; The middle section contains the class's attributes; The lower section contains the class's operations (or "methods").

Figure 2: Sample class object in a class diagram

Almost every developer knows what this diagram is, yet I find that most programmers draw the relationship lines incorrectly.

1.

For a class diagram like the one in Figure 3, you should draw the inheritance relationship1 using a line with an arrowhead at the top pointing to the super class, and the arrowhead should be a completed triangle. [ An association relationship should be a solid line if both classes are aware of each other and a line with an open arrowhead if the association is known by only one of the classes.

2.

3.

Figure 3: A complete class diagram, including the class object shown in Figure 2

In Figure 3, 1. we see both the inheritance relationship and two association relationships.
2. 3.

The CDSalesReport class inherits from the Report class. A CDSalesReport is associated with one CD, but the CD class doesn't know anything about the CDSalesReport class. The CD and the Band classes both know about each other, and both classes can be associated to one or more of each other.

4.

SEQUENCE DIAGRAM Sequence diagrams show a detailed flow for a specific use case or even just part of a specific use case. They are almost self explanatory; they show the calls between the different objects in their sequence and can show, at a detailed level, different calls to different objects. A sequence diagram has two dimensions: The vertical dimension shows the sequence of messages/calls in the time order that they occur AND horizontal dimension shows the object instances to which the messages are sent. A sequence diagram is very simple to draw.

1.

Across the top of your diagram, identify the class instances (objects) by putting each class instance inside a box (see Figure 4).

2.

In the box, put the class instance name and class name separated by a space/colon/space " : " (e.g., myReportGenerator : ReportGenerator).

3.

If a class instance sends a message to another class instance, draw a line with an open arrowhead pointing to the receiving class instance; place the name of the message/method above the line.

4.

Optionally, for important messages, you can draw a dotted line with an arrowhead pointing back to the originating class instance; label the return value above the dotted line.

5.

Personally, we should always like to include the return value lines because we will find the extra details make it easier to read.

Reading a sequence diagram is very simple.


1.

Start at the top left corner with the "driver" class instance that starts the sequence. Then follow each message down the diagram. Remember: Even though the example sequence diagram in Figure 4 shows a return message for each sent message, this is optional.

2. 3.

Figure 4: A sample sequence diagram

Larger view of Figure 4.

By reading our sample sequence diagram in Figure 4, you can see how to create a CD Sales Report.
1. 2.

The aServlet object is our example driver. aServlet sends a message to the ReportGenerator class instance named gen. The message is labeled generateCDSalesReport, which means that the ReportGenerator object implements this message handler. On closer inspection, the generateCDSalesReport message label has cdId in parentheses, which means that aServlet is passing a variable named cdId with the message. When gen instance receives a generateCDSalesReport message, it then makes subsequent calls to the CDSalesReport class, and an actual instance of a CDSalesReport called aCDReport gets returned. The gen instance then makes calls to the returned aCDReport instance, passing it parameters on each message call. At the end of the sequence, the gen instance returns aCDReport to its caller aServlet.

3.

4.

5.

6.

Please note: The sequence diagram in Figure 4 is arguably too detailed for a typical sequence diagram. However, I believe it is simple enough to understand, and it shows how nested calls are drawn. Also, with junior developers, sometimes it is necessary to break down sequences to this explicit level to help them understand what they are supposed to do.

Statechart diagram The statechart diagram models the different states that a class can be in and how that class transitions from state to state. It can be argued that every class has a state, but that every class shouldn't have a statechart diagram.

Only classes with "interesting" states that is, classes with three or more potential states during system activity should be modeled. As shown in Figure 5, the notation set of the statechart diagram has five basic elements: 1. the initial starting point, which is drawn using a solid circle;
2.

a transition between states, which is drawn using a line with an open arrowhead;

3. 4. 5.

a state, which is drawn using a rectangle with rounded corners; a decision point, which is drawn as an open circle; and one or more termination points, which are drawn using a circle with a solid circle inside it.

To draw a statechart diagram, begin with a starting point and a transition line pointing to the initial state of the class. Draw the states themselves anywhere on the diagram, and then simply connect them using the state transition lines.
Figure 5: Statechart diagram showing the various states that classes pass through in a functioning system

Larger view of Figure 5.

The example statechart diagram in Figure 5 shows some of the potential information they can communicate.

For instance, you can tell that loan processing begins in the Loan Application state.

When the pre-approval process is done, depending on the outcome, you move to either the Loan Pre-approved state or the Loan Rejected state.

This decision, which is made during the transition process, is shown with a decision point the empty circle in the transition line.

By looking at the example, a person can tell that a loan cannot go from the Loan Pre-Approved state to the Loan in Maintenance state without going through the Loan Closing state.

Also, by looking at our example diagram, a person can tell that all loans will end in either the Loan Rejected state or the Loan in Maintenance state.

ACTIVITY DIAGRAM
1.

Activity diagrams show the procedural flow of control between two or more class objects while processing an activity. Activity diagrams can be used to model higher-level business process at the business unit level, or to model low-level internal class actions. activity diagrams are best used to model higher-level processes, such as how the company is currently doing business, or how it would like to do business. This is because activity diagrams are "less technical" in appearance, compared to sequence diagrams, and business-minded people tend to understand them more quickly. Like a statechart diagram, the activity diagram starts with a solid circle connected to the initial activity. The activity is modeled by drawing a rectangle with rounded edges, enclosing the activity's name. Activities can be connected to other activities through transition lines, or to decision points that connect to different activities guarded by conditions of the decision point. Activities that terminate the modeled process are connected to a termination point (just as in a statechart diagram). Optionally, the activities can be grouped into swimlanes, which are used to indicate the object that actually performs the activity, as shown in Figure 6.

2.

3.

4.

An activity diagram's notation set is similar to that used in a statechart diagram.

Figure 6: Activity diagram, with two swimlanes to indicate control of activity by two objects: the band manager, and the reporting tool

1.

In our example activity diagram, we have two swimlanes because we have two objects that control separate activities: a band manager and a reporting tool. The process starts with the band manager electing to view the sales report for one of his bands. The reporting tool then retrieves and displays all the bands that person manages and asks him to choose one. After the band manager selects a band, the reporting tool retrieves the sales information and displays the sales report. The activity diagram shows that displaying the report is the last step in the process.

2.

3.

4.

5.

COMPONENT DIAGRAM
The component diagram's main purpose is to show the structural relationships between the components of a system. In UML 1.1, a component represented implementation items, such as

files and executables. Unfortunately, this conflicted with the more common use of the term component," which refers to things such as COM components. Over time and across successive releases of UML, the original UML meaning of components was mostly lost. UML 2 officially changes the essential meaning of the component concept; in UML 2, components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces. Although the UML 2 specification does not strictly state it, components are larger design units that represent things that will typically be implemented using replaceable" modules. But, unlike UML 1.x, components are now strictly logical, design-time constructs. The idea is that you can easily reuse and/or substitute a different component implementation in your designs because a component encapsulates behavior and implements specified interfaces. [Note: The physical items that UML1.x called components are now called "artifacts" in UML 2. An artifact is a physical unit, such as a file, executable, script, database, etc. Only artifacts live on physical nodes; classes and components do not have "location." However, an artifact may manifest components and other classifiers (i.e., classes). A single component could be manifested by multiple artifacts, which could be on the same or different nodes, so a single component could indirectly be implemented on multiple nodes.] In component-based development (CBD), component diagrams offer architects a natural format to begin modeling a solution. Component diagrams allow an architect to verify that a system's required functionality is being implemented by components, thus ensuring that the eventual system will be acceptable. In addition, component diagrams are useful communication tools for various groups. The diagrams can be presented to key project stakeholders and implementation staff. While component diagrams are generally geared towards a system's implementation staff, component diagrams can generally put stakeholders at ease because the diagram presents an early understanding of the overall system that is being built. Developers find the component diagram useful because it provides them with a high-level, architectural view of the system that they will be building, which helps developers begin formalizing a roadmap for the implementation, and make decisions about task assignments and/or needed skill enhancements. System administrators find component diagrams useful because they get an early view of the logical software components that will be running on their systems. Although system administrators will not be able to identify the physical machines or the physical executables from the diagram, a component diagram will nevertheless be welcomed because it provides early information about the components and their relationships (which allows sys-admins to loosely plan ahead).

The notation
The component diagram notation set now makes it one of the easiest UML diagrams to draw. Figure 1 shows a simple component diagram using the former UML 1.4 notation; the example shows a relationship between two components: an Order System component that uses the Inventory System component. As you can see, a component in UML 1.4 was drawn as a rectangle with two smaller rectangles protruding from its left side.

Figure 1: This simple component diagram shows the Order System's general dependency using UML 1.4 notation

The above UML 1.4 notation is still supported in UML 2. However, the UML 1.4 notation set did not scale well in larger systems. For that reason, UML 2 dramatically enhances the notation set of the component diagram, as we will see throughout the rest of this article. The UML 2 notation set scales better, and the notation set is also more informative while maintaining its ease of understanding. Let's step through the component diagram basics according to UML 2.

The basics
Drawing a component in UML 2 is now very similar to drawing a class on a class diagram. In fact, in UML 2 a component is merely a specialized version of the class concept. Which means that the notation rules that apply to the class classifier also apply to the component classifier. (If you read and understood my previous article [http://www106.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/index.html] regarding structure diagrams in general, and class diagrams in particular, you are well under way to understanding component diagrams.) In UML 2, a component is drawn as a rectangle with optional compartments stacked vertically. A high-level, abstracted view of a component in UML 2 can be modeled as just a rectangle with the component's name and the component stereotype text and/or icon. The component stereotype's text is component" and the component stereotype icon is a rectangle with two smaller rectangles protruding on its left side (the UML 1.4 notation element for a component). Figure 2 shows three different ways a component can be drawn using the UML 2 specification.

Figure 2: The different ways to draw a component's name compartment

When drawing a component on a diagram, it is important that you always include the component stereotype text (the word "component" inside double angle brackets, as shown in Figure 2) and/or icon. The reason? In UML, a rectangle without any stereotype classifier is interpreted as a class element. The component stereotype and/or icon distinguishes this rectangle as a component element.

Deployment diagram
The deployment diagram shows how a system will be physically deployed in the hardware environment. Its purpose is to show where the different components of the system will physically run and how they will communicate with each other. Since the diagram models the physical runtime, a system's production staff will make considerable use of this diagram.
The notation in a deployment diagram includes the notation elements used in a component diagram, with a couple of additions, including the concept of a node. A node represents either a physical machine or a virtual machine node (e.g., a mainframe node). To model a node, simply draw a three-dimensional cube with the name of the node at the top of the cube. Use the naming convention used in sequence diagrams: [instance name] : [instance type] (e.g., "w3reporting.myco.com : Application Server"). Figure 8: Deployment diagram

Larger view of Figure 8. The deployment diagram in Figure 8 shows that the users access the Reporting Tool by using a browser running on their local machine and connecting via HTTP over their company's intranet to the Reporting Tool. This tool physically runs on the Application Server named w3reporting.myco.com. The diagram shows the Reporting Tool component drawn inside of IBM WebSphere, which in turn is drawn inside of the node w3.reporting.myco.com. The Reporting Tool connects to its reporting database using the Java language to IBM DB2's JDBC interface, which then communicates to the actual DB2 database running on the server named

db1.myco.com using native DB2 communication. In addition to talking to the reporting database, the Report Tool component communicates via SOAP over HTTPS to the Billboard Service. GENERAL READING

Software development methods


UML is not a development method by itself;[11] however, it was designed to be compatible with the leading object-oriented software development methods of its time (for example OMT, Booch method, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notations (for example OMT), and new methods have been created based on UML, such as IBM Rational Unified Process (RUP). Others include Abstraction Method and Dynamic Systems Development Method.

Modeling
It is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphic representation of a system's model. The model also contains documentation that drives the model elements and diagrams (such as written use cases). UML diagrams represent two different views of a system model:[12]

Static (or structural) view: emphasizes the static structure of the system using objects, attributes, operations and relationships. The structural view includes class diagrams and composite structure diagrams. Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams.

UML models can be exchanged among UML tools by using the XMI interchange format.

Diagrams overview

UML diagrams
Structural UML diagrams Class diagram Component diagram Composite structure diagram Deployment diagram Object diagram Package diagram Profile diagram Behavioural UML diagrams Activity diagram Communication diagram Interaction overview diagram Sequence diagram State diagram Timing diagram Use case diagram UML 2.2 has 14 types of diagrams divided into two categories.[13] Seven diagram types represent structural information, and the other seven represent general types of behavior, including four that represent different aspects of interactions. These diagrams can be categorized hierarchically as shown in the following class diagram:

UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams; this flexibility has been partially restricted in UML 2.0. UML profiles may define additional diagram types or extend existing diagrams with additional notations. In keeping with the tradition of engineering drawings,[citation needed] a comment or note explaining usage, constraint, or intent is allowed in a UML diagram. Structure diagrams Structure diagrams emphasize the things that must be present in the system being modeled. Since structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems.

Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes. Component diagram: describes how a software system is split up into components and shows the dependencies among these components. Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes possible. Deployment diagram: describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware. Object diagram: shows a complete or partial view of the structure of an example modeled system at a specific time. Package diagram: describes how a system is split up into logical groupings by showing the dependencies among these groupings. Profile diagram: operates at the metamodel level to show stereotypes as classes with the <<stereotype>> stereotype, and profiles as packages with the <<profile>> stereotype. The extension relation (solid line with closed, filled arrowhead) indicates what metamodel element a given stereotype is extending.

Class diagram

Component diagram

Composite structure diagram

Deployment diagram

Object diagram

Package diagram Behavior diagrams Behavior diagrams emphasize what must happen in the system being modeled. Since behavior diagrams illustrate the behavior of a system, they are used extensively to describe the functionality of software systems.

Activity diagram: describes the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control. UML state machine diagram: describes the states and state transitions of the system. Use Case Diagram: describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.

UML Activity Diagram

State Machine diagram

Use Case Diagram Interaction diagrams Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. They represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system. Interaction overview diagram: provides an overview in which the nodes represent communication diagrams. Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages. Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints.

Communication diagram

Interaction overview diagram

Sequence diagram

You might also like