UML

UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. UML was created by Object Management Group (OMG) and UML 1.0 specification draft was proposed to the OMG in January 1997. OMG is continuously putting effort to make a truly industry standard. UML stands for Unified Modeling Language. UML is different from the other common programming languages like C++, Java, COBOL etc. UML is a pictorial language used to make software blue prints.

Goals of UML is to define some general purpose modeling language which all modelers can use. language which is simple to understand and use. UML diagrams are not only made for developers but also for business users, common people and anybody interested to understand the system. conclusion the goal of UML can be defined as a simple modeling mechanism to model all possible practical systems in today's complex environment. A conceptual model of UML:

A conceptual model can be defined as a model which is made of concepts and their relationships. A conceptual model is the first step before drawing a UML diagram. It helps to understand the entities in the real world and how they interact with each other.

Three major elements of conceptual model

UML building blocks Rules to connect the building blocks Common mechanisms of UML

Object oriented concepts: Objects: Objects represent an entity and the basic building block. Class: Class is the blue print of an object. Abstraction: Abstraction represents the behavior of an real world entity. Encapsulation: Encapsulation is the mechanism of binding the data together and hiding them from outside world. Inheritance: Inheritance is the mechanism of making new classes from existing one. Polymorphism: It defines the mechanism to exists in different forms. OO Analysis and Design

Identifying the objects of a system. Identify their relationships. Make a design which can be converted to executables using OO languages.

There are three basic steps where the OO concepts are applied and implemented. The steps can be defined as OO Analysis --> OO Design --> OO implementation using OO languages

Building blocks of UML Things Relationships Diagrams

1) Things: Things are the most important building blocks of UML. Things can be: Structural Behavioral Grouping Annotational

Rules

The

Specify what a well-formed model should look like. UML has semantic rules for Names Scope Visibility Integrity Execution

Common Mechanisms Mechanisms/elements that apply consistently throughout the language:

Specifications Adornments Common Divisions Extensibility Mechanisms Stereotypes Tagged values Constraints
Adornments Adorn the model - i.e., enhance the model. Adds to the meaning and/or semantics of the element to which it pertains. Notes are the mechanism provided by UML for adorning a model: o o graphical symbol to render constraints, comments, etc. a note that renders only a comment has no semantic impact on the element it is adorning; at most adds meaning to it and/or provides guidelines for implementation

Stereotypes

Stereotypes allow you to extend the vocabulary of the UML so that you can create new model elements, derived from existing ones, but that have specific properties that are suitable for your problem domain. A particular abstraction is marked as a stereotype and this stereotype is then used at other places in the model to denote the associated abstraction.

Notation: type

Constraints

Used to create rules for the model. Rules that impact the semantics of the model, and specify conditions that must be met. Can apply to any element in the model - attributes of a class, relationship, etc.

Structural things

The Structural things define the static part of the model. They represent physical and conceptual elements. Following are the brief descriptions of the structural things. Class: Class represents set of objects having similar responsibilities. Interface: Interface defines a set of operations which specify the responsibility of a class. Collaboration: Collaboration defines interaction between elements. Use case: Use case represents a set of actions performed by a system for a specific goal. Component: Component describes physical part of a system. Node: A node can be defined as a physical element that exists at run time. Representing class, interface, collaboration,use case, component, node

Class Notation

Object Notation: The object is represented in the same way as the class. The only difference is the name which is underlined as shown below.

Interface Notation: Interface is represented by a circle as shown below. It has a name which is generally written below the circle. Interface is used to describe functionality without implementation. When a class implements the interface it also implements the functionality as per the requirement.

Collaboration Notation: Collaboration is represented by a dotted eclipse as shown below. It has a name written inside the eclipse.

Use case Notation: Use case is represented as an eclipse with a name inside it. It may contain additional responsibilities.

Actor Notation: An actor can be defined as some internal or external entity that interacts with the system. Initial State Notation: Initial state is defined show the start of a process. Final State Notation: Final state is used to show the end of a process.

Active class Notation Active class looks similar to a class with a solid border. Active class is generally used to describe concurrent behaviour of a system.

Behavioral things: A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things: Interaction: Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.

State machine: State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change.

Behavioral things include interactions and state machines. Interaction Notation: Interaction is basically message exchange between two UML components. (communication among the components of the system) The following diagram represents different notations used in an interaction.

State machine Notation: State machine describes the different states of a component in its life cycle.

Grouping things: Grouping things can be defined as a mechanism to group elements of a UML model together. There is only one grouping thing available: Package: Package is the only one grouping thing available for gathering structural and behavioral things.

Annotational things: Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements. Note is the only one Annotational thing available. Note: A note is used to render comments, constraints etc of an UML element.

(2) Relationship : Relationship is another most important building block of UML. It shows how elements are associated with each other and this association describes the functionality of an application.

Dependency: Dependency is a relationship between two things in which change in one element also affects the other one. Association: Association is basically a set of links that connects elements of an UML model. It also describes how many objects are taking part in that relationship. Generalization: Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes inheritance relationship in the world of objects. Realization: Realization can be defined as a relationship in which two elements are connected. One element describes some responsibility which is not implemented and the other one implements them. This relationship exists in case of interfaces.

Bi-directional (standard) association: An association is a linkage between two classes. In Bi-directional, both classes are aware of each other and their relationship. Once flight is associated with a Plane class it will work as an entity.

Uni-directional association: uni-directional association is drawn as a solid line with an open arrowhead. Like standard associations, the uni-directional association includes a role name and a multiplicity value. But the uni-directional association only contains the role name and multiplicity value for the known class.

Aggregation: When a class is formed as a collection of other classes, it is called an aggregation relationship between these classes. It is also called a "has a" relationship. For example, we can think of Car as a whole entity and Car Wheel as part of the Car. In an aggregation relationship, the child class instance can outlive its parent class. To represent an aggregation relationship, you draw a solid line from the parent class to the part class, and draw an unfilled diamond shape on the parent class's association end.

Composition(Composite Aggregation): The composition aggregation relationship is just another form of the aggregation relationship, but the child class's instance lifecycle is dependent on the parent class's instance lifecycle. Company class and a Department class, notice that the composition relationship is drawn like the aggregation relationship, but this time the diamond shape is filled.

Inheritance: A very important concept in object-oriented design, inheritance, refers to the ability of one class (child class) to inherit the identical functionality of another class (super class), and then add new functionality of its own. We can implement generalization/specialization using inheritance.

To model inheritance on a class diagram, a solid line is drawn from the child class (the class inheriting the behavior) with a closed, unfilled arrowhead (or triangle) pointing to the super class. Consider types of bank accounts: Figure 4 shows how both CheckingAccount and SavingsAccount classes inherit from the BankAccount class.

Reflexive associations(recursive association): a class can also be associated with itself, using a reflexive association.

