Introduction to Software Engineering

What does "software engineering" really mean?: Many expert computer scientists say this term is a misnomer.

This course is really about: tools and methods that are useful for larger-scale software development projects.

The concept of literate programming

We are writing a book.: "Engineered" Software is not just software that is delivered. It is software that is explained and validated. To visualize this, envision a book in which the source code occupies the middle chapters.

Donald Knuth, one of the Promethean Titans of computer science, proposed the concept of literate programming.

software is written for two classes readers: human and machine
writing for both audiences is difficult.
traditional software is written primarily for the machine audience
the human audience is often more important (e.g. for maintenance)

Knuth's solution (literate programming) is to write a hybrid document that can be translated into either a book for humans to read, or a source code base for a compiler to compile. Why bring it up here now? Your instructor has to be able to read and understand your code repository in order to grade it. Either give me literate programming, or give me a clear, explained codebase.

What would that look like?: Not just JavaDoc/Doxygen/PyDoc etc, although their use does help.
What more?: Big picture code description, table of contents, connections back to design and requirements.
How to present it?: Via a set of index.html files that explain and link all the source codes together?

Reading assignment: http://www.literateprogramming.com/knuthweb.pdf

Course Perspective

I believe that you learn by doing, and that you learn more and better by doing a larger project than you could do by yourself or in a small group. Ideally this course would cover the entire software lifecycle, and you would learn hard truths about coming into a project during the middle of development. You would have to read and understand others' documents, ask questions until it makes sense, and make an important contribution in a short span. In practice, it is hard to achieve this in a university setting. Don't expect this knowledge to come without a price, whether you learn it here or on the job someday.

Recent (Dr. J Dynasty) History of this Course

In the past few years, CS 383-384 has undertaken with varying degrees of success the following projects.

L33t: An educational software framework which was to teach pre-college students basic principles of computer and information science.
Wellspring: A collaborative software engineering diagram editor.
Arkham Horror: A complex, cooperative board game.
The Table: A platform for computer-assisted board games.
Gus: A Management System for Campus Groups & Clubs.
Freedom in the Galaxy: An adaptation of a Star Wars-like science fiction simulation game.

What I Learned from Previous Iterations

Python is terribly poorly suited to software engineering: Even a brilliant team with expert Python programmers can experience a lack of optimal success of they don't design or communicate well.
Need to start using agile methods from the beginning: We will do all homeworks this semester in terms of assigned task lists and Weekly Activity Reports. Starting with this (next) week.
Instructor needs to be (semi) dictatorial: We need both instructor- and student-leadership. Leaving it all up to you is unwise. Students need to recognize the burden that comes with leadership.
"Smart" does not imply (good leader | productive | team player): There are different kinds of smart I guess
"Bossy" does not imply (good leader): Many teams let whoever is loudest win
Cliques are hard to avoid, and damaging: Hidden costs associated with sticking close with your buddies
Language familiarity seems to be important: Especially when time is of the utmost
Design is more difficult than coding: Counterintuitive. Also: bad design precludes good code.
Early rounds of coding needed to feed design process: "rapid prototyping" is usually where C++ and java stink it up.
We need competition: Although I would prefer a single class-wide effort, it doesn't always work optimally.
We need large teams and shared assets: Small teams do not let you learn some course topics.
Communicating and committing are more difficult than technical issues: Counterintuitive.
Integration is more difficult than designing and coding your own stuff: Therefore it takes time.
All modern OO languages have ugly "warts".: There is a "semantic gap" between clean/abstract OO as seen in designs, and ugly OO provided by programming languages.
Don't run two independent projects: We cannot split the class time like that.
Don't elect a new rotating boss man: Nobody will know where the buck stops. Dr. J suggests instead that your team adopt the rules of pirate captaincy. (Elect a boss, then live with that person's management style. Respect authority. Mutiny only when your project success or grade is at stake.)

Lecture 2

Things I've Learned cont'd

Enact some system to force teammates to meet weekly goals.: Can't be all carrots, must have some sticks.
Sundays are a poor day for team meetings: They work fine for some, fine for awhile, hard to keep attendance up.
Need 1+ group technical sessions each week, not just group/mgt. meetings.: Same-time tech sessions, maybe same place not always necessary.
Group meetings need to start on time and stay on task: Many of your teammates do not have time to goof around

External Inputs

Agile: Mostly we do Sprints. But consider pair programming and test-driven development.
Multi-core: Because it's there. On server, 4 or more cores. On client, 2 or more.

Discussion of this Year's Project Topic

CS 383 has a delightful set of contradictory requirements

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.
Accreditation Requirements: We must spend most class time on lecture material, not just the project

Constraints on the Project

Size and shape constraints will exclude many fine potential software projects you might wish you could do. The constraints include:

Application should have many distinct user tasks, such that each student on team can design several of them (55, or maybe 110 things you can do with the software).
Application domain already familiar to students or easily learnable by the whole class.
Requisite API's (database, network, graphics, etc) already familiar or easily learnable by the whole class.
Can develop for target platform on CS lab machines (additional student machine platform support strongly desirable)

Project Topic Candidates

The class will select from among the following semester projects:

A software metrics tool

Specifically, a tool that measures the "openness" of open source software projects. It would rate the openness of projects in the following categories:

language portability,
library portability,
contributors,
users,
build documentation,
user documentation,
source documentation,
license, and
repository (permanence and accessibility) The tool would formalize and automate the ratings described in "Towards an Openness Rating System for Open Source Software", by [Bein and Jeffery 2010].
A Game.

Not just any game. One sized for the occasion. I have run very successful software engineering course projects in the past based on large, complex strategy (war) games. My favorites are a Star Wars parody (Freedom in the Galaxy, but it is off limits for Spring 2014) and a Lord of the Rings game (War of the Rings). I have been itching to do another funny fantasy game (Swords & Sorcery) or a clone of Sid Meier's Colonization.

A Medical Diagnosis and Treatment Communication Database

Discussion and Vote on Project Candidates

Lecture 3

Expectations Management

A brief discussion on expectations management: this class' primary goal is to teach and gain experience with software engineering concepts, tools, and methods. The goal is not a finished working product at the end of the semester, it is more like: a properly engineered (i.e. documented) working prototype.

Languages

There is the language we will use for our software design (UML), the language we will use fr our documentation (LaTeX), an the language we will implement with (Java). There are some considerations and trade-offs involved in our selection of languages.

UML is an industry standard and CS major should be familiar with it
LaTeX is ASCII-human readable and thus amenable to use with revision control systems such as SVN or Git.
Java is valuable on resumes, similar but easier than C++, and has a good track record.

Basic Concepts for This Week

waterfall and spiral: two competing models for the software development lifecycle. The introduced terminology includes: requirements analysis, design, implementation, testing, and maintenance phases.
use cases and their descriptions: the first step in requirements is to know what tasks the user will perform using the software
agile methods #1: sprint: as defined here, a sprint consists of a interval of time, usually 1-2 weeks, with a concrete set of goals to which each team member commits. In between each sprint is a sprint planning phase, including individual progress reports and a planning meeting.

Use Cases and Class Extraction

You can identify classes from a software specification document by looking for "interesting" nouns, where interesting implies there are some pieces of information to represent in your application, and operations to perform on them. You can also identify classes by developing use cases from the specification document. 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.

I would say: use cases are formatted descriptions of "discrete" tasks. By "discrete", we mean an individual standalone thing a user does while using the system. If you look through the tasks mentioned in a specification document, you can identify a set of candidates. Example candidate tasks for a "wargame":

Combat
Roll dice
Move pieces
Perform the Missions Phase

Example candidate tasks for 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.
Idea: after we have a complete set of use cases for our project, let's use it to form a "version 1.0" estimate of our system's function points. Pull in definition of function points here or a little later.

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

