- static vs. non-static
- constructors in subclasses do not inherit and must call superclass
The Development Team
Large projects are more of a challenge of organization and communication than they are of "programming". The development team may be organized into roles corresponding to the development phases (analyst, designer, programmer, tester, etc.), but perhaps a more crucial distinction is between the customer who is a domain expert and the developer who knows mainly about software. Generalizing, we have content specialists (customer, user, artist, librarian, manager) and functionality specialists (programmer, tester, manager) and one of the main goals of software engineering must be to bridge the Great Divide between these two spheres.The Methods and Tools
You will be learning in this course many current state of the art methods and tools used in software engineering. "Front end" tools are documentation tools designed to help content specialists and programmers talk to (and understand) each other. We will use a subset of UML, a popular diagramming notation for requirements analysis and software design. A drawing tool called Dia available on our Linux systems is good at writing UML diagrams. Our Dia diagrams will be incorporated into HTML analysis and design documents."Back end" tools emphasize synthesis of solutions based on designs. We will use a graphical user interface builder to generate user interfaces, the "make" program to compile many files containing many persons' work together, and the "cvs" source code revision control system.
Some quotes on tools, relevant to software engineering
- Software development is like war:
- "We shall not fail or falter; we shall not weaken or tire.
Neither the sudden shock of battle nor the longdrawn trials
of vigilance and exertion will wear us down. Give us the
tools and we will finish the job." -- Sir Winston Churchhill
- Do you only need one or two tools?
- "An apprentice carpenter may want only a hammer and saw, but a master craftsman employs many precision tools. Computer programming likewise requires sophisticated tools to cope with the complexity of real applications, and only practice with these tools will build skill in their use." -- Robert Kruse
- Do you only need one or two tools?
Why is Software Engineering Crucial?
Because the larger a program gets, and the more features you add, the more bugs you get. Why? Because things get too complex for us to handle. Until we can solve this unsolvable puzzle, Moore's Law is limited or revoked by our inability to utilize hardware, just as we are unable to utilize our own brain (wetware).
Belady-Lehman observed:
[D. Berry, The Inevitable Pain of Software Development,
Monterey Workshop 2002]
So, Software Engineering is All About Pain
Software Engineering, it turns out, is mainly about pain. Dan Berry, one of software engineering's luminary founding fathers, had this to say last October about software engineering methods:Each method, if followed religiously, works. Each method provides the programmer a way to manage complexity and change so as to delay and moderate the B-L upswing. However, each method has a catch, a fatal flaw, at least one step that is a real pain to do, that people put off. People put off this painful step in their haste to get the software done and shipped out or to do more interesting things, like write more new code. Consequently, the software tends to decay no matter what. The B-L upswing is inevitable.Dr. Berry goes on to give the following examples:
| Software Method | Pain |
|---|---|
| Build-and-fix | doesn't scale up |
| Waterfall Model | it is impossible to fully understand and document complex software up front |
| Structured Programming | Change is a nightmare: patch or redesign from scratch |
| Requirements Engineering | Haggling over requirements is a royal pain. |
| Extreme Programming | Writing adequate test cases is a pain |
| Rapid Prototyping | We can't bear to throw away the prototype! |
| Formal Methods | Writing formal specification, and verifying it, may be a pain. Changing requirements is definitely a pain. |
| Code inspections | Documentation prep for inspection is a pain; nobody wants to be inspected. |
| "Daily Builds" | Testing, regression testing, and possibly reworking your latest change to not break someone else's latest change is a pain. |
Object Modeling
Before we do object oriented programming, we do object oriented modeling. A model is a representation of a real-world process or concept in graphic or narrative form. Your goal in modeling is to create a model space that closely corresponds to reality. Your goal in modeling is also to discern what parts of reality are relevant to the application at hand. What the application needs to do, determines which parts of information to represent, and how to store it. Light has been modeled variously as particles or waves; people might be modeled as (SSN, income) number pairs, or as pliable 3D solid bodies, etc.
| Reality | Model space | |||
|---|---|---|---|---|
 |
