Discussion of this Year's Project Topic

Project needs to be the "right size and shape".

Bigger than you can do on your own. Small enough we can complete it, at least somewhat.

Project should be Interesting and Fun

By definition, that means it uses networking and graphics a lot

Project can require no prior expertise on networking and graphics

Those classes are not prerequisites. Consider this a warmup.

Last Year's Topic Burned me out a Bit on Java/Webby stuff...

And it will be harder to do interesting things with multicores there.

I am a Gamer, but...

There is a separate class or two for that.

Strong External Forces on the class

We need to cover accreditation-required mainstream SE topics

Strong External Forces on Dr. J

Publish or Perish. Sponsor obligations. Dr. J's CVE deliverables.

Good News / Bad News

Good news: the program I'm working on for my computer science homework compiles.
Bad news: That's about all it does.
The Expert says: We in industry call this "code reviewed by GCC".

The Core Problem: Complexity

Famous software "engineering" failures

• Denver airport baggage handler
• Patriot missile defense system
• Ariane 5 rocket
• Therac-25 radiation treatment machine

What does software engineering really consist of?

Coding and Testing

we knew about this part already; much of SE comes before it

Knowledge acquisition

learn the application domain the software deals with

Modeling

reducing application domain to a discrete, computable approximation

Problem-solving

overcoming many surprises along the way

Rationale

explaining why we are doing things this way and not that other way

Documenting all of the above

for both internal and external parties, with different needs and vocabulary

Project Discussion.

Happy Labor Day

Teams: C++ and Java

Jon Stoker		Constantine M.		Cliff Clark
Cody Miller		Usman Loum		Ben Daly
Thor King		Travis Weingart		Ben Adler

Kazunori Matsuura	Ben Blaker		Roseanne Sands
Jesse Brent		Jess Smith		Stephen Tutton
Creg Empey		Lavanya Mynam		Raymond Chau

HW#1

Major SE Concepts

Participants and roles.

Typically: client, user, manager, developer, artist, content creator, technical writer... Really, there are many kinds of "developers", only some of whose job is conventional coding. User interface designer, database designer, system architect, network protocol designer...

Work Products

Specification, operation manual, status report, test manual, source code, database, configuration/build/install scripts...

Activities, tasks, and resources.

Requirements: functional and non-functional.

Notations, methods, and methodologies.

Major SE Activities

Requirements Elicitation

Problem specification, use cases, feasibility, project planning

Analysis

Model the problem domain

System Design

Model the major elements of the solution. Processes and their communications, classes and their relationships.

Object Design

Model the details. Class instance data, methods, and interactions.

Implementation (CS 384)

Code

Testing (CS 384)

Find bugs, validate

Managing Development

Communication

Tools, standards, rules of engagement, principles of authority

Rationale

Evaluating alternatives, making and remembering decisions

Software configuration management

Tracking changes, porting, build and install tools

Project Management

Oversight, budgeting, scheduling

Software Lifecycle

Shipping the software is only the beginning

Lecture 4

Introduction to Software Lifecycles

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

Why is Software Engineering Crucial?

Belady-Lehman observed:

[D. Berry, The Inevitable Pain of Software Development, Monterey Workshop 2002]

So, Software Engineering is All About Pain

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.

Introduction to UML

UML stands for Unified Modeling Language. A "modeling language" is not a programming language, although some efforts have been made to "compile" UML diagrams down into code. UML was created when 3 very successful software engineering diagramming gurus banded together to wipe out the other 12 software engineering gurus. Actually, there was a serious need to create a common notation; prior to that, software engineers that worked with one guru's diagrams might not easily be able to read or understand software designs drawn by another software engineer who had been trained using another guru's diagrams.

Chapter 2 of Bruegge gives an overview of UML, featuring 5 common kinds of diagrams, starting with use case diagrams, which are the type we will study first.

use case diagrams

document how human users and other "external entities" perform tasks using the software system that is to be built.

class diagrams

document major application domain entities whose representation in the system will include state and behavior. These diagrams document the associations, or relationships, between classes. At implementation time, there may be many implementation classes in addition to whatever classes are written to correspond to domain classes and domain class relationships.

interaction diagrams

