Lecture 9: Birds + BEES = CLASSES?

Slides:



Advertisements
Similar presentations
Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
Advertisements

10 Software Engineering Foundations of Computer Science ã Cengage Learning.
Edsger W. Dijkstra Simplicity is prerequisite for reliability.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
1 Lecture 5 Introduction to Software Engineering Overview  What is Software Engineering  Software Engineering Issues  Waterfall Model  Waterfall Model.
CSC 395 – Software Engineering Lecture 9: Testing -or- How I Stopped Worrying and Learned to Love the Bug.
1 CS1001 Lecture Overview Object Oriented Design Object Oriented Design.
CSC 395 – Software Engineering Lecture 21: Overview of the Term & What Goes in a Data Dictionary.
Domain Modeling (with Objects). Motivation Programming classes teach – What an object is – How to create objects What is missing – Finding/determining.
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
Proofreading & Revising
CSC 213 – Large Scale Programming Lecture 2: Object-Oriented Analysis & Object-Oriented Design.
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
CSC 213 – Large Scale Programming Lecture 3: Object-Oriented Analysis.
Detailed design – class design Domain Modeling SE-2030 Dr. Rob Hasker 1 Based on slides written by Dr. Mark L. Hornick Used with permission.
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.
1 Analysis Extracting from Use Cases to Create Diagrams.
CSC 395 – Software Engineering Lecture 13: Object-Oriented Analysis –or– Let the Pain Begin (At Least I’m Honest!)
CSC 213 – Large Scale Programming. Today’s Goal  Improve design skills to make usable designs  Noun extraction & UML class diagram reviewed  Connections.
Approaching a Problem Where do we start? How do we proceed?
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,
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Slide 12A.1 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
CSC 213 – Large Scale Programming. Today’s Goal  Understand why testing code is important  Result of poor or no testing & embarrassment caused  Learn.
CS223: Software Engineering
1 COS 260 DAY 12 Tony Gauvin. 2 Agenda Questions? 5 th Mini quiz –Chapter 5 40 min Assignment 3 Due Assignment 4 will be posted later (next week) –If.
Computer Science 313 – Advanced Programming Topics.
DATA FLOW DIAGRAMS.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
MKT 101 – Introduction to Marketing. Already quit & blogged how much you suck How My Homies Roll.
What is qualitative data analysis? Different approaches to analysing qualitative data.
Code Simplicity: Software Design In Open Source Projects Max Kanat-Alexander
Principles of Programming & Software Engineering
Elaboration popo.
IL Marking Get out your CPU / Memory answers Swap with someone else
Chapter 4: Business Process and Functional Modeling, continued
Object-Oriented Analysis and Design
Sequence Diagrams.
Chapter 11 Object-Oriented Design
Unified Modeling Language
Data Abstraction: The Walls
Lecture 18: More Design Work
Week 10: Object Modeling (1)Use Case Model
Object oriented system development life cycle
Abstract descriptions of systems whose requirements are being analysed
Sequence Diagrams.
Programming – Touch Sensors
Design by Contract Fall 2016 Version.
Object-Oriented Analysis
Objects First with Java
The Object-Oriented Thought Process Chapter 05
Introduction If you have got a call for an Agile testing interview, then congratulations are in order. You may be feeling nervous, but it sure to be felt.
Baisc Of Software Testing
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Project Management How to access the power of projects!
Cornell Notes Note-taking strategy that will
Applying Use Cases (Chapters 25,26)
Introduction – “Writing A Program”
Use Case Analysis – continued
Test Cases, Test Suites and Test Case management systems
Bellwork 8 minutes 7 minutes 9 minutes 10 minutes 12 minutes
Cornell Notes Note-taking strategy that will
Chapter 1: Creating a Program.
Presentation transcript:

Lecture 9: Birds + BEES = CLASSES? CSE 542 – Software Engineering Concepts

What Have We Done? Figured out what clients wants project to do Elicited client’s needs & wrote into documents Collect important terms & definitions in dictionary Wrote user stories to record work that could occur User stories often written; many never implemented As conversation continues, stories added & changed Each development iteration (sprint), choose top stories

What Have We Done? User stories examined for problems & questions Looked over and acted out stories to find more roles Reviewed desires and actions to make sure they align Continued discussions to ensure testable results occur Asked “what about…?” to see if other stories exist Reviewed & chose most important stories for iteration Limit future problems by choosing stable areas for work

Software is Unvisualizable Picturing software is difficult Need to capturing all possibilities in single diagram Static & dynamic view of program needed Unified process (UML) offers many solutions Many types of diagrams included within UML Each provides insight into different aspects of system Useful for waterfall-style lifecycles & its planning stages Can be helpful, but only when you do not suck at design

Communication Documents used to communicate ideas to team Programs’ uses detailed using use cases/user stories GUI drawings show how client imagines program Data dictionary outlines ideas required by GUI If documents disagree, communication has failed Error can