Drawing an oval and putting the name of a task in it is not very helpful by itself, for each use case you need to add a detailed use case description. Your first homework assignment is to "go and do this" for your semester project. Section 7.3 of the text explains the format of use case descriptions. Each use case has many or all of the following pieces of information. The items in bold would be found in any reasonable use case description.

Name: The name of the use case.
Actors: What participants are involved in this task.
Goals: What those people are trying to accomplish.
Preconditions: The initial state or event that triggers this task.
Summary: Short paragraph stating what this task is all about.
Related use cases: What use cases does this use case use or extend? What uses/extends this use case?
Steps: The most common sequence of actions that are performed for this task. Lethbridge divides actions into two columns: user input is given in the left column, while system response is given in the right column. The two column format is optional, but saves on paper and may improve clarity. The steps are numbered, so there is no ambiguity in using both columns on each line.
Alternatives: Some use cases may vary the normal sequence of steps.
Postconditions: what does this task produce?

Use case descriptions, examples

A simple generic use case for a "file open" operation might look like:

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

Lecture 4

Discussion of the Agile Manifesto

And Agile software development in Wikipedia

Sprint Meetings

For the purposes of this class, a sprint meeting consists of three parts:

Review (10 minutes): Except on the first one, review the outcome of the past sprint. <= 5 minutes per team, in front of class. Demo finished deliverables. Graded on technical content and communication/relevance/value.
Reflection (2 minutes): Answer two questions: What went well? What could be improved? Process improvement is all extra credit.
Planning (12 minutes): 10 minutes in your team, updating requirements and backlog. 2 minutes per team to report and/or negotiate with your instructor on items committed to complete for the next sprint.

The instructor will often provide one or more Required elements for the following week's sprints, to go along with whatever team-specific goals you formulate.

HW#1

If you want to lead a team, either form its core yourself after class, or write a better HW#1 than your peers.

The Core Problem of Software Engineering: Complexity

Over time, this means: change. What complexity? This refers not to the asymptotic time and space complexity of a code, although they are a crucial part of it, but its complexity to humans trying to build or maintain software. There are dimensions to it: static vs. dynamic, and control vs. data

Famous software "engineering" failures

What ones do you know of?

Denver airport baggage handler
Patriot missile defense system
Ariane 5 rocket
Therac-25 radiation treatment machine
Mars probe
Power grid rolling blackouts
The FBI's Sentinel caseload management system
Healthcare.gov
FAA flight controller system
DOD payroll system.

Lecture 5

Requirements Elicitation Techniques

Purpose: produce a requirements specification (i.e. software specification) document.

Identify functional and non-functional requirements (F+URPS) (Completeness, Consistency, Correctness).
Focus on the users' view of the system, NOT the internals.
Identify actors, scenarios, use cases. Refine and relate use cases.

Scenarios

Before there were use cases, there were scenarios. A scenario is a narrative description of what people do and experience as they try to make use of computer systems and applications [Carroll]. Scenarios may describe a current way things are done, a proposed way that a future software system should do them, a method of evaluating a system, or a method of training a user on a system.

From Scenarios to Use Cases

A set of scenarios may include many different instances in which the user is really performing the same task; these get merged into a use case. Use cases typically contain a primary sequence of steps performed in common by any scenario in which the user is doing that task, plus a number of exceptions or alternatives.

Use Case Writing Guide (adapted from Bruegge)

describe one complete user transaction
use cases are named with verb phrases that indicate what the user is doing
actors are named with noun phrases that indicate their role
boundary between actors and system (i.e. who does what) should be clear
use case steps are phrased in the active voice
7 +- 2 is usually the maximum number of steps
causal relation between successive steps should be clear
exceptions are described separately
do not describe the user interface; UI design is separate
do not exceed 2-3 pages. Probably not even 1 page.

Weekly Activity Reports in Sprints

Send to jeffery@uidaho.edu, not my gmail
format described in the WAR document
Subject line must say exactly: [CS383 WAR] name, date with date in mm?/dd?/yyyy format so I can file them.
Send text in-line, not in an attachment.
You may (and should) include links that point at your work (in the repository, or on cs383.com or whatever).

purpose: Establish a record of your contributions to the team each week. Each sprint, each team member should have 1+ committed deliverables. Past experience shows it is difficult to communicate results of these sprint planning sessions verbally in class.
graded: from 1-4, 4 being an "A"
format: I need to be able to read these really easily. Plain text in the body of the e-mail is better than an attachment.
granularity: 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: If you do submit joint work, I only want one copy, so if you are sharing report text, I want a single submission with all contributors' names on it.
public-ness: Upon reflection, WARs should be public team project artifacts. If you have private comments on your team's efforts, send them separately from your WAR, or visit with me in person.
persistence: There needs to be a better mechanism for keeping these reports, besides me just shoving them underneath my pillow. Like: put them in a subdirectory under your doc/ in your repository.
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.

Upshot: comments and suggestions are welcome; I am going to tweak/improve what we are doing with weekly reports. Lecture 6

Why is Software Engineering Crucial?

Because the larger a program gets, and the more features you add, the more bugs you get. Why? Because things get too complex for us to handle. Until we can solve this unsolvable puzzle, Moore's Law is limited or revoked by our inability to utilize hardware, just as we are unable to utilize our own brain (wetware). Belady-Lehman observed:

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

So, Software Engineering is All About Pain

Software Engineering, it turns out, is mainly about pain. Dan Berry, one of software engineering's luminary founding fathers, had this to say about software engineering methods:

Each method, if followed religiously, works. Each method provides the programmer a way to manage complexity and change so as to delay and moderate the B-L upswing. However, each method has a catch, a fatal flaw, at least one step that is a real pain to do, that people put off. People put off this painful step in their haste to get the software done and shipped out or to do more interesting things, like write more new code. Consequently, the software tends to decay no matter what. The B-L upswing is inevitable.

Dr. Berry goes on to give the following examples:

Software Method	Pain
Build-and-fix	doesn't scale up
Waterfall Model	it is impossible to fully understand and document complex software up front
Structured Programming	Change is a nightmare: patch or redesign from scratch
Requirements Engineering	Haggling over requirements is a royal pain.
Extreme Programming	Writing adequate test cases is a pain
Rapid Prototyping	We can't bear to throw away the prototype!
Formal Methods	Writing formal specification, and verifying it, may be a pain. Changing requirements is definitely a pain.
Code inspections	Documentation prep for inspection is a pain; nobody wants to be inspected.
"Daily Builds"	Testing, regression testing, and possibly reworking your latest change to not break someone else's latest change is a pain.

My goal for this course is to maximize your learning while minimizing your pain.

Agile Methods Tips

Gamedev.net once posted (associated apparently with gdc2010) an interesting article on agile methods, which has since disappeared into the ether. What we have left are the following observations about doing agile methods well. See if any will help in your sprints this semester.

Instead of "completion of developer tasks", focus on delivery of features.
Agile teams spend more time on planning than traditional teams. ?!
Allowing too much uncertainty into a project can reduce velocity.
Developers are responsible for what they achieve each sprint.
Do things that add value.
Get things done in a constrained time-box.
Know your capabilities...and your limitations.
Communications is essential! Keep 'em frequent, keep 'em short.
Central shared place (e.g. wiki) for project information

lecture#7 began here

Some Big Concepts

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?

Let's expand the discussion of use cases to a discussion of software specifications. Per Wikipedia, what I might informally and casually call a software specification is typically and more formally called a Software Requirements Specification, or SRS for those of you who like TLA's. Dr. Oman, our department's reigning software engineering expert, calls them SSRS (Software and Systems Requirements Specification), potentially including hardware or other aspects of the system besides just the software. It can be argued that developing the initial natural language prose document is not the software engineer's job, but instead the customer's; in practice, however, the software engineer frequently has to help, or do the customer's job to some extent. In any case, from an existential point of view, unless we were to choose a project with an extant specification, we must develop one.
There are IEEE standards for requirements specifications. Wikipedia's definition says the requirements specifications includes a set of use cases and in this class you can say that they are a prominent part of the requirements specifications development. Based on the IEEE standards, we have the infamous-yet-improved LaTeX edition of the CS 383 SRS Template.

