Feature 153

.github/workflows/check-project-technical-quality.yml

@@ -39,7 +39,7 @@ jobs:
 
       - name: Compile and package binaries and resources targeted by the technical quality stage
         run: |
-          mvn --batch-mode --update-snapshots --show-version -Drevision=${{ env.ARTIFACT_VERSION }} --fail-fast --file pom.xml -DcreateChecksum=true package -Dmaven.test.skip=true
+          mvn --batch-mode --update-snapshots --show-version -Dstage=technical-quality -Drevision=${{ env.ARTIFACT_VERSION }} --fail-fast --file pom.xml -DcreateChecksum=true package -Dmaven.test.skip=true
         env:
             MAVEN_USERNAME: ${{ secrets.SPACE_CYBNITY_OS_REPO_USERNAME }}
             MAVEN_PASSWORD: ${{ secrets.SPACE_CYBNITY_OS_REPO_PASSWORD }}

.github/workflows/java-project-ci.yml

@@ -279,8 +279,8 @@ jobs:
   # Prepare a release for remote repository installation (published in place of old equals release name in remote repository, reviewed or not)
   # Publish release of parent pom.xml and sub-projects (reusable by other development, or for processing by Automated Acceptance Test stage) that potentially replace previous equals version named
   publish_version_to_release_remote_repository:
-    name: Release publishing (remote repo)
-    if: ${{ success() && !needs.define_project_release_name.outputs.is_snapshot }}
+    name: Release publishing
+    if: ${{ success() && needs.define_project_release_name.outputs.is_snapshot == 'false' }}
     needs: [define_project_release_name, packaging, quality_verification]
     uses: ./.github/workflows/publish-java-packages-version-to-repository.yml
     with:
@@ -291,7 +291,7 @@ jobs:
 
   # Prepare only a snapshot version for remote repository installation
   publish_version_to_snapshot_remote_repository:
-    name: Snapshot version publishing (remote repo)
+    name: Snapshot version publishing
     # By default, don't publish snapshot version on other repository than the local developer workstation's maven repository
     # The Pull Request (PR) of development revision was approved and merged, but maybe work is not finished
 
