view model for other uses see view model disambiguation 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 a whole system from the perspective of a related set of concerns since the early 1990s there have been a number of efforts to prescribe approaches for describing and analyzing system architectures these recent efforts define a set of views or viewpoints they are sometimes referred to as architecture frameworks or enterprise architecture frameworks but are not 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 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 systems specifications a business executive will ask different questions of a system makeup 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 14712000 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 kruchtens 41 view model the zachman framework togaf dodaf rmodp and hamdaqas 51 view model history in the 1970s methods began to appear in software engineering for modeling with multiple views douglas t ross and ke schoman in 1977 introduce the constructs context viewpoint and vantage point to organize the modeling process in systems requirements definition 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 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 viewpoints 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 terms 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 softwareintensive systems ieee std 14712000 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 ieee 1471 now isoiecieee 420102011 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 rmodp was published to provide a useful framework for describing the architecture and design of largescale 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 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 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 viewpoints provide the conventions rules and languages for constructing presenting and analysing views in isoiec 420102007 ieeestd14712000 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 each such architectural model is developed using the methods established by its associated architectural system as well as for the system as a whole modeling perspectives modeling perspectives is a set of different ways to represent preselected 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 behavioralprocessual perspectives this together with rule object communication and actor and role perspectives is one way of classifying modeling approaches 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 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 higherlevel views allow the engineer to fashion and comprehend the whole design and identify and resolve problems in the large lowerlevel views allow the engineer to concentrate on a part of the design and develop the detailed specifications 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 bottomup synthesis of the system may also be useful 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 threeschema approach the notion of a threeschema model was first introduced in 1977 by the ansix3sparc threelevel architecture which determined three levels to model data the threeschema 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 the three schema approach defines three schemas and views external schema for user views conceptual schema integrates external schemata internal schema that defines physical storage structures 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 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 41 view model of architecture illustration of the 41 view model or architecture 41 is a view model designed by philippe kruchten in 1995 for describing the architecture of softwareintensive systems based on the use of multiple concurrent views the views are used to describe the system in the viewpoint of different stakeholders such as endusers 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 logical view is concerned with the functionality that the system provides to endusers development view illustrates a system from a programmers perspective and is concerned with software management process view deals with the dynamic aspect of the system explains the system processes and how they communicate and focuses on the runtime behavior of the system physical view depicts the system from a system engineers point of view it is concerned with the topology of software components on the physical layer as well as communication between these components in addition selected use cases or scenarios are utilized to illustrate the architecture hence the model contains 41 views 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 us 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 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 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 us federal government as having received worldwide acceptance as an integrated framework for managing change in enterprises and the systems that support them rmodp views the rmodp 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 rmodp the enterprise viewpoint which is concerned with the purpose and behaviors of the system as it relates to the business objective and the business processes of the organization the information viewpoint which is concerned with the nature of the information handled by the system and constraints on the use and interpretation of that information the computational viewpoint which is concerned with the functional decomposition of the system into a set of components that exhibit specific behaviors and interact at interfaces the engineering viewpoint which is concerned with the mechanisms and functions required to support the interactions of the computational components the technology viewpoint which is concerned with the explicit choice of technologies for the implementation of the system and particularly for the communications among the components rmodp further defines a requirement for a design to contain specifications of consistency between viewpoints including the use of enterprise objects and processes in defining information units the use of enterprise objects and behaviors in specifying the behaviors of computational components and use of the information units in defining computational interfaces the association of engineering choices with computational interfaces and behavior requirements the satisfaction of information computational and engineering requirements in the chosen technologies 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 customers operating domain in which the developing system will operate 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 overarching all view av operational view ov systems view sv and the technical standards view tv 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 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 federal enterprise architecture levels and attributes enterprise architecture segment architecture and solution architecture 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 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 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 derived from ccsds rasds rmodp iso 10746 and compliant with ieee 1471 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 hereby rasds stands for reference architecture for space data systems see second image enterprise viewpoint organization view includes organizational elements and their structures and relationships may include agreements contracts policies and organizational interactions requirements view describes the requirements goals and objectives that drive the system says what the system must be able to do scenario view describes the way that the system is intended to be used see scenario planning includes user views and descriptions of how the system is expected to behave information viewpoint metamodel view an abstract view that defines information model elements and their structures and relationships defines the classes of data that are created and managed by the system and the data architecture information view describes the actual data and information as it is realized and manipulated within the system data elements are defined by the metamodel view and they are referred to by functional objects in other views reference architecture for space data systems functional viewpoint functional dataflow view an abstract view that describes the functional elements in the system their interactions behavior provided services constraints and data flows among them defines which functions the system is capable of performing regardless of how these functions are actually implemented functional control view describes the control flows and interactions among functional elements within the system includes overall system control interactions interactions between control elements and sensor effector elements and management interactions physical viewpoint data system view describes instruments computers and data storage components their data system attributes and the communications connectors busses networks point to point links that are used in the system telecomm view describes the telecomm components antenna transceiver their attributes and their connectors rf or optical links navigation view describes the motion of the major elements within the system trajectory path orbit including their interaction with external elements and forces that are outside of the control of the system but that must be modeled with it to understand system behavior planets asteroids solar pressure gravity structural view describes the structural components in the system sc bus struts panels articulation their physical attributes and connectors along with the relevant structural aspects of other components mass stiffness attachment thermal view describes the active and passive thermal components in the system radiators coolers vents and their connectors physical and free space radiation and attributes along with the thermal properties of other components ie antenna as sun shade power view describes the active and passive power components in the system solar panels batteries rtgs within the system and their connectors along with the power properties of other components data system and propulsion elements as power sinks and structural panels as grounding plane propulsion view describes the active and passive propulsion components in the system thrusters gyros motors wheels within the system and their connectors along with the propulsive properties of other components mbed top level ontology based on the nominal set of views engineering viewpoint allocation view describes the allocation of functional objects to engineered physical and computational components within the system permits analysis of performance and used to verify satisfaction of requirements software view describes the software engineering aspects of the system software design and implementation of functionality within software components select languages and libraries to be used define apis do the engineering of abstract functional objects into tangible software elements some functional elements described using a software language may actually be implemented as hardware fpga asic hardware views describes the hardware engineering aspects of the system hardware design selection and implementation of all of the physical components to be assembled into the system there may be many of these views each specific to a different engineering discipline communications protocol view describes the end to end design of the communications protocols and related data transport and data management services shows the protocol stacks as they are implemented on each of the physical components of the system risk view describes the risks associated with the system design processes and technologies assigns additional risk assessment attributes to other elements described in the architecture control engineering view analyzes system from the perspective of its controllability allocation of elements into system under control and control system integration and test view looks at the system from the perspective of what must be done to assemble integrate and test system and subsystems and assemblies includes verification of proper functionality driven by scenarios in satisfaction of requirements ivv view independent validation and verification of functionality and proper operation of the system in satisfaction of requirements does system as designed and developed meet goals and objectives technology viewpoint standards view defines the standards to be adopted during design of the system eg communication protocols radiation tolerance soldering these are essentially constraints on the design and implementation processes infrastructure view defines the infrastructure elements that are to support the engineering design and fabrication process may include data system elements design repositories frameworks tools networks and hardware elements chip fabrication thermal vacuum facility machine shop rf testing lab technology development assessment view includes description of technology development programs designed to produce algorithms or components that may be included in a system development project includes evaluation of properties of selected hardware and software components to determine if they are at a sufficient state of maturity to be adopted for the mission being designed 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 enterprise architecture framework organizational architecture software development methodology treasury enterprise architecture framework togaf zachman framework ontology information science knowledge acquisition attribution this article incorporatespublic domain material from the national institute of standards and technology website httpwwwnistgov media related to view models at wikimedia commons vtesoftware engineeringfields computer programming requirements engineering software deployment software design software maintenance software testing systems analysis formal methods concepts data modeling enterprise architecture functional specification modeling language orthogonality programming paradigm software software archaeology software architecture software configuration management software development methodology software development process software quality software quality assurance software verification and validation structured analysis orientations agile aspectoriented object orientation ontology service orientation sdlc modelsdevelopmental agile eup executable uml incremental model iterative model prototype model rad up scrum spiral model vmodel waterfall model xp other spice cmmi data model er model function model information model metamodeling object model systems model view model languages idef uml usl sysml softwareengineers victor basili kent beck grady booch fred brooks barry boehm peter chen danese cooper ward cunningham tom demarco edsger w dijkstra delores m etter martin fowler adele goldstine margaret hamilton c a r hoare lois haibt mary jean harrold grace hopper watts humphrey michael a jackson ivar jacobson alan kay nancy leveson stephen j mellor bertrand meyer david parnas trygve reenskaug winston w royce james rumbaugh mary shaw peri tarr elaine weyuker niklaus wirth edward yourdon related fields computer science computer engineering project management risk management systems engineering category commons 