Introduction to UML

Spend 5-10 minutes surfing http://www.uml.org/#UML2.0 and then read the Crag Systems UML Tutorial Chapters 1 and 2. A supplemental (non-required) reading resource for the diagram types covered in this class can be found in the middle chapters of "Programming with Unicon", where object-oriented features are being presented. 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.
In CS 383, we care about ~4 common kinds of diagrams, starting with use case diagrams. Most other UML diagram types would be used in specialized domains.

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.

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?

Example of how not to use e-mail for interpersonal communications:

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.

This e-mail may have accomplished a certain motivational goal, but it did not improve the working relationship between sender and recipient.

How to Approach Dr. J with Concerns

If you are happy with what we've been doing up to now, feel free to just file this section in a "just in case" folder, for future reference. My goal is to make software engineering happen. All the requirements are negotiable. All the tools edicts are negotiable. All you have to do is come up with a better plan, and sell me on it.

you can speak with Dr. J privately: you might find he is reasonable at times
you can speak with Dr. J as a group: Dr. J is more likely to hear a group
you can elect a leader: Dr. J will listen to duly appointed team leaders

Teams

Use Case Diagrams

One reason to do a use case diagram is to summarize or catalog what tasks are part of the system; a sort of table of contents for the beautiful set of use case descriptions that you should write. But the main reason use case diagrams exist is in order to show who does what, when different users (actors) participate in different (overlapping) tasks. If you only have one actor, or there are no tasks in which multiple actors interact, there may be no reason that you have to do a use case dialog. Consider the 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 began here

Pithy Software Engineering Quote of the Day

Design without Code is just a Daydream. Code without Design is a Nightmare."
-- attributed to Assaad Chalhoub, adapting it from a Japanese proverb.

Revision Control Systems

We have a lot of UML to learn, but we need to get settled on and using a revision control system.

Revision control systems (RCSs) are programs which track changes to collections of files (for example, the files that are part of a software project) over time
you can tell who did what, and revert to an earlier version if you get broken.
a related genre of tool are Software Configuration Management Systems. Configuration Management is when you integrate Revision Control, Testing, Feature Auditing, and (OS + hardware) Platform Adaptation and Porting.
While SCMs are a bit too much for CS 383, revision control is life.

A Brief History of Revision Control

SCCS: "Source Code Control System", one of the early, proprietary revision control systems from AT&T, inventors of C and UNIX. Library model (check out in order to write, then check back in) makes it difficult to overwrite someone else's code, but does not scale very well. Cool but dangerous idea: system integration with "make" on some Sun platforms kept you up to date automatically.
RCS: Early open source revision control system aptly named "Revision Control System". Library model. Set of many separate cryptic commands ("ci", "co", etc.)
CVS: "Concurrent Versioning System" is the open source RCS that defined the 2nd generation. Everyone can edit files at once, it is when you try to check in changes that things get exciting.
SVN: Subversion is almost just a better CVS.
Git: A third generation of these systems has emerged. Git was written by Linus, the inventor of Linux, giving it an unfair marketing advantage.
Mercurial: Another third generation revision control system is Mercurial (Hg). It is said to be much faster and simpler than Git.
Bazaar: Another third generation RCS, haven't used it, but it looks interesting.

Handwaving at SVN

Everyone in 383 should know a bit about SVN. Compared with earlier tools, they have these properties:

let programmers to edit any file at any time. Earlier tools "lock" files, allowing only one programmer to edit a file at a time.
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. Note: occasionally, automatic merging has a spectacular problem. Do sanity checks and develop system tests to avoid surprises.
works on multiple platforms (e.g. UNIX and Windows) and since they are open source, everyone can use them. Previous systems were not very portable (RCS) or proprietary and commercial (SCCS, PVCS, etc).
works over the internet, making it awesome for coordinating the development of public open source projects with personnel scattered around the world.

Lecture 9

Major SVN Commands

SVN works using a "repository" which is a database for source files. Unless you are creating your own repository, the first command you need is

svn checkout projectname

which grabs a copy of a named project from the repository. The various svn commands that manipulate the repository have the syntax

   svn command [filenames...]

The other commands you need immediately for SVN include:

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.

There are many other SVN commands, and command-line options, that you may find useful; read the manuals! One option of special interest is -r tag which let's you ask for older versions from the repository instead of the current version. This may help if the current repository gets broken. :-) Use it with care, however; when you go back to an earlier version, the repository doesn't think any changes you make apply to the current version. 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.

Git

It is possible to study Git relative to the SVN commands, starting with the GitHub Help and Everyday GIT pages. I will be learning this along with you this semester, and the "everyday git" page does not explain things much, it is more summary of what the set of knowledge about Git should be for starters. You don't mind reading hundred-page user's manuals for software tools, you are CS majors. Here is Git's. Obvious differences between Git and SVN:

peer-to-peer

"clone" instead of "checkout":

git clone git://github.com/cjeffery/sworsorc.git

seemingly, a "git add" required on already-existing cloned files in order to track and commit them. In fact, a "git add" to "stage" the file prior to each commit?
separate commit and push steps:
```
git commit -m "message"
git push...
```
When "git add" followed by "git commit" is overkill, a "-a" option to "git commit" will autostage it, i.e. eliminating the need for a prior "git add"

Scrum Roles

Adapted from Scrum Alliance

product owner

for our class purposes, this is me. decide what work will be done each sprint. maintain the backlog.

development team member

deliver increments of functionality each sprint. "they have the responsibility to self-organize to accomplish each sprint goal". product owner says what is to be done, devteam members forecast what can be done in one sprint, and decide how/who are going to do what.

scrum master

"servant leader" who helps the team follow the process.

"evolve the definition of Done".
help find and implement whatever technology and methods are needed to get to Done each sprint.
remove impediments
facilitate meetings, help team members

Creating an Initial Backlog

Adapted from Fear No Project

"Product Backlog" is almost: list of (not-finished-yet) Functional Requirements
Acknowledges Changing Requirements throughout project
SSRS Functional Requirements Section === backlog ++ completed items. Hopefully, backlog shrinks as completed items list grows long
The first backlog is "vision, analysis, and marketing promises"
Oh by the way, everything needs to be prioritized.
Responsibility of the product owner (darn!). But, as an educational exercise, I can of course foist off on you-all as much as I want.

S&S Functional Requirements 2/5/14

This was brainstorming input to the initial product backlog development.

Graphical interface
Network capability for N users, N up to 7
Implement Game Rules
Save Game States
Play Game to Completion
Determine outcome (winner(s))
Customizable scenarios
Scenarios
Linux + Windows (+ MacOS if possible)
"Reasonable performance
Asynchronous mode
Full screen?
Windowed mode?
Multiple Game Instances
"matchmaking" server
main menu
All use cases

Lecture 10

HW#1 Team C: Document Source File(s) Please

Say Hello to "Scrum Master John"

A Brief Comment About Use Case Diagrams

Let's look at work David was brave enough to share...

Overview of Projects

Software engineering applies to small projects, but matters more for big 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?

Project Communications

Plan to try out and/or gain experience with each of these forms of communication this semester.

