Week 9, Day 2 Object-oriented Design Acknowledgement: These slides by Dr. Hasker SE-2811 Slide design: Dr. Mark L. Hornick Content: Dr. Hornick Errors:

Slides:



Advertisements
Similar presentations
Use Case Diagrams Damian Gordon.
Advertisements

2-May-15 GUI Design. 2 HMI design There are entire college courses taught on HMI (Human-Machine Interface) design This is just a very brief presentation.
8.
Introduction To System Analysis and Design
© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Marakas: Decision Support Systems, 2nd Edition © 2003, Prentice-Hall Chapter Chapter 1: Introduction to Decision Support Systems Decision Support.
Requirements Analysis 2 What objects collaborate to achieve the goal of a use case?
System Engineering Instructor: Dr. Jerry Gao. System Engineering Jerry Gao, Ph.D. Jan System Engineering Hierarchy - System Modeling - Information.
3/15/05H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)
Architectural Design.
Chapter 10 Architectural Design
Systems Analysis and Design in a Changing World, Fifth Edition
Liang, Introduction to Java Programming, Sixth Edition, (c) 2007 Pearson Education, Inc. All rights reserved Chapter 12 Object-Oriented.
1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100.
111 Subsystems CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 7)
Designing a Graphical User Interface (GUI) Krisana Chinnasarn, Ph.D. January 2007.
CS 4720 Usability and Accessibility CS 4720 – Web & Mobile Systems.
1 SA Capstone Requirements and Design Week 6 SYST Winter 2015 Some slides adapted from: Systems Analysis and Design in a Changing World, 6th Edition,
Two Approaches to System Development
12 Systems Analysis and Design in a Changing World, Fifth Edition.
Detailed design – class design Domain Modeling SE-2030 Dr. Rob Hasker 1 Based on slides written by Dr. Mark L. Hornick Used with permission.
Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman.
Introduction To System Analysis and Design
Object Oriented Design Jerry KotubaSYST Object Oriented Methodologies1.
Object-Oriented Programming (OOP) CSC-2071 (3+1=4 Credits) Lecture No. 1 MBY.
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 4 - Domain Classes.
1-1 System Development Process System development process – a set of activities, methods, best practices, deliverables, and automated tools that stakeholders.
Approaching a Problem Where do we start? How do we proceed?
Cohesion and Coupling CS 4311
NI ©UNITEN 2000/01 1 Faculty of Applied Engineering and Urban Planning Software Engineering Department Class Diagram Faculty of Information system Technology.
1-1 C Sc 335 Course Overview Object-Oriented Programming and Design Rick Mercer.
GRASP: Designing Objects with Responsibilities
Object-Oriented Design Simple Program Design Third Edition A Step-by-Step Approach 11.
Chapter 8 Object Design Reuse and Patterns. Object Design Object design is the process of adding details to the requirements analysis and making implementation.
CSC241 Object-Oriented Programming (OOP) Lecture No. 1.
9 Systems Analysis and Design in a Changing World, Fourth Edition.
Week 2, Day 2: The Factory Method Pattern Other good design principles Cohesion vs. Coupling Implementing the Strategy Pattern Changing strategies (behaviors)
Object Oriented Design Jerry KotubaSYST Object Oriented Methodologies1.
Computing and SE II Chapter 9: Design Methods and Design Models Er-Yu Ding Software Institute, NJU.
1 Chapter 5 Modeling System Requirements Finding the Use Cases Page
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Use Case Textual Analysis
111 Subsystems CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 7)
1 Software Engineering Lecture 15 Object Oriented Software Design in Java.
SE1011 Week 3, Class 2 Today Sit down by someone you don't know Learn their name Find out who came farther to get to MSOE at the start of the quarter Designing.
SE-2811 Software Component Design Week 1, Day 2 Making teams Warm-up exercise Design pattern defined SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick.
February 19, February 19, 2016February 19, 2016February 19, 2016 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
Chapter 6: The Analysis Workflow Chapter 7: Classes and Objects Chapter 8: Finding Analysis Classes [Arlow and Neustadt, 2005] CS 426 Senior Projects in.
High Level Design Use Case Textual Analysis SE-2030 Dr. Mark L. Hornick 1.
Object-Oriented Paradigm (OOP) Course Code: SE 101 Lecture No. 1.
SE-2811 Software Component Design Week 1, Day 1 Design pattern defined Code that needs a design pattern… SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick.
Project May07-14: Restaurant Automation April 24, 2007.
3/1/01H-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Evaluating Class Diagrams Topics include: Cohesion, Coupling Law of Demeter (handout)
Week 6, Class 3: Composite Swing composites File composites Computer composites SE-2811 Slide design: Dr. Mark L. Hornick Content: Dr. Hornick Errors:
Week 5, Class 3: Decorators Lab questions? Example: Starbuzz coffee Basic Pattern More examples Design Principles Compare with alternatives SE-2811 Slide.
Slide design: Dr. Mark L. Hornick
Week 2, Day 1: The Factory Method Pattern
Note 11 Command Pattern SE2811 Software Component Design
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
SE-2811 Software Component Design
12. Command Pattern SE2811 Software Component Design
3. Object-oriented Design
Bacyal, Grace Luzcelyn B.
UML Class Diagram.
Week 7, Class 1: The Command Pattern (cont.)
7. Decorator SE2811 Software Component Design
4: Object-oriented Analysis & Design
12. Command Pattern SE2811 Software Component Design
Presentation transcript:

Week 9, Day 2 Object-oriented Design Acknowledgement: These slides by Dr. Hasker SE-2811 Slide design: Dr. Mark L. Hornick Content: Dr. Hornick Errors: Dr. Yoder 1

What’s an object? What does it mean to say Java is object-oriented? 1st year: oo programming; 2811: object-oriented design So what’s an object? What are the elements of a class? State Capture information, provide it on request, record events Student: name, id, classes taking, GPA Behavior Operations that do things Student: compute GPA for term, add a class to schedule Responsibility What the object provides to the rest of the system Student: record classes taking, progress

What’s an object? What are the responsibilities of… A house? A roof? door? window? Bank account? Student record in registration system? How many responsibilities should a class have? Textbook: just one! What would happen if Student had just one responsibility? Responsibilities: clear, limited, but complete! When would it make sense to have just one responsibility?

What is the responsibility of java.util.Date? See first line of Java APIJava API What’s an object?

What is the responsibility of java.util.Date? See first line of Java APIJava API Does this match something in the physical world? A concept, not an object! Identity Something you can point at An address: this is just some text A building: there is a specific building at a specific location Helps distinguish between pieces of information about something (color, name, identification number, temperature) and the things that have that information (people, hurricanes, cars, boats) Objects without identity: attributes

What characterizes an object An object is something with Responsibility Identity Behavior State

What characterizes an object An object is something with Responsibility Identity Behavior State But where do objects come from? How do we know we have all the ones we need? Consider a simple example…

How to build a system? Meal Wheel As a hungry student, I want my phone to randomly select from different restaurants so I know where to eat. As a picky student, I want my phone to suggest close restaurants that serve sashimi so I can choose a place to eat within 10 minutes walk. As a restaurant owner, I want to distribute menus to potential customers. As a restaurant owner, I want potential customers to know of dietary restrictions that I support so I can attract customers who do not eat particular foods. What classes should be in this system? Why?

Domain classes Possible classes: table of restaurants to GPS coordinates, table of restaurants to menus, table of dietary restrictions to menu items But if add tracking popularity, wait times, etc., will need to add more tables Solution: domain classes Classes that are part of the problem space Alternative: solution space Classes that are in a particular solution Why prefer domain classes? Solution independent – less likely to change to support new features Natural: these are the entities that form the problem to solve

How to identify domain classes? Solution 1: just sit there and think them up Solution 2: mine the stories/scenarios/requirements Objects: lead to classes Verbs: actions

Finding classes: Meal Wheel As a hungry student, I want my phone to randomly select from different restaurants so I know where to eat. As a picky student, I want my phone to suggest close restaurants that serve sashimi so I can choose a place to eat within 10 minutes walk. As a restaurant owner, I want to distribute menus to potential customers. As a restaurant owner, I want potential customers to know of dietary restrictions that I support so I can attract customers who do not eat particular foods.

Finding classes: Meal Wheel As a hungry student, I want my phone to randomly select from different restaurants so I know where to eat. As a picky student, I want my phone to suggest close restaurants that serve sashimi so I can choose a place to eat within 10 minutes walk. As a restaurant owner, I want to distribute menus to potential customers. As a restaurant owner, I want potential customers to know of dietary restrictions that I support so I can attract customers who do not eat particular foods.

Finding classes: Meal Wheel As a hungry student, I want my phone to randomly select from different restaurants so I know where to eat. As a picky student, I want my phone to suggest close restaurants that serve sashimi so I can choose a place to eat within 10 minutes walk. As a restaurant owner, I want to distribute menus to potential customers. As a restaurant owner, I want potential customers to know of dietary restrictions that I support so I can attract customers who do not eat particular foods. Noun identification method Classes: groups of objects w/ RIBS Attributes: simple data Methods: actions on objects Noun identification method Classes: groups of objects w/ RIBS Attributes: simple data Methods: actions on objects

Other sources of classes Active objects Objects which consume, produce others; objects which control actions Passive objects Data storage, inputs, basic output Example: light switch, sensors, printers Real-world items – domain classes discussed earlier Physical devices – things with internal state to capture Transactions – sales receipt, todo item Persistent information: configuration User interface elements – menus, dialogs

Sound designs 1. Start with domain classes These persist across problem changes Capture things clients, users will recognize Capture requirements that go with those items 2. Add containers, architectural elements Decisions about time/space/complexity tradeoffs Databases, network communications, GUI elements 3. Introduce design patterns, refine These generally reduce coupling, increase flexibility May REMOVE classes from previous steps Be careful about removing domain classes! RIBS: test whether a thing is an object or an attribute, when to make 2+ objects

Common mistakes “doit” class: does everything Generally surrounded by lots of passive objects VERY low cohesion System class – no need to document main()! Often becomes a doit class Classes for actions “parser”, “artificial intelligence”, “list maintainer” Roll these into domain objects! Patterns excepted! Poor inheritance If A extends B, then anywhere a B can appear, so can an A Liskov Substitution Principle Never violate contracts How would these violate RIBS?

Review Noun identification method RIBS Other sources for classes Doit, passive classes and their dangers Liskov Substitution Principle

SE-2811 Dr. Mark L. Hornick 18