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

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

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.

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

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?

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.

Announcements

• Schedule changes: we will be going more sequentially through the text that originally called for by the schedule.
• Read chapter 3. Identify which project organization and communication elements look the most useful in our context.

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

Lecture 6

Announcements

• As of 12:20, only 17 (?) homework #1 turnins? Generally, not turning in homework, or turning it in late, is not OK. If you have difficulties, I want to know about them as early as possible in order to help.
• Found a Microsoft Project Clone ?! (Thanks, Bruce Bolden). Check out the class tools page.
• We are not done talking about project management, we'll just mention a couple more topics from Chapter 3 today, and then revisit the topic soon, after I've checked out the OpenProj tool. But for today: read Chapter 4.
• Paper copies of the "Library Stations" notebooks are available for checkout from Dr. J on a first-come first-serve basis. About half the class could have it checked out at any given moment. Notebooks are due back the class period after you borrow them, but if no one is waiting for one, you may immediately re-check it out.
• Homework #2 is posted, we'll look at it at the end of class

Skill Trees

Team Organization

Roles

Schedule

Requirements Elicitation Techniques

Scenarios

From Scenarios to Use Cases

Use Case Descriptions - Examples

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.

Lecture 7

Announcements

• CS Forums URL change to http://uidahocs.net. Note that you will have to register (i.e. create an account for yourself) in order to see the 383 forums.

Comments on HW#1

A A-A-A-A-A-A-A-A-A-A-
B+B+B+ B B- B-
C C C-C-

Things I observed:

• sure enough, a lot of students, found a lot of resources, and the union of all that makes up an interesting starting point for us
• nevertheless, we have a long ways to go in terms of mapping out our base content, and we did not find as many or as much in the way of online pre-CS/introCS tutorials as I might have liked.
• some students didn't take the assignment seriously, or just spouted a list of tools that they already knew.
• We need a new name, one student found a VITAL project at Columbia university which is too close to our domain for us to keep the name VITAL.

Lecture 8

Modest Proposal

Comments on ACM K-12 Curriculum

concepts

computer organization, information systems, networks, digital representation of information, information organization, modeling and abstraction, algorithmic thinking and programming, universality, limitations of information technology, societal impact of information technology

capabilities

sustained reasoning, manage complexity, test a solution, manage faulty systems and software, organize and navigate information structures and evaluate information, collaborate, communicate to other audiences, expect the unexpected, anticipate changing technologies, and think abstractly about IT.

skills

setup a PC, use basic operating system features, use a word processor and create a document, use a graphics or art package to create illustrations/images/slides, connect a computer to a network, use the Internet to find information and resoruces, use a computer to communicate with others, use a spreadsheet to model simple processes or financial tables, use a database system to set up and access information, use instructional materials to learn about new applications.

algorithms and complexity (31)

analysis of algorithms, divide-and-conquer, graph algorithms, distributed algorithms, computability theory

architecture (36)

digital logic, digital systems, data representation, machine language, memory systems, I/O and communications, CPU design, networks, distributed computing

discrete structures (43)

functions, sets, relations, logic, proof, counting, graphs and trees

graphics and visual computing (3)

fundamental techniques, modeling, rendering, animation, virtual reality, vision

human computer interaction (8)

principles of HCI, building a graphical user interface, HCI aspects of multimedia, and collaboration

information management (10)

database systems, data modeling and relational model, query languages, data mining, hypertext and hypermedia, digital libraries

intelligent systems (10)

fundamental issues, search and optimizatino, knowledge representation, agents, natural language processing, machine learning, planning, robotics.

net-centric computing (15)

introduction to n-c, the web as a client-server, network security, data compression, multimedia, mobile computing

operating systems (18)

concurrency, scheduling and dispatch, virtual memory, device management, security and protection, file systems, embedded systems, fault tolerance

programming fundamentals (38)

algorithms and problem solving, fundamental data structures, recursion, event-driven programming

programming languages (21)

history, virtual machines, language translation, type systems, abstraction, object-oriented programming, functional programming

social and professional issues (16)

ethical responsibilities, risks and liabilities, intellectual property, privacy, civil liberties, crime, economics, impact of internet

software engineering (31)

metrics, requirements, specifications, design, validation, tools, management

ACM Level I: Foundations

Algorthmic problem solving === step by step to accomplish a task. Can be disguised. Steps to perform long arithmetic? Recipes in cooking? Find a way to include conditions and loops. Examples: find your way out of a maze; retrieving a thrown ball; baking cookies; going home from school; making a sand castle; arranging a list of words in alphabetical order. It is what children DO, and not what they see, that determines what they learn , so don't try to just present text or graphics, create activities. Checkout Seymour Papert's Mindstorms.

