Software architecture and detailed design (SWE.2/SWE.3): bind operations to behaviour and code, richer sequence and structure views, budgets, architecture rules

Aperta
#363 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript, markdown, rust, yaml

Direzione di ricerca

Start with the child issues #364–#373 and related issues #329, #334, #343, and #344 to see how this broad architecture and design gap analysis is being split into work. Read the referenced source areas and docs/format/operations.md; the body says source references are in the child issues. Done means the proposed capabilities have been scoped and tracked through those issues; this parent issue does not define an implementation task.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Source

A review of syscribe against the needs of software architecture and detailed design (ASPICE SWE.2 and SWE.3), written from an Android Auto prototype. Each claim was re-checked against the current source (0.53.x); the first two items described things that partly exist already. Source references are in the child issues.

What already exists

  • PartDef, PortDef, InterfaceDef, ItemDef, ActionDef, StateDef; operations: on PortDef/InterfaceDef/ConnectionDef/PartDef (typed parameters with direction, multiplicity and unit; returnType; isQuery; isAsync), see docs/format/operations.md.
  • performs: and exhibitsStates: on parts; derived BDD, IBD, Action, State and Sequence diagrams (alt for IfAction, loop for LoopAction); the Allocation diagram (logical and physical swimlanes).
  • implementedBy: on Part/PartDef/Interface/InterfaceDef with W023 for a missing local path; annotated-source ingestion; wcet: and quantities: with budgets checked (W893); stdio plugins (foreignFormat:); build-config, export-sysml, import-reqif.

Gap analysis

# Item Verdict Child issue
1 Typed operations exists; missing errors, call-site checks, link to behaviour and code A
2 Behaviour binding performs/exhibitsStates exist; operation is not realised by an ActionDef; a PartDef sequence subject is W418 A, B
3 Richer sequence fragments alt/loop only; no return, create, destroy B
4 Class and data diagrams derived BDD exists; no association/multiplicity notation, no struct/typedef with ranges C
5 Component diagram ports have isConjugated/conjugates; no provided/required rendering D
6 Deployment view allocation diagram only; no process/thread/partition/container levels G
7 Timing and resources wcet, quantities exist; no period, priority, memory budgets or roll-up E
8 Architecture rules not there F
9 Detailed design and unit level no unit-level kind (design question) H
10 Code links implementedBy exists; no path#symbol, no drift check A
11 Import stdio plugins are the intended route I
12 Generation no stubs/ARXML; plugin route J

Suggested order

  1. A (operations, behaviour and code binding) with B (sequence from operations, fragments): this turns the contract into a checkable design.
  2. C, D: cheap derived views over data already in the model.
  3. E, F: validate checks. The grid-tie dogfood model states a 70 % CPU / 80 % memory margin (REQ-GTI-SYS-072) and "the hardware trip shares nothing with the firmware" only as prose.
  4. G, H, then I, J as plugins over the structured model export.

Related: #329 (behaviour/architecture link, typed interfaces #331), #334 (diagram generation), #343 and #344 (quantification and requirement-level coverage).

Part of #272 (executable MBSE / software design).

Tracking

  • A: #364
  • B: #365
  • C: #366
  • D: #367
  • E: #368
  • F: #369
  • G: #370
  • H: #371
  • I: #372
  • J: #373

Generated by Claude Code

Lingua principale
Rust
Stelle
8
Fork
1
Merge medio
3h 35m
PR unite (30g)
69

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sjames/syscribe

Tutte le issue di sjames/syscribe

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.