ASD-STAN PREN 9300-004-2005 Aerospace series LOTAR LOng Term Archiving and Retrieval of digital technical product documentation such as 3D CAD and PDM data Part 004 Description Met.pdf

1、ASD STANDARD NORME ASD ASD NORM prEN 9300-004 Edition P 1 October 2005 PUBLISHED BY THE AEROSPACE AND DEFENSE INDUSTRIES ASSOCIATION OF EUROPE - STANDARDIZATION Gulledelle 94 - B-1200 Brussels - Tel. + 32 2 775 8126 - Fax. + 32 2 775 8111 - www.asd-stan.orgICS: Descriptors: ENGLISH VERSION Aerospace

2、 series LOTAR LOng Term Archiving and Retrieval of digital technical product documentation such as 3D, CAD and PDM data Part 004: Description Methods Srie arospatiale LOTAR Archivage Long Terme et rcupration des donnes techniques produits numriques, telles que CAD 3D et PDM Partie 004 : Mthodes de d

3、escription Luft- und Raumfahrt LOTAR Langzeitarchivierung und Bereitstellung digitaler technischer Produktdokumentationen, beispielsweise 3D CAD und PDM Daten Teil 004: Beschreibungsmethoden This “Aerospace Series“ Prestandard has been drawn up under the responsibility of ASD-STAN (The European Asso

4、ciation of Aerospace Industries - Standardization). It is published for the needs of the European Aerospace Industry. It has been technically approved by the experts of the concerned Domain following member comments. Subsequent to the publication of this pre-standard, the technical content shall not

5、 be changed to an extent that interchangeability is affected, physically or functionally, without re-identification of the standard. After examination and review by users and formal agreement of ASD-STAN, it will be submitted as a draft European Standard (prEN) to CEN (European Committee for Standar

6、dization) for formal vote and transformation to full European Standard (EN). The CEN national members have then to implement the EN at national level by giving the EN the status of a national standard and by withdrawing any national standards conflicting with the EN. Edition approved for publication

7、 31 October 2005 Comments should be sent within six months after the date of publication to ASD-STAN Engineering Procedures and Processes Domain Copyright 2005 by ASD-STAN prEN 9300-004:20052 Foreword This standard was prepared jointly by ASD-STAN and the PROSTEP iViP Association. The PROSTEP iViP A

8、ssociation is an international non-profit association in Europe. For establishing leadership in IT-based engineering it offers a moderated platform to its nearly 200 members from leading industries, system vendors and research institutions. Its product and process data standardization activities at

9、European and worldwide levels are well known and accepted. The PROSTEP iViP Association sees this standard and the related parts as a milestone of product data technology. Users should note that all standards undergo revision from time to time and that any reference made herein to any other standard

10、 implies its latest edition, unless otherwise stated. All EN 9300-xxx standards quoted in this document have been either published as ASD-STAN prestandards or in preparation at the date of this standard. This document includes a Bibliography. prEN 9300-004:20053 Contents Page 1 Scope4 2 Normative re

11、ferences4 3 Terms, definitions and abbreviations4 4 Applicability .4 5 Method for scope/scenario description: UML Use Case diagram5 6 Method for process description: Simplified activity diagram.6 7 Methods for data description .9 7.1 General .9 7.2 Express G diagrams9 7.3 Express WHERE Rules .12 7.4

12、 Modelling of a scenario into Express G syntax .12 7.5 Data Dictionary 13 8 Method for system architecture description: UML Package diagram .13 Bibliography14 Figures Figure 1 Used UML elements 5 Figure 2 Example UML Use case diagram. 6 Figure 3 Example of a simplified activity diagram 7 Figure 4 Hi

13、erarchy structure within simplified activity diagrams. 8 Figure 5 HTML- Representation of simplified activity diagrams. 9 Figure 6 Express G Syntax. 10 Figure 7 Example for an Express G Diagram integrate of complete diagram 11 Figure 8 Example of use of Express G Syntax . 12 Figure 9 Example for an

14、UML package diagram. 13 prEN 9300-004:20054 1 Scope The methods are divided to four main categories: 1) Scope and scenario description 2) Process description 3) Data 4) System Architecture For scope and scenario description, the modelling methods are based on Unified Modelling Language (UML) Use Cas

