FIAE Sommer06 GA1

[sg-sd]

So bevor wir jede Aufgabe als einzelnen Thread haben, würde ich sagen das wir einfach mal gemeinsam die GA1 Sommer 06 hier lösen.

Fang ich direkt mal mit Handlungsschritt 1 an:

a)

• Zuviel und teilweise falsche Anwendung der Schriftart
  
• Zuviele Farben max. 4 Farben
  
• keine strukturierung der Felder
  
• Hintergrund ist zu dunkel
  

// Ist aufjedenfall noch zu ergänzen, da das teilweise geraten ist.

Bei der Eingabemaske handelt es sich um eine Fälschung. Wenn der Benutzer in diese Maske die geforderten Dtaen eingibt, kann es bzw. wird es Ihm passieren, dass Betrüger an seine persönlichen Daten kommen. Dies ist daran zu erkennen da ein echter Angestellter der Post, niemals nach der Pinnummer und unbenutzten Tans fragen würde.

c)

Trojaner:

- Ist ein funktionsfähiges Programm, welches eine gewünschte Aufgabe kontrolliert ausführt. Erst durch spezifische Aktivierung wird die schädigende Programmwirkung aktiviert.

Virus:

- Viren produzieren sich selbst und erzeugen Schädigungen. Die Schädigungen können zeitlich begrenzt, aber auch dauerhaft sein. Die Wirkungen können von manipulierten Bildschirmausgaben bis zur Zerstörung von Softwareinhalten reichen.

Hoax:

- Ist eine Art Zeitungsente in elektronischer Form, es handelt sich um eine Falschmeldung, die per E-Mail oder auf anderen Weg verbreitet wird

Seit Ihr damit einverstanden?

[hdmonty]

1a. Grundsätze der Dialoggestaltung DIN EN ISO 9241-110 werden sträflich vernachlässigt:

Grundsätze der Dialoggestaltung DIN EN ISO 9241-110

Ich würde dann noch ergänzen:

• Keine Information erkennbar, wie z.B. Köpergröße(in cm oder m) oder Gewicht(g oder kg) eingegeben werden soll.
  

• Nicht erkennbar, ob es Pflichtfelder gibt.
  

• Steuerbarkeit nicht erkennbar
  

• Das ist offensichtlich eine Phishingmail, in der sich jemand die Zugangsdaten zum Konto ergaunern möchte.
  

• Füllt der Empfänger diese Maske aus, wird wahrscheinlich sein Konto leer geräumt.
  

Also:

• Auf jeden Fall nichts anklicken, am besten nicht mal öffnen.
  

• Der Empfänger sollte diese Mail auf jeden Fall löschen.
  

• Ein Prüfung, ob die Mail von der Bank kommt, kann man sich sparen, denn Banken verschicken solche Mails nicht.
  

• Um nicht weitere solcher Mails zu erhalten, kann man sich Sicherheitssoftware besorgen, die solche Mails abwehrt.
  

c)

Trojaner würde ich eher so definieren:

• Hinter einem vordergründig harmlosen Programm steckt eine schädliche Anwendung, die z.B. Daten ausspioniert.
  

[sg-sd]

Das Wort Phishingmail ist mir doch glatt nicht eingefallen.

Aber der Rest ist meiner Meinung nach i.O.

Handlungschritt 2 wurde bereits in einem anderen Thread gelöst.

Handlungsschritt 3:

a) siehe Anlage

habe ich noch nicht

[hdmonty]

2a)

Da sind noch ein paar Fehler drin:

1. Keine Assoziation zwischen Kunde und Kurs

2. Eine Rechnung besteht nicht nur aus einer Rechnungsposition!

3. Keine Aggregation zwischen Durchgeführter Kurs und Rechnungsposition (nur die Rechnungsposition kennt den DurchgeführtenKurs). Ich würde sowieso sparsam mit Aggregationen umgehen, die sind gar nicht so oft notwendig.

4. Die Beziehung Kunde und Rechnung würde ich nicht als Komposition machen. Wenn der Kunde aus dem System fliegt, muss nicht gleich die Rechnung vernichtet werden (Stichwort: Aufbewahrungspflicht von Rechnung)

Übrigens zur Aufgabe 1 fällt mir auf, dass die Seite ="http://www.ergo-online.de/site.aspx?url=html/software/titel.htm gar nicht so schlecht ist. Unbedingt angucken!

[sg-sd]

Keine Assoziation zwischen Kunde und Kurs

Stimmt, ich habe nur auf dKursListe geguckt das Array ist in beiden Klassen vorhanden. Ist aber eine Referenz auf die Klasse "durchgeführterKurs"

Ich sollte aufmerksamer die Sachen lesen.

2. Eine Rechnung besteht nicht nur aus einer Rechnungsposition!

Gebe ich dir vollkommend Recht, eine Rechnung kann mehrere Positionen haben. Es stimmt aber das es sich um eine Komposition handelt? Da ja eine Rechnung nicht ohne Positionen erstellt werden kann.

3. Keine Aggregation zwischen Durchgeführter Kurs und Rechnungsposition (nur die Rechnungsposition kennt den DurchgeführtenKurs). Ich würde sowieso sparsam mit Aggregationen umgehen, die sind gar nicht so oft notwendig.

Aber die Rechnungsposition kann doch nur durch einen durchgeführtenKurs erstellt werden. Von daher dachte ich das die RechnungsPosition ein Teil des Ganzen durchgeführter Kurs ist.

Die Beziehung Kunde und Rechnung würde ich nicht als Komposition machen. Wenn der Kunde aus dem System fliegt, muss nicht gleich die Rechnung vernichtet werden (Stichwort: Aufbewahrungspflicht von Rechnung)

Hmm da habe ich genauso gedacht wie oben, ohne Kunde gibt es keine Rechnung.

Ich glaub ich denke zu kompliziert bei der ganzen Sache.

[hdmonty]

Ich glaub ich denke zu kompliziert bei der ganzen Sache.

Du hast recht. Du denkst zu kompliziert.

Bei einer Komposition muss man sich immer überlegen:

Wenn ich das Ganze lösche, müssen dann auch die Teile löschen? Wenn ja, dann ist es eine Komposition.

Also:

Rechnung und Rechnungsposition ist ganz klassisch eine Komposition. Richtig.

Bei einer Aggregation ist die Abgrenzung zu einer normalen Assoziation nicht so eindeutig: Deshalb im Zweifel: Finger weg! Es kann nämlich auch falsch sein, wie beim DurchgeführtenKurs und RechnungsPosition. Schon alleine deswegen, weil Rechnungsposition ein Teil der Rechnung ist. Wenn ich also die Rechnung lösche und dadurch die Position, dann verliert ja auch der Kurs ein Teil,aber dem Kurs interessiert es eigentlich gar nicht, weil er es noch nicht einmal mitbekommt(Eigentlich besteht von der Seite noch nicht einmal eine Assoziation. Guck dir mal die abgebildeten Attribute von DurchgeführtenKurs an!).

Und da fällt mir leider noch ein Fehler auf:

Die Aggregation Kunde und Durchgeführter Kurs ist auch falsch. Es könnte doch auch sein, dass der DurchgeführteKurs aus lauter Kunden besteht. Wer ist dann Teil und wer ist Ganzes? Ich kann es nur nochmal sagen: Finger weg von der Aggregation, wenn man sich nicht sicher ist.

Also Kunde und DurchgeführterKurs ist eine normale Assoziation.

[sg-sd]

Hmm ich verstehe, dass jetzt so ungefähr und habe mal ein neues gemacht.

Der Kunde hat nun eine Aggregation auf Rechnung da der Kunde ja zwingend für eine Rechnung benötigt wird. DurchgeführterKurs hat nun eine 1 zu 1 Beziehung zu RechnungsPos, da ein Kurs eine RechnungsPos hat.

[hdmonty]

Im Kern ist sowohl Aggregation und Komposition eine Ganze-Teile Beziehung.

Also Mutter, Vater, Kinder sind Teile einer Familie. Planeten sind Teile des Sonnensystems, GA1, GA2 und WiSo sind Teile unserer Prüfung und Heuschrecken sind Teil des Imperialismus. Aber besteht eine Rechnung aus einem Kunden? Genügt da nicht eine Assoziation? Es reicht doch, wenn der Kunde die Rechnung bezahlt. Also ich würde da auch nur eine Assoziation machen. Ich denke kein Prüfer wird dir daraus ein Strick drehen.

Übrigens, dass die 'Rechnung zwingend den Kunden braucht' drückst du mit der Kardinalität 1 aus. Die Rechnung gehört genau einem Kunden.

Der Durchgeführte Kurs taucht auch in mehreren Rechnungspositionen auf!

[sg-sd]

Also ich hab das so gelernt,

- Assoziation ist eine Beziehung zwischen zwei oder mehr Klassen beschreibt.

z. B. Konto(*) <----besitzt----- Besitzer(1)

- Aggregation, dabei verkörpert eine Klasse das ganze und eine andere ein Teil davon

z. B. Notebook(1) <>------------Festplatte(1)

Ein Notebook ist das Ganze und die Festplatte ein Teil, die Festplatte kann aber ohne das Notebook vorhanden sein.

Und genauso ist es mit der Rechnung und dem Kunden, oder nicht?

- Komposition beschreibt eine starke Abhängigkeit zwischen dem Ganzen un den Teilen, so dass die Teile nicht ohne das Ganze existieren können.

z. B. Bank(1) <>---------Konto(*) (stell dir <> ausgefüllt vor)

Ohne eine Bank kann es keine Kontos geben

[hdmonty]

Hmmm...

Der Kunde taucht in der Rechnung auf und wird zu einem Teil der Rechnung, das ist schon klar. Aber die Rechnungen tauchen doch auch beim Kunden auf. Man kann hier gar nicht so einfach das Ganze und den/die Teil/e bestimmen.

Ach nee, in den Attributen der Rechnung wird nicht mal der Kunde erwähnt, das heißt in unserem Beispiel kennt man den Kunden noch nicht einmal, wenn man nur das Rechnungsobjekt in den Händen hält.

Ich bleibe dabei. Erst mal immer eine normale Assoziation machen und wenn das so eindeutig ist, dass es Teil und Ganzes gibt und nicht umgekehrt, dann eine Aggregation und wenn das Teil nicht existieren kann ohne das Ganze, dann wird es eine Komposition.

[sg-sd]

Ok, dann lassen wir das so bestehen wie du sagtest, mit der Assoziation zwischen Kunde und Rechnung, da dies nicht wirklich als Fehler auszumachen ist.

[d00f]

wie siehts denn mit dem 4. handlungschritt aus.

hat das struktogramm jemand gemacht?

[hdmonty]

Mein Vorschlag zum HS 4 im Pseudocode:

Hilfsvariablen

herzfrequenz = getHerzfrequenz();

aktuelleLeistung = anfLeistung;

zeitzurerhoehung=60*(dauer in vollen Minuten)

zeitbisnaechsteMessung = 15 Sekunden


writeWerte(aktuelleLeistung, herzfrequenz)


solange nicht vom Trainer abgebrochen wurde

	sleep(zeitbisnaechsteMessung )

	zeitzurerhoehung-= zeitbisnaechsteMessung 

	herzfrequenz = getHerzfrequenz();

	writeWerte(anfLeistung, herzfrequenz);

	wenn herzfrequenz>=maxHerzfreq

		ABBRUCH !!!


	wenn zeitzurerhoehung=0

		aktuelleLeistung = aktuelleLeistung *(prozSteigerung/100+1)

                setLeistung(aktuelleLeistung)

		zeitzurerhoehung = 60*(dauer in vollen Minuten)

Ich möchte noch mal anmerken, dass ich mir die Methoden writeWerte(), setLeistung() und getHerzfrequenz() nicht ausgedacht habe. So ein Denglisch gibt die IHK vor.

[hdmonty]

Heir noch das Struktogramm mit einer kleien Änderung zum Pseudocode.

[sg-sd]

zu H1 c)

In der Aufgabe sind die Wirkungsweisen der einzelnen Schädlinge gefragt:

- Trojaner: führt nach Aufruf schädlichen Code aus

- Virus: fürht direkt schädlichen Code aus

- Hoax: gibt dem Anwender falsche Informationen

zu H2)

Um ein Datenbankmodell in der 3.Normalform zu erhalten, muss die Spalte Trainingstage aus der Tabelle Kursarten ausgelagert werden. Da laut Abb. die Spalte Trainingstage mehrere Tage enthalten kann.

Tabelle Kursart Tabelle Trainingstage

- Kursart_ID (1) ------------>(*) - Kursart_ID (PK,FK)

Tabelle Wochentag

- Wochentag_ID(1)--------->(*) - Wochentag_ID(PK,FK)

zu H3)

- Klasse Kunde hat eine bidirektionale Assoziation (* zu *) zu Klasse DurchgeführterKurs

- Klasse Kurs hat eine bidirektionale Aggregation (1 zu *) zu Klasse DurchgeführterKurs

- Klasse RechnungsPos hat eine unidirektionale Assoziation (1 zu 1) zu Klasse DurchgeführterKurs

- Klasse Rechnung hat eine unidirektionale Aggregation (1 zu *) zu Klasse RechnungsPos

- Klasse Kunde hat eine unidirektionale Assoziation (1 zu 0..1) zu Klasse Rechnung

[hdmonty]

sag ich doch

Hast du die Lsg ?

[sg-sd]

zu H3

addDurchgeführterKurs( kurs:Kurs,datum:Date)


//Deklaration zusätzlicher Variablen

DurchgeführterKurs dKurs;

DurchgeführterKurs dKursListeTemp[] = kurs.getDurchgeführterKursListe()


//Überprüfe ob es den angegebenen Kurs schon gibt

FÜR i = 0, i < dKursListeTemp.Länge, i += 1

WENN dKursListeTemp[i].getDatum() = datum;

DANN dKurs = dKursListeTemp[i]

anzahlDurchgeführterKurse += 1

ENDE FÜR 


//Kontrolliere ob ein Kurs gefunden wurde, wenn nicht dann Kurs hinzufügen

WENN dKurs = NULL

DANN dKurs = new DuchgeführterKurs(dKursListeTemp.Länge, Kurs, datum)

        anzahlDurchgeführterKurse += 1

ENDE WENN 


//Aktualisiere dKursListe von Kunde

dKursliste[anzahlDurchgeführterKurse] = dKurs


// Dem Kurs den Teilnehmer hinzufügen

dKurs.addTeilnehmer(this)


//Wenn rechnung = 0 dann neue Rechnung anlegen

WENN rechnung = NULL

DANN rechnung = new Rechnung()

ENDE WENN


// Neue RechnungsPos

rechnung.addRechnungsPosition( rechnungsPosListe.Länge + 1, kurs)

[sg-sd]

sag ich doch

Hast du die Lsg ?

Hab gestern mit nem Kollegen das alles nochmal durchgeackert und wir sind halt zu diesen Ergebnissen gekommen.

[sg-sd]

zu H3

addDurchgeführterKurs( kurs:Kurs,datum:Date)


//Deklaration zusätzlicher Variablen

DurchgeführterKurs dKurs;

DurchgeführterKurs dKursListeTemp[] = kurs.getDurchgeführterKursListe()


//Überprüfe ob es den angegebenen Kurs schon gibt

FÜR i = 0, i < dKursListeTemp.Länge, i += 1

WENN dKursListeTemp[i].getDatum() = datum;

DANN dKurs = dKursListeTemp[i]

anzahlDurchgeführterKurse += 1

ENDE FÜR 


//Kontrolliere ob ein Kurs gefunden wurde, wenn nicht dann Kurs hinzufügen

WENN dKurs = NULL

DANN dKurs = new DuchgeführterKurs(dKursListeTemp.Länge, Kurs, datum)

        anzahlDurchgeführterKurse += 1

ENDE WENN 


//Aktualisiere dKursListe von Kunde

dKursliste[anzahlDurchgeführterKurse] = dKurs


// Dem Kurs den Teilnehmer hinzufügen

dKurs.addTeilnehmer(this)


//Wenn rechnung = 0 dann neue Rechnung anlegen

WENN rechnung = NULL

DANN rechnung = new Rechnung()

ENDE WENN


// Neue RechnungsPos

rechnung.addRechnungsPosition( rechnungsPosListe.Länge + 1, kurs)

Ich nehme den Code zurück das ist eine ältere Version des Codes So ist er richtig:

addDurchgeführterKurs(kurs:Kurs,datum:Date)


i:Integer

rechNr:Integer


DurchgeführterKurs[] dKurs = kurs.getDurchgeführterKursListe()


FÜR i = 0 bis dKurs.length - 1

WENN (dKurs[i].getDatum() = datum)

dKursListe[anzahlDurchgeführterKurse] += dKurs[i]

anzahlDurchgeführterkurse += 1

dKurs[i].addTeilnehmer(this)

ENDE WENN

WENN rechnung = NULL

rechnung = new Rechnung()

rechNr = rechnung.getRechnungNr()

rechnung.addRechnungPosition(rechNr,dKurs[i])

ENDE WENN

ENDE FÜR