 |
|
|
||
"quantity kind" as a generalization/specialization hierarchy
*Dimension (quantity dimension, dimension of a quantity)
*Quantity (quantity) [INCUBATING]
*QuantitySystem (system of quantities)
*Unit (measurement unit, unit of measurement, unit)
base Quantity
derived Quantity
Dimensionless
kind of quantity
ordinal quantity
SI Base Quantities
SI base Units
VIM general and particular quantity examples
[quantity scale]
*DimensionedType
*FrameSpecification
*QuantityProperty
*UnitProperty
*ValueProperty
*ValueType (proposed)
NIST specific/particular quantity examples
Introduction to the Hybrid Sports Utility Sample project for MagicDraw SysML
Navigation tips: for the MD SysML sample
Profiles used in the MD SysML sampl
Figure B.2 - Defining ValueTypes and Units to be used in the sample problem
Figure B.3 - Establishing Structure of the User Model using Packages and Views (Package Diagram)
Figure B.4 - Establishing the Context of the Hybrid SUV System using a User-Defined Context Diagram
Figure B.5 - Establishing Top Level Use Cases for the Hybrid SUV
Figure B.6 - Establishing Operational Use Cases for Drive the Vehicle
Figure B.7 - Elaborating Black Box Behavior for the Drive the Vehicle Use Case
Figure B.8 - Finite State Machine Associated with Drive the Vehicle
Figure B.9 - Black Box Interaction for Start Vehicle, referencing White Box Interaction
Figure B.10 - White Box Interaction for StartVehicle.jpg)
Figure B.11 - Establishing HSUV Requirements Hierarchy (containment)
Figure B.11a HSUV Requirements: Alternative: use «containment» wrapper Components
Figure B.11b HSUV Requirements: Alternative: stereotype UML Components as SysML «requirement»s (non standard)
Figure B.12 - Establishing Derived Requirements and Rationale from Lowest Tier of Requirements Hierarchy
Figure B.13 - Acceleration Requirement Relationships.jpg)
Figure B.15 - Defining the Automotive Domain (Automotive Domain Breakdown)_0.jpg)
Figure B.16 - Defining Structure of the Hybrid SUV System (Hybrid SUV Breakdown)
Figure B.16a - Alternative: using «composition» wrappers for assemblies
Figure B.17 - Internal Structure of Hybrid SUV.jpg)
Figure B.18 - Defining Structure of Power Subsystem (PowerSubsystem Breakdown)_2.jpg)
Figure B.19 - Internal Structure of the Power Subsystem (Alternative 1 - Combined Motor Generator)
Figure B.19a PowerSubsystem BDD: part and port design with required/provided interfaces_0.jpg)
Figure B.20 - Interfaces Typing StandardPorts Internal to the Power Subsystem (ICE Interface Definitions)
Figure B.21 - Initially Defining Flow Specifications for the CAN Bus.jpg)
Figure B.22 - Consolidating Interfaces into the CAN Bus (CAN Bus Description)_1.jpg)
Figure B.23 - Elaborating Definition of Fuel Flow (Power Subsystem Fuel Flow Definition)
Figure B.24 - Defining Fuel Flow Constraints
FuelFlow.constraint_0.jpg)
Figure B.25 - Detailed Internal Structure of Fuel Delivery Subsystem (Fuel Distribution Detail)_0.jpg)
Figure B.26 - Defining Analyses for Hybrid SUV Engineering Development (Analysis Context)
Figure B.27 - Establishing a Performance View of the User Model_1.jpg)
Figure B.28 - Defining Measures of Effectiveness and Key Relationships (HSUV MOEs)
Figure B.29 - Establishing Mathematical Relationships for Fuel Economy Calculations
Figure B.30 - Straight Line Vehicle Dynamics Mathematical Model
Figure B.31 - Defining Straight-Line Vehicle Dynamics Mathematical Constraints
Figure B.33 - Behavior Model for Accelerate Function
Figure B.33a - Behavior Model for Accelerate Function: alternative using Pins_0.jpg)
Figure B.34 - Decomposition of Accelerate Function (Activity and Object Flow Breakdown)
Figure B.35 - Detailed Behavior Model for Provide Power (with Swimlane Allocation).jpg)
Figure B.36 - Flow Allocation to Power Subsystem (Power Functional Allocation).jpg)
Figure B.38 - Special Case of Internal Block Diagram Showing Reference to Specific Properties (Test Results) [NOT SUPPORTED]
WORKAROUND for Property-Specific Types for Hybrid SUV test results
Decomposition of Activity Operate Car: using Activity Decomposition Hierarchy Wizard 
Figure 11.10 - Continuous system example 1: Operate Car_0.png)
Figure 11.10 - Continuous system example 1: Operate Car (adapted to use Pins, no annotations)
Figure 16.3 - Requirements Derivation: Safety Test
Figure 16.4 - Links between requirements and design: MasterCylinderSafety.png)
Figure 8.8 - Block diagram for the Wheel Package (WheelHubAssembly)
Figure 8.8 - WheelHubAssembly: alternative: how to use: composition wrappers
Figure 8.9 - Internal Block Diagram for WheelHubAssembly
HOWTO use property-specific default values: Hybrid SUVs with different size wheels
Default Values for small Hybrid SUV vehicle
Default Values for large Hybrid SUV vehicle
Allocation Tree for Provide Power Actions
Figure B.03: HSUV Model
Figure B.12: Requirement Derivation
Figure B.15: Automotive Domain Breakdown
Figure B.16: HybridSUV Breakdown
Figure B.17: HybridSUV
Figure B.18: Alternative 1 - Combined Motor Generator
Figure B.18: PowerSubsystem breakdown
Figure B.21: CAN Bus FlowSpecifications
Figure B.22: CAN Bus description
Figure B.23: PowerSubsystem Fuel Flow Definition
Figure B.24: Defining Fuel Flow Constraints
Figure B.25: Fuel Distribution Detail
Figure B.26: Analysis Context
Figure B.28: HSUV MOEs
Figure B.29: EconomyContext
Figure B.31: Definition of Dynamics
Figure B.33: Accelerate
Figure B.34: Activity and ObjectFlow breakdown
Figure B.35: with Swimlane Allocation (with elided Pin notation)_0.jpg)
Figure B.35: with Swimlane Allocation (with explicit Pin notation)
Figure B.36: Power Functional Allocation
(11066) Namespace compartment for blocks
(11275): 8.3.2: Unit/Dimension Notation "to underline or not to underline"
(11493) Lack of notation for units and dimensions on values
UseValued
(11622) Mapping of PropertySpecificType to the UML metamodel
UseA
RedfinitionContextForSystem
(12128) Suggest Unit and ValueType both extend abstract DimensionedType, and inherit a 'dimension' attribute
[Suggest show both part-specific values & static values "showing through" to part within a value context with static indicator]
(10059) 'Interfaces on Flow Ports': Recommend use nested ports: Hydraulic Morse System
(10059) 'Interfaces on Flow Ports'
(10342) 'Section: 9.3.2.8 ItemFlow: CASE STUDY: Signal'
CommunicationSystem
(10342) 'Section: 9.3.2.8 ItemFlow'
(10371) RECOMMEND: use both default value "callout" into a note and 'initial values' compartment in an IBD
UseBattery
(11599) "Fix for Fig 9.4 p70"
11599 Figure 9.4 - Interfaces 'ctrl' standard port of InternalCombustionEngine
(11628) Consider nested ports
Context for nested ports example.jpg)
12222) 9.3.2.3 FlowPort, 9.3.2.7 Standard Port: formally permit useful idiom of flowport nested within standard port
8.4.4 Water Delivery: using nested ports
House IBD: using nested ports
HiFi with headphone port with audio flowport ports being produced and consumed by ports with HiFi flowports
example_of_nested_flowport_HiFi_producer_consumer (BDD)
relaying part Property (with SysML NestedConnectorEnd) vs relaying Port
relaying part Property vs relaying Port (BDD)
(10524) Constraint parameter stereotype
(11495) Constraint parameter notation conflicts with UML private ports notation
(11501) Wrong ends of Allocate relationship used in Allocated definition
(12134) «rate» stereotype has property 'rate' type ValueSpecification in 11.3.2.8 Rate yet InstanceSpecification in Figure 11.8 
SysML1.0: Figure 11.10 - Continuous system example 1
Figure B.27: <> Package "steals ownership" of MOEs, Actor, UseCase and Requirement.png)
Figure B.35: prefer <> pins over contrived placement of ObjectNodes on border of swimlanes
Figure B.33: suggest use in/out Pin pairs instead of <> accelPosition ObjectNode
SysML profile/metamodel and additional MagicDraw SysML stereotypes (from 2008)
10.3.2.1 ConstraintBlock
10.3.2.2 ConstraintProperty
8.3.2.1 Binding Connector
8.3.2.10 ValueType
8.3.2.2 Block
8.3.2.3 ConnectorProperty
8.3.2.4 DistributedProperty
8.3.2.6 NestedConnectorEnd
8.3.2.7 ParticipantProperty
AssociationBlock: example of decomposed connections between ParticipantProperties
9.3.2.3 FlowPort
9.3.2.6 ItemFlow
Example: ItemFlow without 'itemProperty'.jpg)
15.3.2.1 Allocate (from Allocations),%20but%20may%20have%20many%20clients%20(to).jpg)
ERROR: A single «allocate» dependency shall have only one supplier (from), but may have many clients (to).
It is a mechanism for associating elements of different types, or in different hierarchies, at an abstract level._0.jpg)
15.3.2.2 Allocated(from Allocations)
ERROR: «allocated» elements may be designated by either the /from or /to end of an «allocate» dependency
Example: ItemFlow with 'itemProperty'
AbstractReferenceProperty (MD SysML)
Block extensions (non-normative)
BlockProperty (MD SysML)
This stereotype provides for the properties "allocatedFrom" and "allocatedTo," which are derived from the «allocate» dependency%20of%20an%20%C2%ABallocate%C2%BB%20whose%20supplier%20is%20extended%20by%20this%20stereotype%20(instance)_0.jpg)
/allocatedFrom:NamedElement[*] Reverse of allocatedTo: the element types and names of the set of elements that are suppliers ..%20of%20an%20%C2%ABallocate%C2%BB%20whose%20client%20is%20extended%20by%20this%20stereotype%20(instance).jpg)
/allocatedTo:NamedElement[*]: The element types and names of the set of elements that are clients ..
Analysis of the UML2 relationship metaclasses that support the SysML «allocate»
ConstraintParameter (MD SysML)
PartProperty (MD SysML)
ReferenceProperty (MD SysML)
SharedProperty (MD SysML)
ValueProperty (MD SysML)
Overview of the SysML diagrams_0.jpg)
Block Definition Diagram (BDD) in MD SysML
Framed IBD in MD SysML with cross-project navigation
Frameless IBD in MD SysML: pros and cons
IBD as “context diagram” for a system
Package Diagram in MD SysML
Package Diagram for View and ViewPoint
Email: please use the contact form Tel: +61 (2) 9386-0090 Post: webel.com.au, PO Box 1816, Bondi Junction, NSW 1355, Australia. ABN: 67 677 268 579 
© Copyright 2000 - 2010 webel.com.au. All rights reserved.
Excluded: selected images from the MagicDraw™ UML and SysML eSchool as referenced by URL, which remain © Copyright 2008 No Magic Inc.
This web site contains educational examples of techniques for parsing text sources into UML™ analysis models.
Where possible explicit permission from authors of original sources has been sought; please report copyright conflicts here.
Text from Wikipedia articles parsed into UML™ analysis models is subject to copyleft under the GNU_Free_Documentation_License
Text from OMG™ specifications - parsed into UML™ analysis models and Drupal™ node titles - remains © Copyright The Object Management Group™.
Text from Java™ tutorials and documentation - parsed into UML™ analysis models and Drupal™ node titles - remains © Copyright Sun Microsystems Inc.
Excluded: selected images from the MagicDraw™ UML and SysML eSchool as referenced by URL, which remain © Copyright 2008 No Magic Inc.
This web site contains educational examples of techniques for parsing text sources into UML™ analysis models.
Where possible explicit permission from authors of original sources has been sought; please report copyright conflicts here.
Text from Wikipedia articles parsed into UML™ analysis models is subject to copyleft under the GNU_Free_Documentation_License
Text from OMG™ specifications - parsed into UML™ analysis models and Drupal™ node titles - remains © Copyright The Object Management Group™.
Text from Java™ tutorials and documentation - parsed into UML™ analysis models and Drupal™ node titles - remains © Copyright Sun Microsystems Inc.
With thanks to Volacci for the wonderful SEO Checklist module.