15、e diagrams. The process descriptions are done using Simplified Activity diagrams. Data modules are described by Express G diagrams. Rules and constraints are described via Express-Where-Rules. Further descriptions, for example, for a data dictionary, are based on tabular forms. To support the develo

16、pment of a system architecture, the modelling method of UML Package diagrams is used. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of

17、the referenced document (including any amendments) applies. ISO 10303-11, Industrial automation systems and integration Product data representation and exchange Part 11: Description methods: The EXPRESS language reference manual. EN 9300-001, Aerospace series LOTAR LOng Term Archiving and Retrieval

18、of digital technical product documentation such as 3D, CAD and PDM data Part 001: Structure. 3 Terms, definitions and abbreviations For the purposes of this standard, the terms, definitions and abbreviations given in EN 9300-007 apply. 4 Applicability EN 9300-004 provides an overview of the used met

19、hods to support a equal level of understanding of the standards context. EN 9300-004 recommends the usage of standardized methods. If not otherwise specified by contractual requirements, EN 9300-004 is applicable to all records which provide objective evidence covering: a) Archiving requirements b)

20、Data quality requirements This EN 9300-004 is applicable to existing records, on current and earlier products, produced using previous regulations. prEN 9300-004:20055 5 Method for scope/scenario description: UML Use Case diagram The Unified Modelling Language (UML) is an industry-standard language

21、for specifying, visualizing, constructing, and documenting software systems. It simplifies the complex process of software design by making a “blueprint“ for construction. The diagrams are realized with the specification of UML version 1.4. According to UML definitions Use Case diagrams identify the

22、 functionality provided by the system (use cases), the users who interact with the system (actors), and the association between users and functionality. Normally Use Cases are used in the analysis phase of software development to articulate the high-level requirements of the system. The primary goal

23、s of a Use Case diagram include: Providing a high-level view of what the system does Identifying the users (actors) of the system Within this document, a Use Case diagram is used to apply the permutation of the requirements into specific scenarios. The following UML elements are used: Process Owner

24、/ActorReference toa Use CaseUse Caseout of currentproject scopeDomain /SystemKey domain of scenarioinclude(case A includescase B mandatory)A Bextend(case B may extendcase A)A B(case A is a subtypeof case B)A BUse CaseUse Caserelevant forinterfacingFigure 1 Used UML elements The UML Use Case diagram

25、describes the dependencies which can occur between identified use cases and involved participants (actors) within the environment of a specific system or domain. The diagram differs between in four types of use case representations: 1) use cases 2) references to a use (further detailed descriptions)

26、 3) use cases which are relevant within this specific domain but not relevant for the project 4) use cases which are relevant for data exchange and interfacing (Within the use case description a combination of use case representation is possible) prEN 9300-004:20056 The dependencies between the use

27、cases are described by different line style of arrows. Dashed line arrows describe the relationships between the use cases (include or extend). Solid line arrows describe the inheritance between the use cases, solid lines describe the interaction between actors and use cases. Figure 2 gives an examp

28、le. Archiving SystemProducerStart ArchivingProcessInitialization ofarchivingprocessArchive digitaldocumentsImmediatearchiving atreleaseincludeFigure 2 Example UML Use case diagram The “start archiving process” is triggered by the actor “producer”. The use case includes the use case “initialization o

29、f archiving process”, which inherits all functionalities of the sub cases “immediate archiving at release” and “archive digital documents”. Additionally “Archive digital documents” indicates a use case which is relevant for data exchange between two systems via an interface. 6 Method for process des

30、cription: Simplified activity diagram The detailed description and analysis of scenarios and resulting processes are shown by simplified activity diagrams based on the UML and IDEF0. IDEF0 is a method designed to model the decisions, actions, and activities of an organization or system. IDEF0 was de

31、rived from a well-established graphical language, the Structured Analysis and Design Technique (SADT). IDEF0 models help to organize the analysis of a system and to promote good communication between the analyst and the customer. IDEF0 is useful in establishing the scope of an analysis, especially a

32、 functional analysis. prEN 9300-004:20057 The used elements for the process description are displayed in the following figure. activity (process )role decisiondatasystemmilestoneprocesssupporting processFigure 3 Example of a simplified activity diagram Every process step is started by a milestone. T

33、he use of milestones allows the integration of required references to and from other processes. In this example, the reference “validation properties”, coming from the milestone ”data preparation” displays the input information for process step “manual validation”. The simplified activity diagram id