@@ -301,7 +301,7 @@ jobs:
       # or only when a reviewed tag is pushed only on the branch (e.g after a review already executed after closed PR)
       # or only when a alpha tag is pushed only on the branch (e.g when feature developer or reviewer indicate that work is finished)
     if: ${{ success()
-          && needs.define_project_release_name.outputs.is_snapshot
+          && needs.define_project_release_name.outputs.is_snapshot == 'true'
           && (
            (github.event.pull_request.merged == true && github.event.pull_request.reviewDecision == 'approved')
            ||

.gitignore

@@ -15,3 +15,4 @@ buildNumber.properties
 #.classpath
 #.settings/
 .flattened-pom.xml
+implementations-line/cockpit-foundations/actions-scheduling/acsc-ui-modules/acsc-frontend/package-lock.json

docs/uml/README.md

@@ -5,6 +5,7 @@ The source artifacts are managed into this directory and maintained via the [Ecl
 Each Papyrus model file (.di) include internal structure hosting specific diagrams relative to its scope of documentation.
 
 # FUNCTIONAL VIEW (Use Cases)
+## Purpose
 - Show the functionality of the system(s) as perceived by the external actors;
 - Exposes the requirements of the system.
 
@@ -13,12 +14,13 @@ Source file named "Use case view":
 - Static aspects (structural diagrams): use cases;
 - Dynamic aspects (behavioral diagrams): interactions, statecharts, activities.
 - Model sub-packages:
-  - Each context of the software (e.g Domain context) is described in a separate sub-package. 
-  
+  - Each context of the software (e.g Domain context) is described in a separate sub-package.
+
 ## Usage
 Formalizes software functional and/or technical analysis according to the functional and technical requirements.
 
 # DESIGN VIEW (Logical Components)
+## Purpose
 - Sub-capture how the functionality is designed inside the domain contexts;
 - Logical view of systems and sub-systems.
 
@@ -62,6 +64,7 @@ Source file named "Design view":
 Formalizes the specification of the software and sub-components produced during the solution analysis and technical design activities.
 
 # PROCESS VIEW (Executions)
+## Purpose
 - Show the concurrency of the system(s);
 - Encompasses the threads and processes that form the system's concurrency and synchronization mechanisms.
 
@@ -76,6 +79,7 @@ Source file named "Process view":
 Describes execution models and synchronization rules, identified during the technical design phase and implementation rules definition.
 
 # IMPLEMENTATION VIEW (Technical Components and Structures)
+## Purpose
 - Show the organization of the core components and files (e.g source code, setting files);
 - Packaging models and dependencies distribution;
 - Addresses the configuration management of the system's releases.
@@ -88,11 +92,12 @@ Source file named "Implementation view":
   - [Implementation guidelines and principles](implementation/README.md)
   - Configuration-management
   - System-assembly
-	
+
 ## Usage
 Formalizes the maintenance documentation aligned with source codes developed, including specificities regarding technologies (e.g language requirements) and frameworks (e.g implementation templates, protocols) used for implementation of the software.
 
 # DEPLOYMENT VIEW (Systems & Applications)
+## Purpose
 - Show the deployment of the systems in terms of physical architecture;
 - Encompasses the node that form the system's hardware topology (e.g type of infrastructure components, network, virtual environments) on which the system executes (e.g resources requirements, runtime platform);
 - Addresses the distribution (e.g flow opening), delivery (e.g procedures to respect), and installation (e.g resource prerequisites) of the parts that make up the physical system.
@@ -110,4 +115,4 @@ Source file named "Deployment view":
 ## Usage
 Describes the environment(s), infrastructure and operating conditions required to install, activate and operate the systems safely.
 #
-[Back To Summary](../)
+[Back To Summary](../)

docs/uml/implementation/README.md

@@ -24,5 +24,16 @@ The assembly of specific modules can be customized for delivery of a business so
 The CYBNITY open source is organized via a structure of Maven project's sub-modules regarding all the source codes developed by the team.
 ![image](Implementation_projects_structure.PNG)
 
+### Development Tutorials and Conventions
+Several coding documentations are available into the [how-to sub-directory](how-to) for assistance to developers.
+
+The CYBNITY coding norms are considered like mandatory to apply and can be controlled via quality check process (e.g by Continuous Integration chain, source code reviews) and are origins for reject of source codes changes considered like violation of the documentation norm.
+
+The CYBNITY conventions are more permissive because are considered as optional, without mandatory quality check (based on the developer motivation and skills), but can be transformed in norm after a period of application.
+#### Conventions
+- [Coding conventions](how-to/coding-conventions.md)
+#### Norms
+- Branch tagging norm
+
 #
 [Back To Parent](../)

docs/uml/implementation/how-to/coding-conventions.md

@@ -0,0 +1,44 @@
+## PURPOSE
+Presentation of several coding conventions followed by the developers implementing the CYBNITY projects.
+
+# SOURCE CODES DOCUMENTATION
+## REQUIREMENTS LINKING
+Specific annotations are available to link the specification documentations (e.g functional, architecture, security requirement...) managed in other repository than GitHub with the source codes developed as realization of them.
+
+- Why it's important: to quickly navigate and control the quality of alignment between the specifications managed in any other tools (e.g Notion tool for Product Requirements Definition, Security control measures and policies, architecture concepts) with the implementation software codes.
+
+- How: the __support framework library__ (dependency defined in parent `pom.xml` of any implementation project) provide specific reusable annotations for add link to requirement managed in an external documentation reference (link based on requirement identifier). The annotation is usable on several source code element types (e.g Method, Parameter, Package...).
+
+For example, to add a reference to an architecture requirement (e.g identified as REQ_ARC_10) into a CYBNITY source code package (e.g into a `package-info.java` file):
+
+```java
+@CYBNITYRequirement(reqType = RequirementCategory.Maintainability, reqId = "10")
+package org.cybnity.infrastructure.technical.message_bus.adapter.impl;
+
+import org.cybnity.framework.support.annotation.CYBNITYRequirement;
+import org.cybnity.framework.support.annotation.RequirementCategory;
+```
+
+## VULNERABILITIES LINKING
+Specific annotation is also available to add any references to known vulnerabilities (e.g generated by reused external technologies which not was fixed; or regarding a specific security mitigation developed into a CYBNITY component) fixed into a CYBNITY source code and/or configuration file.
+
+- Why it's important: some time some vulnerability are not quickly fixed by the technology partners or other open source projects, and CYBNITY program's developers can develop a fix code more quickly (e.g a temporary mitigation solution reducing the threat impact on the CYBNITY software including a dependency to the external problem) during the time for the partner to solve the problem into their software version.
+
+- How: the __support framework library__ (dependency defined in parent `pom.xml` of any implementation project) provide specific reusable annotations for add link to vulnerability declaring by external stakeholder (e.g other software editor) and/or public documentation (e.g Mitre website). The annotation is usable on several source code element types (e.g Type, Method, Local variable, Type parameter...).
+
+For example, to add a reference link to a Mitre published vulnerability (e.g identified as CVE-2022-33915) on a java method fixing the problem during mitigation period into a CYBNITY source code file:
+
+```java
+import org.cybnity.framework.support.annotation.VulnerabilityOrigin;
+import org.cybnity.framework.support.annotation.ThreatOriginCategory;
+
+class X {
+  @VulnerabilityOrigin(originType = ThreatOriginCategory.CVE, originId = "2022-33915")
+  public methodWhereVulnerabilityGenerateImpact(...) {
+
+  }
+}
+```
+
+#
+[Back To Parent](../)

implementations-line/README.md

@@ -8,7 +8,45 @@ Feature implementations versions are designed and delivered as official Foundati
 ### Sources Structure
 Implementation components are built via Maven tool using a [standard Maven project structure](https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html).
 
-# APPLICATIONS MODULES
+The implementation projects are supported by an [Official TechStack version](https://github.com/cybnity/foundation-techstack/blob/feature-157/demonstrators-line/demonstrator-v0/v0-technologies-stack.md) defining the authorized technologies used by any the software sub-project.
+
+# COCKPIT-FOUNDATION COMPONENTS
+The source code managed in this area of Foundation project are about the capabilities provided to the users (e.g web ui services provided to user's web browser) via the user interface layer.
+
+The implementation source codes realizes interactive functions provided by **UI Modules** (UI layer providing functional or technical capabilities) to deliver User eXperiences (UX) to the solution final users of CYBNITY solutions.
+
+- [Actions & Scheduling UI module](cockpit-foundations/actions-scheduling)
+- [Assets & Perimeters Protection UI module](cockpit-foundations/assets-perimeters-protection)
+- [Automation UI module](cockpit-foundations/automation)
+- [Awareness & Training UI module](cockpit-foundations/awareness-training)
+- [Behaviours/Situations Anticipation & Control UI module](cockpit-foundations/behaviours-situations-anticipation-control)
+- [Commandment UI module](cockpit-foundations/commandment)
+- [Coordinations UI module](cockpit-foundations/coordination)
+- [Dashboard & Threshold](cockpit-foundations/dashboard-threshold)
+- [Defensive Maneuvers UI module](cockpit-foundations/defensive-maneuvers)
+- [Defensive Responses & Controls UI module](cockpit-foundations/defensive-responses-controls)
+- [Goals & Evidences UI module](cockpit-foundations/goals-evidences)
+- [ISMS & Strategy UI module](cockpit-foundations/isms-strategy)
+- [Missions & Programming UI module](cockpit-foundations/missions-programming)
+- [Operational Excellence UI module](cockpit-foundations/operational-excellence)
+- [Operational Recovery UI module](cockpit-foundations/operational-recovery)
+- [Operations Cartography UI module](cockpit-foundations/operations-cartography)
+- [SKPI & Dashboard UI module](cockpit-foundations/skpi)
+- [Stakeholders & Responsibilities UI module](cockpit-foundations/stakeholders-responsibilities)
+- [Standards & Compliances UI module](cockpit-foundations/standards-compliances)
+- [Threat/Risks Prevention & Treatment UI module](cockpit-foundations/threats-risks-prevention-treatment)
+- [Vulnerabilities Prevention & Treatment UI module](cockpit-foundations/vulnerabilities-prevention-treatment)
+
+Some shared deployable modules (e. endpoints) are also implemented at the UI layer level:
+- [Web Reactive Frontend server](cockpit-foundations/web-reactive-frontend) (ReactJS / Node.js web app)
+- [Reactive Messaging Gateway](cockpit-foundations/reactive-messaging-gateway) (Vert.x Reactive Backend server)
+
+![image](mpp-ui-technology-stack.png)
+
+![image](mpp-ui-systems-stack.png)
+
+# APPLICATION COMPONENTS
+The source codes managed in this independent projects are dedicated to each CYBNITY applicative domain.
 Each application module dedicated repository manages its source codes structure via repositories with prefix "domain-":
 - [Access Control module](https://github.com/cybnity/domain-access-control)
 - [API Management module](https://github.com/cybnity/domain-api-mgt)
@@ -28,8 +66,64 @@ Each application module dedicated repository manages its source codes structure
 - [Trial & Training Management module](https://github.com/cybnity/domain-trial-training-mgt)
 - [Vulnerability Management module](https://github.com/cybnity/domain-vulnerability-mgt)
 
-# FEATURES MODULES
-The source code are managed in this area of Foundation project.
+Each application domain distributed into the Application Layer aggregates deployable implementation components:
+- One **<< Domain Name >> Gateway Module** (messaging gateway as endpoint of the bounded context)
+- Several deployable **Process Modules**
+![image](mpp-app-technology-stack.png)
+
+![image](mpp-app-systems-stack.png)
+
+# FEATURE COMPONENTS
+The features implementation modules providing services which can be embedded by an application domain and/or can be exposed as reusable/common/shared function at one or several layers of the CYBNITY software.
+
+The implementation source codes mainly are **Java libraries** which can be reused.
+
+For example, a common feature library can be embedded into an application domain or can be independently deployed as a micro-service serving several application domain (e.g as a cluster of a specific technical feature instances).
+
+Several categories of features are implemented through Java libraries regarding:
+- [domain](features/domain): libraries of cyber-serenity features helping final user to manage its ISMS via processes, workflow, combined set of application feature integrated into the UI capability components
+  - [feature-framework](features/domain/feature-framework): library of common and generic utility components (e.g technological classes reusable by any feature implementation project) that does not contain any business/domain functions
+- [integrated-partners](features/integrated-partners): features provided by CYBNITY compatible partners' components (e.g accessory) and adapted via compatibility connectors
+- [operating-system](features/operating-system): technical features provided by operating systems (e.g hypervisor, virtualization component)
+- [physical](features/physical): features provided by physical devices integrated
+- [technical](features/technical): features providing technical services (e.g strongbox, traceability, versioning, encryption) and implementing reusable functions by any CYBNITY component
+- [transport](features/transport): features relative to communication layer between systems and/or application components (e.g firewalling, network monitoring)
+- [workflow-process](features/workflow-process): features providing generic workflow and processes management implementation models
+
+### Domain Layer
+Each application domain can more or less separate its features in micro-services as deployable **Feature Modules** to manage the processing parallelization via Real-Time Stream Computation Units.
+![image](mpp-domain-technology-stack.png)
+
+![image](mpp-domain-systems-stack.png)
+
+### Runtime Model of Feature Components
+The scalability required by a specific feature component is supported by the implementation of a runtime model that include the deployment of a set of micro-service instances regarding it.
+![image](scalable-runtime-model.png)
+
+# INFRASTRUCTURE COMPONENTS
+The source code managed in this area are about the infrastructure components supporting the features and applications modules.
+For example, the implementation source code of an adapter client to a monitoring server (e.g proprietary solution integrated with CYBNITY over a connection adapter and/or via a protocol compatibility implementation) is provided as an infrastructure module.
+Mainly, the **Infrastructure Modules** are provided as **Java libraries** of adaptation client implementations modules.
+
+Several categories of infrastructure technologies are managed in terms of implementation codes:
+- [common](infrastructures/common): shared and transversal structures of infrastructure data (e.g generic event)
+- [continuity](infrastructures/continuity): clients of integration with Business Continuity systems
+- [integration](infrastructures/integration): clients of integration with brokers of messages (e.g Redis cluster, Kafka cluster) allowing to discuss with other CYBNITY or third-parties systems
+  - [Users Interactions Space adapter](infrastructures/integration/system/users-interactions-broker/uib-adapters) to brokers cluster
+  - [Domains Interactions Space adapter](infrastructures/integration/system/domains-interactions-broker/dib-adapters) to brokers cluster
+- [monitoring](infrastructures/monitoring): clients to systems of monitoring (e.g alerting, data visualization, event logging)
+- [registry](infrastructures/registry): clients to registration systems (e.g contents indexing system)
+- [security](infrastructures/security): clients to systems providing security services (e.g Single-Sign-On server, IAM server)
+  - [Access Control & SSO server](infrastructures/security/system/access-control-sso)
+  - [Identities & Access Management server](infrastructures/security/system/identities-access-management)
+  - [Secrets Management server](infrastructures/security/system/secrets-management)
+
+Any implementation component can be categorized as a **Technical Service** (implementation code executing a behavior, or implementation of a system client as adapter implementation module) or as a **Integration API** (when exposing a CYBNITY API exposed to other systems as an input/output point via a standardized protocol).
+
+### Shared Infrastructure Services
+For example, the infrastructure implementation modules allow to manage the dependency with common systems reused (e.g based on open source and/or proprietary partners software instances) into a CYBNITY solution architecture deployment.
+![image](mpp-infrastructure-systems-stack.png)
 
-# SYSTEMS
-System implementation source codes allowing to build the deploybale software components (e.g as virtualized systems) are managed in this repository.
+### Common Transversal Components
+Example of common event-based principles using a common infrastructure library regarding generic event.
+![image](mvf-event-based-architecture.png)