Introduction to UML and Class Diagrams

Similar documents
Introduction to UML and Class Diagrams

Unified Modeling Language

Class Diagram. Classes consist of. Note that class diagrams contain only classes, not objects.

Class Diagram. Classes consist of. Note that class diagrams contain only classes, not objects.

Unified Modeling Language (UML) Class Diagram

Chapter 6 Introduction to Defining Classes

UML. By Somenath Mukhopadhyay.

Object Oriented Paradigm

A - 1. CS 494 Object-Oriented Analysis & Design. UML Class Models. Overview. Class Model Perspectives (cont d) Developing Class Models

CSE 403: Software Engineering, Spring courses.cs.washington.edu/courses/cse403/15sp/ UML Class Diagrams. Emina Torlak

Class diagrams. Modeling with UML Chapter 2, part 2. Class Diagrams: details. Class diagram for a simple watch

Defining Classes and Methods

1/17/2014. UML Help and Details (from: UML for cse UML for a class. UML and project clarifications

AP Computer Science Chapter 10 Implementing and Using Classes Study Guide

Association, Aggregation and Composition. Software Engineering CITS1220

Java Programming. U Hou Lok. Java Aug., Department of Computer Science and Information Engineering, National Taiwan University

The Essence of Object Oriented Programming with Java and UML. Chapter 2. The Essence of Objects. What Is an Object-Oriented System?

Class diagrams. Modeling with UML Chapter 2, part 2. Class Diagrams: details. Class diagram for a simple watch

ITI Introduction to Computing II

Aggregation and Composition

+ Public - Private # Protected # Protected (Overridable) Static

INHERITANCE - Part 1. CSC 330 OO Software Design 1

The return Statement

INTERNAL ASSESSMENT TEST III Answer Schema

Class modelling (part 2)

ITI Introduction to Computing II

Chapter 10. Object-Oriented Analysis and Modeling Using the UML. McGraw-Hill/Irwin

Introduction to C++ Introduction to C++ Dr Alex Martin 2013 Slide 1

APCS Semester #1 Final Exam Practice Problems

Graphical Interface and Application (I3305) Semester: 1 Academic Year: 2017/2018 Dr Antoun Yaacoub

Introduction to OO Concepts

Object-Oriented Design

Example: Fibonacci Numbers

Inheritance, and Polymorphism.

UML Modeling I. Instructor: Yongjie Zheng September 3, CS 490MT/5555 Software Methods and Tools

Design Patterns IV. Alexei Khorev. 1 Structural Patterns. Structural Patterns. 2 Adapter Design Patterns IV. Alexei Khorev. Structural Patterns

Design Patterns IV Structural Design Patterns, 1

Assumptions. History

OO is considered to be supported in three points which are usually symbolized as the three vertexes of a triangle: Encapsulació i ocultació

Programming, numerics and optimization

2 UML for OOAD. 2.1 What is UML? 2.2 Classes in UML 2.3 Relations in UML 2.4 Static and Dynamic Design with UML. UML for OOAD Stefan Kluth 1

LABORATORY 1 REVISION

Objectives. INHERITANCE - Part 1. Using inheritance to promote software reusability. OOP Major Capabilities. When using Inheritance?

COSC 3351 Software Design. An Introduction to UML (I)

Chapter 10 Object-Oriented Design Principles

Engineering Design w/embedded Systems

The Unified Modeling Language. Asst.Prof.Dr. Supakit Nootyaskool IT-KMITL

S T R U C T U R A L M O D E L I N G ( M O D E L I N G A S Y S T E M ' S L O G I C A L S T R U C T U R E U S I N G C L A S S E S A N D C L A S S D I A

An Introduction to C++

Introduction to Programming Using Java (98-388)

Object Oriented Programming in Java. Jaanus Pöial, PhD Tallinn, Estonia

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Class modelling (part 2)

OBJECT ORIENTED DESIGN with the Unified Process. Use Case Realization

EMBEDDED SYSTEMS PROGRAMMING OO Basics

Component Design. Systems Engineering BSc Course. Budapest University of Technology and Economics Department of Measurement and Information Systems

Recursion 1. Recursion is the process of defining something in terms of itself.

OO Techniques & UML Class Diagrams

Object-Oriented Design

Reviewing OO Concepts

C++ (classes) Hwansoo Han

Meltem Özturan

IS 0020 Program Design and Software Tools

Unified Modeling Language

SEEM4570 System Design and Implementation. Lecture 11 From Design to Implementation

Chapter 5: Procedural abstraction. Function procedures. Function procedures. Proper procedures and function procedures

Introduction to Software Engineering. 5. Modeling Objects and Classes

Abstract Data Types (ADT) and C++ Classes

COP 3330 Final Exam Review

Course "Softwaretechnik" Book Chapter 2 Modeling with UML

Data Structures. Data structures. Data structures. What is a data structure? Simple answer: a collection of data equipped with some operations.

Objectives. Explain the purpose and objectives of objectoriented. Develop design class diagrams

COURSE 2 DESIGN PATTERNS

Chapter 2: Relationship between. classes using UML. Dr. Safwan Qasem

Computer Science 2 Lecture 4 Inheritance: Trinidad Fruit Stand 02/15/2014 Revision : 1.7

Introduction to Software Engineering. 5. Modeling Objects and Classes

2. The object-oriented paradigm!

Basic Object-Orientation

administrivia today UML start design patterns Tuesday, September 28, 2010

Object Oriented Software Design II

CompuScholar, Inc. Alignment to Nevada "Computer Science" Course Standards

Object Oriented Software Design II

Chapter 6 Lab Classes and Objects

12 Tutorial on UML. TIMe TIMe Electronic Textbook

Inheritance. Inheritance Reserved word protected Reserved word super Overriding methods Class Hierarchies Reading for this lecture: L&L

Introducing the UML Eng. Mohammed T. Abo Alroos

Chapter 6 Lab Classes and Objects

CSE 12, Week Six, Lecture Two Discussion: Getting started on hw7 & hw8

index.pdf January 21,

CS1004: Intro to CS in Java, Spring 2005

Creating an object Instance variables

OBJECT ORIENTED DESIGN with the Unified Process. Use Case Realization

Details of Class Definition

ITI Introduction to Computing II

ITI Introduction to Computing II

The State Design Pattern

Programming C++ Lecture 3. Howest, Fall 2012 Instructor: Dr. Jennifer B. Sartor

Handout 7. Defining Classes part 1. Instance variables and instance methods.

Ch. 11: References & the Copy-Constructor. - continued -

SOFTWARE DESIGN COSC 4353 / Dr. Raj Singh

Transcription:

Introduction to UML and Class Diagrams Engineering 5895 Faculty of Engineering & Applied Science Memorial University of Newfoundland 2017, T. S. Norvell, A. Vardy 1 / 34

UML Unified Modelling Language (UML) UML is a graphical modelling Language graphical --- UML documents are diagrams modelling --- UML is for describing systems systems --- may be software systems or domains (e.g. business systems), etc. It is semi-formal The UML definition tries to give a reasonably well defined meaning to each construct 2017, T. S. Norvell, A. Vardy 2 / 34

Three Ways of Using UML UML as sketch Used to sketch out some aspects of the system Create diagrams only for important classes and interactions UML as blueprint Complete design for the whole system Interfaces for all subsystems specified (but not implementation!) UML as programming language Diagrams compiled directly to executable code! Neat idea, but not yet mainstream We will utilize UML as sketch in this course 2017, T. S. Norvell, A. Vardy 3 / 34

Classes Classes are specifications for objects Parts of a class: Name Set of attributes (aka data members or fields) Set of operations Constructors: initialize the object state Accessors: report on the object state Mutators: alter the object state Destructors: clean up (not used in Java) 2017, T. S. Norvell, A. Vardy 4 / 34

C++ Representation of a Class class Point { private: Attributes double x, y; public: /* Constructor. */ Point(double x, double y) { this->x = x; this->y = y; }; double getx() { return x; }; void setx(double inx) { x = inx; }; //... }; Operations 2017, T. S. Norvell, A. Vardy 5 / 34

Java Representation of a Class public class Point { private double x, y; Attributes /* Constructor. */ public Point(double x, double y) { this.x = x; this.y = y; } Operations } public double getx() { return x; } public void setx(double inx) { x = inx; } //... 2017, T. S. Norvell, A. Vardy 6 / 34

A Student Class in Java class Student { } Name private long studnum ; private String name ; Attributes public Student( long sn, String nm ) { studnum = sn; name = nm; } public String getname() { return name; } public long getnumber() { return studnum; } Operations 2017, T. S. Norvell, A. Vardy 7 / 34

UML Representation of a Class - private + public UML syntax: +/- name : type 2017, T. S. Norvell, A. Vardy 8 / 34

Classes in UML UML can be used for many purposes. In software design UML classes usually correspond to classes in the code. But in domain analysis UML classes are typically classes of real objects (e.g. real students) rather than their software representations. 2017, T. S. Norvell, A. Vardy 9 / 34

Usage of (Software) Classes in Java A class C can be used in 3 ways: Instantiation. You can use C to create new objects. Example: new C() Extension. You can use C as the basis for implementing other classes Example: class D extends C { } Type. You can use C as a type Examples: C func( C p ) { C q ; } 2017, T. S. Norvell, A. Vardy 10 / 34

Relationships Between Classes Association Aggregation Composition Dependence Generalization 2017, T. S. Norvell, A. Vardy 11 / 34

Association Relationships Association is a general purpose relationship between classes. Associations are typically named. Associations are often implemented with pointers (C++) or reference variables (Java) Student takes Section 2017, T. S. Norvell, A. Vardy 12 / 34

Multiplicity Constraints Each Department is associated with one DepartmentHead and at least one DepartmentMember Each DepartmentHead and DepartmentMember is associated with one Department No constraint means multiplicity is unspecified Department 1 1 1..* DepartmentMember 1 Department Head 2017, T. S. Norvell, A. Vardy 13 / 34

Role names Role names may be given to the ends of an association Only name roles when it adds clarity Professor 1..* teaches instructor Student takes 1..* Section assigned section 2017, T. S. Norvell, A. Vardy 14 / 34

Navigability An arrow-head indicates the direction of navigability. E.g. Given a student object, we can easily find all Sections the student is taking. No arrow-head: means navigability in both directions. Student Department takes 1 1 Section DepartmentHead 2017, T. S. Norvell, A. Vardy 15 / 34

Implementing Navigable Associations Usually implemented with data members class Student { private List<Section> sections; } class Department { private DepartmentHead depthead; } Student takes * Section Department 1 1 DepartmentHead 2017, T. S. Norvell, A. Vardy 16 / 34

Implementing Associations Indirectly An association between objects might also be stored outside of the objects class Department { private static Map<Department,DepartmentHead> heads = new<department,departmenthead> HashMap(); } DepartmentHead gethead() { return heads.get(this); } 2017, T. S. Norvell, A. Vardy 17 / 34

Aggregation Aggregation is a special case of association. It is used when there is a whole-part relationship between objects. Denoted with an unfilled diamond at the whole end eg. A Club is an aggregation of Persons (the members of the club) 2017, T. S. Norvell, A. Vardy 18 / 34

Composition Composition is a special case of aggregation Composition is appropriate when each part is a part of one whole the lifetime of the whole and the part are the same Denoted by a solid diamond at the whole end eg. A Polygon is composed of 3 or more Points 2017, T. S. Norvell, A. Vardy 19 / 34

Composition vs. Aggregation The difference between composition and aggregation is lifetime For example, if whenever the points that compose it are destroyed, the polygon is destroyed (and vice versa) then we have composition But maybe this is not what what we want. If we allow the points to exist independently of the polygon, then we can also use them to define other shapes 2017, T. S. Norvell, A. Vardy 20 / 34

Note: Class Diagrams Show Class Relationships, Not Object Relationships Consider again this example: We're not saying that the same points (i.e. instances of Point) are necessarily shared by Polygons and Circles, but they could be 2017, T. S. Norvell, A. Vardy 21 / 34

Recursive associations Associations may relate a class to itself. -leftchild 0..1 AVLTreeNode 0..1 -rightchild The objects of the class may or may not be associated with themselves. GraphNode 0..* -neighbours (For example, the left and right children of a node would not be that node. But a GraphNode object might be its own neighbour.) Component (from awt) 0..* contains 2017, T. S. Norvell, A. Vardy 22 / 34

Associations vs. attributes OR Both are usually implemented by variables within the class Fields (Java), data members (C++). Use association for references that point to classes or interfaces. Or use aggregation or composition if appropriate Use attributes for primitive types such as int, boolean, char 2017, T. S. Norvell, A. Vardy 23 / 34

Degrees of belonging Attribute. Lifetime of attribute equals life time of object that contains it. Aggregation. Whole-part relationship, but parts could be parts of several wholes, or could migrate from one container to another. Composition. Lifetime of the part equals or is, by design, nested within the lifetime of the whole. Association. Relationship is not part/whole. 2017, T. S. Norvell, A. Vardy 24 / 34

Generalization/Specialization Represents is-a-kindof relationships. E.g. every Chimp is also an Ape. In OO implementation it represents class inheritance: Inheritance of interface and of implementation too. Chimp Person Ape Primate DepartmentHead DepartmentMember 2017, T. S. Norvell, A. Vardy 25 / 34

Pausing here to introduce Inheritance, Abstract Classes and Methods, and Interfaces in Java 2017, T. S. Norvell, A. Vardy 26 / 34

Interfaces Stereotypes are given in angle brackets Interfaces are classes that have no associated implementation. I.e. no attributes, no implementations for any operations In UML use either stereotype to indicate an interface, or lollypop <<interface>> CharSource getnextchar() endofsequence() CharSource Class notation Lollypop 2017, T. S. Norvell, A. Vardy 27 / 34

Realization TestCharInput Classes specialize classes, but realize interfaces. Similar concept, similar notation. (Note dashes) Choice of notations. Diagrams at right are equivalent. <<interface>> CharSource getnextchar() endofsequence() TestCharInput CharSource 2017, T. S. Norvell, A. Vardy 28 / 34

Generalization/Specialization and Realization in Java UML terminology C specializes D C realizes D Java terminology C extends D C implements D TestCharInput class TestCharInput extends TestInput implements CharSource { <<interface>> } CharSource TestInput 2017, T. S. Norvell, A. Vardy 29 / 34

Abstract operations An operation O is abstract in class C if it does not have an implementation in class C. The implementation of the operation will be filled in in specializations of C. abstract class TreeNode { abstract int height() ; } class Leaf extends TreeNode { int height() { return 1 ; } } class Branch extends TreeNode { int height(){return 1 + Math.max( l.height(), r.height() ; } } 2017, T. S. Norvell, A. Vardy 30 / 34

Abstract in Visual Paradigm (VP) In VP classes are made abstract with a checkbox in the specification. Leaf height() : int Branch height() : int Likewise for operations (class must be abstract first). Italics indicate abstractness TreeNode height() : int right 1 1 left 2017, T. S. Norvell, A. Vardy 31 / 34

Abstract and Concrete classes Classes that have abstract operations can not be instantiated --- since this would mean that there is no implementation associated with one of the object s operations Classes that can not be instantiated are called abstract classes. Classes that can be are called concrete In UML use the <<abstract>> stereotype for abstract classes and operations. Alternatively: The name of the abstract class or operation is in italics. 2017, T. S. Norvell, A. Vardy 32 / 34

Dependence Dependence is the weakest form of relationship A class C depends on class D if the implementation or interface of C even mentions D For example if C has an operation that has a parameter of type D local variable return type 2017, T. S. Norvell, A. Vardy 33 / 34

Dependence Dependence relations are important to note because unneeded dependence makes components... harder to reuse in another context harder to isolate for testing harder to write/understand/maintain, as the depended on classes must also be understood It is better to depend on an interface than on a class. More on this later... 2017, T. S. Norvell, A. Vardy 34 / 34