Chapter 16 UML Class Diagrams

Slides:



Advertisements
Similar presentations
Visibility Larman, Chapter 19 (with ideas from George Blank of NJIT) CSE432 Object Oriented Software Engineering.
Advertisements

Stereotypes Stereotypes provide the capability to create a new kind of modeling element. –They can be used to classify or mark modeling elements. –A type.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
UML Class Diagram. UML Class Diagrams2 Agenda What is a Class Diagram? Essential Elements of a UML Class Diagram Tips.
Oct 22, Ron McFadyen1 Design Class Diagrams n Class diagram with – classes – associations – attributes – methods – navigability – interfaces,
Object-Oriented Analysis and Design
Chapter 16. Fig Fig Note: If Sale references nothing then the only thing it is associated with is what references it Note: association name.
UML Class Diagram and Packages Written by Zvika Gutterman Adam Carmi.
7M701 1 Class Diagram advanced concepts. 7M701 2 Characteristics of Object Oriented Design (OOD) objectData and operations (functions) are combined 
NJIT Designing for Visibility Chapter 19 Applying UML and Patterns Craig Larman.
Designing with Interaction and Design Class Diagrams Chapters 15 & 16 Applying UML and Patterns Craig Larman With some ideas from students in George Blank’s.
The Unified Modeling Language (UML) Class Diagrams.
Object-Oriented Analysis and Design
Objectives Design Class Diagrams Issues in system design Generalization Review UML papers.
Systems Analysis and Design in a Changing World, Fifth Edition
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Introduction To System Analysis and Design
Object-Oriented Analysis and Design Feb 25, 2009.
Systems Analysis and Design in a Changing World, 3rd Edition
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Design Class Diagrams (DCDs)
Chapter 16 Applying UML and Patterns Craig Larman
UML Class Diagram Trisha Cummings. What we will be covering What is a Class Diagram? Essential Elements of a UML Class Diagram UML Packages Logical Distribution.
NJIT UML Class Diagrams Chapter 16 Applying UML and Patterns Craig Larman.
Object-Oriented Analysis and Design Feb 11, 2009.
Part VII: Design Continuous
Design Model Lecture p6 T120B pavasario sem.
1 Class Diagrams. 2 Overview Class diagrams are the most commonly used diagrams in UML. Class diagrams are for visualizing, specifying and documenting.
CS212: Object Oriented Analysis and Design Lecture 33: Class and Sequence Diagram.
Chapter 16: UML Class Diagrams
Chapter 16 UML Class Diagrams 1CS6359 Fall 2012 John Cole.
INFO 620Lecture #71 Information Systems Analysis and Design Design Class Diagrams and others INFO 620 Glenn Booker.
Chapter 16 UML Class Diagrams.
Chapter 3: Introducing the UML
OO Methodology Elaboration Phase Iteration 1- Part 3.
ITEC0724 Modern Related Technology on Mobile Devices Lecture Notes #2 1.
Chapter 7 Classes and Methods III: Static Methods and Variables Lecture Slides to Accompany An Introduction to Computer Science Using Java (2nd Edition)
TK2023 Object-Oriented Software Engineering CHAPTER 11 CLASS DIAGRAMS.
Kyung Hee University Class Diagramming Notation OOSD 담당조교 석사과정 이정환.
UML Fundamental Elements. Structural Elements Represent abstractions in our system. Elements that encapsulate the system's set of behaviors. Structural.
BTS430 Systems Analysis and Design using UML Design Class Diagrams (ref=chapter 16 of Applying UML and Patterns)
Design Model: Determining Visibility CH-18. Objectives Identify four kinds of visibility. Design to establish visibility. Illustrate kinds of visibility.
1 Chapter 13: Class Diagram Chapter 19 in Applying UML and Patterns Book.
Elaboration popo.
UML Diagrams: Class Diagrams The Static Analysis Model
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Design Class Diagrams
COMPONENT & DEPLOYMENT DIAGRAMS
Chapter 16 UML Class Diagrams.
GRASP: Visibility and Design
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
Unified Modeling Language
Design Class Diagrams
The Object Oriented Approach to Design
Object Oriented Analysis and Design
Requirements To Design In This Iteration
Chapter 10: Visibility Chapter 18 in Applying UML and Patterns Book.
Chapter 20 Applying UML and Patterns Craig Larman
UML Class Diagram.
Chapter 20 Object-Oriented Analysis and Design
Analysis models and design models
Class Diagrams.
Chapter 11: Class Diagram
Copyright 2007 Oxford Consulting, Ltd
Chapter 22 Object-Oriented Systems Analysis and Design and UML
CIS 375 Bruce R. Maxim UM-Dearborn
Object Oriented System Design Class Diagrams
UML  UML stands for Unified Modeling Language. It is a standard which is mainly used for creating object- oriented, meaningful documentation models for.
Chapter 11: Class Diagram
Design Model: Creating Design Class Diagrams
Presentation transcript:

Chapter 16 UML Class Diagrams “To iterate is human, to recurse, divine.” - anonymous Objectives Provide a reference for frequently used UML class diagram notation. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Introduction The UML includes class diagrams to illustrate classes, interfaces, and their associations. “Static object modeling” This chapter is a reference, it summarizes the notation, irrespective of the perspective (conceptual or software) Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Fig 16.1 Common UML class diagram notation. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Design Class Diagrams (DCD) The UML has notation for showing design details in static structure: Class Diagrams. The definition of design class diagrams occurs within the design phase. The UML does not specifically define design class diagram. The creation of design class diagrams is dependent upon the prior creation of: Interaction diagrams identifies the SW classes that participate in the solution, plus the methods of classes. Conceptual model adds detail to the class definitions. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Fig. 16.2 UML class diagrams in two perspectives. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

As we can see…. A design class diagram illustrates the specifications for SW classes and interfaces. Typical information included: Classes, associations, and attributes Interfaces, with their operations and constants Methods Attribute type information Navigability Dependencies Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Fig. 16.3 Attribute text vs. Association line notation for a UML attribute. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Fig. 16.4 Idioms in association notation usage in different perspectives. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Fig. 16.5 Applying the guidelines to show attributes in two notations. public class Register { private int id; private Sale currentSale; private Store location; } Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

How to make a DCD Identify all the classes participating in the SW solution by analyzing the interaction diagrams. Draw them in a class diagram. Duplicate the attributes from the associated concepts in the conceptual model. Add method names by analyzing the interaction diagrams. Add type information to the attributes and methods. Add the associations necessary to support the required attribute visibility. Add navigability arrows to the associations to indicate the direction of attribute visibility. Add dependency relationship lines to indicate non-attribute visibility. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Creating the NextGen POS DCD Identify SW classes and illustrate them. Register Sale ProductCatalog ProductSpecification Store SalesLineItem Payment Draw a class diagram for these classes. Include the attributes previously identified in the domain model. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Creating the NextGen POS DCD (2) Add method names from interaction diagrams Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Method Names: Issues The following special issues must be considered with respect to method names: Interpretation of the create() message. Depiction of accessing methods. Interpretation of messages to multi-objects. Language-dependent syntax. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

