COMPUTER SCIENCE 2P05 Programming Languages Planning, object-orientation... stuff? Brock University Brock University (Planning, object-orientation... stuff?)Programming Languages 1 / 26
Object-Oriented(OO) Design We know the basic approach to writing OO programs, right? First and foremost: Decomposition into classes Definition of functionality Grady Booch formalized much of what’s now standard procedure for OO design, including the creation of OO modeling languages. His approach focused on: Identifying classes Identifying functionality Identifying relationships (any of this seeming a bit... familiar?) Brock University (Planning, object-orientation... stuff?)Programming Languages 2 / 26
Responsibility-Driven Design An early-ish (early 90’s) approach was to delegate responsibilities (e.g. for knowing and doing ) to classes. A class would be responsible for its own operations ◮ Of course, this relates to the object being the one with the corresponding state information Anything else relying on that behaviour would make a request of the class ◮ We can envision many programs as largely being behaviours delegating to other behaviours Design would thus require characterizing a task in terms of its desired behaviours (at the system level, and at the component level). When allocating members, we need to balance coupling and cohesion (recall: we want loose coupling, and high cohesion). Brock University (Planning, object-orientation... stuff?)Programming Languages 3 / 26
Analysis Prior to absolutely any coding at all, unambiguously establishing all requirements would be necessary. (seriously, anyone else getting deja vu?) One common step would be an analysis , which includes: Defining overall behaviour Identifying major use cases ◮ Top-level behaviours a user might invoke/select Identifying actors ◮ People or systems external to the project, that participate in use cases Brock University (Planning, object-orientation... stuff?)Programming Languages 4 / 26
Use Cases? There are two things one might mean when using the term Use Case (in a software context): You covered Use Cases in 1P03: ◮ Describe the action/goal ◮ Actors? ◮ A brief description ◮ Preconditions (what must be true for the use case to apply) ◮ Postconditions (what’ll be true after it finishes) ◮ Summary of steps ◮ Includes (dependencies on other use cases) ◮ Extensions (variations or alternate versions) But there are also Use Case Diagrams to show dependencies or flow between Use Cases ◮ These give a broader view of how a system operates Brock University (Planning, object-orientation... stuff?)Programming Languages 5 / 26
Use Cases Use Case: Checking out library book Actors: Patron Summary: User scans a book, to be returned by a later (specified) date. Preconditions: Current membership; no owed fines Postconditions: Book in patron’s custody; book has due date Steps: 1. Swipe library card 2. Book is scanned to retrieve record 3. If book is not reserved, associated with patron account 4. Due date is generated based on date and type of book 5. Receipt is printed with due date Includes: Authenticate patron Extensions: 1–3 Renewal: 1. Log into website 2. Retrieve current loans 3. Assign new due date Brock University (Planning, object-orientation... stuff?)Programming Languages 6 / 26
Use Case Diagram Brock University (Planning, object-orientation... stuff?)Programming Languages 7 / 26
Design? Hold up. It’s obvious what we’re doing. This is the waterfall model It is, and it isn’t. Various software development life-cycles have arisen and fallen out of favour, largely to accommodate (or help create) different applications, languages, usages, etc. You can’t talk about languages without considering how they’re used, nor can you talk about how to write software without considering the tools. Though there are numerous software design philosophies, there are many common elements that come up frequently. What we’re really doing today is looking at those aspects that you’re likely to touch on with any significant OO-based design. Brock University (Planning, object-orientation... stuff?)Programming Languages 8 / 26
Design! This is where we’ll start diverging from first-year. There, you filled out CRC cards. We aren’t interested in those, but clearly the principle is still useful: We need to establish classes and responsibilities, right? We need to define relations between classes ◮ Though we’ll now start making distinctions betwen associations and dependencies We also need to introduce a new concept to our modeling: lifelines . Brock University (Planning, object-orientation... stuff?)Programming Languages 9 / 26
Design Is that like extent? As discussed earlier, extent is the lifespan of a variable/object. For how long will that piece be available to the enclosing object? A lifeline (or lifespan) denotes two points: ◮ When an object is instantiated, with relation to the lifespans of other, related, objects ◮ When that object is deallocated Consider how many times you’ve gotten NullPointerException s, because you forgot to initialize a variable? Brock University (Planning, object-orientation... stuff?)Programming Languages 10 / 26
Sequence diagrams Brock University (Planning, object-orientation... stuff?)Programming Languages 11 / 26
What about actual classes? How do we model the classes themselves? Either in terms of structure, or behaviour The classic structural example is class diagrams ◮ Start similar to CRCs ◮ May show inheritance with hollow arrows (a realization includes a dashed line) ◮ Aggregation is shown via hollow diamond; composition via filled diamond ◮ An association may be shown via an arrow (or just a line); a dependency uses a dashed line ◮ Honestly, the diagrams here and here are pretty good The sequence diagram and use case diagram are good examples of behavioural diagrams Brock University (Planning, object-orientation... stuff?)Programming Languages 12 / 26
Recognizing relationships Two of the common concerns are distinguishing between association, aggregation/composition, and inheritancce; and between specifically aggregation and composition. For the former: ◮ Association is a uses relationship ◮ Aggregation is a has a relationship ◮ Inheritance is an is a relationship For the latter: ◮ If a member component could reasonably exist without the enclosing object, it’s aggregation ◮ Otherwise, it’s composition ◮ e.g. a course may contain any number of students, who are free to take other courses ⋆ A department is a composition of several courses, that wouldn’t really make sense independently Brock University (Planning, object-orientation... stuff?)Programming Languages 13 / 26
Why are we talking about this? Technically, we’ve been touching on the Unified Modeling Language (UML), but that isn’t really the point. Once you can start formalizing object design and relationships (through whatever mechanisms), you can also start discussing Design Patterns A Design Pattern is somewhat like a programming trope: a time-tested stereotype of how you could go about some piece of a task (or data representation). A complete solution, then, may consist largely of various patterns combined together. Brock University (Planning, object-orientation... stuff?)Programming Languages 14 / 26
(A quick note on design patterns) When you get to 3P91, you’ll talk about these in vastly more detail. We just need to understand enough to get context on how it affects our choice of language (and vice versa). Similarly, the concept of design patterns is tightly connected to various other programming idioms Brock University (Planning, object-orientation... stuff?)Programming Languages 15 / 26
What is a design pattern? It’s a ‘best-practices’ way to standardize a common relationship. Let’s look at a very common one: Iterator Note that the Iterator pattern doesn’t solely refer to the iterator object itself, but also includes the relationship with the iterated collection The client associates with both the aggregate (collection) and the iterator ◮ The collection creates the iterator ◮ The iterator has a dependent association with the collection What would we expect in the class diagram for the iterator? What would the sequence diagrams for the client, collection, and iterator look like? Brock University (Planning, object-orientation... stuff?)Programming Languages 16 / 26
Model View Controller We arguably should have started with this. MVC is the design pattern. It even predates ‘design pattern’ as a phrase. To best understand this, let’s instead build up to it. We’ll start by looking at a trivial program: notepad. Brock University (Planning, object-orientation... stuff?)Programming Languages 17 / 26
Direct editing Here, we’re directly editing the data There can be only one view/format of the data There are no safeguards What if we wanted to see a better view? (e.g. rendering a markup language) Brock University (Planning, object-orientation... stuff?)Programming Languages 18 / 26
Abstracting display Now, some view transforms data into what we see ◮ It might filter data, render, etc. We now can have multiple views But we still need to edit data directly. Is that how word processors work? Brock University (Planning, object-orientation... stuff?)Programming Languages 19 / 26
Recommend
More recommend