Visibility: In object-oriented design, there is a notation of visibility for attributes and operations. UML identifies four types of visibility: public (+) Protected (#) Private(-) and Package(~)

(3) UML Diagrams:

UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are used to make a complete UML diagram and the diagram represents a system. The visual effect of the UML diagram is the most important part of the entire process. All the other elements are used to make it a complete one. UML includes the following nine diagrams and the details are described in the following chapters. Class diagram Object diagram Use case diagram Sequence diagram Collaboration diagram Activity diagram Statechart diagram Deployment diagram Component diagram

UML Architecture

before designing a system the architecture is made with different perspectives in mind. The most important part is to visualize the system from different viewer's perspective. The better we understand the better we make the system. UML plays an important role in defining different perspectives of a system. These perspectives are: Design of a system consists of classes, interfaces and collaboration. UML provides class diagram, object diagram to support this. Implementation defines the components assembled together to make a complete physical system. UML component diagram is used to support implementation perspective. Process defines the flow of the system. So the same elements as used in Design are also used to support this perspective. Deployment represents the physical nodes of the system that forms the hardware. UML deployment diagram is used to support this perspective. And the centre is the Use Case view which connects all these four. A Use case represents the functionality of the system. So the other perspectives are connected with use case. Architecture and the UML

UML Modeling Types

Structural modeling Behavioral Modeling Architectural Modeling

Structural modeling captures the static features of a system. It never describes the dynamic behavior of the system. Structural model represents the framework for the system and this framework is the place where all other components exist. They all represent the elements and the mechanism to assemble them. They consist of the following: Classes diagrams (most widely used) Objects diagrams Deployment diagrams Package diagrams Composite structure diagram Component diagram Behavioral Modeling: Behavioral model describes the interaction in the system. (shows the dynamic nature of the system) It represents the interaction among the structural diagrams. They consist of the following: Activity diagrams Interaction diagrams Use case diagrams Architectural Modeling: Architectural model represents the overall framework of the system. It contains both structural and behavioral elements of the system. Architectural model can be defined as the blue print of the entire system. Package diagram comes under architectural modeling. There are two broad categories of diagrams and then are again divided into sub-categories: Structural Diagrams Behavioral Diagrams Structural Diagrams

The structural diagrams represent the static aspect of the system. These static aspects represent those parts of a diagram which forms the main structure and therefore stable. These static parts are represents by classes, interfaces, objects, components and nodes. The four structural diagrams are: Class diagram Object diagram Component diagram Deployment diagram

Class Diagram Class diagrams are used for: Describing the static view of the system. Showing the collaboration among the elements of the static view. Describing the functionalities performed by the system. Construction of software applications using object oriented languages.

Points to be remembered The name of the class diagram should be meaningful to describe the aspect of the system. Each element and their relationships should be identified in advance. Responsibility (attributes and methods) of each class should be clearly identified. For each class minimum number of properties should be specified. Because unnecessary properties will make the diagram complicated. Use notes when ever required to describe some aspect of the diagram. Because at the end of the drawing it should be understandable to the developer/coder. Finally, before making the final version, the diagram should be drawn on plain paper and rework as many times as possible to make it correct.

First of all Order and Customer are identified as the two elements of the system and they have a one to many relationship because a customer can have multiple orders. We would keep Order class is an abstract class and it has two concrete classes (inheritance relationship) SpecialOrder and NormalOrder. The two inherited classes have all the properties as the Order class. In addition they have additional functions like dispatch () and receive ().

Object Diagram: Object diagrams can be described as an instance of class diagram. So these diagrams are more close to real life scenarios where we implement a system. Object diagrams are a set of objects and their relationships just like class diagrams and also represent the static view of the system. The usage of object diagrams is similar to class diagrams but they are used to build prototype of a system from practical perspective. Class diagram vs. object diagram a class diagram represents an abstract model consisting of classes and their relationships. But an object diagram represents an instance at a particular moment which is concrete in nature.

Object diagrams can be used for Forward and reverse engineering. Object relationships of a system Static view of an interaction. Understand object behaviour and their relationship from practical perspective.

Component Diagram:

Component diagrams represent a set of components and their relationships. These components consist of classes, interfaces or collaborations. So Component diagrams represent the implementation view of a system. During design phase software artifacts (classes, interfaces etc) of a system are arranged in different groups depending upon their relationship. Now these groups are known as components. Finally, component diagrams are used to visualize the implementation. Component diagrams are used for Model the components of a system. Model database schema. Model executables of an application. Model system's source code.

Deployment Diagram:

Deployment diagrams are a set of nodes and their relationships. These nodes are physical entities where the components are deployed. Deployment diagrams are used for visualizing deployment view of a system. This is generally used by the deployment team. Usage: To model the hardware topology of a system. To model embedded system. To model hardware details for a client/server system. To model hardware details of a distributed application. Forward and reverse engineering.

Behavioral Diagrams:

Any system can have two aspects, static and dynamic. So a model is considered as complete when both the aspects are covered fully. Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be further described as the changing/moving parts of a system. UML has the following five types of behavioral diagrams: Use case diagram Sequence diagram Collaboration diagram State chart diagram Activity diagram

Overview of UML Diagrams

UML sequence diagrams sequence diagram: an "interaction diagram" that models a single scenario executing in the system perhaps 2nd most used UML diagram (behind class diagram)

Sequence Diagrams describe interactions among classes. These interactions are modeled as exchange of messages. These diagrams focus on classes and the messages they exchange to accomplish some desired behavior. Sequence diagrams are a type of interaction diagrams.

Key parts of a sequence diagram

Class roles, which represent roles that objects may play within the interaction. Lifelines, which represent the existence of an object over a period of time. Activations, which represent the time during which an object is performing an operation. Messages, which represent communication between objects.

Sequence diag. from use case

Sequence Diagram Example A sequence diagram for hotel reservation system. The object initiating the sequence of messages is a Reservation window.

Diagram Explanation The Reservation window sends a makeReservation() message to a HotelChain. The HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has available rooms, then it makes a Reservation and a Confirmation.

Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow is a message call. An arrow goes from the sender to the top of the activation bar of the message on the receiver's lifeline. The activation bar represents the duration of execution of the message. In our diagram, the Hotel issues a self call to determine if a room is available. If so, then the Hotel creates a Reservation and a Confirmation. The asterisk on the self call means iteration (to make sure there is available room for each day of the stay in the hotel). The expression in square brackets, [ ], is a condition.

Sequence Diagram Example

Representing objects squares with object type, optionally preceded by object name and colon write object's name if it clarifies the diagram object's "life line" represented by dashed vert. line

Messages between objects message (method call) indicated by horizontal arrow to other object write message name and arguments above arrow

dashed arrow back indicates return

Lifetime of objects creation: arrow with 'new' written above it notice that an object created after the start of the scenario appears lower than the others

deletion: an X at bottom of object's lifeline Java doesn't explicitly delete objects; they fall out of scope and are garbage-collected

Indicating selection and loops frame: box around part of a sequence diagram to indicate selection or loop if -> (opt) [condition] if/else -> (alt) [condition], separated by horiz. dashed line loop -> (loop) [condition or items to loop over]

Example sequence diagram

sd Example

StoreFront

Cart

Inventory

loop

AddItem ReserveItem

Checkout ProcessOrder ConfirmOrder

PlaceItemInOrder

Collaboration Diagram Example A collaboration diagram for student admission. Collaboration diagrams show the same information that is depicted in a sequence diagram but emphasize the organization of objects rather than the time ordering.

Collaboration Diagram Example Collaboration diagrams are also interaction diagrams. They convey the same information as sequence diagrams, but they focus on object roles instead of the times that messages are sent. In a sequence diagram, object roles are the vertices and messages are the connecting links.

Each message in a collaboration diagram has a sequence number. The top-level message is numbered 1. Messages at the same level (sent during the same call) have the same decimal prefix but suffixes of 1, 2, etc. according to when they occur.

Activity Diagrams Activity diagrams show the sequence of activities in a process, including sequential and parallel activities. Symbols are used for activities, decisions and so on. Arrows represent events that connect the activities. Ask what happens first, second, and so on. Determine if the activities happen in sequence or parallel. Examine all the scenarios for a use case.

Activity Diagram Symbols

Activity Diagram Example

Activity Diagram Example An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart diagrams are related. While a statechart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process. The activity diagram shows the how those activities depend on one another. The three involved classes (people, etc.) of the activity are Customer, ATM, and Bank. The process begins at the black start circle at the top and ends at the concentric white/black stop circles at the bottom. The activities are rounded rectangles.

Activity Diagram Example Activity diagrams can be divided into object swimlanes that determine which object is responsible for which activity. A single transition comes out of each activity, connecting it to the next activity. A transition may branch into two or more mutually exclusive transitions. Guard expressions (inside [ ]) label the transitions coming out of a branch. A branch and its subsequent merge marking the end of the branch appear in the diagram as hollow diamonds. A transition may fork into two or more parallel activities. The fork and the subsequent join of the threads coming out of the fork appear in the diagram as solid bars.

State chart Diagrams

Statechart diagrams show class states and the events that cause them to transition between states. It is also called a state transition diagram An event happens at a specific time and place. They cause a change of state, or the transition fires Each time an object changes state, some of its attributes must change. There must be a method to change the attributes. Often there is a display screen or Web form to enter the attributes.

Statechart diagrams are not created for all classes. They are created when: A class has a complex life cycle. An instance of a class may update its attributes in a number of ways through the life cycle. Two classes depend on each other. The objects current behavior depends on what happened previously. Purpose of Statechart Diagrams Statechart diagram is used to describe the states of different objects in its life cycle. States can be identified as the condition of objects when a particular event occurs. Purpose: To model dynamic aspect of a system. To model life time of a system. To describe different states of an object during its life time. Define a state machine to model states of an object. Statechart Example A statechart diagram of an order management system

Statechart Example A statechart diagram showing how a student progresses from a potential student to a graduated student