This section 2.2 is a preparation for the discussion on the quality attributes which we want to achieve through design tactics to doing design decisions.
Since tactics play an important role and since we use them in the next sections of chapter 2 as well,
I want to add another question to these two questions here.
And this question is, you should be able to explain what a tactic is about.
So we add it here, just add it here.
Explain how tactics are used in design decisions
and how they have relations to design patterns.
This is why we want to use these tactics as means of design decisions.
What we do so far is to use them to fulfill requirements.
So let's start with these tactics.
We need an empty sheet of paper to start with.
So I give the headline, Achieving design quality attributes through tactics.
There is a collection of primitive design techniques that are used over and over again.
And they can play an important role for architecting.
As I already mentioned, in such a lecture I can't provide you with experience.
However, experience is not the only thing you need to become a successful software architect.
Some things can be given to you through textbooks and even through a lecture.
And this is a structure of reusable knowledge.
And as such a type of reusable knowledge, I want to introduce the tactics to you.
And this is the core takeaway from chapter 2.
Tactics for all the quality attributes we discuss here.
So tactics are a collection of primitive design techniques
that an architect can use to implement quality attributes.
This is something like a definition.
And they play an important role in the design decisions we do.
And they are somehow a way of reusing knowledge.
And this is similar to design patterns, which come to you as something reusable.
And usually it goes this way, you learn one or the second or the third.
And it's hard to imagine how to use them.
Therefore, it's better to use them in practice.
You use them in a project, you find them somewhere, you understand it.
And you make it to your own knowledge.
I have to refresh the screen here.
And regarding the relation between patterns and design and tactics, I would say yes.
A design pattern is more complex than tactics.
And a design pattern represents a bundle of design decisions.
Why do we use these tactics?
These tactics help you to reach your goals.
They are applied by you to achieve quality attributes.
And what we want to do, we want to present them in a systematic way.
And this enables that you can build your own design pattern out of them.
You can just re-bundle them, you can choose the tactics that you need to fulfill your goals.
The architect might select a set of tactics appropriate for the purpose even if there's no design pattern.
So far to the design, what tactics are about, and this should be the answer to this additional question below.
Tactics are used as a means to achieve design decisions to implement quality attributes.
Let's go ahead with the first question. How do they relate to each other?
What we want to achieve is we want to fulfill a quality attribute, a quality requirement, a need of the architect, of the customer.
And we want to fulfill that by design decisions and the quality attribute scenarios that we have explained in the last video are represented by that.
Just to make a new sheet of that, you can continue below.
We have quality attributes, quality requirements, and in the end we want to have it implemented to have the goals fulfilled.
And to specify that further, we would establish a quality attribute scenario.
We describe the quality attribute requirement by this scenario. And then we select a set of appropriate tactics
to reach this goal and this is a design decision. And hopefully the user is satisfied, we achieved our goals in the end.
So far this is an answer to the first question, explain the relation between quality, requirement, quality attribute scenario and design decisions, and we added tactics as the means to fulfill them.
Before we come to the tactics for some of the quality attributes in the next sections, I want to introduce a systematic way to structure them by categories.
I want to categorize design decisions according to seven categories and this will help us, we will use these categories later on again in decision making, in assessing the architecture, this helps us to deal with them in a more systematic way.
So for that we need another new page and then I come to an example to explain it further.
I want to introduce and to explain seven categories of design decisions and these design decisions shall help you to find what is the category I'm looking for and what are the tactics that are appropriate and how to implement this tactic.
Because it's something to reuse and it's something that's abstract, we have to implement this tactic and therefore it helps to know, okay, this is this further type. So I start with the allocation of responsibilities.
Responsibilities, this term stands for requirements. So there's a certain requirement, for example, you have to make sure that something is highly reliable even if there's a faulty environment, then you can make sure this by introducing some tactics and that is what we want to achieve by the design decisions, but you can assign a responsibility to something.
For example, you want to enable offline work, what could we do? You could have a cache of the transmitted data, even if the network transmission is lost, then you could access the data.
In the first video of chapter two, we mentioned that there are some types of requirements and I go back to them here. So functional quality attributes and constraints, we could use them as an example or we characterize them with other terms, but just requirements.
I use the term here, yes, for basic system functions.
And the second are decisions regarding architectural infrastructure, so parts, technologies.
And the third from my list is quality attributes.
These are assigned to runtime elements.
In our case, and consequently non runtime elements.
And, for example, modules, connectors, components, yeah, these are examples for them.
This is what we do through the first category. Second category is a coordination model.
A coordination model is about communication, so there are elements that have to communicate or that must not communicate.
So, therefore, it's about elements must not be coordinated.
So, for coordination for this communication, there's some there's there are properties.
That is, for example, timeliness.
And it might be even concurrency. And, of course, we want completeness correctness consistency.
The mechanisms for coordination.
There are several options that could be stateful stateless.
It could be synchronous asynchronous.
That could be guaranteed delivery and non guaranteed delivery.
So, make a given acknowledgement. This is meant by them.
And more and additional, the point of performance. So that means throughput capacity. Yeah. And this is important for communication.
Why do I use? Oh, sorry for that. Why do I use the term coordination instead of communication? Coordination is much stronger.
Coordination means that you synchronize things or even not that your communication is much a much weaker term.
That's why I use coordination here. Please remember, it's about communication more or less.
Okay, third point is the data model that category.
I think that's rather clear to anybody what is what is meant about. So, this is about data abstractions.
Operations properties.
Of course, we need some metadata to describe which format is there.
Could be readable and could be written better.
Data and organization of the data.
That means is it kept relational in a relational database or in objects or in any other way.
So, the first three and for the next we add a new category number number three. Number four is the management of resources.
Resources are the ones that are necessary, very important for time behavior, for efficiency and
performance. First of all, we have to decide which resources have to be managed and which are the limits.
Which system elements are responsible.
Which are responsible for this management of the resources.
How resources are shared.
And what is the impact if something is exhausted.
Impact of saturation.
This was number number four.
And number five is about mapping between architectural elements.
Mapping means we have some mapping between modules and runtime elements.
The modules are the ones that are the units that you designed that are responsible for some tasks.
For example, there is one server and you have one client as a module. However, there are several clients at runtime.
Next point is runtime elements.
Two processors.
Which processor performs which runtime element.
Regarding data, the data model items to a data store.
So we have to find some data structures, which of them are in this database, which are in this database and units of mapping of modules.
Two elements.
Two units of delivery.
This is about installation, about deployment. So this one is not necessary. However, all these mappings are unidirectional. Therefore, we can make an error out of them.
These mappings, we discussed the views. So most of these views are in the location structures. The location view.
Next point is binding time.
What does binding time mean?
Binding time is about variability. You have several options and you decide for one of them.
And the point of time when you decide is an important decision. For example, you could decide at development time that you do it this way, that you use this technology.
However, under some conditions, it's important to defer this decision to keep it open for a later point of time so that you can, for example, use it at startup time or even at runtime.
Usually, for example, plugin structures are used for later binding times.
This is about making decisions. Let's write it this way.
Among several variants.
This is binding time and examples for them are you could have a build script.
We could do this during design time. So the designer decides I use this technology.
You could do this during the implementation time. The developer decides, OK, I use parameters in this way.
Or better, it's more precise if we use coding time when we define the source code.
It could be during delivery deployment time.
It could be during startup.
Or even at runtime. These are the options and the last category I mentioned that there are seven last category is choice of technology.
We have to decide there's plenty of technologies usually available for some reason, for some purpose.
And we have to adjust this. We have to find fitting configurations. We have to find things fitting to each other.
Of course, it's always about the technology that is to be used.
And we have to consider what are the characteristics that we want to achieve.
And especially the quality goals, the quality attributes. This is the first point.
Then we want to and this is usually a whole bunch of technology people use the term technology step.
Furthermore, we have to decide about tools for support.
And we need we need some some not only tools for support, we need services for support.
Support could either be from inside the company from experts or from the provider.
We make it have to make the decision, OK, we need a support contract for this and this product to to repair things in time to ensure availability, for example.
Furthermore, we have to consider that there might be side effects.
Side effects could be a rather negative impact on some things or positive points or just constraint.
By deciding about the technology, we have new new constraints or we have a certain coordination model, how things have to operate or we it's we have some familiar to familiarity with some technologies.
And yeah. And I would add here compatibility.
OK, so far, the seven categories and we will come back to them in some points of the lecture.
And these technologies, these categories help us not to forget one of them. And furthermore, all the tactics relate to one or even more of these categories.
The categories help us to do to do this decision making in a structured way. Therefore, please be aware that there are these categories.
You should know them. You should not forget them and you will find them again in the additional material from the book.
There are example design and design decisions and tactics and they are structured in this way.
So this was the video for part two. Thank you so far.