ASTM E2145-07(2013)
(Practice)Standard Practice for Information Modeling (Withdrawn 2017)
Standard Practice for Information Modeling (Withdrawn 2017)
SIGNIFICANCE AND USE
5.1 Modeling is increasingly used in business, industry, and commerce to develop a common understanding of processes, functions, activities, and supporting data. Typical users of such models are systems developers, operations researchers and business analysts, educators, and executives.
5.1.1 Information models are regarded widely as beneficial by saving cost through realignment of processes, risk reduction and elimination of redundancy. Information models convey ideas and facilitate the analysis and understanding of complex processes and structures. These models form the basis for software engineering practices that build systems and databases, redefine organizational structures, improve business processes, and develop standards.
5.1.2 This practice provides a practical means for developers and users of information models to employ appropriate modeling methods and to objectively determine model quality.
5.2 Background:
5.2.1 Models are representations of past, existing, or contemplated reality. Models may assist in the explanation or analysis of complex structures and processes that may exceed human capacity for direct visualization or understanding. Models enable a focus on the key elements of a process or structure while ignoring confounding or irrelevant elements. As such, models make an explicit statement of the meaning of the reality being modeled.
5.2.2 Integrated information engineering models provide a coherent view of the processes and data of an organization or enterprise (5). Activity models identify the fundamental tasks performed in a function. Process models accurately describe the detailed collection of these activities within an organization. Data models are derived from and support the functions described in activity models. Object models also characterize the processes and data required to understand business operations. Both structured and object-oriented models may be used to construct information systems that support those bus...
SCOPE
1.1 Information models are increasingly important in the analysis, design, and sharing a common understanding in information engineering, in business process improvement, in building information systems, in developing informatics standards, and in many other uses.2
1.2 The purpose of this practice is to identify best practices for the creation, use, and assessment of various types of information models.
1.3 Included in this practice are recommended organizational policies and procedures, where modeling is best used and recommended modeling methods, best practices and evaluation criteria.
1.4 Excluded from this practice are detailed specifications of modeling techniques that are specified or described in other sources.
WITHDRAWN RATIONALE
Formerly under the jurisdiction of Committee E31 on Healthcare Informatics, this practice was withdrawn in March 2017. This standard is being withdrawn without replacement due to its limited use by industry.
General Information
Relations
Standards Content (Sample)
NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
Designation: E2145 − 07 (Reapproved 2013) An American National Standard
Standard Practice for
Information Modeling
This standard is issued under the fixed designation E2145; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope* ISO/IEC 19501:2005 Information technology—Open Dis-
tributed Processing—Unified Modeling Language (UML)
1.1 Information models are increasingly important in the
Version 1.4.2
analysis, design, and sharing a common understanding in
ISO/IEC 2382 Information Processing Systems—
information engineering, in business process improvement, in
Vocabulary
building information systems, in developing informatics
2.3 Other Documents and Standards:
standards, and in many other uses.
Unified Modeling Language Specification version 1.5,
1.2 The purpose of this practice is to identify best practices
March 2003
for the creation, use, and assessment of various types of
information models. 3. Terminology
1.3 Included in this practice are recommended organiza- 3.1 The following sections present terms, definitions, and
tional policies and procedures, where modeling is best used acronyms found in this practice and in various modeling
andrecommendedmodelingmethods,bestpracticesandevalu- activities.Thesetermsanddefinitionsarereferencedorderived
ation criteria. from ANSI X3.172 or ISO/IEC 2382 unless otherwise cited.
1.4 Excluded from this practice are detailed specifications 3.2 Definitions:
of modeling techniques that are specified or described in other 3.2.1 activity, n—a group of logically related tasks per-
sources. formed for a purpose.
3.2.2 alternate key attribute, n—inalogicaldatamodel,any
2. Referenced Documents
candidate key of an entity other than the primary key.
2.1 ANSI Standards:
3.2.3 application model, n—a representation or description
ANSI X3.172-1990 Dictionary for Information Systems
of the application software, programs, or components needed
IEEE 1320.1-1998 Standard for Functional Modeling
to support a business function.
Language—Syntax and Semantics for IDEF0
3.2.4 attribute, n—a characteristic of an object or entity (see
IEEE 1320.2-1998 Standard for Functional Modeling
ISO/IEC 11179).
Language—Syntax and Semantics for IDEF1X (Object
3.2.5 attribute value, n—a representation of an instance of
97)
3 an attribute (see ISO/IEC 11179).
2.2 ISO Standards:
3.2.6 behavior, n—in the object-oriented methodology, be-
ISO 8601-88 Data Elements and Interchange Formats—
havior constitutes the observable effects of an operation or
Representation of Dates and Times
event, including any results generated or obtained; and repre-
ISO/IEC 1087 Terminology Work—Vocabulary-Part 1:
sented by operations, methods, and state machines (see UML
Theory and Application
1.5).
ISO/IEC11179 InformationTechnology—Specificationand
Standardization of Data Elements, Parts 1-6
3.2.7 business model, n—a representation of the strategy,
situation, environment, objectives, direction, and similar char-
acteristics of a business enterprise or business area.
This practice is under the jurisdiction ofASTM Committee E31 on Healthcare
3.2.8 business process model, n—a representation of busi-
Informatics and is the direct responsibility of Subcommittee E31.25 on Healthcare
Data Management, Security, Confidentiality, and Privacy.
ness processes, often where these processes are successively
Current edition approved March 1, 2013. Published March 2013. Originally
decomposed to describe component activities, to identify the
approved in 2001. Last previous edition approved in 2007 as E2145 – 07. DOI:
events to which the business shall respond, and to identify the
10.1520/E2145-07R13.
An information model in the context of this standard is any representation of results produced.
process, data, etc., used in any aspect of information technology or information
management.
3 4
Available fromAmerican National Standards Institute (ANSI), 25 W. 43rd St., Available from Object Management Group. OMG Headquarters, 250 First
4th Floor, New York, NY 10036, http://www.ansi.org. Avenue, Needham, MA 02494. http://www.omg.org.
*A Summary of Changes section appears at the end of this standard
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
E2145 − 07 (2013)
3.2.9 column, n—a physical data model and relational data- 3.2.24 function, n—an activity, process or transformation
base structure that is analogous to the attribute of a logical data identified by a verb that describes that which would be
model. accomplished.
3.2.10 concept, n—a unit of thought constituted through
3.2.25 independent entity, n—in a logical data model, an
abstraction on the basis of characteristics common to a set of
entity that does not inherit identifying attributes from another
objects (see ISO/IEC 1087).
entity.
3.2.11 conceptual model, n—an abstract representation of
3.2.26 inheritance, v—the transmission of characteristics
any type of model used to identify the principal components
fromaparentprocess,entity,orobjecttoitschildren(seeUML
and relationships of the subject of the model, and avoiding
1.4).
unnecessary or confounding detail.
3.2.27 internal schema, n—a schema of the ANSI Three
3.2.12 context, n—a designation or description of the appli-
Schema architecture in which views of the information are
cation environment or discipline in which a name is applied or
representations of data structure at the system architecture data
from which it originates (see ISO/IEC 11179).
layer.
3.2.13 data, n—a representation of facts, concepts, or in-
3.2.28 key attribute, n—in a logical data model, an attribute
structions in a formalized manner, suitable for communication,
used to identify an instance of an entity.
interpretation, or processing by humans or automatic means
3.2.29 key inheritance, v—the transmission of a key attri-
(see ISO/IEC 11179).
butefromaparentorindependententitytoachildordependent
3.2.14 data dictionary, n—a database used for data that
entity.
refers to the use and structure of other data; that is, a database
3.2.30 lexical, n—pertainingtowordsorthevocabularyofa
for the storage of metadata (see ANSI X3.172-1990).
language as distinguished from its grammar and construction
3.2.15 data element, n—a unit of data for which the
(see ISO/IEC 11179).
definition, identification, representation and permissible values
3.2.31 location model, n—a representation or description of
are specified by means of a set of attributes (see ISO/IEC
the components and interrelationships of a real or virtual
11179).
location.
3.2.16 data model, n—a description of the organization of
3.2.32 logical model, n—an expansion of a conceptual
data in a manner that reflects an information structure (see
model, or a derivation from a physical model, that provides a
ISO/IEC 11179).
level of detail sufficient to design or effect a business solution.
3.2.17 data steward, n—a person or organization delegated
3.2.33 metadata, n—data that describes other data (see
the responsibility for managing a specific set of data resources,
ISO/IEC 11179).
(see ISO/IEC 11179).
3.2.34 model, n—arepresentationinwhateverformofareal
3.2.18 dependent entity, n—in a logical data model, an
or envisioned object, action, or process.
entity that inherits one or more identifying attributes from
another entity.
3.2.35 modeling, v—the process of creating, revising, docu-
3.2.19 domain, n—the set of possible data values of an menting and presenting a model.
attribute (see ISO/IEC 2382); also the identification, descrip-
3.2.36 model view, n—a collection of models pertaining to a
tion or scope of a segment of industry or commerce, or of a
particular domain and from the perspective of a particular
program, project, or problem.
individual’s role or viewpoint.
3.2.20 encapsulation, v—the packaging of an object’s data
3.2.37 non-key attribute, n—in a logical data model, an
with its corresponding methods with access via a controlled
attribute that is not the primary or part of a composite primary
messaging interface (see UML 1.4).
key of an entity.
3.2.21 entity, n—any concrete or abstract thing of interest,
3.2.38 object, n—any part of a conceivable or perceivable
including associations among things (see ISO/IEC 2382).
world (see ISO 1087).
3.2.22 external schema, n—an external schema is the rep-
3.2.39 object class, n—a set of objects, ideas, abstractions,
resentation of data at the system architecture presentation layer
or things in the real world that can be identified with explicit
as viewed by the user when interacting or communicating with
boundaries and meaning and whose properties and behavior
the information system.
follow the same rules (see ISO/IEC 11179).
3.2.23 foreign key attribute, n—in a logical data model, an
3.2.40 object-oriented methodology, n—any of the formal
attribute or combination of attributes of a child or category
modeling methods or techniques that employ objects to de-
entity whose values match those in a primary key of a related
scribe data and the methods or processes acting on those data
or generic entity instance.
as a single unit for analysis, design, or development (see UML
1.5, ISO/IEC 11179).
3.2.41 organizational model, n—arepresentationordescrip-
ANSI Standards Planning and Requirements Committee—a layered model of
tion of the components and interrelationships of an organiza-
database architecture comprising a physical schema, a conceptual schema, and user
views. tion or organizational component.
E2145 − 07 (2013)
3.2.42 physical model, n—a derivation from a logical 3.3.17 RDB—Relational Database
model, or a physical implementation, providing a highly
3.3.18 RDBMS—Relational Database Management System
detailed definition of the solution needed to carry out the
3.3.19 SADT—Structured Analysis and Design Technique
activities in business area.
3.3.20 SML—Standardized Modeling Language
3.2.43 primary key attribute, n—in a logical data model, the
3.3.21 SQL—Structured Query Language
candidate key selected as the unique identifier of an entity.
3.3.22 SSADM—Structured Systems Analysis and Design
3.2.44 property, n—a peculiarity common to all members of
Methodology
an object class (see ISO/IEC 11179).
3.3.23 UML—Unified Modeling Language
3.2.45 relational data methodology, n—any of several mod-
eling and information management methods and techniques
4. Summary of Practice
that employ structured relationships among entities or tables.
4.1 This practice describes policies and procedures, best
3.2.46 row, n—aphysicaldatamodelandrelationaldatabase
practices for the creation, use, and assessment of information
structure that contains a single instance of data in a table.
models.
3.2.47 structured analysis and design, n— any formalized
4.2 The foundation for these information modeling best
methodology for the analysis, design, development or lifecycle
practices is derived from Donnabedian’s structure, process and
management of information systems where processes and data
outcome quality constructs (1).
are initially treated individually and subsequently integrated in
4.2.1 Structure—Structure constructs identify or describe
a system architecture.
the organization component where modeling activities occur,
3.2.48 subject area, n—a subject area is a portion of an
the composition of the modeling method or tool, its language
entiredatamodelwhichiscreatedtofacilitateunderstandingof
and syntax, and the resources allocated to perform modeling
a specific functional area or component task.
processes, for example human resources, technology, materiel,
3.2.49 table, n—a physical data model and relational data-
etc.
base structure that is analogous to the entity of a data model.
4.2.2 Process—Process constructs identify or describe the
3.2.50 technology model, n—a representation or description appropriate use of modeling, the effective use of modeling
of the hardware, system software, and network components methods, and the correct employment of the modeling tech-
needed to support the business area. nique.
4.2.3 Outcome—A quality information model that provides
3.2.51 view, n—a collection SQL queries stored in a rela-
a meaningful and usable representation of past, present, or
tional database under assigned names and represented as a
future reality, and can be assessed by five dimensions (2) of
temporary or virtual table that does not permanently store the
model quality:
data it presents.
4.2.3.1 Conceptual Correctness—The model accurately re-
3.3 Acronyms:
flects functional or business concepts where all models are
3.3.1 ANSI—American National Standards Institute
representations of real or envisioned objects or concepts. The
3.3.2 ASTM—American Society for Testing and Materials
model shall accurately describe the intended structures or
processes or both.
3.3.3 CORBA—Common Object Request Broker Architec-
4.2.3.2 Conceptual Completeness—The model contains suf-
ture
ficient objects to describe the full scope of the functional or
3.3.4 CRC—Class, Responsibility and Collaboration Ap-
business domain under consideration. The model describes the
proach
full scope or an element of the structures or processes of a
3.3.5 DFD—Data Flow Diagram
concept or both.
3.3.6 ICOM—Input, Control, Output and Mechanisms as 4.2.3.3 Syntactic Correctness—The objects in the model do
used in IDEF activity modeling not violate syntactic rules of the modeling language. Each
modeling method has a predefined language typically consist-
3.3.7 IDEF—Integrated Definition Language
ing of visual structures and symbols where these structures and
3.3.8 IDEF0—The IDEF activity modeling language
symbols are assembled and interpreted according to a clearly
3.3.9 IDEF1X—The IDEF data modeling language
defined and unambiguous set of rules. These rules shall be
widely recognized in the industry and preferably be standard-
3.3.10 IDO—Integrated Delivery Organization
ized (3). The modeling methodology and processes shall
3.3.11 IE—Information Engineering diagramming method-
adhere to these rules.The model shall effectively communicate
ologies
its representations and descriptions to anyone who understands
3.3.12 IEC—International Electrotechnical Commission
the modeling method and syntax.
3.3.13 ISA—Information Systems Architecture
4.2.3.4 Syntactic Completeness—All essential functional or
business concepts are captured at appropriate points in the
3.3.14 ISO—International Organization for Standardization
3.3.15 NIST—National Institute of Standards and Technol-
ogy
The boldface n
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.