(12140) B.4.1.2 Package Diagram: <<access>> should be <<import>>

SysML1.0:

'B.4.1.2 Package Diagram - Showing Package Structure of the Model

..

The relationship between the views (OperationalView and PerformanceView) and the rest of the user model are explicitly expressed using the «access» relationship.'

In fact Figure B.3 shows <<import>> relationships.

(12141) B.4.4.3 Requirement Diagram: 'refineReqt' should just be 'refine'

SysML1.0, p.188:

'B.4.4.3 Requirement Diagram - Acceleration Requirement Relationships
Figure B.13 focuses on the Acceleration requirement, and relates it to other requirements and model elements. The “refineReqt” relation, introduced in Figure B.12, ..'

Should read '"refine" relation'.

(12142) B.4.5.4 Block Definition Diagram: Should say 'white diamond (shared AggregationKind)' not 'white diamond (composition)'

SysML1.0:

'B.4.5.4 Block Definition Diagram - Power Subsystem
..
Note how the of white diamond (composition) on FrontWheel and BrakePedal denotes the same “use-not-composition” kind of relationship previously shown in Figure B.16.'

The choice of the word 'composition' in combination with the white diamond is unfortunate, as it implies 'composite' AggregationKind.

Rewrite to say 'white diamond (shared AggregationKind)' rather than 'white diamond (composition)':

'Note how the of white diamond (shared AggregationKind) on FrontWheel and BrakePedal denotes the same “use-not-composition” kind of relationship previously shown in Figure B.16.'

(12143) B.4.8.3 Activity Diagram (EFFBD): refers incorrectly to objectFlows in BDD Figure B.34

SysML1.0:

'B.4.8.3 Activity Diagram (EFFBD) - Acceleration (detail)

Figure B.35 shows the ProvidePower activity, using the decomposed activities and objectFlows from Figure B.34'

In fact Figure B.34 is a BDD, so it can't show 'objectFlows'. It shows the Blocks that type the ObjectFlows.

(12146) Figure B.9: clarify turnIgnitionToStart message on driver:Driver

Is it supposed to be a message to self ? If so please include message to self path, otherwise explain,

http://www.omg.org/issues/sysml-rtf.html#12146 

(12160) Figure B.29: 'delta-t' shown with solid-line (AggregationKind 'composite'), not dashed line (AggregationKind 'none')

Compare with Figure B.26 which shows 'delta-t:GlobalTime' as reference with AggregationKind 'none'.

B.4.8.3 Activity Diagram (EFFBD): refers to allocations to parts instead of blocks

SysML1.0:

'B.4.8.3 Activity Diagram (EFFBD) - Acceleration (detail)
Figure B.35 shows the ProvidePower activity, using the decomposed activities and objectFlows from Figure B.34. It also uses AllocateActivityPartitions and an allocation callout to explicitly allocate activities and an object flow to parts in the PowerSubsystem block.'

In fact the AllocateActivityPartitions in Figure B.35 represent blocks, not part Properties typed by blocks.

Figure B.10: justify 'StartVehicle' from outside in terms of UML

TODO

Figure B.27: <<view>> Package "steals ownership" of MOEs, Actor, UseCase and Requirement

In Figure B.27 - Establishing a Performance View of the User Model

It is not at all clear how the MOEs, Actor, UseCase and requirement should be shown as directly within the view without the view package "stealing ownership".

Appears to break constraint:

'7.3.2.4 View

[1] A view can only own element import, package import, comment, and constraint elements.'

Note that this relates to::

Issue 11500: <<view>> as Package
extension is very bad idea (sysml-rtf), No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus@magicdraw.com nerijus@nomagic.com)

   <<view>> as Package extension is very bad idea. Package is used for ownership, so it is not possible to show the same elements in different packages (as different point of view)  

Figure B.34 and Figure B.35: ownership of objectFlow 'elecDrivePower:ElecPower' inconsistent

FigureB34 shows an Activity decomposition with:

• an <<activity>> ControlElectricPower owning part Property 'elecDrivePower:ElecPower'.
• an <<activity>> ProvideElectricPower without any owned part Properties.

FigureB35 shows:

• an Action 'a3:ControlElectricPower' with outgoing ObjectFlow to ObjectNode '<<continuous>> driveCurrent'
• an Action 'a4:ProvideElectricPower' with outgoing ObjectFlow to ObjectNode '<<continuous>> elecDrivPower'

The translation of ObjectFlows in FigureB35 to part Properties in the Activity decomposition FigureB34 is thus inconsistent.

Figure B.35: prefer <<continuous>> pins over contrived placement of ObjectNodes on border of swimlanes

Placement of ObjectNodes on boundaries of swimlanes is contrived and graphically unstable.

Prefer typed output/input Pin pairs on CallBehaviorActions corresponding to Parameters. 

TODO: alternative diagram with pins for resolution.

Figure B.36 emg:ElectricalMotorGenerator should be allocated from a4:ProvideElectricPower not ConvertElectricToPower

Figure B.36 shows 'emg:ElectricalMotorGenerator' allocated from <<activity>> ConvertElectricToPower

Figure B.35 shows Action 'a4:ProvideElectricPower' allocated to '<<block>> ElectricalMotorGenerator'.

The table in Figure B.37 shows 'a4:ProvideElectricPower' (incorrectly typed as an Activity) allocated to '<<block>> ElectricalMotorGenerator'.

For consistency  Figure B.36 should show 'emg:ElectricalMotorGenerator' allocated from Action 'a4:ProvideElectricPower'.

Figure B.36: ecu:PowerControlUnit should be allocated from ProportionPower, not ProportionPowerLoad

Figure B36 shows 'ecu:PowerControlUnit' allocated from '<<activity>> ProportionPowerLoad'.

Figure B.35 shows Action 'a1:ProportionPower ' allocated to '<<block>> PowerControlUnit'.

Figure B.37 table shows 'a1:ProportionPower ' allocated to part Property 'ecu:PowerControlUnit'.

For consistency
Figure B.36 should show Action 'a1:ProportionPower ' allocated to '<<block>> PowerControlUnit'.

Figure B.36: ice:InternalCombustionEngine should be allocated from ProvideGasPower, not ConvertGasToPower

Figure B36 shows 'ice:InternalCombustionEngine' allocated from '<<activity>> ConvertGasToPower'.

Figure B35 shows Action 'a2:ProvideGasPower' allocated to '<<block>> InternalCombustionEngine'.

The table in Figure B37 shows Action 'a2:ProvideGasPower' (incorrectly typed as an Activity) allocated to '<<block>> InternalCombustionEngine'.

For consistency Figure B36 should show 'ice:InternalCombustionEngine' allocated from Action 'a2:ProvideGasPower'.

Figure B.36: shows allocations to part Properties, not to Blocks as in Figure B.35

Figure B.35 shows allocations of actions to swimlanes representing blocks.

Figure B.36 shows allocations of activities to part properties.

Figure B.35 should probably shows allocations of actions to part properties.

Figure B.36 should probably show the same allocations of actions to part properties.

Figure B.37: the elements allocated from are of type Action, not Activity

In table Figure B.37 allocations are made from the following Actions (activity usages):

a1:ProportionPower
a2:ProvideGasPower
a3:ControlElectricPower
a4:ProvideElectricPower

The 1st column shows them incorrectly as of type Activity.

 NB: this issue relates to and/or duplicates

Issue 11497: Mixed action and activity
concepts (sysml-rtf)

	Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus@magicdraw.com nerijus@nomagic.com)
	Nature: Uncategorized Issue
	Severity: 
	Summary: Mixed action and activity concepts. B.35, B.36, B.37 - concepts of activity and action are mixed (action is allocated, but activity is in tabular notation)
	

Figure B.38: property names of p:[PowerSubsystem] inconsistent w.r.t. other figures

Figure B.38 gives p:[PowerSubsystem] with parts:

em: [ElectricMotor]
t: [Transmission]
ice: [InternalCombustionEngine]

Figure 9.3 shows PowerSubsystem with parts:

trsm: Transmission
ice: InternalCombustionEngine
(ecu:PowerControlUnit)
(epc: ElectricalPowerController)

Figure 9.6 IBD shows PowerSubsystem with parts:

trsm: Transmission
ice: InternalCombustionEngine
(ecu:PowerControlUnit)
(epc: ElectricalPowerController)

Figure 15.10 IBD shows PowerSubsystem with parts:

trsm: Transmission
ice: InternalCombustionEngine
emg:ElectricalMotorGenerator
(ecu:PowerControlUnit)
(epc: ElectricalPowerController)
(can:CAN_Bus)

Figure B.18 BDD shows PowerSubsystem with parts:

trsm: Transmission
ice: InternalCombustionEngine
em: ElectricalMotorGenerator
pcu:PowerControlUnit
(epc: ElectricalPowerController)
..

For consistency Figure B.38 should show p:[PowerSubsystem] with parts:

emg: [ElectricMotor] (not 'em')
trsm: [Transmission] (not 't')
ice: [InternalCombustionEngine]

Also, Figure B.18 should show PowerSubsystem with part:

ecu:PowerControlUnit

Figure B.9: explain how 'turnIgnitionToStart' message from outside system corresponds with UML

TODO

The composing owner of FrontWheel is never made clear

It is clear from Figure B.18 - Defining Structure of Power Subsystem (Block Definition Diagram) and Figure B.19 - Internal Structure of the Power Subsystem (Internal Block Diagram) that ChassisSubsystem.FrontWheel is shared by PowerSubsystem, and that FrontWheel is a specialisation of WheelHubAssembly.. However nowhere is it made clear which block is the composing owner of FrontWheel (although we may guess that it is ChassisSubsystem).

The polymorphic substitution of FrontWheel for WheelHubAssembly is never explained. 

TODO Figure B.31, Figure 10.1: parameters 'x' and 'dt' (a.k.a. 'delta-t') missing in StraightLineVehicleDynamics

In Figure B.31 - Defining Straight-Line Vehicle Dynamics Mathematical Constraints.

Compare with parameters 'x' and 'dt' on boundary of Figure B.30 - Straight Line Vehicle Dynamics Mathematical Model (Parametric Diagram)
and on dyn:StraightLineVehicleDynamics in Figure B.29 - Establishing Mathematical Relationships for Fuel Economy Calculations.

TODO: 'ft:FuelTankAssy' -> 'ft:FuelTankAssembly': Figure 9.5, 9.4.1.1, B.4.5.5, Figure B.19, B.4.5.6, Figure B.25

Inconsistent w.r.t. Figure B.18, Figure B.23 'ft:FuelTankAssembly'. 

TODO: Fig B.26: referenced value property GlobalTime contradicts assertion that a value property has AggregationKind 'composite'

In Figure B.26 - Defining Analyses for Hybrid SUV Engineering Development (Analysis Context).

GlobalTime is referenced as property 'delta-t' by EconomyContext and «testCase,Interaction» MaxAcceleration. If GlobalTime is a value property this appears to contradict the assertion of:

Issue 12127: 8.3.1.2 Internal Block Diagram: .. value properties must be owned with AggregationKind 'composite' This would be consistent with the following from 8.3.1.2 Internal Block Diagram, Property types: ".. A part or value property is always shown on an internal block diagram with a solid-outline box.

TODO: Figure B.23: Can a block have flow properties and a FlowPort typed by a FlowSpecification with the same flow properties ?

From SysML1.0: 9.3.2.4 FlowProperty: 

'Flow properties are defined directly on blocks or flow specifications that are those specifications which type the flow ports.'

This does not explicitly allow both at once. Further:

'Flow properties enable item flows across connectors connecting parts of the corresponding block types, either directly (in case of the property is defined on the block) or via flowPorts.'

This again seems exclusive. The possiblity of a block having a flow property defined directly on it and then also connected to a FlowPort typed by a compatible FlowSpecification seems to be incompatible with the following:

'For Block, Data Type and Value Type properties, setting an “out” FlowProperty value of a block usage on one end of a connector will result in assigning the same value of an “in” FlowProperty of a block usage at the other end of the connector, provided the flow properties are matched.'

