At first I want to introduce some types of measures of analysis to you.
We want to deal, before that we have to correct this mistake, it's actually 2.10.
So what we want to do is, at first, seeking the answer for this first question, I want
to introduce four different types of analysis to you that can be performed on an architecture.
An architecture is just boxes and lines, there's nothing runnable.
So for example performance could be measured if something is executable there.
However at the point in the early stage of an architecture of a system where we just
work on the architecture, we do the basic decisions, we do not have many things that are executable.
Therefore we have to seek for other things.
This slide gives us an overview over the things that I want to explain to you.
And of course it's already shown here how much tool support can be expected.
However I want to introduce the things a little bit in more detail.
We need a new page for that.
And this is a blank sheet white.
Okay, and let's start with these checklists.
What I want to mention here as something that can be used for analysis is that we want to check if there's something wrong.
That can be done always, even at the early stage when we just have an architecture and nothing executable.
And such checklists check not only if the requirements are recorded.
So we want to measure them. We want to have them with with a more precision and you already know.
Okay, there are these these quality attribute scenarios where we can have a measure for that.
So this is one point and other points.
Are there typical mistakes?
And do the the measures the tactics fulfill satisfy the quality goals?
However and of course we have to do it in more detail for one of the actual quality attributes.
For example for quality in terms of performance we have to check for bottlenecks.
We have to check for enough resource management for the rate of the events.
All the tactics that we already discussed.
And I have shown you the design decision checklists that have been given with the textbook by the authors.
And if we check these, if we have a look at these checklists, you get an impression.
What do I mean by checklist?
And this checklist gives us an example. What is mentioned? What should we expect as a checklist?
So we have here some questions for the different types of quality of design decisions.
A location of responsibilities, coordination model, data model and especially on resource management.
So so far this isn't just an example. These checklists can be applied
if humans audit, use humans assess the design and the design decisions.
And the checklist helps us with that.
So we we don't have just a checklist for the software system itself but for the process as well.
Did we do the right analysis? Did we check for good solutions that are available?
Did we have good measures for that? Next point here, the next box is thought experiments.
Thought experiments are things that are just done in your imagination.
So we try to what would happen. We imagine what would happen with our system.
And this can as well be done with just having boxes and lines and nothing executable yet.
So a thought experiment is something that we do mentally or just verbally or verbally.
Working through a particular scenario.
In the case of performance as a quality attribute, this scenario could be
some cases where some examples when a high number of requests arrive
and a high number of events have to be processed or if there's a shortage of resources.
And we just go through the scenario to check what is happening,
what would be the result or what are the hindering aspects.
So this is usually done by the architect for checking alternatives, for checking,
evaluating the current design.
To check design or to explore alternatives.
And we would go through this scenario step by step and examine what happens.
So far, we could then find problems and we would just record the problems
and try to find solutions later.
So far, the thought experiment. The next point, and this is as well done by humans
and it's done verbally or mentally. So we don't need many tools for that. Yeah, a sheet of paper
would be helpful. Or if we have a more complex setting, we could use models or we could use
some visual representation of our design. The next box here has
quite a funny name back of the envelope analysis,
meaning that we have really a small sheet of paper to perform this analysis.
So the name was back of the
envelope analysis. And this is just a rough analysis
with low effort. Low effort is invested to think over some concepts about problems,
to find out more and making some notes to just to find out what might be problems.
Because there's low effort invested, we could call that a lightweight
way of analyzing things. So we would just do a deeper analysis if it's needed.
No lightweight is written this way.
Deeper analysis only when necessary.
Here again, just the human expert does it
without or without many tools or tool support.
Without much tools or even totally without tool support. Okay, so far there are
measures that can be done by humans only. And now we come to another, I just mentioned here
a group of them, because they are just mentally, I don't have a name for them.
The first two checklists have a name, however, they are just a group. And now let's come to
things that are performed with some tool support. We need a new page for that.
So the group was experiments,
simulations and prototypes.
And they cover tools that help us to perform analysis.
For example, if we want to perform some heavy scenario with heavy traffic,
then there could be a request generator or just an event generator.
Or another example could be a monitor performing or recording what happens.
Or a prototype evaluating several alternatives.
And in this way, we could do different things to perform things, to measure what happens
in small parts of the system to find out what is the reality. So this is much more,
the results make us much more confident than just having a thought experiment.
However, they demand for a higher effort.
Of course, the confidence differs. The deeper we go with our analysis,
for example, with the prototype, if we have a more comprehensive prototype,
we get more confidence. If we just have a small part of the system tiny, for example,
for some storage scenario or for storing persistent data just in one dataset or in one
just in a file instead of the real database, then we are not that confident about the result.
If we get some good figures, that could be good or not. So at least we have more information
than just a prototype. So this group is more or less demand for effort.
And we would do it only at points where we need more confidence, where the risk is higher
or where we have more thorough requirements. Let's come to the analysis models.
However, this will be the next video.