0% found this document useful (0 votes)
49 views

Oose Uml Notes

Ty baba ca Note

Uploaded by

sawant
Copyright
© © All Rights Reserved
Available Formats
Download as PDF or read online on Scribd
0% found this document useful (0 votes)
49 views

Oose Uml Notes

Ty baba ca Note

Uploaded by

sawant
Copyright
© © All Rights Reserved
Available Formats
Download as PDF or read online on Scribd
You are on page 1/ 16
Introduction to UML | P La Learning Objectives ... {) To know about Unified Modeling Language (UML) jg) To study reasons for learning UML. ff Tolearn about three building blocks of UML. {@) To get information on different types of UML diagrams. @ To know different Things and Relationships in UML. § To study UML rules and UML Architecture. @ To get knowledge of UML Advantages and disadvantages. SS eee wm CONCEPT OF UML [[S-18, W-18, S-19}} * UML stands for Unified Modeling Language. UML is a standard graphical language for modeling object-oriented software. * UML can be described as a general-purpose visual modeling language which is used to Visualize, specify, construct, and document software systems. * UML is not a programming language, but tools can be used to generate code in various languages using UML diagrams. UML was created by Object Management Group (OMG) and UML 1,0 specification draft Was proposed to the OMG in January 1997. It was developed in the mid-1990s as a collaborative effort by James Rumbaugh, Grady Booch and Ivar Jacobson, Definition: Tt can be defined as “UML is a language for visualizing, specifying, constructing and documenting artifacts of a software intensive system”. _ Inthis definition, © Visualizing means UML has the standard diagramming notations for drawing or Presenting pictures of software systems. © Specifying means building models that are exact, unambiguous and complete. © Constructing is related to actually implementation of design into coding. © Documentation plays a vital role in any type af system development, which helps during developing a system and after its deployment. UML addresses document- tation of system architecture and other details. (3.1) 32 ng — Sa a ase 1984 (cA) - Sem. VI UML . Goals of ML: visual modeling lan 2se188 ‘Mowing are main goals oe to-use, nee eHaRe role ith a ready- dels. ; : with a ready torn : : 2 Poe snd exchange meaningful jon mechanisms to extend the cents adiag cerelp sd epectaliza nguages and developmen, Sy conne Provide extensibility an Jar programming a! it eo f particula’ * Be independent o: i Proc! We ar: for understanding the modeling language, fy Be iec 10m i arket. Provide a formal nea opject Orientation tools m of Encourage the grow?! ‘UML < s_ collaborati, Be, 4) development concepts such a ations, = igher-level det Support higher- patterns and components. * Integrate best practices. iL EASOI R THE USE OF UM! - a monet oF UML Some of them are listed beiog cig ° There are various reasons for the use ; Software construction needs a plan: Software development iS ety, ee en ‘cular structure is in place, it is ofte, go complex and critical. Once a particular : 1a ae and difficult job to change. UML helps in constructing a model, 2. Appropriate for both new and legacy systems: UML is appropriate for bo, System developments and improvements to existing systems, Only the Path, are modeled will be affected by the change. 3. Inherent traceabili ? The Use Case Driven nature of modeling wit is U Mere that all levels of model trace back to elements of the original funcructur: Tequirements, dimensions and levels Of-d 2. PI it letail: U; aa visualized in multiple dimensions, 5 that a com ute ML allows softwar 3. Be i pee before Sonstruction/development b Puter system can be comple rn icremental dey, PMent and sy Te incremental development environment Prment UML models respond wellé fu 7. Unified: 0 . The b i in| diagre cto (actual) ae) an independent organizatst Bee, dard modeling language in the so! activi 8 Documents jaan assets: To vie dependence on ke; ets: 2m doetmentation ce wi es * diagra unders; 0 ‘Moves the company 9 rst ofthe Company’, Critical busin ge” at any time and inf 1. 5 : isa unive: SS proces ; Software development, Lage because met i, } ad ae in many: em, t f 1 |_ficiess” || Object | [Component] | [Depioyment]| [Activity | [State chart ngth |siagrams]|diagrams]| diagrams: diagrams | | diagrams 1 ne the ure oni . cat the as 2 28 J is | (O0SE (BBA (CA) - Sem. VI 33 Introduction to UML. DIAGRAMS IN UML gram is the graphical presentation of a se ; s t of elements, most oft connected graph of vertices (things) and arcs/paths (relatlonshipe), bee We draw diagrams to visualize a syste: i i ee ren ous 'ystem from different perspectives so a diagram is a UML diagrams are broadly categorized i fee aecems ly categorized as Structural and Behavioral diagrams as UML Diagrams Structural diagrams Behavioral diagrams ae Physical | [Use case] [State machina] [Interaction diagrams] | diagrams| | _ diagrams diagrams diagrams Package | [6 5 diagrams | [oon ereten'| | Sequence | |Interaction) |_ Timing mmunication| | giagrams || overview || diagrams Fig. 3.4: Types of UML Diagrams Structural Diagrams: This is a type of diagram that describes the elements of a specification those are irrespective of time. These diagrams show the things in a system being modeled. The structural diagrams are further classified as: 4. Logical diagrams represent the logical structure of the system 2. Physical diagrams represent the physical structure of the system. 3, Behavioral Diagrams: This is a type of diagram that describes behavioral features of a system or business process. These diagrams show what should happen in a system. They describe how the objects interact with each other to create 2 functioning system. The behavioral diagrams can bé classified as U: diagrams and Interaction diagrams. Interaction collaboration diagrams, whereas state machine diagrams include st: activity diagrams. To view a system in different perspective, diagrams as follows: ; 1. Class Diagram: It shows a set of classes, interfaces and collaborations and oa relationships, Graphically, a class diagram is a collection of vertices and arcs. class diagram addresses the static design view of asystem. ise Case diagrams, State Machine diagrams include sequence and ate charts and UML included nine different types of S “ shows a set of objects and tae Tea ‘ose 188A (cA) - Sem. VI mn i esents static snapshots .-" 2, object Diagram: A repr S of at a point in tim things found in iagram represents or shows a view of asystem- di ra A use case i a 3. A Use Case Disgratl | nships. Use case diagrams address static * and actors and their 3 , An ol " ee system. ction Diagram: An interaction diagram uo interaction 4, Interactio! 5 5 ‘ with messages that are shar; objects and their relationships along Wi) Fe eda ae ied ynam ON cos ae Interaction diagram address ; ‘ er . 5. Collaboration Diagram: A collaboration diagram ba ee focuses on the structural organization of objects that send and receiver, 6. State Chart Diagram: It shows a state machine which includes States transitions and activities, It addresses a dynamic view ofasystem, 7. Activity Diagram: It is a special kind of state chart diagram which Showy from one activity to another within a system. Activity diagram ade dynamic view of a system. 8. Component Structure Diagram: These diagrams explore how objects coo, complete a task, document the internal structure of an object, o describe a design structure or strategy. ee! 9. Deployment Diagrams: Th i : These diagrams show igurati processin, ; : configuration of ig nodes and objects that exist on them, : ig 11. Component pi; iagram: ¢, 1 dependencies a: somes . za liagram : implementation view tans a component — — on Hagram address poate These diagrams combi; ed &N object's State as 13. arene Diay ‘AMS: These gi ject lifelines “trams sh ae Sequence and state diag’ and messages which modi! The vocabul; ‘ary and formed models, bur ooo! should crate th sey don't t oa menage em. That istherore at ae aa © cite me 3 Of th, . “Software d €Velopment nracecs. pject diagram addresses th, ay = Acc thei Ac und To 1 maj The A ag ee Thin toge = Thin mod Any In U Grou You should create and ofus. ‘00SEIBBA (CA) - Sem. VI 35 Introduction to UML « Aconceptual model in UML can be defined as "a model which is made of concepts and their relationships", + A conceptual model is the first step before drawing an UML diagram. It helps to understand the entities in the real world and how they interact with each other. « To model a software intensive system requires learning and understanding three major building blocks. These building blocks are the part of UML vocabulary. © The building blocks of UML vocabulary: 4. Things/Elements of UML. 2, Relationships. 3. Rules. » Things are the basic elements in a model; while relationship binds these things together, diagrams bind collection of things. EW THINGS IN UML / ELEMENTS OF UML ©) Things are the basic building blocks of the UML. We use them to write we models. * Any type of diagram has structure and it also specifies behavior. * In UML, there are four kinds of things ie. Structural things, Behavioral things, Grouping things and Annotational things as shown in Fig. 3.2. Overview of things Class | Active class eS 3 Structural things Interface © Component Usecate [Co |[_ Nowe Collaboration Q | State machine Fig. 3.2: Things in UML us see details of each type of thing. Structural Things ctural things represent a conceptual or physical element. These things UML models. Structural things are the static parts of the model. are nouns prac tii) Cotaboration, che OSE [BBA (ca) (0086 (88A (cA) - Sem-VI listed belo’ things ar tructural tl ; somes of objects that shares the same attributes of object , Class: = : v ‘A class is a description of a 5 fr antics. relationship and sem: interfaces. moreii ‘ * Aclass implements one or Jass is represented with a rectangle. The rectay, Fig. 33,acl ele, + Forexample, in tions. si d operatio class name, attributes and ope FAME — classname taste | attributes colour eat() +— operations aa (a) Repr Gina een atone cine Fig. 3.3: Representation v) Use Case: (i) Interface: ? i ? Use case r * An interface is a collection of operations that specifies a service of | component. observabl. * An interface therefore describes the externally visible behavior of that element, Perse ca ° Interface defines a set of operations which specify the Tesponsibility of a class, model. 4 ° Aninterface might Tepresent the complete behavior of a class or component org Graphical Part of that behavior, solid lines ° an plc defines a set of operation Specifications (that is, their sign), butny in Fig. 3.6. Sst of operation implementations i : 7 li Declaration of interface, as ee : An active | ith the wot fan interface Looks ike a class gcrefore with the keyword <> above the name is Fig. 3.9: Representation Of Artis the focus shown in Fig. 3.9. In an act (viii) Node: perform * Anode can be defined as a physical element that exists at run time. Graphic * Anode isa physical element that exists at run time and C7 withan represents @ computational resource, generally having san distingu atleast some memory and, often processing capability. A set of components may reside on a nod 5.3] e € al migrate from node to node, maeavalee a * Graphically, a node is shown asa ¢ b i i rete mt ch erlyitsname,asinFig.310,”“S¥éllyincluding Fi of Nodes _ a2 Behavioral Things tpt * Behavioral things are the dynary; fnodel, representing behavior over ear'> Of UML models, These are the verbs( PACkags re e OVer ti phavioral things as given below,” “'™® @Rd Space, tn UML, there are three kind Package behavio * Interaction is defined as a b, He pci ehavi ; packe aan Clements to accompli ape sits °F @ group of messages excl! °PP0sed ion involye ‘ask, connectors, ape tierce ; sonst sac Graphically, a messave ; ” Including messages, actio™’ groupin line, almost always “<,°° “Played ag . Graphic x Ways: including 8 directeg ne operation, as in Fig. 3.14, the name of a a arava ally conte Fig. 3.11; Representation® = Messages OSE [BBA (CA) - Sem. V) 3.9 EE — (ii) State: {state machine is a behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events. Mop | the behavior of an individual class or a collaboration of classes may be specified with state machine. 8. ,_q state machine involves a number of other elements, including states, transition. ‘Astate is a condition or situation during the life of an object during which it satisfies some condition, performs Yigg some activity, or waits for some event. Fig. 3.12: Representation Graphically, a state is displayed as a rounded rectangle, of States ©Coq usually including its name shown in Fig. 3.12. ee, K (iii) Activity: * It is a behavior that specifies the sequences of steps a computational process performs. e Inan interaction, the focus is on the set of objects that interact. In a state machine, the focus is on the life cycle of one object at a time. cts * Inan activity, the focus is on the flows among steps without regard to which object performs each step. A step of an activity is called an action. Graphically, an action is displayed as a rounded rectangle with a name indicating its purpose. States and actions are distinguished by their different contexts. Fig. 3.13: Representation of Action | EE Grouping Things ® Grouping things are the organizational parts of UML models. These are the boxes into which a model can be decomposed. | * Grouping things can be defined as a mechanism to group elements of an UML model together. a (i) Package: of © Package is the only one grouping thing available for gathering structural and behavioral things. $ e A package is a general purpose mechanism for organizing the design itself, as ; ‘pposed to classes which organize implementation constructs. © Structural things, behavioral things and even other ___ Grouping things may be placed in a package. ‘Gephicaly, a package is displayed as a tabbed folder, : 'Y including only its name and someti: i cor tents, as shown in a 3.14. @ fometine [ y_s4 ee : of Packages 3.10 ty 1A (CA) - Sem. VJ_ [re ‘ ings EQ] annotational Thing: UML models, ‘Seo arts of i re the explanatory P: © Annotational things a) amechanism to capture Tematis + Annotational things can be defined ss and comments of UML model element . aie © Note is the only one Annotational thing available. dey ( Note: } A notes used to show comments, constraints etc. of an UML element, * A note is simply a symbol for displaying constraints and comments atta, Ass element or a collection of elements. Asso * Graphically, a Note is displayed as a rectangle with a dog eared comer toge, a as ae textual or graphical comments, as shown in Fig. 3.15. pee Retum copy to self Gray link Fig. 3.15: Representation of Note RELATIONSHIPS IN UML * Relationship is another most important building block of UML. * 4 relationship is a connection between things. When we model a system supposed to not only identify the things that form the vocabulary of the syst we should model how these things are related to one another. * Relationship shows how elements are associated with each other and this as/P€S° (linked) describes the functionality of an application. ie : A , bs Ay There are four kinds of relationships in the UML, ie Dependency, Ass? wre ‘ orb 1. Dependency: ‘ For | * Dependency is a semantic re} Fi ina things in which change in one cloner oePendency #8 a relationship bem a - 5 lepe * Dependency states that a ch acts the other one, ine cation of one thing (independ® ing may affect another thin, ae BCen i. ae ia thing) that uses it, but not the reverse. To st a3 ans arrow, (See Fig. 3.16) P is represented with a dashed line ™ ne __ Dependency com Fig. 3.16, a itis For example, in the Fig. 317, the — wtih of Dependency ia ~ dependency relationship is sho P class is depending on the Channel the c . WN usi, FilmClip class and ending in the Chane oa easie or dotted line starti" 7 EI ret dots on th a (QOSE [BBA (CA) - Sem. V] an Introduction to UML rks, deg, FllmClip Cy = dependency ‘ BlevOn(e: Channa fs start bs een Channel reset() Fig. 3.17: Example of Dependency S attachey tg, 2 Association: i + Association is a structural relationship in which objects are dually dependent. er *Pkthen, * Association relationship is used when we want to show structural relationship, Association is basically a set of links that connects elements of an UML model. It also describes how many objects are taking part in that relationship. * Graphically, association is represented as a solid line. For example, Fig. 3.18 shows | linking of objects Airplane and Passengers. Passengers system, we: the system, ae Association Fig. 3.18: Example of Association his associat Types of Association: * There are two types of Association: 1 assccns & Meion | * Itrefers to the formation of a particular class as a result of one class being aggregated | orbuilt as a collection. For example, the class “Library” is made up of one or lore books, among other materials, regation, the contained classes are not strongly lent on the life cycle of the container. mple of Fig. 3.19. Books will remain so even Library is dissolved. aggregation graphically in a diagram, draw a m the parent class to the child class with a d shape near the parent class. Library ‘Aggregation es Books Fig. 3.19: Example of ‘Aggregation ition: pea ilar to the aggregation relationship, with the only difference nS i : f emphasizing the dependence of the contained class to the life cy class. Fig. 3.22. Exam 3 , For't 4. Realization: : Ple of Generalization " se ——___ 005E 1684 (cA)- Sem. V1 er” will be destroyed when the d. For example, House "doesn't exist separate * Thatis, the contained class container class is destroye (parent) and Room (child). Room cael et from the House. _ tionship in an UML Le * To describe a composition relati fecting the two as diagram, use «directional ine gonnesang oy =a = ith a filled diamo pies : ; - ieee the container class and the directional conga an cros arrow to the contained class. elatio ie 3. Generalization: thine’ are - thing i.e. super * A generalization is a relationship between a genera. 7 eae fa orp, imp class and a specific thing i.e. subclass or child class. It is ‘0 the COttgher 1 inheritance in Ps. _ Be Mul ° Generalization can be defined as "a relationship which connects a Specializedda tt is with a generalized element." ; acl * _Itbasically describes inheritance relationships in the world of objects. call * Tt is also known as an “is a” relationship since the child class is a type of thepy For aka whi mat * Generalization is the ideal type of relationship that is used to showcase rey a mez elements in the class diagram. Literally, the child classes “inherit” the com functionality defined'in the parent class, Graphically, generalization relationship is shown as a solid line with a mE arrowhead pointing towards the parent as shown in Fig. 3.21, Be Generalization > a Fig, 3.21: Representation of Generalization ay Fig. 3.22 shows an example of 8eneralization, Aa Generalization It is a semantic relationship detwe go. ¢ er contract that another Classifier n a Wherein one classifier spec o 1 a ‘Carry out, o 2 ae) ° Seti ee ee ee Introduction to UML ‘cose 185a(CA) Sem. VI 33 Realization can be defined as ‘a relationship in which ~ Co, : ents are connected” my two elem Printer RI Fe ternent describes some responsibility which is not "implemented and the other one implements them. This zy relationship exists in the case of interfaces. Realization + Graphically, a realization relationship is displayed as a =™Ple op cross between a generalization and a dependency [oo 2 soap “Itionsh, relationship, as in Fig. 3.23 ®}. For example, in the Fig. 324, printing preferences that fig. a.24 Example of ; : are set using the Printer setup interface are being Realization ‘SS op implemented by the Printer. e “ONeep¢ | other Important Terms used in UML: icity: a 2 zedeqamm 2 Multiplicity: Passengers * tis the active logical association when the cardinality of -— I a class in relation to another is being depicted. It is also *\ called Cardinality. Multipicty For example, one fleet may include multiple airplanes, while one commercial airplane may contain zero to many passengers. The notation 0..* in the diagram means “zero to many”, (See Fig. 3.25). Fig. 3.25: Example of Multiplicity Airplane a RULES OF UML fe any language, the UML has a number of rules that specify what a well-formed model should look like. A well-formed model is one that is semantically self-consistent and in harmony with allits related models. The UML has syntactic and semantic rules for: 1 Names: Whatcan you call things, relationships and diagrams? 2, Scope The context that gives specific meaning toa name. 3. Visibility : How can those names be seen and used by others? How things properly and consistently related to one another? What does it mean to run or simulate a dynamic model? ig the development of a software-intensive system tend to evolve by many stakeholders in different ways and at different times. common for the development team to not only build models that it also to build models that are: Certain elements are hidden to simplify the view. Certain elements may be missing. The integrity of the model is not guaranteed. oo: sen V_ HITECTURE users like develope; E [BBA (CA) - 5 UML ARCHITE 4 by aifferent ing a system th, = used PY 5 pefore desiem the ee x % mo! vee i in min’ various people, analysts an Y Fes in il Feet Oo made with different persP js to visualize the ake ee pa This vie een ea understand the DENe™ t perspective: a * UML plays an importan mentation, epl ec : ay/oesign. IPP ome 4, The im perspectives are Logic Case View. assemb config indepe syster compo captur intera: 5. The D hardw the di: systen diagre $9 | ADV: Various ai PHYSICAL CONCEPTUAL Implementation View Logical View Class, Object, Package, Composite Structure, State Machine Component Use Case View Use case, Activity Process View Deployment View Sequence, Communication, Activity, Timing, Interaction Overview Deployment . # g ¢ ° e 8 S 5 = 3 = 2. It is, 3. Itise 5. Itisb system, a the vorabulary gfe ees the classes, interfi# ¢ aie fact Tequiremenge or” and its solution onal should contr , ide to its eng 7. Mosti ‘softw state diagrams and activity diagrams, 5. The Deployment View of a system includes the nodes that form the system's hardware topology on which the s system. With the UML, the static aspects of this view are captured in interaction diagrams, state dia; grams and activity diagrams. : Bl ADVANTAGES OF UML Various advantages of UML are listed belo 1. Itis a formal language: Each element has model a system, we can model with co; understood by everyone. “ 2, It is concise: The entire language is made u, ribe the behat notation. 3. Itis comprehensive: It describes all important aspects ofa system. Itis scalable: Wherever needed, the lan system modeling projects, verload. ment a strongly defined meaning. When we nfidence that the designed model is ip of simple and straightforward iguage is formal enough to handle massive but it also scales low to small Projects, avoiding is built on lessons learned: UML is the result of best mmunities over the past few years. is standard: UML is controlled by an open standard group with active tributions from a world-wide 8roup of vendors and academics. tly used: It is the most useful method of visualization and documenting ftware system design. is independent: It uses object-oriented design concepts and it is independent of ‘ming language. practices in object-oriented OSE [BBA (CA) - Sem. V) ~ DISADVANTAGES OF UML - e listed belo Disadvantages of UML ar a) : UML has still no s 4. Lack of formality: UI Seats ructure and specification for Mode, format. interfaces. UML does not define a stan’ ; hs d when using UML is the time it takes te 2. Time: Some developers might fin and maintain UML diagrams. To wo) synchronized with the software code, which requires time to set up and m and adds work to a software development project. Diagrams can get overcomplicated: When creating an UML dia conjunction with software development, the diagram might becg a t rk properly, UML diagrams complicated, which can be confusing and frustrating for developers, . Too much importance on design: UML places much im; can be problematic for some developers and companies. . Synchronizing code with models is difficult: makes it difficult to keep them consistent with be added by hand, ects int Show Using multiple models/qj; 3.16 SET 00s ag each other and much Code Tit in portance on design, EE ie 2 Pes behavioral features! What sh i with ‘ould happe €ach other to cre’ Peas e

You might also like