Derived-property census of GetElementProperties against the Pilot

Abierto
  • ¿Algo no está bien?
#2,028 3 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
backend, testing

Línea de trabajo

Start with test-opensysml-go/census_test.go and data/gen_census.py, then read the linked census snapshot and the rules.go property rules to understand how the measurements map to served properties. The issue suggests adding a measured column using the embedded examples; done means the census can report how often served rules return values. The issue gives no specific test command for that addition.

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

Descripción

enhancement spec compliance

Following up on #2012 and #2021: once GetElementProperties made every metamodel property readable by name, we could count, across whole models, which derived properties come back with values. We added a census to our test suite that does this for each MDK in the same way, with the Pilot as the reference column.

How it works

  • The property list is every feature marked derived="true" in the Pilot's SysML.ecore (328 properties), per concrete metaclass.
  • Two corpora: our matrix models (23 files) and the Pilot's examples and training models (195 files, loaded together as one model).
  • For each element, as written, the census reads every derived property its metaclass carries and records a value, an empty answer, or "not derived".
  • OpenSysML is read in process through the Go client, at 071880026e.

Snapshot: census-SNAPSHOT.md. Design and notes: DISCUSSIONS.md, Step 13. It can be rerun with ./run-census.sh from test-suite/.

Summary (properties with values on at least one element / answered but always empty / not derived):

corpus Pilot sysml-toolkit OpenSysML
matrix models 194 / 71 / 0 194 / 69 / 2 142 / 86 / 33
Pilot examples 300 / 22 / 0 297 / 22 / 3 180 / 82 / 54

The "not derived" group largely matches what rules.go declares as omitted, and the service's explanations for those are clear. The census suggests another group may be the most useful one to look at: properties that are listed as served but come back empty on every element where the Pilot has values. On the Pilot examples there are 66 of them. Some of the most frequent:

property Pilot has values OpenSysML
Feature::ownedTypeFeaturing 18,843 of 20,294 empty on all 13,953
InstantiationExpression::instantiatedType 1,456 of 1,456 empty on all 1,107
Type::endFeature 782 of 21,346 empty on all 14,751
Connector::association 605 of 605 empty on all 447
Import::importedElement 408 of 408 empty on all 325
Behavior::step 220 of 220 empty on all 169
Function::result 127 of 127 empty on all 90
Flow::sourceOutputFeature / targetInputFeature 85 of 127 empty on all 106
ConjugatedPortDefinition::originalPortDefinition 79 of 79 empty on all 39
SendActionUsage::payloadArgument 34 of 35 empty on all 23

The same holds for the <kind>Definition of several usage kinds (enumeration, flow, interface, case, use case, view, rendering, allocation...) and for the filtered owned/nested usage lists of Definition and Usage (ownedFlow, nestedTransition, ownedRequirement, ...). The full list is in the snapshot under "Differences from the reference".

A second group fills at a much lower rate than the Pilot, e.g. Step::behavior 5% vs 100%, Expression::function 8% vs 100%, Usage::isReference 3% vs 100%, Connector::sourceFeature 32% vs 94%. Part of this group probably reflects implied relationships: the Pilot includes them after transformation, while GetElementProperties answers with isImpliedIncluded = false (e.g. Feature::type, Type::ownedSpecialization, Type::inheritedFeature). So these numbers are a pointer rather than a verdict. Usage::isReference and the connector ends are the cases we already described in #2012.

A possible use on your side: rules.go already records, per property, the rule that serves it. A measured column next to it, filled the way this census fills it (how often a served rule returns a value over the embedded examples), would show these cases as the rules are written. You're welcome to take the census or any part of it (data/gen_census.py, test-opensysml-go/census_test.go). The Go adapter is about 230 lines and uses only the public client.

Not derived on the Pilot examples (54)

ActionDefinition::action, AllocationDefinition::allocation, AnalysisCaseDefinition::resultExpression, AnalysisCaseUsage::resultExpression, AnnotatingElement::owningAnnotatingRelationship, AssertConstraintUsage::assertedConstraint, AssignmentActionUsage::referent, AssignmentActionUsage::targetArgument, AssignmentActionUsage::valueExpression, Association::associationEnd, Association::relatedType, Association::sourceType, Association::targetType, BooleanExpression::predicate, CalculationDefinition::calculation, ConnectionDefinition::connectionEnd, Documentation::documentedElement, EnumerationDefinition::enumeratedValue, EventOccurrenceUsage::eventOccurrence, ExhibitStateUsage::exhibitedState, Expression::isModelLevelEvaluable, FlowDefinition::flowEnd, ForLoopActionUsage::loopVariable, ForLoopActionUsage::seqArgument, Function::isModelLevelEvaluable, IfActionUsage::elseAction, IfActionUsage::ifArgument, IfActionUsage::thenAction, IncludeUseCaseUsage::useCaseIncluded, InterfaceDefinition::interfaceEnd, LoopActionUsage::bodyAction, MetadataFeature::metaclass, Package::filterCondition, PerformActionUsage::performedAction, RenderingDefinition::rendering, SatisfyRequirementUsage::satisfiedRequirement, SatisfyRequirementUsage::satisfyingFeature, TerminateActionUsage::terminatedOccurrenceArgument, TextualRepresentation::representedElement, UseCaseUsage::includedUseCase, VerificationCaseDefinition::verifiedRequirement, VerificationCaseUsage::verifiedRequirement, ViewDefinition::satisfiedViewpoint, ViewDefinition::view, ViewDefinition::viewCondition, ViewDefinition::viewRendering, ViewUsage::exposedElement, ViewUsage::satisfiedViewpoint, ViewUsage::viewCondition, ViewUsage::viewRendering, ViewpointDefinition::viewpointStakeholder, ViewpointUsage::viewpointStakeholder, WhileLoopActionUsage::untilArgument, WhileLoopActionUsage::whileArgument

Lenguaje dominante
Go
Estrellas
56
Forks
17
Merge medio
12 h 45 min
PR fusionados (30 d)
910

Preparar el entorno

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 Open-MBEE/OpenSysML

Todos los issues de Open-MBEE/OpenSysML

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.