"A list of elements of the environment that may affect or be affected by the System and Project. Includes external systems to be interfaced with." HORBA page 40-41.

Components Tab

• Name: string
• Description: string
• Interface description

Add eslint to the project

Add unit testing to the project. Use the native Node test runner

Classification of behaviors, interfaces, and scenarios by degree of criticality

• ipns://docs.ipfs.tech/
• ipns://docs.ipfs.tech/concepts/dnslink/#publish-content-path
• https://github.com/marketplace/actions/upload-to-ipfs
• https://medium.com/cladular/running-an-interplanetary-file-system-node-using-azure-container-instances-5627814a48f5
• https://learn.microsoft.com/en-us/answers/questions/381556/integrate-azure-blockchain-workbench-with-ipfs

Implement Goals -> Use Cases section

HORABK. Page 40

Comparable:

• https://www.visual-paradigm.com/tutorials/glossary.jsp

• https://sqlite.org/wasm/doc/trunk/index.md
• Is there a comparable Entity Framework solution for TypeScript?

syncing data may become more complicated with a SQL database though. How can CRDTs be utilized?

Implement the Goals Functionality overview.

This includes high level behaviors only

Context, Situation, Mission/Objective, Expected Benefits

In deeper paths it's not possible to go up a level without using browser history:

Introduce Solution concept and move PEGS under it:

• My Solution
  • Project
  • Environment
  • Goals
  • System

HORABK p. 110

create a separate tab.

Also replace the enumerated stakeholder categories with High/Low pickers

Currently routing requires a standalone table initialized in Application._initRouter():

this.#router = new Router([
    ['/', (await import('./pages/Home.mjs')).Home],
    ['/not-found', (await import('./pages/NotFound.mjs')).NotFound],
    ['/projects', (await import('./pages/projects/Projects.mjs')).Projects],
    ['/environments', (await import('./pages/environments/Environments.mjs')).Environments],
    ['/environments/new-entry', (await import('./pages/environments/NewEnvironment.mjs')).NewEnvironment],
    ['/environments/:slug', (await import('./pages/environments/Environment.mjs')).Environment],
    ['/environments/:slug/glossary', (await import('./pages/environments/Glossary.mjs')).Glossary],
    ['/goals', (await import('./pages/goals/Goals.mjs')).Goals],
    ['/goals/new-entry', (await import('./pages/goals/NewGoals.mjs')).NewGoals],
    ['/goals/:slug', (await import('./pages/goals/Goal.mjs')).Goal],
    ['/goals/:slug/rationale', (await import('./pages/goals/Rationale.mjs')).Rationale],
    ['/goals/:slug/functionality', (await import('./pages/goals/Functionality.mjs')).Functionality],
    ['/goals/:slug/stakeholders', (await import('./pages/goals/Stakeholders.mjs')).Stakeholders],
    ['/goals/:slug/use-cases', (await import('./pages/goals/UseCases.mjs')).UseCases],
    ['/goals/:slug/limitations', (await import('./pages/goals/Limitations.mjs')).Limitations],
]);
this.#router.addEventListener('route', this);

Navigating to a page is accomplished via self.navigation.navigate(pathname)

A problem is that if a route changes, there is no error or warning of usage sites needing to change (Stringly typed)

Additionally, the parameters of the routes currently have to be parsed by subtypes of Page such as in SlugPage:

class SlugPage extends Page {
    // /parent/:slug/foo
    #slug = new URL(location.href, document.location.origin).pathname.split('/')[2];

    constructor(properties: Properties<SlugPage>, children: (string | Element)[]) {
        super(properties, children);

        // ...
    }

    get slug() {
        return this.#slug;
    }
}

Routing should be integrated into the Page class and initiating a route should accomplished via a method call on the page object itself instead of via self.navigate. Additionally, route parameters should be automatically available.

Convert the application to a PWA

For some reason the .required::after class is not being applied. Is this due to some bug with the shadow DOM or is it a bug with the CSSOM insertRule method?

The user interfaces and APIs for each Component

The overall structure of the system expressed by a list of major parts (Components)

• https://developer.chrome.com/docs/css-ui/declarative-shadow-dom
• https://webkit.org/blog/13851/declarative-shadow-dom/

Currently all the mappers have the following form:

export interface FooJson extends BaseJson {
    ...props
}

export default class FooToJsonMapper extends BaseToJsonMapper {
    override mapFrom(target: FooJson): Foo {
        const version = target.serializationVersion ?? '{undefined}';

        if (version.startsWith('0.3.'))
            return new Foo(target);
        //... additional versions

        throw new Error(`Unsupported serialization version: ${version}`);
    }

