UVicDSA18
  • Introduction
  • Keras
    • 1. Introduction
    • 2. Documentation Overview
    • 3. Stakeholders
    • 4. Business Goals
    • 5. Architecturally Significant Requirements
    • 6. Module View
      • Main Diagram
      • Element Catalogue
      • Context Diagram
      • Behaviour Diagrams
      • Module Organization Rationale
    • 7.Component and Connector View
      • Main Presentation
      • Element Catalog
        • Elements
        • Relations
        • Interfaces
      • Context Diagram
      • Behavior Diagrams
        • Building a Sequential Model
        • Training a Model
      • Variability Guide
      • Rationale
    • 8. Code Quality and Technical Debt
      • Code Quality Report
        • Introduction
        • Code Quality Issues
      • Potential Technical Debt
        • Introduction
        • Length and Complexity Issues
        • Backend Conditional Code Paths
      • Conclusion
    • 9. Conclusion
    • 10. References
  • Tensorboard
    • List of Figures
    • 1.0 Introduction
    • 2.0 Identifying Stakeholders and Business Goals
      • 2.1 Stakeholders
      • 2.2 Business Goals
    • 3.0 Architecturally Significant Requirements and Utility Tree
      • 3.1 List of Architecturally Significant Requirements
      • 3.2 Prioritized List of Scenarios
      • 3.3 Quality Attribute Scenario Templates
      • 3.4 Utility Tree
    • 4.0 Module View
      • 4.1 Primary Presentation
      • 4.2 Element Catalog
      • 4.3 Context Diagram
      • 4.4 Sequence Diagram
      • 4.5 Rationale
    • 5.0 Component and Connector View
      • 5.1 Primary Presentation
      • 5.2 Element Catalog
        • 5.2.1 Elements and Properties
        • 5.2.2 Relations and Properties
        • 5.2.3 Elements Interfaces
          • Loading Events from a Directory File
          • Processing and Prepare to Load Events into Plugins
        • 5.2.4 Element Behaviour
      • 5.3 Context Diagram
      • 5.4 Variability Guide
      • 5.5 Rationale
    • 6.0 Technical Debt
      • 6.1 SonarQube Analysis
        • 6.1.1 Function Names
        • 6.1.2 Methods and Field Name Capitalization
        • 6.1.3 Cognitive Complexity of the Code
        • 6.1.4 Merging Collapsible “if” Statements
        • 6.1.5 Reducing Code Duplications
      • 6.2 CodeScene Analysis
        • 6.2.1 Hotspots
        • 6.2.2 Refactoring Targets
        • 6.2.3 Code Age
        • 6.2.4 Internal Temporal Coupling
      • 6.3 Technical Debt Recommendations
        • 6.3.1 Duplications and Refactoring
        • 6.3.2 Function Recommendation
        • 6.3.3 Stability
        • 6.3.4 Absence of a Dataset Module
        • 6.3.5 Compatibility of Multiple Browsers
        • 6.3.6 “TODO” Search and Analysis
        • 6.3.7 Other Recommendations
      • 6.4 Technical Debt Summary and Conclusions
    • 7.0 Pull Request
      • 7.1 Problem Description
      • 7.2 Solution
    • 8.0 Conclusions
    • 9.0 References
  • Toyplot
  • Strapi
    • Purpose
    • About Strapi System
    • Stakeholders
    • Business Goals
    • Architecturally Significant Requirements (ASR)
    • Utility Tree
    • Quality Attribute Scenarios (QAS)
    • Module View
      • Primary Presentation
      • Element Catalog
        • Elements and Properties
        • Relations and Properties
        • Element Behaviour
      • Context Diagram
      • Rationale
    • Component and Connector View
      • Primary Presentation
      • Element Catalog
        • Elements and Properties
        • Relations and Properties
        • Element Behaviour
      • Context Diagram
      • Variability Guide
      • Rationale
    • Code Quality and Technical Debt
    • Conclusion
  • Cartographer
    • 1.0 Introduction
    • 2.0 Stakeholder Analysis
    • 3.0 Architecturally Significant Requirements
    • 4.0 Module View
    • 5.0 Component and Connector View
    • 6.0 Code Quality Review
    • 7.0 Conclusion
    • 8.0 References
  • RocketChat
    • Abstract
    • 1. Introduction
      • 1.1 Project overview
      • 1.2 About RocketChat
      • 1.3 Our Project Team
    • 2. Stakeholders and Business Goals
      • 2.1 Stakeholders
      • 2.2 Business Goals
    • 3. Architecturally Significant Requirements
      • 3.1 ASR
      • 3.2 Utility Tree
      • 3.3 Quality Attribute Scenario
    • 4. Module View
      • 4.1 Primary Presentation
      • 4.2 Element Catalog
      • 4.3 Context Diagram
      • 4.4 Behaviour Diagram
      • 4.5 Rationale
    • 5. Component and Connector View
      • 5.1 Primary Presentation
      • 5.2 Element Catalog
      • 5.3 Behaviour Diagram
      • 5.4 Interface Documentation
      • 5.5 Rationale
    • 6. Code Quality and Technical Debt
      • 6.1 Code Quality Analysis Tools
        • 6.1.1 SonarQube
        • 6.1.2 CodeScene
    • 7. Conclusion
    • References
  • SwaggerUI
  • Homebrew
    • 1. Introduction
      • 1.1 Project Overview
      • 1.2 Our Project Team
      • 1.3 Our Supervisors
    • 2. Identifying Project Stakeholders and Business Goals
      • 2.1 Stakeholders
      • 2.2 Business Goals
    • 3. Architecturally Significant Requirements and Utility Tree
      • 3.1 Architecturally Significant Requirements
      • 3.2 Utility Tree
      • 3.3 Quality Attribute Scenarios
    • 4. Module View
      • 4.1 Primary Presentation
      • 4.2 Element Catalog
      • 4.3 Context Diagram
      • 4.4 Behaviour Diagram
      • 4.5 Rationale
    • 5. Component and Connector View
      • 5.1 Primary Presentation
      • 5.2 Element Catalog
      • 5.3 Interface Documentation
        • 5.3.1 Interface
        • 5.3.2 Interface
      • 5.4 Context Diagram
      • 5.5 Variability Guide
        • 5.5.1 Adding/Removing Formulae in homebrew-core
        • 5.5.2 Managing Custom Formulae in homebrew-core
      • 5.6 Behaviour Diagram
      • 5.7 Rationale
    • 6. Code Quality and Technical Debt
      • 6.1 Code Quality Analysis Tools
        • 6.1.1 SonarQube
        • 6.1.2 CodeClimate
        • 6.1.3 CodeScene
      • 6.2 Analysis of Issues
        • 6.2.1 Primary Refactoring Targets
        • 6.2.2 Change Management
    • 7. Conclusion
    • 8. References
  • Open source contributions
