Причина отмены 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. Значение и использование

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 business operations. Application models describe in varying levels of detail, the overall architecture and components of the software needed to support the envisioned business functions. Organizational models reflect the current and envisioned future state of the organization, especially as this impacts business processes enabled or supported by information systems. Location models identify and describe the business and geographic position and relationships of structural components of an organizational entity. Technology models describe in varying levels of detail those hardware, system software, and network components needed to operate the information systems supporting a business area.

Models may be textual, graphic, or mixed graphic and text forms, including, tables and structured lists, flowcharts, process flow diagrams, state diagrams, data flow diagrams, entity-relationship diagrams, and related techniques develop an understanding of business processes and the transformation of data through these processes (6). Modeling products may also relate two or more types of models, such as for an Application-Data Matrix, or Technology-Location Plan.

5.3 Framework for Relating Models to Systems:

5.3.1 Since proposed by Zachman in 1987 (3), the Information System Architecture (ISA) has become one of several means to view and to blueprint information systems within an entire organization, to design business processes and change enterprise strategies, and to describe and interrelate the components of an information system to the entire organization. The cells within the framework represent primitive architectural constructs where the sets of columns collectively represent a consistent integrated model for each perspective (row). These rows describe different types of artifacts, each having a different purpose:

5.3.1.1 Row 1—artifacts define the scope as boundaries of the enterprise.

5.3.1.2 Row 2—artifacts define the conceptual design as envisioned by the enterprise “owners” or stakeholders.

5.3.1.3 Row 3—artifacts present a logical design, how the enterprise concepts will be realized independent of technology.

5.3.1.4 Row 4—artifacts describe the physical design, how the enterprise implementation is generally constrained by technology.

5.3.1.5 Row 5—artifacts specify the physical implementation as a specific application of technology.

5.4 Principles and Approaches to Modeling:

5.4.1 Modeling activities have been prevalent throughout the history of the engineering disciplines. This rich history indicates four basic principles (7):

5.4.1.1 The choice of what models to create has a profound influence on how a problem is approached and how a solution is shaped.

5.4.1.2 Every model may be expressed at different levels of precision.

5.4.1.3 The best models are connected to past, current, or envisioned future reality.

5.4.1.4 No single model is sufficient; every nontrivial system is best approached through a small set of nearly independent models.

5.4.2 The three approaches to information modeling are characterized as top-down, bottom-up, and inside-out (8). Of these, the top-down and bottom-up approaches are most often used.

5.4.2.1 The “top-down” approach follows a progression of activities that first analyzes and understands functionality of the domain-of-interest and only then progresses to model preparation. The top-down paradigm typically consists of preparing a high level or conceptual model followed successively by logical and physical models in increasing levels of detail. The strength of this approach is it provides a broadly-based and comprehensive set of rationally derived models that are generally appropriate across the spectrum of functional or business activities. This paradigm saves time, conserves resources, and reduces risk over the long-term course of system development.

The “bottom-up” approach reflects the experience of subject matter experts in one or more specialized subdomains. These panels of experts prepare small models that are subsequently integrated. The strength of this approach is that it addresses detail that can be easily converted to a specific application, and may be tuned or optimized for a small and contained segment of the business environment. Often, it is used when the entire domain is not well understood or in the absence of a business model foundation. The bottom-up paradigm solves small problems quickly. It produces narrowly focused model components requiring extensive effort for subsequent integration into systems with a broader scope or enterprise solutions.

5.5 Use of Modeling Techniques for Content—The complexity and extensiveness of business processes, the information used in these processes, and the information systems supporting these processes inhibit or prevent a comprehensive understanding to the depth of detail frequently required. Formal methods are needed to facilitate the development and sharing of a common understanding about information, the processing of that information, and the systems supporting those processes.

5.6 Use of Models for System Engineering :

5.6.1 System engineering is considered in all leading system lifecycle methodologies as a sequential, cyclic, or iterative sequence of four essential activities from a visionary or inception activity to deployment or implementation (9) as illustrated in Fig. 1. Performance and outcome of these activities can be substantially improved through modeling. For example, system development models may consist of elementary structures like an organizational chart to detailed structural representation of a software package. Models typically are employed in the planning and analysis phase of software development, in system and software design, and in the coding process.

FIG. 1 Typical System Life Cycle Phases

5.6.1.1 Booch, et al (7) , state that the single fundamental reason for modeling a system is to better understand the system being developed, achieving four aims:

(1) To visualize an existing or desired system;(2) To specify the structure and behavior of a system;(3) To provide a guiding template for system construction; and(4) To document the decisions made in system development.

5.6.1.2 Pressman notes three additional reasons for modeling (10) in system development:

(1) The business problem and solution can be approached incrementally, thus reducing the probability that a major feature will be misinterpreted or overlooked; (2) The customer or user can more easily review the analysis and design, to help preclude or eliminate areas of ambiguity and misunderstanding; and (3) The development proceeds in a logical, efficient and more readily manageable manner through the migration of models from analysis through design and development.

Most importantly, models greatly enhance quality, reduce risk, and multiply capability in system development. Models enable the developer to proactively build-in quality during design rather than reactively assess quality during development. As models are transformed from analysis through physical software, sets of quality criteria can be created for each modeling step. As the models are reviewed against these criteria incrementally risk of failure decreases. Errors in requirements definition, design, and development can be uncovered easily and corrected at the earliest possible time with less effort and delay than if corrected during module or integration testing. Use of modeling tools, as in model-driven design and development, greatly magnifies the productivity of individual designers and developers.

5.6.2 Modeling in Systems Inception—Analytical models are essential to the systems inception and planning. In the inception phase, models help develop the business rationale and communicate this rationale in the system business case. Semantic and diagrammatic models help explain the thought processes leading to a system proposal. Activity models are useful to design future business activities and business process improvement. Financial models and simulations are important components of the business case and risk prediction (11) , and for software engineering project management (12, 13), and estimation (14).

5.6.3 Modeling in Systems Elaboration—The elaboration phase of the systems development paradigm includes analysis and high level design. Models are essential to system elaboration by analyzing, recording, and detailing business process and system functionality. Typical examples of analytical and high level design models include business process flow diagrams, conceptual entity models, conceptual technology models, etc.

5.6.4 Migration of Models in System Construction—A software engineering methodology provides development paradigms as a procedural framework for the design, construction, testing and implementation of systems. Within a development methodology, modeling methods prescribe the symbology and heuristics used to create models of varying levels of detail. Automation, via computer-assisted software engineering (CASE) tools, facilitates the modeling process and provides the vehicle that achieves transformability. The transformation from analysis to a functioning system is termed forward engineering while transformation from a functioning system to analytical or design models is termed reverse engineering.

The benefit of using standardized modeling methods is the software models that are created are easily understandable and readily transformable to a functioning system (10). As illustrated in Fig. 2, models follow a logical progression from Conceptual to Logical to Physical (8, 15) . Fig. 2 also illustrates the relationship between system lifecycle phases and Zachman Framework, along with representative types of business process and data models. This cascade of models facilitates the understanding of concepts and the implementation of information applications, databases or systems.

FIG. 2 Migration of Models in System Development

The systems development process originates with either an existing system in need of improvement or a vision of a new or reengineered system. The chain of models begins with conceptual modeling where activities and data are modeled at a high level of detail.

5.6.5 Organizational Issues—The structure and process elements of the model quality paradigm involve the creation and maintenance of an environment and procedures that facilitates creation, evaluation, communication, and utilization of information models. For the system development organization there should be a component responsible for the creation and maintenance of models. The organization should establish policies for modeling and standardize the model development process, methodologies, and tool sets. These policies constitute internal, or organizational standards or conventions, consisting of the following:

5.6.5.1 Syntactic Conventions—The library of model symbols to be employed;

5.6.5.2 Positional Conventions—The manner in which symbols are displayed or presented in the model; and

5.6.5.3 Semantic Conventions—The grouping of model components according to meaning.

5.6.5.4 The organization should provide a battery of standardized modeling methods from which the software developers can select as appropriate to the needs of a specific development project.

5.7 Using Models for Standards Development:

5.7.1 Organizations may develop their own internal standards, such as standard operating procedures, or they may develop standards for use by the public, an industry or professional community, or other group of consumers. Modeling facilitates the development, communication and understanding of both internal and industry-wide standards. Developers of internal and external standards may use models to prepare and present a common reference to their work. Furthermore, consumers may find models facilitate the implementation and use of standards by their organizations by providing standards users a blueprint from which they can tailor and optimize model components for implementation. Here adherence to the structure, process, and outcome quality requirements shall be especially rigorous since the models produced provide the foundation for standards that may have substantial industry impact.

Область применения

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.²

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.