Design Books

Just a note: I have updated the class syllabus with supplementary design books. These include Design Patterns, Effective & More Effective C++, Effective Java, and Modern C++ Design. These are books that I have personally found helpful. Any other suggestions are welcome, drop a comment.

Some Fall 06 Projects...

Evoart

Trans.latio.us

Assignment 1: Concept Paragraph

Your first assignment is a concept paragraph, or executive summary, of a software project that you might like to do for this class. Your concept should be no more than one page typed, but it need not be a single paragraph. You should avoid going too deep into technical details. Focus on the key aspects of the project; who will use it, why is it needed, how does it work, how much effort is required to finish it. This paragraph will become an abstract for a full project proposal in the coming weeks.

Kevin DeVries of Vertical Power has an excellent project involving embedded system programming that is available for this class. Below is an example concept paragraph provided by him.

Vertical Power is developing a power management system for small experimental aircraft. One of the subsystems, the Large Switch Panel, is used by the pilot to control the power settings of the different avionics and electrical components of the aircraft. A small 16x1 character display is used to provide feedback and allow setup of the management system.

The project scope includes the User Interface Specification and development of the specification on actual hardware. The interface must be usable and intuitive, despite the limited resources of the panel (a dozen switches and a push-button). Although the primary focus is application-level software, the students will become familiar with the Atmel family of micro-processors and the issues that surround real-time software.

The students will be rquired to implement all stages of software development, including requirements, design, development, and test. Any student involved with the project will have the opportunity to test the system during ground and flight tests.

Welcome to Software Engineering

It's spring! This is the CS 460 blog. Check here frequently for news, updates, and assignments. Notice that each post has the option to leave a comment. Please do. Other students will often have the same questions that you do. Comments are a great way to get things answered, either by the instructor or fellow students.

Final Presentations Dec 12

The final class meeting is Dec 12 10am-12pm. Each group will present their project. Presentations should be 15-20 min in length, and well rehearsed. Your presentations should:

• Desribe what the project is.
  
• Demonstrate the application.
  
• Discuss the level of completion.
  
• Discuss the group's working process, what worked and didn't work.
  

Best of the web roundup

The site "Software Development in the Real World" has a nice roundup of websites that emphasize good design and organization.

Object Oriented Programming in C

There are several in the class that have "C" as their native language. How then can they map all of our discussions of object oriented programming to this "arcane" procedural, portable assembly. The answer may surprise you, "Object oriented programming is a state of mind." It's away of solving problems, not a language paradigm necessarily. Laurent Deniau illuminates Object Oriented Programming in C. Here is a lengthy, detailed manual for doing OOP in C by Axel-Tobias Schriener. Yet another useful resource .

Code Style and Conventions

Code Style and Conventions should appear in your SDD. The central aims in devising a coding style for your projects is predictability and readability:

• Predictability Can members of your group identify semantic features of the code at a glance. You should avoid bad variable names (a, f(), etc), instead use nouns for variables and verbs for functions (m_date, up_vector, computeLocalTime()). Use names to indicate member variables "m_date". If you are using set/get style for member variables, use those names "setTime(), getTime()"; make sure you have symmetry in your names too.
  
  
• Readability Can you read the code and tell what it does. The pinnacle of readable code is Literate Programming, which intertwines documentation and source. You can move toward this without a special programming environment by enforcing good names, liberal use of space, and frequent English comments to lead the eye through the code.
  

Since many of you are using a web interface, be sure to have conventions for your HTML and style sheets, even if they are automatically generated.

Standard Java conventions.

Details on Naming Conventions.

An example style guide for Mozilla code practice. Note, this style assumes "C" code. Here is a more java friendly style guide called "Turbine".

An example of a code style enforcer for visual studio.

System Design Document (SDD)

The system design document will be a very important component of your system. Yet more writing! This document is designed for internal use, for your team. It plays an important role in system documentation and maintenance. A successful SDD will capture the design philosophy and system at a high level, as well as detailed object level descriptions. This document should reflect your requirements document, i.e. reference reqs by number, and identify how the requirements were captured by the system. Brad Appleton has a nice template for SDDs. One might consider using Doxygen to generate at least some of the SDD directly from the code comments.

Requirements Recap

Karl Wiegers has a nice article about Writing Quality Requirements. This article covers strategies for validating your requirements. Please pay attention to the section Reviewing Requirements for Quality.

Because the quality of any product depends on the quality of the raw materials fed into it, poor requirements cannot lead to excellent software.