\documentclass{schullsg}
\usepackage[utf8]{inputenc}
\usepackage{schulinf}

% Dieses Dokument ist in der Zusammenarbeit von Informatikreferendaren und
% ehemaligen Informatikreferendaren der Studienseminare (heute ZfsL) Arnsberg,
% Hamm und Solingen entstanden.
%
% Das Dokument steht unter der Lizenz: Creative Commons by-nc-sa Version 4.0
% http://creativecommons.org/licenses/by-nc-sa/4.0/deed.de
%
% Nach dieser Lizenz darf das Dokument beliebig kopiert und bearbeitet werden,
% sofern das Folgeprodukt wiederum unter gleichen Lizenzbedingungen vertrieben
% und auf die ursprünglichen Urheber verwiesen wird.
% Eine kommerzielle Nutzung ist ausdrücklich ausgeschlossen.
%
% Die Namensnennung durch einen Verweis und die Lizenzangabe der ursprünglichen
% Urheber auf den Materialien für Schülerinnen und Schüler ist erforderlich.
%
% Die Sammlung der Dokumente steht unter
% http://ddi.uni-wuppertal.de/material/materialsammlung/
% zur Verfügung.
%
% Das LaTeX-Paket zum Setzen der Dokumente der Sammlung steht
% unter  http://www.ctan.org/pkg/schule
% zur Verfügung.

\usepackage[pdfauthor={Referendare der Informatikfachseminare Arnsberg, Hamm und Solingen}]{hyperref}
\includexmp{lizenz}
\cclizenz{byncsaeu}
\footerQRLink{materialsammlung_qr_url.pdf}

\svnid{$Id: erlaeuterung_loesung.tex 1350 2015-11-09 10:50:26Z humbert $}

\dokName{Chat}
\jahrgang{11}

\begin{document}

\section*{Modellierung zum Thema \enquote{Chats} -- Erläuterung der Diagramme zu einer möglichen Lösung}

Bei der Modellierung der Kommunikation mittels Chats können diverse Probleme auftreten, 
da es mehrere Wege gibt, das Problem sinnvoll zu modellieren.
Als Einstiegsproblem eignet sich das Thema \enquote{Chats} deshalb nicht, jedoch können
eventuell auftretende Mehrdeutigkeiten bei der Modellierung gut in einem Kurs mit fortgeschrittenen Schülerinnen und Schülern erörtert werden.

\section*{Objektdiagramm}
\begin{center}
  \includegraphics{chat_diagramme-1} 
\end{center}

\vspace{2ex}

Es ist offen, wie detailliert man den Vorgang der elektronischen Nachrichtenübermittlung modellieren will. Im obigen Beispiel für ein Objektdiagramm verfügen die handelnden Personen Svenja und Frederike über je ein Informatiksystem, auf welchem eine Chat-Client-Software ausgeführt wird, die mit dem zentralen ICQ-Server kommuniziert.
Denkbar ist es aber auch, weniger stark in die Tiefe zu gehen und stattdessen eine Black-Box-Sicht zu verwenden, welche die Details des Nachrichtenaustauschs kapselt.
Der Aufgabentext wäre dann dementsprechend abzuändern.

Es ist möglich, die Kommunikation mit dem Server so zu modellieren, dass sie nicht über die Client-Software abläuft, sondern von den Informatiksystemen abgewickelt wird. Eine solche Sichtweise orientierte sich eher an der Hardware (physikalische Verbindung des Geräts mit dem Internet), während die obige Lösung eine Software-Sicht darstellt (die Software öffnet einen Port zum Server).

Falls die Schülerinnen oder Schüler schon den Begriff des Protokolls kennen, ist fraglich, inwiefern dieses im Objektdiagramm zu berücksichtigen wäre.
Eine saubere Lösung dieses Problems wäre das Einführen einer Assoziationsklasse \enquote{Protokoll} für die Assoziation zwischen \enquote{ChatClientSoftware} und \enquote{ChatServer} im nachfolgenden Klassenprogramm. Es ist jedoch fraglich, ob man dieses fortgeschrittene UML-Gestaltungsmerkmal thematisieren möchte -- insbesondere im Anfangsunterricht.


\section*{Klassendiagramm}

\begin{center}
  \includegraphics{chat_diagramme-2}
\end{center}

\vspace{2ex}

Hat man die im obigen Klassendiagramm darsgestellten Klassen identifiziert, stellt man gegebenenfalls fest, dass im Objektdiagramm beim \enquote{icqServer} nicht spezifiziert wurde, ob man diesen als Hardware oder Software betrachtet. Gemäß Klassendiagramm (untere Assoziation \enquote{fuehrt aus}) handelt es sich um Software.
Hier wird das grundsätzliche Problem deutlich, dass im Alltag insbesondere der Begriff Server sowohl für einen Softwaredienst als auch für das Informatiksystem verwendet wird, auf welchem dieser Dienst läuft.

Bei den genannten Attributen und Methoden handelt es sich lediglich um Vorschläge.
Um die Freiheit der Modellierung seitens der Schülerinnen und Schüler nicht zu sehr einzuschränken, sollen hier keine zu engen Vorgaben gemacht werden, so sind hier etwa keine Argumente für die Methoden expliziert (um die Schnittstelle offen zu halten) und die in der UML üblichen Datentypangaben fehlen ebenfalls.

\end{document}