<<constructor>> SuperclassFoo(Long) Method names: create The “create” message is the UML language independent form to indicate instantiation and initialization. When translating the design to an OOPL, it must be expressed in terms of its idioms for instantiation and initialization. <<constructor>> SuperclassFoo(Long) Class Name Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Method names: Accessing Methods Accessing methods are those which retrieve (accessor method - get) or set (mutator method) attributes. It is common idiom to have an accessor and mutator for each attribute, and to declare all attribute private (to enforce encapsulation). They are also called getter and setter methods. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Method names: Multi-Objects A message to a multi-object is interpreted as a message to the container/collection object Java’s map, C++’s map, Smalltalk’s dictionary. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Fig. 16.6 Two ways to show a collection attribute in the UML. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Method Names: Language Dependent Syntax The basic UML format for methods: methodName(parameterList) The type of the attributes, method parameters, and method return values may all optionally be shown. The design class diagram should be created by considering the audience. If it is being created in a CASE tool with automatic code generation, full and exhaustive details are necessary. If it is being created for SW developers to read, exhaustive low-level detail may adversely effect the noise-to-value ratio. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Adding Associations and Navigability Navigability is a property of the role which indicates that it is possible to navigate uni-directionally across the association from objects of the source to target class. Navigability implies visibility. Navigability is identified from Interaction Diagrams. Most, if not all, associations in design-oriented class diagrams should be adorned with the necessary navigability arrows. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Showing navigability, or attribute visibility Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Association with navigability Define an association with a navigability adornment from A to B: A sends a message to B. A creates an instance B. A needs to maintain a connection to B Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Associations with Navigability Adornments Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Adding dependency relationships Dependency relationship indicates that one element (of any kind, including classes, use cases, and so on) has knowledge of another element. A dependency is a using relationship that states a change in specification of one thing may affect another thing that uses it, but not necessarily the reverse. The dependency relationship is useful to depict non-attribute visibility between classes. Parameters Global or local visibility A dashed arrow line A dashed directed line Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Dependency Relationships Non-Attribute Visibility Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Notation for Method Bodies in DCDs Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Interfaces The UML has several ways to show interface implementations. Timer getTime() Clock1 getTime( ) The UML has several ways to show interface implementations. Since both the socket line notation and the dependency line notation used curved lines not common in drawing tools, most people use a dependency arrow and the «interface» stereotype. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

