stefan.macke

Im Grunde ist es doch ein vollständiges XML-Dokument. Du bekommst halt nicht nur eins, sondern mehrere. Der Wurzelknoten ist halt <frame>. Nun kommt es halt auf den Kontext drauf an, was du mit den Daten vorhast. Wenn die XML-Struktur vorgegeben ist, könnte man dann den XmlSerializer verwenden und aus dem XML-Dokument ein POCO-Objekt erzeugen.
[XmlRoot("frame")] public class Frame {     [XmlElement("id")]     public int Id { get; set; } } string xml = "<frame><id>1</id></frame>"; XmlSerializer serializer = new XmlSerializer(typeof(Frame)); Frame frame = (Frame)serializer.Deserialize(new StringReader(xml)); Um einfach über alle Kind-Elemente im Wurzelknoten zu iterieren kann man auch ein XDocument verwenden:
string xml = "<frame><id>1</id></frame>"; XDocument xDoc = XDocument.Parse(xml); foreach(XElement element in xDoc.Root.Descendants()) {     Console.WriteLine($"{element.Name} -> {element.Value}"); } Ein XDocument lässt sich auch mittels Linq Filtern. 
Eine weitere Möglichkeit, um Abfragen auf XML-Dokumenten abzusetzen wäre XPath und der XPathNavigator:
string text = "<frame><id>1</id></frame>";            XPathDocument docNav = new XPathDocument(new StringReader(text)); XPathNavigator nav = docNav.CreateNavigator(); XPathNodeIterator nodes = nav.Select("//frame/*"); while (nodes.MoveNext()) {     Console.WriteLine($"{nodes.Current.Name} -> {nodes.Current.Value}"); } XPath ist eine vom W3C entwickelte Abfragesprache für XML-Dokumente. Eine Dokumentation findest du auch im Wikipedia-Artikel.
Viele Wege führen nach Rom aber ich halte die Lösung mit regulären Ausdrücken eine der schlechtesten. Das ist sehr fehleranfällig, denn was passiert, wenn dazwischen irgendwo mal ein Leerzeichen oder ein Zeilenumbruch ist? Damit muss dein Ausdruck auch klar kommen können, denn das ist ja kein Fehler. Auch sind reguläre Ausdrücke schlecht lesbar. Ich denke mal, du selbst wirst den regulären Ausdruck binnen kürzester Zeit nicht mehr verstehen und muss erst mal wieder nachschauen, was der bedeutet. XML-Dokumente einlesen ist ein gelöstestes Problem und warum sollte man sich wieder selbst eine Lösung ausdenken? Selbst das .Net-Framework bietet hier sogar mehrere Lösungen an. Das Framework bietet mit der XmlDocument-Klasse sogar noch eine vierte Variante.

Um die NWA aber sinnvoll nutzen zu können, sollte diese Subjektivität möglichst eliminiert werden. Daher ist die Angabe der Werteskala und die Begründung für die vergebene Punktzahl so wichtig.
Bei Skalen von 1 bis 100 kann fast nur eine rein subjektive Bewertung erfolgen. Wie beschrieben: Wie soll der Unterschied zwischen 75 und 76 Punkten glaubhaft begründet werden?
Kleinere Skalen, die für jeden Wert genau festlegen, wann er zu vergeben ist, sind objektiv(er) einsetzbar. Beispiel: Kriterium "Dokumentation des Produkts" -> 0 Punkte: Keine Doku vorhanden, 1 Punkt: Englische Doku vorhanden, 2 Punkte: Deutsche Doku vorhanden, 3 Punkte: Deutsche Doku mit lauffähigen Beispielanwendungen vorhanden. Diese Bewertung kann von jedem Mitarbeiter vorgenommen werden, ohne großen Interpretationsspielraum.
Natürlich ist es ein bestimmter Aufwand, für jedes Kriterium so eine Skala vorzubereiten. Aber genau das würde ich von einem Prüfling im Rahmen seiner Projektarbeit erwarten. Ansonsten kann man sich die NWA auch sparen und sich wahllos irgendwelche "Nutzwertkoeffizienten" ausdenken.

