Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Coming up: Introduction to Objects Objects,

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Advertisements

Analysis Modeling Static Modeling.
CS 340 UML Class Diagrams. A model is an abstraction of a system, specifying the modeled system from a certain viewpoint and at a certain level of abstraction.
UML Class Diagram. UML Class Diagrams2 Agenda What is a Class Diagram? Essential Elements of a UML Class Diagram Tips.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Slide 1 Systems Analysis & Design CS183 Spring Semester 2008 Dr. Jonathan Y. Clark Course Website:
What is UML? A modeling language standardized by the OMG (Object Management Group), and widely used in OO analysis and design A modeling language is a.
7M701 1 Class Diagram advanced concepts. 7M701 2 Characteristics of Object Oriented Design (OOD) objectData and operations (functions) are combined 
Data and Process Modeling
1 Object-Oriented Modeling Using UML CS 3331 Fall 2009.
PRJ566: PROJECT PLANNING AND MANAGEMENT Class Diagrams.
UML Class Diagrams: Basic Concepts. Objects –The purpose of class modeling is to describe objects. –An object is a concept, abstraction or thing that.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Coming up: Class Syntax Basic Class Diagrams.
Unified Modeling Language
Object-Oriented Analysis and Design
Chapter 9 Domain Models. Domain Model in UML Class Diagram Notation A “visual dictionary”
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.
1 A Student Guide to Object- Orientated Systems Chapter 4 Objects and Classes: the basic concepts.
OBJECT AND CLASES: THE BASIC CONCEPTS Pertemuan 8 Matakuliah: Konsep object-oriented Tahun: 2009.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Coming up: Class Syntax Basic Class Diagrams.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Coming up: Class Syntax Basic Class Diagrams.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Objects, Classes, and Basic Class Diagrams.
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.
5 Systems Analysis and Design in a Changing World, Fourth Edition.
UML Diagrams: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Use Cases CS/SWE 421 Introduction to Software.
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 4 - Domain Classes.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Unit 3 Conceptual Data Modeling. Key Concepts Conceptual data modeling process Classes and objects Attributes Identifiers, candidate keys, and primary.
Today in OOAD  The Domain Model Artifact UML Classes  EU-Bid Domain Model Exercise  EU-Lease Domain Model Assignment Guest Speaker  Kate Cunningham,
Unified Modeling Language © 2002 by Dietrich and Urban1 ADVANCED DATABASE CONCEPTS Unified Modeling Language Susan D. Urban and Suzanne W. Dietrich Department.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 03. Classes,
The Static Analysis Model Class Diagrams Prof. Hany H. Ammar, CSEE, WVU, and Dept. of Computer Science, Faculty of Computers and Information, Cairo University.
Fall 2010 CS4310 Requirements Engineering A Brief Review of UML & OO Dr. Guoqiang Hu Department of Computer Science UTEP 1.
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.
UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University
What is a Structural Model?
Class Diagram Classes are the most important building block of any object-oriented system. A class is a description of a set of objects that share the.
Design Model Lecture p6 T120B pavasario sem.
Relationships Relationships between objects and between classes.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
1 Class Diagrams. 2 Overview Class diagrams are the most commonly used diagrams in UML. Class diagrams are for visualizing, specifying and documenting.
Domain Classes – Part 1.  Analyze Requirements as per Use Case Model  Domain Model (Conceptual Class Diagram)  Interaction (Sequence) Diagrams  System.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Use Cases CS/SWE 421 Introduction to Software.
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.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Coming up: Unified Modeling Language Introduction.
Object Modeling THETOPPERSWAY.COM. Object Modelling Technique(OMT)  Building a model of an application domain and then adding implementation.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Coming up: Unified Modeling Language Introduction.
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Introduction to the Unified Modeling Language.
UML Diagrams: Class Diagrams The Static Analysis Model
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Object-Oriented Analysis and Design
Introduction to the Unified Modeling Language
Unified Modeling Language
OO Domain Modeling With UML Class Diagrams and CRC Cards
Today’s Objectives Define the Problem Domain
UML Unified Modelling Language
Object Oriented Analysis and Design
Introduction to the Unified Modeling Language
Introduction to the Unified Modeling Language
Objects, Classes, and Basic Class Diagrams
Objects, Classes, and Basic Class Diagrams
Class Diagrams Class diagram is basically a graphical representation of the static view of the system and represents different aspects of the application.
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.
Presentation transcript:

Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Coming up: Introduction to Objects Objects, Classes, and Basic Class Diagrams CS/SWE 421 Introduction to Software Engineering Dan Fleck (Slides adapted from Dr. Stephen Clyde with permission)

