kopf
brlogo
fensterobenrechts
   
fensteruntenblau
   
 

 

Änderungen in den Vorgaben zu den unterrichtlichen Voraussetzungen für die schriftlichen Prüfungen im Abitur in der gymnasialen Oberstufe im Jahr 2012 und 2013 gegenüber den Vorgaben für 2011

Zusammengestellt von: Andrea Bohlen

 

Vorbemerkung

Dieses ist keine amtliche Information, sondern der Versuch der Informatik-Treff-Redaktion, den Zugang zu den Änderungen in den neuen Vorgaben zum Zentralabitur NRW ein wenig zu begleiten und zu erleichtern. Der hier präsentierte Inhalt ist jedoch mit der Fachaufsicht der Bezirksregierung Düsseldorf abgesprochen.

Für die amtlichen und damit verbindlichen Vorgaben siehe:

http://www.standardsicherung.schulministerium.nrw.de/abitur-gost/fach.php?fach=15

 

Quellen:


1. Vorgaben

Vorgaben zu den unterrichtlichen Voraussetzungen für die schriftlichen Prüfungen im Abitur in der gymnasialen Oberstufe im Jahr 2012  

http://www.standardsicherung.nrw.de/abitur-gost/fach.php?fach=15

 

2. Materialien

Materialien zu den zentralen Abiturprüfungen im Fach Informatik ab 2012 Java:

http://www.standardsicherung.nrw.de/abitur-gost/fach.php?fach=15

Entsprechende Materialien gibt es an gleicher Stelle auch für das Sprachkonzept Delphi.

 

3. Präsentation

PowerPoint-Präsentation und Vortrag auf dem Fachworkshop Informatik auf der Fachtagung Zentralabitur 2012 am 22.03.2011 von Klaus Dingemann (Bezirksregierung Münster) und Jan Vahrenhold (Technische Universität Dortmund); unveröffentlicht

 

1.  Grundlegende Änderungen

 

In I.1  Konzepte des objektorientierten Modellierens ist das Geheimnisprinzip hinzugekommen.

„Hat-Beziehung, Kennt-Beziehung und Ist-Beziehung“ wurde ersetzt durch Beziehungen zwischen Klassen: (Gerichtete) Assoziation mit Multiplizität, Vererbung (siehe hierzu auch die neuen Materialien und die Erläuterungen dazu).

Unter I.2  ist präzisiert worden, dass Such- und Sortierverfahren auf Feldern und Listen im Unterricht zu behandeln sind.

Statt „geordneter Baum“ wird nun der Begriff Binärer Suchbaum verwendet.

Die Unterpunkte zu den ungerichteten, gewichteten Graphen sind um den Punkt Breiten- und Tiefensuche ergänzt worden.

Im Bereich der Datenbanken werden nun auch Vereinigung, Differenz, kartesiches Produkt und Umbenennung explizit genannt.

Im Bereich der endlichen Automaten und formalen Sprachen sind deterministische, endliche  Automaten gemeint sowie reguläre Sprachen und ihre Grammatiken.

 

2.  Einige Hinweise zu den Materialien zu den zentralen Abiturprüfungen im Fach Informatik ab 2012

 

Diese Hinweise basieren auf Informationen aus dem Fachworkshop Informatik auf der Fachtagung Zentralabitur 2012 am 22.03.2011 und dem entsprechenden pdf-Dokument von Klaus Dingemann (Bezirksregierung Münster) und Jan Vahrenhold (Technische Universität Dortmund).

 

Klassendiagramme

 

Aufgrund vieler in der Vergangenheit aufgetretener Missverständnisse und Unklarheiten in Bezug auf Klassendiagramme wird diesen in den neuen Materialien ein ganzes Kapitel gewidmet.

Ein Klassendiagramm einer einzigen Klasse (früher auch als Klassenkarte bezeichnet) enthält den Klassennamen, sowie (optional) Attribute und Methode.

Die Angabe der Typen erfolgt sowohl bei Attributen, Methoden als auch Parametern in der UML-Notation: <Name>:<Typ>.

(Quelle: Präsentation S. 23)

 

