The Digital Architecture Framework (DAF) Metamodel is a modeling language which defines the notation for all elements used in the different stages of an organization life cycle to support the concept of Digital Engineering (DE), from the requirement to the application. DAF is intended to be used within a DE scope. The aim of the DE is to create a Digital Twin of an organization or domain, by holding all knowledge of the enterprise in an Authoritate Source of Truth (ASoT). The products of this knowledge (text documents, code configuration, deployment files, etc.) are generated from the model rather than produced, managed, and stored separately.

To be able to transform this abstract model into running code the support of a special class of frameworks is required, called Aphrodites (Alfa). DigitalPy is a Python framework that implements the Aphrodites 2.0 specifications. Other Aphrodites frameworks and the original specification are maintained under the Olympos MDA project (e.g. VenusSharp a C# implementation). The most notable being the WCMF, an Aphrodite framework for PHP.

An Aphrodites framework consists of frozen spots and hot spots. On one hand, frozen spots define the overall architecture of a software system, that is to say, its basic components and the relationships between them. These remain unchanged (frozen) in any instantiation of the application framework. On the other hand, hot spots represent those parts where the programmers using the framework add their own code to add the functionality specific to their own project.

The aim of a DigitalPy is to define all the frozen spots, so that is hot spot can be generated from the ASOT. While DigitalPy is well suited for Digital Enginering, there are no dependencies with the ASoT or the DAF Generator (DAFGen) that are maintained as a separated project.

This is not about “how easy the Hello World example is” rather “How long you need to understand enough to use it”. Design simplicity is a key principle and unnecessary complexity is avoided to the user. DigitalPy hides the complexity behind a clear defined, simple API.

A lesson learned from “Ruby on rails” in positive and the typical old J2EE application in negative sense. DigitalPy runs with minimal or no configuration. Even if a configurable entity was not configured, there should be some proper default to attach it with.

DigitalPy follows

• Abstraction: Alpha abstraction, supports the KISS principle, by hiding internal implementation and showing only the required features or set of services that are offered.
• Encapsulation: Alpha binds data and attributes or methods and data members in classes, also implements the Facade structural pattern (see below)
• Inheritance: Alpha allocates features to super classes that can be inherited from children classes
• Polymorphism: Alpha describe objects with polymorphic charatteristics.

provides a way to describes concepts like “Domain Object”, Services , View . See also the MVC point below.

is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other.

An application is usually based on a domain model that represents the real-world concepts of the domain of interest. In object oriented programming this model is implemented using classes. Depending on the application requirements the instances of some of these classes have to be persisted in a storage to keep the contained data. These classes represent the data model. The classes that provide the infrastructure for storing data form the persistence layer.

the dModelclasses support the ability to Create, Read, Update and Delete (CRUD) tree of elements taking in account the model information. DigitalPy defines PersistentObject as base class for persistent domain classes. It mainly implements an unique identifier for each instance (see ObjectId), tracking of the persistent state, methods for setting and getting values as well as callback methods for lifecycle events. For the composition of object graphs the derived class Node is used as base class. It implements relation support for persistent objects.

To retrieve persisted objects PersistenceFacade is used. The actual operations for creating, reading, updating and deleting objects (e.g. SQL commands) are defined in classes implementing the PersistenceMapper interface (see Data Mapper Pattern). Although not necessary there usually exists one mapper class for each persistent domain class. Mapper classes are introduced to the persistent facade by configuration.

Associations are an important concept in a Chronos model, since they describe the relations between entities, namely the parent-child relation. There are three different types of Relationships supported: Composite, Shared and normal Associations. It is important to understand how DAFGen recognizes parents and children in an association with composite or shared ends the parent is always the class, that is connected with the diamond end of the association, even if that is placed on the target side of the association.

Normal associations are treated as parent-child relation, if they are only navigable in one direction, which is then defined as the child to parent direction.

Different association types shown below result in different behaviors regarding the operations allowed on child entities

Another question that may arise is how to model multiple associations between two types. Given that you have Person and Task entity types and you want to associate tasks with persons. To achieve this, you'll draw a shared association between them and place the aggregation (diamond) end at the Person class.
But what if you want to have a task a task owner and a task creator? In this case you'll have to draw a second association. The next question is now how the generator can distinguish between a task creators and task owners. This is, where the concept of roles comes into play. To resolve this conflict, you'll have to assign role names to the person and task association ends. The generator will generate different entity and mapper classes for each role, which allows the framework to know which role a person has in relation to a given task.

If different entity types should have the same attributes, one may define a common base class that makes these available to inheriting classes. An example may be a EntityBase type, which defines meta information like creation date and last modification date for all entity types The DAFGen expects to have a target class/mapper definitions for each class in the model. In case of inheritance the subclasses will contain the attributes of the parent classes too. For abstract base classes no mapper class will be generated.

Inheritance will cause the generator to draw new relations in the following cases: • Subclasses of parent classes of the current entity will also become parents . • Parent classes of the superclass of the current entity will also become parents. • Subclasses of child classes of the current entity will also become children . • Child classes of super classes of the current entity will also become children .

Another aspect of associations is the use of arrow ends that describe the navigability. If an arrow end is omitted on one end, that means that the appropriate entity type is not seen from the other end. This association information is written into the generated mapper classes.

Modular design is a generally recognized “Good Thing(tm)” in software engineering. As in science in general, breaking a problem down to smaller, bite-sized pieces makes it easier to solve. It also allows different people to solve different parts of the problem and still have it all work correctly in the end. Each component is then self-contained and, as long as the interface between different components remains constant, can be extended or even gutted and rewritten as needed without causing a chaotic mess. DigitalPy supports this principle with his component Architecture (see below).

Aphrodite 1.0 describes a monolithic architecture, to support a better modular design, the 2.0 specs introduces the concept of Component Architecture.

• Independent − Alfa Components are designed to have minimal dependencies on other components thanks to the DigitalPy routing system.
• Reusability − Alfa Components are designed to be reused in different situations in different applications. However, some components may be designed for a specific task.
• Replaceable − Alfa Components may be substituted with other similar components.
• Not context specific − Alfa Components are designed to operate in different environments and contexts and can be deployed anywhere.
• Encapsulated − A component depicts a Facade, which allow the caller to use its functionality, and do not expose details of the internal processes or any internal variables or state.
• Deployability - Alfa Components can de deployed at runtime, registering themselves to the application core.

each component exposes a Facade, that is inheriting from the framework Facade. All the messages are routed trough the facade to the Component Actionmapper that allocates the action to the proper controller as defined in internalActionMapping.ini.

this allows:

• Isolation: We can easily isolate our code from the complexity of a subsystem.
• Testing Process: Using Facade Method makes the process of testing comparatively easy since it has convenient methods for common testing tasks.
• Loose Coupling: Availability of loose coupling between the clients and the Subsystems.

each component exposes a Facade, that is inheriting from the framework Facade. All the messages are routed trough the facade to the Component Actionmapper that allocates the action to the proper controller as defined in internalActionMapping.ini.

Here is an example of how you could create a facade for a "emergency" component in Python :

class EmergencyFacade:
    def received(self, request, response):
        # Implement the logic for handling received emergency alerts here
        pass

class Emergency:
    @staticmethod
    def Received(request, response):
        emergency_facade = EmergencyFacade()
        emergency_facade.received(request, response)

The Emergency class acts as a facade, providing a single point of entry for handling emergency alerts. The Received method delegates the actual handling of the alert to the EmergencyFacade class. This allows you to encapsulate the implementation details of the emergency alert handling logic within the EmergencyFacade class, while providing a simpler interface for interacting with it through the Emergency facade.

You can then use the Emergency class in your actionmapping configuration like this:

[actionmapping]
EmergencyAlert = FreeTAKServer.components.extended.emergency.Emergency.Received
EmergencyInContact = FreeTAKServer.components.extended.emergency.Emergency.Received
EmergencyRingTheBell = FreeTAKServer.components.extended.emergency.Emergency.Received
EmergencyGeoFenceBreached = FreeTAKServer.components.extended.emergency.Emergency.Received
This allows you to keep the implementation details of the emergency alert handling logic separate from the rest of the application, and makes it easier to maintain and modify the code in the future.

DigitalPy supports a base API which can register flask blueprints dynamically.

This enables component developpers to quickly add exposed functionality without the need to develop a new service from scratch. These blueprint's must be put in the path DPApplicationRoot/Blueprints/your_blueprint.py. From there, they will be dynamically registered.

DigitalPy also supports a Pub-Sub protocol.

DigitalPy core contains the following component: