Startseite > Archiv > Architektur

Architektur

Als Abonnent haben Sie vollen Zugriff auf alle Artikel im Archiv. Zum Download eines Artikels und/oder der zugehörigen Quelltexte, klicken Sie den gewünschten Artikel einfach an.

Nicht nur außen schön

(dotnetpro 08/2010, Seite 126)
Was haben ein Topmodel und ein Blockschaltbild gemein? Beide schauen toll aus. Während aber in dem einen noch Intelligenz, Gefühl undWissen stecken können, bleibt das andere eine Sammlung von Farbflächen ohne ein Mehr an Information. Schaltpläne mit Event-Based Components bieten hier wesentlich mehr Zusammenhänge.

Stecker mit System

(dotnetpro 07/2010, Seite 126)
Anonym ist in. Zumindest unter Komponenten. Denn wenn keine Komponente die andere kennt, können sie leicht ausgetauscht werden. Damit sind sie testbar, wiederverwendbar und aggregierbar. Und der Theorie lässt Ralf Westphal Praxis folgen: Die Beispiel-Anwendung dreht Wörter um, ganz so, als wären die Buchstaben unabhängig.

Zusammenstecken – funktioniert

(dotnetpro 06/2010, Seite 132)
Wer Hardwareplatinen zusammenbastelt, hat es mit diskreten Bauteilen zu tun: Kondensatoren, Transistoren, ICs und Widerstände.Warum gibt es solche Bauteile nicht auch in der Software? „Gibt es“, sagt RalfWestphal und führt Sie ein in die Welt der Event-Based Components.

Die Gegend auskundschaften

(dotnetpro 05/2010, Seite 124)
Würden Sie sich als Mensch mit Persönlichkeitsspaltung bezeichnen? Wenn ja, haben Sie die besten Voraussetzungen, durchgängig sauberen Code zu schreiben. Denn Sie schlüpfen je nach Anforderung in die Rolle des Feature-Entwicklers oder die des Clean Coders. Für alle anderen gilt: Lernen, worauf Sie künftig achten müssen. Diesmal am Beispiel einer verteilten Lesezeichenanwendung.

Im Gleichgewicht

(dotnetpro 05/2010, Seite 130)
Architektonische Entscheidungen sind ohne die Berücksichtigung technologischer Rahmenbedingungen undenkbar, denn Technologie definiert das Fundament, auf dem sich Architektur bewegen kann. Dieser Artikel zeigt anhand des WCF-Erweiterungsmodells das Zusammenspiel zwischen Technologie und Architektur.

Jeder für sich

(dotnetpro 04/2010, Seite 133)
Dass eine einzige Installation einer Anwendung zugleich mehrere Benutzer bedienen soll, ist eine häufig geforderte Funktion. Dafür ist jedoch eine korrekte Datentrennung notwendig. dotnetpro zeigt, wie Multimandantenfähigkeit bereits auf Basis der Datenbank hergestellt werden kann.

Attraktiv möbliert

(dotnetpro 04/2010, Seite 124)
Eben mal ein paar Objekte wegschreiben und per Schlüssel wiederholen: Lassen Sie in so einem Fall die relationale Datenbankkiste nur ja im Keller stehen. Dafür gibt es Lösungen wie das Lounge Repository. Wie es entstanden ist und wie es funktioniert? Bitte treten Sie ein, wir führen Sie durch die Lounge und erzählen ihre Entstehungsgeschichte.

Singularität im Kern

(dotnetpro 03/2010, Seite 132)
Mit LightCore steht ein Microkernel zur Verfügung, der quasi nebenbei auch als Dependency-Injection-Container dient: Er ist leichtgewichtig, kompakt und vor allem schnell – ohne dass man dabei Features vermissen würde.

Alles verstanden?

(dotnetpro 02/2010, Seite 130)
Idealerweise sagt der Name einer Funktion, was sie tut oder was sie zurückgibt. Bei einem sogenannten Fluent Interface wird das wesentlich weiter getrieben:Mehrere aneinander gekettete Methodenaufrufe formen einen Satz, der sowohl für Menschen als auch für den Compiler gut verständlich ist.

Lernen von anderen

(dotnetpro 01/2010, Seite 124)
Wer mitreden will über automatisiertes Testen oder testorientiertes Entwickeln, muss es selbst ausprobieren. dotnetpro-Autor Golo Roden hat sich dieser Übung unterzogen und kann nun mitreden. Sein Beispiel gerät zu einem Lehrstück, wie testorientiertes Entwickeln in Angriff zu nehmen ist.

Verbindungsstücke

(dotnetpro 12/2009, Seite 124)
Schnittstellen gehören zu den wichtigsten Elementen der Softwarearchitektur, sind die Grundlage verteilter Anwendungen und stehen am Anfang jeder Softwareentwicklung. Ihre Konzeption ist oft nicht einfach. Dieser Artikel zeigt erste Schritte auf dem Weg, Ordnung in die Vielzahl der Möglichkeiten zu bringen.

Die Versteh-Maschine bauen

(dotnetpro 12/2009, Seite 119)
Eine Abstraktionsschicht oberhalb der Implementierung: Alle Welt kann sie dringend brauchen. Damit könnten Mitarbeiter der Fachabteilungen ihre Geschäftsregeln festlegen, Projektmanager die Anforderungen an die Software definieren und Entwickler modellgetrieben entwickeln. Einige neuere OMG-Standards unterstützen genau diese Abstraktionsschicht.

Neues aus dem Softwareuniversum

(dotnetpro 12/2009, Seite 110)
Nicht nur das reale Universum expandiert, sondern auch das Softwareuniversum. Nun hat es die Ebene der Anwendungsarchitektur erreicht. Der Effekt: Architektur abstrahiert, immer mehr weg von konkreter Technik, hin zu echten logischen Konzepten.

Vertragt euch!

(dotnetpro 12/2009, Seite 130)
Design by Contract erhält mit der Code-Contracts-Bibliothek einen festen Platz im .NET Framework 4.0. Der erste Teil der Serie hat die Bestandteile und Konzepte von Design by Contract und Code Contracts grundlegend vorgestellt. Dieser zweite Teil vertieft ausgewählte Aspekte, etwa die Vererbung von Verträgen, und erklärt die Unterschiede zu Konzepten wie Test-Driven Design.

Ein Sumpf wird grün

(dotnetpro 11/2009, Seite 130)
Eine bestehende monolithische Anwendung mit Unit-Tests nachzurüsten ist möglich, wenn auch kein Spaziergang. Es besteht kein Grund, davor Angst zu haben. Ein kleines Programm zum Wortezählen hat gezeigt, wie der Weg dorthin mit Integrationstests beginnt und über aufgetrennten Code führt. Das Ziel: Separate Komponenten und Kontrakte – und schon sind Unit-Tests möglich.

Vertraglich abgesichert

(dotnetpro 11/2009, Seite 124)
Eigenschaften und Verhalten eines Codeelements mit einer Spezifikation explizit ausdrücken – das ist das Ziel von Design by Contract. Das Konzept erlebt derzeit eine Renaissance, da es mit der Code-Contracts-Bibliothek Einzug in das .NET Framework 4.0 hält. In einer zweiteiligen Serie erläutert dotnetpro Prinzipien, Technologie und Anwendung von Design by Contract und Code Contracts.

Den Sumpf trockenlegen

(dotnetpro 10/2009, Seite 130)
Wer Software schreibt, sollte sie sofort auch selbst testen. Aber nicht irgendwie, sondern automatisiert mit Unit-Tests. Das ist keine wirklich neue Erkenntnis. Dennoch ist solches Vorgehen immer noch keine selbstverständliche Praxis. Da stellt sich die Frage: Warum nicht?

Doppelt genäht hält besser

(dotnetpro 09/2009, Seite 130)
Wer seine Software als Komponenten entwickelt, hat beim Outsourcing die Nase vorn. Denn eine solide Komponentenorientierung stellt alle Instrumente zur Verfügung, um Dienstleister so genau wie möglich zu beauftragen – damit das fertige Produkt so aussieht, wie es gedacht war, und sich Korrekturen minimieren.

Schnuppern am Application Space - Teil 2

(dotnetpro 08/2009, Seite 124)
Mit seinem Heckle-Service hat Christian Weyer eine Beispielanwendung für Windows Azure vorgestellt. Ralf Westphal hat einen sehr ähnlichen Zwischenrufdienst mithilfe des Application Space konzipiert. Nun werden die Clients für Referent und Teilnehmer implementiert.