Sichtbarkeit

Die Sichtbarkeit von Methoden oder Variablen wird durch  + (public)  und  - (private)  gekennzeichnet.

(Quelle: Präsentation S. 23)

 

Abstrakte Klassen

Abstrakte Klassen werden durch den Zusatz  {abstract} gekennzeichnet. Die Namen abstrakter Methoden werden kursiv geschrieben oder mit einer Wellenlinie unterstrichen. (Letzteres ist nötig, wenn das Klassendiagramm handschriftlich erstellt wird.) Die „normale“ Unterstreichung mit einem geraden Strich darf hierfür nicht verwendet werden, da diese im UML-Standard  static  bedeutet.

Wenn eine Klasse mindestens eine abstrakte Methode hat, ist die Klasse abstrakt. Umgekehrt kann jedoch eine Klasse, die abstrakt, ist auch Methoden haben, die nicht abstrakt sind.

(Quelle: Präsentation S. 23)

Dies ist ein Implementationsdiagramm einer abstrakten Klasse:

Implementationsdiagramm einer abstrakten Klasse

(Quelle: Präsentation S. 23)

 

Unterscheidung zwischen Entwurfs- und Implementationsdiagrammen

Unterschieden wird zwischen Entwurfs- und Implementationsdiagrammen. Dies liegt daran, dass in der Vergangenheit Unstimmigkeiten aufgetreten sind. Zum Beispiel:

 

ein Versuch eines Klassendiagramms

(Abbildung und Frage aus: Präsentation S. 28 (Folie20))

 

Unstimmig ist hierbei unter anderem die Assoziation der Klasse List . Die Klasse List verwaltet Objekte vom (allgemeinen) Typ Object, nicht (nur) vom Typ Spielkarte. Auch die Erläuterungen zu diesem Diagramm in den Materialien zum Zentralabitur 2007  sind an mehreren Stellen nicht ganz richtig.

Ein weiteres Problem liegt daran, dass durch die Multiplizität an dem Assoziationspfeil der Klasse Spielkartenpaeckchen zur Klasse Spielkarte schon deutlich wird, dass die Klasse Spielkartenpaeckchen mehrere Objekte der Klasse Spielkarte verwaltet, aber trotzdem noch gewünscht wird, dass im Klassendiagramm deutlich werden soll, dass diese Assoziation mit Hilfe eines Objekts der Klasse List implementiert werden soll.

Um dies zu ermöglichen, wird nun mit Hilfe der Unterscheidung zwischen Entwurfs- und Implementationsdiagramm die Entwurfs- und Implementationsebene klarer getrennt. Ein Entwurfsdiagramm stellt die Konzeption dar, während in Implementationsdiagrammen ein  konkreter Bezug zur Implementation deutlich wird. 

(Quelle: Präsentation S. 30)

 

Entwurfsdiagramm:

ein Entwurfsdiagramm

(Abbildung Quelle: Präsentation S.31 (Folie 23))

 

In Entwurfsdiagrammen werden die Basisdatentypen Zahl , Text und Wahrheitswert verwendet. Zahl schließt dabei (im Gegensatz zu Integer des UML 2.0 -Standards) ein, dass Datentypen verwendet werden können, die Zahlen mit Nachkommastellen repräsentieren.  Auf einen Typ UnlimitedNatural (natürliche Zahlen und Unendlich) wird bewusst verzichtet.

Der Datentyp Datenansammlung ist eine didaktische Reduktion der UML-Notation. Auf die Untersuchung, ob eine lineare Ordnung vorliegt (ordered) und/oder die gespeicherten Elemente eindeutig sind (nonunique/unique), kann dadurch verzichtet werden.

(Quelle: Präsentation S. 31-33)

 

Implementationsdiagramm:

ein Implementationsdiagramm

(Abbildung Quelle: Materialien S. 7)

 

„Erläuterung:

Bezeichner der Attribute, durch die die Assoziationen realisiert werden, stehen an den Pfeilen.

Objekte der Klasse Stack verwalten Objekte der Klasse Object.

Der Kommentar an der Klasse Stack verdeutlicht, welche Inhaltsobjekte im Stack hier verwendet werden sollen.

Das Rechteck um das Klassendiagramm zeigt an, dass alle Klassen im gleichen Namensraum liegen.“

(Quelle: Materialien S. 7)

Im Implementationsdiagramm werden konkrete Umsetzungsvorgaben dargestellt. Es werden programmiersprachenspezifische Basisdatentypen verwendet und es wird dargestellt, welche konkreten Strukturen verwendet werden sollen.

(Quelle: Präsentation S. 41)

Bei dem in den Abbildungen dargestellten Beispiel wurde die Modellierung im Implementationsdiagramm  zusätzlich um Konstruktoren und Selektoren erweitert.  

(Quelle: Präsentation S. 35)

 

Kritisierbar an diesem Beispiel aus den Materialien für das Zentralabitur 2012 ist (nach Dingemann und Vahrenhold), dass die Speicherung der Bewertung redundant ist:  Ein Objekt der Klasse Leistungsueberpruefung speichert die Note als Text, ein Objekt der Klasse Klausur speichert sie zusätzlich als Zahl. Um die Redundanz zu entfernen und die Vererbungsbeziehung beizubehalten, wird eine Methode zur Umrechnung benötigt, die von Objekten der Klasse Klausur genutzt werden kann. Eine andere Möglichkeit wäre eine Generalisierung von Leistungsueberpruefung und Klausur in Form einer abstrakten Oberklasse.

(Quelle: Präsentation S. 38)



Felder von Objekten (Arrays)

In den Materialien für das Zentralabitur 2012 findet sich der folgende Satz:

„Für die im Entwurfsdiagramm angegebenen Datensammlungen werden konkrete Datenstrukturen gewählt, deren Inhaltstypen in Form von Kommentardiagrammen angegeben werden.“

(Quelle: Materialien S. 7)

 

Felder von Objekten spielen hier jedoch eine Sonderrolle:

Die Schreibweise  – auto: Auto [ ] als Bezeichner für ein Array  auto von Objekten der Klasse  Auto in einer „Klassenkarte“, dem Diagramm einer Klasse (zum Beispiel einer Klasse Autoparkplatz) ist nach wie vor gültig.
Wenn die Klasse Auto explizit dargestellt wird, wird man im Entwurfsdiagramm (statt dem Attribut „auto“ im Klassendiagramm der Klasse  Autoparkplatz) einen Assoziationspfeil zur Klasse  Auto mit entsprechender Multiplizität angeben. Wenn die Klasse Auto oder die Beziehung zwischen den Klassen Autoparkplatz und Auto im Diagramm vernachlässigt werden soll, kann man auch auf das Klassendiagramm der Klasse Auto und den Asssoziationspfeil dorthin verzichten und stattdessen im Klassendiagramm (der "Klassenkarte") der Klasse Autoparkplatz das Attribut auto vom Typ Datenansammlung < Auto > angeben. (s.u. (Absatz Assoziationen)) Bei Datenansammlungen wird der Typ der einzelnen Daten in spitzen Klammern angegeben.

Im Implementationsdiagramm ist dagegen das (mehrwertige) Attribut „auto“ nicht als Assoziationspfeil darzustellen, auch wenn das Implementationsdiagramm ein Klassendiagramm der Klasse  Auto  enthält. Denn  Auto [ ]  kann nicht als Klasse dargestellt werden, weil Auto [ ]  kein zulässiger Klassenname ist, und ein Assoziationspfeil mit der Aufschrift  Auto [ ]  ist nicht richtig, weil der Name der Assoziation nicht  Auto [ ]  ist.

Felder werden also anders als Listen behandelt. Sie werden in gewisser Weise wie „eingebaute Datentypen“ betrachtet und somit (wie Attribute vom Typ String ) nicht über einen Assoziationspfeil modelliert.

(Quelle: email von Prof. Dr. Jan Vahrenhold vom 18.11.2011)

 

Beispiel:

ein Implementationsdiagramm der Klassen Auto und Autoparkplatz

Zwei Möglichkeiten für ein Entwurfsdiagramm der Klassen Auto und Autoparkplatz

 

