Models and modelling languages

Slides:



Advertisements
Similar presentations
1 Aspects of IEEE P1471 Viewpoints in Unified Modeling Language (UML) Manzur Ashraf, BRAC University Humayra Binte Ali, Dhaka University Md.Mahfuz Ashraf,
Advertisements

Model building. Primary purpose of modelling Quantitative and qualitative external models Model construction versus model use.
CIT731: Database Development Object Oriented Modeling (OOM)
Chapter 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent.
CS 340 UML Class Diagrams. A model is an abstraction of a system, specifying the modeled system from a certain viewpoint and at a certain level of abstraction.
Conceptual Modeling in UML A super-short introduction by Ambjörn Naeve
Unified Modeling Language
Object-Oriented Analysis and Design
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Introduction To System Analysis and Design
Software Testing and Quality Assurance
Chapter 2 Data Models Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
1 UML – an overview What is UML? UML stands for Unified Modelling Language. ”The Unified Modelling Language is a visual language for specifying, constructing.
Introduction to UML Visual modeling Models and its importance
Java Programming, 3e Concepts and Techniques Chapter 1 An Introduction to Java and Program Design.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Unified Modeling Language Visual language.
1 Info 1409 Systems Analysis & Design Module Lecture 8 – Modelling tools and techniques HND Year /9 De Montfort University.
Sharif University of Technology1 Design and Use-case Realization Software Engineering Laboratory Fall 2006.
Foundations This chapter lays down the fundamental ideas and choices on which our approach is based. First, it identifies the needs of architects in the.
CASE Tools And Their Effect On Software Quality Peter Geddis – pxg07u.
Java Programming, 2E Introductory Concepts and Techniques Chapter 1 An Introduction to Java and Program Design.
UML Unified Markup Language Ziya Karakaya Atılım University, Computer Engineering
UML REVIEW –PART1 1. Introduction What is UML visual modelling language UML is a language not a methodology? Q: why is this distinction important? UML.
Modelling information systems
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
1 Lecture 3: Introducing Data Flow Diagrams (DFDs) Section 1 - The Concept of Diagrams Why use Diagrams? Diagrams as Working Documents Systems Analysis.
CIT UPES | Sept 2013 | Unified Modeling Language - UML.
Chapter 8 Architecture Analysis. 8 – Architecture Analysis 8.1 Analysis Techniques 8.2 Quantitative Analysis  Performance Views  Performance.
CS 360 Lecture 6.  A model is a simplification of reality  We build models to better understand the system being developed.  We build models of complex.
Chapter 6 – System Design II: Behavioral Models. 6.1 Models Models - what do you think of? 2.
METACASE. WHAT THIS PRESENTATION IS ABOUT  What’s META MODELING?  What’s METACASE?  METAEDIT+ 5.1 EVALUTION PROGRAM  Diagram and its kinds.
Introduction To System Analysis and Design
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
1 UML Basic Training. UML Basic training2 Agenda  Definitions: requirements, design  Basics of Unified Modeling Language 1.4  SysML.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering.
Modeling system requirements. Purpose of Models Models help an analyst clarify and refine a design. Models help simplify the complexity of information.
Algorithms & Flowchart
 What is Modeling What is Modeling  Why do we Model Why do we Model  Models in OMT Models in OMT  Principles of Modeling Principles of Modeling 