Appspace im Einsatz

(dotnetpro 07/2009, Seite 131)
Mit seinem Heckle-Service hat Christian Weyer eine Beispielanwendung für Windows Azure vorgestellt. Ralf Westphal konzipiert hier einen sehr ähnlichen Zwischenrufdienst mithilfe des Application Space.

Appspace Grundlagen

(dotnetpro 07/2009, Seite 124)
Es geht auch einfach. Komponenten über die Weiten des Internets miteinander kommunizieren zu lassen, muss nicht schwierig sein. Das Baukastensystem Application Space vereinfacht vielschichtige Aufgaben.

Kolumne

(dotnetpro 06/2009, Seite 126)
Parallelverarbeitung können Sie auch anders implementieren als mit den üblichen Threads. Mit dem richtigen Framework können Sie einfach Aufgaben für Dienste zur Ausführung „einplanen“, indem Sie ihnen Nachrichten schicken. Die Concurrency and Coordination Runtime von Microsoft macht das möglich.

Alles fließt koordiniert

(dotnetpro 05/2009, Seite 120)
Mit Microsofts Concurrency Coordination Runtime lassen sich die Details des Multithreadings verbergen. Sequenzielle Prozessschritte können Sie über Ports miteinander koppeln und dadurch parallelisierbar machen.

Architekturen vermitteln

(dotnetpro 05/2009, Seite 129)
Wenn Softwarearchitektur über das reine Benennen von Schnittstellen und Komponenten hinausgeht, bedarf sie in der Regel einiger Erläuterungen. Besser noch wäre ein Verfahren, mit dem sich eine Spezifikation gleich in Programmcode umwandeln ließe. Dieser Artikel stellt eine Möglichkeit vor.

Kanalfahrt ohne Hindernisse

(dotnetpro 04/2009, Seite 124)
Langsam dämmert die Erkenntnis: Softwareentwicklung erfordert künftig einen neuen Ansatz: den der Parallelverarbeitung. Klingt kompliziert, muss es aber nicht sein. Microsoft bietet einen Mechanismus, der das Entwickeln mit Threads abstrahiert. Dazu gehört aber auch ein neuer Denkansatz seitens des Entwicklers.

PISA für Entwickler

(dotnetpro 03/2009, Seite 131)
Nach den ersten stürmischen Jahren ihres überschaubaren Lebens ist die Softwareentwicklung an einem Punkt angekommen, an dem sie und ihre Protagonisten, die Entwickler, erst einmal innehalten und sich auf ein Wertesystem besinnen sollten. Das meint zumindest dotnetpro-Philosoph Ralf Westphal und plädiert für den „Clean Code Developer“.

Rundum-Türsteher-Service

(dotnetpro 03/2009, Seite 124)
Das Konzept anspruchsbasierter digitaler Identitäten soll das Zusammenschalten von Zugangsdiensten auf Grundlage von WS-Standards ermöglichen und den Zugangsmechanismus von Anwendung und Plattform entkoppeln. Unter Windows war der Umgang damit bisher aufwendig und kompliziert. Die Plattform Geneva soll das ändern.

Grundlagen skalierbarer Parallelverarbeitung

(dotnetpro 02/2009, Seite 128)
Parallelverarbeitung muss nicht schwierig sein. Zwar gilt es, bei der Koordinierung gleichzeitiger Aktivitäten mehr zu bedenken als bei der üblichen synchronen sequenziellen Verarbeitung. Doch davon sollten Sie sich nicht ins Bockshorn jagen lassen.

Ein Framework zum Umgang mit Parallelverarbeitung

(dotnetpro 01/2009, Seite 128)
Die Zukunft der Softwareentwicklung liegt in der Parallelverarbeitung – daran führt früher oder später kein Weg vorbei. Nur wenn das Potenzial jeder Anwendung in dieser Hinsicht erkannt und ausgeschöpft wird, kann sie von der wachsenden Zahl an Prozessorkernen profitieren.

Architekturmuster für die Problemdomäne

