View model

Last updated
The TEAF Matrix of Views and Perspectives. TEAF Matrix of Views and Perspectives.svg
The TEAF Matrix of Views and Perspectives.

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns. [1] [2]

Contents

Since the early 1990s there have been a number of efforts to prescribe approaches for describing and analyzing system architectures. A result of these efforts have been to define a set of views (or viewpoints). They are sometimes referred to as architecture frameworks or enterprise architecture frameworks, but are usually called "view models".

Usually a view is a work product that presents specific architecture data for a given system. However, the same term is sometimes used to refer to a view definition, including the particular viewpoint and the corresponding guidance that defines each concrete view. The term view model is related to view definitions.

Overview

The purpose of views and viewpoints is to enable humans to comprehend very complex systems, to organize the elements of the problem and the solution around domains of expertise and to separate concerns. In the engineering of physically intensive systems, viewpoints often correspond to capabilities and responsibilities within the engineering organization. [3]

Most complex system specifications are so extensive that no single individual can fully comprehend all aspects of the specifications. Furthermore, we all have different interests in a given system and different reasons for examining the system's specifications. A business executive will ask different questions of a system make-up than would a system implementer. The concept of viewpoints framework, therefore, is to provide separate viewpoints into the specification of a given complex system in order to facilitate communication with the stakeholders. Each viewpoint satisfies an audience with interest in a particular set of aspects of the system. Each viewpoint may use a specific viewpoint language that optimizes the vocabulary and presentation for the audience of that viewpoint. Viewpoint modeling has become an effective approach for dealing with the inherent complexity of large distributed systems.

Architecture description practices, as described in IEEE Std 1471-2000, utilize multiple views to address several areas of concerns, each one focusing on a specific aspect of the system. Examples of architecture frameworks using multiple views include Kruchten's "4+1" view model, the Zachman Framework, TOGAF, DoDAF, and RM-ODP.

History

In the 1970s, methods began to appear in software engineering for modeling with multiple views. Douglas T. Ross and K.E. Schoman in 1977 introduce the constructs context, viewpoint, and vantage point to organize the modeling process in systems requirements definition. [4] According to Ross and Schoman, a viewpoint "makes clear what aspects are considered relevant to achieving ... the overall purpose [of the model]" and determines How do we look at [a subject being modelled]?

As examples of viewpoints, the paper offers: Technical, Operational and Economic viewpoints. In 1992, Anthony Finkelstein and others published a very important paper on viewpoints. [5] In that work: "A viewpoint can be thought of as a combination of the idea of an “actor”, “knowledge source”, “role” or “agent” in the development process and the idea of a “view” or “perspective” which an actor maintains." An important idea in this paper was to distinguish "a representation style, the scheme and notation by which the viewpoint expresses what it can see" and "a specification, the statements expressed in the viewpoint's style describing particular domains". Subsequent work, such as IEEE 1471, preserved this distinction by utilizing two separate terms: viewpoint and view, respectively.

Since the early 1990s there have been a number of efforts to codify approaches for describing and analyzing system architectures. These are often termed architecture frameworks or sometimes viewpoint sets. Many of these have been funded by the United States Department of Defense, but some have sprung from international or national efforts in ISO or the IEEE. Among these, the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE Std 1471-2000) established useful definitions of view, viewpoint, stakeholder and concern and guidelines for documenting a system architecture through the use of multiple views by applying viewpoints to address stakeholder concerns. [6] The advantage of multiple views is that hidden requirements and stakeholder disagreements can be discovered more readily. However, studies show that in practice, the added complexity of reconciling multiple views can undermine this advantage. [7]

IEEE 1471 (now ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description) prescribes the contents of architecture descriptions and describes their creation and use under a number of scenarios, including precedented and unprecedented design, evolutionary design, and capture of design of existing systems. In all of these scenarios the overall process is the same: identify stakeholders, elicit concerns, identify a set of viewpoints to be used, and then apply these viewpoint specifications to develop the set of views relevant to the system of interest. Rather than define a particular set of viewpoints, the standard provides uniform mechanisms and requirements for architects and organizations to define their own viewpoints. In 1996 the ISO Reference Model for Open Distributed Processing (RM-ODP) was published to provide a useful framework for describing the architecture and design of large-scale distributed systems.

