Case Study Uml

Please download to get full document.

View again

of 19
9 views
PDF
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Document Description
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,
Document Share
Documents Related
Document Tags
Document Transcript
  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 anddesign. By an analysis the system is first described by a set of requirements, andthen 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 andcontinues with detailed specification of these parts and their interaction. For theearly phases of software projects UML provide support for identifying andspecifying 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 chartdiagrams 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 andcomplex languages, you still need to model. Modeling can be as straightforward asdrawing a flowchart listing the steps carried out by an application. Defining a modelmakes 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 firststep in either building or enhancing a system. This involves knowing what a system ismade up of, how it behaves, and so forth. Modeling a system ensures that it becomesreadable 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 beenmodeled to make it easy to understand, we tend to identify similarities or redundancy, bethey in terms of functionality, features, or structure.Even though there are many techniques and tools for modeling, in this article series, wewill be concerning ourselves with modeling object-oriented systems and applicationsusing 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 tomodel systems and make them readable. This essentially means that UML provides theability 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 theobject-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 tokeep UML as a clear and concise modeling language without being tied down to anytechnologies. UML Diagrams The underlying premise of UML is that no one diagram can capture the differentelements of a system in its entirety. Hence, UML is made up of nine diagrams that can beused 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 elementsand 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 anddefine a detailed design of the system. The class diagram classifies the actorsdefined in the use case diagram into a set of interrelated classes. The relationshipor 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 thatuniquely 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 stateof a class at a given point of time while the system is running. The object diagramcaptures 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 differentstates that objects in the system undergo during their life cycle. Objects in thesystem 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 inresponse 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  it is time-ordered. This means that the exact sequence of the interactions betweenthe objects is represented step by step. Different objects in the sequence diagraminteract with each other by passing messages . ã Collaboration diagram: A collaboration diagram groups together theinteractions between different objects. The interactions are listed as numberedinteractions that help to trace the sequence of the interactions. The collaborationdiagram helps to identify all the possible interactions that each object has withother objects. ã Component diagram: The component diagram represents the high-level partsthat make up the system. This diagram depicts, at a high level, what componentsform part of the system and how they are interrelated. A component diagramdepicts the components culled after the system has undergone the development or construction phase. ã Deployment diagram: The deployment diagram captures the configuration of theruntime elements of the application. This diagram is by far most useful when asystem 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, anadditional characteristic that a software system possesses is related to implementation.Before we categorize UML diagrams into each of these three characteristics, let us take aquick 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 entirelynew 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 ã 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 asystem, 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 essentiallyhow a system can be viewed from a software life cycle perspective. Each of these viewsrepresents 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, sequencediagram, and collaboration diagram are used in this view. ã Component View: Next, you have the component view that shows the groupedmodules 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 UMLare 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 andforemost, 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 begreat if the class diagrams that you draw in the tool can somehow be used to generate thesource 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 codefiles 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 stepin 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 thatmake 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,
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks