Meine Blogeinträge! Durchgeführte Projekte! Meine Interessen! MiCasaIsSuCasa! This is me!
MYBLOG

"The programmer, like the poet, works only slightly removed from pure thought-stuff.
He builds his castles in the air, from air, creating by exertion of the imagination.

Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.
- Frederick P. Brooks
Seite 1 | 2 | 3 >>

Die CLR - Really smart, isn’t it? erstellt am 09.09.2008

Die CLR (Common Language Runtime) ist die Laufzeitumgebung des .NET Frameworks und somit ein  wesentlicher Bestandteil, denn durch sie werden schließlich .NET Anwendungen zur Ausführung gebracht.  Doch was macht sie so besonders?

Die CLR arbeitet mit einer Zwischensprache, genau wie die Programmiersprache Java. Anstatt einen prozessorspezifischen Maschinencode zu generieren, erzeugt der Compiler einer .NET-Sprache einen plattformunabhängigen Zwischencode. Dieser heißt Microsoft Intermediate Language (MSIL) und wird durch die Laufzeitumgebung zur Ausführung gebracht.

Was zählt ist das Außenverhalten

Die CLR kommt auf verschiedenen Plattformen zum Einsatz, seien das Betriebssysteme, elektronische Geräte, oder innerhalb einer Sandbox wie es bei Silverlight der Fall ist. In all diesen Fällen ist die Ausführung des IL-Codes der Plattform angepasst.

Eine Desktop-Anwendung wird zum Beispiel durch die CLR des .Net Frameworks innerhalb von Windows ausgeführt. Hier wird die Anwendung durch einen Just-In-Time Compiler stückchenweise in Maschinencode übersetzt und erst anschließend zur Ausführung gebracht. Dadurch, dass nicht interpretiert, sondern vor der Ausführung kompiliert wird und der Just-in-Time-Compiler sehr schnell ist, ist der Performance-Verlust durch die Intermediation gering. Im Zweifel gibt es auch die Möglichkeit, das Ergebnis der Kompilierung von MSIL zu Maschinencode zu speichern und später auszuführen. Dies wird als Native Image bezeichnet. Ein Native Image ist aber nicht mehr plattformunabhängig. Anders ist es bei dem .Net Microframework, hier kommt der IL-Code durch Interpretation zur Ausführung. Es ist ebenfalls möglich den IL-Code vorher komplett in Maschinen-Code zu übersetzen.

Das Wichtige der verschiedenen Vorgehensweisen der Laufzeitumgebung ist, dass das Verhalten nach außen hin dasselbe bleibt. Die CLR ist eine Blackbox, die Interna interessieren uns nicht. Der IL-Code, bzw. die Spezifikation, welche den IL-Code beschreibt dient als Schnittstellendefinition zwischen dem .Net Sprachcompiler und der CLR, welche den Code zur Ausführung bringt. Somit ist es möglich denselben Code auf verschiedenen Plattformen auszuführen. Es muss für jede Plattform nur eine passende Laufzeitumgebung vorhanden sein.

Das besondere darin?!

Durch diese Zwischensprache und der Laufzeitumgebung ist die Ausführung auf mehreren Plattformen möglich. Wenn man direkt auf Maschinencode kompiliert, braucht man für jede andere Plattform einen anderen Compiler und das für jede Sprache. Durch die Zwischensprache brauche ich für eine Sprache nur einen Compiler auf den IL-Code und für jede Plattform eine Laufzeitumgebung, welche diesen IL-Code entsprechend zur Ausführung bringt.

Zudem löst die CLR das Problem, dass bisher jede Sprache seine eigene Laufzeitumgebung benötigt hat und diese Laufzeitumgebungen sehr unterschiedliche Dienste bereitgestellt haben, was deutliche Unterschiede in der Programmierweise und im Programmierkomfort mit sich gebracht hat. Die .NET CLR stellt z. Bsp. einen Garbage Collector, Exception Handling, ein Sicherheitssystem und die Interoperabilität mit nicht .NET-Anwendungen bereit.

Des Weiteren enthält der IL-Code Zusatzinformationen, sogenannte Meta-Daten durch welche die Ausführung des Programms von der Laufzeitumgebung verwaltet werden kann. Programmcode, der im Rahmen der CLR ausgeführt wird, heißt Managed Code. Der restliche Code wird entsprechend Unmanaged Code genannt.

Unter der Lupe

Wenn eine .NET-Anwendung gestartet wird, ruft Windows nicht die CLR selbst direkt auf, sondern zunächst einen Runtime Host. Dieser lädt die CLR und übergibt dieser den Einstiegspunkt für die Anwendung. Es gibt verschiedene Hosts: den Shell Runtime Host, den Internet Explorer Runtime Host und ASP.NET sowie auch das Silverlight Browser Plug-In. Abbildung 2 visualisiert diesen Sachverhalt etwas näher. Auf der linken Seite befindet sich der Unmanaged Hosting Code der die Laufzeitumgebung startet und auf der Rechten der Managed Code mit den für die CLR spezifizierten Konzepten wie beispielsweise Anwendungsgrenzen.

clr_hosting.jpg

Um nun den von einem .Net Sprachcompiler erstellten IL-Code in der CLR auszuführen muss diese von einem Runtime Host geladen und initialisiert werden. Für diesen Startprozess ist eine vom .NET Framework bereitgestellte API zuständig, welche sich in der Datei mscoree.dll befindet. Weitere Funktionen zur Steuerung der CLR befinden sich in der Datei mscorsvr.dll oder mscorwks.dll. Je nachdem ob die CLR auf einem Server oder einer Workstation läuft. Die wesentliche Funktion zum erstellen einer CLR ist CorBindToRuntimeEx der Datei mscoree.dll. Abbildung 3 zeigt diese zusammen mit der Angabe spezieller Parameter.

create_clr.jpg

Der erste Parameter ist für die Angabe der zu verwendenden Versionsnummer der CLR zuständig. Wird wie hier keine gemacht, so wird auf die neueste Version zugegriffen. Danach wird bestimmt ob die Server oder Workstation Variante verwendet wird. Zudem folgen Angaben zum Anpassen der CLR, wie beispielsweise Nebenläufigkeit der Garbage Collection oder Loader Optimization. Die letzten Parameter sind optional und dienen dazu einen Zeiger auf das gewünschte Interface zu erhalten, womit es möglich ist die CLR noch weiter anzupassen. Ich gehe an dieser Stelle nicht weiter auf die Parameter ein, diese können jedoch in folgendem Artikel nachgelesen werden: MSDN-Artikel  vom März 2001.

Die Funktion CorBindToRuntimeEx erstellt nun eine Instanz der CLR und gibt uns durch den Zeiger spRuntimeHost die Möglichkeit diese zu steuern. Als nächstes wird durch spRuntimeHost->Start der CLR Prozess gestartet.

Wer das Ganze selbst ausprobieren möchte, für den habe ich ein kleines Projekt erstellt, welches eine solche Laufzeitumgebung erstellt und eine Anwendung ausführt.

Sample CLR Host Project

Artikel im PDF-Format


Keine Kommentare
 
  Kommentar hinzufügen | Permalink  


Silverlight, ein Browser Plug-In erstellt am 03.08.2008

Für alle die meinen letzten Workshop nicht besuchen konnten, da sie bereits im Urlaub sind oder es durch das Feiern nach den Vorlesungen nicht geschafft haben früh aus dem Bett zu kommen, habe ich hier eine kleine Zusammenfassung.

Im Bereich des Marketings wird Silverlight, als eine Technologie, welche die Erstellung interaktiver, multimedialer Anwendungen für das Web ermöglicht, beschrieben. Hinzugefügt wird häufig, das Silverlight Plattform- und Betriebssystemunabhängig und ein Browser Plug-In ist. Doch uns interessiert in diesem Artikel der technische Hintergrund. Warum ist es unabhängig von der Plattform? Wie ermöglicht ein einfaches Browser Plug-In die Erstellung interaktiver multimedialer Anwendungen?

Wie schon in der Überschrift angedeutet ist Silverlight ein Browser Plug-In. Es ist somit ein Programm, welches dem Browser hinzugefügt wird und somit Funktionalitäten für den Browser und für eine Webseite zur Verfügung stellt.
Im Falle von Silverlight werden Funktionen zur Erstellung einer interaktiven und multimedialen Anwendung bereitgestellt. Doch wie funktioniert das Ganze?