Coming up: Introduction to Objects Introduction to Objects n Objects are the fundamental building blocks of object-oriented systems n What is an object? –It represents any “thing” –It has a boundary in space and time –It is an abstraction –It encapsulates state and/or behavior –It has identity

Coming up: Exercise - Object Hunt Introduction to Objects n What aren’t objects? –Events (sometimes) –Relationships between objects (most of the time) –Behavior (most of the time) –Constraints (most of the time)

Coming up: Introduction to Classes Exercise - Object Hunt n Part 1 - List examples of objects in the Third National Bank Elevator System n Part 2 - List some concepts from this system that would not typically be modeled as objects

Coming up: Three Perspectives Introduction to Classes n Classes are abstractions that allow us to deal with whole collections of objects that share some commonalties n Examples of classes in a Student Records Management System Student Course Class Section Instructor Class Grade Major Department College Semester

Coming up: Classes from different Perspectives Three Perspectives n Objects and classes, as well as all other modeling components in UML, can be interpreted from different perspectives: n Three common perspectives: –Analysis - description of the problem domain –Specification - logical description of software system –Implementation - description of software components and their deployment

Coming up: Class Syntax Classes from different Perspectives n Meaning from three perspectives –Analysis: sets of objects –Specifications: interfaces to encapsulated software representations of objects –Implementations: abstract data types Student AnalysisSpecification Student {Joe, Sue, Mary, Frank, Tim, …} Interface Student {…} Implementation class Student {…} Student

Coming up: Class Names Class Syntax n A box divided into compartments –Name –Attributes –Operations –Responsibilities –Used-defined compartments Student major: String gpa: Real standing: String add(Class Section) drop(Class Section) -- The set of students known to the registration system -- An exception occurs if gpa falls below 2.0

Coming up: Class Name Syntax Class Names n The name should be a noun or noun phrase n The name should be singular and description of each object in the class n The name should be meaningful from a problem-domain perspective –“Student” is better than “Student Data” or “S-record” or any other implementation driven name n Avoid jargon in the names n Try to make the name descriptive of the class’s common properties

Coming up: Return to Objects – Object Syntax Exercise – Class Identification n Identify meaningful classes in the Elevator System

Coming up: Object Name Syntax Return to Objects – Object Syntax n Object syntax is similar to class syntax, except –the name identifies specific or generic object –the name includes the class that the object belongs to n Remember, individual objects are instances of classes joe: Student major: String = “CS” gpa: Real = 4.0 standing: String = “” add(Class Section) drop(Class Section)

Coming up: Attributes from an Analysis Perspective Attributes n Attributes represent characteristics or properties of objects n They are place holders or slots that hold values n The values they hold are other objects n The name of an attribute communicates its meaning n An attribute can be defined for individual objects or classes of objects –If defined for a class, then every object in the class has that attribute (place holder)

Coming up: Attributes from a Specification Perspective Attributes from an Analysis Perspective n An attribute relates an object to some other object n It has the same semantics as an association joe: Student name: String = “Joe Jones” joe: Student Joe Jones : String Is basically the same as... name 1

Coming up: Attributes from an Implementation Perspective Attributes from a Specification Perspective n An attribute represents an obligation to provide or manage a certain (single) piece of information Student major: String gpa: Real standing: String n For example, each Student object must be able to encapsulate a major, a GPA, and a standing