depict dynamic behavior and communication between objects. Generally more detailed elaborations and special cases of the "relationships" from class diagrams.

statecharts

These are finite automata, with software engineering semantics added. There are states, events, and behavior that goes on during states or events.

activity diagrams

flowcharts and similar diagrams in which the elements depicted represent the execution of a sequence of instructions.

Lecture 5

Here's the CS Lab FAQ

Team Assignments

"That was Easy..."

Extended discussion of hw #2 and class project.

SVN and Version Control

• 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.
• SVN 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).
• SVN works over the internet, making it awesome for coordinating the development of public open source projects with personnel scattered around the world.

Major SVN Commands

Unless you are creating your own repository, the first command you need is

svn checkout projectname

   svn command [filenames...]

svn diff [filenames...]

Show any differences between your file and the version in the repository

svn 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.

svn commit [filenames...]

Merge your changes into the repository.

svn log [filenames...]

Show history of changes that were made to a file or files.

Similarly, there are "gotchas" to avoid if you have to move a directory around in the SVN repository. One student just did a "mv" and then was stuck in a "eternal SVN conflicts from hell" mode, until he found out he needed to do new "svn add" commands for the directories at their new locations. His GUI client interface (Eclipse) allowed him to get into this mess and failed to warn / prevent it... So be careful: you have been warned.

Lecture 6

Announcements

• Read book chapters 3-4. Identify which project organization and communication elements look the most useful in our context.
• Homework #2 link added to the class homepage

Big Concepts from Bruegge Chapter 2

• In software engineering, modeling is the art of constructing a simplified representation of a domain, which portrays those aspects of its essence and behavior that are needed for a given application.
• Big complex systems get modeled as a set of subsystems
• Big complex designs get drawn using multiple views
• UML relies heavily on object-oriented principles. If you have programmed in C++ does that mean you understand OOP?

Use Cases and Class Extraction

Lethbridge defines a use case as:

A use case is a typical sequence of actions that an actor performs in order to complete a given task.

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 a Parker Brothers game called Monopoly:

• 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.

Now we will expand on the discussion of use cases, use case diagrams, and look at examples.

Use Case Descriptions

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?

Lecture 7

Today we continue our discussion of use cases, but first, some perspective!

Requirements Elicitation Techniques

Scenarios

From Scenarios to Use Cases

Use case descriptions, examples

Open File Summary: A user performs this task in order to view a document. The user specifies a filename and the document is opened in a new window. Steps: Choose "Open" from the menu bar. System displays a File Open dialog. User selects a filename and clicks "OK". System closes the dialog and opens the file in a new window. Alternative: If the user clicks Cancel in step 3, no file is opened.

Lethbridge-style two column format is nicely motivated in the following example, 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 Actor: car driver Goal: to leave the parking lot Precondition: driver previously entered the parking lot, picked up a ticket, and has stayed in the lot long enough that they must pay to leave. Summary: driver brings their vehicle to an exit lane, inserts their ticket into a machine, and pays the amount shown on the machine. Related use case: exit parking lot, paying via credit card. Steps: 1. Drive to exit lane, triggering a sensor. 2. System prompts driver to insert their ticket. 3. Insert ticket. 4. System displays amount due. 5. Insert money into slot until cash in exceeds amount due.   6. System returns change (if any) and raises exit barrier 7. Drive through exit, triggering a sensor. 8. Lower exit barrier Alternative: User crashes through exit barrier with rambars on front of truck in step 1. (just kidding)

The following example (by Lethbridge et al) gives you one more look at use case descriptions. This one is for a library management application.

Check out item for a borrower Actor: Checkout clerk (regularly), chief librarian (occasionally) Goal: Help the borrower borrow the item, and record the loan Precondition: The borrower wants to borrow a book, and must have a library card and not owe any fines. The item must be allowed for checkout (not on reserve, not from reference section, not a new periodical, etc.) Steps: 1. Scan item's bar code and borrower's library card. 2. Display confirmation that the loan is allowed, give due date. 3. Stamp item with the due date. 4. Click "OK" to check out item to borrower. 5. Record the loan and display confirmation that record has been made. Alternative: the loan may be denied for any number of interesting reasons in step 2 (see preconditions).

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