1 System Analysis and Design Using UML INSTRUCTOR: Jesmin Akhter Lecturer, IIT, JU.
UML as a Specification Language for Embedded Systems. By, Mir Ahmed Ali, Asst. Professor, ECM department, SNIST. By, Prof. Narsiah sir, Director of School.
Modeling as a Design Technique Chapter 2 Part 1: Modeling Concepts Object-Oriented Modeling and Design Byung-Hyun Ha
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Software Engineering Lecture 8 Object-Oriented Analysis.
Lecture 9-1 : Intro. to UML (Unified Modeling Language)
Week 04 Object Oriented Analysis and Designing. What is a model? A model is quicker and easier to build A model can be used in simulations, to learn more.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
Lecture 14 22/10/15. The Object-Oriented Analysis and Design  Process of progressively developing representation of a system component (or object) through.
Winter 2007SEG2101 Chapter 31 Chapter 3 Requirements Specifications.
Concepts and Realization of a Diagram Editor Generator Based on Hypergraph Transformation Author: Mark Minas Presenter: Song Gu.
2 1 Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel Data Models Why data models are important About the basic data-modeling.
Introduction to UML Hazleen Aris Software Eng. Dept., College of IT, UNITEN. …Unified Modeling Language.
1 BTS330 Visual Modeling. What is Visual Modeling? 2 Copyright © 1997 by Rational Software Corporation Computer System Business Process Order Item Ship.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
CS 501: Software Engineering Fall 1999 Lecture 15 Object-Oriented Design I.
Object Oriented Analysis & Design By Rashid Mahmood.
WELCOME TO OUR PRESENTATION UNIFIED MODELING LANGUAGE (UML)
EENG 1920 Chapter 6 System Design II: Behavioral Models 1.
Chapter 5 – System Modeling
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Object-Oriented Analysis and Design
Unified Modeling Language
Introduction to Unified Modeling Language (UML)
University of Central Florida COP 3330 Object Oriented Programming
Chapter 6 – System Design II: Behavioral Models
Introduction to UML.
Software Design Lecture : 15.
Presentation transcript:

Models and modelling languages is written in a Language Model Welcome to this introduction to graphical models and modelling languages. In this introduction we will give a broad outline of what graphical models are and motivate their use in system development. We will also discuss the difference between reality, model, concept and term. Futhermore, we will present what a modelling language is, since graphical models are based on modelling languages. is described by System

The reality – three levels People carrying out manual activities Peolpe interacting with computers This picture represents the reality. Note that in fact it is a sort of model of the reality, but let us for the sake of the argument imagine that it is the reality i.e. phenomena that exist in the reality and that we can understand with our sences. We understand that in reality there are houses, people, computers, computer networks, people who work with computers, people who communicate with other people, computers which calculates or computers which send data to other computers. We can with an informal, simplified and systematic approach divide this reality into three levels. We define the three levels like this: - at the upper level people perform manual activities, - at the middle level people interact with the interfaces of different types of computerised equipment – note that it is in fact also a form of manual activities, i.e. people write words and sentences with the help of a keyboard, read what is on the display and maybe load the computer with a compact disc, - at the lower level computerised equipment performs automatic activities. Computers carrying out automatic activities

The reality and models – three levels Business processes (in Activity Diagram) Communication between people (in Sequence Diagram) Business concepts (in Class Diagram) Use Case Here we added one more section to the right in the picture. We call it the section for graphical models/diagrams, while the left section is called ”the reality”. Once again note that what we see to the left is a sort of model of the reality, but for the sake of the argument, we will imagine that it is the reality. To the right we see models or diagrams of what is in the reality. It is usual to say that these models/diagrams will represent phenomena in the reality. The models/diagrams to the right are created in the modelling language, Unified Modelling Language or UML. According to the UML specification it is different diagrams, not models that we see to the right in the picture. Together these diagrams form a model of what we want to represent. In other words the different diagrams gives different aspects or perspectives of the model. Note that different authors are looking at the relation between model and diagram in different ways. Some authors are using models or graphical models and diagrams as synonyms. Also note that a model does not need to be graphical, it can for example be formulated as a text or a formula. If we look at the right section of the picture we can note as follows: - at the upper level there is an Activity Diagram for modelling business processes, a Sequence Diagram for modelling communication between people and a Class Diagram for modelling business concepts, i.e. the concepts that are used in the business when people are communicating orally or by sending a document, - at the middle level it is a Use Case diagram for modelling the interaction between people and computers, - at the lower level it is a Activity Diagram for modelling soft- and hardwareprocesses in computer systems, a Sequence Diagram for modelling communication within and between software as well as hardware, and a Class Diagram for modelling the information elements used by computers. As we can see some of the types of UML diagrams are used in more than one level, for example Class Diagrams, Activity Diagrams and Sequence Diagrams are used both at the upper and the lower level. Activity Diagram Sequence Diagram Information Model (in Class Diagram) The reality Graphical models/diagrams

What is a graphical model? A graphical model is a simplified and visualized description of a phenomenon (most often a system). A graphical model is made for a certain purpose – for example an aid for analysing a business or as the basis for building an information system. So what is a graphical model? A graphical model is a simplified and visualized description of a phenomenon, which is most often a system. The system can for example be a business, an information system, a stereo, or a telephone switchboard system. A graphical model is always made for a certain purpose, for example it can be used as the basis for building an information system or for the general view of an organization’s way of working.