(dotnetpro 12/2008, Seite 130)
Wie erstellt man die Architektur für die Problemdomäne? Soll man sich hier besser auf die Daten oder auf die Prozesse konzentrieren? dotnetpro unternimmt einen Streifzug durch die verschiedenen Architekturmuster, von Transaction Script über Table Module und Active Record bis hin zu Domain Model. Besonders spannend: Manche Pattern sind in .NET und Visual Studio bereits fest eingebaut.

Eine Architektur für Legacy-Code, Teil 4

(dotnetpro 12/2008, Seite 126)
Das Migrieren einer bestehenden Anwendung kann eine spannende Sache sein – wenn Sie es richtig angehen. Im letzten Teil der Serie führen Sie die Erkenntnisse der Analyse der Anwendung zusammen und gießen sie zu einem neuen Innenleben für die Software. Dabei machen Sie diese gleich fit für künftige Anpassungen.

Eine Architektur für Legacy-Code, Teil 3

(dotnetpro 11/2008, Seite 118)
Den Legacy-Code einer bestehenden Anwendung zu durchforsten, um ihn für Erweiterungen oder eine neue .NETVersion vorzubereiten: wie öde! Oder auch nicht – wenn Sie richtig dabei vorgehen und sich nicht in Codedetails verzetteln. Mit den entsprechenden Werkzeugen ist es kein Problem, sich unbekanntem Code zu nähern.

Programmlogik aspektorientiert prüfen

(dotnetpro 11/2008, Seite 124)
Vereinbarungen innerhalb von Software sind ebenso relevant wie in der realen Welt. Nur gehört ihre Prüfung nicht unbedingt zu den eigentlichen Aufgaben einer Software. AOP und das Framework PostSharp erlauben es, Software logisch zu beweisen, ohne den Code der Geschäftslogik zu überfrachten.

Die Zukunft ist asynchron

(dotnetpro 10/2008, Seite 121)
Zwischen einem Flaschenzug und einer Computeranwendung besteht prinzipiell kein Unterschied. Beide setzen eine Kette von synchronisierten Aktionen in Gang. Doch die Entwicklung der Hardware hin zu Mehrfachprozessoren verlangt von der Softwareentwicklung eine neue Sicht auf Funktionen – nämlich eine asynchrone.

Tolle Typen

(dotnetpro 10/2008, Seite 114)
Datenstrukturen gehören zu den Grundpfeilern einer Anwendung. Sie bieten rudimentäre Gültigkeitsüberprüfungen und Anwendungslogik. Unter dem Blickwinkel einer Gesamtarchitektur können sie jedoch problematisch sein, wenn sie nur ungenügend mit anderen Aspekten abgestimmt sind. Metainformationen können das Problem lösen.

Die individuelle Architektur

(dotnetpro 09/2008, Seite 123)
Architektur ist wesentlich mehr als das Aufbauen von Anwendungsschichten. Denn die Anforderungen sind für jede Anwendung anders. Ralf Westphal, Content Manager der prio.conference 2008, erklärt im Interview, was die Teilnehmer auf der Konferenz lernen können.

Eine Architektur für Legacy-Code, Teil 2

(dotnetpro 09/2008, Seite 124)
Legacy-Code muss nicht vom Mainframe stammen. Auch .NET-1.0-Code gilt bereits als „Vermächtnis“ von früher. Gehen Sie bei einer Migration systematisch vor! Erarbeiten Sie sich die Problemdomäne. Entwerfen Sie den SOLL-Zustand. Dann können Sie damit beginnen, alten Code Stück für Stück iterativ vom IST zum SOLL zu übertragen.

Vom Model-View-Controller zum Model-View-ViewModel

(dotnetpro 08/2008, Seite 129)
Seitdem das Model-View-Controller-Muster das Licht der Welt erblickt hat, haben sich die Ansätze zur Architektur von Anwendungen weiterentwickelt. Um dieser Entwicklung gerecht zu werden, hat sich auch Model-View-Controller angepasst. Seine jüngste Variante heißt Model-View-ViewModel.

Erweiterbare Anwendungen aufbauen

(dotnetpro 08/2008, Seite 128)
Das Microsoft Add-in Framework (MAF) ist eine neue Möglichkeit, Anwendungen erweiterbar auf zubauen. Jörg Neumann wird das Framework auf der prio.conference 2008 vorstellen. dotnetpro sprach mit ihm, welche Vor- und Nachteile es bringt.

