XML – Extensible Markup Language

• XML steht für eXtensible Markup Language und ist aus der Not entstanden, dass HTML an seine Grenzen gestoßen ist.

• XML ist ein Datenformat. Bei XML handelt es sich um eine textbasiertes Datenformat, ähnlich wie “JavaScript Object Notation”, besser bekannt als JSON. Somit können XML-Daten in einem Editor geöffnet und bearbeitet werden. Zudem können Computer das XML-Format lesen und schreiben.

• XML besteht wie HTML aus sogenannten Tags, die zwischen spitzen Klammern '<' '>' stehen.

• Im Gegensatz zu XML gibt es in HTML nur einen fest definierten Satz an Tags.

• Mit XML können Sie eigene Tags definieren. Lediglich wie ein Tag aussehen muss ist definiert, nicht aber was er bedeutet.

• Ein XML-Tag kann folgendermaßen alleine stehen. Alternativ kann ein Tag auch einen Bereich umschließen. Dann gibt es einen öffnenden und einen schließenden Tag.

• Tags können ineinander verschachtelt sein. Auf diese Weise kann eine Hierarchie erzeugt werden.

• Bei Bedarf kann ein Tag einen oder mehrere Parameter haben.

• Parameter bestehen immer aus einem Namen und einem Wert. Der Wert wird mit doppeltem Anführungszeichen umschlossen und mit einem Gleichheitszeichen zugewiesen.

Einsatz von XML

Was ist XML? – Anwendung

• Grundsätzlich kann XML zum Beschreiben, Speichern und Austauschen von Daten genutzt werden.

• Die wichtigsten Vorteile von XML sind die große Verbreitung und der geringe Lernaufwand. Außerdem kann XML leicht von Menschen und Maschinen interpretiert werden.

• Der einzige Nachteil von XML ist der Datenoverhead im Vergleich zu einem Binärformat. Das bedeutet, dass eine im XML-Format gespeicherte Struktur mehr Speicherplatz benötigt als unbedingt nötig. Dementsprechend kann Sie auch etwas langsamer verarbeitet werden.

• XML wird häufig verwendet, um Anwendungsdaten zu importieren und exportieren. Zum Beispiel kann eine Kundendatenbank gut im XML-Format dargestellt werden. Indem Tags verschachtelt werden, können Sie mehrere Attribute zu einem Kunden zuordnen. Ein Feld für die Telefonnummer kann zusätzlich in einem Parameter speichern, ob es sich bei der Nummer um eine Mobil- oder Privatnummer handelt.

• Das erste Wort “eXtensible” bezeichnet schon, dass die Sprache erweiterbar ist. XML verwenden Sie heute wohl täglich in Technologien wie beispielsweise HTML oder RSS.

Was ist ein UML Diagramm?

Die Unified Modeling Language (UML) wurde entwickelt, um eine gemeinsame, semantisch und syntaktisch umfangreiche visuelle Modellierungssprache für die Architektur, das Design und die Implementierung von komplexen Softwaresystemen zu schaffen – und zwar sowohl für strukturelle als auch für verhaltensbasierte Modelle. Die UML wird weit über die Softwareentwicklung hinaus eingesetzt, so zum Beispiel für Abläufe von Herstellungsprozessen.

Die UML entspricht den Konzepten, die in anderen Bereichen verwendet werden, und besteht aus verschiedenen Diagrammarten. Insgesamt beschreiben UML-Diagramme die Grenzen, die Struktur und das Verhalten von Systemen und den darin enthaltenen Objekten.

UML ist keine Programmiersprache, aber es gibt Tools, die UML-Diagramme nutzen, um Code in verschiedenen Sprachen zu generieren. UML hat einen direkten Bezug zu objektorientierter Analyse und Design.

UML und seine Rolle beim objektorientierten Modellieren und Design

In der Informatik, also der Wissenschaft von Algorithmen und Daten, gibt es viele Paradigmen oder Modelle zur Lösung von Problemen. Dabei stehen vier Modellkategorien für die Problemlösung zur Verfügung: imperative, funktionale, deklarative und objektorientierte Sprachen (OOP). In objektorientierten Sprachen werden Algorithmen durch die Definition von „Objekten“ und die Interaktion der Objekte untereinander ausgedrückt. Diese Objekte können manipuliert werden und sie existieren in der echten Welt. Dabei kann es sich um Gebäude, Widgets auf einem Desktop oder Menschen handeln. Objektorientierte Sprachen dominieren die Welt der Programmierung, denn sie können reale Objekte modellieren. UML ist eine Kombination aus mehreren objektorientierten Notationen: objektorientiertes Design, Objektmodellierungstechnologie und objektorientierte Softwareentwicklung. UML nutzt die Stärken dieser drei Ansätze für ein schlüssigeres Verfahren, das sich einfacher verwenden lässt. UML vereint die Best Practices für die Erstellung und Dokumentation unterschiedlicher Aspekte der Modellierung von Software- und Geschäftssystemen.

Die Geschichte und Ursprünge von UML

Die „3 Amigos“ der Softwareentwicklung – so wurden sie in Fachkreisen genannt – hatten andere Methodiken weiterentwickelt. Sie arbeiteten gemeinsam an einer Lösung, um durch neue Standards Klarheit für Programmierer zu schaffen. Die Zusammenarbeit von Grady, Booch und Rumbaugh verbesserte alle drei Methoden und optimierte das finale Produkt. Durch den unermüdlichen Einsatz dieser Vordenker kam es 1996 zur Veröffentlichung der UML 0.9- und 0.91-Dokumente. Schnell war klar, dass UML in mehreren Organisationen – darunter Microsoft, Oracle und IBM – als entscheidend für die eigene Geschäftsentwicklung angesehen wurde. Gemeinsam mit vielen anderen Einzelpersonen und Unternehmen erarbeiteten sie Ressourcen, mit denen man eine vollwertige Modellierungssprache entwickeln konnte. Die 3 Amigos veröffentlichten 1999 einen Benutzerleitfaden für einheitliche Modellierungssprache („The Unified Modeling Language User Guide“) und 2005 folgte eine zweite überarbeitete Auflage mit Informationen über UML 2.0.

OMG: Nicht das, was Sie denken!

Laut ihrer Website ist die Object Management Group® (OMG®) ein internationales, nicht gewinnorientiertes Konsortium zur Förderung von Technologiestandards, das 1989 ins Leben gerufen wurde und auf einem Konzept der offenen Mitgliedschaft basiert. Die OMG-Standards werden von Anbietern, Endnutzern, Bildungseinrichtungen und Behörden festgelegt. OMG Task Forces entwickeln Integrationsstandards für Unternehmen für eine breite Palette an Technologien und eine noch breitere Palette an Branchen. Die Modellierungsstandards von OMG, darunter UML und Model Driven Architecture® (MDA®), machen es möglich, dass Software- und andere Prozesse aussagekräftig visuell dargestellt, ausgeführt und gewartet werden können. Die OMG überwacht die Definition und Einhaltung der UML-Spezifikationen. Dadurch können Entwickler und Programmierer zu unterschiedlichsten Zwecken in sämtlichen Phasen des Software-Lebenszyklus für Systeme aller Größen auf eine einheitliche Sprache zurückgreifen.

Der Zweck von UML

