What is UML?
In simple terms, UML stands for Unified Modeling Language.
The question arises, what is "Unified"? Unified means multiple models integrated into a single model. In around 1970s, may authors developed multiple modeling languages, thus creating confusion among users. Hence, they came together and created a unified model.
So, what is modeling? Modeling is the way of depicting reality with the help of diagrams.
What is language? Language is the art which helps us to communicate between each other.
Now, what's a "Modeling Language"?
A modeling language gives "Iconography" and "Semantics" to express a concept.
Now, what's "Iconography"?
A modeling language provides "Iconography" and "Semantics" to express sample icons.
Now, what's "Semantics"?
"Semantics" are rules for using those icons.
UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. Object Management Group (OMG) created UML and UML 1.0. The summary of the specification was proposed to the OMG in January 1997. UML can be described as a general-purpose visual modeling language to visualize, specify, construct and document software systems. Although UML is generally used to model software systems, its work does not end here. It is also used to model non-software systems as well like process flow in a manufacturing unit etc. UML is not a programming language but tools can be used to generate code in various languages using UML diagrams.
UML is a general-purpose modeling language. It was initially run to capture the behavior of complex software and non-software system and now it has become an OMG standard.
UML offers elements and components to model the fundamentals of complex systems. It follows the object-oriented concepts and techniques. Hence, using the pictorial language, we can cast the object-oriented systems.
UML diagrams are illustrated from different perspectives like design, implementation, deployment, etc. To end with, we can define UML as a modeling language to round up the architectural, behavioral and structural aspects of a system.
Objects are the means to this object-oriented world. To identify the object efficiently is the basic condition of object-oriented analysis and design. After that, the duties are assigned to the objects. After completing the task, the design is done using the input from the analysis. UML has a key role in this OO analysis and design; The UML diagrams are used to model the design which makes it more important.
In this blog, we will discuss about
3. Modeling Architecture Views using UML
4. Fourteen Type of Diagrams in UML
Purpose of UML
A picture is worth a thousand words, is what fits well about UML. Object-oriented concepts were brought into view much earlier than UML. So at that time, there were no standard methodologies to arrange and merge the object-oriented development. At that point in time UML came into the picture. There are a number of goals for developing UML but the most important is:
- To define some general-purpose modeling language, which is pretty simple to understand and use by all the modelers.
- It is not only made for developers but also for business users, common people and anybody interested to understand the system.
- It can be software or non-software.
- To be clear, the UML is not a development method rather it accompanies processes to make a successful system.
Lastly, the goal of UML can be defined as a simple modeling mechanism to model all possible practical systems in today’s complex environment.
History of UML
Different approaches to object-oriented analysis and design began appearing between the mid-1970s and late 1980s. As various methods were evolving in the same direction, authors of the models decided to come up with a unified modeling language. Several organizations found UML strategic to their business. Object Management Group (OMG) played a crucial role in unifying the models. Present UML version is v2.5.
Modeling Architecture Views using UML
Different users use any real-world system. The users can be developers, testers, business people, analysts and many more. So before designing a system the architecture is made with different perspectives in mind. The most important part is to visualize the system from different viewers’ perspective. The better we understand the better we make the system. This set of views is known as the 4+1 Views of Software Architecture. UML plays an important role in defining different perspectives of a system. These perspectives are:
- Use Case View
+ 4 Architecture views
- Design
- Implementation
- Process
- Deployment
And the center 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 the use case.
- Use-case view: Describes the functionality of the system, its external interfaces, and its principal users. The use-case view contains the Use-Case Model. This view is mandatory when using the 4+1 Views because all elements of the architecture should be derived from requirements.
- Logical view: Describes how the system is structured in terms of units of implementation. The elements are packages, classes, and interfaces. The relationship between elements shows dependencies, interface realizations, part-whole relationships, and so forth. Note: This view is mandatory when using the 4+1 Views of Software Architecture.
- Implementation view: Describes how development artifacts are organized in the file system. The elements are files and directories (any configuration items). This includes the development of artifacts and deployment artifacts. This view is optional when using the 4+1 Views.
- Process view: Describes how the run-time system is structured as a set of elements that have run-time behavior and interactions. Run-time structure often bears little resemblance to the code structure. It consists of rapidly changing networks of communication objects. The elements are components that have a run-time presence (processes, threads, Enterprise JavaBeans™ (EJB™), servlets, DLLs, and so on), data stores, and complex connectors, such as queues. Interaction between elements varies, based on technology. This view is useful for thinking about run-time system quality attributes, such as performance and reliability. This view is optional when using the 4+1 Views.
- Deployment views: Describe how the system is mapped to the hardware. This view is optional when using the 4+1 Views.
In addition, you may wish to represent the following:
- Data view: A specialization of the logical view. Use this view if persistence is a significant aspect of the system, and the translation from the design model to the data model is not done automatically by the persistence mechanism.
Want to read later? Download the eBook
Fourteen Type of Diagrams in UML
Diagrams are the heart of UML. These diagrams are broadly categorized as structural and behavioral diagrams.
- Structural diagrams consist of static diagrams like class diagram, objects diagram, etc.
- Behavioral diagrams consist of dynamic diagrams like sequence diagram, collaboration diagram, etc.
Structural Modeling
Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other. The elements in a structure diagram represent the meaningful concepts of a system and may include abstract, real-world and implementation concepts, there are seven types of structure diagram as follows:
- Classes diagrams
- Objects diagrams
- Deployment diagrams
- Package diagrams
- Composite structure diagram
- Component diagram
- Profile Diagram
Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time, there are seven types of behavior diagrams as follows:
- Use Case Diagram
- Activity Diagram
- State Machine Diagram
- Sequence Diagram
- Communication Diagram
- Interaction Overview Diagram
- Timing Diagram
Use Cases and Scenarios
Use cases and scenarios describe how actors (a person or a system) interact with a solution to accomplish one or more of that person or systems goals. Use case has 2 parts: Use case diagram and Use case specifications. Scenarios depict series of steps performed by actors and solution to achieve a goal. A use case describes several scenarios in form of primary, and alternate or exception flows. The use case diagram for a project control system is shown below:
Use case diagram: Visually depicts scope of solution, actors involved, and use cases.
Associations: Relationships between actors and use cases are known as associations. 2 commonly used relationships are:
Extend: Allows for insertion of additional behavior into a use case. Here, base use case gets extended by the extended use case. Extended use case is optional and its execution ALWAYS depends on a condition. Point at which extension occurs is called extension point.
Base use case is complete without extended use case where as extended use case is incomplete without base use case.
Include: Allows base use case to make use of functionality present in another use case. Included use case is ALWAYS executed. Base use case is incomplete without included use case.
Common function is included and Mandatory. Additional function is Extend and Non-mandatory.
Use case description
Use case description provides details of step by step interaction in use cases. Typically, following are included in use case descriptions.
Name
A unique name comprising of a verb and noun.
Goal
Brief description of a successful outcome of use case from an actor’s perspective.
Actors
Any person, system, or event external to system under design that interacts with that system. Each actor must be given a unique name representing the role they play system interactions. A particular person may fill roles of multiple actors over time. A use case is started by an actor, referred to as primary actor for that use case. Other actors who participate in use case in a supporting role are called secondary actors. Roles may not match with job titles, and should NEVER be name of actual persons.
Trigger
An event (action taken by a primary actor) to initiate use case.
Flow of events
Set of steps performed by actor and solution during the use case.
Type of flows:
Basic, primary or main success flow:
Shortest or simplest successful path to achieve an actor’s goal.
Alternative flow: Other paths to be followed to achieve an actor’s goal.
Exception flow: If circumstance does not allow actor to achieve its goal, use case is considered unsuccessful, and is terminated. For example, in a bank transaction, ATM machine asking user to change amount based on account balance. Exception flows are ones where application fails to achieve goal, say e.g., ATM fails to connect to bank server.
Post-conditions or guarantees
Any fact that must be true when use case is complete. MUST be true for all flows. Can be different for successful and unsuccessful outcomes of use case.
Strengths
- Good at clarifying scope and providing a high-level understanding of requirements.
- Use case specifications make it easy to understand functional behavior of a system.
Limitations
- Written at higher-level of abstraction (low level of detail).
- Lack of standardized formats.
- Need analysis to identify include use cases.
Solved Example:
Let’s learn the use case model by means of an example. GRCPerfect is a Governance, Risk and Compliance Management System developed for the IT and ITES domain. The primary objective of GRCPerfect is to help companies implement Governance, Quality, and Information Security Management Systems in an integrated manner. It has various features, one of which is to plan and track projects and programs using standards such as CMMI, ISO 9001, and ISO 27001 etc.
Through this example let’s try to understand how a user logs in to the GRCPerfect system.
Data Flow Diagrams (DFDs)
Show transformation of data from (data source such as external sources, data processing activities, and destinations of data). Data used in DFDs should be described in data dictionary. Highest level diagram (Level 0) is context diagram representing the entire system.
Level 1 DFDs show processes related to system with respective input data, output transformed data and data stores.
Further levels (level 2 and 3) break down major processes from level 1 diagram.
Logical data flow diagrams represent future or essential state. Physical data flow diagrams model all of data stores, printers, forms, devices and other manifestations of data of current or future state.
Externals (Entity) (Source, or Sink or both) - Person, organization, system, or device providing or receiving data. These are outside of the system under analysis. Each external must have at least one data flow going to or coming from it. Represented by using a noun inside a rectangle.
Data store
Stores data for future use. Must have at least one data flow going to or coming from it. Represented as 2 parallel lines or as an open-ended rectangle with a label.
Data Process
Transforms data into an output. Names contain a verb and a noun. Must have at least one data flow going to it and one data flow coming from it. Represented as a circle or rectangle with rounded corners.
Data flow
Movement of data between an external, a process and a data store. Represented as a line with an arrow displayed between processes. Named using nouns.
Strengths
- Depict transaction-based systems and boundaries of a system.
- To discover processes and data.
- Excellent way to define scope and interfaces.
- Helps in effort estimation.
- Easy to understand.
- Helps to identify duplicate or missing data elements.
Limitations
- Can become complex for large-scale systems.
- Different DFD notations exist.
- Can’t show sequence of activities, logic or stakeholders.
Worked out Example:
Let’s learn the data flow diagram by means of an example. GRCPerfect is a Governance, Risk and Compliance Management System developed for the IT and ITES domain. The primary objective of GRCPerfect is to help companies implement Governance, Quality, and Information Security Management Systems in an integrated manner. It has various features, one of which is to plan and track projects and programs using standards such as CMMI, ISO 9001, and ISO 27001 etc.
Through this example let’s try to understand how the data flows and gets transformed in the project schedule management module of GRCPerfect.
An external is a person, organization, automated system, or any
device capable of producing data or receiving data. It can be a source of information (source) or sink (receiver of information). The user shown in the diagram is a source as the user has to provide the search criteria. Another source is the PM. These are represented using rectangles.
Search for schedule, delete schedule, add new schedule, update schedule etc. are data processes. Here, the data is transformed into an output. For instance, the add new schedule process provides schedule details as its output. It is represented in the form of a circle or a rectangle with rounded corners. Processes should have at least one input and one output.
Schedule and Risk DB are data stores. The schedule data store is a collection of data related to schedules where data may be read repeatedly and stored for further use. Each data store must have at least one data flow going to it or coming from it. It is represented as two parallel lines or as an open ended rectangle.
Thus, data flow diagrams portray the transformation of data. It depicts where the data comes from, the activities which process the data, whether the output results are stored or utilized by another activity etc. DFDs are relatively simple to understand and is a great way to illustrate interfaces, connections to other systems etc. However, it doesn’t illustrate the sequence of activities and can become increasingly complex for large scale systems.
Data Models
Data models describe entities, classes or data objects relevant to a domain, their attributes and relationships among them.
Conceptual data model
Data models are independent of any solution and represents how business perceives its information.
Logical data model
Normalizes data for data integrity, used to design a solution.
Physical data model
Describe physical data organization in a database. Addresses concerns like performance, concurrency and security. Logical and physical data models include elements specific to solutions, developed by Implementation SMEs.
Entity or Class
Entities represent something physical (Warehouse), something organizational (Sales Area), something abstract (Product Line), or an event (Appointment). Entities are known as classes in class diagrams. Classes contain attributes and relationships with other classes, operations describing what can be done with class, such as generating an invoice or opening a bank account. Each instance of an entity or class has a unique ID.
Attribute: Attributes define particular piece of information associated with an entity, including size, allowable values and type of information it represents. Attributes should be described in a data dictionary. Business rules often specify allowable values.
Cardinality
Minimum and maximum number of occurrences to which an entity is related another entity. Can be 0, 1 or many. Read relationship between 2 entities in either direction, using this format: Each occurrence (of this entity) is related to (minimum, maximum) (of this other entity). In a class model, term association is used instead of relationship and multiplicity is used instead of cardinality.
Entity-Relationship Diagram (Crow's Foot Notation)
Strengths
- Helps in consistent vocabulary.
- Ensures logical design of persistent data correctly represents business needs.
- Consistent approach to analyze and document data and its relationships.
- Can be at different levels of detail.
- Can expose missing requirements.
Limitations
- Requires background in software.
- Often beyond knowledge of individual stakeholders.
Worked out Example:
Let’s learn data modelling by means of an example. GRCPerfect is a Governance, Risk and Compliance Management System developed for the IT and ITES domain. The primary objective of GRCPerfect is to help companies implement Governance, Quality, and Information Security Management Systems in an integrated manner. It has various features, one of which is to plan and track projects and programs using standards such as CMMI, ISO 9001, ISO 27001 etc.
Through this example let’s try to understand the entity relationship diagram and class diagram for the project schedule management module of GRCPerfect.
ER Diagram
Here, schedule is an entity with attributes such as ID, description, status and target date. The relationship between the entities schedule and schedule history is one to many. The relationship between user and schedule is many to many. A user can create several schedules. The relationship between two entities can be read from either direction.
Class diagram
In a class diagram, entities are referred to as classes. As seen in the diagram, the various classes are schedule, projects, schedule resources, project allocation and application users. A class contains a class name, attributes and operations respectively. Let’s consider the schedule class and understand the 3 sections of a class. Schedule is the name of the class, WBS ID, Description, planned start date etc. are attributes and add and update are the operations you can carry out on the schedule class. This means a schedule can be added as well as updated.
A class has associations (same as relationship in entity model) with other classes. Here, the term multiplicity is used instead of cardinality. The association between a schedule resource and schedule is 0..* to 1 which means no resource or several resources can be assigned to a schedule.
Sequence Diagram
Sequence diagrams (also known as event diagrams) model logic of usage scenarios, by showing information (also known as stimuli, or message) passed between objects during execution of a scenario. Sequence diagrams show how objects (interface components or software components) interact but not how they are related to one another.
Objects are represented as boxes from left to right. Messages sent are represented as horizontal arrows with name on top.
Shows particular instance of each object with a lifeline below to indicate when object is created and destroyed.
Earlier events are depicted at top of lifeline, with later events shown further down. Arrival of stimulus at an object is called an event.
Sequence diagrams only specify ordering of events, not exact timings of events. An activation box represents period during which an operation is executed.
Types of messages sent between objects are
Synchronous call transfers control to receiving object. Sender waits for a return message. Typical example: Chat.
Asynchronous call (also known as a signal) allows object to continue with its own processing after sending signal. Typical example: Email.
Strengths
- Shows interactions between objects in visual and chronological (time) order.
- Refines use cases with more details.
Limitations
- Creating sequence diagram for every use case can be a waste of time and effort.
- Fairly technical.
Example:
GRCPerfect is a Governance, Risk and Compliance Management System developed for the IT and ITES domain. The primary objective of GRCPerfect is to help companies implement Governance, Quality, and Information Security Management Systems in an integrated manner. It has various features, one of which is to plan and track projects and programs using standards such as CMMI, ISO 9001, ISO 27001 etc.
Through this example let’s try to understand the sequence diagram for the “Search schedule” use case of the schedule management module of GRCPerfect system.
Main Scenario:
The Project Manager specifies a milestone name on the search page and then presses the search button. The system validates the PM’s search criteria. If the milestone name is entered, the system searches the schedule list and displays the search results on the search results page when the search is complete.
Alternate Scenario:
If the PM did not enter the milestone name before pressing the search button, the system displays an error message.
In this example, Search Page, Search Results Page etc. are objects. A lifeline is drawn as a dashed line and represents the lifespan of an object. The period during which an operation is executed is shown as an activation box which is the rectangle below the lifeline. Messages are interactions between two objects which are represented in the form of arrows.
Thus, a sequence diagram shows how processes or objects interact during a scenario. It provides a visual representation of the interactions between objects
State Model
State models (aka state transition model) analyze different possible states (formal representation of a status) of an entity within a system, how that entity changes from one state to another and what can happen to entity when it is in each state.
A state model describes:
- Set of possible states (Statuses) for an entity,
- Sequence of states,
- Events and conditions that cause state change and
- Actions that the entity can perform.
Process models show all of entities affected by the process. State models show a complementary view: what happens to one entity across all processes.
State: An entity can have can be in more than one state (Active-In progress, Inactive-Cancelled) at same time. A complex state can be decomposed into sub-states.
State transition: State transitions (can be conditional, automatic or recursive) are determined by steps of a process, by business rules, or by information content.
State sequences are not always linear; an entity could skip over several states or revert to a previous state, more than once.
State diagram
A state diagram shows life cycle of one entity, beginning when entity first comes into existence and moving by all of different states that entity may have until it is discarded and no longer of use. A state is shown as a rectangle with rounded corners.
State tables
A state table is a 2-dimensional matrix showing states and transitions between them. Used during elicitation and analysis either as an alternative, a precursor (prior), or a complement to a state diagram. A simple way to get started on a state model to elicit state names and event names from Domain SMEs.
Strengths
- Better understanding of entities having complex behavior and rules.
- Identifies business rules.
- Identifies activities applying to different states.
Limitations
- Consumes time and effort.
- Obtaining consensus is time-consuming
Worked out Example:
Let’s learn the state model by means of an example. GRCPerfect is a Governance, Risk and Compliance Management System developed for the IT and ITES domain. The primary objective of GRCPerfect is to help companies implement Governance, Quality, and Information Security Management Systems in an integrated manner. It has various features, one of which is to plan and track projects and programs using standards such as CMMI, ISO 9001, ISO 27001 etc.
Through this example let’s try to understand how a project schedule is managed in GRCPerfect.
The beginning of the entity’s life cycle (schedule is the entity here) is shown using a dark circle and end of the life cycle is showing using an encircled dark circle. In the state model shown above, we can see two super states called Active schedule and Inactive schedule. States like open, assigned, on hold and in progress are sub states under the super state Active which means a schedule in any of these states is considered active. States like cancelled and closed are sub states under the Inactive schedule super state. When a schedule is newly created by the project manager, it is in the open state. Once the PM assigns it to a resource and the resource starts working on it, the state of the schedule will be in progress. These are called state transitions. If the resource requires additional clarification on the assigned schedule, it is moved to on hold state. Note that the flow between in progress state and on hold state is bi-directional. Once the schedule in progress is completed, it goes to the closed state. One should also keep in mind that the activity can get cancelled from the open, assigned, in progress or on hold state due to certain influencing factors or known reasons. The activity ends once it is closed or cancelled.
Thus, state modelling is a technique which is used to describe and analyze the various possible states of an entity within a system, how it changes from one state to another, and what can happen to the entity when it is in each state.
A sound understanding of the states and transitions is required to build a state diagram. It is worthwhile to create state models only for entities which are perceived to be complex.
Conclusion
The UML is free and open to all. It keeps in account the needs of the user and scientific communities, as established by experience with the underlying techniques on which it is based.
Many methodologists, organizations, and tool vendors have decided to use it. Since the UML builds upon similar semantics and notation from Booch, OMT, OOSE, and other leading methods and has incorporated input from the UML partners and feedback from the general public, widespread adoption of the UML should be straightforward.
There are two aspects of “unified” that the UML achieves:
First, it effectively ends the inconsequential differences between the modeling languages of previous methods.
Secondly, and most importantly it unifies the perspectives among many different kinds of systems (business versus software), development phases (requirements analysis, design, and implementation), and internal concepts.
About Adaptive US
Adaptive US is World's #1 Provider of IIBA Certifications Courses and Study Aids. It is the ONLY training institute to provide 100% Success Guarantee or 100% Refund promise.
Website: www.adaptiveUS.com
Use Cases and Scenarios | Free Use Case Template
How to Model Software Requirements Effectively | Free UML Guide
No Comments Yet
Let us know what you think