Software Design And Architecture - Introduction to UML - Unified Modeling Language

Introduction to UML - Unified Modeling Language

The Unified Modeling Language (UML) is a visual language for capturing software designs and patterns. Dig a little deeper, though, and you’ll find that UML can be applied to quite a few different areas and can capture and communicate everything from company organization to business processes to distributed enterprise software. It is intended to be a common way of capturing and expressing relationships, behaviors, and high-level ideas in a notation that’s easy to learn and efficient to write. UML is visual; just about everything in it has a graphical representation.

History, Need and Tools

You can apply UML in any number of ways, but common uses include:

• Designing software
• Communicating software or business processes
• Capturing details about a system for requirements or analysis
• Documenting an existing system, process, or organization

 
UML has been applied to countless domains, including:

• Banking and investment sectors
• Health care
• Defense
• Distributed computing
• Embedded systems
• Retail sales and supply





UML Basics

Note:  Sometimes Implementation is called as "Realization"



Association

Associations are stronger than dependencies and typically indicate that one class retains a relationship to another class over an extended period of time. The lifelines of two objects linked by associations are probably not tied together (meaning one can be destroyed without necessarily destroying the other). Associations are typically read as “…has a…”. For example, if you have a class named Window that has a reference to the current mouse cursor, you would say “Window has a Cursor”. Note that there is a fine line between “…has a…” and “…owns a…” (see “Aggregation” later in this section). In this case, Window doesn’t own the Cursor; Cursor is shared between all applications in the system. However, Window has a reference to it so that the Window can hide it, change its shape, etc.  You show an association using a solid line between the classes participating in the relationship.

Navigability

Associations have explicit notation to express navigability. If you can navigate from one class to another, you show an arrow in the direction of the class you can navigate to. If you can navigate in both directions, it is common practice to not show any arrows at all, but as the UML specification points out, if you suppress all arrows you can’t distinguish nonnavigable associations from two-way associations. However, it is extremely rare to use a nonnavigable association in the real world, so this is unlikely to be a problem.

Multiplicity


Because associations typically represent lasting relationships, they are often used to indicate attributes of a class. As mentioned in the “Attributes by Relationship” section, you can express how many instances of a particular class are involved in a relationship. If you don’t specify a value, a multiplicity of 1 is assumed. To show a different value, simply place the multiplicity specification near the owned class.

Aggregation

Aggregation is a stronger version of association. Unlike association, aggregation typically implies ownership and may imply a relationship between lifelines. Aggregations are usually read as “…owns a…”. For example, if you had a classed named Window that stored its position and size in a Rectangle class, you would say the “Window owns a Rectangle.” The rectangle may be shared with other classes, but the Window has an intimate relationship with the Rectangle.

Composition

Composition represents a very strong relationship between classes, to the point of containment. Composition is used to capture a whole-part relationship. The “part” piece of the relationship can be involved in only one composition relationship at any given time. The lifetime of instances involved in composition relationships is almost always linked; if the larger, owning instance is destroyed, it almost always destroys the part piece. UML does allow the part to be associated with a different owner before destruction, thus preserving its existence, but this is typically an exception rather than the rule. A composition relationship is usually read as “…is part of…”, which means you need to read the composition from the part to the whole. For example, if you say that a window in your system must have a titlebar, you can represent this with a class named Titlebar that “…is part of…” a class named Window.

Generalization

A generalization relationship conveys that the target of the relationship is a general, or less specific, version of the source class or interface. Generalization relationships are often used to pull out commonality between difference classifiers. For example, if you had a class named Cat and a class named Dog, you can create a generalization of both of those classes called Animal. A full discussion of how and when to use generalization (especially versus interface realization) is the subject for an object-oriented analysis and design book and isn’t covered here. Generalizations are usually read as “…is a…”, starting from the more specific class and reading toward the general class. Going back to the Cat and Dog example, you would say “a Cat…is a…Animal” (grammar aside).

Realization or Implementation

An interface is a classifier that has declarations of properties and methods but no implementations. You can use interfaces to group common elements between classifiers and provide a contract a classifier that provides an implementation of an interface must obey. For example, you can create an interface named Sortable that has one operation named comesBefore(...). Any class that realizes the Sortable interface must provide an implementation of comesBefore(...).

Dependency

The weakest relationship between classes is a dependency relationship. Dependency between classes means that one class uses, or has knowledge of, another class. It is typically a transient relationship, meaning a dependent class briefly interacts with the target class but typically doesn’t retain a relationship with it for any real length of time. Dependencies are typically read as “…uses a…”. For example, if you have a class named Window that sends out a class named WindowClosingEvent when it is about to be closed, you would say “Window uses a WindowClosingEvent.”

Modeling

It should go without saying that the focus of UML is modeling. However, what that means, exactly, can be an open-ended question. Modeling is a means to capture ideas, relationships, decisions, and requirements in a well-defined notation that can be applied to many different domains. Modeling not only means different things to different people, but also it can use different pieces of UML depending on what you are trying to convey.
 

In general a UML model is made up of one or more diagrams. A diagram graphically represents things, and the relationships between these things. These things can be representations of real-world objects, pure software constructs, or a description of the behavior of some other object. It is common for an individual thing to show up on multiple diagrams; each diagram represents a particular interest, or view, of the thing being modeled.

