8/8/2019 27118240 Case Study UML

1/21

CASE STUDY

ON

UML(Unified modeling Language)

LORD KRISHNA COLLEGE OF TECHNOLOGY

Indore (M.P.)

GUIDED BY: SUBMITTED BY:

Mr. Mohsin Sheikh Ganesh PrakashRoll no.-0835CS071023

CS branch, 3rd Year.

8/8/2019 27118240 Case Study UML

2/21

8/8/2019 27118240 Case Study UML

3/21

Introduction

UML is a result of the evolution of object-oriented modeling languages. It was developed

by Rational Software Company by unifying some of the leading object-oriented modelingmethods,

Booch by Grady Booch, OMT (Object Modeling Technique), by Jim Raumbaugh and

OOSE (Object-Oriented Software Engineering), by Ivar Jacobson.

UML is used for modeling software systems; such modeling includes analysis and

design. By an analysis the system is first described by a set of requirements, and

then by identification of system parts on a high level. The design phase is tightlyconnected to the analysis phase. It starts from the identified system parts and

continues with detailed specification of these parts and their interaction. For the

early phases of software projects UML provide support for identifying and

specifying requirements as use cases. Class diagrams or component diagrams can

be used for identification of system parts on a high level. During the design phaseclass diagrams, interaction diagrams, component diagrams and state chart

diagrams can be used for comprehensive descriptions of the different parts in thesystem.

Modeling is an activity that has been carried out over the years in software development.

When writing applications by using the simplest languages to the most powerful and

complex languages, you still need to model. Modeling can be as straightforward asdrawing a flowchart listing the steps carried out by an application. Defining a model

makes it easier to break up a complex application or a huge system into simple, discrete

pieces that can be individually studied. We can focus more easily on the smaller parts of

a system and then understand the "big picture." Hence, the reasons behind modeling canbe summed up in two words:

Readability

Reusability

Readability brings clarityease of understanding. Understanding a system is the firststep in either building or enhancing a system. This involves knowing what a system is

made up of, how it behaves, and so forth. Modeling a system ensures that it becomes

readable and, most importantly, easy to document. Depicting a system to make it readableinvolves capturing the structure of a system and the behavior of the system.

Reusability is the byproduct of making a system readable. After a system has been

modeled to make it easy to understand, we tend to identify similarities or redundancy, be

they in terms of functionality, features, or structure.

Even though there are many techniques and tools for modeling, in this article series, we

will be concerning ourselves with modeling object-oriented systems and applications

using the Unified Modeling Language. The Unified Modeling Language, or UML, as it is

8/8/2019 27118240 Case Study UML

4/21

popularly known by its TLA (three-letter acronym!), is the language that can be used to

model systems and make them readable. This essentially means that UML provides the

ability to capture the characteristics of a system by using notations. UML provides a widearray of simple, easy to understand notations for documenting systems based on the

object-oriented design principles. These notations are called the nine diagrams of UML.

UML does not have any dependencies with respect to any technologies or languages.

This implies that we can use UML to model applications and systems based on either ofthe current hot technologies; for example, J2EE and .NET. Every effort has been made to

keep UML as a clear and concise modeling language without being tied down to any

technologies.

UML Diagrams

The underlying premise of UML is that no one diagram can capture the different

elements of a system in its entirety. Hence, UML is made up of nine diagrams that can be

used to model a system at different points of time in the software life cycle of a system.The nine UML diagrams are:

Use case diagram: The use case diagram is used to identify the primary elements

and processes that form the system. The primary elements are termed as "actors"

and the processes are called "use cases." The use case diagram shows whichactors interact with each use case.

Class diagram: The class diagram is used to refine the use case diagram and

define a detailed design of the system. The class diagram classifies the actorsdefined in the use case diagram into a set of interrelated classes. The relationship

or association between the classes can be either an "is-a" or "has-a" relationship.

Each class in the class diagram may be capable of providing certainfunctionalities. These functionalities provided by the class are termed "methods"of the class. Apart from this, each class may have certain "attributes" that

uniquely identify the class.

Object diagram: The object diagram is a special kind of class diagram. An objectis an instance of a class. This essentially means that an object represents the state

of a class at a given point of time while the system is running. The object diagram

captures the state of different classes in the system and their relationships orassociations at a given point of time.

State diagram: A state diagram, as the name suggests, represents the different

states that objects in the system undergo during their life cycle. Objects in the

system change states in response to events. In addition to this, a state diagram alsocaptures the transition of the object's state from an initial state to a final state in

response to events affecting the system.

Activity diagram: The process flows in the system are captured in the activitydiagram. Similar to a state diagram, an activity diagram also consists of activities,

actions, transitions, initial and final states, and guard conditions.

Sequence diagram: A sequence diagram represents the interaction betweendifferent objects in the system. The important aspect of a sequence diagram is that

8/8/2019 27118240 Case Study UML

5/21

it is time-ordered. This means that the exact sequence of the interactions between

the objects is represented step by step. Different objects in the sequence diagram

interact with each other by passing "messages".

Collaboration diagram: A collaboration diagram groups together the

interactions between different objects. The interactions are listed as numbered

interactions that help to trace the sequence of the interactions. The collaborationdiagram helps to identify all the possible interactions that each object has with

other objects.

Component diagram: The component diagram represents the high-level partsthat make up the system. This diagram depicts, at a high level, what components

form part of the system and how they are interrelated. A component diagram

depicts the components culled after the system has undergone the development or

construction phase. Deployment diagram: The deployment diagram captures the configuration of the

runtime elements of the application. This diagram is by far most useful when a

system is built and ready to be deployed.

UML Diagram ClassificationStatic, Dynamic, and Implementation

A software system can be said to have two distinct characteristics: a structural, "static"

part and a behavioral, "dynamic" part. In addition to these two characteristics, an

additional characteristic that a software system possesses is related to implementation.Before we categorize UML diagrams into each of these three characteristics, let us take a

quick look at exactly what these characteristics are.

Static: The static characteristic of a system is essentially the structural aspect of

the system. The static characteristics define what parts the system is made up of.

Dynamic: The behavioral features of a system; for example, the ways a systembehaves in response to certain events or actions are the dynamic characteristics of

a system.

Implementation: The implementation characteristic of a system is an entirely

new feature that describes the different elements required for deploying a system.

The UML diagrams that fall under each of these categories are:

Static

o Use case diagram

o Class diagram

Dynamico Object diagram

o State diagram

o Activity diagram

o Sequence diagram

o Collaboration diagram

Implementation

o Component diagram

8/8/2019 27118240 Case Study UML

6/21

o Deployment diagram

4+1 View of UML Diagrams

Considering that the UML diagrams can be used in different stages in the life cycle of a

system, let us take a look at the "4+1 view" of UML diagrams. The 4+1 view offers adifferent perspective to classify and apply UML diagrams. The 4+1 view is essentially

how a system can be viewed from a software life cycle perspective. Each of these views

represents how a system can be modeled. This will enable us to understand where exactlythe UML diagrams fit in and their applicability.

These different views are:

Design View: The design view of a system is the structural view of the system.

This gives an idea of what a given system is made up of. Class diagrams andobject diagrams form the design view of the system.

Process View: The dynamic behavior of a system can be seen using the processview. The different diagrams such as the state diagram, activity diagram, sequence

diagram, and collaboration diagram are used in this view. Component View: Next, you have the component view that shows the grouped

modules of a given system modeled using the component diagram.

Deployment View: The deployment diagram of UML is used to identify thedeployment modules for a given system. This is the deployment view of the

Use case View: Finally, we have the use case view. Use case diagrams of UML

are used to view a system from this perspective as a set of discrete activities ortransactions.

Features in UML Tools

This takes us to an important questionwhat exactly should we look for in a UML tool?

Because the primary use of a UML tool is to enable you to draw diagrams, first and

foremost, we need to see what types of UML diagrams the tool supports. But, is drawingUML diagrams all that you would expect from a UML tool? For example, wouldn't it be

great if the class diagrams that you draw in the tool can somehow be used to generate the

source code for actual Java classes or C++ classes?

Let us take a look at another scenario. Suppose you were given a large set of source code

files with lots and lots of classes. Wouldn't it be a nightmare wading through the codetrying to figure out how all the classes are interconnected? This is where UML tools step

in to make things a lot easier by providing support for such features. Now, let's definethese features in technical terms:

UML diagram support: The UML tool should support all the nine diagrams that

make up UML. You should look for a tool that supports drawing use cases,

designing the static view diagrams such as class diagrams and object diagrams,

8/8/2019 27118240 Case Study UML

