1 About Application Frameworks

The easiest way to think about application frameworks is in the context of an example. To that end, imagine that you had to implement an office suite consisting of a word processing application, a spreadsheet application, and a presentation application. The different applications have some functionality in common (e.g., the ability to create a new file, open a file, save a file, quit, etc.) and some unique functionality (e.g., the ability to perform a mail merge in the word processing application, the ability perform calculation on a column of numbers in the spreadsheet application, the ability to animate bullet points in the presentation application). The role of the application framework is to provide the functionality that is common across all of the applications.

2 The Software Process

We will be using a traditional/heavyweight (as opposed to agile) software development process during this part of the course. I have already completed the planning, product design, and engineering design actions/tasks. Your job will be to implement the design that I have created.

I will also serve as the project manager. In that role, I have scheduled all of the programming assignments. You must adhere to the schedule that I have created.

Each programming assignment constitutes a single milestone and will have specific deliverables. Since we will not be using an incremental process, we will not have a working product at the end of each programming assignment. That is, we will not have a working product until all of the programming assignments have been completed. However, you will be able to (and required to) run unit tests and integration tests for each set of deliverables. To facilitate integration testing, I have designed, and you will implement, a demonstration application called "The Big Pixel".

We will be using a parallel development process. That is, each of you will implement the same product. However, unlike in a traditional parallel development process (in which the developers work independently), you will periodically share information with the other developers (for pedagogical reasons).

3 Learning Objectives

Remember that this course is about design, not implementation. So, the primary purpose of the programming assignments is to get you to think critically about the design that has been given to you. As a side benefit, you will probably become a better programmer, but that is not the purpose of the programming assignments. After you complete each programming assignment, we will have an in-class discussion of the design (not the implementation).

It is important that you think critically about the design of the application framework during the first half of the course because, during the second half of the course, you will be responsible for designing (and implementing) a product. In other words, during the first half of the course you need to become a better designer so that you can create a good design during the second half of the course.

4 Document Formats

We will be using several different document formats this semester.

• The academic aspects of the programming assignments (e.g., submission requirements, due dates, etc.) will be in HTML files.
• The products themselves will be described/specified in two different kinds of files. Textual descriptions/specifications will be in PDF files. UML diagrams will be in SVG files so that you can "zoom in" without loss of detail (since some of them are quite large).

5 The Specific Application Framework

The specific application framework that you will be implementing contains only the basic functionality that must be included in GUI-based, desktop applications. Specifically, it includes the ability to: open documents, close documents, create new documents, save documents (including both "save" and "save as"), print documents, and quit the application. This includes functionality that enables/disables these operations based on the current state of the system. For example, the "save" functionality is disabled until there is something to save (i.e., until a change has been made).

The framework enforces a somewhat non-traditional work flow that would probably upset interaction designers. This was done to simplify the design and implementation. The work flow that it enforces is discussed in the following PDF document:

An abstract UML class diagram for the framework is available in the following SVG file:

6 The Demonstration Application

The demonstration application called "The Big Pixel" can be used to draw rectangles of different sizes and colors. In and of itself it is of no value. However it will have enough functionality to allow you to run integration tests.

An abstract UML class diagram for the demonstration application is available in the following SVG file:

7 Best Practices

Though this is a design course, we will use "best practices" when it comes to implementation. Two are particularly important to mention at this point.