Coming up: Attribute Syntax Attributes from an Implementation Perspective n Attributes from an implementation perspective are similar data members in C++ or Java n They are place holders with value semantics n Each object can have different values n Constraints can be placed on the attributes to restrict how and when the values can be changed

Coming up: Exercise – Attributes Attribute Syntax visibility: public “+”, protected “#”, or private “-” name: capitalize first letter of each word that makes up the name, except for the first multiplicity: number, range, or sequence of number or ranges. type: build-in type or any user-defined class initial-value: any constant and user-defined object property-string: e.g, changeable, addOnly, frozen [visibility] name [multiplicity] [:type] [=initial-value] [{property-string}]

Coming up: Operations Exercise – Attributes n Describe meaningful attributes for the key classes in the Elevator System

Coming up: Operations Operations n Meaning from three perspectives –Analysis: Ways in which objects interaction –Specification: An obligation to provide a service –Implementation: A function member, a method

Coming up: Operation Syntax Operations Student major: String GPA: Real standing: String add(Class Section) drop(Class Section) Class Section name: String capacity: Integer add(Student) drop(Student) checkPrerequisites(Students) Prerequisite <has takes> Course

Coming up: Type of Relationships in Class Diagrams Operation Syntax visibility: “+”, “#”, “-” name: verb or verb phase, capitalize first letter of every word, except first parameter-list: coma separated list of parameters return-type: primitive type or user-defined type property-string: isQuery, sequential, guarded, concurrent [visibility] name [(parameter-list)] [:return- type] [{property-strong}]

Coming up: Associations Type of Relationships in Class Diagrams Relation A consolidated snippet of the UML Meta-model Association Generalization Dependency Aggregation Binary AssociationN-ary Association

Coming up: Associations Associations n An association is a structural relationship that specifies that objects of class may be connected to objects of another class n Meaning from three perspectives –Analysis: Links between objects –Specification: Obligation to provide a connection between objects –Implementation: Object pointers, references, linking structures, etc.

Coming up: Association Names Associations Student Class Section Course Semester Instructor Department takes> is registered for> teaches> sponsors> <works for is instance of> is held during>

Coming up: Navigation Association Names n Associations may be named –The names should communicate the meaning of the links –The names are typically verb phases –The name should include an arrow indicating the direction in which the name should be read

Coming up: Navigation Navigation n The navigation of associations can be –uni-directional –bi-directional –unspecified Class Section Course Instructor Department teaches> sponsors> <works for is instance of>

Coming up: N-ary Associations Navigation n The navigation of association without an arrowhead is assumed to be undefined n Navigation has little value when modeling from a conceptual perspective –Why? n Navigation is more important from specification and implementation perspectives –Why?

Coming up: Generalization N-ary Associations n Associations can connect more than one class n Notation: n How should we go about naming an n-ary association? StudentAdvisor Major

Coming up: Generalization Generalization n Generalization is another kind of relationship in UML – see Meta Model n From an analysis perspective, it is a pure generalization/specialization concept, i.e., the specialization is a subset of the generalization StudentPerson Graduate Student

Coming up: Generalization Generalization n From a specification/implementation perspective, generalization can represent sub- typing, inheritance, type capability, and substitutability (depends on the language) Student major: String GPA: Real standing: String add(Class Section) drop(Class Section) Person name: String address: String changeAddress(new_address)

Coming up: Class Diagrams Exercise – Simple Associations n From an analysis perspective: –Identify meaningful associations and generalization/specializations among classes in the Elevator System

Coming up: Class Diagrams Class Diagrams n Class Diagrams describe –the types of objects in a system –their properties (attributes and operations) –relationships between objects n They can also include –Grouping concepts like packages –Constraints –Various kinds of annotations

Coming up: Class Diagrams Class Diagrams n Class Diagrams are like the paragraphs of a technical paper –each diagram should focus on a specific topic –a diagram provides supporting detail for the main concept(s) that it is trying to communicate –the level of the abstraction used in the diagrams should be consistent n Together, all the diagrams for a system comprise a “model” of that system