7/21

defining the dynamic view diagrams such as sequence, activity, state, and

collaboration diagrams and the component and deployment diagrams that form

the implementation view of the system.

Forward engineering: A UML tool should not have its use limited to just a

pictorial depiction of diagrams. Because the structure of the system defined by the

diagram is translated by a developer into actual source code (classes), the UMLtool should bridge this step by generating the source code of the classes with the

methods stubbed out. Developers can take up this stub code and fill in with the

actual code. This characteristic of automating the generation of source code iscalled forward engineering. Forward engineering support by a UML tool is

normally for a specific language or a set of languages. If you are a Java developer,

verify that the UML tool that you want to use has forward engineering support for

Java. Similarly, if you are a C++ developer, the UML tool should provide youforward engineering support for C++.

Reverse engineering: Reverse engineering is exactly the opposite of forward

engineering. In reverse engineering, the UML tool loads all the files of the

application/system, identifies dependencies between the various classes, andessentially reconstructs the entire application structure along with all the

relationships between the classes. Reverse engineering is a feature normallyprovided by sophisticated and high-end UML tools.

Round-trip engineering: Another useful feature apart from forward and reverse

engineering is round-trip engineering. Forward and reverse engineering are

essentially one-off activities that take input and generate the required output.Round-trip engineering extends these features.

An important rule in software design is that no design remains unchanged. This isas true for small systems as it is for large systems. During development, the

design structure defined in the UML model does undergo changes to incorporate

physical differences in implementation that may not have been envisaged duringdesign. It becomes very difficult to keep the design of the system updated with the

changes in the source code. The round-trip engineering feature enables the UML

tool to synchronize the model with the changes in the application code.

Documentation: Documentation is an integral aspect of a UML tool. Software

designing, by nature, is an abstract process. Apart from a few syntax and semantic

ground rules, there are no other rules. The thought process of a software architect

who designs applications using UML can be lost if the reasons behind certaindesign decisions are not captured and well documented. This becomes painfully

clear when large systems are maintained and no one has a clue to why a

subsystem was designed in a certain way. Hence, a UML tool must necessarilyprovide some way for the designer to document design decisions in the diagrams

by using simple things such as annotations or comments. In addition to this, the

UML tool should support the generation of reports/listings of the different designelements of the diagram.

Apart from the above features, you should also identify a few features that would

definitely be useful to have in the UML tool.

8/8/2019 27118240 Case Study UML

8/21

Version control: A very important feature that we want to have in the UML tool

is either an integrated version control mechanism or connectivity to a standard

version control system. Configuration management is an integral part in thebuilding of software systems. Considering that the design of a system is a very

important artifact of the software lifecycle, maintaining versions and baselines of

the system design is a desirable feature to have in UML tools. In the absence ofdirect support for version control, it is the responsibility of the designer to

maintain versions of the design.

Collaborative modeling environment: Enterprise systems are huge and theirdesigns are quite complex. While designing complex systems, there may be

different teams involved and may carry out design work on different subsystems

in parallel. This collaborative design effort needs to be properly synchronized by

the UML tool. The UML tool should provide support for a collaborative modelingenvironment with capability to compare different versions designs for differences

or even merge different versions of a design. Collaborative modeling is always a

nice feature to have in UML tools.

Integration with popular Integrated Development Environments (IDE): Withthe increasing use of iterative methodologies for building software systems, it

becomes very difficult to keep the design of the system in sync with thedeveloped code. Hence, it would be useful if the UML tool provides integration

with popular IDEs. This feature would enable the UML tool to be updated with

the changes in the source code made in the IDE.

Test script generation: The system or subsystem designed in a UML tool mayrepresent a set of functional aspects as well. Hence, it would be really useful if, in

addition to generating stub code, the tool also generates test scripts that can be

used for testing how the generated class functions.

Model View Controller (MVC) modeling: Enterprise application architectures

have increasingly begun to standardize and are based on the Model View

Controller architecture. Hence, if you design n-tier, Web-enabled enterpriseapplications, you should look for a UML tool that supports designing applications

based on the MVC architecture. Support for MVC modeling makes it easier to

organize and clearly distinguish the design elements along the lines of the MVClayers. This will help in the long run in improving the readability of the model.

Popular UML Tools

We will list here a few of the "movers and shakers" of vendors of UML tools. Please note