Die OMG definiert den Zweck der UML wie folgt: - Systemarchitekten und Softwareentwickler erhalten ein Tool für die Analyse, das Design und die Implementierung von softwarebasierten Systemen sowie für die Modellierung von Geschäfts- und ähnlichen Prozessen. - Die Branchensituation soll optimiert werden, indem dafür gesorgt wird, dass Tools zur visuellen Modellierung von Objekten miteinander kompatibel sind. Allerdings ist es für einen sinnvollen Austausch von Modelldaten zwischen Tools notwendig, dass eine einheitliche Notation und Semantik verwendet wird. UML erfüllt die folgenden Anforderungen: - Festlegung einer formalen Definition für ein gemeinsames Metamodell, das auf Meta-Object Facility (MOF) basiert und die abstrakte Syntax der UML spezifiziert. Die abstrakte Syntax definiert die UML-Modellierungskonzepte, ihre Attribute und ihre Beziehungen sowie die Regeln für die Kombination dieser Konzepte zur Entwicklung partieller oder kompletter UML-Modelle. - Eine detaillierte Erklärung der Semantik für jedes einzelne UML-Modellierungskonzept. Die Semantiken definieren – in einer von der Technologie unabhängigen Art und Weise –, wie die UML-Konzepte von Computern realisiert werden. - Bestimmung der von Menschen lesbaren Notationselemente für die Darstellung individueller UML-Modellierungskonzepte sowie die Festlegung von Regeln für die Kombination solcher Konzepte, um eine Vielzahl von Diagrammarten für verschiedene Aspekte des modellierten Systems erstellen zu können. - Festlegung von Methoden, mit denen gewährleistet werden kann, dass UML-Tools mit dieser Spezifizierung übereinstimmen. Dies wird (in einer separaten Spezifizierung) durch eine XML-basierte Spezifizierung von zugehörigen Modell-Austauschformaten (XMI) unterstützt – konforme Tools müssen diesen Prozess dann durchlaufen.

UML und Datenmodellierung

Die UML ist zwar unter Programmierern beliebt, wird aber in der Regel nicht von Datenbankentwicklern verwendet. Einer der Gründe dafür ist, dass die UML-Ersteller ihren Schwerpunkt nicht auf Datenbanken gelegt haben. Dennoch ist die UML für die allgemeine Darstellung von Datenmodellkonzepten geeignet und kann für verschiedene Arten von UML-Diagrammen eingesetzt werden. Für Informationen über die Verwendung von Schichten in einem objektorientierten Klassenmodell in einer relationalen Datenbank lesen Sie diesen Artikel über die Datenbankmodellierung in UML:

Neuerung bei UML 2.0

UML wird kontinuierlich verbessert. UML 2.0 ist eine erweiterte Variante von UML, mit der noch mehr Aspekte der Entwicklung abgedeckt werden können, so zum Beispiel agile Konzepte. Ziel war es, UML neu zu strukturieren und zu optimieren und somit die Benutzerfreundlichkeit, die Implementierung und die Anpassung zu vereinfachen. Hier sind einige der wichtigsten Neuerungen bezüglich UML-Diagrammen: - Bessere Integration zwischen strukturellen und verhaltensbasierten Modellen. - Möglichkeit, eine Hierarchie und eine Aufschlüsselung eines Softwaresystems in Komponenten und untergeordnete Komponenten abzubilden. - UML 2.0 erhöht die Anzahl an Diagrammen von 9 auf 13.

UML-Begriffsglossar

Machen Sie sich mit dem UML-Vokabular vertraut: In der folgenden Liste finden Sie ausgewählte Begriffe aus dem UML 2.4.1-Dokument, das Nichtmitgliedern der OMG dabei helfen soll, häufig verwendete Begriffe zu verstehen: - Einhaltung abstrakter Syntax Benutzer können Modelle von einem Tool auf ein anderes übertragen, selbst wenn sie unterschiedliche Notationen verwenden - Common Warehouse Metamodel (CWM) Standard-Schnittstellen, die für den Austausch von Warehouse- und Business-Intelligence-Metadaten zwischen Warehouse-Tools, Warehouse-Plattformen und Warehouse-Metadatenspeichern in verteilten heterogenen Umgebungen verwendet werden. - Einhaltung konkreter Syntax Benutzer können weiterhin in unterschiedlichen Tools die Notation verwenden, mit der sie vertraut sind - Kern Im Kontext von UML bezieht sich der Begriff „Kern“ in der Regel auf das „Kernpaket“, wobei es sich um ein vollständiges Metamodell handelt, das speziell für eine hohe Wiederverwendbarkeit entwickelt wurde - Spracheinheit Besteht aus einer Sammlung eng zusammenhängender Modellierungskonzepte, die Benutzern die Möglichkeit bieten, ausgewählte Aspekte des Systems nach einem bestimmten Paradigma oder Formalismus darzustellen - Ebene 0 (E0) Die unterste Compliance-Ebene in der UML-Infrastruktur – eine einzelne Spracheinheit, mit der die Modellierung von verschiedenen Arten von klassenbasierten Strukturen möglich ist, die in den meisten verwendeten objektorientierten Programmiersprachen auftreten - Meta Object Facility (MOF) Eine von der OMG eingeführte Modellierungsspezifikation, die die Grundlage für die Metamodelldefinitionen in der MDA-Sprachfamilie der OMG bildet - Metamodell Definiert die Sprache und die Prozesse, aus denen ein Modell entwickelt wird - Metamodell-Konstrukte (LM) Die zweite Compliance-Ebene in der UML-Infrastruktur – eine zusätzliche Spracheinheit für erweiterte klassenbasierte Strukturen, die für die Entwicklung von Metamodellen (mithilfe von CMOF) wie UML selbst verwendet wird. UML hat nur zwei Compliance-Ebenen - Modellgetriebene Architektur (MDA) Ein Ansatz für eine einheitliche Zusammenstellung modellgetriebener Technologiespezifikationen - Object Constraint Language (OCL) Eine deklarative Sprache für die Beschreibung von Regeln, die für die Unified Modeling Language gelten. OCL ergänzt UML durch Begriffe und Flussdiagramm-Symbole, die präziser sind als natürliche Sprache, aber nicht so komplex wie Mathematik - Object Management Group (OMG) ist ein nicht gewinnorientiertes Konsortium für die Entwicklung von Standards in der Computerbranche, deren Mitglieder die UML-Spezifikation definieren und verwalten - UML 1 Erste Version der Unified Modeling Language - Unified Modeling Language (UML) Eine visuelle Sprache für die Spezifizierung, Konstruktion und Dokumentation der Artefakte in einem System - XMI Eine XML-basierte Spezifikation von zugehörigen Modellaustauschformaten

Von UML festgelegte Modellierungskonzepte

Die Systementwicklung konzentriert sich im Großen und Ganzen auf drei unterschiedliche Systemmodelle:

• Funktional: Hierbei handelt es sich um Anwendungsfalldiagramme, welche die Systemfunktionalität aus Sicht des Benutzers beschreiben.

• Objekt: Hierbei handelt es sich um Klassendiagramme, welche die Systemstruktur im Hinblick auf Objekte, Attribute, Assoziationen und Vorgänge beschreiben.

• Dynamisch: Interaktionsdiagramme, Zustandsdiagramme und Aktivitätsdiagramme werden verwendet, um das interne Verhalten eines Systems zu beschreiben.

Für die Visualisierung solcher Systemmodelle verwendet man zwei unterschiedliche Diagrammarten: Struktur- und Verhaltensdiagramme.

Objektorientierte Konzepte in UML

Die Objekte in der UML sind Entitäten, die auch in der Realität existieren. In der Softwareentwicklung können Objekte dafür verwendet werden, um das zu erstellende System so zu beschreiben oder zu modellieren, dass es für die Domain relevant ist. Objekte ermöglichen außerdem die Zerlegung komplexer Systeme in verständliche Komponenten, sodass immer nur ein Teilbereich dargestellt wird.

Hier sind einige grundlegende Konzepte einer objektorientierten Welt:

• Objekte Repräsentation einer Entität und des jeweiligen Grundbausteins.

• Klasse Plan eines Objekts.

• Abstraktion Verhalten einer Entität aus der echten Welt.

• Verkapselung Mechanismus, bei dem Daten zusammengefügt werden, um diese vor der Außenwelt zu verbergen.

• Vererbung Der Mechanismus, bei dem neue Klassen aus einer vorhandenen erstellt werden.

• Polymorphismus Definiert den Mechanismus, der angewendet wird, um unterschiedliche Formen anzunehmen.

Arten von UML-Diagrammen

UML verwendet Elemente und verknüpft diese auf unterschiedliche Art und Weise miteinander, um verschiedene Arten von Diagrammen zu erstellen: zum einen Diagramme, die statische oder strukturelle Aspekte eines Systems darstellen, zum anderen verhaltensbasierte Diagramme, die die dynamischen Aspekte eines Systems erfassen.

Strukturelle UML-Diagramme

• Klassendiagramm Das am häufigsten verwendete UML-Diagramm und die wichtigste Grundlage für jede objektorientierte Lösung. Klassen in einem System, Attribute und Vorgänge sowie die Beziehung zwischen den einzelnen Klassen. Klassen werden gruppiert, um Klassendiagramme zu erstellen, wenn große Systeme als Diagramm dargestellt werden sollen.

Zwischen Objekten entstehen Assoziationen und Kardinalität (Kann- oder Muss-Beziehung). Eine Assoziation könnte auch eine Rolle haben, die die Funktion eines Objektes im Zusammenhang mit der dieser Assoziation beschreibt. (z.B. Kunde als Rolle des “Auftragsgebers”)

Bei dem Begriff “Richtunge” unterscheiden sich “Unidirektional” und “Bidirektional”. Beim ersteren kennt eine Klasse alle ihre assoziierten Klassen, diese wissen aber nicht, mit wem sie verbunden sind. Beim letzteren kennen verbundene Objekte sich gegenseitig.

Der Begriff “Aggregation” stellt eine Beziehung zwischen einem ganzen und seinen Teilen dar. “Komposition” ist Spezialfall der Aggregation . Einzelteile können nur mit dem Aggregat existieren. Ein Einzelteil kann nur genau einem Aggregat zugeordnet werden.

• Komponentendiagramm Stellt die strukturelle Beziehung von Softwaresystemelementen dar. Wird am häufigsten für komplexe Systeme mit mehreren Komponenten eingesetzt. Komponenten kommunizieren über Schnittstellen.

• Kompositionsstrukturdiagramm Kompositionsstrukturdiagramme werden verwendet, um die interne Struktur einer Klasse darzustellen.

• Implementierungsdiagramm Illustriert die Systemhardware und die zugehörige Software. Nützlich, wenn eine Softwarelösung auf mehreren Maschinen mit individuellen Konfigurationen implementiert wird.

• Objektdiagramm Zeigt die Beziehung zwischen Objekten unter Verwendung von Beispielen aus der Realität. Hierbei wird illustriert, wie ein System zu einem bestimmten Zeitpunkt aussieht. Da Daten in Objekten zur Verfügung stehen, können diese ebenfalls dafür verwendet werden, um Beziehungen zwischen Objekten zu verdeutlichen.

• Paketdiagramm Es gibt zwei spezielle Arten von Abhängigkeiten, die zwischen Paketen definiert werden: Paketimporte und Paketverschmelzungen. Pakete können die unterschiedlichen Ebenen eines Systems darstellen, um die Architektur zu visualisieren. Paketabhängigkeiten können so dargestellt werden, dass die Kommunikationsmechanismen zwischen verschiedenen Schichten erkennbar sind.

Verhaltensbasierte UML-Diagramme

• Aktivitätsdiagramme Grafisch dargestellte Geschäfts- oder Betriebsabläufe, um die Aktivität eines Teils oder einer Komponente in einem System zu visualisieren. Aktivitätsdiagramme werden alternativ zu Zustandsdiagrammen verwendet.

• Kommunikationsdiagramm Ähnelt dem Sequenzdiagramm, allerdings liegt der Fokus hier auf der Nachricht, die zwischen Objekten weitergegeben wird. Die gleichen Informationen lassen sich mit einem Sequenzdiagramm und unterschiedlichen Objekten darstellen.

• Interaktionsübersichtsdiagramm Es gibt sieben Arten von Interaktionsdiagrammen und dieses Diagramm zeigt die Abfolgesequenz von Aktionen im modellierten System.

• Sequenzdiagramm Zeigt, wie und in welcher Reihenfolge Objekte miteinander interagieren. Solche Diagramme repräsentieren Interaktionen für ein bestimmtes Szenario.

• Zustandsdiagramm Ähnlich wie Aktivitätsdiagramme beschreibt diese Art von Diagramm das Verhalten von Objekten, die in ihrem aktuellen Zustand unterschiedliche Verhaltensweisen an den Tag legen.