K-2

1. use keyboard and mouse (be able to type, point and click)
2. use computer for directed and independent learning activities (be able to follow instructions)
3. communicate about technology using appropriate terminology (know common terms)
4. use multimedia to support learning (be able to turn on / off speakers...)
5. work cooperatively and collaboratively using technology (share)
6. positive social/ethical behaviors (take turns; no copying; citation)
7. responsibilities when using technology
8. create multimedia with help
9. use technoology for problem solving, communication, and illustration
10. gather information and communicate using telecommunications with help
11. understand how 0's and 1's can be used to represent information such as images and numbers
12. understand how to arrange (sort) information without using a computer

Grades 3-5

1. Develop simple understanding of algorithms such as search, or network routing (or text compression?) using manual exercises.

Grades 6-8

1. Understand the concept of graph as a tool for representing problem states and solutions to problems
2. Understand the fundamentals of logic and its use for solving real-world problems.

SEE APPENDIX A.1, sample activities for Level 1.

Use Case Diagrams and Examples

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 9

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 10

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.

Lecture 11

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

Statechart Diagram Examples

More Statechart Examples

Lecture 12

UML Tools

Review of HW#2a submissions

Lecture 13

Ethics and Social Implications of Computing Technologies. Review papers at Dr. J's CS Ethics page.

Lecture 14

Terrorism and Technology

• Dark Web

Project News

Dev Language

A C++-vs.-Java vote took place in the forums, along with a discussion of the pros and cons. While I am a dictator and the vote is non-binding, I read what is written there, and Java got all the votes that count, which are votes with rationale behind them. The arguments are consistent with my own observations at present. Java will let us run as an applet if we want, it is more OO than C++, most importantly it has a garbage collector. This does not mean Java does not have problems, I know it has problems. It is not my favorite language, Unicon is.

Project Name

Of the names proposed on the forums, I ended up liking one that I was unfamiliar with. Several were great: FRISBEE, LOL... I wanted to like QUILL because it has a UI in the middle. But I ended up liking leet (or 133t), because what it means on the surface is exactly what we want to promote: total mastery and domination of technology, revelry and celebration of such expertise. We need an acronym, though; the one proposed on the web is majorly no-good. "Engineering Technology" is a swear-word in many universities. How about "Little Elites' Extraordinary Tutor"?

Leveling up

I see the experience model for our project as a tree. You start out as a Newb(ie), and after a certain about of expertise you become a non-newb and work your way up. After a certain point, very early, the leveling starts to be subject-specific. We need a firm handle on this tree.

UML

Although Eclipse documentation seems to imply that it has a UML tool, my initial search for such a tool turned up something that seems preliminary and useless to us (no 2D drawing editor, just a module to read .uml files). I am going to end up mandating Dia for 383-384 this year unless someone shows me a cross-platform alternative or a working Eclipse-based UML graphical drawing tool.

Map

We need a map of our space. The "virtual world" needs to be editable content. It needs to serve as a metaphor for the knowledge we teach. I want it to consist of a sequence of 2D levels, where each level has a series of rooms which constitute different subjects. You generally have one or more choices about which room to head over to. You generally have to defeat/master one or more of the rooms on a level to get down to the next level. The DATA for this map will be ascii art, similar to rogue or nethack. The graphical depiction of this map can be ascii art in the prototype, and can be replaced/upgraded to nicer graphics in the real implementation. The content editor can work with (and edit) ascii art maps.

NPC's

I envision a different personality character for each subject, somewhat like going to Hogwarts or whatever. These are fictional characters around whom to build games/activities/content exercises.

