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

Abierto
#363 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, markdown, rust, yaml

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Rust
Estrellas
8
Forks
1
Merge medio
3 h 35 min
PR fusionados (30 d)
69

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sjames/syscribe

Todos los issues de sjames/syscribe

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.