Objects What are Objects Observations

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

Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
Systems Analysis and Design 8th Edition
Ch 12: Object-Oriented Analysis
Systems Analysis and Design in a Changing World, Fourth Edition
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 5: Restaurant.
7M701 1 Software Engineering Object-oriented Design Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 12 )
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Slide 6C.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 6B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 8B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 SWE Introduction to Software Engineering Lecture 15 – System Modeling Using UML.
IMS1805 Systems Analysis Topic 3: Doing Analysis (continued from previous weeks)
©Ian Sommerville 2006Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
1/31 CS 426 Senior Projects Chapter 1: What is UML? Chapter 2: What is UP? [Arlow and Neustadt, 2005] January 22, 2009.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
Slide 7A.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 6A.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Objectives Explain the purpose and objectives of object- oriented design Develop design class diagrams Develop interaction diagrams based on the principles.
1 CS 426 Senior Projects Chapter 1: What is UML? Chapter 2: What is UP? [Arlow and Neustadt, 2002] January 26, 2006.
Slide 12C.50 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005.
Case Study: Class Extraction.
Slide 10C.52 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
PRJ566: PROJECT PLANNING AND MANAGEMENT Class Diagrams.
The chapter will address the following questions:
Chapter 7: The Object-Oriented Approach to Requirements
Classification of UML Diagrams
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
ITEC224 Database Programming
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix A Object-Oriented.
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.
Object Oriented Analysis & Design & UML (Unified Modeling Language)1 Part V: Design The Design Workflow Design Classes Refining Analysis Relationships.
Systems Analysis and Design in a Changing World, Fifth Edition
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
1 Analysis Extracting from Use Cases to Create Diagrams.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
CSC 395 – Software Engineering Lecture 13: Object-Oriented Analysis –or– Let the Pain Begin (At Least I’m Honest!)
Chapter 7 System models.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Systems Analysis and Design in a Changing World, 3rd Edition
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 4: Restaurant.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Systems Analysis & Design 7 th Edition Chapter 5.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2 nd Edition Copyright 2003 © John Wiley & Sons, Inc. All rights reserved.
An Introduction to the Unified Modeling Language
Slide 12A.1 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
OBJECT ORIENTED AND FUNCTION ORIENTED DESIGN 1 Chapter 6.
Introduction to OOAD and the UML
THE ANALYSIS WORKFLOW  The specification document  Informal specifications  The analysis workflow  Extracting the entity classes  Functional modeling:
Slide 12D.88 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
Slide 12F.135 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
Object Modeling THETOPPERSWAY.COM. Object Modelling Technique(OMT)  Building a model of an application domain and then adding implementation.
 To explain why the context of a system should be modelled as part of the RE process  To describe behavioural modelling, data modelling and object modelling.
Object-Oriented Software Engineering Practical Software Development using UML and Java Modelling with Classes.
Chapter 6: The Analysis Workflow Chapter 7: Classes and Objects Chapter 8: Finding Analysis Classes [Arlow and Neustadt, 2005] CS 426 Senior Projects in.
Kyung Hee University Class Diagramming Notation OOSD 담당조교 석사과정 이정환.
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.
1 M206 Chapter 31: An Overview of Software Development 1.Defining the problem 2.Analyzing the requirement – constructing initial structural model 3.Analyzing.
Object-Oriented Analysis and Design
Unified Modeling Language
University of Houston-Clear Lake
Chapter 20 Object-Oriented Analysis and Design
Software Analysis.
Presentation transcript:

Introduction to Unified Modelling Language (UML) (part 2 Class diagram, Associations)

Objects What are Objects Observations “a discrete entity with a well-defined boundary that encapsulates state and behaviour; an instance of a class” UML Reference Manual, 2nd Edition-2004 Observations an instance of a class state is maintained in fields behaviour is implemented via methods every object is uniquely identified

UML Object Notation

Classes What are Classes “the descriptor for a set of objects that share the same attributes, operations, methods, relationships, and behaviour” UML Reference Manual, 2nd Edition-2004 template for objects with similar features

UML Class Notation

UML Class Notation

How Much to Show? Scenarios scenario 1: inter-class relationship scenario 2: behaviour of a class or classes scenario 3: entity classes representing data entities

How Much to Show? Scenarios scenario 1: inter-class relationship class boxes are probably enough with name compartment only scenario 2: behaviour of a class or classes class boxes with name & operations compartment

Analysis Classes What is an Analysis Class? represents an important concept of the problem domain maps on to real-world concepts an attempt to capture the big picture

Analysis Classes

Analysis Classes Observations name reflects the intent of abstraction focus clearly defined/understood small & well defined set of responsibilities high cohesion & low coupling

Classes The three class types in the Unified Process are UML notation Entity classes Boundary classes Control classes UML notation

Entity Classes An entity class models information that is long lived Examples: Account Class in a banking information system Mortgage Class and Investment Class in the information system Instances of all these classes remain in the information system for years

Boundary Classes A boundary class models the interaction between the information system and its actors Boundary classes are generally associated with input and output Examples: Sales Report Class in the E-Commerce information system Mortgage Listing Class and Investment Listing Class in the information system

Control Classes A control class models complex computations and algorithms Examples: Compute GPA Student Class, in the PSU information system

Stereotypes UML notation for these three types of classes These are stereotypes (extensions of UML) UML allows us to define additional constructs that are not part of UML but which we need in order to model a system accurately

The Unified Process and Classes The Unified Process does not describe how classes are extracted Users of the Unified Process are expected to have a background in object-oriented analysis and design We temporarily suspend this discussion of the Unified Process to explain how classes are extracted, and then return to the Unified Process