Consider the following figure from a book by Lethbridge.

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.

The next figure illustrates a bunch of more exotic use case diagram items, namely actors and use cases that use or extend other actors and use cases.

Given that UML is a diagramming notation, its ironic that the main thing about use cases are the use case descriptions. It is easy to omit 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.

The Bruegge textbook, as well as Figures 11-1 and 11-2 of the Unicon book give some more examples of use cases.

Lecture 8

Announcements

ssh+svn tricks.

This part is different than how CVS does it, so I am having to learn along with you.

Group name: cs383_svn created, but our sysadmin Larry has this to say:

An old account existed for Benjamin Blaker that I was able to move forward,
so I reset his password and notified him.  I was able to create a new
account for Yik Chun Chau and I sent notification of the account (login) and
password.  I was unable to create or find accounts for Roseanne Sands and
Stephen Fischer. If you can find out the VandalWeb IDs (ala abcd1234) I can
create accounts for them and notify them.

It is possible some of the students have not tried to log onto wormulon yet,
so they may not know if their passwords work. If they can't get on - just
have them send me an email and I'll reset the passwords.

Lecture 9

Lecture 10

Lectures 9 and 10 by Ziad.

Lecture 11

Lecture 11 was spent by students working in groups on requirements analysis.

Lecture 12

Where we are at: you are finishing up and turning in your first pass at requirements analysis. As of 11am, 7 people had added their names to the svn repository. We need to move forward with some lecture material; there will be another round of requirements analysis, after some feedback, for you to refine your ieas.

Overview of Projects

• Dividing the Labor
• Scheduling delivery of various parts of the system
• Where Does the Buck Stop?
• How do we document bugs?
• How do we evaluate the system?
• How are requirements to be documented?
• Who talks to the client?

Consider Figure 3-2, one of the dumbest statecharts I have ever seen. Still, it conveys information about major project phases.

Project Communications

• Problem Inspection - gather information about the problem
• Status meetings
• Peer reviews
• Client / Project Reviews
• Releases
• Requests for clarification
• Requests for change
• Issue resolution

Team Organization

Roles

Schedule

Analysis - What Else Besides Use Cases

The analysis model is sometimes viewed as a three-part chorus: "functional model", "object model", "dynamic model".

At this phase, we start talking about objects in more detail, still focusing on the application domain, not the implementation. Domain objects can be classified into three general categories: entity, boundary, and control. You can use <<stereotypes>> to identify a class' category. Alternatively, you could color code them or group them physically, maybe separating the categories using dashed lines or some such.

Identifying Entities

• Real-world entities that the system tracks
• Real world activities that the system tracks
• Terms developers/users clarify/explain in order to understand the use case
• Recurring nouns in the use cases
• Data sources or sinks

POS	Model	Example
Proper noun	instance	Alice
Common noun	class	Field officer
"Doing" verb	operation (method)	create, submit, select
"Being" verb	inheritance	is a kind of, is one of either...
"Having" verb	Aggregation	has, consists of, includes
Modal verb	constraints	must be
Adjective	attribute	incident description

Boundary Objects

• gui controls needed for the use case
• forms the users need to enter data into
• notices and messages the system will use to inform the user
• different actors' terminals (windows/connections...)
• do NOT UML-model the actual screenshots (sketch or use an interface builder)
• use end-user terms for describing interfaces, not implementation terms

Control Objects

Sequence Diagrams

• First column = actor who initiated use case
• 2nd column = boundary object used to initiate
• 3rd column = control object in charge of use case
• <<create>> 3rd from 2nd; additional boundaries from 3rd; entities probably do not get created except in specific situations (they are usually "persistent" from some prior use case)
• entity objects get accessed by others, they do not access non-entities

CRC Cards

Lecture 13

Class 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

inheritance

aggregation

user defined

Inheritance: the Un-Association

Here is an example class hierarchy from the Lethbridge book (chapter 2):

Aggregation: the Simplest Association

Association Details

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.

User-defined Association Examples

What are some example instances of this association?

Here is a more detailed version of that association:

Person name SSN address salary job title

employee                 employer *               Works-for

Company name address

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:

Country name

Has-capital

City name

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?

Statecharts

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

