Derived-property census of GetElementProperties against the Pilot

Aperta
  • Qualcosa non va?
#2,028 3 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend, testing

Direzione di ricerca

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.

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

Descrizione

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

Lingua principale
Go
Stelle
56
Fork
17
Merge medio
12h 45m
PR unite (30g)
910

Preparare l'ambiente

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

Tutte le issue di Open-MBEE/OpenSysML

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.