This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
Simplifying Distributed Transactions with Sagas in Kafka (Stephen Zoio, Simpl...confluent
Microservices are seen as the way to simplify complex systems, until you need to coordinate a transaction across services, and in that instant, the dream ends. Transactions involving multiple services can lead to a spaghetti web of interactions. Protocols such as two-phase commit come with complexity and performance bottlenecks. The Saga pattern involves a simplified transactional model. In sagas, a sequence of actions are executed, and if any action fails, a compensating action is executed for each of the actions that have already succeeded. This is particularly well suited to long-running and cross-microservice transactions. In this talk we introduce the new Simple Sagas library (https://github.com/simplesourcing/simplesagas). Built using Kafka streams, it provides a scalable fault tolerance event-based transaction processing engine. We walk through a use case of coordinating a sequence of complex financial transactions. We demonstrate the easy to use DSL, show how the system copes with failure, and discuss this overall approach to building scalable transactional systems in an event-driven streaming context.
Kappa vs Lambda Architectures and Technology ComparisonKai Wähner
Real-time data beats slow data. That’s true for almost every use case. Nevertheless, enterprise architects build new infrastructures with the Lambda architecture that includes separate batch and real-time layers.
This video explores why a single real-time pipeline, called Kappa architecture, is the better fit for many enterprise architectures. Real-world examples from companies such as Disney, Shopify, Uber, and Twitter explore the benefits of Kappa but also show how batch processing fits into this discussion positively without the need for a Lambda architecture.
The main focus of the discussion is on Apache Kafka (and its ecosystem) as the de facto standard for event streaming to process data in motion (the key concept of Kappa), but the video also compares various technologies and vendors such as Confluent, Cloudera, IBM Red Hat, Apache Flink, Apache Pulsar, AWS Kinesis, Amazon MSK, Azure Event Hubs, Google Pub Sub, and more.
Video recording of this presentation:
https://youtu.be/j7D29eyysDw
Further reading:
https://www.kai-waehner.de/blog/2021/09/23/real-time-kappa-architecture-mainstream-replacing-batch-lambda/
https://www.kai-waehner.de/blog/2021/04/20/comparison-open-source-apache-kafka-vs-confluent-cloudera-red-hat-amazon-msk-cloud/
https://www.kai-waehner.de/blog/2021/05/09/kafka-api-de-facto-standard-event-streaming-like-amazon-s3-object-storage/
Simplifying Distributed Transactions with Sagas in Kafka (Stephen Zoio, Simpl...confluent
Microservices are seen as the way to simplify complex systems, until you need to coordinate a transaction across services, and in that instant, the dream ends. Transactions involving multiple services can lead to a spaghetti web of interactions. Protocols such as two-phase commit come with complexity and performance bottlenecks. The Saga pattern involves a simplified transactional model. In sagas, a sequence of actions are executed, and if any action fails, a compensating action is executed for each of the actions that have already succeeded. This is particularly well suited to long-running and cross-microservice transactions. In this talk we introduce the new Simple Sagas library (https://github.com/simplesourcing/simplesagas). Built using Kafka streams, it provides a scalable fault tolerance event-based transaction processing engine. We walk through a use case of coordinating a sequence of complex financial transactions. We demonstrate the easy to use DSL, show how the system copes with failure, and discuss this overall approach to building scalable transactional systems in an event-driven streaming context.
Kappa vs Lambda Architectures and Technology ComparisonKai Wähner
Real-time data beats slow data. That’s true for almost every use case. Nevertheless, enterprise architects build new infrastructures with the Lambda architecture that includes separate batch and real-time layers.
This video explores why a single real-time pipeline, called Kappa architecture, is the better fit for many enterprise architectures. Real-world examples from companies such as Disney, Shopify, Uber, and Twitter explore the benefits of Kappa but also show how batch processing fits into this discussion positively without the need for a Lambda architecture.
The main focus of the discussion is on Apache Kafka (and its ecosystem) as the de facto standard for event streaming to process data in motion (the key concept of Kappa), but the video also compares various technologies and vendors such as Confluent, Cloudera, IBM Red Hat, Apache Flink, Apache Pulsar, AWS Kinesis, Amazon MSK, Azure Event Hubs, Google Pub Sub, and more.
Video recording of this presentation:
https://youtu.be/j7D29eyysDw
Further reading:
https://www.kai-waehner.de/blog/2021/09/23/real-time-kappa-architecture-mainstream-replacing-batch-lambda/
https://www.kai-waehner.de/blog/2021/04/20/comparison-open-source-apache-kafka-vs-confluent-cloudera-red-hat-amazon-msk-cloud/
https://www.kai-waehner.de/blog/2021/05/09/kafka-api-de-facto-standard-event-streaming-like-amazon-s3-object-storage/
Domain Driven Design - Strategic Patterns and MicroservicesRadosław Maziarka
Presentation describes Domain Driven Design - approach to create applications driven by business domain. I show how to split your monolith base on DDD strategic patterns.
Should you use traditional REST APIs to bind services together? Or is it better to use a richer, more loosely-coupled protocol? This talk will dig into how we piece services together in event driven systems, how we use a distributed log (event hub) to create a central, persistent history of events and what benefits we achieve from doing so. Apache Kafka is a perfect match for building such an asynchronous, loosely-coupled event-driven backbone. Events trigger processing logic, which can be implemented in a more traditional as well as in a stream processing fashion. The talk will show the difference between a request-driven and event-driven communication and show when to use which. It highlights how the modern stream processing systems can be used to
hold state both internally as well as in a database and how this state can be used to further increase independence of other services, the primary goal of a Microservices architecture.
Grafana Loki: like Prometheus, but for LogsMarco Pracucci
Loki is a horizontally-scalable, highly-available log aggregation system inspired by Prometheus. It is designed to be very cost-effective and easy to operate, as it does not index the contents of the logs, but rather labels for each log stream.
In this talk, we will introduce Loki, its architecture and the design trade-offs in an approachable way. We’ll both cover Loki and Promtail, the agent used to scrape local logs to push to Loki, including the Prometheus-style service discovery used to dynamically discover logs and attach metadata from applications running in a Kubernetes cluster.
Finally, we’ll show how to query logs with Grafana using LogQL - the Loki query language - and the latest Grafana features to easily build dashboards mixing metrics and logs.
An overview of Azure API Management, common use cases, and how it helps organizations to govern, publish, secure, analyze, and manage APIs for internal and external consumption whether their running in the cloud or on-prem.
Event Driven Architecture with a RESTful Microservices Architecture (Kyle Ben...confluent
Tinder’s Quickfire Pipeline powers all things data at Tinder. It was originally built using AWS Kinesis Firehoses and has since been extended to use both Kafka and other event buses. It is the core of Tinder’s data infrastructure. This rich data flow of both client and backend data has been extended to service a variety of needs at Tinder, including Experimentation, ML, CRM, and Observability, allowing backend developers easier access to shared client side data. We perform this using many systems, including Kafka, Spark, Flink, Kubernetes, and Prometheus. Many of Tinder’s systems were natively designed in an RPC first architecture.
Things we’ll discuss decoupling your system at scale via event-driven architectures include:
– Powering ML, backend, observability, and analytical applications at scale, including an end to end walk through of our processes that allow non-programmers to write and deploy event-driven data flows.
– Show end to end the usage of dynamic event processing that creates other stream processes, via a dynamic control plane topology pattern and broadcasted state pattern
– How to manage the unavailability of cached data that would normally come from repeated API calls for data that’s being backfilled into Kafka, all online! (and why this is not necessarily a “good” idea)
– Integrating common OSS frameworks and libraries like Kafka Streams, Flink, Spark and friends to encourage the best design patterns for developers coming from traditional service oriented architectures, including pitfalls and lessons learned along the way.
– Why and how to avoid overloading microservices with excessive RPC calls from event-driven streaming systems
– Best practices in common data flow patterns, such as shared state via RocksDB + Kafka Streams as well as the complementary tools in the Apache Ecosystem.
– The simplicity and power of streaming SQL with microservices
CSI – IT2020, IIT Mumbai, October 6th 2017
Computer Society of India, Mumbai Chapter
The presentation focuses on Microservices architecture and the comparison between MicroService with Standard Monolithic Apps and SOA based Apps. It also gives a quick outline of Domain Driven Design, Event Sourcing and CQRS, Functional Reactive Programming and comparison of SAGA pattern with 2 Phase Commit.
http://www.csimumbai.org/it2020-17/index.html
As businesses grow, so does the complexity of their software. New features, new models, and new background processes all continue to be added. . .and developers struggle to make sense of it all. Yet the end user demands a swift and functional experience when interacting with your application. It is paramount to be open to alternative patterns that help tame complex, high-demand services. Two such patterns are command-query responsibility segregation (CQRS) and event sourcing (ES).
Command-query responsibility segregation is an architectural pattern for user-facing applications that extends from the now standard Model-View-Controller (MVC) pattern and is an alternative to the CRUD pattern. At its core, CQRS is about changing how we think of and work with our data by introducing two types of models: all user actions become commands, and a read-only query model powers our views. Commands and queries are logistically separated, providing additional decoupling of our application. CQRS also calls for changes in how we store and structure our data.
Enter event sourcing. Instead of persisting the current state of our domain objects or entities, we record historical events about our data. The key advantage is that we can examine our application data at any point in time, rather than just the current state. This pattern changes how we persist and process our data but is surprisingly efficient.
While each of the two patterns can be used exclusively, they complement each other beautifully and facilitate the construction of decoupled, scalable applications or individual services. Stephen Pember explores the fundamentals of each pattern and offers several examples and demonstration code to show how one might actually go about implementing CQRS and ES. Steve discusses task-based UIs and domain-driven design as he outlines some of the advantages—and challenges—that ThirdChannel has seen when developing systems using CQRS and ES over the past year.
Understanding MicroSERVICE Architecture with Java & Spring BootKashif Ali Siddiqui
This is a deep journey into the realm of "microservice architecture", and in that I will try to cover each inch of it, but with a fixed tech stack of Java with Spring Cloud. Hence in the end, you will be get know each and every aspect of this distributed design, and will develop an understanding of each and every concern regarding distributed system construct.
Architecture principles, How to, Patterns,
Comparison with other SOA styles
Pragmatic options to scale Monoliths
Illustrated with the Netflix stack and Gilt, SoundCloud testimonials
To go futher, check 200 - Building Microservices
http://fr.slideshare.net/SteveSfartz/building-microservices-55458071
Building Cloud-Native App Series - Part 2 of 11
Microservices Architecture Series
Event Sourcing & CQRS,
Kafka, Rabbit MQ
Case Studies (E-Commerce App, Movie Streaming, Ticket Booking, Restaurant, Hospital Management)
There is a lot of talk now around the term Service Mesh. The hype is high and the promise is real. The problem is that there is not really a good definition of what service mesh really is. In this talk we are going to review the problem service meshes are trying to solve, name the core components that make up a service mesh, and discuss the benefits an organization can receive by implementing this new technology.
Conférence Devoxx FR 2022
"Microservices, DDD et bootstrapping pour faire un départ lancé"
Résumé de la présentation :
Associer microservices et conception DDD (Domain-Driven Design) semble une évidence. Le découpage en contextes et les différentes couches d’architecture constituent un cadre séduisant pour bâtir des microservices avec une structure stéréotypée. Mais si on souhaite respecter les fondamentaux du DDD et garantir l’isolation des différentes couches on arrive rapidement à une structure de projet basée sur plusieurs modules qui peuvent devenir complexes à gérer et qui risquent de ralentir le cycle de développement, en particulier lors de la phase de démarrage.
Cette présentation est un retour d’expérience d’un grand projet dans lequel le générateur de code Telosys a été utilisé pour automatiser la phase d’amorçage de chaque microservice.
Environnement technique : Java, SpringBoot, Telosys
[2015/2016] AADL (Architecture Analysis and Design Language)Ivano Malavolta
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
Domain Driven Design - Strategic Patterns and MicroservicesRadosław Maziarka
Presentation describes Domain Driven Design - approach to create applications driven by business domain. I show how to split your monolith base on DDD strategic patterns.
Should you use traditional REST APIs to bind services together? Or is it better to use a richer, more loosely-coupled protocol? This talk will dig into how we piece services together in event driven systems, how we use a distributed log (event hub) to create a central, persistent history of events and what benefits we achieve from doing so. Apache Kafka is a perfect match for building such an asynchronous, loosely-coupled event-driven backbone. Events trigger processing logic, which can be implemented in a more traditional as well as in a stream processing fashion. The talk will show the difference between a request-driven and event-driven communication and show when to use which. It highlights how the modern stream processing systems can be used to
hold state both internally as well as in a database and how this state can be used to further increase independence of other services, the primary goal of a Microservices architecture.
Grafana Loki: like Prometheus, but for LogsMarco Pracucci
Loki is a horizontally-scalable, highly-available log aggregation system inspired by Prometheus. It is designed to be very cost-effective and easy to operate, as it does not index the contents of the logs, but rather labels for each log stream.
In this talk, we will introduce Loki, its architecture and the design trade-offs in an approachable way. We’ll both cover Loki and Promtail, the agent used to scrape local logs to push to Loki, including the Prometheus-style service discovery used to dynamically discover logs and attach metadata from applications running in a Kubernetes cluster.
Finally, we’ll show how to query logs with Grafana using LogQL - the Loki query language - and the latest Grafana features to easily build dashboards mixing metrics and logs.
An overview of Azure API Management, common use cases, and how it helps organizations to govern, publish, secure, analyze, and manage APIs for internal and external consumption whether their running in the cloud or on-prem.
Event Driven Architecture with a RESTful Microservices Architecture (Kyle Ben...confluent
Tinder’s Quickfire Pipeline powers all things data at Tinder. It was originally built using AWS Kinesis Firehoses and has since been extended to use both Kafka and other event buses. It is the core of Tinder’s data infrastructure. This rich data flow of both client and backend data has been extended to service a variety of needs at Tinder, including Experimentation, ML, CRM, and Observability, allowing backend developers easier access to shared client side data. We perform this using many systems, including Kafka, Spark, Flink, Kubernetes, and Prometheus. Many of Tinder’s systems were natively designed in an RPC first architecture.
Things we’ll discuss decoupling your system at scale via event-driven architectures include:
– Powering ML, backend, observability, and analytical applications at scale, including an end to end walk through of our processes that allow non-programmers to write and deploy event-driven data flows.
– Show end to end the usage of dynamic event processing that creates other stream processes, via a dynamic control plane topology pattern and broadcasted state pattern
– How to manage the unavailability of cached data that would normally come from repeated API calls for data that’s being backfilled into Kafka, all online! (and why this is not necessarily a “good” idea)
– Integrating common OSS frameworks and libraries like Kafka Streams, Flink, Spark and friends to encourage the best design patterns for developers coming from traditional service oriented architectures, including pitfalls and lessons learned along the way.
– Why and how to avoid overloading microservices with excessive RPC calls from event-driven streaming systems
– Best practices in common data flow patterns, such as shared state via RocksDB + Kafka Streams as well as the complementary tools in the Apache Ecosystem.
– The simplicity and power of streaming SQL with microservices
CSI – IT2020, IIT Mumbai, October 6th 2017
Computer Society of India, Mumbai Chapter
The presentation focuses on Microservices architecture and the comparison between MicroService with Standard Monolithic Apps and SOA based Apps. It also gives a quick outline of Domain Driven Design, Event Sourcing and CQRS, Functional Reactive Programming and comparison of SAGA pattern with 2 Phase Commit.
http://www.csimumbai.org/it2020-17/index.html
As businesses grow, so does the complexity of their software. New features, new models, and new background processes all continue to be added. . .and developers struggle to make sense of it all. Yet the end user demands a swift and functional experience when interacting with your application. It is paramount to be open to alternative patterns that help tame complex, high-demand services. Two such patterns are command-query responsibility segregation (CQRS) and event sourcing (ES).
Command-query responsibility segregation is an architectural pattern for user-facing applications that extends from the now standard Model-View-Controller (MVC) pattern and is an alternative to the CRUD pattern. At its core, CQRS is about changing how we think of and work with our data by introducing two types of models: all user actions become commands, and a read-only query model powers our views. Commands and queries are logistically separated, providing additional decoupling of our application. CQRS also calls for changes in how we store and structure our data.
Enter event sourcing. Instead of persisting the current state of our domain objects or entities, we record historical events about our data. The key advantage is that we can examine our application data at any point in time, rather than just the current state. This pattern changes how we persist and process our data but is surprisingly efficient.
While each of the two patterns can be used exclusively, they complement each other beautifully and facilitate the construction of decoupled, scalable applications or individual services. Stephen Pember explores the fundamentals of each pattern and offers several examples and demonstration code to show how one might actually go about implementing CQRS and ES. Steve discusses task-based UIs and domain-driven design as he outlines some of the advantages—and challenges—that ThirdChannel has seen when developing systems using CQRS and ES over the past year.
Understanding MicroSERVICE Architecture with Java & Spring BootKashif Ali Siddiqui
This is a deep journey into the realm of "microservice architecture", and in that I will try to cover each inch of it, but with a fixed tech stack of Java with Spring Cloud. Hence in the end, you will be get know each and every aspect of this distributed design, and will develop an understanding of each and every concern regarding distributed system construct.
Architecture principles, How to, Patterns,
Comparison with other SOA styles
Pragmatic options to scale Monoliths
Illustrated with the Netflix stack and Gilt, SoundCloud testimonials
To go futher, check 200 - Building Microservices
http://fr.slideshare.net/SteveSfartz/building-microservices-55458071
Building Cloud-Native App Series - Part 2 of 11
Microservices Architecture Series
Event Sourcing & CQRS,
Kafka, Rabbit MQ
Case Studies (E-Commerce App, Movie Streaming, Ticket Booking, Restaurant, Hospital Management)
There is a lot of talk now around the term Service Mesh. The hype is high and the promise is real. The problem is that there is not really a good definition of what service mesh really is. In this talk we are going to review the problem service meshes are trying to solve, name the core components that make up a service mesh, and discuss the benefits an organization can receive by implementing this new technology.
Conférence Devoxx FR 2022
"Microservices, DDD et bootstrapping pour faire un départ lancé"
Résumé de la présentation :
Associer microservices et conception DDD (Domain-Driven Design) semble une évidence. Le découpage en contextes et les différentes couches d’architecture constituent un cadre séduisant pour bâtir des microservices avec une structure stéréotypée. Mais si on souhaite respecter les fondamentaux du DDD et garantir l’isolation des différentes couches on arrive rapidement à une structure de projet basée sur plusieurs modules qui peuvent devenir complexes à gérer et qui risquent de ralentir le cycle de développement, en particulier lors de la phase de démarrage.
Cette présentation est un retour d’expérience d’un grand projet dans lequel le générateur de code Telosys a été utilisé pour automatiser la phase d’amorçage de chaque microservice.
Environnement technique : Java, SpringBoot, Telosys
[2015/2016] AADL (Architecture Analysis and Design Language)Ivano Malavolta
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
This is a one day workshop presentation, primarily on the new OMG Foundational UML specification for executable model semantics, but also discussing extensions for executable SysML (System Modeling Language) models.
[2016/2017] AADL (Architecture Analysis and Design Language)Ivano Malavolta
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
This is an introductory lecture to Architecture Description Languages, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)
This presentation is about a lecture I gave within the "Software Modeling" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam.
http://www.ivanomalavolta.com
[2017/2018] AADL - Architecture Analysis and Design LanguageIvano Malavolta
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
you can be friend with me on orkut
"mangalforyou@gmail.com" : i belive in sharing the knowledge so please send project reports ,seminar and ppt. to me .
Hönnunarmunstur eru aðferðir við að leysa algeng vandamál. En notkun þeirra felst í að takast á við verkefni sem þarf að leysa. Fyrst koma verkefnin og svo finnum við hvaða munstur hentar miðað við þær forsendur sem við höfum. Oft þegar verið er að vinna að lausnum þá er alls ekki hægt að gera allan hugbúnaðinn í einu, heldur þarf að "hakka" suma hluti meðan unnið er í öðru. Til þess að lenda ekki í technical dept þarf að vera með stöðugt refactoring.
Í þessum fyrirlestri skoðum við vandamál og rifjum upp grunnmunstrin (base patterns) sem við kynntumst í L05 Design Patterns. Þá skoðum við hvernig við leysum tengingu við póstþjón.
Conducting Experiments on the Software Architecture of Robotic Systems (QRARS...Ivano Malavolta
Slides of my invited talk at the 2nd workshop on Quality and Reliability Assessment of Robotic Software Architectures and Components (QRARSAC), co-located with the International Conference on Robotics and Automation (ICRA 2023).
Abstract of the talk. Today robotic systems are central to many industrial sectors, such as logistics, autonomous warehousing, and healthcare. If on one side ROS is helping roboticists by providing a standardized communication platform for robotic systems, on the other side ROSsystems are getting more and more large and complex, thus making it extremely difficult to ensure their level of quality, e.g., in terms of performance, security, energy efficiency, testability, maintainability. Improving the quality of robotic systems is not a new activity, but in this talk, we tackle it from a different perspective: we look at them from a software architecture perspective. In this talk, I will walk you through a series of experiments we conducted at the Vrije Universiteit Amsterdam targeting the architecture of ROS systems, we will discuss some architectural tactics for ROS systems, and will close with an overview of our open-source tool for automatically executing experiments on robotics software.
The slides of a short presentation I gave about my experience about working in the context of EU grants. It contains tips and tricks for the before/during/after phases of a EU project.
The Green Lab - Research cocktail @Vrije Universiteit Amsterdam (October 2020)Ivano Malavolta
The slides of my presentation about the Green Lab at the event called Research Cocktail (October 2020). The event is organized by the Computer Science Department of the Vrije Universiteit Amsterdam.
The source code of our tools and the replication package of our experiments performed in the Green Lab can be found here: https://github.com/S2-group
For further details about the Green Lab and all our activities around it, you can contact me at i.malavolta@vu.nl
Navigation-aware and Personalized Prefetching of Network Requests in Android ...Ivano Malavolta
Slides of my presentation at the NIER track of the 41th International Conference on Software Engineering (ICSE 2019).
The paper is available here: http://www.ivanomalavolta.com/files/papers/ICSE_2019_NAPPA.pdf
How Maintainability Issues of Android Apps Evolve [ICSME 2018]Ivano Malavolta
Slides of my presentation at the Research track of the 34th International Conference on Software Maintenance and Evolution (ICSME 2018).
The full paper is available here: http://www.ivanomalavolta.com/files/papers/ICSME_2018.pdf
Collaborative Model-Driven Software Engineering: a Classification Framework a...Ivano Malavolta
Slides of my presentation at the Journal first track of the 40th International Conference on Software Engineering (ICSE 2018).
The accompanying extended abstract is available here: http://www.ivanomalavolta.com/files/papers/ICSE_2018_JournalFirst.pdf
The original TSE paper is available here: http://www.ivanomalavolta.com/files/papers/TSE_2017.pdf
This presentation is about a lecture I gave within the "Software Design" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam.
http://www.ivanomalavolta.com
Modeling behaviour via UML state machines [Software Design] [Computer Science...Ivano Malavolta
This presentation is about a lecture I gave within the "Software Design" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam.
http://www.ivanomalavolta.com
This presentation is about a lecture I gave within the "Software Design" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam.
http://www.ivanomalavolta.com
This presentation is about a lecture I gave within the "Software Design" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam.
http://www.ivanomalavolta.com
Requirements engineering with UML [Software Design] [Computer Science] [Vrije...Ivano Malavolta
This presentation is about a lecture I gave within the "Software Design" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam.
http://www.ivanomalavolta.com
Modeling and abstraction, software development process [Software Design] [Com...Ivano Malavolta
This presentation is about a lecture I gave within the "Software Design" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam.
http://www.ivanomalavolta.com
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
[2017/2018] Introduction to Software ArchitectureIvano Malavolta
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.it/.
http://www.ivanomalavolta.com
Communications Mining Series - Zero to Hero - Session 1DianaGray10
This session provides introduction to UiPath Communication Mining, importance and platform overview. You will acquire a good understand of the phases in Communication Mining as we go over the platform with you. Topics covered:
• Communication Mining Overview
• Why is it important?
• How can it help today’s business and the benefits
• Phases in Communication Mining
• Demo on Platform overview
• Q/A
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
GraphSummit Singapore | The Art of the Possible with Graph - Q2 2024Neo4j
Neha Bajwa, Vice President of Product Marketing, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AIVladimir Iglovikov, Ph.D.
Presented by Vladimir Iglovikov:
- https://www.linkedin.com/in/iglovikov/
- https://x.com/viglovikov
- https://www.instagram.com/ternaus/
This presentation delves into the journey of Albumentations.ai, a highly successful open-source library for data augmentation.
Created out of a necessity for superior performance in Kaggle competitions, Albumentations has grown to become a widely used tool among data scientists and machine learning practitioners.
This case study covers various aspects, including:
People: The contributors and community that have supported Albumentations.
Metrics: The success indicators such as downloads, daily active users, GitHub stars, and financial contributions.
Challenges: The hurdles in monetizing open-source projects and measuring user engagement.
Development Practices: Best practices for creating, maintaining, and scaling open-source libraries, including code hygiene, CI/CD, and fast iteration.
Community Building: Strategies for making adoption easy, iterating quickly, and fostering a vibrant, engaged community.
Marketing: Both online and offline marketing tactics, focusing on real, impactful interactions and collaborations.
Mental Health: Maintaining balance and not feeling pressured by user demands.
Key insights include the importance of automation, making the adoption process seamless, and leveraging offline interactions for marketing. The presentation also emphasizes the need for continuous small improvements and building a friendly, inclusive community that contributes to the project's growth.
Vladimir Iglovikov brings his extensive experience as a Kaggle Grandmaster, ex-Staff ML Engineer at Lyft, sharing valuable lessons and practical advice for anyone looking to enhance the adoption of their open-source projects.
Explore more about Albumentations and join the community at:
GitHub: https://github.com/albumentations-team/albumentations
Website: https://albumentations.ai/
LinkedIn: https://www.linkedin.com/company/100504475
Twitter: https://x.com/albumentations
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!SOFTTECHHUB
As the digital landscape continually evolves, operating systems play a critical role in shaping user experiences and productivity. The launch of Nitrux Linux 3.5.0 marks a significant milestone, offering a robust alternative to traditional systems such as Windows 11. This article delves into the essence of Nitrux Linux 3.5.0, exploring its unique features, advantages, and how it stands as a compelling choice for both casual users and tech enthusiasts.
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
3. Real-Time, Critical, Embedded
Systems
« Real-time systems are defined as those systems in
which the correctness of the system depends not only on
the logical result of computation, but also on the time at
which the results are produced » Stankovic, 1988.
Properties we look for:
– Functions must be predictable: the same data input will
produce the same data output.
– Timing behavior must be predictable: must meet temporal
constraints (e.g. deadline).
4. Real-Time, Critical, Embedded
Systems
Critical (or hard) real-time systems: temporal constraints
MUST be met, otherwise defects could have a dramatic
impact on human life, on the environment, on the system
Embedded systems: computing system designed for
specific control functions within a larger system
n Often with temporal constraints
n Part of a complete device, often including hardware and
mechanical parts
n Limited amount of resources
5. Real-Time, Critical, Embedded
Systems
• Need to handle time. Concurrent applications.
• May have dramatic impact on human life, on the
system, ...
• Do not allow software maintenance
à difficult to correct erroneous software/bugs
• High implementation cost
– temporal constraints verification, safety, dedicated hardware/
software
• Examples : aircraft, satellite, automotive, …
5
7. Real-Time, Critical, Embedded
Systems
Specific software engineering methods/models/tools to
master quality and cost
n Example : early verifications at design step
9. Objectives of this lecture
• Issues
– How to model/design a real-time critical embedded system that
conforms to requirements?
– How to verify the solution?
– How to prototype/implement it?
• One solution among others: use an architectural
language
• to model the system
• to run various verification
• and to automatically produce the system
• Focus on the AADL2.1 SAE standard (2012)
10. Case study
Goal: to model a simple radar system
Let us suppose we have the following requirements:
1. System implementation is composed by physical devices (Hardware
entity): antenna + processor + memory + bus
2. and software entities : running processes and threads + operating system
functionalities (scheduling) implemented in the processor that represent a
part of execution platform and physical devices in the same time
3. The main process is responsible for signals processing : general pattern:
transmitter -> antenna -> receiver -> analyzer -> display
4. Analyzer is a periodic thread that compares transmitted and received
signals to perform detection, localization and identification
11. Outline of this lecture
Goal: introduce model-based description of embedded real-time
critical systems using the AADLv2 architectural language
• Part 1: Basics on AADLv2 core
– Syntax, semantics of the language
• Part 2: Case study
– A radar illustrative case study
13. Outline
1. Quick overview
2. AADL key modeling constructs
1. Software components
2. Execution platform components
3. Properties
4. Modelling large scale systems
3. Tool support
14. Introduction
AADL: AL for real-time critical embedded systems
(Architecture Analysis and Design Language)
– Goal : modeling software and hardware architectures
• to master complexity
• to perform analysis
• to generate code
• ….
– Concepts : components, connections, deployments.
– Many ALs : formal/non formal, application domain, …
15. AADL: Architecture Analysis & Design
Language
• International standard promoted by SAE, AS-2C
committee, released as AS5506 family of standards
• Version 1.0 (2004), version 2 (2009), 2.1 (2012)
– Based on feedback from industry users, mostly from the space
and avionics domain
• Annex document to address specific needs
– Behavior, data, error modeling, code generation, …
19. AADL: Architecture Analysis & Design
Language
Based on the component-connector paradigm
Key Elements:
• Core AADL language standard
– Textual & graphical, precise semantics, extensible
• AADL Meta model & XMI/XML standard
– Model interchange & tool interoperability
• Annexes Error Model Annex as standardized extension
– Error Model Annex addresses fault/reliability modeling, hazard
analysis
• UML 2.0 profile for AADL
– Transition path for UML practitioners community
22. AADL components
• AADL model : hierarchy/tree of components
• AADL component
• Model a software or a hardware entity
• May be organized in packages : reusable
• Has a type/interface, one or several implementations
• May have subcomponents
• May combine/extend/refine others
• May have properties : valued typed attributes (source code file name,
priority, execution time, memory consumption, …)
• Component interactions
– Modeled by component connections
– AADL features are connection points
23. AADL components
• How to declare a component:
– Component type:
• name, category, properties, features => interface
– Component implementation: internal structure (subcomponents),
properties
• Component categories: model real-time abstractions, close to the
implementation space (ex : processor, task, …)
• Each category has a well-defined semantics/behavior, refined
through the property mechanism
– Software components
– Hardware components: execution platform
– Systems : bounding box of a system
• Model a deployment
24. Component type
• AADLv2 distinguished type and implementation
Component type = high-level specification of a component
All component type declarations follow the same pattern:
24
<category> foo [extends <bar>]
features
-- list of features
-- interface
properties
-- list of properties
-- e.g. priority
end foo;
Inherit features and
properties from parent
Interface of the component:
Exchange messages, access to
data or call subprograms
Some properties describing
non-functional aspect of the
component
25. Component type example
-- model a sequential execution flow
subprogram Spg -- Spg represents a C function,
features -- in file "foo.c", that takes one
in_param : in parameter foo_data; -- parameter as input
properties
Source_Language => C;
Standard properties, one can
Source_Text => ("foo.c");
define its own properties
end Spg;
-- model a schedulable flow of control
thread bar_thread -- bar_thread is a sporadic thread :
features -- dispatched whenever it
in_data : in event data port foo_data; -- receives an event on its “in_data"
properties -- port
Dispatch_Protocol => Sporadic;
end bar_thread;
26. Component implementation
• Component Implementation completes the interface
– Think spec/body package (Ada), interface/class (Java)
<category> implementation foo.i [extends <bar>.i]
subcomponents
-- internal components
foo.i implements foo
calls
-- called subprograms,
-- only for threads or subprograms
connections
properties
-- list of properties
-- e.g. Deadline
end foo.i;
27. Component implementation example
subprogram Spg -- Spg represents a C function,
features -- in file "foo.c", that takes one
in_param : in parameter foo_data; -- parameter as input
properties
Source_Language => C;
Source_Text => ("foo.c");
end Spg;
thread bar_thread -- bar_thread is a sporadic thread,
features -- it is dispatched whenever it
in_data : in event data port foo_data; -- receives an event
properties
Dispatch_Protocol => Sporadic;
end bar_thread;
thread implementation bar_thread.impl -- in this implementation, at each
-- dispatch we execute the "C" call
calls -- sequence. We pass the dispatch
C : { S : subprogram spg; }; -- parameter to the call sequence
connections
P1: parameter in_data -> S.in_param;
end bar_thread.impl;
Connect data/
parameter
28. AADL concepts
• AADL introduces many other concepts:
– Related to embedded real-time critical systems
• AADL flows: capture high-level data + execution flows
• AADL modes: model operational modes in the form
of an alternative set of active components,
connections, …
– To ease models design/management
• AADL packages (similar to Java, renames, private/
public)
• AADL abstract component, component extensions, …
29. Outline
1. Quick overview
2. AADL key modeling constructs
1. Software components
2. Execution platform components
3. Properties
4. Modelling large scale systems
3. Tool support
31. Three levels of description
• Category (predefined)
• Type
– specification of the external interface
• Implementation
– specification of the content
• Instance
– instantiation of a type
or an implementation
– this is done by the tool
32. Software components categories
• Process : address space. It must
hold at least one thread
• Thread : schedulable execution
flow, Ada or VxWorks task, Java
or POSIX thread. Execute
programs
• Data : data placeholder, e.g. C
struct, C++ class, Ada record
• Subprogram : a sequential
execution flow. Associated to a
source code (C, Ada) or a model
(SCADE, Simulink)
• Thread group : hierarchy of
threads
33. Software components
Example of a process component composed of two
threads
thread receiver
end receiver;
thread implementation receiver.impl
end receiver.impl;
thread analyser
end analyser;
thread implementation analyser.impl
end analyser.impl;
process processing
end processing;
process implementation processing.others
subcomponents
receive : thread receiver.impl;
analyse : thread analyser.impl;
. . .
end processing.others;
34. Software components
Example of a thread component : a thread may call
different subprograms
thread receiver
end receiver;
thread implementation receiver.impl
calls CS : {
call1 : subprogram Receiver_Spg;
call2 : subprogram ComputeCRC_Spg;
};
end receiver.impl;
subprogram Receiver_Spg
end Receiver_Spg;
subprogram ComputeCRC_Spg
end ComputeCRC_Spg;
. . .
35.
36.
37.
38.
39.
40.
41. Thread group
A thread group represents an organizational component to
logically group threads contained in a process
Thread groups can be hierarchically nested
42.
43. Subprogram
A subprogram component represents an execution entry point in source
text
No component can contain subprogram subcomponents. Instances of
subprogram don't exist
A subprogram call in the implementation of a thread or another
subprogram may be “seen as” the inclusion of a subprogram
subcomponent
A thread can have call sequences for its states:
– initialization, finalization, activation, deactivation, computation, and recovery
Each thread dispatch executes the computation call sequence once
47. Data
It represents static data (e.g., numerical data or source text)
and data types within a system
– (e.g., used as data types on ports and parameters)
Components may have a shared access to a data
component
Good practice: to store data definitions in a separate file
51. Component connection
Features of subcomponents are connected in the
“connections” subclause of the enclosing component
Example
thread analyser
features
analyser_out : out data port
Target_Position.Impl;
end analyser;
thread display_panel
features
display_in : in data port Target_Position.Impl;
end display_panel;
process implementation processing.others
subcomponents
display : thread display_panel.impl;
analyse : thread analyser.impl;
connections
port analyse.analyser_out -> display.display_in;
end processing.others;
54. Data connection policies
Immediate
receiver thread is immediately
awaken, and will read data
when emitter finished
Delayed
actual transmission is
delayed to the next time
frame
56. Modes
A mode represents an operational state of a system
A mode of a component can influence:
– property values
– activation of specific subcomponents
– existence of connections
Example - Modes of a cruise controller:
{initialize, disengaged, engaged}
57. Modes transitions
Mode transitions represent configuration changes as reaction
to events
– Triggered through ports (from outside or from a subcomponent)
– Triggered internally by implementation software
– Triggered internally in an execution platform component or a
device
• Note: Modes are not intended for modeling detailed
internal behavior of threads or subprograms (︎ AADL
Behavior Annex)
60. Outline
1. Quick overview
2. AADL key modeling constructs
1. Software components
2. Execution platform components
3. Properties
4. Modelling large scale systems
3. Tool support
61. Hardware components categories
• Processor/virtual processor
– schedule component (combined CPU and RTOS scheduler). A
processor may contain multiple virtual processors
• memory
– model data storage (memory, hard drive)
• device
– component that interacts with the environment. Internals (e.g.
firmware) is not modeled.
• bus/virtual bus
– data exchange mechanism between components
Device Memory bus Processor
70. Software/platform binding
• Actual_Processor_Binding
– Specify which processor schedules and executes a thread or
executes a (kernel mode) device driver
• Actual_Memory_Binding
– Specify the memory components in which executable code
(process components) and data (data component) reside
• Actual_Connection_Binding
– Specify the communication channels that are used by logical
connections (see next section)
73. Outline
1. Quick overview
2. AADL key modeling constructs
1. Software components
2. Execution platform components
3. Properties
4. Modelling large scale systems
3. Tool support
74. AADL properties
Property:
– Typed attribute, associated to one or more components
– Property = name + type + allowed components
– Property association = property name + value
Allowed types in properties:
– aadlboolean, aadlinteger, aadlreal, aadlstring,
enumeration, many others …
Can be propagated to subcomponents: inherit
Can override parent’s one, case of extends
76. AADL properties
Properties are associated to a component type (1) or
implementation (2), as part of a subcomponent instance (3),
or a contained property association (4).
process implementation processing.others
subcomponents
receive0 : thread receiver.impl;
receive1 : thread receiver.impl;
receive2 : thread receiver.impl
{Deadline => 200 ms;}; -- (3)
properties -- (4)
Deadline => 300 ms applies to receive1;
end processing.others;
thread receiver
properties -- (1)
Compute_Execution_Time => 3 .. 4 ms;
Deadline => 150 ms ;
end receiver;
thread implementation receiver.impl
properties -- (2)
Deadline => 160 ms;
Compute_Execution_Time => 4 .. 10 ms;
end receiver.impl;
77. Property sets
Property sets :
– Group property definitions
– They can be either
• part of the standard, e.g. Thread_Properties
• or user-defined, e.g. for new analysis as power analysis
Example :
property set Thread_Properties is
. . .
Priority : aadlinteger applies to (thread, device, …);
Source_Text : inherit list of aadlstring applies to (data, port, thread, …);
. . .
end Thread_Properties;
79. Measurement units
Properties are typed with units to model physical systems,
related to embedded real-time critical systems
property set AADL_Projects is
Time_Units: type units (
ps,
ns => ps * 1000,
us => ns * 1000,
ms => us * 1000,
sec => ms * 1000,
min => sec * 60,
hr => min * 60);
-- …
end AADL_Projects;
property set Timing_Properties is
Time: type aadlinteger
0ps .. Max_Time units Time_Units;
Time_Range: type range of Time;
Compute_Execution_Time: Time_Range
applies to (thread, device, subprogram,
event port, event data port);
end Timing_Properties;
80. Outline
1. Quick overview
2. AADL key modeling constructs
1. Software components
2. Execution platform components
3. Properties
4. Modelling large scale systems
3. Tool support
81. AADL packages
A package provides a means to organize the descriptions by
the use of namespaces
A package can contain:
– component types
– component implementations
– port group types
– annex libraries
83. AADL systems
Help structuring an architecture, with its own hierarchy of
subcomponents.
A system can include one or several subsystems
In an AADL specification there is always a root system
component
Bindings : model the deployment of components inside the
component hierarchy
System
84. AADL systems
subprogram Receiver_Spg …
thread receiver …
thread implementation receiver.impl
… call1 : subprobram Receiver_Spg; …
end receiver.impl;
process processing
end processing;
process implementation processing.others
subcomponents
receive : thread receiver.impl;
analyse : thread analyser.impl;
. . .
end processing.others;
device antenna
end antenna;
processor leon2
end leon2;
system radar
end radar;
system implementation radar.simple
subcomponents
main : process processing.others;
cpu : processor leon2;
properties
Actual_Processor_Binding =>
reference cpu applies to main;
end radar.simple;
85. A full AADL system : a tree of
component instances
• Component types and
implementations only define a
library of entities (classifiers)
• An AADL model is a set of
component instances (of the
classifiers)
• System must be instantiated
through a hierarchy of
subcomponents, from root
(system) to the leafs
(subprograms, ..)
• We must choose a system
implementation component as
the root system model !
Root System
Sub System Process Processor
Thread Data
Subprogram
86. About subcomponents
Some restrictions apply on subcomponents
– A hardware cannot contain software, etc
data data, subprogram
thread data, subprogram
thread
group
data, thread, thread group, subprogram
process thread, thread group, data
processor Memory, virtual processor, bus
memory Memory, bus
system ALL except subprogram, thread, and thread
group
86
87. System instances
Component types and instances are “only” blueprints
System instances represents the runtime architecture of an
operational physical system
Composed of software components + execution platform
XML for storing system instances
88. System instances 2
System instances are automatically generated by OSATE
starting from complet system implementations
89. Components extension & refinement
Extension: to define a new extended classifier based on an
existing classifier
Allows incremental refinement of a model
• Component extension
– Component types
– Component implementations
WHY extensions?
– Add elements to a classifier
• features, subcomponents, connections, flows, etc.
– Refine existing elements in a component
– Add or override properties
100. Radar case study
Hardware/Software breakdown: components
PACKAGE radar
PUBLIC
PROCESS processing
-- …
END processing;
DEVICE antenna
-- …
END antenna;
END RADAR;
101. Radar case study
Hardware/Software breakdown: features
in/out ports
bus access
PROCESS processing
FEATURES
to_screen : OUT EVENT PORT;
send_pulse : OUT EVENT PORT;
receive_pulse : IN DATA PORT;
get_angle : IN DATA PORT;
END processing;
DEVICE antenna
FEATURES
antenna_in : IN EVENT PORT;
VME : REQUIRES BUS ACCESS VME;
END antenna;
102. Radar case study
Hardware/Software breakdown: connections
Logical cnx
Hardware cnx
103. Radar case study
Hardware/Software breakdown: connections
SYSTEM IMPLEMENTATION radar.simple
SUBCOMPONENTS
aerial : DEVICE antenna;
rotor : DEVICE motor;
monitor : DEVICE screen;
main : PROCESS processing.others;
cpu : PROCESSOR leon2;
VME : BUS VME;
RAM : MEMORY RAM;
CONNECTIONS
PORT aerial.antenna_out -> main.receive_pulse;
PORT rotor.motor_out -> main.get_angle;
PORT main.send_pulse -> aerial.antenna_in;
PORT main.to_screen -> monitor.screen_in;
BUS ACCESS VME -> aerial.VME;
BUS ACCESS VME -> rotor.VME;
BUS ACCESS VME -> monitor.VME;
BUS ACCESS VME -> cpu.VME;
BUS ACCESS VME -> RAM.VME;
104. Radar case study
• Hardware/Software breakdown: bindings
Bindings
PROPERTIES
Actual_Memory_Binding => reference (ram) applies to main;
Actual_Processor_Binding => reference (cpu) applies to main;
END radar.simple;
108. What this lecture means to you?
AADL = Architecture Analysis & Design Language
AADL is for architectural description, period
à Not to be compared with UML suites
– Behavior, types, link with source code is not required
Keep in mind models support an objective
– In this lecture, it is just a high-level view of the design
What is not covered by this lecture:
flows, annexes, multidimensional arrays, virtual
processors/buses, analyses with external tools
109. Suggested readings
1. The SAE Architecture Analysis & Design Language (AADL) Standard.
Peter H. Feiler, January 2008. [Introduction to the language]
2. The Architecture Analysis & Design Language (AADL): An Introduction,
Peter H. Feiler David P. Gluch John J. Hudak, February 2006. [Use this
as reference manual]
3. OSATE plugin:
SEI validation plugins.
SEI. [Analysis in general]
4. Developing AADL Models for Control Systems: A Practitioner’s Guide.
John Hudak Peter Feiler. July 2007. [Flow latency analysis]
110. Links
Tool:
• http://www.aadl.info/aadl/osate/stable/2.0.8/products/
Example projects (other than the ones on Lore):
1. https://github.com/yoogx/AADLib
2. https://github.com/osate/examples
3. http://www.santoslab.org/pub/high-assurance/module-aadl/
slides/AADL-Isolette.pdf