This is the fourth day of my participation in the August More text Challenge. For details, see:August is more challenging

Architecture description Language ADL

3.1 define

ADL is a formal language, which provides a specific syntax and conceptual framework for the conceptual architecture modeling of software systems with the support of the underlying semantic model. Tools based on the underlying semantics support the presentation, analysis, evolution, refinement, design process of the architecture, and so on.

3.2 Basic components of ADL

  1. Component and component interface: a unit of computation or data storage where computation and state are stored.
  2. Connectors: Architectural building blocks used to model interactions between components and the rules governing those interactions.
  3. Architecture configuration: A connection diagram describing the components and fittings of an architecture.

3.3 Main architecture description languages

  1. Aesop: Supports architecture-style applications.
  2. MetaH: Provides guidance to designers on the design of real-time electronic control software systems.
  3. C2: Description of a user interface system that supports a messaging style.
  4. Rapide: Supports simulation of architectural designs and provides tools to analyze simulation results.
  5. SADL: Provides a formal basis for architectural refinement.
  6. Unicon: Supports heterogeneous component and connection types and provides a high-level compiler for the architecture.
  7. Wright: Support explanation and analysis of interactions between architectural artifacts.

Domain specific software architecture DSSA

4.1 define

A DSSA is a collection of software components that are dedicated to a particular type of task (domain), can be used effectively across the domain, and that define a standard composite structure for the successful construction of an application system.

DSSA is the development foundation of domain model, reference requirement, reference architecture, etc. of group application in a specific problem domain. Its goal is to support the generation of multiple applications in a specific domain.

Vertical domain: A software architecture that is common in a specific domain. It is a complete architecture. Horizontal domain: a widget that is part of the same thing across multiple different specific domains (e.g., shopping and education have billing systems, billing systems are horizontal domains).

4.2 The three basic activities of DSSA

Domain analysis: The main goal of this phase is to obtain the domain model (domain requirements). Identification information source, the source of information in the process of the entire field of engineering, the possible sources of information including the existing system, technical literature, the problem domain and system development, user surveys, and market analysis, field evolution history, etc., on the basis of this analysis can be in the field of the demand of the system, determine which demand is widely Shared in the field of system, thus the domain model is established.

Domain design: The goal of this phase is to obtain the DSSA. A DSSA describes a solution to the requirements expressed in the domain model, which is not a representation of a single system, but a high-level design that can accommodate the requirements of multiple systems in the domain. Once the domain model is established, dssas that meet the requirements of the domain being modeled can be derived.

Domain implementation: The primary goal of this phase is to develop and organize reusable information based on the domain model and DSSA. This reusable information may be extracted from existing systems or may require new development.

The above process is an iterative, gradual refinement process. In each stage of implementing the domain project, it is possible to go back to the previous step, modify and improve the results obtained from the previous step, and then go back to the current step to carry out the activities of this stage on a new basis.

4.3 The four roles involved in DSSA

Domain experts: include experienced users of systems in the domain, experienced software engineers engaged in requirements analysis, design, implementation, and project management of systems in the domain, etc. Provide knowledge of requirements specification and implementation of systems in the domain, help organize a standardized, consistent domain dictionary, help select sample systems as the basis for domain engineering, review domain models, DSSA and other domain engineering products, etc.

Domain analyst: An experienced system analyst with a knowledge engineering background will be employed. Control the entire domain analysis process, perform knowledge acquisition, and organize the acquired knowledge into the domain model.

Domain designer: An experienced software designer. DSSA is developed according to the domain model and the existing system, and the accuracy and the feasibility of DSSA are verified.

Domain implementer: An experienced programmer. Develop artifacts based on the domain model and DSSA.

4.4 DSSA Establishment Process

  1. Define domain scope: Applications in a domain must meet a set of user requirements.
  2. Define domain-specific elements: Create a dictionary of the domain, generalize the terms in the domain, and identify the same and different elements of the domain.
  3. Define constraints on domain-specific design and implementation requirements: Identify all constraints in the domain and what consequences these constraints have on the design and implementation of the domain.
  4. Define the domain model and architecture: produce a similar architecture and describe its component specifications. Generate and collect reusable product units: add reusable components to DSSA for use in new systems.

The above processes are concurrent, recursive, repetitive, and spiral.

4.5 Three-level model

  • Domain development environment: Domain architects determine the core architecture, producing reference structures, reference requirements, architectures, domain models, and development tools.

  • Domain-specific application development environment: Application engineers instantiate the core architecture according to the specific environment.

  • Application execution environment: The operator implements the instantiated architecture.