Lecture 1: Design Rudiments
Now I’m Taking OOSE
This is a song called “Now I’m Taking OOSE” Subtitle: “Procrastinating on Lecture Prep” Woke up really early In that cold November morning Registration opened And I was trying to get my seat In OOSE And I had to beat What seemed Like five thousand other people And I did it Sucks for them And I went back to sleep Now I’m reconsidering Was this a good idea ’Cause instead of teaching Software Engineering The guy is just playing his new guitar As if I cared ’Cause I don’t I guess I’ll just pretend to laugh Ha ha ha Ha ha Now I’m taking OOSE My best friend is Roboose Working on a project I choose That sucks less than TODOOSE Now I’m taking OOSE Half of it are labs Group mate had garlic for lunch I’m sorry buddy But I don’t think that we can work under this condition Go brush your teeth And coming to think of it Maybe not even then ’Cause you know, Would it kill you to read the iteration page before to the lab? Then we don’t have to explain everything to you… Not nice, buddy Ohhh, burn Now I’m taking OOSE My best friend is Roboose Working on a project I choose That sucks less than TODOOSE Now I’m taking OOSE My best friend is Roboose Working on a project I choose That sucks less than TODOOSE Now I’m taking OOSE Now I’m taking OOSE Now I’m taking OOSE Now I’m taking OOSE
- Come up with features for TODOOSE
- Some of my ideas:
- Different kinds of users, for example, project manager, software developer, and so forth.
- Private and public lists.
- Reordering items.
- Nesting (indentation).
- Multiple lists (move tasks between lists).
- Notes & other item data.
- Synching with other providers (Apple Reminders, Google Keep, and so forth).
- Features we came up with in class:
- Vim plugin.
- Select multiple (maybe all) items as done at once.
- See what’s complete.
- Can we start writing code already?
- Consider design.
- When we talk about design we mean design of the code, not graphic design.
- And planning in general: writing pseudo-code, writing correctness proofs, and so forth.
- Unified Modeling Language (UML).
- There are many types of diagrams, we’ll only talk about Class Diagrams.
- An UML diagrams of the different types of UML diagrams (so meta!) (from Wikipedia):
- Emergent Design.
- Diagrams may merely document existing code.
- That’s what happened with TODOOSE: we started with code, and now we can reflect on what we did and draw diagrams about it.
- Diagrams are just a different perspective, and it may give you new insight.
- Big Design Up Front (BDUF) or Rough Design Up Front (RDUF).
- Complex systems.
- You’re architecting something for other people to build, for example, a plugin system (diagrams may be part of the documentation for plugin developers), or a network protocol (diagrams may help you communicate with browser developers), and so forth.
- Consider design.
- Levels of abstraction:
- Depends on your audience, and on what you want to communicate.
- Some diagrams correspond one-to-one with code.
- Some diagrams are open to interpretation and convey only high-level ideas.
- Low-level class diagram in IntelliJ for the whole
- Version annotated in class:
- Read diagram and code side-by-side:
- Constructors (parameters).
- Methods (parameters and return types).
- Dependency (dashed arrow).
- Annotations on edges, for example, «create».
- Association (solid arrow).
- Multiplicity (
*, and so forth).
- Whole-part diamond.
- Most things about the syntax of the diagram are intentional, for example, the shape of the arrowhead, whether the diamond is filled in or not, and so forth.
- See Wikipedia article for more on syntax.
- Common mistake: Relationships must be between two classes (except for inheritance, because the arrow makes the relationship clear).
- A lot of information: getters and setters,
identifierfield, extra arrows, and so forth.
High-Level Class Diagrams
- The diagram we drew in class for extended TODOOSE features:
- Classes like controllers, repositories, server, and so forth.
- Getters and setters.
- Obvious attributes, for example, identifier.
- Classes that are models.
- Sketch class diagram for some of the features we thought in the beginning of class.
- Class diagrams must match the features, the wireframes, and everything else in the project proposal.
- Nouns → Classes.
- Verbs → Methods (or Classes, if they’re sufficiently complicated).
- Common mistake:
- Abuse inheritance (“is-a” relationship).