Neue Aufgabentypen

Im Zusammenhang mit der Trennung zwischen Entwurfs- und Implementationsdiagramm liegen neue Aufgabentypen nahe, z. B.:

  • Die Umwandlung eines Entwurfsdiagramms in ein Implementationsdiagramm. Das Entwurfsdiagramm ist programmiersprachenunabhängig. Durch die Festlegung der Modellierung wird die Korrektur vereinfacht. Es besteht die Möglichkeit den Anforderungsbereich III abzudecken, z.B. indem eine Begründung der Entscheidung für eine konkrete Struktur verlangt wird.

  • Rekonstruktion eines Entwurfsdiagramms aus einem Implementationsdiagramm als Abstrahierung von einer programmiersprachlichen Realisierung.

  • Vergleich alternativer Entwurfs- und Implementationsentscheidungen. (Möglichkeit, den Anforderungsbereich III abzudecken.)

(Quelle: Präsentation S. 43)

 

Beziehungen zwischen Klassen

 

Assoziation  

 

ein Assoziationspfeil

 

Eine Assoziation (bisher in Schulen des Landes NRW oft als „kennt-Beziehung“ oder als „hat-Beziehung“ bezeichnet) ist eine semantische Beziehung zwischen Objekten (1) der beteiligten Klassen. Ein Objekt der einen Klasse kann ein Objekt der anderen Klasse verwalten.

Die Darstellung einer gerichteten Beziehung erfolgt durch einen Pfeil, optional mit Namen. Falls nur eine Linie ohne Pfeilspitze gezeichnet wird, bedeutet dies, dass eine bidirektionale Beziehung vorliegt.

Bezeichner der Attribute, mit denen Assoziationen realisiert werden, werden nur dann in der „Klassenkarte“, dem Klassendiagramm einer Klasse, aufgeführt, wenn die Assoziation nicht durch einen Assoziationspfeil angegeben wird. Dies kann der Fall sein, wenn die Klasse, zu der eine Assoziation besteht, nicht als „Klassenkarte“ dargestellt wird, z.B. weil sie im Kontext als unwichtig angesehen wird.

Beispiel (Implementationsdiagramm):

ein Implementationsdiagramm mit dem Namen eines Attributs auf einem Assoziationspfeil

oder, falls die Klassen Klausur und Leistungsueberpruefung nicht explizit dargestellt werden sollen:

Implementationsdiagramm ohne Assoziationspfeil


In den Entwurfsdiagrammen werden an den Assoziationspfeilen Multiplizitäten angegeben.( z. B. 1,   0..1 ,   0..* oder   1..* ). Eine fehlende Multiplizität ist als  0..*  zu lesen.

Multiplizitäten der Form  2..5  dürfen, müssen aber nicht verwendet werden.

Multiplizitäten an der Seite einer gerichteten Assoziation, von der diese ausgeht, sind ausdrücklich nicht Bestandteil der Vorgaben. Da eine entsprechende technische Realisierung anspruchsvoll ist, wird sogar davon abgeraten, eine Multiplizität an dieser Seite einer Assoziation zu verwenden.

Kompositionen (früher oft als „hat-Beziehung“ bezeichnet) sind spezielle Assoziationen, bei denen eine existentielle Abhängigkeit der Teile vom Ganzen besteht. Kompositionen dürfen weiterhin im Unterricht thematisiert werden. Für das Zentralabitur ist eine Unterscheidung zwischen Komposition und Assoziation, die aber keine Komposition ist, nicht nötig.

Ähnlich den Assoziationen in Klassendiagrammen werden im Bereich Datenbanken  in ER-Modellen gleichartige Beziehungen zwischen Entitäten zweier Entitätsmengen zu Beziehungsmengen zusammengefasst.

(Quelle: Präsentation S. 24-27)

 

(1)  Ergänzung zur Frage, ob es hier um Objekt- oder Klassenbeziehungen geht:

aus Heide Balzert: „Lehrbuch der Objektmodellierung, Analyse und Entwurf mit der UML 2“, 2.Auflage,München 2005, S.42: „Zwischen den Objekten von Klassen können Objektbeziehungen …existieren. Will man alle gleichartigen Objektbeziehungen zwischen Klassen beschreiben, so benötigt man das Konzept der Assoziation. So wie es sich bei den Objekten um Exemplare einer Klasse handelt, sind die Objektbeziehungen als Exemplare einer Assoziation aufzufassen. “

 

Vererbung

 

ein Vererbungspfeil

 

Die Vererbung beschreibt die Beziehung zwischen einer allgemeineren Klasse (Oberklasse) und einer spezialisierten Klasse (Unterklasse). Die Unterklasse stellt alle öffentlichen Attribute und alle nicht überschriebenen öffentlichen Methoden der Oberklasse zur Verfügung.

In der Unterklasse können Attribute und Methoden ergänzt oder auch überschrieben werden.“

(Quelle: Materialien S. 6)

Die Vererbung ist früher oft als „ist-Beziehung“ bezeichnet worden.

 

 

Lineare Strukturen und Baum-/Graphenstrukturen

 

Es wurde darauf geachtet, dass in den Materialien bzw. den zur Verfügung gestellten Implementationen jeweils mindestens eine Datenstruktur rekursiv (Klasse BinaryTree) und mindestens eine Datenstruktur nicht-rekursiv (Klasse List) definiert wird. 

(Quelle: Präsentation S. 5)

 

Klassendokumentationen

Die Klassen für lineare Strukturen und Baum-/Graphenstrukturen sind nun möglichst implementationsunabhängig dokumentiert. Vor- und Nachbedingungen werden nicht mehr ausgewiesen.

(Quelle: Präsentation S. 5)

 

Änderungen der Klasse List

gegenüber den Materialien zu den zentralen Abiturprüfungen von 2010

 

Die Klasse List verfügt nun über folgende Methoden:

 

Anfragen:

boolean isEmpty ( )

boolean hasAccess ( )

Object  getObject ( )

 

Aufträge (zur Navigation):

void next ( )

void toFirst ( )

void toLast ( )

 

Aufträge (Ändern der Liste):

void setObject (Object pObject)

void append (Object pObject)

void insert  (Object pObject)

void concat  (List pList)

void remove ( )

   

Damit kann man ein Objekt der Klasse List nun als einfach verkette Liste ansehen.

Die Klasse List verfügt über weniger Methoden, so dass sie übersichtlicher ist und veränderte Aufgaben möglich sind.

Die Methodenbezeichner wurden angepasst (an die möglichst implementationsunabhängige Dokumentation).

Die Funktionalität der Methoden hat sich leicht verändert.

(Quelle: Präsentation S. 8)

 

Die Methode hasAccess ( ) dient zur Prüfung, ob ein Zugriff an der aktuellen Listenposition möglich ist, und bietet die Möglichkeit eines vollständigen Listendurchlaufs ohne eine Sonderbehandlung des letzten Listenelements.

 

liste1.toFirst ( );

while (liste1.hasAccess ( )) {

   // …

  liste1.next ( );

}

(Quelle: Präsentation S. 10)

 

Die Klasse BinaryTree (statt BinTree)

Durch die Namensänderung soll die binäre Eigenschaft des Baums betont werden.

In der Beschreibung der Klasse werden BinaryTrees rekursiv definiert.

Bei der Beschreibung der Klasse wurde der Begriff  „Wurzel“ nicht verwendet, da dieser formal korrekt unter Verwendung von Konzepten aus der Graphentheorie definiert werden müsste. (Eine informelle Verwendung des Begriffs ist im Unterricht zulässig, jedoch keine Voraussetzung für das Zentralabitur.)

Daher wurden auch zwei Methodennamen verändert: setObject (…) statt setRootItem ( …) und getObject ( ) statt getRootItem ( ) .

(Quelle: Präsentation S. 11-12)

 

Skizze eines binären Baums

 

Die Klasse BinarySearchTree (statt OrderedTree)

Durch den neuen Namen liegt die Betonung nun darauf, dass es sich um Binärbäume mit einer Suchfunktion handelt.

Die zusätzlichen Methoden getItem ( ), getRightTree ( ) und getLeftTree ( ) ermöglichen eine Traversierung des Baums.