34、entifies the participating roles via swim lanes. The swim lanes differentiate the various roles (persons) and systems (e.g. CAD system or the archive). The interaction between single activities within the process chain is represented by the data flow. In cases of decisions, the role has the chance t

35、o take corrective action. For single process steps, a supporting process gives further information, e.g. about archiving policies for “generate package information”. To reduce the amount of information within one description level, the simplified activity diagrams are based on a hierarchical structu

36、re, following IDEF0. A shadow behind a process element indicates a further detailed description for this specific process. prEN 9300-004:20058 The hierarchy structure is displayed within the following figure. Figure 4 Hierarchy structure within simplified activity diagrams The simplified activity di

37、agrams will be provided via a HTML Representation. The HTML Representation simplifies the handling, the search for information and the navigation through the process description and is divided into two main windows: Navigation bar Process description window Within the HTML representation of the proc

38、ess description, the different levels are connected via hyperlinks, so that navigation between the detail levels is possible. After a click on a process step the display will change to the next level. The HTML representation offers the possibility of getting detailed information for a single process

39、 step (blue mark in the corner of the process symbol). Further functionalities are print and zoom. prEN 9300-004:20059 The following figure gives an example. navigation barprocess description windowzoom functionsprint functiondetailed definitionFigure 5 HTML Representation of simplified activity dia

40、grams 7 Methods for data description 7.1 General The description of data uses the graphical representation of Express G Diagrams and the definition of rules and constraints via “EXPRESS WHERE Rules”. An overview of the recommended usage of entities and attributes is provided in tabular form (Data di

41、ctionary). For example, ISO 10303 (STEP) AP 214 specifies the recommended archiving data format. 7.2 Express G diagrams An Express G Diagram describes formally the used data elements and their constraints. AECMA-STAN LOTAR uses the EXPRESS-G (ISO 10303-11 version 2) as modelling method. It visualize

42、s the logical context and the relationships between the information objects. EXPRESS-G is not a programming language, instead it is characterized by a specification language whose based on the Entity Relationship Method 2. It is possible to model objects, as well as relationships and constraints bet

43、ween the objects. prEN 9300-004:200510 EXPRESS-G is directly related to the EXPRESS data modelling language. Everything that is drawn in EXPRESS-G can be defined in EXPRESS. However, not everything that can be defined in EXPRESS can be drawn in EXPRESS-G. The following figure provides an overview of

44、 the main Express G syntax and elements. Reference on this pagefrom another pageEXPRESS elementary Data types(NUMBER, REAL, INTEGER,STRING, LOGICAL, BOOLEAN)TYPEchoice = SELECT ()the standardized EXPRESS - G SyntaxprocessSCHEMA processSchemaENTITY foreign_use, defined withinSCHEMA foreign_schema,use

45、d fromInter- Schema- ReferencesReference to another pagePage referencesREALthingsTYPE things =ENUMERATION ()process ENTITY processTYPE what_it_isUser defined typeData typechoicewhat_it_isMandatory AttributeOPTIONAL AttributeAttribute / relationshipforeign_schema.foreign_refpage#, ref# (#,#,)page#, r

46、ef# entity_nameSUBTYPE - relationshipforeign_schema.foreign_useFigure 6 Express G Syntax Elements of the Express G Diagrams are displayed in following Figure 7. The figure describes relationships between the entities person and organization. prEN 9300-004:200511 Figure 7 Example for an Express G Dia

47、gram integrate of complete diagram The entity “person_in_organization” is further described by its relevant attributes. The attributes are: the mandatory attribute “role” the optional attributes “location” and “id” The entity stands in relation to the entity “person” via the mandatory attribute “ass

48、ociated_person” and to “organization” via the mandatory attribute “associated_organization”. The attribute “associated_person” displays an additional capability, INVERSE attributes. INVERSE attributes can be used to describe the cardinality and existence dependencies between entity types. If the inv

49、erse attribute is used, at least one (or more) organization must exist (indicated by S1:?). An instance of entity ”person_in_organization” can be related to another instance of the same type through an instance of entity “person_in_organization_relationship“. Further attributes point at “Person_in_organization”. The reference 128, which is described in detail on page 86, points at “person_in_organization”, indicated through the term: 3,128 (86). SELECT type “person_organization_select” represents the union of entity