If an "out" FlowProperty is connected to an external element indirectly - via an outgoing delegation Connector to a FlowPort with a compatible FlowSpecification - then that FlowSpecification would have to also have a matching "out" FlowProperty, not an "in" FlowProperty.

In any case, the combination of FlowProperty defined on a Block combined with a FlowPort typed by a compatible FlowSpecification that is implied by Figure B.23 - Elaborating Definition of Fuel Flow. (Block Definition Diagram) is inconsistent with the connections made in Figure B.25 - Detailed Internal Structure of Fuel Delivery Subsystem (Internal Block Diagram).

TODO: Figure B.23: The sense of direction seems the wrong way round in the Block flow properties and FlowSpecification

Compare the sense of Fuel flow direction in:

• Figure B.19 - Internal Structure of the Power Subsystem (Alternative 1 - Combined Motor Generator)

• Figure B.25 - Detailed Internal Structure of Fuel Delivery Subsystem (Fuel Distribution Detail)

The flow of Fuel "supply" is from ft:FuelTankAssembly to the ice:InternalCombustionEngine, and the sense of Fuel "return" is from the engine to the tank. However in the original SysML1.0 sample Figure B.23 - Elaborating Definition of Fuel Flow. (Block Definition Diagram) the FlowProperty fuelSupply:Fuel is 'in' on ft:FuelTankAssembly and 'out' on ice:InternalCombustionEngine. Also, flow properties of the FlowSpecificationFuelFlow (if not conjugated at the engine) would then have to be fuelSupply:Fuel 'out' & fuelReturn:Fuel 'in'.

TODO: Figure B.25: Why are the flowports typed by FuelFlow <<FlowSpecification>> never used ?

In Figure B.23 - Elaborating Definition of Fuel Flow (Power Subsystem Fuel Flow Definition) ice:InternalCombustionEngine has a non-conjugated FlowPort of type FuelFlow <<FlowSpecification>>, and ft:FuelTankAssembly has a conjugated FlowPort of type FuelFlow <<FlowSpecification>>, however in Figure B.25 - Detailed Internal Structure of Fuel Delivery Subsystem (Fuel Distribution Detail) only ice:InternalCombustionEngine has an 'inout' FlowPort of type Fuel , and ft:FuelTankAssembly has two separate atomic flowports p1:Fuel 'out' and p2:Fuel 'in' for the supply and return lines respectively.

Why are the flow ports with flow specifications introduced then never used (except in a parametric diagram Figure B.24) ?

TODO: Figure B.26: GlobalTime not clearly defined

In Figure B.26 - Defining Analyses for Hybrid SUV Engineering Development (Analysis Context).

GlobalTime is referenced as property 'delta-t' by EconomyContext and «testCase,Interaction» MaxAcceleration. The spec sample diagram does not state whether this is a Block or a ValueType, however it can be inferred from the BindingConnector to parameter dt:Time in Figure B.29 that 'delta-t' must be compatible with «ValueType» Time.

GlobalTime is also not defined in the value types of Figure B.2.

TODO: Figure B.28: parameter 'vc' of constraint property ':CapacityEquation' inconsistent w.r.t. CapacityEquation in Figure B.26

In Figure B.26 - Defining Analyses for Hybrid SUV Engineering Development (Analysis Context)  CapacityEquation has three parameters: 'v1:Vol', 'v2:Vol', 'v3:Vol'.

In Figure B.28 - Defining Measures of Effectiveness and Key Relationships (HSUV MOEs) there is a contraint property :CapacityEquation with a single parameter 'vc'.

TODO: Figure B.33: appears to use Dependencies (dashed) instead of control flows

TODO

TODO: Figure B.33: suggest use in/out Pin pairs instead of <<continuous>> accelPosition ObjectNode

TODO: Figure B.34 - Decomposition of “Accelerate” Function: should show Accelerate <<activity>>

It should show the Accelerate <<activity>> decomposed into children MeasureVehicleConditions and ProvidePower before decomposing the children.

TODO: Figure B.38: has part typed by '[Interior]' rather than '[InteriorSubsystem]'

In Figure B.38 - Special Case of Internal Block Diagram Showing Reference to Specific Properties (serial numbers).

Inconsistent w.r.t. Figure B.16, B.17.