Case Study Uml

CASE STUDY ON “UML(Unified modeling Language)” LORD KRISHNA COLLEGE OF TECHNOLOGY Indore (M.P.) GUIDED BY: SUBMITTED BY: Mr. Mohsin Sheikh Ganesh Prakash Roll no.-0835CS071023 CS branch, 3rd Year.

Table of Contents • Introduction • UML Diagrams • UML Diagram Classification • 4+1 View of UML Diagrams • Features in UML Tools • Popular UML Tools • Representations • Use Case Diagram • Class Diagram • Object Diagram • Sequence Diagram • State-chart Diagram • Activity diagram • Component Diagram • Deployment Diagram • Conclusion

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 modeling methods, • 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 tightly connected 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 phase class diagrams, interaction diagrams, component diagrams and state chart diagrams can be used for comprehensive descriptions of the different parts in the system. 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 as drawing 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 can be summed up in two words: • Readability • Reusability Readability brings clarity—ease of understanding. Understanding a system is the first step 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 readable involves 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 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 wide array 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 of the 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 which actors 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 actors defined 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 certain functionalities. 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 object is 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 or associations 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 also captures 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 activity diagram. 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 between different objects in the system. The important aspect of a sequence diagram is that 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 collaboration diagram helps to identify all the possible interactions that each object has with other objects. • Component diagram: The component diagram represents the high-level parts that 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 Classification—Static, 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 system behaves 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 oUse case diagram oClass diagram • Dynamic o Object diagram o State diagram o Activity diagram o Sequence diagram o Collaboration diagram

• Implementation o Component diagram 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 a different 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 exactly the 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 and object diagrams form the design view of the system. • Process View: The dynamic behavior of a system can be seen using the process view. 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 the deployment 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 or transactions. Features in UML Tools This takes us to an important question—what 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 drawing UML 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 code trying 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 define these 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, 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 UML tool 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 is called 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 you forward 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, and essentially reconstructs the entire application structure along with all the relationships between the classes. Reverse engineering is a feature normally provided 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 is as 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 during design. 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 certain design 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 necessarily provide 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 design elements 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. • 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 the building 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 of direct 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 their designs 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 modeling environment 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): With the increasing use of iterative methodologies for building software systems, it becomes very difficult to keep the design of the system in sync with the developed 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 may represent 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 enterprise applications, 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 MVC layers. 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 different requirements. Rational Rose provides support for all the standard features that we discussed in the previous section such as UML diagram support, forward and 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 collaborative modeling 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. This enables you to share and distribute your application design where the Rational Rose tool is not installed. • Together Control Center: Together Control Center (formerly from Togethersoft) 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 source project. 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 different requirements. 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 Poseidon for UML Community Edition 1.5 free for individual software developers.

Representations Types of Things Name Symbol Description Variations/ other related elements Description of a set of objects that share the same: attributes, operations, - actors Class relationships and semantics. - signals - utilities Interface A collection of operations that specify a service of a class or component. Collaboration An interaction and a society or roles and other elements that work together to provide some cooperative behavior that is bigger than the sum of all the elements. Represent implementation of patterns that make up the system. Actor The outside entity that communicates with a system, typically a person playing a role or an external device Use Case A description of set of sequence of actions that a system perform that produces an observable result of value to a particular actor. Used to structure behavioral things in the model. Active class A class whose objects own a process or execution thread and therefore can initiate 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 of interfaces.

Node A physical resource that exists in run time and represents a computational resource. Interaction Set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. State machine A behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events. Packages General purpose mechanism of organizing elements into groups. Note A symbol for rendering notes and constraints attached to an element or a collection of elements. Relations

The types of UML relationships are shown in the table 2, relationships are used to connect things into well defined models (UML diagrams). 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 requirements of 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 the complete 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 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 (and just 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 show implementation 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 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, and the 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 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 shows the 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) by putting each class instance inside a box.

State-chart diagram The state-chart diagram models the different states that a class can be in and how that class 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 be modeled. 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 with rounded 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 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-level business 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 is because activity diagrams are "less technical" in appearance, compared to sequence diagrams, and business-minded people tend to understand them more quickly.

Component diagram A component diagram provides a physical view of the system. Its purpose is to show the dependencies 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: The phrase component package level is a programming language-neutral way of referring to class container levels such as .Net’s namespaces (e.g., System.Web.UI) or Java's packages (e.g., java.util).]

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 the diagram 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

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 embedded development 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

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.

Case Study Uml

by ganesh12july on Feb 19, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 3

Statistics

Case Study Uml — Document Transcript