Problem Inspection - gather information about the problem: did first pass, reiterate as needed
Requests for clarification: you may start asking me questions any time now.
Status meetings: in particular, we will do a form of "sprints" as defined by agile methods/extreme programming
Peer reviews: aside from pair programming, which is peer review as code is written, there are reviews of design work and/or code that you conduct within your team or subteam.
Client / Project Reviews: you learn a lot when reality intrudes on your wishful thinking
Releases: software releases are the ultimate awesomest form of communication
Requests for change: Early software engineers blamed all their troubles on the customer. Agile software engineers embrace requests for change, and provide the customer with functionality as early as possible so that they get this feedback right away.
Issue resolution: Testing, bug reports, managing bugs and getting them fixed in a timely manner all contribute to the overall success or failure of a project.

Team Organization

With (for example, around) 15 people on your team, you will probably divide labor and organize into subteams. Within the subteam, different team members may play (potentially multiple) varying roles: programmer, graphic artist, user interface designer, system architect, network programmer, website- and user-manual author, etc. Question: how do (sub)teams talk to other (sub)teams?

Hierarchy	Peer-based	liaison-based
Each subteam has a leader. Leaders of each subteam meet regularly. Pro: scalability. Con: leader spends much of their time in meetings.	Anyone talks to anyone. Pro: politically correct, egalitarian, fits student mind-set. Con: chaotic. hard to find the right person to talk to.	Subteams have a designated liaison that other teams may contact. Pro: offloads communication from overworked leaders. Con: liaison potentially adds another layer of indirection to communication. Layers slow things.

Schedule

This is harder than just developing a linear sequence: in a large team effort, multiple things must be developed in parallel, and various tasks cannot be started until others are completed. Gantt and PERT charts are two ways to present this information, one with a strong horizontal time axis, and one without.

Backlog and Sprint Planning

Analysis - What Else Besides Use Cases

Having studied the application domain it is time to produce an analysis model. "Structure and formalize the requirements". 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» enclosed in angle quotes or crudely approximated with less-than and greater than (<<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

Red flags:

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

Red flags:

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

Coordinate boundary and entity objects. "Manage" the forward progress through a use case. One control object per use case, or maybe per actor in the use case.

Sequence Diagrams

This UML diagram type is kind of redundant with use case descriptions, but the shift in perspective often identifies additional classes and methods. One way to organize sequence diagrams is to use columns thusly:

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

Lecture 11

Class Diagrams

Class diagrams are the "meat and potatoes" of object-oriented analysis and design. Class diagrams describe more detailed, more implementation-oriented things than use case diagrams. Class diagrams can present varying levels of detail about the classes in them. Some class diagrams may have nothing more than the class name for each class; others may hold the full list of fields and methods. When more space is taken by class details, there is room for fewer classes per diagram, so you often have "overview diagrams" that show many classes and their connections, supplemented by "detail diagrams" that show more information about closely related classes.

Associations

Perhaps the main purpose for class diagrams is to identify and depict relationships between objects that will be needed in the running system. An association is the word we use for such a relationship. We draw a line between the rectangles for classes to depict an assocation. There are three major types of associations:

inheritance
aggregation
user defined

Inheritance: the Un-Association

We have discussed how inheritance is not really an association, it is a relationship between kinds of things, in the design and maybe in the programming language type system, whereas associations are relationships between instances (objects) at run-time. Inheritance is so vital that many class diagrams focus specifically on a large inheritance class hierarchy, similar to a biological taxonomy of species. Inheritance is usually a static feature of a design, although there exist languages in which instances can change who they inherit from at runtime. Here is an example class hierarchy from the Lethbridge book (chapter 2):

Aggregation: the Simplest Association

Aggregation, the parts-whole relationship, is perhaps the most useful association of all of them. Many many complex things are made up of an assembly of simpler items. There are at least two flavors of aggregation, static and dynamic. Static aggregation is lifelong aggregation; the parts cannot exist apart from the whole, or enter or leave the whole. Dynamic aggregation is more like a team whose members can come and go. Here is an example of a massive chain of aggregations with a familiar theme:

Lecture 12

Grading Update

HW#1 returned today. Quick peek at Rubric Sheets
potential triple-jeopardy: things not understood get graded again on exam, and in project grade.
Looked at a lot of Use Case Diagrams, mostly good, still grading
Looks like "Scrum Grader Jayendra" will be joining us

Backlog Update

Each week, get your name attached to 6-9 hours' worth of backlog items. Do them. Track your time, somewhat. Turn in a report.

GitHub Update

17/17 have requested/received Collaborators push privileges.
11/17 are in README.md
doc/README.md describes the use of the doc/ subfolder
The problem with Java IDE's (they require their own sick folder structure)

Association Details

There are many details added to associations to show more information about the relationship. Some of these details are discussed in Chapter 5 in your text.

link: just as classes have instances at runtime called objects, associations have instances at runtime called links. Links occasionally are so important and complicated that they need their own attributes. The main information about them is usually their lifetime, and what instances they are connecting.
multiplicity: a.k.a. cardinality, it is the number of object instances per link instance in a given relationship
qualifier: some many-to-one relationships have a unique key used to traverse the association.
roles: the different ends of an association may have differing roles associated with them. Especially useful if both ends of an association connect the same class.
composition: there is a special kind of aggregation called composition, which denotes aggregations in which the component parts have no existence apart from the whole thing. The relationship is hardwired, static, or constant. Composition is marked using a filled diamond; hollow diamond means a regular (transitory, or dynamic) aggregation.

Here are some more class diagram figures from some old software engineering text (Pfleeger). One point here is that it is logical to start with a simple sketch of classes and basic relationships, and add many details later on.

Lecture 13

A Tale of Two LaTeX Errors

leftmargin=! was not OK, appeared in team A's "al" environment
\subtitle was not defined; used in team B and team C
Not a big deal, but in a large group / multi-platform project, keeping our LaTeX as portable (simple?) as possible is more important than being clever or impressive.
I don't really want to have to add things to my TEXINPUTS environment variable (or install new packages) so that I can pdflatex your homeworks...

...and the HW2 Winner is... Team A

all teams had a lot of use cases more or less in common
based on format and content, team A is our reference going forward
a good number of use cases from team C deserve consideration
look in use case descriptions (as well as original specifications) for classes and relationships

User-defined Association Examples

Here is an association you might see in a human resources application:

Person

employee employer
Works-for

Company

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?

Class Diagrams Examples -- closer to home

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 previous students did right, and what needs to be changed. We can also work, as an example, some of the classes and relationships for our projects.

A "Good" Class Diagram...

Has more than a couple classes
Has meaningful associations, adequately defined
Notationally, triangles, diamonds and so on in the correct locations; nothing missing
Has an appropriate focus on application domain (showable to a customer domain expert, not encumbered yet with implementation artifacts).
http://www.agilemodeling.com/artifacts/classDiagram.htm -- Note that Figure 9 towards the end of this article looks fishy to me. Why? How would you fix it?

More Class Diagram Examples

If you google or UML class diagram examples, you will come up with lots of links like the following which maybe useful in coming to terms with UML class diagrams. However, the main way to get used to them is to practice them yourselves, which we will do in class today. Lecture 14

Five minutes each team A/B/C

Presumably, on your class diagrams.

WAR comments

As of "quitting time" last night, I received 6/17 WAR reports. Clearly I did not spend enough time explaining what and why. HW#3 and class webpages clearly state: Tuesday 6pm.
Basic confusion regarding required Subject: line of email. Literal interpretation would be
```
Subject: [CS383 WAR], Clinton Jeffery/2/19/2014
```
In retrospect, use [CS383 WAR] name, date, with date in mm?/dd?/yyyy format
Length: helps to keep it under a page. Go longer as needed, fine.
Format: as given in the WAR tutorial
Why WAR? Gives me another channel of feedback. Helps me see where additional attention is needed. Allows lazy folks to self-identify.

Git Comments

I'm pretty sure I just overwrote our whole project on github through my incompetence. - a student

This is one of the cooler confessionals I've had the pleasure of receiving in my 21 years as a CS faculty.
Q: "How much Git competence is required for CS 383?"
A: more than "total noob", less than "zen master".
Our goals should include: learn some more Git each week for awhile.

Reflections on the SSRS

In CS 383 we are constructing a "book" documenting our project. The first major chapter, on requirements, is about finished and will consist of our master use cases and preliminary class diagrams.

Using Git (SVN, we miss you) to merge changes works well with line-oriented, text-based content.
Beware binaries: revision control doesn't cover changes to binary image files. This is the single biggest argument for using plantUML instead of a fine UML drawing tool like Dia.

Software Project Estimation

This material originated in CS 384, but logically it seems you would want to estimate things near the start of a project, like after you have sized it up via requirements analysis. I looked at websites for some of this material, in addition to consulting Roger S. Pressman's book on software engineering.

Historically, software was an insignificant % of the budget for a computer project. Moore's law has fixed that.
Big software cost estimate errors kill corporations, and someday countries.
Ways to be accurate: estimate after finished, estimate base done having done the same thing previously, decompose into estimatable subcomponents, use an (empirically validated?) model
Estimate based on size, in LOC or function points (FP)?
The reason decomposing helps: "similar" projects are rare, but similar functions, classes, modules, data structures and algorithms are common
Example based on LOC: after careful decomposition, one gets an estimate that a software will take 33KLOC, that the organization writes 620LOC per person-month, and each month costs $8K. Then total cost is $431K and 54 months. (Pressman)
Example based on FP: after careful decomposition, the project has 320 FP, but weighted by difficulty it is adjusted to 375 FP. The organization averges 6.5 FP/month @ $8K, cost/FP is $1230 and total project cost is $461K and 58 months. (Pressman)

COCOMO

Boehm's COnstructive COst MOdel. Barry Boehm is one of the luminary founding fathers of software engineering, inventor of the spiral model of software development, and one of the early predictors that software costs would come to dwarf hardware costs in large computer systems. COCOMO is acronym-laden, and subject to perpetual tweaking and twisting of its interpretation. Whatever I give in lecture notes about it will contradict various COCOMO authoritative sources.
COCOMO starts from an estimate of SLOC (source lines of code). This includes declarations, but no comments, no generated code, no test drivers). Boehm also refers to KDSI (thousands of delivered source instructions) and it appears to be used more or less interchangeably with SLOC.

