High Level Design Checklist

Lessons learned during the creation of High Level Designs

  • Include UML Class Diagram for new classes or changes to existing classes and the relevant surrounding classes. If you can't create a UML diagram, you don't understand the problem.
  • Capture the reasons behind design decisions (either from meetings or from my own head) and include them in the HLD.
  • Stick to existing intentions/conventions of the code being modified unless there is a good reason to deviate, and in that case, document the reason.
  • Use a UML Sequence Diagram to capture behavior.
  • Before starting HLD, create a check list of features from the FS. (Feb 12, 2009)
  • While reviewing, comparse HLD to FS to ensure all the functionality is covered. (Feb 12, 2009)
  • As an act of self-review, play a game of Follow the Data through the system to ensure that all required changes have been considered. If you can't figure out how data is going to get into a certain state or get to a certain place in the system, the HLD is not complete. (Feb 12, 2009)
  • During HLD review meetings, note every change that was brought up, and the reason for that change, in a printed copy of the HLD. This is good practice even when reviewing someone else's HLD, to ensure that all the necessary changes were made, or if they were not, to remind the group of the reason for the change. (Feb 13, 2009)
  • During HLD review meetings, add a check box in the left-hand margin for every note added to the print copy. (Feb 13, 2009)
  • Include thorough test cases in the HLD. This ensures that you have considered every condition, and it projects your knowledge and assumptions onto the developer implementing the task, further ensuring they will produce code that resolves the issue. (June 10, 2009)
  • Define all the inputs and outputs of all calls. For example, the format of XML to and from the back-end should be spelled out clearly. (July 28, 2009)
  • When defining the inputs and outputs of all calls, define them in terms of technical entities, not non-technical abstractions. For example, "pass a list of people to the GUI" is an abstraction, "pass a list of tuples containing PersonPeriodID and EmployeeNumber" is specific. (July 31, 2009)

All designs should obey the following software principles:

  • SOLID (see http://www.oodesign.com/design-principles.html and http://www.lostechies.com/blogs/chad_myers/archive/2008/03/07/pablo-s-topic-of-the-month-march-solid-principles.aspx)
    • SRP: Single Responsibility Principle
      • THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.
    • OCP: Open Closed Principle
      • SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION BUT CLOSED FOR MODIFICATION.
    • LSP: Liskov Substitution Principle
      • FUNCTIONS THAT USE … REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.
    • ISP: Interface Segregation Principle
      • CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE
    • DIP: Dependency Inversion Principle
      • A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS
      • B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS
  • DRY
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License