| Name | aac JSON |
| Version |
0.4.6
JSON |
| download |
| home_page | None |
| Summary | A distinctly different take on Model-Based System Engineering (MBSE) that allows a system modeller to define a system in simple yaml. |
| upload_time | 2024-05-20 17:27:45 |
| maintainer | None |
| docs_url | None |
| author | None |
| requires_python | None |
| license | None |
| keywords |
mbse
|
| VCS |
|
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
[](https://github.com/DevOps-MBSE/AaC/actions/workflows/main-branch.yml)
[](https://gitpod.io/from-referrer/)
# Note to Contributors
Due to certain uncontrollable circumstances surrounding the environment in which
Architecture-as-Code is being developed and funded, we cannot accept any new outside
contributions at this time. We will reject any pull requests from unknown sources.
While this is unfortunate, we still accept feedback and ideas that will better the
form and function of the AaC product in all of its forms. We apologize for this inconvenience.
In the future, it is our intention to accept contributions from outside sources
per our standards and code of conduct. We are committed to reaching the goal of an
open source repository and hope that potential contributors will still follow our
progress and join us in the future.
# Architecture-as-Code (AaC)
AaC is a distinctly different take on Model-Based System Engineering (MBSE) that allows a
system modeller to define a system in simple yaml. This approach allows engineers to
apply rigorous configuration management to their baselines (unlike other "boxes and lines" approaches).
Our team has spent many years engineering, building, testing, and delivering complex systems. In
that time we've seen an enormous amount of effort and money put into system modelling. Unfortunately,
it is almost always the case that the system model is either never used by the teams building and
delivering product, or it adds complexity to those team's workflow and becomes an impediment. The
creators of AaC have spent many years working to adopt and tailor the principles of DevOps within
our professional workplaces. We've seen the amazing efficiencies that can be achieved by knocking down
the "wall of confusion" between developers and operations and optimizing around system thinking, flow,
and continuous improvement through learning and experimentation. We believe the critical tipping point
that allowed this to occur was the creation of Infrastructure-as-Code and the adoption of new practices
like GitOps that embrace automated quality assurance, automated deployment, and continuous monitoring.
Our objective is to knock down the "wall of confusion" that exists between systems engineering and
development, optimizing the total system delivery value stream from concept/requirement through to
operations with complete traceability and configuration management throughout. We believe we can
discover new ways to define, deliver, and evolve complex systems using Architecture-as-Code.
AaC is a self-defining solution. At the heart of the AaC application is a definition of AaC itself.
This model checks itself for correctness. Core data types are purposefully simple and can be
extended by a user.
AaC is designed with extensibility in mind. The built-in functionality is intentionally minimized.
AaC uses a plug-in system to extend the base capability. To further simplify this, AaC includes a
built-in command to generate new plugins from an AaC model. There are a few internal examples of this
in the plugins folder of the repository and more info below.
## Using AaC to Model Your System
AaC is written in Python to help make it more approachable for casual users and easily extensible for
power users.
**You will need Python 3.9 or later to run AaC.**
To install AaC on Linux or Windows:
```bash
pip install aac
```
To use AaC you first define a model of your system in yaml. Refer to the documentation for more details.
A simple model for an EchoService is provided here for reference. Cut and paste the below model into a
file called EchoService.yaml.
*Note: This is using a little yaml trick to concatenate the content of two yaml files into a single file.*
```yaml
schema:
name: Message
fields:
- name: body
type: string
- name: sender
type: string
---
model:
name: EchoService
description: This is a message mirror.
behavior:
- name: echo
type: REQUEST_RESPONSE
description: This is the one thing it does.
input:
- name: inbound
type: Message
output:
- name: outbound
type: Message
acceptance:
- scenario: onReceive
given:
- The EchoService is running.
when:
- The user sends a message to EchoService.
then:
- The user receives the same message from EchoService.
```
Now you can run AaC against your model.
```bash
aac check EchoService.yaml
```
AaC has some core "root types" for you to work with. You can see the root types of `schema` and `model` used in the example above.
The AaC core root types are:
- schema: Allows you to model data structures used within your system as user-defined types.
- enum: Allows you to model enumerated values (types with only specific values allowed).
- model: Allows you to model the components of your system and their interfaces. These can be abstract or concrete.
- usecase: Allows you to model the behavior and interactions between your models.
- plugin: Allows you to easily extend the AaC DSL itself and create tailored aac commands to your needs.
Although you can use the yaml trick above when modelling your system, it would be better to keep things more
structured and organized. To help with this AaC allows you to define each item you model in a separate file and
then import it as needed. To do this just put an **import** at the root of your model file.
Here's an example of the EchoService broken into two files:
*Message.yaml*
```yaml
schema:
name: Message
fields:
- name: body
type: string
- name: sender
type: string
```
*EchoService.yaml*
```yaml
import:
files:
- ./Message.yaml
---
model:
name: EchoService
description: This is a message mirror.
behavior:
- name: echo
type: REQUEST_RESPONSE
description: This is the one thing it does.
input:
- name: inbound
type: Message
output:
- name: outbound
type: Message
acceptance:
- scenario: onReceive
given:
- The EchoService is running.
when:
- The user sends a message to EchoService.
then:
- The user receives the same message from EchoService.
```
Ok, so that's interesting, but what can you do with the AaC model once you've built it?
AaC is designed and built on years of experimentation, experience, and learning. But this version
is a brand new implementation rewritten entirely in Python in an attempt to make AaC more user friendly
to both the casual user and the power user. Right now AaC doesn't have a lot of additional features.
But new plugins are being created to deliver more functionality. Over time there will be plugins
available to use the AaC model to auto-generate content for reviews, documentation, and even system
development and deployment.
## User Documentation
Users who would like more detailed documentation on leveraging AaC can find it in our Github pages [User Guide Documentation](https://arch-as-code.org/project_documentation/user_guide/index.html)
## Developer Documentation
Contributors, developers, or just generally interested parties who would like to understand the more technical underpinnings of AaC are welcome to read the project and developer documentation found in our Github pages [Developer Guide Documentation](https://arch-as-code.org/project_documentation/dev_guide/index.html)
We're also actively working on other functionality so keep an eye out for new updates.
Raw data
{
"_id": null,
"home_page": null,
"name": "aac",
"maintainer": null,
"docs_url": null,
"requires_python": null,
"maintainer_email": null,
"keywords": "MBSE",
"author": null,
"author_email": null,
"download_url": null,
"platform": null,
"description": "[](https://github.com/DevOps-MBSE/AaC/actions/workflows/main-branch.yml)\n[](https://gitpod.io/from-referrer/)\n\n# Note to Contributors\n\nDue to certain uncontrollable circumstances surrounding the environment in which\nArchitecture-as-Code is being developed and funded, we cannot accept any new outside\ncontributions at this time. We will reject any pull requests from unknown sources.\nWhile this is unfortunate, we still accept feedback and ideas that will better the\nform and function of the AaC product in all of its forms. We apologize for this inconvenience.\n\nIn the future, it is our intention to accept contributions from outside sources\nper our standards and code of conduct. We are committed to reaching the goal of an\nopen source repository and hope that potential contributors will still follow our\nprogress and join us in the future.\n\n\n# Architecture-as-Code (AaC)\n\nAaC is a distinctly different take on Model-Based System Engineering (MBSE) that allows a\nsystem modeller to define a system in simple yaml. This approach allows engineers to\napply rigorous configuration management to their baselines (unlike other \"boxes and lines\" approaches).\nOur team has spent many years engineering, building, testing, and delivering complex systems. In\nthat time we've seen an enormous amount of effort and money put into system modelling. Unfortunately,\nit is almost always the case that the system model is either never used by the teams building and\ndelivering product, or it adds complexity to those team's workflow and becomes an impediment. The\ncreators of AaC have spent many years working to adopt and tailor the principles of DevOps within\nour professional workplaces. We've seen the amazing efficiencies that can be achieved by knocking down\nthe \"wall of confusion\" between developers and operations and optimizing around system thinking, flow,\nand continuous improvement through learning and experimentation. We believe the critical tipping point\nthat allowed this to occur was the creation of Infrastructure-as-Code and the adoption of new practices\nlike GitOps that embrace automated quality assurance, automated deployment, and continuous monitoring.\nOur objective is to knock down the \"wall of confusion\" that exists between systems engineering and\ndevelopment, optimizing the total system delivery value stream from concept/requirement through to\noperations with complete traceability and configuration management throughout. We believe we can\ndiscover new ways to define, deliver, and evolve complex systems using Architecture-as-Code.\n\nAaC is a self-defining solution. At the heart of the AaC application is a definition of AaC itself.\nThis model checks itself for correctness. Core data types are purposefully simple and can be\nextended by a user.\n\nAaC is designed with extensibility in mind. The built-in functionality is intentionally minimized.\nAaC uses a plug-in system to extend the base capability. To further simplify this, AaC includes a\nbuilt-in command to generate new plugins from an AaC model. There are a few internal examples of this\nin the plugins folder of the repository and more info below.\n\n## Using AaC to Model Your System\nAaC is written in Python to help make it more approachable for casual users and easily extensible for\npower users.\n\n**You will need Python 3.9 or later to run AaC.**\n\nTo install AaC on Linux or Windows:\n```bash\npip install aac\n```\n\nTo use AaC you first define a model of your system in yaml. Refer to the documentation for more details.\nA simple model for an EchoService is provided here for reference. Cut and paste the below model into a\nfile called EchoService.yaml.\n*Note: This is using a little yaml trick to concatenate the content of two yaml files into a single file.*\n```yaml\nschema:\n name: Message\n fields:\n - name: body\n type: string\n - name: sender\n type: string\n---\nmodel:\n name: EchoService\n description: This is a message mirror.\n behavior:\n - name: echo\n type: REQUEST_RESPONSE\n description: This is the one thing it does.\n input:\n - name: inbound\n type: Message\n output:\n - name: outbound\n type: Message\n acceptance:\n - scenario: onReceive\n given:\n - The EchoService is running.\n when:\n - The user sends a message to EchoService.\n then:\n - The user receives the same message from EchoService.\n```\n\nNow you can run AaC against your model.\n```bash\naac check EchoService.yaml\n```\n\nAaC has some core \"root types\" for you to work with. You can see the root types of `schema` and `model` used in the example above.\nThe AaC core root types are:\n- schema: Allows you to model data structures used within your system as user-defined types.\n- enum: Allows you to model enumerated values (types with only specific values allowed).\n- model: Allows you to model the components of your system and their interfaces. These can be abstract or concrete.\n- usecase: Allows you to model the behavior and interactions between your models.\n- plugin: Allows you to easily extend the AaC DSL itself and create tailored aac commands to your needs.\n\nAlthough you can use the yaml trick above when modelling your system, it would be better to keep things more\nstructured and organized. To help with this AaC allows you to define each item you model in a separate file and\nthen import it as needed. To do this just put an **import** at the root of your model file.\n\nHere's an example of the EchoService broken into two files:\n*Message.yaml*\n```yaml\nschema:\n name: Message\n fields:\n - name: body\n type: string\n - name: sender\n type: string\n```\n*EchoService.yaml*\n```yaml\nimport:\n files:\n - ./Message.yaml\n---\nmodel:\n name: EchoService\n description: This is a message mirror.\n behavior:\n - name: echo\n type: REQUEST_RESPONSE\n description: This is the one thing it does.\n input:\n - name: inbound\n type: Message\n output:\n - name: outbound\n type: Message\n acceptance:\n - scenario: onReceive\n given:\n - The EchoService is running.\n when:\n - The user sends a message to EchoService.\n then:\n - The user receives the same message from EchoService.\n```\n\nOk, so that's interesting, but what can you do with the AaC model once you've built it?\nAaC is designed and built on years of experimentation, experience, and learning. But this version\nis a brand new implementation rewritten entirely in Python in an attempt to make AaC more user friendly\nto both the casual user and the power user. Right now AaC doesn't have a lot of additional features.\nBut new plugins are being created to deliver more functionality. Over time there will be plugins\navailable to use the AaC model to auto-generate content for reviews, documentation, and even system\ndevelopment and deployment.\n\n## User Documentation\nUsers who would like more detailed documentation on leveraging AaC can find it in our Github pages [User Guide Documentation](https://arch-as-code.org/project_documentation/user_guide/index.html)\n\n## Developer Documentation\nContributors, developers, or just generally interested parties who would like to understand the more technical underpinnings of AaC are welcome to read the project and developer documentation found in our Github pages [Developer Guide Documentation](https://arch-as-code.org/project_documentation/dev_guide/index.html)\n\n\nWe're also actively working on other functionality so keep an eye out for new updates.\n",
"bugtrack_url": null,
"license": null,
"summary": "A distinctly different take on Model-Based System Engineering (MBSE) that allows a system modeller to define a system in simple yaml.",
"version": "0.4.6",
"project_urls": null,
"split_keywords": [
"mbse"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "5545448a35e51dc4f0fdb108d5c15ad25ebff9906279cb633b15dc0a1dec28ef",
"md5": "5edbdda31e93b640a3e0255ebe20dd69",
"sha256": "0291fe795f3694ed201e47a9cbd07a00bfcd27282da0baae989294c4f444fcd8"
},
"downloads": -1,
"filename": "aac-0.4.6-py3-none-any.whl",
"has_sig": false,
"md5_digest": "5edbdda31e93b640a3e0255ebe20dd69",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": null,
"size": 93858,
"upload_time": "2024-05-20T17:27:45",
"upload_time_iso_8601": "2024-05-20T17:27:45.468181Z",
"url": "https://files.pythonhosted.org/packages/55/45/448a35e51dc4f0fdb108d5c15ad25ebff9906279cb633b15dc0a1dec28ef/aac-0.4.6-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-05-20 17:27:45",
"github": false,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"lcname": "aac"
}
