Object Oriented Analysis and Design Using the UML

Slides:



Advertisements
Similar presentations
Use Case Diagrams.
Advertisements

Informática II Prof. Dr. Gustavo Patiño MJ
Unified Modeling Language
Informática II Prof. Dr. Gustavo Patiño MJ
UML Class Diagram. UML Class Diagrams2 Agenda What is a Class Diagram? Essential Elements of a UML Class Diagram Tips.
2008/03/25 Unified Modeling Lanauage 1 Introduction to Unified Modeling Language (UML) – Part One Ku-Yaw Chang Assistant Professor.
Object-Oriented Analysis and Design
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Object Oriented Analysis and Design Using the UML
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 
Unified Modeling Language (UML)
Class Diagram & Object Diagram
Page 1  Copyright © 1997 by Rational Software Corporation Class Diagrams A class diagram shows the existence of classes and their relationships in the.
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
© Copyright Eliyahu Brutman Programming Techniques Course.
UML Class Diagrams: Basic Concepts. Objects –The purpose of class modeling is to describe objects. –An object is a concept, abstraction or thing that.
Unified Modeling Language
OOAD Using the UML - Introduction to Object Orientation, v 4.2 Copyright  Rational Software, all rights reserved 1 Object Oriented Analysis.
UML Unified Modeling Language. What is UML? Unified Modeling Language (UML) is a standardized, general-purpose modeling language in the field of software.
Object Oriented Analysis and Design Using the UML Version 4.2 Introduction to Object Orientation Prepared by:Kandarp R. Somaiya.
Page 1 What is the UML? UML stands for Unified Modeling Language The UML combines the best of the best from – Data Modeling concepts (Entity Relationship.
Object-OrientedMethodologies
3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 3, Slide 1 February 20, 2004 Lecture 3: Introduction to Software Analysis and.
UML Diagrams: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Page 1  Copyright © 1997 by Rational Software Corporation Computer System Business Process Order Item Ship via “ Modeling captures essential parts of.
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
Unified Modelling Language UML. Use case Diagram : A use case diagram is “a diagram that shows the relationships among actors and use cases within a system.use.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 02. Objects,
ניתוח מערכות מידע 1 Unified Modeling Language (UML) § § The Unified Modeling Language (UML) is the industry-standard language for: Specifying, Visualizing,
® 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.
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.
EC-241 Object-Oriented Programming LECTURE 9. Objectives: Introduction to Object Oriented Design Revise the basic principles of object orientation Unified.
BCS 2143 Object Oriented Design Using UML. Objectives Objects Interactions Finding Classes Relationship Between Classes Attribute and Operation Class.
Object Oriented Analysis & Design Using UML (CS-512) M-Tech CSE (Ist & 3rd Sem) Part Time Mr. Pawan Luthra Assistant Professor (CSE Deptt.) SBSSTC, Ferozepur.
1 The Unified Modeling Language. 2 The Unified Modeling Language (UML) is a standard language for writing software blueprints. The UML may be used to.
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,
Design Model Lecture p6 T120B pavasario sem.
 Week08.  Review Schedule Weeks 8-14  This week o Review last class o Introduce Class Diagrams o ICE-03 Sheridan SYST Engineering Quality Systems.
Use Case Diagrams.
OOAD Using the UML - Introduction to Object Orientation, v 4.2 Copyright  Rational Software, all rights reserved 1 Object Oriented Analysis.
 Building Block Building Block  Things in the UML Things in the UML  Structural Things Structural Things  Behavioral Things Behavioral Things  Grouping.
Page 1  Copyright © 1997 by Rational Software Corporation Putting the UML to Work The ESU University wants to computerize their registration system –
Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A.
بسم الله الرحمن الرحيم اللهم صلي علي احمد السجايا محمد الخصال شفيع البرايا سليم النوايا صادق الاقوال.
1 IBM Software Group ® Essentials of Visual Modeling with UML 2.0 Module 3: Concepts of Object Orientation.
Didik Dwi h t t p : / / b l o g. e l e k t r o. u m. a c. i d / d i d i k Object Oriented Software Engineering.
Object Modeling THETOPPERSWAY.COM. Object Modelling Technique(OMT)  Building a model of an application domain and then adding implementation.
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.
UML Fundamental Elements. Structural Elements Represent abstractions in our system. Elements that encapsulate the system's set of behaviors. Structural.
Unified Modeling Language. What is UML? Standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems,
2-1 © Prentice Hall, 2004 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
UML Diagrams: Class Diagrams The Static Analysis Model
UML Diagrams By Daniel Damaris Novarianto S..
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Object-Oriented Analysis and Design
Concepts of Object Orientation
Use case Diagram.
Review By: Reham Lotfi.
UML SEQUENCE AND CLASS DIAGRAMS
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
Software Architecture & Design Pattern
UML Class Diagrams: Basic Concepts
Object Oriented Analysis and Design Using the UML
The Unified Modeling Language
Software Engineering Lecture #11.
Object Oriented Analysis and Design Using the UML
Understand and Use Object Oriented Methods
Presentation transcript:

Object Oriented Analysis and Design Using the UML

Basic Concepts of Object Orientation Class Attribute Operation Interface (Polymorphism) Component Package Subsystem Relationships

What is an Object? Informally, an object represents an entity, either physical, conceptual, or software Physical entity Conceptual entity Software entity Truck Chemical Process Linked List

A More Formal Definition An object is a concept or thing with sharp boundaries and meaning for an application An object is something that has: State Behavior Identity

Representing Objects An object is represented as rectangles with underlined names Professor :Professor LAL Class Name Only Object Name Only

OO Principle: Abstraction What is a Class? A class has been called a “cookie cutter” for objects. A class is a description of a group of objects with same properties (attributes), behavior (operations), relationships, and semantics An object is an instance of a class OO Principle: Abstraction

Sample Class Class Course Properties Name Location Days offered Credit hours Start time End time Behavior Add a student Delete a student Get course roster Determine if it is full a + b = 10

Representing Classes A class is represented using a compartmented rectangle a + b = 10 Professor Professor Simran

Class Compartments A class is comprised of three sections The first section contains the class name The second section shows the structure (attributes) The third section shows the behavior (operations) In Rose: You may select which compartments are displayed via Diagram Object Properties for the diagram element. You may select which items appear in which compartments using the Edit Compartment function for the diagram element. Professor name empID create( ) save( ) delete( ) change( ) Class Name Attributes Operations

What is an Attribute? :CourseOffering CourseOffering :CourseOffering Object Class Attribute Attribute Value :CourseOffering number = 101 startTime = 900 endTime = 1100 CourseOffering number startTime endTime :CourseOffering number = 104 startTime = 1300 endTime = 1500

What is an Operation? CourseOffering Class Operation addStudent deleteStudent getStartTime getEndTime Class Operation

OO Principle: Modularity What is a Package? A package is a general purpose mechanism for organizing elements into groups A model element which can contain other model elements Package is rendered as a tabbed folder including name and sometimes, its contents. OO Principle: Modularity Package Name

Basic Concepts of Object Orientation Class Attribute Operation Interface (Polymorphism) Component Package Subsystem Relationships

Relationships Association Dependency Generalization Aggregation Composition Dependency Generalization Don’t cover the details of the graphic on this slide. The semantics of each of the relationships will be discussed later.

Relationships: Association Models a semantic connection among classes Associations connect instances of two or more classes together for some duration (as opposed to a dependency relationship, which represents a temporary association between two instances). Dependency relationships will be discussed in the Class Design module. Do not use relationship/role names if they add no value/information to the model. Remember, readability and understandability of the model are key -- only add information that adds value, not clutter to the diagrams. Professor University Works for Class Association Association Name Role Names University Professor Employee Employer

Association Association represents binary relationship between classes * enroll * Student Course advisee * * teach 1 1 Faculty adviser

Relationships: Aggregation A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts There are many examples of whole-part relationships: a Library contains Books, within a company Departments are made-up of Employees, a Computer is composed of a number of Devices. However, whether you model a relationship as an association or aggregation is really dependent on the domain being modeled. This is discussed in more detail on a later slide. Whole Part Schedule Student Aggregation

Aggregation and Compositon Aggregation is a special form of association Has-a or part-whole relationship Composition is a stronger form of aggregation

A form of aggregation with strong ownership and coincident lifetimes The parts cannot survive the whole/aggregate Explain to the students that the diamond on this slide must be filled in with black so that the books would print right. If it was filled in with white, it would not be filled in in the books. Note: Compositional aggregation can be shown in by nesting one class within another; however, Rose does not directly support the drawing of a class within a class. Composition is not equivalent to containment by value, as some languages do not support containment by value (e.g., Java). By-value vs. by-reference is an implementation “thing”, whereas composition is a conceptual “thing” that can realized in the implementation using by-value, or by-reference (if the distinction is supported). Note: In Rose, composition is modeled by specifying “by-value” for the containment property of a role of a relationship. Whole Part Schedule Student Aggregation

Association: Multiplicity and Navigation Multiplicity defines how many objects participate in a relationships The number of instances of one class related to ONE instance of the other class Specified for each end of the association Associations and aggregations are bi-directional by default, but it is often desirable to restrict navigation to one direction If navigation is restricted, an arrowhead is added to indicate the direction of the navigation

Association: Multiplicity Specification of multiplicity flushes out business rules and assumptions. The lower bound is critical, as the lower bound is what determines whether or not the relationship is optional (e.g., a lower bound of 0 indicates that the relationship is optional). Multiplicity is needed on both ends of a relationship, even if you can only navigate in one direction. Even though there is no need to navigate in that direction, the multiplicity still provides valuable business information. Sometimes navigation decisions are made for performance reasons, which may change over time. The multiplicity should reflect the requirements. Navigation is discussed on later slides. The use of ‘N’ instead of ‘*’ is Booch, not UML (e.g., the use of “0..N” and ‘N’ is not UML). Unspecified Exactly one Zero or more (many, unlimited) One or more Zero or one Specified range Multiple, disjoint ranges 1 0..* 1..* 0..1 2..4 2, 4..6

Example: Multiplicity and Navigation Schedule Student 1 0..* Navigation

Example 1 1 1 * * * 1 1 Chairman-of Member-of 1 1..* University College Department Student 1 1 Chairman-of Member-of 1 1..* Faculty

Relationships: Dependency A relationship between two model elements where a change in one may cause a change in the other. Client Supplier Component Class Package Client Supplier Dependency relationship ClientPackage SupplierPackage Dependency relationship

Dependency is a relationship between entities such that the proper operation of one entity depends on the presence of the other entity, and changes in one entity would affect the other entity.

Relationships: Generalization Generalization relationships are also permitted between packages. However, since packages do not themselves have any semantics, generalization between packages is not very common (generalization amongst subsystems, however, is practical). According to Grady Booch: “The terms “inheritance” and “generalization” are, practically speaking, interchangeable. The UML standardized on calling the relationship “generalization” so as not to confuse people with language-specific meanings of inheritance. To confuse matters further, some call this an “is-a” or a “kind of” relationship (especially those into conceptual modeling in the cognitive sciences). So, for most users, it’s fair to use either term. For power users - people who care about things like the UML metamodel and specifying formal semantics of the same, the relationship is called “generalization” and applying such a relationship between, for example, two classes, results in the subclass inheriting the structure and operations of the superclass (i.e. inheritance is the mechanism). A relationship between superclass and subclass. Defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses. Single inheritance Multiple inheritance Generalization is an “is-a-kind of” relationship

Example: Single Inheritance One class inherits from another Ancestor Account balance name number Withdraw() CreateStatement() Checking Savings GetInterest() Superclass (parent) Generalization Relationship Subclasses Descendents

Example: Multiple Inheritance A class can inherit from several other classes FlyingThing Animal multiple inheritance Airplane Helicopter Bird Wolf Horse Use multiple inheritance only when needed, and always with caution !

Example: What Gets Inherited Ask the class the following to test their understanding: “Without looking at your notes: How many operations does Car have? Answer: 1 How may relationships? Answer: 1 How many operations does Truck have? Answer: 2 How may relationships? Answer: 2” Generalization provides a way to implement polymorphism in cases where polymorphism is implemented the same way for a set of classes. The use of generalization to support polymorphism is discussed in more detail in the Class Design module GroundVehicle Person owner Superclass (parent) weight licenseNumber 0..* 1 register( ) generalization Truck Trailer Car Subclass size tonnage getTax( )

UML Unified Modeling Language

What is UML? UML is a language for Visualizing Specifying Constructing Documenting

Building Blocks of UML Things -- abstraction Relations -- tie things together Diagrams -- group interesting collections of things

Class diagrams Object diagrams Component diagrams Deployment diagrams To view the static parts of a system using one of four following diagrams: Class diagrams To represent classes and interfaces Object diagrams To represent Objects Component diagrams To represent different components Deployment diagrams To represent different nodes of the system

Collaboration Diagrams To view the dynamic parts of a system using one of five following diagrams: Use Case Diagrams Organizes the behavior of the system Sequence Diagrams Focused on the time ordering of messages Collaboration Diagrams Focused on the structural organization of objects that send and receive messages State Chart Diagrams Focused on the changing state of the system driven by events Activity Diagrams Focused on the flow of control from activity to activity

Use Case Diagrams

It models dynamic aspects of system. Shows set of use cases ,actors and their relationships. Contents Use cases Actors relationships

Use Case Diagrams Use Case diagrams show the various activities the users can perform on the system. They model the dynamic aspects of the system.

Use Case Diagrams A set of ACTORS : roles users can play in interacting with the system. An actor is used to represent something that users our system. A set of USE CASES: each describes a possible kind of interaction between an actor and the system. Uses cases are actions that a user takes on a system A number of RELATIONSHIPS between these entities (Actors and Use Cases). Relationships are simply illustrated with a line connecting actors to use cases.

Use Case Diagrams - Actors An actor is a user of the system playing a particular role. Actor is shown with a stick figure. employer employee client

Use Case Diagrams – Use Cases Use case is a particular activity a user can do on the system. Is represented by an ellipse. Following are two use cases for a library system. Borrow Reserve

Use Case Diagram for Student Assessment Management System Grade system Record grades Student View grades Teacher Distribute Report cards Create report cards Printing administrator

University Record System (URS) A University record system should keep information about its students and academic staff. Records for all university members are to include their id number, surname, given name, email, address, date of birth, and telephone number. Students and academic staff each have their own unique ID number: studN (students), acadN (academic employee), where N is an integer (N>0). In addition to the attributes mentioned above: Students will also have a list of subjects they are enrolled in. A student cannot be enrolled in any more than 10 subjects. Academic employees will have a salary, and a list of subjects they teach. An academic can teach no more than 3 subjects.

Some Actions Supported by URS The system should be able to handle the following commands. Add and remove university members (students, and academic staff) Add and Delete subjects Assign and Un-assign subjects to students Assign and Un-assign subjects to academic staff.

Use Case Diagram - URS System add member del member system user academic add subject del subject assg subject unass subject student enrol subject unenrol subject