    override mapTo(source: Foo): FooJson {
        return {
            ...super.mapTo(source),
            // ..additionalProps
        };
    }
}

Most repositories are of the form:

export default class FooRepository extends BaseRepository<Foo> {
    constructor() { super('foo', new FooToJsonMapper(pkg.version)); }
}

There is also a LocalStorageRepository specialized for the storage type:

export class LocalStorageRepository<E extends Entity> extends Repository<E> {
    constructor(readonly storageKey: string, mapper: Mapper<E, EntityJson>) {
        super(mapper);
    }

    get storage(): Storage {
        return localStorage;
    }

    get(id: E['id']): Promise<E | undefined> { ... }

    getAll(filter: (entity: E) => boolean = _ => true): Promise<E[]> { ... }

    add(item: E): Promise<void> { ... }

    clear(): Promise<void> { ... }

    update(item: E): Promise<void> { ... }

    delete(id: E['id']): Promise<void> { ... }
}

Note the storage member which was defined to support unit testing:

const fakeStorage: Storage = new DomStorage(null, { strict: true });

class TestLocalStorageRepository<F extends Foo> extends LocalStorageRepository<F> {
    override get storage() {
        return fakeStorage;
    }
}

This smells and has significant duplication. This needs to be done better

An Assumption is a property of an environment that may be assumed. They are not imposed by the environment. Example: Client Screen resolutions will be larger than 1024x768

Rendering is still a bit awkward. The Template Method pattern approach causes problems with private field access which leads to verbose workarounds in certain cases

Describes the behaviors (functional and non-functional) of Components. What the system does

UML models exist:

Is this a 1 to many relationship between components and the diagrams?

Remove license headers from files.

With a LICENSE file in place this is sufficient. the header becomes redundant and introduces a maintenance burden for the year.

Currently the DataTable enforces uniqueness constraint on entries.

The Domain should probably enforce this instead. Research a way to accomplish this.

The application is deployed to https://final-hill.com/cathedral/. It lists everything as a 404 as it assumes it will be deployed to root.

"Obligations and limits imposed on the project and system by the environment" HORABA page 40-41

"[A]n environment property that may affect components, goals, behaviors, tasks or products" The Anatomy of Software Requirements

• statement
• category: Business Rule | Physical Law | Engineering Decision

One approach, to avoid redundancy, would be to reify code comments into the class for the running application to access

Interactions between the environment, Actors, and the system

Use Cases
User Stories

Need to reference Goals -> Use Cases

Implement storage versioning to support schema evolution.

This is dependent on determining the ultimate storage strategy.

If it remains JSON one approach is to utilize the package version and have the data layer do the mapping based on the versions

As an SPA, when an update is deployed clients have a good chance of not being updated due to long running sessions.

Clean Architecture needs to be followed more closely by leveraging use cases. Currently none are defined

The framework has become more trouble than it's worth.

• Implicit Globals
• Build sizes too large
• Can't practically avoid server components
• nuxi generate creates a non-functional build
• plugins poorly maintained
• requires custom plugins in the IDE to develop (and it won't type check properly)
• The router is buggy and requires sibling dummy pages to get subpaths to work properly
• etc.

• https://www.ontopia.net/topicmaps/materials/tao.html
• https://en.wikipedia.org/wiki/Topic_map
• https://en.wikipedia.org/wiki/Mind_map

Currently borked and not deploying

Build and deploy to github pages for now

The SPA does not support direct navigation or reloads in deep links. Enable the Service Worker to support this use case

https://chromestatus.com/feature/5176596826161152

The project currently utilizes the Navigation API to intercept navigation events and handle them

As of 2023-11-01, the Navigation API is still experimental and supported
by only Chromium-based browsers (~73% coverage as of January 2024)

https://developer.mozilla.org/en-US/docs/Web/API/Navigation_API
https://developer.chrome.com/docs/web-platform/navigation-api/
https://caniuse.com/mdn-api_navigation

Types are polyfilled via dom-navigation package

Once the feature is fully adopted by major browsers, remove the polyfill

For consistency, the MiniCards and PEGSCards should have a hover effect like the other navigable elements

State what the System will NOT do.

An Effect is an environment property affected by a System.

Deeper navigation does not highlight the tab:

Update the DataTable to prevent duplicate field entries

Currently the stakeholders are all plotted at the origin of each quadrant.

The Stakeholder model needs to updated to include availability and influence fields.