Chapter 1 Overview of UML for Java Programmers. 2 Outline Diagram Types Diagram Types Class Diagrams Class Diagrams Object Diagrams Object Diagrams Sequence.

Slides:



Advertisements
Similar presentations
Modeling Main issues: What do we want to build How do we write this down.
Advertisements

UML (Sequence Diagrams, Collaboration and State Chart Diagrams) Presentation By - SANDEEP REDDY CHEEDEPUDI (Student No: ) - VISHNU CHANDRADAS (Student.
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
Modeling Main issues: What do we want to build How do we write this down ©2008 John Wiley & Sons Ltd. vliet.
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 9 Slide 1 Appendix 3 Object-Oriented Analysis and Design.
Object-Oriented Analysis and Design
Design Patterns in Java Appendix D UML at a Glance Summary prepared by Kirk Scott 1.
Unified Modeling Language (UML)
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
SE-565 Software System Requirements More UML Diagrams.
Chapter 3 : Software Process and Other Models Juthawut Chantharamalee Curriculum of Computer Science Faculty of Science and Technology, Suan Dusit University.
Object-oriented design Part 4: More UML. Interfaces An interface is a language construct specific to Java Java does not support multiple inheritance Interfaces.
ACM/JETT Workshop - August 4-5, 2005 UML Modeling using MagicDraw UML for Java Programmers.
Unified Modeling Language
UML Sequence Diagrams Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
State and Sequence Diagrams Modelling dynamic information So far we have seen: Use Case Diagrams – requirements capture, interface.
UML for Java Programmers Object Mentor, Inc. Copyright  by Object Mentor, Inc All Rights Reserved
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 2: Modelling.
UML Collaboration Diagram. Recap System Sequence Diagrams (SSD) UML for SSD Examples.
程建群 博士(Dr. Jason Cheng) 年03月
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
UML diagrams What is UML UML diagrams –Static modeoing –Dynamic modeling 1.
An Introduction to the Unified Modeling Language
The Unified Modeling Language Part II Omar Meqdadi SE 2730 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Course Instructor: Kashif Ihsan 1. Chapter # 3 2.
SWT - Diagrammatics Lecture 4/4 - Diagramming in OO Software Development - partB 4-May-2000.
1 Kyung Hee University Diagram Editor : Design View Spring 2001.
Appendix D UML at a Glance Summary prepared by Kirk Scott 1.
Introduction to UML CS A470. What is UML? Unified Modeling Language –OMG Standard, Object Management Group –Based on work from Booch, Rumbaugh, Jacobson.
OMT Modeling 1. Object Model : presented by the object model and the data dictionary. 2. Dynamic Model: presented by the state diagrams and event flow.
Chapter 3 Class Diagrams. 2 Outline Class Basics Class Basics Classes Classes Association Association Multiplicity Multiplicity Inheritance Inheritance.
UML Part 1: Class Diagrams. Introduction UML stands for Unified Modeling Language. It represents a unification of the concepts and notations presented.
INFO 620Lecture #71 Information Systems Analysis and Design Design Class Diagrams and others INFO 620 Glenn Booker.
Chapter 3: Introducing the UML
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
Introduction to Unified Modeling Language (UML) By Rick Mercer with help from The Unified Modeling Language User Guide, Grady Booch, James Rumbaugh, Ivar.
Appendix 3 Object-Oriented Analysis and Design
Analysis Classes Unit 5.
CHAPTER
UML Diagrams By Daniel Damaris Novarianto S..
The Movement To Objects
Unified Modeling Language
Unified Modeling Language (UML)
Main issues: • What do we want to build • How do we write this down
Course Outcomes of Object Oriented Modeling Design (17630,C604)
7.1 What Is An Object Object-oriented program - Description or simulation of application Object-oriented programming is done by adopting or extending an.
Object-Oriented Analysis and Design
Chapter 11: Collaboration Diagram - PART1
Unified Modeling Language
Introduction to Unified Modeling Language (UML)
Sequence Diagram.
UML Diagrams Jung Woo.
Business System Development
UML dynamic Modeling (Behavior Diagram)
Software Architecture & Design Pattern
Classification of UML Diagrams
Week 12: Activity & Sequence Diagrams
Introduction to Unified Modeling Language (UML)
Chapter 20 Object-Oriented Analysis and Design
CIS 375 Bruce R. Maxim UM-Dearborn
Appendix A Object-Oriented Analysis and Design
Protocols CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 8) Meyer, B., Applying design by contract, Computer,
Sylnovie Merchant, Ph.D. MIS 161 Spring 2005
Chapter 22 Object-Oriented Systems Analysis and Design and UML
CIS 375 Bruce R. Maxim UM-Dearborn
Object Oriented System Design Class Diagrams
Appendix A Object-Oriented Analysis and Design
Appendix 3 Object-Oriented Analysis and Design
Presentation transcript:

Chapter 1 Overview of UML for Java Programmers

2 Outline Diagram Types Diagram Types Class Diagrams Class Diagrams Object Diagrams Object Diagrams Sequence Diagrams Sequence Diagrams Collaboration Diagrams Collaboration Diagrams State Diagrams State Diagrams

3 What is UML? (1/3) The Unified Modeling Language (UML) is a graphical notation for drawing diagrams of software concepts. The Unified Modeling Language (UML) is a graphical notation for drawing diagrams of software concepts. UML can be used to describe UML can be used to describe A problem domain A problem domain A proposed software design A proposed software design An already completed software implementation An already completed software implementation

4 What is UML? (2/3) Fowler describes the above mentioned levels as Fowler describes the above mentioned levels as Conceptual level: Conceptual level: Describes concepts and abstractions that exist in the human problem domain. Describes concepts and abstractions that exist in the human problem domain. Specification level: Specification level: A description of source code yet to be written. A description of source code yet to be written. Implementation level: Implementation level: A description of source code that already exists. A description of source code that already exists.

5 What is UML? (3/3) Diagrams at the Conceptual level are not strongly related to source code. Diagrams at the Conceptual level are not strongly related to source code. The diagrams in this book will be at Specification/Implementation level. The diagrams in this book will be at Specification/Implementation level.

6 Diagrams at the Conceptual Level (1/2) Not strongly related to source code, but related to human language. Not strongly related to source code, but related to human language. Do not follow strong semantic rules, and therefore their meaning can be ambiguous and subject to interpretation. Do not follow strong semantic rules, and therefore their meaning can be ambiguous and subject to interpretation.

7 Diagrams at the Conceptual Level (2/2) Example: Example: An Animal is a generalization of a Dog. An Animal is a generalization of a Dog. A Dog is a special case of an Animal. A Dog is a special case of an Animal. Nothing more can be inferred from Figure 1-1. Nothing more can be inferred from Figure 1-1. Two different interpretations: Two different interpretations: You pet dog, Sparky, is an animal. You pet dog, Sparky, is an animal. Dogs, as a biological species, belong to the animal kingdom. Dogs, as a biological species, belong to the animal kingdom.

8 Diagrams at the Specification /Implementation Level (1/2) Have a strong connection to source code. Have a strong connection to source code. A Specification level diagram can be turned into source code. A Specification level diagram can be turned into source code. An Implementation level diagram can be used to describe existing source code. An Implementation level diagram can be used to describe existing source code. Diagrams at these levels Diagrams at these levels Must follow rules and semantics. Must follow rules and semantics. Have very little ambiguity. Have very little ambiguity. Have a great deal of formality. Have a great deal of formality.

9 Diagrams at the Specification /Implementation Level (2/2) Example: Example: public class Animal {} public class Dog extends Animal {}

10 Questions How do you create a new class from an existing class using inheritance? How do you create a new class from an existing class using inheritance?

11 Main Kinds of Diagrams in UML (1/2) Static Diagrams Static Diagrams Describe the unchanging logical structure of software elements by depicting classes, objects, and data structures; and the relationship between them. Describe the unchanging logical structure of software elements by depicting classes, objects, and data structures; and the relationship between them. Dynamic Diagrams Dynamic Diagrams Show how software entities change during execution by depicting the flow of execution, or the way entities change state. Show how software entities change during execution by depicting the flow of execution, or the way entities change state.

12 Main Kinds of Diagrams in UML (2/2) Physical Diagrams Physical Diagrams Show the unchanging physical structure of software entities by depicting physical entities such as source files, libraries, binary files, data files, etc., and the relationships that exist between them. Show the unchanging physical structure of software entities by depicting physical entities such as source files, libraries, binary files, data files, etc., and the relationships that exist between them.