Why graphical models? Graphical models reduce the complexity by hiding less important objects of a system and visualise the important ones Graphical models will give overview and structure – which is important when analysing and understanding complex systems. Graphical models reduce the complexity by hiding less interesting details and visualizing the important characteristics. Therefore graphical models provide general view and structure, which is central when analysing and understanding phenomena in the reality. Even relatively small systems can be complex and models are developed and used to understand these systems. Graphical models also facilitates communication between people, for example between different interested parties, who for example can be organization management, system developers, system users and clients. Graphical models can also be an efficient tool to agree on problems and solutions. Within system development it is not unusual to be faced with imprecise formulated problems. To create models of the problem is one way to specify the problem and to agree on a common interpretation of the problem. Models are also an efficient method to communicate and discuss alternative solutions to the problem. Graphical models will facilitate communication between people. Therefore, graphical models can be an efficient tool for making people agree on problems and solutions.

Graphical models in system development - Analysing tools – facilitates analysis of a business. - Design descriptions – drawings over the system to be developed or changed. Validating instrument – i.e. to validate the system towards customers and users with the help of graphical models, so that the system gets correct qualities before its done developed. Contact between customers and developers. Within system development, graphical models serve the following purposes: The graphical models can act as an analysing tool, i.e. they facilitate analysis of a business. It can for example be about to specify problems and identify reasons why the problem exists. The graphical models can also act as design descriptions, i.e. the models can act as drawings over the system to be developed or changed. Further the models can act as a validating instrument, i.e. the system can with the help of the models be validated, so that the system will have the qualities that customers and users want the system to have. It is also usual that the graphical models acts as a contract, or part of a contract between the customer and developers. Models clarifies what to be developed, i.e. the models acts as a sort of requirement specifikation for the developer to develop. When the development of the system is completed the customer can compare the result, i.e. the system, with the models, to check that he/she received what was ordered.

Two different kind of models Structural Models / Structure Diagrams - specifies static aspects of a system , i.e static relations / relations between terms. Behavioral Models / Behavioral Diagrams Models can be divided into two categories - Structural Models/Structural Diagrams and Behavioral Models/Behavioral Diagrams. Structural Models or Structural Diagrams specify the static aspects of the system, i.e. the static relations between the terms of the system. Behavioral Models or Behavioral Diagrams specify dynamic (behavioral) aspects of the system. i.e. they specify the manipulation or change of the static relations and in what order they occur. As we mentioned earlier in this presentation the UML- specification distinguish diagrams from models, while other authors’s models and diagrams are synonymous. Specifies dynamic (behavioral) aspects of the system, i.e. specifies the manipulation / the change of the static relations and in what order it occurs.

Models: structural and behavioral Structural Models/ Structure Diagrams Busines processes (in Activity Diagram) Communication between people (in Sequence Diagram) Busines concepts (in Class Diagram) Behavioral Models/ Behavioral Diagrams Use Case From the diagram earlier described, only the Class Diagrams are Structure Diagrams, the rest are Behavioral diagrams. Activity Diagram Sequence Diagram Information Model (in Class Diagram) models/diagrams

Models are written in a language Terms/concepts in a UML Activity Diagram language: action flow branch join Terms/concepts in a UML Class Diagram language: class attribute method association Language Language is written in a is written in a Behavioral Diagram Terms/concepts in a behavioral Diagram: receive order check order deliver order Structural Diagram Terms/concepts in a Structural Diagram: customer order order number A system is often described with the help of both Structure Diagrams and Behavioral Diagrams. In the picture there is a Behavioral Diagram to the left and a Structure Diagram to the right. Both of these diagrams have a number of concepts that can be represented in the reality, for example the action of receiving an order or the order itself. But what is interesting for us now is not what the elements are representing in the reality, but the symbols used for modelling ”receiving an order” and ”order” and also what these symbols mean. In the Behavioral Diagram for example, we see a rectangle with round corners and arrows between the rectangles. These symbols are of importance and can be combined according to certain rules. The rectangles with round corners represent actions, while the arrows represent the flow between the actions, i. e. the arrows states in what order the actions will be carried out. The symbols, the rules for how they can be combined, and their meening are central qualities of a modelling language. is described by is described by System [Kleppe et al, 2003]

