sábado, 31 de janeiro de 2009
terça-feira, 27 de janeiro de 2009
System - Wikipedia, the free encyclopedia
System - Wikipedia, the free encyclopedia: "System
From Wikipedia, the free encyclopedia
Jump to: navigation, search
For other uses, see System (disambiguation).
A schematic representation of a closed system and its boundary
System (from Latin systēma, in turn from Greek σύστημα systēma) is a set of interacting or interdependent entities, real or abstract, forming an integrated whole.
The concept of an 'integrated whole' can also be stated in terms of a system embodying a set of relationships which are differentiated from relationships of the set to other elements, and from relationships between an element of the set and elements not a part of the relational regime.
The scientific research field which is engaged in the study of the general properties of systems include systems theory, systems science and systemics. They investigate the abstract properties of the matter and organization, searching concepts and principles which are independent of the specific domain, substance, type, or temporal scales of existence.
Most systems share the same common characteristics. These common characteristics include the following
* Systems are abstractions of reality.
* Systems have structure which is defined by its parts and their composition.
* Systems have behavior, which involves inputs, processing and outputs of material, information or energy.
* The various parts of a system have functional as well as structural relationships between each other.
The term system may also refer to a set of rules that governs behavior or structure.
Contents
[hide]
* 1 History
* 2 System concepts
* 3 Types of systems
o 3.1 Cultural system
o 3.2 Economic system
* 4 Application of the system concept
o 4.1 Systems in information and computer science
o 4.2 Systems in engineering
o 4.3 Systems in social and cognitive sciences and management research
* 5 See also
* 6 References
* 7 Further reading
* 8 External links
[edit] History
The term System has a long history which can be traced back to the Greek language.
In the 19th century the first to develop the concept of a 'system' in the natural sciences was the French physicist Nicolas Léonard Sadi Carnot who studied thermodynamics. In 1824 he studied what he called the working substance (system), i.e. typically a body of water vapor, in steam engines, in regards to the system's ability to do work when heat is applied to it. The working substance could be put in contact with either a boiler, a cold reservoir (a stream of cold water), or a piston (to which the working body could do work by pushing on it). In 1850, the German physicist Rudolf Clausius generalized this picture to include the concept of the surroundings and began to use the term 'working body' when referring to the system.
One of the pioneers of the general systems theory was the biologist Ludwig von Bertalanffy. In 1945 he introduced models, principles, and laws that apply to generalized systems or their subclasses, irrespective of their particular kind, the nature of their component elements, and the relation or 'forces' between them.[1]
Significant development to the concept of a system was done by Norbert Wiener and Ross Ashby who pioneered the use of mathematics to study systems [2][3] .
In the 1980s the term complex adaptive system was coined at the interdisciplinary Santa Fe Institute by John H. Holland, Murray Gell-Mann and others.
[edit] System concepts
Environment and boundaries
Systems theory views the world as a complex system of interconnected parts. We scope a system by defining its boundary; this means choosing which entities are inside the system and which are outside - part of the environment. We then make simplified representations (models) of the system in order to understand it and to predict or impact its future behavior. These models may define the structure and/or the behaviour of the system.
Natural and man-made systems
There are natural and man-made (designed) systems. Natural systems may not have an apparent objective but their outputs can be interpreted as purposes. Man-made systems are made with purposes that are achieved by the delivery of outputs. Their parts must be related; they must be “designed to work as a coherent entity” - else they would be two or more distinct systems
Open system
An open system usually interacts with some entities in their environment. A closed system is isolated from its environment.
Process and transformation process
A system can also be viewed as a bounded transformation process, that is, a process or collection of processes that transforms inputs into outputs. Inputs are consumed; outputs are produced. The concept of input and output here is very broad. E.g., an output of a passenger ship is the movement of people from departure to destination.
Subsystem
A subsystem is a set of elements, which is a system itself, and a part of a larger system.
[edit] Types of systems
Evidently, there are many types of systems that can be analyzed both quantitatively and qualitatively. For example, with an analysis of urban systems dynamics, [A.W. Steiss] [4] defines five intersecting systems, including the physical subsystem and behavioral system. For sociological models influenced by systems theory, where Kenneth D. Bailey [5] defines systems in terms of conceptual, concrete and abstract systems; either isolated, closed, or open, Walter F. Buckley [6] defines social systems in sociology in terms of mechanical, organic, and process models. Bela H. Banathy [7] cautions that with any inquiry into a system that understanding the type of system is crucial and defines Natural and Designed systems.
In offering these more global definitions, the author maintains that it is important not to confuse one for the other. The theorist explains that natural systems include sub-atomic systems, living systems, the solar system, the galactic system and the Universe. Designed systems are our creations, our physical structures, hybrid systems which include natural and designed systems, and our conceptual knowledge. The human element of organization and activities are emphasized with their relevant abstract systems and representations. A key consideration in making distinctions among various types of systems is to determine how much freedom the system has to select purpose, goals, methods, tools, etc. and how widely is the freedom to select distributed (or concentrated) in the system.
George J. Klir [8] maintains that no 'classification is complete and perfect for all purposes,' and defines systems in terms of abstract, real, and conceptual physical systems, bounded and unbounded systems, discrete to continuous, pulse to hybrid systems, et cetera. The interaction between systems and their environments are categorized in terms of absolutely closed systems, relatively closed, and open systems. The case of an absolutely closed system is a rare, special case. Important distinctions have also been made between hard and soft systems.[9] Hard systems are associated with areas such as systems engineering, operations research and quantitative systems analysis. Soft systems are commonly associated with concepts developed by Peter Checkland through Soft Systems Methodology (SSM) involving methods such as action research and emphasizing participatory designs. Where hard systems might be identified as more 'scientific,' the distinction between them is actually often hard to define.
[edit] Cultural system
Main article: Cultural system
A cultural system may be defined as the interaction of different elements of culture. While a cultural system is quite different from a social system, sometimes both systems together are referred to as the sociocultural system. A major concern in the social sciences is the problem of order. One way that social order has been theorized is according to the degree of integration of cultural and social factors.
[edit] Economic system
Main article: Economic system
An economic system is a mechanism (social institution) which deals with the production, distribution and consumption of goods and services in a particular society. The economic system is composed of people, institutions and their relationships to resources, such as the convention of property. It addresses the problems of economics, like the allocation and scarcity of resources.
[edit] Application of the system concept
Systems modeling is generally a basic principle in engineering and in social sciences. The system is the representation of the entities under concern. Hence inclusion to or exclusion from system context is dependent of the intention of the modeler.
No model of a system will include all features of the real system of concern, and no model of a system must include all entities belonging to a real system of concern.
[edit] Systems in information and computer science
In computer science and information science, system could also be a method or an algorithm. Again, an example will illustrate: There are systems of counting, as with Roman numerals, and various systems for filing papers, or catalogues, and various library systems, of which the Dewey Decimal System is an example. This still fits with the definition of components which are connected together (in this case in order to facilitate the flow of information).
System can also be used referring to a framework, be it software or hardware, designed to allow software programs to run, see platform.
[edit] Systems in engineering
In engineering, the concept of a system is usually well defined. It is used in numerous different concrete contexts, and it is the subject of the basic engineering activities, such as: planning, design, implementation, building, and maintaining. Systems engineering is also a generalized theoretical branch of the different engineering approaches and paradigms.
[edit] Systems in social and cognitive sciences and management research
Social and cognitive sciences recognize systems in human person models and in human societies. They include human brain functions and human mental processes as well as normative ethics systems and social/cultural behavioral patterns.
In management science, operations research and organizational development (OD), human organizations are viewed as systems (conceptual systems) of interacting components such as subsystems or system aggregates, which are carriers of numerous complex processes and organizational structures. Organizational development theorist Peter Senge developed the notion of organizations as systems in his book The Fifth Discipline.
Systems thinking is a style of thinking/reasoning and problem solving. It starts from the recognition of system properties in a given problem. It can be a leadership competency. Some people can think globally while acting locally. Such people consider the potential consequences of their decisions on other parts of larger systems. This is also a basis of systemic coaching in psychology.
Organizational theorists such as Margaret Wheatley have also described the workings of organizational systems in new metaphoric contexts, such as quantum physics, chaos theory, and the self-organization of systems.
[edit] See also
Examples of systems
* List of systems (WPS list)
* Complex system
* Computer system
* Meta-systems
* Solar system
* Systems in human anatomy
Theories about systems
* Chaos theory
* Cybernetics
* Systems ecology
* Systems intelligence
* Systems theory
* Formal system
* World-systems theory
Systems science portal
Related topics
* Complexity and organization
* Network
* Glossary of systems theory
* System of Systems
* System of Systems Engineering
* Systems art
[edit] References
1. ^ 1945, Zu einer allgemeinen Systemlehre, Blätter für deutsche Philosophie, 3/4. (Extract in: Biologia Generalis, 19 (1949), 139-164.
2. ^ 1948, Cybernetics: Or the Control and Communication in the Animal and the Machine. Paris, France: Librairie Hermann & Cie, and Cambridge, MA: MIT Press.Cambridge, MA: MIT Press.
3. ^ 1956. An Introduction to Cybernetics, Chapman & Hall.
4. ^ Steiss 1967, p.8-18.
5. ^ Bailey, 1994.
6. ^ Buckley, 1967.
7. ^ Banathy, 1997.
8. ^ Klir 1969, pp. 69-72
9. ^ Checkland 1997; Flood 1999.
[edit] Further reading
* Alexander Backlund (2000). 'The definition of system'. In: Kybernetes Vol. 29 nr. 4, pp. 444-451.
* Kenneth D. Bailey (1994). Sociology and the New Systems Theory: Toward a Theoretical Synthesis. New York: State of New York Press.
* Bela H. Banathy (1997). 'A Taste of Systemics', ISSS The Primer Project.
* Walter F. Buckley (1967). Sociology and Modern Systems Theory, New Jersey: Englewood Cliffs.
* Peter Checkland (1997). Systems Thinking, Systems Practice. Chichester: John Wiley & Sons, Ltd.
* Robert L. Flood (1999). Rethinking the Fifth Discipline: Learning within the unknowable. London: Routledge.
* George J. Klir (1969). Approach to General Systems Theory, 1969.
[edit] External links
Sister project Look up system in
Wiktionary, the free dictionary.
* Definitions of Systems and Models by Michael Pidwirny, 1999-2007.
* Definitionen von 'System' (1572-2002) by Roland Müller, 2001-2007 (most in German)."
Model-driven architecture - Wikipedia, the free encyclopedia
Model-driven architecture - Wikipedia, the free encyclopedia: "Model-driven architecture
From Wikipedia, the free encyclopedia
(Redirected from Model-Driven Architecture)
Jump to: navigation, search
Model-driven architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model-driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.[1]
Contents
[hide]
* 1 Overview
o 1.1 Related standards
o 1.2 Trademark
* 2 Model-driven architecture topics
o 2.1 MDA approach
o 2.2 MDA tools
o 2.3 MDA concerns
* 3 Conferences
* 4 Code generation controversy
* 5 See also
* 6 References
* 7 Further reading
* 8 External links
[edit] Overview
The Model-Driven Architecture approach defines system functionality using a platform-independent model (PIM) using an appropriate domain-specific language.
Then, given a platform definition model (PDM) corresponding to CORBA, .NET, the Web, etc., the PIM is translated to one or more platform-specific models (PSMs) that computers can run. (EDIT: This requires mappings and transformations and should be modeled too.)
The PSM may use different Domain Specific Languages, or a General Purpose Language like Java, C#, PHP, Python, etc.[citation needed]. Automated tools generally perform this translation.
The OMG organization provides rough specifications rather than implementations, often as answers to Requests for Proposals (RFPs). Implementations come from private companies or open source groups.
MDA principles can also apply to other areas such as business process modeling where the PIM is translated to either automated or manual processes[citation needed].
[edit] Related standards
The MDA model is related to multiple standards, including the Unified Modeling Language (UML), the Meta-Object Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC), the Software Process Engineering Metamodel (SPEM), and the Common Warehouse Metamodel (CWM). Note that the term “architecture” in Model-driven architecture does not refer to the architecture of the system being modeled, but rather to the architecture of the various standards and model forms that serve as the technology basis for MDA.
Executable UML is an other specific approach to implement MDA
[edit] Trademark
The Object Management Group holds trademarks on MDA, as well as several similar terms including Model Driven Development (MDD), Model Driven Application Development, Model Based Application Development, Model Based Programming, and others. The main acronym that has not yet been deposited by OMG until now is MDE. As a consequence, the research community uses MDE to refer to general model engineering ideas, without committing to strict OMG standards.[citation needed]
[edit] Model-driven architecture topics
[edit] MDA approach
OMG focuses Model-driven architecture on forward engineering, i.e. producing code from abstract, human-elaborated specifications[citation needed]. OMG's ADTF (Analysis and Design Task Force) group leads this effort. With some humour, the group chose ADM (MDA backwards) to name the study of reverse engineering. ADM decodes to Architecture-Driven Modernization. The objective of ADM is to produce standards for model-based reverse engineering of legacy systems [2]. Knowledge Discovery Metamodel (KDM) is the furthest along of these efforts, and describes information systems in terms of various assets (programs, specifications, data, test files, database schemas, etc.).
One of the main aims of the MDA is to separate design from architecture. As the concepts and technologies used to realize designs and the concepts and technologies used to realize architectures have changed at their own pace, decoupling them allows system developers to choose from the best and most fitting in both domains. The design addresses the functional (use case) requirements while architecture provides the infrastructure through which non-functional requirements like scalability, reliability and performance are realized. MDA envisages that the platform independent model (PIM), which represents a conceptual design realizing the functional requirements, will survive changes in realization technologies and software architectures.
Of particular importance to model-driven architecture is the notion of model transformation. A specific standard language for model transformation has been defined by OMG called QVT.
[edit] MDA tools
The OMG organization provides rough specifications rather than implementations, often as answers to Requests for Proposals (RFPs). The OMG documents the overall process in a document called the MDA Guide.
Basically, an MDA tool is a tool used to develop, interpret, compare, align, measure, verify, transform, etc. models or metamodels.[3] In the following section 'model' is interpreted as meaning any kind of model (e.g. a UML model) or metamodel (e.g. the CWM metamodel). In any MDA approach we have essentially two kinds of models: initial models are created manually by human agents while derived models are created automatically by programs. For example an analyst may create a UML initial model from its observation of some loose business situation while a Java model may be automatically derived from this UML model by a Model transformation operation.
An MDA tool may be one or more of the following types[citation needed]:
* Creation Tool: A tool used to elicit initial models and/or edit derived models.
* Analysis Tool: A tool used to check models for completeness, inconsistencies, or error and warning conditions. Also used to calculate metrics for the model.
* Transformation Tool: A tool used to transform models into other models or into code and documentation.
* Composition Tool: A tool used to compose (i.e. to merge according to a given composition semantics) several source models, preferably conforming to the same metamodel.
* Test Tool: A tool used to 'test' models as described in Model-based testing.
* Simulation Tool: A tool used to simulate the execution of a system represented by a given model. This is related to the subject of model execution.
* Metadata Management Tool: A tool intended to handle the general relations between different models, including the metadata on each model (e.g. author, date of creation or modification, method of creation (which tool? which transformation? etc.)) and the mutual relations between these models (i.e. one metamodel is a version of another one, one model has been derived from another one by a transformation, etc.)
* Reverse Engineering Tool: A tool intended to transform particular legacy or information artifact portfolios into full-fledged models.
Some tools perform more than one of the functions listed above. For example, some creation tools may also have transformation and test capabilities. There are other tools that are solely for creation, solely for graphical presentation, solely for transformation, etc.
One of the characteristics of MDA tools is that they mainly take models (e.g. MOF models or metamodels) as input and generate models as output[citation needed]. In some cases however the parameters may be taken outside the MDA space like in model to text or text to model transformation tools.
Implementations of the OMG specifications come from private companies or open source groups. One important source of implementations for OMG specifications is the Eclipse Foundation. Many implementations of OMG modeling standards may be found in the Eclipse Modeling Framework (EMF) or Graphical Modeling Framework (GMF), the Eclipse foundation is also developing other tools of various profiles as GMT. Eclipse's compliance to OMG specifications is often not strict. This is true for example for OMG's EMOF standard, which Eclipse approximates with its ECORE implementation. More examples may be found in the M2M project implementing the QVT standard or in the M2T project implementing the MOF2Text standard.
Power RAD is being developed by Outline Systems Inc. Microsoft is proposing the DSL tools approach which is a similar approach, not based on OMG standards. Another open source project called AndroMDA provides an extensible framework for generating code using virtually any technology/platform (e.g., .NET, Java, etc.) and is meant to be used repeatedly as part of the build process (i.e., instead of just generating starter code once at the beginning of a project).
One should be careful not to confuse the List of MDA Tools and the List of UML tools, the former being much broader. This distinction can be made more general by distinguishing 'variable metamodel tools' and 'fixed metamodel tools'. A UML CASE tool is typically a 'fixed metamodel tool' since it has been hard-wired to work only with a given version of the UML metamodel (e.g. UML 2.1). On the contrary, other tools have internal generic capabilities allowing them to adapt to arbitrary metamodels or to a particular kind of metamodels.
Usually MDA tools focus rudimentary architecture specification, although in some cases the tools are architecture-independent (or platform independent).
Simple examples of architecture specifications include:
* Selecting one of a number of supported reference architectures like Java EE or Microsoft .NET,
* Specifying the architecture at a finer level including the choice of presentation layer technology, business logic layer technology, persistence technology and persistence mapping technology (e.g. object-relational mapper).
* Metadata: information about data.
[edit] MDA concerns
Some key concepts that underpin the MDA approach (launched in 2001) were first elucidated by the Shlaer-Mellor method during the late 1980s. Indeed a key absent technical standard of the MDA approach (that of an action language syntax for Executable UML) has been bridged by some vendors by adapting the original Shlaer-Mellor Action Language (modified for UML)[citation needed]. However during this period the MDA approach has not gained mainstream industry acceptance; with the Gartner Group still identifying MDA as an 'on the rise' technology in its 2006 'Hype Cycle'[4], and Forrester Research declaring MDA to be 'D.O.A.' in 2006[5]. Potential concerns that have been raised with the OMG MDA approach include:
* Incomplete Standards: The MDA approach is underpinned by a variety of technical standards, some of which are yet to be specified (e.g. an action semantic language for xtUML), or are yet to be implemented in a standard manner (e.g. a QVT transformation engine or a PIM with a virtual execution environment).[6][7]
* Vendor Lock-in: Although MDA was conceived as an approach for achieving (technical) platform independence, current MDA vendors have been reluctant to engineer their MDA toolsets to be interoperable. Such an outcome could result in vendor lock-in for those pursuing an MDA approach.[citation needed]
* Idealistic: MDA is conceived as a forward engineering approach in which models that incorporate Action Language programming are transformed into implementation artifacts (e.g. executable code, database schema) in one direction via a fully or partially automated 'generation' step. This aligns with OMG's vision that MDA should allow modelling of a problem domain's full complexity in UML (and related standards) with subsequent transformation to a complete (executable) application[8]. This approach does, however, imply that changes to implementation artifacts (e.g. database schema tuning) are not supported . This constitutes a problem in situations where such post-transformation 'adapting' of implementation artifacts is seen to be necessary. Evidence that the full MDA approach may be too idealistic for some real world deployments has been seen in the rise of so-called 'pragmatic MDA'[9]. Pragmatic MDA blends the literal standards from OMG's MDA with more traditional model driven mechanisms such as round-trip engineering that provides support for adapting implementation artifacts.
* Specialised Skillsets: Practitioners of MDA based software engineering are (as with other toolsets) required to have a high level of expertise in their field. Current expert MDA practitioners (often referred to as Modeller/Architects) are scarce relative to the availability of traditional developers.[10]
* OMG Track Record: The OMG consortium who sponsor the MDA approach (and own the MDA trademark) also introduced and sponsored the CORBA standard which itself failed to materialise as a widely utilised standard[11].
* Uncertain Value Proposition: As discussed, the vision of MDA allows for the specification of a system as an abstract model, which may be realized as a concrete implementation (program) for a particular computing platform (i.e. .NET). Thus an application that has been successfully developed via a pure MDA approach could theoretically be ported to a newer release .NET platform (or even a Java platform) in a deterministic manner – although significant questions remain as to real-world practicalities during translation (such as user interface implementation). Whether this capability represents a significant value proposition remains a question for particular adopters. Regardless, adopters of MDA who are seeking value via an 'alternative to programming' should be very careful when assessing this approach. The complexity of any given problem domain will always remain, and the programming of business logic needs to be undertaken in MDA as with any other approach. The difference with MDA is that the programming language used (e.g. xtUML) is more abstract (than, say, Java or C#) and exists interwoven with traditional UML artifacts (e.g. class diagrams). Whether programming in a language that is more abstract than mainstream 3GL languages will result in systems of better quality, cheaper cost or faster delivery, is a question that has yet to be adequately answered.
[edit] Conferences
Among the various conferences on this topic we may mention ECMDA, the European Conference on MDA and also MoDELS, former firmed as <<UML>> conference series (till 2004), the Italian Forum on MDA in collaboration with the OMG. There are also several conferences and workshops (at OOPSLA, ECOOP mainly) focusing on more specific aspects of MDA like model transformation, model composition, and generation.
[edit] Code generation controversy
Code generation means, that the user creates UML diagrams, which have some connoted model data, and the UML tool derives from the diagrams parts or all of the source code for the software system. In some tools, the user can provide a skeleton of the program source code, in the form of a source code template where predefined tokens are then replaced with program source code parts during the code generation process.
There is some debate among software developers about how useful code generation as such is. It certainly depends on the specific problem domain and how far code generation should be applied. There are well known areas where code generation is an established practice, not limited to the field of UML.
The idea of completely leaving the 'code level' and start 'programming' on the UML diagram level (i.e., design level) is quite debated among developers. That is the vision for MDA. This idea is not in such widespread use compared to other software development tools like compilers or software configuration management systems.
An often cited criticism is that the UML diagrams just lack the detail which is needed to contain the same information as is covered with the program source. Some developers even claim that 'the Code is the design' [12][13].
[edit] See also
* Algebra of Systems
* ATLAS Transformation Language
* Code generation
* CodeGear ECO
* Customer Relationship Management * Compiere
* Domain-driven design
* Enterprise Resource Planning
* Executable UML
* Jean-Marc Jézéquel
* Meta-Object Facility
* Metamodeling
* Model-driven engineering
* Model-driven integration
* Model Transformation Language
* Modeling Maturity Levels
* OpenBlueLab
* openCRX
* Platform Independent Model
* Platform Specific Model
* Software factory
* Unified Modeling Language
* QVT
* Web engineering
* WebML
[edit] References
1. ^ 'OMG pursues new strategic direction to build on success of past efforts'
2. ^ adm website http://adm.omg.org
3. ^ Bézivin, J, Gérard, S, Muller, P-A, and Rioux, L (2003). 'MDA components: Challenges and Opportunities'. In: Metamodelling for MDA.
4. ^ 'Hype Cycle for Emerging Technologies, 2006' $495.00
5. ^ 'MDA Is DOA, Partly Thanks To SOA'
6. ^ 'UML - Unified or Universal Modeling Language? UML2, OCL, MOF, EDOC - The Emperor Has Too Many Clothes'
7. ^ 'MDA: Nice Idea. Shame about the...'
8. ^ 'Bringing MDA to Eclipse, using a pragmatic approach'
9. ^ 'A Response to Forrester'
10. ^ 'Are You Ready For the MDA?'
11. ^ 'The Rise and Fall of CORBA'
12. ^ http://www.developerdotstar.com/mag/articles/reeves_design_main.html by Jack W. Reeves
13. ^ Bleading-Edge
[edit] Further reading
* David S. Frankel. Model Driven Architecture: Applying MDA to Enterprise Computing. John Wiley & Sons, ISBN 0-471-31920-1
* Meghan Kiffer The MDA Journal: Model Driven Architecture Straight From The Masters. ISBN 0-929652-25-8
* Anneke Kleppe (2003). MDA Explained, The Model Driven Architecture: Practice and Promise. Addison-Wesley. ISBN 0-321-19442-X
* Steve Mellor (2004). MDA Distilled, Principles of Model Driven Architecture. Addison-Wesley Professional. ISBN 0-201-78891-8
* Chris Raistrick. Model Driven Architecture With Executable UML. Cambridge University Press, ISBN 0-521-53771-1
* Stanley J. Sewall. Executive Justification for MDA
[edit] External links
The external links in this article may not follow Wikipedia's content policies or guidelines.
Please improve this article by removing excessive or inappropriate external links.
* MDA FAQ at OMG Website
* Mendix:Provider of Model Driven application platform
* The official MDA Guide Version 1.0.1
* OMG's MDA Web site
* An Introduction to Model Driven Architecture at ibm.com
* Animated Introduction - MDA Explained (4 minutes) at PathfinderMDA.com
* OMG's list of MDA tools and products
* Understanding the Model Driven Architecture (MDA)
* When Model Driven Architecture turn out right by Giancarlo Frison
* Domain-Specific Modeling and Model Driven Architecture by Steve Cook
* Domain Specific Modeling in IoC Frameworks
* Planet MDE's list of MDA tools
* Model-Driven Architecture: Vision, Standards And Emerging Technologies at omg.org
* On the Unification Power of Models.
* Acceleo - OpenSource MDA Code generator based on Eclipse and EMF
* BLU AGE(tm) - 100% Application Generator based on UML/OCL/MDA technologies
* ECO - Model-Driven Development framework from CodeGear (Borland) company
* configX - MDA framework for creating web applications
* Executive Justification for MDA
* Select Business Solutions - Select Solution for MDA based on Select Architect's UML and code synchronization capabilities
* Discussion of Compiere, an MDA enterprise application environment, which directly executes the model (without code generation)
* International School on Model-Driven Design for Distributed, Realtime, Embedded Systems (MDD4DRES)"
From Wikipedia, the free encyclopedia
(Redirected from Model-Driven Architecture)
Jump to: navigation, search
Model-driven architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model-driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.[1]
Contents
[hide]
* 1 Overview
o 1.1 Related standards
o 1.2 Trademark
* 2 Model-driven architecture topics
o 2.1 MDA approach
o 2.2 MDA tools
o 2.3 MDA concerns
* 3 Conferences
* 4 Code generation controversy
* 5 See also
* 6 References
* 7 Further reading
* 8 External links
[edit] Overview
The Model-Driven Architecture approach defines system functionality using a platform-independent model (PIM) using an appropriate domain-specific language.
Then, given a platform definition model (PDM) corresponding to CORBA, .NET, the Web, etc., the PIM is translated to one or more platform-specific models (PSMs) that computers can run. (EDIT: This requires mappings and transformations and should be modeled too.)
The PSM may use different Domain Specific Languages, or a General Purpose Language like Java, C#, PHP, Python, etc.[citation needed]. Automated tools generally perform this translation.
The OMG organization provides rough specifications rather than implementations, often as answers to Requests for Proposals (RFPs). Implementations come from private companies or open source groups.
MDA principles can also apply to other areas such as business process modeling where the PIM is translated to either automated or manual processes[citation needed].
[edit] Related standards
The MDA model is related to multiple standards, including the Unified Modeling Language (UML), the Meta-Object Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC), the Software Process Engineering Metamodel (SPEM), and the Common Warehouse Metamodel (CWM). Note that the term “architecture” in Model-driven architecture does not refer to the architecture of the system being modeled, but rather to the architecture of the various standards and model forms that serve as the technology basis for MDA.
Executable UML is an other specific approach to implement MDA
[edit] Trademark
The Object Management Group holds trademarks on MDA, as well as several similar terms including Model Driven Development (MDD), Model Driven Application Development, Model Based Application Development, Model Based Programming, and others. The main acronym that has not yet been deposited by OMG until now is MDE. As a consequence, the research community uses MDE to refer to general model engineering ideas, without committing to strict OMG standards.[citation needed]
[edit] Model-driven architecture topics
[edit] MDA approach
OMG focuses Model-driven architecture on forward engineering, i.e. producing code from abstract, human-elaborated specifications[citation needed]. OMG's ADTF (Analysis and Design Task Force) group leads this effort. With some humour, the group chose ADM (MDA backwards) to name the study of reverse engineering. ADM decodes to Architecture-Driven Modernization. The objective of ADM is to produce standards for model-based reverse engineering of legacy systems [2]. Knowledge Discovery Metamodel (KDM) is the furthest along of these efforts, and describes information systems in terms of various assets (programs, specifications, data, test files, database schemas, etc.).
One of the main aims of the MDA is to separate design from architecture. As the concepts and technologies used to realize designs and the concepts and technologies used to realize architectures have changed at their own pace, decoupling them allows system developers to choose from the best and most fitting in both domains. The design addresses the functional (use case) requirements while architecture provides the infrastructure through which non-functional requirements like scalability, reliability and performance are realized. MDA envisages that the platform independent model (PIM), which represents a conceptual design realizing the functional requirements, will survive changes in realization technologies and software architectures.
Of particular importance to model-driven architecture is the notion of model transformation. A specific standard language for model transformation has been defined by OMG called QVT.
[edit] MDA tools
The OMG organization provides rough specifications rather than implementations, often as answers to Requests for Proposals (RFPs). The OMG documents the overall process in a document called the MDA Guide.
Basically, an MDA tool is a tool used to develop, interpret, compare, align, measure, verify, transform, etc. models or metamodels.[3] In the following section 'model' is interpreted as meaning any kind of model (e.g. a UML model) or metamodel (e.g. the CWM metamodel). In any MDA approach we have essentially two kinds of models: initial models are created manually by human agents while derived models are created automatically by programs. For example an analyst may create a UML initial model from its observation of some loose business situation while a Java model may be automatically derived from this UML model by a Model transformation operation.
An MDA tool may be one or more of the following types[citation needed]:
* Creation Tool: A tool used to elicit initial models and/or edit derived models.
* Analysis Tool: A tool used to check models for completeness, inconsistencies, or error and warning conditions. Also used to calculate metrics for the model.
* Transformation Tool: A tool used to transform models into other models or into code and documentation.
* Composition Tool: A tool used to compose (i.e. to merge according to a given composition semantics) several source models, preferably conforming to the same metamodel.
* Test Tool: A tool used to 'test' models as described in Model-based testing.
* Simulation Tool: A tool used to simulate the execution of a system represented by a given model. This is related to the subject of model execution.
* Metadata Management Tool: A tool intended to handle the general relations between different models, including the metadata on each model (e.g. author, date of creation or modification, method of creation (which tool? which transformation? etc.)) and the mutual relations between these models (i.e. one metamodel is a version of another one, one model has been derived from another one by a transformation, etc.)
* Reverse Engineering Tool: A tool intended to transform particular legacy or information artifact portfolios into full-fledged models.
Some tools perform more than one of the functions listed above. For example, some creation tools may also have transformation and test capabilities. There are other tools that are solely for creation, solely for graphical presentation, solely for transformation, etc.
One of the characteristics of MDA tools is that they mainly take models (e.g. MOF models or metamodels) as input and generate models as output[citation needed]. In some cases however the parameters may be taken outside the MDA space like in model to text or text to model transformation tools.
Implementations of the OMG specifications come from private companies or open source groups. One important source of implementations for OMG specifications is the Eclipse Foundation. Many implementations of OMG modeling standards may be found in the Eclipse Modeling Framework (EMF) or Graphical Modeling Framework (GMF), the Eclipse foundation is also developing other tools of various profiles as GMT. Eclipse's compliance to OMG specifications is often not strict. This is true for example for OMG's EMOF standard, which Eclipse approximates with its ECORE implementation. More examples may be found in the M2M project implementing the QVT standard or in the M2T project implementing the MOF2Text standard.
Power RAD is being developed by Outline Systems Inc. Microsoft is proposing the DSL tools approach which is a similar approach, not based on OMG standards. Another open source project called AndroMDA provides an extensible framework for generating code using virtually any technology/platform (e.g., .NET, Java, etc.) and is meant to be used repeatedly as part of the build process (i.e., instead of just generating starter code once at the beginning of a project).
One should be careful not to confuse the List of MDA Tools and the List of UML tools, the former being much broader. This distinction can be made more general by distinguishing 'variable metamodel tools' and 'fixed metamodel tools'. A UML CASE tool is typically a 'fixed metamodel tool' since it has been hard-wired to work only with a given version of the UML metamodel (e.g. UML 2.1). On the contrary, other tools have internal generic capabilities allowing them to adapt to arbitrary metamodels or to a particular kind of metamodels.
Usually MDA tools focus rudimentary architecture specification, although in some cases the tools are architecture-independent (or platform independent).
Simple examples of architecture specifications include:
* Selecting one of a number of supported reference architectures like Java EE or Microsoft .NET,
* Specifying the architecture at a finer level including the choice of presentation layer technology, business logic layer technology, persistence technology and persistence mapping technology (e.g. object-relational mapper).
* Metadata: information about data.
[edit] MDA concerns
Some key concepts that underpin the MDA approach (launched in 2001) were first elucidated by the Shlaer-Mellor method during the late 1980s. Indeed a key absent technical standard of the MDA approach (that of an action language syntax for Executable UML) has been bridged by some vendors by adapting the original Shlaer-Mellor Action Language (modified for UML)[citation needed]. However during this period the MDA approach has not gained mainstream industry acceptance; with the Gartner Group still identifying MDA as an 'on the rise' technology in its 2006 'Hype Cycle'[4], and Forrester Research declaring MDA to be 'D.O.A.' in 2006[5]. Potential concerns that have been raised with the OMG MDA approach include:
* Incomplete Standards: The MDA approach is underpinned by a variety of technical standards, some of which are yet to be specified (e.g. an action semantic language for xtUML), or are yet to be implemented in a standard manner (e.g. a QVT transformation engine or a PIM with a virtual execution environment).[6][7]
* Vendor Lock-in: Although MDA was conceived as an approach for achieving (technical) platform independence, current MDA vendors have been reluctant to engineer their MDA toolsets to be interoperable. Such an outcome could result in vendor lock-in for those pursuing an MDA approach.[citation needed]
* Idealistic: MDA is conceived as a forward engineering approach in which models that incorporate Action Language programming are transformed into implementation artifacts (e.g. executable code, database schema) in one direction via a fully or partially automated 'generation' step. This aligns with OMG's vision that MDA should allow modelling of a problem domain's full complexity in UML (and related standards) with subsequent transformation to a complete (executable) application[8]. This approach does, however, imply that changes to implementation artifacts (e.g. database schema tuning) are not supported . This constitutes a problem in situations where such post-transformation 'adapting' of implementation artifacts is seen to be necessary. Evidence that the full MDA approach may be too idealistic for some real world deployments has been seen in the rise of so-called 'pragmatic MDA'[9]. Pragmatic MDA blends the literal standards from OMG's MDA with more traditional model driven mechanisms such as round-trip engineering that provides support for adapting implementation artifacts.
* Specialised Skillsets: Practitioners of MDA based software engineering are (as with other toolsets) required to have a high level of expertise in their field. Current expert MDA practitioners (often referred to as Modeller/Architects) are scarce relative to the availability of traditional developers.[10]
* OMG Track Record: The OMG consortium who sponsor the MDA approach (and own the MDA trademark) also introduced and sponsored the CORBA standard which itself failed to materialise as a widely utilised standard[11].
* Uncertain Value Proposition: As discussed, the vision of MDA allows for the specification of a system as an abstract model, which may be realized as a concrete implementation (program) for a particular computing platform (i.e. .NET). Thus an application that has been successfully developed via a pure MDA approach could theoretically be ported to a newer release .NET platform (or even a Java platform) in a deterministic manner – although significant questions remain as to real-world practicalities during translation (such as user interface implementation). Whether this capability represents a significant value proposition remains a question for particular adopters. Regardless, adopters of MDA who are seeking value via an 'alternative to programming' should be very careful when assessing this approach. The complexity of any given problem domain will always remain, and the programming of business logic needs to be undertaken in MDA as with any other approach. The difference with MDA is that the programming language used (e.g. xtUML) is more abstract (than, say, Java or C#) and exists interwoven with traditional UML artifacts (e.g. class diagrams). Whether programming in a language that is more abstract than mainstream 3GL languages will result in systems of better quality, cheaper cost or faster delivery, is a question that has yet to be adequately answered.
[edit] Conferences
Among the various conferences on this topic we may mention ECMDA, the European Conference on MDA and also MoDELS, former firmed as <<UML>> conference series (till 2004), the Italian Forum on MDA in collaboration with the OMG. There are also several conferences and workshops (at OOPSLA, ECOOP mainly) focusing on more specific aspects of MDA like model transformation, model composition, and generation.
[edit] Code generation controversy
Code generation means, that the user creates UML diagrams, which have some connoted model data, and the UML tool derives from the diagrams parts or all of the source code for the software system. In some tools, the user can provide a skeleton of the program source code, in the form of a source code template where predefined tokens are then replaced with program source code parts during the code generation process.
There is some debate among software developers about how useful code generation as such is. It certainly depends on the specific problem domain and how far code generation should be applied. There are well known areas where code generation is an established practice, not limited to the field of UML.
The idea of completely leaving the 'code level' and start 'programming' on the UML diagram level (i.e., design level) is quite debated among developers. That is the vision for MDA. This idea is not in such widespread use compared to other software development tools like compilers or software configuration management systems.
An often cited criticism is that the UML diagrams just lack the detail which is needed to contain the same information as is covered with the program source. Some developers even claim that 'the Code is the design' [12][13].
[edit] See also
* Algebra of Systems
* ATLAS Transformation Language
* Code generation
* CodeGear ECO
* Customer Relationship Management * Compiere
* Domain-driven design
* Enterprise Resource Planning
* Executable UML
* Jean-Marc Jézéquel
* Meta-Object Facility
* Metamodeling
* Model-driven engineering
* Model-driven integration
* Model Transformation Language
* Modeling Maturity Levels
* OpenBlueLab
* openCRX
* Platform Independent Model
* Platform Specific Model
* Software factory
* Unified Modeling Language
* QVT
* Web engineering
* WebML
[edit] References
1. ^ 'OMG pursues new strategic direction to build on success of past efforts'
2. ^ adm website http://adm.omg.org
3. ^ Bézivin, J, Gérard, S, Muller, P-A, and Rioux, L (2003). 'MDA components: Challenges and Opportunities'. In: Metamodelling for MDA.
4. ^ 'Hype Cycle for Emerging Technologies, 2006' $495.00
5. ^ 'MDA Is DOA, Partly Thanks To SOA'
6. ^ 'UML - Unified or Universal Modeling Language? UML2, OCL, MOF, EDOC - The Emperor Has Too Many Clothes'
7. ^ 'MDA: Nice Idea. Shame about the...'
8. ^ 'Bringing MDA to Eclipse, using a pragmatic approach'
9. ^ 'A Response to Forrester'
10. ^ 'Are You Ready For the MDA?'
11. ^ 'The Rise and Fall of CORBA'
12. ^ http://www.developerdotstar.com/mag/articles/reeves_design_main.html by Jack W. Reeves
13. ^ Bleading-Edge
[edit] Further reading
* David S. Frankel. Model Driven Architecture: Applying MDA to Enterprise Computing. John Wiley & Sons, ISBN 0-471-31920-1
* Meghan Kiffer The MDA Journal: Model Driven Architecture Straight From The Masters. ISBN 0-929652-25-8
* Anneke Kleppe (2003). MDA Explained, The Model Driven Architecture: Practice and Promise. Addison-Wesley. ISBN 0-321-19442-X
* Steve Mellor (2004). MDA Distilled, Principles of Model Driven Architecture. Addison-Wesley Professional. ISBN 0-201-78891-8
* Chris Raistrick. Model Driven Architecture With Executable UML. Cambridge University Press, ISBN 0-521-53771-1
* Stanley J. Sewall. Executive Justification for MDA
[edit] External links
The external links in this article may not follow Wikipedia's content policies or guidelines.
Please improve this article by removing excessive or inappropriate external links.
* MDA FAQ at OMG Website
* Mendix:Provider of Model Driven application platform
* The official MDA Guide Version 1.0.1
* OMG's MDA Web site
* An Introduction to Model Driven Architecture at ibm.com
* Animated Introduction - MDA Explained (4 minutes) at PathfinderMDA.com
* OMG's list of MDA tools and products
* Understanding the Model Driven Architecture (MDA)
* When Model Driven Architecture turn out right by Giancarlo Frison
* Domain-Specific Modeling and Model Driven Architecture by Steve Cook
* Domain Specific Modeling in IoC Frameworks
* Planet MDE's list of MDA tools
* Model-Driven Architecture: Vision, Standards And Emerging Technologies at omg.org
* On the Unification Power of Models.
* Acceleo - OpenSource MDA Code generator based on Eclipse and EMF
* BLU AGE(tm) - 100% Application Generator based on UML/OCL/MDA technologies
* ECO - Model-Driven Development framework from CodeGear (Borland) company
* configX - MDA framework for creating web applications
* Executive Justification for MDA
* Select Business Solutions - Select Solution for MDA based on Select Architect's UML and code synchronization capabilities
* Discussion of Compiere, an MDA enterprise application environment, which directly executes the model (without code generation)
* International School on Model-Driven Design for Distributed, Realtime, Embedded Systems (MDD4DRES)"
Model-driven engineering - Wikipedia, the free encyclopedia
Model-driven engineering - Wikipedia, the free encyclopedia: "Model-driven engineering
From Wikipedia, the free encyclopedia
(Redirected from Model Driven Engineering)
Jump to: navigation, search
The introduction to this article provides insufficient context for those unfamiliar with the subject.
Please help improve the article with a good introductory style.
Model-driven engineering (MDE) is a software development methodology which focuses on creating models, or abstractions, more close to some particular domain concepts rather than computing (or algorithmic) concepts. It is meant to increase productivity by maximizing compatibility between systems, simplifying the process of design, and promoting communication between individuals and teams working on the system.
A modeling paradigm for MDE is considered effective if its models make sense from the point of view of the user and can serve as a basis for implementing systems. The models are developed through extensive communication among product managers, designers, and members of the development team. As the models approach completion, they enable the development of software and systems.
The best known MDE initiative is the Object Management Group (OMG) initiative Model-Driven Architecture (MDA), which is a registered trademark of OMG.[1]
Contents
[hide]
* 1 History of MDE
* 2 MDE as used in software engineering
* 3 See also
* 4 References
* 5 Further reading
* 6 External links
[edit] History of MDE
The first tools to support MDE were the Computer-Aided Software Engineering (CASE) tools developed in the 1980s. Companies like Integrated Development Environments (IDE - StP), Cadre Technologies, Bachman Information Systems, and Logicworks (BP-Win and ER-Win) were pioneers in the field. But CASE had the same problem that current MDA/MDE tools have today: the model gets out of sync with the application (see below). The government got involved in the modeling definitions creating the IDEF specifications. With several variations of the modeling definitions (see Grady Booch, Jim Rumbaugh, Ganes, Sarson, Harel, Shlaer, Mellor, and others) they were eventually joined creating the Unified Modeling Language (UML). Rational Rose, the dominant product for UML implementation, was done by Rational Corporation (Booch) which in 2002 was acquired by IBM.
[edit] MDE as used in software engineering
As it pertains to software development, model-driven engineering refers to a range of development approaches that are based on the use of software modeling as a primary form of expression. Sometimes models are constructed to a certain level of detail, and then code is written by hand in a separate step. Sometimes complete models are built including executable actions. Code can be generated from the models, ranging from system skeletons to complete, deployable products. With the introduction of the Unified Modeling Language (UML), MDE has become very popular today with a wide body of practitioners and supporting tools. More advanced types of MDE have expanded to permit industry standards which allow for consistent application and results. The continued evolution of MDE has added an increased focus on architecture and automation.
MDE technologies with a greater focus on architecture and corresponding automation yield higher levels of abstraction in software development. This abstraction promotes simpler models with a greater focus on problem space. Combined with executable semantics this elevates the total level of automation possible. The Object Management Group (OMG) has developed a set of standards called model-driven architecture (MDA), building a foundation for this advanced architecture-focused approach.
Model-integrated computing is yet another branch of MDE.
According to Douglas C. Schmidt, model-driven engineering technologies offer a promising approach to address the inability of third-generation languages to alleviate the complexity of platforms and express domain concepts effectively[2].
[edit] See also
* Model transformation (QVT)
* Language-oriented programming (LOP)
* Domain-Specific Modeling (DSM)
* Domain Specific Language (DSL)
* Model-based testing (MBT)
* Software factory (SF)
* Business-driven development (BDD)
* Generic Eclipse Modeling System (GEMS)
* Eclipse Modeling Framework (EMF)
* Graphical Modeling Framework (GMF)
* Modeling Maturity Level (MML)
* Service-Oriented Modeling Framework (SOMF)
* Application Lifecycle Management (ALM)
[edit] References
1. ^ Object Management Group (2006-05-24). 'OMG Trademarks'. Retrieved on 2008-02-26.
2. ^ Schmidt, D.C. (February 2006). 'Model-Driven Engineering'. IEEE Computer 39 (2). http://www.cs.wustl.edu/~schmidt/PDF/GEI.pdf. Retrieved on 16 May 2006. , 'A promising approach to address platform complexity — and the inability of third-generation languages to alleviate this complexity and express domain concepts effectively — is to develop Model-Driven Engineering (MDE) technologies...'
[edit] Further reading
* Model Driven Architecture: Applying MDA to Enterprise Computing, David S. Frankel, John Wiley & Sons, ISBN 0-471-31920-1
[edit] External links
* Model-Driven Architecture: Vision, Standards And Emerging Technologies at omg.org
* On the Unification Power of Models.
* A podcast discussion on Model-Driven Software Development.
* Article Making model-based code generation work
* International School on Model-Driven Design for Distributed, Realtime, Embedded Systems (MDD4DRES)"
From Wikipedia, the free encyclopedia
(Redirected from Model Driven Engineering)
Jump to: navigation, search
The introduction to this article provides insufficient context for those unfamiliar with the subject.
Please help improve the article with a good introductory style.
Model-driven engineering (MDE) is a software development methodology which focuses on creating models, or abstractions, more close to some particular domain concepts rather than computing (or algorithmic) concepts. It is meant to increase productivity by maximizing compatibility between systems, simplifying the process of design, and promoting communication between individuals and teams working on the system.
A modeling paradigm for MDE is considered effective if its models make sense from the point of view of the user and can serve as a basis for implementing systems. The models are developed through extensive communication among product managers, designers, and members of the development team. As the models approach completion, they enable the development of software and systems.
The best known MDE initiative is the Object Management Group (OMG) initiative Model-Driven Architecture (MDA), which is a registered trademark of OMG.[1]
Contents
[hide]
* 1 History of MDE
* 2 MDE as used in software engineering
* 3 See also
* 4 References
* 5 Further reading
* 6 External links
[edit] History of MDE
The first tools to support MDE were the Computer-Aided Software Engineering (CASE) tools developed in the 1980s. Companies like Integrated Development Environments (IDE - StP), Cadre Technologies, Bachman Information Systems, and Logicworks (BP-Win and ER-Win) were pioneers in the field. But CASE had the same problem that current MDA/MDE tools have today: the model gets out of sync with the application (see below). The government got involved in the modeling definitions creating the IDEF specifications. With several variations of the modeling definitions (see Grady Booch, Jim Rumbaugh, Ganes, Sarson, Harel, Shlaer, Mellor, and others) they were eventually joined creating the Unified Modeling Language (UML). Rational Rose, the dominant product for UML implementation, was done by Rational Corporation (Booch) which in 2002 was acquired by IBM.
[edit] MDE as used in software engineering
As it pertains to software development, model-driven engineering refers to a range of development approaches that are based on the use of software modeling as a primary form of expression. Sometimes models are constructed to a certain level of detail, and then code is written by hand in a separate step. Sometimes complete models are built including executable actions. Code can be generated from the models, ranging from system skeletons to complete, deployable products. With the introduction of the Unified Modeling Language (UML), MDE has become very popular today with a wide body of practitioners and supporting tools. More advanced types of MDE have expanded to permit industry standards which allow for consistent application and results. The continued evolution of MDE has added an increased focus on architecture and automation.
MDE technologies with a greater focus on architecture and corresponding automation yield higher levels of abstraction in software development. This abstraction promotes simpler models with a greater focus on problem space. Combined with executable semantics this elevates the total level of automation possible. The Object Management Group (OMG) has developed a set of standards called model-driven architecture (MDA), building a foundation for this advanced architecture-focused approach.
Model-integrated computing is yet another branch of MDE.
According to Douglas C. Schmidt, model-driven engineering technologies offer a promising approach to address the inability of third-generation languages to alleviate the complexity of platforms and express domain concepts effectively[2].
[edit] See also
* Model transformation (QVT)
* Language-oriented programming (LOP)
* Domain-Specific Modeling (DSM)
* Domain Specific Language (DSL)
* Model-based testing (MBT)
* Software factory (SF)
* Business-driven development (BDD)
* Generic Eclipse Modeling System (GEMS)
* Eclipse Modeling Framework (EMF)
* Graphical Modeling Framework (GMF)
* Modeling Maturity Level (MML)
* Service-Oriented Modeling Framework (SOMF)
* Application Lifecycle Management (ALM)
[edit] References
1. ^ Object Management Group (2006-05-24). 'OMG Trademarks'. Retrieved on 2008-02-26.
2. ^ Schmidt, D.C. (February 2006). 'Model-Driven Engineering'. IEEE Computer 39 (2). http://www.cs.wustl.edu/~schmidt/PDF/GEI.pdf. Retrieved on 16 May 2006. , 'A promising approach to address platform complexity — and the inability of third-generation languages to alleviate this complexity and express domain concepts effectively — is to develop Model-Driven Engineering (MDE) technologies...'
[edit] Further reading
* Model Driven Architecture: Applying MDA to Enterprise Computing, David S. Frankel, John Wiley & Sons, ISBN 0-471-31920-1
[edit] External links
* Model-Driven Architecture: Vision, Standards And Emerging Technologies at omg.org
* On the Unification Power of Models.
* A podcast discussion on Model-Driven Software Development.
* Article Making model-based code generation work
* International School on Model-Driven Design for Distributed, Realtime, Embedded Systems (MDD4DRES)"
Meta Modelo - Wikipedia, the free encyclopedia
Metamodeling - Wikipedia, the free encyclopedia: "Metamodeling
From Wikipedia, the free encyclopedia
(Redirected from Meta-modeling)
Jump to: navigation, search
Metamodeling, or meta-modeling in software engineering and systems engineering among other disciplines, is the analysis, construction and development of the frames, rules, constraints, models and theories applicable and useful for modeling a predefined class of problems. As its name implies, this concept applies the notions of meta- and modeling.
Example of a eologic map information meta-model, with four types of meta-objects, and their self-references.[1]
Contents
[hide]
* 1 Overview
* 2 Metamodeling topics
o 2.1 Definition
o 2.2 Metadata modeling
o 2.3 Model transformations
o 2.4 Relationship to ontologies
o 2.5 Types of meta-models
o 2.6 Zoos of metamodels
* 3 See also
* 4 References
* 5 Further reading
[edit] Overview
'Metamodeling' is the construction of a collection of 'concepts' (things, terms, etc.) within a certain domain. A model is an abstraction of phenomena in the real world; a metamodel is yet another abstraction, highlighting properties of the model itself. A model conforms to its metamodel in the way that a computer program conforms to the grammar of the programming language in which it is written.
Common uses for metamodels are:
* As a schema for semantic data that needs to be exchanged or stored
* As a language that supports a particular method or process
* As a language to express additional semantics of existing information
Because of the 'meta' character of metamodeling, both the praxis and theory of metamodels are of relevance to metascience, metaphilosophy, metatheories and systemics, and meta-consciousness. The concept can be useful in mathematics, and has practical applications in computer science and computer engineering/software engineering which are main focus of this article.
[edit] Metamodeling topics
[edit] Definition
In software engineering, the use of models is more and more recommended. This should be contrasted with the classical code-based development techniques. A model always conforms to a unique metamodel. One of the currently most active branch of Model Driven Engineering is the approach named model-driven architecture proposed by OMG. This approach is based on the utilization of a language to write metamodels called the Meta Object Facility or MOF. Typical metamodels proposed by OMG are UML, SysML, SPEM or CWM. ISO has also published the standard metamodel ISO/IEC 24744. All the languages presented below could be defined as MOF metamodels.
[edit] Metadata modeling
Metadata modeling is a type of metamodeling used in software engineering and systems engineering for the analysis and construction of models applicable and useful to some predefined class of problems.
[edit] Model transformations
One important move in Model Driven Engineering is the systematic use of Model Transformation Languages. The OMG has proposed a standard for this called QVT for Queries/Views/Transformations. QVT is based on the Meta-Object Facility or MOF. Among many other Model Transformation Languages (MTLs), some examples of implementations of this standard are AndroMDA, VIATRA, Tefkat or MT.
[edit] Relationship to ontologies
Meta-models are closely related to ontologies. Both are often used to describe and analyze the relations between concepts[2]
* Ontologies : express something meaningful within a specified universe or domain of discourse by utilizing a grammar for using vocabulary. The grammar specifies what it means to be a well-formed statement, assertion, query, etc. (formal constraints) on how terms in the ontology’s controlled vocabulary can be used together. [Metamodel-b]
* Meta-modeling : can be considered as an explicit description (constructs and rules) of how a domain-specific model is built. In particular, this comprises a formalized specification of the domain-specific notations. Typically, metamodels are – and always should follow - a strict rule set. [Metamodel-a]. “A valid metamodel is an ontology, but not all ontology are modeled explicitly as metamodels” [Metamodel-b].
[edit] Types of meta-models
For software engineering, several types of models (and their corresponding modeling activities) can be distinguished:
* Metadata modeling (MetaData Model)
* Meta-Process Modeling (MetaProcess Model)
* Executable Meta-Modeling (combining both of the above and much more, as in the general purpose tool Kermeta)
* Model Transformation Language (see below)
[edit] Zoos of metamodels
A library of similar meta-models has been called a Zoo of meta-models.[3] There are several types of meta-model zoos.[4] Some are expressed in ECore. Others are written in MOF 1.4 - XMI 1.2. The metamodels expressed in UML-XMI1.2 may be uploaded in Poseidon for UML, a UML CASE tool.
[edit] See also
Sister project Wikimedia Commons has media related to: Metamodeling
* Data governance
* Model Driven Engineering (MDE)
* Model-driven architecture (MDA)
* Domain Specific Language (DSL)
* Domain-Specific Modeling (DSM)
* Generic Eclipse Modeling System (GEMS)
* Kermeta (Kernel Meta-modeling)
* Meta model (NLP)
* MODAF Meta-Model
* Object Process Methodology
* Requirements analysis
* MOF Queries/Views/Transformations (MOF QVT)
* Surrogate model
* Transformation language
* VIATRA (Viatra)
* XML transformation language (XML TL)
[edit] References
1. ^ David R. Soller et al. (2001) Progress Report on the National Geologic Map Database, Phase 3: An Online Database of Map Information Digital Mapping Techniques '01 -- Workshop Proceedings U.S. Geological Survey Open-File Report 01-223.
2. ^ E. Söderström, et al. (2001) 'Towards a Framework for Comparing Process Modelling Languages', in: Lecture Notes In Computer Science; Vol. 2348. Proceedings of the 14th International Conference on Advanced Information Systems Engineering. Pages: 600 – 611, 2001
3. ^ paper.
4. ^ AtlanticZoo."
Modelo Matemático - Wikipédia, a enciclopédia livre
Modelo (matemática) - Wikipédia, a enciclopédia livre: "Modelo (matemática)
Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Wikipedia:Revisão
Esta página ou secção foi marcada para revisão, devido a inconsistências e/ou dados de confiabilidade duvidosa. Se tem algum conhecimento sobre o tema, por favor verifique e melhore a consistência e o rigor deste artigo. Considere utilizar {{revisão-sobre}} para associar este artigo com um WikiProjeto.
Um modelo matemático é uma representação ou interpretação simplificada da realidade, ou uma interpretação de um fragmento de um sistema, segundo uma estrutura de conceitos mentais ou experimentais.
Um modelo apresenta apenas uma visão ou cenário de um fragmento do todo. Normalmente, para estudar um determinado fenómeno complexo, criam-se vários modelos. Os modelos matemáticos são utilizados praticamente em todas as áreas científicas, como, por exemplo, na biologia, química, física, economia, engenharia e na própria matemática pura.
Para representar um fenômeno físico complexo pode-se utilizar : modelos físicos, modelos matemáticos ou modelos híbridos de vários tipos.
Os modelos físicos são baseados no Teorema de Bridgman e as escalas de semelhança são calculadas com base no Teorema de Buckingham. Estes modelos são muito utilizados, em laboratórios, para estudos de maiores complexidades como estudos de hidrodinâmica em engenharia hidráulica, (usinas hidrelétricas, navios), e de aerodinâmica (aviões, automóveis, etc), mecânica quântica.
Praticamente nenhuma grande obra hidráulica, porto ou usina hidrelétrica, é projetada sem estudos detalhados em vários modelos matemáticos de diversas categorias como hidrologia, hidráulica, mecânica dos solos. Também são muitíssimo utilizados a construção de vários modelos físicos específicos ( turbinas, casa de força, vertedouro, eclusas , escada de peixe, etc. Estes modelos podem ser bidimensionais ou tridimensionais (modelo de conjunto).
Em Teoria de modelos um modelo é uma estrutura composta por um conjunto universo e por constantes, relações e funções definidas no conjunto universo.
[editar] Ver também
* Modelos físicos
* Hidráulica
* Hidráulica Marítima"
Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Wikipedia:Revisão
Esta página ou secção foi marcada para revisão, devido a inconsistências e/ou dados de confiabilidade duvidosa. Se tem algum conhecimento sobre o tema, por favor verifique e melhore a consistência e o rigor deste artigo. Considere utilizar {{revisão-sobre}} para associar este artigo com um WikiProjeto.
Um modelo matemático é uma representação ou interpretação simplificada da realidade, ou uma interpretação de um fragmento de um sistema, segundo uma estrutura de conceitos mentais ou experimentais.
Um modelo apresenta apenas uma visão ou cenário de um fragmento do todo. Normalmente, para estudar um determinado fenómeno complexo, criam-se vários modelos. Os modelos matemáticos são utilizados praticamente em todas as áreas científicas, como, por exemplo, na biologia, química, física, economia, engenharia e na própria matemática pura.
Para representar um fenômeno físico complexo pode-se utilizar : modelos físicos, modelos matemáticos ou modelos híbridos de vários tipos.
Os modelos físicos são baseados no Teorema de Bridgman e as escalas de semelhança são calculadas com base no Teorema de Buckingham. Estes modelos são muito utilizados, em laboratórios, para estudos de maiores complexidades como estudos de hidrodinâmica em engenharia hidráulica, (usinas hidrelétricas, navios), e de aerodinâmica (aviões, automóveis, etc), mecânica quântica.
Praticamente nenhuma grande obra hidráulica, porto ou usina hidrelétrica, é projetada sem estudos detalhados em vários modelos matemáticos de diversas categorias como hidrologia, hidráulica, mecânica dos solos. Também são muitíssimo utilizados a construção de vários modelos físicos específicos ( turbinas, casa de força, vertedouro, eclusas , escada de peixe, etc. Estes modelos podem ser bidimensionais ou tridimensionais (modelo de conjunto).
Em Teoria de modelos um modelo é uma estrutura composta por um conjunto universo e por constantes, relações e funções definidas no conjunto universo.
[editar] Ver também
* Modelos físicos
* Hidráulica
* Hidráulica Marítima"
Modelos físicos - Wikipédia, a enciclopédia livre
Modelos físicos - Wikipédia, a enciclopédia livre: "Modelos físicos
Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Wikipedia:Princípio da imparcialidade
Este artigo ou secção possui passagens que não respeitam o princípio da imparcialidade.
Tenha algum cuidado ao ler as informações contidas nele. Se puder, tente tornar o artigo mais imparcial.
Wikipedia:Reciclagem
Esta página precisa ser reciclada de acordo com o livro de estilo.
Sinta-se livre para editá-la para que esta possa atingir um nível de qualidade superior.
Modelos físicos são ferramentas usadas em diversos ramos da engenharia mecânica, engenharia civil , naval, nuclear e em outros ramos para se projetar um protótipo, como por exemplo, um avião, um navio, uma plataforma de petróleo, um automóvel, bombas e turbinas hidráulicas, uma usina hidrelétrica, barragens, prédios sujeitos a ventos ou a terremotos. Normalmente este tipo de modelagem física é utilizado para complementar os cálculos dos modelos matemáticos durante um projeto muito grande e complexo. No projeto da Usina hidrelétrica de Tucuruí, por exemplo, os estudos em modelos reduzidos foram conduzidos no Laboratório Saturnino de Brito, no Rio de Janeiro, durante um período de oito anos. A construção de modelos físicos, em escalas reduzidas, embora tentada anteriormente por Arquimedes, Leonardo Da Vinci e outros estudiosos só foi possível após a descoberta da Teoria da Semelhança Mecânica por Isaac Newton e do Teorema de Bridgman.
Nos modelos aerodinâmicos a semelhança aplicada é a de Mach, nos modelos hidrodinâmicos de escoamentos em condutos forçados utiliza-se a chamada semelhança de Reynolds e nos condutos livres ( canais, usinas hidrelétricas, vertedores utiliza-se a semelhança de Froude.
* Modelos hidráulicos (físicos, matemáticos e híbridos).
Um modelo é uma representação ou interpretação simplificada da realidade, ou uma interpretação de um fragmento de um sistema segundo uma estrutura de conceitos. Um modelo apresenta 'apenas' uma visão ou cenário de um fragmento do todo. Normalmente, para estudar um determinado fenômeno complexo, criam-se vários modelos. Em Teoria de modelos um modelo é uma estrutura composta por um conjunto universo e por constantes, relações e funções definidas no conjunto universo.
Praticamente nenhuma grande obra hidráulica, como molhes, diques, quebra-mares, portos, uma ampliação de praia artificial ou uma usina hidrelétrica, é projetada sem estudos detalhados em vários tipos de modelos matemáticos de diversas categorias e tipos como modelos de hidrologia, hidráulica, mecânica dos solos.
Também são muitíssimo utilizados a construção de vários modelos físicos específicos para molhes, diques, quebra-mares, turbinas, casa de força, vertedouros, eclusas , escada de peixe, etc. Estes modelos podem ser bidimensionais ou tridimensionais (modelo de conjunto).
Além dos modelos meramente conceituais, que facilitam e norteiam a compreensão e a visualização dos fenômenos naturais intervenientes, dois métodos de simulação podem servir de instrumento para o estudo de fenômenos físicos na natureza, tais como, por exemplo, a qualidade de águas fluviais, estuariais e costeiras: modelos físicos e modelos matemáticos.
A aplicação de um método não exclui o emprego do outro. O modelo físico pode servir de referência para a calibração do modelo matemático como, por exemplo, nos estudos de jatos (modelos semi-empíricos). Os modelos matemáticos representam os fenômenos da natureza por meio de equações. Estas equações matemáticas dos fenômenos físicos são, em alguns casos, de difícil representação e solução. Além disso, necessitam seguidamente do uso de coeficientes desconhecidos que deverão ser medidos na natureza ou em modelos físicos. Como a resolução das equações completas nem sempre é possível, faz-se necessário desprezar certos termos e ainda formular hipóteses sobre a distribuição espacial de certas grandezas (modelos integrais) ou discretizar o espaço e o tempo (modelos numéricos). Estes modelos podem ser uni, bi e tridimensionais. A escolha das hipóteses simplificadoras e do tipo de modelo é fundamental para a validade dos resultados obtidos. Os modelos físicos têm a vantagem de não apresentarem uma discretização do problema, pois este é continuo e pode ter uma representação geométrica tridimensional sem dificuldades. Os modelos híbridos, apesar de possuírem custos iniciais elevados, se apresentam como uma solução para reduzir os custos de operações devido à sua grande flexibilidade, pois permite a realização de vários ensaios em pouco tempo. São basicamente modelos físicos comandados por computadores.
[editar] Bibliografia
* Rios, J. L. P. – Modelos Matemáticos em Hidráulica e no Meio Ambiente no Simpósio Luso-Brasileiro sobre Simulação e Modelação em Hidrâulica. APRH – LNEC. Lisboa, 1986.
[editar] Ver também
* Aerodinâmica
* Difusão, convecção, reação
* Modelagem computacional
* Velocimetria laser
* Modelo das Partículas Fluidas
* Hidráulica aplicada a tubulações"
Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Wikipedia:Princípio da imparcialidade
Este artigo ou secção possui passagens que não respeitam o princípio da imparcialidade.
Tenha algum cuidado ao ler as informações contidas nele. Se puder, tente tornar o artigo mais imparcial.
Wikipedia:Reciclagem
Esta página precisa ser reciclada de acordo com o livro de estilo.
Sinta-se livre para editá-la para que esta possa atingir um nível de qualidade superior.
Modelos físicos são ferramentas usadas em diversos ramos da engenharia mecânica, engenharia civil , naval, nuclear e em outros ramos para se projetar um protótipo, como por exemplo, um avião, um navio, uma plataforma de petróleo, um automóvel, bombas e turbinas hidráulicas, uma usina hidrelétrica, barragens, prédios sujeitos a ventos ou a terremotos. Normalmente este tipo de modelagem física é utilizado para complementar os cálculos dos modelos matemáticos durante um projeto muito grande e complexo. No projeto da Usina hidrelétrica de Tucuruí, por exemplo, os estudos em modelos reduzidos foram conduzidos no Laboratório Saturnino de Brito, no Rio de Janeiro, durante um período de oito anos. A construção de modelos físicos, em escalas reduzidas, embora tentada anteriormente por Arquimedes, Leonardo Da Vinci e outros estudiosos só foi possível após a descoberta da Teoria da Semelhança Mecânica por Isaac Newton e do Teorema de Bridgman.
Nos modelos aerodinâmicos a semelhança aplicada é a de Mach, nos modelos hidrodinâmicos de escoamentos em condutos forçados utiliza-se a chamada semelhança de Reynolds e nos condutos livres ( canais, usinas hidrelétricas, vertedores utiliza-se a semelhança de Froude.
* Modelos hidráulicos (físicos, matemáticos e híbridos).
Um modelo é uma representação ou interpretação simplificada da realidade, ou uma interpretação de um fragmento de um sistema segundo uma estrutura de conceitos. Um modelo apresenta 'apenas' uma visão ou cenário de um fragmento do todo. Normalmente, para estudar um determinado fenômeno complexo, criam-se vários modelos. Em Teoria de modelos um modelo é uma estrutura composta por um conjunto universo e por constantes, relações e funções definidas no conjunto universo.
Praticamente nenhuma grande obra hidráulica, como molhes, diques, quebra-mares, portos, uma ampliação de praia artificial ou uma usina hidrelétrica, é projetada sem estudos detalhados em vários tipos de modelos matemáticos de diversas categorias e tipos como modelos de hidrologia, hidráulica, mecânica dos solos.
Também são muitíssimo utilizados a construção de vários modelos físicos específicos para molhes, diques, quebra-mares, turbinas, casa de força, vertedouros, eclusas , escada de peixe, etc. Estes modelos podem ser bidimensionais ou tridimensionais (modelo de conjunto).
Além dos modelos meramente conceituais, que facilitam e norteiam a compreensão e a visualização dos fenômenos naturais intervenientes, dois métodos de simulação podem servir de instrumento para o estudo de fenômenos físicos na natureza, tais como, por exemplo, a qualidade de águas fluviais, estuariais e costeiras: modelos físicos e modelos matemáticos.
A aplicação de um método não exclui o emprego do outro. O modelo físico pode servir de referência para a calibração do modelo matemático como, por exemplo, nos estudos de jatos (modelos semi-empíricos). Os modelos matemáticos representam os fenômenos da natureza por meio de equações. Estas equações matemáticas dos fenômenos físicos são, em alguns casos, de difícil representação e solução. Além disso, necessitam seguidamente do uso de coeficientes desconhecidos que deverão ser medidos na natureza ou em modelos físicos. Como a resolução das equações completas nem sempre é possível, faz-se necessário desprezar certos termos e ainda formular hipóteses sobre a distribuição espacial de certas grandezas (modelos integrais) ou discretizar o espaço e o tempo (modelos numéricos). Estes modelos podem ser uni, bi e tridimensionais. A escolha das hipóteses simplificadoras e do tipo de modelo é fundamental para a validade dos resultados obtidos. Os modelos físicos têm a vantagem de não apresentarem uma discretização do problema, pois este é continuo e pode ter uma representação geométrica tridimensional sem dificuldades. Os modelos híbridos, apesar de possuírem custos iniciais elevados, se apresentam como uma solução para reduzir os custos de operações devido à sua grande flexibilidade, pois permite a realização de vários ensaios em pouco tempo. São basicamente modelos físicos comandados por computadores.
[editar] Bibliografia
* Rios, J. L. P. – Modelos Matemáticos em Hidráulica e no Meio Ambiente no Simpósio Luso-Brasileiro sobre Simulação e Modelação em Hidrâulica. APRH – LNEC. Lisboa, 1986.
[editar] Ver também
* Aerodinâmica
* Difusão, convecção, reação
* Modelagem computacional
* Velocimetria laser
* Modelo das Partículas Fluidas
* Hidráulica aplicada a tubulações"
Hierarquia DIKW - Wikipédia, a enciclopédia livre
Hierarquia DIKW - Wikipédia, a enciclopédia livre: "Hierarquia DIKW
Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
DIKW é uma hierarquia informacional utilizada principalmente nos campos da Ciência da Informação e da Gestão do Conhecimento, onde cada camada acrescenta certos atributos sobre a anterior.
[editar] Características
Os seus componentes, em ordem crescente de importância e normalmente dispostos em um sistema de coordenadas cartesianas, são os seguintes:
* Dados (Data) é o nível mais básico;
* Informação (Information) acrescenta contexto e significado aos dados;
* Conhecimento (Knowledge) acrescenta a forma como usar adequadamente a informação;
* Sabedoria (Wisdow) acrescenta o entendimento de quando utilizá-los.
Desta forma, a hierarquia DIKW é um modelo teórico que se mostra útil na análise e no entendimento da importância e limites das atividades dos trabalhadores do conhecimento.
[editar] Ligações externas
* Data, Information, Knowledge, and Wisdom (em inglês)"
Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
DIKW é uma hierarquia informacional utilizada principalmente nos campos da Ciência da Informação e da Gestão do Conhecimento, onde cada camada acrescenta certos atributos sobre a anterior.
[editar] Características
Os seus componentes, em ordem crescente de importância e normalmente dispostos em um sistema de coordenadas cartesianas, são os seguintes:
* Dados (Data) é o nível mais básico;
* Informação (Information) acrescenta contexto e significado aos dados;
* Conhecimento (Knowledge) acrescenta a forma como usar adequadamente a informação;
* Sabedoria (Wisdow) acrescenta o entendimento de quando utilizá-los.
Desta forma, a hierarquia DIKW é um modelo teórico que se mostra útil na análise e no entendimento da importância e limites das atividades dos trabalhadores do conhecimento.
[editar] Ligações externas
* Data, Information, Knowledge, and Wisdom (em inglês)"
Model - A Simplification of Reality
Model - A Simplification of Reality: "Model
Model, like so many words in the English language, has a multitude of meanings depending on the context in which it is used. In a systems context I have come to understand model to mean:
A simplification of reality intended to promote understanding.
We often deal with things, later I'll call them systems, that are so complex as to be beyond the limits or our intuitive comprehension. As such, we construct models, simplifications of the real thing, which allow us to study that which we seek to understand.
Whether a model is right or wrong is simply a value judgment, whether it is correct or incorrect is something that will be evident in time. The most important question to ask should relate to the extent to which the models we develop promote the intentioned development of our understanding. The extent to which a model aids in the development of our understanding is the basis for deciding how good the model is.
In developing models there is always a trade off. A model is a simplification of reality, and as such, certain details are excluded from it. The question is always what to include and what to exclude. If relevant components are excluded there is a chance that the model will be too simple in nature and will not support the development of the understanding desired. On the other hand, if too much detail is included, the model may become so complicated that, again, it fails to promote the development of the deeper levels of understanding one seeks. One cannot develop every model in the context of the entire universe, unless of course your name is Carl Sagan.
Personally I find I learn a lot from models developed by others. In an attempt to return the favor many of the models I have developed over the years are available for downloading on various web pages on this site.
When I first began developing models what seemed the greatest hindrance to progress was a blank sheet of paper. I used to spend endless amounts of time trying to figure out where to start because I wanted to make sure I got it right. As a result of my insistence on getting it right I got it wrong, simply because the model wasn't progressing. Sound like a typical Catch-22?
What I finally realized was that it simply doesn't matter where one starts! Any place you start is the beginning. You can build the model from the top down, from the bottom up, from the inside out, or from the outside in. If one pursues continued elaboration of the model sooner or later one arrives at an equivalent well defined understanding.
Now that I have stopped worrying about getting it right, admitting that each stage of model refinement or elaboration is just another approximation of some more elaborate system, I have begun to make more progress, and hopefully am developing better models.
What I have found to be absolutely essential is that if one builds a model with the intent of simulating it, each step of the elaboration must be relatively small and manageable, and must represent an operational simulation. That is, each elaboration must run as a simulation. Every time I have developed multiple levels of model refinement or elaboration without testing it I have set myself up for numerous headaches."
Model, like so many words in the English language, has a multitude of meanings depending on the context in which it is used. In a systems context I have come to understand model to mean:
A simplification of reality intended to promote understanding.
We often deal with things, later I'll call them systems, that are so complex as to be beyond the limits or our intuitive comprehension. As such, we construct models, simplifications of the real thing, which allow us to study that which we seek to understand.
Whether a model is right or wrong is simply a value judgment, whether it is correct or incorrect is something that will be evident in time. The most important question to ask should relate to the extent to which the models we develop promote the intentioned development of our understanding. The extent to which a model aids in the development of our understanding is the basis for deciding how good the model is.
In developing models there is always a trade off. A model is a simplification of reality, and as such, certain details are excluded from it. The question is always what to include and what to exclude. If relevant components are excluded there is a chance that the model will be too simple in nature and will not support the development of the understanding desired. On the other hand, if too much detail is included, the model may become so complicated that, again, it fails to promote the development of the deeper levels of understanding one seeks. One cannot develop every model in the context of the entire universe, unless of course your name is Carl Sagan.
Personally I find I learn a lot from models developed by others. In an attempt to return the favor many of the models I have developed over the years are available for downloading on various web pages on this site.
When I first began developing models what seemed the greatest hindrance to progress was a blank sheet of paper. I used to spend endless amounts of time trying to figure out where to start because I wanted to make sure I got it right. As a result of my insistence on getting it right I got it wrong, simply because the model wasn't progressing. Sound like a typical Catch-22?
What I finally realized was that it simply doesn't matter where one starts! Any place you start is the beginning. You can build the model from the top down, from the bottom up, from the inside out, or from the outside in. If one pursues continued elaboration of the model sooner or later one arrives at an equivalent well defined understanding.
Now that I have stopped worrying about getting it right, admitting that each stage of model refinement or elaboration is just another approximation of some more elaborate system, I have begun to make more progress, and hopefully am developing better models.
What I have found to be absolutely essential is that if one builds a model with the intent of simulating it, each step of the elaboration must be relatively small and manageable, and must represent an operational simulation. That is, each elaboration must run as a simulation. Every time I have developed multiple levels of model refinement or elaboration without testing it I have set myself up for numerous headaches."
DIKW - Wikipedia, the free encyclopedia
DIKW - Wikipedia, the free encyclopedia: "The 'DIKW Hierarchy', also known variously as the 'Wisdom Hierarchy', the 'Knowledge Hierarchy', the 'Information Hierarchy', and the 'Knowledge Pyramid'[1], refers loosely to a class of models[2] for representing purported structural and/or functional relationships between data, information, knowledge, and wisdom. 'Typically information is defined in terms of data, knowledge in terms of information, and wisdom in terms of knowledge'[1].
Not all versions of the DIKW model reference all four components (earlier versions not including data, later versions omitting or downplaying wisdom), and some include additional components. In addition to a hierarchy and a pyramid, the DIKW model has also been characterized as a chain[3][4], as a framework [5], and as a continuum[6].
Contents
[hide]
* 1 History
o 1.1 Information, Knowledge, Wisdom
o 1.2 Data, Information, Knowledge, Wisdom
o 1.3 Data, Information, Knowledge
* 2 Description
* 3 Data
o 3.1 Data as Fact
o 3.2 Data as Signal
o 3.3 Data as Symbol
* 4 Information
o 4.1 Structural vs. Functional
o 4.2 Symbolic vs. Subjective
* 5 Knowledge
o 5.1 Knowledge as Processed
o 5.2 Knowledge as Procedural
o 5.3 Knowledge as Propositional
* 6 Wisdom
* 7 Representations
* 8 Criticisms
* 9 References
[edit] History
'The presentation of the relationships among data, information, knowledge, and sometimes wisdom in a hierarchical arrangement has been part of the language of information science for many years. Although it is uncertain when and by whom those relationships were first presented, the ubiquity of the notion of a hierarchy in embedded in the use of the acronym DIKW as a shorthand representation for the data-to-information-to-knowledge-to-wisdom transformation.'[7]
[edit] Information, Knowledge, Wisdom
Educator Danny P. Wallace traces the earliest conception of a hierarchy involving knowledge and wisdom to 1927 and 1941, in early works of American philosopher Mortimer Adler, later to be formalized as 'goods of the mind'[7], in 1970--'knowledge, understanding, prudence, and even a modicum of wisdom'[8]--and later revised, in 1986, as follows: 'As health, strength, vigor and vitality are bodily goods, so information, knowledge, understanding and wisdom are goods of the mind - goods that acquired, perfect it.'[9]
The earliest formalized distinction between wisdom, knowledge, and information may have been made by poet and playwright T.S. Eliot[10][11]:
Where is the Life we have lost in living?
Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?
-- from T.S. Eliot, 'Choruses from 'The Rock''
Nearly half a century later, American composer Frank Zappa articulated an extended version of the information-knowledge-wisdom hierarchy[12]:
Information is not knowledge,
Knowledge is not wisdom,
Wisdom is not truth,
Truth is not beauty,
Beauty is not love,
Love is not music,
and Music is THE BEST.
-- from Frank Zappa, 'Packard Goose'
Thereafter, American author and educator Harlan Cleveland cited to Eliot in his 1982 article discussing the hierarchy.[13][7]
[edit] Data, Information, Knowledge, Wisdom
Other early versions (prior to 1982) of the hierarchy that refer to a data tier include those of Chinese-American geographer Yi-Fu Tuan[13][verification needed][14] and sociologist-historian Daniel Bell.[13][verification needed][14]. In 1980, Irish-born engineer Mike Cooley invoked the same hierarchy in his critique of automation and computerization, in his book Architect or Bee?: The Human / Technology Relationship.[15][verification needed][14]
Thereafter, in 1987, Checkoslovakian-born educator Milan Zeleny mapped the elements of the hierarchy to knowledge forms: know-nothing, know-what, know-how, and know-why.[16][verification needed] Zeleny 'has frequently been credited with proposing the [representation of DIKW as a pyramid]...although he actually made no reference to any such graphical model.'[7]
The hierarchy appears again in a 1988 address to the International Society for General Systems Research, by American organizational theorist Russell Ackoff, published in 1989.[17]. Subsequent authors and textbooks cite Ackoff's as the 'original articulation'[1] of the hierarchy or otherwise credit Ackoff with its proposal[18]. Ackoff's version of the model includes an understanding tier (as Adler had, before him[8][9][7]), interposed between knowledge and wisdom. Although Ackoff did not present the hierarchy graphically, he has also been credited with its representation as a pyramid.[17][7].
In the same year as Ackoff presented his address, information scientist Anthony Debons and colleagues introduced an extended hierarchy, with 'events', 'symbols', and 'rules and formulations' tiers ahead of data.[19][7].
[edit] Data, Information, Knowledge
In 1955, English-American economist and educator Kenneth Boulding presented a variation on the hierarchy consisting of 'signals, messages, information, and knowledge'.[20][7]. However, '[t]he first author to distinguish among data, information, and knowledge and to also employ the term 'knowledge management' may have been American educator Nicholas L. Henry'[7], in a 1974 journal article[21].
Jennifer Rowley notes that there is 'little reference to wisdom' in discussion of the DIKW in recently published college textbooks[1], and does not include wisdom in her own definitions following that research[18]. Meanwhile, Zins's extensive analysis of the conceptualizations of data, information, and knowledge, in his recent research study, makes no explicit commentary on wisdom[2], although some of the citations included by Zins do make mention of the term[22][23][24].
[edit] Description
The DIKW model 'is often quoted, or used implicitly, in definitions of data, information and knowledge in the information management, information systems and knowledge management literatures, but there has been limited direct discussion of the hierarchy'[1]. Reviews of textbooks[1] and a survey of scholars in relevant fields[2] indicate that there is not a consensus as to definitions used in the model, and even less 'in the description of the processes that transform elements lower in the hierarchy into those above them'[1][25].
This has led Israeli researcher Chaim Zins to suggest that the data–information–knowledge components of DIKW refer to a class of no less than five models, as a function of whether data, information, and knowledge are each conceived of as subjective, objective (what Zins terms, 'universal' or 'collective') or both. In Zins's usage, subjective and objective 'are not related to arbitrariness and truthfulness, which are usually attached to the concepts of subjective knowledge and objective knowledge'. Information science, Zins argues, studies data and information, but not knowledge, as knowledge is an internal (subjective) rather than an external (universal–collective) phenomenon.[2]
[edit] Data
In the context of DIKW, data is conceived of as symbols or signs, representing stimuli or signals[2], that are 'of no use until...in a usable (that is, relevant) form'[18]. Zeleny characterized this non-usable characteristic of data as 'know-nothing'[16][verification needed][14].
In some cases, data is understood to refer not only to symbols, but also to signals or stimuli referred to by said symbols--what Zins terms subjective data.[2] Where universal data, for Zins, are 'the product of observation'[18] (italics in original), subjective data are the observations. This distinct is often obscured in definitions of data in terms of 'facts'.
[edit] Data as Fact
Rowley, following her study of DIKW definitions given in textbooks[1], characterizes data 'as being discrete, objective facts or observations, which are unorganized and unprocessed and therefore have no meaning or value because of lack of context and interpretation.'[18] In Henry's early formulation of the hierarchy, data was simply defined as 'merely raw facts'.[21], while two recent texts define data as 'chunks of facts about the state of the world'[26] and 'material facts'[27], respectively.[7] Cleveland does not include an explicit data tier, but defines information as 'the sum total of...facts and ideas'.[13][7]
Insofar as facts have as a fundamental property that they are true, have objective reality, or otherwise can be verified, such definitions would preclude false, meaningless, and nonsensical data from the DIKW model, such that the principle of Garbage In, Garbage Out would not be accounted for under DIKW.
[edit] Data as Signal
In the subjective domain, data are conceived of as 'sensory stimuli, which we perceive through our senses'[2], or 'signal readings', including 'sensor and/or sensory readings of light, sound, smell, taste, and touch'[25]. Others have argued that what Zins calls subjective data actually count as a 'signal' tier (as had Boulding[20][7]), which precedes data in the DIKW chain.[6]
American information scientist Glynn Harmon defines data as 'one or more kinds of energy waves or particles (light, heat, sound, force, electromagnetic) selected by a conscious organism or intelligent agent on the basis of a preexisting frame or inferential mechanism in the organism or agent.'[28]
The meaning of sensory stimuli may also be thought of as subjective data:
Information is the meaning of these sensory stimuli (i.e., the empirical perception). For example, the noises that I hear are data. The meaning of these noises (e.g., a running car engine) is information. Still, there is another alternative as to how to define these two concepts— which seems even better. Data are sense stimuli, or their meaning (i.e., the empirical perception). Accordingly, in the example above, the loud noises, as well as the perception of a running car engine, are data.[2] (Italics added. Bold in original)
Subjective data, if understood in this way, would be comparable to knowledge by acquaintance, in that it is based on direct experience of stimuli. However, unlike knowledge by acquaintance, as described by Bertrand Russell and others, the subjective domain is 'not related to...truthfulness'.[2]
Whether Zins' alternate definition would hold would be a function of whether 'the running of a car engine' is understood as an objective fact or as a contextual interpretation.
[edit] Data as Symbol
Whether the DIKW definition of data is deemed to include Zins's subjective data (with or without meaning), data is consistently defined to include 'symbols'[17][29], or 'sets of signs that represent empirical stimuli or perceptions'[2], of 'a property of an object, an event or of their environment'[18]. Data, in this sense, are 'recorded (captured or stored) symbols', including 'words (text and/or verbal), numbers, diagrams, and images (still &/or video), which are the building blocks of communication', the purpose of which 'is to record activities or situations, to attempt to capture the true picture or real event,' such that 'all data are historical, unless used for illustrative purposes, such as forecasting.'[25]
Boulding's version of DIKW explicitly named the level below the information tier message, distinguishing it from an underlying signal tier.[20][7] Debons and colleagues reverse this relationship, identifying an explicit symbol tier as one of several levels underlying data.[19][7].
Zins determined that, for most of those surveyed, data 'are characterized as phenomena in the universal domain'. 'Apparently,' clarifies Zins, 'it is more useful to relate to the data, information, and knowledge as sets of signs rather than as meaning and its building blocks'.[2]
[edit] Information
In the context of DIKW, information meets the definition for knowledge by description ('information is contained in descriptions[18] [Italics in original]), and is differentiated from data in that it is 'useful'. 'Information is inferred from data'[18], in the process of answering interrogative questions (e.g., 'who', 'what', 'where', 'how many', 'when')[17][18], thereby making the data useful[29] for 'decisions and/or action'[25]. 'Classically,' states a recent text, 'information is defined as data that are endowed with meaning and purpose.'[26][7]
[edit] Structural vs. Functional
Rowley, following her review of how DIKW is presented in textbooks[1], describes information as 'organized or structured data, which has been processed in such a way that the information now has relevance for a specific purpose or context, and is therefore meaningful, valuable, useful and relevant.' Note that this definition contrasts with Rowley's characterization of Ackoff's definitions, wherein '[t]he difference between data and information is structural, not functional.'[18]
In his formulation of the hierarchy, Henry defined information as 'data that changes us'[21][7], this being a functional, rather than structural, distinction between data and information. Meanwhile, Cleveland, who did not refer to a data level in his version of DIKW, described information as 'the sum total of all the facts and ideas that are available to be known by somebody at a given moment in time'.[13][7]
American educator Bob Boiko is more obscure, defining information only as 'matter-of-fact'.[27][7].
[edit] Symbolic vs. Subjective
Information may be conceived of in DIKW models as: (i) universal, existing as symbols and signs; (ii) subjective, the meaning to which symbols attach; or (iii) both.[2]. Examples of information as both symbol and meaning include:
* American information scientist Anthony Debons's characterization of information as representing 'a state of awareness (consciousness) and the physical manifestations they form', such that '[i]nformation, as a phenomena, represents both a process and a product; a cognitive/affective state, and the physical counterpart (product of) the cognitive/affective state.'[30]
* Danish information scientist Hanne Albrechtsen's description of information as 'related to meaning or human intention', either as 'the contents of databases, the web, etc.' (italics added) or 'the meaning of statements as they are intended by the speaker/writer and understood/misunderstood by the listener/reader.'[31]
Zeleny formerly described information as 'know-what'[16][citation needed], but has since refined this to differentiate between 'what to have or to possess' (information) and 'what to do, act or carry out' (wisdom). To this conceptualization of information, he also adds 'why is', as distinct from 'why do' (another aspect of wisdom). Zeleny further argues that there is no such thing as explicit knowledge, but rather that knowledge, once made explicit in symbolic form, becomes information.[3]
[edit] Knowledge
The knowledge component of DIKW 'is generally agreed to be an elusive concept which is difficult to define. Knowledge is typically defined with reference to information.'[18] Definitions may refer to information having been processed, organized or structured in some way, or else as being applied or put into action.
Zins has suggested that knowledge, being subjective rather than universal, is not the subject of study in information science, and that it is often defined in propositional terms[2], while Zeleny has asserted that to capture knowledge in symbolic form is to make it into information, i.e., that 'All knowledge is tacit'[3].
'One of the most frequently quoted definitions'[7] of knowledge captures some of the various ways in which it has been defined by others:
Knowledge is a fluid mix of framed experience, values, contextual information, expert insight and grounded intuition that provides an environment and framework for evaluating and incorporating new experiences and information. It originates and is applied in the minds of knowers. In organizations it often becomes embedded not only in documents and repositories but also in organizational routines, processes, practices and norms.[32][7]
[edit] Knowledge as Processed
Mirroring the description of information as 'organized or structured data', knowledge is sometimes described as:
* 'synthesis of multiple sources of information over time'
* 'organization and processing to convey understanding, experience [and] accumulated learning'
* 'a mix of contextual information, values, experience and rules'[18]
One of Boulding's definitions for knowledge had been 'a mental structure'[20][7] and Cleveland described knowledge as 'the result of somebody applying the refiner's fire to [information], selecting and organizing what is useful to somebody'[13][7]. A recent text describes knowledge as 'information connected in relationships'.[26][7].
[edit] Knowledge as Procedural
Zeleny defines knowledge as 'know-how'[16][3] (i.e., procedural knowledge), and also 'know-who' and 'know-when', each gained through 'practical experience'[3] . 'Knowledge...brings forth from the background of experience a coherent and self-consistent set of coordinated actions.'[16][7]. Further, implicitly holding information as descriptive, Zeleny declares that 'Knowledge is action, not a description of action.'[3]
Ackoff, likewise, described knowledge as the 'application of data and information', which 'answers 'how' questions'[17][verification needed][29], that is, 'know-how'.[18].
Meanwhile, textbooks discussing DIKW have been found to describe knowledge variously in terms of experience, skill, expertise or capability:
* 'study and experience'
* 'a mix of contextual information, expert opinion, skills and experience'
* 'information combined with understanding and capability'
* 'perception, skills, training, common sense and experience'[18].
Businessmen James Chisholm and Greg Warman characterize knowledge simply as 'doing things right'.[5]
[edit] Knowledge as Propositional
Knowledge is sometimes described as 'belief structuring' and 'internalization with reference to cognitive fameworks'[18]. One definition given by Boulding for knowledge was 'the subjective 'perception of the world and one's place in it''[20][7], while Zeleny's said that knowledge 'should refer to an observer's distinction of 'objects' (wholes, unities)'[16][7].
Zins, likewise, found that knowledge is described in propositional terms, as justifiable beliefs (subjective domain, akin to tacit knowledge), and sometimes also as signs that represent such beliefs (universal/collective domain, akin to explicit knowledge). Zeleny has rejected the idea of explicit knowledge (as in Zins' universal knowledge), arguing that once made symbolic, knowledge becomes information.[3] Boiko appears to echo this sentiment, in his claim that 'knowledge and wisdom can be information'.[27][7].
In the subjective domain:
Knowledge is a thought in the individual’s mind, which is characterized by the individual’s justifiable belief that it is true. It can be empirical and non-empirical, as in the case of logical and mathematical knowledge (e.g., 'every triangle has three sides'), religious knowledge (e.g., 'God exists'), philosophical knowledge (e.g., 'Cogito ergo sum'), and the like. Note that knowledge is the content of a thought in the individual’s mind, which is characterized by the individual’s justifiable belief that it is true, while “knowing” is a state of mind which is characterized by the three conditions: (1) the individual believe[s] that it is true, (2) S/he can justify it, and (3) It is true, or it [appears] to be true.[2](Italics added. Bold in original)
The distinction here between subjective knowledge and subjective information is that subjective knowledge is characterized by justifiable belief, where subjective information is a type of knowledge concerning the meaning of data.
Boiko implied that knowledge was both open to discourse and justification, when he defined knowledge as 'a matter of dispute'.[27][7].
[edit] Wisdom
Although commonly included as a level in DIKW, 'there is limited reference to wisdom'[1] in discussions of the model. Boiko appears to have dismissed wisdom, characterizing it as 'non-material'.[27][7]
Zeleny described wisdom as 'know-why'[16], but later refined his definitions, so as to differentiate 'why do' (wisdom) from 'why is' (information), and expanding his definition to include a form of know-what ('what to do, act or carry out')[3]. According to University of Michigan Ph.D. candidate Nikhil Sharma, Zeleny has argued for a tier to the model beyond wisdom, termed 'enlightenment'[14].
Ackoff refers to understanding as an 'appreciation of 'why'', and wisdom as 'evaluated understanding', where understanding is posited as a discrete layer between knowledge and wisdom[17][7][29]. Adler had previously also included an understanding tier[9][8][7], while other authors have depicted understanding as a dimension in relation to which DIKW is plotted[5][29]. Rowley attributes the following definition of wisdom to Ackoff:
Wisdom is the ability to increase effectiveness. Wisdom adds value, which requires the mental function that we call judgment. The ethical and aesthetic values that this implies are inherent to the actor and are unique and personal.[18]
Cleveland described wisdom simply as 'integrated knowledge--information made super-useful'.[13][7] Other authors have characterized wisdom as 'knowing the right things to do'[5] and 'the ability to make sound judgments and decisions apparently without thought'[26][7].
[edit] Representations
A flow diagram of the DIKW hierarchy. Public domain.
It is requested that a diagram or diagrams be included in this article to improve its quality.
For more information, refer to discussion on this page and/or the listing at Wikipedia:Requested images. (January 2009)
DIKW is a hierarchical model often depicted as a pyramid[1][7], with data at its base and wisdom at its apex. In this regard it is similar to Maslow's hierarchy of needs, in that each level of the hierarchy is argued to be an essential precursor to the levels above. Unlike Maslow's hierarchy, which describes relationships of priority (lower levels are focused on first), DIKW describes purported structural or functional relationships (lower levels comprise the material of higher levels). Both Zeleny and Ackoff have been credited with originating the pyramid representation[7], although neither used a pyramid to present their ideas.[16][17][7].
DIKW has also been represented as a two-dimensional chart[33][5] or as one or more flow diagrams[25]. In such cases, the relationships between the elements may be presented as less hierarchical, with feedback loops and control relationships.
Debons and colleagues[19] may have been the first to 'present the hierarchy graphically'[7].
[edit] Criticisms
Raphael Capurro, a philosopher based in Germany, argues that data is an abstraction, information refers to 'the act of communicating meaning', and knowledge 'is the event of meaning selection of a (psychic/social) system from its ‘world’ on the basis of communication'. As such, any impression of a logical hierarchy between these concepts 'is a fairytale'.[34]
One objection offered by Zins is that, while knowledge may be an exclusively cognitive phenomena, the difficulty in pointing to a given fact as being distinctively information or knowledge, but not both, makes the DIKW model unworkable.
[I]s Albert Einstein’s famous equation “E = MC2” (which is printed on my computer screen, and is definitely separated from any human mind) information or knowledge? Is “2 + 2 = 4” information or knowledge?[2]
Alternatively, information and knowledge might be seen as synonyms.[35] In answer to these criticisms, Zins argues that, subjectivist and empiricist philosophy aside, 'the three fundamental concepts of data, information, and knowledge and the relations among them, as they are perceived by leading scholars in the information science academic community', have meanings open to distinct definitions.[2] Rowley echoes this point in arguing that, where definitions of knowledge may disagree, '[t]hese various perspectives all take as their point of departure the relationship between data, information and knowledge.'[18]
American philosophers John Dewey and Arthur Bentley, arguing that 'knowledge' was 'a vague word', presented a complex alternative to DIKW including some nineteen 'terminological guide-posts'.[36][7].
Information processing theory argues that the physical world is made of information itself. Under this definition, data is either comprised of or synonymous with physical information. It is unclear, however, whether information as it is conceived in the DIKW model would be considered derivative from physical-information/data or synonymous with physical information. In the former case, the DIKW model is open to the fallacy of equivocation. In the latter, the data tier of the DIKW model is preempted by an assertion of neutral monism.
Educator Martin Frické has submitted an article critiquing the DIKW hierarchy for publication, in which he argues that the model is based on 'dated and unsatisfactory philosophical positions of operationalism and inductivism', that information and knowledge are both weak knowledge, and that wisdom is the 'possession and use of wide practical knowledge.[37]
[edit] References
Please add ISBNs for the books listed in this article or section.
Listing ISBNs makes it easier to conduct research. If the {{Cite book}} or {{citation}} templates are in use, you may add ISBNs automatically. Alternatively, you can add them manually or discuss this issue on the talk page. (January 2009)
1. ^ a b c d e f g h i j k Rowley, Jennifer (2007). 'The wisdom hierarchy: representations of the DIKW hierarchy'. Journal of Information Science 33 (2): 163-180. http://jis.sagepub.com/cgi/content/abstract/33/2/163.
2. ^ a b c d e f g h i j k l m n o p Zins, Chaim (22 January 2007). 'Conceptual Approaches for Defining Data, Information, and Knowledge'. Journal of the American Society for Information Science and Technology (Wiley Periodicals, Inc.) 58 (4): 479-493. doi:10.1002/asi. http://www.success.co.il/is/zins_definitions_dik.pdf. Retrieved on 7 January 2009.
3. ^ a b c d e f g h Zeleny, Milan (2005). Human Systems Management: Integrating Knowledge, Management and Systems. World Scientific. pp. 15-16. ISBN 9789810249137.
4. ^ Lievesley, Denise (September 2006). 'Data information knowledge chain'. Health Infomatics Now (Swindon: The British Computer Society) 1 (1): 14. http://www.bcs.org/server.php?show=ConWebDoc.7163. Retrieved on 8 January 2008.
5. ^ a b c d e Chisholm, James; Greg Warman (2007). 'Experiential Learning in Change Management'. in Silberman, Melvin L.. The Handbook of Experiential Learning. Jossey Bass. p. 321-40. ISBN 9780787982584.
6. ^ a b Choo, Chun Wei; Brian Detlor, Don Turnbull (September 2006). Web Work: Information Seeking and Knowledge Work on the World Wide Web. Kluwer Academic Publishers. p. 29-48. ISBN 978-0792364603.
7. ^ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae af ag ah ai aj ak al Wallace, Danny P. (2007). Knowledge Management: Historical and Cross-Disciplinary Themes. Libraries Unlimited. pp. 1-14. ISBN 9781591585022.
8. ^ a b c Adler, Mortimer Jerome (1970), The Time of Our Lives: The Ethics of Common Sense, Holt, Reinhart and Winston, p. 206, ISBN 9780030818363
9. ^ a b c Adler, Mortimer Jerome (1986), A Guidebook To Learning For The Lifelong Pursuit Of Wisdom, Collier Macmillan, p. 11, ISBN 9780025003408
10. ^ Eliot, T.S. (1934). ROCK: A Pageant Play Written For Performance at Sadler's Wells Theatre 28 May - 9 June 1934 On Behalf of the Forty-Five Churches Fund of the Diocese of London. London: Faber and Faber.
11. ^ Eliot, T.S. (c1964). Selected Poems. New York: Harcourt Brace Jovanovich.
12. ^ Zappa, Frank (1979). 'Packard Goose' (Song lyric). Joe's Garage: Act II & III (album).
13. ^ a b c d e f g Cleveland, Harlan (December 1982). 'Information as a Resource'. The Futurist: 34-39.
14. ^ a b c d e Sharma, Nikhil (4 February 2008). 'The Origin of the “Data Information Knowledge Wisdom” Hierarchy'. Retrieved on 7 January 2009.
15. ^ Cooley, Mike (1980). Architect or Bee?: The Human / Technology Relationship. Monroe: South End Press.
16. ^ a b c d e f g h Zeleny, Milan (1987). 'Management Support Systems: Towards Integrated Knowledge Management'. Human Systems Management 7 (1): 59–70.
17. ^ a b c d e f g Ackoff, Russell (1989), 'From Data to Wisdom', Journal of Applied Systems Analysis 16: 3-9
18. ^ a b c d e f g h i j k l m n o p q Rowley, Jennifer; Richard Hartley (2006). Organizing Knowledge: An Introduction to Managing Access to Information. Ashgate Publishing, Ltd.. pp. 5-6. ISBN 9780754644316.
19. ^ a b c Debons, Anthony; Ester Horne, Scott Cronenweth (1988). Information Science: An Integrated View. Boston: G.K. Hall. p. 5.
20. ^ a b c d e Boulding, Kenneth (1955). 'Notes on the Information Concept'. Exploration (Toronto) 6: 103-112. CP IV, pp. 21-32..
21. ^ a b c Henry, Nicholas L. (May/June 1974), 'Knowledge Management: A New Concern for Public Administration', Public Administration Review 34: 189
22. ^ Dodig-Crnkovi, Gordana, as cited in Zins, id., at pp. 482.
23. ^ Ess, Charles, as cited in Zins, id., at p. 482-83.
24. ^ Wormell, Irene, as cited in Zins, id., at p. 486.
25. ^ a b c d e Liew, Anthony (June 2007). 'Understanding Data, Information, Knowledge And Their Inter-Relationships'. Journal of Knowledge Management Practice 8 (2). http://www.tlainc.com/articl134.htm. Retrieved on 7 January 2009.
26. ^ a b c d Gamble, Paul R.; John Blackwell (educator) (2002). Knowledge Management: A State of the Art Guide. London: Kogan Page. p. 43.
27. ^ a b c d e Boiko, Bob (2005). Content Management Bible (2nd ed.). Indianapolis: Wiley. p. 57.
28. ^ Harmon, Glynn, as cited by Zins, id., at p. 483.
29. ^ a b c d e Bellinger, Gene; Durval Castro, Anthony Mills (2004). 'Data, Information, Knowledge, and Wisdom'. Retrieved on 7 January 2009.
30. ^ Debons, Anthony, as cited in Zins, id., at p. 482.
31. ^ Albrechtsen, Hanne, as cited in Zins, id., at p. 480.
32. ^ Davenport, Thomas H.; Laurence Prusack (1998). Working Knowledge: How Organizations Manage What They Know. Boston: Harvard Business School Press. pp. 5.
33. ^ Choo, Chun Wei (May 10, 2000). 'The Data-Information-Knowledge Continuum'. Web Work: Information Seeking and Knowledge Work on the World Wide Web. Retrieved on 9 January 2009.
34. ^ Capurro, Raphael, as cited in Zins, id., at p. 481
35. ^ Poli, Roberto, as cited in Zins, id., at p. 485.
36. ^ Dewey, John; Arthur F. Bentley (1949). Knowing and the Known. Boston: Beacon Press. pp. 58, 72-74.
37. ^ Frické, Martin (2008). 'The Knowledge Pyramid: A Critique of the DIKW Hierarchy' (preprint article). http://dlist.sir.arizona.edu/2327/01/The_Knowledge_Pyramid_DList.pdf"
Assinar:
Postagens (Atom)