Coming up: Multiplicity Constraints Class Diagrams n Pitfalls of Class Diagrams: –Using class diagrams alone can cause developers to focus too much on structure and ignore behavior –Using the wrong (or a mixed) perspective can lead to misunderstanding –Using the wrong level of abstraction can be confusing to the target audience –Using mixed levels of abstraction can reduce the usefulness of diagram

Coming up: Multiplicity Constraints Multiplicity Constraints Student Class Section Course Semester Instructor Department takes> is registered for> teaches> sponsors> <works for is instance of> is held during> 1..* *

Questions n From the previous diagram –How many classes can a student take? –Do you have to be registered in any classes to be a student? –Do I need to teach this class to be an Instructor? Do I need to teach ANY classes?

Coming up: Dependencies Multiplicity Constraints n A multiplicity constraint can be –a single number –a “*”, meaning an arbitrarily large number or simply “many” –a range, denoted by “min..max” –a sequence of single numbers and ranges

Coming up: Dependencies Dependencies Relation A consolidated snippet of the UML Meta-model Association Generalization Dependency Aggregation Binary AssociationN-ary Association

Coming up: Dependencies Dependencies n A dependency is a type of relationship n It says that one modeling component “uses” another. n If the later changes then, the former may have to change as well Student add(Course) drop(Course) Prerequisite

Coming up: Dependencies Dependencies n Meaning from three perspectives –Analysis: physical or logical dependency between the connected classes –Specification: a “uses” relationship at an interface level –Implementation: a “uses” relationship at an implementation level. Just think: uses!

Coming up: Aggregations (is part of) Dependencies n Syntax: –a dashed link with an straight-line arrowhead point to a component on which there is a dependency n Dependencies can be defined among: classes, notes, packages, and other types of components n Can dependencies go both ways? n Any problems with having lots of dependencies?

Coming up: Aggregation Aggregations (is part of) Relation A consolidated snippet of the UML Meta-model Association Generalization Dependency Aggregation Binary AssociationN-ary Association

Coming up: Composition (very similar to aggregation) Aggregation n Aggregation: is a special kind of association that means “part of” n Aggregations should focus on single type of composition (physical, organization, etc.) 1 1 * 4..* Pizza Order Slice Crust Sauce Serving Cheese Serving Topping Serving

Coming up: Using a class diagram Composition (very similar to aggregation) n Think of composition as a stronger form of aggregation. Composition means something is a part of the whole, but cannot survive on it’s own. BuildingRoom

Lets look at BookstoreExample4.jpg n Does John McCain (who has 7 houses) have a problem using this system? n If Barack Obama decides to create a Federal sales tax, how would we change the system? n Why is there a display method in Item, Book, MusicCD and Software? n An ItemOrder is part of how many Orders? n Can you explain how a search works using this diagram?

Class Exercise n Lets create the WeGrow class diagram

Coming up: Questions Validating a class diagram n One of the most important, and often overlooked issues is how to validate a class diagram. (Usually best for an diagram at the implementation perspective) n Given a specification or a use-case, can you look at the class diagram and use attributes and methods to “execute” a use case? n Lets try it for the WeGrow class diagram

Coming up: More Questions Questions n What’s the difference between an attribute and an association with another class? For example, should “grade” be an attribute or a link to another class called “Grade”? n When during the software engineering life cycle should you build classes diagrams?

Coming up: More Questions More Questions n How does one decide how to break up the responsibilities of a system into meaningful classes? n How do you know if you have identified the best classes for a system? n How do you know where in a class hierarchy a particular attribute or operation bests fit?

Coming up: More Questions More Questions n How do you know when a class diagram is complete? n How can you manage change control on all the class diagrams for project? n What do you do with class diagrams after a system has been built and delivered?

Bonus Slide! n If you’re interested in Auto-generating UML, Netbeans has an option to do it. –Install the UML plugin –Right-click on a project –Choose “Reverse Engineer” –Go to the new UML project –Select a package and choose to generate a new UML diagram