CSC 213 – Large Scale Programming. Today’s Goal  Improve design skills to make usable designs  Noun extraction & UML class diagram reviewed  Connections.

Slides:



Advertisements
Similar presentations
COMP 121 Week 7: Object-Oriented Design and Efficiency of Algorithms.
Advertisements

Chapter 7 Structuring System Process Requirements
Object Oriented Design An object combines data and operations on that data (object is an instance of class) data: class variables operations: methods Three.
Problem Solving #1 ICS Outline Review of Key Topics Review of Key Topics Example Program Example Program –Problem 7.1 Problem Solving Tips Problem.
Important concepts in software engineering The tools to make it easy to apply common sense!
Algorithms and Problem Solving-1 Algorithms and Problem Solving.
Algorithms and Problem Solving. Learn about problem solving skills Explore the algorithmic approach for problem solving Learn about algorithm development.
1 CS1001 Lecture Overview Object Oriented Design Object Oriented Design.
Software Engineering Case Study Slide 1 Introductory case study.
Domain Modeling (with Objects). Motivation Programming classes teach – What an object is – How to create objects What is missing – Finding/determining.
Chapter 7 Structuring System Process Requirements
Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN:
Chapter 3 Object-Oriented Analysis of Library Management System(LMS)
CSC 213 – Large Scale Programming. Today’s Goal  Learn Unified Process to design programs  Understand what are the “types” of Java classes  Methods.
Objects What are Objects Observations
Lecture 2: UML Class DIAGRAM
Slide 12.1 © The McGraw-Hill Companies, CS 4310: Software Engineering Lecture 7 Systems Analysis Object-Oriented Design.
Abstraction IS 101Y/CMSC 101 Computational Thinking and Design Tuesday, September 17, 2013 Carolyn Seaman University of Maryland, Baltimore County.
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
Data Flow Diagram A method used to analyze a system in a structured way Used during: Analysis stage: to describe the current system Design stage: to describe.
CSC 213 – Large Scale Programming Lecture 2: Object-Oriented Analysis & Object-Oriented Design.
CSC 213 – Large Scale Programming Lecture 3: Object-Oriented Analysis.
LECTURE 38: REFACTORING CSC 395 – Software Engineering.
Software Life Cycle Requirements and problem analysis. –What exactly is this system supposed to do? Design –How will the system solve the problem? Coding.
CS3320::CH111 OBJECT-ORIENTED ANALYSIS Chapter 11.
University of Toronto Department of Computer Science © Steve Easterbrook. This presentation is available free for non-commercial use with attribution.
 2000 Deitel & Associates, Inc. All rights reserved. Optional Case Study - Chapter 5 Outline 5.1 Introduction 5.2 Collaborations 5.3 Creating Collaborations.
1 Analysis Extracting from Use Cases to Create Diagrams.
Chapter 17 GRASP: Designing Objects with Responsibilities. 1CS6359 Fall 2011 John Cole.
 2000 Deitel & Associates, Inc. All rights reserved. Optional Case Study - Chapter 3 Outline 3.1 Introduction 3.2 Class Attributes 3.3 Statechart Diagrams.
CSC 395 – Software Engineering Lecture 13: Object-Oriented Analysis –or– Let the Pain Begin (At Least I’m Honest!)
Review: Cohesion and Coupling, Mutable, Inheritance Screen Layouts Software methodologies – Extreme Programming Object-Oriented Design – CRC Cards - UML.
Question of the Day  On a game show you’re given the choice of three doors: Behind one door is a car; behind the others, goats. After you pick a door,
LECTURE 14: USE CASE BASICS CSC 212 – Data Structures.
Question of the Day  On a game show you’re given the choice of three doors: Behind one door is a car; behind the others, goats. After you pick a door,
Lecture 3 Uses Cases Topics UML Use Cases pop quiz Readings: Chapter 3 January 24, 2008 CSCE 492 Software Engineering.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
CSC 395 – Software Engineering Lecture 14: Object-Oriented Analysis –or– Ripping the Band-Aid Off Quickly.
Slide 12A.1 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
DOMAIN MODEL: ADDING ATTRIBUTES Identify attributes in a domain model. Distinguish between correct and incorrect attributes.
CSCI-383 Object-Oriented Programming & Design Lecture 10.
THE ANALYSIS WORKFLOW  The specification document  Informal specifications  The analysis workflow  Extracting the entity classes  Functional modeling:
Chapter 17 – Object- Oriented Design. Chapter Goals To learn about the software life cycle To learn about the software life cycle To learn how to discover.
Use Case Textual Analysis
Software Engineering Zhang Shuang
CSC 107 – Programming For Science. Science Means Solving Problems  Physics – How does an atom work?
Session 3 How to Approach the UML Written by Thomas A. Pender Published by Wiley Publishing, Inc. October 5, 2011 Presented by Kang-Pyo Lee.
SWE 4743 Responsibility Driven Design with CRC cards Richard Gesick.
CS223: Software Engineering
Class Diagrams Chapter 3. Classes and Objects Classes are the descriptions –definitions Objects are the things –instances.
© 2005 by Prentice Hall Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
n Taking Notes and Keeping a Journal n Listening Skills n Working Together n Managing Your Time.
High Level Design Use Case Textual Analysis SE-2030 Dr. Mark L. Hornick 1.
Identification of Classes. Object Oriented Analysis (OOA) OOA is process by which we identify classes that play role in achieving system goals & requirements.
Computer Science 313 – Advanced Programming Topics.
Algorithms and Problem Solving. Learn about problem solving skills Explore the algorithmic approach for problem solving Learn about algorithm development.
Requirements capture: Using UML Use Cases David Millard and Yvonne Howard {dem,
Creating an ERD Part 1 Define the Problem
GRASP – Designing Objects with Responsibilities
Chapter 4: Business Process and Functional Modeling, continued
Lecture 9: Birds + BEES = CLASSES?
CMPE 280 Web UI Design and Development August 29 Class Meeting
Lecture 18: More Design Work
OO Domain Modeling With UML Class Diagrams and CRC Cards
OO Domain Modeling With UML Class Diagrams and CRC Cards
Object-Oriented Analysis
Slides by Steve Armstrong LeTourneau University Longview, TX
Software Construction Lecture 2
Class Diagrams – Part I Chapter 3.
Algorithms and Problem Solving
Presentation transcript:

CSC 213 – Large Scale Programming

Today’s Goal  Improve design skills to make usable designs  Noun extraction & UML class diagram reviewed  Connections to use for fields in diagrams detailed  Describe process to find classes’ public methods  Using textual analysis to start our search for methods  Learn to test designs & find potential errors  Discover reasons for iterative nature of this process  Indentify & fix common errors that occur in designs  Learn about using CRC cards to check design validity

Designing Programs  Designing programs just like making music  How do you get to Carnegie Hall?

Designing Programs  Designing programs just like making music  How do you get to Carnegie Hall?  How do you get to Carnegie Hall? (old joke)

Good News For The Term  Designing program ultimately like any other skill  Get many opportunities at this over term  Why is this important? Why should you care?

Good News For The Term  Designing program ultimately like any other skill  Get many opportunities at this over term  Why is this important? Why should you care?

First Step In Design: Classes  Find (& underline) nouns in requirements  Go through & eliminate any external to solution entity classes  Select entity classes (main classes in program)  Look at remaining nouns that not abstract & singular boundary classes  Find boundary classes (I/O & recording states)  From options, use singular form of abstract nouns  Adjectives describing entity classes could work, too control classes  Determine control classes (structs. & algorithms)  Needed for any plurals lacking specific number  Important algorithms that do not have a name

Next Step: Fields  Look for possessives during reading of text  Should also look for text suggesting data possession  Consider boundary classes; often used for fields  May rely on common understandings: use your brain  Can now publicize design for entire team to use  You’ve done your part: let suckers do the hard work  Use UML class diagrams to avoid writing lots of words

UML Class Diagrams

Optional Relationships  Aggregation  Used when target instances used outside of source aggregates  Car aggregates CarParts (e.g., tires, engine, lights…)  Composition  Use when objects from target used only within source composes  Chessboard composes Squares  Association  Source object has field of target type  Often used to imply source calls target's methods

 Generalization (“inheritance”)  Shows subclass-superclass relationship  Does not involve fields, multiplicities, or anything else  Makes this a different type of connection than others  Must draw all generalizations within the diagram  For implementation to be correct, these are critical  Cannot specify any other way, so vital to be shown Required Connection

Elevator's UML Class Diagram

Actions Are Verbs  Now need to find methods for all of our classes  At this point in time, many not know all methods  Important public methods described in text, however  To find methods, look for verbs in requirements  Circle each verb since it is a possible method  Since often not helpful, check all “to be” & “has” uses  Circle algorithm names and longer action descriptions  Looking through text, only public methods found  Find more methods later when looking at algorithms

Looking for verbs 1. Circle all the verbs in the text Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

Looking for verbs 1. Circle all the verbs in the text Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

Looking for verbs 2. Double-check all uses of “to be” and “has” Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

Looking for verbs 2. Double-check all uses of “to be” and “has” Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

Looking for verbs 3. Circle algorithm names & action descriptions Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

Looking for verbs 3. Circle algorithm names & action descriptions Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

Which Class Gets the Method?  Look for SRP violations for path to true laziness

Which Class Gets the Method?  Look for SRP violations for path to true laziness

Single Responsibility Principle  Goal of every class & method written  Make sure that class represents single concept  Methods perform single action & not “bucket of mud” SRP  Many benefits accrue when code follows SRP  Easier to write code, since design becomes simpler  More focused results make debugging a snap  Modifying design quicker when changes needed

No Free Cheeseburgers

CRC Cards Explained  Divide 3x5 Card into 3 parts  Class name from UML design document  Responsibilities are the methods class will need  Collaborations are classes it will interact with

Responsibilities  Initially you should start with actions you found  Add facts class knows, since these are getter methods  If class should not be responsible, move action  Instead, the action placed in class where makes sense  Make classes collaborators after action moved  Pays off in long run, but may make new classes now

Responsibilities  Initially you should start with actions you found  Add facts class knows, since these are getter methods  If class should not be responsible, move action  Instead, the action placed in class where makes sense  Make classes collaborators after action moved  Pays off in long run, but may make new classes now How to know if responsibility logical?

Seriously!

If the Responsibility Fits  Try each responsibility into following statement  Will find statement is valid only if responsibility fits The (class name) (responsibility) itself  Move actions to class that works in statement The (new class) (responsibility) (old class)

Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

So Remember

For Next Lecture  Reading for Wednesday available on Angel  How can we solve bugs BEFORE we code?  Can we prevent getting trapped and lost?  Prevent your name from becoming swear word!  Weekly assignment problem due in class Wed.  Can be found on Angel as problem #3 for Week #1