On Roles of Models in Information Systems(Arne Sølvberg)

Gustavo Carvalhoghcc@cin.ufpe.br

26 de Agosto de 2010

What is the purpose of Information Systems?

• Information systems are built in order to support some other system, by supporting the exchange of information between the other system and its environment.

• Information systems are closely connected with computer systems.

Information Systems x Computer Systems

• The computer system is seen as a part of the information system which it serves.

• In the Nordic countries it is common to distinguish between infology (the discipline of information systems) and datalogy (the discipline of data systems).

Dissatisfaction from IT-profession

• Domain issues are so different from computer issues that they demand different treatment, so that it is difficult to arrive to a unified theory.

• Domain issues are so different from each other that the relationships between the computer sphere and the various domains are so different that there is not one solution for all.

• Technology develops so fast that as soon as a solution for a computer-domain pair has been found, it is outdated by new technological innovations

Information - , data - , and domain systems

• Information systems consist of collections of data, and of information processes that collect, store, transform and distribute data in forms that make sense to the receivers of the data.

• We shall distinguish between the information system and the domain system (“the other system”) which is served by the information system.

• We shall use the term total system for the “whole” formed by the information system and the domain system.

The “Total System”

Intelligent Artifact

Environment

observation

intervention

interaction

System

Model

MappingReferencing

Modeling domain systems

• Modeling the domain is an essential part of requirements elicitation in information systems engineering

• Conceptual modeling was initiated from these application types. Depending on the nature of the particular application domain these modeling efforts are called by different names, e.g., business modeling , agent modeling, intention oriented information systems modeling.

Issues in Information Systems Engineering

• Some of the most important issues in information systems engineering are concerned with – managing information system projects – systems design approaches – modeling languages for information-, domain- and

and data systems – comprehension of specifications – modeling of the meaning of data – validation techniques – changes in the domain and the technological

environment

Engineering practice

• Information systems engineering differs from classical engineering in the cost profile of the projects

• In classical engineering, the higher spending are invoked during the last phase of the projects, when the actual realization of the engineering design is done.

• The costs in information systems engineering is associated with the requirements development, the design, the programming and testing.

• The costs of making mistakes during the design are huge in most classical engineering projects (waterfall method).

Evolution of detail

• Most solutions to engineering problems are so complex that it is impossible for anybody to understand every detail at the same time.

• A basic problem in engineering is to find an approach to developing solutions to unsurveyable systems.

Evolution of detail (cont.)

• The most common solution strategy consists in breaking a problem into simpler subproblems, then to find solutions to each subproblems so that they together form a solution to the problem.

• The decomposition of systems into subsystems stop when existing solutions are found for the system, or the system is simple enough to be understood without further decomposition.

Requirements and solutions

• Information systems have always been built in order to satisfy some purpose.

• There were two major approaches to information systems engineering and software engineering, the deductive approach and the process oriented approach, e.g., data flow oriented techniques.

• During the 1980's and 90's has seen a new approach, the “problem-oriented” approach.

• The deductive approach– the deductive approach is the assumption that

problem formulation can be separated from the problem's software solution

– This line of thinking is consistent with the recommendation of keeping requirements specification separate from the software specification (the “think-first-program-later” approaches).

Requirements and solutions

• The process oriented approach– The process oriented approach is that

problem formulation and problem solution are intertwined, that the solution to a problem at one level of detail serves as the formulation of a problem on the next level of detail.

Requirements and solutions

• The “problem-oriented” approach– The “problem-oriented” approaches rest on

the principle that designing effective solutions requires a detailed understanding of the problem.

– Only for problems of limited size is it possible to precisely and completely define the problems

Requirements and solutions

Formal and informal specification

• A desirable property of a specification language would be that it lends itself both to the informal and formal tasks.

• Unfortunately there is no such language. What we would like to have is a modeling language which supports increased formality of expression through systematic addition of specification detail, starting from an informal basis.

• Graphical languages are usually used for sketching systems structures on the road from informality to formality. These languages are widely used, e.g., UML, ER-diagrams.

Comprehension

• The need for comprehension of system specifications is complicated by the necessity that somewhere in the development process system specifications are stated in executable terms.

• A solution of the dilemma has been sought in model driven development (MDD), also known as model driven architecture and model driven engineering.

• The main idea of using the term model driven is that, in order to increase comprehensibility, software and data specifications are developed in a language that reflects the particularities of the domain. These specifications should later on be automatically translated into executable software.

Validation

• Validation is the process of comparing the desired properties of a system to the expected properties of its design, and of determining whether the expected properties of a proposed design of system satisfy the desired properties.

• The comparison between expected and desired properties is mostly based on human evaluations of informally expressed statements of system properties.

Modeling of data, information and the domain

• The goal is to find a way of modeling which makes it possible to interpret the meaning of data related with our understanding of the UoD.

• Data system languages are keys to realization of the digital system components and cannot be avoided. So we need to have parallel specifications, in three different modeling languages: data, information and the domain .

Meaning

• Digital data is always associated with meaning. Each data element represents some relevant property of the world.

• Relationships between digital data and what the data refer to are rarely explicitly stated, but are usually informally indicated by the names given to the data elements. Ex.:– NAME-OF-PERSON – EMPLOYEE

• Information modeling is an approach to provide meaning to data.

UoD – Universe of Discourse

• The term universe of discourse generally refers to the collection of objects being discussed in a specific discourse.

• The knowledge, which is represented in an information system, is totally conceptual. The data, which are stored and processed by an information system, are linguistic units, which denote concepts and referents in the Universe of Discourse.

• A database is a model of some aspect of the reality of an organization.

Modeling the UoD

• The objective is to specify information as a relation between data concepts and UoD concepts. The data concepts are data types, and the UoD concepts are class concepts and quantitative concepts. Scale concepts including measurement units and precision come additionally.

Recommendations for further work

• Information models must represent the meaning of data, that is, data should be explicitly related to the phenomena they represent;

• System models must be comprehensible on every level of systems detail;

• System models must permit specification in terms of solutions on every level of detail, in order to provide for executable specifications

Recommendations for further work

• System models must support the need for validation of design proposals during their development

• System models must support different specification detail, both formal and informal specifications

• System models must encourage systematic evolution of specification detail from low level of detail to high level of detail

Conclusion

• He propose a definition of information as a relationship between domain model concepts and data model concepts.