• Keystone Copy King - typing tutor.
• Tiger the Cat - mouse tutor.
• Ida Know - trivia mistress.
• Nicholas Worth - e-valuation. Turn in treasures to ths guy.
• Conan the Librarian. He will teach you library skills, or else!
• Hex Witch - Binary representation expert
• Party L. Order and Todd L. Order - Comparison (nonidentical) Twins
• Larry L33t - cybervocabularian
• Alger Rythm - searching, sorting, etc. (Will also go by "Al". Students must solve a mystery puzzle to discover Al's identity).
• Ada Zed - programming

Monsters

I envision a number of "monsters" representing different tests of student knowledge and expertise. Some are specific to locations where that subject is taught, while others may wander in.

• Tool Troll - tests your knowledge of which tool for which job.

hw2a.doc

Dia and UML Use Case and Class Diagrams

Lecture 15

Goldwater

Homework #4 is posted

When is Open Source, not really Open?

Eliza, CIA and rogue0 Mashup

We want to do some graphics, sure, but Content is King, not eye candy. We could prototype almost everything in text this semester, and worry about all the graphics, applet or alternative deployment issues, and so on next semester, and I would be happy. Question: how much pre-CS material cannot be presented, or could not be tested, in a text-only prototype? How crippled would a text-only prototype be, compared to a graphical version?

Lecture 16

Homework #3 Comments

• 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

Career Fair at WSU

Excerpts from Software is Hard

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.

Lecture 18

Bolden of the Day (BOTD, aka Best of Bolden)

(Ultra) Violet UML editor

Midterm (?!) : Next Friday, a week from today

Halo 3 study-for-midterm session next Wednesday 6-9pm

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

Lecture 19

Another NPC?

Internship Opportunity

Date: Fri, 05 Oct 2007 16:28:11 -0700
From: Christopher Jones 
Subject: Programming Internship at SEL

My group at Schweitzer is looking for another intern for some AFT
(automated functional testing) work.  Could you please pass this on
to any qualified and interested students?

The position is open right now, and I believe we're looking for
someone who can stay through the summer, and possibly longer
term.  I don't know exactly what they would be doing but it would
involve programming (my group is Software Support).  My boss's
comment was, "Where are all those hotshot programmers?"

There is a link below to view/apply online.  I believe it's the
correct one; any interested students can contact the hiring people
(info listed on the first page) for more details.  My boss is Steve
Rupp (it wouldn't hurt to mention his name).

Main web site:  http://www.selinc.com/careers/index.html
Specific
opening:
https://www1.recruitingcenter.net/Clients/SELinc/PublicJobs/controller.cfm?jbaction=JobProfile&job_id=11773


Thanks,
Chris Jones

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 20

Go over Midterm Exam answers

Discuss Dia printing and Eclipse UML options

Availability of others' HW3 solutions

This week's events; extension of HW#5

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.

Lecture 21

"Design Week"

Why are interaction and collaboration diagrams useful?

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

"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

Lecture 22

Internshop Opportunities at Chief Architect

HP Scholarship?

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.

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

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

Antipatterns

Lecture 23

Navigation Ideas

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

The Patterns

Abstract Factory

Builder

Factory Method

Prototype

Singleton

Adapter

Bridge

Lecture 24

HW#6

Examination of HW5

Lecture 25

ASEE SMART Scholarships

IEEE Computer Society Certification

From: 
Sent: Monday, October 29, 2007 12:13 PM
Subject: IEEE CS Is Accepting Applications for Entry Level SE Exam

Dear Colleagues,

The IEEE Computer Society, the s leading provider of technical
information and services to the s computing professionals, is
developing a program to certify entry level software developers and
engineers.  This program, the Certified Software Development Associate
(CSDA) Program, will provide formal recognition of entry-level
professionals who have successfully achieved a level of proficiency
commonly accepted and valued by the industry and will complement our
certification program for mid-level software developers and engineers, the
Certified Software Development Professional (CSDP) Program.  We are pleased
to announce that the CSDA program is now accepting applications for
participation in the beta test of the certification exam.

The beta test window will open 7 December 2007 and close 18 January 2008.
The Computer Society has set a goal of at least 200 candidates to take the
exam for validation of the content and establishing a pass/rail rate.  Beta
test participants will be able to take the test at a greatly reduced cost.
Passing candidates will become one of the first Certified Software
Development Associates.

For the beta test only, the Computer Society is seeking students in their
final year of a program leading to a baccalaureate or equivalent degree and
entry-level software developers and engineers who have graduated with a
baccalaureate or equivalent degree since November of 2004. After the exam
is released to the public in April 2008, registration will be open to more
experienced professionals.

Attached is an application to participate in the beta test.  Additional
information, including the content outline of the exam, can be found at
www.computer.org/certification/csda.  Please forward this to your
entry-level colleagues, students and anyone else you feel may benefit from
this opportunity.

Thank you for your support of this program.

Steve Tockey
Chair, CSDP Certification Committee and CSDA Examination Development
Committee
Construx Software
Steve.tockey@construx.com
(See attached file: CSDABetaApp.pdf)
IEEE Computer Society
1828 L Street, NW  Suite 1202
Washington, DC  20036
tel: +1-202-371-0101
fax: +1-202-728-0884
email:  ssaul@computer.org

HW#5 Library Skills Team comments

use cases/diagrams

The team wrote up 8 pages of use case diagrams on various aspects of the library stations, around 104 use case descriptions total! The diagrams are presented poorly and do not convey nontrivial information about the interactions needed for certain tasks. If most tasks are indeed trivial they do not need as much space; for the ones that are non-trivial, more attention and thought are needed.

use case descriptions

MANY of the use cases are basically duplicates of the block-copy-and-edit variety; for each lesson there are 3 use cases (100x3=300?). Redundancy is tolerable in a software specification only if it has a reason. If there are 30 use case descriptions which say "the user reads text, scrolls to the end, and clicks the Done button", that is 29 too many. Also, entry conditions and step #1 are often redundant, the redundant step #1 should be removed if all it says is the user selected the activity from the menu.

Create Author Card (example)

I don't understand the Create Author Card use case; it would help if it referenced the station # from which it comes. If I recall correctly, it is not about performing menial data entry, it is about the student knowing how to identify the different pieces of information on a real book. To do that they will need to see on-screen a virtual book (cover, spine, title page, backside of title page) whose information we can then check.

Class Diagram

This is one of the better class diagrams, not covering their whole subsystem and overusing aggregation but otherwise identifying some reasonable underlying classes.

Lecture 26

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.

The Red Pill

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.

Map of Discovery and Library Stations - Dependencies

Consider the prerequisite structure of the library stations. One can almost do these as an activity diagram, although it might be better to do it as a plain old dependency graph. Version 0 of this graph is a linear sequence of stations from 1-100. Version 1 of it (provided by Dr. J interviewing the customer) is a little more interesting. There are six sort of major "test" stations which require all previous stations: 25, 42, 60, 75, 91, and 100. Between these exams, the instruction activities range from nearly sequential (61-68) to nearly independent (35-41 can all be done in parallel). We could explore the application domain further to try and relax the dependencies and give a more "open world" feel to it, or we could implement dependencies as the librarian tells us they should be.

We don't want to present the user with a map with 100 options. We don't want to present the user with a map with 100 options, with 95 of them grayed out at any one time. We want to present the user with those options that are actually available. On a menu, this would mean building the menu dynamically at runtime instead of statically with a gui interface builder. On a map, it would mean... not showing the whole map, showing only the map of where we've been and where we are eligible to go. If we were using NPC's to give out activities, we would have each NPC know the prerequisites for its activities, and lookup the user's experience when we build the list of activities available to the user.

Questions for the class: what other teams (besides library stations) have enough activities to actually provide a decent introduction to their topic? What other teams' activities build on simpler activities, allowing the user to progress to more advanced material after they master the basics? Who provides the user interface for selecting from available activities? How can the user tell for each "island" how many activities are available on it to choose from, and how far they've progressed towards completing that island's content?

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

Project Status

There is a day extension on HW#7, but we can't really bump HW#8 back... so feel free to buy Crysis, but don't install it until your presentation is "in the can".

We need to spend much (> 30 minutes) of today and Friday discussion project design issues, and it needs to be student-directed, not instructor directed. However, we need it to be orderly and we need everyone to listen, rather than just the chaos of individual conversations we've had in past.

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

A Few Notes on Library Stations

The Library Stations team has been understaffed and needs "transfers". Strangely, they did not ask for help as far as I can recall.

Virtual Library

A number of stations cannot be done without virtual bookshelves, which I haven't seen a design for.

• 15-18...need a nonfiction stack with dewey decimal 000-999 and specific call numbers present on the shelves. Using "Stack Guides" to pick which shelf, and then using binary search within the shelf, won't be meaningful without having a fairly large number of fairly large shelves.
• 16 needs to be: the system demonstrates binary search. Or just skip it.
• 19 and 38 need a range of fiction with authors from A-Z.
• 39 needs a nonfiction shelf
• 36, 41, 42 need both fiction and nonfiction stacks, with specific books or groups of books on particular subjects.
• A simulated library catalog for the virtual library is also needed. Station 40 uses the catalog exclusively, it is also used in other stations, 79-82 for example.
• 87 needs to be rewritten as an information-only
• 88 assumes access to a library catalog and a phone book. Not easy to implement. The point is, phone books alphabetize differently than library catalogs.
• Example catalog http://www.youseemore.com/DentonISD/school.asp?schooltype=es&branch=104
• Station 51 would require access to a physical book, except that's impossible. The station could be done using a scan of a title page and the backside of the title page.
• Station 95 would require access to an atlas, to lookup locations by their latitude and longitude. We can live without it. Or: use google earth or some such.

Stations to Delete/Skip

7, 12, 33, 34, 35, 83, 86

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 Tuesday December 11, from 12:30-2:30pm. 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.