1 Class Diagrams. 2 Overview Class diagrams are the most commonly used diagrams in UML. Class diagrams are for visualizing, specifying and documenting.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
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.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Architectural Modeling Notations.
Unified Modeling Language
Object-Oriented Analysis and Design
UML – Class Diagrams.
1 © Wolfgang Pelz UML3 UML 3 Notations describe how to use reusable software. Package Component Deployment Node.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
7M701 1 Class Diagram advanced concepts. 7M701 2 Characteristics of Object Oriented Design (OOD) objectData and operations (functions) are combined 
Component and Deployment Diagrams
© Copyright Eliyahu Brutman Programming Techniques Course.
Object-Oriented Analysis and Design
UML Sequence Diagrams Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
OO Analysis and Design CMPS OOA/OOD Cursory explanation of OOP emphasizes ▫ Syntax  classes, inheritance, message passing, virtual, static Most.
Development of Rigorous Adaptive Information Systems
An Object-Oriented Approach to Programming Logic and Design
An Introduction to Software Architecture
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: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
1 UML Basic Training. UML Basic training2 Agenda  Definitions: requirements, design  Basics of Unified Modeling Language 1.4  SysML.
Systems Analysis and Design in a Changing World, 3rd Edition
Unified Modeling Language © 2002 by Dietrich and Urban1 ADVANCED DATABASE CONCEPTS Unified Modeling Language Susan D. Urban and Suzanne W. Dietrich Department.
1 Class Diagrams: Advanced Concepts. 2 Overview Class diagrams are the most commonly used diagrams in UML. Class diagrams are the most commonly used diagrams.
Design Analysis builds a logical model that delivers the functionality. Design fully specifies how this functionality will be delivered. Design looks from.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
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.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Advanced UML Class Diagrams.
TAL7011 – Lecture 4 UML for Architecture Modeling.
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University
Object-Oriented Analysis and Design Feb 11, 2009.
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
Design Model Lecture p6 T120B pavasario sem.
Relationships Relationships between objects and between classes.
OBJECT ORIENTED AND FUNCTION ORIENTED DESIGN 1 Chapter 6.
Karolina Muszyńska Based on: S. Wrycza, B. Marcinkowski, K. Wyrzykowski „Język UML 2.0 w modelowaniu SI”
Software Engineering Lecture 8 Object-Oriented Analysis.
UML / UML 2.0 Diagrams (Part I) 1. Overview of the 13 diagrams of UML Structure diagrams 1.Class diagram 2.Composite structure diagram (*) 3.Component.
Lecture 9-1 : Intro. to UML (Unified Modeling Language)
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
Chapter 16 UML Class Diagrams 1CS6359 Fall 2012 John Cole.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
Chapter 3: Introducing the UML
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
ITEC0724 Modern Related Technology on Mobile Devices Lecture Notes #2 1.
Introduction to UML Hazleen Aris Software Eng. Dept., College of IT, UNITEN. …Unified Modeling Language.
UML Fundamental Elements. Structural Elements Represent abstractions in our system. Elements that encapsulate the system's set of behaviors. Structural.
Basic Structural Modeling Pertemuan ke 4 Classes.
WELCOME TO OUR PRESENTATION UNIFIED MODELING LANGUAGE (UML)
1 IS 0020 Program Design and Software Tools Unified Modeling Language Lecture 13 April 13, 2005.
1 IS 0020 Program Design and Software Tools Unified Modeling Language Lecture 13 November 30, 2004.
R R R CSE870: UML Component Diagrams Implementation Diagrams.
UML Diagrams: Class Diagrams The Static Analysis Model
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Object-Oriented Analysis and Design
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
Unified Modeling Language
The Object Oriented Approach to Design
Object Oriented Analysis and Design
Unified Modeling Language
Analysis models and design models
Software Design Lecture : 15.
Class Diagrams.
An Introduction to Software Architecture
The generalization of class
UML  UML stands for Unified Modeling Language. It is a standard which is mainly used for creating object- oriented, meaningful documentation models for.
Presentation transcript:

1 Class Diagrams

2 Overview Class diagrams are the most commonly used diagrams in UML. Class diagrams are for visualizing, specifying and documenting the system from a static perspective. Class diagrams indicate which classes know about other classes and, if they do, what type of relationship exists. Class diagrams will have different levels of detail (abstraction) depending on where we are in the software development process.

3 Overview Class diagrams commonly contain classes, interfaces, collaborations and associations. Class diagrams help in showing the functional requirements of the system - the services the system should provide to its end users.

4 A Class Diagram

5 Common Modeling Techniques To model a collaboration (a group of classes working toward a common purpose) … –Use scenarios to see which classes are actually involved in carrying out a particular operation. Scenarios will also aide in establishing relationships between classes. –Fill in the ‘responsibilities’ section of each class icon. The responsibilities of each class will eventually evolve into actual attributes and behaviors. –A complex system typically requires multiple class diagrams. Each diagram is devoted to a particular functionality of the system.

6 Modeling Simple Collaborations

7 Common Modeling Techniques To model a logical database schema … –Identify the persistent objects - objects that are stored on disk between runs of the program. –Label persistent objects as such in the class diagrams using tags or stereotypes.

8 Modeling a Database Schema

