Prioritizing Forces in Software Design Prioritizing Forces in Software DesignBy: A. Cockburn
Published in: PLoPD2
Pages: 317-333
General principles for software design.
Category: Architectural
Summary: General principles for software design.
Pages: 321-322
Protect system integrity from change by identifying areas of predicted variation and creating a stable interface around them.
Pages: 322-324
When the interface to the persistence infrastructure is likely to change, use persistence accessor methods. These are owned by the infrastructure, not the domain, and may be regenerated at any time.
Category: Architectural, Client-Server, Persistence
Pages: 324-325
When team membership is likely to change, separate subsystems by staff skill requirements. This allows specialists to work in their area of expertise and enables successors to see the results of these special abilities in isolation.
Category: Organization and Process
Pages: 325
You're developing workstation application software. Create three subsystems: infrastructure, user interface, and application domain. User interface experts can concentrate on human factors and user interface programming; application domain experts can concentrate on application requirements, data needs, and model object behavior; and infrastructure experts can concentrate on system structure.
Category: Architectural, GUI Development
Pages: 325-326
When a team has a high percentage of novices, create two class layers in the user interface subsystem. Use highly skilled developers for the generic classes, and novices for the specific classes. Let the generic user interface developers create frameworks, and the specific user interface developers use them.
Category: GUI Development, Organization and Process
Pages: 326-327
When a team has a high percentage of novices, create two class layers for the problems in the system. Use experts to design the generic parts, and novices to design the specific parts.
Category: Architectural, Organization and Process
Pages: 327
To protect system integrity from changing external components, define the user interface to be outside the application proper. Make all functions of the application accessible through a program-driven interface.
Pages: 328
Should input validation be performed before the application is called, or should it be performed by the application itself? Perform entry validation in two steps. Keystroke validation is performed in the user interface, and value validation is performed by the application.
Pages: 328-329
When a user can cancel a transaction after making changes but before committing, the most efficient way of editing is to keep two copies of the object, the safe copy and the editing copy.
Category: Transaction Processing
Pages: 329-330
When there are conflicting design issues for a class, assign designers in conflict to work on different layers of the class hierarchy.
Category: Organization and Process
Pages: 330-331
Validation, domain, and persistence are the three parts of any persistent domain object. When they are designed by different teams following Skill Mix, the class hierarchy for persistent domain classes consists of Model (for the common domain issues), ValidatedModel (for the validation issues), and PersistentModel (for the persistence issues). Model and ValidatedModel can be merged or broken apart, depending on the design.
Category: Architectural, Persistence, System Modelling
Pages: 331
Provide a single point of call to volatile interfaces. This protects developers from massive rework if an interface changes and provides a unified interface to a set of interfaces.
Pages: 331-332
To protect developers from massive rework due to persistence layer interface changes, the user interface should never call the persistent subsystem layer directly. Instead, it calls a domain object, whose superclass provides a single point of implementation for the service.
Category: Architectural, Persistence