Powered by GitBook
On this page
  • Views and Beyond Approach
  • Acknowledgements
  • Further Reading
  • Copyright and License

Introduction

Neil Ernst, Omar Elazhary University of Victoria, April, 2018

This is a edited book of contributions from students in an upper-level software engineering course at the University of Victoria. Modeled heavily on the pioneering DelftSWA course from van Deursen et al. (1), the course goal was to introduce students to "documenting and understanding software". We did this by picking a large, open-source software system on Github and documenting its architecture in several phases. The result is a comprehensive, if partial, description of the system from the point of view of relative newcomers.

Views and Beyond Approach

In contrast to the Delft approach, we used the Software Engineering Institute views and beyond approach for documenting software. The main focus is to trace technical decisions back to business/project goals using the lens of quality attributes. We focus on identifying the architecturally significant drivers that impact the software design. The views and beyond model suggests there are three main types of architectural structures to reason about: modules at implementation time, components and connectors at runtime, and allocation structures connecting the code to non-code artifacts.

Acknowledgements

This course would not be possible without the help of Arie, Andy and Maurício at Delft, who pioneered this approach in 2015.

Further Reading

  1. Arie van Deursen, Maurício Aniche, Joop Aué, Rogier Slag, Michael de Jong, Alex Nederlof, Eric Bouwers. A Collaborative Approach to Teach Software Architecture. 48th ACM Technical Symposium on Computer Science Education (SIGCSE), 2017.

  2. Arie van Deursen, Alex Nederlof, and Eric Bouwers. Teaching Software Architecture: with GitHub! avandeursen.com, December 2013.

  3. Amy Brown and Greg Wilson (editors). The Architecture of Open Source Applications. Volumes 1-2, 2012.

  4. Paul Clements et al. Documenting Software Architectures. Addison Wesley, 2011, ISBN-13: 978-0321552686.

Copyright and License

The copyright of the chapters is with the authors of the chapters. All chapters are licensed under the Creative Commons Attribution 4.0 International License. Reuse of the material is permitted, provided adequate attribution (such as a link to the corresponding chapter on the UVicDSA book site) is included.

NextKeras

Last updated 6 years ago

Creative Commons