Project Design
Project Design
The project involves a file system,
contained within an ordinary Linux file. The goal is to gain experience with
operating system structures related to files: create and delete; open and close;
read, write, and reposition; and get file attributes, set file attributes.
Imagine that your file system will have 2 users, who don't like to trust each
other all the time.
Importance of prerequisites:
- if you emphasize quality at the end of a project, you focus on system testing
- if you emphasize quality in the middle of a project, you focus on construction
practices
- if you emphasize quality at the beginning of a project, you focus on prerequisites
- planning = risk management
- costs of error recovery (p.29,"Code Complete")
|
Requirements |
Architecture |
Construction |
System Test |
Post-Release |
Requirements |
1 |
3 |
10 |
10 |
100 |
Architecture |
- |
1 |
10 |
15 |
100 |
Construction |
- |
- |
1 |
10 |
25 |
- costs may be less with an iterative approach than sequential
- different projects require different approaches
- "requirements are like water. They're easier to build on when they are
frozen" - Anon
After requirements comes architecture
- also known as system-level architecture, top-level design, and high-level
design
- quality of architecture determines the conceptual integrity of system
(ease of completing all three parts).
- good architecture makes construction easy
- mistakes become more expensive as we progress through the stages
- how is our system going to meet the requirements? what are users
going to do?
- Raskin's laws of interface design:
- the computer shall cause no harm, either directly or
indirectly through inaction
- the user shall do no more work than is absolutely necessary
- system functionality determines what is possible, the interface
determines how users will access those possibilities
- effective, comprehensible, satisfying activities
- usability vs. utility, form vs. function
- mental models, metaphors
Typical architectural components
- program organization:
- an overview that describes the system in broad terms, so that
the big picture can be seen
- provide evidence that alternatives to the final organization
were considered, along with the reasoning for the final organization.
For maintenance, design rationale is at least as important as
the design itself
- define the major building blocks (classes or subsystems) and
their responsibilities. Every feature listed in the requirements
should be covered by at least one building block (and if it is
more than one, the coverage should be complementary). Building
blocks should know as little as possible about other building
blocks
- define the communication rules for each building block (which
blocks can communicate directly or indirectly [or not at all])
- major classes:
- design rationale
- 80/20: specify the 20% of classes that do 80% of the work.
- data design:
- describe the major files and tables used
- user interface design:
- specify major elements of web pages, GUIs, CLI, etc.
- architecture should be modularized to allow refinement of interface
(and to allow testing). Interface changes likely mean architecture
changes.
- resource management:
- describe management of DB connections, threads, memory, etc.
- estimate resource usage in typical and extreme cases
- scalability:
- Input/Output:
- how it will be accomplished
- how and where I/O errors are detected
- Error processing:
- corrective or detective?
- active or passive?
- error propogation?
- handling error message?
- exception handling?
- Fault tolerance
- Architectural feasibility
- Change Strategy
Design in Construction
- Design Challenges:
- design is a "wicked" problem
- design is a sloppy process (even if it produces a clean result)
- design is about tradeoffs and priorities
- design involves restrictions
- design is nondeterministic
- design is a heuristic process
- design is EMERGENT
- Key Design Concepts:
- Manage complexity!
- essential and accidental difficulties
- main technical reason for project failure
- keep code in manageable chunks that programmers can think about
- don't proliferate accidental complexity (see Raskin's 2nd Law)
- Desirable characteristics
- minimal complexity: simple over "clever", support
focus on individual pieces of code
- ease of maintenance: think of the maintenance programmer as
your audience
- loose coupling: minimize the number of connections between
parts of your system
- extensibility: allow for change
- reusability
- high fan-in: good use of utility classes
- low-to-medium fan-out: use few other classes
- portability
- leanness
- stratification: design system to view it at one level without
dipping in to other levels (build firewalls)
- standard techniques
- Design Building Blocks: Heuristics
- find real-world objects (metaphors)
- identify the objects and attributes
- determine what can be done to each object
- determine what each object is allowed to do to other objects
- determine the parts of each object that will be visible to
other objects
- define each object's interfaces
- form consistent abstractions
- encapsulate implementation details
- inherit - when inheritance simplifies design
- hide secrets
- so your brain doesn't have to deal with extra complexity
- so effects of changes are localized
- identify areas likely to change (and isolate them)
- business rules
- hardware dependencies
- input and output
- nonstandard language features
- difficult design and construction areas
- status variables
- data-size constraints
- (also applies to core + additional functionality)
- keep coupling loose
- Design Practices
- iterate
- divide and conquer
- top-down and bottom-up approaches
- experimental prototyping
- collaborative design
- how much is enough?
- capturing your design work: insert design documentation into the
code