Lecture 14

SVN Woes ... and Practices

• As of today 10/1/08, Credits.java had 9 names (not counting Drj) and Credits.cpp had 9 names.
• Java team has created a docs/ directory, C++ team hasn't yet.
• If you mess up the SVN repository, get help, don't just ignore it.
• Do exercise care with the class SVN. Practice on your own SVN repository, not ours!
• How to avoid stomping on others' work? For binary files (image files, .doc files...) SVN provides little or no help.

Statechart Diagram Examples

Lecture 15

Announcements

• Engineering career fair Monday
• Monday you will also find out from my attire whether the Vandals are able to best UNR in men's football.
• Midterm a week from today

HW clarification

More Class Diagram Examples

• http://www.agilemodeling.com/artifacts/classDiagram.htm

Lecture 16

Comparing the C++ and Java team's Requirements Analysis Documents

More Statechart Examples

Ethics and Social Implications of Computing Technologies.

Goldwater

When is Open Source, not really Open?

Homework Comments (from past years)

• Use case descriptions were mostly good, many UML diagrams had problems.
• A lot of great creative work contributed.
• Use case description common problem: vagueness
• UML diagram common problem: legibility
• Use case common problem: some things in ovals aren't really use cases
• Class diagram common problem: associations not defined.
• Class diagram common problem: inheritance or aggregation abuse
• Use case descriptions' arbitrary limits need to come from somewhere
• Use case descriptions' scenarios (steps) often contain preconditions or other extraneous matter.
• Do not cite our system as one of its own actors
• Do not describe development process using use cases*
• Do not write a use case for a non-action or failed action
• Better to gray out or not mention things user isn't eligible for yet, rather than put emphasis on things user can't do.
• Granularity of use case: 1-2 steps is probably too small, lots of steps smacks of multiple tasks being performed.

Lecture 17

Excerpts from Software is Hard

• add some excerpts here

Introduction to System Design

The line between analysis and design is a gray one. Broadly, requirements analysis was supposed to focus on what the software should do, while design should figure out how to do it. In our project, we are still figuring out our requirements, but we need to work out a design. The best we can do is: resolve any conflicts in currently-proposed requirements, make any pending decisions, document what we've identified and agreed on at this point, and call that our requirements document, realizing that it may have fatal flaws of omission or commission.

Bruegge says that our next job is to identify design goals, establish an initial subsystem decomposition, and refine that subsystem decomposition until all design goals are satisfied.

Design Goals

Subsystem Decomposition

A subsystem is characterized by what services or interfaces it provides to the rest of the application.

Object Oriented Design: Adding Detail

For detailed design, we need to reorganize/regroup and assign teams to go into the details of various aspects of content delivery and activities.

We should divide the labor right now for work on design, adding details and corrections to your project analysis, and merging ideas you find in other folks' homeworks #2-3.

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.

Vertical and Horizonal Teams

Administration team (MikeB, BrandonArp, RusselF, ChrisS, Serge)

account creation and management, user and teacher reporting

Navigation team (Justin, JoeyG, DanM, Trevor, AnthonyK)

integration / user interface / map / activity selection

Library skills team (DeanT, AndrewG, JosephE)

develop content / activities / NPC's related to library skills

Data (tutorial) team (MarkC, ChrisF, KaneG)

develop content / activities / NPC's related to binary representations

Algorithms team (AlexO, Curt, KC, Shruti, BrandonM)

develop content /activities / NPCs related to logic and sequencing of algorithms and problem solving

Help / chat team (NateE, BenS, Patrick, BennyH)

develop automated and human-based help and chat communications

User Interface Design

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

1. Minimize # of clicks for common tasks
2. Provide all the information that's needed on a single screen
3. Strive for "direct manipulation"
4. Modeless is usually better than modal
5. Be familiar and consistent with other applications

Lecture 18

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: ralph
To: cjeffery
Date: Wed, Apr 22
Subject: Carping

I'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 interaction and collaboration diagrams useful?

Lecture 19

Design Buzzwords and Vague Concepts

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

Lecture 20

Team Meeting Day: Wednesday

"Good" Design

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.

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.
• Lethbridge and Laganier have 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

Are you a team?