Eine Silverlight Anwendung besteht aus zwei Bereichen. Einmal die Darstellung der Oberfläche - Aussehen, Animation, Interaktion -  und zum Anderen die Steuerung der Oberfläche und des Verhaltens der Anwendung. Das Konzept, welches hier verwendet wird ist vielen vielleicht schon von der Programmierung von Webseiten bekannt: Die Trennung von Design und Code.

Silverlight verwendet zur Beschreibung der Oberfläche eine auf XML basierende Sprache - XAML (Extensible Application Markup Language). Zur Steuerung des Verhaltens der Anwendung können Sprachen wie JavaScript, C#, IronPython und IronRuby verwendet werden. Warum das möglich, wird später verdeutlicht.

Bisher haben wir den Aufbau einer Silverlight Anwendung betrachtet, jetzt gehe ich auf das Plug-In näher ein. Wie in Abbildung 1 zu sehen ist wird das Plug-In in drei  Bereiche eingeteilt.  Der Presentation Core ist für das parsen der Beschreibung der Oberfläche zuständig. Die Common Language Runtime führt den Code aus und die Base Class Library dient als Framework, welches bereits bestimmte Funktionalitäten zur Verfügung stellt. In Silverlight 1.0 gibt es nur den Presentation Core. Zur Steuerung des Verhaltens der Anwendung wird daher JavaScript verwendet.

Wir sehen auch schon in der Einteilung des Plug-Ins den Bezug zu dem Konzept von Trennung zwischen Design und Code. Es gibt den Presentation Core zum Rendern von XAML und zur Darstellung der Oberfläche und andererseits eine Laufzeitumgebung, welche den Code-Behind zur Ausführung bringt.

Objekt Modelle

Wie weiter oben angesprochen ist XAML  ein XML-Dialekt und wird zur Beschreibung einer Oberfläche verwendet.  Wie auch in XML bilden in XAML die Elemente eine Baumstruktur, das sogenannte Silverlight Objekt Modell. Dasselbe geschieht ebenfalls bei einer Webseite. Hier wird die Oberfläche durch HTML beschrieben und kann so in eine Baumstruktur überführt werden. Dies bildet das Objekt Modell der HTML Seite. Abbildung 2 verdeutlicht diesen Sachverhalt.

Wie in Abbildung 2 zu sehen ist wird eine Silverlight Anwendung innerhalb eines Div-Tags in die Webseite eingefügt. Es ist möglich die XAML Beschreibung aus einer externen Datei zu laden oder direkt in die HTML Datei einzubetten.

Warum ist es möglich mit JavaScript eine Silverlight-Anwendung zu steuern? Sind das nicht zwei unterschiedliche Welten?!

Damit diese beiden Welten kommunizieren können werden mehrere Schnittstellen benötigt. Die Schnittstelle zwischen HTML und dem Silverlight Plug-In bildet das Object-Tag. Das ist eine allgemein gehaltene Schnittstelle von HTML und dient dazu externe Daten oder auch Programme, wie das Silverlight Plug-In, zur Anzeige auf der Webseite einzubinden. Listing 1 zeigt die Einbettung einer Silverlight Anwendung in eine Webseite. Um nun von JavaScript auf das Silverlight Plug-In zu zugreifen wird eine weitere Schnittstelle benötigt – das Document Object Model (DOM).

silverlight_listing1.gif

Das Document Object Model ist eine Schnittstelle welche einen einheitlichen Zugriff auf das Objekt Modell der HTML-Seite ermöglicht und dient uns als Schnittstelle zwischen JavaScript und dem Silverlight Plug-In. Listing 2 zeigt den Zugriff von JavaScript auf das Silverlight Plug-In.

silverlight_listing2.gif

Durch den Aufruf von GetElementById ist es möglich ein JavaScript Objekt, welches das Div-Tag mit dem Bezeichner silverlightControlHost repräsentiert zu erstellen. Innerhalb dieses Objektes befindet sich als firstChild ein JavaScript Objekt des Object-Tags,  welches die Schnittstelle zu dem Silverlight Plug-In  darstellt.  Warum sich auch eine Referenz auf ein Objekt, welches das Object-Tag repräsentiert, darin befindet, erklärt sich bei der Betrachtung von Listing 1 fast von selbst. In Listing 1 befindet sich genau dieses Object-Tag als erstes Kind-Element innerhalb des Div-Containers und durch den Aufruf von GetElementById erzeugen wir ein Objekt welches ab dem übergebenen Bezeichner die Baumstruktur repräsentiert.