View model topics

View

A view of a system is a representation of the system from the perspective of a viewpoint. This viewpoint on a system involves a perspective focusing on specific concerns regarding the system, which suppresses details to provide a simplified model having only those elements related to the concerns of the viewpoint. For example, a security viewpoint focuses on security concerns and a security viewpoint model contains those elements that are related to security from a more general model of a system. [8]

A view allows a user to examine a portion of a particular interest area. For example, an Information View may present all functions, organizations, technology, etc. that use a particular piece of information, while the Organizational View may present all functions, technology, and information of concern to a particular organization. In the Zachman Framework views comprise a group of work products whose development requires a particular analytical and technical expertise because they focus on either the “what,” “how,” “who,” “where,” “when,” or “why” of the enterprise. For example, Functional View work products answer the question “how is the mission carried out?” They are most easily developed by experts in functional decomposition using process and activity modeling. They show the enterprise from the point of view of functions. They also may show organizational and information components, but only as they relate to functions. [9]

Viewpoints

In systems engineering, a viewpoint is a partitioning or restriction of concerns in a system. Adoption of a viewpoint is usable so that issues in those aspects can be addressed separately. A good selection of viewpoints also partitions the design of the system into specific areas of expertise. [3]

Viewpoints provide the conventions, rules, and languages for constructing, presenting and analysing views. In ISO/IEC 42010:2007 (IEEE-Std-1471-2000) a viewpoint is a specification for an individual view. A view is a representation of a whole system from the perspective of a viewpoint. A view may consist of one or more architectural models. [10] Each such architectural model is developed using the methods established by its associated architectural system, as well as for the system as a whole. [6]

Modeling perspectives

Modeling perspectives is a set of different ways to represent pre-selected aspects of a system. Each perspective has a different focus, conceptualization, dedication and visualization of what the model is representing.

In information systems, the traditional way to divide modeling perspectives is to distinguish the structural, functional and behavioral/processual perspectives. This together with rule, object, communication and actor and role perspectives is one way of classifying modeling approaches [11]

Viewpoint model

In any given viewpoint, it is possible to make a model of the system that contains only the objects that are visible from that viewpoint, but also captures all of the objects, relationships and constraints that are present in the system and relevant to that viewpoint. Such a model is said to be a viewpoint model, or a view of the system from that viewpoint. [3]

A given view is a specification for the system at a particular level of abstraction from a given viewpoint. Different levels of abstraction contain different levels of detail. Higher-level views allow the engineer to fashion and comprehend the whole design and identify and resolve problems in the large. Lower-level views allow the engineer to concentrate on a part of the design and develop the detailed specifications. [3]

Illustration of the views, products and data in Architecture Framework. ArchitectureFrameworkStructure.png
Illustration of the views, products and data in Architecture Framework.

In the system itself, however, all of the specifications appearing in the various viewpoint models must be addressed in the realized components of the system. And the specifications for any given component may be drawn from many different viewpoints. On the other hand, the specifications induced by the distribution of functions over specific components and component interactions will typically reflect a different partitioning of concerns than that reflected in the original viewpoints. Thus additional viewpoints, addressing the concerns of the individual components and the bottom-up synthesis of the system, may also be useful. [3]

Architecture description

An architecture description is a representation of a system architecture, at any time, in terms of its component parts, how those parts function, the rules and constraints under which those parts function, and how those parts relate to each other and to the environment. In an architecture description the architecture data is shared across several views and products.

At the data layer are the architecture data elements and their defining attributes and relationships. At the presentation layer are the products and views that support a visual means to communicate and understand the purpose of the architecture, what it describes, and the various architectural analyses performed. Products provide a way for visualizing architecture data as graphical, tabular, or textual representations. Views provide the ability to visualize architecture data that stem across products, logically organizing the data for a specific or holistic perspective of the architecture.

Types of system view models

Three-schema approach

The notion of a three-schema model was first introduced in 1977 by the ANSI/X3/SPARC three-level architecture, which determined three levels to model data. 4-2 ANSI-SPARC three level architecture.svg
The notion of a three-schema model was first introduced in 1977 by the ANSI/X3/SPARC three-level architecture, which determined three levels to model data.

The Three-schema approach for data modeling, introduced in 1977, can be considered one of the first view models. It is an approach to building information systems and systems information management, that promotes the conceptual model as the key to achieving data integration. [13] The Three schema approach defines three schemas and views:

At the center, the conceptual schema defines the ontology of the concepts as the users think of them and talk about them. The physical schema describes the internal formats of the data stored in the database, and the external schema defines the view of the data presented to the application programs. [14] The framework attempted to permit multiple data models to be used for external schemata. [15]

Over the years, the skill and interest in building information systems has grown tremendously. However, for the most part, the traditional approach to building systems has only focused on defining data from two distinct views, the "user view" and the "computer view". From the user view, which will be referred to as the “external schema,” the definition of data is in the context of reports and screens designed to aid individuals in doing their specific jobs. The required structure of data from a usage view changes with the business environment and the individual preferences of the user. From the computer view, which will be referred to as the “internal schema,” data is defined in terms of file structures for storage and retrieval. The required structure of data for computer storage depends upon the specific computer technology employed and the need for efficient processing of data. [16]

4+1 view model of architecture

Illustration of the 4+1 view model or architecture. 4+1 Architectural View Model.svg
Illustration of the 4+1 view model or architecture.

4+1 is a view model designed by Philippe Kruchten in 1995 for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. [17] The views are used to describe the system in the viewpoint of different stakeholders, such as end-users, developers and project managers. The four views of the model are logical, development, process and physical view:

The four views of the model are concerned with :

In addition selected use cases or scenarios are utilized to illustrate the architecture. Hence the model contains 4+1 views. [17]

Types of enterprise architecture views

Enterprise architecture framework defines how to organize the structure and views associated with an enterprise architecture. Because the discipline of Enterprise Architecture and Engineering is so broad, and because enterprises can be large and complex, the models associated with the discipline also tend to be large and complex. To manage this scale and complexity, an Architecture Framework provides tools and methods that can bring the task into focus and allow valuable artifacts to be produced when they are most needed.

Architecture Frameworks are commonly used in Information technology and Information system governance. An organization may wish to mandate that certain models be produced before a system design can be approved. Similarly, they may wish to specify certain views be used in the documentation of procured systems - the U.S. Department of Defense stipulates that specific DoDAF views be provided by equipment suppliers for capital project above a certain value.

Zachman Framework

Simplified illustration of the Zachman Framework with an explanation of the rows. The original framework is more advanced, see for an example here. Simplification Zachman Enterprise Framework.jpg
Simplified illustration of the Zachman Framework with an explanation of the rows. The original framework is more advanced, see for an example here.

The Zachman Framework, originally conceived by John Zachman at IBM in 1987, is a framework for enterprise architecture, which provides a formal and highly structured way of viewing and defining an enterprise.

The Framework is used for organizing architectural "artifacts" in a way that takes into account both who the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality) is being addressed. These artifacts may include design documents, specifications, and models. [19]

The Zachman Framework is often referenced as a standard approach for expressing the basic elements of enterprise architecture. The Zachman Framework has been recognized by the U.S. Federal Government as having "... received worldwide acceptance as an integrated framework for managing change in enterprises and the systems that support them." [20]

RM-ODP views

The RM-ODP view model, which provides five generic and complementary viewpoints on the system and its environment. RM-ODP viewpoints.jpg
The RM-ODP view model, which provides five generic and complementary viewpoints on the system and its environment.

The International Organization for Standardization (ISO) Reference Model for Open Distributed Processing (RM-ODP) [21] specifies a set of viewpoints for partitioning the design of a distributed software/hardware system. Since most integration problems arise in the design of such systems or in very analogous situations, these viewpoints may prove useful in separating integration concerns. The RMODP viewpoints are: [3]

RMODP further defines a requirement for a design to contain specifications of consistency between viewpoints, including: [3]

DoDAF views

The Department of Defense Architecture Framework (DoDAF) defines a standard way to organize an enterprise architecture (EA) or systems architecture into complementary and consistent views. It is especially suited to large systems with complex integration and interoperability challenges, and is apparently unique in its use of "operational views" detailing the external customer's operating domain in which the developing system will operate.

DoDAF linkages among views. DoDAF Linkages Among Views.jpg
DoDAF linkages among views.

The DoDAF defines a set of products that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through graphic, tabular, or textual means. These products are organized under four views:

Each view depicts certain perspectives of an architecture as described below. Only a subset of the full DoDAF viewset is usually created for each system development. The figure represents the information that links the operational view, systems and services view, and technical standards view. The three views and their interrelationships driven – by common architecture data elements – provide the basis for deriving measures such as interoperability or performance, and for measuring the impact of the values of these metrics on operational mission and task effectiveness. [22]

Federal Enterprise Architecture views

In the US Federal Enterprise Architecture enterprise, segment, and solution architecture provide different business perspectives by varying the level of detail and addressing related but distinct concerns. Just as enterprises are themselves hierarchically organized, so are the different views provided by each type of architecture. The Federal Enterprise Architecture Practice Guidance (2006) has defined three types of architecture: [23]

Federal Enterprise Architecture levels and attributes Architectural Levels and Attributes.jpg
Federal Enterprise Architecture levels and attributes

By definition, Enterprise Architecture (EA) is fundamentally concerned with identifying common or shared assets – whether they are strategies, business processes, investments, data, systems, or technologies. EA is driven by strategy; it helps an agency identify whether its resources are properly aligned to the agency mission and strategic goals and objectives. From an investment perspective, EA is used to drive decisions about the IT investment portfolio as a whole. Consequently, the primary stakeholders of the EA are the senior managers and executives tasked with ensuring the agency fulfills its mission as effectively and efficiently as possible. [23]

By contrast, segment architecture defines a simple roadmap for a core mission area, business service, or enterprise service. Segment architecture is driven by business management and delivers products that improve the delivery of services to citizens and agency staff. From an investment perspective, segment architecture drives decisions for a business case or group of business cases supporting a core mission area or common or shared service. The primary stakeholders for segment architecture are business owners and managers. Segment architecture is related to EA through three principles: structure, reuse, and alignment. First, segment architecture inherits the framework used by the EA, although it may be extended and specialized to meet the specific needs of a core mission area or common or shared service. Second, segment architecture reuses important assets defined at the enterprise level including: data; common business processes and investments; and applications and technologies. Third, segment architecture aligns with elements defined at the enterprise level, such as business strategies, mandates, standards, and performance measures. [23]

Nominal set of views

In search of "Framework for Modeling Space Systems Architectures" Peter Shames and Joseph Skipper (2006) defined a "nominal set of views", [6] Derived from CCSDS RASDS, RM-ODP, ISO 10746 and compliant with IEEE 1471.

Illustration of the "Nominal set of views". Nominal set of views.jpg
Illustration of the "Nominal set of views".

This "set of views", as described below, is a listing of possible modeling viewpoints. Not all of these views may be used for any one project and other views may be defined as necessary. Note that for some analyses elements from multiple viewpoints may be combined into a new view, possibly using a layered representation.

In a latter presentation this nominal set of views was presented as an Extended RASDS Semantic Information Model Derivation. [24] Hereby RASDS stands for Reference Architecture for Space Data Systems. see second image.

Enterprise Viewpoint [6]
Information viewpoint [6]
Reference Architecture for Space Data Systems. Reference Architecture for Space Data Systems.jpg
Reference Architecture for Space Data Systems.
Functional viewpoint [6]
Physical viewpoint [6]
MBED Top Level Ontology based on the Nominal set of views. MBED Top Level Ontology.jpg
MBED Top Level Ontology based on the Nominal set of views.
Engineering viewpoint [6]
Technology viewpoint [6]

In contrast to the previous listed view models, this "nominal set of views" lists a whole range of views, possible to develop powerful and extensible approaches for describing a general class of software intensive system architectures. [6]

See also

Related Research Articles

<span class="mw-page-title-main">Software architecture</span> High level structures of a software system

Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.

<span class="mw-page-title-main">Zachman Framework</span> Structure for enterprise architecture

The Zachman Framework is an enterprise ontology and is a fundamental structure for enterprise architecture which provides a formal and structured way of viewing and defining an enterprise. The ontology is a two dimensional classification schema that reflects the intersection between two historical classifications. The first are primitive interrogatives: What, How, When, Who, Where, and Why. The second is derived from the philosophical concept of reification, the transformation of an abstract idea into an instantiation. The Zachman Framework reification transformations are: identification, definition, representation, specification, configuration and instantiation.

<span class="mw-page-title-main">Business process modeling</span> Activity of representing processes of an enterprise

Business process modeling (BPM) in business process management and systems engineering is the activity of representing processes of an enterprise, so that the current business processes may be analyzed, improved, and automated. BPM is typically performed by business analysts, who provide expertise in the modeling discipline; by subject matter experts, who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both. Alternatively, the process model can be derived directly from events' logs using process mining tools.

Enterprise architecture (EA) is a business function concerned with the structures and behaviours of a business, especially business roles and processes that create and use business data. The international definition according to the Federation of Enterprise Architecture Professional Organizations is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."

<span class="mw-page-title-main">Department of Defense Architecture Framework</span> Enterprise architecture framework

The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal, graphical, probabilistic, or alternative conceptual means. The current release is DoDAF 2.02.

A system architecture is the conceptual model that defines the structure, behavior, and more views of a system. An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structures and behaviors of the system.

The British Ministry of Defence Architecture Framework (MODAF) was an architecture framework which defined a standardised way of conducting enterprise architecture, originally developed by the UK Ministry of Defence. It has since been replaced with the NATO Architecture Framework.

<span class="mw-page-title-main">Enterprise architecture framework</span> Frame in which the architecture of a company is defined

An enterprise architecture framework defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models – typically matrices and diagrams – for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.

IEEE 1471 is a superseded IEEE standard for describing the architecture of a "software-intensive system", also known as software architecture.

<span class="mw-page-title-main">RM-ODP</span> Reference model in computer science

Reference Model of Open Distributed Processing (RM-ODP) is a reference model in computer science, which provides a co-ordinating framework for the standardization of open distributed processing (ODP). It supports distribution, interworking, platform and technology independence, and portability, together with an enterprise architecture framework for the specification of ODP systems.

<span class="mw-page-title-main">Enterprise modelling</span>

Enterprise modelling is the abstract representation, description and definition of the structure, processes, information and resources of an identifiable business, government body, or other large organization.

Enterprise systems engineering (ESE) is the discipline that applies systems engineering to the design of an enterprise. As a discipline, it includes a body of knowledge, principles, and processes tailored to the design of enterprise systems.

<span class="mw-page-title-main">John Zachman</span> American computer scientist

John A. Zachman is an American business and IT consultant, early pioneer of enterprise architecture, chief executive officer of Zachman International, and originator of the Zachman Framework.

<span class="mw-page-title-main">ArchiMate</span> Enterprise architecture modeling language

ArchiMate is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way.

<span class="mw-page-title-main">Function model</span>

In systems engineering, software engineering, and computer science, a function model or functional model is a structured representation of the functions within the modeled system or subject area.

<span class="mw-page-title-main">Three-schema approach</span> Approach to building information systems

The three-schema approach, or three-schema concept, in software engineering is an approach to building information systems and systems information management that originated in the 1970s. It proposes three different views in systems development, with conceptual modelling being considered the key to achieving data integration.

<span class="mw-page-title-main">NIST Enterprise Architecture Model</span> Reference model of enterprise architecture

NIST Enterprise Architecture Model is a late-1980s reference model for enterprise architecture. It defines an enterprise architecture by the interrelationship between an enterprise's business, information, and technology environments.

<span class="mw-page-title-main">TRAK</span> Enterprise architecture framework

TRAK, or The Rail Architecture Framework, is a general enterprise architecture framework aimed at systems engineers. It is based on MODAF 1.2.

<span class="mw-page-title-main">Architecture of Interoperable Information Systems</span>

The Architecture of Interoperable Information Systems (AIOS) is a reference architecture for the development of interoperable enterprise information systems. If enterprises or public administrations want to engage in automated business processes with other organizations, their IT systems must be able to work together, i.e. they need to be interoperable. The AIOS represents a generic building plan for these organizations to develop interoperable information systems by systematically adjusting and extending their internal information systems. The AIOS was described in a doctoral thesis and is based on the results of various research projects on interoperability. It is independent from specific products or vendors but describes generically the different layers, views, relationships and technical means needed to efficiently establish interoperable information systems. To this aim it combines concepts from service-oriented architecture, Collaborative Business and Business Process Modelling. It can be seen as complementary to ARIS, a well-known architecture for internal information systems and business processes.

Software architecture description is the set of practices for expressing, communicating and analysing software architectures, and the result of applying such practices through a work product expressing a software architecture.

References

  1. ISO/IEC/IEEE 42010:2011, Systems and so— Architecture description
  2. ISO/IEC 10746-1, Information technology — Open Distributed Processing — Reference model: Overview
  3. 1 2 3 4 5 6 7 Edward J. Barkmeyer ea (2003). Concepts for Automating Systems Integration NIST 2003.
  4. Douglas T. Ross and K.E. Schoman, Jr. "Structured analysis for requirements definition." IEEE Transactions on Software Engineering, SE-3(1), January 1977.
  5. A. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein, and M. Goedicke. "Viewpoints: A framework for integrating multiple perspectives in system development." International Journal of Software Engineering and Knowledge Engineering, 2(1):31-58, 1992.
  6. 1 2 3 4 5 6 7 8 9 10 11 Peter Shames, Joseph Skipper. "Toward a Framework for Modeling Space Systems Architectures" Archived 2009-02-27 at the Wayback Machine . NASA, JPL.
  7. Easterbrook, S.; Yu, E.; Aranda, J.; Yuntian Fan; Horkoff, J.; Leica, M.; Qadir, R.A. (2005). "Do viewpoints lead to better conceptual models? An exploratory case study". 13th IEEE International Conference on Requirements Engineering (RE'05). pp. 199–208. CiteSeerX   10.1.1.78.4594 . doi:10.1109/RE.2005.23. ISBN   978-0-7695-2425-2.
  8. Sinan Si Alhir (2003). "Understanding the Model Driven Architecture (MDA)". In: Methods & Tools. Fall 2003.
  9. US Department of the Treasury Chief Information Officer Council (2000). Treasury Enterprise Architecture Framework. Version 1, July 2000. Archived 18 March 2009 at the Wayback Machine
  10. IEEE-1471-2000
  11. John Krogstie, (2003). Conceptual modeling, Archived March 16, 2007, at the Wayback Machine
  12. Matthew West and Julian Fowler (1999). Developing High Quality Data Models Archived December 21, 2008, at the Wayback Machine . The European Process Industries STEP Technical Liaison Executive (EPISTLE).
  13. STRAP SECTION 2 APPROACH. Retrieved 30 September 2008.
  14. John F. Sowa (2004). [ "The Challenge of Knowledge Soup"]. published in: Research Trends in Science, Technology and Mathematics Education. Edited by J. Ramadas & S. Chunawala, Homi Bhabha Centre, Mumbai, 2006.
  15. Gad Ariav & James Clifford (1986). New Directions for Database Systems: Revised Versions of the Papers. New York University Graduate School of Business Administration. Center for Research on Information Systems, 1986.
  16. itl.nist.gov (1993) Integration Definition for Information Modeling (IDEFIX) Archived 2013-12-03 at the Wayback Machine . 21 Dec 1993.
  17. 1 2 Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.
  18. US Department of Veterans Affairs (2008) A Tutorial on the Zachman Architecture Framework Archived July 13, 2007, at the Wayback Machine . Accessed 06 Dec 2008.
  19. A Comparison of the Top Four Enterprise Architecture Methodologies Archived 2008-04-09 at the Wayback Machine , Roger Sessions, Microsoft Developer Network Architecture Center,
  20. Federal Enterprise Architecture Framework Archived September 16, 2008, at the Wayback Machine
  21. ISO/IEC 10746-1:1998 Information technology – Open Distributed Processing: Reference Model – Part 1: Overview, International Organization for Standardization, Geneva, Switzerland, 1998.
  22. 1 2 DoD (2007) DoD Architecture Framework Version 1.5 . 23 April 2007 Archived March 11, 2005, at the Wayback Machine
  23. 1 2 3 4 Federal Enterprise Architecture Program Management Office (2006). FEA Practice Guidance [ dead link ].
  24. 1 2 3 Peter Shames & Joseph Skipper (2006). Towards a Framework for Modeling Space Systems Architectures Archived 2010-05-27 at the Wayback Machine . 25 May 2006.
Attribution

PD-icon.svg This article incorporates public domain material from the National Institute of Standards and Technology.