that this list is by no means exhaustive and is not meant to provide any ranking for any

UML tool.

Rational Rose: No discussion of UML tools is complete without the mention of

the Rational Rose modeling tool from Rational Software Corporation. Rational

Rose (the Rose stands for "Rational Object-oriented Software Engineering") is a

visual modeling tool for UML. It comes in different versions suited to differentrequirements. Rational Rose provides support for all the standard features that we

discussed in the previous section such as UML diagram support, forward and

8/8/2019 27118240 Case Study UML

9/21

reverse engineering support, and documentation and round-trip engineering

support. Apart from this, Rational Rose also provides support for version control,

IDE integration, design pattern modeling, test script generation, and collaborativemodeling environment. In addition, Rational Rose also supports the designing of

data models within the same environment. An interesting feature of Rational Rose

is the ability to publish the UML diagrams as a set of Web pages and images. Thisenables you to share and distribute your application design where the Rational

Rose tool is not installed.

Together Control Center: Together Control Center (formerly fromTogethersoft) from Borland is an entire suite of visual modeling tools for UML.

Together Control Center supports UML diagrams, MVC modeling, forward and

reverse engineering, and round-trip engineering, as well as integration with IDEs

such as IBM WebSphere Studio.

It supports comprehensive documentation and a powerful collaborative modeling

environment.

An added feature of Together Control Center is the pattern repository. The pattern

repository (similar to the template-driven modeling concept discussed above)makes frequently used diagrams and design patterns readily available for reuse in

modeling. Together Control Center supports the Rational Unified Process as well

as the Extreme Programming methodologies.

Poseidon: Poseidon from Gentle ware has its roots in the Agrium open sourceproject. The Agrium modeling tool evolved as an open source effort and is a

useful, full-featured UML tool freely available under the Open Publication

License. Gentle ware has taken Agrium a step further and turned it into a good

modeling tool. Poseidon comes in different flavors suited to differentrequirements. Poseidon supports forward and reverse engineering and

documentation generation by using special-purpose plug-ins.

Gentle ware has not forgotten its open source moorings and offers the Poseidonfor UML Community Edition 1.5 free for individual software developers.

8/8/2019 27118240 Case Study UML

10/21

Representations

Types of Things

Name Symbol Description Variations/

other

related

elements

Class

Description of a set of objects thatshare the same: attributes, operations,relationships and semantics.

- actors

- signals

- utilities

Interface A collection of operations that specifya service of a class or component.

Collaboration An interaction and a society or rolesand other elements that work togetherto provide some cooperative behavior

that is bigger than the sum of all theelements. Represent implementation of

patterns that make up the system.

Actor The outside entity that communicateswith a system, typically a person

playing a role or an external device

Use Case A description of set of sequence ofactions that a system perform thatproduces an observable result of valueto a particular actor. Used to structure

behavioral things in the model.

Active class A class whose objects own a process orexecution thread and therefore caninitiate a control activity on their own

Component A component is a physical and

replicable part that conforms to and provides the realization of a set ofinterfaces.

Node A physical resource that exists in runtime and represents a computational

resource.

8/8/2019 27118240 Case Study UML

11/21

Interaction Set of messages exchanged among aset of objects within a particularcontext to accomplish a specific

purpose.

State machine A behavior that specifies the sequencesof states an object or an interactiongoes through during its lifetime in

response to events, together with itsresponses to those events.

Packages General purpose mechanism oforganizing elements into groups.

Note A symbol for rendering notes andconstraints attached to an element or a

collection of elements.

Relations

The types of UML relationships are shown in the table 2, relationships are used toconnect things into well defined models (UML diagrams).

8/8/2019 27118240 Case Study UML

12/21

Use-case diagram

A use case illustrates a unit of functionality provided by the system. The main purpose of

the use-case diagram is to help development teams visualize the functional requirementsof a system, including the relationship of "actors" (human beings who will interact with

the system) to essential processes, as well as the relationships among different use cases.

Use-case diagrams generally show groups of use cases either all use cases for thecomplete system, or a breakout of a particular group of use cases with related

functionality (e.g., all security administration-related use cases). To show a use case on a

8/8/2019 27118240 Case Study UML

13/21

use-case diagram, you draw an oval in the middle of the diagram and put the name of the

use case in the center of, or below, the oval. To draw an actor (indicating a system user)

