Documentation Roadmap and Overview - SENG-350-2024-fall/Team-11 GitHub Wiki

Purpose and Scope of the SAD

This SAD specifies the software architecture for the Mister ED Virtual Triage System. All information regarding the software architecture may be found in this document, although much information is incorporated by reference to other documents.

The document details the software architecture, which is comprised of the system's core components, their externally visible properties, and the interactions among them. "Externally visible properties" refers to aspects like performance, availability, and reliability, which are observable by other components or users and influence the system's behavior. Non-architectural details, internal implementations that don't impact component interactions, are documented separately.

The software architecture emphasizes how system elements relate to each other. This architecture is presented through different views, such as Allocation view, or Admin view.

Architecture views help to clarify specific perspective, such as Admin vs Chemist (Pharmacist). Together, these views form a comprehensive architecture blueprint. The Mister ED system architecture prioritizes availability and modularity, allowing for continuous user access and adaptability in the healthcare context. This ensures that the system meets critical healthcare needs by facilitating effective triage and recommendation processes.

How the SAD Is Organized

This SAD is organized into the following seven sections:

  • This Documentation Roadmap and Overview provides information about this document and its intended audience. It provides the roadmap and document overview. Every reader who wishes to find information relevant to the software architecture described in this document should begin by reading this section, which describes how the document is organized, and where information may be found.
  • Architecture Background provides information about the software architecture. It describes the background and rationale for the software architecture. It explains the constraints and influences that led to the current architecture, and it describes the major architectural approaches that have been utilized in the architecture.
  • Views and Mapping Between Views specify the software architecture.
  • Referenced Materials and Glossary and Acronyms provide reference information. Referenced Materials provides look-up information for documents that are cited elsewhere in this SAD. Glossary and Acronyms is an index of architectural elements and relations giving their definition, and where each is used in this SAD.

How a View Is Documented

Views are documented with the following template:

1. Primary Presentation

  • Is usually graphical
  • Should include a key that explains the notation
  • Shows elements and relations among them
  • Shows the information you want to convey about the view first
  • Should identify elements that are external to scope of the view
    • If external entities are not clearly marked in the diagram, consider adding a context diagram

2. Element Catalog

  • Explains elements depicted in primary presentation and their properties
  • Is usually a table with element name and textual description
  • May contain interface documentation
  • May contain behavior documentation

3. Variability Guide

  • Points where system can be parameterized or reconfigured. Examples:
    • Number of instances in a pool
    • Support for plug-ins or add-ons
    • Support for different versions of OS, database server or runtime environment
  • Maybe the view is a reference architecture
    • Provide guidelines to instantiate it

4. Other Information

  • Description and rationale for important design decisions (including relevant rejected alternatives)
  • Results of analysis, prototypes and experiments
  • Context diagram

5. Parent View

  • If the current view is the refinement of another view, indicate which one