DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Slides:



Advertisements
Similar presentations
UML Class Diagram. UML Class Diagrams2 Agenda What is a Class Diagram? Essential Elements of a UML Class Diagram Tips.
Advertisements

2008/03/25 Unified Modeling Lanauage 1 Introduction to Unified Modeling Language (UML) – Part One Ku-Yaw Chang Assistant Professor.
UML – Class Diagrams.
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 
Class Diagram & Object Diagram
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
7M822 UML Class Diagrams advanced concepts 15 September 2008.
UML Class Diagrams: Basic Concepts. Objects –The purpose of class modeling is to describe objects. –An object is a concept, abstraction or thing that.
Object-Oriented Analysis and Design
ECE 355: Software Engineering
Uml is made similar by the presence of four common mechanisms that apply consistently throughout the language. After constructing or developing the architecture.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Databases : Data Modeling 2007, Fall Pusan National University Ki-Joune Li.
Unit 1 INTRODUCTION TO MODELING AND CLASS MODEL Ref : L7-UML.PDF.
Unified Modeling Language © 2002 by Dietrich and Urban1 ADVANCED DATABASE CONCEPTS Unified Modeling Language Susan D. Urban and Suzanne W. Dietrich Department.
Chapter 16 Applying UML and Patterns Craig Larman
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 03. Classes,
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.
Lecture 1: UML Class Diagram September 12, UML Class Diagrams2 What is a Class Diagram? A class diagram describes the types of objects in the system.
Class Diagram. Classes Software Design (UML) Class Name attributes operations A class is a description of a set of objects that share the same attributes,
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.
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.
1 Class Diagrams. 2 Overview Class diagrams are the most commonly used diagrams in UML. Class diagrams are for visualizing, specifying and documenting.
Ch- 8. Class Diagrams Class diagrams are the most common diagram found in modeling object- oriented systems. Class diagrams are important not only for.
Software Engineering Lecture 8 Object-Oriented Analysis.
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.
CS212: Object Oriented Analysis and Design Lecture 33: Class and Sequence Diagram.
Chapter 16 UML Class Diagrams 1CS6359 Fall 2012 John Cole.
Chapter 3: Introducing the UML
ITEC0724 Modern Related Technology on Mobile Devices Lecture Notes #2 1.
Class Diagram Lecture # 1. Class diagram A Class Diagram is a diagram describing the structure of a system shows the system's classes Attributes operations.
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
UML Fundamental Elements. Structural Elements Represent abstractions in our system. Elements that encapsulate the system's set of behaviors. Structural.
ITEC1301 Object-Oriented Systems Construction Lecture Notes #4 1.
Modeling with UML – Class Diagrams
UML Chapter 17.
CHAPTER
UML Diagrams: Class Diagrams The Static Analysis Model
UML-Class Diagrams. UML-Class Diagrams Order placement problem A Company has two types of customers, corporate customers and personal customers. All.
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Object-Oriented Analysis and Design
Unified Modeling Language
UML Class & Object Diagram II
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
Introduction to UML Introduction to UML Shiyuan Jin September,23,2002
UML Class Diagrams: Basic Concepts
Interactions.
Object Oriented Analysis and Design
The Unified Modeling Language
Seminar 3 UML Class Diagram.
Lec 3: Object-Oriented Data Modeling
Software Engineering Lecture #11.
UML Class Diagram.
Use Cases.
UNIT – V.
CIS 375 Bruce R. Maxim UM-Dearborn
Analysis models and design models
Class Diagrams.
Copyright 2007 Oxford Consulting, Ltd
Class Diagrams Class diagram is basically a graphical representation of the static view of the system and represents different aspects of the application.
Chapter 22 Object-Oriented Systems Analysis and Design and UML
CIS 375 Bruce R. Maxim UM-Dearborn
Object Oriented System Design Class Diagrams
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.
Class Diagram and Composite Structure Diagram P. P. Mahale
Presentation transcript:

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING (2016-17) OBJECT ORIENTED ANALYSIS AND DESIGN III B. Tech II Sem UNIT-2

What is classifier? A classifier is a mechanism that describes structural and behavioral features. In general, the modeling elements that can have instances are called classifiers. Class, Instance, Data type, Signal, Component, Node, Use case, Subsystem are classifiers. (packages are not.)

Advanced classes

Classifier Description A classifier is a mechanism that has structural features (in the form of attributes), as well as behavioral features (in the form of operations). Classifiers include classes, interfaces, data types, signals, components, nodes, use cases, and subsystems. Those modeling elements that can have instances are called classifiers. Every instance of a given classifier shares the same features. The most important kind of classifier in UML is class. The other kinds of classifiers are given in following figure:

Classifier Description(continued…)

Classifier Description(continued…)

Special properties of attributes and operations Visibility Public[+]: any outside classifier with visibility to the given classifier can use this feature. Protected[#]: any descendant of the classifier can use the feature. Private[-]: only the classifier itself can use the feature.

Special properties of attributes and operations Scope The owner scope of a feature specifies whether the feature appears in each instance of the classifier or whether there is just a single instance of feature for all instances of the classifier. instance : each instance holds its own value. classifier : just one value for all instances. [static]

Abstract, Root, Leaf and Polymorphic Elements

Multiplicity It’s reasonable to assume that there may be any number of instances of classes. The number of instances a class may have is called multiplicity.

Attributes The syntax of an attribute in the UML is: [ visibility ] name [ multiplicity ] [ : type ] [ = initial- value ] [ { property- There are three defined properties changeable : no restrictions on modifying the attribute’s value addOnly : additional value may be added for attributes with a multiplicity > 1, but once created, a value may not be removed or altered. frozen : the attribute’s value may not be changed after object is initialized. [const] string} ]

Operations There are five defined properties The syntax of an operation in UML is: [ visibility ] name [ ( parameter-list ) ] [ : return-type ] [ { property-string } ] [ direction ] name : type [ = default-value ] in, out, inout : means parameter may be modified or n There are five defined properties leaf : may not be overridden <page 7> isQuery : leave the state of subsystem unchanged. sequential : only one flow is in the object at a time. guarded : sequential zing all calls. concurrent : treating the operation as atomic. 3. 4. 5. are for concurrence.

Template class Like template classes in C++ and Ada. Cannot use a template directly; you have to instantiate it first.

What is Relationship A relationship is a connection among things. There are four most important relationships in object-oriented modeling: Dependencies Generalizations Associations Realizations

Dependency Specifying a change in the specification of one thing may affect another thing, but not necessarily the reverse. Rendering as a dashed line [ ] UML defines a number of stereotypes. There are eight stereotypes that apply to dependency relationships among classes and objects in class diagrams.

Dependency

Dependency Two stereotypes that apply to dependency relationships among packages. access – source package is granted the right to reference the elements of the target package. import – a kind of access, but only public content. Two stereotypes that apply to dependency relationships among use case. extend – target use case extends the behavior of source. include – source use case explicitly incorporates the behavior of another use case at a location specified by the source

Dependency Three stereotypes when modeling interactions among objects. become – target is the same object of source at later time call – source operation invoke the target operation copy – target is an exact, but different, copy of source In the context of state machine send – source operation sends the target event In the context of organizing the elements of your system into subsystem and model trace – target is an historical ancestor of the source (model relationship among elements in different models)

Generalization A generalization is a relationship between a general thing and a more specific kind of that thing.

Association An association is a structural relationship, specifying that objects of one thing are connected to object of another. Basic adornments: name, role, multiplicity, aggregation. Advanced adornments: navigation, qualification, various flavors of aggregation

Association Navigation : adorning an association with an arrowhead pointing to the direction of traversal. Visibility : objects at that end are not accessible to any objects outside the association.

Association Qualification : A form of aggregation with strong ownership and coincident lifetime of the parts by the whole. Interface specifier : An interface is a collection of operations that are used to specify a service of a class or a component; every class may realize many interfaces.

Association Composition: In a composite aggregation, an object may be a part of only one composite at a time. For example, in a windowing system, a Frame belongs to exactly one Window. In a composite aggregation, the whole is responsible for the disposition of its parts, which means that the composite must manage the creation and destruction of its parts. For example, when you create a Frame in a windowing system, you must attach it to an enclosing Window. Similarly, when you destroy the Window, the Window object must in turn destroy its Frame parts.

Association Constraints implicit: The relationship is not manifest but, rather, is only conceptual. ordered: the set of objects at one end of an association are in an explicit order. changeable: links between objects may be changed. add Only: new links may be added from an object on the opposite end of association. frozen: a link added may not be modified or deleted. Xor: over a set of associations, exactly one is man fest for each associated object.

Realization A realization is a semantic relationship between classifiers in which one classifier specifies a contract that anther classifier guarantees to carry out. Use in two circumstances: In the context of interfaces. In the context of collaborations. Rendering as:

Interfaces types and Roles An interface is a collection of operations that are used to specify a service of a class or a component. Graphically, an interface is rendered (represented) as a circle; in its expanded form, an interface may be rendered as a stereotyped class(a class with stereotype interface) Two naming mechanism: A simple name (only name of the interface). A path name is the interface name prefixed by the name of the package in which that interface lives represented.

Interfaces types and Roles To distinguish an interface from a class, prepend an ‘I’ to every interface name. Operations in an interface may be adorned with visibility properties, concurrency properties, stereotypes, tagged values, and constraints. Interface don't have attributes. interfaces span model boundaries and it doesn't have direct instances.

Interface Relationships An interface may participate in generalization, association, dependency and realization relationships. Interfaces may also be used to specify a contract for a use case or subsystem. Type: A type is a stereotype of a class used to specify a domain of objects, together with the operations (but not the methods) applicable to the object of that type. Roles: A role names (indicates) a behavior of an entity participating in a particular context. Or, a role is the face that an abstraction presents to the world.

Class Diagram The class diagram is a static diagram. It represents the static view of an application. Class diagram is not only used for visualizing, describing and documenting different aspects of a system but also for constructing executable code of the software application. The class diagram describes the attributes and operations of a class and also the constraints imposed on the system. The class diagrams are widely used in the modelling of object oriented systems because they are the only UML diagrams which can be mapped directly with object oriented languages. The class diagram shows a collection of classes, interfaces, associations, collaborations and constraints. It is also known as a structural diagram.

Points for drawing a class diagram The name of the class diagram should be meaningful to describe the aspect of the system. Each element and their relationships should be identified in advance. Responsibility (attributes and methods) of each class should be clearly identified.

Class Diagram * class * * * Multiplicity: mandatory 1 Association Name class Order Multiplicity: mandatory Attributes -dateReceived -isPrepaid * Customer 1 -number :String -name -price : Money -address +dispatch() Association Operations +creditRating() : String() +close() 1 {if Order.customer.creditRating is Generalization "poor", then Order.isPrepaid must be true } Corporate Customer Personal Customer Constraint (inside braces{}} -contactName -creditCard# -creditRating Multiplicity: Many value -creditLimit +remind() +billForMonth(Integer) Multiplicity: optional 0..1 * Employee * OrderLine -quantity: Integer * 1 Product -price: Money -isSatisfied: Boolean

Object diagrams They can be described an instance of class diagram. Object diagrams represent an instance of a class diagram They are more close to real life scenarios. They are a set of objects and their relationships just like class diagrams and also represent the static view of the system. The usage of object diagrams is similar to class diagrams but they are used to build prototype of a system from practical perspective Object diagrams are derived from class diagrams so object diagrams are dependent upon class diagrams.

Object diagrams Forward and reverse engineering. Object relationships of a system Static view of an interaction. Understand object behavior and their relationship from practical perspective Object diagrams are consist of objects. The link in object diagram is used to connect objects. Objects and links are the two elements used to construct an object diagram