Diagrams

UML 2.0 divides diagrams into two categories: structural diagrams and behavioral diagrams. Structural diagrams are used to capture the physical organization of the things in your system—i.e., how one object relates to another. 

There are several structural diagrams in UML 2.0:


Class diagrams

Class diagrams use classes and interfaces to capture details about the entities that make up your system and the static relationships between them. Class diagrams are one of the most commonly used UML diagrams, and they vary in detail from fully fleshed-out and able to generate source code to quick sketches on whiteboards and napkins. 

Component diagrams

Component diagrams show the organization and dependencies involved in the implementation of a system. They can group smaller elements, such as classes, into larger, deployable pieces. How much detail you use in component diagrams varies depending on what you are trying to show. Some people simply show the final, deployable version of a system, and others show what functionality is provided by a particular component and how it realizes its functionality internally.

Composite structure diagrams

Composite structure diagrams are new to UML 2.0. As systems become more complex, the relationships between elements grow in complexity as well. Conceptually, composite structure diagrams link class diagrams and component diagrams; they don’t emphasize the design detail that class diagrams do or the implementation detail that composite structures do. Instead, composite structures show how elements in the system combine to realize complex patterns.

 
Deployment diagrams

Deployment diagrams show how your system is actually executed and assigned to various pieces of hardware. You typically use deployment diagrams to show how components are configured at runtime. 

 
Package diagrams

Package diagrams are really special types of class diagrams. They use the same notation but their focus is on how classes and interfaces are grouped together. 

 
Object diagrams

Object diagrams use the same syntax as class diagrams and show how actual instances of classes are related at a specific instance of time. You use object diagrams to show snapshots of the relationships in your system at runtime.

Behavioral diagrams focus on the behavior of elements in a system. For example, you can use behavioral diagrams to capture requirements, operations, and internal state changes for elements. The behavioral diagrams are:

Use case diagrams
 
Use case diagrams capture functional requirements for a system. They provide an implementation-independent view of what a system is supposed to do and allow the modeler to focus on user needs rather than realization details.

Activity diagrams

Activity diagrams capture the flow from one behavior or activity, to the next. They are similar in concept to a classic flowchart, but are much more expressive. 

 

Communication diagrams
 

Communication diagrams are a type of interaction diagram that focuses on the elements involved in a particular behavior and what messages they pass back and forth. Communication diagrams emphasize the objects involved more than the order and nature of the messages exchanged. 

 

Interaction overview diagrams

Interaction overview diagrams are simplified versions of activity diagrams.  Instead of emphasizing the activity at each step, interaction overview diagrams emphasize which element or elements are involved in performing that activity. The UML specification describes interaction diagrams as
emphasizing who has the focus of control throughout the execution of a system.


Sequence diagrams

Sequence diagrams are a type of interaction diagram that emphasize the type and order of messages passed between elements during execution. Sequence diagrams are the most common type of interaction diagram and are very intuitive to new users of UML. 

 

State machine diagrams

State machine diagrams capture the internal state transitions of an element.  The element could be as small as a single class or as large as the entire system. State machine diagrams are commonly used to model embedded systems and protocol specifications or implementations. 

Timing diagrams
 
Timing diagrams are a type of interaction diagram that emphasize detailed timing specifications for messages. They are often used to model real-time systems such as satellite communication or hardware handshaking. They have specific notation to indicate how long a system has to process or respond to messages, and how external interruptions are factored into execution.

 

Views

While not strictly part of UML itself, the concept of views of a system helps the modeler choose diagrams that help convey the correct information depending on his goals. Specifically, models are often divided into what is called the 4+1 views of a system. The 4+1 notation represents four distinct views of a system and one overview of how everything fits together. 

The four views are:

Design view

The design view captures the classes, interfaces, and patterns that describe the representation of the problem domain and how the software will be built to address it. The design view almost always uses class diagrams, object diagrams, activity diagrams, composite structure diagrams, and sequence
diagrams to convey the design of a system. The design view typically doesn’t address how the system will be implemented or executed.

 

Deployment view

The deployment view captures how a system is configured, installed, and executed. It often consists of component diagrams, deployment diagrams, and interaction diagrams. The deployment view captures how the physical layout of the hardware communicates to execute the system, and can be used to show failover, redundancy, and network topology.

Implementation view

The implementation view emphasizes the components, files, and resources used by a system. Typically the implementation view focuses on the configuration management of a system; what components depend on what, what source files implement what classes, etc. Implementation views almost always use one or more component diagrams and may include interaction diagrams,
statechart diagrams, and composite structure diagrams.

 

Process view

The process view of a system is intended to capture concurrency, performance, and scalability information. Process views often use some form of interaction diagrams and activity diagrams to show how a system actually behaves at runtime.

 

The four distinct views of a system are brought together with the final view:

Use case view
 

The use case view captures the functionality required by the end users. The concept of end users is deliberately broad in the use case view; they include the primary stakeholders, the system administrator, the testers, and potentially the developers themselves. The use case view is often broken down into collaborations that link a use case with one or more of the four basic views.
The use case view includes use case diagrams and typically uses several interaction diagrams to show use case details.