01.12.2006
Alles eine Frage der Haltung
SOA steht für Service Oriented Architecture. Eigentlich. Diese Auflösung des Akronyms zeigt an: Hier geht es um Technologie. Doch das führt in die Irre. Denn bei SOA geht es nicht um Technologie, sondern um eine Haltung. Das ist mir bei der Lektüre von Rainer Graus Artikel in der dotnetpro [1] noch einmal klar geworden. Das Akronym SOA sollte stehen für Service Oriented Attitude.
weiterlesen
01.11.2006
Einstieg in den praktischen Softwareentwurf, Teil 6
„Welche Operationen wünscht sich ein Client von seinem Service?“ Die Modellierung der Kontrakte zwischen den Komponenten steht im Mittelpunkt dieser Folge zum Softwareentwurf. Verfolgen Sie die Wertströme bis an ihr Ziel. Bilden Sie für jedes Client-Service-Paar einen Vertrag über die Zusammenarbeit. Und was kommt dabei heraus? Code!
weiterlesen
01.11.2006
Öffentliche Qualität
Früher hat mich vor allem Softwaretechnologie interessiert. Damals habe ich das CP/M BIOS direkt anprogrammiert und sogar verändert. Damals habe ich mich mit den Feinheiten der 3-D-Grafikprogrammierung beschäftigt. Damals waren ADO.NET Details für mich wichtig. Das hat sich in den letzten Jahren verändert. Jetzt beschäftigen mich weniger die Technologien als vielmehr der Kontext, in dem sie eingesetzt werden. Die Architektur von Software ist für mich zum zentralen Thema geworden, also die Frage, wie Code organisiert sein sollte, damit er nicht nur funktionalen, sondern auch nicht-funktionalen Anforderungen genügt. In diesem Zusammenhang stehen Aspekte wie systematische Codeproduktion, Korrektheitstests oder ganz allgemein Softwarequalität.
weiterlesen
01.11.2006
LINQ ? Language Integrated Query
Die Version 2.0 des .NET Framework setzte einen Meilenstein in der Weiterentwicklung von C#. Generics, die sich auch im IL-Code widerspiegeln, kennzeichnen eines der wichtigsten Features von diesem Release. Partial classes, nullable types und access modifiers bei Properties sind einige der weiteren Features von C# 2.0.
weiterlesen
01.10.2006
Einstieg in den praktischen Softwareentwurf, Teil 5
Halbzeit Den Aufwand schätzen, die Releases planen, das Datenmodell definieren: Darum geht es in dieser Folge zum Softwareentwurf. Die Grundlage dafür bilden auch hier die Features, die bereits am Anfang der Projekts definiert wurden. Mit diesen Schritten ist die Hälfte des Weges zum fertigen Produkt zurückgelegt. Die Implementierung rückt in greifbare Nähe.
weiterlesen
01.10.2006
SharePoint für Entwickler
Dass sich der Microsoft SharePoint Portal Server und sein kleiner Bruder, die Windows SharePoint Services, für webbasierte Zusammenarbeit, Dokumentenverwaltung und zentrale Informationsablage eignen, ist vielen Lesern der dotnetpro vielleicht bekannt.
weiterlesen
01.09.2006
Einstieg in den praktischen Softwareentwurf, Teil 4
Am Anfang ist der Anwender. Als Client benutzt er über das Frontend die Funktionen, die die Software als Service anbietet. Dieses Modell von Konsumenthier und Service - anbieter dort zieht sich durch die gesamte Softwarearchitektur. dotnetpro zeigt, wie Sie auch die Funktionen der Benutzerschnittstelle auf diese Weise systematisch modellieren.
weiterlesen
01.09.2006
Der Preis ist heiß
Wie viel sollte Software eigentlich kosten? Am besten natürlich gar nichts – jaja, ich weiß. Aber im Ernst: Je länger ich über die Preisbildung von Software nachdenke, desto unsicherer werde ich. Denn irgendwie scheint mir die Softwareindustrie mit dieser Frage noch nicht ganz im Reinen.
weiterlesen
01.08.2006
Einstieg in den praktischen Softwareentwurf, Teil 3
Die Anforderungen an die Software sind definiert. Ein erster Strukturentwurf bestimmt die Bauteile der Software. Im nächsten Schritt untersuchen Sie, wie diese Softwareteile miteinander kooperieren. Verfolgen Sie ausgehend vom Anwender die Wertströme durch die Software. Basierend auf diesen Wertströmen können Sie anschließend Kontrakte für einzelne Funktionen definieren.
weiterlesen
01.08.2006
Software as a Factory?
Analogien haben Macht! Sie haben die Macht, uns weiterzubringen; sie haben aber auch die Macht uns einzuzwängen. Die richtige Analogie zur rechten Zeit hilft uns, ein Problem zu lösen. Aber eine falsche Analogie versperrt uns den Weg zum Ziel.
weiterlesen