Zustandsdiagramme zeigen die durch Ereignisse (Events) beeinflussten Zustände, die ein Objekt annehmen kann, sowie die Ereignisse oder Nachrichten, die im kausalen Zusammenhang mit einem Zustandswechsel stehen. In einem Geschäftssystem wird die Zustandsänderung der Objekte (Verhalten) durch Geschäftsprozesse nach Geschäftsregeln ausgelöst.

Am leichtesten sind Zustandsdiagramme zu verstehen, wenn die objektorientierte Programmierung verstanden wurde. Für Objekte gelten folgende Grundsätze:

• jedes Objekt gehört jeweils zu genau einer Klasse
• die Klasse beschreibt den Anfangszustand sowie Startparameter (welche den Zustand jedoch sofort ändern können)
• ein Objekt wird aus einer Klasse erzeugt und irgendwann wieder zerstört (gelöscht), der Zeitraum zwischen Erzeugung und Zerstörung ist der Lebenszeitraum des Objekts
• während des Lebenszeitraums kann ein Objekt von Ereignissen oder Nachrichten beeinflusst werden und dadurch seinen Zustand wechseln.

Zustandsdiagramme haben ihre größte Bedeutung in der Software-Entwicklung, Geschäftsprozessmodellierung oder allgemeiner in der Wirtschaftsinformatik.

Elemente eines Zustandsdiagramms

1. Zustand

Eine Aktivität bildet eine Funktion/Methode bzw. einen Prozess ab. Aktivitäten werden in abgerundeten Rechtecken dargestellt.

2. Übergänge (Ereignisse)

Übergänge stehen für Ereignisse.

2.1 Einfacher Übergang

Ein Übergang verursacht einen Zustandswechsel. Übergänge symbolisieren Ereignisse und werden mit Pfeilen dargestellt. Ereignisse können eingeteilt werden in:

• objekterzeugende Ereignisse
• Ereignisse zur Lebenszeit des Objekts
• objektzerstörende Ereignisse

Ein Ereignis kann statt einer Entscheidung auch eine einfache Bedingung haben. Bedingungen (als boolesche Ausdrücke) für Übergänge werden in eckigen Klammern an den jeweiligen Übergang geschrieben.

2.2 Aufspaltung

Die Aufspaltung führt von einem Ereignis zu mehreren Ereignisse. Eine horizontale oder vertikale Linie dient als Synchronisationsbalken, der für die Parallelisierung der nachfolgenden Ereignisse steht.

2.3 Zusammenführung

Die Zusammenführung ist die Umkehrung der Aufspaltung: Mehrere Ereignisse lösen ein Ereignis aus.

3. Entscheidung (Verzweigung)

Eine Verzweigung hat einen Eingang und mindestens zwei Ausgänge.

4. Startzustand

Tritt ein objekterzeugendes Ereignis ein, so beginnt der Übergang dem Symbol für den Startzustand.

Der Startzustand symbolisiert die Entstehung (in der Software-Entwicklung: Instanziierung) eines Objekts.

5. Endzustand

Tritt ein objektzerstörendes Ereignis ein, so endet ein Übergang beim Symbol für den Endzustand.

Endzustand bedeutet das Lebensende bzw. die Löschung des Objekts.

Beispiel eines Zustandsdiagramm

Das nachfolgende Zustandsdiagramm zeigt das Verhalten einer verteilten Anwendung (Client-Server-Programm). Diese Anwendung besteht im Grunde aus zwei verschiedenen Programmen, einem Client- und einem Server-Programm.

Aktivitätsdiagramme sind vergleichbar mit Programmablaufplänen oder Struktogrammen und nicht nur in der Software-Entwicklung nützlich, sondern auch in der Prozessabbildung, beispielsweise zur Abbildung von Geschäftsprozessen. Aktivitätsdiagramme ermöglichen die Abbildung von Verantwortungsbereichen über Prozesse sowie die Parallelisierung von Prozessen, was Aktivitätsdiagramme besonders für die Darstellung und Analyse von Geschäftsprozessen in der Wirtschaftsinformatik und Aktivitäten bei verteilten Anwendungen in der Software-Entwicklung qualifiziert.

Elemente eines Aktivitätsdiagramms

1. Aktivität

Eine Aktivität bildet eine Funktion/Methode bzw. einen Prozess ab. Aktivitäten werden in abgerundeten Rechtecken dargestellt.

2. Zustand

Zustände von Objekten werden in Rechtecken dargestellt und sind in Aktivitätsdiagrammen als Eingangs- und Ausgangsinformation von Bedeutung. Viele Aktivitätsdiagramme kommen jedoch auch ganz ohne Zustände aus.

3. Kontrollfluss (Übergang)

Mit einem Kontrollfluss werden ein oder mehrere Aktivitäten ausgelöst. Diese Übergänge von Startpunkt zu Prozessen, Prozessen untereinander bis zu einem Endpunkt werden mit Pfeilen dargestellt. Jede Aktivität (Prozess) beginnt und endet mit einem Übergang, wenn nicht mit einer Verzweigung.

3.1 Einfacher Kontrollfluss

Ein einzelner Pfeil zeigt einen einfachen Übergang zwischen Startpunkt und Prozess, Prozess und Prozess oder Prozess und Endpunkt.

3.2 Aufspaltung

Die Aufspaltung führt von einem Prozess zu mehreren Prozessen. Eine horizontale oder vertikale Linie dient als Synchronisationsbalken, der für die Parallelisierung der nachfolgenden Prozesse steht.

3.3 Zusammenführung

Die Zusammenführung ist die Umkehrung der Aufspaltung: Mehrere Prozesse führen zu einem Prozess.

4. Entscheidung (Verzweigung)

Eine Verzweigung hat einen Eingang und mindestens zwei Ausgänge.

5. Startzustand

6. Endzustand

7. Verantwortlichkeitsbereiche

Jede Aktivität liegt in einem Verantwortlichkeitsbereich, beispielsweise in einer Client- oder Server-Software oder in verschiedenen Unternehmensbereichen.

Aktivitätsdiagramm – Beispiel

Nachfolgend ein vereinfachtes Beispiel eines Aktivitätsdiagramms, welches den Zahlungsprozess zwischen Kunden, Kassierer und Kassensystem abbildet. Aus Gründen der Einfachheit wird nur die Möglichkeit der EC-Karten-Zahlung eingeräumt.

Stellenwertsysteme basieren auf der bestimmten Wertigkeit einer Position (Stelle) jeder Ziffer. Ein typisches Zahlensystem, welches kein Stellenwertsystem, sondern ein Additionssystem ist, ist das Notieren von Ereignissen/Objekten mit Strichen, beispielsweise das (für Bierdeckelnotizen bekannte) System, wonach vier Striche vertikal, der fünfte Strich diagonal dargestellt werden. Additionssysteme können auch in anderer Form dargestellt werden, sind gewöhnlicherweise aber nur für kleine Summen übersichtlich.

Stellenwertsysteme entsprechen einer anderen Logik, nämlich der der Stellenwerte.

Der Wert einer Zahl (Zahlenwert) wird nicht an Hand von Strichen oder anderen Symbolen abgezählt, sondern errechnet. Der Zahlenwert ist die Summe aus allen Ziffernwerten (die einer Zahl zugehörig sind). Die Ziffernwerte sind die jeweiligen Produkte aus Stellenwert und Nennwert.

Zahlenwert = ∑ Ziffernwert_i = ∑ (Nennwert_i x Stellenwert_i)

Stellenwertsysteme im Alltag und der Informatik

Zahlen nach Stellenwertsystem dargestellt, werden nicht mit Strichen, sondern mit einer Folge von Ziffern angegeben.

Eine Ziffer ist ein Zeichen zur Darstellung von Zahlen aus einem Zeichenvorrat, der aus einer Ziffernzahl (Basis) x verschiedener Elemente besteht.

Das uns bekannteste und meist verwendete Zahlensystem ist das Dezimalzahlensystem (Zehnersystem, “dezi” = “zehn”, zurückzuführen auf die zehn Finger des Menschen).

Dezimalzahlensystem: Basis = 10 Zeichenvorrat: 0,1,2,3,4,5,6,7,8,9

Der Endwert einer Zahl ist die Summe aus allen Produkten nach Stellen. Ein aus den Nennwerten und den Stellenwerten.

Die zwei wichtigsten Zahlensysteme in der Informatik sind das Dualzahlensystem (Binärzahlsystem, Zweiersystem) und das Hexadezimalzahlensystem (Sechser- plus Zehnersystem).

Dualzahlensystem: Basis = 2;  Zeichenvorrat: 0, 1

Hexadezimalzahlensystem: Basis = 16; Zeichenvorrat: 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F

Diese Zahlensysteme werden, auf Grund der alltäglichen Nutzung des Dezimalzahlensystems, am besten verstanden, wenn diese in das Dezimalzahlensystem umgewandelt werden.

Beispiel einer binären Zahl (Dualzahl):

Beispiel einer Hexadezimalzahl:

Ein weiteres gängiges Zahlensystem ist das Oktalzahlensystem (Achtersystem), auf welches an dieser Stelle jedoch nicht weiter eingegangen wird.

Oktalzahlensystem: X = 8; Zeichenvorrat: 0,1,2,3,4,5,6,7

Zurückrechnen vom Dezimalsystem ins Dualsystem

Dezimalzahl 79 in Dual umrechnen:

79 / 2 = 39 Rest 1 (da 0,5 * 2 = 1)

39 / 2 = 19 Rest 1

19 / 2 = 9 Rest 1

9 / 2 = 4 Rest 1

4 / 2 = 2 Rest 0

2 / 2 = 1 Rest 0

1 / 2 = 0 Rest 1

=> 1001111

Zurückrechnen vom Dezimalsystem ins Hexadezimalsystem

Dezimalzahl 79 in Hexadezimal umrechnen:

79 / 16 = 4 Rest F (0,9375 * 16 = 15 = F)

4 / 16 = 0 Rest 4

=> 4F

Umrechnen von Dualzahlen in Hexadezimalzahlen

Diese Rechnung ist sehr einfach. Es gilt: Vier Stellen der Dualzahl entspricht einer Stelle einer hexadezimalen Zahl. Als Zwischenschritt werden die vier Stellen (immer ausgehend vom Komma) abgezählt und dezimal betrachtet.

Umrechnen der Dualzahl 1001111 in Hexadezimal:

(Achtung! Auf diese Weise kann die Binärzahl nicht in das Dezimlasystem umgerechnet werden! 1001111 sind nicht 4 + 15 sondern 79!)

Umrechnen von Hexadezimalzaheln in Dualzahlen

Umgekehrt funktioniert dies genauso gut. Ein anderes Beispiel mit der hexadezimalen Zahl B0D3:

(Achtung! Auf diese Weise kann die Hexadezimalzahl B0D3 nicht in das Dezimalsystem umgerechnet werden! B0D3 ist nicht 11 + 0 + 13 + 3 sondern 45267)

Rechnen mit dem Dualzahlensystemen

Addition von Dualzahlen

0 + 0 = 0
1 + 0 = 1  bzw. 0 + 1 = 1
1 + 1 = 0 Rest 1
1 + 1 + 1 = 1 Rest 1
1 + 1 + 1 + 1 = 0 Rest 1 und 1 (zwei Einsen)

Die Restwerte werden als Überträge in die Rechnung (immer für die nächst höhere Stelle) mit eingebracht. Überträge werden hier blau dargestellt.

Beispiel: 110111 + 10110 = 1001101

Beispiel: 101111 + 11111 + 10010 = 1100000

Subtraktion von Dualzahlen

1. Fall – Minuend ist größer als Subtrahend:
   Beispiel: 11011 – 110 = 10101

   1.) 110 auf gleiche Stellenzahl bringen -> 00110
   2.) den Subtrahend umkehren -> 11001
   3.) den Subtrahend zum Minuend addieren

   Minuend			1	1	0	1	1
   Umgekehrter Subtrahend			1	1	0	0	1
   Überlauf		1	1		1	1
   Summe			1	0	1	0	0

   4.) Aus dem Überlauf wird dann nochmals die verbleibende 1 hinzu addiert!

   			1	0	1	0	0
   Plus Überlauf			0	0	0	0	1
   Summe			1	0	1	0	1

   Die letzte Summe ist das Ergebnis 10101.

   Weiteres Beispiel: 101110 – 100

   Minuend		1	0	1	1	1	0
   Umgekehrter Subtrahend		1	1	1	0	1	1
   Überlauf	1	1	1	1	1
   Summe		1	0	1	0	0	1

   Aus dem Überlauf wird dann nochmals die verbleibende 1 hinzu addiert!

   		1	0	1	0	0	1
   Plus Überlauf		0	0	0	0	0	1
   						1
   Summe		1	0	1	0	1	0

   Das Ergebnis lautet: 101010

2. Minuend ist kleiner oder gleich Subtrahend
   Beispiel:  11010 – 111011 = ???
   1.) Subtrahend umkehren: 111011 -> 000100
   2.) Zum umgekehrten Subtrahend 1 addieren: 000100 + 000001 = 000101
   3.) Minuend und umgekehrten Subtrahend addieren:

   Minuend		0	1	1	0	1	0
   Neuer Subtrahend		0	0	0	1	0	1
   Überlauf
   Summe		0	1	1	1	1	1

4.) Die Summe wird wiederum umgekehrt: 011111 -> 100000
5.) Zur umgekehrten Summe wird eine 1 hinzu addiert: 100000 + 00001 = 100001

Das Ergebnis lautet 100001 (negativ, da eine größere Zahl von einer kleineren Zahl abgezogen wurde).

Multiplizieren von Dualzahlen:

Ein einfaches Beispiel: 1010 x 110 = 111100

Die Multiplikation kann sich auch etwas komplexer gestalten, so dass Überträge (blaue Zahlen) zu berücksichtigen sind. Beispiel: 1011011 x 10011 = 11011000001

Division von Dualzahlen

Die Division beginnt immer beim Divident an der Stelle mit dem höchsten Stellenwert (ganz links). Es wird schrittweise versucht, den Dividenten durch den Divisor zu teilen.

• Kann der Divisor vom Dividenten vollständig (mit Dualsubtraktion) subtrahiert werden?
  • Wenn ja, dann eine 1 im Ergebnis verzeichnen und mit Rest weiter rechnen.
  • Wenn nein, dann eine 0 im Ergebnis verzeichnen und eine Stelle nach rechts rücken, wieder von vorne mit der Frage beginnen.

Beispiel: Divident = 10110; Divisor = 101

Weiteres Beispiel: Divident = 1011101; Divisor = 111

Rechnen mit dem Hexadezimalzahlensystemen

Addieren von Hexadezimalzahlen:

Beispiel: AB96F + 2A3 = ABC12

Beispiel: 40A113 + 13248 + ECEDF + F2CE9F = 14370D9

Multiplizieren von Hexadezimalzahlen:

Bei der Multiplikation müssen Überträge bereits bei der Multiplikation berücksichtigt werden.
Ein einfaches Beispiel: ABB x 208 = 15CBD8

Beispiel: FD12A x CF4 = CCE15408

Insbesondere die Selbstbeschreibungsfähigkeit (Software soll sich selbst erklären können, unter Berücksichtigung der Zielgruppe) und die Erwartungskonformität (der Benutzer soll bekommen, was er mit der Anschaffung und Nutzung der Software erwartet) erleichtern die Erlernbarkeit von Software.

Es sollen die Standardfunktionen der Software sowie die Individualisierbarkeit (Anpassung der Software an individuelle Ansprüche und Vorgaben) so gestaltet werden, dass sie für den Benutzer aus der Zielgruppe leicht durchschaubar und somit für ihn erlernbar sein.

Es kommt wirklich nicht selten vor, dass Benutzer Software verwenden, so wie sie es aus ihrem Umfeld her kennen, ohne dabei die Fähigkeiten in Sachen Individualisierbarkeit auszureizen, weil sich die Funktionen der Individualisierbarkeit und individuelle Funktionen selbst nicht selbstbeschreiben und zusätzlich noch zu kompliziert gestaltet sind.

Die Erlernbarkeit von Software hängt natürlich auch vom Benutzer und seinem Vorwissen ab. Die Erlernbarkeit ist nur dann ausreichend, wenn die Funktionen der Software für jeden Benutzer aus der Zielgruppe, für welche die Software bestimmt wurde, vollständig (mit Ausnahme von versteckten Funktionen, welche nur für die Software-Entwicklung gedacht sind) mit angemessenen Mitteln und vertretbarer Mühe erlernbar sind.

Sicher ist die Erlernbarkeit von Software nicht direkt messbar und auch “angemessene Mittel” und “vertretbare Mühe” sind stark Auslegungssache. Der Softwarehersteller muss sich selbstkritisch mit dem Thema auseinandersetzen und eigene, eher pessimistische Maßstäbe setzen.

Andererseits ist die zu gute Erlernbarkeit für den Softwarehersteller manchmal gar nicht so erstrebenswert, wo doch viel Geld mit dem Support und mit Kursen/Zertifikaten gemacht werden kann und das Hauptaugenmerk nun mal leider nicht auf die Softwarequalität gelegt wird. Dennoch sollte jedes Unternehmen zumindest die grundlegenden Funktionen einer Software leicht erlernbar auslegen, so dass nur spezielle Funktionen durch weiteren Support erläutert und somit richtig nutzbar gemacht werden.

Ein sehr gutes Beispiel für einen Durchbruch in Sachen Erlernbarkeit, ist die grafische Benutzeroberfläche, welche durch Microsoft Windows erstmals richtig bekannt wurde und damit als erstes Betriebssystem sich im Heimanwendermarkt etablieren konnte. Während professionelle Computeranwender sich noch lange Zeit überwiegend mit der Konsolenbedienung zufrieden gaben, haben die vergleichsweise ungeduldigen Heimanwender durch die viel schneller erlernbare Grafikoberflächenbedienung Zugang zu der Bedienung des PCs gefunden. Die Grafikoberfläche hatte ihre Nachteile in der größeren Ressourcenlast und führte daher zu Performance-Einbüßen, dennoch war dies im Vergleich doch das geringere Übel.

Der harte Kern jeden Wissens sind Daten, welche mit einer Bedeutung versehen, Informationen sind. Informationen ergeben Wissen, wenn diese aus einem bestimmten Kontext heraus interpretiert werden (können) und entsprechend darauf reagiert werden kann.

Ziele des Wissensmanagement sind:

1. Förderung der Aneignung von neuem Wissen
   Beispielhafte Leitfrage: “Wie können unsere Mitarbeiter den Umgang mit neuen Verfahren lernen?”
2. Schaffung von Möglichkeiten zur Nutzung von bestehendem Wissen
   Beispielhafte Leitfrage: “Welche Organisation fördert innovatives Denken?”
3. Verhinderung von Verlust des Wissens
   Beispielhafte Leitfrage: “Wie kann ein Know-How-Verlust trotz Fluktuation verhindert werden?”

Implizites Wissen ins explizite Wissen überführen, und umgekehrt

Wissensmanagement managed leider nicht Wissen direkt, sondern die Wissensprozesse, also Prozesse, welche helfen, Wissen….

• zu erlangen
• zu sammeln
• zu verteilen
• aufzubereiten
• zu nutzen und
• beizubehalten

Wissen, welches jeder Mensch für sich im Kopf hat, ist implizit (intransparent, nicht verteilt und nicht für jemand anderes aufbereitbar). Von langfristiger Bedeutung für jedes Unternehmen ist explizites Wissen, welches in Form von Sprache auf Medien (Papier, optische Datenträger, Film etc.) vorliegt und somit langfristig für andere Menschen zugänglich ist.

Ziel des Wissensmanagements ist die Überführung von implizitem Wissen (so viel wie möglich) ins explizite Wissen.

Bevor implizites Wissen ins explizite Wissen überführt werden kann, muss das Wissen aus dem Kopf jedoch erst mal aufbereitet werden.

Auch Wissen hat diesbezüglich eine eigene Wertschöpfungskette, von wirren Erinnerungen, Gedanken und Ideen bis hin zu formalen und strukturierten Informationen. Das Wissen reift so bis zur Anwendbarkeit aus und wird von teilweise implizitem zu explizitem Wissen erweitert.

Der springende Punkt im Wissensmanagement ist aber nicht nur die Wissensbeschaffung, sondern auch die Beibehaltung des Wissens (im Unternehmen). Was passiert, wenn der Chefentwickler die Firma verlässt? Hierfür gibt es verschiedene Konzepte, bei welchen jedes einzelne keine perfekte Lösung verspricht, jedoch weit besser ist, als wenn dieses Problem ignoriert wird.

Ein Konzept ist beispielsweise jegliches Wissen, welches für Prozesse relevant ist, zu dokumentieren (z. B. mit einer Verfahrensanweisung) und alles gespeicherte Wissen zu klassifizieren und mit einem Index zu versehen. Der Index taucht dann wieder in Archiven auf, welche eine Suche nach Wissen zu bestimmten Produkten und Prozessen ermöglichen.

]]> http://www.der-wirtschaftsingenieur.de/index.php/wissensmanagement/feed/ 0 http://www.der-wirtschaftsingenieur.de/index.php/open-system-interconnection-referenzmodell/ http://www.der-wirtschaftsingenieur.de/index.php/open-system-interconnection-referenzmodell/#comments Mon, 25 Jan 2010 21:29:11 +0000 admin http://www.der-wirtschaftsingenieur.de/?p=1757 Das OSI-Referenzmodell (auch: OSI-Schichtenmodell, OSI-Modell, engl.: “Open Systems Interconnection Reference Model”) ist ein, in der Computer-Netzwerktechnik relevantes Modell der Internationalen Organisation für Normung (ISO).
Das OSI-Referenzmodell ist ein mehrschichtiges System eines offenen Netzwerksystems. Es ist die Grundlage, auf der Netzwerkkommunikationsprotokolle aufbauen.

Maßgeblich ist das OSI-Modell für offene Netzwerksysteme; dieses sind Netzwerke, in denen jeder Anwenderprozess mit jedem anderen über offengelegte Schnittstellen kommunizieren kann.

Das OSI-Modell basiert auf sieben Schichten nach dem Prinzip der Kapselung, welche für sich jeweils alleine für eine in sich geschlossene Ebene stehen.

1. Bitübertragungsschicht (Physikalische Schicht; Physical Layer):
   Realisierung der Übertragung von Daten über eine physische Schnittstelle bitweise in Form von digitalen Signalen. Ungesicherte Verbindung. Das Protokoll ist abhängig von der Hardware (z. B. Netzwerkkarte, Netzwerkchipsatz oder Bluetoothempfänger) und den physischen Erfordernissen der Signalübertragung. Die moderne Telefonverbindung findet auf dieser Ebene statt.
2. Datensicherungsschicht (Datenverbindungsschicht; Data Link Layer):
   Absicherung der korrekten Übertragung zusammenhängender Bitfolgen zwischen
   den kommunizierenden Rechnern, Erkennung und Korrektur von Fehlern in der Bitübertragung. Das HDLC-Protokoll (High-level Data Link Control Protocol) ist ein typisches Protokoll der Datensicherungsschicht.
3. Vermittlungsschicht (Netzwerkschicht; Network Layer):
   Innerhalb dieser Schicht wird der Weg vermittelt, über welchen die Daten zwischen Quell- und
   Zielrechner gesendet werden. Berücksichtigt werden dabei verfügbare Vermittlungsarten und Netzwerktopologien. Es werden virtuelle Verbindung aufgebaut. Bei Verbindungen über nur einen Kanal werden Multiplexverfahren verwendet.
4. Transportschicht (transport layer):
   Die Transportschicht ist Dienstleister, der den Dienstnutzer von der konkreten, untergelagerten Netzrealisierung
   unabhängig macht. Gängige Protokolle sind das verbindungslose UDP und verbindungsorientierte TCP. Egal ob im lokalen Netzwerk oder Internet, über TCP und UDP können Daten immer unabhängig von Topologie und Hardware eingesetzt werden. Protokolle der Transportschicht gleichen oftmals Schwächen unterschichtiger Protokolle aus, können Vorränge im Datentransfer und Verbindungsqualitäten gewährleisten.
5. Kommunikationssicherungsschicht (Sitzungsschicht; Session Layer):
   Synchronisation der Kommunikation, inklusive Beginn und Ende. Ermöglichung der Wiederherstellung der Verbindung. Übernahme der Senden-/Empfangssynchronisation.
6. Darstellungsschicht (Presentation Layer):
   Einheitliche Interpretation und Austausch der Daten unabhängig von ihrer konkreten Darstellung in der Anwenderschicht. Sorgt für den Verbindungsaufbau und -abbau (Sockets). Ermöglicht nötige Datentransformation.
7. Anwendungsschicht (Application Layer):
   Auf der Anwendungsschicht spielt sich der Dienst ab, welcher vom Benutzer wahrgenommen wird. Der Dienst wird vom Betriebssystem oder einer anderen höheren Software angeboten und mit ihm bieten sich indirekt die Protokolle eins bis sechs des OSI-Referenzmodells an. Verteilte Anwendungen werden über die Anwendungsschicht gekoppelt. Die Anwendungsschicht ist die höchste Ebene und fungiert daher auch als die Schnittstelle zwischen Mensch und Computer-Netzwerk.

Jede Schicht verrichtet ihren Dienst für die nächst höhere Schicht. So wurden Protokolle auf der Anwendungsschicht geschrieben (z. B. File Transfer Protokoll – FTP), welche sich nur auf die Verwendung der Daten innerhalb des Betriebssystems konzentrieren und dabei viele weitere Protokolle auf den unteren Schichten nutzen (z. B. TCP, IP, Ethernet).

Das OSI-Modell ist ein theoretisches Modell. Die sieben Schichten bedeuten keinesfalls, dass auch genau für jede Schicht ein eigenes Protokoll existiert. Viele Protokolle verrichten ihre Dienste übergreifend über mehrere Schichten des OSI-Modells.

Die Schichten 1 bis 4 sind die transportorientierten, von 5 bis 7 die anwendungsorientierten Schichten des OSI-Modells.

Das OSI-Referenzmodell ist Grundlage für die Netzwerkkommunikation. Jedoch nicht alle Netzwerkgeräte interpretieren Datenpakete bis zur letzten Schicht. Im Gegenteil, denn bis zur Anwendungsschicht werden Daten grundsätzlich nur von Geräten interpretiert, die auch über eine Ein- und Ausgabefunktion verfügen und direkte Schnittstelle zum Menschen sind.

Wenn eine Nachricht von einem PC über ein Netzwerk, z. B. mit typischen Übermittlern wie Hub, Switch und Router, zu einem anderen Netzwerk übertragen wird, dann wird auf jenen Übermittlern die Nachricht bis zur Vermittlungsschicht interpretiert. Die ersten drei Schichten dienen nur der Datenübertragung von Punkt zu Punkt, ohne Weitsicht zum Empfänger.  Die Schichten von vier bis sieben sind Ende zu Ende orientiert. Dies bedeutet, dass die Nachricht in der Theorie die Anwendungsschicht (Interpretation durch eine höhere Software) erst beim Empfänger-PC erreicht.

Dennoch sollte es ein Benutzerhandbuch geben, welches alle Funktionen verständlich und ausführlich beschreibt, jedoch den Nutzen jeder Funktion auf  den Punkt bringt. Für das richtige Schreiben des Benutzerhandbuchs gibt es eine  Reihe eigener Regeln für Struktur, Sprache und Technik. In Deutschland ist das Fehlen eines verständlichen und vollständigen Handbuchs sogar als ein Mangel nach dem BGB zu sehen.

Fern ab vom Handbuch, sollte die Software selbst jedoch selbstbeschreibungsfähig sein, denn dies gewährleistet den flexiblen Einsatz der Software.

Probleme durch falsche Bedienung sowie auch Programmfehler sollen durch Dialoge angezeigt und erklärt werden, zudem sollen nach Möglichkeit Lösungswege vorgeschlagen werden. Dabei ist auf eine Sprache zu achten, die an die Zielgruppe des Programms angepasst ist, in jedem Fall aber klar formuliert, ohne Rechtsschreib- und Grammatikfehler (diese stellen nicht nur die Software-Qualität in Frage, sondern könne auch für sprachliche Mehrdeutigkeiten sorgen).

Die Benutzeroberfläche ist dann nicht selbstbeschreibungsfähig, wenn Funktionen sowie der funktionale Zusammenhang ganz oder teilweise unverständlich ist. Wenn dazu noch keine weiterführenden Informationen (z. B. als Hilfe, FAQ etc.) abgerufen werden können, ist die Software bei entsprechender Komplexität quasi nur noch für an der Entwicklung beteiligten Experten bedienbar und somit weder wirtschaftlich noch flexibel einsetzbar.
Der Benutzer muss sich über den Funktionsumfang und den aktuellen Systemzustand informieren können, diese Informationen müssen ihm leicht zugängig sein. Es ist für den optimalen Softwareeinsatz außerdem unabdingbar, dass der Benutzer sich leicht über den Programmvorgang leicht verständlich und schnell erfassbar in Kenntnis gesetzt wird. Beispielsweise ist es sehr ärgerlich, wenn das Programm auf Parameter wartet, der Benutzer dieses jedoch gar nicht weiß und den Programmfortschritt abwartet.

Die Software soll Rückmeldungen an den Benutzer geben können und darüber informieren, wie das Ergebnis erreicht wurde (Prozesse) bzw. auftretende Probleme erläutern.

Um Routinetätigkeiten jedoch nicht unnötig auszubremsen, sollte der Informationsgrad jedoch vom Benutzer bis zu einem verantwortbaren Bereich einschränkbar sein.

Die Fehlerrobustheit betrifft sowohl die Zuverlässigkeit der Arbeitsergebnisse (Berechnungen) als auch der Zuverlässigkeit der Software selbst (Software-Stabilität).

Eine zu lange Zahl oder Zeichenkette oder Daten, welche in einem anderen Format erwartet wurden, können das Arbeitsergebnis unbrauchbar machen oder gar zum Programmabsturz führen.

Wird eine Zahl beispielsweise vom Typ Integer erwartet, ist das Eingabefeld auf die richtige maximale Länge zu begrenzen und zu prüfen, ob die Eingabedaten tatsächlich nur Zahlen (und nicht etwa Sonderzeichen oder Buchstaben) enthalten. Wird ein Datum erwartet, ist nicht nur die richtige Länge zu begrenzen, sondern auch ein (möglichst gängiges) Format zu definieren und auf Einhaltung zu prüfen.

Fehler können bei jeder Eingabe durch den Benutzer aus Unwissenheit, Unerfahrenheit, Missgeschick oder Unaufmerksamkeit erfolgen. Es gilt daher, dem Benutzer niemals zu vertrauen, sondern alle Eingaben auf Fehlerfreiheit zu überprüfen. Der Benutzer wird diese kritische Einstellung gegenüber seinen Eingaben mit Vertrauen in die Programmzuverlässigkeit würdigen.

Ein weiterer Aspekt ist die gezielte Ausnutzung eines Fehlers (SQL-Injection, gezielte Herbeiführung eines Buffer-Overflows für Exploits u.a.), welche durch Fehlerrobustheit so weit wie möglich erschwert werden soll.

Fehlerhafte Eingaben müssen korrigierbar sein. Trotz fehlerhafter Eingaben muss das beabsichtigte Arbeitsergebnis nur mit geringem oder besser gar keinem Korrekturaufwand (durch selbstständige Fehlerkorrektur) erreicht werden können.

Der Benutzer soll auf Fehler hingewiesen und zur Korrektur aufgefordert oder ihm diese empfohlen werden. Fehlermeldungen sowie Korrekturaufforderungen müssen verständlich, sachlich und konstruktiv formuliert und logisch, aber leicht nachvollziehbar strukturiert sein (abhängig von der Komplexität und vom zu erwartenden Kenntnisstand der Benutzer, können “logisch” und “nachvollziehbar” zwei gegensätzliche Adjektive sein!).

Eine selbstständige Fehlerkorrektur durch das System gilt als kritisch und sollte dem Benutzer angezeigt werden, so dass er die Korrektur bestätigen oder ggf. abändern kann.

Zur Fehlermeldung gehören Fehlererkennung, wo ein Fehler auftrat, warum er auftrat (Erklärung eines kausalen Zusammenhangs) sowie ggf. Empfehlungen zur zukünftigen Fehlervermeidung.

Durch sinnvolle Gestaltung der Mensch-Maschine-Schnittstelle (Fehlerprävention) durch sinnvolle Strukturierung, Benennung, Beschriftung und weiterführenden Informationen, soll das Auftreten von Fehlern bereits von vorne herein unwahrscheinlich werden. So sollte das richtige Format z. B. für ein Datum oder eine Telefonnummer vorgegeben werden (idealerweise mit Beispiel), bestenfalls aber kann der Benutzer sofort an Hand der Eingabefeldgestaltung das zu verwendende Format erkennen.

Bei der Software-Entwicklung ist ein systemeigenes Fehlermanagement zu überlegen. Ein solches Fehlermanagement soll negative Auswirkungen (z. B. Zeitverlust) von Fehlern begrenzen. Dazu gehört u.a. die Reversibilität von
Fehlern (z. B. mit UNDO-Funktionen zum rückgängig machen von Eingabeschritten). Je komplexer die Software wird, desto schwieriger sind allerdings i.d.R. auch der Entwurf und die Implementierung einer Reversibilität.

Ist die Bereitstellung aller benötigten Informationen und Funktionen zur Erledigung einer vorbestimmten Aufgabe (z. B. die Erstellung von Textdokumenten oder CAD-Modellen) durch die Software nicht gegeben, so ist die Software nicht angemessen praktikabel und wenig benutzerfreundlich gestaltet.

Der Benutzer soll (durch Tipps und Empfehlungen) von der Software über Informationen und Zustände informiert und unterstützt, jedoch möglichst nicht genervt werden. Dies wird mit einem Dialogsystem (vom kleinen Hinweis in der Statusanzeige bis hin zum Piepton begleitetem Fenster-Dialog) erreicht, wobei sich die Software Einstellungen (Kenntnisnahmen und Prioritäten wie Sicherheitsstufen / Warnlevel) merken muss. Wurde eine immer wieder auftauchende Information vom Benutzer zur Kenntnis genommen, soll dieser Benutzer den Hinweis auf diese Information deaktivieren können (deaktivierfähige Hinweise sind beispielsweise Tipps über die Software beim Start der Software oder bei Ausführen einer bestimmten Aktion z. B. dass eine Datei vor dem öffnen automatisch konvertiert und als temporäre Datei abgespeichert wird).

