![]() Architecture decision records (discussed below).Use case documentation includes a list of actors, pre-conditions, post-conditions, assumptions, steps, variations, related qualities and constraints, and related use cases. Use cases, which contain a written description of how the system will be used.Pattern documentation includes a description, context, problem statement, solution, consequences, known use cases, variants, and diagrams. ![]() Design Patterns, which contain architecture or code patterns used on the project.Principle documentation includes a description, the rationale, the implications for the project, the counterforces pushing back against the principle, counterarguments to the principle, and the scope at which the principle applies. Principles underlying the design and implementation strategy for the system.Quality documentation includes a description, context, scenarios, test cases, metrics (if applicable), tradeoff notes, and related qualities. Qualities, which document the architecture or design qualities that we are designing our system around.We also document the source of the constraint, metrics for the constraint (if applicable), and ways to check the constraint (if applicable). Like component specifications, constraint documentation includes a rational. Constraints, which document hard constraints that our system must meet.Component specifications (often called “CRC-R cards”), which describe the responsibilities, requirements, collaborators, and rationale behind a given component.We tend to separate our A&D documentation into the following categories: For this section, we’re going to share the documentation included in one of our more complex projects, since it provides a comprehensive overview. The architecture and design (A&D) documentation included in a project depends on the complexity of that project and the amount of design effort we applied to it. We’ll also share other ways we document our software projects. Given that both questions center around diagrams, we’ll focus our answer on that topic. What do you consider to be a valid architecture diagram? What are some that you have discovered you prefer over others? ![]() The author admonishes developers to create and record a software architecture for their project before they start coding, and then says “Beware: activity diagrams, flowcharts, and sequence diagrams describe operation, not architecture.” In “Better Embedded Systems Software”, Phillip Koopman says that “an architecture is some figure that had boxes and arrows representing components and connections” and provides examples like “call graph, class diagram, data flow diagram, hardware allocation diagram, control hierarchy diagram” as well as a few exceptions to the rule (“message dictionary, real time schedule, memory map”). The second question arose during a discussion on Timeless Laws of Software Development, by Jerry Fitzpatrick: What type of documentation do you create for your code? Do you use UML? Subset of UML? Something else? Can you provide samples? We received a pair of questions that prompted this Q&A article.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |