1. Lecture 2: UML Class DIAGRAM
CSC 213 – Large Scale Programming
Give warning that this is less cut and dry. Explain that most will not pay attention, but will be big win for those that do…
Lecture 2: UML Class DIAGRAM

2. Today’s Goal Learn Unified Process to design programs
Understand what are the “types” of Java classes
Methods of selecting the potential classes
How these designs presented for others to use

3. Classroom Development
Always start from scratch
Know all requirements from the start
And requirements will not change
Coding begins immediately at start
Projects are trivial jokes in real-world
If lasts 3 weeks, projects “very large”
Code cannot be reused
Never look at again, anyway

4. Why These Phases Matter

5. Our Goal

6. Our Nemesis

7. Electric Boogaloo Developing automated DJ for clubs
Plays music at party
Songs will be chosen using party-goers requests
Removes people who do not belong
Colleague already developed requirements
Now on vacation for next few months

8. Electric Boogaloo User Stories
User wants hip-hop Partier realizes there is a real lack of hip-hop. They request a hip-hop song be played. The system randomly selects a song from its list of hip-hop songs and adds it to the song queue. When removed from the queue, the system plays the song and displays its name and artist.
(Similar stories exist for electronica & Stevie Wonder)

9. Oops… Forgot Something
User wants Justin Bieber A user requests a Justin Bieber song be played. The system takes their picture and sends it to the security guards.
By looking over our use cases, we can check if we forgot something. In this case, we forgot a means to eject the unacceptable.

10. What’s Next?

11. Find the Classes Designing classes next step in process
Could help find & fix inconsistent requirements
Unclear requirements clarified and made easy
Outlining classes makes coding easy
Already know methods to call from other classes
Will provide chance to do some easy debugging

12. 3 “Types” of Classes Unified Process concept simplifies designs
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

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
Start with plain English requirements
Should be easy & comes with most assignments

14. Entity Classes Highlight all nouns that you find in requirements
These nouns are candidate classes for application
Many candidates not needed, so can prune list
Eliminate all those classes external to program
Ignore (for now) some ideas that not entity classes
Since not things, prune abstract (non-physical) nouns
Nouns used for communication rarely drive program
Thinking will change -- must work iteratively
Quicker to write & easier to debug a good design

15. Boundary Classes These classes will perform all input & output
May have many details which are all independent
Only 1 constant known: these details will change
Class for each independent detail to limit rewriting
Make life easier, start design at 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

16. 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 now needed…

17. Control Classes Non-obvious algorithms using many classes
Rule of thumb: obvious algorithm have name
Control classes already exist for named algorithms
Needed when requirements include plural nouns
Can use array or enum, if exact number known
Else design needs class to hold these instances

18. Find the Classes Designing classes next step in process
For each class, determine fields & methods
Link classes that work together so easy to code
When done well, coding becomes relatively simple
Must communicate design in clear way to others
All this information and more highlighted
Provides vital check that can often find bugs
Will do this by drawing pretty pictures

19. Why Draw Classes? Pictures used to share ideas easily
Gets everyone up & coding at once
Group spends lab watching you code…
…or get suckers to work while you relax

20. How To Design Classes Classes represent things
Start by finding all nouns in requirements
More art than science and highly iterative
From initial classes, some nouns external to system
Need boundary & control classes even if not listed
As you go along will develop rules of thumb
Good judgment comes from experience, and experience comes from bad judgment.
– Fred Brooks

21. Start Your (mp3) Engines
Classes needed
User wants hip-hop Partier requests a hip- hop song be played. Randomly select a song from the list of hip-hop songs & add it to the song queue. When removed from the queue, play the song & displays its name and artist.

22. name : type UML Class Diagrams Classes drawn in 3-part box
Class name written in top portion of box
Attributes (fields) written in middle portion
Operations (methods) written in bottom portion
Language-independent diagrams used in this
Work with & used by many languages
All variables written using following format :
name : type

23. More Relationships Generalization for extends & implements
Use open triangle ( ) from subclass to superclass
Class only needs to list methods & field class declares
Solid line for extends; dashed for implements
Important fields drawn as associations
Use open arrow () to fields class
In middle section of class, do not list field again

24. More Relationships Aggregation Composition
Source field is data structure holding target instances
Source end has open diamond part of connection
Used when target instances used outside of source
Car aggregates CarParts (e.g., tires, engine, lights…)
Composition
Similar to aggregation (implies data structure of targets)
Use when objects from target used only within source
Chessboard composes Squares

25. Drawing Relationships
Nearly all relationships must be labeled
Except generalizations; means different thing
Near midpoint of arrow, specify name of field
Also specify numbers involved on each side
Number written down on each end of the link
Can be specific number of objects included
Could be some range of numbers like ‘2..5’
+ means 1 of more objects required to be used
Use Kleene’s star ‘*’ for 0 or more objects
Make comment about redacting any jokes about this
Add that this is also an excellent way of checking for bugs:
* Should have a 1 involved in each relationship
* If number is unknown, this cannot work

26. What About the Methods? Uses should become public methods
Start assuming this until proven otherwise
Requirements verbs become initial method listing
Pre- & post-conditions should be also be added
Think and then add to javadoc comments
Private methods may add to the preconditions
Always specify assumptions explicitly
Will save TONS of debugging time

27. For Next Lecture Link to article for Monday on lecture page
Reading for Monday available on Angel
What else can we do before coding?
Are there more tricks that enables our laziness?
How to trick smarter suckers into doing our work?