Did you meet with your team enough to sew your homework #5 together into a coherent document? Division of labor is great, but integration is harder and equally important. It will be part of your grade on future team homeworks from now on. It requires scheduling and not everyone-goes-and-does-their-part-the-night-before-its-due.

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.

Produce an editable, electronic document

Hand-drawn sketches are welcome. Whose job is it to scan them in so that they are part of the project ? .jpg or .pdf files are welcome. For us to be able to edit, we need the .dia or other source files used to produce the .jpg or .pdf if there are any.

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.

Lecture 21

Design Patterns

• Textbook Patterns Sections
• "Idioms and Patterns as Architectural Literature", by Coplien
• "The Structure of Pattern Languages", by Salingaros

Design Patterns Background

The original design patterns book described in detail 23 reoccurring patterns in software, divided into three main categories: creational (5 patterns), structural (7 patterns), and behavioral (11 patterns). 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.

What is a Design Pattern?

Minimalist Definition

Expanded Definition

How Design Patterns Solve Design Problems

How to Select a Design Pattern

I would just add that, first you familiarize yourself with a bunch of design patterns, and then when doing design you recognize which pattern to use via deja vu.

How to Use Design Patterns

Design Patterns versus Pattern Languages

Some Cynical Observations About Design Patterns

Name That Design Pattern

Lecture 22

Read the Coplien paper mentioned at start of the last lecture.

The Patterns

A ton of the examples in the design patterns revolve around the GUI aspects of "a diagram drawing tool" (uniquely relevant for some instances of CS 383, such as Fall08)

Abstract Factory

Example: UI Toolkit that can create either Qt or Windows-native components.

Builder

Example: an RTF reader might parse input (construction process), producing different representations for different output (ASCII, LaTeX, Wysiwig...)

Factory Method

Example: application framework needs to instantiate classes, but only knows about abstract classes, which it cannot instantiate

Prototype

Example: Toolbar-based applications where you create an instance by clicking on one. The toolbar may be generic framework code. Each button could be a different subclass, but instead attach a different prototype instance to each one.

Singleton

Example: a print spooler. Highlander quote: "There can be only one".

Adapter

Bridge

Lecture 23

Dr. J's "Best of the Rest"

Decorator

Facade

Flyweight

Proxy

Chain of responsibility

Command

Antipatterns

Thoughts on Coplien's Paper

• Idioms capture a solution to a problem in a context (= pattern)
• Idioms capture (language-specific) interactions between objects
• Design patterns capture language-independent interactions

Lecture 24

HW#6

Lecture 25

Welcome back from Break

Weekly Status Report comments

format

The web form I made up is not all that great. I need to be able to read these really easily. Plain text in the body of the e-mail would be better than an attachment that isn't easily readable because of internal scrollbars. Duh, at least I fixed my war.html form's HTML so that the text areas are no longer these tiny rectangles (I had said "columns" instead of "cols". HTML is not very forgiving.)

granularity

If I only get two reports, that's not enough, but some teams would prefer to avoid individual reporting. The point of weekly reports is to tell me what you are doing; probably an upper bound ought to be 2-3 subteam members can submit a joint report on their activities.

redundancy

I got many copies of the same report document, with tweaks. I only want one copy, so if you are sharing report text, I want a single submission with all contributors' names on it.

persistence

There needs to be a better mechanism for keeping these reports, besides me just shoving them underneath my pillow. Like, maybe svn.

sharing

some reports contain information that would be useful if it were visible to the entire team

privacy

Some reports might contain information that should be for my eyes only.

Project Issues

C++: Boost

Is it working everywhere that matters? Does it have version issues?

Java: XML parsing

Presumably we are using standard class libraries and examples, yes? Do we need any supporting discussion or demonstration?

File Format

This is: how we store UML projects and diagrams on disk. Generally there are text and binary formats, and there are human-readable and not-really-human-readable formats out there.

Protocol

This needs to subsume file format (need to transmit whole diagrams on start of collaboration), adding incremental/edit commands.

Lecture 26

Design Document Discussion

We went into the SSDD Template and found it has additional suggestions that may be useful, such as a Requirements Traceability section that maps from requirements elements to their corresponding design elements.

Designing for Security