• Zeitverlaufsdiagramm Wie bei Sequenzdiagrammen wird hier das Verhalten von Objekten in einem bestimmten Zeitraum dargestellt. Wenn es nur ein einziges Objekt gibt, ist das Diagramm recht simpel. Bei mehr als einem Objekt werden die Interaktionen der Objekte während des festgelegten Zeitraums dargestellt.

• Anwendungsfalldiagramm Stellt eine bestimmte Funktionalität eines Systems dar und wurde entwickelt, um zu illustrieren, wie Funktionen zueinander in Beziehung stehen und welche internen/externen Akteure es gibt.

Subject: Das zu erstellende System. Akteur (actor): Der Benutzer und das externe System. Anwendungsfall (Use case): Anforderung an das Systemverhalten.

Hamburg Besuch

https://www.hamburgmuseum.de/de/home

http://www.hamburg.de/tickets/e/9644468/die-kameliendame/

http://www.hamburg.de/tickets/e/8093942/elbphilharmonie-tour-das-original/

Miller’s Law, zu Deutsch die Millersche Zahl, beschreibt die Tatsache, dass ein Mensch gleichzeitig nur 7 ± 2 Informationseinheiten – sogenannte Chunks – im Kurzzeitgedächtnis präsent halten kann. Die Größe des Kurzzeitgedächtnisses ist genetisch festgelegt und kann auch durch Training nicht gesteigert werden.

Erkannt wurde diese Tatsache von George Armitage Miller, einem US-amerikanischen Psychologen und Professor an der Princeton University.

Miller’s Law und die Auswirkungen auf UX

Je mehr Chunks sich auf einem Interface befinden, desto schwieriger wird es, sie wahrzunehmen und zu verarbeiten. Besonders kritisch ist das für Erstbenutzer, denn sie haben keine Erfahrung oder die Möglichkeit, die Erinnerung aus dem Langzeitgedächtnis hervorzurufen. Aufgrund der eingeschränkten Kurzzeiterinnerung wird es immer schwieriger, ein funktionierendes Produkt zu gestalten, da der Benutzer während der Bedienung häufig viele Informationen verarbeiten muss.

Miller’s Law betont auch die Bedeutung von Voraussicht und richtiger Planung in einem Design-Prozess. Denn wer dem Interface neue Features hinzufügen will, muss auch sicherstellen, dass die Gegebenheiten neue Funktionen unterstützen, ohne die visuelle Grundlage zu zerstören.

Ein anderes Wahrnehmungsphänomen, das in Bezug auf Miller’s Law beobachtet wurde, ist bekannt als Primacy-Recency-Effekt. Ein psychologisches Gedächtnisphänomen, welches dazu führt, dass bei einer Reihe dargestellter Objekte früher (Primäreffekt) und später (Rezenzeffekt) dargestellte Information besser im Gedächtnis behalten werden.

Das wirft viele Fragen im Design-Prozess auf: Wenn wir uns an den Anfang und das Ende einer Erfahrung am besten erinnern, wie können wir die positiven Erfahrungen stärken und negativen lindern? Wann fängt UX an und wo hört es auf? Sollten wir Elemente aufgrund der besseren Erinnerung eher am Anfang beziehungsweise am Ende platzieren? All das sind Fragen, die sich besonders UX-Designer beim Entwickeln von Produkten stellen sollten.

Miller’s Law lässt sich mit minimalem Aufwand auf jeden Aspekt unseres Lebens übertragen: Ordne die Anzahl der Elemente in relevante Chunks, die nicht mehr als neun Bits enthalten. Unser Gehirn ist so in der Lage, sich an Position und Funktionalität zu erinnern. Zu große Listen sind für den Nutzer mental schwer zu organisieren. Informationsdesign muss geplant und gut durchdacht sein, bevor die Entwicklung stattfindet.

Miller’s Law: Über den Tellerrand Wir leben in einer Welt mit einer exponentiell wachsenden Informationsmenge. Wenn wir sie nicht richtig organisieren oder sogar zu eliminieren versuchen, verschlechtern wir letztlich unsere Fähigkeit, kritische Aufgaben des Lebens zu erfüllen – zum Beispiel, die eigene Existenz zu sichern.

Deshalb ist es so wichtig, sich von Dingen, Produkten und Dienstleistungen zu befreien, die einen nicht weiter bringen, keinen RoI bringen. Das entspricht dem Pareto-Prinzip: Es besagt, dass 80 Prozent der Ergebnisse mit 20 Prozent des Gesamtaufwandes erreicht werden.

Miller’s Law lehrt uns, dass Menschen endliche Informationen zwar aufnehmen und verarbeiten können, die Informationsüberflutung aber zu einer Ablenkung führt, die sich negativ auf unsere Leistung auswirkt.

#Spring

Persephone was the beautiful daughter of Zeus and Demeter. Wherever she stepped, flowers would appear, and all of the animals would follow her to marvel at her beauty. Hades, the lord of the Underworld, was getting lonely and depressed in his gloomy domain. He gazed up to the earth, and he saw beautiful Persephone. He decided to have her. The god grabbed Persephone, put her in his chariot, and rode back to the underground before anyone could see him.

Demeter, Persephone’s mother and the goddess of harvest and agriculture, started wandering the Earth searching for her missing daughter. Finally, she found out it was Hades who captured her. Enraged, she decided to neglect her duties until her daughter was returned to her. All of the plants soon began to die. The goddess covered the world in snow, saying that the world shall be as barren as her heart. All of the other gods and goddesses pleaded Demeter to make the earth fertile once again, but she explained to them that she wouldn’t do anything until her daughter came back to her. Zeus, in fear of losing everything on earth to Demeter’s pain, ordered Hades to return Persephone. Hades finally agreed. Happy that she was soon going to see her mother again, Persephone, ravenously hungry by this time, ate 6 pomegranate seeds from the platter that Hades offered her. When Zeus and Demeter came to get the girl, Hades announced that she could not go, for she had eaten the food of the dead. Not wanting anything to get worse, Zeus made a compromise: Persephone would stay 6 months with Hades in the underworld, and 6 months with her mother on earth. This is the story explaining why there are seasons, with the year divided into 6 months of live and bloom and 6 months of winter and cold.

Difference between Microprocessor and Microcontroller – Computer Science for dummies.

The terms microprocessor and microcontroller have always been a hell of confusion for first semester computer science students. Those two share many common features and at the same time they have significant differences. Visually if an untrained person takes a look at any microcontroller or microprocessor, he would hardly detect any difference between those two products.

However those two are almost entirely different in many practical aspects. Those differences present themselves in terms of application, production cost, processing power as well as consuming power and inclusive or rather exclusive peripheral functions.

The classic example of a microprocessor application is a laptop, that kind of maschine you use to watch your favorite YouTuber, do Microsoft Excel or any kind of possible digital work. A microprocessor is basically just a CPU (Central Processing Unit) without any predifined task. A system designer has to equip them externally with USB-Port, keyboard, mouse, memory, sensors, etc. to make them functional. The most popular microprocessor suppliers are AMD, Intel and Apple.

Meanwhile in a case of microcontrollers, they are mostly used for a very specific task in order to reduce the cost and consuming power. Example for microcontroller applications are refrigerator, microwave, car etc. These devices are very simple and limited comparing to a modern laptop, I mean a microwave should only be able to cook food and not simulate thermodynamics. Because of its limited functions a microcontroller has all of its memory elements, input/output interface integrated along with the CPU inside a single chip. This in turn reduces the size and the cost. Depending on the definition a microcontroller could almost be termed as a mini computer or a computer on a single chip. Famous producers of microcontrollers are Texas Intruments, Intel, Raspberry Pi, Arduino.