Die Methode getSortedList ( ) steht nicht mehr zur Verfügung.

Einige Methodenbezeichnungen sind verkürzt worden: insert(…) statt insertItem(…), search(….) statt searchitem(…) und remove(…) statt removeItem(…).

(Quelle: Präsentation S. 13)

 

 Änderungen der Klasse Graph

Die Dokumentation ist nun unabhängig von der Implementation.

Auf eine Klasse Edge wird verzichtet.

Damit entfallen in der Klasse GraphNode die Methoden insertEdge ( …) und edges ( ) .

Die Methode zum Erfragen des Namens eines Knotens wurde umbenannt in getName ( ) (statt name ( ) ).

(Quelle: Präsentation S. 14)

 

Die Klasse Graph verfügt nun über folgende Methoden:

 

Anfragen:

boolean isEmpty ( )

boolean hasNode (String pName)

boolean hasEdge (GraphNode pNode1, GraphNode pNode2)

boolean allNodesMarked ( )

GraphNode getNode (String pName)

double getEdgeWeight (GraphNode pNode1, GraphNode pNode2)

List getNodes ( )

List getNeighbours (GraphNode pNode)

 

Aufträge:

void addnode (GraphNode pNode)

void addEdge (GraphNode pNode1, GraphNode pNode2)

void removeNode (GraphNode pNode)

void removeEdge (GraphNode pNode1, GraphNode pNode2)

void resetMarks ( )

(Quelle: Präsentation S. 15-17)


Materialien zu Automaten und Grammatiken

 

Übergangsdiagramm eines einfachen endlichen Automaten

 

Die Materialien wurden um ein Kapitel zu dem Bereich „Endliche Automaten und formale Sprachen“ ergänzt. Hier erfolgen inhaltliche und sprachliche Präzisierungen, sowie Beispiele.

(Quelle: Präsentation S. 20)

Ein deterministischer, endlicher Automaten wird durch ein 5-Tupel (Eingabealphabeth, Zustandsmenge, Zustandsübergangsfunktion, Anfangszustand und Menge der Endzustände) definiert, eine Grammatik als 4-Tupel (Menge der Nichtterminalsymbole, Menge der Terminalsymbole, Startsymbol und Menge der Regeln).

(Quelle: Materialien S.31-32, Präsentatiion S.20)

 

Ergänzung der Materialien für den Bereich Datenbanken

 

Durch Definitionen, Beschreibungen, Erläuterungen und Beispiele zu Entity-Relationship-Modellen, Datenbankschemata und Schlüssel, Normalisierungen sowie der Relationenalgebra (Selektion, Projektion, Vereinigung, Differenz, kartesisches Produkt, Umbenennung und Join) werden die Vorgaben präzisiert. Darstellungsformen werden vorgegeben und durch Beispiele veranschaulicht.

Neu hinzugekommen sind die Datenbankoperatoren Vereinigung, Differenz und Umbenennung.

(Quelle: Präsentation S. 21, Materialien S. 24-30)

 

Vorausgesetzt werden nun folgende SQL-Sprachelemente:

SELECT (DISTINCT) … FROM

WHERE

GROUP BY

ORDER BY

ASC, DESC

(LEFT / RIGHT) JOIN … ON

UNION

AS

NULL

Vergleichsoperatoren: =, <>, >, <, >=, <=, LIKE, BETWEEN, IN, IS NULL

Arithmetische Operatoren: +, -, *, /, (…)

Logische Verknüpfungen: AND, OR, NOT

Funktionen: COUNT, SUM, MAX, MIN

 

Es werden SQL-Abfragen über eine und mehrere verknüpfte Tabellen vorausgesetzt.

Es können auch verschachtelte SQL-Ausdrücke vorkommen.“

(Quelle: Materialien S. 27)

 

In eigener Sache: Wir hätten an dieser Stelle natürlich gerne die gesamte Präsentation veröffentlicht. Das ist jedoch aus urheberrechtlichen Gründen leider nicht möglich.

 

 
 
Friday, 15. December 2017 / 07:25:31