sysand add mbse4u/sysmod
SecondaryUseCase, SystemProcess, and ContinuousUseCase (each specializing SystemUseCase, with secondaryUseCases, systemProcesses, and continuousUseCases usages) and the matching keywords #secondaryUseCase, #systemProcess, and #continuousUseCase.System → system, User → user, ExternalSystem → externalSystem, EnvironmentalEffect → environmentalEffect. Replace #System, #User, #ExternalSystem, and #EnvironmentalEffect with the lower-case forms in existing models.#systemUseCase keyword (SystemUseCaseMetadata) now applies to use case definitions only, no longer to use case usages.CustomerRequest added. Specification: added the DeliveryProcess system process, the BookDelivery use case, the MonitorDroneHealth continuous use case (with droneSTM state flying), and the createDeliveryOrder action; ChargeDrone is now a secondary use case, chargeInFlight is typed by ChargeDrone, and payloadMass is typed by ISQ::mass. Functional architecture: deliveryManagement performs createDeliveryOrder.payloadMass :> ISQ::mass.Project::subProjects is no longer a derived feature computed from all Project-typed suboccurrences. It is now a plain occurrence subProjects : Project [*], and a sub-project is added by explicitly subsetting it (occurrence myComponentProject : MyComponentProject :> subProjects). This makes membership in the sub-project list an explicit modeling decision and is consistent with the subProjectsAI prompts, which already required sub-projects to subset subProjects. Models that relied on the automatic derivation must add :> subProjects to their sub-project usages.controlStationProject in DeliveryDroneSystemProject.sysml now explicitly subsets subProjects, and its doc comment and the README no longer describe the list as derived.subProjects feature.tolerance attribute (default 0.0) to the MaxValue, MinValue, RangeValue, MinAvailability, and MinReliability boilerplates in SYSMODRequirementsBoilerplates. It relaxes the bound(s) of the require constraint (currentValue <= maxValue + tolerance, currentValue >= minValue - tolerance, minValue - tolerance <= currentValue <= maxValue + tolerance, uptime / totalTime >= minAvailability - tolerance, meanTimeBetweenFailures >= minMTBF - tolerance), so specializations that do not set it get the unrelaxed bound(s). For MinReliability the tolerance is a duration (default 0.0 [SI::s]). Previously MaxValue declared a tolerance that its constraint ignored. ExactValue is unchanged; use ToleranceValue for a target value with a tolerance band.MaxValue and MinValue boilerplates from strict to inclusive bounds (<= / >= instead of < / >), consistent with RangeValue, MinAvailability, and MinReliability and with the usual reading of "up to" / "at least" in requirement texts. A value exactly equal to the bound now satisfies the requirement.MaxPayloadMass now sets a tolerance of 0.1 kg on its 5 kg MaxValue limit.tolerance attributes and constraints.subject droneSystem declares perform action uc<Name> ::> <name>; for every DeliveryDroneSystem action it orchestrates, and the successions, bindings, flows, and local flight legs reference these performed actions (droneSystem.ucPlanDelivery) instead of the system's actions directly. Updated the example model (specification) accordingly for BookDelivery, DeliverPackage, ChargeDrone, ReportFleetStatus, HandleEmergencyLanding, and MonitorDroneHealth; DeliverPackage now continues from ucPlanDelivery to the flyToPickup leg, and ChargeDrone no longer includes detectLowBattery.perform action pattern in DeliverPackage.LevelKind literal medium to middle (value 0.5 unchanged). Replace LevelKind::medium with LevelKind::middle in existing models.LevelKind::medium is now LevelKind::middle.middle literal.name attribute (ScalarValues::String) to ExtendedStakeholder to hold the name of the stakeholder.name (johnFinch, tomSchilling, logisticCompany, droneOperator, recipient, regulator).ReliableDelivery, SafeOperation, and LowDeliveryCost now declare the brownfield system as subject and their stakeholder (LogisticCompany or DroneOperator); the concern usages in the project bind them to the project's stakeholders.SYSMODProcesses package with SYSMODDefaultProcess, the default SYSMOD workflow, and one action definition per step: SetupProject, SpecifyBrownfieldSystem, SpecifyProblemStatement, IdentifyStakeholders, ElaborateStakeholderNeeds, PitchSystemIdea, DefineSystemSpecification (with the nested steps specifySpecificationArchitecture, identifyUseCases, and elaborateSystemRequirements), CreateSolutionArchitectures, and VerifyAndValidateRequirements. Successions define the default order (all steps after setupProject are optional), flows connect the step outputs to the project features, and bindings connect the step inputs to the project features created by earlier steps. The item definition ArchitectureDescription represents informal architecture descriptions given as input by a human or an AI assistant.ISO15288Processes package with an action definition and a doc comment for each of the 30 ISO/IEC/IEEE 15288 system life cycle processes (agreement, organizational project-enabling, technical management, and technical processes). #refinement dependencies in SYSMODProcesses map each SYSMOD step to the ISO 15288 process(es) it refines, e.g., DefineSystemSpecification refines SystemRequirementsDefinition.defaultProcess (the SYSMODDefaultProcess performed by the project; redefine it with a specialization to tailor the process), purpose (a brief description of the project's purpose), and verificationCases (verification cases with the product system as subject) to Project.defaultProcessAI (sysmod-default-process) to AIProject in SYSMOD4AI. It walks the user step by step through SYSMODDefaultProcess, delegates each step to the AI metadata of the artifacts it produces, and its validation prompt reports the status of every step and the next step to perform.SYSMOD4AI prompts to model subjects, stakeholders, and actors as explicit, bound parameters:
stakeholderNeedsAI: each need definition declares the brownfield system as its first parameter (subject) and a typed stakeholder parameter per stakeholder; the need usages bind the subject to brownfieldContextImpl.soiImpl and the stakeholder parameters to the project's stakeholder part usages. The validation prompt checks the subject binding and that every need has a bound stakeholder parameter.specificationContextAI: each use case definition declares the specification system as subject and a typed actor parameter per participating actor; the use case usages bind them to the context's soi and actor part usages. The validation prompt checks the actor parameter bindings.systemRequirementSpecificationAI: each requirement declares the specification system as subject and a typed stakeholder parameter for the stakeholders of the framed need; the root requirement binds the subjects of its nested requirements. The validation prompt requires a frame relationship to a stakeholder need and at least one stakeholder parameter.systemIdeaContextAI: removed the validation check for a satisfy relationship from the system idea to the problem statement.MaxValue, MinValue, RangeValue, ExactValue, and ToleranceValue boilerplates (currentValue, maxValue, minValue, targetValue, tolerance) are now untyped instead of ScalarValues::Real, so they accept plain numbers as well as quantity values with units. A specialization narrows all value attributes of a boilerplate to the same type, e.g., attribute :>> maxValue :> ISQ::mass = 5 [SI::kg];. MinAvailability keeps Real for its unitless ratio.tolerance attribute of all SYSMODRequirementsBoilerplates now has the multiplicity [0..1]. ToleranceValue::tolerance is therefore optional too and defaults to 0.0 like the others; MinReliability::tolerance (a duration) defaults to 0 [SI::s]. A specialization with units must set the tolerance with the same unit, since the default 0.0 is a plain number.MaxPayloadMass narrows currentValue, maxValue, and tolerance to ISQ::mass and sets maxValue = 5 [SI::kg] and tolerance = 0.1 [SI::kg] with units.Project::specificationContext::soi and Project::specificationContextImpl::soiImpl instead of the system idea features.ExtendedStakeholder attribute priority (risk × effort) to attention. It measures how much attention a stakeholder needs and is no longer confused with the priority attribute of ExtendedConcern, which is unchanged. Replace references to a stakeholder's priority with attention in existing models.attention attribute.MaxValue library snippet and MaxPayloadMass model snippet, the AI layers of steps 4 and 6–9, and the "Full SYSMOD Library" appendix (boilerplates and AI prompts).name attribute of ExtendedStakeholder and the stakeholder names of the example model.AI metadata definition and AIProject out of SYSMOD.sysml into a new top-level package, SYSMOD4AI (file SYSMOD4AI.sysml), which privately imports SYSMOD. Import it in addition to SYSMOD only where AI-assisted workflows are wanted — the core methodology library no longer carries any AI-specific content.SYSMODRequirementsBoilerplates (file SYSMODRequirementsBoilerPlates.sysml): it is now a top-level library package alongside SYSMOD and SYSMOD4AI (previously nested inside SYSMOD), and the name's spelling is corrected. Update any qualified references from SYSMOD::RequirementBoilderplates to SYSMODRequirementsBoilerplates.SYSMOD, SYSMOD4AI, and SYSMODRequirementsBoilerplates as the three separate packages they now are, instead of one monolithic package.AI metadata definition and per-step AI prompts to match the library: all seven AI attributes are now shown (including perform_prompt, story_prompt, slide_prompt), the sysmod-stakeholder-priority-map skill is now documented, and the deck's own copies of the v5.1.2 MinValue/MinAvailability fixes and the boilerplates renaming — which had not been carried over from the library into the documentation — are now consistent with it.sysmod-solution-context / "solution architecture" leftovers from its text, matching the library's actual functional/logical/product structure.doc comment with explicit "When to use" / "When not to use" sections to all 14 AI metadata usages in SYSMOD4AI.sysml (projectAI, projectOwnerAI, brownfieldContextAI, problemStatementAI, projectStakeholdersAI, stakeholderPriorityMapAI, stakeholderNeedsAI, systemIdeaContextAI, specificationContextAI, systemRequirementSpecificationAI, functionalContextAI, logicalContextAI, productContextAI, subProjectsAI), written in the style of an AI-assistant skill's trigger/skip conditions and cross-referencing the adjacent skill to use instead where scopes could overlap. This paves the way for generating Claude Skills (or equivalent skill definitions for other LLM platforms) directly from these elements.AI metadata definition's own doc and in the "About the AI Skill Layer" intro slide.functionalContextAI validation prompt in SYSMOD4AI.sysml.packagePort (one inout parcel item) with payloadPort carrying separate pkgIn/pkgOut items, added a customer actor with a customerInterface to payloadPort, added an energyPort for the electrical energy supply, and documented all ports of DeliveryDroneSystem.Energy item definition.DeliveryDroneSystem and documented, including their items; use cases reference them via droneSystem.<action> instead of defining local copies. Renamed batteryLow to acceptBatteryLow (with an explicit accepted lowBattSignal), replaced flyToHomeStation by a flyToHome leg of flyToPosition targeting the new homePosition item, let detectLowBattery send its signal via a port, and added an energy input to DeliverPackage and chargeInFlight.deliveryManagement, flightControl, packageManagement, batteryManagement, droneManagement, and fleetManagement, which perform the specification actions, are bound to the inherited system ports, and are connected via typed ports from a new Interfaces package (PositionInterface, PositionPort, EnergyPort, DeliveryPort, PayloadPort, ...). Corrected the remaining "solution" wording in its doc comments to "specification".payloadPort, energyPort, customer, port docs), Specification (step 7), Use Cases (step 8: current SystemUseCase :> ConstrainedOccurrence library snippet with startShot/endShot, and the reworked DeliverPackage), Functional Architecture (step 10), the maxPayloadMass name in steps 9 and 11, the remaining "solution" wording in the appendix's functional/logical/product context docs, and an invalid trailing comma in the appendix's projectAI create_questions.SYSMOD4AI and SYSMODRequirementsBoilerplates to the Sysand package index (.meta.json), so both new library files are included in the published package, and added the version line to the SYSMOD4AI header.minValue > currentValue) so it required the opposite of a lower bound; it now correctly requires currentValue > minValue.