The choices made during program design should be recorded in a design document.

Factors influencing the decisions are the requirements of the system, the technology available for building the system, knowledge of software design principles and "best practice" and experience o prior designs.

Parts of a systems are:

1. components - reusable, replaceable parts that have a clear role a can can be isolated.
2. modules - a programming level component; files in C or C++, classes or packages in Java.
3. System - an entity having a set of defined responsibilities or objectives and consisting of hardware or software or both.
4. Subsystem - a part of a larger systems that has a distinct interface; the package in Java.

Design can be top-down or bottom-up and both are often used together in the same system. Making high-level decisions first leads to top-down design. Making decision about low-level utilities and general-purpose components first leads to bottom-up design.

Aspects of design include:

• architecture - the gross division of software into subsystems and components
• class design - including associations, attributes, interactions and states
• user interface design - how the users will interact with the system
• database design - how data is stored persistently
• algorithm design - how computations are carried out
• protocol design - how subsystems and components interact over communications links

Principles of design are:

1. Divide and conquer - at all levels and in all ways; work in parallel, break large parts in pieces, use modular technology like packages and classes.
2. Increase cohesion - keep parts organized in a related way, usually with a hierarchy
3. Reduce coupling - direct manipulation of data (use accessors), global variables (use parameters or encapsulation), flags (use polymorphism), concrete classes (use interfaces), excessive calls (use encapulsation of code), imported packages (only import wht you need), OS, library or hardware dependence (use interfaces)
4. Keep abstraction high
5. Increase resuability - make designs as general as possible, use hooks to allow added functionality, simplify
6. Reuse exisiting designs and code
7. Design for flexibility - no hard-coding (file names, limits, sizes)
8. Anticipate obsolescence - avoid early releases, specific libraries, undocumented features, unreliable resources, non-standard languages or technologies
9. Design for portability - write once, run anywhere
10. Design for testability - program in small steps and test each change
11. Design defensively - avoid overkill and excessive complexity

Developing a good architectural model enables better understanding in the team, allows parallel work effort, prepares for extensibilty and facilities resuse and resuability.

The architecture can have different views, each expressible using UML diagrams:

• The logical breakdown into subystems - the package diagram
• The run-time behavior of the system - use activity, sequence and state diagrams
• The data to be distributed and shared - use class diagrams
• The run-time structure - use the deployment diagram

Typical architectural patterns are:

• multi-layer - each layer communicates with layers below it using specific interfaces (API) or protocols
• client-server or peer-to-peer (distributed) - handling of connections, and requests for service acroos those connections; usually network-based
• the broker - the proxy design pattern
• transaction processing - processing commands to change stored data, often in servers
• pipe and filter - process a stream of data with a series of processes each of which makes a transformation to its input
• model-view-controller (MVC) - separates the functional components (the model) from the user interface (the view); the controller handles the attachmment of a view to a model.

Contents of a design document:

1. Purpose - link to requirements document
2. Priorities - gneral principles used in the design
3. Outline - UML diagrams
4. Design issues - decisions made and issues resolved
5. Details - APIs or protocols to be used, major data structues or algorithms

DON'T:

• state the obvious (e.g. Java has access control in classes)
• write code or comments for code (put them in the code itself)
• write details that can be automatically extracted (e.g. javadoc)