In the next video I want to explain the steps of attribute-driven design, the method ADD.
That's the design method we want to use and that is described in our textbook.
However, if you would please go to the schedule, here please notice there's an update of the schedule.
And if you go through the schedule, you will notice that there is, in this part, you will notice, okay, there is chapter 7 of the book.
However, if you check the textbook, there's apparently nothing.
So it's very abstract and therefore there's the digestion to use the extra literature.
And there are two papers by Wojciech and Woot in 2006 and 2007.
However, we can see it on the slide more. Let's switch back to the slides.
Yes, it's written here where we have this two more illustrative papers.
This one by Wojciech in 2006 and by Woot in 2007.
They explain the method in a better way with more examples, with more explanations, with less abstract.
However, this is for ADD 2 and there's an update to ADD 3. However, we just have the slides for that.
So I will explain it in the next video.
What is the difference? There is only a slight number of, a slow number of difference. However, they have seven steps.
So with this video, where I want to go through these seven steps, explain them briefly.
Don't be, be, Angel. Yeah.
Yeah, don't be afraid because it's so abstract. We will have details with the next video.
So at first, let's start with the fact, we go to the slides showing the overview over the steps.
And these slides actually are from the presentation of the tutorial of Cervantes and Kasman in, from the Saturn conference.
And the slides are available in the additional material.
So we have the, as already mentioned, they propose, they call it ADD 3.0 and have seven steps for that.
In the, in the core, it's the same. However, some revisions.
The first revision is that we have some, that we have an overview over the input first.
Let's go to this first slide, to the first slide for that. Before starting, we have to make sure that all the inputs are known, that they are clear enough, that we have enough details.
So what we see here is what we already know, the architecture specific requirements described by scenarios.
Furthermore, we have the constraints and some primary functional requirements. They are important because they determine the architecture as well.
Furthermore, the purpose for the whole design and the architectural concerns that determine the outcome, the first decision, the sequence of the decisions as well.
So with the next step, we decide where to start and in which order we have to proceed.
We start by selecting which drivers are the most important ones, have the biggest impact.
And as you already, hopefully you remember, it is, this is described in the utility tree.
In the utility tree, we have these two priorities. Hopefully you remember that the first priority was the priority for the impact on the business.
And the second one was the impact on the architecture. So both are they valuable for the customer and are they valuable for the work of the architects?
The highest priority architecture specific requirements have to be discussed first, have to be the most important drivers.
And then by this priority, we decide where to start, which is the first point. However, we have to do this, we have to cut the whole problem down.
We have to split the whole system up. The whole requirements have to be split up into sub parts.
So the whole system with the whole function divided into into several sub functions and these sub functions are then discussed.
Do they go in breadth or in depth first?
So this is divided and then we just start with some of the, with one of the sub problems.
Okay, the next three steps are about the real design decisions.
So we do, we choose one element to start with it and we try to do to find a solution for that or we refine it further.
And then we decide about the solution. The solution is here called choose a design concept that satisfied the drivers.
The drivers have been selected here, though this is the most important one. Let's assume security is very important for our system.
So we do a security system, a decision on the security architecture, security principles at first.
Hopefully we have a quality attribute scenario describing what are the most important security concerns.
And then we decide which are the, yes, and this is the driver.
And then we have some parts that are essential for security.
For example, they have the most valuable data or they hide the protected part of that or they represent the part of the system that has to be protected.
Some especially important services are similar.
And then we decide which are the design concepts for that.
And then it's called instantiate. So do you remember the design?
Most of the design concepts are somehow abstract. They have to be implemented, added details have to be added.
So if you just have a design pattern, it's just boxes and lines. You have to build something more, something executable out of it.
So define classes for it. Define interfaces. Define in which way messages are transferred.
So this is meant by instantiate. Allocate responsibilities. What does that mean?
Allocation of responsibilities. This is requirements are mapped to this block.
Let's make a note on it. So here.
So requirements are mapped to some architectural elements.
And this is what we call allocation of responsibilities.
And this is done by three typical types of design decisions.
The first, of course, we need this decomposition. We decide which one to decompose.
This is the one of step three. Then we identify and select what can be used here.
This is, for example, something from the toolbox. So the toolbox plays a role here.
And then we do this, what I just mentioned, allocation of responsibilities.
We develop elements that become part of the solution.
Okay. And after this is done, we go to the next step.
We record everything. We record the design decision we have taken.
We write down what is the resulting architecture. What are the additions, the added elements, the added details to the boxes and lines in the views, in the architectural views.
This will be our next chapter, by the way, how to describe an architecture.
And this is what some people call a blueprint, the plan for the architecture, the actual design.
And it's not complete in this step. However, we have to write down what is the essential.
What is the real decision? What is the interface, for example, or what is the security architecture in
So in the end, we check, yeah, we do it, we act, and then we check, do, act, check.
This is what usually people, humans do in an iteration. We check if everything is fulfilled and if it's fine.
And if not, it becomes part of the next cycle. And if yes, we could go deeper or to the next element or so far.
Yeah, they are analyzed. Do they really lead to an advantage, to an advance? And what are the next steps?
Hopefully, the architectural design has been enhanced. It's refined by some way or extended and we can go for the next iteration.
And now the good question is, what is, yeah, okay, it's just part of it. And the next slides show in which way the decision on the next iteration could be performed.
It could be performed in breadth or in depth, or both, or combinations of that.
In this example comes from the book. They have, at some point, the architects decide for service-oriented architecture.
And this is what are the parts of the service-oriented architecture, the components. Of course, you need an architecture for each of them.
And you have to start with someone. And they decided, because of the basic decisions, the decisions with a big impact on the rest of the architect, they decided to do the infrastructure first.
For example, because there are technology decisions involved. You need to buy a product.
And if you decide for this product, for this middleware, or for this service broker, whatever, you make a very basic decision that has an impact on all the other things.
Therefore, these architects, in this example, decided on the infrastructure components first.
And then this might be with this sequence. What are the selected drivers? Okay, what is it to be refined?
And the design concept in this case was service-oriented architecture. And then they decided, okay, on the microservice, on the infrastructure, and recorded it somehow.
And now we are on the point what to do next. And what to do next could be any of the other services. Or it could be, yes, we refine that further.
And in this case, it could be refine another component or the infrastructure. And they decided, yes, let's do the infrastructure first.
Because this enterprise service bus has all the decisions about the details of the interface have a big impact on each of the services.
And we have to know how the enterprise service bus works, how the registry, how the broker works in detail before that we can make good decisions on the actual services.
Okay, so far, it will be the next iteration. Let's go to the first one here. And the next iteration starts with some decisions that are already made.
So some decisions are made, for example, some technology decisions. And then it goes the same way, the same sequence of things.
We decide, okay, what are the next important driver? Security again, or another thing, or whatever. And then what are the elements to be cared, to be taken care of in this next iteration?
You know this iteration from Scrum, I'm sure. So it's very similar and it's good fitting to the agile methodologies where we have iterations over and over again.
Okay, so far, you find these slides, actually, these ones in the presentation of Chavantes and Kasman from 2015, together with some explanations about the differences, there are only a few differences between ADT2 and ADT3.
So it's not that much with some examples, with at least one example. And here, in our lecture, the next video will be on an example. Thank you.