Reasoning About Architecture in Software Development
Software architecture, documentation, and decision-making play crucial roles in the success of a project. Understanding the purposes and customers of documentation, as well as the impact of decisions on architecture evolution, is key to progress.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Documenting Architecture HOW DO WE REASON ABOUT ARCHITECTURE?
Documentation? It s the second week of the semester and we re talking about documentation? Isn t that something that we do at the end and barely pay attention to?
George George Santayana Santayana Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement; and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it. The Life of Reason
What is Software Architecture The software architecture of a system is the set of structures needed to reason about the system. These structures comprise software elements, relations among them and the properties of both.
Purposes of Documentation Education: New members of the team, potential clients or funders Communicating among stakeholders: Decisions made and why, how we got to where we are A basis for system analysis and construction: How the system is constructed, how we addressed different quality attributes (requirements) A basis for forensics: A problem has occurred, how do we determine where and why? What are the implications of various potential fixes?
Customers of Documentation Project Managers Schedule / Plan Resources Required Budget / Spending to budget Alternatives Development Team Testers and Integrators Designers of Other Systems Maintainers End Users Analysts Infrastructure Support Personnel Future Architects
Decisions Architectures are defined and evolve because of decisions that are made Documentation then is Why they were made? What tradeoffs were made? Who did what? What assumptions do we make? When were they made? All of this is crucial to progress
Model A model is a description from which detail has been removed in a systematic manner and for a particular purpose A simplification of reality intended to promote understanding Models are the most important engineering tool, they allow us to understand and analyze large and complex problems https://www.cl.cam.ac.uk/teaching/1112/SWDesign/softwaredesign01.pdf
Architectural Blueprints Software architecture deals with the design and implementation of the high-level structure of the software It is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy the major functionality and performance of the system, as well as some other, non-functional requirements such as: Performance Scalability Portability Availability Etc Software Architecture = {Elements, Forms, Rationale/Constraints} Elements are processing, data and connecting elements Forms are properties (constrain choices) and relationships (constrain placement) Rationale, the motivation for choices To describe a software architecture, we use a model composed of multiple views or perspectives.
Views Module Views Decomposition Layer Uses Class Data Model Component & Connector Views Service Structure Concurrency Structure Allocation Views Deployment Structure Implementation Structure Work Assignment Quality Views Security View Communication View Exception Handling Reliability Performance
Behaviors Use Cases Sequence Diagrams Communication Diagrams Activity Diagrams
Other Important Things System Context Diagram Patterns Terminology Rationale