Communication Breakdown How to handle differences in these documents? Completely rely on one & define it as “controlling” Find common ground that exists in the documents Look through notes to reconstruct what happened Restart process from scratch & develop single answer Better idea: verify documents with each other Similar terms describe work across stories or use cases No problem acting out scenarios with GUI diagrams Pre- & post-conditions match without any “loops”

Not Detailed Enough

Way Too Detailed (¼th scale)

Too Detailed

Back to the Real-World Important work is never completed in single pass Typos are universal & only found by proofreading More eyes are better; easy to miss your own mistakes Should allow revisiting; improvements possible any time All of this means work is better given more time But deadlines often set, so plan accordingly

Find the Classes Designing classes next step in process Could help find & fix inconsistent requirements Requirements clarified if you do not understand them Outlining classes makes coding easy Already defined methods to call from other classes Will provide chance to do some easy debugging

Find the Classes All designs should use requirements as the source Documents needs for the entire project If it is not required, why spend time (= $$$$)? Need project to be traceable back to requirements So perform textual analysis on use cases/user stories Only a first step, but useful should matter go to courts Be prepared for change, few will make final design Provides useful starting place, however, so worth it

Noun Extraction Finds entity class candidates to be used in design Initial pass may (will) not find all entity classes Some classes not used even though found early on Provides strong hints for other needed classes Many nouns not needed, must actively prune list Eliminate any & all classes external to program “External” & “program” unspecific – depends on situation

Designing Elevator Controller 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.

1. Underline the nouns in the requirements Noun Extraction 1. Underline the nouns in the requirements 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.

Noun Extraction 1. Underline the nouns in the requirements 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.

Noun Extraction 2. Eliminate nouns external to the problem 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.

Noun Extraction 2. Eliminate nouns external to the problem 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.

3 “Types” of Classes Unified Process concept simplifies design process Entity classes hold long-lived data driving program Input & output handled by boundary classes Control classes do complex processing in program "Types" not real, exist for design purposes only A class is a class is a class within Java & program But they can help checking design covers all needs

Entity Classes

Entity Classes Focus on entity classes & ignore (for now) others Since not things, prune abstract (non-physical) nouns Ignore communication – rarely drives programs flow Thinking will change -- must work iteratively Writing & debugging easier given good design Minutes spent in design saves hours in coding & testing

“Must work iteratively” !=

Find Entity Classes 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.

Find Entity Classes 1. Ignore abstract (non-physical) nouns 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.

Find Entity Classes 1. Ignore abstract (non-physical) nouns 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.

Find Entity Classes 2. Only use singular form of each noun 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.

Find Entity Classes 2. Only use singular form of each noun 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.

Our Entity Classes Button Floor Elevator 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. Button Floor Elevator

Boundary Classes These classes will perform all input & output May have many details which are all independent Only 1 detail known: it will change before its over Make class for each detail & limit future rewriting Make life easier, start from simplest ideas Easy to combine simple classes to create complex ones Taking a complex class and breaking up far harder Rarely rewrite complex classes because of difficulty… … instead often just throw out & start from scratch

Skipping Boundary Classes Boundary classes may duplicate primitive type Can eliminate this class; it adds nothing to design Code will have primitive hard-coded everywhere Saves writing javadoc for class, field, getter & setter When needs change and class is now needed…

Skipping Boundary Classes Boundary classes may duplicate primitive type Can eliminate this class; it adds nothing to design Code will have primitive hard-coded everywhere Saves writing javadoc for class, field, getter & setter When needs change and class is now needed… Find & replace all primitives littering code Scan entire program to track down all I/O for this data Retest entire application to ensure no bugs created

Skipping Boundary Classes Boundary classes may duplicate primitive type Can eliminate this class; it adds nothing to design Code will have primitive hard-coded everywhere Saves writing javadoc for class, field, getter & setter When needs change and class is now needed… Find & replace all primitives littering code Scan entire program to track down all I/O for this data Retest entire application to ensure no bugs created Industry standard is to just write class at start

Find Boundary Classes 1. Reexamine abstract nouns & keep if used in I/O 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.

Find Boundary Classes 1. Reexamine abstract nouns & keep if used in I/O 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.

Find Boundary Classes 2. Only use singular form of each noun 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.

Find Boundary Classes 3. There is no step 3 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.

I Know Boundary Classes! 3. There is no step 3 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. Movement Request Illumination

Control Classes Non-obvious algorithms using many classes Rule of thumb: obvious algorithm have name Control classes already exist for named algorithms Possibly created for plurals ignored previously Can use array or enum, if exact number known Else, design needs structure to hold instances

Control Classes Non-obvious algorithms using many classes Rule of thumb: obvious algorithm have name Control classes already exist for named algorithms Possibly created for plurals ignored previously Can use array or enum, if exact number known Else, design needs data structure to hold instances

