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

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

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

Why These Phases Matter

Our Goal

Our Nemesis

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

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)

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.

What’s Next?

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

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

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

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

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

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…

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

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

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

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

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.

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

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

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

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

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

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?