13 Example Program: TreeMap.java Implements a map based upon a simple binary tree algorithm. Implements a map based upon a simple binary tree algorithm. Make sure you are familiar with the code before you proceed. Make sure you are familiar with the code before you proceed.

14 TreeMap.java (1/3) public class TreeMap { TreeMapNode topNode = null; TreeMapNode topNode = null; public void add(Comparable key, Object value) { public void add(Comparable key, Object value) { if (topNode == null) if (topNode == null) topNode = new TreeMapNode(key, value); topNode = new TreeMapNode(key, value); else else topNode.add(key, value); topNode.add(key, value); } public Object get(Comparable key) { public Object get(Comparable key) { return topNode == null ? null : topNode.find(key); return topNode == null ? null : topNode.find(key); }}

15 TreeMap.java (2/3) class TreeMapNode { private final static int LESS = 0; private final static int LESS = 0; private final static int GREATER = 1; private final static int GREATER = 1; private Comparable itsKey; private Comparable itsKey; private Object itsValue; private Object itsValue; private TreeMapNode nodes[] = new TreeMapNode[2]; private TreeMapNode nodes[] = new TreeMapNode[2]; public TreeMapNode(Comparable key, Object value) { public TreeMapNode(Comparable key, Object value) { itsKey = key; itsKey = key; itsValue = value; itsValue = value; } public Object find(Comparable key) { public Object find(Comparable key) { if (key.compareTo(itsKey) == 0) return itsValue; if (key.compareTo(itsKey) == 0) return itsValue; return findSubNodeForKey(selectSubNode(key), key); return findSubNodeForKey(selectSubNode(key), key); }

16 TreeMap.java (3/3) private Object findSubNodeForKey(int node, Comparable key) { private Object findSubNodeForKey(int node, Comparable key) { return nodes[node] == null ? null : nodes[node].find(key); return nodes[node] == null ? null : nodes[node].find(key); } public void add(Comparable key, Object value) { public void add(Comparable key, Object value) { if (key.compareTo(itsKey) == 0) if (key.compareTo(itsKey) == 0) itsValue = value; itsValue = value; else else addSubNode(selectSubNode(key), key, value); addSubNode(selectSubNode(key), key, value); } private void addSubNode(int node, Comparable key, Object value) { private void addSubNode(int node, Comparable key, Object value) { if (nodes[node] == null) if (nodes[node] == null) nodes[node] = new TreeMapNode(key, value); nodes[node] = new TreeMapNode(key, value); else else nodes[node].add(key, value); nodes[node].add(key, value); }}

17 Class Diagrams (1/4) Class diagram of TreeMap: Class diagram of TreeMap:

18 Class Diagrams (2/4) Shows the major classes and relationships in the program. Shows the major classes and relationships in the program. Rectangles represent classes, and arrows represent relationships. Rectangles represent classes, and arrows represent relationships. All the relationships in Figure 1-2 are associations. Associations are simple data relationships in which one object holds a reference to, and invokes methods upon, the other. All the relationships in Figure 1-2 are associations. Associations are simple data relationships in which one object holds a reference to, and invokes methods upon, the other.

19 Class Diagrams (3/4) The name on an association maps to the name of the variable that holds the reference. The name on an association maps to the name of the variable that holds the reference. A number next to an arrowhead typically shows the number of instances held by the relationship. A number next to an arrowhead typically shows the number of instances held by the relationship. Class icons can have more than one compartment. The top compartment always holds the name of the class. The other compartments describe functions and variables. Class icons can have more than one compartment. The top compartment always holds the name of the class. The other compartments describe functions and variables.

20 Class Diagrams (4/4) The > notation means that Comparable is an interface. The > notation means that Comparable is an interface.

21 Questions What is an interface? What is an interface? Why are interfaces important? Why are interfaces important? What is an instance? What is an instance? Can you find the relationships between TreeMap.java and Figure 1-2? Can you find the relationships between TreeMap.java and Figure 1-2?

22 Object Diagrams (1/3) Object Diagram of TreeMap: Object Diagram of TreeMap:

23 Object Diagrams (2/3) Shows a set of objects and relationships at a particular moment in the execution of the system. Shows a set of objects and relationships at a particular moment in the execution of the system. Can also be viewed as a snapshot of memory. Can also be viewed as a snapshot of memory. Rectangles represent objects. Note that object names are underlined. Rectangles represent objects. Note that object names are underlined. The name after the colon is the name of the class that the object belongs to. The name after the colon is the name of the class that the object belongs to.

24 Object Diagrams (3/3) The lower compartment of each objects shows the value of that object’s itsKey variable. The lower compartment of each objects shows the value of that object’s itsKey variable. The relationships between the objects are called links, and are derived from the associations in Figure 1-2. The relationships between the objects are called links, and are derived from the associations in Figure 1-2.

25 Sequence Diagrams (1/3) Sequence diagram of TreeMap.add method: Sequence diagram of TreeMap.add method: public void add(Comparable key,Object value){ if (topNode == null) if (topNode == null) topNode = new TreeMapNode(key, value); topNode = new TreeMapNode(key, value); else else topNode.add(key, value); topNode.add(key, value);}

26 Sequence Diagrams (2/3) The stick figure represents an unknown caller. The stick figure represents an unknown caller. The boolean expressions inside square brackets are called guards. The boolean expressions inside square brackets are called guards. The long arrows are messages sent between the objects. The long arrows are messages sent between the objects. The message arrow that terminates on the TreeMapNode icon represents construction. The message arrow that terminates on the TreeMapNode icon represents construction.

27 Sequence Diagrams (3/3) The little arrows with circles are called data tokens, which are the construction arguments. The little arrows with circles are called data tokens, which are the construction arguments. The skinny rectangle below TreeMap is called an activation, which shows how much time the add method executes. The skinny rectangle below TreeMap is called an activation, which shows how much time the add method executes. The dashed lines are lifelines, they show the lifetime of the objects they descend from. The dashed lines are lifelines, they show the lifetime of the objects they descend from.

28 Collaboration Diagrams (1/3) Collaboration diagram depicting the case of TreeMap.add where treeNode is not null : Collaboration diagram depicting the case of TreeMap.add where treeNode is not null :

29 Collaboration Diagrams (2/3) Contain the same information that sequence diagram contain. Contain the same information that sequence diagram contain. Sequence diagram make the order of the messages clear. Sequence diagram make the order of the messages clear. Collaboration diagrams make the relationships between the objects clear. Collaboration diagrams make the relationships between the objects clear.

30 Collaboration Diagrams (3/3) A link exists wherever one object can send a message to another. A link exists wherever one object can send a message to another. Smaller arrows over the links are the messages, which are labeled with the names, sequence numbers, and any guards that apply. Smaller arrows over the links are the messages, which are labeled with the names, sequence numbers, and any guards that apply. The dot structure of the sequence number shows the calling hierarchy. The dot structure of the sequence number shows the calling hierarchy.

31 State Diagrams (1/5) States: There are two states named Locked and Unlocked. States: There are two states named Locked and Unlocked.

32 State Diagrams (2/5) Events: Events: Two events may be sent to the machine. Two events may be sent to the machine. The coin event means that the user has dropped a coin into the turnstile. The coin event means that the user has dropped a coin into the turnstile. The pass event means that the user has passed through the turnstile. The pass event means that the user has passed through the turnstile.

33 State Diagrams (3/5) Transitions: Transitions: The arrows are called transitions. They are labeled with the event that triggers the transition and the action that the transition performs. The arrows are called transitions. They are labeled with the event that triggers the transition and the action that the transition performs.

34 State Diagrams (4/5) Interpretation: Interpretation: If we are in the Locked state and we get a coin event, then we transition to the Unlocked state and we invoke the Unlock function. If we are in the Locked state and we get a coin event, then we transition to the Unlocked state and we invoke the Unlock function. If we are in the Unlocked state and we get a pass event, then we transition to the Locked state and we invoke the Lock function. If we are in the Unlocked state and we get a pass event, then we transition to the Locked state and we invoke the Lock function.

35 State Diagrams (5/5) Interpretation (cont.): Interpretation (cont.): If we are in the Unlocked state and we get a coin event, then we stay in the Unlocked state and we call the Thankyou function. If we are in the Unlocked state and we get a coin event, then we stay in the Unlocked state and we call the Thankyou function. If we are in the Locked state and we get a pass event, then we stay in the Locked state and we call the Alarm function. If we are in the Locked state and we get a pass event, then we stay in the Locked state and we call the Alarm function.