Eine Gewichtung brauchst du, wenn es halt etwas zu gewichten gibt. In deinem ersten Beispiel sind alle Kriterien gleich wichtig. Für den unwahrscheinlichen Fall, dass das wirklich so ist, brauchst du keine Gewichtung.
Was du unabhängig von der Gewichtung aber unbedingt noch einbauen solltest, ist eine Erklärung der zu vergebenden Punkte. Die Skala ist schon sehr krass: 0-50 Punkte. Was heißt das? Warum bekommt man z.B. 47 und nicht 48 Punkte? Wer bewertet das? Wie wird das überhaupt bewertet?
Und durch die unterschiedlichen Skalen der Kriterien hast du eigentlich eine versteckte Gewichtung. Denn bei Kriterium 4 sind ja mehr als doppelt so viele Punkte möglich wie bei 1. Alles etwas seltsam.
Mein allgemeines Feedback: Werteumfang deutlich reduzieren (z.B. 0-3); erklären, was die Werte bedeuten (z.B. 0 nicht vorhanden, 1 schlecht, 2 mittelmäßig, 3 hervorragend); Gewichtung einführen (es gibt immer Kriterien, die wichtiger sind als andere); erläutern, wer die Bewertung durchführt und wie sie auf die Werte kommen.

Eine Gewichtung brauchst du, wenn es halt etwas zu gewichten gibt. In deinem ersten Beispiel sind alle Kriterien gleich wichtig. Für den unwahrscheinlichen Fall, dass das wirklich so ist, brauchst du keine Gewichtung.
Was du unabhängig von der Gewichtung aber unbedingt noch einbauen solltest, ist eine Erklärung der zu vergebenden Punkte. Die Skala ist schon sehr krass: 0-50 Punkte. Was heißt das? Warum bekommt man z.B. 47 und nicht 48 Punkte? Wer bewertet das? Wie wird das überhaupt bewertet?
Und durch die unterschiedlichen Skalen der Kriterien hast du eigentlich eine versteckte Gewichtung. Denn bei Kriterium 4 sind ja mehr als doppelt so viele Punkte möglich wie bei 1. Alles etwas seltsam.
Mein allgemeines Feedback: Werteumfang deutlich reduzieren (z.B. 0-3); erklären, was die Werte bedeuten (z.B. 0 nicht vorhanden, 1 schlecht, 2 mittelmäßig, 3 hervorragend); Gewichtung einführen (es gibt immer Kriterien, die wichtiger sind als andere); erläutern, wer die Bewertung durchführt und wie sie auf die Werte kommen.

Mein kompletter Entwurf (Fachinformatiker Anwendungsentwicklung, Thema SQL) ist online: Unterweisungsentwurf für die AdA-Prüfung. Ist allerdings schon aus 2006.
Hier gibt es noch zwei weitere Beispiele (ISDN-Karte einbauen, PC aufbauen) aus den IT-Berufen: http://www.ada-schein-pruefung.de/unterweisung.php
Wenn noch jemand etwas aktuellere Entwürfe hat, gerne her damit!

Letztendlich können wir erst eine genauere Antwort  über Zeilenabstand und Schriftart geben, wenn wir seine IHK kennen bzw. kann diese ihm nur die Antwort liefern. Aber wenn es keine Vorgaben gibt, würde ich persönlich mit der Entscheidung über einen Zeilenabstand von 1,3 bis 1,5 warten, bis die Dokumentation soweit fertig geschrieben ist. Dieser Unterschied von bis zu 0,2, kann später dazu genutzt werden um den Text der geforderten Seitenzahl ein wenig anzupassen. 

@jk86Ich glaube, das bezog sich darauf, dass IT-Jobs immer mehr ins Ausland verlagert werden.

Einfach nur um von Einzelschicksalen wieder auf den allgemeinen Arbeitsmarkt zurückzukommen: der Fachinformatiker gehört seit Neustem zu den 10 beliebtesten Ausbildungsberufen bei männlichen Azubis. Von einer Abnahme der Nachfrage - bei Betrieben und Bewerbern - kann also wahrlich nicht die Rede sein.
https://www.bibb.de/de/pressemitteilung_60513.php

Wir setzen in der Ausbildung auch eine wenig verbreitete Sprache ein: Natural. Sie ist ähnlich zu Cobol. Damit verdient unser Unternehmen sein Geld, also müssen auch die Azubis die Sprache lernen. Aber als Ausbilder achte ich darauf, dass sie zusätzlich mindestens eine "moderne" Sprache wie Java oder C# lernen. Sowohl die Konzepte der Objektorientierung als auch andere Plattformen wie das Web sollten meiner Meinung nach in der Ausbildung heutzutage vermittelt werden. Ich habe also nichts gegen eine Ausbildung auf RPG, wenn zusätzlich auch moderne Inhalte berücksichtigt werden. Man kann als Unternehmen evtl. nicht nur das ausbilden, was für das Tagesgeschäft nötig ist, sondern muss auch darüber hinaus Inhalte anbieten. Darauf würde ich bei der Wahl des Ausbildungsplatzes achten.

Generell: du lernst in der Ausbildung Programmieren. Die Programmiersprache die dabei verwendet wird ist nur ein Werkzeug.

Ja. So wie UML ein graphisches Verfahren ist, Software zu modellieren. 
Ich verstehe nicht, worin der Nachteil bestehen sollte.
Das Zusammenspiel von Objekten, die durch Komposition zusammengesteckt werden kann ich schlechter testen als durch Aggregation.  Die von Dir Angeführten Mocks bieten Dir Möglichkeiten, die du ohne nicht hast: bspw. sicherstellen, dass gewissen Methode keinmal, einmal, mindestens einmal aufgerufen worden sind. 
Möchte ich das nicht testen, benötige ich auch keine Mocks. 
Das heißt, Du hast im Vergleich zur Komposition keine Nachteile. Da sind die Objekte genauso opak in der Benutzung.
Seine Software in der Art zu strukturieren bietet Dir die Möglichkeit, testgesteuert (ich vermeide explizit »testdriven«) Deine Software zu entwickeln. 
Man kann sein Smartphone nutzen, um ulkige Katzenvideos zu gucken - aber es ist noch mehr drin.
Es ist natürlich von den Ansprüchen, die man an sein Produkt hat, abhängig.
Das tolle an der Softwarentwicklung ist ja, dass Du als Entwickler bestimmen kannst, mit welchen Wegen Du zum Ziel kommst. Ich bin aus dem Alter raus, wo ich den Leuten erzählen will, was sich wie richtiger anfühlt.
Es zählt, dass mit der Software Geld verdient werden kann. Ob das objektorientiert, funktional, prozedural, strukturiert passiert interessiert keinen Kunden/Arbeitgeber. Am Ende des Budgets muss das Problem gelöst sein, sonst taugt der Ansatz nicht.
 

Kann mich nur anschließen. Das geht gar nicht! Und die geben sogar zu, dass die gleiche Aufgabe fertigen Entwicklern gestellt wurde. Tut mir leid, aber da schreit alles: "Wir brauchen billige Arbeitskräfte, die wir nicht ausbilden müssen!".
Überleg mal: Zwei Wochen Programmierung!? Das ist der Umfang des Abschlussprojekts für Anwendungsentwickler!

Kann mich nur anschließen. Das geht gar nicht! Und die geben sogar zu, dass die gleiche Aufgabe fertigen Entwicklern gestellt wurde. Tut mir leid, aber da schreit alles: "Wir brauchen billige Arbeitskräfte, die wir nicht ausbilden müssen!".
Überleg mal: Zwei Wochen Programmierung!? Das ist der Umfang des Abschlussprojekts für Anwendungsentwickler!

Kann mich nur anschließen. Das geht gar nicht! Und die geben sogar zu, dass die gleiche Aufgabe fertigen Entwicklern gestellt wurde. Tut mir leid, aber da schreit alles: "Wir brauchen billige Arbeitskräfte, die wir nicht ausbilden müssen!".
Überleg mal: Zwei Wochen Programmierung!? Das ist der Umfang des Abschlussprojekts für Anwendungsentwickler!

Was zum Geier? 
Das using hat hier überhaupt nichts zu suchen ...
Das using ist für das IDisposable-Interface und dieses Interface dient fürs Aufräumen vom Speicher von unmanaged Code.
Wenn du das Haus nur innerhalb eines Blockes haben willst, dann setze es doch ein ein Block:
{ var house = new House( new List<Room> { new Room(windowCount: 1), new Room(windowCount: 3) { Name = "dining" } }); house.Garage = garage; Console.WriteLine("house in a using statement"); Console.WriteLine(house.ToString()); Console.WriteLine("leaving using statement"); } @ Topic:
Eine Aggregation assoziiert "ein Besitz".
z.B. ein Forum besitzt Mitglieder. Das Forum kann aber auch ohne Mitglieder bestehen.
Oder eine Garage besitzt ein Fahrzeug. Die Garage besteht aber auch, wenn kein Fahrzeug drinnensteht.
Eine Komposition assoziert "ein Teil".
z.B. das Herz ist ein Teil des Menschens. Ohne ein Herz kann ein Mensch nicht leben.
Oder ein Raum ist ein Teil eines Gebäudes. Ohne ein Raum existiert auch kein Gebäude.

...wurde bislang noch nicht abgefragt. Was aber auch ok ist. Wer braucht denn schon wirklich ein Timing-Diagramm?
Wie beschrieben setze ich die UML sehrwohl für die Modellierung ein. Allerdings nicht im Detail - also Klassen mit Attributen und allem Schnickschnack - sondern insb. für die Architekturplanung. Das detaillierte Klassendesign oder Abläufe, die man mit einem Sequenzdiagramm modellieren könnte, ergeben sich bei Anwendung von TDD erst bei der Entwicklung.
Nichtsdestotrotz gibt es viele gute Werkzeuge (z.B. den Enterprise Architect), die Roundtrip-Engineering beherrschen und Code zu Modell und Modell zu Code wandeln können. Dadurch wird die Aktualisierung der Modelle ein Kinderspiel.
Genau wie bei Code
Das kommt auf den Grad der Abstraktion an. UML hat nicht den Anspruch, die Details perfekt abzubilden. Das kann Code tatsächlich besser. Dafür kannst du in deinen Diagrammen die Sicht und den Grad der Detaillierung frei wählen und komplexe Abläufe auf ihren Kern herunterbrechen. Von daher sehe ich die UML gerade bei komplexen Abläufen als äußerst hilfreich an.
Siehe oben. Das geht sehrwohl. Allerdings sollte nicht der Anspruch sein, "fertigen" Code zu generieren, sondern z.B. Klassenrümpfe oder Pakete. Das spart dann tatsächlich sogar Zeit, wenn man mit dem Modell beginnt.
Da wir auch mehrere selbst entwickelte DSLs im Einsatz haben, kann ich nur zustimmen: für die Codegenerierung optimal! Aber für die Dokumentation und grobe Modellierung würde ich trotzdem ein grafisches Werkzeug wie die UML vorziehen.

Das stimmt nicht doch gar nicht. @stefan.macke schreibt eindeutig, dass es auch für die Modellierung vor der Entwicklung genutzt wird. Lediglich, wenn selbst das wegfallen würde, hätte UML auch noch zur Dokumentation seine Daseinsberechtigung.
Was aber vermutlich auch daran liegt, dass derjenige, der diese angefertigt hat, vermutlich letzten Endes selber UML gar nicht vernünftig verstanden hat.
Das soll für mein Verständnis ein UML-Diagramm auch erst einmal gar nicht. UML dient imo vor allem der Visualisierung von Abläufen und Zusammenhängen und auch nicht alles muss dann später zu 100% mit dem erzeugten Code übereinstimmen.
Ein Use-Case-Diagramm zeigt beispielsweise auf einfachste Weise auf, was eine Anwendung von außen betrachtet tun soll und ist auch ohne viel Wissen von UML für Laien (i.d.R. der Kunde) zu verstehen und kann damit als Konzeptions- und Diskussionsgrundlage dienen.
Das habe ich anders in Erinnerung. Es gibt sogar Firmen, die damit ihr Geld verdienen Software zu entwickeln, die genau das bewerkstelligt. Und aus Klassendiagrammen habe ich während meiner Ausbildung in der Schule definitiv auch schon Code generiert.
Wenn es hier um die Diskussion geht, was alles überflüssig wäre zu lernen während der Ausbildung, ist UML sicherlich nicht das, was an erster Stelle steht (da sind PAP und Struktogramme sicherlich weiter vorne). Es zu lernen ist jedoch durchaus berechtigt und sollte auch nicht unter den Tisch gekehrt werden.
Es geht bei der IHK-Ausbildung auch nicht darum die neuesten state of the art Techniken zu beherrschen (die zum Teil übrigens schneller wieder im Erdboden verschwinden, als dass sie aufgetaucht sind), sondern darum eine Grundlage für strukturierte und saubere Entwicklung zu bieten.
Du hast deine Meinung zu UML, andere und vor allem die IHK, die nunmal das Sagen bei der Ausbildung hat, haben eine andere.

Du hast - mal wieder - völlig recht, was die Praxis angeht. Allerdings kann man das den Prüflingen definitiv nicht empfehlen! Die Wahrscheinlichkeit, einen Punktabzug zu bekommen bzw. sogar durchzufallen, weil die zeitlichen Vorgaben nicht eingehalten wurden, ist sehr hoch!
Jeder weiß, dass die Projektarbeit geschönt ist. Dieser Fakt steht auch bei der anstehenden Neuordnung der IT-Berufe ganz oben auf der Mängelliste. Es wird überlegt, von diesem starren Projektrahmen wegzugehen. Bis es jedoch soweit ist, kann ich nur jedem Prüfling raten, die Zeit exakt einzuhalten!

Du hast - mal wieder - völlig recht, was die Praxis angeht. Allerdings kann man das den Prüflingen definitiv nicht empfehlen! Die Wahrscheinlichkeit, einen Punktabzug zu bekommen bzw. sogar durchzufallen, weil die zeitlichen Vorgaben nicht eingehalten wurden, ist sehr hoch!
Jeder weiß, dass die Projektarbeit geschönt ist. Dieser Fakt steht auch bei der anstehenden Neuordnung der IT-Berufe ganz oben auf der Mängelliste. Es wird überlegt, von diesem starren Projektrahmen wegzugehen. Bis es jedoch soweit ist, kann ich nur jedem Prüfling raten, die Zeit exakt einzuhalten!

Pass bloß auf, sowas darfst du den heutigen Azubis nicht zu laut erzählen... nachher meinen die noch, wir sind damals noch auf Dinosaurieren zur Arbeit geritten.

Ich würde behaupten, dass Copy und Paste von StackOverflow auch den Alltag "fertiger" Entwickler bestimmt
Allerdings sollte man immer verstehen, was man da kopiert.
Btw, unterstützt dich dein/e Ausbilder/in nicht bei der Einarbeitung?

Unsere IHK hat auf andere Dinge Wert gelegt. Und bei einer Bewertung von 98 Punkten, kann ich das ja nicht so falsch gemacht haben.
Das Problem ist halt immer, dass jede IHK ihr eigenes Süppchen kocht.

Da muss ich leider entschieden widersprechen. Es kann sein, dass einige IHKen auf Kunden- und/oder Entwicklerdoku verzichten, aber meiner Erfahrung nach, wollen die meisten IHKen das explizit haben. Das steht sogar in den Bewertungsmatrizen für die Dokumentation (s.u.). Zumindest die Benutzerdokumentation ist demnach Pflichtprogramm als Teil jeder Projektdokumentation. Eine Entwicklerdokumentation (z.B. mit JavaDoc) würde ich im Sinne einer guten Bewertung aber auch noch zusätzlich erstellen.
Vgl. (u.a.):
http://www.ihk-niederrhein.de/downloads/ihk/Bewertungsmatrix_Doku_FIAN.pdf https://www.darmstadt.ihk.de/blob/daihk24/produktmarken/aus_und_weiterbildung_channel/pruefungen/downloads/downloads/2551166/bdb388bedbc086ef6af8038551c207d2/Bewertungsmatrix_FIAE-data.pdf http://www.dortmund.ihk24.de/blob/doihk24/bildung/downloads/305454/d4d06e5b78c03eaf279dbfdb8e000292/Handreichungen_IT_Berufe-data.pdf

Dein Fehler sind die 16 Bit für die Hexzahl. Dafür brauchst du nur 4 Bit. 2^4 = 16 Möglichkeiten. Mit 16 Bit könntest du 2^16 = 65.536 Zahlen/Möglichkeiten abbilden.
Also: 4 Bit * 60 * 24 * 11 = 63.360 Bit = 7.920 Byte.

Ich hatte letzte Woche bei der IHK Dresden (als FIAE).
Ich war eine halbe Stunde vorher da, hab mein Zeug aufgebaut, Berichtsheft, Einladung und Personalausweis vorgelegt.
Als dann alle Prüfer da waren, haben sie sich kurz vorgestellt, gefragt, ob ich Vorbehalte gegen einen von ihnen hätte, ob ich mich gesundheitlich in der Lage fühle. Und ich wurde belehrt, dass mein Handy aus sein muss und ich keinerlei Aufzeichnungen der Prüfung tätigen dürfte.
Mir wurde kurz der Ablauf der Prüfung erklärt (Präsentation - kurz draußen warten - Fachgespräch - kurz draußen warten - Ergebnis) und dann konnte ich auch schon loslegen. Nach der Präsentation wollte ich rausgehen, aber die Prüfer meinten, dass das nicht notwendig wäre und sind direkt ins Fachgespräch eingestiegen. Sie hatten ein-zwei Fragen zur Präsentation und bisschen was Allgemeines (OOP, Testarten, Vorgehensmodelle, Umsatz vs. Gewinn).
Danach bin ich raus, die haben sich gefühlt ewig beraten, mich wieder reingerufen und zur bestandenen Abschlussprüfung gratuliert. An dem Tag selbst habe ich nur einen Schein mit "bestanden" erhalten. Gestern kam dann ein Brief mit den Punkten.
 
Die Prüfer waren total nett und wollen einem wirklich nichts böses. Nur schauen, ob du den Inhalt deiner Arbeit verstanden hast und weißt, was du tust. Meine Präsentation habe ich ungefähr n dutzend Mal durchgesprochen (Ausbilder, Freunde, Familie) und das Fachgespräch mal mit meinem Ausbilder geübt.