Form-Oriented Concepts

Concepts for Modeling of Submit/Response Style Applications

• Domain-Specific Modeling. Our modeling contributions start from a defined application domain. The modeling methods are developed towards this concrete area. We do not start out with the claim of presenting a universal method, able to model all systems from embedded systems to computing grids. Of course we can expect to find other application areas for our approaches. But they will show up through time. This approach is therefore a more patient one.
• Black-Box Modeling at the User Interface. We follow a particularly fundamental and mature approach to system modeling, namely the black-box modeling approach. The interface of our black box is the user interface, hence the only computer interface that can be touched by the user. In order to make the black-box modeling work we have to define the human-computer interaction paradigm we want to use, namely submit/response style systems.
• Submit/Response Style Systems. The human-computer interaction is modeled as a strictly alternating message exchange between user and system. The system messages have the character of reports; they do not change once they have been sent to the user. After submission of a form the next page is shown automatically. In the submit/response style interface model the user action of providing a message to the system is intricately combined with the previous system message in that the form is embedded into the report and the presented information can be directly and symbolically reused by the user. Submit/response style systems are successful, due to their advantageous software system architecture, which fosters scalability and maintainability.
• Two-Staged Interaction Paradigm. Submit/response style systems are the natural solution for a wide range of business and administrative applications. Working with submit/response style systems has cognitive advantages because of an inherently easy form metaphor. The next message the user wants to send to the system appears as a form, which can be edited by the user and then submitted. Therefore submit/response style systems follow a two staged interaction paradigm. The work is divided by single explicit system interaction points into protected bunches of work concerning editing single forms. Form orientation relies on defined user interface modeling as an integral part of requirements specification and analysis. Thereby it exploits the two staged interaction paradigm to define bipartite state transition diagrams for modeling user interfaces, namely form storyboards and formcharts.
• Transparency of Page Interaction. In modeling the submit/response style interface we have an elegant abstraction from the detailed workings of the input devices. There is no need to model the fine-grained interaction of the user with the page in order to fill out forms and to navigate between input forms. This user interaction is transparent, i.e. the user and the modeler have the impression that the user works directly on the form.
• Direct Manipulation of Opaque References. The form metaphor goes beyond the paper form metaphor, especially concerning the dealing with references to entities in the system. The user can manipulate the references abstractly, without seeing their internal representations, i.e. as numerical keys or whatever. This knowledge not only can be used to create new widgets for conventional browsers, it can also be used to create a novel integrated client concept altogether.
• Page Diagram Modeling. How do you start in a project developing a web-based application? You could start by painting the system welcome page on a blackboard. Then you continue to paint more and more pages and to connect them by arrows representing links or possible form submissions. This would be a rational way to actuate modeling of a submit/response style software system. Page diagrams offer a conceptual basis. Though natural, the outlined process may quickly become bulky. But with the concept of conservative model decomposition the process can be intuitively split into manageable parts. Well-understood page diagram modeling will hel. Page diagrams are coarse-grained state transition diagrams.
• Form Storyboarding. Form storyboards are designed with respect to informal communication between domain experts and system analysts. The special way that signatures of server actions are visualized as forms make form storyboards capable of serving as mock-up prototypes. Form storyboards can be transformed into formcharts without structural friction.
• Fully Typed Modeling. Using the fundamental concept of static typing rigorously in the modeling approach pays off. The static types give an easy interpretation of the finiteness of the state model. We can use the type system itself as the definition language for pages as well as for forms. The type system therefore replaces a markup language and immediately yields maximal separation of content from presentation. The pure type description of the pages and forms creates an interface model, which is bare metal and high-level at the same time. The consistent use of the type system also allows for an unprecedented amount of reuse. For example, the same record definition may be used in the page description, the form definition, the database model, as well as in all mediating business operations.
• Formcharts. Formcharts depict the bipartite state machine of a form-oriented user interface model. They are used for rigorous software system specification. They are annotated with precise dialogue specifications and are integrated with a layered data model.
• Conservative Model Decomposition. A notion of model decomposition is conservative if it is minimal and semantically compatible. It is minimal if the hierarchy resulting from the decomposition is just a partial order on pieces of the whole model, i.e., no additional structuring elements are introduced during decomposition. It is compatible with the model semantics if the model pieces resulting from a decomposition are again self-contained models. The defined model decomposition of form orientation diagrams is conservative; it is based on pure graph union as the composition mechanism. Conservative model decomposition enables feature modeling.
• Feature-Driven Approach. Consider the following simple system requirement: the user wants to reach an overview page from everywhere. A use-case based approach must fail in modeling this feature. A use-case driven approach must fail in finding this feature. The form-orientated diagrams introduce a notation for system state collections, which enables modeling features and a feature-driven approach. Thereby use cases become a special kind of feature. The conservative model decomposition ensures the maintainability of features.
• Layered Data Modeling. Form orientation explicitly admits non-transparency for phenomena that are well understood and which can and must be considered during early phases of software engineering without essential loss of generality. In form orientation the data model is layered. It consists of an information model for persistent data and a user message model for data that are exchanged during human-system interaction. Data types of the semantic data model have defined semantics with respect to the data dictionary: every information model type implicitly introduces an opaque reference message type.
• Dialogue Constraints. Dialogue specifications annotate the formchart. They are written with respect to both the layered data model and the dialogue history. For every formchart element several kinds of specifications are predefined and given semantics. Several kinds of specifications can be identified that constitute no specification overhead and can be recovered directly during system implementation.
• Taking Transactions Seriously. Transactions are of crucial importance for enterprise applications. The achievement of the sophisticated transactional core technologies, the database and the transaction monitor, is the establishment of a virtual machine, in which every transaction client has a virtual serial view of the transactional core system. These transactional clients are supposed to finish transactions quickly and automatically. The transactional paradigm has such serious implications that it dominates the system architecture. Many universal modeling techniques fail to address transactionality with adequate high priority. Our modeling method gives the transactional paradigm a central and leading role. In a strict ranking of priorities it is decided that nice metaphors like object orientation have to go for good if there is no clear compatibility with transactionality.
• Dialogue Patterns. Form orientation is not about modeling bottle receivers, traffic lights, coffee machines, etc. The world of form orientation is the mundane world of forms, i.e. purchase orders, receipts, invoices, etc. What are the workflow patterns dealing with these entities with respect to human-computer interactions? Form orientation enables the formulation of such dialogue patterns: from the outset examples from real-world enterprise applications are provided.
• Forward and Reverse Engineering of Presentation Layers. The language Angie is a specification language for web-based presentation layers that is oriented towards the NSP type system. The language Angie can be seen as a textual format of formcharts. It is already successfully exploited by the fully implemented tools JSPick and Angie. The JSPick tool is a design recovery tool for Java Server Pages based web presentation layers that generates high-level system descriptions in an Angie dialect. The Angie tool generates a complete Java Server Pages based prototypical dialogue from a high-level system description.
• Strongly Typed Server Pages. The Next Server Pages technology is a server pages technology that is fully integrated with the concepts of form orientation. A notion of correctness is defined that can be statically checked and ensures a type-safe interplay of generated forms and targeted server pages as well as the generation of valid documents with respect to a defined user interface description language. A formal definition of the static semantics of the Next Server Pages technology has been given as a Per Martin-Löf style type system. Case studies exemplify how the impedance mismatch between modeling and implementation is mitigated by the approach.