The notation of the language/syntax and semantics Graphical modelling language contains: Notation/syntax -- states which symbols there are in the language and how they look like, how they can be combined, and how they are related to the concepts of the language, for example that an arrow represents the concept ”flow”. Semantics – defines the central concepts of the language. The concepts are usually defined in form of a Conceptual Model called Meta Model. Language is written in a A graphical modelling language contains notation/syntax and semantics. However it is not clear where the borders between these concepts are and different authors have different views of what is included in the notation/syntax and what is included in the semantics. One interpretation is that the notation/syntax states which symbols there are in the language and what they look like, how they can be combined, and how they are related to the concepts of the language, for example that an arrow represents the concept ”flow”. The semantics defines concepts like ”action”, ”flow”, ”class”, and ”attribute” in the language. These concepts are usually defined in form of a Meta Model. Diagram

A UML-diagram is based on a language UML:s Structure Diagrams and Behavioral Diagrams are written in the same language Language is written in a is written in a Behavioral Diagram Concepts in a Behavioral Diagram: order is received, order is controlled Structural Diagram Concepts in a Structural Diagram: customer, order, order number Note that UML has a common language for all types of diagrams. One concept, for example ”action” exists in several types of diagrams. is described by System is described by [Kleppe et al, 2003]

Models, languages and Meta Models Concepts in the UML language: class, association action, flow Concepts in the UML Meta Model : class, association action, flow Language Concepts in diagrams: customer, order, order number Meta Model is written in a Is defined by Diagram The semantics of a modelling language, i.e. the concepts of the modelling language, like ”action” and ”flow”, can as mentioned, be modelled in form of a Conceptual Model, which is called a Meta Model. It specifies how the modelling concepts are in relation to each other and how they can be combined. For example, UML has a Meta Model. However, note that the Meta Model does not specify the meaning of the different symbols used. This is done by using notation/syntax. UML’s specification consists for example of a notation (the syntax) and a Meta Model (the semantics). A Meta Model can define a language. Simplified you can say that the language and the Meta Model are equal. is described by System [Kleppe et al, 2003]

Graphical modelling languages Examples of graphical modelling languages: UML, E(A)R diagram, Petri nets, Event-Process Chain (EPC), IDEF0, IDEF3, Data Flow Diagram, Role-activity diagram (RAD), database diagram. Some graphical modelling languages are more expressive than others. One of the reasons for that is that certain graphical modelling languages contains more modelling elements (symbols). They can then represent more concepts, i.e. more aspects of the reality (the system). One disadvantage is that such a language contains more modelling terms for the user to learn. There are several different graphical modelling languages, for example UML, E(A)R diagram, Petri nets, Event-Process Chain (EPC), IDEF0, IDEF3, Data Flow Diagram, Role-activity diagram (RAD), database diagram. Some of these modelling languages have specified explicit Meta Models, some languages are more informal where the Meta Model is not explicitly expressed. The risk of not having an explicit Meta Model is that the language can be interpreted differently by different users. Some graphical modelling languages are more expressive than others. One of the reasons for that is that certain graphical modelling languages contains more modelling elements (symbols). They can then represent more concepts, i.e. more aspects of the reality (the system). One disadvantage with a language which contains many symbols is that the language is more difficult for the user to learn.

Modelling concepts – a comparison Class Diagram E(A)R-Diagram Database Diagram Class Entity Table Association Relation Foreign key Attribute Attribute Column Multiplicity ”Multiplicity” ”Multiplicity” Object Instance Row or post This picture shows an overview of how the three mentioned modelling languages are in relation to each other. In the table we can see which modelling elements that are comparable, sometimes almost synonyms. When talking about for example an object in a UML-Class Diagram, the meaning is often broadly speaking the same as an instance in an E(A)R-Diagram or a row or a post in a Database Diagram. However observe that the terms do not always describe the exact same concepts! Yet note that the terms not always at all, stands for the same concept!

The relation concept and term It is important to understand the distinction between concept and term when analysing businesses and when designing system. Different departments in a company can for exampel use different terms for the same concept and one term for differnt concepts. If this is not correctly understood it will make the communication between the departments more difficult and make the design of a common system for the different departments more difficult. In the same way two information systems can use different terms for the same concept and the same term for different concepts, which makes the integration of the system more difficult. Term ”Computer”