UML stereotypes A stereotype represents a refinement of an existing modeling concept and is defined within a UML profile. UML uses stereotypes encapsulated in guillemots (« and », not << and >> ) to extend many diagram symbols. Guillemots can be found in the latin-1 symbol set in Windows Insert Symbol command) Examples: «interface» «extends» «includes» «actor» «create» «destroy» Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Fig. 16.8 Stereotype declaration and use. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Association Navigation An association is a structural relationship that specifies that objects of one thing are connected to objects of another. Navigation Navigability is a property of the role which indicates that it is possible to navigate uni-directionally across the association from objects of the source to target class. Navigability implies visibility. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Dependency A dependency is a using relationship, specifying that a change in the specification of one thing may affect another thing that uses it. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Figure 16.10 Showing dependency. Public class Foo { Public void doX( ) { System.runFinalization( ); . . . } Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Figure 16.11 Optional dependency labels in the UML. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Interfaces – Different Notations Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Generalization A generalization is a relationship between a general thing (called the super class or parent) and a more specific kind of that thing (called the subclass or child). is-a-kind-of relationship. Is this the same as OO PL inheritance? In donain modeling, no. In software modeling, yes. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Aggregation and Composition Aggregation – (seldomly used) Whole/part relationship Has-a relationship Composition is a type of aggregation and a strong kind of whole/part relationship: 1. An instance of the part belongs to only one composite instance at a time. 2.The part must always belong to a composite, and 3.The composite is responsible for the creation and deletion of its parts. (If the composite is destroyed, its parts must either be destroyed, or attached to another composite.) Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Constraints A UML constraint is a restriction or condition on a UML element. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Qualified Association A Qualified Association has a qualifier that is used to select an object (or objects) from a larger set of related objects, based upon the qualifier key. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Association Class An association class allows you treat an association itself as a class, and model it with attributes, operations, and other features. You will see that it is necessary to use an association class in modeling of some cases. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Figure 16.17 Showing a singleton. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

User Defined Compartments Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Active Class An active object runs on and controls its own thread of execution. The class of an active object is an active class. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Realization A realization is a semantic relationship between classifiers in which one classifier specifies a contract that another classifier guarantees to carry out. We use realization in two circumstances: In the context of interfaces. In the context of collaborations. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

When to create DCDs? Although this presentation of design class diagrams follows the creation of interaction diagrams, in practice they are usually created in parallel. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Phases Inception Elaboration Construction The Design Model and DCDs will not usually be started until elaboration because it involves detailed design decisions, which are premature during inception Elaboration During this phase, DCDs will accompany the UC realization interaction diagrams; they may be created for the most architecturally significant classes of the design. CASE tools can reverse-engineer (generate) DCDs from source code Construction DCDs will continue to be generated from the source code as an aid in visualizing the static structure of the system Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Chapter 18 Designing for Visibility “A mathematician is a device for turning coffee into theorems.” - Paul Erdös Objectives Identify four kinds of visibility. Design to establish visibility. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Introduction Visibility is the ability of one object to see or have reference to another. Q. When is visibility necessary? A. To send a message from one object to another, the receiver object must be visible to the sender, so the sender has to have a pointer or reference to the receiver. Those new to object design sometimes don’t think about and design to achieve necessary visibility. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Q.If A sends messages to B, which must be visible to which? A. “B is visible to A” means “A can send a message to B”. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Visibility Visibility is related to the scope: Is one resource (such as an instance) within the scope of another? The motivation to consider visibility: For an object A to send a message to an object B, B must be visible to A. How visibility can be achieved from object A to object B: Four kinds of visibility: Attribute visibility - B is an attribute of A Parameter visibility - B is a parameter of a method of A Local visibility - B is a local object in a method of A Global visibility - B is in some way globally visible. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Attribute Visibility Attribute visibility from A to B exists when B is an attribute of A. Relatively permanent visibility because it persists as long as A and B exist Most common form of visibility Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Parameter Visibility Parameter visibility from A to B exists when B is passed as a parameter to a method of A. Relatively temporary visibility because it persists only within the scope of the method. The second most common form of visibility in the OO systems. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Parameter to Attribute Visibility It is common to transform parameter visibility into attribute visibility Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Local Visibility Local visibility from A to B exists when B is declared as a local object within a method of A. Relatively temporary visibility since it persists only within the scope of the method. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Local Visibility There are two common means by which local visibility is achieved: Create a new local instance and assign it to a local variable. Assign the returning object from a method invocation to a local variable. A variation of this method does not explicitly declare a variable, but one implicitly exists as the result of a returning object from a method invocation Ex: anObject.getAnotherObject.doSomething(); Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Global Visibility Global visibility from A to B exists when B is global to A. Relatively permanent visibility since it persists as long as A and B exist. The least common form of visibility in OO Systems. Ways to achieve global visibility: Assign an instance to a global variable. Use the Singleton pattern Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Singleton Pattern (Gang of Four) Problem: Exactly one instance of a class is needed. Objects need a single point of access. Solution: Define a class method that returns the singleton object, instantiating it if it does not exist. Example: A print queue—many programs must access one queue. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Illustrating Visibility in the UML Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Visibility in the UML Public: Any outside classifier with visibility to the given classifier can use the feature; specified by pre-pending the symbol “+”. Protected: Any descendant of the classifier can use the feature; specified by pre-pending the symbol “#”. Private: Only the classifier itself can use the feature; specified by pre-pending the symbol “-”. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Terms: Classifier and Feature A classifier is a mechanism that describes structural and behavioral features. Modeling elements that can have instances are called classifiers. Classifiers include classes, interfaces, datatypes, signals, components, nodes, use cases, and subsystems. A classifier has structural feature (in the form of attributes), as well as behavioral features (in the form of operations). A feature is a property, such as operations or attributes that is encapsulated within entity such as an interface, a class, or a datatype. Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005

Questions & Answers Q. Which would you use if you wanted a relatively permanent connection? A. attribute, or global Q. Which would you use if you didn't want a permanent connection? A. parameter, or local Q. How would you create a local visibility? A. create a new instance - use result of a method call Q. How would you achieve a global visibility? A. use a global variable in C++, static (or class) variable (in C++ or Java) - use the Singleton pattern (a static method that returns the object) Dr. Kivanc Dincer CS319 Week 7 - Oct.24,2005