The Main Contributions to Modeling in General

• Artifact Orientation. We do not prescribe a process. Instead we pursue artifact orientation from the outset. Well-understood artifacts are a key in software development in their own right. The implicit objective of some state-of-the-art software processes is to decouple artifacts from processes, however, resulting in sometimes complex, e.g. spiral or two-dimensional process structures. Despite defined tailoring, some of these processes tend towards clumsy prescriptiveness and micro management. There are a great many project driving forces. They are different in every project. We doubt that it is possible to have a general purpose software development process, unless it is ultra-lightweight. Artifact orientation is about posing a permanent question: how to proceed in order to contribute most effectively to the growth and quality of a defined project-dependent artifact set.
• High-Level Programming. A constraint-based specification is in general not executable. It can be incomplete, unique, or unsatisfiable. Moreover, it can be redundant. The satisfiability is in general not a mechanically decidable question. This not only limits automatic generation of systems, it may also be unwanted from a modeling point of view, since both the generator and the modeler may find it hard to understand some models. High-level programming refers to the concept of having a programming paradigm on the same level as the constraint specification paradigm, which allows a guaranteed unique and executable specification to be given. This is in many cases the more natural definition, e.g. for a simple insert operation we have seen that the specification with pre and post conditions is cumbersome in comparison to an insert command. Imperative-style programming is not always less abstract than declarative.
• Business Logic Modeling. Our modeling method gives an implicit definition of what business logic is supposed to be. The models in our method are business logic. These models contain only information on the abstraction level of business programming. Our models can be viewed as being executable on a virtual business machine. This virtual business machine is in fact a worldwide net of businesses interaction with each other and with their clients. Our modeling method presents a logical view on applications, just as SQL provides a logical view on data. Business modeling forms a defined abstraction layer. We propose to use business modeling as a fixed part of an artifact-oriented software development approach. It is the core of the functional specification of a system.
• Business Logic Programming. The combination of the concepts of business modeling and high-level programming is business logic programming. It can be seen as the continuation of the concept of fourth generation languages for enterprise applications. It is a conceptual abstraction from and consequent extension of this paradigm towards non-proprietary solutions, whereas these 4GL languages have become typically product-specific solutions.
• The Business Web. The basic programming paradigm and therefore the virtual machine of our high-level programming approach is the transactional business network, the business web. This is a virtual distributed execution platform that spans organizations. We have identified message-based communication as the feasible paradigm which allows the realization of the virtual machine on current platforms. The abstract machine model consists of a set of automata, which represent enterprise systems, and which communicate by messages. This network and automaton model allow a transactional coupling of systems so that each message to an automaton is processed in a local transaction on this automaton.
• Non-Universal Programming. By avoiding WHILE type loops or freestyle recursion a high-level programming paradigm can even be made total, i.e. programs always terminate. This non-Turing-universality can be found, for example, in SQL. Even if the restrictions found there may be found too restrictive, it must be said that typical classes of business logic do not need computational universality. A high-level programming paradigm can help in making it necessary to explicitly enable higher complexity classes.
• Transactional Programming. The high-level programming paradigm of choice for transactional applications is imperative in its style, but due to the possibility of user aborts this paradigm goes beyond other imperative paradigms in crucial aspects. The same has to be said with respect to the update commands themselves, which have concurrent semantics not found in many other imperative programming paradigms.
• State History Diagrams. State history diagrams unify state charts and class diagrams. The visit of a state implicitly causes the instantiation of an object, so that the history of a state machine run is given by a history object path. This history object model (HOM) is used in form-oriented analysis to give precise though still lightweight semantics to the temporal aspects of the dialogue constraint language.
• History Log Warehouse. Many typical tasks in enterprise applications can be seen as accessing logged data, i.e. write-only data. The history log warehouse is an operational approach to temporal modeling, which identifies executable temporal queries. It serves as a basis for a fundamental understanding of business logic patterns. It allows a more regular business logic design.
• Integrated Source Code Model. The models and programs are seen as data and are therefore instances of ordinary data types. The modeling methods including the form-oriented interface can be used to define source code manipulation on a high level. The integrated source code model can abstract from many problems like name collisions.
• Bipartite Modeling of Finite Aspects. The bipartite modeling we have introduced for formcharts is valuable for all finite state modeling problems, where the finite state model is only an aspect of the system and is accompanied by a more complex system model. As a complex state we see every system, which is described by a data model and actual algorithms acting on the data model. The specification of such finite state behavior by a bipartite state machine enforces the separation of concerns. The finite state machine alternates between receptive states, which listen for the next event, and reactive states, which react to an event and are left automatically in order to return to an receptive state. These bipartite finite state models have the natural property that a single event type leads to a single transition from a receptive to a reactive state. The bipartite structure actually models a fact of the system, namely that the system does change the state with the reception of the event. The bipartite model pays tribute to the fact that in the addressed type of complex systems the reaction is indeed a computation and therefore extended in time, even if it is terminated automatically. Bipartite modeling is the cornerstone of the user interface model of form-oriented analysis.