Control Classes Non-obvious algorithms using many classes Rule of thumb: obvious algorithm have name Control classes already exist for named algorithms Possibly created for plurals ignored previously Can use array or enum, if exact number known Else, design needs data structure to hold instances Topics from 116 & 250 used over & over again

Finding Control Classes! 1. Reexamine plurals & keep when necessary 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.

Finding Control Classes! 1. Reexamine plurals & keep when necessary 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.

Finding Control Classes! 2. Eliminate if constant number (array) needed 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.

Finding Control Classes! 2. Eliminate if constant number (array) needed 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.

Finding Control Classes! 2. Eliminate if constant number (array) needed 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.

Finding Control Classes! 3. Select data structure to use for each plural 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.

Finding Control Classes! 3. Select data structure to use for each plural 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. PriorityQueue

Now Assign Fields Designing classes next step in process For each class, determine fields Link classes that work together so easy to code When done well, coding becomes relatively simple What should be fields & how can we know? Since they are abstract, boundary classes often fields Control classes often fields; something must use it Read text again: look where noun possesses another

Association Relationship Bidirectional relationships (shown as ) Objects on either end of line refer to the other Very rare to have this; should not often be seen When this does occur, double-check your design Unidirectional relationships (shown as ) Access goes one way: source refers to the target Important fields only need to be identified this way Remember: this simplifies coding and is common idea

More Connections Aggregation Composition Relationship shows source instance “has-a” target Implies source is collection of targets Usually via formal collection (List, Tree, Set, …) Composition Stronger form of aggregation relationship Implies target exists entire for use by source Can be via a collection (Chessboard composes Squares) Functional compositions also exist (Car composes its parts)

Single Responsibility Principle Goal of every class & method written Make sure that class represents single concept Methods perform single action & not “bucket of mud” 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

Win Users & Influence People Only a few minutes to make first impression Do not lose time by making user read manuals Entice user with an clear, obvious utility Get users to payoff as quickly as possible Make their journey’s first steps obvious Common metaphors make it easy to start Look familiar? This slide is paraphrased from the UI lecture!

Avoid Fear & Loathing Artifacts nearly always written exactly once Ignore writers viewpoint – they will never use work Focus on the many others reading & using artifacts Save time in long run by using common metaphors The quicker they understand the more they like you Focus on user & avoid annoying questions Remind them that their work will be handed to people less talented than them. If they need to convince the code monkeys of the workability of their design, they lose time

Intuitive Is Key Making users think is preying on their weakness Time spent thinking == time cursing you out Users assume that everything has a purpose Men’s nipples, appendix, Trump still get discussed Users assume a purpose, why else would it exist? Unused methods & parameters create guessing game What is the meaning of method’s return value?

Make It Intuitive Remain consistent when using metaphor: Employee.getFirstName() Employee.fileAnnualReport() Employee.addToDatabase() Employee.initialize() Slide could just as easily be for classes, UI, use cases, more…

Make It Intuitive Remain consistent when using metaphor: Employee.getFirstName() Employee.fileAnnualReport() Employee.addToDatabase() Employee.initialize() Slide could just as easily be for classes, UI, use cases, more…

Make It Intuitive Easiest to follow when names & usage are parallel String.compareTo(String str) String.compareToIgnoreCase(String str) Slide could just as easily be for classes, UI, use cases, more…

Make It Intuitive Easiest to follow when names & usage are parallel String.compareTo(String str) String.compareToIgnoreCase(String str) String.equals(String str) String.equalsIgnoreCase(String str) Slide could just as easily be for classes, UI, use cases, more…

Make It Intuitive Easiest to follow when names & usage are parallel String.compareTo(String str) String.compareToIgnoreCase(String str) String.equals(String str) String.equalsIgnoreCase(String str) String.regionMatches(boolean iC,String str) String.regionMatchesIgnoreCase(String str) Slide could just as easily be for classes, UI, use cases, more…

Make It Intuitive Easiest to follow when names & usage are parallel String.compareTo(String str) String.compareToIgnoreCase(String str) String.equals(String str) String.equalsIgnoreCase(String str) String.regionMatches(boolean iC,String str) String.regionMatchesIgnoreCase(String str) Slide could just as easily be for classes, UI, use cases, more…

Make It Intuitive Easiest to follow when names & usage are parallel String.compareTo(String str) String.compareToIgnoreCase(String str) String.equals(String str) String.equalsIgnoreCase(String str) String.regionMatches(boolean ignoreCase, …) String.regionMatchesIgnoreCase(String str) Slide could just as easily be for classes, UI, use cases, more…

Make Their Lives Easier [P]erfection is attained not when there is nothing left to add, but when there is nothing left to remove Move to the next slide to better make M. de Sant-Exusperry’s point

Make Their Lives Easier [P]erfection … is nothing left to remove Discuss concerns over complexity of GUI designs in quizzes; remind students of the quote from the little prince Discuss quizzes (to be handed back at end) and my reasoning for the results