May-June 2001 ISISTAN Research Institute – Tandil, Argentina Software Design Methodologies: UML in Action Dr. Mohamed Fayad, J.D. Edwards Professor Department.

Slides:



Advertisements
Similar presentations
Introduction to Object Orientation System Analysis and Design
Advertisements

Withdrawal Transaction Use Case Primary Actor: Customer Pre-conditions: The customer must have a valid ATM card and PIN. Post-conditions: The customer.
Use Case Diagrams Damian Gordon.
Use Case & Use Case Diagram
1 Object-oriented design Part 2: OO tools & UML. 2 CRC cards Design tool & method for discovering classes, responsibilities, & relationships Record on.
Use Case Modeling SJTU. Unified Modeling Language (UML) l Standardized notation for object-oriented development l Needs to be used with an analysis and.
SWE 214 (071) Use Case Diagrams Slide 1 Use Case Diagrams Examples.
May-June 2001 ISISTAN Research Institute – Tandil, Argentina Software Design Methodologies: UML in Action Dr. Mohamed Fayad, J.D. Edwards Professor Department.
Ch 12: Object-Oriented Analysis
CS3773 Software Engineering Lecture 03 UML Use Cases.
Information System Design IT60105
1 Classes. 2 Finding classes w Choosing classes is first step in defining essence of problem w If you can recognize an abstraction, you’ve found a candidate.
Lecture 9 Object-Oriented Analysis
Chapter 12 ATM Case Study, Part 1: Object-Oriented Design with the UML
Fall 2002 SJSU -- CmpE Enterprise & Application Frameworks Dr. M.E. Fayad, Professor Computer Engineering Department – RM# College of Engineering San José.
Interaction Diagrams Activity Diagram State Machine Diagram
L10-S1Object Identification SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department,
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5, Analysis: Dynamic Modeling.
May-June 2001 ISISTAN Research Institute – Tandil, Argentina Software Design Methodologies: UML in Action Dr. Mohamed Fayad, J.D. Edwards Professor Department.
May-June 2001 ISISTAN Research Institute – Tandil, Argentina Software Design Methodologies: UML in Action Dr. Mohamed Fayad, J.D. Edwards Professor Department.
May-June 2001 ISISTAN Research Institute – Tandil, Argentina Software Design Methodologies: UML in Action Dr. Mohamed Fayad, J.D. Edwards Professor Department.
Lecture 4 Class Responsibility Collaboration Cards
Object Oriented Analysis Process
May-June 2001 ISISTAN Research Institute – Tandil, Argentina Software Design Methodologies: UML in Action Dr. Mohamed Fayad, J.D. Edwards Professor Department.
May-June 2001 ISISTAN Research Institute – Tandil, Argentina Software Design Methodologies: UML in Action Dr. Mohamed Fayad, J.D. Edwards Professor Department.
May-June 2001 ISISTAN Research Institute – Tandil, Argentina Software Design Methodologies: UML in Action Dr. Mohamed Fayad, J.D. Edwards Professor Department.
© M.E. Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering.
L6-1-S1Design Heuristics - 1 © M.E. Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department,
Chapter 9 Domain Models 1CS6359 Fall 2012 John Cole.
Use Case Modeling. Use case diagram For each use case we develop  Object class diagram (with attributes only)  System sequence diagram (analysis) 
Domain Modeling (with Objects). Motivation Programming classes teach – What an object is – How to create objects What is missing – Finding/determining.
The chapter will address the following questions:
OO Analysis and Design CMPS OOA/OOD Cursory explanation of OOP emphasizes ▫ Syntax  classes, inheritance, message passing, virtual, static Most.
From Problem Statement to Design
Chapter 7 Structuring System Process Requirements
CS212: Object Oriented Analysis and Design Lecture 4: Objects and Classes - I.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 25. Review Design Level Class Diagram Identifying classes/Operations/Attributes Associations – Simple associations.
1 Object-Oriented Analysis Use Case Driven. 2 The outline method for OOA 1.Identify object classes within the problem domain 2.Define the behaviour of.
Faculty of Computer & Information Software Engineering Third year
Object oriented classification Classification is the process of checking to see if an object belongs to a category or a class, is regarded as a basic attribute.
Faculty of Computer & Information
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
1 Graph Coverage (6). Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Section
Designing Classes CS239 – Jan 26, Key points from yesterday’s lab  Enumerated types are abstract data types that define a set of values.  They.
Requirements specification Why is this the first major stage of software development? –Need to understand what customer wants first Goal of requirements.
CS212: Object Oriented Analysis and Design Lecture 32: Use case and Class diagrams.
111 Subsystems CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 7)
1 Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde.
OO DomainModeling With UML Class Diagrams and CRC Cards Chapter 6 Princess Nourah bint Abdulrahman University College of Computer and Information Sciences.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
Identification of Classes. Object Oriented Analysis (OOA) OOA is process by which we identify classes that play role in achieving system goals & requirements.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 5th Edition Copyright © 2015 John Wiley & Sons, Inc. All rights.
Chapter 3: Software Design –Use case Diagram Nouf Alghanmi.
1 Object-Oriented Static Modeling of the Banking System - III Lecture # 33.
Inf 43: Introduction to Software Engineering May 7, 2016.
1 Case Study and Use Cases for Case Study Lecture # 28.
CMPE 280 Web UI Design and Development August 29 Class Meeting
Use Case Modeling - II Lecture # 27.
Structured Analysis and Design Technique
ATM OO Design and Implementation Case Study
Dynamic Modeling of Banking System Case Study - I
Advanced Object-Oriented Analysis & Design
Object-Oriented Static Modeling of the Banking System - I
OO Domain Modeling With UML Class Diagrams and CRC Cards
OO Domain Modeling With UML Class Diagrams and CRC Cards
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Object-Oriented Analysis & Design
Real-Time Structured Analysis and Design Technique (RSTAD)
Presentation transcript:

May-June 2001 ISISTAN Research Institute – Tandil, Argentina Software Design Methodologies: UML in Action Dr. Mohamed Fayad, J.D. Edwards Professor Department of Computer Science & Engineering University of Nebraska, Lincoln Ferguson Hall, P.O. Box Lincoln, NE

L5-S2Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 2 Lesson 5: Object Identification - 2

L5-S3Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Lesson Objectives 3 + Learn how to identify: Associations and aggregations Attributes Behaviors Inheritance + Understand how to use the following approaches: Use Case CRC Questioning Techniques + Understand how to refine objects and associations + Learn how to define responsibility & collaborations + Learn how to eliminate unnecessary classes, associations, and attributes

L5-S4Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 4 Automated Teller Machine (ATM) Stop bothering me! I told you I don’t have any money!

L5-S5Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 5 Actors Customer Bank System Automated Teller Machine ATM Operator In Use Cases, Everything that interacts with the system will be modeled as an actor, such as persons as well as machines.

L5-S6Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 6 Use Cases in ATM Custome r Bank System Cash Withdrawal Transfer Funds Deposit Funds Automated Teller Machine Balance Inquiry System Start ATM Operator

L5-S7Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Use Case: Cash Withdrawal When a customer inserts a card in the ATM, the machine reads the code from the card and checks if it is a valid card. If the card is valid then the machine queries the customer for a PIN number, else the card is ejected. When the machine matches customer coded in the PIN number, the machine checks the validity of the PIN number. If the PIN number is correct and matches the card number then the machine asks for the desired transaction the customer wishes to perform. When the customer selects cash withdrawal the machine asks for the desired amount with a warning indicating only multiple of $10 is allowed. When A Use Case Description: Cash Withdrawal

L5-S8Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 8 Candidate Objects Account ATM Balance Inquiry Bank Card Reader Cancel Key Cash Dispenser Deposit Slot Deposit Funds Display Screen (Bank System Interface) Menu (Graphical User Interface) User Message Numeric Keypad Numeric Input Key PIN Cash Receipt Printer Special Input Key Transfer Funds Cash Withdrawal

L5-S9Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Define Responsibilities –What are the goals of the system –What must objects know to meet goals –What steps must each object accomplish Determine Collaborations –Decompose responsibilities into interactions among objects –Define clients and servers –Where should knowledge be held 9 System Responsibilities & Collaborations

