uml guidelines
DESCRIPTION
Simple guidelines for the usage of UML modelingTRANSCRIPT
UML GUIDELINES
1 DOCUMENT INFORMATION
1.1 Table of Contents
1 DOCUMENT INFORMATION........................................................................................................................2
1.1 Table of Contents.............................................................................................................................................2
1.2 Table of recommendations.............................................................................................................................2
2 GENERAL...........................................................................................................................................................4
3 PACKAGE DIAGRAM......................................................................................................................................6
4 USE CASE DIAGRAM.....................................................................................................................................10
5 CLASS DIAGRAM...........................................................................................................................................11
6 SEQUENCE DIAGRAM .................................................................................................................................13
7 STATECHART DIAGRAM.............................................................................................................................14
8 COMPONENT DIAGRAM.............................................................................................................................15
8.1 Standard UML stereotypes for components..............................................................................................15
8.2 Organizing components...............................................................................................................................16
8.3 Modeling executables and libraries............................................................................................................17
8.4 Modeling tables, files and documents........................................................................................................18
8.5 Modeling an API............................................................................................................................................18
8.6 Modeling source code...................................................................................................................................19
9 DEPLOYMENT DIAGRAM............................................................................................................................21
10 UML DIAGRAMS IN SPECIFICATION DOCUMENTS.........................................................................23
10.1 General..........................................................................................................................................................23
10.2 Functional specification..............................................................................................................................23
10.3 System architecture/subsystem architecture specification...................................................................24
10.4 Module specification...................................................................................................................................24
11 APPENDIX......................................................................................................................................................25
11.1 Components.................................................................................................................................................2511.1.1 Logical and physical views.....................................................................................................................2511.1.2 Components vs. classes...........................................................................................................................2511.1.3 Binary replacealibity................................................................................................................................2511.1.4 Types of components...............................................................................................................................25
11.2 FAQ...............................................................................................................................................................26
1.2 Table of recommendations
REC. 1 NOT ALL THE DIAGRAMS IN UML ARE USEFUL..........................................................................4
REC. 2 USE NATURAL LANGUAGE TO COMPLEMENT UML MODELS...............................................4
REC. 3 AVOID OVERMODELING....................................................................................................................5
REC. 4 USE THE PACKAGE DIAGRAM TO DIVIDE THE DIAGRAM INTO MORE MANAGEABLE PIECES..........................................................................................................................................................6
REC. 5 USE THE PACKAGE DIAGRAM TO REPRESENT THE HIGH LEVEL VIEW OF THE SYSTEM.........7
REC. 6 ATTACH UML STEREOTYPES TO PACKAGES TO DESCRIBE THE TYPE OF PACKAGE......9
REC. 7 DEFINE ONLY THE MOST ESSENTIAL USE CASES......................................................................10
REC. 8 USE A STANDARD FORMAT TO DESCRIBE USE CASES TEXTUALLY....................................10
REC. 9 AVOID TOO MUCH DETAIL IN CLASS DIAGRAMS....................................................................11
REC. 10 AVOID COMPLEX ASSOCIATIONS BETWEEN CLASSES..........................................................11
REC. 11 NAME AN ASSOCIATION ONLY IF IMPROVES UNDERSTANDING....................................11
REC. 12 ATTACH UML STEREOTYPES TO CLASSES TO DESCRIBE THE TYPE OF CLASS..............11
REC. 13 DESCRIBE ONLY THE MOST IMPORTANT SEQUENCES..........................................................13
REC. 14 DESCRIBE EXTERNAL OBJECTS WITH AN ACTOR SYMBOL IN SEQUENCE DIAGRAMS.13
REC. 15 USAGE OF ARROW SYMBOLS IN SEQUENCE DIAGRAMS......................................................13
REC. 16 USE THE STATECHART DIAGRAM ONLY IN SPECIAL CASES..............................................14
REC. 17 USE THE RECOMMENDED COMPONENTS IN DEPLOYMENT DIAGRAM.........................22
2 GENERAL
These guidelines are based on an approach that unnecessary activities are harmful. With real software projects, there is no time to play around with useless diagrams or theories. Therefore, only the most essential techniques in deploying UML are recommended in this document.
You don't have to be on a highceremony project to find using bits of the UML handy. You don't have to use all of it, just the bits you find useful.
Rec. 1 Not all the diagrams in UML are useful.
The most important diagrams in UML are:
• class diagram
• sequence diagram
The following diagrams in UML are needed sometimes:
• use case diagram,
• statechart diagram
• component diagram
Use the following diagrams only in special cases:
• deployment diagram
• collaboration diagram
• activity diagram
Rec. 2 Use natural language to complement UML models.
Natural language is an essential modeling tool. Natural language is the way to capture requirements; it is typically used whenever there is a need to communicate with end users. Natural language is also used if there is a need to emphasize something related to diagrams.
The UML diagram is usually not enough to describe the system. Textual descriptions of diagrams are also needed in the documents. You can also use the UML note in diagrams to give more information.
The use-case m odel specifies the behavior and surroundings of the system in term s of use cases and actors. The description of an actor or use case is found in its specification, w hich is displayed w hen double-clicking on the actor or use case. The docum entation field on the G eneral tab, is displayed in the application w indow w hen you select and actor or use case. (If not, click D ocum entation on the View m enu.)
U se-C ase M odel of the O rder System
Instead of describing the flow of events of a use case in the docum entation field of its specification, an external docum ent w ith the description can be connected to the use case, w hich is done on the D iagram tab in its specification.
The use cases constitute the functional requirem ents on the system . They also define how the requirem ents are distributed am ong the design objects of the system , i.,e. how the objects interact to perform each use case. In the Brow ser you can see that the M anage O rder use case is described in tw o interaction diagram s of the type sequence diagram .
M anage O rder
M anage Custom er R egister
O rder Adm inistrator
Execute O rder
M anage Articles
Store Adm inistrator
Figure 1. Use natural language to complement UML models.
Rec. 3 Avoid overmodeling.
Choose undermodeling instead of overmodeling. Draw the diagrams at the proper level of abstraction and illustrate only what is essential. Make sure that the diagrams are clear and readable. Add textual commentary instead of overmodeling.
3 PACKAGE DIAGRAM
One of the oldest questions in software methods is: How do you beak down a large system into smaller systems? We ask this question because as systems get large, it becomes difficult to understand them and the changes we make to them.
One idea is to group the classes together into higherlevel units. This idea, applied very loosely, appears in many objectoriented methods. In the UML, this grouping mechanism is called the package.
The idea of packages can be applied to any model element, not just classes. Without some heuristics to group classes together, the grouping becomes arbitrary. The one I have found most useful and the one stressed most in the UML is the dependency.
Rec. 4 Use the package diagram to divide the diagram into more manageable pieces.
Packages are a vital tool for large projects. If your diagram doesn’t fit in a page or if there are more than 20 elements in your diagram, your diagram is obviously too big.
InitializeNavigator
ManageNavigator
Operator
ManageSystem
UpdateNetworkObjectState
ManageTopology
MoveNetworkObject
AddNEUpdateNE
ManageNE DeleteNE
AddTrunk
UpdateTrunk
ManageTrunk
DeleteTrunk
Bind
Unbind
DeleteServerUpdateServerAddServer
ManageServerManageDomain
Figure 2. Bad example: all use cases in the same level
Manage Navigator
(from Navigator Management)
Manage Topology
(from Topology Management)
Manage System
(from System Management)
Operator
Initialize Navigator
Figure 3. Good example: use cases divided into packages.
Rec. 5 Use the package diagram to represent the high level view of the system.
In the high level view, each package represents a subsystem.
Arrows between packages illustrate dependencies between parts of the system. A dependency exists between two elements if changes to the definition of one element may cause changes to the other subsystem that provides services to another subsystem is a server and it is symbolized with the arrow end in the relationship. A subsystem depends on another subsystem if the functionality of the first subsystem cannot be fully used without the other.
SMS System
3rd Party Application
NMS System
M
3rd Party System
M
Figure 4. Associations between systems.
Service Platform Browser
<<layer>>
Service Management
<<subsystem>>
M
Customer Management
<<subsystem>>
M
Cross-Domain Management
<<subsystem>>
Kernel M
M
Database
M
M
M
M
M
M
Figure 5. Associations between functional subsystems.
Applications
Core
Platform
Kernel
Database
Figure 6. Associations between layers.
Service Platform Browser
<<sublayer>>
(from Application)
Client Applicat ions
<<sublayer>>
(from Application)
Platform<<sublayer>>
(from Application)
Figure 7. Associations between sublayers.
Rec. 6 Attach UML stereotypes to packages to describe the type of package.
The following stereotypes are recommended:
• <<system>>
• <<subsystem>>
4 USE CASE DIAGRAM
Use cases should give a general overview what a user can do with this system. The use case diagram is an implementationindependent look at the system. It focuses on a highlevel picture of what the system will do, without worrying about the details of how the system will do it. Good use cases can be used when planning system tests or writing user manuals.
Requirements concerning the functionality of the system should be mapped to use cases.
Rec. 7 Define only the most essential use cases.
It is not necessary to define all the possible use cases. Analyze only the most important functional requirements of the system as use cases. You can group use cases according to their importance.
Rec. 8 Use a standard format to describe use cases textually.
It is not necessary to express use cases graphically with use case diagram. Use cases can also be expressed textually. Use the following format with use cases:
Use Case Name:
Description:
Preconditions:
Work flow in steps:
Postconditions:
Exceptions:
Actors:
Timing Constraints:
5 CLASS DIAGRAM
Rec. 9 Avoid too much detail in class diagrams.
Represent only the most important attributes and methods e.g. only the public attributes and methods. Avoid describing attribute types, method types and method parameters in class diagrams. This way it will be easier to keep the class diagrams uptodate later.
Rec. 10 Avoid complex associations between classes.
UML supports many different types of associations. Complex associations typically cause misunderstanding among developers. Describe the associations in textual form in UML note or in the specification document. However, all the associations should be modeled because the dependencies between classes represent important information.
The following associations are recommended:
• Unidirectional association. Navigability exists in only one direction. Use the bidirectional association (navigability in both directions) in special cases as unidirectional is sufficient in most cases.
• Multiplicity. Indicates how many objects may participate in the given relationship. The most common multiplicities in practice are
• 1 (exactly one)
• * (the range 0..infinity)
• 0..1 (either none or one)
• Generalization. Generalizations are associations between more general elements and more specific elements in which the more specific elements are fully consistent with the more general elements and inherit and may add information to the characteristics provided by the more general elements.
• Aggregation. The partof relationship. Example: a car has an engine and wheels as its parts.
• Dependency. Dependencies are associations between a collection of dependent client elements and another collection of independent supplier elements. The client elements require knowledge of and the presence of the supplier elements. Dependencies are used to model dependencies among model elements where changes in the independent supplier elements may require changes to the dependent client elements. Example of a dependency: a parameter reference or the creation of an object.
Rec. 11 Name an association only if improves understanding.
It is not necessary to name every association. Association names like “has” or “is related to” are often useless.
Rec. 12 Attach UML stereotypes to classes to describe the type of class.
The following stereotypes are recommended:
• <<interface>>
• <<abstract>>
NMSNetworkElement
idnamecoordinatestype
NMSEquipmentHandler
getByNetworkElement()
<<Interface>>NMSInterfaceHandler
getByNetworkElement()
<<Interface>>NMSNetworkElementHandler
get()getAllByTime()
<<Interface>>
NMSEquipment
unittypestate
NMSInterface
interfaceATMaddressIPaddressIPsubnetworkAddresstypecapacitystate
NMSTrunk
idfromInterfacetoInterfacetypecapacitystateavailability
NMSTrunkHandler
getByNetworkElement()getByCircuit()statistics()
<<Interface>>
NMSEquipmentFault
idfaultSourceaffectedCircuitsproblemDescriptionspecifiersptgptmaintenanceStatusseverityacknowldgeTimeonTimeoffTime
NMSEquipmentFaultHandler
getAllByTime()getByNetworkElement()getByCircuit()
<<Interface>>
NMSCustomerSite
customerIdsiteIdnameaddressmodemnetworkElementInterfaceIPsubnetworkAddressestypedescriptioncoordinatescontacttelephoneNumberfaxNumber
NMSCustomerSiteHandler
create()modify()getByCustomer()getAll()
<<Interface>>
Figure 8. Good example of a class diagram.
6 SEQUENCE DIAGRAM
The rationale for using sequence diagrams is to illustrate how use cases are implemented in the system. Sequence diagram can describe interaction between systems, subsystems, modules or classes.
Rec. 13 Describe only the most important sequences.
There is no need to describe all the possible sequences in the system. This kind of approach helps to keep models uptodate later.
Rec. 14 Describe external objects with an actor symbol in sequence diagrams.
It should be possible to distinguish internal objects from the external objects.
Rec. 15 Usage of arrow symbols in sequence diagrams.
Use only the basic symbols. Add textual commentary in more complicated cases. Use only the following symbols in sequence diagrams:
• Simple.
For messages with a single thread of control, one object sends a message to a passive object.
• Asynchronous
Asynchronous communication occurs, when the client sends a message to the supplier for processing, and continues to execute its code without waiting for or replying on the supplier’s receipt of the message.
7 STATECHART DIAGRAM
A statechart diagram shows the states of a single object, the events or messages that cause the transition from one state to another and the actions that result from a state change.
Rec. 16 Use the statechart diagram only in special cases.
Use the statechart diagram if you want to describe a complicated algorithm. Use the statechart for objects with complex, dynamic behavior to exemplify the states of an object during its lifetime. Statechart diagrams can also be used to visualize the dialog structure of the GUI. Here, a state stands for a dialog box, window, or Web page. An event causes a movement from one dialog to another.
8 COMPONENT DIAGRAM
One of the main problems in UML at the moment is how to use components. Common modeling techniques with components are introduced in this subchapter. Components are clarified in the appendix.
8.1 Standard UML stereotypes for components
All the UML's extensibility mechanisms apply to components. The UML defines five standard stereotypes that apply to components.
1. <<executable>>Specifies a component that may be executed on a node.
2. <<library>>Speficies a static or dynamic object library.
3. <<table>>Specifies a component that represents a database table.
4. <<file>>Specifies a component that represents a document containing source code or data.
5. <<document>>Specifies a component that represents a document.
8.2 Organizing components
You can organize components by grouping them in packages organize in the same manner in which you would organize classes.
validator
configuration
framework
genos
kernel
log
servletFW
util
workhorsexml
core
Figure 9. Platform components (Java classes) organized into packages.
8.3 Modeling executables and libraries
To model executables and libraries:
• Model the deployment components that make up your implementation.
• Identify the partitioning of your physical system.
• Model any deployment components: executables and libraries.
• Model the relationships among these components.
• It is important to model the dependencies of these elements in order to visualize the impact of change.
• For larger systems that are deployed across several computers, it is useful to model the way the components are distributed by asserting the nodes on which they are located.
• Stereotypes used
• <<executable>>
• <<library>>
• <<interface>>
• Rose specific: <<EXE>>
• Rose specific: <<DLL>>
something.exe<<EXE>>
libx.dll<<DLL>>
liby.dll<<DLL>>
libz.dll<<DLL>>
Deployment components of the physical system and their dependencies.
Figure 10. Executables, libraries and their relationships.
8.4 Modeling tables, files and documents
To model tables, files, and documents:
• Deployment components that are neither executables nor libraries and yet are critical to the physical environment, e.g. data files, help documents, scripts, log files, initialization files, and installation/removal files.
• Identify the ancillary components that are part of the physical implementation of your system and model these things as components.
• You can also include other executables, libraries and interfaces in the same diagram. Model the dependencies among these parts.
• Stereotypes used
• <<executable>>
• <<library>>
• <<interface>>
• <<table>>
• <<file>>
• <<document>>
something.exe<<EXE>>
libx.dll<<DLL>>
liby.dll<<DLL>>
libz.dll<<DLL>>
Deployment components of the physical system and their dependencies. Other deploytment components also included.
myhelp.hlp
start.ini
Figure 3. Executables, libraries and other deployment components.
8.5 Modeling an API
To model an API:
• Model the component and its interface.
• Expose only those properties of the interface that are important to visualize in the given context.
• You can also include the signatures for each operation in the API.
• Stereotypes used
• <<executable>>
• <<interface>>
AVCListener
AVCListener
GOSListener
GOSListener
Notif iable
Notif iable
CreateListener
CreateListener
DeleteListener
DeleteListener
ListenerAdapter
ListenerAdapter
Figure 4. Components (Java classes) and their interfaces.
8.6 Modeling source code
To model source code:
• Model the configuration of all the source code files that your development tools use to create these components.
• These represent the work product components of your development process.
• This is useful for visualizing the compilation dependencies among the source code files.
CallerInfo
StackTraceParser
CommandLog
LogBase
DateFormatter
ErrorLog
Log
TraceLog
LogMsg
Figure 5. Source file components in Log.
DataObject
Attribute
Operativ eParameter
Operativ eParameter
GOSIdGOSFilter
GOSSelect
RMIBridge_i
RMIBridge_i
RMICoreComponent
RMICoreComponent
RMIGenOSClient
Figure 6. Some of the source file components in GenOS.
9 DEPLOYMENT DIAGRAM
Deployment diagrams show the configuration of runtime processing elements and the software components, processes, and objects that live on them. Software component instances represent runtime manifestations of code units.
Components that do not exist as runtime entities (because they have been compiled away) do not appear on these diagrams, they should be shown on component diagrams.
<<computer>>Web Client WS
<<computer>>Management Server
<<computer>>Web Server
<<computer>>Database Server
<<module>>Web Browser
<<module>>HTTP Server
<<module>>Servlet Engine
<<applet>>Client Applet
<<HTML page>>GUI
<<servlet>>Client Servlet
<<module>>XSLT Processor
Example 11. Deployment view: SMS system structure.
Rec. 17 Use the recommended components in deployment diagram.
Components presented in deployment diagram are:
• EXE
• process
• file
• class (only in Java)
• jar (only in Java)
10 UML DIAGRAMS IN SPECIFICATION DOCUMENTS
10.1 General
There are three perspectives you can use in drawing diagrams (especially class diagrams):
• Conceptual. This perspective is used in functional specification. If you take the conceptual perspective, you draw a diagram that represents the concepts in the domain under study. These concepts will naturally relate to the classes that implement them, but there is often no direct mapping. Indeed, a conceptual model should be drawn with little or no regard for the software that might implement it, so it can be considered languageindependent.
Class diagrams can be extremely valuable here, as long as you draw them from the conceptual perspective. In other words, you should treat each class as a concept in a user's mind. The class diagrams you draw are then not diagrams of data or of classes, but rather of the language of your users.
• Specification. This perspective is used in system/subsystem architecture specification. Now we are looking at software, but we are looking at the interfaces of the software, not the implementation. Objectoriented development puts a great emphasis on the difference between interface and implementation, but this is often overlooked in practice because the notion of class in an OO language combines both interface and implementation. This is a shame, because the key to effective OO programming is to program to a class’s interface rather than to its implementation
• Implementation. This perspective is used in module specification. In this view, we really do have classes and we are laying the implementation bare. This is probably the perspective used most often, but in many ways the specification perspective is often a better one to take.
It is very important to separate the specification perspective and the implementation perspective. Perspective is not part of the formal UML, but it has been found extremely valuable when modeling and when reviewing models. The UML can be used with all three perspectives. By tagging classes with a stereotype, you can provide an indication of the perspective. You mark classes with <<implementation class>> to show the implementation perspective, and with <<type>> for the specification and conceptual perspective.
10.2 Functional specification
The UML models in functional specification should at least answer the following questions:
1. What is the problem?
2. What kind of solution solves the problem?
The following diagrams are recommended:
• analysis class diagram
• use case diagram
The following diagrams are optional:
• statechart diagram
10.3 System architecture/subsystem architecture specification
The UML models in system architecture specification should answer at least the following questions:
1. What is the logical partitioning of the system into subsystems? Knowing this helps you to understand the overall structure of the system and to comprehend how system functionality is allocated.
2. What is the runtime configuration of the system? Designing what processes there are, how they relate, and how they are allocated to available computers is an essential part of architectural design. This helps in debugging the system and estimating its performance as well as in planning the development and the integration order.
3. What is the configuration of the developed system in terms of components? This helps in organizing the development and integration work as well as in software configuration management.
4. How does the architecture implement the most important use cases? This provides visibility to design rationale and makes it possible to validate the performance of designed system from the user’s point of view.
The following diagrams are recommended:
• package diagram
• deployment diagram
• component diagram
• sequence diagram
10.4 Module specification
The following diagrams are recommended:
• class diagram
• sequence diagram
The following diagrams are optional:
• statechart diagram
11 APPENDIX
11.1 Components
Components live in the material world of bits and therefore are an important building block in modeling the physical aspect of a system. A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces.
11.1.1 Logical and physical views
You do logical modeling to visualize, specify, and document your decisions about the vocabulary of your domain and the structural and behavioral way those things collaborate. You do physical modeling to construct the executable system. Whereas these logical things live in the conceptual world, the physical things live in the world of bits that is, they ultimately reside on physical nodes and can be executed directly or can, in some indirect manner, participate in an executing system.
In the UML, all these physical things are modeled as components. A component is a physical thing that conforms to and realizes a set of interfaces. Interfaces therefore bridge your logical and physical models. For example, you may specify an interface for a class in a logical model, and that same interface will carry over to some physical component that realizes it.
11.1.2 Components vs. classes
There are some significant differences between components and classes.
• Classes represent logical abstractions; components represent physical things that live in the world of bits. In short, components may live on node, classes may not.
• Components represent the physical packaging of otherwise logical components and are at a different level of abstraction. Components represent the physical packaging of a set of other logical elements, such as classes.
• Classes may have attributes and operations directly. In general, components only have operations that are reachable only through their interfaces.
11.1.3 Binary replacealibity
The basic intent of every componentbased operating system facility is to permit the assembly of systems from binary replaceable parts.
• A component is physical. It lives in the world of bits, not concepts.
• A component is replaceable. A component is substitutable it is possible to replace a component with another that conforms to the same interfaces.
• A component is part of a system. A component rarely stands alone. Rather, a given component collaborates with other components and in so doing exists in the architectural or technology context in which it is intended to be used.
• A component conforms to and provides the realization of a set of interfaces.
11.1.4 Types of components
Three kinds of components may be distinguished.
1. Deployment components. Components necessary to form an executable system. Examples: DLL, EXE. Also CORBA and EJB components are deployment components.
2. Work product components. These components are essentially the residue of the development process, like things from which deployment components are created. These components do not directly participate in an executable system but are the work products of development that are used to create the executable system. Examples: source code files, data files.
3. Execution components. These components are created as a consequence of an executing system.
11.2 FAQ
Frequently asked questions:
QUESTION:
What is the purpose of modeling?
ANSWER:
Developing a model for an industrialstrength software system prior to its construction or renovation is as essential as having a blueprint for large building. Good models are essential for communication among project teams and to assure architectural soundness. As the complexity of systems increase, so does the importance of good modeling techniques. There are many additional factors of a project’s success, but having a rigorous modeling language standard is one essential factor
QUESTION:
What is modeling?
ANSWER:
Modeling is the easiest way of moving you step by step through the processes of: Identifying the requirements of the application and modeling business processes Mapping requirements to abstract business objects, identifying and applying design patterns, and creating usage scenarios Identifying and designing business objects or partitioning services across a threetiered services model Mapping business objects to software components and designing how components will be distributed across a network
QUESTION:
What problems does visual modeling address?
ANSWER:
The problems that visual modeling addresses are:
• Software that poorly fits user needs
• Inability to deal with changing requirements
• Software integration problems
• Discovery of serious flaws too late in the project
• Software that is hard to maintain and extend
QUESTION:
When do I need modeling?
ANSWER:
Modeling can be useful at any point in the application development process.
When first building an application, your time is much better spent dealing with issues such as the planned business uses and how you will implement a programming environment to address these business issuesnot where and how you are going to place the buttons on your first screen.
Modeling can also be introduced in the middle of an existing project. Rational Rose includes powerful tools for reverse engineering as well as forward engineering of classes and component architectures. You can gain valuable insights to your asbuilt architecture and help pinpoint deviations from the original design.
QUESTION:
What is the UML?
ANSWER:
The Unified Modeling Language (UML) is considered the de facto standard object modeling language in the industry. The UML is the evolution of early approaches to objectoriented analysis and design. Based on the seminal works by Grady Booch, Ivar Jacobson, and Jim Rumbaugh in the Booch, OOSE, and Object Modeling Technique (OMT) methods, these three Rational experts have provided the basis for the next generation of visual software modeling. The UML details the application modeling language for:
• Business process modeling with use cases
• Class and object modeling
• Component modeling
• Distribution and deployment modeling
QUESTION:
What is UML?
ANSWER:
The Unified Modeling Language (UML) is the industrystandard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. Using UML, programmers and application architects can make a blueprint of a project, which, in turn, makes the actual software development process easier.
QUESTION:
Who created UML?
ANSWER:
UML was created at Rational Software by methodologists Grady Booch, Ivar Jacobson, and Jim Rumbaugh with input from other leading methodologists, many software vendors, as well as endusers. Its aim is to unify the various existing systems into a bestofbreed modeling language.
QUESTION:
Is UML a standard?
ANSWER:
Yes. UML was adopted by the Object Management Group (www.omg.org) as a standard in November, 1997.
QUESTION:
Do I really need UML? Can't I just describe how my application is designed using regular words?
ANSWER:
While it's certainly possible to describe interrelated processes and code architecture in words, many people prefer to use a diagram to visualize the relationship of elements to one another. UML is a standard way to create these diagrams. As a result, it makes it easier for programmers and software architects to communicate.
QUESTION:
I already use project management software to plan my software development projects. Why should I use UML?
ANSWER:
Unlike project management software, which is designed to coordinate the various parts of a project in relation to a timeline, UMLbased diagrams can be used to show the interrelationships within a project from an architectural perspective.
QUESTION:
How does UML relate to OMT, Booch, OOSE, and other modeling languages?
One of the goals of the design of UML was to unify the various modeling languages into one common standard. Those that are familiar with OMT, Booch, or OOSE will have little trouble picking up UML because many of the concepts are very similar.