Ing Guidelines Of Basic Software EA UML AUTOSAR TR BSWUML Guide
AUTOSAR_TR_BSWUMLingGuide
AUTOSAR_TR_BSWUMLingGuide
AUTOSAR_TR_BSWUMLingGuide
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 47
| Download | |
| Open PDF In Browser | View PDF |
Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Document Title Modeling Guidelines of Basic Software EA UML Model Document Owner Document Responsibility Document Identification No Document Classification AUTOSAR AUTOSAR 117 Auxiliary Document Status Part of AUTOSAR Release Final 4.2.1 Document Change History Release Changed by 4.2.1 AUTOSAR Release Management 4.1.1 AUTOSAR Administration 3.1.4 AUTOSAR Administration 3.1.1 3.0.1 AUTOSAR Administration AUTOSAR Administration 2.1.1 AUTOSAR Administration 2.0 AUTOSAR Administration 1 of 47 Change Description Editorial changes Finalized for Release 4.1 Modeling of header files has been revised Description of parameter modeling has been reworked Legal disclaimer revised Legal disclaimer revised Added description for range stereotype Change Requirements for function parameter and structure attributes Document meta information extended Small layout adaptations made Usage of packages clarified Sequence diagram modeling clarified Legal disclaimer revised Initial release Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Disclaimer This specification and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the companies that have contributed to it shall not be liable for any use of the specification. The material contained in this specification is protected by copyright and other types of Intellectual Property Rights. The commercial exploitation of the material contained in this specification requires a license to such Intellectual Property Rights. This specification may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only. For any other purpose, no part of the specification may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher. The AUTOSAR specifications have been developed for automotive applications only. They have neither been developed, nor tested for non-automotive applications. The word AUTOSAR and the AUTOSAR logo are registered trademarks. Advice for users AUTOSAR specifications may contain exemplary items (exemplary reference models, "use cases", and/or references to exemplary technical solutions, devices, processes or software). Any such exemplary items are contained in the specifications for illustration purposes only, and they themselves are not part of the AUTOSAR Standard. Neither their presence in such specifications, nor any later documentation of AUTOSAR conformance of products actually implementing such exemplary items, imply that intellectual property rights covering such exemplary items are licensed under the same rules as applicable to the AUTOSAR Standard. 2 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Table of Contents 1 Scope of this Document ............................................................................ 5 2 Related Documentation ............................................................................ 6 2.1 2.2 Deliverables of AUTOSAR work packages ............................................... 6 Related standards and norms ................................................................... 6 3 Terms and abbreviations .......................................................................... 7 4 Requirements on the modeling of the Basic Software .............................. 8 4.1 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 4.1.7 4.2 4.2.1 4.2.2 4.2.3 4.2.4 General ..................................................................................................... 8 [TR_BSWUML_00017] UML 2.0 ............................................................... 8 [TR_BSWUML_00065] Application of the BSW UML Profile .................... 8 [TR_BSWUML_00001] Allowed elements ................................................ 9 [TR_BSWUML_00002] Allowed relationships ......................................... 10 [TR_BSWUML_00053] Allowed set of diagrams .................................... 11 [TR_BSWUML_00060] Documentation of elements ............................... 11 [TR_BSWUML_00047] Links between diagrams shall be hyperlinks ..... 12 Structural Design .................................................................................... 13 [TR_BSWUML_00054] Use of Packages ............................................... 13 [TR_BSWUML_00003] Diagrams usage ................................................ 13 [TR_BSWUML_00038] Component diagram appearance options .......... 13 [TR_BSWUML_00039] Component diagram appearance of BSW module diagrams ................................................................................................. 14 4.2.5 [TR_BSWUML_00004] Header File Modeling ........................................ 15 4.2.6 [TR_BSWUML_00005] Basic Software Module Modeling ...................... 16 4.2.7 [TR_BSWUML_00010] Component Definition ........................................ 16 4.2.8 [TR_BSWUML_00009] Version numbers of software modules .............. 17 4.2.9 [TR_BSWUML_00025] ‘Language’ definition of Components ................ 18 4.2.10 [TR_BSWUML_00052] Interface creation ............................................... 19 4.2.11 [TR_BSWUML_00006] Interface Modeling ............................................. 20 4.2.12 [TR_BSWUML_00011] Accessing interfaces of other components ........ 21 4.2.13 [TR_BSWUML_00027] Definition of structures ....................................... 21 4.2.14 [TR_BSWUML_00026] Definition of enumerations ................................. 22 4.2.15 [TR_BSWUML_00028] Definition of simple types ................................... 23 4.2.16 [TR_BSWUML_00059] Definition of typedefs ......................................... 24 4.2.17 [TR_BSWUML_00066] Definition of ranges for typedefs ........................ 24 4.2.18 [TR_BSWUML_00062] Definition of functions and callbacks .................. 25 4.2.19 [TR_BSWUML_00068] Definition of parameters .................................... 25 4.2.20 [TR_BSWUML_00037] Definition of pointer types .................................. 26 4.2.21 [TR_BSWUML_00055] Use of parameter kind ....................................... 27 4.2.22 [TR_BSWUML_00061] Definition of return type ..................................... 27 4.2.23 [TR_BSWUML_00063] Definition of scheduled functions ....................... 28 4.2.24 [TR_BSWUML_00035] Sub elements of BSW modules ......................... 28 4.3 Behavioral Design ................................................................................... 29 4.3.1 General ................................................................................................... 29 4.3.2 Sequence Diagrams ............................................................................... 30 4.3.3 [TR_BSWUML_00057] Parameter values in sequence diagrams .......... 31 3 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 4.3.4 4.3.5 4.4 4.4.1 4.4.2 4.4.3 4.4.4 4.5 4.5.1 5 BSW UML Profile .................................................................................... 44 5.1.1 5.1.2 5.1.3 5.1.4 6 4 of 47 State Machine Diagrams......................................................................... 35 Activity Diagrams .................................................................................... 39 Model synchronization ............................................................................ 41 [TR_BSWUML_00013] Creating a Design Master .................................. 41 [TR_BSWUML_00023] Design Master naming convention .................... 41 [TR_BSWUML_00014] Creating replicas from the Design Master ......... 42 [TR_BSWUML_00022] Replica naming convention ............................... 42 Documentation generation ...................................................................... 43 [TR_BSWUML_00067] Providing an alternative name for generated tables ...................................................................................................... 43 Stereotypes callback, function and scheduled function........................... 44 Stereotypes module, type, typedef and structure .................................... 44 Stereotypes mandatory, configurable and optional ................................. 45 Stereotype range .................................................................................... 45 Administrative Info .................................................................................. 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 1 Scope of this Document This Modeling Guideline contains guidelines for the usage of the Enterprise Architect UML Modeling Tool (EA) that is used for the detailed architecture design of the AUTOSAR Basic Software. Each guideline has its unique identifier starting with the prefix “TR_BSWUML_” (BSW = Basic Software). For any review annotations, remarks or questions please refer to this unique ID rather than chapter or page numbers! 5 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 2 Related Documentation 2.1 Deliverables of AUTOSAR work packages [1] List of Basic Software Modules AUTOSAR_TR_BSWModuleList.pdf [2] General Requirements on Basic Software Modules AUTOSAR_SRS_BSWGeneral.pdf [3] Layered Software Architecture AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf 2.2 Related standards and norms [4] UML 2.0, Unified Modeling Language: Superstructure, Version 2.0, OMG document formal/05-07-04." 6 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 3 Terms and abbreviations Terms Definitions BSW Module Component Each BSW module is modeled using one “UML Component” and several “Interface Classes” within the BSW UML model. The “UML Component” represents the internal behavior or C-file(s) of the BSW module. It is called “BSW Module Component” Model element defined by [4]. UML 2.0 class with stereotype “interface”. Each BSW module is modeled using one “UML Component” and several “Interface Classes” within the BSW UML model. The “Interface classes” represent the header files of a specific BSW module. They are called “BSW Module Interfaces” The “project view” window within the Enterprise Architect is called “Tree view”. UML Component Interface class BSW Module Interface Tree view 7 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 4 Requirements on the modeling of the Basic Software 4.1 General 4.1.1 [TR_BSWUML_00017] UML 2.0 ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00017 WP Architecture 14.10.2004 UML 2.0 shall be used for modeling the BSW UML model. Changed high The UML specification 2.0 shall be used for modeling the AUTOSAR Basic Software with the tool Enterprise Architect (EA). Not defining new modeling techniques when there are techniques already available and standardized. Modeling the Basic Software of AUTOSAR. ----- 4.1.2 [TR_BSWUML_00065] Application of the BSW UML Profile ID: Initiator: Date: Short Description: Type: Importance: Description: 8 of 47 TR_BSWUML_00065 Technical Office 27.04.2007 BSW UML profile Application of the BSW UML Profile high The latest version of the BSW UML profile has to be applied to the BSW UML model. When a new version of the BSW UML profile has been released, it has to be reapplied to the BSW UML model. To apply the profile, it has to be exported to XML via the “Save Package as UML Profile” menu entry. Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 The exported XML file than has to be reimported on the BSW UML model file via the “Import Profile” menu. Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: The BSW UML profile is needed to store additional BSW specific information in the model. ---- 4.1.3 [TR_BSWUML_00001] Allowed elements ID: Initiator: 9 of 47 TR_BSWUML_00001 WP Architecture Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: 27.04.2007 Allowed elements high The following elements of UML are allowed to use within the Basic software overall UML model: - package - class (‘typedef’) for classes describing C typedefs - class (‘type’) for classes describing C types - class (‘structure’) for classes describing C structs - enumeration for C enums - operation (‘function’) for functions - operation (‘scheduled_function’) for scheduled functions - operation (‘callback’) for callbacks - component (‘module’) for components describing the interfaces of a BSW module - interface - lifeline - fragment - note - node (with stereotype peripheral or cluster) - state (including initial, final, fork/join, choice, exit) - action - decision - activity - boundary Other elements shall not be used. Restriction of different modeling techniques. Modeling of the complete communication stack [TR_BSWUML_00053] Allowed diagrams ---- 4.1.4 [TR_BSWUML_00002] Allowed relationships ID: Initiator: Date: Short Description: Type: Importance: Description: 10 of 47 TR_BSWUML_00002 WP Architecture 07.10.2004 Allowed relationships Changed high The following relationships are allowed to use within the Basic software overall UML model: - realize - nesting - dependency (‘mandatory’) : for mandatory interfaces of a component - dependency (‘optional’) : for optional interfaces of a component - dependency (‘configurable”) : for configurable interfaces of a component - message - Self-message - Call - transition - activity edge Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: Other relationships shall not be used. Restriction of different modeling techniques. Modeling of the complete communication stack [TR_BSWUML_00053] Allowed diagrams ---- 4.1.5 [TR_BSWUML_00053] Allowed set of diagrams ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00053 WP Architecture 07.10.2004 Allowed set of diagrams Changed high Only a reduced set of diagrams shall be used. Allowed structural diagrams are : - Package diagrams and - Component diagrams. Allowed sequence diagrams are: - Sequence diagrams - Activity diagrams and - State machine diagrams. Restriction of different modeling techniques. Modeling of the complete communication stack [TR_BSWUML_00001] Allowed elements [TR_BSWUML_00002] Allowed relationships ---- 4.1.6 [TR_BSWUML_00060] Documentation of elements ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: TR_BSWUML_00060 Technical office 27.04.2007 Elements used for generating SWS tables must be documented High Documentation (‘Notes’) must be provided for the following element types: class (‘type’, ‘typedef’, ‘structure’) attributes operation (‘function’, ‘scheduled_function’, ‘callback’) enumeration parameter BSW documentation generator needs description for these elements to be able to generate the tables. Use Case: 11 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Dependencies: Conflicts: Supporting Material: Contributes to: 4.1.7 -- [TR_BSWUML_00047] Links between diagrams shall be hyperlinks ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: 12 of 47 ---- TR_BSWUML_00047 WP Mode Management 14.02.2005 Links between diagrams shall be hyperlinks Changed High If the relationship between two diagrams shall be visualized, then the link shall be modeled as a hyperlink. Easier navigation between diagrams. ----- Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 4.2 Structural Design 4.2.1 [TR_BSWUML_00054] Use of Packages ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00054 Technical Office 31.07.2006 Use of Packages New High Packages may be used in three ways: (1) To group (only) sub-packages, (2) to represent one BSW module, grouping the BSW module component and its interfaces or (3) placed below a package of the second type to group additional elements detailing a BSW module. Packages of the first or second type shall only be added by the technical office. Clear structure of the BSW UML model. Modeling of the complete software architecture [TR_BSWUML_00003] Diagrams usage [TR_BSWUML_00009] Version numbers of software modules [TR_BSWUML_00035] Sub elements of BSW modules ---- 4.2.2 [TR_BSWUML_00003] Diagrams usage ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Contributes to: TR_BSWUML_00003 WP Architecture 07.10.2004 Diagram usage Changed . high Each package containing only sub-packages shall at least have one structural “Component” diagram which shows the contents and, if possible, the relationships of the packages which it contains. Each package representing a BSW module shall at least have one structural “Component” diagram which shows at least the "realize", "mandatory", “optional” and “configurable” relationships of the BSW module component which it contains. The name of this diagram shall be equal to the BSW module component name. This diagram shall be placed below the appropriate diagram within the tree view. Have for each structural element a diagram showing the elements containing it. -- 4.2.3 [TR_BSWUML_00038] Component diagram appearance options ID: 13 of 47 TR_BSWUML_00038 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: WP Architecture 08.02.2005 Component diagram appearance options New high In general only the following appearance options of component diagrams shall be set: - Use stereotype icons - yes - Scale printing to 1 page - optional - Show page border - yes - Highlight foreign objects - yes - Show package contents - optional - Show details on diagram - yes - Hide operations - yes - Hide attributes - yes If a user requires more options, he shall ask the technical office for clearance: technical.office@autosar.org. Harmonization of diagram appearance. ----- 4.2.4 [TR_BSWUML_00039] Component diagram appearance of BSW module diagrams ID: Initiator: Date: Short Description: Type: Importance: 14 of 47 TR_BSWUML_00039 WP Architecture 13.01.2005 Component diagram appearance of BSW module diagrams new high Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Description: Rationale: Diagrams placed below the BSW module package shall apply the following changes to the appearance options compared to TR_BSWUML_00038: - Hide attributes - No - Hide operations - No - Show constraints - yes - Show Tags - yes Visualizing all attributes, operations and constraints of a BSW module component. Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00038 ---- 4.2.5 [TR_BSWUML_00004] Header File Modeling ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: 15 of 47 TR_BSWUML_00004 WP Architecture 03.09.2009 Header File Modeling Changed High Each file of a basic software module being of external relevance shall be modeled as an own public document artifact (see Toolbox>Component). The document artifacts shall be declared as either header or source file using the stereotypes “header” and “source”. Document artifacts can include other artifacts using a dependency with stereotype “include”. With the additional stereotype “optional”, optional inclusion can be expressed. Document artifacts with stereotype “header” can relate to interfaces, using a dependency with stereotype “declares”, artifacts with stereotype “source” can relate to modules, using a dependency with stereotype “realize”. The following consistency constraints apply: A source file realizing a module shall include header files declaring all interfaces that are realized and required by the module. Enabling the showing of “include” relationships between source and header files. Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Use Case: Modeling of Eep header file inclusion «declares» «header» Eep.h Eep «realize» «includes» «realize» «module» Eep «source» Eep.c «optional,includes» «header» Eep_Cbk.h «includes» «mandatory» «declares» «header» Dem::Dem.h Dem_ReportErrorStatus Dependencies: Conflicts: Supporting Material: Contributes to: SRS_BSW_00370, SRS_BSW_00346, SRS_BSW_00353, SRS_BSW_00361 ---- 4.2.6 [TR_BSWUML_00005] Basic Software Module Modeling ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00005 WP Architecture 27.04.2007 Basic Software Module Modeling new high Each basic software module source code file(s) shall be modeled as an UML package containing one component with stereotype “module” (the “BSW Module Component”) and the appropriate interfaces (the “BSW Module Interfaces”). The name of the package and component shall be the Prefix of the basic software module (specified within the basic software list). Restriction of different modeling techniques. Modeling of ECU State Manager. Name of this component: EcuM ----- 4.2.7 [TR_BSWUML_00010] Component Definition ID: Initiator: Date: Short Description: Type: 16 of 47 TR_BSWUML_00010 WP Architecture 08.10.2004 Component Definition new Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: high Each “BSW Module Component” in the cluster diagram shall be marked as “Composite Element”. Easier navigation within the model Look into the details of one specific component. ----- 4.2.8 [TR_BSWUML_00009] Version numbers of software modules ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: 17 of 47 TR_BSWUML_00009 WP Architecture 07.10.2004 Version numbers of software modules Changed High For each component which has the ‘module’ stereotype (represents a BSW module) the version must be specified according to the modules version number. Model everything in the same style so that it is easier to understand Modeling of Fls Interfaces: ----- Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 4.2.9 [TR_BSWUML_00025] ‘Language’ definition of Components ID: Initiator: Date: Short Description: Type: Importance: Description: TR_BSWUML_00025 WP Architecture 26.11.2004 ‘Language’ definition of Components Changed (supporting material added) high The ‘Language’ Attribute of at least each Component which represents a Software module shall be set to AUTOSAR. Rationale: The AUTOSAR language defines a set of basic types which shall be used within AUTOSAR. Using AUTOSAR type uint8 as return value. --If you set in the options menu AUTOSAR to the default language the correct language will be set automatically: Tools -> Options -> Use Case: Dependencies: Conflicts: Supporting Material: 18 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Contributes to: -- 4.2.10 [TR_BSWUML_00052] Interface creation ID: Initiator: Date: Short Description: Type: Importance: Description: 19 of 47 TR_BSWUML_00052 WP Architecture 07.11.2005 Interface creation new high Interfaces shall only be created by dragging “Interface” from the toolbox into a diagram. Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Rationale: There are two ways in EA to create an interface class: (a) Create a regular class and afterwards add the stereotype <>. (b) Directly drag a new interface into a diagram (e.g. from the toolbox window). Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: Only (b) leads to a real interface in the EA sense: o correct icon in the project view o class and all operations are enforced to be abstract Modeling of the complete communication stack ----- 4.2.11 [TR_BSWUML_00006] Interface Modeling ID: Initiator: Date: Short Description: Type: Importance: Description: 20 of 47 TR_BSWUML_00006 WP Architecture 07.10.2004 Interface Modeling new high Each external interface class shall be modeled in “circle notation” within the Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: “component diagram” of a package containing the basic software module components and/or classes. Interfaces are the containers for subsequent API elements, they can contain type definitions and functions. See according sections for descriptions, how to model elements of interfaces. Restriction of different modeling techniques. Modeling of ECU State manager. Type definitions: TR_BSWUML_00026, TR_BSWUML_00027, TR_BSWUML_00028, [TR_BSWUML_00059 Function definitions: TR_BSWUML_00062, TR_BSWUML_00063 ---- 4.2.12 [TR_BSWUML_00011] Accessing interfaces of other components ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00011 WP Architecture 27.04.2007 Accessing interfaces of other components Changed high If a basic software module requires the access of another module this relation shall be modeled as a “mandatory” dependency between the component of the basic software module requiring the access and the appropriate Interface class of the other basic software module. If the interface to be accessed is not in the same package a link to the interface shall be copied into the appropriate diagram. The link shall be modeled in circle notation. Restriction of modeling techniques Eep Interface “uses” interface of Eep driver. ----- 4.2.13 [TR_BSWUML_00027] Definition of structures ID: Initiator: Date: Short Description: Type: Importance: Description: 21 of 47 TR_BSWUML_00027 WP Architecture 27.04.2007 Definition of structures high Each type definition which represents a structure declaration shall be modeled as a class with the stereotype ‘structure’. All possible entries shall be defined as attributes of that class. The attributes shall have the scope “public”. The ordering of the attributes shall be the same as expected in the generated table. For each attribute the appropriate type shall be specified: Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: All types have to be defined in the same way, so that there are no inconsistencies within the model. The example shown in the description represents the following Std_Types enumeration: typedef struct PduInfoType { uint8* SduDataPtr, uint16 Length }; Definition of simple types TR_BSWUML_00028 ---- 4.2.14 [TR_BSWUML_00026] Definition of enumerations ID: Initiator: Date: Short Description: Type: Importance: Description: 22 of 47 TR_BSWUML_00026 WP Architecture 26.11.2004 Definition of enumerations Changed high Each type definition representing an enumeration shall be modeled as a n UML enumeration. Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 All possible entries have to be defined as attributes of this class. The order of the attributes from top to bottom shall represent the order of the enumeration specified. The Attributes shall have no type and the ‘scope’ has to be set to ‘public’. It shall be placed below the interface specifying it. Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: For attribute names, the AUTOSAR-conform attribute values shall be used. If for this attribute value a code number exist, this code number shall be placed in the "initial” value entry of a type's detailed properties form in EA. All types have to be defined in the same way, so that there are no inconsistencies within the model. The example shown in the description represents the following Std_Types enumeration: typedef enum FlsIf_JobResultType { FLSIF_JOB_OK, FLSIF_JOB_PENDING, … }; Need to represent DCM's Neg Resp Codes (NRCs), for which an enum type is defined in SWS DCM v1.1.6, section 8.1.2.8. Place the NRC "DEM_E_xxx" in [attribute]"name" and the 0x value in "initial” value. Definition of simple types TR_BSWUML_00028 ---- 4.2.15 [TR_BSWUML_00028] Definition of simple types ID: Initiator: Date: Short Description: Type: Importance: Description: 23 of 47 TR_BSWUML_00028 WP Architecture 27.04.2007 Definition of simple types high Each type definition shall be modeled as a separate class with stereotype ‘type’. If the type has a hardware and configuration independent type (e.g. Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: ‘unit8’), the tagged value ‘range’ has to specify the range as text. All types have to be defined in the same way, so that there are no inconsistencies within the model. -Definition of structures [TR_BSWUML_00027], Definition of enumerations TR_BSWUML_00026 --- 4.2.16 [TR_BSWUML_00059] Definition of typedefs ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00059 Technical Office 27.04.2007 Definition of typedefs high Each type definition shall be modeled as a separate class with stereotype ‘typedef’. If the typedef is independent from the configuration, the typedef must be a specialization of the type it is referring to. If the typedef can refer to different types depending on the configuration, the typedef must be a specialization of those types. The documentation generator has extract information regarding the typedefs from the UML model. -Definition of structures TR_BSWUML_00028, Definition of enumerations TR_BSWUML_00026 ---- 4.2.17 [TR_BSWUML_00066] Definition of ranges for typedefs ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: 24 of 47 TR_BSWUML_00066 Technical Office 23.07.2007 Definition of ranges for typedefs high If a typedef (class with stereotype < >) has a restricted set of ranges, an attribute with stereotype < > has to be created for each such range. The name of the attribute specifies the range label and the notes field describes the range. The documentation generator has to extract information regarding the range of typedefs from the UML model. See «typedef» Fim_FunctionIdType. Definition of structures TR_BSWUML_00028 -Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Supporting Material: Contributes to: --- 4.2.18 [TR_BSWUML_00062] Definition of functions and callbacks ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00062 Technical Office 27.04.2007 Definition of functions high Each BSW function must be represented by an operation with stereotype ‘function’. Each BSW callback must be represented by an operation with stereotype ‘callback’. The following tagged values must be specified: ServiceID: numeric id of the function Synchronous: must be set to ‘true’ if this function is synchronous, must be set to ‘false’ otherwise Reentrancy: description of the reentrancy for this function. Should be set to “Reentrant” for reentrant functions. Should be set to “Non-Reentrant” for non-reentrant functions. The documentation generator needs this information to generate the function tables. ------ 4.2.19 [TR_BSWUML_00068] Definition of parameters ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: 25 of 47 TR_BSWUML_00068 WP Virtual Functional Bus 09.07.2009 Definition of parameters New High Parameters of functions are defined, by going to the “Edit Parameters” dialog and adding the parameters with the “New” button. All parameters must have a name and a type. Type names in braces (e.g. “ ”) are considered to be generic. A C ellipse can be used by typing a blank as name and “…” as type. It is as well considered a generic type. Parameters shall not have stereotypes. All parameters must have a kind indicating the direction of the information flow. The order of the parameters in the list is relevant. Harmonization of modeling techniques. Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: ----- 4.2.20 [TR_BSWUML_00037] Definition of pointer types ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: 26 of 47 TR_BSWUML_00037 WP Architecture 13.01.2005 Definition of pointer types new high If a parameter or a return value of a module interface represents a pointer the asterix(es) shall be placed directly after the original type. Readability of the module (specific views will otherwise filter out that information). Harmonization of modeling techniques. Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: ----- 4.2.21 [TR_BSWUML_00055] Use of parameter kind ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00055 Technical Office 27.04.2007 Use of parameter kind New High The drop down list for the 'kind' of function parameters should be set to the appropriate value (in, out, in/out, return). In the case that EA adds a "*" to the parameter type (for 'out') although it is already a pointer (by a typedef), this should be annotated in the field 'notes' of the respective function. Note that all out and inout parameters must be pointer types. Use the in/out feature and work around the EA bug. Modeling of the com stack types [TR_BSWUML_00037] Definition of pointer types ---- 4.2.22 [TR_BSWUML_00061] Definition of return type ID: Initiator: Date: 27 of 47 TR_BSWUML_00061 Technical Office 27.04.2007 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: Definition of return type New High The return type of a function must not be specified. Instead a parameter with kind ‘return’ must be used. Return parameters must be documented. This is not possible when just the return type is specified. ---- 4.2.23 [TR_BSWUML_00063] Definition of scheduled functions ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00063 Technical Office 27.04.2007 Definition of functions High Each BSW scheduled function must be represented by an operation with stereotype ‘scheduled function’. In addition to the tagged values for functions, the following tagged values must be specified: schedule: Must be set to one of the following values o FIXED_CYCLIC o ON_PRE_CONDITION o VARIABLE_CYCLIC o VARIABLE_CYCLIC_OR_ON_PRE_CONDITION The documentation generator needs this information to generate the function tables. ------ 4.2.24 [TR_BSWUML_00035] Sub elements of BSW modules ID: Initiator: Date: Short Description: Type: Importance: Description: 28 of 47 TR_BSWUML_00035 WP Architecture 13.01.2005 Sub elements of BSW modules Changed high The internal behaviour of BSW modules may be modeled in two ways: (1) A package may be added to the package representing the BSW module or (2) elements can be placed below the BSW module component. In case of optional functionality or scaled functionality the respective Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 dependency in the respective diagram shall be commented by selecting ‘Attach Note or Constraint’. The Sub elements of a component could be of type: - separation of concerns / grouping of functionality - optionally / scalability Refinement of ComM. Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: ----- 4.3 Behavioral Design 4.3.1 General 4.3.1.1 [TR_BSWUML_00030] Usage of Sequence Diagrams ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: 4.3.1.2 29 of 47 TR_BSWUML_00030 WP Architecture 13.01.2005 Usage of Sequence Diagrams new high Only sequence diagrams shall be used for modeling interactions of different modules. Restriction of different modeling techniques. Modeling of the sequences of API calls during a LIN frame transmission. BSW_UMLGuide_00007 ---- [TR_BSWUML_00031] Usage of State Machine Diagrams Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00031 WP Architecture 13.01.2005 Usage of State Machine Diagrams new high Only state machine diagrams shall be used for modeling state dependencies within and in between elements. Restriction of different modeling techniques. Modeling of ECU Manager state changes. BSW_UMLGuide_00007 ---- 4.3.2 Sequence Diagrams 4.3.2.1 [TR_BSWUML_00012] Location of Sequence Diagrams ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: 4.3.2.2 -- [TR_BSWUML_00020] Packages to contain sequence diagrams ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: 30 of 47 TR_BSWUML_00012 WP Architecture 13.01.2005 Location of Sequence Diagrams Renamed High All sequence diagrams have to be placed within the “Interaction View Package” Definition of similar model structures Modeling of the AUTOSAR COM stack ---- TR_BSWUML_00020 WP Architecture 25.01.2005 Packages to contain sequence diagrams Changed High A new sequence diagram shall be put into an appropriate package. If no such package is available, it shall be requested from the technical office: technical.office@autosar.org. Guarantee of readability and correct placement of the sequence tree. --Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Conflicts: Supporting Material: Contributes to: 4.3.2.3 ---- [TR_BSWUML_00021] Commenting of Sequence Diagrams ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: TR_BSWUML_00021 WP Architecture 19.10.2004 Commenting of Sequence Diagrams New High Each Sequence diagram shall have a comment placed as ‘note’ within the diagram that contains the following items: Status (open – proposed – approved – conflict – rejected) Description Comment If a sequence diagram is rejected or on conflict, the reason shall be described within the comment. Give other people the chance to understand. Traceability Status: approved Description: A CAN frame is received and indicated to the upper layer in interrupt context. Dependencies: Conflicts: Supporting Material: Contributes to: Comment: -none----- 4.3.3 [TR_BSWUML_00057] Parameter values in sequence diagrams ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: 31 of 47 TR_BSWUML_00057 Technical Office 31.07.2006 Parameter values in sequence diagrams New High If a function is called with a fixed value for one or more of its parameters in a sequence diagram, then this should be modeled by writing 'ParName:=value' in the field 'Parameters' of the respective message. Unified message modeling. Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Use Case: sd startup & shutdow n EcuM::EcuM WdgM::WdgM WdgIf::WdgIf Wdg::Wdg Mcu::Mcu {Startup I} Wdg_Init(ConfigPtr) Initialization of Watchdog Driver in SLOW_MODE for startup phase Wdg_Init EcuM Callout If necessary, EcuM Callout can be used to trigger the Watchdog Driver before Watchdog Manager initialization {Startup II} WdgM_Init(ConfigPtr) Std_ReturnType:= WdgIf_SetMode(DeviceIndex,WdgMode: =WDGIF_FAST_MODE) Std_ReturnType:= Wdg_SetMode(Mode) Wdg_SetMode WdgIf_SetMode WdgM_Init {Run} {Prep Shutdow n} {Go Sleep} Mcu_SetMode(McuMode:=SLEEP_MODE) Mcu_SetMode {Go OFF I} WdgM_DeInit() WdgM_DeInit() Status: Proposed by TO as per SWS WdgM 0.9 Description: Comments: Preconditions: HW Watchdog supports "SLOW" and "FAST" modes Dependencies: Conflicts: Supporting Material: Contributes to: 4.3.3.1 32 of 47 -- [TR_BSWUML_00058] Return values in sequence diagrams ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: [TR_BSWUML_00019] Labeling returns --- TR_BSWUML_00058 Technical Office 31.07.2006 Return values in sequence diagrams New High If the return of a function should be shown to give a specific value, then this should be modeled by writing 'FuncName=value' in the field 'Message' of the respective return-message. Unified message modeling. Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Use Case: sd Sender_Receiv er_Ev ent_Runnable Sender's COM & Network & Receiver's COM Sender :Application Sender :RTE Com::Com Receiv er :RTE Runnable Rte_StatusType:= Rte_Send_p_e(instance,data) Com_SendSignal(SignalId, SignalDataPtr) Com_SendSignal(Com_SignalIdType, Com_ApplicationDataRefType) Rte_Send_p_e(Rte_Instance, void)=RTE_E_OK Rte_COMCallback_Signal_e() (1) The receiver's COM puts the received event item into its COM-queue and invokes the callback function provided by RTE. Com_ReturnType:= Com_ReceiveSignal(SignalId, SignalDataPtr) (2) RTE receives the event item e from COM and puts it into the RTE-queue for event e. Com_ReceiveSignal(Com_SignalIdType, Com_ApplicationDataRefType*)=COM_E_OK Activate an OSEK Task (3) The OSEK task that will execute the receiver's runnable is started. Rte_COMCallback_Signal_e() (4) RTE fetches an event from the event e queue and calls the receiver's runnable with the fetched event as input parameter. Receivers Runnable Receivers Runnable (5) The task is completed. Status: Proposed by TO as per RTE SWS 0.07 Description: Inter-ECU communication Explicit Sender-Receiver communication: INFORMATION_TYPE = event Port name = p, Event item name = e Sender attribute: SUCCESS = no SEND_MODE = once receiver attribute: RECEIVE_MODE = activation_of_runnable_entity BUFFERING = queue(x) (The receiver's COM is implementing the queue) Dependencies: Conflicts: Supporting Material: Contributes to: 4.3.3.2 [TR_BSWUML_00019] Labeling returns ---- [TR_BSWUML_00018] Modeling of data copying ID: Initiator: Date: Short Description: Type: Importance: Description: TR_BSWUML_00018 WP Architecture 18.10.2004 Modeling of data copying new high Within sequence diagrams, the following scheme shall be used for modeling data copied/stored/…: Data flow is depicted as Self-Message plus a comment field In the message text is documented: What data is copied 33 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: 4.3.3.3 From source To target Definition of uniform data exchange modeling Modeling of data exchange between buffers of different layers ----- [TR_BSWUML_00019] Labeling returns ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: TR_BSWUML_00019 WP Architecture 07.10.2004 Labeling returns Changed High Returns shall be labeled. The label shall be the name of the function it belongs to without parameter names or -types. Returns shall be marked as “Is Return”. It is announced that in future return labels can be automatically be selected within the Enterprise architect. If this is possible no hand-made adaptations shall be done after selection. Allow easy identification to which function a return belongs A UML message has the name “Transmit CAN PDU”. The return message has the same name. sd Nv M_GetDataIndex Generic Elements::Nv M User Nv M::Nv M NvM_GetDataIndex(BlockId,DataIndexPtr) NvM_GetDataIndex Status: Proposed by TO as per NvM SWS 1.44 Description: Comments: Dependencies: Conflicts: Supporting Material: Contributes to: 4.3.3.4 -- [TR_BSWUML_00036] Linking sequence diagrams ID: Initiator: Date: Short Description: Type: Importance: 34 of 47 ---- TR_BSWUML_00036 WP Architecture 13.01.2005 Linking sequence diagrams new high Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Each package within the ‘Interaction Views’ package shall contain dedicated diagrams containing descriptions and links to sub diagrams. Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: These diagrams will be generated by the model owner. The author of a sequence diagram shall therefore provide a short description of contents of generated packages and diagrams to the model owner. Readability of overall module ------ 4.3.4 State Machine Diagrams 4.3.4.1 [TR_BSWUML_00041] States shall have thick lines ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: 35 of 47 TR_BSWUML_00041 WP Mode Management 14.02.2005 States shall have thick lines new high The state boxes shall have an outline of 2 points Allow easier distinction between states and activities Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: 4.3.4.2 transition 36 of 47 -- [TR_BSWUML_00042] A trigger condition shall be defined for each ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: (to see what is meant please zoom to 200%) TR_BSWUML_00048 --- TR_BSWUML_00042 WP Mode Management 14.02.2005 A trigger condition shall be defined for each transition Changed High In each transition between two states the trigger of the transition (the condition to make a transition) shall be defined in the ‘Trigger’ field of the ‘State Flow Properties’. Necessary for complete behavioral description Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: 4.3.4.3 activities 37 of 47 -- [TR_BSWUML_00043] Transitions may be modeled with sub- ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: ---- TR_BSWUML_00043 WP Mode Management 14.02.2005 Transitions may be modeled with sub-activities Changed High To reduce complexity of diagrams Activities may be modeled in a hierarchical way by using sub-activities. In some cases complex activities could trigger a transition. In these cases the diagrams become rather complex. These sub-activities may be visualized as sub activities to reduce complexity in one diagram. Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Use Case: Overview State diagram. ad WAKEUP Perform WAKEUP I Caution: This activity may issue an ECU reset. from SLEEP and GOSLEEP Perform WAKEUP VALIDATION SleepFlag := true Validation Successful? [no] [yes] Perform WAKEUP REACTION WKACT WKACT == ECUM_WKACT_FULLBOOT ? [yes] SleepFlag:= false Perform WAKEUP II [no] WKACT == ECUM_WKACT_SLEEP_OP ? Wake-Sleep-Operation [yes] [no] WKACT == ECUM_WKACT_TTII ? [yes] Time Triggered Increased Inoperation [no] return SleepFlag Dependencies: Conflicts: Supporting Material: Contributes to: 38 of 47 Refined activity ‘WAKEUP’. ----- Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 4.3.4.4 [TR_BSWUML_00046] Links to parent diagrams shall be drawn as hyperlink diagram references ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00046 WP Mode Management 14.02.2005 Links to parent diagrams shall be drawn as diagram references Changed medium The shown diagram (which is only an example) shows an activity diagram of a sub-activity of a larger system. The frame around the diagram indicates the link to the parent diagram. Applies to state and activity diagrams similarly. Simple forward/backward navigation ---Diagram references do not work in the HTML-Report! -- 4.3.5 Activity Diagrams 4.3.5.1 [TR_BSWUML_00048] Activities shall have thin lines ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: 39 of 47 TR_BSWUML_00048 WP Mode Management 14.02.2005 Activities shall have thin lines new high The activity boxes shall have an outline of 1 point Allow easier distinction between states and activities Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: 4.3.5.2 -TR_BSWUML_00041 ---- [TR_BSWUML_00049] Conditions to be defined for each branch ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: TR_BSWUML_00049 WP Mode Management 14.02.2005 Conditions to be defined for each branch Changed High If a flow branches because of a condition, the ‘Decision’ element shall be used. All outgoing control flows must have set a ‘Guard’ constraint in ‘Control Flow Properties’. If different flows shall be merged, also the “Decision” element shall be used. -ad WAKEUP Perform WAKEUP I Caution: This activity may issue an ECU reset. from SLEEP and GOSLEEP Perform WAKEUP VALIDATION SleepFlag := true Validation Successful? [no] [yes] Perform WAKEUP REACTION WKACT WKACT == ECUM_WKACT_FULLBOOT ? [yes] SleepFlag:= false Perform WAKEUP II [no] WKACT == ECUM_WKACT_SLEEP_OP ? Wake-Sleep-Operation [yes] [no] WKACT == ECUM_WKACT_TTII ? [yes] Time Triggered Increased Inoperation [no] return SleepFlag Dependencies: Conflicts: Supporting Material: Contributes to: 40 of 47 --Similar rules apply for forks/joins. The idea is to have the control flow clearly defined. Object flow follows slightly different rules. Such as strict rules make UML clumsy for use with object flow elements. -- Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 4.3.5.3 [TR_BSWUML_00050] Activities to be re-used in sequence diagrams should also be drawn as sequence diagrams ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00050 WP Mode Management 14.02.2005 Activities to be re-used in sequence diagrams must also be drawn as sequence diagrams new medium If an activity is to be referenced within a sequence diagram the drawing messages will not look nice. Therefore this type of activities should also be modeled as sequence diagrams. Nice modeling. ------ 4.4 Model synchronization All guidelines related to the design master are not intended for ‘normal’ users, because the master of the BSW UML model will not be distributed. This chapter will be refined as soon as the process of collaborative work on the BSW UML model has been agreed. 4.4.1 [TR_BSWUML_00013] Creating a Design Master ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00013 WP Architecture 14.10.2004 Creating a Design Master Changed High Convert the base project to a Design Master using the Make Design Master option in the Tools ( Manage .EAP File submenu. -This shall be done once for the project by AUTOSAR Technical Office only (already done – no more actions required). ----- 4.4.2 [TR_BSWUML_00023] Design Master naming convention 41 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00023 WP Architecture 14.10.2004 Design Master naming convention New High The file name of the Design Master shall have the following naming: Master_AR_BasicSWArchitecture.eap and to be managed by a version management tool. -Master_AR_BasicSWArchitecture.eap ----- 4.4.3 [TR_BSWUML_00014] Creating replicas from the Design Master ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: TR_BSWUML_00014 WP Architecture 14.10.2004 Creating replicas from the Design Master new high Create replicas from the design master using the Create New Replica option in the Tools ( Manage .EAP File submenu. Further work must be done on the replica. -To create your own local working model. This has to be done only once. ----- 4.4.4 [TR_BSWUML_00022] Replica naming convention ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: 42 of 47 TR_BSWUML_00022 WP Architecture 14.10.2004 Replica naming convention new high Replicas of the design master shall have the following naming convention: Replica_AR_BasicSWArchitecture_ _ .eap -Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: Replica_AR_BasicSWArchitecture_V24.1_CMA.eap ----- 4.5 Documentation generation 4.5.1 [TR_BSWUML_00067] Providing an alternative name for generated tables ID: Initiator: Date: Short Description: Type: Importance: Description: Rationale: Use Case: Dependencies: Conflicts: Supporting Material: Contributes to: 43 of 47 TR_BSWUML_00067 TO 05.09.2007 Providing an alternative name for generated tables new high The documentation generator for the API tables uses the element name as table name for the inclusion in the SWS Word document. This name has a limited length in Word, which some elements in the BSW UML model exceed. An alternative shorter name can be added by editing the tagged value “aName”. Limitation on the length of anchors in Word. ---AUTOSAR_SWS_DEM.doc -- Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 5 BSW UML Profile 5.1.1 Stereotypes callback, function and scheduled function class BSW-Profile Operations «metaclass» Operation + + + + + isOrdered: Boolean isQuery: Boolean = false isUnique: Boolean lower: Integer upper: UnlimitedNatural «extends» callback Since EA doesn't support inheritance for stereotypes, we have to duplicate all attributes in derived class. To allow mapping to eclipse UML2, which does support inheritance in stereotypes, we have to set the duplicated attributes to derived, so that the converter doesn't duplicate the attributes. - Using inheritance allows us to write oAW templates in a more maintainable fashion, since it also supports inheritance in stereotypes. Synchronous: char = Synchronous Reentrant: char = Non Reentrant ServiceID: int = 0 aName: char function -/ -/ -/ -/ Synchronous: char = Synchronous Reentrant: char = Non Reentrant ServiceID: int = 0 aName: char «enumeration» Schedule scheduled_function FIXED_CYCLIC FIXED_CYCLIC_WITH_PRECONDITION ON_PRE_CONDITION VARIABLE_CYCLIC_OR_ON_PRECONDITION VARIABLE_CYCLIC -/ -/ -/ -/ - Synchronous: char = Synchronous Reentrant: char = Non Reentrant ServiceID: int = 0 aName: char schedule: Schedule = FIXED_CYCLIC 5.1.2 Stereotypes module, type, typedef and structure 44 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 class BSW-Profile Classifiers «metaclass» Class «metaclass» Component + + isIndirectlyInstantiated: Boolean = true isActive: Boolean «extends» «extends» «extends» typedef module - aName: char «extends» structure - aName: char type - Range: char aName: char 5.1.3 Stereotypes mandatory, configurable and optional class BSW-Profile Relationships «metaclass» Dependency + direction: Direction = Source -> Desti... «extends» mandatory «extends» «extends» configurable optional 5.1.4 Stereotype range 45 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 class BSW-Profile Properties «metaclass» Attribute «extends» range 46 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential - Modeling Guidelines of Basic Software EA UML Model AUTOSAR Release 4.2.1 6 Administrative Info Last used Requirements ID is [TR_BSWUML_00068] 47 of 47 Document ID 117: AUTOSAR_TR_BSWUMLModelModelingGuide - AUTOSAR confidential -
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.5 Linearized : No Page Count : 47 Language : de-DE Tagged PDF : Yes Title : Modeling Guidelines of Basic Software EA UML Model Author : AUTOSAR Subject : AUTOSAR Keywords : Release, 4.2 Creator : Microsoft® Word 2010 Create Date : 2014:10:15 15:36:32+02:00 Modify Date : 2014:10:15 15:36:32+02:00 Producer : Microsoft® Word 2010EXIF Metadata provided by EXIF.tools