Scale Drivers

COCOMO specifies 5 scale drivers:

precedentedness
development flexibility
architecture / risk resolution
team cohesion
process maturity

Cost Drivers

COCOMO has ~15 parameters that assess not just the software to be developed, they assess your environment and team as well. They are rated one of: (very low, low, nominal, high, very high, extra high), with the different values contributing multipliers that combine to form an effort adjustment factor. From Wikipedia:

Product attributes
Cost Drivers	Ratings
Cost Drivers	Very Low	Low	Nominal	High	Very High	Extra High
Required software reliability	0.75	0.88	1.00	1.15	1.40
Size of application database		0.94	1.00	1.08	1.16
Complexity of the product	0.70	0.85	1.00	1.15	1.30	1.65
Hardware attributes
Run-time performance constraints			1.00	1.11	1.30	1.66
Memory constraints			1.00	1.06	1.21	1.56
Volatility of the virtual machine environment		0.87	1.00	1.15	1.30
Required turnabout time		0.87	1.00	1.07	1.15
Personnel attributes
Analyst capability	1.46	1.19	1.00	0.86	0.71
Applications experience	1.29	1.13	1.00	0.91	0.82
Software engineer capability	1.42	1.17	1.00	0.86	0.70
Virtual machine experience	1.21	1.10	1.00	0.90
Programming language experience	1.14	1.07	1.00	0.95
Project attributes
Use of software tools	1.24	1.10	1.00	0.91	0.82
Application of software engineering methods	1.24	1.10	1.00	0.91	0.83
Required development schedule	1.23	1.08	1.00	1.04	1.10

COCOMO equations 1 and 2

Effort = 2.94 * EAF * (KSLOC)^E
Time_to_develop = 2.5(Effort)^0.38 where EAF is an Effort Adjustment Factor derived from cost drivers, and E is an exponent derived from the 5 scale drivers. EAF defaults to 1 and E defaults to 1.0997. But since these are parameters, it is largely the structure of the equation that matters. Effort is in "man-months" or "person-months". Total time to develop is derived from this number. The co-efficients in these equations are samples that get adjusted in particular environments.
Example: Average? 8KSLOC? Then effort = 2.94 * (1.0) * (8)^1.0997 = 28.9 person-months
Calculators:

Estimating SLOC

Basic ideas summarized: you can estimate SLOC from a detailed design, by estimating lines per method for each class, and summing. Or you can do it (possibly much earlier in your project) by calculating your "function points" and estimating lines-per-function-point in your implementation language.

www.spc.ca/resources/metrics/software_estimation.pdf
Jonathan Hodgson's estimation page looks especially useful
QSM's LOC/FP table. Please take this with a mountain of salt.

Function Points

Perhaps this might be the 2nd type of thing you measure about a forthcoming or under-construction software project (after "# of use cases").

# user-input activities
# user-output views
# user "queries" (for database apps)
# of data files
# of external interfaces

Weight each of these; perhaps just designate as "simple", "average", or "complex". Sum of weights = "function points" of program.

Statecharts

A statechart, or state diagram, depicts dynamic properties of a system. A statechart consists of

a set of states: drawn as circles, ovals, or rectangles, with a label or number inside.
a set of transitions: drawn as arrows from one state to another.
a start state, and a set of final states

Some of you may be getting an eery sense of deja vu at this point. Statecharts are a non-trivial extension of finite automata, because they have:

instead of "input symbols", events associated with transitions: these may be complex, synchronous or asynchronous
events may have conditions, drawn inside square brackets
activities

Statechart Diagram Examples

A "Good" Statechart Example

Has more than a couple states
Has a meaningful, well-defined scope -- the class(es) whose behavior it governs are specified
the representation of the states is explicit (which fields, and which value ranges, denote the states).
the transitions are are labeled with events. conditions are present where needed
actions, activities, or changing behavior controlled by the states is given
http://www.atmarkit.co.jp/fjava/devs/mda_tool01/statechart.gif

Tieing StateCharts and Class Diagrams together

For any statechart, what class does it govern? What attributes store the states? Consider the following example...

Lecture 15

Announcements

Midterm coming up on Wednesday 3/12. Review on Monday 3/10.

Reading Assignment: Software is Hard

Peek at the SSRS

We are moving on from requirements to design
Are there any major aspects of requirements analysis we will need that we haven't done already?
If so, we should add them to the backlog, and otherwise the backlog will start filling up with software design tasks.

More Statechart Examples

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 problems: legibility and printability
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.

Scrum Grader's Report

/src/temp/ScenarioConfiguration and /src/temp/scrolling_map_demo did not run for him, what special build instructions are needed?
Where are JSON libraries in Github; if not present, let's put them there.
What CLASSPATH or other instructions are needed to compile the scrolling map demo
Assignment fulfillment traceability: for every Github commit that fulfills a HW/sprint task, the github comment should include an identifying label, as in HW5#3 for the third sprint task listed in HW #5.

Checkout a few Agile Methods and Agile Practices

This is a reading assignment. Learn the following 5 buzzwords, so you can use them casually in conversation with colleagues, job interviewers, midterm examinations, etc.

Our goal: think about these and develop our own "agile" process for the rest of 383. Possibly by experimentation or by vote. Lecture 16

Sprint Planning

status report on the last sprint

what got done; demos
problems and new items for the backlog

goals for the week

subteam structure; redundancy avoidance
"unify" class design in UML and code.
turn prototype code into "stubs" in github src/ subdirectories
add in details from both directions and resolve conflicts/duplication

Sprint Management Tools

Trello

