What?
----------------------------------------
What is the purpose of this course? What are the goals of this
course?
(1) to consolidate your programming skills; we may push a bit
beyond your current knowledge
(2) to expose you to proven techniques of industrial and academic
software construction; implied goal: academia can consolidate
positive insights and improve industrial practice
What is a non-goal of the course?
(1) to teach purely academic ideas on the software development
process
(2) to use academic or industrial tools that you may or may not
find at your workplace
How?
----------------------------------------
How do we achieve these goals? Clearly, there are many different
ways of doing just that. I use the idea of a studio course, which
I have imported from the fine arts. You will
(1) develop a program
(2) show and tell in class and possibly in private sessions
(3) repeat
Initially, I will present some basic ideas and principles of
software design and development. This will be followed with a
discussion of some so-called software patterns in a specific
context.
Later on, I will also present specific programming knowledge for
specific tasks. For example, one of the projects will involve
wiring together two components of a project via tcp sockets.
In addition, the projects will involve some domain knowledge. The
word "domain" refers to the application domain of a program. An
accounting program requires knowledge about the art of
accounting. A scientific program requires knowledge about the
scientific domain. In this course, I will attempt to keep the
domain knowledge to a minimum so that we can focus on the
development of software. Still, we cannot possibly write
interesting software in a vacuum, and we cannot learn to develop
software well with completely boring domains. So, you must be
prepared to know something about the domain of application. In
the real world, you will probably find out far more than you ever
wanted to know.
In short, the development of software requires
(1) the use of proven techniques of software development
(2) knowledge about programming languages and computer systems
(3) knowledge about the application domain.
The course focuses on (1), with some ideas from (2) -- which you
also get in other courses, and as little as possible of (3).
Software
----------------------------------------
What's software? What do people do with it? What properties should
it have?
- it works: --> my front page
- it works correctly: it does what a (paying) customer wants it to do
- it works fast (enough): it does so in a reasonable time
- it is robust: it tolerates user errors and certain kinds of internal
errors, warning: ??
But that's not the true problem. The real problem is this:
(Social) Theorem: No interesting software system is ever finished.
Corollary: Someone is always working on this software.
This someone could be a person that takes over the code from you.
Or this someone could be a person who picks up your code long
after you have left the project. Or this someone could be you,
because your boss asked you to fix a bug or add a piece of
functionality or whatever long after you had initially worked on
it. You are a different person now; you have forgotten what you
thought about and you can't possibly remember everything.
Corollary: Develop the program so that you can read and modify it
a day later, a month later, or a year later.
--> my front page again
Development
----------------------------------------
How do people develop software? Don't ask.
How do people think other people should develop software?
The waterfall model:
(1) determine the needs and requirements for the software:
(2) translate the requirements into specifications
(3) code implementations for the specifications
(4) test the code: find mistakes
(5) debug: eliminate the mistakes
(6) deploy: insert the software into the context
where it is supposed to work
(7) maintain the code: fix bugs, add functionality
People have tried to develop according to this model, but they now
understand that this model doesn't work. What really works is an
iterative approach to this process.
(1) write up the story of the software, find the use cases end to
end interactions between the desired system and users and
other contexts
(2) pick a central/important use case and implement it to the
point where it is useful
(3) deploy and observe consumers/clients
(4) go back to (1) or (2)
Where do all the requirement statements, specification, test, and
debugging activities go?
"writing up the story of software" means writing up what the
customer tells you so that the customer understands what you
wrote and you can use your story to guide your efforts -- this is
informal communication about requirements and specifications
"extracting/writing use cases" from the stories means to break up
your story into small doable tasks
"implementing" in (2) means that not just writing some code and
hoping for the best; it means
to lay out the concepts of the story and the use case
to formulate the kind of data this involves
to illustrate the desired use case with behavioral examples
to turn the examples into tests (code)
to design and write code that passes all these tests
--> design recipes
--> note: science
How again?
----------------------------------------
How can we teach this?
--> discuss modeling techniques
--> discuss data design and documentation
--> discuss testing
--> discuss coding follows data and documentation
--> discuss safe guards (contracts)
--> discuss reuse of proven patterns of code
==> public presentations of your work, as if the people in class
had to take over your code NOW
==> public inspection of your work serves as the prime quality
control tool in class and later in the real world
Discussing without doing is useless. So, you code and practice
what you see. You maintain the code for the duration of one
semester. No that isn't real life, but it's the best you can
do. You will see that returning to a piece of code after three
weeks is difficult, and so we hope that you will appreciate these
lessons for work on real projects.
Overview of course pages; basic policies
----------------------------------------