Äußerst wichtige Hinweise, insbesondere die, welche bei Unaufmerksamkeit zu Datenverlust oder schlimmeren führen können, sind jedoch von der Deaktivierfähigkeit auszuschließen. Ein Beispiel: Wird die Anwendung geschlossen, gehen nicht gespeicherte Änderungen verloren. Der Hinweis auf diese Tatsache sollte nicht automatisch umgangen werden können, es ist aber automatisch sicherzustellen, dass der Hinweis nur erscheint, wenn wirklich Änderungen nach dem letzten Speichern vorgenommen wurden.

Aufgaben, die aus der technischen Eigenheit der Software und des Systems erwachsen und aus denen keine kritischen Zustände entstehen können, sollen durch das System eigenständig ausgeführt werden (z. B. Zwischenspeicherung, Überprüfung von sowie Hinweis über Systemkomponenten und Kompatibilität).

Verfügbare Funktionen der Software sollen an wiederkehrende Aufgabenstellungen angepasst werden können (z. B. durch Standardwertdefinierung, Abspeicherung von Profilen für unterschiedliche Zwecke).

Die Komplexität der Software, ihrer Funktionalität und die Aufgabe soll auf ein angemessenes Level reduziert werden
können. Der Benutzer soll nicht permanent mit Informationen überflutet werden, sondern sich auf das im Moment Wesentliche beschränken können. Elemente (Items) sollen logisch gruppiert, Ausschnitte gezoomt, Funktionsumfänge angepasst, dabei insbesondere beschränkt (z. B. wählbare Minimalinstallation, benutzerdefinierte Installation oder Ansicht) werden können.

Die Ergonomie hat ganz allgemein das Ziel, eine menschengerechte Arbeits-/Produktgestaltung und eine bestmögliche Mensch-Maschine-Schnittstelle zu erreichen und dauerhaft zu gewährleisten. Dies ist keinesfalls ein “Öko-Gedanke” oder eine Nebensächlichkeit, denn hier geht es um die Aufrechterhaltung der Arbeitsfähigkeit und letztendlich auch um eine Effizienz beim Umgang mit moderner Technik.

Bei der Software-Ergonomie trifft die Software-Entwicklung auf die Psychologie und Arbeitswissenschaft. Vielfach reicht schon gesunder Menschenverstand, um in ergonomischer Hinsicht gute Software zu entwickeln. Immerhin arbeiten Software-Entwickler auch mit moderner Software wie Entwicklungsumgebungen (beispielsweise MS Visual Studio), welche ebenfalls in Sachen Ergonomie mehrmals überdacht wurde (man Vergleiche die verschiedenen Versionen untereinander).

Der Software-Entwickler ist  jedoch nicht alleine dazu fähig, eine durch und durch ergonomische Software zu entwickeln, denn dieser konzentriert sich eher auf die Kernfunktion der Software und ist von seinem Produkt grundsätzlich überzeugt und, sofern Eindrücke von Dritten nicht zur Software-Entwicklung vermittelt werden, von Natur aus völlig verblendet. Der Software-Entwickler (dass er in einem Entwickler-Team beteiligt ist, macht es kaum besser) ist ein Profianwender seiner Software und wird sich weder gut in einen Anfänger, noch in tägliche Alltagsprobleme hineinversetzen können.

Es ist aus der Zielgruppe für eine Software auch eine Ergonomieebene abzuleiten. Beispielsweise arbeiten mit einem Betriebssystem wie Microsoft Windows oder Microsoft Word Benutzer jeglicher Gruppen, so auch absolute Anfänger, während sich für spezielle Entwicklungsumgebungen oder CAD-Software andere Gruppen ergeben, welche wahrscheinlich nicht mehr darauf hingewiesen werden wollen, dass die Software automatische Zwischenspeicherungen vornimmt. Diese Zielgruppen verbringen unterschiedlich lange Zeitspannen mit der Software, haben unterschiedliches Vorwissen und Auffassungsgaben.

Die DIN ISO 9241 ist eine internationale Norm, welche für die Gestaltung von  Software (neben Hardware und der Arbeit mit IT-Systemen) -Ergonomievorgaben festsetzt und beachtet werden sollte. In der DIN ISO 9241-110 werden Grundsätze der Gestaltung von Dialogen in der Software definiert. Die Norm legt Grundsätze für eine Dialoggestaltung fest und ist somit von nicht geringer Bedeutung in der Software-Entwicklung, insbesondere, wenn es um die Windows-Programmierung geht.

Einige Grundsätze in der Dialoggestaltung in der Software-Entwicklung:

• Erlernbarkeit (Suitability for learning)
• Selbstbeschreibungsfähigkeit (Self-descriptiveness)
• Fehlerrobustheit (Error tolerance)
• Aufgabenangemessenheit (Suitability for the task)