Published on

An Introduction on UML

1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Sequential:Only one call to an instance may be outstanding at once. Guarded: Multiple calls from concurrent threads may occur simultaneously to one instance, but only one is allowed to commence. The others are blocked until the performance of the first operation is complete. (Designers to ensure that deadlocks can’t occur)Concurrent: Multiple calls from concurrent threads may occur simultaneously to one instance on any concurrent operation. All of them may process concurrently with correct semantics. (Inside the method implementation synchronization problems are correctly addressed.)
  • Uml

    1. 1. UML <br />U M L(Unified Modeling Language)BYCh. Vishwa MohanProject ManagerVision Krest Embedded Systems<br />
    2. 2. Software Development Life Cycle (SDLC)<br />Requirement Definition <br />Requirement Analysis. <br />System Design <br />Prototyping <br />Construction<br />Integration <br />Testing <br />Implementation <br />Documentation <br />Maintenance. <br />
    3. 3. What is a Process? <br />
    4. 4. What are the Life Cycle Types ? <br />Structured Methods<br />Code and Fix (Traditional) <br />Waterfall<br />Spiral<br />Ward & Mellor (Real Time & Embedded Systems)<br />Object Oriented Methods<br />OOA/OOD By Coad & Yourdon<br />OOD By Booch<br />OMT By Rambaugh<br />OOSE by Jacobson <br />
    5. 5. Drawbacks of Traditional Methods ! <br />Adaptability to change is very poor. <br />Bugs. <br />Person Dependency <br />No way to communicate with team members. <br />No way to model the system <br />Limited user involvement. <br />Persons involved in the analysis will required to go for coding and further phases. <br />
    6. 6. Benefits of the Object Oriented Methodologies: <br />New requirements can be added at later stage and their integration will be very easy. <br />It’s possible to deal with more complex systems.<br />Easy way to make communication between software developers and experts. <br />Seen over the whole of their lifetime, OO models are more stable and thus easier to modify. <br />OO abstraction allows increases reusability of work outcomes. <br />Finally it’s more fun. <br />
    7. 7. Steps involved in the OO Software Development:<br />Identify the objects and their attributes. <br />Study operations associated with the objects. <br />Design classes from objects having similar characteristics. <br />Establish relationship between classes. <br />Implement the classes and relationships between them. <br />
    8. 8. UML<br />What is Model ? <br />Representation in a certain medium of some thing in the same or other medium. <br />A model represents the blueprint of the system. It is an abstract representation of a system. <br />What is In a Model ? <br />Semantics:<br />It captures the classes, associations, states, use cases and messages. <br />Visual Representation:<br />How to represent model elements. Different tool vendors shows different representation for the same model.<br />
    9. 9. What is UML ? <br />UML is a general purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software intensive system. <br />UML enables system builders to create blue prints that capture their vision in a standard easy-to understand way and communication them to others.<br />UML can be used with all processes, throughout the development life cycle, and across different implementation technologies.<br />UML captures the static and dynamic behavior of systems. <br />
    10. 10. What is a Visual Modeling ?<br />Basically, the modeling captures the essential parts of the system. <br />Computer system basically automate business processes. However, it’s not easy to build software systems on time and within budget.<br />Building a complex software system requires blueprint. You don’t construct a building without a blueprint. Visual modeling is the blueprint for software systems.<br />Finally we can say, Visual Modeling is the key to successful software development. <br />
    11. 11. What is a Visual Modeling?<br />
    12. 12. Benefits of Visual Modeling?<br />Visual Modeling captures business process<br />Use case analysis is a technique to capture business process from users perspective. <br />Visual Modeling is a communication tool.<br />Use visual modeling to capture business objects and logic. <br />Use visual modeling to analyze and design your application. <br />Visual Modeling manages complexity. <br />Visual Modeling defines software architecture. <br />With the help of Visual modeling language your model your system independent of implementation language. <br />Visual Modeling promotes reuse. <br />Here Visual Modeling can be used as component browser and it can also be used to model component assembly. <br />
    13. 13. UML Concepts are:<br />The UML may be used to:<br /><ul><li>Display the boundary of a system & its major functions using use cases and actors
    14. 14. Illustrate use case realizations with interaction diagrams
    15. 15. Represent a static structure of a system using class diagrams
    16. 16. Model the behavior of objects with state transition diagrams
    17. 17. Reveal the physical implementation architecture with component & deployment diagrams
    18. 18. Extend your functionality with stereotypes</li></li></ul><li>OO Software Development with UML<br />Inside the UML, you can not only describes data and functions; their interconnections and their relationships with the surrounding world (I.e., with other data and functional units) can be defined in a differential way. <br /><ul><li>This dependency relationship helps the programmers from development to coding phase. It helps the programmers higher degree of complexity. </li></li></ul><li>What are the Benefits of UML?<br />Reverse Engineering <br />Re-engineering <br />Forward Engineering<br />Documentation Development<br />Source Code Generation. <br />
    19. 19. Different Diagrams in UML <br />Use Case Diagram <br />Class Diagram <br />Sequence Diagram <br />Collaboration Diagram <br />State Transition Diagram<br />Activity Diagram <br />Component Diagram <br />Module Diagram <br />Deployment Diagram. <br />Presentation Diagram<br />
    20. 20.
    21. 21. UML Views<br />Static Views<br />Dynamic Views<br /><ul><li>Static View:
    22. 22. Static View is the foundation of UML. It captures the object Structure. It doesn’t contains details of dynamic behavior.
    23. 23. The key elements in the Static View are
    24. 24. Classifier
    25. 25. Relationships</li></li></ul><li>Classifiers: <br />A classifier is a modeling element, that defines the structure and behavior. Classifiers are: <br />Classes<br />Interfaces<br />Data types<br />Nodes <br />Actors <br />Signal <br />Behavioral things are classified by other classifiers use cases and signals. <br />A Classifier have identity, state, behavior & relationships. <br />Relationships among classifiers are: Association, Generalization, various kinds of dependency including Realization and Usage. <br />
    26. 26. Classes: <br />A Class defines a set of objects that have a state and behavior. <br />State is described by its attributes and associations. <br />A Class has unique name within its container. The class has a visibility with respect to its container. <br />If a class is a part of package then you can represent the class preceded with package name. <br /><ul><li>Eg: HouseHoldApp::WashingMachine</li></li></ul><li>Use Case Diagram<br />Use Case Diagrams are used to model the interaction of system with the external actors.<br />A use case is a description of a system’s behavior from a users standpoint. It consists of group of actors, a set of use cases.<br />Use case diagram is used to <br />Modeling the system from user point of view<br />It shows the boundaries between system and the outside world. <br />It is a powerful tool to gather functional requirements. <br />Used to identify external users. <br />An Actor is a stereotype of class.It is an object outside the scope of the system under discussion. <br />In UML three types of relationships between use cases are defined: <br />Include<br />Extend<br />Generalization (Uses)<br />Communication between Actors and Use cases can either be Unidirectionalor Bi-directional. <br />
    27. 27. Actor<br />Registrar<br />Faculty<br />Student<br />Billing System<br />An actor is someone or some thing that must interact with the system under development.<br />An Actor is a stereo type of class. <br />An actor is represented with a sticky man. <br />
    28. 28. Use Case<br />Maintain Schedule<br />Maintain Curriculum<br />Request Course Roster<br />A use case is a pattern of behavior the system exhibits<br /><ul><li>Each use case is a sequence of related transactions performed by an actor and the system in a dialogue.
    29. 29. Use case represented with oval. </li></ul>Actors are examined to determine their needs<br /><ul><li>Registrar -- maintain the curriculum
    30. 30. Professor -- request roster
    31. 31. Student -- maintain schedule
    32. 32. Billing System -- receive billing information from registration</li></li></ul><li>Use Case Diagram<br />Request Course Roster<br />Professor<br />Student<br />Maintain Schedule<br />Maintain Curriculum<br />Faculty <br />Registrar<br />Use case diagrams are created to visualize the relation ships between actors and use cases. <br />
    33. 33. <<uses>><br />Register for courses<br /><<uses>><br />Logon validation<br />Maintain curriculum<br />Uses and Extends Use Case Relationship<br />As the use cases are documented, other use case relationships may be discovered<br /><ul><li>A uses relationship shows behavior that is common to one or more use cases.
    34. 34. An extends relationship shows optional behavior </li></li></ul><li>Use Case Diagram :<br />
    35. 35. Use Case Realization<br />The use case diagram presents an outside view of the system<br /><ul><li>Interaction diagrams describe how use cases are realized as interactions among societies of objects</li></ul>Two types of interaction diagrams<br /><ul><li>Sequence diagrams
    36. 36. Collaboration diagrams</li></li></ul><li>Class Diagram: <br />Class diagram is the heart of OOAD. <br />A class diagram shows the existence of classes and their relationships in the logical view of a system. <br />The class diagram depicts the static structure of a system. UML modeling elements in this diagram are: <br />Classes and their structure and behavior (attributes & operations)<br />Their Relationships with other classes. <br />Multiplicity and Navigation indicator.<br />Role Names<br />Class: The common noun corresponding to every object identified in the problem domain is a class.<br />A class is a collection of objects with common structure, common behavior, common relationships and common semantics. <br />Classes are found by examining the objects in sequence and collaboration diagram<br />
    37. 37. Class Diagram<br />Classes can represent <br />Physical thing (Airplane) <br />Business thing (order, invoice)<br />Logical thing (broadcasting schedule)<br />Application thing (Button, Cerror)<br />Computer thing (hash table)<br />Behavior thing (A Task)<br />Types of Classes you can show<br /><ul><li>Concrete Class
    38. 38. Abstract Class
    39. 39. Template Class
    40. 40. Interface Class
    41. 41. Utility Class</li></li></ul><li>Classes<br />ScheduleAlgorithm<br />RegistrationManager<br />RegistrationForm<br />Professor<br />Course<br />Student<br />CourseOffering<br />Inside UML a class is represented with three compartments: <br />First compartment represented with class name.<br />Second is represented with attributes<br />Finally third compartment is used to represent the behaviors of a class. <br />
    42. 42. Attributes<br />CourseOffering<br />number<br />loation<br />time<br />The structure of a class is represented by its attributes.<br />Attributes may be found by examining class definitions, the problem requirements, and by applying domain knowledge. <br />Each course offering<br />has a number, location <br />and time<br />
    43. 43. Operations<br />registration <br />registration <br />form<br />manager<br />RegistrationManager<br />3: add course(joe, math 01)<br />addCourse(Student,Course)<br />The behavior of a class is represented by its operations. <br />Operations may be found by examining interaction diagrams. <br />
    44. 44. Relationships <br />Relationships provides pathway for communication between objects. <br />Sequence and/or collaboration diagrams are examined to determine what links between objects need to exist to accomplish the behavior. <br />If two objects need to “talk” there must be a link between them.<br />Three types of relationships are:<br />Association, Aggregation and Dependency.<br />
    45. 45. Interfaces: <br />Interfaces does not have attributes. So there is no state for interfaces. <br />Interfaces doesn’t have outgoing associations that are visible to it.<br />You can draw the following relationships with interfaces<br /><ul><li>Generalization
    46. 46. Realization
    47. 47. Association</li></ul>An Interface is represented by a Circle with small line attached to it. <br />Interface<br />
    48. 48. Association <br />An association establishes relationship between two classes. It is a bi-directional. <br />Data can flow both directions across association. <br />The frequency of association is called Multiplicity. <br />You can apply constraints on association (eg: ordered, or etc., ) <br />One way of association is called directed association, in which only one side knows the other, but not vice versa. <br />Different types of associations are: <br /><ul><li>Recursive Association
    49. 49. Attributed Association
    50. 50. Qualified Association
    51. 51. Derived Association
    52. 52. Directed Association </li></li></ul><li>Aggregation & Dependency <br />An aggregation is a stronger form of relationship where the relationship is between a whole and its parts. <br /><ul><li>An aggregation is shown as a line connecting the related classes with a diamond next to the class representing the whole. </li></ul>A dependency relationship is a weaker form of relationship showing a relationship between a client and a supplier where the client does not have semantic knowledge of the supplier.<br /><ul><li>A dependency is shown as a dashed line pointing from the client to the supplier.</li></li></ul><li>Finding Relationships <br />RegistrationMgr<br />RegistrationMgr<br />.NET : Course<br />3: add student(joe)<br />Course<br />Relationships are discovered by examining the interaction diagrams. <br /><ul><li>If two objects must talk there must be a path way for communication. </li></li></ul><li>Typical Class Diagram <br />
    53. 53. Multiplicity <br />Multiplicity defines how many objects participate in a relationship. <br /><ul><li>It defines the number of instances of one class related to ONE instance of the other class.
    54. 54. For each association and aggregation, there are two multiplicity decisions to make: one for each end of the relationship
    55. 55. A class also has multiplicity. </li></li></ul><li>Navigation <br />Although association and aggregation are bi-directional by default, it is often desirable to restrict navigation to one direction. <br /><ul><li>If navigation is restricted, an arrowhead is added to indicate the direction of the navigation. </li></li></ul><li>Concurrency <br />Inside class diagram, you can specify the attribute concurrency for each method. This concurrency states that it’s semantic of concurrent calls to the same passive instance. <br />Basically it addresses the synchronization problem in the case of multiple threads. <br />The different concurrency options are:<br /><ul><li>Sequential
    56. 56. Guarded
    57. 57. Concurrent </li></li></ul><li>Inheritance <br />Inheritance is a relationships between a superclass and its subclass. <br />There are two ways to find inheritance:<br /><ul><li>Generalization
    58. 58. Specialization. </li></ul>Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy. <br />
    59. 59. Inheritance Representation <br />
    60. 60. Links <br />Link: A Link is an instance of an association. It connects objects rather then classes. <br /><ul><li>Link name should be under lined. </li></ul>Mohan:Faculty<br />JayaMukhi:Batch<br />Teaches<br />
    61. 61. Stereotypes<br />Stereotype and Constraints are two constructs the UML provided for extending the language. <br /><ul><li>Stereotype is nothing but adding new features to the existing elements and make is as new element.
    62. 62. Stereotypes can be sued to extend the UML notational elements. </li></ul>Stereotypes may be used to classify and extend associations, inheritance relationships, classes, and components. <br />Examples of stereotypes: <br />Class Stereotypes: Actor, boundary, entity, utility, exception. <br />Inheritance Stereotypes: uses and extends. <br />Component Stereotypes: subsystem. <br />
    63. 63. Constraints<br />A Constraint is an expression which restricts the possible contents, states are the semantics of a model element which must always be satisfied. <br />Constraints are always enclosed in braces. <br />The below represents constraint on association. <br />Bank Teller <br />Customer<br />Servers {ordered} <br />Chooses<br />.NET Course<br /> Student<br />{Or}<br />Java Course<br />Chooses<br />
    64. 64. Sequence Diagram:<br />Objects are usually identified by studying the problem domain. The main tools to study the objects behavior are: <br /><ul><li>Sequence Diagram
    65. 65. State Transition Diagram
    66. 66. Activity Diagram
    67. 67. Collaboration Diagram</li></ul>Sequence diagram is a tool to model the dynamic behavior of the system. <br /><ul><li>It shows a graphical method to illustrate the sequence of events that occur one particular execution of the system.
    68. 68. The sequence diagram shows the interaction between objects in a time sequence.
    69. 69. The messages can be : Simple, Synchronous, Asynchronous and Reply messages. </li></li></ul><li>Representation of Messages<br />The below are the symbols of the message representations.<br />
    70. 70. Sequence Diagram<br />registration <br />registration <br />math 101<br />math 101 <br /> : Student<br />form<br />manager<br />section 1<br />1: fill in info<br />2: submit<br />3: add course(joe, math 01)<br />4: are you open?<br />5: are you open?<br />6: add (joe)<br />7: add (joe)<br />A Sequence diagram displays the object interaction arranged in a time sequence. <br />
    71. 71. Sequence Diagram<br />
    72. 72. State Transition Diagram <br />A state transition diagram shows: <br /><ul><li>The life history of a given class.
    73. 73. The events that cause a transition from one state to another.
    74. 74. The actions that result from a state change. </li></ul>State transition diagrams are created for objects with significant dynamic behavior.<br />
    75. 75. State Transition Diagram<br />
    76. 76. Collaboration Diagram<br />The Collaboration diagram shows a set of interactions between selected objects in a specific limited situation (context), focusing on the relations between the objects and their topography. <br /><ul><li>A Collaboration diagram displays the object interactions organized around objects and their links to one another.
    77. 77. The collaboration diagram shows the chronological sequence of the messages, their names, responses and their arguments. </li></ul>Like sequence diagram collaboration diagram also shows the object interaction. <br /><ul><li>The sequence diagram is organized according to time and collaboration diagram is organized according to space.
    78. 78. The sequence diagram and collaboration diagram are similar in fact semantically they are equivalent. You can turn a sequence diagram into equivalent collaboration diagram and vice versa. </li></li></ul><li>Collaboration Diagram<br />
    79. 79. Component Diagram<br />Component diagram illustrate the organizations and dependencies among software components. <br />A component may be: <br /><ul><li>A source Code Component
    80. 80. A run time Component
    81. 81. An executable component. </li></li></ul><li>Typical Component Diagram<br />
    82. 82. Deployment Diagram<br />Registration<br />Database<br />Main <br />Library<br />Building<br />Dorm<br />The deployment diagram shows the configuration or run-time processing elements and the software processes living on them. <br />The deployment diagram visualizes the distribution of components across the enterprise. <br />
    83. 83.
    84. 84.
    85. 85.
    86. 86.
    87. 87. Questions ?<br />