Extracting Entity Classes Entity class extraction consists of three steps that are carried out iteratively and incrementally: Functional modeling Present scenarios of all the use cases (a scenario is an instance of a use case) Class modeling Determine the entity classes and their attributes Determine the interrelationships and interactions between the entity classes Present this information in the form of a class diagram Dynamic modeling Determine the operations performed by or to each entity class Present this information in the form of a statechart

Flowchart for Extracting Entity Classes

Initial Class Diagram: Painting System Case Study The second step in extracting the entity classes is class modeling The aim of this step is to extract the entity classes, determine their interrelationships, and find their attributes Usually, the best way to begin this step is to use the two-stage noun extraction method Stage 1: Describe the information system in a single paragraph Stage 2: Identify the nouns in this paragraph, then select the entity classes from those nouns

Noun Extraction: Painting System Case Study Stage 1: Describe the information system in one paragraph: Reports are to be generated in order to improve the effectiveness of the decision-making process for buying works of art. The reports contain buying and selling information about paintings, which are classified as masterpieces, masterworks, and other paintings

Noun Extraction: Painting System (contd) Stage 2: Identify the nouns in this paragraph Reports are to be generated in order to improve the effectiveness of the decision-making process for buying works of art. The reports contain buying and selling information about paintings, which are classified as masterpieces, masterworks, and other paintings The nouns are report, effectiveness, process, buying, work of art, selling, information, painting, masterpiece, and masterwork

Noun Extraction: Painting System (contd) effectiveness, process and information are abstract nouns and are therefore unlikely to be entity classes Abstract nouns identify things that have no physical existence Nouns buying and selling are derived from the verbs “buy” and “sell” They will probably be operations of some class

Noun Extraction: Painting System (contd) Noun report is unlikely to be an entity class, because a report is not long lived A report is much more likely to be a boundary class Noun work of art is just a synonym for painting

First Iteration of the Initial Class Diagram This leaves four candidate entity classes: Painting Class, Masterpiece Class, Masterwork Class, and Other Painting Class

Second Iteration of the Initial Class Diagram Consider the interrelationships between the entity classes A masterpiece is a specific type of painting, and so is a masterwork and an “other painting” Painting Class is therefore the base class Masterpiece Class, Masterwork Class, and Other Painting Class are subclasses of that base class

Second Iteration of Initial Class Diagram (contd)

Third Iteration of the Initial Class Diagram The class diagram does not reflect aspects of the pricing algorithm When dealing with a masterwork “The information system first computes the maximum purchase price as if it were a masterpiece by the same artist”

Third Iteration of the Initial Class Diagram (contd) That is, a masterwork has to have all the attributes of a masterpiece (so that its maximum purchase price can be computed as if it were a masterpiece) and, in addition, it may have attributes of its own This is modeled in the next slide

Third Iteration of the Initial Class Diagram (contd)

Fourth Iteration of the Initial Class Diagram Another aspect of the pricing algorithm that is not reflected in the current class diagram is “The information system computes the coefficient of similarity between each painting for which there is an auction record and the painting under consideration for purchase”

Fourth Iteration of the Initial Class Diagram (contd) Auctioned Painting Class is needed to make these comparisons An auctioned painting must be a subclass of Painting Class But a painting previously been sold at an auction somewhere in the world has nothing to do with paintings currently on display for sale in Osbert’s gallery

Fourth Iteration of the Initial Class Diagram (contd)

Fourth Iteration of the Initial Class Diagram (contd) An instance of Painting Class is either A painting that Osbert has bought (an instance of Gallery Painting Class), or A painting sold at some auction (an instance of Auctioned Painting Class)

Initial Class Diagram: Painting System Case Study Why was the first iteration of the class diagram so inadequate? The Painting System case study appears to be a straightforward data-processing application The one-paragraph description correctly did not incorporate the pricing algorithm Unfortunately, the algorithmic details turned out to be critical to the class diagram

Initial Class Diagram: Painting System (contd) The first iteration of the class diagram was no good However, repeated iteration and incrementation led to a reasonable class diagram This demonstrates the power of the iterative and incremental approach

Initial Class Diagram (contd) Finally, we add the attributes of each class to the class diagram the result is shown on the next slide The empty rectangle at the bottom of each box will later be filled with the operations of that class

Fifth Iteration of the Initial Class Diagram (contd)

Fifth Iteration of the Initial Class Diagram (contd)

Done with the Painting System case study Still the dynamic modeling – later

Design Classes What is a Design Class? Integrates the problem domain & solution domain problem domain → refined analysis classes solution domain → implementation specific classes are complete, ready to be implemented

Design Classes Concerns responsibility inheritance the public methods imply a contract code evolution should be considered inheritance major concern of design classes (why?)

Inheritance Concerns the strongest form of coupling between classes “fragile base class” problem changes in the base class impact subclasses inflexible to change fixed at runtime

Example: Ambitious John

Inheritance or Interface interface & implementation concerns with reuse Interface interface only concerns with functionality contract “design by contract” concerns with reuse (what?)

Further Considerations Student Self-Study Templates Nested classes Multiple Inheritance

connection between two things (usually classes) What is an Association? connection between two things (usually classes) “for a link between two object, there must be an association between the class of those objects” link is an instance of an association link can be represented by dependency relationship

Example

Reflexive Association

Reflexive Association

Aggregation

Composition

Association Classes

Association Classes Observations association classes are purely analysis classes convert association class into normal design class use the various relationships to clarify association (aggregation, composition, dependency) additional constraints to refine the model navigation, multiplicity