Student answers in class included protecting against malicious I/O-based attacks, such as "SQL injection". Dr. J pointed out the obvious need to encrypt any data that is non-public, and mentioned SSH tunnels as the easiest way to do this in many cases. It was also mentioned that the 2007-2008 sysem might best protect the privacy of users by not retaining any more private information than might be absolutely necessary. The system is not intended for official academic course delivery or grading, so FERPA probably does not apply.

Lecture 27

Design Tools

Earlier I was appalled to find that Eclipse didn't bundle a UML design drawing tool. Now I am appalled to find the Eclipse doesn't really bundle a Java GUI builder tool either! In both cases, we are supposed to select, download, and install a plug-in. Eclipse.org apparently endorsed and adopted a tool called Visual Edit, but the tool is not supported in the current version of Eclipse, an indication that it (VE) is in trouble.

Anyhow, Dr. J bites the bullet and tries installing some plug-ins. Let's see, Help...Software Updates... Find and Install... yes, this is not too bad. Not willing to go back to earlier version of Eclipse, so visual edit is out, but "Jigloo" seems to have good ratings, will try it.

Lecture 28

GUI, GUI, GUI

It is ultimately your job to select a GUI builder product, not mine. I tried WindowBuilder Pro Installer, a commercial tool that is supposed to be better than the free stuff; it had a messy activation feature and after I did everything and tried to use it, it seemingly hung (growing the process at around 3MB/sec, I waited a few minutes and then gave up).

Dr. J's Reflection on UML Diagram Types

The Bruegge text calls an activity diagram a special-case of a state chart, and in some of your homeworks I may have criticized a diagram for having not very well-defined, or too "verb" oriented states. My view is that activity diagrams are not statecharts. If you did an activity diagram, don't call it a statechart, and I won't criticize it for sounding "verb"-ish.

A good class diagram...

Conveys key relationships (associations) between classes

not just inheritance and aggregation, but application domain (and object communication) relationships

Conveys enough detail to be useful in the implementation...

not just class member variables and methods, but roles, multiplicity...

A good statechart...

Has well-defined states, represented by a specific variable (or two) in a (explicitly identified) class

I should be able to see and understand what variable(s) in the class diagram represent the states in the statechart.

has states whose lifetime generally exceeds a single method.

has states which affect the object's behavior

Typical

   class C(h2ostate, slushdegree)
      method precipitate(x,y)
          case foostate of {
          "solid": pileup(1.0)
          "liquid": drain(1.0)
          "slush": { pileup(slushdegree); drain(1.0 - slushdegree) }
          }
      end

A good activity diagram...

conveys control flow details for a particular method...

many of the states may be implemented as method calls in this or another class... or they can be assignments, etc.

would serve as pseudo-code allowing straightforward coding

for every "fork", there had better be an identifiable "join", a.k.a. "barrier". This is small-scale, or "fine-grained" concurrency. If you really want to diagram true and persistent concurrent threads or processes with synchronous or asynchronous communication, look to other UML diagram types.

A good interation (sequence or collaboration) diagram...

shows "messages" (method invocations) which bounce control flow through a number of objects in order to fulfill a given use case

drills down to the specifics

shows possibly many instances that are involved

can be tied back to the class diagram(s)

it should be clear how each object knows the other object to whom the sequence diagram shows it sending a message. Is it via an object reference in class A (identified by an association line in the class diagram)? If not, how does (the object from) class A know to send (the object from) class B a message?

Lecture 29

The End is Near

3 weeks left? Time in this class for one more culminating assignment, including a presentation of your designs in detail.

More Notes from HW#6's

Please address these matters in your homework #7. Your grade will be affected by how well you address them.

Should a class diagram be a connected graph? What does it mean if there are several disconnected subgraphs, or classes with no associations at all? It means there are relationships (associations) missing.

Just like use case diagrams need supporting use case descriptions which are obviously more important than the diagram itself, class diagrams must have a supporting text section which describes, in some detail in natural lanuage, what each class and each association means. The admin team's createAccount State Diagram has a pretty good example of this.

Can a statechart be an NFA, or does it have to be a DFA? Sorry, but you have to either be a DFA, or you have to add mutually-exclusive guards/conditions on your events, see Nav team's Activity State Diagram #1 for an example where the "Navigate Path" event needs guards/conditions.