|
An object is an application-specific group of related information, used to represent some part of a model. "Numbers" or "arrays" are not application-specific, but "rate schedules" or "teams" might very well be objects in applications that work with those ideas.
Fields and Methods
The information in an object is called a field (a.k.a. member variable). Fields are tightly controlled and modified according to the rules of the application domain from which that object originates (laws of physics, corporate policies, etc.). This control is achieved by means of encapsulation: you can't get at the information directly, you must go through a public interface consisting of a set of methods (a.k.a. member functions).
| Reality | Model space | ||||
|---|---|---|---|---|---|
|
|
There are lots of different kinds of cars that could be represented by the same class, and share the same code. Classes define attributes and methods which form some kind of approximation or projection of the real world thing or idea. What attributes you choose depend on what the application will need to do with the objects. A set of methods forms a public interface to the objects of a given class; attributes are not accessed directly.
A method is a function that:
- operates on an instance
- can read or write information from the instance's fields
- can call other methods to do part of its work
- can ask another object to do part of its work (via its public interface)
lecture #3 began here
Book Learning!
Read: Lethbridge Chapter 2!It is titled "review of object orientation", but it is OK if it is not review for some of you.
Book Learning!
Read: Lethbridge Chapter 7! This is all about user-centered design and use cases, which I believe should come first as a way of trying to identify the classes we will need for OO class design later.
Homework #1
Let's get started!Boehm's Top 10
Barry Boehm is one of the titans of the software engineering field, a leading proponent of such concepts as the "Spiral Model".- Finding and fixing a software problem after delivery of the product is 100 times more expensive than defect removal during requirements and early design phases.
- Nominal software development schedules can be compressed up to 25% (by adding people, money, etc.) but no more.
- Maintenance costs twice what development costs.
- Development and maintenance costs are primarily a function of size, e.g. the number of source lines of code, in the product.
- Variations in humans account for the greatest variations in productivity.
- The ratio of software to hardware costs went from 15:85 in 1955 to 85:15 in 1985 and continues to grow in favor of software as the dominant cost.
- Only about 15% of the development effort is in coding.
- Application products cost three times as much per instruction as individual programs; systems software products costs nine times as much.
- Walk-throughs catch 60% of the errors
- Many software processes obey a Pareto distribution:
- 20% of the modules contribute 80% of the cost
- 20% of the modules contain 80% of the errors!
- 20% of the errors consume 80% of the repair budget
- 20% of the modules take 80% of the execution time
- 20% of the tools are used 80% of the time
Use Cases and Class Extraction
You can identify classes from a software specification document by looking for "interesting" nouns, where interesting implies there are some pieces of information to represent in your application, and operations to perform on them. You can also identify classes by developing use cases from the specification document. Use cases are formatted descriptions of "discrete" tasks. By "discrete", we mean an individual standalone thing a user does while using the system.If you look through the tasks mentioned in a specification document, you can identify a set of candidates. Example candidate tasks for a "wargame":
- Combat
- Roll dice
- Move pieces
- Perform the Missions Phase
Example candidate tasks for Parker Brothers' Monopoly game:
- Buy property
- Roll dice
- Move piece
- Count money
Entire books have been written about use cases. Use cases are also described in Chapter 11 of the Unicon book; some of today's examples may be found there.
Terminology
- actor
- role that an external entity plays in a system
- use case (or just "case")
- depiction of some aspect of system functionality that is visible to one or more actors.
- extension
- a use case that illustrates a different or deeper perspective on another use case
- use
- a use cases that re-uses another use case.
A use case is a typical sequence of actions that an actor performs in order to complete a given task.Now we will expand on the discussion of use cases, use case diagrams, and look at examples.
Use Case Descriptions
Drawing an oval and putting the name of a task in it is not very helpful by itself, for each use case you need to add a detailed use case description. Your first homework assignment is to "go and do this" for your semester project.Section 7.3 of the text explains the format of use case descriptions. Each use case has many or all of the following pieces of information. The items in bold would be found in any reasonable use case description.
- Name
- The name of the use case.
- Actors
- What participants are involved in this task.
- Goals
- What those people are trying to accomplish.
- Preconditions
- The initial state or event that triggers this task.
- Summary
- Short paragraph stating what this task is all about.
- Related use cases
- What use cases does this use case use or extend? What uses/extends this use case?
- Steps
- The most common sequence of actions that are performed for this task. Lethbridge divides actions into two columns: user input is given in the left column, while system response is given in the right column. The two column format is optional, but saves on paper and may improve clarity. The steps are numbered, so there is no ambiguity in using both columns on each line.
- Alternatives
- Some use cases may vary the normal sequence of steps.
- Postconditions
- what does this task produce?
Open File |
Lethbridge-style two column format is nicely motivated in Example 7.2 from the text, which has enough steps to where two columns saves enough space to matter. When you start having trouble fitting the whole use case description on a page, there are substantial benefits to a compact format.
Exit parking lot, paying cash |
Lethbridge Example 7.3 gives you one more look at use case descriptions. This one is for a library management application.
Check out item for a borrower |
Now, ask yourself: why is Dr. J convinced that use case descriptions are a vital software engineering job in the initial stages of requirements analysis? The first person to tell me can stop by for a delicious San Saba chocolate covered almond in my office.
Use Case Diagrams and Examples
One reason to do a use case diagram is simply to summarize or catalog what tasks are part of the system; a sort of table of contents. But the main reason use case diagrams exist is in order to show who does what, when different users (actors) participate in different (overlapping) tasks. If you only have one actor, or there are no tasks in which multiple actors interact, there may be no reason that you have to do a use case dialog.Consider the textbook example, Figure 7.1.
There are three actors (Registrar, Student, Professor), and there are five use cases. The "Find information about course" use case is vague and probably the three actor types can find out different information from each other. They are not typically involved in the same instance of finding out information about a class, so the example could be better.
Figure 7.2 illustrates a bunch of more exotic use case diagram items, namely actors and use cases that use or extend other actors and use cases.
Unlike last semester's textbook, Lethbridge covers the main thing about use cases fairly well, which are the use case descriptions. For use case diagrams, we need to look for or construct some more examples. Lethbridge he omits one interesting category of actor in use case diagrams, namely: external system actors. A computer program may interact with external entities that are not humans; they may be remote database servers, for example.
Figures 11-1 and 11-2 of the Unicon book give some more examples of use cases.
lecture #4 began here
Class Diagrams
Class diagrams are the "meat and potatoes" of object-oriented analysis and design. We will begin our discussion of them today, and continue next week. Class diagrams describe more detailed, more implementation-oriented things than use case diagrams.Class diagrams can present varying levels of detail about the classes in them. Some class diagrams may have nothing more than the class name for each class; others may hold the full list of fields and methods. When more space is taken by class details, there is room for fewer classes per diagram, so you often have "overview diagrams" that show many classes and their connections, supplemented by "detail diagrams" that show more information about closely related classes.
Associations
Perhaps the main purpose for class diagrams is to identify and depict relationships between objects that will be needed in the running system. An association is the word we use for such a relationship. We draw a line between the rectangles for classes to depict an assocation. There are three major types of associations:- inheritance
- aggregation
- user defined
- aggregation
Inheritance: the Un-Association
We have discussed how inheritance is not really an association, it is a relationship between kinds of things, in the design and maybe in the programming language type system, whereas associations are relationships between instances (objects) at run-time. Inheritance is so vital that many class diagrams focus specifically on a large inheritance class hierarchy, similar to a biological taxonomy of species. Inheritance is usually a static feature of a design, although there exist languages in which instances can change who they inherit from at runtime.
Here is an
example class hierarchy from the Lethbridge book (chapter 2):
Aggregation: the Simplest Association
Aggregation, the parts-whole relationship, is perhaps the most useful association of all of them. Many many complex things are made up of an assembly of simpler items. There are at least two flavors of aggregation, static and dynamic. Static aggregation is lifelong aggregation; the parts cannot exist apart from the whole, or enter or leave the whole. Dynamic aggregation is more like a team whose members can come and go. Here is an example of a massive chain of aggregations with a familiar theme:
Association Details
There are many details added to associations to show more information about the relationship. Some of these details are discussed in Chapter 5 in your text.- link
- just as classes have instances at runtime called objects, associations have instances at runtime called links. Links occasionally are so important and complicated that they need their own attributes. The main information about them is usually their lifetime, and what instances they are connecting.
- multiplicity
- a.k.a. cardinality, it is the number of object instances per link instance in a given relationship
- qualifier
- some many-to-one relationships have a unique key used to traverse the association.
- roles
- the different ends of an association may have differing roles associated with them. Especially useful if both ends of an association connect the same class.
- composition
- there is a special kind of aggregation called composition, which denotes aggregations in which the component parts have no existence apart from the whole thing. The relationship is hardwired, static, or constant. Composition is marked using a filled diamond; hollow diamond means a regular (transitory, or dynamic) aggregation.
Here are some more class diagram figures from some old software engineering text (Pfleeger). One point here is that it is logical to start with a simple sketch of classes and basic relationships, and add many details later on.
As a larger example of class diagrams and associations, consider a previous semester's project. They produced two, overlapping class diagrams, one focusing mainly on cards and card decks and one focusing on characters, units, and the map. We can look at these two diagrams and consider what they did right, what needs to be changed for the campaign game. We can also work, as an example, some of the classes and relationships for the Monopoly game.
lecture #5 began here
User-defined Association Examples
Here is an association you might see in a human resources application:
|
employee employer Works-for |
|
What are some example instances of this association?
Here is a more detailed version of that association:
|
employee employer * Works-for |
|
There is a multiplicity, since many people may work for the same company. But what if a given person works for more than one company?
Here is an association you might need for a geography application:
| Has-capital |
|
Now, what are some examples of this association? Give me some instances -- and their "links". To include more information in this association, we need to know:
- How many capitals can a country have?
- How many countries can a city be capital of?
- Does every country have a capital? Vice-versa?
lecture #6 began here
Reading
For coverage of this week's lectures, read Lethbridge Chapter 8, ESPECIALLY Section 8.2.Statecharts
A statechart, or state diagram, depicts dynamic properties of a system. See p. 276 of the text. A statechart consists of- a set of states
- drawn as circles, ovals, or rectangles, with a label or number inside.
- a set of transitions
- drawn as arrows from one state to another.
- a start state, and a set of final states
Some of you may be getting an eery sense of deja vu at this point. Statecharts are a non-trivial extension of finite automata, because they have:
- instead of "input symbols", events associated with transitions
- these may be complex, synchronous or asynchronous
- events may have conditions, drawn inside square brackets
- activities
Statechart Diagram Examples
lecture #7 began here
More Statechart Examples
Next week we will work on statechart examples relevant to your semester project.
Collaboration Diagrams (Chapter 9)
Collaboration diagrams are the next form of UML diagram we will describe in this course. Collaboration diagrams describe how a set of objects interacts by calling from method to method.Collaboration Diagram Examples
A collaboration where an actor pushes a button to get an elevator to his floor. The control object checks how long the job queues of all the elevators are and chooses the shortest. It then creates a job order object and invokes it by putting it in a queue. The elevator object runs concurrently and picks up jobs from the queues. The elevator is an active object, meaning that it executes concurrently with its own thread of control.
The object MainWindow receives the message NewCustomer, and creates a
Customer object. A CustomerWindow is created, and the customer object
is then passed to the CustomerWindow which allows for update of the
customer data.
A collaboration diagram that summarizes sales results.
A Collaboration Diagram for a Printer Server
Collaboration Diagram with Simple Numbering
Collaboration Diagram with Decimal Numbering
lecture #8 began here
Object Oriented Design: Adding Detail
This week's lectures will include material from Lethbridge Chapter 5. You can view object oriented design as a process of adding detail to class diagrams. We will look at as many examples of this process as we can.Where Do We Go Next?
For detailed design, we need to reorganize/regroup and assign teams to go into the details of various aspects of gameplay. A Big Question we need to decide (today) is: one team, or two?Homework #3: Detailed Design
You are dividing labor right now for work on phase 2, adding details and corrections to your project analysis, and merging ideas you find in other teams' homework #2. Make sure your names are on any submitted course documents. In fact, I need to know who did which parts of which documents, so I don't lump everyone together under the same grade. If you are asked to prepare part of a document you don't understand, better ask your classmates and/or instructor what is needed for that part.lecture #9 began here
User Interface Design
By the next round of turnin, we will need to establish a fairly complete user interface design for things like the main screen. User Interface Design is the subject of an entire course (CS 485) and for our purposes we will have to settle for a rudimentary and primitive introduction.User interface design starts from what tasks/activities the application is to support. You probably will discover a few tasks in this phase that requires a dialog for a task we haven't identified previously. But mainly we need to design dialogs and sequences of actions to perform specific tasks in use cases.
Aspects of User Interfaces
- look
- this is the most obvious part of user interface design, but not the most important part
- feel
- this is like: what clicks perform what operations. how many clicks does it take. does it feel like you are directly manipulating the objects on the screen, or does it feel like you are following a long sequence of orders you receive from the program.
- metaphors
- users can quickly learn an unfamiliar task, or quickly interpret an unfamiliar graphic, if a familiar metaphor is used. Examples: "desktop metaphor"
- mental model
- a user interface provides the user with a particular mental model of how they view the system. designing that model will determine many aspects of the user interface (what info to show, what tasks to support)
- navigation rules
- navigation through large structures which don't all fit on the screen is a central issue for many (most) applications.
A few Obvious User Interface Tips
- Minimize # of clicks for common tasks
- Provide all the information that's needed on a single screen
- Strive for "direct manipulation"
- Modeless is usually better than modal
- Be familiar and consistent with other applications
Interpersonal Communications: Some Rules of Engagement
- 1. Respect your classmates, even when you disagree or they are wrong.
- "Treat others the way you would like to be treated" - Jesus. I am not impressed, and will not tolerate for long, group "leaders" who disrespect their teammates publically. If you have a problem with one of your team member's contributions, discuss it with them privately. If you cannot resolve it through polite discussion with the individual, discuss it RESPECTFULLY within your group, and if there is a problem that can't be resolved internally, see me. Part of your grade will be based on whether I determine that you respected your classmates or not.
- 2. Accept group decisions even when you disagree.
- "The Needs of the Many Outweigh the Needs of the Few...or the One" - Spock. There has to be some mechanism for making decisions, whether it is democracy, dictatorship, or whatever. Those decisions should be made based on what's best for the group, not what makes an individual look good.
- 3. You must include all group members in decisions.
- I want to hear no more team members who are surprised about something that affects them.
- 4. You should do your best to contribute to your team.
- "From each according to his abilities" - Marx. The easiest way to fail this course is to not contribute to your team. If you do your best, make your contribution, and the team discards it, that is not your problem or fault. If you don't do your best to help your team succeed, don't be surprised at the grade you get.
- 5. E-mail is not a good medium for resolving problems.
- I have found through many long years that e-mail does not work well at conveying emotions. Using e-mail to try to resolve problems can easily make them worse. Of course, sometimes you have no choice, but basically e-mail is easily misinterpreted. Human faces and intonation are lost, and people do not type as well as they talk. When there is a problem, your best bet is to e-mail to setup a meeting to discuss it. Your next best bet is to think, and rethink, what you are planning to send by e-mail. Ask: how will this person react to this e-mail? Have I respected them? Will they understand my situation? Will they feel I am attacking them, or trying to help?
From: ralphThis e-mail may have accomplished a certain motivational goal, but it did not improve the working relationship between sender and recipient.
To: cjeffery
Date: Wed, Apr 22
Subject: CarpingI'm more than a bit tired of beating you about the ears in hopes that you'll rearrange your priorities, work habits, or whatever it takes to get your research on track.
I'll assess the situation in a couple of weeks. If I'm still not satisfied with your progress, I'll put it in writing.
Why are collaboration diagrams useful?
Collaboration diagrams help connect the use cases and classes. Each scenario (== sequence of steps for a use case description) can lead to a collaboration diagram.Design Buzzwords and Vague Concepts
Guess what, the book talks about design. Assignment: read Chapter 5 in full at this point if you haven't already. It gives step-by-step procedures for performing the tasks of detail design you need for your project homeworks 3-4.Here are some buzzwords and ideas that relate to design:
Design methods
- 1. modular decomposition
- top-down breaking up function into parts
- 2. data-oriented decomposition
- top-down breaking up information into parts
- 3. event-oriented decomposition
- identifying what changes are to be made, and when they occur
- 4. outside-in design
- blackbox I/O orientation
- 5. object-oriented design
- relationships between data
Things that get designed
- 1. Architecture
- interaction between programs and their environment, including other programs
- 2. Code
- algorithms and data structures, starting with equations, pseudocode, etc.
- 3. Executable/package
- how is this system going to be installed and run on user machines?
Some common breakdowns
- poor prioritization
- failure to consider constraints on the solution (missing requirements)
- failing to perform mental simulations of complex multi-step activities
- failing to track and return to subproblems which aren't solved yet
- failing to expand/merge/integrate subsolutions into a complete whole
"Good" Design
Book material on design resides in chapters 7-9; skim them and look for good parts.- Low coupling
- Coupling refers to the interdependences between components. Components need to be as independent as possible. The book defines many kinds of coupling, including content coupling, control coupling, stamp coupling, and data coupling.
- High cohesion
- Cohesion refers to the degree to which a component is focused and connected internally (it is almost "internal coupling"). Bad cohesion has a single component doing unrelated tasks. Bad cohesion may coinside with lots of duplicate code (same thing repeated with slight changes for different tasks). The book defines levels of cohesion: coincidental, logical, temporal, procedural, communicational, sequential, functional.
- Minimal complexity
- There are several types of complexity, but in general, complexity is bad, and the goal is to minimize it while meeting requirements. Most of the complexity measures that are out there measure the complexity of code, but we are talking about design right now. Designs that are complex, or designs that poorly address the application domain and requirements, lead to complex code. Bad programmers can of course create complex code from even good designs.
lecture #10 began here
Good/Bad Design Examples
- Vince Kellen's Coupling and Cohesion Examples give examples of bad cohesion, indicated by excessive module length/size, along with other goodies.
- Our textbook has an on-line "knowedge base" including a set of design principles and a software quality section
- Wikipedia entries on coupling and cohesion give some concrete examples
Comments on Homework
- Produce a readable document
- I have to be able to read your hard copies, I really mean it! If you can't format your diagrams to fit the page, or print a lot of text so small I can't read it with my glasses on, or don't have enough toner in your printer: fix it.
- Avoid "buzzword infection"
- Students learning software engineering or UML are exposed to many new terms. When writing software engineering documentation, keep the technical buzzwords out of your application domain descriptions unless they really belong there. Example: in use cases you learn about actors, so in your descriptions of the application domain, the word "actors" starts being used to refer to many non-actor things.
CVS and Version Control
CVS stands for "Concurrent Versions System". It is a software version control system, whose primary function is to aid in the coordination of programmers on large projects. Compared with earlier tools SCCS (source code control system) and RCS (revision control system), CVS offers some significant advantages:- It allows all programmers to edit any file at any time. Earlier tools used a "locking" system to allow only one programmer to edit a file at a time.
- It semi-automatically merges changes by multiple programmers; if the edits do not conflict it is fully automatic, and if the edits are to the same place in the program, it notes the conflict, shows both versions, and requires the programmer(s) to resolve the conflicts manually.
- CVS works on multiple platforms (e.g. UNIX and Windows) and since it is open source, everyone can use it. Previous systems were not very portable (RCS) or proprietary and commercial (SCCS, PVCS, etc).
- CVS works over the internet, making it awesome for coordinating the development of public open source projects with personnel scattered around the world.
Major CVS Commands
CVS works using a "repository" which is a database for source files. You can specify which repository to use via a command line option, but it is usually done by setting a CVSROOT environment variable. This can be set to either a local directory or an internet machine and directory name. When you checkout a project from a repository, your project directory remembers which repository it belongs to, so there is no problem using CVS with many different projects in different repositories; you don't have to keep resetting CVSROOT all the time.Unless you are creating your own repository, the first command you need is
cvs checkout projectnamewhich grabs a copy of a named project from the repository. The various cvs commands that manipulate the repository have the syntax
cvs command [filenames...]The other commands you need immediately for CVS include:
- cvs diff [filenames...]
- Show any differences between your file and the version in the repository
- cvs update [filenames...]
- Merge in any changes others' have committed to the repository. If you have changed lines that others have changed, the conflict is reported and both copies of the changed lines are left in for you to merge by hand.
- cvs commit [filenames...]
- Merge your changes into the repository.
- cvs log [filenames...]
- Show history of changes that were made to a file or files.
Demonstration of CVS on the current class project
HW #4
lecture #11 began here
Comments on Homework
- States in statecharts must correspond to (sets of) values of attributes in some class: make explicit
- Arrows/transitions in statecharts must be identified/labeled with the events that cause them.
- Methods in many use case descriptions need to migrate to class diagrams
- Some teams will need to split class diagram into multiple pieces
- Do not just copy text from rules (duh) -- analyze and adapt
- Many HW3 use case diagrams still have things that aren't use cases in them
- User tasks != character "tasks" in the simulation
- Tie your credits a bit closer to your materials
Implementing UML Constructs
At the beginning of the semester, we said... languages vary in their ability to implement OO designs.We had a lab where there was some UML-to-C++ going on, but we need a lot more details in our designs, and we need a lot more practice with going from UML to code. Now let's return to that topic and consider the implementation of associations in your semester projects.
Filenames
Go with InitialCaps on classnames and filenames. Unless you use 8.3 filenames, you don't have infinite portability, but that is OK.Documenting Code
I have alluded to JavaDoc, is there a similar tool for C++?JavaDoc comments look like this example. They must be placed immediately BEFORE the thing they describe. The first sentence should always be a summary of the described entity.
/** * This is a beautiful JavaDoc comment. */Our UML documentation can be referenced (once we rename doc/ to doc-files/ in our project) with a comment like:
/** * The UML class diagram for this code is * <A href="doc-files/myclass.html"> here </A> */JavaDoc comments can include a large number of interesting "tags", signalled by the at sign (@). Some are standalone (@see, @deprecated, etc) and some are "in-line", meaning they are enclosed by curly braces in order to clear mark the end of the tag, as in {@link #getDiplomacy()}
For our class the best tags are: @author, {@link...}, @param, @return, @see, and @version. There are other tags; read the man page.
lecture #12 began here
Midterm Exam: let's go ahead and see what you know on Friday March 10. Review text chapters 2,4,5,7,8,9, focusing on sections that related to material discussed in class or activities done in homeworks or labs.
CVS Repository
To create it I had to saymkdir ~/371 mkdir ~/371/CVSROOT cd ~/html/courses/371/fps # where my sources were cvs import FPS mumbledy fumbledy chgrp -R cs371 ~/371To get your copy you should say
setenv CVSROOT /home/uni1/jeffery/371 newgrp cs371 cvs checkout FPSTo modify files in the repository
newgrp cs371 cvs update, commit, etc.
A Few Nuggets from Lethbridge
- Avoid unnecessary generalizations. At what point do you stop making subclasses, and just handle differences in instances, if any, via a field value?
- Have a generalization key.
- Constraints; OCL exists
- Tasks in developing a UML model are more than just drawing classes and relationships. They include identifying responsibilities for each class, which help lead to the methods the class needs.
- Class criteria include: don't define two classes with different names, if one of them is really the same thing as the other. Don't define classes for things that should be instances of other classes. Don't define classes for things that have no meaningful data. Don't define classes for things that have no meaningful behavior (i.e. methods). Don't define classes for things that are too vague. Don't define classes for things irrelevant to this application domain or this particular application within that domain.
lecture #13 began here
CVS check: 6 students have done enough lab work to stick their names into credits.cpp:
void credits()
{
std::cout << "FPS - a CS371 project" << std::endl;
std::cout << "Clint Jeffery" << std::endl;
std::cout << "Michael Simmons" << std::endl;
std::cout << "Scott Blauert" << std::endl;
std::cout << "Gustavo Jimenez"<< std::endl;
std::cout << "Jeston Uhl"<< std::endl;
std::cout << "Curtis Wyatt" << std::endl;
std::cout << "Philip Killough" << std::endl;
}
Design Patterns
Some of this material can be found in Lethbridge Chapter 6.
Architect Christopher Alexander wrote extensively about the concept of patterns in building, and software design patterns were inspired by his work. Design Patterns create a common vocabulary for "known good" solutions that seem to recur over and over again. If we do not recognize and exploit these recurrences, we reinvent the wheel over and over again.
Design Patterns in software got popularized by a "Gang of Four" authors (Gamma, Helm, Johnson and Vlissides) who wrote a book in 1995. Like most New Things in software engineering, it spawned a cult following and a legion of wannabes inventing "design patterns" for things like wallpaper. But the original idea is valid and many of the design patterns in the Design Patterns book are legitemate.
The original design patterns book described in detail 23 reoccurring patterns in software, divided into three main categories: creational, structural, and behavioral. Each pattern is described exceedingly well in prose and outlined in a UML class diagram, after which example implementations are sketched in C++ or Smalltalk. Within all three categories a great deal of similarity can be observed, such as the heavy use of abstract classes; enough to suggest the existence of meta-patterns.
The design patterns fad has died down, but the concept of design patterns has been thoroughly institutionalized by the software engineering community.
