get the solution


Page 3 of 3123

C# Plugins mit AppDomains realisieren

By
on Regards: .NET Framework; C#;

1. Einführung

Im letzten Post konnte man ein einfaches  Beispiel sehen, wie während der Laufzeit „Plugins“ geladen und ausgeführt wurden.

Wir möchten aber die Plug-Ins von unserer Hauptanwendung isolieren und eigene Sicherheitsrichtlinien für diese festlegen. So heißt es z.B. in der MSDN

„Verwenden Sie Anwendungsdomänen, um Aufgaben zu isolieren, die einen Prozess zum Absturz bringen könnten. Wenn der Zustand der AppDomain, in der eine Aufgabe ausgeführt wird, instabil wird, kann die AppDomain ohne Auswirkungen auf den Prozess entladen werden. Dies ist wichtig, wenn ein Prozess über einen längeren Zeitraum ohne Neustart ausgeführt werden muss. Sie können auch Anwendungsdomänen verwenden, um Aufgaben zu isolieren, die keine Daten gemeinsam verwenden sollten.“
(AppDomain-Klasse, 22.08.10, http://msdn.microsoft.com/de-de/library/system.appdomain.aspx)

Ein .Net Prozess enthält mindestens eine AppDomain. Diese  StandardAppDomain wird auch Default AppDomain genannt. Jede AppDomain hat ihren eigenen virtuellen Adressenspeicher. Ein Prozess kann also mehrere AppDomains enthalten.

Da jede AppDomain ihren eigenen virtuellen Adressenspeicher hat, ergeben sich folgende Eigenschaften:

  • AppDomains können nicht auf Objekte von anderen AppDomains direkt zugreifen
  • AppDomains können entladen werden, mit Ausnahme der Default AppDomain
  • AppDomains können unterschiedliche Sicherheitsprivilegien vergeben werden
  • AppDomains können unterschiedlich konfiguriert werden (AppDomainSetup)

Wie man aus der Abbildung entnehmen kann, werden die Assemblies in den AppDomain auch getrennt behandelt. Während der Windows Prozess ausgeführt wird, kann man keine Programm-Dateien, wie z.B. die Plugin.dll ersetzen oder löschen.   Das Löschen der Plugin.dll ist erst möglich, wenn die „AppDomain 2“ entladen wurde.

Um das Verändern der Plugindatei während der Laufzeit zu ermöglichen, gibt es das Feature Shadow Copy.
Dabei wird die zu ladende Assembly in ein temporäres Verzeichnis kopiert. Die Originaldatei kann somit jederzeit ersetzt werden. Siehe dazu auch AppDomain and Shadow Copy (AppDomain and Shadow Copy, 22.08.10, http://blogs.msdn.com/b/junfeng/archive/2004/02/09/69919.aspx )

Bestimmte Grundtypen werden in jeder AppDomain benötigt. Um Ressourcen zu schonen, gibt es eine AppDomain neutrale Zone. In diese wird z.B. die MSCorLib.dll geladen da diese den Typ System.Object, System.Integer usw. enthält. Alle AppDomains können auf diese „Domain-Neutral Assemblies“ zugreifen.
Um auf Objekte von einer AppDomain auf die andere zugreifen zu können, müssen die Objekte MarshalByRefObject implementieren.

2. Sonstige Bemerkungen

Bibliotheken die mit Assemblies.Load geladen werden, „landen“ in der DefaultAppDomain. Diese Dateien werden erst nach dem Beenden des Prozesses wieder freigegeben.
Hier ein Beispielcode:

	 public static void Main(string[] Args)
	 {
	    //Gib die AppDomain zurück in der wir uns befinden
	    System.Console.WriteLine(AppDomain.CurrentDomain);
	 
	    //AppDomain erstellen
	    AppDomain appDomain = AppDomain.CreateDomain("AppDomain #2");
	 
	    //Schauen wir ob es sich um die Default Domain handelt
	    System.Console.WriteLine(AppDomain.CurrentDomain + " " + AppDomain.CurrentDomain.IsDefaultAppDomain());
	 
	    System.Console.WriteLine(appDomain + " " + appDomain.IsDefaultAppDomain());
	 
	    Print(AppDomain.CurrentDomain.GetAssemblies());
	 
	    //In unsere AppDomain lib laden
	    appDomain.DoCallBack(new CrossAppDomainDelegate(delegate()
	        {
	            System.Console.WriteLine(AppDomain.CurrentDomain);
	            Assembly.LoadFrom(@"C:\Users\martin\Plugin.dll");
	        }));
	 
	    Print(appDomain.GetAssemblies());
	}
	static void Print(System.Reflection.Assembly[] Assemblies)
	{
	    int i = 0;
	    foreach (System.Reflection.Assembly assem in Assemblies)
	        System.Console.WriteLine("[{0}] {1}", ++i, assem.GetName().Name);
	}

Die Ausgabe dazu sieht wie folgt aus:

	Die Ausgabe dazu sieht wie folgt aus:
	Name:ConsoleApplication1.vshost.exe
	Keine Kontextrichtlinien vorhanden.
	 
	Name:ConsoleApplication1.vshost.exe
	Keine Kontextrichtlinien vorhanden.
	 True
	Name:AppDomain #2
	Keine Kontextrichtlinien vorhanden.
	 False
	[1] mscorlib
	[2] Microsoft.VisualStudio.HostingProcess.Utilities
	[3] System.Windows.Forms
	[4] Microsoft.VisualStudio.HostingProcess.Utilities.Sync
	[5] System
	[6] Microsoft.VisualStudio.Debugger.Runtime
	[7] mscorlib.resources
	[8] vshost
	[9] System.Core
	[10] System.Xml.Linq
	[11] System.Data.DataSetExtensions
	[12] System.Data
	[13] System.Xml
	[14] WindowsBase
	[15] ConsoleApplication1
	[16] System.Drawing
	[17] Accessibility
	[18] DomainManager
	[19] IPlugin
	 
	Name:AppDomain #2
	Keine Kontextrichtlinien vorhanden.
	 
	[1] mscorlib
	[2] Microsoft.VisualStudio.HostingProcess.Utilities
	[3] ConsoleApplication1
	[4] Plugin

Mit dem AppDomains sind wir  unserem Ziel, einen robusten und flexiblen Plugin-Manager zu schreiben, einiges näher gekommen. Als nächstes gilt es die Hostanwendung vor Exceptions der Plugins zu schützen. Das heißt ein Plugin soll nicht die komplette Anwendung crashen.

Eine Möglichkeit wäre für die Plugins einen Wrapper oder einen Proxy zu erstellen.   Dazu müssen die Plugin-Funktionen mit einem Try/Catch Block versehen werden. Bei einer Exception könnte man auch ein Event auslösen.

Beispiel Code:

        public interface IPlugin
	{
	    public void Execute();
	    public void Connect(object info);
	}    
	public class PluginProxy : System.MarshalByRefObject, IPlugin
	{
	    private IPlugin m_IPlugin;
	 
	    //Other Code for Events etc. 
	    void Init(string assemblyName, string typeName)
	    {
	        m_IPlugin = (IPlugin)Activator.CreateInstance(assemblyName, typeof(IPlugin));
	    }
	    public void Execute()
	    {
	        try
	        {
	            m_IPlugin.Execute();
	        }
	        catch (Exception ex)
	        {
	            //Event feuern
	            this.OnException(ex);
	        }
	    }
	    public void Connect(object info)
	    {
	        try
	        {
	            m_IPlugin.Connect(info);
	        }
	        catch (Exception ex)
	        {
	            //Event feuern
	            this.OnException(ex);
	        }
	    }
	}

Damit kann man schon einige Exceptions abfangen. Allerdings sind wir nicht in der Lage auf interne Ereignisse der Plugins zu reagieren. Das heißt,  wenn ein Plugin einen Timer oder ein FileSystemWatcher-Ereignis abonniert (könnte genauso irgendein anderes Ereignis sein) das eine Exception auslöst, können wir diese nicht abfangen.

Die Host Anwendung wird also abstürzen wenn eines der internen Plugin –Ereignisse eine Exception wirft. Da nützen uns auch die AppDomains nichts, die die Plugins isolieren. Zumindest kenne ich in diesem Zusammenhang keine Lösung, die das Abstürzen der Hostanwendung verhindern würde.  Auch im Internet habe ich dazu nichts gefunden.

Jedoch gibt es einen anderen Lösungsansatz, den ich aufgegriffen habe.

„In den Versionen 1.0 und 1.1 von .NET Framework wird eine unbehandelte Ausnahme, die in einem anderen als dem Hauptanwendungsthread auftritt, von der Laufzeit abgefangen und führt daher nicht zum Beenden der Anwendung. Das UnhandledException-Ereignis kann also ausgelöst werden, ohne dass die Anwendung beendet wird. Ab .NET Framework Version 2.0 wurde diese Option für unbehandelte Ausnahmen in untergeordneten Threads entfernt, da solche stillen Fehler zu einer Verschlechterung der Leistung, beschädigten Daten und Lockups führten, was insgesamt schwer zu beheben war.“ (Ausnahmen in verwalteten Threads, 22.08.10, http://msdn.microsoft.com/de-de/library/ms228965(v=VS.100).aspx)

Die Idee ist also, die Anwendung bei unbehandelten Ausnahmen auf das Verhalten der Common Language Runtime auf Versionen 1.0 und 1.1 zurück zu setzen, damit der Haupt-Thread weiter läuft.

Das macht man indem man mit der Funktion ICLRPolicyManager::SetUnhandledExceptionPolicy die gewünschte Policy setzt. Leider stellt der AppDomainManager keine passende managed Funktion bereit. Deshalb kann man das Runtime verhalten in der Application.config wie folgt setzen.

        <?xml version="1.0" encoding="utf-8" ?>
	<configuration>
	  <runtime>
	    <legacyUnhandledExceptionPolicy enabled="true" />
	  </runtime>
	</configuration>

Dabei muss unbedingt beachtet werden, dass sich der Debugger mit der gesetzten Abwärtskompatibilität falsch verhält.

Um zu sehen ob das Programm auch erwartungsgemäß funktioniert, muss man das kompilierte Programm  manuell, ohne den Debugger bzw. Visual Studio 2008 starten.

Für reine Debugging Zwecke, die nicht die Plugins betreffen, würde ich die Abwärtskompatibilität temporär entfernen.

Ein Beispiel bzgl. der gesetzten Abwärtskompatibilität wird in diesem Blog Eintrag demonstriert. Allerdings finde ich, dass der Autor die Demo unnötig mit seiner eigenen Exception Klasse aufgebläht hat. Wie man das viel einfacher und mit weniger Code machen kann, sieht man in meiner PluginManger bzw. PluginDomain Klasse.

3. AppDomain und Plugin erstellen

Bevor man aber überhaupt die Plugin-Isolation machen kann, muss man sich Gedanken machen wie man die Plugins in Kombination mit den AppDomains handhabt.

Meine Idee ist für jedes Plugin eine separate AppDomain zu erstellen. Das Erstellen der AppDomain für das Plugin soll eine Klasse für uns erledigen die PluginDomain heißt. Es handelt sich dabei um eine generische Klasse, damit man den Plugin-Typ angeben kann. Den Generischen Typ brauchen wir später beim Erstellen der Plugin-Instanz und um die Instanz speichern. Das macht das Arbeiten mit dem Plugin einfacher, da der „Cast“ Vorgang weg fällt.

Die Klasse wird mit dem Konstruktor PluginDomain(string assemblyPath) initialisiert, wobei der Parameter assemblyPath den Pfad des Plugins enthält. Im Konstruktor wird die AppDomain mit Hilfe der Klasse AppDomainSetup konfiguriert und erstellt.

        //Beim erstellen der AppDomain wird die Funktion GetInterfaceTypes aufgerufen
	appDomainSetup.AppDomainInitializer = new AppDomainInitializer(GetInterfaceTypes);
	//Parameter der Funktion übergeben, Pfad des Plugins und nach welchem Interface gesucht werden soll
	appDomainSetup.AppDomainInitializerArguments = new string[] { assemblyPath, typeof(T).ToString() };

Der Eigenschaft AppDomainSetup.AppDomainInitializer  wird der delegate GetInterfaceTypes zu gewiesen. Wenn die AppDomain initialisiert wird, wird die Methode GetInterfaceTypesu in der erstellten AppDomain ausgeführt. Wir wollen in die erstellte AppDomain die Plugin-Assembly laden. Theoretisch könnte man dieses Vorhaben auch mit der Funktion AppDomain.DoCallBack realisieren.

        /// <summary>
	/// Diese Methode sucht in der übgergebenen Datei die erste Klassen die das übergebene
	/// Interface implementieren.
	/// </summary>
	/// <param name="args">Der erste Parameter ist der Datepfad der Datei die nach dem gesuchten 
	/// Interface durchsucht werden soll.
	/// Im zweiten Parameter wird das Interface übergeben.</param>
	private static void GetInterfaceTypes(string[] args)
	{
	    AppDomain appDomain = System.AppDomain.CurrentDomain;
	 
	    //Laden wir die Plugin Assembly in unsere AppDomain
	    System.Reflection.Assembly assembly = System.Reflection.Assembly.LoadFrom(args[0]);
	 
	    String pluginType = String.Empty;
	 
	    foreach (Type type in assembly.GetTypes())
	    {
	        //Check only Public Types
	        if (type.IsPublic)
	        {
	            //Check only not abstract Types
	            if (!type.IsAbstract)
	            {
	                //look up the interface
	                Type typeInterface = type.GetInterface(args[1], true);
	                if (typeInterface != null)
	                {
	                    //return the type which implements our interface
	                    pluginType = type.FullName;
	                }
	            }
	        }
	    }
	 
	    //Daten über die Methode SetData setzen, weil der AppDomainInitializer-Delegate
	    //kein Rückgabewert hat. Mit GetData können die Daten wieder abgeholt werden
	    //http://msdn.microsoft.com/en-us/library/37z40s1c.aspx
	    appDomain.SetData(_GetDataPluginTypes, pluginType);
	}

In der Methode GetInterfaceTypes welche unsere CallBack Funktion ist, durchsuchen wir die Assembly nach dem Typ der unser Plugin-Interface implementiert. Der Vorgang ist ähnlich diesem (siehe GetModul). Denn gefunden Typen wollen wir zurückgeben damit wir eine Instanz vom Plugin erstellen können. Weil der AppDomainInitializer-Delegate kein Rückgabewert besitzt müssen wir mit der Methode AppDomain.SetDataund GetData arbeiten. Mit diesen Methoden kann man Daten zwischen AppDomains transportieren.

Bei diesen Methoden muss man folgendes beachten: Angenommen wir würden das Objekt typeInterface mit SetData in unserer Plugin AppDomain verschicken und in der Default AppDomain wieder mit GetData abholen, hätte das folgenden Effekt. Der Typ typeInterface ist in der Default AppDomain nicht bekannt, da die Plugin-Assembly nur in der Plugin-AppDomain geladen ist. Die Plugin-Assembly wird also auch in die Default AppDomain geladen.

Nach dem die AppDomain erstellt und die GetInterfaceTypes Methode ausgeführt wurde können wir den Plugin-Typ mit AppDomain.GetData() abholen.

Jetzt wo wir wissen welcher Typ unser Plugin implementiert, erstellen wir mit CreateInstanceFromAndUnwrap die Plugin-Instanz. Die Instanz speichern wir in die generische Eigenschaft die logischerweise Instance heißt.

	_Instance = this._appDom.CreateInstanceFromAndUnwrap(_AssemblyPath, pPluginType) as T;

Noch bevor die Instanz erstellt wird, haben wir von der AppDomain das UnhandledException Event angemeldet.

	_appDom.UnhandledException += new UnhandledExceptionEventHandler(AppDom_UnhandledException);

Diese tritt auf, wenn eine Ausnahme in der AppDomain nicht abgefangen wurde. Dieses Event ist dafür gedacht, dass man den Fehler mitloggen kann. Nach dem das Event gefeuert wurde, wird das Programm normalerweise beendet.

Da wir aber bei unserem Programm die Abwärtskompatibilität aktiviert haben, wird das Programm weiter ausgeführt. Wenn eine Exception in einer AppDomain bzw. in einem Plugin auftritt, werden wir dieses Plugin entfernen, in dem wir die AppDomain entladen in dem es sich befindet. Die Default AppDomain kann nicht entladen werden.

Wir werden in der Funktion AppDom_UnhandledException eine Key setzen damit wir im Pluginmanager wissen, welche AppDomain wir entladen müssen. (Wir machen also fast das gleiche wir hier, nur einfacher.)
Über die UnhandledExceptionEventArgs können wir auf das Exception Objekt zugreifen.  In dieses Tragen wir über

        System.AppDomain appDomain = sender as System.AppDomain;
	Exception exception = e.ExceptionObject as Exception;
	 
	exception.Data.Add("PluginDomain", this);

das Plugin ein, das die Exception ausgelöst hat. Der PluginManager hat ebenfalls von alle PluginDomains das UnhandledException Event registriert.

Er führt darin einige Prüfungsroutinen aus, um auch sicher  zu stellen dass die Exception auch von einem unserer Plugins geworfen wurde.

Anschließend versucht er sie zu entladen.

        if (appDomain.Equals(plugindomain.AppDomain) && 
            plugindomain.AppDomain.IsDefaultAppDomain().Equals(false))
	{
	    new Thread(delegate()
	    {
	        try
	        {
	            Console.WriteLine("Unloading the offending application domain...");
	 
	            AppDomain.Unload(appDomain);
	            appDomain = null;
	            plugindomain = null;
	        }
	        catch (System.Threading.ThreadAbortException abortexception)
	        {
	            //(AppDomain..::.Unload beendet Threads mit Thread..::.Abort
	            //http://msdn.microsoft.com/de-de/library/cyayh29d.aspx
	 
	            appDomain = null;
	            plugindomain = null;
	            System.Console.WriteLine(abortexception);
	        }
	        catch (CannotUnloadAppDomainException unloadexception)
	        {
	            System.Console.WriteLine(unloadexception);
	        }
	        catch (Exception ex)
	        {
	            Console.WriteLine(ex.ToString());
	        }
	        finally
	        {
	            OnPluginChangedEvent(new PluginManager.PluginChangedArgs(plugindomain,
	             ChangedAction.Remove));
	        }
	 
	        Console.WriteLine("Unloaded the offending application domain...");
	 
	}).Start();

Beim Entladen gilt folgendes zu beachten.

Wurde eine AppDomain entladen, sind alle darin enthaltenen Typen nicht mehr verwendbar. Ein Zugriff auf einen entladenen Typ würde eine AppDomainUnloadedException auslösen. Die entladene AppDomain gibt alle geladenen Assemblies wieder frei.

Ist in einer AppDomain ein oder noch mehrere Threads aktiv wird eine ThreadAbortException geworfen. Das bedeudet, dass beim „unloaden“ einer AppDomain eine ThreadAbortException auftreten kann. Mehr Informationen siehe dazu in der MSDN. Nachdem entladen der AppDomain macht sich der GC auf, um die Ressourcen von der AppDomain frei zu geben.

Am besten ihr schaut euch noch die Demo an. In der Demo ist ein Plugin vorhanden, das via Timer eine ArgumentNullException wirft. Die Domain wird anschließend entladen. Die aktivierte Abwärtskompatibilität verhindert, dass die Host-Anwendung abstürzt. Über eine Rückmeldung freue ich mich.

Source Code PluginManager


Page 3 of 3123

C# Anwendung Plugin fähig machen

By
on Regards: .NET Framework; C#;

In diesem Beispiel sieht man wie man ein einfaches Plugin-System realisiert. Demonstriert wird das ganze anhand eines „Mathematikprogramms“.
Das Mathematikprogramm lädt zu Beginn alle Plugins. Wenn der Benutzer z.B. die Wurzelfunktion aufruft mit „sqrt(3)“ durchsucht das Mathematikprogramm alle Plugins und schaut nach ob eines der Plugins die Funktion „sqrt“ berechnen kann. Der Pluginname verrät, für welche Mathematikfunktion das Plugin zu ständig ist. Wurde kein zuständiges Plugin gefunden, wird die Meldung „unbekannte Funktion“ ausgegeben.
Gibt der Benutzer als Eingabe z.B. „sqrt(4)“ ein, wird dem Plugin, das die Funktion „sqrt“ implementiert, „sqrt(4)“ übergeben. Somit weiß das Plugin was es überhaupt berechnen soll. Zurück gibt es das berechnete Ergebnis  der Eingabe.
Damit wir wissen wie die Plugins „aussehen“, also wie die Funktionen, Eigenschaften heißen, müssen wir ein Interface für die Plugins definieren. Ansonsten könnte es passieren (wenn verschiedene Entwickler die Plugins erstellen) dass die zu berechnende Funktion einmal „Berechne(String input)“ oder „Calculate(int input)“ heißt.
Wenn jeder das Interface des Plugins implementiert, kann es nicht zu solchen Problemen kommen. Unser Plugin-Interface sieht wie folgt aus.
            /// <summary>
	    /// Definiert das "Aussehen" unseres Plugins
	    /// </summary>
	    public interface IPlugin
	    {
	        /// <summary>
	        /// Name des Plugins
	        /// </summary>
	        String Name { get; set; }
	 
	        /// <summary>
	        /// Beschreibung des Plugins
	        /// </summary>
	        String Description { get; set; }
	 
	        /// <summary>
	        /// Berechnet die Eingabe
	        /// </summary>
	        /// <param name="pInput">Eingabe die ausgewertet werden soll.</param>
	        /// <returns>Gibt das berechnete Ergebnis zurück</returns>
	        String Calc(String pInput);
	    }

Das bedeutet, dass jeder, der unser Interface implementiert zwei Properties “Name” und “Description” definiert und zu guter Letzt eine Funktion “Calc”.

Im Namen speichern wir den Funktionsnamen der Mathematischen Funktion. Als z.B. „sqrt“. In der Funktion Calc berechnen wir den Übergabewert pInput und geben das Ergebnis als String zurück. Natürlich wäre eine andere Mathematische Funktion wie z.B. Modulointeressanter zu implementieren.Als nächstes gilt es die Mathematik Klasse MathCore zu erstellen, welche die Plugins lädt und erstellt.

Als erstes wird die Funktion LoadPlugins aufgerufen. Dieser übergeben wir den Dateipfad in dem sich die Plugins befinden.

Als nächstes gilt es die Mathematik Klasse MathCore zu erstellen, welche die Plugins lädt und erstellt.
Als erstes wird die Funktion LoadPlugins aufgerufen. Dieser übergeben wir den Dateipfad in dem sich die Plugins befinden.

        public void LoadPlugins(String pPluginPath)
	{
	            String[] files = Directory.GetFiles(pPluginPath);
	 
	            foreach (String file in files)
	            {
	                FileInfo fileInfo = new FileInfo(file);
	 
	                if (fileInfo.Extension.Equals(".dll"))
	                {
	                    Dictionary<string, object> dictionary = GetModul(file, typeof(IPlugin.IPlugin));
	                    foreach (var a in dictionary)
	                    {
	                        Plugins.Add(a.Key,a.Value);
	                    }
	 
	                }
	 
	            }
	}

Es werden alle Dateien aus dem Verzeichnis gelesen und Dateien mit der Dateiendung „.dll“ gefiltert. Ist eine Datei eine „.dll“, wird die Funktion GetModul(file, Type) aufgerufen. Diese lädt die Plugins in unsere Instanz hinein. Sehen wir uns dazu diese Funktion genauer an.

        private static Dictionary<string, object> GetModul(string pFileName, Type pTypeInterface)
	{
	            //Hier speichern wir unsere Plugins
	            Dictionary<string, object> interfaceinstances = new Dictionary<string, object>();
	 
	            //Loads an assembly given its file name or path.
	            Assembly assembly = Assembly.LoadFrom(pFileName);
	 
	            // http://msdn.microsoft.com/de-de/library/t0cs7xez.aspx
	            // Assembly Eigenschaften checken
	            foreach (Type type in assembly.GetTypes())
	            {
	                if (type.IsPublic) // Ruft einen Wert ab, der angibt, ob der Type als öffentlich deklariert ist. 
	                {
	                    if (!type.IsAbstract)  //nur Assemblys verwenden die nicht Abstrakt sind
	                    {
	                        // Sucht die Schnittstelle mit dem angegebenen Namen. 
	                        Type typeInterface = type.GetInterface(pTypeInterface.ToString(), true);
	 
	                        //Make sure the interface we want to use actually exists
	                        if (typeInterface != null)
	                        {
	                            try
	                            {
	 
	                                object activedInstance = Activator.CreateInstance(type);
	                                if (activedInstance != null)
	                                {
	                                    interfaceinstances.Add(type.Name, activedInstance);
	                                }
	                            }
	                            catch (Exception exception)
	                            {
	                                System.Diagnostics.Debug.WriteLine(exception);
	                            }
	                        }
	 
	                        typeInterface = null;
	                    }
	                }
	            }
	 
	            assembly = null;
	 
	            return interfaceinstances;
	}

Der Funktion wird der Pfad der Assembly übergeben, die nach Plugins durchsucht werden soll. Zusätzlich muss man den Typ des Plugins übergeben.

Wir laden die Assembly mit Assembly.LoadFrom() damit wir Informationen aus ihr lesen können (Stichwort Reflection). Mit der Funktion GetTypes() erhalten wir alle Typen (Klassen), die in der Assembly gespeichert sind. Als nächstes führen wir ein paar Routineprüfungen durch wie z.B. ob der Typ public ist und nicht abstrakt.

Danach „suchen“ oder besser gesagt holen wir mit der Methode GetInterface() das  Plugin-Interface falls der gerade iterierende Typ das Plugin implementiert hat. Falls kein Interface implementiert wurde ist der Rückgabewert NULL. Deshalb wird als nächstes überprüft ob der Rückgabewert ungleich NULL ist. Haben wir einen Rückgabewert erhalten, erstellen wir mit Activator.CreateInstance eine Instanz. Diese speichern wir dann in unser Dictionary.

So werden die Plugins Schritt für Schritt in unsere Anwendung geladen. Wurden alle Dateien auf Plugins überprüft, kann man mit der Funktion public string Calc(string pInput) Mathematikfunktionen aufrufen bzw. ausführen.

Ruft man _MathCore.Calc(“sqrt(3)”) auf, wird in der Funktion Calc der Input String interpretiert damit man weiß, welche Mathematikfunktion aufgerufen wird. In diesem Fall wäre das „sqrt“. Anschließend wird nach dem passenden Plugin mit der Funktion GetPlugin gesucht. Wurde es gefunden, wird der Input String an das Plugin weitergereicht und die Funktion Calc vom Plugin aufgerufen.

Wurde kein Plugin gefunden, wird “Funktion nicht gefunden”  zurückgegeben.

Wie gesagt handelt es sich hierbei um ein sehr einfaches Plugin-System. Das Beispiel verwendet die Plugins zwar nur in einer Konsolen Applikation, trotzdem sollte es kein Problem sein, das Ganze in WPF oder WinForms umzusetzen.

Bei einem ausgereiften Plugin-System gibt es Features wie z.B., dass die Plugins auf bestimmte Teile des Host System zugreifen können (z.b auf ein Control), dass Plugins wiederum Plugins enthalten können oder, dass die Plugins in einer Art Sandbox (Stichwort AppDomain ) gehostet werden damit kein schädlicher Code ausgeführt werden kann usw. usf.

Seit .NET 2< wurden eine Reihe neuer Techniken mitgeliefert die das Erstellen von Plugins vereinfachen soll.

Anbei ein paar Links:

http://www.mycsharp.de/wbb2/thread.php?threadid=34472
http://www.codeproject.com/KB/cs/pluginsincsharp.aspx

Beispiel Projekt herunterladen


Page 3 of 3123

ONLINE COMMUNITIES

By
on Regards: Article;

Heutige große Webplattformen wie z.B. Youtube, Twitter, Lima-City, kernel.org, wikipedia, aboutpixe.com  haben eines gemeinsam. Sie besitzen, oder sind eine Onlinecommunity. Ein Webmaster der eine große Plattform mit einer Onlinecommunity schaffen will, muss mehr als nur eine Seite ins Netz stellen, damit eine lebendige, gesunde, wachsende Onlinecommunity entsteht. In diesem Artikel erfährt man die wichtigsten Dinge über eine Onlinecommunity. Viel Spaß beim lesen.

Inhalt

1. Einführung
1.2 Was ist eine Onlinecommunity?
1.3 Entstehung und Charakteristik von Communities
2. Online kommunizieren
2.1 Faktoren, die Kommunikation erleichtern
2.2 Soziales Auftreten, Identität und Beziehungen
2.3 Rollen, Rituale, Normen und Community Politiken
2.4 Onlinecommunity Formen und Veränderungen
3 Online Communities entwickeln und evaluieren
3.1 Technologie-Übersicht von Onlinecommunitys
3.2 Soziabilität und Benutzerfreundlichkeit
3.2 Erfolgreiche Onlinecommunitys
4 Onlinecommunity Typen
5 Analyse und Forschung
5.1 Data Logging
6 Zusammenfassung
8 Literatur

1. Einführung

Das Internet hat seit seinem Bestehen unseren Alltag Leben maßgeblich beeinflusst. Durch die, in den letzten Jahren, entstandenen Plattformen namens „Social Networks“, wie Facebook oder Twitter hat das Internet noch mehr Einfluss auf unser Tun und Handeln. So ist es nicht verwunderlich, dass sich ein Teil des gesellschaftlichen Lebens mittlerweile im Internet abspielt.

„From discussion boards, to wikis, to social networking sites, people do things together through digital communication.” (Gleave, 2009, S. 1)

Es gibt’s nichts was man im Internet nicht kann. Einkaufen, Spiele spielen, nach Informationen suchen oder fragen, mit anderen Menschen über Themen diskutieren, all das ist in der „Virtuellen Welt“ kein Problem. Durch die zahlreichen Internetbenutzer haben sich virtuelle Gemeinschaften gebildet. Diese virtuellen Gemeinschaften werden auch Onlinecommunitys genannt. Was eine Onlinecommunity ausmacht und welche Arten es gibt, wird in den nächsten Kapiteln erörtert.

1.2 Was ist eine Onlinecommunity?

Zunächst möchte ich in den Begriff Offlinecommunity einführen und definieren. Eine Offlinecommunity ist eine Gemeinschaft, wie wir sie aus dem realen Leben kennen. Das kann zum Beispiel eine Familiengemeinschaft oder eine Vereinsgemeinschaft sein.

Ausgehend von der akademischen Ausbildung und der Ansichtsweise werden die Kriterien zur Definition einer Onlinecommunity anders gewichtet (vgl. Preece, 2003, S.597).

Deshalb gibt es keine allgemeine anerkannte Definition zu Onlinecommunitys. Jedoch haben sich einige Kernmerkmale, die jede Onlinecommunity besitzt herauskristallisiert (Whittaker, Issacs, & O’Day zit. nach Preece, 2003, S. 597):

  • Members have a shared goal, interest, need, or activity that provides the primary reason for belonging to the community.
  • Members engage in repeated, active participation and there are often intense interactions, strong emotional ties, and shared activities occurring between participants.
  • Members have access to shared resources, and there are policies for determining access to those resources.
  • Reciprocity of information, support, and services between members is important.
  • There is a shared context of social conventions, language, and protocols.

Diese Kernmerkmale sind sehr allgemein gehalten und treffen auch auf Offlinecommunitys zu. Da die Kommunikation bei Onlinecommunitys eine große Rolle spielt, zeigen sich rasch die Unterschiede zwischen Online- und Offlinecommunitys.

“An online community is a group of people who interact in a virtual environment. They have a purpose, are supported by technology, and are guided by norms and policies.” (Preece, 2000)

Die Benutzer einer Onlinecommunity haben den Nachteil, dass sie ein bestimmtes technisches Equipment benötigen, um an Onlinecommunitys teil nehmen zu können. Andererseits erhalten sie dadurch den Vorteil, dass sie nicht ortsgebunden sind. So können auch über große Distanzen enge Kontakte gepflegt werden. Dies ist ein wesentlicher Unterschied zu den Offlinecommunitys, die eine bestimmte Nähe voraussetzen, damit Kommunikation statt finden kann.

“Things such as birth and physical location determined belonging to a community.” (Preece, 2003, S. 597)

Die Teilnehmer können dabei genauso starke Gefühle entwickeln wie bei einer Offlinecommunity. Dabei spielt der Kommunikationskanal bei Onlinecommunitys eine wesentliche Rolle.

1.3 Entstehung und Charakteristik von Communities

Früher wurden Onlinecommunitys vorwiegend in Ausbildungs- und Büroplätzen eingesetzt. Alle Benutzer hatten in etwa die gleichen Voraussetzungen. Nachdem aber die Anzahl der Computer-und Internetbenutzer explodiert ist hat sich die Demografie stark verändert. Dadurch haben die Benutzer ein vielseitiges Profil erhalten die unter anderem folgendes beinhaltet:

  • Unterschiedliche Kulturen
  • Altersunterschiede
  • Soziale Hintergründe
  • unterschiedliches technisches „Know How“

(vgl. Preece, 2003, S. 599)
Nicht nur die Benutzergruppe hat sich verändert. Durch die ständig neu veröffentlichten Technologien, verändern sich die Onlinecommunitys ständig mit.
Wie bereits im Kapitel 1 Einführung erwähnt wurde, gibt es nichts was man im Internet nicht tun könnte. Oder anders gesagt, im Internet kann man fast alle Dinge wie im realen Leben tun. Menschen im Internet machen das Gleiche wie Leute, die sich in Gesellschaft befinden. Sie unterhalten sich, nur geschieht dies im Internet ausschließlich über Worte, mit der Tatsache verbunden, dass sie unabhängig sind von Zeit und Anwesenheit an einem bestimmten Raum oder Ort.

So schreibt auch Rheingold, „Online people do almost everything that people do when they get together, but they do it with words on screens, leaving their bodies behind independent of local time or location (Rheingold zit. nach Preece, 2003, S. 599).

Wissenschaftler versuchen heraus zu finden, wie das Internet unser Alltagsleben beeinflusst. Dabei ist die Kommunikationsweise und der Linguistische Part sehr interessant.

2. Online kommunizieren

Es gibt verschiedene Möglichkeiten zu kommunizieren, dabei hat jede Kommunikationsart hat ihre Vor- und Nachteile.

Wenn man zum Beispiel in einer Onlinecommunity mittels Text kommuniziert, repräsentieren sich die Teilnehmer nur über ihre Wörter. Dabei spielen Semantik und Syntax der Nachricht eine Rolle für den Inhalt. Diese Art der Kommunikationen hat den Nachteil, dass Zusatzinformationen wie z.B. Körpersprache, Gesichtsausdruck und Stimmlage verloren gehen. (vgl. Preece, 2003, S. 599)

Wenn man hingegen mit Videokonferenzschaltung kommuniziert, gehen keine nonverbalen Informationen verloren, denn durch das Bild ist der Tonfall, Gestik und Mimik sichtbar. Videokonferenzen haben den Nachteil, dass die Teilnehmeranzahl beschränkt ist. Wenn man z.B. mit 100 Personen gleichzeitig eine Videoschaltung hält, dann passen unmöglich alle Teilnehmer auf einen Bildschirm.

For example, video-conferencing conveys some nonverbal communication; but, because of limitations of communications bandwidth, screen size and resolution, subtle body language, and important contextual information about participants’ moods, the context in which they are participating and their environment is lost (Olson & Olson zit. nach Preece, 2003, S. 600)

Olson schreibt, dass aufgrund der beschränkten Breitbandverbindung die nonverbalen Informationen entfallen. Heutzutage hat aber der Großteil der Internetbenutzer, die auch über die notwendige Hardware für eine Videokommunikation verfügen, einen Breitbandanschluss. Das darauf folgende Zitat zeigt, dass die Aussage von Olson nicht mehr ganz zeitgemäß ist.

„In der EU verfügen bereits im Frühjahr 2008 80 Prozent der Haushalte mit Internetanschluss über einen Breitbandzugang.“ (Breitband-Internetzugang, 11.02.2010, http://de.wikipedia.org/wiki/Breitband-Internetzugang ).

Oft ist eine Videokonferenz nicht erforderlich oder die Situation erlaubt eine Video-Schaltung nicht. Wenn der Inhalt einer Nachricht falsch interpretiert wird, kann es trotz Videokonferenzschaltung  zu Problemen kommen. Es muss bekannt sein welche Person in welcher Funktion spricht und wie sie aussieht,  damit die Nachricht möglichst richtig verstanden wird.

Trotz einer Videokonferenzschaltung kann es zu Kommunikationsproblemen kommen, wenn der Inhalt der Nachricht falsch interpretiert wird.

Bei einem Gespräch müssen die Gesprächsteilnehmer über die gleichen Grundvoraussetzungen verfügen. Zum Beispiel, wenn Person A über seine Tochter zu Person B spricht, muss Person B wissen, dass Person A das spielende Kind im Zimmer nebenan meint und nicht die Kinder drei Blocks weiter. (vgl. Preece, 2003, S. 600)

Die Sprecher erkennen auch, anhand der Aufmerksamkeit des Teilnehmers, ob dieser dem Inhalt folgen kann (vgl. Preece, 2003, S. 600).

2.1 Faktoren, die Kommunikation erleichtern

Damit die Gesprächsteilnehmer die gleichen Grundvoraussetzungen mit bringen gilt es folgende Punkte zu beachten kann (Preece, 2003, S. 600):

  • sharing the same physical space, i.e., co-presence
  • being able’to see each other, i.e., visibility
  • being able to hear each other and detect voice tone, i.e., audibility
  • both partners experiencing the conversation at roughly the same time, i.e., co-temporality
  • sending and receiving more or less simultaneously, i.e., simultaneity
  • keeping turns in order, i.e., sequentiality
  • being able to review messages, i.e., reviewability o being able to revise messages; i.e., revisability

Für die Auswahl des Kommunikationstypus ist der Grund der Kommunikation ausschlaggebend. Der Grund der Kommunikation ist ausschlaggebend, welcher Kommunikationstyp gewählt wird. Werden zum Beispiel Heikle Themen (wie persönliche Probleme) angesprochen, wählt man eine eher unpersönlichere Kommunikationsmethode, wie das darauffolgende Zitat zeigt.

“Text-only environments can be preferable when the content of the conversation is potentially embarrassing, as in a discussion about a rape incident.” (Newell & Gregor zit. nach Preece, 2003, S. 600).

Weiters unterscheidet man bei der Kommunikationsart zwischen synchroner und asynchroner Kommunikation.

„Synchrone Kommunikation beinhaltet all jene Kommunikationsformen, bei denen die Aktionspartner zur selben Zeit teilnehmen, wie dies zum Beispiel bei Text-, Video- oder Audiochats der Fall ist.“ (Marchtrenker,2008, S. 17)

„Der Begriff asynchrone Kommunikation bezeichnet die zeitlich versetzt stattfindende Kommunikation.“ (Marchtrenker,2008, S. 14)

Eine asynchrone Kommunikation ist von Vorteil, wenn die Onlinecommunity Teilnehmer gehandicapt sind, weil sie z.B. nicht schnell schreiben können., sie lässt ihnen Zeit sich eine passende Antwort zu überlegen und zu tippen. In einer Alkohol Selbsthilfe Onlinecommunity wollen z.B. die Benutzer zu jeder Zeit Nachrichten schreiben können (vgl. Preece, 2003, S. 600).
Damit wäre die asynchrone Kommunikation zweckmäßiger, als die synchronische.

Bei einem Chat der synchron abläuft, stehen die Chattenden unter einem zeitlichen druck, da der Gegenüber auf eine Antwort wartet. Somit bleibt dem antwortendem nicht immer genug Zeit über seine Antwort nach zu denken.

2.2 Soziales Auftreten, Identität und Beziehungen

Wenn sich zwei Personen zum ersten Mal treffen, spielt der erste Eindruck eine wichtige Rolle. Mit den uns zu Verfügung stehenden Informationen die unser der Gegenüber mit dem Aussehen, Geruch, seinem agieren usw. vermittelt, hinterlässt dieser bei uns einen Eindruck.

Das soziale Auftreten im Internet unterscheidet sich zum realen Auftreten dahin gehend, dass bestimmte Informationen, Geruch des Gegenübers, Aussehen usw. beim Aufeinandertreffen fehlen.
“So, another feature of reduced social presence, particularly in low bandwidth environments, is that the way people form impressions of each other is different, which can have both positive and negative effects, depending on the situation.” (Preece, 2003, S. 601)

Die fehlenden Informationen können also einen falschen Eindruck vom Onlinecommunity Teilnehmer hinterlassen. Die Benutzer haben ein falsches Bild von ihrem „Gegebenüber“.

Die fehlenden nonverbalen Informationen können auch schnell, zu Missverständnissen führen, wenn die Beiträge schlecht erklärt oder nichts mit dem Kontext zu tun haben (vgl. Preece, 2003, S. 601).

Gerade Anfänger die noch nicht ganz mit der Technik vertraut sind und noch nicht richtig mit dem Medium Internet umgehen können, sind gefährdet Nachrichten falsch auf zu fassen (vgl. Preece, 2003, S. 601).

Falsch verstandene Beiträge können rasch, unerwartete beleidigte Attacken hervorrufen. Diese werden im Internet-Jargon als „Flamewar“ bezeichnet.

Es gibt auch Situationen in denen es von Vorteil ist, wenn man über den Kommunikationspartner nicht alles weiß. Es ist dann einfacher über heikle Themen zu sprechen. Mit der Zeit lernen sich die Benutzer Stück für Stück immer näher kennen. Dies geschieht nach dem Schneeballprinzip.

“[…] If you tell me something about yourself, I’ll tell you something about me.” (Preece, 2003, S. 601).

Damit es zu keinen schlimmeren Missverständnissen und zu einem kargen Tonfall kommen kann, wird in Onlinecommunitys darauf geachtet, dass die Beiträge in einem „sanften Tonfall“ geschrieben werden.
Mittels Emoticons alias „smilies“ kann man dem Beitrag abschwächen bzw. mehr Ausdruckskraft verleihen.

„Durch den Einsatz der zuvor genannten Zeichen Kombinationen versuchen die User der elektronischen Medien die fehlenden nonverbale Kommunikation zu ersetzen.“ (Wascher, 2007,S. 9)

2.3 Rollen, Rituale, Normen und Community Politiken

Wie im vorherigen Kapitel erwähnt wurde, wird in Onlinecommunitys darauf geachtet, einen milden Ton an zu schlagen.
Die Benutzer schreiben dann einfachheitshalber „IMHO“ was so viel bedeutet wie „In my humble opinion“.

Dies ist eine der vielen Internet Abkürzungen die in Onlinecommunitys verwendet werden. „Da die Kommunikation mittels quartärer Medien meist sehr schnell funktioniert, verwenden viele User dieser neuen Kommunikation Akronyme, um schneller schreiben, also kommunizieren zu können.“ (Wascher, 2007,S. 8)

Eine Liste von Abkürzungen (Netzjargon) gibt es in der Wikipedia. (11.02.2010 http://de.wikipedia.org/wiki/Liste_von_Abk%C3%BCrzungen_(Netzjargon) )

Wie bei Vereinen werden in Onlinecommunitys Betreuer benötigt. Die Rollen der Vereinsmitglieder können in den meisten Fällen direkt in die Onlinecommunity importiert werden. Falls eine neue Onlinecommunity ohne realen Bezug entwickelt wird sind Normen und Regeln erforderlich, die festlegen was erlaubt ist und was nicht. Auch muss entschieden werden ob Entscheidungen demokratisch gefällt werden oder nicht. Wichtig ist auch wie man, die Regeln durchsetzen will. (vgl. Preece, 2003, S. 603)

In den meisten Fällen kommt ein Moderator zum Einsatz der die Onlinecommunity betreut. Er hat unter anderem die folgenden Aufgaben.” (Berge, 1992; Collins & Berge, 1997; Salmon, 2000 zit. nach Preece, 2003, S. 603)

  • Facilitating so that the group is kept focused and on topic.
  • Managing the list, e.g., archiving, deleting, and adding subscribers.
  • Filtering messages and deciding which ones to post; typically, this involves removing flames, libelous posts, spam, inappropriate or distracting jokes, and generally keeping the ratio of relevant messages high, which is often described as the signal/ noise ratio.
  • Being the expert, which involves answering frequently asked questions (PAQs) or directing people to online FAQs and understanding the topics of discussion.
  • Editing text, digests, or formatting messages.
  • Promoter of questions that generate discussion.
  • Marketing the list to others so that they join, which generally involves providing information about it.
  • Helping people with general needs.
  • Being a fireman by ensuring that flaming and ad hominem attacks are done offline.

2.4 Onlinecommunity Formen und Veränderungen

Kritische Masse:

Damit eine Onlinecommunity sich am Leben erhält, benötigt diese genug Teilnehmer, die an Diskussionen teilnehmen und neue erstellen. Gibt es zu wenig Benutzer und somit weniger Beiträge sinkt das Interesse der Benutzer an der Onlinecommunity. Es wird immer weniger Beiträge geben, bis es schlussendlich keine aktiven Benutzer mehr in der Onlinecommunity gibt. (vgl. Preece, 2003, S. 602)

Will man eine Onlinecommunity aufbauen und hat noch nicht die kritische Masse erreicht, so kann man mithilfe von gefälschten Benutzern, die dem Administrator der Onlinecommunity gehören, eine aktive Onlinecommunity vorgaukeln. Der Administrator schreibt mit den gefälschten Benutzern Beiträge, damit außenstehende glauben, dass es sich um eine lebendige Onlinecommunity handelt.
(vgl. Was versteht man unter…? Kritische Masse, 20.02.2010, http://www.community-management.de/2008/06/was-versteht-man-unter%E2%80%A6-kritische-masse/ ).

Wechselwirkung und soziales Dilemma:

In einer „gesunden“ Onlinecommunity findet ein Informationsaustausch zwischen den Benutzern statt. Dabei ist es wichtig, dass alle Benutzer an diesem Informationsaustausch teilnehmen. Wenn zum Beispiel Benutzer A einem anderen Benutzer in einer sachlichen Fragestellung weiterhilft, erwartet dieser, dass ihm später auch Ratschläge gegeben werden, falls dieser danach fragt. Ist dieser Fall gegeben spricht man von einer Wechselwirkung. Problematisch ist, es wenn diese Wechselwirkung unter den Benutzern nicht stattfindet. Die aktiven Benutzer werden die Onlinecommunity verlassen und es wird die kritische Masse erreicht.

So heißt es auch, “whatever is given ought to be repaid, if only to ensure that more is available when needed. Repayment of support and social resources might be in the form of exchanges of the same kind of aid, reciprocating in another way or helping a mutual friend in the network.” (Wellman & Gulia zit. nach Preece, 2003, S. 603)

Es handelt sich um ein soziales Dilemma, wenn das Verhalten eines Benutzers einer Onlinecommunity schadet. (vgl. Preece, 2003, S. 603)

Das soziale Dilemma kann derart gravierende Auswirkungen auf die Onlinecommunity haben, dass die Anzahl an aktiven Benutzern zurück geht.

Wenn z.B. immer mehr Benutzer Beiträge nur noch lesen, anstatt sich an der Diskussion aktiv zu beteiligen wird es immer weniger interessante Beiträge geben. Die Folge ist eine sterbende Onlinecommunity.

Benutzer die in einer Onlinecommunity registriert sind aber nur mit lesen werden auch „lurker“ genannt. Es gibt in jeder Onlinecommunity einen hohen Anteil an Beobachter. Dies kann unterschiedliche Gründe haben. Entweder sie wissen nicht wo sie starten sollen, sie sind schüchtern, oder sie finden keine interessanten Themen. (vgl. Inside the mind of an online community lurker, 27.02.2010, http://www.communityspark.com/inside-the-mind-of-an-online-community-lurker/ )

Es kann aber noch ganz andere Gründe geben, warum diese nicht aktiv in der Community werden.

3 Online Communities entwickeln und evaluieren

Eine Onlinecommunity zu entwickeln erfordert eine strukturierte Planung.

Zuerst muss festgelegt werden welche Aufgaben die Benutzer in der Onlinecommunity haben und welches Ziel hinter der Kommunikation verfolgt wird. Der nächste Schritt ist, das Entwickeln eines Konzept-Models der Onlinecommunity. Danach kann die passende Software erstellt, oder eine vorhandene eingesetzt werden. Beim vorletzten Schritt geht es um den letzten Fein-schliff der Onlinecommunity. Unter anderem soll die Benutzerfreundlichkeit geprüft und überarbeitet werden. Zum Schluss gilt es die Onlinecommunity zu veröffentlichen und den Benutzern schmackhaft zu machen. (vgl. Preece, 2003, S. 605)
Das kann man in dem man bereits zum Start den Inhalt für die BesucherInnen hinterlegt. (vgl. Marchtrenker,2008, S. 21)

„Um eine Attraktivität für neue potentielle MitgliederInnen zu erzeugen, sollte eine kritische Masse von TeilnehmerInnen von Beginn an vorhanden sein, denn leere Chats und Foren ohne Themen […] würden eher abweisend wirken.“ (Kim zit. nach Marchtrenker,2008, S. 21)

Damit die Benutzer der Onlinecommunity sich schnell zu recht finden, ist es wichtig, dass die richtigen Technologien und Systeme eingesetzt werden. „[…]Es ist ratsam, nicht zu viele Systeme zu kombinieren, um einerseits die BenutzerInnen nicht zu überfordern und andererseits besonders am Anfang die Community in einem System zu bündeln und aufzubauen.“ (Marchtrenker,2008, S. 18)

Trotzdem sollten synchrone und asynchrone Technologien miteinander verknüpft werden.
“Instant messages are used to signal that a document has been posted for review and so on. These combinations of technologies and the Web site on which they reside provide a richer basis for community than any single technology could on its own; they are the community.” (Preece, 2003, S. 605)
Im Gegensatz zu herkömmlicher Software müssen, Onlinecommunity-Softwares laufend mit der Community mit entwickelt werden.
„So muss Wachstum und Veränderung der Gemeinschaft noch vor der Eröffnung einer Commmunity-Plattform einkalkuliert werden und die technischen Systeme mit Weitblick ausgewählt werden. Oft wird der Fehler gemacht, dass Systeme zu detailliert geplant werden und damit jegliche Entwicklungschancen verloren gehen, obwohl genau solche Entwicklungen für das Wachsen von Gemeinschaften unabdingbar sind.“ (Marchtrenker,2008, S. 25)

3.1 Technologie-Übersicht von Onlinecommunitys

In diesem Kapitel werden die wichtigsten und verbreitetesten Technologien aufgezählt, die in Onlinecommunitys Verwendung finden.

Mit einer Mailinglist findet die asynchrone Kommunikation über E-Mail statt. Alle Beteiligten müssen sich dazu registrieren. (vgl. Preece, 2003, S. 605) Für den Zugang ist ein E-mail-Client notwendig, sofern der Anbieter der Mailinglist keine Weboberfläche zu Verfügung stellt.

Ein Nachteil dieser Technologie ist das anmelden an einer Mailinglist, da dieses Verfahren sich von Betreiber zu Betreiber unterscheidet. Außerdem können viele Beiträge schnell unübersichtlich werden. (vgl. Mailingliste, 20.02.2010, http://de.wikipedia.org/wiki/Mailingliste ).

„Newsgroups sind schriftliche Foren, die ein bestimmtes Thema behandeln. Zum Unterschied zu Mailinglisten werden die Nachrichten aber nicht automatisch an alle TeilnehmerInnen gesandt, sondern stehen auf einem Server zum Abruf bereit.“ (Döring, 2003 zit. nach Marchtrenker,2008, S. 15)

In Diskussionsforen werden Beiträge asynchron verfasst. Dabei werden die Themen klar strukturiert geordnet. Größere Forensysteme werden in Unterforen unterteilt, in denen jeweils bestimmte Themen abgehandelt werden. (vgl. Marchtrenker,2008, S. 14 f.)

Alte geschriebene Beiträge werden archiviert und können anderen Benutzern als Informationsquelle dienen. Um einen geregelten Ablauf in den Foren zu gewährleisten kommt meist ein Moderator zum Einsatz. (vgl. Marchtrenker,2008, S.15)

Viele Foren können durch kleine Features von den Administratoren erweiter werden. So gibt es zum Beispiel ein Feature das dem Teilnehmer eine E-mail sendet, wenn jemand auf seinen Beitrag geantwortet hat. Für Internetneulinge ist es anfangs schwer sich zu recht zu finden. (vgl. Preece, 2003, S. 606).

WikiWebs erfreuen sich in den letzten Jahren immer größere Beliebtheit. Die asynchrone Kommunikationsform wird in den Bereichen Bildung und Nachschlagewerke eingesetzt. (vgl. Marchtrenker,2008, S.15)

„Ein Wiki […] ist ein Hypertext-System für Webseiten, dessen Inhalte von den Benutzern nicht nur gelesen, sondern auch online direkt im Browser geändert werden können.“ (Wiki, 20.02.2010, http://de.wikipedia.org/wiki/Wiki ).

Den Betreibern des Wikis bleibt es selbst überlassen, ob die Benutzer den Inhalt ohne Registrierung verändern dürfen.

Bei synchron ortsunabhängigen verschickten Textmitteilungen handelt es sich um Text-basierte Chats. Dabei können an der Konversation ein oder mehrere Benutzer teilnehmen. Die Nachrichten können schnell ausgetauscht und die Unterhaltung geht schnell voran. “(vgl. Preece, 2003, S. 606 f.) Der Einstieg in den Chat, kann unter Umständen durch die diversen Abkürzungen die Benutzer verwenden erschwert werden (mehr dazu siehe 2.3 Rollen, Rituale, Normen und Community Politiken).

„Besonders bei vielen gleichzeitigen TeilnehmerInnen ist es wichtig, schlagfertig zu sein und sich aktiv am Chat zu beteiligen, um dem schnellen Wechsel der Nachrichten folgen zu können.“ (Marchtrenker,2008, S.17) Je nach Betreiber ist eine Registrierung notwendig. Für mache Chats ist es notwendig zusätzlich Software zu installieren.

Neben den Text-basierten-Chats gibt es auch Audiochats. „Anders als bei Textchats erfolgt hierbei der Informationsaustausch visuell bzw. über den Audiokanal.“ (Marchtrenker,2008, S.17) .Das hat den Vorteil, dass keine Schreibarbeit geleistet werden muss. Der Benutzer kann während des Audiochats also auch anderen Tätigkeiten nachgehen. Für den Audiochat ist eine zusätzliche Installation von Hard- und Sofware nötig.

Eine besondere Form von Onlinecommunitys stellen Online-3D-Infratkuren dar. Die Teilnehmer halten sich in einer grafischen, virtuellen Welt auf, um dort untereinander zu kommunizieren. Die Kommunikation findet synchron und mittels Audio- oder Text-basierten Chat statt.

Die Benutzer selber können sich Visuell anderen Teilnehmern präsentieren, was die Kommunikation unterstützt. Online-3D-Infrasktruturen setzen in Punkto Software und Hardware hohe Maßstäbe an die Benutzer. Auch dauert die Eingewöhnung erwartungsgemäß länger wie in anderen Systemen. “(vgl. Preece, 2003, S. 607)

3.2 Soziabilität und Benutzerfreundlichkeit

Unter Soziabilität versteht man, dass Individuen schnell neue soziale Beziehungen knüpfen können. (vgl. Soziabilität, 20.02.2010, http://de.wikipedia.org/wiki/Soziabilit%C3%A4t ).

Etwas anders ausgedrückt kann man dies auch wie folgt definieren. „Sociability is concerned with planning and developing social policies and supporting social interaction. “(Preece, 2003, S. 605)

Bei Soziabilität in einer Onlinecommunity spielen die Ziele, Teilnehmer und die Richtlinien der Onlinecommunity eine wichtige Rolle.
So sollte aus dem Namen der Onlinecommunity das Ziel hervorgehen. Interessierte finden so die Community schneller. Je nach dem Ziel der Onlinecommunity unterscheiden sich deren Teilnehmer. Z.B. erfüllen Onlinecommunitys für Kinder andere Kriterien wie für Erwachsene. (vgl. Preece, 2003, S. 607)

Onlinecommunitys für Kinder haben zum Beispiel ein grafisch verspieltes auftreten und beschäftigen sich mit anderen Inhalten, als eine für Erwachsene.
Die Richtlinien müssen stark genug sein um die Onlinecommunity zu leiten, gleichzeitig muss diese aber flexibel genug sein, dass sich die Onlinecommunity weiterentwickeln kann. (vgl. Preece, 2003, S. 607)

Die Soziabilität kann mit Hilfe der Usability verbessert werden.

Usability zu Deutsch Benutzerfreundlichkeit nimmt eine immer wichtigere Rolle in Onlinecommunitys ein. „Auch das immer größere Angebot im Netz verleiht den BersucherInnen die Macht, zwischen verschiedenen Webseiten auswählen zu können, wobei neben Qualität und Quantität der bereitgestellten Inhalte vor allem auch die Usability als wesentliche Kriterien herangezogen werden.“ (Marchtrenker,2008, S. 44)
Eine einfache Benutzerfreundlichkeit zeichnet sich dadurch aus, dass sie intuitiv ist und nach kürzester Zeit erlernbar. Wieder Erkennbarkeitsmerkmale bei Navigation und Dialogen sind dabei wichtig. Die Informationen müssen für den Benutzer schnell und klar ersichtlich sein. Der Benutzer steuert die Software und nicht umgekehrt. Der Zugang zur Onlinecommunity kann für die Benutzer erschwert werden, wenn zusätzlich Software installiert werden muss. (vgl. Preece, 2003, S. 607 f.)
Durch Umfragen in der Onlinecommunity kann festgestellt werden ob die Benutzer eine Verbesserung der Bedienbarkeit wünschen.

3.2 Erfolgreiche Onlinecommunitys

Erfolgreiche Onlinecommunitys sind leicht zu erkennen. Sie haben viele aktive Benutzer mit vielen interessanten Beiträgen. Die Benutzer sind schon länger bei der Onlinecommunity angemeldet und gehen mit einander respektvoll um.

“[…]the number and type of incidents that produce uncivil behavior (low in successful communities); average duration of membership (high); the percentage of people who are still members after a certain period of time (high); etc” (Preece zit. Preece, 2003, S. 608)

Im nächsten Absatz werden wichtige Dinge beschrieben, die einen Benutzer veranlassen sich bei einer Onlinecommunity aktiv zu beteiligen.
Der Titel der Onlinecommunity muss klar ersichtlich sein, damit der Benutzer das Ziel der Community schnell erkennt. Die Registrierung und das Abmelden darf nicht kompliziert sein. Außerdem sollten die Richtlinien den Benutzer nicht zu sehr einschränken, damit dieser sich in der Community entfalten kann. (vgl. Preece, 2003, S. 609)

Dem Benutzer sollte ein einfacher Zugang zu den Ressourcen der Onlinecommunity gewährt werden.
„Um die TeilnehmerInnen verstärkt an die Community zu binden, sollten regelmäßige Veranstaltungen organisiert werden. Sofern möglich, und dies kommt vor allem bei kleineren Gemeinschaften vor, auch reale Treffen.“ (Marchtrenker,2008, S. 24)

4 Onlinecommunity Typen

Angefangen von den verschiedensten Hobbys bis zu jeder Gruppierung oder Vereinigung hat einfach alles eine Onlinecommunity. Dadurch, dass das Internet nur begrenzt kontrollierbar ist, haben sich auch Gruppen mit illegalem bzw. verfassungswidrigem Inhalt verbreitet. (vgl. Preece, 2003, S. 609)

Ein weiter Bereich sind Patienten Onlinecommunitys. Dort werden Selbsthilfegruppen gebildet, oder Teilnehmer mit den gleichen Leiden tauschen ihre Erfahrungen aus. (vgl. Preece, 2003, S. 610)

Ein weiterer Vorteil kann die Text-basierte Kommunikation sein, da diese nicht so persönlich ist. (siehe 2.1 Faktoren die Kommunikation erleichtern)
Auch im Bildungssektor werden Onlinecommunitys eingesetzt. Die Studenten organisieren und  helfen sich gegenseitig. „Online communities […] have a role in bringing social interaction to learning and supporting the learning process.” (Preece, 2003, S. 611)

Auch die Industrie hat Onlinecommunitys entdeckt und investiert derzeit in diesen Markt. Die Benutzer können zu Produkten der Hersteller ihr Feedback abgeben. So kann die Industrie schneller auf Kundenwünsche reagieren. Die Kunden fühlen sich auf deren Plattformen ernst genommen und sind deshalb treuere Kunden als andere. Die Firmen errichten auch Onlinecommunitys auf denen sich die Kunden untereinander zu den Produkten helfen können. (vgl. Erfolgreiche Online Communities I, 26.02.2010, http://www.contentmanager.de/magazin/artikel_1766-657_online_communities.html  ).
Erwähnt sollte noch werden, dass diese Plattformen stärker von Zensur betroffen sind um ein positives Image nach außen zu gewährleisten.

6 Zusammenfassung

In einer Onlinecommunity können sich Menschen über das Internet unterhalten. Dabei spielt die Kommunikationsart eine wichtige Rolle, denn jede hat ihre Vor- und Nachteile. So kann zum Beispiel bei einer Audiokommunikation der Teilnehmer ungestört weitere Eingabemittel bedienen. Allerdings ist für diese eine weitere Hardware erforderlich.
Bei der Text basierten Kommunikation wurden bestimmte Normen bzw. Akronymen von Internetbenutzern eingeführt, um eine schnellere Kommunikation zu gewährleisten. Neben diesem Ritual haben sich auch noch verschiedene Netzpolitiken durchgesetzt, die ein Zusammenleben in der Onlinecommunity unterstützten sollen. Diese Richtlinien können z.B. die verwendete Sprache, innerhalb der Onlinecommunity, fest legen.
Bei der Entwicklung einer Onlinecommunity ist es wichtig, dass auf die Bedürfnisse der Benutzer eingegangen wird, um den Mitgliedern eine möglichst passende Umgebung zu Verfügung zu stellen. Werden falsche Kommunikationsarten in die Plattform integriert hat dies Auswirkungen auf die Soziabilität und somit auf die Anzahl der aktiven Benutzer innerhalb der Onlinecommunity. Auch muss die Plattform ständig mit der Onlinecommunity mitentwickelt werden.
Viele Firmen haben das große Potential von Onlinecommunitys erkannt und investieren in Onlinecommunitys. Die Firmen erhalten unmittelbar Rückmeldung vom Kunden und können auch so den Markt besser analysieren.

8 Literatur

Berge, Z. L., & Collins, M.P. (1995) Computer-mediated communication and the online classroom: Overview and perspectives. Zitiert nach Preece, J., Maloney-Krichmar, D., (2003) “Online Communities: focusing on sociability and usability”, in Jacko, J. A., Sears, A. The Human-Computer Interaction Handbook. Mahwah, New Jersey, London: Lawrence Erlbaum, S.597-616

Breitband-Internetzugang, 11.02.2010, http://de.wikipedia.org/wiki/Breitband-Internetzugang

Döring Nicola. (2003) Sozialpsychologie des Internets. Die Bedeutung des Internets für Kommunikationsprozesse, Identitäten, soziale Beziehungen und Gruppen. Zitiert nach Marchtrenker, F., (2008) Virtual Communities – Technische und gesellschaftliche Aspekte am Beispiel eines Online-Spielemagazins. Dipl.-Arb., Institut für Gestaltungs- und Wirkungsforschung der Technischen Universität Wien

Eine Liste von Abkürzungen (Netzjargon). 11.02.2010, http://de.wikipedia.org/wiki/Liste_von_Abk%C3%BCrzungen_(Netzjargon)

Erfolgreiche Online Communities I, 26.02.2010, http://www.contentmanager.de/magazin/artikel_1766-657_online_communities.html

Gleave, E., Welser, H., Lento, T., Smith, M, (2009) A Conceptual and Operational Definition of “Scial Role” in Online Community. In Proceedings of the 42nd Hawaii International Conference on System Sciences – 2009 (conference proceedings)

Inside the mind of an online community lurker, 27.02.2010, http://www.communityspark.com/inside-the-mind-of-an-online-community-lurker/

Kim Amy Jo. Community Building on the Web. zitiert nach Marchtrenker, F., (2008) Virtual Communities – Technische und gesellschaftliche Aspekte am Beispiel eines Online-Spielemagazins. Dipl.-Arb., Institut für Gestaltungs- und Wirkungsforschung der Technischen Universität Wien

Mailingliste, 20.02.2010, http://de.wikipedia.org/wiki/Mailingliste

Marchtrenker, F., (2008) Virtual Communities – Technische und gesellschaftliche Aspekte am Beispiel eines Online-Spielemagazins. Dipl.-Arb., Institut für Gestaltungs- und Wirkungsforschung der Technischen Universität Wien

Newell, A. F., & Gregor, P. (1997) Human computer interaction for people with disabilities. Zitiert nach Preece, J., Maloney-Krichmar, D., (2003) “Online Communities: focusing on sociability and usability”, in Jacko, J. A., Sears, A. The Human-Computer Interaction Handbook. Mahwah, New Jersey, London: Lawrence Erlbaum, S.597-616

Olson, G. M. & Olson, J.S. (1997). Research on computer supported cooperative work. Zitiert nach Preece, J., Maloney-Krichmar, D., (2003) “Online Communities: focusing on sociability and usability”, in Jacko, J. A., Sears, A. The

Human-Computer Interaction Handbook. Mahwah, New Jersey, London: Lawrence Erlbaum, S.597-616

Preece, J. (2001) Sociability and usability in online communities: Determining and measuring success. Zitiert nach Preece, J., Maloney-Krichmar, D., (2003) “Online Communities: focusing on sociability and usability”, in Jacko, J. A., Sears, A. The Human-Computer Interaction Handbook. Mahwah, New Jersey, London: Lawrence Erlbaum, S.597-616

Preece, J., Maloney-Krichmar, D., (2003) “Online Communities: focusing on sociability and usability”, in Jacko, J. A., Sears, A. The Human-Computer Interaction Handbook. Mahwah, New Jersey, London: Lawrence Erlbaum, S.597-616

Rheingold, H., (1994) The virtual  community. Homesteading on the electronic frontier. Zitiert nach nach Preece, J., Maloney-Krichmar, D., (2003) “Online Communities: focusing on sociability and usability”, in Jacko, J. A., Sears, A.
The Human-Computer Interaction Handbook. Mahwah, New Jersey, London: Lawrence Erlbaum, S.597-616

Soziabilität, 20.02.2010, http://de.wikipedia.org/wiki/Soziabilit%C3%A4t

Wascher, K., (2009) Einflüsse moderner Medien auf das Kommunikationsverhalten der Dotcom-Generation. Mag. , Institut für Mathematik an der Universität

Was versteht man unter…? Kritische Masse, 20.02.2010, http://www.community-management.de/2008/06/was-versteht-man-unter%E2%80%A6-kritische-masse/

Wellman, B. &Gulia, M. (1999b). Virtual communities as communities: Net surfers don’t ride alone. Zitiert nach Preece, J., Maloney-Krichmar, D., (2003) “Online Communities: focusing on sociability and usability”, in Jacko, J. A., Sears, A. The Human-Computer Interaction Handbook. Mahwah, New Jersey, London: Lawrence Erlbaum, S.597-616

Wiki, 20.02.2010, http://de.wikipedia.org/wiki/Wiki

Whittake, S., Issacs, E., &O’Day, V. (1997) Widening the net. Workshop report on theory and practice of physical and network communities. Zitiert nach Preece, J., Maloney-Krichmar, D., (2003) “Online Communities: focusing on sociability and usability”, in Jacko, J. A., Sears, A. The Human-Computer Interaction Handbook. Mahwah, New Jersey, London: Lawrence Erlbaum, S.597-616


Page 3 of 3123

Einführung in die Programmierung

By
on Regards: Article;

Ab und zu schau ich auf meiner alten Seite vorbei und stöbere deren Artikel durch. Die Seite ist für Besucher nicht sichtbar. Es ist schade um die Artikel, wenn diese ohne einen Nutzen vor sich hin faulen. Deshalb habe ich diesen Artikel von der alten Homepage in den Blog eingetragen. Er wurde am 14.02.04 verfasst. Da er sich aber grundlegend mit der Programmierung befasst, hat sich am Inhalt nichts geändert. Anregungen und Kritik sind erwünscht. ? Viel Spaß beim lesen.

Einleitung
Einführung
Anweisungen
Syntax
Abarbeitung
Algorithmus
Programmiersprachen
Basic
Java
Fortran
Cobol
Pascal
Perl
PHP
C
C++
C#
Assembler
Niedrige Programmiersprachen
Grundbegriffe
Maschinensprache
Niedrige Programmiersprachen
Hohe Programmiersprachen
Interpreter Sprachen
Compiler

1 Einleitung

Bevor wir mit dem eigentlichen Programmieren beginnen, sollten wir uns zuerst dem theoretischen Teil, sprich den Grundbegriffen, widmen.

Alle Operationen die ein digitaler Computer vornimmt, basieren auf einem Bauteil, welcher erkennen kann ob ein Schalter bzw. ein Gatter geöffnet oder geschlossen ist. Ein Computer kann also zwischen zwei Zuständen unterscheiden, Strom an oder aus, Zustand 1 oder 0. Aus diesen Erkennungsbauteilen lassen sich logische Schaltungen anordnen, mit denen sich dann mathematische Operationen ausführen lassen. Die mathematischen Grundlagen dieser logischen Schaltungen legte der britische Mathematiker George Boole in der ersten Hälfte des 19. Jahrhunderts fest. Die von ihm erfundene Boolesche Algebra beschreibt das Rechnen, mit den logischen Ausdrücken wahr und falsch.
Ein Programm gibt dem Prozessor also Befehle, die beschreiben wie diese Logikschaltungen angesteuert werden. Diese Befehle müssen aber, damit der Prozessor sie versteht im Binärsystem als in einer Anordnung von 0 und 1 vorliegen. Ein Programm bedeutet also das Senden einer zeitlich genau abgestimmten Serie von An- und Aus-Signalen. Diese Signalfolgen ergeben den Maschinencode (Binärcode oder auch Maschinensprache genannt).
Das Programmieren der ersten Computer war eine schwierige und mühevolle Aufgabe, weil die Programme von Hand gesteckt werden mussten. Die Programmierer benötigten oft Tage um einfache Aufgaben zu programmieren. Die nachfolgenden Computer erhielten Speichersysteme in denen die Programme gespeichert werden konnten. Statt ein Programm von Hand zu stecken, wurde es z.B. auf Lochkarten gespeichert und vom Computer eingelesen. Die Idee der Lochkarten hatte übrigens der französische Erfinder Joseph Marie Jacquard. Er verwendete bei dem Entwurf einer automatischen Webmaschine dünne, gelochte Holzbretter zur Steuerung komplizierter Webmuster.
Durch die Einführung dieser Speicher konnte ein einmal geschriebenes Programm auf beliebig vielen Rechnern ausgeführt werden, ohne jedes Mal die Relais oder Elektronenröhren neu verdrahten zu müssen. Immer noch musste aber ein Programm im Binärcode geschrieben werden. Es lag nahe für diese sehr zeitaufwändige Übersetzungsaufgabe Programme zu entwerfen. Diese Übersetzerprogramme erlaubten es nun, anstelle oft wiederkehrender Standardanweisungen, einfache kurze Merkwörter einzusetzen. Diese Merkwörter (Mnemonics) wurden dann vom Programm auf Fehler kontrolliert und übersetzt. Diese frühen Programmiersprachen heißen Assemblersprachen.
Ein großer Nachteil der Assemblersprachen war allerdings, dass die einmal geschriebenen Programme nur auf diesem einen Prozessortyp liefen. Dies führte zur Entwicklung sogenannter “Höherer Programmiersprachen”. Höhere Programmiersprachen bestehen ganz aus diesen Merkwörtern. Diese werden dann genau wie bei Assemblersprachen auf Fehler überprüft und übersetzt. Diese Übersetzer in den Binärcode heißen Compiler. Eine „Höhere Programmiersprache“ ist also nicht mehr so stark vom Prozessor, sondern vom Compiler abhängig. Dies führt aber dazu, dass “Höhere Programmiersprachen“ nicht mehr die volle Leistung des jeweiligen Prozessortyps ausschöpfen können und dadurch etwas langsamer sind.
Eine Programmiersprache ist also ein Programm welches jedem Befehl Merkwörter zuordnet und dann in den Binärcode übersetzt.

1.1 Allgemeine Einführung

Ein Programm hat die Aufgabe ein Problem zu lösen. Dabei besteht jede Datenverarbeitung aus drei Schritten:

E … Eingabe von Daten (Input)
V … Verarbeitung der Eingangsdaten zu neuen Daten, den Ausgabedaten (Processing)
A … Ausgabe der Daten (Output)

1.2 Anweisungen

Unter einer Anweisung versteht man einen Befehl, der eine bestimmte Aktion ausführt. In jeder Programmiersprache müssen Anweisungen bestimmten Regeln entsprechen, die man in ihrer Gesamtheit als Syntax bezeichnet.

1.3 Syntax

Syntax bedeutet wenn man diese ins Deutsche übersetzt „Satzbau“.
Eine Programmiersprache ist definiert durch eine Folge von Zeichen, die nach bestimmten Regeln aneinander gereiht werden. Eine Syntax gibt ausschließlich Regeln vor, nach denen man Folgen von Zeichen konstruieren kann.

1.4 Abarbeitung

Ein Computerprogramm wird immer Schritt für Schritt abgearbeitet. Bei einer solchen Abarbeitung wird immer nach dem selben Grundprinzip vorgegangen, das die Problemlösung beschreibt (=Algorithmus), dieses Prinzip wird von jeder Programmiersprache vorgegeben.

1.5 Algorithmus

Algorithmus bezeichnet eine Verarbeitungsvorschrift, die die Problemlösung beschreibt. Oder anders ausgedrückt, ein Algorithmus fasst alle Schritte zusammen, die man auf dem Weg zur Lösung gehen muss. Diese Verarbeitungsvorschrift ist genauestens formuliert, sodass sie direkt im geschrieben Programm umgesetzt werden kann.

1.6 Programmiersprachen

Basic

…bedeutet „Beginners All Purpose Symbolic Instruction Code“ zu Deutsch „Symbolischer Allzweck Befehlscode für Anfänger“. 1963 befassten sich Thomas E. Kurtz und John Kemeny am Dartmouth College mit dem Problem, das man Nicht-Technik-Studenten, die Arbeit am Computer näher bringen wollte, damit diese später in der Wirtschaft ein grundsätzliches Verständnis besitzen. Man ging dazu über, eine eigene Sprache zu entwickeln, die speziell auf die Bedürfnisse der Studenten abgestimmt sein sollte – die Geburtsstunde von BASIC. Wie aus dem Namen schon zu entnehmen ist, ist Basic leicht zu erlernen. Es wird bei dieser Programmiersprache kein strukturiertes Programmieren gefordert, deshalb ist es sehr leicht, unübersichtliche Programme zu schreiben.

Java

… wurde von „Sun“ entwickelt, mit dem Ziel, eine plattformunabhängige Programmiersprache zu entwickeln. Dies gelingt, indem das Java-Programm (der Quellcode) in eine Metasprache (übergeordnete Sprache) übersetzt wird & diese erst bei der Ausführung mittels der „Virtual machine“, also einem virtuellen Computer –quasi ein Interpreter, in die Maschinensprache der jeweiligen Plattform umgesetzt wird. Java ist eine objektorientierte Sprache.

Fortran

…ist die Abkürzung für Formula Translation (Formelübersetzung). Fortran wurde im Jahre 1954 entwickelt. Früher wurden alle wissenschaftlichen- technischen Anwendungen in dieser Sprache programmiert.

Cobol

…steht für Common Business Oriented Language was soviel wie „Allgemeine Geschäfts orientierte Sprache“ bedeutet. 1960 wurde Cobol entwickelt, anschließend im Jahre 1974 genormt und ist die meistbenutzte Programmiersprache für kaufmännische Aufgabenstellungen. Cobol ist besonders vorteilhaft bei der Verarbeitung großer Datenmengen.

Pascal

Die Programmiersprache ist nach dem Französischen Mathematiker Blaise Pascal(1623-1663) benannt. Sie ist 1971 von Niklas Wirth an der ETH Zürich entwickelt worden. Die Programmiersprache wurde 1983 genormt. Die Sprache ist sehr übersichtlich. Da wichtige Teile wie z.B. I/O Steuerung nicht genormt wurden, entstanden auch hier verschiedene Dialekte, dadurch konnte sich die Sprache nicht durchsetzten.

Perl (Practical Extraction and Report Language)

Perl wurde ursprünglich von Larry Wall entworfen, er stellte 1993 die Skriptsprache der Allgemeinheit zu Verfügung. Perl wurde ursprünglich unter „Unix“ entwickelt, ist jedoch inzwischen für die meisten Betriebssysteme verfügbar. Perl verfügt über leistungsfähige Routinefunktionen für Zeichenfolgen zum Extrahieren von Informationen aus Textdateien. Perl kann eine Zeichensprache assemblieren und an die Shell als Befehl senden. Aufgrund dessen wird dieses Sprache häufig bei Tasks für die Systemverwaltung eingesetzt. Dies ist ein weiterer Grund warum Systemadministratoren und Webentwickler Perl besonders gern einsetzen.
Bemerkung: Skriptsprachen, ermöglichen die Ausführung des Programmcodes ohne getrennte Übersetzungsphasen.
Programme, die in Skriptsprachen geschrieben sind, werden auch Skripte genannt. Es handelt sich immer um Textdateien oder Textfragmente, die mit einem normalen Editor bearbeitet werden können.

PHP

Die Scriptsprache PHP wurde 1994 von Rasmus Lerdorf entwickelt. Er nannte seine Sprache Personal Home Page / Form Interpreter, da er sie für seine eigene Homepage verwendete um Formulare auszuwerten. Mittlerweile verbirgt sich hinter der Abkürzung der lange Name „PHP Hypertext Preprocessor“ Der PHP-Code wird auf dem Server verarbeitet. PHP unterstützt eine Vielzahl von Datenbanksystemen und kann durch eine Vielzahl von Modulen um wichtige Funktionen erweitert werden.

C

C wurde 1972 von Brian Kernighan und Dennis Ritchie in den Bell Laboratories entwickelt und ist sehr streng genormt. C hat ein sehr klares Sprachkonzept, verfügt über ein breites Anwendungsspektrum (z.B. Linux wurde in C programmiert) und über knappe Befehle. Da der Sprachumfang von C klein ist, kann es auch leicht auf den verschiedensten Plattformen implementiert werden und eignet sich hiermit auch für Hardwarezugriffe. Die Vorteile von C bestehen in seiner sehr variablen Architektur (C kann für die verschiedensten Anforderungen spezialisiert werden) und seine damals unglaubliche Effizienz (Programme waren bis zu 10-mal schneller als gleiche Programme in COBOL).

C++

C++ ist der Nachfolger von C und wird so genannt, weil es “Eins mehr” ist. In Sprachen wie Java(script) und PHP wird eine Zahl durch das Ansetzen von “++” um Eins erhöht. Die Sprache C++ wurde von Bjaarne Stroustrup in Jahre 1985 entwickelt. C++ ist baukastenförmig aufgebaut, wobei jeder Baustein ein Programmteil ist. Aufgrund dieser Baustein -Architektur ist C++ so effizient. Da lediglich die Objekte (Befehle) ins Programm integriert werden, die für ein Programm benötigt werden, befindet sich kein unnötiger Ballast im Quelltext.

C#

C# wird als C Sharp gesprochen. C# wurde von Microsoft in Kooperation mit Anders Hejlsberg, dem Designer der Sprache „Delphi“, entwickelt und ist am 14. Februar 2002 im Rahmen des .NET Framework veröffentlicht worden. C# ist grundsätzlich keine neue Programmiersprache, zumindest was die Syntax betrifft. C# ist mehr oder weniger aus der Syntax der C/C++ Sprachfamilie hervorgegangen. C# vereint die hohe Performance von C++ und die Einfachheit von Visual Basic. Das Konzept ist aber von Grund auf neu entwickelt worden und fügt sich hundertprozentig in die neue .NET-Technologie ein. Außerdem unterstützt C# vollständig die „component-based (komponentenbasierte)” Programmierung. Komponente sind Bausteine, die einmal entwickelt und immer wieder verwendet werden können. Das spart Entwicklungszeit. C# ist wie Java plattenformunabhängig. Das heißt, ein Programm läuft nicht nur unter dem Betriebssystem, unter dem es entwickelt wurde, son dern auf allen Systemen, für die eine Version des .NET Framework existiert. Wie C++ ist auch C# eine moderne objektorienierte Programmiersprache.

Assembler

Assembler ist eine Maschinensprache und somit die älteste Programmiersprache überhaupt. Assembler ist eine sehr schlichte Sprache, die die Maschinenbefehle direkt in eine für den Menschen lesbare Form abbildet. Dabei entspricht eine Assembleranweisung im Allgemeinen genau einer Maschinenspracheanweisung.
Statt 00000101 00000011 11101000 kann man in Assembler kürzer und lesbarer „add ax1000“ schreiben. Eine Maschinensprache und damit auch der Assemblercode sind auf den jeweiligen Prozessor zugeschnitten, d.h. Maschinenspracheprogramme sind im Allgemeinen nicht portierbar!

1.7 Niedrige Programmiersprachen
1.7.1 Grundbegriffe

Prozessor oder CPU ( Central Processing Unit), quasi das „Herz“ eines Computers, kann nur relativ einfache Befehle ausführen wie addieren, Daten von einer bestimmten Speicheradresse laden oder dort abspeichern, zu einer bestimmten Speicheradresse springen (z.B. Grafikkarte) und dort den Programmablauf fortführen, etc.
Diese Befehle sind codiert, also sozusagen durchnumeriert, der Befehl „Springe zur Adresse D3AAH“ könnte z.B. den Code „CAD3AA“ haben. Es ist leicht nachvollziehbar, dass diese Befehle bzw. deren Codes von Prozessor zu Prozessor unterschiedlich sind.

1.7.1.2 Maschinensprache

Maschinensprache: Befehlssprache des jeweiligen Prozessors. Besteht in der Regel aus einigen hundert Befehlen, jeder davon ist eine Abfolge von ein bis vier Bytes.
Typische Befehle: Wert in einem Prozessorspeicherplatz (Register) ablegen, von dort auslesen, einfachste Additionen und Vergleiche, …

Beispiel: Möchte man z.B. auf einem Intel-Prozessor (80×86) den Wert 1000 im Register ax ablegen, verwendet man folgenden Maschinensprachebefehl:

00000101 00000011 11101000

Das erste Byte bezeichnet den Code des entsprechenden Befehls (binär 5), die nächsten zwei Bytes den Datenanteil (binär 1000).

1.7.1.3 Niedrige Programmiersprachen

Niedrige Programmiersprachen sind z.B. Assembler und C. Diese verfügen über einen dem tatsächlichen CPU-Befehlssatz sehr ähnlichen Wortschatz. Es gibt für diese Plattform keinen Compiler oder Interpreter.

1.8 Hohe Programmiersprachen

Hohe Programmiersprachen sind Programme, die in einer Sprache geschrieben sind, die für den Menschen (relativ) leicht, jedoch für den Prozessor unlesbar ist. Man könnte auch sagen, dass die Problematik mittels eines Computerprogramms mit einer abstrakten, d.h. nicht CPU-abhängige Sprache gelöst werden kann.
Im Gegensatz zur Assemblersprache, die maschinenorientiert ist, ist eine höhere Programmiersprache mehr problemorientiert und nicht plattformabhängig. Nachdem die Aufgabe mit einer dieser Sprachen gelöst wurde, muss diese Sprache in die Sprache des jeweiligen Computertyps, also CPU, (und Grafikkarte, etc) umgesetzt werden. Dazu gibt es zwei Strategien: den Interpreter und den Compiler.

 

1.9 Interpreter Sprachen

Englische Bezeichnung für “Übersetzer”. Beim Interpreter wird das jeweilige, in einer höheren Programmiersprache erstellte Programm unmittelbar vor dem Durchführen (zeilenweise) in die Maschinensprache übersetzt und anschließend ausgeführt. Daraus ergibt sich, dass die Ablaufgeschwindigkeit wesentlich geringer wird. Im Gegensatz zu einem Compiler erzeugt ein Interpreter keinen speicherbaren Maschinencode.

 

1.10 Compiler

Ein Übersetzungsprogramm, welches Programme einer höheren Programmiersprache in die vom Prozessor ausführbare Maschinensprache umwandelt.
Allgemein: Die gesamte Programmbearbeitung mit einem Übersetzer (Compiler) erfolgt in drei Stufen, wobei auch drei Dateien erzeugt werden:
In den Quell- oder Source-Code schreibt der Programmierer mit seiner gewählten Programmiersprache das Programm.
Der Compiler übersetzt diesen vom Programmierer geschriebenen Quellcode und erzeugt den Object-Code, der noch nicht ausführbar ist. Er führt einen Syntaxtest durch und gibt im Fehlerfall Hinweise auf die Art des Kodierungs-Fehlers.
Der Linker oder „Verbinder“ hängt noch Teile des Compilers wie Ein-/Ausgabe Routinen, Funktionsberechnungen oder fremde Routinen an. Nach dem Linken entsteht das ausführbare Element, das der Prozessor verarbeiten kann.

Quellen:

Informatik Skriptum aus der Schule

Autor(en):Schmaranz, Klaus; Softwareentwicklung in C. Verlag: Springer, Berlin; Auflage: 1 (September 2001) ISBN: 3540419586
Autor(en):Dirk Louis, Shinja Strasser; C# in 21 Tagen 2002 Verlag: Markt+Technik ISBN: 3-8272-6069-8
Autor(en):Walter Doberenz, Thomas Kowalski; Visual C#.NET – Grundlagen und Profiwissen 2003
Verlag: Carl Hanser ISBN 3-446-22021-6
Autor(en): Joscha Feth; Dynamische Webseiten mit Flash und PHP 2002 Verlag: Markt+Technik ISBN: 3827262852
Links vom 14.02.2004
http://php.martin-jansen.de/entstehung.php
http://de.wikipedia.org/
http://www.principia-natura.de
http://www.guidetocsharp.de/
http://www.masterportal24.com


Page 3 of 3123