Moreover microprocessors operate at much higher speed than microcontrollers. Whereas the microcontrollers operate from a few MHz to 50 MHz, today’s microprocessor operate above 1 GHz to the 4 GHz for the high-end processors. The sames applies to term of RAM (Ramdom-Access-Memory and ROM (Read Only Memory).

In conclusion, comparing microcontroller and microprocessor in terms of cost is not justified. Undoubtedly a microcontroller is far cheaper than a microprocessor. However microcontroller cannot be used in place of microprocessor and using a microprocessor is not advised in place of a microcontroller as it makes the application inefficiently.

Interessante Internetseiten, Ideen und Startups (Update)

http://www.searchenterprisesoftware.de/definition/IBM-Watson Flaggschiff KI-Plattform von IBM

https://www.heartbeatlabs.com/de/ Berliner Startup im Bereich Telemedizin

https://www.javatpoint.com/ Online Kurs für Java Programmierung

https://storj.io/ Dezentraler auf Blockchain basierter Cloud. Zukünftige Alternative für Dropbox und co.?

https://www.udemy.com/ Online Kurse

http://up-for-grabs.net/#/ Open-Source Plattform

http://www.banksy.co.uk/ Banksy

https://www.heise.de/newsticker/meldung/Zahlen-bitte-Wie-bunt-ist-die-Ebene-4024574.html Das Farbenproblem

Schluss mit Prokrastination.

Menschen sind irrational und dazu noch emotional was Produktivität betrifft. Wir scrollen nämlich lieber durch den endlosen Facebook News Feed als die doch so wichtige Abschlussarbeit für Uni eins für allemal zu erledigen. Wer springt denn nämlich schon gerne ins kalte Wasser, wenn es auf dem Land trocken und warm ist?

Und was tun wir währenddessen? “Katzenvideos” anschauen. Zugegeben sind Katzenvideos ein Segen im Zeitalter des Internets. Nichtsdestotrotz bringen uns die süße Tiere nicht dabei voran, ETCS-Punkte zu sammeln.

Warum prokrastinieren wir? Weil wir als emotionale Wesen uns dadurch hoffen, eine Art Motivation zu spüren, die uns antreibt einer Verpflichtung nachzukommen. Nach dem Motto:“Gleich wird der perfekte Moment kommen um mit dem Lernen anzufangen. Jeden Moment werde ich es spüren.”

Die traurige Weisheit ist aber, dass der “perfekte Moment” nicht existiert, manchmal muss man eben ins kalte Wasser springen. Wer den Schritt nicht erwagt, verbringen täglich Studen damit:

• Ein inspirierendes Youtube-Video zu gucken.
• Auf Instagram zu gehen und das “perfekte Leben” von anderen Menschen zu beneiden.
• Irritierende Motavionssprüchen zu verinnerlichen, die eigentlich absolut null inhaltliche Substanz haben.

Mein Tipp dafür ist simpel, dass man eine Verpflichtung nicht als eine ganze Einheit betrachten soll. Vielmehr soll man dies als einen durchgängigen Prozess betrachten, den man in kleinen Teilen zerlegen kann und damit Schritt für Schritt voran kommen. Langsam aber sicher und kontinieurlich.

Beispiel: – Möchtest du abnehmen und mehr Sport machen? Schließ nicht gleich einen zweijährigen Vertrag im Fitnessstudio nur um nie mehr dahin zu gehen. – Verbring lieber die eine tägliche Stunde, die du sonst mit Netflix verbringst, damit einen Spaziergang zu machen. – Möchtest du gerne wieder in den Urlaub? Dann beginn damit jeden Tag etwas Geld beiseite zu legen.

Der Tipp ist simpel, aber es ist nicht keinesweg einfach. Erledigen wir täglich die kleinen unscheinbaren Aufgaben, so lässt sich der Schneeballeffekt nicht lang auf sich warten.

Regeln zum Mitnehmen:

1. Liebe was du tust und tue was du liebst.

2. Du kannst nicht jedem gefallen.

3. Schlechte Zeiten werden kommen. Sei gewaffnet.

4. Gute Zeiten werden kommen. Verliere nicht die Geduld.

5. Räume deinen Sachen auf, wenn du fertig bist.

6. Habe immer drei Plänen. Einen für den nächsten Tag. Einen für das nächste Jahr. Einen für deinen Lebensweg.

7. Sei bodenständig. Du hast noch viel zu lernen.

8. Neid und Ego werden dich zerstören. Behalte Kontrolle über sie.

9. Lese, lese und lese!

10. Sag die Wahrheit. Oder wenigstens keine Lüge!