With this very short video I want to discuss the differences between ADD 3.0 and with the ADD 2 that is discussed in the material that we have in our book.
I do this especially because we don't have an extended material on ADD yet.
There will be the book by Kasman and Cervantes. However, it's not yet available today.
So I use these slides by Kasman and Cervantes to discuss these differences. It's very short as I mentioned it.
So you find these slides in the Moodle for this week.
Let's immediately start with what ADD is about.
ADD is one of the architectural design methods and there are some others as well.
For example, the Microsoft Method Rational Unified Process and ADD is one of them.
So the development method usually covers the whole architectural life cycle and it's rather general, therefore a few details.
It has to be general, it has to be abstract to serve the purpose of all projects, to support all kinds of projects which need software architecture.
Most of them start with architectural drivers, then there's an architectural design methodology and then we need architectural documentation and then we need architectural evaluation.
This is what we mean by the whole architectural life cycle.
We will now care about the steps and show the differences between the four steps in the book and the seven steps that we have here.
At first, this slide you have already seen in the lecture, so I go through it just telling you what is important.
ADD is a design method where there's an important focus on quality attributes, on quality goals.
This is necessary because the quality goals play a special role for the basic decisions.
Many of the very basic decisions are driven by quality needs and these decisions are basic ones because they are made first and all the other, the later decisions are based on them.
So it will be very hard to change them later.
Maybe some of you already know this from other effects.
So for example, if you need security, it's very hard to introduce security later after a project, even with such simple things like correctness in terms of functionality.
It's hard to do testing after you care less about functionality, about correctness or performance.
If you want to introduce performance later as a goal, you should have chosen a different platform, a different technology, a different architectural style to have more, for example, scalability or more resource scheduling.
ADD is a method driven by quality attributes, putting a focus on that, and it was released in 2006.
It's iterative, so it fits well to the current usual agile design methodologies, such as SCRUM or extreme programming.
It provides some steps for architectural design.
These slides tell us details. I doubt a little bit because they have to be general.
They have to be general to fit for all the projects we do.
And we try in this lecture, we try to give you some more examples to make it more accessible to you, to make comprehension easier.
What we want, that's true for all the design methods, we want to have some prediction, we want to have some prognosis, what to expect in the end, especially in terms of quality attributes.
So we want to find out, we want to determine, we want to control which quality, for example, in terms of performance efficiency, will be the outcome at the end of the project, even if we do decisions on the beginning, in the beginning phase.
So far, ADD has been developed long ago, and there have been a lot of experiences with that, and some limitations turned out.
As you know, this is quite natural for everything.
Let's discuss these limitations, and then it's easier to understand what is the difference between the previous ADD 2.0, which we have in the book.
One of the limitations is that quality attributes and some functional requirements have been considered.
So we need something more. We need design objectives and architectural concerns.
Design objectives mean we have some goals that we want to provide as design principles.
So design principles should be allowed for the first place.
And architectural concerns, that means we have some special topics that have to be considered in our project, in our company, or for a certain reference model.
For example, there could be a certain message structure, or we want to have a service-oriented architecture, because the neighboring system has a service-oriented architecture as well.
Next point, decomposition. In step two of ADD, we have one element that is decomposed in the next iteration.
Sometimes it happens that a couple of elements, a bunch of elements, has to be decomposed.
So several layers in one step have to be decomposed in one step.
So if you take it seriously, what is written in ADD 2.0, you are not allowed to take three layers and cut them according to domain functionality,
to a new service, for example, which demands for three layers as well.
We will have an example later.
And the sequence in step three is we decompose an element, and the drivers have not yet been considered.
However, in some cases, or many cases, the drivers are the ones that decide about how the iteration performs or what is the structure of decomposition.
So drivers have to be addressed before.
Next point, at step four, it turned out that tactics and patterns are not the only things we need.
We need more such as frameworks, reference architectures that could play an important role as well.
So it's extended what we use as reusable architectural elements.
And the last point, we need some more documentation.
It turned out, especially together with agile methodologies, that it's not enough to have documentation after.
Initial documentation is very important to write it up, to have it in written form, somehow with graphics or with text,
to have these spaces for revising decisions, to improving decisions in the next step, to reconsidering decisions,
just to keep the things when we develop, we go further.
Even if it's limited, however, we have to document our decisions.
Okay, having said this, it comes out that we have these seven steps, plus step nine, refinement, if necessary,
these seven steps here, as you have noticed in the lecture.
So the next slides in this slide set have already been discussed in the video for the lecture.
Therefore, I skip them and go further until the next section here and in this slide set.
So we continue with number 28.
So if you want to use the slide set for download, then feel free.
And we want to discuss the details of these differences of ADD 3.0.
Let's at first discuss design decisions.
We use this term quite frequently, and it's important to discuss the different types of decisions.
This was already on one of the slides regarding the steps.
We have different decisions.
One is about the elements that have to be decomposed.
The next one is about the things we use as elements for a solution.
So we decide about design concepts that can be used for solving problems, for setting the inputs within an iteration.
And then we need further design decisions to fill them with details, to instantiate them, to implement them, for example,
and to allocate responsibility to define interfaces to do everything that is necessary to make it a complete design.
So especially this selection of a process of elements to be used can be a challenge because you have to look for everything.
You have to consider a lot of things.
We discussed the toolbox as one of the points we did, and the seminar groups 2, 3 and 4 discussed searching the web as an issue in the last week.
So we do this, we consider this a little bit further.
These design concepts, things we can reuse, can be of a broad variety.
Several concepts are there, starting with very abstract ones, some things like reference architectures or deployment patterns, architectural design patterns, tactics, or externally developed third-party components, such as frameworks like products that are developed professionally.
So we want to find solutions for parts of the problems, which are called subproblems here.
We do this in iterative ways, so we care about one of the elements that have been chosen, and we want to reuse existing solutions.
We don't want to build things new that's engineering, we reuse things that have been proven successful.
And this is not only better and not only faster, but both of it.
And especially if we are not experts in the field, it's a good idea to benefit from things that have been proven their value for experts.
And we need our creativity just to identify, which means finding, to adapting, to adjusting things according to our needs, and to combine them.
All of them are very demanding, we need creativity to imagine what can happen, what can be valuable.
Another point, let's go through the details that have been mentioned.
There we already had a slide on reference architecture, but however it's valuable to do this once more.
A reference architecture is a blueprint, a blueprint usually that is typical for an application domain.
Examples are mobile applications or rich clients, rich internet applications, service applications, web applications.
However, there are some examples from certain domains, for example from the insurance domain, or from workflow domains.
Usually here there's an example for that, and there's a guidebook as an example for that.
Next point in our list was deployment patterns.
Deployment becomes more and more important when we want to move things into production quickly.
So while we have registered or achieved a good speed up in development, through agile development, through scrum and so far,
it's still the time and the number of steps bringing things into production, to a real environment, to be used by the customers.
It's still very long, therefore we need this acceleration for deployment, this continuous development.
And therefore we need some deployment patterns.
We had deployment as an additional quality attribute, deployability as an additional quality attribute in this lecture.
Tactics that have already been discussed for several purposes, for several quality attributes and design patterns, architectural patterns have already been discussed as well.
So there are problems, solutions to recurring problems and there are many catalogues.
However, design and architectural patterns, there are some weak boundaries between them.
So therefore it's somehow, for example, the layer pattern can be a design pattern on the smaller scope and an architectural pattern with having a wider scope.
And last but not least, we should not forget externally developed components as they are called in this slide set.
In our lecture we frequently call them technologies.
So technologies are commercial products, most of them are commercial projects, some of them are open source products.
They are reusable software that can be reused as they are, they are executable.
So they are somehow generic, they serve different purposes, address recurring problems as well.
So therefore these are examples for things that can be reused and they have been on this slide here as design concepts that can be used in making decisions.
However, let's continue with this decision about the design concepts on slide 35 of this slide set.
And we always start from the goal. We operate in a goal-driven way.
So there's an iteration goal and we want a design concept that satisfies all the requirements.
And for this we try to find candidates that could be a solution for that.
And then we select one out of them with the best properties.
This is what you usually do. You check everything that could play a role, make a long list of candidates and then strike out step by step.
Firstly, the ones that do not fulfill the constraints, later the ones that have a lower quality, do not completely fulfill, satisfy the quality goals.
So this helps us to find out design concepts that fulfill the goals here.
And this is somehow driven or could be driven by a roadmap as we do it for some domains.
This slide shows how we would develop for a Greenfield system, a system that means a system where there's no predecessor, there's no legacy.
It is built from scratch without having something before.
And in a domain that is very mature, where everything is clear how the domain structure is, this axis is the time axis.
And we would start selecting reference architecture for that domain.
A mature domain means, okay, we already know the structure, therefore we know we have some, hopefully we have some reference architectures that help us.
And together with possibly deployment patterns, and hopefully with some components that are already available, we define the structure of the system.
So this is the first set of design decisions.
On the next step, we would care about primary functionality.
This primary functionality can be solved, of course, by functional components.
However, by the help of architectural patterns that support domain objects or domain components.
For example, you have a customer object and it has several states for the customer.
Or for flight reservation, there is a system with states for the reservation building and the fulfillment.
And after setting up those decisions, we would have a next level in next iterations.
We would decide about the quality attributes and scenarios of the other quality, attribute quality concerns that have a slightly lower priority.
We decide about tactics, patterns, deployments, patterns, and so on so far.
So far we finished this small edition about ADD 3.0.
And thanks to Kasman and Cervantes for their slides.
Thanking you for your attention.