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

2. 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

3. 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

4. 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

5. 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

6. 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”

7. Not Detailed Enough

8. Way Too Detailed (¼th scale)

9. Too Detailed

10. 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

11. 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

12. 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

13. 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

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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

20. Entity Classes

21. 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

22. “Must work iteratively” !=

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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

29. 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

30. 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…

31. 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

32. 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

33. 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.

34. 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.

35. 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.

36. 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.

37. 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

38. 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

39. 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

40. 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

41. 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.

42. 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.

43. 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.

44. 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.

45. 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.

46. 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.

47. 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

48. 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

49. 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

50. 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)

51. 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

52. 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!

53. 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

54. 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?

55. 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…

56. 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…

57. 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…

58. 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…

59. 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…

60. 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…

61. 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…

62. 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

63. 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