Abstract
Good design and implementation are necessary but not sufficient pre-requisites for the successful reuse of object-oriented frameworks. Although not always recognized, good documentation is crucial for effective framework reuse and comes with many issues. Defining and writing good quality documentation for a framework is often hard, costly, and tiresome, especially when not aware of its key problems and the best ways to address them. This document presents patterns from a set of related patterns that describe proven solutions to recurrent problems of documenting object-oriented frameworks. The pattern language they all form together aims at helping non-experts on cost-effectively documenting object-oriented frameworks. The patterns here presented address the problems of explaining how to use a framework and illustrating what it can be good for, respectively the patterns "COOKBOOK & RECIPES" and "GRADED EXAMPLES".

Abstract
Good documentation benefits every software development project, especially large ones, but it can be hard, costly, and tiresome to produce when not supported by appropriate tools and methods. The documentation of a software system uses different artifacts, namely source code, for low-level internal documentation, and specific-purpose models and documents, for higher-level external documentation (e.g. requirements documents, use-case specifications, design notebooks, and reference manuals). All these artifacts require continual review and modification throughout the life-cycle to preserve their consistency and value. Good software documents are often heterogeneous, i.e., they combine different kinds of contents (text, code, models, images) gathered from separate software artifacts, a combination usually difficult to maintain as the system evolves over time, considering that source code, models and documents are typically produced and maintained separately in multiple sources using different environments and editors. This paper presents a wiki that helps on quickly weaving different kinds of contents into a single heterogeneous document, whilst preserving its semantic consistency. The fundamental goal of this wiki (XSDoc Wiki) is to reduce the development-documentation gap by making documentation more convenient and attractive to developers. An example taken from the JUnit framework documentation helps to illustrate the features more relevant to do such weaving. Copyright 2005 ACM.

Abstract
Good design and implementation are necessary but not sufficient pre-requisites for successfully reusing object-oriented frameworks. Although not always recognized, good documentation is crucial for effective framework reuse, and often hard, costly, and tiresome, coming with many issues, especially when we are not aware of the key problems and respective ways of addressing them. Based on existing literature, case studies and lessons learned, the authors have been mining proven solutions to recurrent problems of documenting object-oriented frameworks, and writing them in pattern form, as patterns are a very effective way of communicating expertise and best practices. This paper presents a small set of patterns addressing problems related to the framework documentation itself, here seen as an autonomous and tangible product independent of the process used to create it. The patterns aim at helping non-experts on cost-effectively documenting object-oriented frameworks. In concrete, these patterns provide guidance on choosing the kinds of documents to produce, how to relate them, and which contents to include. Although the focus is more on the documents themselves, rather than on the process and tools to produce them, some guidelines are also presented in the paper to help on applying the patterns to a specific framework. © 2011 Springer-Verlag Berlin Heidelberg.

Abstract
Good design and implementation are necessary but not sufficient pre-requisites for the successful reuse of object-oriented frameworks. Although not always recognized, good documentation is crucial for effective framework reuse but comes with many issues. Writing good quality documentation for a framework is often hard, costly, and tiresome, especially when not aware of its key problems and the best ways to address them. This document presents two of a set of related patterns that describe proven solutions to help non-experts on solving recurrent problems of documenting object-oriented frameworks. The patterns here presented address the problems of describing the customization points of the framework and how such customization is supported, respectively the patterns Customization Points and Design Internals. Copyright 2006 ACM.

Abstract
Despite documentation being considered the primary challenge to agile methods in safety-critical software systems development [1], agile would be of particular interest to improve changeability while providing efficiency and effectiveness to all the phases of software development. In this work, we created mechanisms for automating document processing and management to improve the efficiency and effectiveness of documentation activities of safety-critical software systems development, most concretely in the aerospace domain. The implemented tools were co-designed and validated iteratively in the concrete industrial context of Critical Software (CSW) projects, within a wider research work towards continuous certification [3]. We interviewed Critical Software professionals to validate our solution, collected feedback on the implemented tools and got insights for future work. The tools were also the target of synthetic tests that allowed us to conclude that document automation is possible in the critical-safety software development industry and carries several benefits. The developed tools are not yet qualified in compliance with the DO-330 standard (Tools Qualification).

Abstract
Context: Low-code development is a concept whose presence has grown both in academia and the software industry and is discussed alongside others, such as model-driven engineering and domain-specific languages. Usability is an important concept in low-code contexts since users of these tools often lack a background in programming. Grey literature articles have also stated that low-code tools have high usability.Objective: This paper examines the current literature about low-code and no-code to discover more about them and their relationship with usability, particularly its quality, which factors are the most relevant, and how users view these tools. This focus on usability aims to provide a different point of view from other works on low-code.Method: We performed a systematic literature review based on a formal protocol for this study. The search protocol returned a total of 207 peer-review articles across five databases, which was supplemented with a snowballing process. These were filtered using inclusion and exclusion criteria, resulting in 38 relevant articles that were analysed, synthesised and reported.Conclusion: Despite growing interest and a strong enterprise presence in academia, we did not find a formal definition of low-code, although common characteristics have been specified. We found that users have a heightened awareness of usability regarding low-code tools, with some authors performing feasibility studies on their implementations or listing factors that influence the user experience in a given tool. Researchers are considering usability factors unconsciously, and the low-code field would grow if research on usability increased. This paper also suggests a definition for low-code development.