├── Egitimler ├── readme.md ├── DDS Arakatmanı Eğitimi.pdf ├── Yazılım Mimarileri Eğitimi.pdf └── Gerçek Zamanlı ve Gömülü Sistemler Eğitimi.pdf ├── Sözlük.mht ├── sözlük.pdf ├── ROS2 ├── images │ └── ROS2 │ │ ├── Ros2Sender │ │ └── Ros2Sender.png │ │ ├── Ros2Context │ │ └── Ros2Context.png │ │ ├── Ros2Component │ │ └── Ros2Component.png │ │ ├── Ros2Container │ │ └── Ros2Container.png │ │ └── Ros2Sequence │ │ └── Ros2Sequence.png ├── readme.md ├── Ros2Sequence.puml ├── Ros2Sender.puml ├── Ros2Context.puml ├── Ros2Component.puml ├── Ros2Container.puml └── Ros2Component.svg ├── ISO-25010 Kalite Öznitelikleri Türkçe Şablonu.pdf ├── Mimari Ödünleşim Analiz Methodu(ATAM) Şablonu.docx ├── C4Examples ├── Modern C++ ile sürdürülebilir yazılım mimarisi_V1.0.pdf ├── readme.md ├── CleanComponent.puml ├── CleanContext.puml ├── CleanContainer.puml └── clean.cpp ├── rossequence.puml ├── README.md ├── Madr.md ├── UtilityTree.puml ├── ATAM Template.md ├── madr_with_desc.md ├── c4 Diagrams ├── C4Modeli.md ├── arch42_with_c4.md ├── Sözlük.csv └── Arc42 Template in Markdown.md /Egitimler/readme.md: -------------------------------------------------------------------------------- 1 | Yazılım Mimarileri 2 | Gömülü Yazılım geliştirme 3 | DDS 4 | -------------------------------------------------------------------------------- /Sözlük.mht: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/Sözlük.mht -------------------------------------------------------------------------------- /sözlük.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/sözlük.pdf -------------------------------------------------------------------------------- /Egitimler/DDS Arakatmanı Eğitimi.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/Egitimler/DDS Arakatmanı Eğitimi.pdf -------------------------------------------------------------------------------- /Egitimler/Yazılım Mimarileri Eğitimi.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/Egitimler/Yazılım Mimarileri Eğitimi.pdf -------------------------------------------------------------------------------- /ROS2/images/ROS2/Ros2Sender/Ros2Sender.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/ROS2/images/ROS2/Ros2Sender/Ros2Sender.png -------------------------------------------------------------------------------- /ROS2/images/ROS2/Ros2Context/Ros2Context.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/ROS2/images/ROS2/Ros2Context/Ros2Context.png -------------------------------------------------------------------------------- /ROS2/images/ROS2/Ros2Component/Ros2Component.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/ROS2/images/ROS2/Ros2Component/Ros2Component.png -------------------------------------------------------------------------------- /ROS2/images/ROS2/Ros2Container/Ros2Container.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/ROS2/images/ROS2/Ros2Container/Ros2Container.png -------------------------------------------------------------------------------- /ROS2/images/ROS2/Ros2Sequence/Ros2Sequence.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/ROS2/images/ROS2/Ros2Sequence/Ros2Sequence.png -------------------------------------------------------------------------------- /ISO-25010 Kalite Öznitelikleri Türkçe Şablonu.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/ISO-25010 Kalite Öznitelikleri Türkçe Şablonu.pdf -------------------------------------------------------------------------------- /Mimari Ödünleşim Analiz Methodu(ATAM) Şablonu.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/Mimari Ödünleşim Analiz Methodu(ATAM) Şablonu.docx -------------------------------------------------------------------------------- /Egitimler/Gerçek Zamanlı ve Gömülü Sistemler Eğitimi.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/Egitimler/Gerçek Zamanlı ve Gömülü Sistemler Eğitimi.pdf -------------------------------------------------------------------------------- /C4Examples/Modern C++ ile sürdürülebilir yazılım mimarisi_V1.0.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hkutluca/yazilimmimarileri/HEAD/C4Examples/Modern C++ ile sürdürülebilir yazılım mimarisi_V1.0.pdf -------------------------------------------------------------------------------- /rossequence.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | participant User_Code 3 | participant RCLCpp 4 | participant RCL 5 | participant RMW 6 | participant DDS 7 | autonumber 8 | User_Code->RCLCpp: Publisher::Publish 9 | RCLCpp->RCL: rcl_publish 10 | RCL->RMW: rmw_publish 11 | RMW->DDS: data_writer.write 12 | @enduml 13 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Software Architecture related templates and drawings 2 | =============== 3 | Software architecture related templates and examples for following medium publications: 4 | 5 | Turkish: https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri 6 | 7 | English: https://medium.com/software-architecture-foundations 8 | -------------------------------------------------------------------------------- /ROS2/readme.md: -------------------------------------------------------------------------------- 1 | C4 and UML diagrams for ROS2 2 | ![Ros2 Context](images/ROS2/Ros2Context/Ros2Context.png "ROS2 Context Architecture") 3 | 4 | ![Ros2 Component](images/ROS2/Ros2Container/Ros2Container.png "ROS2 Container Architecture") 5 | 6 | ![Ros2 Component](images/ROS2/Ros2Component/Ros2Component.png "ROS2 Architecture") 7 | 8 | ![Ros2 Code](images/ROS2/Ros2Sequence/Ros2Sequence.png "ROS2 Sequence Architecture") 9 | 10 | ![Ros2 Code](images/ROS2/Ros2Sender/Ros2Sender.png "ROS2 Sender Architecture") -------------------------------------------------------------------------------- /C4Examples/readme.md: -------------------------------------------------------------------------------- 1 | 2 | ![image](https://user-images.githubusercontent.com/27637182/182039042-8a695898-70db-4d73-989e-07a56a7f7909.png) 3 | 4 | ![image](https://user-images.githubusercontent.com/27637182/182039105-257c7a6b-b86a-49c7-b9f3-f30e6658e3ed.png) 5 | 6 | ![image](https://user-images.githubusercontent.com/27637182/182039149-f205a954-197a-42f3-b585-3d0f575db1f2.png) 7 | 8 | ![image](https://user-images.githubusercontent.com/27637182/182039368-c12eacb9-99fc-43cf-b6cc-2eea14032a1d.png) 9 | 10 | -------------------------------------------------------------------------------- /Madr.md: -------------------------------------------------------------------------------- 1 | # {short title of solved problem and solution} 2 | 3 | 4 | ## Context and Problem Statement 5 | 6 | 7 | ## Decision Drivers 8 | 9 | 10 | ## Considered Options 11 | 12 | 13 | ## Decision Outcome 14 | 15 | 16 | ### Positive Consequences 17 | 18 | 19 | ### Negative Consequences 20 | 21 | ## Pros and Cons of the Options 22 | 23 | ### {option 1} 24 | 25 | ### {option 2} 26 | 27 | 28 | ## Links 29 | -------------------------------------------------------------------------------- /UtilityTree.puml: -------------------------------------------------------------------------------- 1 | @startmindmap 2 | * Quality 3 | ** 1.Perfomance 4 | *** Capacity 5 | ****_: ... 6 | ; 7 | 8 | ** 2.Relability 9 | *** Availability 10 | ****_: ... 11 | ; 12 | ****_: ... 13 | ; 14 | ****_: ... 15 | ; 16 | 17 | ** 3. Compatibility 18 | *** Interoperability 19 | ****_: ... 20 | 21 | ; 22 | ** 4. Functional Suitability 23 | 24 | *** Functional appropriateness 25 | 26 | ****_: .... 27 | ; 28 | 29 | ** 5. Portability 30 | 31 | *** Adaptability 32 | 33 | ****_: .... 34 | ; 35 | 36 | @endmindmap -------------------------------------------------------------------------------- /ROS2/Ros2Sequence.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | title Sequence Diagram for Ros2 Mw components 3 | participant Publisher_User_Code 4 | participant "RCLCpp(publisher)" as rcpp_p 5 | participant "RCL(publisher)" as rcl_p 6 | participant "RMW(publisher)" as rmw_p 7 | participant "DDS(publisher)" as dds_p 8 | participant "DDS(Subscriber)" as dds_s 9 | 10 | autonumber 11 | Publisher_User_Code->rcpp_p: Publisher::Publish 12 | rcpp_p->rcl_p: rcl_publish 13 | rcl_p->rmw_p: rmw_publish 14 | rmw_p->dds_p: data_writer.write 15 | dds_p->>dds_s: udp multicast.send/shared memory transfer 16 | 17 | @enduml -------------------------------------------------------------------------------- /ATAM Template.md: -------------------------------------------------------------------------------- 1 | 2 |
3 | 4 | | Scenario #: ... | ... || | | 5 | | :----------- |-----------|-----------|----------- |---------- | 6 | | **Environment:** | ... | 7 | |**Stimulus:**|... | 8 | |**Response:**| ...| 9 | |**Response Measure**|... | 10 | |**Architectural Decisions**| **Sensitivity** |**Tradeoff** |**Risks** |**Non-risk**| 11 | Decision 1 explanation|| Tradeof-1| | 12 | |Decision 2 Explanation|Sensitivitiy-1 | |Risk-1| 13 | |**Reasoning:**| | 14 | |**Sensitivity Tradeoff Risks Non-risk** |**Explanation**| 15 | |Tradeoff_1 | 16 | |Sensivitiy_1| 17 | |Risk-1| | 18 | 19 | -------------------------------------------------------------------------------- /ROS2/Ros2Sender.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | title Sequence diagram for sending a message 3 | participant main as main 4 | participant "rclpp" as rcpp_p 5 | participant "MinimalPublisher : public rclcpp::Node" as node 6 | participant publisher 7 | autonumber 8 | main->rcpp_p: init() 9 | create node 10 | main-> node:create 11 | node->node: create_publisher() 12 | create publisher 13 | node->publisher: 14 | node->node: create_wall_timer() 15 | main->rcpp_p :spin 16 | loop 17 | rcpp_p->node:execute() 18 | end 19 | group timer expires 20 | node->>node: timer_callback() 21 | create message 22 | node->message : new Message("Hello, world!") 23 | node->publisher:publish(message) 24 | end 25 | @enduml 26 | -------------------------------------------------------------------------------- /C4Examples/CleanComponent.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml 3 | ' uncomment the following line and comment the first to use locally 4 | ' !include C4_Component.puml 5 | 6 | LAYOUT_WITH_LEGEND() 7 | 8 | title Component Diagram for Voice Activated door control system 9 | 10 | Person_Ext(customer, "Person", "person walks to the door") 11 | Container(Service, "Service", "C++", "Main Service") 12 | 13 | Container(VoiceRecogniton, "VoiceRecogniton", "C++", "Voice Recognition Module") 14 | Container(DoorControl, "DoorControl", "C++", "Opens and Clsoeses door") 15 | 16 | Rel(customer,Service,"talks") 17 | Rel(Service,VoiceRecogniton,"Initiatesd Voice Recognition") 18 | Rel(Service,DoorControl,"Initiates Door control") 19 | 20 | @enduml 21 | 22 | -------------------------------------------------------------------------------- /C4Examples/CleanContext.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml 3 | ' uncomment the following line and comment the first to use locally 4 | ' !include C4_Component.puml 5 | 6 | LAYOUT_WITH_LEGEND() 7 | 8 | title Context Diagram for Voice Activated Door Control System 9 | 10 | Person(customer, "Person", "person walks to the door") 11 | System(VoiceActivatedDoorControl,"Voice Activated Door Control System","Receives realtime voice of person and makes recognition, then opens door if access permited") 12 | System_Ext(DoorControlHardware, "Door Control System", "Opens/Closes Door with electronics systems") 13 | System_Ext(MicrophoneSystem, "Microphone System", "Microphone for door control") 14 | Rel(customer, VoiceActivatedDoorControl, "Uses system to enter the house using own voice") 15 | Rel(VoiceActivatedDoorControl, DoorControlHardware, "Disceate IO","Commands to open/close door") 16 | Rel(VoiceActivatedDoorControl, MicrophoneSystem, "UDP","Gets voice data as UDP stream") 17 | @enduml 18 | 19 | -------------------------------------------------------------------------------- /C4Examples/CleanContainer.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml 3 | ' uncomment the following line and comment the first to use locally 4 | ' !include C4_Component.puml 5 | 6 | LAYOUT_WITH_LEGEND() 7 | 8 | title Container Diagram for Voice Activated Door Control System 9 | 10 | Person_Ext(customer, "Person", "person walks to the door") 11 | Container(VoiceActivatedDoorControl,"Voice Activated Door Control Microservice","c++","Receives realtime voice of person and makes recognition, then opens door if access permited") 12 | Container(VoiceTraining,"Voice Training Microservice","c++","Gets sample voices from rest sdervice and uses them for machine learing purpose") 13 | Container(WEBComponent,"WebComponent","React","User interface for management and monitoring of system") 14 | ContainerDb(DB, "DB", "PosgreeSQL", "Stores metadata for voice recognition") 15 | Rel_Down(customer,VoiceActivatedDoorControl,"audio") 16 | Rel_Down(customer,WEBComponent,"Trains own voice to system") 17 | Rel(VoiceActivatedDoorControl,DB,"Gets voice recognition data") 18 | Rel(VoiceTraining,DB,"Puts voice recognition data") 19 | Rel(WEBComponent,VoiceTraining,"Rest","Sends Voice Recognition Data") 20 | 21 | @enduml 22 | 23 | -------------------------------------------------------------------------------- /ROS2/Ros2Context.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml 3 | ' uncomment the following line and comment the first to use locally 4 | ' !include C4_Context.puml 5 | 6 | title System Context diagram for AutoWare Auto and ROS2 7 | 8 | Person(Integrator, "Integrator", "Autonomous Vehicle Developer") 9 | System(Autoware_Auto,"Autoware Auto", " Autoware is the world's first all-in-one open-source software for self-driving vehicles hosted under the Autoware Foundation. The Autoware.Auto project, based on ROS 2, is the next generation successor of the Autoware.AI project, based on ROS 1.") 10 | 11 | 12 | System(Ros2 , "ROS2", "Robot Operating System (ROS) is a set of open source algorithms, hardware driver software and tools developed to develop robot control software. ROS includes mature open source libraries to be used for navigation, control, motion planning, vision and simulation purposes.") 13 | 14 | System_Ext(DDS, "DDS", "Data Distribution Service (DDS) is a data centric publish/subscribe middleware used for data transmission in distributed real time systems. ") 15 | 16 | Rel(Integrator, Autoware_Auto, "Utilizes") 17 | Rel_Neighbor(Autoware_Auto, Ros2 , "Based on") 18 | 19 | Rel(Ros2 , DDS, "communication middleware") 20 | 21 | @enduml -------------------------------------------------------------------------------- /ROS2/Ros2Component.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml 3 | ' uncomment the following line and comment the first to use locally 4 | ' !include C4_Component.puml 5 | 6 | 7 | title Component Diagram for ROS2 components 8 | 9 | Component_Ext(DDS, "DDS Middleware library", "DDS Library from DDS vendor(Fast RTPS, Cyclone DDS, RTI Connext)") 10 | Component(usercodeCpp, "User Code", "C++", "User code, no direct access to DDS MW") 11 | Component(usercodePy, "User Code", "Py", "User code, no direct access to DDS MW") 12 | 13 | Container_Boundary(app, "ROS2 Components") { 14 | Component(rmw, "ROS middleware interface(RMW)", "C++", "The ROS middleware interface (rmw API) is the minimal set of primitive middleware capabilities needed to build ROS on top. Providers of different middleware implementations must implement this interface in order to support the entire ROS stack on top. \n pub/sub with QOS, Services with QOS, Discovery, Graph events") 15 | Component(rcl, "ROS Client Library(rcl)", "C api and optional C++ Implementation", " \n Nodes, Publisher, Subscription, Service Client, Service Server, Timer, Console logging, Parameter") 16 | Component(rclCPP, "rclCPP", "C++", "ROS Client Library C++ Wrapper.") 17 | Component(rclPy, "rclPy", "Python", "ROS Client Library Python Wrapper.") 18 | Rel(rmw, DDS, "Uses","Api") 19 | Rel(usercodeCpp, rclCPP, "Uses","Api") 20 | Rel(usercodePy, rclPy, "Uses","Api") 21 | Rel(rclCPP, rcl, "Uses","Api") 22 | Rel(rclPy, rcl, "Uses","Api") 23 | Rel(rcl, rmw, "Uses","Api") 24 | } 25 | 26 | @enduml -------------------------------------------------------------------------------- /C4Examples/clean.cpp: -------------------------------------------------------------------------------- 1 | #include 2 | #include 3 | #include 4 | 5 | class User; 6 | struct RecognitionData { 7 | int32_t id=0; 8 | }; 9 | 10 | class StatusData; 11 | class DoorInterface { 12 | public: 13 | void OpenDoor(int id) {} 14 | }; 15 | 16 | // outbound 17 | class RecognitionResultInterface { 18 | public: 19 | RecognitionResultInterface() = default; 20 | virtual ~RecognitionResultInterface() = default; 21 | virtual void SuccessfulRecognition(RecognitionData data) = 0; 22 | virtual void IncompleteSoundData(StatusData status) = 0; 23 | }; 24 | 25 | // outbound 26 | 27 | class DataBaseInterface { 28 | public: 29 | DataBaseInterface(); 30 | virtual ~DataBaseInterface(); 31 | virtual void GetMetaData() = 0; 32 | virtual void GetUserHistory(User user) = 0; 33 | }; 34 | 35 | // module interface inbound 36 | class VoiceRecogniton { 37 | public: 38 | VoiceRecogniton(); 39 | void Init(RecognitionResultInterface &, DataBaseInterface &); 40 | void Recognise(std::vector data); 41 | }; 42 | 43 | // Implementation 44 | 45 | class PosgreSQLDataBaseInterface : public DataBaseInterface { 46 | public: 47 | PosgreSQLDataBaseInterface(); 48 | virtual ~PosgreSQLDataBaseInterface(); 49 | void GetMetaData() override; 50 | void GetUserHistory(User user) override; 51 | 52 | private: 53 | DoorInterface door_interface_; 54 | }; 55 | 56 | 57 | // Implementation 58 | 59 | class RecognitionResultInterfaceImpl : public RecognitionResultInterface { 60 | public: 61 | explicit RecognitionResultInterfaceImpl(const std::shared_ptr& door_interface) 62 | : door_interface_(door_interface){}; 63 | void SuccessfulRecognition(RecognitionData data) override; 64 | void IncompleteSoundData(StatusData status) override; 65 | 66 | private: 67 | std::shared_ptr door_interface_; 68 | }; 69 | void RecognitionResultInterfaceImpl::SuccessfulRecognition(RecognitionData data) { 70 | // Send command to open door 71 | door_interface_->OpenDoor(data.id); 72 | } 73 | 74 | int main() { 75 | auto door_interface = std::make_shared(); 76 | 77 | RecognitionResultInterfaceImpl recognition_result_interface{door_interface}; 78 | 79 | PosgreSQLDataBaseInterface db_interface; 80 | 81 | 82 | auto voice_recognition = std::make_shared(); 83 | 84 | voice_recognition->Init(recognition_result_interface,db_interface); 85 | } 86 | -------------------------------------------------------------------------------- /ROS2/Ros2Container.puml: -------------------------------------------------------------------------------- 1 | @startuml 2 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml 3 | ' uncomment the following line and comment the first to use locally 4 | ' !include C4_Container.puml 5 | ' LAYOUT_TOP_DOWN() 6 | 7 | title Container diagram for Autoware Auto 8 | Container(Sensing, "Sensing", "Autoware mainly recognizes road environments with the help of LIDAR scanners and cameras.") 9 | Container(Localization, "Localization", "The localization contains nodes and libraries which provide an estimate regarding the location of the vehicle using various methods and algorithms") 10 | Container(Perception, "Perception", "filters and segmentation. The filters are nodes and libraries which are part of the filtering pipeline for sensor data. Nodes work as standalone filtering modules or cascaded with other filtering algorithms working on the same sensor data types. Enable sensor data to be grouped into clusters or objects of interest which can provide downstream procsses more information about the environment.") 11 | Container(Planning, "Planning", "Produce a trajectory towards a provided goal. Involved in the planning process in order to alleviate the complexity of the path-planning optimization problem.") 12 | Container(Control, "Control", "Nodes and libraries related to the controller functionalities of the vehicle. They enable the autonomous vehicle to follow a reference trajectory appropriately by converting the input trajectory into longitudinal and lateral commands.") 13 | Container(VehicleInterface, "Vehicle Interface", "Sensor/Actuator Drivers") 14 | 15 | System_Ext(Vehicle, "Vehicle", "The Autonomous Vehicle") 16 | System_Ext(Sensors, "Sensors", "Lidar, Camera, GPS etc.") 17 | Rel(Sensors, Sensing, "Socket, Serial etc.") 18 | Rel(Sensing, Perception, "Sensing Data") 19 | Rel_Neighbor(Perception, Planning, "Surrounding Environment") 20 | Rel_Neighbor(Planning, Control, "Trajectory") 21 | Rel(Control, VehicleInterface, "Vehicle Commands") 22 | Rel(VehicleInterface,Control, "Steering, Velocity Feedback") 23 | BiRel(VehicleInterface, Vehicle, "Can, Socket, Serial") 24 | Rel(Sensing, Localization, "Current Position and Velocity") 25 | Rel(Localization,Perception, "Current Position and velocity") 26 | Rel(Localization,Planning, "Current Position and velocity") 27 | Rel(Localization, Control, "Current Position and velocity") 28 | Rel(VehicleInterface, Localization, "VehicleSensor") 29 | @enduml -------------------------------------------------------------------------------- /madr_with_desc.md: -------------------------------------------------------------------------------- 1 | # {short title of solved problem and solution} 2 | 3 | * Status: {proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)} 4 | * Deciders: {list everyone involved in the decision} 5 | * Date: {YYYY-MM-DD when the decision was last updated} 6 | 7 | Technical Story: {description | ticket/issue URL} 8 | 9 | ## Context and Problem Statement 10 | 11 | {Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.} 12 | 13 | ## Decision Drivers 14 | 15 | * {driver 1, e.g., a force, facing concern, …} 16 | * {driver 2, e.g., a force, facing concern, …} 17 | * … 18 | 19 | ## Considered Options 20 | 21 | * {option 1} 22 | * {option 2} 23 | * {option 3} 24 | * … 25 | 26 | ## Decision Outcome 27 | 28 | Chosen option: "{option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}. 29 | 30 | ### Positive Consequences 31 | 32 | * {e.g., improvement of quality attribute satisfaction, follow-up decisions required, …} 33 | * … 34 | 35 | ### Negative Consequences 36 | 37 | * {e.g., compromising quality attribute, follow-up decisions required, …} 38 | * … 39 | 40 | ## Pros and Cons of the Options 41 | 42 | ### {option 1} 43 | 44 | {example | description | pointer to more information | …} 45 | 46 | * Good, because {argument a} 47 | * Good, because {argument b} 48 | * Bad, because {argument c} 49 | * … 50 | 51 | ### {option 2} 52 | 53 | {example | description | pointer to more information | …} 54 | 55 | * Good, because {argument a} 56 | * Good, because {argument b} 57 | * Bad, because {argument c} 58 | * … 59 | 60 | ### {option 3} 61 | 62 | {example | description | pointer to more information | …} 63 | 64 | * Good, because {argument a} 65 | * Good, because {argument b} 66 | * Bad, because {argument c} 67 | * … 68 | 69 | ## Links 70 | 71 | * {Link type} {Link to ADR} 72 | * … 73 | 74 | 75 | -------------------------------------------------------------------------------- /c4 Diagrams: -------------------------------------------------------------------------------- 1 | Context Diagram 2 | ```plantuml 3 | @startuml 4 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml 5 | ' uncomment the following line and comment the first to use locally 6 | ' !include C4_Context.puml 7 | 8 | title System Context diagram for AutoWare Auto and ROS2 9 | 10 | Person(Integrator, "Integrator", "Autonomous Vehicle Developer") 11 | System(Autoware_Auto,"Autoware Auto", " Autoware is the world's first all-in-one open-source software for self-driving vehicles hosted under the Autoware Foundation. The Autoware.Auto project, based on ROS 2, is the next generation successor of the Autoware.AI project, based on ROS 1.") 12 | 13 | 14 | System(Ros2 , "ROS2", "Robot Operating System (ROS) is a set of open source algorithms, hardware driver software and tools developed to develop robot control software. ROS includes mature open source libraries to be used for navigation, control, motion planning, vision and simulation purposes.") 15 | 16 | System_Ext(DDS, "DDS", "Data Distribution Service (DDS)  is a data centric publish/subscribe middleware used for data transmission in distributed real time systems. ") 17 | 18 | Rel(Integrator, Autoware_Auto, "Utilizes") 19 | Rel_Neighbor(Autoware_Auto, Ros2 , "Based on") 20 | 21 | Rel(Ros2 , DDS, "communication middleware") 22 | 23 | @enduml 24 | ``` 25 | 26 | 27 | Container Diagram 28 | ```plantuml 29 | @startuml 30 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml 31 | ' uncomment the following line and comment the first to use locally 32 | ' !include C4_Container.puml 33 | 34 | ' LAYOUT_TOP_DOWN() 35 | ' LAYOUT_AS_SKETCH() 36 | LAYOUT_WITH_LEGEND() 37 | 38 | title Container diagram for Autoware Auto 39 | 40 | 41 | Container(Sensing, "Sensing", "Autoware mainly recognizes road environments with the help of LIDAR scanners and cameras.") 42 | 43 | Container(Localization, "Localization", "The localization contains nodes and libraries which provide an estimate regarding the location of the vehicle using various methods and algorithms") 44 | Container(Perception, "Perception", "filters and segmentation. The filters are nodes and libraries which are part of the filtering pipeline for sensor data. Nodes work as standalone filtering modules or cascaded with other filtering algorithms working on the same sensor data types. Enable sensor data to be grouped into clusters or objects of interest which can provide downstream procsses more information about the environment.") 45 | Container(Planning, "Planning", "Produce a trajectory towards a provided goal. Involved in the planning process in order to alleviate the complexity of the path-planning optimization problem.") 46 | 47 | Container(Control, "Control", "Nodes and libraries related to the controller functionalities of the vehicle. They enable the autonomous vehicle to follow a reference trajectory appropriately by converting the input trajectory into longitudinal and lateral commands.") 48 | Container(VehicleInterface, "Vehicle Interface", "Sensor/Actuator Drivers") 49 | 50 | 51 | System_Ext(Vehicle, "Vehicle", "The Autonomous Vehicle") 52 | System_Ext(Sensors, "Sensors", "Lidar, Camera, GPS etc.") 53 | 54 | Rel(Sensors, Sensing, "Socket, Serial etc.") 55 | Rel(Sensing, Perception, "Sensing Data") 56 | Rel_Neighbor(Perception, Planning, "Surrounding Environment") 57 | Rel_Neighbor(Planning, Control, "Trajectory") 58 | 59 | Rel(Control, VehicleInterface, "Vehicle Commands") 60 | Rel(VehicleInterface,Control, "Steering, Velocity Feedback") 61 | 62 | BiRel(VehicleInterface, Vehicle, "Can, Socket, Serial") 63 | 64 | Rel(Sensing, Localization, "Current Position and Velocity") 65 | Rel(Localization,Perception, "Current Position and velocity") 66 | Rel(Localization,Planning, "Current Position and velocity") 67 | Rel(Localization, Control, "Current Position and velocity") 68 | Rel(VehicleInterface, Localization, "VehicleSensor") 69 | 70 | @enduml 71 | ``` 72 | 73 | 74 | 75 | 76 | 77 | ```plantuml 78 | @startuml 79 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml 80 | ' uncomment the following line and comment the first to use locally 81 | ' !include C4_Component.puml 82 | 83 | LAYOUT_WITH_LEGEND() 84 | 85 | title Component Diagram for ROS2 based Autoware Auto Application 86 | 87 | Component_Ext(DDS, "DDS Middleware library", "DDS Library from DDS vendor") 88 | Container(usercode, "User Code", "C++", "User code for Vehicle Interface, Perception, Planning etc.") 89 | 90 | Container_Boundary(app, "ROS2 Components") { 91 | Component(rmw, "RMW", "C++", "ROS middleware Interface") 92 | Component(rcl, "rcl", "C++", "ROS Client Library") 93 | Component(rclCPP, "rclCPP", "C++", "ROS Client Library C++ Wrapper.") 94 | Rel(rmw, DDS, "Uses","Api") 95 | Rel(usercode, rclCPP, "Uses","Api") 96 | Rel(rclCPP, rcl, "Uses","Api") 97 | Rel(rcl, rmw, "Uses","Api") 98 | } 99 | 100 | @enduml 101 | ``` 102 | 103 | 104 | 105 | 106 | 107 | ```plantuml 108 | @startuml 109 | participant User_Code 110 | participant RCLCpp 111 | participant RCL 112 | participant RMW 113 | participant DDS 114 | autonumber 115 | User_Code->RCLCpp: Publisher::Publish 116 | RCLCpp->RCL: rcl_publish 117 | RCL->RMW: rmw_publish 118 | RMW->DDS: data_writer.write 119 | @enduml 120 | 121 | ``` 122 | -------------------------------------------------------------------------------- /C4Modeli.md: -------------------------------------------------------------------------------- 1 | Context Diagram 2 | ============== 3 | 4 | 5 | ```plantuml 6 | 7 | @startuml 8 | 9 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml 10 | ' uncomment the following line and comment the first to use locally 11 | ' !include C4_Context.puml 12 | 13 | title System Context diagram for AutoWare Auto and ROS2 14 | 15 | Person(Integrator, "Integrator", "Autonomous Vehicle Developer") 16 | System(Autoware_Auto,"Autoware Auto", " Autoware is the world's first all-in-one open-source software for self-driving vehicles hosted under the Autoware Foundation. The Autoware.Auto project, based on ROS 2, is the next generation successor of the Autoware.AI project, based on ROS 1.") 17 | 18 | 19 | System(Ros2 , "ROS2", "Robot Operating System (ROS) is a set of open source algorithms, hardware driver software and tools developed to develop robot control software. ROS includes mature open source libraries to be used for navigation, control, motion planning, vision and simulation purposes.") 20 | 21 | System_Ext(DDS, "DDS", "Data Distribution Service (DDS) is a data centric publish/subscribe middleware used for data transmission in distributed real time systems. ") 22 | 23 | Rel(Integrator, Autoware_Auto, "Utilizes") 24 | Rel_Neighbor(Autoware_Auto, Ros2 , "Based on") 25 | 26 | Rel(Ros2 , DDS, "communication middleware") 27 | 28 | @enduml 29 | ``` 30 | 31 | Container Diagram 32 | =============== 33 | ```plantuml 34 | @startuml 35 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml 36 | ' uncomment the following line and comment the first to use locally 37 | ' !include C4_Container.puml 38 | 39 | ' LAYOUT_TOP_DOWN() 40 | ' LAYOUT_AS_SKETCH() 41 | LAYOUT_WITH_LEGEND() 42 | 43 | title Container diagram for Autoware Auto 44 | 45 | 46 | Container(Sensing, "Sensing", "Autoware mainly recognizes road environments with the help of LIDAR scanners and cameras.") 47 | 48 | Container(Localization, "Localization", "The localization contains nodes and libraries which provide an estimate regarding the location of the vehicle using various methods and algorithms") 49 | Container(Perception, "Perception", "filters and segmentation. The filters are nodes and libraries which are part of the filtering pipeline for sensor data. Nodes work as standalone filtering modules or cascaded with other filtering algorithms working on the same sensor data types. Enable sensor data to be grouped into clusters or objects of interest which can provide downstream procsses more information about the environment.") 50 | Container(Planning, "Planning", "Produce a trajectory towards a provided goal. Involved in the planning process in order to alleviate the complexity of the path-planning optimization problem.") 51 | 52 | Container(Control, "Control", "Nodes and libraries related to the controller functionalities of the vehicle. They enable the autonomous vehicle to follow a reference trajectory appropriately by converting the input trajectory into longitudinal and lateral commands.") 53 | Container(VehicleInterface, "Vehicle Interface", "Sensor/Actuator Drivers") 54 | 55 | 56 | System_Ext(Vehicle, "Vehicle", "The Autonomous Vehicle") 57 | System_Ext(Sensors, "Sensors", "Lidar, Camera, GPS etc.") 58 | 59 | Rel(Sensors, Sensing, "Socket, Serial etc.") 60 | Rel(Sensing, Perception, "Sensing Data") 61 | Rel_Neighbor(Perception, Planning, "Surrounding Environment") 62 | Rel_Neighbor(Planning, Control, "Trajectory") 63 | 64 | Rel(Control, VehicleInterface, "Vehicle Commands") 65 | Rel(VehicleInterface,Control, "Steering, Velocity Feedback") 66 | 67 | BiRel(VehicleInterface, Vehicle, "Can, Socket, Serial") 68 | 69 | Rel(Sensing, Localization, "Current Position and Velocity") 70 | Rel(Localization,Perception, "Current Position and velocity") 71 | Rel(Localization,Planning, "Current Position and velocity") 72 | Rel(Localization, Control, "Current Position and velocity") 73 | Rel(VehicleInterface, Localization, "VehicleSensor") 74 | 75 | @enduml 76 | ``` 77 | 78 | 79 | 80 | Component Diagram 81 | ================= 82 | 83 | ```plantuml 84 | @startuml 85 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml 86 | ' uncomment the following line and comment the first to use locally 87 | ' !include C4_Component.puml 88 | 89 | LAYOUT_WITH_LEGEND() 90 | 91 | title Component Diagram for ROS2 based Autoware Auto Application 92 | 93 | Component_Ext(DDS, "DDS Middleware library", "DDS Library from DDS vendor") 94 | Container(usercode, "User Code", "C++", "User code for Vehicle Interface, Perception, Planning etc.") 95 | 96 | Container_Boundary(app, "ROS2 Components") { 97 | Component(rmw, "RMW", "C++", "ROS middleware Interface") 98 | Component(rcl, "rcl", "C++", "ROS Client Library") 99 | Component(rclCPP, "rclCPP", "C++", "ROS Client Library C++ Wrapper.") 100 | Rel(rmw, DDS, "Uses","Api") 101 | Rel(usercode, rclCPP, "Uses","Api") 102 | Rel(rclCPP, rcl, "Uses","Api") 103 | Rel(rcl, rmw, "Uses","Api") 104 | } 105 | 106 | @enduml 107 | ``` 108 | 109 | 110 | CODE 111 | ================== 112 | 113 | ```plantuml 114 | @startuml 115 | participant User_Code 116 | participant RCLCpp 117 | participant RCL 118 | participant RMW 119 | participant DDS 120 | autonumber 121 | User_Code->RCLCpp: Publisher::Publish 122 | RCLCpp->RCL: rcl_publish 123 | RCL->RMW: rmw_publish 124 | RMW->DDS: data_writer.write 125 | @enduml 126 | 127 | ``` 128 | -------------------------------------------------------------------------------- /arch42_with_c4.md: -------------------------------------------------------------------------------- 1 | # 2 | 3 | **About arc42** 4 | 5 | arc42, the Template for documentation of software and system 6 | architecture. 7 | 8 | Created and maintained by Dr. Peter Hruschka, Dr. Gernot Starke and 9 | contributors. 10 | 11 | Template Revision: 8.0 EN (based on asciidoc), February 2022 12 | 13 | © We acknowledge that this document uses material from the arc 42 14 | architecture template, . 15 | 16 | # Introduction and Goals {#section-introduction-and-goals} 17 | 18 | ## Requirements Overview {#_requirements_overview} 19 | 20 | ## Quality Goals {#_quality_goals} 21 | 22 | ## Stakeholders {#_stakeholders} 23 | 24 | +-------------+---------------------------+---------------------------+ 25 | | Role/Name | Contact | Expectations | 26 | +=============+===========================+===========================+ 27 | | * | *\* | *\* | 28 | | \* | | | 29 | +-------------+---------------------------+---------------------------+ 30 | | * | *\* | *\* | 31 | | \* | | | 32 | +-------------+---------------------------+---------------------------+ 33 | 34 | # Architecture Constraints {#section-architecture-constraints} 35 | 36 | # System Scope and Context {#section-system-scope-and-context} 37 | 38 | 39 | ## Business Context {#_business_context} 40 | 41 | Context Diagram 42 | ```plantuml 43 | @startuml 44 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml 45 | ' uncomment the following line and comment the first to use locally 46 | ' !include C4_Context.puml 47 | 48 | title System Context diagram for AutoWare Auto and ROS2 49 | 50 | Person(Integrator, "Integrator", "Autonomous Vehicle Developer") 51 | System(Autoware_Auto,"Autoware Auto", " Autoware is the world's first all-in-one open-source software for self-driving vehicles hosted under the Autoware Foundation. The Autoware.Auto project, based on ROS 2, is the next generation successor of the Autoware.AI project, based on ROS 1.") 52 | 53 | 54 | System(Ros2 , "ROS2", "Robot Operating System (ROS) is a set of open source algorithms, hardware driver software and tools developed to develop robot control software. ROS includes mature open source libraries to be used for navigation, control, motion planning, vision and simulation purposes.") 55 | 56 | System_Ext(DDS, "DDS", "Data Distribution Service (DDS)  is a data centric publish/subscribe middleware used for data transmission in distributed real time systems. ") 57 | 58 | Rel(Integrator, Autoware_Auto, "Utilizes") 59 | Rel_Neighbor(Autoware_Auto, Ros2 , "Based on") 60 | 61 | Rel(Ros2 , DDS, "communication middleware") 62 | 63 | @enduml 64 | ``` 65 | 66 | **\** 67 | 68 | ## Technical Context {#_technical_context} 69 | 70 | **\** 71 | 72 | **\** 73 | 74 | **\** 75 | 76 | # Solution Strategy {#section-solution-strategy} 77 | 78 | # Building Block View {#section-building-block-view} 79 | Container Diagram 80 | ```plantuml 81 | @startuml 82 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml 83 | ' uncomment the following line and comment the first to use locally 84 | ' !include C4_Container.puml 85 | 86 | ' LAYOUT_TOP_DOWN() 87 | ' LAYOUT_AS_SKETCH() 88 | LAYOUT_WITH_LEGEND() 89 | 90 | title Container diagram for Autoware Auto 91 | 92 | 93 | Container(Sensing, "Sensing", "Autoware mainly recognizes road environments with the help of LIDAR scanners and cameras.") 94 | 95 | Container(Localization, "Localization", "The localization contains nodes and libraries which provide an estimate regarding the location of the vehicle using various methods and algorithms") 96 | Container(Perception, "Perception", "filters and segmentation. The filters are nodes and libraries which are part of the filtering pipeline for sensor data. Nodes work as standalone filtering modules or cascaded with other filtering algorithms working on the same sensor data types. Enable sensor data to be grouped into clusters or objects of interest which can provide downstream procsses more information about the environment.") 97 | Container(Planning, "Planning", "Produce a trajectory towards a provided goal. Involved in the planning process in order to alleviate the complexity of the path-planning optimization problem.") 98 | 99 | Container(Control, "Control", "Nodes and libraries related to the controller functionalities of the vehicle. They enable the autonomous vehicle to follow a reference trajectory appropriately by converting the input trajectory into longitudinal and lateral commands.") 100 | Container(VehicleInterface, "Vehicle Interface", "Sensor/Actuator Drivers") 101 | 102 | 103 | System_Ext(Vehicle, "Vehicle", "The Autonomous Vehicle") 104 | System_Ext(Sensors, "Sensors", "Lidar, Camera, GPS etc.") 105 | 106 | Rel(Sensors, Sensing, "Socket, Serial etc.") 107 | Rel(Sensing, Perception, "Sensing Data") 108 | Rel_Neighbor(Perception, Planning, "Surrounding Environment") 109 | Rel_Neighbor(Planning, Control, "Trajectory") 110 | 111 | Rel(Control, VehicleInterface, "Vehicle Commands") 112 | Rel(VehicleInterface,Control, "Steering, Velocity Feedback") 113 | 114 | BiRel(VehicleInterface, Vehicle, "Can, Socket, Serial") 115 | 116 | Rel(Sensing, Localization, "Current Position and Velocity") 117 | Rel(Localization,Perception, "Current Position and velocity") 118 | Rel(Localization,Planning, "Current Position and velocity") 119 | Rel(Localization, Control, "Current Position and velocity") 120 | Rel(VehicleInterface, Localization, "VehicleSensor") 121 | 122 | @enduml 123 | 124 | ``` 125 | 126 | 127 | ## Whitebox Overall System {#_whitebox_overall_system} 128 | 129 | ***\*** 130 | ```plantuml 131 | @startuml 132 | !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml 133 | ' uncomment the following line and comment the first to use locally 134 | ' !include C4_Component.puml 135 | 136 | LAYOUT_WITH_LEGEND() 137 | 138 | title Component Diagram for ROS2 based Autoware Auto Application 139 | 140 | Component_Ext(DDS, "DDS Middleware library", "DDS Library from DDS vendor") 141 | Container(usercode, "User Code", "C++", "User code for Vehicle Interface, Perception, Planning etc.") 142 | 143 | Container_Boundary(app, "ROS2 Components") { 144 | Component(rmw, "RMW", "C++", "ROS middleware Interface") 145 | Component(rcl, "rcl", "C++", "ROS Client Library") 146 | Component(rclCPP, "rclCPP", "C++", "ROS Client Library C++ Wrapper.") 147 | Rel(rmw, DDS, "Uses","Api") 148 | Rel(usercode, rclCPP, "Uses","Api") 149 | Rel(rclCPP, rcl, "Uses","Api") 150 | Rel(rcl, rmw, "Uses","Api") 151 | } 152 | 153 | @enduml 154 | ``` 155 | Motivation 156 | 157 | : *\* 158 | 159 | Contained Building Blocks 160 | 161 | : *\* 162 | 163 | Important Interfaces 164 | 165 | : *\* 166 | 167 | ### \ {#__name_black_box_1} 168 | 169 | *\* 170 | 171 | *\* 172 | 173 | *\<(Optional) Quality/Performance Characteristics\>* 174 | 175 | *\<(Optional) Directory/File Location\>* 176 | 177 | *\<(Optional) Fulfilled Requirements\>* 178 | 179 | *\<(optional) Open Issues/Problems/Risks\>* 180 | 181 | ### \ {#__name_black_box_2} 182 | 183 | *\* 184 | 185 | ### \ {#__name_black_box_n} 186 | 187 | *\* 188 | 189 | ### \ {#__name_interface_1} 190 | 191 | ... 192 | 193 | ### \ {#__name_interface_m} 194 | 195 | ## Level 2 {#_level_2} 196 | 197 | ### White Box *\* {#_white_box_emphasis_building_block_1_emphasis} 198 | 199 | *\* 200 | 201 | ### White Box *\* {#_white_box_emphasis_building_block_2_emphasis} 202 | 203 | *\* 204 | 205 | ... 206 | 207 | ### White Box *\* {#_white_box_emphasis_building_block_m_emphasis} 208 | 209 | *\* 210 | 211 | ## Level 3 {#_level_3} 212 | 213 | ### White Box \<\_building block x.1\_\> {#_white_box_building_block_x_1} 214 | 215 | *\* 216 | 217 | ### White Box \<\_building block x.2\_\> {#_white_box_building_block_x_2} 218 | 219 | *\* 220 | 221 | ### White Box \<\_building block y.1\_\> {#_white_box_building_block_y_1} 222 | 223 | *\* 224 | 225 | # Runtime View {#section-runtime-view} 226 | 227 | ## \ {#__runtime_scenario_1} 228 | 229 | - *\* 230 | 231 | - *\* 233 | 234 | ## \ {#__runtime_scenario_2} 235 | 236 | ## ... {#_} 237 | 238 | ## \ {#__runtime_scenario_n} 239 | 240 | # Deployment View {#section-deployment-view} 241 | 242 | ## Infrastructure Level 1 {#_infrastructure_level_1} 243 | 244 | ***\*** 245 | 246 | Motivation 247 | 248 | : *\* 249 | 250 | Quality and/or Performance Features 251 | 252 | : *\* 253 | 254 | Mapping of Building Blocks to Infrastructure 255 | 256 | : *\* 257 | 258 | ## Infrastructure Level 2 {#_infrastructure_level_2} 259 | 260 | ### *\* {#__emphasis_infrastructure_element_1_emphasis} 261 | 262 | *\* 263 | 264 | ### *\* {#__emphasis_infrastructure_element_2_emphasis} 265 | 266 | *\* 267 | 268 | ... 269 | 270 | ### *\* {#__emphasis_infrastructure_element_n_emphasis} 271 | 272 | *\* 273 | 274 | # Cross-cutting Concepts {#section-concepts} 275 | 276 | ## *\* {#__emphasis_concept_1_emphasis} 277 | 278 | *\* 279 | 280 | ## *\* {#__emphasis_concept_2_emphasis} 281 | 282 | *\* 283 | 284 | ... 285 | 286 | ## *\* {#__emphasis_concept_n_emphasis} 287 | 288 | *\* 289 | 290 | # Architecture Decisions {#section-design-decisions} 291 | 292 | # Quality Requirements {#section-quality-scenarios} 293 | 294 | ## Quality Tree {#_quality_tree} 295 | 296 | ```plantuml 297 | 298 | @startmindmap 299 | * Quality 300 | ** 1.Perfomance 301 | *** Capacity 302 | ****_: ... 303 | ; 304 | 305 | ** 2.Relability 306 | *** Availability 307 | ****_: ... 308 | ; 309 | ****_: ... 310 | ; 311 | ****_: ... 312 | ; 313 | 314 | ** 3. Compatibility 315 | *** Interoperability 316 | ****_: ... 317 | 318 | ; 319 | ** 4. Functional Suitability 320 | 321 | *** Functional appropriateness 322 | 323 | ****_: .... 324 | ; 325 | 326 | ** 5. Portability 327 | 328 | *** Adaptability 329 | 330 | ****_: .... 331 | ; 332 | 333 | @endmindmap 334 | 335 | ``` 336 | ## Quality Scenarios {#_quality_scenarios} 337 | 338 |
339 | 340 | | Scenario #: Availability | Scenario Name || | | 341 | | :----------- |-----------|-----------|----------- |---------- | 342 | | **Environment:** | ... | 343 | |**Stimulus:**|... | 344 | |**Response:**| ...| 345 | |**Response Measure**|... | 346 | |**Architectural Decisions**| **Sensitivity** |**Tradeoff** |**Risks** |**Non-risk**| 347 | Decision 1 explanation|| Tradeof-1| | 348 | |Decision 2 Explanation|Sensitivitiy-1 | |Risk-1| 349 | |**Reasoning:**| | 350 | |**Sensitivity Tradeoff Risks Non-risk** |**Explanation**| 351 | |Tradeoff_1 | 352 | |Sensivitiy_1| 353 | |Risk-1| | 354 | 355 | 356 | # Risks and Technical Debts {#section-technical-risks} 357 | 358 | # Glossary {#section-glossary} 359 | 360 | +-----------------------+-----------------------------------------------+ 361 | | Term | Definition | 362 | +=======================+===============================================+ 363 | | *\* | *\* | 364 | +-----------------------+-----------------------------------------------+ 365 | | *\* | *\* | 366 | +-----------------------+-----------------------------------------------+ 367 | -------------------------------------------------------------------------------- /Sözlük.csv: -------------------------------------------------------------------------------- 1 | ;;;;; 2 | Terim;İngilizce;Açıklaması;İlgili Yazı;; 3 | Açık mimari;Open Architecture;"Açık Mimari, açık standartları kullanarak geliştirilmiş ve yeni bileşen ekleme, değiştirme ve yerine farklısını koyma yada çıkartmayı kolaylaştırmış bilgisayar yada yazılım mimarisi olarak tanımlanabilir. Açık ve ortak kabul görmüş standartların kullanımı 4 | Arayüz protokol ve veri standartlarının kabul edilmesi 5 | Standart servislerin belirlenmesi 6 | Birden fazla üretici tarafından sağlanan ürünlerin kullanımı 7 | En az çaba ile birlikte çalışabilirlik 8 | Kolayca ölçeklenebilir ve güncellenebilir sistemler 9 | Taşınabilir uygulamalar 10 | Taşınabilir kullanıcılar(kullanıcıların aynı amaçlı farklı sistemlere kolayca adapte olması)";https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/a%C3%A7%C4%B1k-sistem-mimarileri-1-temel-%C3%B6zellikler-6a413b754a62;; 11 | Arakatman ;middleware;Dağıtık ortamda farklı çalışabilir modüller olarak geliştirilen yazılımın bir bütün olarak çalışabilmesi için başta veri alışverişi olmak üzere farklı seviyelerde işbirliği yapmaları gerekmektedir. Dağıtık ortamda çalışan bu uygulamaların iletişimi için kendimizin geliştireceği TCP/IP yada UDP protokolü ile haberleşen kütüphanelerden yerine Arakatman yazılımları dağıtık uygulamalar ile işletim sistemi ve haberleşme protokolü arasında bir katman olarak görülmektedir. Heterojen bir sistemde tüm farklılıkları yöneterek üst seviye uygulamaları karmaşıklıktan kurtarır. Aynı zamanda bu uygulamaların herhangi bir anda hangi bilgisayar üzerinde çalıştığı, o an hayatta olup olmadığı, veriyi almaya hazır olup olmadığı gibi daha birçok teknik problemi çözmek üzere tasarlanmaktadır.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/arakatmanlar-1-arakatman-yaz%C4%B1l%C4%B1mlar%C4%B1-genel-bilgiler-c6c8d5e8f23a;; 12 | Bağımlılık;Coupling;"Bağımlılık kod seviyesi (kod), kurulabilme (deployment) veya çalışma zamanı (execution time) olabilmektedir. Her bir seviye bağımlılığın azaltılması farklı açılardan projeye fayda sağlayacaktır.  13 | Veri Yapısı Bağımlılığında bir bileşen diğer bir bileşen ile bir nesne yada veri yapısının tamamını paylaşır. Kontrol bağımlılığında bir başka bir bileşenin nasıl işleyeceği ile ilgili kontrol algoritmasını belirler. 14 | Dış bağımlılıkta yazılım bileşeni dış bir donanıma yada başka bir yazılıma bağımlıdır. 15 | Ortak bağımlılıkta ise iki bileşen ortak bir veri yapısına bağımlıdır. 16 | İçerik Bağımlılığında bir bileşen diğer bileşenin verisini yada kontrol akışını değiştirir. Bu en kötü bağımlılıktır.";https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/tasar%C4%B1m%C4%B1n-temelleri-2-ba%C4%9F%C4%B1ml%C4%B1l%C4%B1k-ve-uyumluluk-tasar%C4%B1m-prensipleri-20e28490e985;; 17 | Bileşen tabanlı mimari ;Component Based Architecture;Sistem küçük bileşenler ve bu bileşenleri bir arada tutan bileşen yöneticisinden meydana gelir. Bileşen yöneticisi çalışma zamanında kendisine tanımlanan bileşenleri başlatabilir, durdurabilir. Bileşenlerin genelde tanımlı standart ara yüzleri bulunmaktadır. ;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/mimari-tasar%C4%B1m-kal%C4%B1plar%C4%B1-94a4f47d32a8;; 18 | Desen;Pattern ;Mimari desenler ise tekrarlanan tasarım problemlerine bulunmuş ve çalıştığı ispat edilmiş çözüm yöntemleridir. Bina mimari tasarımında kullanılan tasarım kalıpları ile benzer yaklaşımdadır. Mimari desenler, yazılım geliştirmede kullanılan tasarım desenlerine göre daha üst seviyede görülmektedir.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarisi-temel-kavramlar-4de64353b4ac;; 19 | Durum Makinesi;State Machine;Nesnelerin kontrol ve durum akışını modellemek için kullanılır. Durum(State) tasarladığımız sistemin belirli bir işi yaptığı yada başka bir duruma geçmek için uyarı beklediği koşullardır. laylar (Event) sistemde durum değişikliğine sebep olan iç veya dış itkilerdir. Bir tuşa basılması, belirli bir zamanın geçmesi, kapının açılması birer olay olarak durum değişikliğine sebep olurlar.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/g%C3%B6m%C3%BCl%C3%BC-ve-ger%C3%A7ek-zamanl%C4%B1-tasar%C4%B1m-kal%C4%B1plar%C4%B1-1-durum-makineleri-e9ab5200decb;; 20 | Kalite Öznitelikleri Çalıştayı ;Quality Attribute Workshop;Proje paydaşlarını bir araya getirerek etkileşim ile gereksinimler üzerinde hemfikir olmayı hedefler. Bu etkileşim geliştirilen sistemin paydaşların beklentileri ile uyumlu olmasını ve projenin geliştirme aşamasında başarısızlığa sebep olacak hataya dayanıklılık, performans gibi kalite gereksinimlerinin erken aşamada tasarıma girmesini sağlayacaktır.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/kalite-%C3%B6znitelikleri-%C3%A7al%C4%B1%C5%9Ftay%C4%B1-ya-da-kalite-fikir-f%C4%B1rt%C4%B1nas%C4%B1-a521409c7a23;; 21 | Kalite Öznitelikleri Tabanlı Tasarım ;Attribute Driven Design-ADD;Kalite Öznitelikleri Tabanlı Tasarım öncelikleana kullanım durumları, kalite öznitelik senaryoları, mimari kaygılar ve proje sınırlamaları girdilerin değerlendirilmesi ile başlıyor. Bu veriler değerlendirildikten sonra tekrarlı bir şekilde yazılım mimarisi tasarımı üst seviyeden başlanılarak detaylandırılır. Tasarım problemi daha alt problemlere bölünür. Bu döngüde hangi problemi adresleyeceğine karar verirsin. Genelde ilk iterasyonda sistem mimarisinin ana iskeleti oluşturulur. Daha sonra bu iskeleti destekleyecek ek yapılar tasarlanır. İhtiyaç duyulması durumunda üçüncü ve devamındaki döngülerde hala çözüm üretilmemiş problemler çözümlenir.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarileri-5-kalite-%C3%B6znitelikleri-tabanl%C4%B1-tasar%C4%B1m-fb38d79376f3;; 22 | Katmanlı Mimari;Layered Architecture;Her katman farklı bir fonksiyonu yerine getirir ve genel olarak kendisinden bir alt ve bir üst katman ile iletişim kurar. Katmanlı mimari kalıbında eğer bir katman sadece bir alt katmandan servis alabiliyor ise bu tür sistemlere kapalı katmanlı sistem diyoruz. Bir katman kendinden iki ve daha fazla altta olan katmanlara da erişiyor ise buna açık katmanlı sistem denmektedir.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/mimari-tasar%C4%B1m-kal%C4%B1plar%C4%B1-94a4f47d32a8;; 23 | Mevcut Sistemde Tasarım Değişikliği; BrownField System;Mevcut bir sistemin üzerine sistemin geçmişten gelen tasarımsal kısıtlarını göz önünde tutarak ekleme ve değişiklikler yapılır.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarileri-5-kalite-%C3%B6znitelikleri-tabanl%C4%B1-tasar%C4%B1m-fb38d79376f3;; 24 | Mikro-Servis Mimarisi;Microserivce Architecture;Mikro servis kavramındaki temel bakış servislerin mikro olmasından çok anlamlı ve tek bir iş mantığımı sağlıyor olmasıdır. Aynı zamanda yönetilebilir küçük bir takım tarafından geliştirilebilir olması önem verilen bir noktadır. Mikro servis mimarisi aslında dağıtık mimarinin temel faydalarından faydalanmak üzere gelişmiştir. Servisler birbirinden bağımsız şekilde yüklenebilir. Bir servis istenmeden kapandığında diğer servisleri etkilemez. Kritik servisler birden fazla kopya çalıştırılarak genişleyebilen yapı sağlanır.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/mimari-tasar%C4%B1m-kal%C4%B1plar%C4%B1-94a4f47d32a8;; 25 | Mimari Erozyon;Architectural Erosion;projenin ileri ki aşamalarında takvim sıkışıklığı, yazılımcı değişikliği gibi faktörler ile mimari kararlar doğru şekilde yazılıma aktarılmaz yada mevcut bir özellik istenmeden bozulur.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/mimarinin-evrimi-3-yeniden-d%C3%BCzenleme-yada-yeniden-yazma-a54205e0ac19;; 26 | Mimari Kaygılar;Architectural Concerns;" 27 | Mimari kaygılar ise alınması gereken tasarım kararlarını ifade eder. Örnek olarak alınan verinin doğrulaması, iletişim mekanizmaları, verinin yedeğinin alınması ve hata yönetimi sayılabilir.";https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarisi-2-mimari-gereksinimler-bf010e41f99c;; 28 | Mimari Ödün Analizi Metodu;(Architectural Tradeoff Analysis Method-ATAM;ATAM incelenen mimarinin potansiyel risklerini, ödünleşim ve duyarlılık noktalarını tespit eden bir yazılım mimarisi değerlendirme ve analiz etme yöntemidir. ATAM, alınan tasarım kararlarının sonuçlarını sistemden beklenen kalite öznitelikleri doğrultusunda değerlendirmeyi amaçlar.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarisi-9-mimarinin-de%C4%9Ferlendirilmesi-8c0657c514b7;; 29 | Olay Fırtınası; Event Stroming;İş alanını daha iyi analiz edilerek fonksiyonel gereksinimlerin oluşturulması hedefleyen bir yöntemdir. Bu yaklaşım son zamanlarda (İş alanı Tabanlı Tasarım (Domain Driven Design) için etkin olarak kullanılmaktadır.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/kalite-%C3%B6znitelikleri-%C3%A7al%C4%B1%C5%9Ftay%C4%B1-ya-da-kalite-fikir-f%C4%B1rt%C4%B1nas%C4%B1-a521409c7a23;; 30 | Oyun fırtınası;Game-Storming;Bir konuda ilgili bütün paydaşların bir araya gelerek problemi yaratıcı bir şekilde oyun yöntemi ile analiz edip çözüm üretmeyi hedefler. Yaratıcılığı ve paydaşlar arası sahiplenmeyi arttırdığı için son yıllarda aktif olarak tercih edilmektedir.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/kalite-%C3%B6znitelikleri-%C3%A7al%C4%B1%C5%9Ftay%C4%B1-ya-da-kalite-fikir-f%C4%B1rt%C4%B1nas%C4%B1-a521409c7a23;; 31 | Paydaş;Stakeholder;Yazılım mimarisinin paydaşları mimari ile ilgisi olan geliştirici, test mühendisi, kullanıcı, üst yönetim gibi kişilerden oluşur. Bir yazılım için paydaşları belirler iken, “yazılımdan kimler etkilenecek” ve “kimler yazılımı etkileyecek” soruları sorulur. ;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarisi-temel-kavramlar-4de64353b4ac;; 32 | Performans;Performance;Yazılımın zaman ile ilgili ilgili gereksinimleri sağlama özelliğidir. Bir olay olduğunda sistemin tamamı yada bir bölümü bu olaya belirlenen zamanda cevap vermesi beklenir.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarisi-notlar%C4%B1-4-performans-kalite-%C3%B6zniteli%C4%9Fi-2c7345d924e3;; 33 | Referans mimariler;Reference Architectures;"Referans mimariler ise belirli bir alandaki yazılım mimarisinin ihtiyaçlarına karşılık veren ve genelde birden fazla tasarım kalıbını içeren bütünsel bir mimaridir. Belirli bir referans mimariyi temel alan yazılımcı referans mimaride tanımlı katmanlar içerisinde referans mimaride tanımlı bileşenleri ve bu bileşenler arasında ise yine tanımlı ilişkileri kurar. 34 | ";https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarisi-temel-kavramlar-4de64353b4ac;; 35 | Servis Tabanlı Mimari;Service Oriented Architecture; farklı kabiliyetler servis olarak geliştirilmekte ve istemcilerin istekleri bu servislere iletildiğinde ilgili servis diğer servislerden tanımlı ara yüzler üzerinden hizmet alarak istemcinin ihtiyacını karşılamaktadır.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/mimari-tasar%C4%B1m-kal%C4%B1plar%C4%B1-94a4f47d32a8;; 36 | Sıfırdan Tasarım;Greenfield System;Yazılım tasarımı tamamen yeni bir alanda yapılıyor ise mimari tasarım çok daha yaratıcı ve zorlayıcı olabilmektedir. Bu tür sistemlerin tasarımına sıfırdan tasarım denmektedir.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarileri-5-kalite-%C3%B6znitelikleri-tabanl%C4%B1-tasar%C4%B1m-fb38d79376f3;; 37 | Süreklilik;Availability;Süreklilik kalite özniteliği bir sistemin ihtiyaç duyulduğunda kullanılabilir ve faydalanılabilir olma derecesidir. ;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarisi-notlar%C4%B1-3-s%C3%BCreklilik-kalite-%C3%B6zniteli%C4%9Fi-c3566777e66c;; 38 | Taktikler;Tactics;Mimari taktikler temel seviyedeki çözüm teknikleridir. Yazılım geliştiriciler bu temel seviyedeki taktikleri yıllardır kullanmaktadır. Örneğin yazılımın performansını arttırmak için verinin birden fazla kopyasını tutma, kaynakları arttırma, koşut çalışmayı sağlama kullanılabilecek taktikler arasındadır.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarisi-temel-kavramlar-4de64353b4ac;; 39 | Teknik Borç;Technical Debt;İdeal olmayan kod, tasarım yada mimari, bir problemi çözmek için kullandığınız kestirme yol veya dikkate almadığımız hata veya operasyonel durumların sonradan tespit edilip kodda düzeltilmesi ekstra maliyet getirecektir. Bu durum finansal sistemden esinlenerek teknik borç olarak nitelendirilir. ;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/mimarinin-evrimi-1-teknik-bor%C3%A7-nedir-e87d89fe12de;; 40 | Teslim Zamanı  ;Deadline;Bir işin bitmesi gereken en son zamanı belirtir.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarisi-notlar%C4%B1-4-performans-kalite-%C3%B6zniteli%C4%9Fi-2c7345d924e3;; 41 | Test Edilebilir Tasarım ;Design for Testability;Tasarımın içine test ile ilgili özelliklerin eklenmesidir.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarileri-8-test-edilebilir-tasar%C4%B1m-ff558effa027;; 42 | Test edilebilirlik;Testability;Test edilebilirlik kalite özniteliği bir yazılımın hatalarının test ile ne kadar kolay yakalanabileceği ölçüsüdür. Test Edilebilirlik kalite özniteliğinin öncelikle gözlenebilirlik, kontrol edilebilirlik ve boyutsal küçüklük kalite özniteliklerinin ile alakalıdır.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarileri-8-test-edilebilir-tasar%C4%B1m-ff558effa027;; 43 | Uyumluluk;Cohession;"Bileşen içi uyumluluk ile ilgili sınıflandırma aşağıdaki gibidir: 44 | Tesadüfi Uyumluluk alakasız elementlerin aynı bileşen içinde yer almasıdır. 45 | Mantıksal uyumluluk mantıksal olarak benzer fakat yöntemsel olarak farklı işlemlerin bir arada bulunmasıdır. 46 | Zamansal uyumlulukta aynı zaman içinde/ sırasında yapılacak işler aynı bileşen içinde yer alır. 47 | Yordam Uyumluluğu işleme sırası peş peşe olan işlemler aynı bileşen içinde yer alır. 48 | Haberleşme uyumluluğunda aynı girdi üzerine işlem yapan elemanlar aynı bileşende yer alır. 49 | Fonksiyonel uyumlulukta tek bir fonksiyonu yerine getiren işlemler aynı bileşen içinde yer almaktadır. Bu ideal durumdur.";https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/tasar%C4%B1m%C4%B1n-temelleri-2-ba%C4%9F%C4%B1ml%C4%B1l%C4%B1k-ve-uyumluluk-tasar%C4%B1m-prensipleri-20e28490e985;; 50 | Yazılım Mimarileri;Software Architecture;"""";https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/yaz%C4%B1l%C4%B1m-mimarisi-temel-kavramlar-4de64353b4ac;; 51 | Yeniden düzenleme;Refactor;Yeniden düzenleme yazılımın iç yapısının düzeltilirken dış davranışının aynı kalması olarak tanımlanmaktadır. Mimari yeniden düzenlemede ise amaç sistemin değiştirilebilirlik, performans, test edilebilirlik, değiştire bilirlik,bakım yapılabilirlik ve süreklilik gibi kalite öz niteliklerini iyileştirmek olacaktır.;https://medium.com/yaz%C4%B1l%C4%B1m-mimarileri/mimarinin-evrimi-2-teknik-bor%C3%A7-nas%C4%B1l-%C3%B6denir-35f993a7e95c;; 52 | ;;;;; 53 | ;;;;; 54 | -------------------------------------------------------------------------------- /Arc42 Template in Markdown.md: -------------------------------------------------------------------------------- 1 | **About arc42** 2 | 3 | arc42, the Template for documentation of software and system 4 | architecture. 5 | 6 | By Dr. Gernot Starke, Dr. Peter Hruschka and contributors. 7 | 8 | Template Revision: 7.0 EN (based on asciidoc), January 2017 9 | 10 | © We acknowledge that this document uses material from the arc 42 11 | architecture template, . Created by Dr. Peter 12 | Hruschka & Dr. Gernot Starke. 13 | 14 | > **Note** 15 | > 16 | > This version of the template contains some help and explanations. It 17 | > is used for familiarization with arc42 and the understanding of the 18 | > concepts. For documentation of your own system you use better the 19 | > *plain* version. 20 | 21 | Introduction and Goals 22 | ====================== 23 | 24 | Describes the relevant requirements and the driving forces that software 25 | architects and development team must consider. These include 26 | 27 | - underlying business goals, essential features and functional 28 | requirements for the system 29 | 30 | - quality goals for the architecture 31 | 32 | - relevant stakeholders and their expectations 33 | 34 | Requirements Overview 35 | --------------------- 36 | 37 | **Contents.** 38 | 39 | Short description of the functional requirements, driving forces, 40 | extract (or abstract) of requirements. Link to (hopefully existing) 41 | requirements documents (with version number and information where to 42 | find it). 43 | 44 | **Motivation.** 45 | 46 | From the point of view of the end users a system is created or modified 47 | to improve support of a business activity and/or improve the quality. 48 | 49 | **Form.** 50 | 51 | Short textual description, probably in tabular use-case format. If 52 | requirements documents exist this overview should refer to these 53 | documents. 54 | 55 | Keep these excerpts as short as possible. Balance readability of this 56 | document with potential redundancy w.r.t to requirements documents. 57 | 58 | Quality Goals 59 | ------------- 60 | 61 | **Contents.** 62 | 63 | The top three (max five) quality goals for the architecture whose 64 | fulfillment is of highest importance to the major stakeholders. We 65 | really mean quality goals for the architecture. Don’t confuse them with 66 | project goals. They are not necessarily identical. 67 | 68 | **Motivation.** 69 | 70 | You should know the quality goals of your most important stakeholders, 71 | since they will influence fundamental architectural decisions. Make sure 72 | to be very concrete about these qualities, avoid buzzwords. If you as an 73 | architect do not know how the quality of your work will be judged … 74 | 75 | **Form.** 76 | 77 | A table with quality goals and concrete scenarios, ordered by priorities 78 | 79 | Stakeholders 80 | ------------ 81 | 82 | **Contents.** 83 | 84 | Explicit overview of stakeholders of the system, i.e. all person, roles 85 | or organizations that 86 | 87 | - should know the architecture 88 | 89 | - have to be convinced of the architecture 90 | 91 | - have to work with the architecture or with code 92 | 93 | - need the documentation of the architecture for their work 94 | 95 | - have to come up with decisions about the system or its development 96 | 97 | **Motivation.** 98 | 99 | You should know all parties involved in development of the system or 100 | affected by the system. Otherwise, you may get nasty surprises later in 101 | the development process. These stakeholders determine the extent and the 102 | level of detail of your work and its results. 103 | 104 | **Form.** 105 | 106 | Table with role names, person names, and their expectations with respect 107 | to the architecture and its documentation. 108 | 109 | | Role/Name | Contact | Expectations | 110 | | ----------- | ------------------------- | ------------------------- | 111 | | Role-1 | Contact-1 | *<Expectation-1*> | 112 | | Role-2 | Contact-2 | *<Expectation-2*> | 113 | 114 | Architecture Constraints 115 | ======================== 116 | 117 | **Contents.** 118 | 119 | Any requirement that constrains software architects in their freedom of 120 | design and implementation decisions or decision about the development 121 | process. These constraints sometimes go beyond individual systems and 122 | are valid for whole organizations and companies. 123 | 124 | **Motivation.** 125 | 126 | Architects should know exactly where they are free in their design 127 | decisions and where they must adhere to constraints. Constraints must 128 | always be dealt with; they may be negotiable, though. 129 | 130 | **Form.** 131 | 132 | Simple tables of constraints with explanations. If needed you can 133 | subdivide them into technical constraints, organizational and political 134 | constraints and conventions (e.g. programming or versioning guidelines, 135 | documentation or naming conventions) 136 | 137 | System Scope and Context 138 | ======================== 139 | 140 | **Contents.** 141 | 142 | System scope and context - as the name suggests - delimits your system 143 | (i.e. your scope) from all its communication partners (neighboring 144 | systems and users, i.e. the context of your system). It thereby 145 | specifies the external interfaces. 146 | 147 | If necessary, differentiate the business context (domain specific inputs 148 | and outputs) from the technical context (channels, protocols, hardware). 149 | 150 | **Motivation.** 151 | 152 | The domain interfaces and technical interfaces to communication partners 153 | are among your system’s most critical aspects. Make sure that you 154 | completely understand them. 155 | 156 | **Form.** 157 | 158 | Various options: 159 | 160 | - Context diagrams 161 | 162 | - Lists of communication partners and their interfaces. 163 | 164 | Business Context 165 | ---------------- 166 | 167 | **Contents.** 168 | 169 | Specification of **all** communication partners (users, IT-systems, …) 170 | with explanations of domain specific inputs and outputs or interfaces. 171 | Optionally you can add domain specific formats or communication 172 | protocols. 173 | 174 | **Motivation.** 175 | 176 | All stakeholders should understand which data are exchanged with the 177 | environment of the system. 178 | 179 | **Form.** 180 | 181 | All kinds of diagrams that show the system as a black box and specify 182 | the domain interfaces to communication partners. 183 | 184 | Alternatively (or additionally) you can use a table. The title of the 185 | table is the name of your system, the three columns contain the name of 186 | the communication partner, the inputs, and the outputs. 187 | 188 | **<Diagram or Table>** 189 | 190 | **<optionally: Explanation of external domain interfaces>** 191 | 192 | Technical Context 193 | ----------------- 194 | 195 | **Contents.** 196 | 197 | Technical interfaces (channels and transmission media) linking your 198 | system to its environment. In addition a mapping of domain specific 199 | input/output to the channels, i.e. an explanation with I/O uses which 200 | channel. 201 | 202 | **Motivation.** 203 | 204 | Many stakeholders make architectural decision based on the technical 205 | interfaces between the system and its context. Especially infrastructure 206 | or hardware designers decide these technical interfaces. 207 | 208 | **Form.** 209 | 210 | E.g. UML deployment diagram describing channels to neighboring systems, 211 | together with a mapping table showing the relationships between channels 212 | and input/output. 213 | 214 | **<Diagram or Table>** 215 | 216 | **<optionally: Explanation of technical interfaces>** 217 | 218 | **<Mapping Input/Output to Channels>** 219 | 220 | Solution Strategy 221 | ================= 222 | 223 | **Contents.** 224 | 225 | A short summary and explanation of the fundamental decisions and 226 | solution strategies, that shape the system’s architecture. These include 227 | 228 | - technology decisions 229 | 230 | - decisions about the top-level decomposition of the system, e.g. 231 | usage of an architectural pattern or design pattern 232 | 233 | - decisions on how to achieve key quality goals 234 | 235 | - relevant organizational decisions, e.g. selecting a development 236 | process or delegating certain tasks to third parties. 237 | 238 | **Motivation.** 239 | 240 | These decisions form the cornerstones for your architecture. They are 241 | the basis for many other detailed decisions or implementation rules. 242 | 243 | **Form.** 244 | 245 | Keep the explanation of these key decisions short. 246 | 247 | Motivate what you have decided and why you decided that way, based upon 248 | your problem statement, the quality goals and key constraints. Refer to 249 | details in the following sections. 250 | 251 | Building Block View 252 | =================== 253 | 254 | **Content.** 255 | 256 | The building block view shows the static decomposition of the system 257 | into building blocks (modules, components, subsystems, classes, 258 | interfaces, packages, libraries, frameworks, layers, partitions, tiers, 259 | functions, macros, operations, datas structures, …) as well as their 260 | dependencies (relationships, associations, …) 261 | 262 | This view is mandatory for every architecture documentation. In analogy 263 | to a house this is the *floor plan*. 264 | 265 | **Motivation.** 266 | 267 | Maintain an overview of your source code by making its structure 268 | understandable through abstraction. 269 | 270 | This allows you to communicate with your stakeholder on an abstract 271 | level without disclosing implementation details. 272 | 273 | **Form.** 274 | 275 | The building block view is a hierarchical collection of black boxes and 276 | white boxes (see figure below) and their descriptions. 277 | 278 | ![Hierarchy of building blocks](images/05_building_blocks-EN.png) 279 | 280 | **Level 1** is the white box description of the overall system together 281 | with black box descriptions of all contained building blocks. 282 | 283 | **Level 2** zooms into some building blocks of level 1. Thus it contains 284 | the white box description of selected building blocks of level 1, 285 | together with black box descriptions of their internal building blocks. 286 | 287 | **Level 3** zooms into selected building blocks of level 2, and so on. 288 | 289 | Whitebox Overall System 290 | ----------------------- 291 | 292 | Here you describe the decomposition of the overall system using the 293 | following white box template. It contains 294 | 295 | - an overview diagram 296 | 297 | - a motivation for the decomposition 298 | 299 | - black box descriptions of the contained building blocks. For these 300 | we offer you alternatives: 301 | 302 | - use *one* table for a short and pragmatic overview of all 303 | contained building blocks and their interfaces 304 | 305 | - use a list of black box descriptions of the building blocks 306 | according to the black box template (see below). Depending on 307 | your choice of tool this list could be sub-chapters (in text 308 | files), sub-pages (in a Wiki) or nested elements (in a modeling 309 | tool). 310 | 311 | - (optional:) important interfaces, that are not explained in the 312 | black box templates of a building block, but are very important for 313 | understanding the white box. Since there are so many ways to specify 314 | interfaces why do not provide a specific template for them. In the 315 | worst case you have to specify and describe syntax, semantics, 316 | protocols, error handling, restrictions, versions, qualities, 317 | necessary compatibilities and many things more. In the best case you 318 | will get away with examples or simple signatures. 319 | 320 | ***<Overview Diagram>*** 321 | 322 | Motivation 323 | 324 | : *<text explanation>* 325 | 326 | Contained Building Blocks 327 | 328 | : *<Description of contained building block (black boxes)>* 329 | 330 | Important Interfaces 331 | 332 | : *<Description of important interfaces>* 333 | 334 | Insert your explanations of black boxes from level 1: 335 | 336 | If you use tabular form you will only describe your black boxes with 337 | name and responsibility according to the following schema: 338 | 339 | | **Name** | **Responsibility** | 340 | | -------------------- | -------------------------------------------- | 341 | | Black Box 1 |  *<Text>* | 342 | | Black Box 2 |  *<Text>* | 343 | 344 | If you use a list of black box descriptions then you fill in a separate 345 | black box template for every important building block . Its headline is 346 | the name of the black box. 347 | 348 | ### <Name black box 1> 349 | 350 | Here you describe <black box 1> according the the following black 351 | box template: 352 | 353 | - Purpose/Responsibility 354 | 355 | - Interface(s), when they are not extracted as separate paragraphs. 356 | This interfaces may include qualities and performance 357 | characteristics. 358 | 359 | - (Optional) Quality-/Performance characteristics of the black box, 360 | e.g.availability, run time behavior, …. 361 | 362 | - (Optional) directory/file location 363 | 364 | - (Optional) Fulfilled requirements (if you need traceability to 365 | requirements). 366 | 367 | - (Optional) Open issues/problems/risks 368 | 369 | *<Purpose/Responsibility>* 370 | 371 | *<Interface(s)>* 372 | 373 | *<(Optional) Quality/Performance Characteristics>* 374 | 375 | *<(Optional) Directory/File Location>* 376 | 377 | *<(Optional) Fulfilled Requirements>* 378 | 379 | *<(optional) Open Issues/Problems/Risks>* 380 | 381 | ### <Name black box 2> 382 | 383 | *<black box template>* 384 | 385 | ### <Name black box n> 386 | 387 | *<black box template>* 388 | 389 | ### <Name interface 1> 390 | 391 | … 392 | 393 | ### <Name interface m> 394 | 395 | Level 2 396 | ------- 397 | 398 | Here you can specify the inner structure of (some) building blocks from 399 | level 1 as white boxes. 400 | 401 | You have to decide which building blocks of your system are important 402 | enough to justify such a detailed description. Please prefer relevance 403 | over completeness. Specify important, surprising, risky, complex or 404 | volatile building blocks. Leave out normal, simple, boring or 405 | standardized parts of your system 406 | 407 | ### White Box *<building block 1>* 408 | 409 | …describes the internal structure of *building block 1*. 410 | 411 | *<white box template>* 412 | 413 | ### White Box *<building block 2>* 414 | 415 | *<white box template>* 416 | 417 | … 418 | 419 | ### White Box *<building block m>* 420 | 421 | *<white box template>* 422 | 423 | Level 3 424 | ------- 425 | 426 | Here you can specify the inner structure of (some) building blocks from 427 | level 2 as white boxes. 428 | 429 | When you need more detailed levels of your architecture please copy this 430 | part of arc42 for additional levels. 431 | 432 | ### White Box <\_building block x.1\_> 433 | 434 | Specifies the internal structure of *building block x.1*. 435 | 436 | *<white box template>* 437 | 438 | ### White Box <\_building block x.2\_> 439 | 440 | *<white box template>* 441 | 442 | ### White Box <\_building block y.1\_> 443 | 444 | *<white box template>* 445 | 446 | Runtime View 447 | ============ 448 | 449 | **Contents.** 450 | 451 | The runtime view describes concrete behavior and interactions of the 452 | system’s building blocks in form of scenarios from the following areas: 453 | 454 | - important use cases or features: how do building blocks execute 455 | them? 456 | 457 | - interactions at critical external interfaces: how do building blocks 458 | cooperate with users and neighboring systems? 459 | 460 | - operation and administration: launch, start-up, stop 461 | 462 | - error and exception scenarios 463 | 464 | Remark: The main criterion for the choice of possible scenarios 465 | (sequences, workflows) is their **architectural relevance**. It is 466 | **not** important to describe a large number of scenarios. You should 467 | rather document a representative selection. 468 | 469 | **Motivation.** 470 | 471 | You should understand how (instances of) building blocks of your system 472 | perform their job and communicate at runtime. You will mainly capture 473 | scenarios in your documentation to communicate your architecture to 474 | stakeholders that are less willing or able to read and understand the 475 | static models (building block view, deployment view). 476 | 477 | **Form.** 478 | 479 | There are many notations for describing scenarios, e.g. 480 | 481 | - numbered list of steps (in natural language) 482 | 483 | - activity diagrams or flow charts 484 | 485 | - sequence diagrams 486 | 487 | - BPMN or EPCs (event process chains) 488 | 489 | - state machines 490 | 491 | - … 492 | 493 | <Runtime Scenario 1> 494 | -------------------------- 495 | 496 | - *<insert runtime diagram or textual description of the 497 | scenario>* 498 | 499 | - *<insert description of the notable aspects of the interactions 500 | between the building block instances depicted in this diagram.>* 501 | 502 | <Runtime Scenario 2> 503 | -------------------------- 504 | 505 | … {#_} 506 | - 507 | 508 | <Runtime Scenario n> 509 | -------------------------- 510 | 511 | Deployment View 512 | =============== 513 | 514 | **Content.** 515 | 516 | The deployment view describes: 517 | 518 | 1. the technical infrastructure used to execute your system, with 519 | infrastructure elements like geographical locations, environments, 520 | computers, processors, channels and net topologies as well as other 521 | infrastructure elements and 522 | 523 | 2. the mapping of (software) building blocks to that infrastructure 524 | elements. 525 | 526 | Often systems are executed in different environments, e.g. development 527 | environment, test environment, production environment. In such cases you 528 | should document all relevant environments. 529 | 530 | Especially document the deployment view when your software is executed 531 | as distributed system with more then one computer, processor, server or 532 | container or when you design and construct your own hardware processors 533 | and chips. 534 | 535 | From a software perspective it is sufficient to capture those elements 536 | of the infrastructure that are needed to show the deployment of your 537 | building blocks. Hardware architects can go beyond that and describe the 538 | infrastructure to any level of detail they need to capture. 539 | 540 | **Motivation.** 541 | 542 | Software does not run without hardware. This underlying infrastructure 543 | can and will influence your system and/or some cross-cutting concepts. 544 | Therefore, you need to know the infrastructure. 545 | 546 | Maybe the highest level deployment diagram is already contained in 547 | section 3.2. as technical context with your own infrastructure as ONE 548 | black box. In this section you will zoom into this black box using 549 | additional deployment diagrams: 550 | 551 | - UML offers deployment diagrams to express that view. Use it, 552 | probably with nested diagrams, when your infrastructure is more 553 | complex. 554 | 555 | - When your (hardware) stakeholders prefer other kinds of diagrams 556 | rather than the deployment diagram, let them use any kind that is 557 | able to show nodes and channels of the infrastructure. 558 | 559 | Infrastructure Level 1 560 | ---------------------- 561 | 562 | Describe (usually in a combination of diagrams, tables, and text): 563 | 564 | - the distribution of your system to multiple locations, environments, 565 | computers, processors, .. as well as the physical connections 566 | between them 567 | 568 | - important justification or motivation for this deployment structure 569 | 570 | - Quality and/or performance features of the infrastructure 571 | 572 | - the mapping of software artifacts to elements of the infrastructure 573 | 574 | For multiple environments or alternative deployments please copy that 575 | section of arc42 for all relevant environments. 576 | 577 | ***<Overview Diagram>*** 578 | 579 | Motivation 580 | 581 | : *<explanation in text form>* 582 | 583 | Quality and/or Performance Features 584 | 585 | : *<explanation in text form>* 586 | 587 | Mapping of Building Blocks to Infrastructure 588 | 589 | : *<description of the mapping>* 590 | 591 | Infrastructure Level 2 592 | ---------------------- 593 | 594 | Here you can include the internal structure of (some) infrastructure 595 | elements from level 1. 596 | 597 | Please copy the structure from level 1 for each selected element. 598 | 599 | ### *<Infrastructure Element 1>* 600 | 601 | *<diagram + explanation>* 602 | 603 | ### *<Infrastructure Element 2>* 604 | 605 | *<diagram + explanation>* 606 | 607 | … 608 | 609 | ### *<Infrastructure Element n>* 610 | 611 | *<diagram + explanation>* 612 | 613 | Cross-cutting Concepts 614 | ====================== 615 | 616 | **Content.** 617 | 618 | This section describes overall, principal regulations and solution ideas 619 | that are relevant in multiple parts (= cross-cutting) of your system. 620 | Such concepts are often related to multiple building blocks. They can 621 | include many different topics, such as 622 | 623 | - domain models 624 | 625 | - architecture patterns or design patterns 626 | 627 | - rules for using specific technology 628 | 629 | - principal, often technical decisions of overall decisions 630 | 631 | - implementation rules 632 | 633 | **Motivation.** 634 | 635 | Concepts form the basis for *conceptual integrity* (consistency, 636 | homogeneity) of the architecture. Thus, they are an important 637 | contribution to achieve inner qualities of your system. 638 | 639 | Some of these concepts cannot be assigned to individual building blocks 640 | (e.g. security or safety). This is the place in the template that we 641 | provided for a cohesive specification of such concepts. 642 | 643 | **Form.** 644 | 645 | The form can be varied: 646 | 647 | - concept papers with any kind of structure 648 | 649 | - cross-cutting model excerpts or scenarios using notations of the 650 | architecture views 651 | 652 | - sample implementations, especially for technical concepts 653 | 654 | - reference to typical usage of standard frameworks (e.g. using 655 | Hibernate for object/relational mapping) 656 | 657 | **Structure.** 658 | 659 | A potential (but not mandatory) structure for this section could be: 660 | 661 | - Domain concepts 662 | 663 | - User Experience concepts (UX) 664 | 665 | - Safety and security concepts 666 | 667 | - Architecture and design patterns 668 | 669 | - "Under-the-hood" 670 | 671 | - development concepts 672 | 673 | - operational concepts 674 | 675 | Note: it might be difficult to assign individual concepts to one 676 | specific topic on this list. 677 | 678 | ![Possible topics for crosscutting concepts](images/08-Crosscutting-Concepts-Structure-EN.png) 679 | 680 | *<Concept 1>* 681 | ------------------- 682 | 683 | *<explanation>* 684 | 685 | *<Concept 2>* 686 | ------------------- 687 | 688 | *<explanation>* 689 | 690 | … 691 | 692 | *<Concept n>* 693 | ------------------- 694 | 695 | *<explanation>* 696 | 697 | Design Decisions 698 | ================ 699 | 700 | **Contents.** 701 | 702 | Important, expensive, large scale or risky architecture decisions 703 | including rationals. With "decisions" we mean selecting one alternative 704 | based on given criteria. 705 | 706 | Please use your judgement to decide whether an architectural decision 707 | should be documented here in this central section or whether you better 708 | document it locally (e.g. within the white box template of one building 709 | block). 710 | 711 | Avoid redundancy. Refer to section 4, where you already captured the 712 | most important decisions of your architecture. 713 | 714 | **Motivation.** 715 | 716 | Stakeholders of your system should be able to comprehend and retrace 717 | your decisions. 718 | 719 | **Form.** 720 | 721 | Various options: 722 | 723 | - List or table, ordered by importance and consequences or: 724 | 725 | - more detailed in form of separate sections per decision 726 | 727 | - ADR (architecture decision record) for every important decision 728 | 729 | Quality Requirements 730 | ==================== 731 | 732 | **Content.** 733 | 734 | This section contains all quality requirements as quality tree with 735 | scenarios. The most important ones have already been described in 736 | section 1.2. (quality goals) 737 | 738 | Here you can also capture quality requirements with lesser priority, 739 | which will not create high risks when they are not fully achieved. 740 | 741 | **Motivation.** 742 | 743 | Since quality requirements will have a lot of influence on architectural 744 | decisions you should know for every stakeholder what is really important 745 | to them, concrete and measurable. 746 | 747 | Quality Tree 748 | ------------ 749 | 750 | **Content.** 751 | 752 | The quality tree (as defined in ATAM – Architecture Tradeoff Analysis 753 | Method) with quality/evaluation scenarios as leafs. 754 | 755 | **Motivation.** 756 | 757 | The tree structure with priorities provides an overview for a sometimes 758 | large number of quality requirements. 759 | 760 | **Form.** 761 | 762 | The quality tree is a high-level overview of the quality goals and 763 | requirements: 764 | 765 | - tree-like refinement of the term "quality". Use "quality" or 766 | "usefulness" as a root 767 | 768 | - a mind map with quality categories as main branches 769 | 770 | In any case the tree should include links to the scenarios of the 771 | following section. 772 | 773 | Quality Scenarios 774 | ----------------- 775 | 776 | **Contents.** 777 | 778 | Concretization of (sometimes vague or implicit) quality requirements 779 | using (quality) scenarios. 780 | 781 | These scenarios describe what should happen when a stimulus arrives at 782 | the system. 783 | 784 | For architects, two kinds of scenarios are important: 785 | 786 | - Usage scenarios (also called application scenarios or use case 787 | scenarios) describe the system’s runtime reaction to a certain 788 | stimulus. This also includes scenarios that describe the system’s 789 | efficiency or performance. Example: The system reacts to a user’s 790 | request within one second. 791 | 792 | - Change scenarios describe a modification of the system or of its 793 | immediate environment. Example: Additional functionality is 794 | implemented or requirements for a quality attribute change. 795 | 796 | **Motivation.** 797 | 798 | Scenarios make quality requirements concrete and allow to more easily 799 | measure or decide whether they are fulfilled. 800 | 801 | Especially when you want to assess your architecture using methods like 802 | ATAM you need to describe your quality goals (from section 1.2) more 803 | precisely down to a level of scenarios that can be discussed and 804 | evaluated. 805 | 806 | **Form.** 807 | 808 | Tabular or free form text. 809 | 810 | Risks and Technical Debts 811 | ========================= 812 | 813 | **Contents.** 814 | 815 | A list of identified technical risks or technical debts, ordered by 816 | priority 817 | 818 | **Motivation.** 819 | 820 | “Risk management is project management for grown-ups” (Tim Lister, 821 | Atlantic Systems Guild.) 822 | 823 | This should be your motto for systematic detection and evaluation of 824 | risks and technical debts in the architecture, which will be needed by 825 | management stakeholders (e.g. project managers, product owners) as part 826 | of the overall risk analysis and measurement planning. 827 | 828 | **Form.** 829 | 830 | List of risks and/or technical debts, probably including suggested 831 | measures to minimize, mitigate or avoid risks or reduce technical debts. 832 | 833 | Glossary 834 | ======== 835 | 836 | **Contents.** 837 | 838 | The most important domain and technical terms that your stakeholders use 839 | when discussing the system. 840 | 841 | You can also see the glossary as source for translations if you work in 842 | multi-language teams. 843 | 844 | **Motivation.** 845 | 846 | You should clearly define your terms, so that all stakeholders 847 | 848 | - have an identical understanding of these terms 849 | 850 | - do not use synonyms and homonyms 851 | 852 | **Form.** 853 | 854 | A table with columns <Term> and <Definition>. 855 | 856 | Potentially more columns in case you need translations. 857 | 858 | | Term | Definition | 859 | | --------------------------------- | --------------------------------- | 860 | | Term 1 | <definition-1> | 861 | | Term 2 | <definition-2> | 862 | 863 | 864 | 865 | -------------------------------------------------------------------------------- /ROS2/Ros2Component.svg: -------------------------------------------------------------------------------- 1 | Component Diagram for ROS2 componentsROS2 Components[Container]ROS middlewareinterface(RMW)[C++]The ROS middlewareinterface (rmw API) is theminimal set of primitivemiddleware capabilitiesneeded to build ROS on top.Providers of differentmiddleware implementationsmust implement thisinterface in order to supportthe entire ROS stack on top.pub/sub with QOS, Serviceswith QOS, Discovery, GrapheventsROS Client Library(rcl)[C api and optional C++Implementation]Nodes, Publisher,Subscription, Service Client,Service Server, Timer,Console logging, ParameterrclCPP[C++]ROS Client Library C++Wrapper.rclPy[Python]ROS Client Library PythonWrapper.DDS Middlewarelibrary[DDS Library from DDSvendor(Fast RTPS, Cyclone DDS,RTI Connext)]User Code[C++]User code, no direct accessto DDS MWUser Code[Py]User code, no direct accessto DDS MWUses[Api]Uses[Api]Uses[Api]Uses[Api]Uses[Api]Uses[Api]Legendpersonsystemcontainercomponentexternal personexternal systemexternal containerexternal component --------------------------------------------------------------------------------