Concepts Concepts are a mental representation of one or more phenomena in the reality, like for example: Concept existing objects (expressed with substantives) aktions and events (expressed with verbs or substantivized verbs, for example ”registration”) relations and positions (expressed with substantives, adverbs or conjunctions) quality (expressed with adjectives) Term ”Computer” Concepts are a mental representation or idea of one or more phenomena in the reality, like for example objects, actions, events, relations, positions and quality. A concept can only represent one phenomenon, like for example “Nisse”, or via abstraction cover all phenomena that have certain common characteristics, like “Student”. A concept can only represent one phenomenon (“Nisse”), or via abstraction cover all phenomena that have certain common characteristics (“Student”). [Hedin et al, 2000]

Term A term is a more or less arbitrary symbol for a concept. ”Computer” A term can consist of articulated sound, a word in form of letters, a group of words, or a graphical symbol. A term is a more or less arbitrary symbol for a concept. A term can consist of articulated sound, a word in form of letters , a group of words, or a graphical symbol. The latter is central when building graphical models. Term and word can be seen as synonyms, but some authors mean that a word is becomming a term when it is defined as a component in a terminological system (terminology). Term and word can be seen as synonyms, but some authors means that a word is becomming a term when it is defined as a component in a terminological system. Terms within a certain area constitutes a terminological system (terminology). [Hedin et al, 2000]

The relation concept and term To use a concept it has to be a term for it. Term All terms refers to concepts. ”Computer” The connection between concept and term should be as unambiguous as possible, otherwise interpretation problems arises, like: - synonymy - polysemy - homonymy The distinction between concept and term can sometimes be difficult to understand, since it is not possible to communicate a concept without a term and all terms represents concepts. Term and concept can in other words not be without each other. The connection between concept and term should be as unambiguous as possible, otherwise interpretation problems arises, like: - synonymy, - polysemy, - homonymy. [Hedin et al, 2000]

The relation concept and term Concepts Terms x Synonymy A Different terms refer to the same concept (”UML” and ”Unified Modeling Language” refer to the same thing) y z Polysemy A The same term refers to different concepts. Often due to that new meanings for old terms are stipulated. (”democracy”) x B Two or more terms can be synonymous if they refer to the same concept. For example the terms “UML” and “Unified Modeling Language” are synonyms, since they refer to the same thing, the same the same concept. If two or more terms which are synonyms, are not understood as synonyms, it can make the communication more difficult. Polysemy means that the same term refers to different concepts. One typical example is the term ”democracy” which can have different meanings in different countries. Homonymy means that terms that sounds or are spelled the same way have different meanings. “Light” in form of “daylight” and “light as a feather” are in fact two different terms, although they are spelled the same way. It is becoming clear when they are to be interpreted in another language like swedish. Also homonymy can cause communication problems. Homonymy A x Terms that sounds or are spelled the same way with different meanings. “Light” B x x C [Hedin et al, 2000]

Delphic versus cryptical languages Social-science researchers are often using a vague language (“delphic language”), which causes a number of polysemy. Natural scientists use a “cryptical language” which all the time fills up with new terms and is therefore difficult to understand for non-specialists. Generally so-called delphic and cryptical languages are distinguished. Social-science researchers are often using a delphic language, i.e. a vague language, which causes a number of polysemy. That means that terms’s meanings can drift apart during debates and presentations, which makes the communication more difficult. Natural scientists use a rather “cryptical language” which all the time fills up with new terms, i.e. every new phenomenon gets a new term, and therefore becomes difficult to understand for non-specialists. The question then is where the subject computer- and systems sciences belongs. The subject has both a technical part and a social-science part. There are for example many technical terms and the number is growing all the time, which makes it more difficult for non-specialists to follow when for example a technician describes a phenomenon. At the same time popular and trendy terms have many different meanings (concepts). [Hedin et al, 2000]

Ogden’s triangle Charles Ogden (1889-1957) interested himself in the connection between: - the term (the linguistic expression) - the concept (the mental idea, the intension) - the referent (the phenomenon in the reality, the extension) Concept An english linguist , Charles Ogden, did not just make the distinction between the term and the concept, he also distinguished the referent and the concept plus the referent and the term. He constructed the Ogden’s triangle as an instrument for analysing the relations between term, concept and referent. The referent corresponds to the phenomenon that exist in the reality. The referent is usually called the extension of the term while the concept is usually called the intension. The extension can be seen as all the phenomena that exists in the real world. For example the term “computer” have the extension “ all existing computers”. The intension then is a sort of definition of the term “computer” for example “machine to handle data”. One term can be lacking referent, for example the term “unicorn”. Note that concept, term and referent should be seen from a persons perspective. This person is therefore placed in the middle of the triangle. Referent Term Ogden’s triangle ”Computer”