A narrative story line? Maybe not, but understanding of the whole system is affected by whether the connections between use cases, statecharts or sequence or activity diagrams, and class diagrams are apparent. Ideally, a use case would motivate the extra details included in the secondary UML diagrams, which would motivate substantial content in the UML class diagram. At least, when looking at diagrams I should know what use cases and class(es) they belong to -- put in cross references, using an obvious naming or numbering scheme. Include the whole thing, not just the recent work but the parts I need from before in order to understand the new stuff.

Let me say it again: for each statechart, I want to know what class it belongs to and what member variable(s) in the class diagram represent the state information.

As details grow, don't be bashful about splitting your class diagram into multiple views: one big-picture view and multiple close-ups-with-details is the natural thing to expect.

What, no title? Yes, I actually expect you to label and identify your work properly.

.docx? Please save as .doc, .docx is not multiplatform yet. Don't leave Linux and Mac users in the lurch.

.png? Please include source files, I really mean it.

Lecture 30

More HW#6-Inspired Musings on Design

When do you split a state chart? When some states pertain to one object and other states pertain to a different object, consider splitting the statechart and do two statecharts that execute in parallel in the respective objects. Example from the data types team: there was a tank game, and it had a state chart for what we might call the "game control" (i.e. what the player is seeing, the user interface) but some states seemed to suggest (to me) that the objects in the game such as the tanks might need to track their state (damaged, moving etc), but that needs to be done in a separate statechart.

When do you know a design is not finished and you have more details to work out? When you see a class with a name like "Hex Game", it not only needs its own variables and methods, you also suspect that its a whole big coarse-grained subsystem with other classes, associations, statecharts, and so forth all missing and needed.

Remember how you are supposed to define major UML diagrammatic elements in a supporting text description? This is not just for classes, it goes for associations as well. And generally, associations often need more thought in your class diagrams, teams often get associations wrong or they are just missing.

The goal of things like activity diagrams or statecharts is NOT to restate the same things listed in the usecase diagrams! It is to work out details at a finer grain of detail, the "inside-the-objects" details, as opposed to the use case descriptions' "user-eye-view" from outside the objects.

In addition to what I said last time about diagrams referencing related items in other diagrams or text sections of the overall design document, I would add that (duh) diagrams need enough clear title markings so that they can be identified. Perhaps besides just a name, each diagram should indicate its UML diagram type and have a brief explanation of what it depicts.

Sneak Peek at HW#8

HW#8 is available so you can plan your schedule ahead accordingly.

Discussion of Sequence Diagrams

The class featured a discussion of sequence diagrams and what to do if your part of the project had no interesting items that needed one. Dr. J's main answer was: look for pieces of functionality where your design has not really broken out things at a fine-enough granularity yet. Other answers include: was your team too conservative in its interpretation of its role? Does your team have more people in it than are needed for the tasks you've defined for yourself? Team reallocations may be appropriate.

Lecture 31

Design Patterns Note

Our textbook seems to select the following design patterns as especially interesting and worth understanding: Bridge, Adapter, Strategy, Abstract Factory, Command, and Composite. It has supporting examples of these patterns, so study them. Appendix A gives details on 9 design patterns, these 6 plus 3 more (Facade, Observer, Proxy).

Bruegge section 8.4.7 suggests a sort of buzzword-based "expert system" for detecting when natural language requirements or design prose suggests particular design patterns, for example when you hear something like "policy and mechanism should be decoupled", a light dings in your head and you say "this sounds like a job for.... a Strategy!"

Composite

Compose objects into tree structures to represent part-whole hierarchies. Treat individuals and composites uniformly. The client won't have to know whether they are working with a leaf or not. New kinds of leaves won't require that the hierarchy code be modified.

Decorator

Attach additional responsibilities to an object dynamically.

Facade*

Provide a single unified interface to a set of subsystem interfaces. Goal: reduce coupling between a subsystem and the rest of the system.

Flyweight

Use sharing to support large numbers of fine-grained objects efficiently.

Proxy*

Provide a surrogate or placeholder for another object.

Chain of Responsibility