L5-S10Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 10 CRC Cards General –Each class is described on a separate 3X5 or 4X6 card The cards are known as CRC card. They have 3 sections: –Class –Responsibilities –Collaborations ATM (role) Responsibility Collaboration ServerClients Access & modify account balance Account (role) Balance Inquiry Deposit Transaction Funds Transfer Withdrawal Transaction

L5-S11Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad  Generalize and Specialize objects  Associate Objects  Recognize Accidental Objects  Challenging and Testing Objects  Ask Questions 11 Other Techniques Help Refine Objects

L5-S12Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Generalization exposes commonalities Exercise helps to identify new classes Considerations for generalizations and specializations –Is it in the problem domain? –Is it within the system’s responsibilities? –Will there be inheritance? 12 Explore Generalizations and Specializations

L5-S13Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Essential objects represent genuine high-level abstractions Accidental objects represent qualitative judgments 13 Avoid Accidental Objects

L5-S14Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Needed Remembrance -- attributes Needed Behavior -- methods Usually Multiple Services per Object Usually More than One Object per Class 14 Challenge Objects

L5-S15Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Uniformity Test –Each instance must have the same set of characteristics and be subject to the same rules - Car license More than a Name Test –Every object has attributes, if not it is probably an attribute of another object -- home address Or Test –If inclusion criteria should not use “OR” in any significant way -- driver’s license number or learner’s permit number More Than a List Test –If inclusion criteria is only a list of instances -- decadent foods includes croissant, cappuccino, chocolate pie, ice cream. 15 Other Object Tests

L5-S16Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Something universal and real for reuse Should encapsulate some reasonably complex behavior to justify existence Methods that don’t make use of its current class’s own attributes is probably encapsulated in the wrong object. Small and simple stable interfaces Self sufficient and complete 16 Final Object Checklist

L5-S17Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Play Twenty Questions –Is it animal, vegetable, or mineral? –Does it have fur or feathers? –Can it fly? Define Boundaries –What else? –What about..? Quantify Qualities as Attributes –How fast? –How hot? 17 Questioning Techniques Help Elicit Domain Knowledge

L5-S18Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Irrelevant Associations –outside problem domain Implementation Associations –Examples: concurrent process, contains a list Associations Between Eliminated Classes 18 Eliminating Unnecessary Associations

L5-S19Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Actions or Transient Events –Examples: “Interacts with the Robot”, “ATM accepts cash card.” Ternary Associations –Decompose as binary associations or rephrase to one binary association. Derived Associations –These are redundant –Examples: “Younger than..” derived from age 19 Eliminating Unnecessary Associations (cont’d)

L5-S20Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Choose meaningful association names Add role names where appropriate Add attributes or associations which qualify existing associations –Example: “Standard Oil of Ohio” uses state attribute to qualify company name. Specify one-to-many and many-to-many associations in the class diagram Add missing associations –Not in problem statement –from knowledge of application domain 20 Refine Association List

L5-S21Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Attributes can be thought as a simple association with a value which is not an object –Examples: name, age, weight Usually corresponding to nouns followed by possessive phrases –Examples: “color of the car”, “age of the donor” Less likely to be fully described in the problem statement Included in the class box diagram Not as relevant to the problem structure as associations 21 Identifying Attributes

L5-S22Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad  Descriptive Attributes  Naming Attributes  Referential Attributes 22 Attribute Types

L5-S23Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Provide facts intrinsic to each instance of the object. –Examples Account.balance, Cat.weight –If the value of a descriptive attribute changes, it means only that some aspect of an instance has changed, but the instance is still the same instance. 23 Descriptive Attributes

L5-S24Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Are used to name or label instances. –Examples:Account.number, Flight.number –Names are typically somewhat arbitrary –Naming attributes are frequently used as an identifier or part of an identifier. –If the vale of a naming attribute changes, it means only that a new name has been given to exactly the same instance 24 Naming Attributes