Das JavaScript Objekt, welches das Object-Tag repräsentiert, enthält nun auch die Funktionen die das Silverlight Plug-In zur Verfügung stellt. Dadurch ist es möglich die in XAML beschriebenen Elemente anzusprechen und Methoden und Eigenschaften dieser zu nutzen.


Damit das Silverlight Plug-In die Methoden und Eigenschaften der XAML Elemente zur Verfügung stellen kann muss sich das Plug-In ebenfalls wieder an eine Schnittstelle halten. In diesem Fall muss es sich an den Aufbau von JavaScript Objekten halten.

Habe ich etwas verpasst?

Bisher habe ich ohne es wirklich genau hervorzuheben von Silverlight 1.0 gesprochen. Diese Version enthält nur den Presentation Core, also den Bereich zur Darstellung von XAML. In Silverlight 2.0 existiert dieser genauso, nur kommen in dieser Version die Common Language Runtime und eine Base Class Library hinzu.

Was bringt das denn jetzt alles? Wir haben doch gesehen, dass wir bereits mit JavaScript das Verhalten der Anwendung steuern können?! Ich habe bereits oben angesprochen, dass Silverlight auch Sprachen wie C#, IronPython und IronRuby unterstützt. Das liegt daran das sich dieser Code durch die von Silverlight 2.0 mitgelieferte Laufzeitumgebung ausführen lässt. Innerhalb dieser wird der Code in einem kontrollierten Bereich ausgeführt. Es wird Exception Handling, Garbage Collection und weitere Features von ihr unterstützt. Die Base Class Library unterstützt gezielt die neuen Bereiche wie die Windows Communication Foundation, viele konzepte der Windows Presentation Foundation sowie Benutzersteuerelemente. Desweiteren werden dynamische Sprachen unterstützt.

Einen umfassenderen Überblick darüber gibt es unter folgendem Link:

http://msdn.microsoft.com/en-us/library/bb404713(VS.95).aspx


Ich hoffe, dass ich hiermit ein Paar grundlegende Fragen zum Thema Silverlight klären konnte. Probeweise stelle ich ich ein Paar meiner Artikel als PDF Dokumente Online. Diesen Artikel gibt es hier zum Download. Da mein Kommentar Feld im Moment nicht eingeschaltet ist - vielen Dank an alle Spammer da draußen - würde ich mir von meinen ganzen Lesern wünschen mir einfach per E-Mail (denis.dwornitzak@student-partners.com) zu schreiben was ihr an meinen Artikeln schlecht findet, gut findet, was ich besser machen könnte und was euch sonst noch so einfällt.


Keine Kommentare
 
  Kommentar hinzufügen | Permalink  


Veranstaltungsinformation erstellt am 18.07.2008

Da der Internetauftritt des Studentprogram-South abgeschaltet wurde, werde ich die Informationen zu unseren Veranstaltungen in meinem Blog posten. Unter dem Menüpunkt „MyStuff“ findet ihr die Präsentationen und den Source-Code zu bisherigen und zukünftigen Veranstaltungen. Auf der rechten Seite befindet sich der Terminkalender welcher die jeweils aktuellen Veranstaltungen anzeigt.

In der kommenden Woche, am 24.07.08 findet eine weitere Veranstaltung der WPF-Reihe statt (siehe rechts im Terminkalender). In Teil 3 der Serie wird Silverlight beleuchtet. Dabei werde ich versuchen das Gleichgewicht zwischen technischen Hintergründen und grafischen Aspekten zu halten, so dass es ein ausgeglichenes Gesamtbild ergibt. Mit dabei sind natürlich wieder meine neu eingeführten „Think Criticals“, welche euch zum Nachdenken anregen sollen und auch technisch anspruchsvollere Hintergründe klären sollen.


1 Kommentar
 
  Kommentar hinzufügen | Permalink  


Engineering Software erstellt am 18.04.2008

