Talk:View model

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computing / Software (Rated C-class)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software.
 
WikiProject Systems (Rated C-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Systems, which collaborates on articles related to systems and systems science.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is within the field of Enterprise modelling.
 

Normal set of views[edit]

The "nominal set of views" is no original work, as user:RichardVeryard suggested. The text about it is copied from one Public Domain (PD) NASA source, written by a NASA employee. I added some more references, to express this fact some more. But maybe I should add an extra explaination for introduction.

There is a reason I added this perspective of a "normal set of views". This "set of views" contrasts the earlier mentioned "view models". This seems to be an other way of defining the "view model idea". It also seems to me that this "normal set of views" is a new and original way of looking at possible views by Peter Shames and Joseph Skipper. I haven't investigated this any further. I will try to make this more clear in the article.

-- Marcel Douwe Dekker (talk) 12:57, 4 December 2008 (UTC)

As far as I can tell, references 2 and 15 are the same, and point to what appears to be an incomplete draft of a paper on the NASA website. If this is the only source for this framework, then it is not notable enough to be ranked alongside RM-ODP and DODAF. Is it possible to use this paper as a source for some additional insights into the topic of view models without presenting the entire framework? --RichardVeryard (talk) 13:44, 5 December 2008 (UTC)
Thanks for you concern. Ref 2 and 15 have the same name, but the first is a paper and the second and a set presentation sheets with a slightly different content. But I share your concern. I will try to:
  • Move the entire framework to a separate article, under I think the title Reference Architecture for Space Data Systems (RASDS), and leave just a short summary here
  • improve the representation of RM-ODP and DoDAF some more, and
  • write about other reference view models as well
This article is evolving. If you have more suggestions, let me know. -- Marcel Douwe Dekker (talk) 14:06, 5 December 2008 (UTC)
I think you might find it hard to establish notability for RASDS. The only references I can find are to papers by the authors. Good luck. --RichardVeryard (talk) 14:42, 5 December 2008 (UTC)
This will be one of my least concerns. As far as I can see:
  • The RASDS is beeing developed by the Consultative Committee for Space Data Systems (CCSDS) since at least 2004 and there are more then just a few papers by the authors.
  • Their so called "set of nominal views" seems to be the view model within the RASDS Architetural framework.
  • Now I guess this framework is one of more Architectural frameworks beeing developed by the NASA
  • Just like the DoDAF and Federal Enterprise Architecture these works of the NASA and CCSDS (partly) are in the public domain. This gives the opportunity to create well illustrated and well written (because original text can be used) articles.
By the way I do think the initiating organization, the Consultative Committee for Space Data Systems (CCSDS), is as notable as the DoD, ISO or IEEE. I don't see a real problem here.
I do agree listing of the entire view model framework isn't perfect, and I will keep searching for an alternative. -- Marcel Douwe Dekker (talk) 21:58, 5 December 2008 (UTC)

View model[edit]

This first comment copied here from the Talk:Data model article

I am adding corrections to the articles that are in support of my day job, and as the next few months I am going to be responsible for reconciling the terminology between two ISO standards, one of them being the ISO/IEC 42010 IEEE Recommended Practice for Architectural Descriptions of Software-Intensive Systems, I am willing to put some time into the models and viewpoints.

I looked at the view model. My first impression was that this article is about the models of user interface, in other words, that it is related to the model-view-controller architecture pattern. I like the content of the article, with one exception. Do you think, the section about perspective and projection in maps is less directly related to models? It looked somewhat anomalous, it is only an analogy (maybe a useful one).

I do not think, there is a view model in the same sense as e.g. a data model. The concept of a view belongs to a higher meta-level as it provides some organization to models.

Here is what IEEE 42010 says:

In the conceptual framework of this recommended practice, an architectural description is organized into one or more constituents called (architectural) views. Each view addresses one or more of the concerns of the system stakeholders. The term view is used to refer to the expression of a system’s architecture with respect to a particular viewpoint.
NOTE—This recommended practice does not use terms such as functional architecture, physical architecture, and technical architecture, as are frequently used informally. In the conceptual framework of the recommended practice, the approximate equivalents of these informal terms would be functional view, physical view, and technical view, respectively.
Other information, not contained in any constituent view, may appear in an AD , as a result of an organization's documentation practices. Examples of such information are the system overview, the system context, the system stakeholders and their key concerns, and the architectural rationale.
A viewpoint establishes the conventions by which a view is created, depicted and analyzed. In this way, a view conforms to a viewpoint. The viewpoint determines the languages (including notations, model, or product types) to be used to describe the view, and any associated modeling methods or analysis techniques to be applied to these representations of the view. These languages and techniques are used to yield results relevant to the concerns addressed by the viewpoint.
An architectural description selects one or more viewpoints for use. The selection of viewpoints typically will be based on consideration.

What do you think?

Equilibrioception (talk) 03:43, 13 January 2009 (UTC)

Thanks for your respons. As a start I made added some wikilinks to your text to determine both what mean terms we are talking about and which are of them have Wikipedia articles. Now to the content. I keep wondering if your first association with user interface and model-view-controller was before or after you started reading the article...!? The introduction of this article doesn't link to either one of them. So was it your first impression or first expectation?
This article is written to cover the idea of view model in systems engineering and software engineering and the field of enterprise architecure, which in my opinion has emerged somewhere in between. My focus is more specific on the systems analysis activities in these disciplines. The view model sort of defines the very basic approach here. Now I can also image you associate the "view model" with a user interface, because "view models" sort of appear as user interface in enterprise modelling tool as Avolution... Is this why you made the association...??
This last question keeps me wondering, in what context the term "view model" has emerged. Next I started searching for some historical definitions of the term "view model", and found in the 1980s the following phrases:
  1. For the three kinds of applications mentioned in the introduction, it can be said that a two-dimensional side-view model can certainly serve as a tool for... Source: Hugo B. Fischer (1980). Transport Models for Inland and Coastal Waters: Proceedings of a Symposium. International Association for Hydraulic Research, American Society of Civil Engineers, University of California, Berkeley. p. 485.
  2. ABSTRACT An approach to defining a conceptual view model of entities and /... concept of using entities and relationschips to model information may be generalized to the point where a conceptual view can de defined (using entities and relationships) that models entity relationship definitions. This leads to the need for an internal conceptual view of a conceptual / The conceptual view model in figue 8 (or any previous figure for that matter) can be used as a map to guide the flow of the logic manipulating the data... . Source: Peter P. S. Chen (1981). Entity-relationship Approach to Information Modeling and Analysis . P. 563/567/573
  3. A view model represents a small subset of reality, appropriate to one application of the database contents. Most databases will require several view models ... Source: Gio Wiederhold (1983). Database Design. p. 349.
  4. The view model is achieved by the ANSI-standard three-level architecture of DBMS which is a fundamental concept of database technology.... Source: Yaacov Chaueka (1988). Computers in Literary and Linguistic Research: Literary and Linguistic... Association for Literary and Linguistic Computing International Conference. p.203.
  5. The development of integrated systems technology involved creating several models of the classical design process. The most important is the "view" model, which holds that during the process, the designer creates and maintains several views of his circuit, which include a functional view, a functional simulation view, a logical view... Source: Electronics. ‎McGraw-Hill Pub. Co., 1984. p. 123.
This quick (far incomplete) search allready shows that in the 1980s:
It was in fact my own idea to name ANSI-standard and the Zachman Framework a "view model". In the sources I hadn't found any real conformation about this.
Ok. I will leave this for now. I will get back to mentioning of the perspective and projection in maps later on. First I like to know. Was it your expectation or first impression?
-- Marcel Douwe Dekker (talk) 21:10, 13 January 2009 (UTC)
P.S. I noticed the part of the ISO/IEC 42010 or IEEE 1471 you quoted doesn't use the term view model...!?
This was my expectation, before reading the article, rather than the impression after reading the article. I do not believe that the architecture community has the established use of the term view model. The term architecture framework is used instead. Personally, I find that the term view model brings a subtle mismatch in the use of metalevels when you build the sequence: data model, function model and then view model, because most views usually include both data and function. There are however models of user interfaces, which are also views in the traditional model-view-controller framework. It seems to me that there are view models (user interface models) and view metamodels (or architecture frameworks). The word view is rather ambiguous, of course. So is the word model, isn't it ? ISO 42010 specifies what is a architecture view and how it is defined.
-- Equilibrioception (talk) 21:04, 25 January 2009 (UTC)
The problem is that the term view model implies significantly more rigor in defining a framework, than there really is (arguably also more than there should be, from the pragmatics perspective). The stateholders of a particular data model are the people interested in the particular data. The stakeholders of a view model in the sense of the design space of architecture frameworks are the people creating such frameworks, or studying such framework. This is my another approach to explain the two different metalevels to which these concepts belong. When you look at the ANSI-SPARC Architecture, it is usually called the Three-level architecture, not the view model. The google search of the phrase view model is dominated by the model-view-controller occurences (except for this article). It does seem to me that you are breaking some new ground here.
-- Equilibrioception (talk) 21:19, 25 January 2009 (UTC)
Thanks for you sharp comments. In return I like to explain, that this article is inspired on how Philippe Kruchten (his 1995 paper) has used the term view model, or at least how I have interpreted his intention. I have seen a similarity between:
  • The TEAF documentation speaks of a "Matrix of Views and Perspectives"
  • ANSI-SPARC Architecture indeed spoke of a "Three-level architecture"
  • John Zachman (1987) spoke of a "generic set of architectural representations"
  • Philippe Kruchten (1995) spoke of a "View Model of Software Architecture".
  • The RM-ODP spoke of five "generic and complementary viewpoints".
  • DoDAF about the "linkages among views"
  • The FEA about "levels and attributes", and
  • Some NASA guys about "Nominal set of views".
And brought this together in this article under the title "view model".
Now I just searched for some more books were the term "View model" is used. I noticed the term is just quit often, but indeed, only in minor cases, in the way it is presented here. Maybe it would be better, if this article would be renamed "architectural view model", or "enterprise architectural view model", or shortly "enterprise view model", to express the limited scope of this article.
I don't agree the term "view model" here is, has the same meaning as the term Enterprise Architecture Framework (EAF). A view model can be part of an EAF, but is limited to defining the set of views. The EAF is more, because it also defines the set of models/modeling languages to be used in the particular Enterprise Architecture.
-- Marcel Douwe Dekker (talk) 00:10, 26 January 2009 (UTC)
Marcel, I find that your work in the Wikipedia is very impressive, so you raised my curiosity. I am many years in the software architecture field, but I have not heard the term view model before. Maybe I have missed something. So out of curiosity, I went through the quotes mentioned above. You have provided some 13 quotes above, where this term occurs in some context. Last 7 use the term view or viewpoint, but not view model.
You rely on Philippe Kruchten's seminal paper. I suspect that there is more that one way to parse the phrase "4+1 view model": one can say that in the universe of view models Philippe has introduced a new one called the "4+1" view model; but it is also possible to say that in the universe of models Philippe has introduced a new one called "4+1 view" model. The phrase "4+1 view model" occurs 6 times in the article; 5 times in captions, and only once in context, which may be used to validate the intended meaning. In the abstract Philippe says that the article presents a model for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. I believe, that this supports the second interpretation of the phrase.
Out of the first 5 quotes, at least two can be parsed in the same way as Philippe's model. This leaves only 3 quotes. I'll check the papers themselves.
The Google search that eliminates the 'controller' and just looks for model and view at the same page does not show anything interesting in the first few pages:
 model view -controller -viewmodel -model-view -model/view -modelview  -"model viewer"
However, there is an overwhelming number of uses of the term "Model-View-Controller" as one of the key design patterns.
Microsoft uses the term ViewModel in the sense of the model of the user interface:
A 'ViewModel is a model for a view in the application (duh!). It exposes data relevant to the view and exposes the behaviors for the views, usually with Commands. The model is fairly specific to a view in the application, but does not subclass from any WPF classes or make assumptions about the UI that will be bound to it. Since they are separate from the actual UI, these classes are also relatively straightforward to unit test. see MSDN Blogs.
Just as a suggestion, how do you like the term modeling viewpoint or modeling perspective? For once, it will justify that section on perspective. (smiley goes here). Since Modeling perspectives already exists, how about viewpoint model ? Are we using the good old Occam's razor principle as some sort of guidance here ? (another smiley may go here , too).
-- Equilibrioception (talk) 05:16, 28 February 2009 (UTC)


Interesting stuff, this fact-checking. I tried to locate the following abstract:
ABSTRACT An approach to defining a conceptual view model of entities and /... concept of using entities and relationschips to model information may be generalized to the point where a conceptual view can de defined (using entities and relationships) that models entity relationship definitions. This leads to the need for an internal conceptual view of a conceptual / The conceptual view model in figue 8 (or any previous figure for that matter) can be used as a map to guide the flow of the logic manipulating the data... . Source: Peter P. S. Chen (1981). Entity-relationship Approach to Information Modeling and Analysis . P. 563/567/573
This is from a conference proceedings paper: Jerome M. Fox, J. Carlos Goti, Claude R. Miller, James M. Sagawa: Implementing a Self-Defining Entity-Relationship Model to Hold Conceptual View Information. ER 1981: 563-576.
You must have access to some good electronic library to even find the abstract. My quick search did not yield the paper itself, or any impact it may had. This seems to be the only paper published by any of the first three authors, and one of two papers, published by the last one. But, impact aside, clearly, they are talking about a model of information at a level of a conceptual view, which they refer to as a conceptual view model as in your quote above. So, again, it does not seem to be the model of a particular view, but rather, a particular view of a model. My two cents.
-- Equilibrioception (talk) 06:10, 28 February 2009 (UTC)
I think we are talking about at least three related but different fields:
Now it have become clear that the term "view model" could be confused with "Model-View-Controller", which seems to have a specific meaning in software architecture. To be honest, I don't understand a word for the "Model-View-Controller" article, because it is presented as:
... an architectural pattern used in software engineering.
... and an architectural patterns are software patterns that offer well-established solutions to architectural problems in software engineering.
This makes the "Model-View-Controller a well-established solutions to architectural problems", what ever n architecural problem maybe. It is at least clear to me this has nothing to do with the things explained in this article.
Now I already explained the term "view model" is a title choosen to represent an part of enterprise architecture, which is called by different names:
  • "Matrix of Views and Perspectives"
  • "Three-level architecture"
  • "generic set of architectural representations"
  • "View Model of Software Architecture".
  • "generic and complementary viewpoints".
  • "linkages among views"
  • "levels and attributes", and
  • "Nominal set of views".
Maybe we can bring some more light here by changing the title to Enterprise architecture view model.
-- Marcel Douwe Dekker (talk) 16:15, 28 February 2009 (UTC)

The articles title[edit]

Your analysis is very sharp indeed. I understand the reality that you are describing (as per your last paragraph). So, our discussion is related to finding a more appropriate term. I also understand that you do not want to describe the general concept of a view or viewpoint in models (which is the goal of the article Modeling perspectives), but you want to steer clear from it. Right ?

  • My first point is that the term view model is not an established one. There is not enough evidence on established use of this term in the communities including (but not limited to) systems engineering, enterprise architecture, software engineering, software architecture and information engineering.
  • My second point is that the term view model (used without further qualifications) can be easily confused as being related to the "view" part of the Model-View-Controller pattern, and therefore can be easily interpreted as a "model of the user interface". This is supported by a large number of uses of the term "view" in the context of a Model-View-Controller.
  • My third point is that the term view model is too general and therefore too close to the term Modeling perspective
  • My fourth point is that the the term model may be too ambitious in this context: so far enterprise architecture frameworks are only defining views, rather than modeling them. I see a subtle difference there.
  • My fifth point is that the general section on perspective (insightful as it is) belongs to the article Modeling perspectives rather than to the article about enterprise views.
  • You suggested a new term Enterprise architecture view model. This will work, and dropping the word model will (to my taste) work even better. You go to the article Enterprise architecture view to learn about different views in the same way as you would go to the article Color to learn about different colors, color theories, etc. By the way look at the use of color models vs color theories.

To conclude; I like your article in general, so the purpose of this discussion is to make it even better. I prefer to offer you my suggestions, rather than go a edit the article; suggested new term Enterprise architecture view model will work; and you can also consider Enterprise architecture view, or Enterprise architecture views

-- Equilibrioception (talk) 06:32, 1 March 2009 (UTC)

Wikipedia articles need to be build on reliable source, such as for example this article:
Nico Lassing, Daan Rijsenbrij, Hans Van Vliet (2001) Viewpoints on modifiability in: International Journal on Software Engineering and Knowledge Engineering. (2001}, Vol. 11. nr. 4, pp. 453-478.
Abstract: Software architecture is generally regarded as an important tool to achieve systems of higher quality. It is claimed that the foundation for a system’s quality is laid by the decisions made in the software architecture. A question that is occupying both researchers and practitioners is in which areas should decisions be made in the software architecture? We believe architectural view models play an important role in the answer to this question. View models consist of a coherent set of architectural views. These view models have both a prescriptive and a descriptive role in the development process. Their prescriptive role is that they call for a number of aspects to be considered when defining a software architecture and their descriptive role is that they provide a framework to document a software architecture. Currently, a number of view models exist, the most important of which are the 4+1 View Model of Kruchten and the four views by Soni et al. In our experience with modifiability analysis for business information systems we found that the views in current view models do not include all information required. In this paper we discuss the views we found useful for architecture level impact analysis of business information systems. They are illustrated using a case study we performed for the Dutch Tax Department. We claim that when these views are required for architecture level impact analysis, the decisions they capture should also be considered during architecture development.
An article like this makes it quite clear, that view models exits. So we don't need to discuss whether or not the term is established, and if there is evidence or not, and the rest. There are some things we can do.
  1. Rename this article to enterprise architecture view model, enterprise architecture view or architectural view model as Lassing et al. calls it.
  2. If we rename and move this article, the term view model can become a disambig page, with links to the related terms Model-View-Controller, Modeling perspectives, this article, and maybe some other view models listed in this article: 4+1 Architectural View Model, Zachman Framework etc. And mabe even to particular views involved in those view models, such as the Operational View
  3. I enlarged the difference between the Modeling perspectives article and this article, by renaming that article to Modeling perspective, the singular form. I also copied the general section on perspective there as well. This text relate to both that and this article.
Now about the article title. I don't think enterprise architecture view is a good title. It not only ignors the existence of view models, it points in the wrong direction. The current Modeling perspective article already lists a general series of views. An article about "enterprise architecture view" should descripe the individual views in enterprise architecture frameworks such as the "Functional view", "Operational View", "Organizational view" etc. But this is not what this article is about. This article descriptions the frameworks, constructed with those views.... the view model. So this leaves us with two options. -- Marcel Douwe Dekker (talk) 22:31, 1 March 2009 (UTC)
P.S. I removed the text on perspective from the Modeling perspective because I think it makes the article even more confusing. I noticed the whole article is based on one idea by John Krogstie, who is specifically speaking about a conceptual modeling perspective or perspectives on conceptual modeling. The big difference with this article is, that this article is about perspectives on enterprise modelling
Marcel, thank you for the article link. The article is interesting. I like the introduction - they are making some good points. Regarding the modifiability analysis. I think this is the key concept of software architectures, in particular to the technical aspects, which bridge to design. It is known as Robustness analysis. There is a stub article on RATF and a stub article on Robustness. This is the best thing (since sliced bread, of course). Are you familiar with this technique? One fine day ...
You say: An article like this makes it quite clear, that view models exits, yet it only proves that the concept was invented not by you, but by them. Upon more careful reading, I suspect I will be able to make the same case against the the concept of the view model.
Here is another case against the view model: in theory, yes, one can model architecture views, and even have a theory of enterprise architecture views, and this would be a good thing. However, do not forget, that software architectures and especially enterprise architectures are more about communication across large multi-functional teams. So, the set of views in an enterprise architecture is something very stable, because of the enormous amount of training and tool building around it. Look at UPDM for example. Here is an analogy for you: enterprise architecture views are related to the real architecture blueprints. There is a well-defined set of perspectives to a building blueprint:
* structural
* plumbing
* electrical
* ventilation
* interior design
Is there a theory of blueprint views ? Perhaps, but this does not mean that I can (easily) invent yet another cool view and toss it over to my contractor.
Therefore distinction should be made between the academic research perspective it is useful to have an architecture viewpoint theory (why there are coherent sets of viewpoints, and what makes one work better than another); and the practical perspective of describing established viewpoints.
You suggest: enterprise architecture view model, or architectural view model. My preference is architectural view model, because "4+1" view model is not an enterprise architecture view model, but a very well-known one. The article does not mention the Soni's view model (yet). Other view models in the article are enterprise architecture view models.
How would you define the difference between an enterprise architecture and software architecture ?
How about architecture view models (plural)? We are not talking about a single such model, right? By the way, I second you on the change Model perspective to singular, as this article describes the single concept. I also accept your point that architecture view title is not good, as we want to describe coherent collections of architecture views. If we agree to call such coherent collection of architecture views an architecture view model, the article should be titled architecture view models.
I can be singular, if you'd like to look for a less confusing term as model. As an example, look at Color scheme (singular). The article talks about the choice of colors, basically, a coherent collection of colors selected for a particular design purpose. They happily enumerate several color schemes (plural). But the term XYZ model (singular) is confusing as the title, as this can mean both the single model of XYZ, as well as the entire universe of models of XYZ. This was the source of my confusion at the very beginning of our discussion.
I deeply suspect, that this less confusing substitute for the term model already exists. An this is the term framework. What is in your opinion the difference between a particular enterprise architecture view model (singular, a single instance), and an enterprise architecture framework ?
To conclude, I suggest renaming to architecture view models. This discussion has generated few points that can be addressed in the disambiguation page.
Respectfully, Equilibrioception (talk) 03:24, 2 March 2009 (UTC)
Wikipedia articles are mostly singular: Enterprise architecture, Enterprise architecture framework, Modeling language, perspective etc. There is no need to make an exception here. Especially because this article aims to explain "what is a view model". "what are its basic principles?" "Which types exist?" "How is it applied?". It is all about the "view model". -- Marcel Douwe Dekker (talk) 08:20, 2 March 2009 (UTC)
-- Marcel Douwe Dekker (talk) 08:20, 2 March 2009 (UTC)

Views in software architecture and views in enterprise architecture[edit]

I wonder if you Equilibrioception confuse "Views in software architecture" with "views in enterprise architecture". For example in Paul Clements et al. (2003) Documenting Software Architectures: Views and Beyond the example they are given about "Views in software architecture" are:

  1. a set of views in .... Rational’s Unified Process, which is based on Kruchten’s 4+1 view approach.
  2. The Siemens Four Views model (in: Hofmeister, C., R. Nord, and D. Soni. (200). Applied Software Architecture, Addison-Wesley, Boston)

The current article doesn't relate to any set of views in the Rational’s Unified Process, or to any set of views in any other software development methodology.

Maybe this is the problem with our discussion. You are assumming I am talking about this subject, while I don't. I presume that there are two subjects here:

  1. View models in software development methodology
  2. View models in enterprise architecture frameworks.

The story about this first subject hasn't been written yet, or maybe a little in the modeling perspective article Software architecture#Views. At the moment these two sections are hardly developed and are in need of more reliable sources. Maybe here is the story about "architecture view models" or "architectural viewpoints" you would like to read.

This article focusses on Enterprise architecture. To avoid this confusion any more, better we name this article enterprise architecture view model. -- Marcel Douwe Dekker (talk) 09:08, 2 March 2009 (UTC)

P.S. I think a great problem here that both in traditional technical drawing and architectural drawing, and in the new fields software architecture and enterprise architecture there are no good overview article about views in these area's in Wikipedia yet.

I have simply asked a question. Thank you for making your position more clear by acknowledging the difference between "Views in software architecture" with "views in enterprise architecture"; however I do not see your explanation as to what that difference might be. This is something we may want to address in the article itself. My objective for this discussion is to improve the article.
If my understanding of the discussion is correct, earlier you said that So this leaves us with two options and presented two alternative titles Enterprise architecture view model and Architecture view model. I have merely informed you about my preferred option, and provided my arguments. Does this imply that I want to read about "architecture view models" ? In a certain sense, yes. And it certainly does not mean that I do not want to read an article about "enterprise architecture view models".
So you have just provided arguments that the article is really about "enterprise architecture view models", so there really was no option earlier, and the title in this case ought to be Enterprise architecture view model (or models).
-- Equilibrioception (talk) 16:11, 2 March 2009 (UTC)

You seem to suggest I am having all the answers allready but I don't. For me it is trial and error here, just as in a lot of other articles I have written. I am just starting the realize, that view models are defined in different close related fields from systems engineering, software engineering, and enterprise architecture to ...

I think there is really not enough information yet to get a clear picture. This article is designed to set an example by taking several well established subjects from those three fields. Now for a moment I was thinking there could be different view models in systems engineering, software engineering, and enterprise architecture. But I am doubting this allready. So now at the moment I think renaming this article to enterprise architecture view model is not so good idea after all. Maybe it should be architecture view model or maybe architectural view model because I don't want to exclude systems and software engineering. One way or an other the title should be singular. -- Marcel Douwe Dekker (talk) 20:34, 2 March 2009 (UTC)

Disambiguation page[edit]

Here is the initial list:

-- Equilibrioception (talk) 03:59, 2 March 2009 (UTC)

I think this far over the top. Most important this article is never meant to be about software architecture, but about enterprise architecture and about enterprise architecture frameworks. Second disambig pages don't list red links. Third if there is a link to software architecture, I think that article should explain fist. And last but not least. Linking to the Architectural drawing article, I recently wrote, only confuses things. As far as I now, in classic architecture they don't speak about view models. Also you don't relate to separate article sections in a disambig page... and the Architectural drawings and Architectural plans aricle are one. I merged both last week. I think this will do:
The term view model relates to:
See also
-- Marcel Douwe Dekker (talk) 08:37, 2 March 2009 (UTC)
Marcel, can you clarify you position on the "4+1 view model" ? What is in your opinion the difference between the
1. views in software development methodology
2. views in Rational Unified process (that indeed are based on "4+1 view model")
3. architecture views
4. "4+1 view model"
5. enterprise architecture views
(here are view are meant to be cohesive collections of views, or in your terminology view models). You seem to say that: (2) is an instance of (1); the article is not about (1); the article is not about (3); the article is in part about (4); (4) is an example of (3); (3) is not (5); the title of the article ought to be (5);
-- Equilibrioception (talk) 16:23, 2 March 2009 (UTC)
I have explained about the different types of view models latter on.
For now I have created a View model (disambiguation). -- Marcel Douwe Dekker (talk) 20:37, 2 March 2009 (UTC)

Section Perspective is outside of the scope of the article[edit]

I strongly recommend migrating this section to a separate article called Perspective (science). Another suggestion is to merge the articles perspective (visual) and perspective (graphical). The section on perspective is a very good article that links together several important topics, otherwise not covered, but it is way out of scope in a software architecture type of an article. Consider a Thought experiment where you print out this article to brief a Chief information officer on the topic of Enterprise Architecture Frameworks.

-- Equilibrioception (talk) 04:28, 2 March 2009 (UTC)
This section about "Perspective, views and projection in ordinary science":
  1. gives a summary of the general meaning of perspective and views, and perspective in ordinary science, and
  2. composed with section from related wikipedia articles
  3. There is no new meaning of perspective here,
  4. This section related to multiple subjects
  5. There is no doubt these subject are in a way related to the modelling of views.
So making this a separate article seems makes little sense to me. Wikipedia article need to be about one particular article, and not about a summary of existing articles. -- Marcel Douwe Dekker (talk) 08:15, 2 March 2009 (UTC)
You missed my point in the title of the section: the section about "Perspective, views and projection in ordinary science" is outside of the scope of the article on "enterprise archtecture view models". Using the terminology common to programming languages, this section is inlined, while in accordance to the principle of separation of concerns it should be referenced.
To make my earlier point very clear indeed, I said that there is no doubt that this section should be a physical part of the article on enterprise architecture view models. This is different from "is not related" (I agree, that it is related). Look, there are large clusters of related knowledge in Wikipedia, but this does not mean that we have a single article with multiple sections. We do make decisions to place content into separate articles and connect them with links.
You commented mostly on my secondary point, which is "where to place the section, once it is extracted from the article on enterprise architecture views and replaced with a reference". In my opinion, the options are (1) make it a separate article; (2) merge this section with the other two articles on perspective into a new combined article.
-- Equilibrioception (talk) 16:36, 2 March 2009 (UTC)
I will removed this section from the article for now, and stored it here. -- Marcel Douwe Dekker (talk) 19:48, 2 March 2009 (UTC)


Perspective, views and projection in ordinary science section removed from the article[edit]

An object projected on a plane.

The idea of a view and viewpoints are close related to the idea of perspective. In science and society this term has multiple meaning. There are in fact different kind of perspectives. In context of vision and visual perception, a visual perspective is the way in which objects appear to the eye based on their spatial attributes, or their dimensions and the position of the eye relative to the objects.

In the graphic arts, such as drawing graphical perspective representing the effects of visual perspective in drawings. Here it is an approximate representation, on a flat surface such as paper, of an image as it is perceived by the eye. Perspective works by representing the light that passes from a scene through an imaginary rectangle (the painting), to the viewer's eye. It is similar to a viewer looking through a window and painting what is seen directly onto the windowpane. Each painted object in the scene is a flat, scaled down version of the object on the other side of the window.[1]

In the cognitive science the term "perspective" is used more metaphorically. In theory of cognition a cognitive perspective is the choice of a context or a reference (or the result of this choice) from which to sense, categorize, measure or codify experience, cohesively forming a coherent belief, typically for comparing with another, in relation to cognitive topics.

Conical, Cylindrical and Conformal perspective for map projection.

Cartography speaks of map projection, meaning any method of representing the surface of a sphere or other shape on a plane. Map projections are necessary for creating maps. All map projections distort the surface in some fashion. Depending on the purpose of the map, some distortions are acceptable and others are not; therefore different map projections exist in order to preserve some properties of the sphere-like body at the expense of other properties. There is no limit to the number of possible map projections.

The views used in systems and software engineering have some similarity with the visual perspective used in drawing and the map projection in cartography. As in map projection the Systems analyst has the possibility to use different kind of views to construct different kind of images of the system. There also seems to be no limit to the number of possible views. The difference is that in drawing and mapmaking a physical objects and physical space is represented. Systems and software engineering are dealing with representing societal and knowledge structures. Creating systems views has also similarity with the cognitive perspective. There is choice of a context or a reference from which experience codified and categorized often within modelling frameworks.

Further comment[edit]

Maybe removing this part from the article makes the whole article more clear. Removing this section for now gives me some time to think about this. -- Marcel Douwe Dekker (talk) 19:48, 2 March 2009 (UTC)

The new flow works much better. And please find a new home for the removed content.
-- Equilibrioception (talk) 19:20, 7 March 2009 (UTC)
Thank you for being persistent in making your case. You recent changes have improved the article. I added a section on architecture data, products and views, and how same data is shared among the views. Do you agree with this perspective on the topic ? I also added a comment that makes a distinction between a view as a very specific product and a definition of a view. View model is related to (coherent sets of) view definitions. In the domain of architecture frameworks the two meanings of the term view are often used without notice.
-- Equilibrioception (talk) 19:28, 7 March 2009 (UTC)
Thanks for your response. I do thing the inital definition has improved, but I am not so sure about some other things. I agree with your intention. But it seems with the section, you introduced, a series of new terms emerged here, usch as view definition, architecture description, architecture data, data layer and architecture data element
Now you named the section "Architecture Views, Products and Data", which should be just "Architecture views, products and data", according to Wikipedia naming conventions. And the section doesn't explain the term Architecture view. I am very aware that Wikipedia is written for outsiders, and I always try to avoid using new terms. -- Marcel Douwe Dekker (talk) 21:57, 9 March 2009 (UTC)
I see your point, please check the revised version, where the phrase "architecture view" is avoided.
-- Equilibrioception (talk) 02:06, 10 March 2009 (UTC)

I wikified the section some more, and I think it is ok now. I doubt however these changes have made a big difference. I have been aware that there is a mayor problem with the basic terms we are using here to explain the (enterprise) architectural view model. Terms like View, Viewpoint. viewpoint model, and Modeling perspective perspective. And some of the red links in the IEEE 42010, you started this discussion with:

In the conceptual framework of this recommended practice, an architectural description is organized into one or more constituents called (architectural) views. Each view addresses one or more of the concerns of the system stakeholders. The term view is used to refer to the expression of a system’s architecture with respect to a particular viewpoint.
NOTE—This recommended practice does not use terms such as functional architecture, physical architecture, and technical architecture, as are frequently used informally. In the conceptual framework of the recommended practice, the approximate equivalents of these informal terms would be functional view, physical view, and technical view, respectively.
Other information, not contained in any constituent view, may appear in an AD , as a result of an organization's documentation practices. Examples of such information are the system overview, the system context, the system stakeholders and their key concerns, and the architectural rationale.
A viewpoint establishes the conventions by which a view is created, depicted and analyzed. In this way, a view conforms to a viewpoint. The viewpoint determines the languages (including notations, model, or product types) to be used to describe the view, and any associated modeling methods or analysis techniques to be applied to these representations of the view. These languages and techniques are used to yield results relevant to the concerns addressed by the viewpoint.
An architectural description selects one or more viewpoints for use. The selection of viewpoints typically will be based on consideration.

It has become clear to me views play an significant role in

  • systems engineering and systems analysis
  • software engineering and software development
  • enterprise engineerin and enterprise architecure

If we want to explain more about this situation, we should do more then just attempting to improve this article. Other related articles should be created and or improved as well, and that is maybe even more important at the moment. -- Marcel Douwe Dekker (talk) 19:34, 10 March 2009 (UTC)

I am hesitating to dive into this area because there are lots of inter-related pages and the editing task looks complicated. Maybe we need a mind map or concept model of the whole area to help the editors to work out what pages are required and what material goes on which page. --RichardVeryard (talk) 18:01, 11 March 2009 (UTC)
One of the most remarkeble inter-relation here is between enterprise architecture, business architecture, process architecture, software architecture and Systems architecture. Now mindmap or not, I think at the moment it is maybe more important that the differences between these terms are made more clear. The fact for example that the software architecture article gives a list of typical enterprise architecture is very confusing (to me), as if there is no difference between the two.
-- Marcel Douwe Dekker (talk) 21:14, 11 March 2009 (UTC)
There are several "schools of thought" addressing the same major area from different perspectives (no pun intended), with different backgrounds. Do not forget information architecture. But where is the line to perform the "untangling"? How far can we as Wikipedia editors can push the "unconfused" terminology, if the confusion often exists in publications? It is a big and delicate task.
The concept of a "view" is also quite similar to the concept of a "model". So a "data model diagram" is a particular "view". According to IEEE, there is a certain relations between a "view" and a "model": A view may consist of one or more architectural models. Each such architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view.
I'd be interested to work on a mindmap mentioned by RichardVeryard
-- Equilibrioception (talk) 02:55, 12 March 2009 (UTC)
You might want to start just with venn diagrams to determine the relation between those terms and that "same major area", and construct a mind map around it. -- Marcel Douwe Dekker (talk) 03:04, 12 March 2009 (UTC)
Mind map or concept map? --RichardVeryard (talk) 11:33, 12 March 2009 (UTC)

Types of view models defined in science[edit]

I think the past discussion is based on very incomplete data. There seems to be a large collection of scientific publications about using the term "view model". To get a better impression I will try to make a list of the types of view models defined there. Eventually maybe some of this list may be added to the View model (disambiguation) or not.

  • Connection view model [3]
  • Dynamic spherical view model (DSVM)[4]
  • Enterprise multi-view model [5]
  • Environment holarchic viewmodel [6]
  • Materialized view model[7]
  • Multiple-view model for a software product line[8]
  • Multi-view model for head gesture recognition[9]
  • Private view model[10]
  • Three-Layered XML View Model [12]
  • Virtual view model[7]
References
  1. ^ Perspective Drawing Handbook By Joseph D'Amelio, p. 19, published by Dover Publications
  2. ^ Rajugan, R. et al. (2005) "Modeling Ontology Views: An Abstract View Model for Semantic Web".
  3. ^ John R. Anderson (2002). Intelligent Networks: Principles and Applications‎. p.109.
  4. ^ Fred A. Hamprecht et al. (2007). Pattern Recognition: 29th DAGM Symposium, Heidelberg, Germany, September 12 2007. p.29
  5. ^ Yanbo Han et al. (2002). Engineering and Deployment of Cooperative Information Systems. p.255
  6. ^ Ann Dale, Stuart B. Hill (2001). At the Edge: Sustainable Development in the 21st Century‎. P.21.
  7. ^ a b Ashish Gupta et al. (1999). Materialized Views: Techniques, Implementations, and Applications‎. p.15.
  8. ^ Jan Bosch (2004). Software Reuse: Methods, Techniques, and Tools: 8th International Conference. p.275.
  9. ^ Jorge S. Marques (2005). Pattern Recognition and Image Analysis: Second Iberian Conference, IbPRIA. p.493
  10. ^ Isabel Seruca (2006). Enterprise Information Systems VI. p. 175
  11. ^ Gavriel Salvendy (2001). Handbook of Industrial Engineering. p.508
  12. ^ Rajugan, R. et al. (2005) "A Three-Layered XML View Model: A Practical Approach".
  13. ^ Tok Wang Ling (504). Deductive and Object-oriented Databases: Fourth International Conference. p. 504.
Further comment

Now I noticed most types seems to be defined in the field systems and software engineering. -- Marcel Douwe Dekker (talk) 21:21, 2 March 2009 (UTC)

Copy-paste registration[edit]

-- Mdd (talk) 21:45, 6 November 2009 (UTC)