Your SlideShare is downloading. ×
0
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Lecture-03 Introduction to UML
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Lecture-03 Introduction to UML

3,310

Published on

Introduction to UML

Introduction to UML

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,310
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
233
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Object Oriented Software Modeling and Design CE 350 Abdel-Karim Al-Tamimi, Ph.D. [email_address] http://faculty.yu.edu.jo/altamimi Al-Tamimi 2011 ©
  • 2. Overview
    • Introduction UML
    Al-Tamimi 2011 ©
  • 3. UML Definition and Usage
    • UML stands for : Unified Modeling Language
    • UML helps in facilitating:
      • Specification
      • Visualization
      • Architecture Design
      • Construction
      • Simulation and Testing
      • Documentation
    Al-Tamimi 2011 ©
  • 4. UML Basics
    • A model helps getting an abstract idea of the objects the software product consists of and their interactions
      • Employ information hiding in the model
    • Model’s point of view is important to determine the final shape of the diagram and the necessary information to be included
      • Use-case diagram vs. Class diagram
    Al-Tamimi 2011 ©
  • 5. Using Models/Diagrams
    • It is easier to change models than code
    • Allow non-technical team members/ clients to understand the structure of the system and be active in decision making
    • Client can check if the system’s design is confined to the agreed-on requirements
    Al-Tamimi 2011 ©
  • 6. Types of Diagrams
    • There are several types of diagrams :
      • Use-Case Diagrams
      • Activity Diagrams
      • Class Diagrams
      • Interaction Diagrams
      • State Diagrams
    Al-Tamimi 2011 ©
  • 7. Types of Diagrams Al-Tamimi 2011 ©
  • 8. UML: Fundamental Level
    • The first level examines fundamental UML knowledge, including basic notions on class diagrams, activity diagrams, interaction diagrams, and use case diagrams, as well as various elements such as standard stereotypes and primitive types
    • These basics include not only the elements visible to UML users, but also abstract UML concepts, such as Element—the base class for all UML classes in the metamodel
    Al-Tamimi 2011 ©
  • 9. Use Case Diagram: Introduction
    • It lists the capabilities of the system (including their users)
    • Documents the macro requirements of the system
    Al-Tamimi 2011 © Borrow Book Student
  • 10. Activity Diagram
    • In UML an activity diagram is a version of flowchart
    • Activity diagrams are used to analyze processes , or even process re-engineering
    • Very helpful in understanding the overall process without indulging in technical issues
    • Explains the steps (actions) the user takes to achieve a certain milestone/milestones
    • There are a Start point and an End point
    Al-Tamimi 2011 ©
  • 11. Activity Diagram: Example Al-Tamimi 2011 © Leave House Take Class Wander Around Return to House Take another Class Done for today ? Arrive to university End of day
  • 12. Class Diagram
    • Show the classes in the system and the relationships between these classes
    • There are many possible class diagrams, and a single class can be shown in more than one class diagram
    • Show the classes and their relationships in the best way to understand the system
    • Does not explain the classes interactions, just a static view of the system
    Al-Tamimi 2011 ©
  • 13. Class Diagrams: Example Al-Tamimi 2011 © Student Book Reference Magazine
  • 14. Interaction Diagrams
    • Interaction diagram are categorized into:
      • Sequence diagrams
        • Models a single flow, the classes are on top
      • Collaboration diagrams
        • Messages and classes are organized in the spatial space, no single flow
    • These diagram represent the same information using different perspectives
    • Shows objects and messages between them
    Al-Tamimi 2011 ©
  • 15. Interaction Diagrams – Sequence Diagram Al-Tamimi 2011 © Student Book Library Walk to school Access Library Browse Book Borrow book Read book
  • 16. Interaction Diagrams – Collaboration Diagram Al-Tamimi 2011 © Book Student Library 1-Walk to school 5-Read book 3-Browse book 4-Borrow book 2-Access library
  • 17. State Diagram
    • Shows the changing state of a single object as it passes through the system
    Al-Tamimi 2011 © Walking Leave the house Studying Arrive to School / take class Done Resting Have a break Yes
  • 18. UML Notations Al-Tamimi 2011 ©
  • 19. UML Notation of Objects and Classes Al-Tamimi 2011 © Class Object - indicates private attributes/methods + indicates public attributes/methods # indicates protected attributes/methods ~ indicates package visible attributes/methods Notice the naming convention BankAccount BankAccount - name - balance + debit (int amount): void + credit (int amount): void Object1 : BankAccount name = John Smith balance = 1,000 Object2 : BankAccount name = Robert Jones balance = -200
  • 20. Visibility / Access Modifiers Review
    • Public : visible to all elements that can access the contents of the namespace that owns it
    • Private : only visible inside the namespace that owns it
    • Protected : visible to elements that have a generalization relationship to the namespace that owns it
    • Package : Any element marked as having package visibility is visible to all elements within the nearest enclosing package
    Al-Tamimi 2011 ©
  • 21. UML Class Example Al-Tamimi 2011 © Student
    • StudentName:String
    • StudentID:Integer
    • DOB:DateTime
    • GPA:Double=0.0
    • + getGPA():Double
    • + setName(Name:String)
    • CalculateGPA():Double
  • 22. Relationships between Classes
    • There are essentially four important types of relationships between classes:
      • Generalization/specialization
        • Inheritance
      • Aggregation (“part-of”)
      • Association
        • Role and the connection between the classes
      • Realization
        • one model element (the client) realizes the behavior that the other model element (the supplier) specifies
    Al-Tamimi 2011 ©
  • 23. Generalization / Specialization Relationship Al-Tamimi 2011 © BankAccount attributes and methods are not specified again New attribute “interest” is shown in the subclass Generalization Specialization
  • 24. Generalization / Specialization Relationship
    • An abstract class is used to specify the required behaviors (operations) of a class, without having to provide their actual implementations
    • An operation without the implementation (body) is called an abstract operation
    • A class with one or more abstract operations is an abstract class
    • An abstract class cannot be instantiated because it does not have the required implementation of the abstract operations
    Al-Tamimi 2011 ©
  • 25. Association Relationship
    • Object-oriented systems are made up of objects of many classes. Associations represent relationships among classes
    • An association is represented by a line drawn between the associated classes involved with an optional role name attached to either end
    • The role name is used to specify the role of an associated class in the association
    • If an association connects two objects instead of classes, it is called a link
    • A link is an instance of an association.
    Al-Tamimi 2011 ©
  • 26. Association Relationship Al-Tamimi 2011 © Name of Link Multiplicity Role Name of Association
  • 27. Multiplicity Al-Tamimi 2011 © UML Multiplicity Meaning 1 Exactly 1 (default) 2 Exactly 2 1..3 From 1 to 3 inclusive 3, 5 Either 3 or 5 1..* At least [1], and at most [unlimited] * Unlimited (including 0) 0..1 Either 0 or 1
  • 28. Multiplicity: Example Al-Tamimi 2011 © Student Book borrows 0..1 0..5 Professor borrows * 0..1
  • 29. Qualification Relationship
    • Qualification serves as names or keys that are part of the association and are used to select/qualify objects across the association at the other end
    • In UML, a qualifier is used to model this association semantic, that is an association attribute whose value determines a unique object or a subset of objects at the other end of an association
    • The qualifier goes at the opposite end of the association from the class of which it’s an attribute
    Al-Tamimi 2011 ©
  • 30. Qualification Relationship Al-Tamimi 2011 © Account Number  a single person Account number acted as a filter
  • 31. Qualification Relationship: Example Al-Tamimi 2011 © Driver vehicle drives But if he can only drive 4 wheels vehicles: Driver vehicle drives 4 wheels What if he can only drive his own car: Driver vehicle drives License plate
  • 32. Reflexive Associations
    • Relates one object of a class to another object of the same class
    • In other words, a class can be associated with itself
    • Reflexive associations are two types
      • directional
      • and bi-directional
    Al-Tamimi 2011 ©
  • 33. Reflexive Association: Example Al-Tamimi 2011 ©
  • 34. Reflexive Association: Example Al-Tamimi 2011 © Directional Bi-directional
  • 35. Association Classes Al-Tamimi 2011 © Sometimes, it is necessary to describe an association by including some attributes which do not naturally belong to the objects involved in the association Enrollment is an association class
  • 36. Association Classes: Example Al-Tamimi 2011 © Can a person have multiple positions at the same company ?
  • 37. N-ary Association Al-Tamimi 2011 ©
  • 38. N-ary Association Al-Tamimi 2011 © 3 or a Ternary association
  • 39. N-ary Association Al-Tamimi 2011 © decomposed
  • 40. Aggregation Relationship
    • Aggregation is a stronger form of association
    • It represents the has-a or part-of relationship
    • In UML, a link is placed between the “whole” and the “parts” classes with a diamond head attached to the “whole” class to indicate that this association is an aggregation
    • Multiplicity can be specified at the end of the association for each of the “part-of” classes to indicate the quantity of the constituent parts
    • Typically, aggregations are not named, and the keywords used to identify aggregations are “ consists of ”, “ contains ” or “ is part of ”
    Al-Tamimi 2011 ©
  • 41. Aggregation : Example Al-Tamimi 2011 ©
  • 42. Aggregation: Example Al-Tamimi 2011 © Company warehouse Salesman Store 0..* 1..* 0..* 0..* 1..* 0..*
  • 43. Composition Relationship
    • A stronger form of aggregation is called composition , which implies exclusive ownership of the “part-of” classes by the “whole” class, i.e. a composite object has exclusive ownership of the parts objects
    • This means that parts may be created after a composite is created, but such parts will be explicitly removed before the destruction of the composite
    • It is represented using a filled diamond head
    Al-Tamimi 2011 ©
  • 44. Composition: Example Al-Tamimi 2011 ©
  • 45. Composition: Example Al-Tamimi 2011 © Report Title Column Figure 1 1 1 1..* 1..* 0..*
  • 46. General Notes
    • Generalization indicates " is-a ” relationship
    • Composition indicates “ part-of ” relationship
    • Aggregation indicates “ has-a ” relationship
    Al-Tamimi 2011 © Car Engine Person Address Book Reference
  • 47. Difference Between Aggregation and Composition Relationships
    • When attempting to represent real-world whole-part relationships, e.g., an engine is part of a car, the composition relationship is most appropriate
      • A department belongs to only one university
    • When representing a software or database relationship, e.g., ConvertToPDF component is a part of a software library Printing, an aggregation relationship is best
    • Aggregation - Without whole part can exist. Composition - Without whole part can't exit.
    Al-Tamimi 2011 ©
  • 48. Dependency Relationship
    • Dependency is a weaker form of relationship which indicates that one class depends on another because it uses it at some point of time
    • Dependency exists if a class is a parameter variable or local variable of a method of another class
      • The class uses the other’s class object(s) in its runtime
      • In use-case diagrams is used to indicate that a change to the supplier might require a change to the client
    Al-Tamimi 2011 ©
  • 49. Dependency Relationship: Example Al-Tamimi 2011 © Server DatabaseConnectionManager <<use>>
  • 50. Dependency Relationships in UML (1 of 2) Al-Tamimi 2011 © Type of Dependency Keyword Description Abstraction «abstraction», «derive», «refine», or «trace» Relates two model elements, or sets of model elements, that represent the same concept at different levels of abstraction, or from different viewpoints Binding «bind» Connects template arguments to template parameters to create model elements from templates
  • 51. Dependency Relationships in UML (2 of 2) Al-Tamimi 2011 © Type of Dependency Keyword Description Realization «realize» Indicates that the client model element is an implementation of the supplier model element, and the supplier model element is the specification Substitution «bind» Indicates that the client model element takes the place of the supplier; the client model element must conform to the contract or interface that the supplier model element establishes Usage «use», «call», «create», «instantiate», or «send» Indicates that one model element requires another model element for its full implementation or operation
  • 52. Realization Relationship
    • In this relationship, one element realizes the behavior that the other element specifies
    • Usually associated with class and component diagrams
    • Usually represents the relationship between an interface (abstract class) and a sub-class that implements the interface
    Al-Tamimi 2011 ©
  • 53. Realization Relationship: Example Al-Tamimi 2011 © Payable << interface >> Employee Invoice SalaryEmployee
  • 54. Constraints and Notes
    • Constraints are an extension of the semantics of a UML element, allowing one to add new rules or modify existing ones. Sometimes it is helpful to present an idea about restrictions on attributes and associations for which there is no specific notation
    • Constraints are represented by a label in curly brackets ( {constraintName} or {expression} ) that are attached to the constrained element
    Al-Tamimi 2011 ©
  • 55. Constraints and Notes: Example Al-Tamimi 2011 ©
  • 56. Constraints and Notes: Example Al-Tamimi 2011 ©
  • 57. Resources
    • Matt Weisfeld, The Object Oriented Thought Process , Sams Publishing, ISBN:0-672-32611-6
    • M. Jesse, “UML 2.0 for dummies”, ISBN:0764526146
    • P. Kimmel, “UML Demystified”, McGraw Hill, ISBN: 0-07-148671-2
    • http://www.thefullwiki.org/Unified_Modeling_Language
    Al-Tamimi 2011 ©
  • 58. Resources
    • Object oriented technology, By Tsang, Lau & Leung 2005, Mcgraw-Hill
    • M. Chonoles and J. Schardt, UML 2 for dummies, ISBN:0764526146
    • http://publib.boulder.ibm.com/infocenter/rsmhelp/v7r0m0/index.jsp?topic=/com.ibm.xtools.modeler.doc/topics/cdepend.html
    Al-Tamimi 2011 ©

×