9 Common Modeling Techniques Multiple class diagrams are required to model large systems. Each individual class diagram … –Shows a single aspect of the system. –Contains only elements that are essential to understanding that aspect. –Provide details consistent with its level of abstraction. –Uses meaningful class and member names. Pointers to other classes are modeled as associations.

10 Advanced Class Diagram Features

11 Overview A classifier is a mechanism that describes structural and behavioral features. Types of classifiers are … –classes, interfaces, datatypes, signals, components, nodes, use cases and subsystems. Classes are the most important kind of classifier. –Classes have a number of features beyond attributes and behaviors that allow you to model some of the more subtle/advanced features of a system.

12 Advanced Class Features

13 Terms and Concepts Other classifier definitions: –Interface - A collection of operations that are used to specify a service of a class or component. –Datatype - Modeled as a class with the strerotype >. May be primitive or user-defined. –Signal - A class used for communicating information. The class in its entirety is a kind of message. –Component - A physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. –Node - A physical element that exists at run time and that represents a computational resource.

14 Terms and Concepts Other classifier definitions: –Use case - A description of a set of a sequence of actions that yields an observable result of value to a particular actor. Actor - An external user of the system. –Subsystem - A grouping of element that carry out a subset of the entire systems functionality. Modeled as a package with the stereotype >

15 Classifier Icons

16 Terms and Concepts Visibility –Class members (attributes and behaviors) may be specified as public (+), private (-), or protected (#). –In UML the single character visibility indicator is placed to the left of the member. # myProtectedFunction( ) - myPrivateFunction( ) + myPublicFunction( ) –Restricting visibility is the same as restricting accessibility. By restring accessibility you are limiting the number of entry points into an object. By restricting the number of entry points you are facilitating debugging and code re-use.

17 Terms and Concepts Scope –Individual member data (attributes) may have either class scope or instance scope. –Class scope - A single copy of an attribute is shared by all instances of a class. In UML you underline the attribute to indicate class scope: productCount : int In C++ members with class scope would be declared as static: static int productCount –Instance scope - Each instance of a class would have its own copy of the attribute. All attributes have instance scope by default.

18 Terms and Concepts Abstract –A abstract class cannot have any direct instances. –Not all OO programming languages directly support abstract classes. (In C++ abstract classes contain one or more pure virtual functions). int myFunction(int x) = 0; Pure virtual functions have no function body. –An abstract class is thought to be so general as to be useless by itself. –Abstract classes only occur in the context of an inheritance hierarchy. –In UML you specify that a class is abstract by writing its name in italics.

19 Terms and Concepts Root and Leaf –Tags may be used to indicate that a class can have no parents ( {root} ) or children ( {leaf} ). There is rarely an occasion to use this feature.

20 Terms and Concepts Polymorphism –Polymorphic behavior exists in the context of inheritance. –Polymorphism applies to behavior (member functions) only. –Polymorphism is synonymous with dynamic binding. –In UML a behavior name in italics is used to indicate polymorphism. –In C++ a polymorphic call would most likely appear as (*baseClassPointer).poylmorphicFunction( ); baseClassPointer -> poylmorphicFunction( );

21 Abstract and Concrete Classes and Operations

22 Terms and Concepts Multiplicity –Class multiplicity In ULM it can be indicated by placing a number in the upper right corner of the class icon. Most commonly expressed in the context of associations between classes. –Attribute multiplicity In UML it is indicated as an expression appearing in square brackets just after the attribute name. Looks like an array declaration in C++. –attributeName [4] : attributeType

23 Terms and Concepts Attributes –May be expressed using various levels of detail. –The syntax for an attribute is [visibility] name [multiplicity] [: type] [ = initialValue ] [{propertyTag}] –There are three predefined property tags changeable - the attribute may be read and modified (default) addOnly - when multiplicity > 1, additional objects may be added but not removed frozen - read only (constant value) –The only feature of an attribute that is required in a class icon is its name.

24 Terms and Concepts Operations (behaviors) –May be expressed using various levels of detail. –The syntax for an operation is [visibility] name [(parameterList)] [: returnType] [{propertyTag}] –Predefined propertyTags are... isQuery - cannot change the state of the object. Sequential - only one thread of control in the object at a time. Guarded - pretty much the same as sequential concurrent - multiple threads of control may be in the object simultaneously.

25 Terms and Concepts Operations (behaviors) continued... –Each parameter has the syntax: [direction] name : type [= defaultValue] Directions may be in, out, or inout. –The only feature of an operation that is required in a class icon is its name.

26 Terms and Concepts Templates are... –A parameterized element. –Intended to facilitate software reusability. –Used to automate the creation of class definitions. –Similar to macros in assembly language. –Essentially a class definition with the data types of certain attributes yet to be defined. –Most commonly used to create container classes. –Represented in UML as a dashed box in the upper right-hand corner of the class icon, which lists the template parameters. –Directly supported in C++.

27 Template Icon

28 Common Modeling Techniques A well-defined class is loosely coupled (few entry points) and highly cohesive (all members work toward a common functionality). Ask yourself “Am I trying to show what the class does or how it does it”. That will tell you at what level of abstraction to model the class. In the requirements and specification phase you are interested in “what”. In the design phase you are interested in “how”. Don’t hesitate to attach notes to the class icons if further clarification is necessary.