Give more than one object a chance to handle an incoming message. Pass the request along the chain until an object handles it.

Command*

Encapsulate a request as an object. Assists with queing the tasks for later execution, prioritizing them, and supporting an "undo" operation.

Interpreter

Interpret sentences in a language by defining and operating on an internal data structure representation of that language.

Iterator

Provide a way to access the elements of an aggregate object sequentially.

Mediator

Define an object that encapsulates how a set of objects interact.

Memento

Capture and externalize an object's internal state so that the object can be restored to this state later.

Observer*

Create a mechanism such that when one object changes its state, all its dependent observers are notified and updated. Also called "Listeners" in some systems; a whole "publish-subscribe" paradigm follows this pattern.

State

Allow an object to alter its behavior when its internal state changes, appearing to have changed its class.

Strategy*

Define a set of encapsulated, interchangeable, algorithms; allow algorithms to vary independently of their clients.

Template Method

Define the skeleton of an algorithm, deferring some steps to subclasses.

Visitor

Represent an operation on elements of an object structure; enable new operations without changing the element classes.

Object / Component Design

Specifying the public interfaces (set of public methods) helps you:

• identify missing attributes and operations
• specify type signatures and visibility
• specify invariants
• specify preconditions and postconditions

The first two of these are absolutely necessary to get to the implementation stage, while the latter two are vital in debugging and/or proving a module's correctness.

Lecture 32

HW#7 Comments

all of them graded except... library stations team

some of you marked who-did-what, most didn't

would like to re-grade some of these, and some of your HW#6, with individual's contributions identified

mixed results as far as correcting problems noted previously

fixed in a few cases, not in others

sequence trouble

when it looks like an event triggers a prior event, the diagram gets suspicious to me.

new block-copy-and-edit diagrams

find a way to merge them

new rhetorical and generic diagrams

find a way to apply them to illustrate our situation concretely

granularity issues

many diagrams where the story does not yet tell enough details for you to go and implement what you've designed

supporting text

teams that put in the supporting text to explain diagrams generally got better grades than teams that didn't.

some teams did some nice prototyping work

associations are still underrepresented minorities

they need further elaboration, especially inter-team associations such as DB and activity-related communications

Lecture 33

Online Course Evaluations

As of Friday 12:20pm, our response rate was up to 56%; last semester the the departmental average was around 60%, so you are close. I won't know who submitted evaluations and who didn't, but thanks for those of you who have participated. I do not believe the system will be on next week, if you are going to participate it needs to be today.

Final Examination Review

The final exam is XXXXday December XX, from XX:XX-XX:XXpm. It is a comprehensive examination. It may address any of the following topics. Not all topics will be covered. Some topics would have to be abbreviated or questions on them would have to be structured carefully in order to allow them to be answered in a short amount of time.

1. Define and compare several development models.
2. Construct a project plan and schedule.
3. Develop a set of questions for a customer in order to elicit requirements.
4. Develop a software requirements specification document.
5. Develop UML use case descriptions and diagrams.
6. Develop user interface descriptions and prototypes.
7. Develop a software design document.
8. Develop UML class diagrams, statecharts, activity diagrams and collaboration diagrams
9. Define inheritance, aggregation, and user-defined associations/responsibilities between classes.
10. Establish and maintain mappings between requirements and design documents.
11. Define major architectural styles for computer-based systems. Identify an appropriate architecture for a given requirements specification.
12. Seek out, evaluate, select, and utilize appropriate function libraries and class libraries to address the needs of an application domain or software design.
13. Work together in small groups and report effectively on group activities and decisions.
14. Define multiple team organizational styles and roles.
15. Summarize the Software Engineering Code of Ethics and the ACM Code of Ethics, and apply these principles in hypothetical scenarios.
16. Write about issues relevant to the success of a software project.
17. Review technical documents and provide constructive feedback.
18. Describe several primary sources for software engineering research and information.
19. Summarize the current state and trends in professional certification mechanisms for software engineering.
20. Study and report on the function and usage of unfamiliar software development tools.
21. Effectively use a user interface builder or similar prototyping or code generating tool.
22. Describe the application of design patterns.
23. Define several of the most widely applicable design patterns.