Ich habe als ich in Dallas war einen Ingenieur kennengelernt mit dem ich sehr interessante Gespräche über die „Ingenieurskunst“ geführt habe. Er heißt Renko und hat in Deutschland Verfahrenstechnik studiert, ist nun schon seit über 20 Jahren in seinem Beruf tätig und eine Koryphäe auf seinem Gebiet. Umso spannender war es für mich bei einem gemütlichen Bier und einem köstlichen texanischen T-Bone-Steak das Wissen eines echten Profis anzuzapfen. Die Tage in Dallas haben mich sehr motiviert und mir zu neuen Ansichten verholfen.

Das Leben als Ingenieur ist ein sehr Spannendes. Denn als Ingenieur erbaut man selbst Dinge aus dem nichts (creatio ex nihilo). Dabei werden vorhandene von der Natur gegebene Gesetze genutzt um Neues zu erschaffen.

Damit Maschinenbauer komplexe Anlagen entwickeln, Elektrotechniker umfangreiche Schaltungen und Chemiker komplizierte Prozesse  beherrschen können, arbeiten Sie mit Bauplänen, Schaltungsentwürfen und verschiedensten Modellen.

Wer kennt das nicht? Schon in der Schulzeit werden wir dazu bewegt zu Verallgemeinern; Abstrakt zu denken. In Physik führen wir Versuche durch welche wir zunächst anhand von Skizzen gedanklich prüfen. In der Chemie betrachten wir Formeln, welche chemische Reaktionen verursachen. Doch ist es nicht so, dass sich keiner darüber Gedanken macht, warum wir genau diese Art von Formel verwenden. Schauen wir uns ein Beispiel aus der Chemie an. Die folgende Abbildung zeigt einen chemischen Prozess wie wir ihn aus dem Unterricht kennen.

Durch anwenden der Regeln dieses Reaktionsschemas ergibt sich folgendes: Drei Wasserstoffatome mit jeweils einem Valenzelektron bilden zusammen mit einem Stickstoffatom, welches auf der äußersten Schale fünf Elektronen besitzt, ein Ammoniak Molekül (An dieser Stelle wurde vernachlässigt, dass Gase unter Normalbedingung von Druck und Temperatur nie einzeln auftreten sondern immer im Verband). Das Besondere an diesem Modell ist, das es leicht verstehbar und anwendbar ist sobald man sich mit den Regeln vertraut gemacht hat.

Letztendlich sind Formeln wie wir sie aus der Chemie kennen oder auch Schaltpläne aus der Elektrotechnik nichts anderes als Modelle, welche sich durchgesetzt haben, da sie das Verhalten von chemischen Abläufen bzw. elektronischen Systemen sehr genau abbilden. Solche Modelle helfen uns komplexe Vorgänge verstehbar und beherrschbar zu machen. Wir können damit komplexe Vorgänge auf ein Konzept, welches systematisch angewandt wird, verallgemeinern und somit die Komplexität verringern.

Was hat das denn mit Software Engineering (SE) zu tun? Wir bauen doch Software? Und genau hier liegt ein großer Irrtum. Denn Software bauen ist im SE nur die halbe Miete. „Engineering“ steht dafür, dass es ebenso eine Ingenieursdisziplin ist. Wir erbauen wie Ingenieure in anderen Wissenschaften neue Dinge anhand gegebener Gesetze. Betrachten wir nun ein Beispiel aus der UML (Unified Modelling Language).

Dieses Diagramm aus der UML besitzt ebenfalls wie das Modell der chemischen Formel seine eigenen Regeln. Es beschreibt die Komposition von Objekten. Somit ist der Lebenskontext von Objekt B an Objekt A gekoppelt.

Der wesentliche Unterschied im Software-Engineering ist, dass wir bis auf ein grundlegendes Gesetz keine Vorgaben bzw. Einschränkungen beim erbauen von Software-Systemen haben *. Das einzige Gesetz welchem wir im SE unterliegen ist das Gesetz des nächsten Befehls. Das uns dadurch sehr viele Freiheiten gegeben werden führt dazu, dass wir unsere eigenen Konzeptwelten entwerfen um uns schließlich selbst an Vorgaben und Gesetze zu binden. Damit versuchen wir, wie es uns die Natur vormacht, komplexe Systeme greifbarer; verstehbarer zu machen. Doch genau diese Freiheit bringt ebenso ihre Schwierigkeiten mit sich. Es kann z. Bsp. kein einheitliches Vorgehen für das Erstellen von Software geben. Jedes Problem das in Software gegossen wird muss auf seine eigene spezielle Art angegangen werden. Dabei können wir lediglich versuchen vorhandene Vorgehensweisen und Modelle auf das neue Problem anzuwenden - doch das muss nicht immer die beste Lösung sein. So wird es im SE immer Variationen von Konzepten geben auf die man sich stützen wird.