Scrum und Architektur

(dotnetpro 07/2008, Seite 141)
Scrum ist eine agile Technik, um Softwareprojekte abzuwickeln. Doch ist diese Managementmethode architektur - neutral? Oder erzwingt sie, Anwendungen in ganz bestimmter Architektur zu gestalten? Eine Diskussion.

Methodik des Softwarebaus

(dotnetpro 07/2008, Seite 136)
Das Entwickeln von Software braucht mehr Regeln. Diese These vertritt dotnetpro-Autor Ralf Westphal und hat sich aufgemacht, diesen Missstand zu beheben. Denn wo Regeln herrschen, muss sich niemand den Kopf zerbrechen und hat Zeit und Muße für die anwendungsspezifischen Probleme.

WCF-Serverentwicklung

(dotnetpro 06/2008, Seite 134)
Keine andere Problematik wird so kontrovers diskutiert wie die Trennung von Business Layer und Datenbank. Dabei steht sie nur stellvertretend für ein Grundproblem der Informatik: Was ist Anwendungslogik und wie kann sie auf die Bestandteile der Anwendung verteilt werden? Dieser Artikel gibt einen Überblick über die Details der Fragestellung und zeigt Lösungsansätze.

Kolumne: Konventionen beim Softwareentwurf: Microkernel

(dotnetpro 06/2008, Seite 126)
Wie beim Hausbau braucht auch die Entwicklung von Software Konventionen, um Qualität erreichen zu können. Leider gibt es derzeit davon zu wenig. Mehr Konventionen würden den Entwickler besser leiten, ihm Arbeit und Entscheidungen abnehmen sowie mehr Zeit verschaffen, sich um das eigentliche Problemfeld der Software zu kümmern.

Architektur- und Entwurfsmuster für Office Business Applications

(dotnetpro 04/2008, Seite 142)
Die Programmierung unter Microsofts Office-Plattform wird vielfach unterbewertet und oft noch mit einfacher VBA-Makroprogrammierung gleichgesetzt. Dabei ermöglicht sie mit eigenen Architektur- und Entwurfsmustern die Entwicklung komplexer Geschäftsanwendungen für Office, die durchaus den Ansprüchen an moderne Softwarearchitektur genügen.

Architektur-Kolumne mit Aufmacher

(dotnetpro 04/2008, Seite 136)
Aus einer Handvoll Kundenanforderungen folgt die beste Architektur aller Zeiten. Ohne Zweifel? Ohne Alternativen? Nein: Es gibt keine beste Architektur, denn diese hängt nicht zuletzt vom zugrunde liegenden Wertesystem ab. Und auf den Geschmack kommt es dann auch noch an.

Wertesystem als Grundlage

(dotnetpro 03/2008, Seite 120)
Was man nicht messen kann, kann man auch nicht kontrollieren. Zur Steuerung gehört aber noch der Plan, wie die Messwerte im Idealfall aussehen sollen. Ein Wertesystem also. Dass es so etwas auch für die Architektur geben muss, dafür plädiert Ralf Westphal.

Mustererkennung visualisieren: Die grafische Umsetzung

(dotnetpro 03/2008, Seite 135)
dnpPatViz, das Mustererkennungsprogramm für jegliche Art von textlich erfassbaren Mustern, gedeiht. Nun fehlt für die nächste Version nur noch die grafische Anzeige von Mustern in Form von Bögen. Dazu erhält die Software noch ein UserControl, das diese Aufgabe übernimmt – und dazu noch einen FileAdapter für Midi-Daten.

WPF-Anwendungen strukturiert aufbauen

(dotnetpro 03/2008, Seite 124)
Unter WPF führen oft mehrere Wege zum Ziel. Layoutanweisungen können im XAML-Code, im Code einer Klasse oder in einem Stylesheet hinterlegt sein. Wer da nicht Ordnung hält, ver - heddert sich leicht in unübersichtlichem Spaghetti-Code. Strukturieren Sie Ihre WPF-Anwendung lieber so wie eine Prinzregententorte: schichtweise. Das erleichtert auch die Arbeit im Team.

Anzeige