The Unified Modeling Language (UML) is used for visualizing, specifying, constructing and documenting the artifacts of the software-intensive systems. UML follows the object-oriented analysis and development concepts and methodology which was developed beginning in the late 80s. UML has been evolving since the second half of the 1990s and accepted by Object Management Group (OMG) as a standard software development tool in 2001.
Object Oriented Methodology
Object Oriented (OO) methodology is an approach to designing modular, reusable software systems which allows the large-scale applications to be developed in independent modules. The main building block of OO is the object and class.
Object is anything that is visible or tangible (thing, person, or matter), generally drawn from a vocabulary of the problem or solution space.
Class is a description of a set of common objects. Object allows us to decompose the system into smaller and manageable components and allows us to build one component at a time. Every object has identity, state, and behavior. In the OO methodology, we usually parse the requirements first to determine the nouns and verbs of the system. The noun becomes objects and classes and, the verbs become an operation or methods which then they are used to create the modules and components of the system.
Unified Modeling Language
A model is a simplification of reality and it provides the blueprints of a system. UML is a software-centric modeling tool which has a vocabulary and rules like a language. Using its formal language, it creates the conceptual, logical and physical representation of the system. UML evolves throughout the software development life cycle incrementally in contrary to the waterfall model. UML diagrams are developed from the special symbols and notations. UML models can create executable architecture from the model and the model can be directly connected to a variety of programming languages. It is possible to map the UML models to the programming languages such as Java, C++ or others, or even to Oracle tables in a relational database.
Building Blocks of UML
The vocabulary of the UML encompasses three kinds of building blocks: thing, relationships and diagrams:
Things: are the objects and classes which are the abstraction of the model
Relationships: tie things (objects and classes) together
Diagrams: group interesting collections of things
Things in UML
The things are the basic building blocks of OO methodology and they are used to develop UML models. There are four kinds of things in UML which are called: Structural, Behavioral, Grouping and Annotational things. We will review only the basic structural and basic behavioral modeling features of UML in this paper. The advanced Structural and Behavioral Modeling techniques, and also Grouping and Annotational things are left to be reviewed in another paper.
Structural things are the nouns of UML models. They represent either conceptual or physical elements of the UML. There are five basic structural things:
Class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class implements one or more interfaces.
Interface is a collection of operation represents a class or component.
Use case is a description of set of sequence of actions that a system performs and yields an observable result of value to a particular actor. A use case is used to structure the behavioral things in a model.
Component is the physical part of a system that conforms to and provides the realization of a set of interfaces. In a system, we encounter different kinds of deployment components, such as COM+ components or Java Beans, as well as components that are artifacts of the development process, such as source code files. A component typically represents the physical packaging of a system, otherwise logical elements, such as classes, interfaces, and collaborations.
A node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability. A set of components may reside on a node and may also migrate from node to node
Relationships in UML
There are four kinds of relationships in the UML: Dependency, Association, Generalization and Realization. These relationships are the basic relational building blocks of the UML. We use them to write well-formed models.
A dependency is a semantic relationship between two things in which a change to one thing (the independent thing) may affect the semantics of the other thing (the dependent thing).
An association is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association, representing a structural relationship between a whole and its parts.
A generalization is a specialization/generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent).
A realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out. We encounter realization relationships between the interfaces and the classes or components that realize them, and also between use cases.
UML Diagrams (Models)
A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships). The UML has the following type of diagrams:
Structural (Static) Type Diagrams
Behavioral (Dynamic) type Diagrams
Basic Structural Diagrams
We use the structural diagrams of UML to capture the static aspects of a system. We can think of the static aspects of a system as representing its relatively stable skeleton. The UML’s structural diagrams are roughly organized around the major groups of things we find when modeling a system. The static parts of a system consist of using one of the four following diagrams.
Class diagram: classes, interfaces, and collaborations
Object diagram: objects
Component diagram: Components
Deployment diagram: Nodes
Class diagram is used to represent the structure of the system by detailing the classes, their attributes (characteristics) and diagramming the relationship of each class to the other classes. These are static view diagrams of the model that describes the behavior and attributes. They are highly useful for visualizing the relationship between interfaces and classes. Class diagrams depict the building blocks of the system and include information about the interface, aggregations, generalization, and associations as shown in Figure-2.
Object diagram depicts the relationship between classes at a specific time as opposed to just in general. They are often used along with the class diagrams to show multiplicity.
Component diagram depicts a set of components and their relationships. We use component diagrams to illustrate the static implementation view of a system. Component diagrams are related to class diagrams in that a component typically maps to one or more classes, interfaces, or collaborations but more abstract way.
Deployment diagram depicts a set of nodes and their relationships. The run-time architecture of a system is modeled in deployment diagrams. Hardware elements are referred to as nodes and the configuration of the nodes is modeled. Deployment diagrams also show the software elements that are associated with each node.
Behavioral Things (Dynamic Parts of a Model)
Behavioral things are the dynamic parts of UML models. These are the verbs of a model, representing behavior over time and space. The dynamic model describes how the objects change state and in which order the state changes can take place.
Use case diagram models the requirements. It consists of set of use cases and actors and their relationships. They show what the system is intended to do and how it works in a basic way. Elements that represent external entities are called actors. Use case diagrams show how the system is interacted with by other systems, external hardware or users.
Sequence diagram depicts the sequence of messages/calls in the time order that they occur between the objects.
Statechart diagram depicts the behavior states of object which consists of states, transitions, events, and activities. They are especially important in modeling the behavior of an interface, class, or collaboration.
Activity diagram depicts the flow from activity to activity within a system.
The Development Guidelines of the Basic UML Diagrams
UML is a highly useful tool for when the structure of a system needs to be defined and the visual representation is easy to understand.
With the Use Cases we capture the functional requirements of the system step by step from the user scenarios and high level requirements
We create the objects and classes of the system from the use cases and then create the domain model by gathering the logically related object and classes. Use cases are also mapped to domain model
From the use cases and domain model (class, objects, etc.), we create the Activity diagram to depict the procedural flow of control between two or more class objects while processing an activity.
With the sequence diagrams, we depict the sequence of messages/calls in the time order that they occur between the objects.
The statechart diagram models the different states that a class can be in and how that class transitions from state to state.
The component diagrams provide the physical view of the system. Their purpose is to show the dependencies that the software has on the other software components (e.g., software libraries) in the system
The deployment diagram depict 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.
Object Oriented (OO) methodology is an approach to designing modular, reusable software systems which allows the large-scale applications to be developed in independent modules. The main building block of OO is the object and class.