on a use-case diagram, you draw a stick person to the left or right of your diagram (andjust in case you're wondering, some people draw prettier stick people than others).

Class diagram

The class diagram shows how the different entities (people, things, and data) relate to

each other; in other words, it shows the static structures of the system. A class diagram

can be used to display logical classes, which are typically the kinds of things the business

people in an organization talk about. . Class diagrams can also be used to showimplementation classes, which are the things that programmers typically deal with. An

implementation class diagram will probably show some of the same classes as the logical

8/8/2019 27118240 Case Study UML

14/21

classes diagram. The implementation class diagram won't be drawn with the same

attributes, however, because it will most likely have references to things like Vectors and

Hash Maps.

Object Diagram

An Object diagram focuses on some particular set of object instances and attributes, andthe links between the instances. A correlated set of object diagrams provides insight into

how an arbitrary view of a system is expected to evolve over time. Object diagrams are

more concrete than class diagrams, and are often used to provide examples, or act as test

8/8/2019 27118240 Case Study UML

15/21

cases for the class diagrams. Only those aspects of a model that are of current interest

need be shown on an object diagram.

Sequence diagram

Sequence diagrams show a detailed flow for a specific use case or even just part of a

specific use case. They are almost self explanatory; they show the calls between the

different objects in their sequence and can show, at a detailed level, different calls to

different objects. A sequence diagram has two dimensions: The vertical dimension showsthe sequence of messages/calls in the time order that they occur; the horizontal dimension

shows the object instances to which the messages are sent. A sequence diagram is very

simple to draw. Across the top of your diagram, identify the class instances (objects) byputting each class instance inside a box.

8/8/2019 27118240 Case Study UML

16/21

State-chart diagram

The state-chart diagram models the different states that a class can be in and how thatclass transitions from state to state. It can be argued that every class has a state, but that

every class shouldn't have a state-chart diagram. Only classes with "interesting" states

that is, classes with three or more potential states during system activity should bemodeled. The notation set of the state-chart diagram has five basic elements: the initial

starting point, which is drawn using a solid circle; a transition between states, which is

drawn using a line with an open arrowhead; a state, which is drawn using a rectangle withrounded corners; a decision point, which is drawn as an open circle; and one or more

termination points, which are drawn using a circle with a solid circle inside it. To draw a

state-chart diagram, begin with a starting point and a transition line pointing to the initial

8/8/2019 27118240 Case Study UML

17/21

state of the class. Draw the states themselves anywhere on the diagram, and then simply

connect them using the state transition lines.

Activity diagram

Activity diagrams show the procedural flow of control between two or more class objects

while processing an activity. Activity diagrams can be used to model higher-levelbusiness process at the business unit level, or to model low-level internal class actions. In

my experience, activity diagrams are best used to model higher-level processes, such as

how the company is currently doing business, or how it would like to do business. This isbecause activity diagrams are "less technical" in appearance, compared to sequence

diagrams, and business-minded people tend to understand them more quickly.

8/8/2019 27118240 Case Study UML

18/21

Component diagram

A component diagram provides a physical view of the system. Its purpose is to show thedependencies that the software has on the other software components (e.g., software

libraries) in the system. The diagram can be shown at a very high level, with just the

large-grain components, or it can be shown at the component package level. [Note: Thephrase component package level is a programming language-neutral way of referring to

class container levels such as .Nets namespaces (e.g., System.Web.UI) or Java's

packages (e.g., java.util).]

8/8/2019 27118240 Case Study UML

19/21

Deployment diagram

The deployment diagram shows 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. Since thediagram models the physical runtime, a system's production staff will make considerable

use of this diagram. The notation in a deployment diagram includes the notation elements

used in a component diagram, with a couple of additions, including the concept of a node.A node represents either a physical machine or a virtual machine node (e.g., a mainframe

8/8/2019 27118240 Case Study UML

20/21

node). To model a node, simply draw a three-dimensional cube with the name of the node

at the top of the cube.

Conclusion:

UML does not provide the magic solution to all embeddeddevelopment problems. However, it is possible to make significant steps to improve the

productivity of a developer by using UML model-driven development and robust and

powerful OO language. Alleviating the chaos of complex software development is the

8/8/2019 27118240 Case Study UML

21/21

primary motivation for using UML to describe and build software. Finally, code

generation increases UML's value to the developer by reducing errors and improving

productivity.