Emacs "Org Mode"

Lecture 17

Student-Identified Issues

Unit/group id or numbering system
Lack of cohesion among student efforts. Need communication strategy.
Intra-class messaging system needed.

Instructor-Identified Issues

Need for students to proactively own (more of) the planning
Need for full set of model classes, in src/model, corresponding 1:1 to master class diagrams set (which should be renamed btw)
src/model is your default location for game (application domain) entities.
client/ is your default location for GUI/view code.
server/ is ... mainly for communications code, and maybe the game state.
Need for public API for access to the model.
- Given the master class diagram, howabout a static/singleton instance of Game (Game.game? Game.g?)
- Given a hex id (string "0904"), how do we get the Hex instance? Its province? Its Stack?
Spells prioritization
Scenarios prioritization

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. Our next job is to identify design goals, establish an initial subsystem decomposition, and refine that subsystem decomposition until all design goals are satisfied [Bruegge].

Design Goals

Some design goals come from the nonfunctional requirements, and some emerge from further discussion with the client, and that they all need to be written down. The nonfunctional requirements are already written down. The client is not a software designer, what do they know about it? We need to think "outside the text" a minute here.

Subsystem Decomposition

What exactly is a subsystem? The amount of work a single developer or team can produce? This idea due to [Bruegge] seems bad on the face of it. The subsystems should address relatively separable or independent elements within the overall system; it should be logically driven by the requirements or our ideas of how to meet those requirements. But it is the case that one of the consequences of subsystem decomposition is to identify pieces that persons or teams can focus on in detail. A subsystem is characterized by what services or interfaces it provides to the rest of the application.

Object Oriented Design: Adding Detail

You can view object oriented design as a process of adding detail to class diagrams. We will look at as many examples of this process as we can. For detailed design, we need to reorganize/regroup and assign teams to go into the details of various aspects of content delivery and activities.

User Interface Design

By the next round of turnin, we will need to establish a fairly complete user interface design for things like the main screen. User Interface Design is the subject of an entire course and for our purposes we will have to settle for a rudimentary and primitive introduction. User interface design starts from what tasks/activities the application is to support. You probably will discover a few tasks in this phase that requires a dialog for a task we haven't identified previously. But mainly we need to design dialogs and sequences of actions to perform specific tasks in use cases.

Aspects of User Interfaces

look: this is the most obvious part of user interface design, but not the most important part
feel: this is like: what clicks perform what operations. how many clicks does it take. does it feel like you are directly manipulating the objects on the screen, or does it feel like you are following a long sequence of orders you receive from the program.
metaphors: users can quickly learn an unfamiliar task, or quickly interpret an unfamiliar graphic, if a familiar metaphor is used. Examples: "desktop metaphor"
mental model: a user interface provides the user with a particular mental model of how they view the system. designing that model will determine many aspects of the user interface (what info to show, what tasks to support)
navigation rules: navigation through large structures which don't all fit on the screen is a central issue for many (most) applications.

A few Obvious User Interface Tips

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

Design Buzzwords and Vague Concepts

Here are some buzzwords and ideas that relate to design:

Design methods

1. modular decomposition: top-down breaking up function into parts
2. data-oriented decomposition: top-down breaking up information into parts
3. event-oriented decomposition: identifying what changes are to be made, and when they occur
4. outside-in design: blackbox I/O orientation
5. object-oriented design: relationships between data

Things that get designed

1. Architecture: interaction between programs and their environment, including other programs
2. Code: algorithms and data structures, starting with equations, pseudocode, etc.
3. Executable/package: how is this system going to be installed and run on user machines?

Common architectures Pipes, layers, client-server, peer-to-peer, ring ...

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

Extemporaneous Comments

Getting familiar with your piece
Printed sprint reports

Lecture 18

"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

Design Patterns

Reading Assignment:

Wikipedia article on (software) design patterns
"Idioms and Patterns as Architectural Literature", by Coplien
"The Structure of Pattern Languages", by Salingaros (optional reading assignment)
You can also check out this link: from Celinio's blog and see if it is still live.

Design Patterns Background

Design Patterns were invented in homage to architectural patterns, specifically the work of Christopher Alexander. Their initial introduction for software design, in a book by Gamma, Helm, Johnson and Vlissides in 1995, had an electrifying effect: suddenly it was no longer possible to talk about software design without referring to as many of the patterns as possible. A whole mini-industry and cult sprang up around the task of specifying as many patterns as possible. Of course, most of those patterns are not very useful. 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.

At least one software engineering textbook author (Bruegge, section 8.4.7) has suggested 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!"
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

A quad-tuple consisting of:

Design Patterns proponents are trying to create a common vocabulary of buzzwords, to reduce the cost of communication and increase the level of understanding when software engineers are talking with one another. Reading assignment clarification: if you don't have a copy of the real Design Patterns book lying around, check out the following:

Wikipedia article on (software) design patterns

Lecture 21

Project-Related Matters

