 Week08.  Review Schedule Weeks 8-14  This week o Review last class o Introduce Class Diagrams o ICE-03 Sheridan SYST30009 - Engineering Quality Systems.

Slides:



Advertisements
Similar presentations
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
Advertisements

Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall A.1.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Department of Computing
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Objectives Explain how events can be used to identify use cases that define requirements Identify and analyze events and resulting use cases Explain how.
Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition.
Chapter 14 (Web): Object-Oriented Data Modeling
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
Overview Objective: refine information gathered
2Object-Oriented Analysis and Design with the Unified Process Events and Use Cases  Use case  Activity the system carries out  Entry point into the.
6. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Explain how events can be used to identify use cases that define requirements.
PRJ566: PROJECT PLANNING AND MANAGEMENT Class Diagrams.
Chapter 14: Object-Oriented Data Modeling
Chapter 14: Object-Oriented Data Modeling
Chapter 5: Modeling Systems Requirements: Events and Things
Chapter 13 (Online): Object-Oriented Databases
Systems Analysis and Design in a Changing World, Tuesday, Feb 27
Modeling System Requirements:
Systems Analysis and Design in a Changing World, Fifth Edition
1 A Student Guide to Object- Orientated Systems Chapter 4 Objects and Classes: the basic concepts.
Jerry KotubaSYST39409-Object Oriented Methodologies1 Object Oriented Methodologies Week04.
Conceptual Data Modeling. What Is a Conceptual Data Model? A detailed model that shows the overall structure of organizational data A detailed model.
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.
Database Management System Prepared by Dr. Ahmed El-Ragal Reviewed & Presented By Mr. Mahmoud Rafeek Alfarra College Of Science & Technology Khan younis.
Unified Modeling Language, Version 2.0
5 Systems Analysis and Design in a Changing World, Fourth Edition.
Systems Analysis and Design in a Changing World, Fifth Edition
R McFadyen Chapter 7 Conceptual Data Modeling.
Association Class Generalization/Specialization Whole-Part Page More Associations 1.
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 4 - Domain Classes.
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 4 Domain Classes.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
CHAPTER 13 (ONLINE): OBJECT-ORIENTED DATA MODELING © 2013 Pearson Education, Inc. Publishing as Prentice Hall 1 Modern Database Management 11 th Edition.
1 © Prentice Hall, 2002 Chapter 14: Object-Oriented Data Modeling Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R.
© 2009 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 15: Object-Oriented Data Modeling Modern Database Management 9 h Edition Jeffrey A.
© 2011 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 13 (Online): Object-Oriented Data Modeling Modern Database Management 10 th Edition.
CHAPTER 13: OBJECT-ORIENTED DATA MODELING (OVERVIEW) © 2013 Pearson Education, Inc. Publishing as Prentice Hall 1 Modern Database Management 11 th Edition.
Jerry KotubaSYST39409-Object Oriented Methodologies1 Object Oriented Methodologies Week05/06.
Unified Modeling Language © 2002 by Dietrich and Urban1 ADVANCED DATABASE CONCEPTS Unified Modeling Language Susan D. Urban and Suzanne W. Dietrich Department.
Objectives Explain how events can be used to identify use cases that define requirements Identify and analyze events and resulting use cases Explain.
Object Oriented Methodologies
Modeling system requirements. Purpose of Models Models help an analyst clarify and refine a design. Models help simplify the complexity of information.
Fall 2010 CS4310 Requirements Engineering A Brief Review of UML & OO Dr. Guoqiang Hu Department of Computer Science UTEP 1.
Lecture 8 Object-Oriented Analysis and Design 20.1 COSC4406: Software Engineering.
5 Systems Analysis and Design in a Changing World, Fifth Edition.
Modeling System Requirements: Events and Things. Objectives Explain the many reasons for creating information system models Describe three types of models.
What is a Structural Model?
Object-Oriented Data Modeling
LESSON05 Jerry Kotuba Object Oriented Methodologies 1.
Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A.
CHAPTER 13: OBJECT-ORIENTED DATA MODELING (OVERVIEW) Modern Database Management 11 th Edition Jeffrey A. Hoffer, V. Ramesh, Heikki Topi © 2013 Pearson.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Appendix A Object-Oriented Analysis and Design A.1.
Object Oriented Methodologies
Basic Characteristics of Object-Oriented Systems
5 Systems Analysis and Design in a Changing World, Fourth Edition.
5 Chapter 5: Modeling Systems Requirements: Events and Things Systems Analysis and Design in a Changing World.
Object-Oriented Modeling
Business System Development
DATA REQIREMENT ANALYSIS
The Movement To Objects
Engineering Quality Software
Lec 3: Object-Oriented Data Modeling
Chapter 20 Object-Oriented Analysis and Design
Appendix A Object-Oriented Analysis and Design
Systems Analysis – ITEC 3155 Modeling System Requirements – Part 2
Basic OOP Concepts and Terms
Appendix A Object-Oriented Analysis and Design
Appendix A Object-Oriented Analysis and Design
Presentation transcript:

 Week08

 Review Schedule Weeks 8-14  This week o Review last class o Introduce Class Diagrams o ICE-03 Sheridan SYST Engineering Quality Systems 2

 Identify and analyze the objects and object-classes needed in a system  Learn how to identify and represent relationships between object classes.  Learn how to identify and create super/subclass relationships  Learn how to create a Unified Modeling Language (UML) class diagram using System Architect Sheridan SYST Engineering Quality Systems 3

 Use case o Activity the system carries out o Entry point into the modeling process  Event decomposition: help identify use cases  Elementary business processes (EBPs) o Basic unit of analysis o Initiated by event occurring at specific time and place o Discrete system response that adds business value Sheridan SYST Engineering Quality Systems 4

 Event decomposition o Develops use cases based on system response to events o Focus on business processes and business requirements  Result of the decomposition: o List of use cases triggered by business events o Use cases at the right level of analysis Sheridan SYST Engineering Quality Systems 5

 Problem domain o Set of work-related “things” in system component Things have data representation within system o Examples: products, orders, invoices, customers  OO approach to things in problem domain o Objects that interact in the system  Identify and understand things in problem domain o Key initial steps in defining requirements Sheridan SYST Engineering Quality Systems 6