Ogden’s triangle Ogden’s triangle shows that a person has a mental idea (concept) about a phenomenon in the reality (referent) and to communicate with others he/she uses a symbol (term). Also note that to communicate a phenomenon in the reality (referent) we can either point at it or try to convey our idea about the referent via the language – for example with the help of a conceptual definition. Concept Ogden’s triangle shows that a person has a mental idea (concept) about a phenomenon in the reality (referent) and to communicate with others he/she uses a symbol (term). Also note that to communicate a phenomenon in the reality (referent) we can either point at it or try to convey our idea about the referent via the language – for example with the help of a conceptual definition. Referent Term Ogden’s triangle ”Computer”

Problem to interpret the reality The same phenomenon in the reality (referent) can cause different mental ideas (concepts) because of different understandings. A classical example is the planet Venus, which can be interpreted as two different concepts: “Morning star” and “Evening star”. Concept One problem with communication is that the same phenomenon in the reality, i.e. the referent, can cause different mental ideas. For example the expert and the amateur will maybe get different mental ideas when looking at a computer. Another example is the planet Venus, which can cause two mental ideas, i.e. two concepts, namely the morning star and the evening star. Referent Ogden’s triangle ”Server” ”Monitor” Term

Ogden’s triangle – problems analysis Concept Problem concept - referent: The reality is interpreted different because of different understandings Problem concept - term Synonymy Homonymy Polysemy This picture shows that problems with synonymy, homonymy and polysemy has to do with the relation ”concept – term”, while the problem that the reality is interpreted different because of different understandings has to do with the relation ”concept – referent”. Term Referent ”Computer” ”Server” ”Monitor”

Ogden’s triangle – what does this mean .... Concept - Conceptual definition - Conceptual Model Ogden’s triangle can also be used to clarify the difference between terminology and Conceptual Model. We try to place the words at the right side of the Ogden’s triangle, i.e. on the relation ”concept – term”. One terminology could then be interpreted as a list of words, while a Conceptual Model also defines the meaning of the words, i.e. clarifies the intension of the words. Yet note that several authors use the term ”terminology” as the same meaning as a number of conceptual definitions. - Terminology Term Referent ”Computer” ”Server” ”Monitor”

Conceptual modelling A Conceptual Model starts from a mental idea och tries to render a part of the reality in form of a graphical idea. Conceptual modelling is an instrument : - to analyse and define the concepts no matter what we call them (what terms we are using), - to state a terminology, i.e. which terms will be used. Conceptual Models are usually used in the analyse phase of a system development project. A Conceptual Model starts from a mental idea och tries to render a part of the reality in form of a graphical idea. Conceptual Models are used partly to analyse and define the concepts no matter what we call them (i.e. irrespective of what terms we are using), partly to state a terminology, i.e. make it clear which terms that will be used. 0..* Student Course 0..* [Hedin et al, 2000]

Ogden’s triangle Concept x married to ”married to” y Term ”Nisse” Anna This picture shows that a model, which is placed in the upper right corner, contains of both concepts and terms. Let us imagine that the two referents down to the left are married and that phenomenon will be modelled. The two referents can for example be modelled in form of ovals and the relationship between the referents is modelled in form of lines between the ovals. The ovals and the lines can also be seen as terms. Terms like “Nisse”, “Anna” and “married with” are used in combination with the symbols. If we do not know the names of the two persons who are married, they can get temporary terms like for example x and y, which can be replaced with the names when they become known. Note that the model, as we mentioned earlier defines the concepts no matter what we call them (i.e. irrespective of what terms we are using). Term ”Nisse” Anna x Referent Nisse ”married to” y ”Anna”

Ogden’s triangle Concept Anna married to ”married to” Nisse Term Now, the terms x and y are replaced with Anna and Nisse . With this example the introductory lecture covering models and modeling languages ends. Term ”Nisse” Anna x Referent Nisse ”married to” y ”Anna”