Rock Solid Software Architecture with ADRs, arc42 and Microsites - Ein Erfahrungsbericht en

Das arc42-Architektur-Template verleitet dazu alle Kapitel von oben nach unten durchzuarbeiten. Ein Architektur-Review offenbart aber eine sinnvollere Herangehensweise, um Softwarearchitektur zu erarbeiten. Dabei wird zuerst der In-Scope und Out-Of-Scope des Vorhabens definiert, anschließend Qualitätsattribute aufgenommen um schließlich konkrete Qualitätsszenarien abzuleiten.

Die Dokumentation dieser Ergebnisse im arc42 stellt uns vor viele Aufgaben und Fragestellungen: Wie erarbeite Architekturentscheidungen, Qualitätsattribute und Qualitätsszenarien? Und wie dokumentiere ich sie effizient?

In diesem Vortrag zeigen wir anhand des Docs-as-Code Ansatzes, wie wir mit dem arc42-Template effizient arbeiten und die Dokumentation als Microsite jedem zur Verfügung gestellt wird. Durch diese Vorgehensweise ist es effizient möglich eine Architekturdokumentation zu erstellen, die jedem Review standhält.

Modern software architecture documentation hands on en

Architecture documentation is very often treated stepmotherly. Yet documentation supports the design work and creates transparency and guard rails for the implementation and maintenance of the software architecture. On the one hand, it is not simple however to hold the important information from the draft of the software architecture structured and easily understandable. On the other hand, most attempts in search of practicable handling for creation and maintenance end in the WYSIWYG hell of a word processor or the deep maw of a wiki. Building on lightweight tools and text formats, this workshop shows how to create documentation that is as redundancy-free as possible and can be delivered in appealing formats optimized for different target groups.

With the help of many practical exercises, the seminar deals with concepts such as Continuous Documentation and Documentation as Code. The goal is modern, effective, and pragmatic documentation of software architecture. We build on proven methods, formats, and tools like AsciiDoc/Markdown, PlantUML, docToolchain, Maven/Gradle, jqAssistant, and many more. In detail, we take care of the automation of the documentation build process, the generation of content from the model, database schema or source code, the structured storage including versioning and historicization, and the use or creation of meaningful and easily maintainable graphics.

Agile development teams can thus integrate documentation work into their daily tasks and deliver up-to-date, comprehensive, and well-structured results at any time. In addition, the creation of documentation can be integrated into the review process and thus constantly improved and further developed.

How to document and communicate software architectures these days en

Our software projects are getting bigger and more complex. Technologically, a lot has been done in recent years to get this complexity under control. But communication between all project stakeholders has become even more important. A prerequisite for this is documentation of the software architecture. It should be as up-to-date, pragmatic and goal-oriented as possible. But unfortunately, documentation often has a low priority in our projects. In some cases, those responsible lack the motivation. Or suboptimal tools like word processing, heavyweight UML tools or wikis nip all efforts in the bud.

We want to end prejudices and show with concrete examples how documenting can not only be fun, but also easy. We will talk about our experiences and focus on lightweight tools and lean text and graphic formats. They facilitate the automated creation of effective, comprehensive and, above all, redundancy-free documentation that can be delivered in various formats with little effort and optimized for different target groups. Embedding this documentation as code in the development and review processes also enables good traceability, continuous improvement and further development.

Spock und AsciiDoc – Vom Test zur Spezifikation und zurück de

Spock ist ein Testframework für Webanwendungen, mit dem man unter Anderem den Behavior Driven Development Ansatz, kurz BDD, verfolgen kann. Der Product Owner beschreibt das Verhalten einer Applikation und der Entwickler überprüft es über einen automatischen Test. Dem Entwickler reicht die Ausgabe "PASSED" oder "FAILED", denn er kennt ja den Code seiner Tests.

Wäre es nicht cool, wenn auch der Product Owner ein verständliches Dokument bekäme? Kein Problem! Wir generieren über ein Template einfach einen Test-Report in AsciiDoc und fügen weitere erklärende Texte hinzu um eine les- und ausführbare Spezifikation zu erhalten. Screenshots aller wichtigen Schritte bereichern die Spezifikation weiter. Sollte aber die Spezifikation nicht am Anfang stehen? Und warum Spezifikation, wenn wir agil sein wollen? Richtig!

Stellen wir also eine iterative Feature-Beschreibung an den Anfang und verfeinern diese mit automatischen Tests um am Ende eine gut lesbare und verifizierbare Spezifikation des Verhaltens unseres Systems zu erhalten! Die Vorteile liegen auf der Hand – die Vorgehensweise verbessert die Kommunikation zwischen Product Owner und Entwicklern und am Ende bekommen wir ein Dokument welches Ihre wertvolle Software korrekt und überprüfbar beschreibt.

Prompt-Engineering for Developers en

At a time when large language models such as OpenAI's GPT series are becoming increasingly important, developers and software architects are faced with the exciting challenge of making the best use of these technologies in chat applications. The quality of interaction with such models depends largely on how precisely and thoughtfully our queries are formulated.

In this talk we will take a look at LLMs like chatGPT from the user's perspective. We will learn how we as developers can use modern AI to get better in what we do.

The first part of the talk dives deep into the art of "prompt engineering". Here we look at how targeted "priming" can be used to steer the AI in certain answer or thought directions. This subtle control of the AI makes it possible to obtain answers that are precisely tailored to the context and the needs of the user. We also look at the differences and areas of application of few-shots, zero-shots and many-shots. Each of these approaches has its own strengths and it is crucial to understand when and how they can best be used in chat applications. The challenge of limited token counts and strategies to achieve clear, coherent and helpful responses within this limitation will be highlighted.

As a special bonus of the talk, we will briefly discuss the use of embeddings, which enable topic-specific communications with AI and thus further increase the relevance of the answers.

W-JAX 2023