UML (Unified Modeling Language)The Unified Modeling Language (UML) is a standard language for specifying, visualizing,constructing, and documenting the artifacts of software systems, as well as for business modelingand other non-software systems. The UML represents a collection of best engineering practicesthat have proven successful in the modeling of large and complex systems. The UML is a veryimportant part of developing object oriented software and the software development process.The UML uses mostly graphical notations to express the design of software projects. Using theUML helps project teams communicate, explore potential designs, and validate the architecturaldesign of the software.Goals of UMLThe primary goals in the design of the UML were: 1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. 2. Provide extensibility and specialization mechanisms to extend the core concepts. 3. Be independent of particular programming languages and development processes. 4. Provide a formal basis for understanding the modeling language. 5. Encourage the growth of the OO tools market. 6. Support higher-level development concepts such as collaborations, frameworks, patterns and components. 7. Integrate best practices.Why Use UML?As the strategic value of software increases for many companies, the industry looks fortechniques to automate the production of software and to improve quality and reduce cost andtime-to-market. These techniques include component technology, visual programming, patternsand frameworks. Businesses also seek techniques to manage the complexity of systems as theyincrease in scope and scale. In particular, they recognize the need to solve recurring architecturalproblems, such as physical distribution, concurrency, replication, security, load balancing andfault tolerance. Additionally, the development for the World Wide Web, while making some thingssimpler, has exacerbated these architectural problems. The Unified Modeling Language (UML)was designed to respond to these needs.Types of UML DiagramsEach UML diagram is designed to let developers and customers view a software system from adifferent perspective and in varying degrees of abstraction. UML diagrams commonly created invisual modeling tools include:Use Case Diagram displays the relationship among actors and use cases.1Class Diagram models class structure and contents using design elements such as classes,packages and objects. It also displays relationships such as containment, inheritance,associations and others.Interaction Diagrams
• Sequence Diagram displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects). • Collaboration Diagram displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages.State Diagram displays the sequences of states that an object of an interaction goes throughduring its life in response to received stimuli, together with its responses and actions.Activity Diagram displays a special state diagram where most of the states are action states andmost of the transitions are triggered by completion of the actions in the source states. Thisdiagram focuses on flows driven by internal processing.Physical Diagrams • Component Diagram displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at run times well as at more than one time.1 • Deployment Diagram displays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units.Use Case DiagramsA use case is a set of scenarios that describing an interaction between a user and a system. Ause case diagram displays the relationship among actors and use cases. The two maincomponents of a use case diagram are use cases and actors.An actor is represents a user or another system that will interact with the system you aremodeling. A use case is an external view of the system that represents some action the usermight perform in order to complete a task.When to Use: Use Cases DiagramsUse cases are used in almost every project. They are helpful in exposing requirements andplanning the project. During the initial stage of a project most use cases should be defined, but asthe project continues more might become visible.How to Draw: Use Cases Diagrams
Use cases are a relatively easy UML diagram to draw, but this is a very simplified example. Thisexample is only meant as an introduction to the UML and use cases. If you would like to learnmore see the Resources page for more detailed resources on UML.Start by listing a sequence of steps a user might take in order to complete an action. Forexample a user placing an order with a sales company might follow these steps. 1. Browse catalog and select items. 2. Call sales representative. 3. Supply shipping information. 4. Supply payment information. 5. Receive conformation number from salesperson.These steps would generate this simple use case diagram:This example shows the customer as a actor because the customer is using the ordering system.The diagram takes the simple steps listed above and shows them as actions the customer mightperform. The salesperson could also be included in this use case diagram because thesalesperson is also interacting with the ordering system.From this simple diagram the requirements of the ordering system can easily be derived. Thesystem will need to be able to perform actions for all of the use cases listed. As the project
progresses other use cases might appear. The customer might have a need to add an item to anorder that has already been placed. This diagram can easily be expanded until a completedescription of the ordering system is derived capturing all of the requirements that the system willneed to perform.Class DiagramsClass diagrams are widely used to describe the types of objects in a system and theirrelationships. Class diagrams model class structure and contents using design elements such asclasses, packages and objects. Class diagrams describe three different perspectives whendesigning a system, conceptual, specification, and implementation.1 These perspectivesbecome evident as the diagram is created and help solidify the design. This example is onlymeant as an introduction to the UML and class diagrams. If you would like to learn more see theResources page for more detailed resources on UML.Classes are composed of three things: a name, attributes, and operations. Below is an exampleof a class.Class diagrams also display relationships such as containment, inheritance, associations andothers.2 Below is an example of an associative relationship:The association relationship is the most common relationship in a class diagram. The associationshows the relationship between instances of classes. For example, the class Order is associatedwith the class Customer. The multiplicity of the association denotes the number of objects thatcan participate in then relationship. For example, an Order object can be associated to only onecustomer, but a customer can be associated to many orders.Another common relationship in class diagrams is a generalization. A generalization is usedwhen two classes are similar, but have some differences. Look at the generalization below:
In this example the classes Corporate Customer and Personal Customer have some similaritiessuch as name and address, but each class has some of its own attributes and operations. Theclass Customer is a general form of both the Corporate Customer and Personal Customerclasses.1 This allows the designers to just use the Customer class for modules and do notrequire in-depth representation of each type of customer.When to Use: Class DiagramsClass diagrams are used in nearly all Object Oriented software designs. Use them to describe theClasses of the system and their relationships to each other.How to Draw: Class DiagramsClass diagrams are some of the most difficult UML diagrams to draw. To draw detailed anduseful diagrams a person would have to study UML and Object Oriented principles for a longtime. Therefore, this page will give a very high level overview of the process. To find list ofwhere to find more information see the Resources page.Before drawing a class diagram consider the three different perspectives of the system thediagram will present; conceptual, specification, and implementation. Try not to focus on oneperspective and try see how they all work together.When designing classes consider what attributes and operations it will have. Then try todetermine how instances of the classes will interact with each other. These are the very first stepsof many in developing a class diagram. However, using just these basic techniques one candevelop a complete view of the software system.
This example is only meant as an introduction to the UML and use cases. If you would like tolearn more see the Resources page for more detailed resources on UML.Interaction DiagramsInteraction diagrams model the behavior of use cases by describing the way groups of objectsinteract to complete the task. The two kinds of interaction diagrams are sequence andcollaboration diagrams. This example is only meant as an introduction to the UML andinteraction diagrams. If you would like to learn more see the Resources page for a list of moredetailed resources on UML.When to Use: Interaction DiagramsInteraction diagrams are used when you want to model the behavior of several objects in a usecase. They demonstrate how the objects collaborate for the behavior. Interaction diagrams donot give a in depth representation of the behavior. If you want to see what a specific object isdoing for several use cases use a state diagram. To see a particular behavior over many usecases or threads use an activity diagrams.How to Draw: Interaction DiagramsSequence diagrams, collaboration diagrams, or both diagrams can be used to demonstrate theinteraction of objects in a use case. Sequence diagrams generally show the sequence of events
that occur. Collaboration diagrams demonstrate how objects are statically connected. Bothdiagrams are relatively simple to draw and contain similar elements. 1Sequence diagrams:Sequence diagrams demonstrate the behavior of objects in a use case by describing the objectsand the messages they pass. the diagrams are read left to right and descending. The examplebelow shows an object of class 1 start the behavior by sending a message to an object of class2. Messages pass between the different objects until the object of class 1 receives the finalmessage.Below is a slightly more complex example. The light blue vertical recrtangles the objectsactivation while the green vertical dashed lines represent the life of the object. The green verticalrectangles represent when a particular object has control. The represents when the object isdestroyed. This diagrams also shows conditions for messages to be sent to other object. Thecondition is listed between brackets next to the message. For example, a [condition] has to bemet before the object of class 2 can send a message() to the object of class 3.The next diagram shows the beginning of a sequence diagram for placing an order. The objectan Order Entry Window is created and sends a message to an Order object to prepare the order.
Notice the the names of the objects are followed by a colon. The names of the classes theobjects belong to do not have to be listed. However the colon is required to denote that it is thename of an object following the objectName:className naming system.Next the Order object checks to see if the item is in stock and if the [InStock] condition is met itsends a message to create an new Delivery Item object.The next diagrams adds another conditional message to the Order object. If the item is[OutOfStock] it sends a message back to the Order Entry Window object stating that the object isout of stack.
This simple diagram shows the sequence that messages are passed between objects tocomplete a use case for ordering an item.Collaboration diagrams:Collaboration diagrams are also relatively easy to draw. They show the relationship betweenobjects and the order of messages passed between them. The objects are listed as icons andarrows indicate the messages being passed between them. The numbers next to the messagesare called sequence numbers. As the name suggests, they show the sequence of the messagesas they are passed between the objects. There are many acceptable sequence numberingschemes in UML. A simple 1, 2, 3... format can be used, as the example below shows, or formore detailed and complex diagrams a 1, 1.1 ,1.2, 1.2.1... scheme can be used.The example below shows a simple collaboration diagram for the placing an order use case. Thistime the names of the objects appear after the colon, such as :Order Entry Window following theobjectName:className naming convention. This time the class name is shown to demonstratethat all of objects of that class will behave the same way.State DiagramsState diagrams are used to describe the behavior of a system. State diagrams describe all of thepossible states of an object as events occur. Each diagram usually represents objects of a singleclass and track the different states of its objects through the system.When to Use: State Diagrams
Use state diagrams to demonstrate the behavior of an object through many use cases of thesystem. Only use state diagrams for classes where it is necessary to understand the behavior ofthe object through the entire system. Not all classes will require a state diagram and statediagrams are not useful for describing the collaboration of all objects in a use case. Statediagrams are other combined with other diagrams such as interaction diagrams and activitydiagrams.How to Draw: State DiagramsState diagrams have very few elements. The basic elements are rounded boxes representing thestate of the object and arrows indicting the transition to the next state. The activity section of thestate symbol depicts what activities the object will be doing while it is in that state.All state diagrams being with an initial state of the object. This is the state of the object when it iscreated. After the initial state the object begins changing states. Conditions based on theactivities can determine what the next state the object transitions to.Below is an example of a state diagram might look like for an Order object. When the objectenters the Checking state it performs the activity "check items." After the activity is completed theobject transitions to the next state based on the conditions [all items available] or [an item is notavailable]. If an item is not available the order is canceled. If all items are available then theorder is dispatched. When the object transitions to the Dispatching state the activity "initiatedelivery" is performed. After this activity is complete the object transitions again to the Deliveredstate.
State diagrams can also show a super-state for the object. A super-state is used when manytransitions lead to the a certain state. Instead of showing all of the transitions from each state tothe redundant state a super-state can be used to show that all of the states inside of the super-state can transition to the redundant state. This helps make the state diagram easier to read.The diagram below shows a super-state. Both the Checking and Dispatching states cantransition into the Canceled state, so a transition is shown from a super-state named Active tothe state Cancel. By contrast, the state Dispatching can only transition to the Delivered state, sowe show an arrow only from the Dispatching state to the Delivered state.Activity DiagramsActivity diagrams describe the workflow behavior of a system. Activity diagrams are similar tostate diagrams because activities are the state of doing something. The diagrams describe the
state of activities by showing the sequence of activities performed. Activity diagrams can showactivities that are conditional or parallel.When to Use: Activity DiagramsActivity diagrams should be used in conjunction with other modeling techniques such asinteraction diagrams and state diagrams. The main reason to use activity diagrams is to modelthe workflow behind the system being designed. Activity Diagrams are also useful for: analyzinga use case by describing what actions need to take place and when they should occur; describinga complicated sequential algorithm; and modeling applications with parallel processes.However, activity diagrams should not take the place of interaction diagrams and statediagrams. Activity diagrams do not give detail about how objects behave or how objectscollaborate.How to Draw: Activity DiagramsActivity diagrams show the flow of activities through the system. Diagrams are read from top tobottom and have branches and forks to describe conditions and parallel activities. A fork is usedwhen multiple activities are occurring at the same time. The diagram below shows a fork afteractivity1. This indicates that both activity2 and activity3 are occurring at the same time. Afteractivity2 there is a branch. The branch describes what activities will take place based on a set ofconditions. All branches at some point are followed by a merge to indicate the end of theconditional behavior started by that branch. After the merge all of the parallel activities must becombined by a join before transitioning into the final activity state.
Below is a possible activity diagram for processing an order. The diagram shows the flow ofactions in the systems workflow. Once the order is received the activities split into two parallelsets of activities. One side fills and sends the order while the other handles the billing. On theFill Order side, the method of delivery is decided conditionally. Depending on the condition eitherthe Overnight Delivery activity or the Regular Delivery activity is performed. Finally the parallelactivities combine to close the order.
Physical DiagramsThere are two types of physical diagrams: deployment diagrams and component diagrams.Deployment diagrams show the physical relationship between hardware and software in asystem. Component diagrams show the software components of a system and how they arerelated to each other. These relationships are called dependencies. 1When to Use: Physical DiagramsPhysical diagrams are used when development of the system is complete. Physical diagrams areused to give descriptions of the physical information about a system.How to Draw: Physical Diagrams
Many times the deployment and component diagrams are combined into one physical diagram.A combined deployment and component diagram combines the features of both diagrams intoone diagram.The deployment diagram contains nodes and connections. A node usually represents a piece ofhardware in the system. A connection depicts the communication path used by the hardware tocommunicate and usually indicates a method such as TCP/IP.The component diagram contains components and dependencies. Components represent thephysical packaging of a module of code. The dependencies between the components show howchanges made to one component may affect the other components in the system. Dependenciesin a component diagram are represented by a dashed line between two or more components.Component diagrams can also show the interfaces used by the components to communicate toeach other. 1The combined deployment and component diagram below gives a high level physical descriptionof the completed system. The diagram shows two nodes which represent two machinescommunicating through TCP/IP. Component2 is dependant on component1, so changes tocomponent 2 could affect component1. The diagram also depicts component3 interfacing withcomponent1. This diagram gives the reader a quick overall view of the entire system.