Sheridan SYST Engineering Quality Systems 7

 Things can be identified with methodology  Separate the tangible from the intangible  Include information from all types of users  Ask important questions about nature of event o “What actions upon things should be acknowledged and recorded by the system?” Sheridan SYST Engineering Quality Systems 8

 List nouns users mention when discussing system  Event table as source of potential things o Use cases, external agents, triggers, response  Select nouns with questions concerning relevance o Further research may be needed Sheridan SYST Engineering Quality Systems 9

Sheridan SYST Engineering Quality Systems 10

 Analyst document entity associations ( relationships) o Example: “Is placed by” and “works in”  Associations apply in two directions o Customer places an order o An order is placed by a customer  Multiplicity: the number of associations o One to one or one to many  The associations between types of things o Unary (recursive), binary, n-ary Sheridan SYST Engineering Quality Systems 11

Sheridan SYST Engineering Quality Systems 12 Associations Naturally Occur between Things

Sheridan SYST Engineering Quality Systems 13 Multiplicity of Relationships

 Specific details of things are called attributes  Analyst should identify attributes of things  Identifier (key): attribute uniquely identifying thing o Examples: Social Security number, vehicle ID number, or product ID number  Compound attribute is a set of related attributes o Example: multiple names for the same customer Sheridan SYST Engineering Quality Systems 14

Sheridan SYST Engineering Quality Systems 15

 Domain model class diagram as UML class o OOA applies domain model class diagram to things  Problem domain objects have attributes  Software objects encapsulate attributes and behaviors o Behavior: action that the object processes itself  Software objects communicate with messages  Information system is a set of interacting objects Sheridan SYST Engineering Quality Systems 16

Sheridan SYST Engineering Quality Systems 17

Sheridan SYST Engineering Quality Systems 18

Sheridan SYST Engineering Quality Systems 19

 Generalization/specialization notation o Inheritance hierarchy o Rank things the more general to the more special Motor vehicle class includes trucks, cars, buses  Classification: means of defining classes of things o Superclass: generalization of a class o Subclass: specialization of a class Sheridan SYST Engineering Quality Systems 20

Sheridan SYST Engineering Quality Systems 21

 See SLATE Sheridan SYST Engineering Quality Systems 22