Ein anderer Ansatz der genau auf diese Problematik eingeht sind domänenspezifische Sprachen. Diese verfolgen den Gedanken für ein Problem ein geeignetes Modell zu entwerfen, welches den Umgang mit diesem Problem beherrschbar und auch verstehbarer macht. Domänenspezifische Sprachen betrachten somit direkt die Problemdomäne.

Die Gespräche mit Renko haben mich auf eine weitere Problematik aufmerksam gemacht. Als Software Engineer sollte man nicht nur in seiner Software Welt beheimatet sein sondern auch über den Tellerrand hinausblicken. Damit ist gemeint, dass man Vorgehensweisen anderer Ingenieursdisziplinen betrachten soll. Schließlich muss sich ein Ingenieur nicht nur in seinem Bereich auskennen sondern sich ebenso mit anderen Ingenieuren verständigen können. Als Mikrotechnologe habe ich umfangreiche Kenntnisse über die chemischen Prozesse in der Halbleitertechnik und als Elektrofachkraft genügend Grundkenntnisse um mit Profis zusammenarbeiten zu können. Desweiteren können in manchem Fällen die Techniken aus einem anderen Fach im SE sehr nützlich sein.

 

* Was uns als Mensch wirklich einschränkt ist unsere Sichtweise auf ein vorhandenes Problem. Wir Menschen lernen im Allgemeinen durch Erfahrungen aus unserer Umgebung und wenden das gelernte auf neue Aufgaben an. Nur werden wir es wohl niemals schaffen über das Lernen von Dingen aus unserer Umgebung hinauszugehen.


Keine Kommentare
 
  Kommentar hinzufügen | Permalink  


Geschafft, es ist - das Jahr 2007 erstellt am 30.12.2007

Nun ist es soweit. Das Jahr 2007 endet mit seinen 365 Tagen und das Jahr 2008 beginnt. Zum Jahreswechsel hin habe ich meine Serie "Braindump" begonnen. In dieser Serie von Blogeinträgen werde ich meine Gedanken zu verschiedenen Themen äußern. Für das kommende Jahr habe ich mir vorgenommen mein Blogsystem dahingehend zu erweitern, dass jeder bei meinen Einträgen mitmischen kann. Bis dahin wünsche ich allen Lesern und Leserinnen einen guten Rutsch und ein frohes neues Jahr!


Keine Kommentare
 
  Kommentar hinzufügen | Permalink  


Mentale Gedankenmodelle erstellt am 30.12.2007

In dem Software-Engineering, speziell dem Usability-Engineering, hatten wir mit mentalen Gedankenmodellen zu tun. Diese entwirft ein Benutzer beim Umgang mit einer GUI. Wir als SW-Engineer müssen unsere Oberflächen so entwerfen, das der Benutzer ein konsistentes mentales Modell bilden kann. Das bedeutet das z.Bsp. ein Button das machen soll was der Benutzer durch  die Bezeichnung des Buttons bereits ahnt.

Wir Menschen bilden nicht nur mentale Modelle beim Umgang mit Software, sondern sie sind Bestandteil unseres alltäglichen Lebens. Beispielsweise wenn wir die Heizung einschalten dann wird der Raum wärmer. Das ist jetzt nur ein einfaches Beispiel um verständlich zu zeigen was so ein Modell sein soll. Ein solches Gedankenmodell ist durch „Wenn…dann…“-Aussagen geprägt.

Nehmen wir ein komplexeres Beispiel. Beispielsweise das Marketing einer Firma. Um ein Produkt auf dem Markt erfolgreich zu verkaufen benötigt man ein sehr umfangreiches mentalles Modell des Verhaltens des Marktes. Ein Manager der so ein Modell sehr nah an das tatsächliche Verhalten des Marktes und der Zielgruppe seines Produktes angepasst hat, der wird sein Produkt erfolgreich verkaufen können  da er bereits vorhersagen kann was auf dem Markt gewünscht ist.

Nenne ich ein anderes Beispiel das uns Studenten etwas näher liegt. Vor den Klausuren kommt folgendes Szenario an jeder Uni sehr häufig vor.

Peter meint zu Pan: „Oh man diese Klausur schaffe ich nie“. Pan zu Peter: „Klar schaffst du das, ist doch gar nicht so schwer“. Peter antwortet verzweifelt: „Ich verstehe das nicht. Jede Aufgabe ist anders. Ich finde keinen Zusammenhang, einfache keine klare Linie, obwohl wir beide den gleichen Arbeitsaufwand investiert haben“.

Wer kennt das nicht. Irgendeine Vorlesung fällt einem immer schwer. Es kann nicht alles einfach sein. Wäre ja auch langweilig. Jetzt zum Szenario.

Aus diesem Szenario geht hervor, dass Peter keine Ahnung von diesem nicht genannten Fach hat und Pan sich darin schon sehr gut auszukennen scheint. Der Unterschied zwischen diesen beiden Personen liegt darin, das Pan im Laufe der erledigten Aufgaben ein mentales Modell, welches sehr Nahe am tatsächlichen Verhalten des Kontextes dieser Aufgabenstellungen liegt, entwickelt hat. Peter hingegen hat es nicht geschafft ein solches Modell zu entwickeln, welches sehr nahe an dem Verhalten des Kontextes der Aufgabenstellungen liegt.

Um jetzt noch ein Stückchen weiter von der Informatik abzuschweifen möchte ich weiter gehen und die Sicht auf Intelligenz von einer anderen Perspektive sehen. Das obige Beispiel mit den beiden Studenten bringt mich dazu zu behaupten das Intelligenz davon abhängt wie passend eine Person ein mentales Modell für ein Verhalten von etwas entwerfen kann.  Mit passend meine ich, dass das gedankliche Modell, welches unser Gehirn entwirft, sehr nahe an dem Verhalten des untersuchten Kontextes liegt.

Gehe ich zurück auf das obige Marketing-Beispiel, bei dem sehr viele Einflüsse zusammenfließen um vorherzusagen ob ein Produkt auf dem Markt ankommt oder nicht. Um hier ein geeignetes Modell zu entwickeln werden weitaus komplexere Gedankengänge benötigt als beim Einschalten der Heizung.

Wir Menschen verwenden ständig unsere eigenen Gedankenmodelle um so unsere eigene Sicht auf die Dinge zu erhalten. In manchen Bereichen müssen wir diese nicht miteinander abstimmen und in manchen wie beispielsweise der Schule ist es notwendig unsere gedanklichen Modelle, unsere Sichten  auf die Dinge, miteinander anzupassen.  So hat jeder seine ganz persönliche Sicht auf die Welt.

PS: Auch dieser Blogeintrag ist ein mentales Gedankenmodell. Somit ist ein mentales Gedankenmodell wiederum ein Modell, eine Beschreibung.


Keine Kommentare
 
  Kommentar hinzufügen | Permalink  


Seite 1 | 2 | 3 >>

Anzeigename: deSiriX-oNe
Realname: Denis Dwornitzak
Studiengang:
Software-Engineering

Kontakt: E-Mail

Weitere Informationen gibt's hier...
 
Die letzten Einträge
 
Links
 
Terminübersicht

C# 3.0 und LINQ

Datum: 24.09.2009 - 09:00 Uhr
Dauer: ca. 4 Std.
Ort: HS Esslingen, Geb.1 Raum F1.205
Referent: Denis Dwornitzak, Andreas Maier

Downloads: Präsentation und Materialien

Windows Presentation Foundation

Datum: 25.09.2009 - 09:00 Uhr
Dauer: ca. 4 Std.
Ort: HS Esslingen, Geb.1 Raum F1.205
Referent: Denis Dwornitzak, Andreas Maier

Downloads: Präsentation und Materialien

The almighty .NET language - C++/CLI

Datum: 30.05.2009 - 08:30 Uhr
Dauer: ca. 4 Std.
Ort: HS Heilbronn im Raum F025
Referent: Denis Dwornitzak, Andreas Maier

Downloads: Präsentation und Materialien

Windows Presentation Foundation

Datum: 02.03.2009 - 08:30 Uhr
Dauer: ca. 4 Std.
Ort: HS Heilbronn im Raum F025
Referent: Denis Dwornitzak, Andreas Maier

Downloads: Präsentation und Materialien