L5-S25Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Are used to tie an instance of one object to an instance of another. –Examples: Cat.owner name indicates which person owns this cat. –If the vale of a referential attribute changes, it means that different instances are now being associated. 25 Referential Attributes

L5-S26Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad First Rule: One instance of an object or a class has exactly one value for each attribute at any given time. 26 Rules of Attributes Employee M/S Phone M. Fayad G. Smee L. Harris 1234 OK Not OK [Shlaer-Mellor 90]

L5-S27Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Second Rule: An attribute must contain no internal structure Examples: –Age, balance, size are all OK. –A name consists of first name, middle initial, and last name (Not OK) –An address contains house number, street name, city, state, zip code, and country name (Not OK) 27 Rules of Attributes (cont’d)

L5-S28Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Third Rule: When an object has a compound identifier -- that is, one made up of two or more attributes -- every attribute that is not part of the identifier represents a characteristic of the entire object. 28 Rules of Attributes (cont’d) Juice Transfer storage Tank ID cooking Tank ID gallons plannedTime The juice Transfer.gallons attribute means that the number of gallons transferred from the storage tank to the cooking tank and not the number of gallons in either the storage tank or the cooking tank.

L5-S29Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Fourth Rule: Each attribute is not part of an identifier that represents a characteristic of the instance named by the identifier and a characteristic of some other non-identifier attribute 29 Rules of Attributes (cont’d) Batch batch ID recipe ID gallons cookingTime The Batch.cookingTime attribute must represent the actual time the batch was cooked, and not the cooking time specified by the recipe

L5-S30Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Do not keep attributes that have an object as a value, they are associations Do not keep attributes that depend on a context, these are qualifiers for associations If an object can have more that one name, then the name qualifies an association of that object with another 30 Eliminating Unnecessary Attributes

L5-S31Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Do not put attributes of the association in one or the other of the objects involved in the association, put the attributes in the association itself Eliminate attributes which are only used internally by the object Keep initial analysis of attributes at a high level Eliminate attributes which are too low level Attributes which are in some instances of a class, but not in others, indicate that the class should be split into two or more classes 31 Eliminating Unnecessary Attributes (cont’d)

L5-S32Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Identify classes which share common information Three basic approaches: Bottom Up –Look for classes with repeated associations, attributes or behaviors, and group together into higher level classes –This approach is easier for inexperienced modelers Top Down –Look for Noun phrases describing different kinds of things in the problem statement. –Examples: Family cars, Sports cars, Luxury cars Combination of the two approaches works the best. –Do Top Down when doing initial analysis –Identify repeated information in the late passes. 32 Identifying Inheritance

L5-S33Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Always use the “AKO” test –All inheritance specifications should identify one or more classes which are “A Kind Of” a higher level class. –NEVER use inheritance for “Part / Part-of” relationships Use multiple inheritance only when necessary –Some object-oriented programming languages do not even have this feature. 33 Identifying Inheritance (cont’d)

L5-S34Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Done in latest stages List of behaviors can become large and get detailed quickly. May correspond to queries about attributes and associations –Operations to read or write attribute or association value –Examples: user name, property value, etc. May correspond to events or activities –Examples: begin simulation, alert, calculate balance, computer distance 34 Identifying Behaviors

L5-S35Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad 35 Experience and Domain Knowledge Good objects come from language of domain –If you are not an expert -- consult users Experience will tune decisions –Slowly at first –Much faster later Just do it!

L5-S36Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Define with examples: CRC cards, associate objects, referential attributes. Describe the third norm for testing objects What are the differences between essential objects and accidental objects What are questioning techniques and their purposes? Describe how do you identify: associations, aggregations, inheritance, attributes, and behaviors Describe how to refine objects and associations Explain how to define responsibilities and collaborations 36 Discussion Questions

L5-S37Object Identification- 2 May-June 2001 ISISTAN Research Institute – Tandil, Argentina -- M.E. Fayad Define: –Guidelines –Heuristics What do you think of these heuristics –A designer should distribute system intelligence uniformly among the top level classes in the system. –A designer should have 4.6 top level classes per 1,000 lines of code. –Eliminate classes that are outside the system 37 Questions for the Next Lecture