Sheridan SYST Engineering Quality Systems 23

 Construct a class diagram from a narrative including relationships and multiplicities.  Identify and represent inheritance hierarchies in a class diagram.  Learn what is meant by a concrete and/or abstract class.  How to determine and note the constraints for generalization / specialization relationships.  Learn how to describe Whole-to-Part relationships on a class diagram.  How to draw all these relationships using System Architect. Sheridan SYST Engineering Quality Systems 24

 Document the static structure of the system  They define what classes there are and how they are related  The symbol on the right defines the data and behaviour encapsulated by a class.  Objects “know things and know how to do things!” Sheridan SYST Engineering Quality Systems 25

 Demo exercise Sheridan SYST Engineering Quality Systems 26

 From last class… Sheridan SYST Engineering Quality Systems 27

 We need to know what types of things the user works with routinely. o Many types Tangible Intangible Important to include information from all types of users Sheridan SYST Engineering Quality Systems 28

Jacobson’s Three Types Of Objects Entity Interface Control Sheridan SYST Engineering Quality Systems 29

 Attributes  Behavior (methods & operations) o Real world o Data world Sheridan SYST Engineering Quality Systems 30

Class Diagram Showing Two Classes Object Diagram with Two Instances Sheridan SYST Engineering Quality Systems 31

 relationship among object classes  solid line connecting classes  association is named i.e. drives  where line connects to class is called “association role” Sheridan SYST Engineering Quality Systems 32

Sheridan SYST Engineering Quality Systems 33  shows number of objects in an association  lower..upper bound  bounds are inclusive 2..5  0..1 = optional one  0..* = optional many  1..* = many  1 = exactly one * * ** ** * *

 Examples Sheridan SYST Engineering Quality Systems 34

 SLATE – Lesson 08 Class Diagram Exercises Sheridan SYST Engineering Quality Systems 35

Sheridan SYST Engineering Quality Systems 36

 Some instances of a class (subclass) may be grouped together based on features not shared by the rest of the class. o Attributes o Behavior o Relationships  Key verb is “isakinda” (and inverse, “canbea”). Sheridan SYST Engineering Quality Systems 37

 A subclass is made up of selected instances from another class, the “Parent class” or “superclass.”  A superclass includes all the instances of the subclass, plus possibly more as well. Sheridan SYST Engineering Quality Systems 38

 Inheritance is when a subclass instance, in addition to the attributes and behavior it has by virtue of being in the subclass, also has all the attributes and behavior that instances of the superclass have. Sheridan SYST Engineering Quality Systems 39 Each subclass then adds attributes and behaviors that it needs but the other one doesn’t.

 The subclass relationship actually is a relationship in the way we have used that word.  It requires a verb (one in each direction). o “isakinda” o “canbea” Sheridan SYST Engineering Quality Systems 40 isakinda canbea

 To be considered truly O-O, a language, database, etc. must support: o Objects, o Classes, o Inheritance, and o Polymorphism Sheridan SYST Engineering Quality Systems 41

 With subclasses, we can show more detail about relationships on our diagram. o For instance, in most companies, only managers can hire and fire. o In other words, only certain kindsa employees can do certain tasks. (only a baker can bake)  We are able to show that some relationships affect only a subclass, not every instance. Sheridan SYST Engineering Quality Systems 42

 SLATE- Inheritance Exercise Sheridan SYST Engineering Quality Systems 43

Sheridan SYST Engineering Quality Systems 44

 generalization path o solid line with hollow arrowhead pointing from subclass to superclass  indicate basis of generalization  name the path for the attribute being removed = called the discriminator  discriminator shows which property is abstracted by a generalization relationship Sheridan SYST Engineering Quality Systems 45

 constraints on the subclasses  overlapping: descendent may be descended from more than one of the subclasses o student can be both a research and teaching assistant  disjoint: descendent may not be descended from more than one of the subclasses o patient can not be both out and resident Sheridan SYST Engineering Quality Systems 46

 complete: all subclasses are listed o only have out and resident patients  incomplete: all subclasses are not listed o more subclasses are available o can have casual, part-time employees Sheridan SYST Engineering Quality Systems 47

 SLATE – Lesson 5 Vehicle Registration System Sheridan SYST Engineering Quality Systems 48

Sheridan SYST Engineering Quality Systems 49

 Continue with relationships o Class diagram Whole-Part associations (Aggregation) Sheridan SYST Engineering Quality Systems 50