At the moment, Github shows 25K LOC
- So far we have "nothing" to show for it ?!
- it would seem like integration of code we write will be at least as challenging as writing code.
This is a weird class, where you have to analyze, decide on, and commit to delivering your own completed homework assignments.
HUD team, and a few individuals, e-mailed me regarding your commitment for this Sprint. For others, you have committed to a 0 as far as I am aware.
My problem: how to "Trust, but Verify" your 383 efforts?
- The Scrum Grader found no commits for at least 4 persons in the last sprint. Why?
- At the moment we have a broad lack of accountability, and it is easy for some to slack. Unfortunately, it is also easy for you to get a 0. Ideas?
Your problem: how do I make my work visible to the Scrum Grader?
- Actually do some (>= 6-9 hours' worth) useful work each week.
- Get it integrated (called successfully from) the class' code.
- Include explicit pointers to your work in your WAR
- Make it as Easy as Possible to award you points. For example, there was one person who committed a statechart .pu but not .png

Netbeans, Ant, and Maven

How much time have you invested so far in learning to use Netbeans? What is the state of the Master Netbeans Project? How do I try it?
Ant appears to be the underlying tool used by netbeans for project builds. Read at least its Introduction and Tutorials pages, from its Documentation link. Ant is on wormulon, so even though Netbeans is not there (?), we might in principle be able to build there if we wanted to. Ant Version on Wormulon: 1.7.1. On machine in my office: 1.8.2. Current version: 1.9.3. Impressions:
- Ant is more portable than "make"
- Ant xml files are much, much longer and more user-hostile than makefiles
  - Corollary: Ant files are best edited via an IDE such as Netbeans
- The authors of Ant are arrogant and stupid (e.g. "Makefiles are inherently evil" remark)
For what its worth, Maven is a more powerful tool than Ant. You should read its Maven in 5 Minutes introduction.
- Maven uses a Project Object Model
- it has uncanny abilities to reconcile complex projects with multiple versions of code compiled against different JVM's, and to download dependencies not present on a machine

The Patterns

We will not cover all of the GoF design patterns, several are similar to each other and they are not all equally important. A ton of the examples in the Design Patterns book revolve around the GUI aspects of "a diagram drawing tool" (uniquely relevant for some instances of CS 383, such as Fall08)

Composite

Compose objects into tree structures to represent part-whole hierarchies (i.e. aggregation), plus:

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.

Abstract Factory

Provide an interface for creating objects without specifying their concrete classes. Example: a UI Toolkit that can create either Qt or Windows-native components.

Builder

Separate the construction of a complex object (traversal algorithm) from its representation (data structure), so that the same construction process can create different representations. Example: an RTF reader might parse input (construction process), producing different representations for different output (ASCII, LaTeX, Wysiwig...)

Factory Method

Let subclasses decide which class to instantiate for a specified object-creation interface. Example: application framework needs to instantiate classes, but only knows about abstract classes, which it cannot instantiate

Prototype

Specify objects to create using a prototypical instance; create objects by copying. 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

Ensure a class has only one instance, and provide a global point of access. Example: a print spooler. Highlander quote: "There can be only one".

Adapter

Convert the interface of a class into another interface, expected by clients.

Bridge

Decouple abstraction from implementation, so the two can vary independently.

Design Patterns - Dr. J's "Personal Favorites"

These patterns seem valuable in Real Life, from my personal experience.

Decorator

Attach additional responsibilities to an object dynamically. An alternative to subclassing for extending functionality.

Facade

Provide a single unified interface to a set of subsystem interfaces. Goal: reduce coupling between a subsystem and the rest of the system. Can anyone say "DirectX" or "SDL"?

Flyweight

Use sharing to support large numbers of fine-grained objects efficiently. Share the constant part in a big pool; reduce the cost of thousands-of-similar-objects. GoF mentions word processor example, but Dr. J has lots of personal examples from the field of compilers.

Flyweight -- key properties

Use flyweight pattern when

You have large number of objects
The objects have substantial shareable constant state ("substantial" means: a lot more than a pointer's worth)

What you are really doing: pooling the constant part, thus shrinking the non-shared part. Design patterns literature will often refer to the dynamic part of the instance as the extrinsic part, and the pooled/shared part as the intrinsic part. Extrinsic part might be represented by a (smaller) instance OR by the client code, which passes it in as parameter(s) to the (shared) flyweight instance when requesting its behavior.

"Smoking Gun" Flyweight Examples

Personal explerience and googling "flyweight examples" turned up many examples.

word processor: the design patterns book mentions that much of the elements of a rich text document can be shared. Not just repeated string text, but the font information, etc.
lexical analysis: similar to the word processor example, compilers can often share memory for repeated elements in their data structures. Not just the string identifiers (which repeat a lot) and constants, but other lexical attributes (such as what filename the token was found in). Shareable structures also occur in syntax, type checking subsystems, etc.
phone systems: things like "ring tone generators" can be shared across a large number of telephone users
insect populations: I guess these are knee-jerk examples for a pattern named after an insect...
war games: many games (and movie animation softwares) have to simulate a large number of solders. Although part of their data is instance-specific (location and orientation, health and ammo), another very large part of their data (3D model of physical appearance) is shareable

Proxy

A placeholder for another object to control access to it. Networked/remote objects.

"Smoking Gun" Proxy Examples

"Secure" objects: Proxy might be in place in order to impose a layer of security on access
Distributed object: Local object may be serving as a proxy for a remote object.
Reference counting: Provide a proxy for a pointer and you can count # of references to it
Simplifying or hiding the use of flyweights: Proxies are the lightweight instances

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. Decouple the sending of a message from who will receive it. Fundamental to concepts such as exception handling, and event-driven programming. Often called delegation. Note the close relationship here to Composite (chains usually follow a path from a leaf to a root through a hierarchy), and to the classic "Chain of Command" used in the military and other hierarchies.

"Smoking Gun" Chain of Responsibility Examples

in GUI's: incoming user / gui events are routed through a chain of GUI components from the outermost window/dialog through intermediate panels into the inner components, until you find the (first) component that agrees to handle the event.
obtaining approvals, lodging complaints: approvals and complaints often follow a protocol from local to global
symbol tables in nested scopes: especially in heavily nested situations, such as pascal programs, or "big Java" apps with packages inside packages inside packages

Command

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

"Smoking Gun" Command Examples

Thread pools: If a set of N threads is being shared by many concurrent jobs, it sure helps for each incoming job to be turned into an object so it can be placed on a queue.
Network protocols: The X11 protocol and many others are structured around the notion that network messages are serialized commands.
GUI "Wizards": A multi-page GUI wizard can be viewed as constructing (filling in) a command object which is finally passed on to the rest of the system when the final page Submit button is pressed.

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.

This pattern is too widespread to need much in the way of a smoking gun. Lots and lots of computing gets done by building collections of things and walking through them afterwards. It is common to need to support multiple iteratings on the same collection at the same time, which is what this pattern achieves, by pulling the "walking through" state out into a separate object from the collection being iterated through.

Mediator

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

"Smoking Gun" Mediator Examples

mapping between users and groups in file systems permissions: As argued on sourcemaking.com, a mediator can be used as an object that instantiates and manages a many-to-many relationship.
dialog class in a GUI: a dialog facilitates interaction between other GUI controls. Does this imply that mediators might be common in "control" situations in general?
chat application: the central server that connects n users is often a mediator.

Memento

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

"Smoking Gun" Memento Examples

Core dumps and other process "restore" and "checkpointing" features: A traditional mechanism for computer jobs that ran so long that the odds were good that a machine crash would occur before the job finished.
Object serialization mechanisms: These can be used to save on disk OR to move an object to another machine

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.

"Smoking Gun" Observer Examples

the Model-View-Controller: uses an observer to update the views whenever the model changes
...

State

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

"Smoking Gun" State Examples

car transmissions, vending machines, ceiling fans...
essentially, all statecharts??
"mode-based" user interfaces: e.g. vi's "insert mode" vs. "command mode"

Strategy*

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

"Smoking Gun" Strategy Examples

file handling: for small files, use strategy A, for large files use strategy B
salaried vs. hourly employees: methods for calculating their pay will be different

Template Method

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

There is no smoking gun needed for the template method, it is a common way (popularized with direct support in Ada (generics) and C++ (templates)) to share an algorithm across a diverse range of data types.

Visitor

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

"Smoking Gun" Strategy Examples

At least one person really hates the visitor pattern. Is it that bad?

Antipatterns

We only have time to mention the existence of these, but they are fun.

Some Final Thoughts on Patterns

These are from Coplien's Paper.

Emphasis on patterns is analogous to emphasis on associations instead of classes
Patterns are about systems, not just individual components
Patterns can form "microarchitectures"
Patterns can be applied to other areas besides design (process patterns, user interface patterns, teaching patterns, project organization patterns...)
Patterns can be "interdisciplinary" among different software areas.
Patterns thrive on capturing and articulating points of complexity (no complexity => no need for patterns). OOP needs patterns worse than traditional structured programming because OOP tends to be more complex than structured programming (e.g. dynamic data-driven relationships instead of static code-control-flow relationships).
Patterns' immediate ancestor were "programming idioms"
- Idioms capture a solution to a problem in a context (= pattern)
- Idioms capture (language-specific) interactions between objects
- Design patterns capture language-independent interactions
Patterns are about people, not houses, or software. The human side is usually about either utility, or aesthetics. Software designs tend to capture API's and data structures but miss nuances of relationships; software process distances itself from unreliable human beings.
Human Software Pattern Example: Simply Understood Code

Interaction Diagrams

Two additional UML notations under the category of "interaction diagrams" that may be useful are: sequence diagrams, and collaboration diagrams. There is a close relationship between these two diagram types. The following figures are from "Unified Modeling Language User Guide".

Sequence Diagrams

Sequence diagrams are classically used to show parallel threads or processes and their communication, but they can certainly depict control flow bouncing around between objects within a single thread. To create a sequence diagram, you line up all the involved objects as columns along the x axis, and use the y axis to depict time (or vice versa).

Collaboration Diagrams

Collaboration diagrams are semantically equivalent to sequence diagrams, but are telling a sequential dynamic story atop (or "in the context of") a class diagram, making it somewhat easier to relate them back to the class diagrams. To create a collaboration diagram you start with a (subset of a) class diagram and annotate it with specific sequences of method calls, which are textually numbered to depict their ordering.

Why are sequence and collaboration diagrams useful?

These UML diagram types help connect the use cases and classes. Each scenario (== sequence of steps for a use case description) can lead to a collaboration diagram. The collaboration diagrams in turn help identify missing classes, methods, and associations for class diagrams.

Look at a few more Collab and Sequence Diagrams

From our books, or from the web.

Vertical and Horizonal Teams

Consider the major technical categories for your project (UI, database, etc.). It is possible to organize teams around these categories, or around functional tasks, each team being responsible for a set of related use cases. Which is better, and why?

Administration team: account creation and management, user reporting
Navigation team: integration / user interface / map / activity selection
Application Mechanics team: develop content / activities / phases / gameplay
Data team: database, file and/or in-memory data structure representations
Algorithms team: problem solving from the internals point of view
Help team: develop automated and/or human-based help communications
Network team: develop inter-process communications as needed

Where we are At

Lectures: Time for implementation and testing
Project: Give me a Star System Game, starting from working use cases, one at a time, and bottom-up.

Adjustments

Individual Accountability

This means WAR.

Documentation vs. Demo vs. Delivered Functionality

Documentation is empty without Implementation.
Implementation is rhetorical without Delivered Functionality.
Delivered Functionality is useless without Documentation.

Are you a team?

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

Produce readable design document(s)

I have to be able to read and understand project documents! 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.

The Master Design Document

Although we want to emphasize agility :-) let's consider how our agility might be compatible with a goal of having a design that makes sense when viewed as a whole. Consider the SSDD Template; it has additional suggestions that may be useful, such as a Requirements Traceability section that maps from requirements elements to their corresponding design elements. In fact, the main difference between doing it waterfall vs. doing it agile is whether you do it all at once up front, or gradually. The outcome should still be high quality software whose design is documented.

Navigation Aids

I won't even notice your project documents unless home pages, tables of contents, or indices include pointers to the good stuff. For example, how do I navigate and discover the many documents that are accumulating in your SVN?

File Formats

Generally I might not bother to read/grade a document that I cannot easily browse from my desktop linux machine. This affects .doc vs. .docx, the use of Visio, etc.

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.

Git Tip

If "git pull origin" is not working for you, you might try "git fetch origin +master:master". The Git tutorial says to use "git pull origin master". The implication is that the use of a default branch (master) might not work reliably, or that there is no default branch.

Design Tools

Design Tools cover a wide range of functions ranging from UML drawing tools to user interface builders. Anytime design tools come up, the phrase CASE (computer-aided software engineering) is liable to get used. Ideally a CASE tool would integrate and automate the many phases of software engineering, including design. Since the waterfall is not realistic, ideally a CASE tool would be able to show changes in UML diagrams that occur in the coding phase. 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.

Dr. J's Reflection on UML Diagram Types

We need to spend some more time on getting the Details worked out for our software design. UML is not going to magically solve that for us, it is a set of diagramming notations, no more. Having said that, it is the case that bad UML diagrams may make it more difficult for us to accomplish our goal (of working out the details well enough to where we will be able to implement them), and good ones may help. 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...
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 interaction (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?

a pattern name

a description of what problem it solves

a description of the solution

an assessment of consequences and implications of the pattern

Expanded Definition

Name and Classification

Intent

Also Known As

Motivation

Applicability

Structure (e.g. UML)

Participants

Collaborations

Consequences

Implementation

Sample Code

Known Uses

Related Patterns

How Design Patterns Solve Design Problems

finding objects - if the pattern says you need one, you need one

determining granularity - several patterns address granularity explicitly

specifying interfaces - patterns describe part or all of the public interfaces of the classes in them

specifying implementations - patterns may include known-efficient code samples

code reuse - "design reuse facilitates code reuse"

How to Select a Design Pattern

GoF suggest several ways, such as

look for which design problem above affects you, then look for design patterns that pertain to it

scan all the patterns' Intent sections

study how patterns interrelate

study patterns of similar purpose - to tell when to use which 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

Buy the GoF book, read the pattern in detail

Look at the sample code to get a concrete feel for it

Apply (translate) the pattern Structure section to your application classes

Adapt the sample code when it is appropriate to do so; otherwise write your own Lecture 19

WAR Report Issues

Do not be SO sketchy that I can't tell what you did, where I can see it, or (very roughly) how much time you spent. I want pointers to work committed, and enough information to have a feel for whether it was meaningful or difficult or whatever.
"Its difficult to plan what I'm supposed to do. A few people in the group just work on several parts of the project, then inform everyone what they've done it. So its very difficult to know what I should work on so I don't break anything."
"Having the last 5 minutes of class to discuss with group would be helpful."
"I am not able to get together with my group during their meeting times."

Lecture 20

HW# Update

I will give copies of WAR reports to scrum-grader Jayandra each week. The reason you have to include pointers to work is so that he can find it.
Implication: if a given piece of work isn't in Github, it didn't happen, at least for grading purposes.
Scrum-grader Jayandra has requested, for future HW, that commit comments include the HW# for which the commit applies. For example instead of a commit comment like "Posting my Statechart", you should write a commit comment like "Posting my Statechart (HW6: Multiple Teams #X)", where X is the homework deliverable. In order for this to work, I will change from bullet-lists to numbered-lists in future homeworks.

Some Cynical Observations About Design Patterns

Of course these were not new inventions, they were a catalog of tried and true methods. That is OK.

2 comments:

My Prime Journey23 March 2022 at 14:33
You can always get social media marketing services in order to get evolved in social media marketing because you need to maintain and optimize your profile, post pictures and videos regularly, respond to comments and get customers to build your brand.
My Prime Journey23 March 2022 at 14:50
if you want to get best software development services in USA you need to get in touch with Unisoftwares. Software development services consists of a process in which a software/application is designed under a specific plan strategy to meet the requirements of a business or personal objective.

Tuesday, 1 April 2014

SOFTWARE ENGINEERING FOR STUDANT

Introduction to Software Engineering

The concept of literate programming

Course Perspective

Recent (Dr. J Dynasty) History of this Course

What I Learned from Previous Iterations

Things I've Learned cont'd

External Inputs

Discussion of this Year's Project Topic

Constraints on the Project

Project Topic Candidates

Discussion and Vote on Project Candidates

Expectations Management

Languages

Basic Concepts for This Week

Use Cases and Class Extraction

Terminology

Use Case Descriptions

Use case descriptions, examples

Discussion of the Agile Manifesto

Sprint Meetings

HW#1

The Core Problem of Software Engineering: Complexity

Famous software "engineering" failures

Requirements Elicitation Techniques

Scenarios

From Scenarios to Use Cases

Use Case Writing Guide (adapted from Bruegge)

Weekly Activity Reports in Sprints

Why is Software Engineering Crucial?

So, Software Engineering is All About Pain

Agile Methods Tips

Some Big Concepts

Introduction to UML

Interpersonal Communications: Some Rules of Engagement

How to Approach Dr. J with Concerns

Teams

Use Case Diagrams

Pithy Software Engineering Quote of the Day

Revision Control Systems

A Brief History of Revision Control

Handwaving at SVN

Major SVN Commands

Git

Scrum Roles

Creating an Initial Backlog

S&S Functional Requirements 2/5/14

HW#1 Team C: Document Source File(s) Please

Say Hello to "Scrum Master John"

A Brief Comment About Use Case Diagrams

Overview of Projects

Project Communications

Team Organization

Schedule

Backlog and Sprint Planning

Analysis - What Else Besides Use Cases

Identifying Entities

Boundary Objects

Control Objects

Sequence Diagrams

Class Diagrams

Associations

Inheritance: the Un-Association

Aggregation: the Simplest Association

Grading Update

Backlog Update

GitHub Update

Association Details

A Tale of Two LaTeX Errors

...and the HW2 Winner is... Team A

User-defined Association Examples

Class Diagrams Examples -- closer to home

A "Good" Class Diagram...

More Class Diagram Examples

Five minutes each team A/B/C

WAR comments

Git Comments

Reflections on the SSRS

Software Project Estimation