Week2 ATAM and views

[junsoopark]

[ATAM] Hello.
This is the first video of Week two in the previous week.
We talked about several quality attributes such as performance, availability,
modifiability and security for each quality attribute. We talked about different tactics.
And last week we also discussed how can we describe quality attribute requirements as
quality attributes scenarios.
And we mentioned that the quality attribute requirements are essential to drive design
decisions.
So in this first video, of week two, we'll talk about ATAM.
[Architecture evaluation]
ATAM is a method for architecture evaluation.
So in general,the goal of architecture evaluation techniques is to assess to what degree
the architecture is fit for the purpose for which it is intended.
The output of the architecture evaluation is the identification of risks.
We will look at the software architecture and the output is not to fix the architecture. If he has problems, is to identify potential problems.
That means the risk of the architecture not being able to address the quality attribute
requirements.
So that is the question down below that we're trying to answer with an architecture
evaluation.
And of course, we want the architecture evaluation effort to be lean, to be unexpensive,
agile.
You cannot be more expensive than the value it provides.
Well, we should remember that this is a quote from Brian Foote in the big ball of mud
paper.
We should remember that if you think good architecture is expensive, try bad
architecture.

[The ATAM*] So.
ATAM means architecture, trade off analysis method.
And it's a technique, a method to evaluate architectures.
And it was created by the SEI in the late 90s and has been used since by people at the
SEI and all around the world.
Documentation for the method descriptions of the method are publicly available on the
internet.
It's also described in different books, including our textbook software, architecture and
practice.
So we use ATAM to evaluate the consequences of design decisions, understanding the
quality, attribute requirements and business goals.
So in this lecture.
I'm going to go over a basic explanation of the ATAM method, if you are going to apply it
in full well, contact me for more details about the method.
And we also have in the reading assignment the section in the book the software
architecture and Practice Book that describes the method.
In the slides I'm going to use in this video are.
To the most part, the same slides that the SEI uses when people at the SEI are presenting
theATAM method to a team that has an architecture that is going to be evaluated.

[Purpose of the ATAM (1)]
So purpose of the ATAM, it helps stakeholders to ask the right questions to discover
potentially problematic architectural decisions.
Later on, this is past the ATAM risks that were discovered can be the focus of mitigation
activities.
For example, you can do further design start, a technical experiment, a prototype trying
to address the potential issues, the risks. We don't fix.
We don't do all of that.
During the ATAM, the ATAM may point out a risk fixing or mitigating the risk is something
that happens after the ATAM.
The trade offs will be explicitly identified and documented as part of the method.

[Purpose of the ATAM (1)]
And look, the purpose of the ATAM is not to provide precise analysis, ATAM is to it to
some extent a subjective evaluation. It's not a mathematical evaluation.
We want to.
Illicit risks based on existing architectural decisions, not to say, for example,this
architecture will fall short of the performance requirement X by 10 milliseconds. No, it's not like so objective.
It's more subjective, pointing out potential problems.
So we find we try to find trends which are correlations between architectural decisions
and how these decisions affect system properties or qualities.

[ATAM Benefits] But look.
The benefits of the ATAM go beyond the identified risks, we clarify quality attribute
requirements.
If you remember our discussion in week one,we said that often times teams focus on
functional requirements and overlook quality attribute requirements.
If that is the case and you do an ATAM,the ATAM will create the need to describe the
quality attributes requirements, which is a side kind of benefit.
It also improves the architectural documentation because the technique during the
method,we will look at different architecture artifacts and you need to understand it. So if the documentation is not clear enough, the evaluation team will point out how to
improve the architectural documentation itself.
And we'll produce documented basis for architectural decisions, so architecture decisions
will be more well informed.
And one thing that is also a side benefit, there is increased communication among various
stakeholders.
So at the end, of course, the end result is an improved architecture.

[ATAM phases]
So the ATAM method has four phases. Zero, one, two and three.
Phase zero is offline, basically, the software team will interact with the evaluation team or at least one person thatIs part of the evaluation crew, and we'll exchange emails, etc.
And that may take a while, a few weeks.
So that's phase zero to establish partnership and prepare for the actual evaluation.
The actual evaluation consists of phases one and two, these two phases have nine steps
that we're going to cover in a minute.
In each phase takes one or two days, and there is an interval of one or two weeks between
them.
And well, at least in the old days before COVID, phasesone and two would take place at
the customer site so people would be physically together and discuss the architecture
and evaluate the architecture.
Phase three is follow up also of typically offline exchanging emails or maybe having a
phone or Zoom call.
So let's go over all these phases in detail.

[ATAM Phase 0]
Phase zero, again, this precedes the actual architecture evaluation, and then there is
this interaction between the customer.
I mean, this is the customer would be the someone responsible for the software project
oftentimes is thelead architect that will interact with the evaluation team or one person in the evaluation team,and they will exchange information about the method itself.
How it works.
What do we need? Who should participate?And then come to an agreement, OK, let's do this and then you move on to phases one and two.
One thing that happens that's not mentioned here is the evaluation team.
Hmm, excuse me, asks for, um, the the existing architecture documentation.
At that point, there is a go no go decision because sometimes the customer will ask for
an evaluation,but there's no architecture yet because the whole project is still in its
initial steps.
So when there is no architecture yet, the then we can not perform the ATAM. And in that case, it's a no go decision.
There are other techniques that we can use.
For example, the quality attribute workshop, but the AATAM requires some understanding of
the architecture.
Of course, it's not the final architecture, it's not the complete architecture,but the
the key design decisions should be in place and should be reasonably documentedso that
we have something to look at when we are evaluating the architecture.
So if there is some understanding of the architecture and the customer, meaning the team
project.
The people responsible for the project and the evaluation team come to an agreement. We move on to phase one.
Here we will gather the evaluation team in the software project team.

[ATAM Phase 1]
In most of the people are technically oriented, so the phase one is architecture
centric.
We will focus on finding out what architecture information we have and analyze itbased on
some requirements that we list in the shape of quality attributes and areas.
And this is a top down analysis looking at quality attributes in high level architecture
design decisions.

[The 9 steps of the ATAM]
So phases one and two.
Consist of nine steps, the famous ATAM nine steps, and they are broken down into one
through six in phase one, seven eight and nine in phase two. Let's go over each step.
We're covering the first six steps, which are part of phase one.
So this is terminology, this part of the ATAM method, description phases and inside each
phase you have steps.

[Step 1: Present the ATAM]
So step one, remember, at this point, we have the evaluation team on site or these days
in a Zoom call, and they're they're gathered for the day. OK, remember phase one takes a whole day.
Sometimes it spills into a second day.
But we have the project team and the evaluation team.
They get together and in step one, someone from the evaluation team. Typically, the team evaluation team leader will present the ATAM method itself. And there is.
This is a 30 minute presentation very similar to this presentation that I am recording
here in the shape of a lecture. OK.
Just describing the technique covering utility tree generation. What we do.
Scenario brainstorming, describing what is a scenario, what, what, what our risks, trade
offs, et cetera.
So in mentioning the outputs of the ATAM.
So this is a kind of canned presentation.
That you're just repeating every time you do The ATAM describing the method, then we mo
on to step two.
v

[Step 2: Present the business goals]
Someone from the project team gives a presentation.
That person is typically someone with.
Business focus, like the product owner, a business analyst, a domain expert.
That person will describe the business context of the system, will mention the high level
functional requirements.
It's an overview of the system what it does and will mention high level quality attribute
requirements,saying security is very important because of this and that performance is
very important because of this and that cost, etc. So this is also a brief presentation.
Then we move on to step three here.

[Step 3: Present architecture]
Someone more on the technical side and less on the business side will give a presentation
of the architecture.
So sometimes there is an architect or the lead technical lead.
It doesn't matter what role that person plays,but there's some that is someone who
understands the existing architecture and that person will give an overview of the
architecture.
We'll talk about the technical constraints.
Um.
We'll talk about the runtime environment, the runtime, infrastructure, hardware,
middleware,etc.
the implementation frameworks languages will describe the system using different perspectives.
So you may think where, but how does that person know what to say in the preparation phase?Phase zero the evaluation team already gives basically like a recipe of what they should see in the architectural presentation.
OK.
And that person will go over the architectural approaches in the existing solution in how they can address quality attribute requirements.
At that point, this is somewhat interactive.
The evaluation team begins probing the architecture and.
Trying to identify risks.
So step four, this is where.

[Step 4: Identify architectural approaches]
Good part of the architecture evaluation risk elicitation starts, so this is when there
is a discussion. That goes like this.
We go over the architecture not to understand the parts that take care of each
functional requirement.
We go over the architecture to understand the major architectural approaches.
And when we say architectural approach in this context, it can be the use of a tactic, a
design pattern, an architecture pattern, some design strategy. So the evaluation team is not familiar with the business domain. Necessarily.
And they're not familiar with the implementation details.
Sometimes the evaluation team doesn't understand, for example, the I mean is not familiar
with, the programing language being used,but they understand design patterns, tactics, etc.
So in step four,we go over the architecture and the evaluation team will try to identify these tactics.
So they will say, Oh, it looks like you're organizing the code in layers.
Oh, it looks like you're using data replication here.
What is the mechanism for synchronization? Oh, you have a batch program that does
extract, transform and load.
So you have, um, event driven communication.
So you're using a message queue, this message queueIs it um, is there redundancy? Is
there partitioning?And you can ask, OK, so there is this sensor.
How do you know the sensor is alive?Is there a ping echo mechanism? So we we bring the vocabulary of tactics and patterns to the discussion so that even if the architect,the development team is not familiar with these terms,these tactics and patterns, the evaluation team will try to identify the use of tactics and patterns, and they build
that terminology.
OK.
And why would we do that? Because we know that given certain tactics and patterns contribute to achieve specific qualities.
So if we we know you're using Ping Echo, we know you will be able to identify availability issues timely.

And these are places where we have these architectural approaches, are key to realize the quality attribute goals.

[Step 5: Generate quality attribute utility tree] In step five.
We discuss the requirements more specifically the quality attribute requirements of the
system.
And per the ATAM method, we do that building a utility tree,which is this top down list
of quality attributes and areas of quality requirements, let's say.
OK, so the top level?Well, there's the root of the tree and then the high level nodes are
the quality attributes, performance, modify ability, security, et cetera.
And we may have multiple levels, but the leaves of the tree are quality attributes
scenarios.
So part of phase one, we go over an explanation of what is a quality attribute scenario
that takes place in step one.
So at this moment, the evaluation team will help the customer, the technical team,to
describe quality attribute requirements in the shape of scenarios with the different
parts.
And we will put them together in a tree utility tree, and we will prioritize these
quality attributes scenarios. Now.
I'm not going.
I'm not going to go over the description of a key scenario because we covered that in week one.
And there's this note that says that when we come to this step where we want to enlist the quality attributes scenarios, the evaluation team.
Doesn't simply say, tell me, what are the scenarios?What, tell me what is a performance quality attributes an area that you may have in the system.
So, um, people on the customer side, they're not familiar with quality attributes scenarios, usually.
One way to stimulate the discussion to start a discussion is to use what we call general scenarios.
And there are multiple general scenarios for different quality attributes.
In fact, if you search the software architecture in practice book,you'll see that for
each chapter where we have the quality attribute, there is a description of general
scenarios. So.

The evaluation team comes prepared with some general scenarios that work as seeds for
the discussion. Okay.
Here's a simple example of a utility tree.

[Utility tree]
And you see this one has performance, modify ability, availability, security. There's this next level.
For example, performance can be subdivided into data latency and transaction throughput
for this particular system.
And then the leaves of the tree are the scenarios.
Look, in this slide, this is a simplified version of a utility tree in practice. The utility tree is recorded in a document, a text document in a table. OK.
Yeah, it's not practical to try to draw it as a tree. Like this? OK.
Oh, and you see in blue, this is the prioritization of each scenario. And he has two dimensions.
First one is the technical difficulty of realizing or addressing that requirement. Which maps to how difficult means how risky it is in the second dimension is the
importance of that scenario for the business.
Sometimes addressing a given requirement is very, very difficult. But it's not that relevant for the business.
So we may not ever achieve that requirement.
And we use a high, medium, low scale here.
And another comment is that when we are creating the utility tree,we'll have a document
that everybody's seen and we record recording the the scenarios. There's someone in the evaluation team taking notes.
And.
We will check that the scenarios haveThe six parts.
Simply, it can be a little simpler, we want to identify the stimulus, the environment,
and we want to see a testable slash measurable response.
And of course, as we mentioned in week one, the classification here is less relevant than
understanding the scenario and understanding its priority.
So if during this discussion, someone says, well, this an that you have under usability
is actually a performance scenario. There's no problem we can move it around.
The important thing is that, that scenario is there.
Is there somewhere in this division in quality attributes?It's just something that we do

to simplify.
Walking through all of the scenarios.

[Step 6: Analyze architectural approaches]
And we get to step six here.
We analyze the architecture by probing.
The architectural approaches vis-a-vis the quality attribute requirements. So we go over the utility tree.
We pick the highest priority scenarios and we basically go back and ask.
How does the architecture address this scenario?We go one by one scenario by scenario. And then typically, the architect will bring back the architecture and describe what
architectural approaches are used to address each scenario.
So maybe for a performance scenario, the architect will say, Well, we introduce
concurrency here, so we have parallel processing, so that's a tactic. And.
In this discussion, we identify. Risks, no risks.
Sensitivity points and trade offs.
So this probing of the architecture, uh, happens by asking. Quality attributes, specific questions.
And what is that?

[Quality attribute questions]
Well, we will ask questions that.
Relate the requirements with the design decisions, so if you have a performance
requirement,you can ask, for example, how many instances of Service X should exist at
peak load.
Given that we understand that the system will get that many requests at peak load because
there is a scenario for that.
What are the message arrival rates? So you have a device that is receiving messages from
sensors or actuators,so you can ask that question and then discuss how the architecture
takes care can handle that message arrival rate.
For modifiability, you may have scenarios for modifiability anticipating changes.
So you may think, Oh, this this device should have installed apps, should have plug ins,
may require online updates,so you may ask questions related to code organization in layers and anticipating how can you make specific changes,maybe to add a plug in to change an API, etc.
? And the evaluation team is taking note of these things risks, non risks, etc.

[Risk, non-risk, sensitivity point, tradeoff point]
A risk is what the name says, a potential problem in this context. The potential problem might be an architecture decision.
A non risk is an architecture decision that we looked back and forth, and it is
positive.
So it is helping to achieve a given quality with no negative effects that are visible.
A sensitive point is some property of a component of a configuration that is critical for
achieving a particular quality attribute scenario response.
So maybe, for example, if you have concurrency, you doing parallel processing?The number
of instances of the processing that you have at the same time is a sensitive,
sensitivity point.
If you're doing encryption.
And encryption is necessary for privacy, but you're concerned with the performance
overhead.
The choice of the algorithms, the choice of number of bits for the encryption key. That's a sensitivity point.
OK.
And the last item there is a trade off point.
So this is a property that was a decision that affects two or more quality attributes. And you know, you gaining with respect to one quality, but you losing with respect to
another quality.
Next slide has some better examples.
So here's an example of a risk.

[Examples]
Rules for defining the functional scope of business logic in modules of the domain layer
are not clear.
This issue may result in replication of functionality, thereby compromising
modifiability, so I don't know,maybe during the architecture description, the the architect presented a design diagram saying our application is organized in four layers.
We have our UI layer.
We have an application layer.
We have a domain layer, we have the database.
And then when we discuss quality attributes in areas, we identify that there is there are
scenarios regarding business logic that is evolving,etc.
So and then we ask a question, how do you know?If a given piece of business logic is to be placed in the domain layer or in the application layer,so if, uh, if the architect
doesn't know the answer,if it's not clear what business logic should go in the domain layer, for example,then there is a risk because the maybe there's like tens of people writing code.
And some people may place business logic in the application layer in other people may place, may create the same business logic in the domain layer.
OK, so that's a possible risk.
And you just take note of that doing the ATAM.
Here's an example of a sensitivity point.
The number of person days of effort to create the new rest service is sensitive to the
choice between using Python and the Django Framework,which is new to the team or using
JAVA and spring, which is something that the team is familiar with.
So you need to create rest services There's the design decision there, or should we use
Python?Because Python, with Django brings benefits A and B, but it's something that the
team is not familiar with.
So that choice, we will fact modifiability will affect the effort. The number of person days.
Down below we have an example of a trade off.
So using a cloud based identity and access management service to authenticate users,
improves security and modifiability,but will create a performance overhead for on premises applications that will interact with the service.

So maybe during the architecture discussion, we found out that, um. So let's try to illustrate that there is a local network.
And the system that we are discussing. Let's say it's s one.
This system runs on a server here on the local network. Most of the users.
Are connected using the same local network. And they access the system right there.
However, in a recent design decision, um. The organization decided to use.
An identity access management system.
That is in a in the cloud service connected via the internet for log in, maybe allowing
users to log in with their Google account.
OK.
That means for this person to use the application here first, you need an interaction
with this external service to to perform the log in, the sign inSo that creates a performance overhead.
So that's a trade off.
You knew you chose this, this solution here, because it's super secure. It's easily maintained, has a lot of benefits, not expensive, etc.
But it will bring you a performance overhead, so there's a clear tradeoff there. And finally, an example of a non risk.
So you have some device.
That has a message, arrival rate one per second.
And, you know, the processing time of each message is less than 30 milliseconds. And there is a high, um, high, high priority process, uh, that is processing these
messages.
And given the CPU, you have the environment, you have a one second soft deadline is
reasonable.
So you look at the configuration prescribed by the architecture.
You look at the message arrival rate and you are sure you have some confidence that
there's no problem there.
So you look at that and hey, this is good.
We know this is going to work.

This requirement, this performance requirement is fine.

[ATAM Phase 2] All right.
So step six is the last step of phase one. The evaluation team goes home.
We have a bunch of artifacts, possibly in a Google Doc or a word document.
Um, and then um, we wait a week or two and we get together again.
The very same evaluation team and a group of people on the customer side, OK,we have the
same people that we have in the in phase one, but we add a lot of stakeholders.
So phase two is stakeholder centric and we want to get a more diverse point of view
around the requirements for the system.
And we will also double check the findings of phase one in terms of requirements and
whether the architecture can address the requirements.

[Stakeholders in phase 2] So we invite for phase two.
A wide group of stakeholders that is anyone that is concerned with some aspect of the
system.
So project manager, developers, product owners or ba or domain expert, architect or
technical leader,people who work with tests, integration, we can also invite the UI
designer or web designer if that person is there.
Um, people who work with information security.
So someone from the Information Security Office, if there is a database, there might be a
data administrator or a DBA, so you can invite them.
If this is a network or distributed system, you can invite the SRE, the site reliability
engineer or network admin or system admin.
Device hardware expert, maybe have a performance expert or performance analyst who can
invite the person so there is no right list of stakeholders,you just try to find out who
are the stakeholders of the system and invite all of them. I mean, one representative of each role.
If you will.
And I remember when I joined the SCI and was learning about software, architecture,
techniques, et cetera, everywhere,I would hear the word stakeholder and talking about it
and talking to stakeholders the importance of the stakeholders.
And I was thinking on my mind, who are these stakeholders? And the first image that came
to mind for me was something like this.

[steak holders]
But this is the wrong spelling.
So these are not people holding steaks.
Actually, I am from Brazil.
So when I heard stakeholder, uh, first I was thinking more of of the people you find in
in a Brazilian steakhouse like, uh, like this.

[Picture 3]

[steak holders]
I don't know if you have been to a Brazilian steak house where they serve meat on skewers
and they go around and I apologize if you are a vegetarian.
And this image showing all this carnage may be aggressive.
So anyway, but this is the wrong stakeholder.
We're talking about stakeholders different spellings, so people who have some stake, some
concern in the system.

[The 9 steps of the ATAM] So we are in phase two.
We invite all these people and we are going to perform step seven, eight and nine before we get to step seven.

[Phase 2 begins with a phase 1 recap] We do a recap of phase one, of course. So there are several new participants.
So we repeat step one, which is the presentation of ATAM, we recap the business presentation, the architectural presentation and we recap.
We take a look at the utility tree and we take a look at we have what we have analyzed so far, the risks that we have identified so far.
OK.
And at that point, everybody, all the new participants are up to speed with the current list of risks, architectural approaches and trade offs.

[Step 7: Brainstorm and prioritize scenarios]
Then we do step seven, which is a brainstorming session for eliciting quality attributes
scenarios.
At that point, all participants are aware of what is QA scenario, it's their importance.
So we open up a brainstorm and ask everybody to suggest scenarios and remember because
it's a brainstorming session.
People will suggest scenarios freely.
We take note of them.
And we don't discuss them right away.
After the brainstorming.
There might be some clarification of the scenarios,and we, so the method suggests that we
do a voting, voting for what? To find out what are the most important scenarios. So this is for prioritizing the scenarios, and how do you do the voting?Well, each
stakeholder.
Gets a number of votes that is equal to 20 percent of the number of scenarios. So if you have 30 scenarios as a result of the brainstorm.
Um, each person will get.
Nine, nine votes, if you have 20 scenarios, each person will get six votes and so on and
so forth.
And then each person can vote.
The way they want, they can place all their votes on a given scenario.
They can distribute the votes across several scenarios in any way they see fit. Very often, the stakeholders will cast their votesTo the scenarios that they have
suggested,but oftentimes they they find other scenarios that people suggested that they
realize, Oh, this is quite important.
And one thing that is usually done, we go back to the utility tree, which was created in
phase one,when we compare that prioritization with the prioritization that results from the discussion with all the participants,with many more stakeholders and we realize that.
New people that are participating in phase two may bring up scenarios that are very important that had not been considered in phase one.

[Step 8: Analyze architectural approaches]
And then step eight, we do something very similar to what we did in step six.
So we will analyze the architecture based on the scenarios we pick the high priority
scenarios, typically five to 10 scenarios.
So for each scenario, we go to the architecture and ask and try to find out how does the
architecture can address that scenario?And again, we'll take note of risks, known risks and trade offs.

[Step 9: Present the results] Step nine.
Um.
Often times between step eight and step nine, there is a gap.
Maybe there's a lunch break, or maybe we finish at the end of day one and then step nine
takes place on day two of phase two.
That's when we present the results.
So between step eight and nine, the evaluation team is very busy putting together some
sort of presentation of the results of the ATAM.
So it's a brief presentation with the architectural approaches, the scenarios,utility
tree with the scenarios prioritized risks and non risks, sensitivity points and
tradeoffs and risk themes.
So we oftentimes looking at all the risks that were listed.
We find themes of risks,concentration of risks around part of the system or around some
element of the infrastructure or some major design decisions. And then phase two is concluded.
So this is a traditional diagram that.

[Conceptual flow of the ATAM]
Shows the conceptual flow of the ATAM, like 30000 feet description.
We use as input the business drivers that are more are distilled in the inform the
quality attributes.
And they are distilled in scenarios.
So this this part of the the diagram here. Is focusing on the problem.
And then we have the software architecture.
Where we identify architectural approaches like tactics and patterns that we see there. And detailed architectural decisions.
So this bottom part here. Is focusing on the solution.
Understanding the problem and understanding the solution, we perform the ATAM evaluation, the analysis,as a result of that, we find out the trade offs, the sensitivity points, the non risks.
This is all informative, but the the.
The major benefit is to identify the risks, because these risks, which can be distilled
in risk themes,should impact the architecture and sometimes the business drivers.
So I mean the problem space, so it may change, some requirements may change.
Um, for example, we may relax some performance requirement because you find out this is
too complicated toachieve or you change the architecture later on to address a given
potential problem.
So why do I say this is the key benefit?Because when we identify the risk doing an ATAM
evaluation, we can more easily fix the architecture or adapt the requirements to the
problem.
If you don't identify this risk and the project, moves on,gets to implementation and
maybe the product is ruled out and maybe we the problem corresponding to the risk
actually occurs.
And at that point, fixing the system there is already already in production is much more
expensive.

[ATAM Phase 3]
OK, so just to wrap up, there is phase three, which happens offline.
So the evaluation team at the end of phase two, uh, the evaluation is basically
completed, but the evaluation team goes,goes home and they just produce a final report,
a document with all the information organized. So they have time to organize things.
Um.
Sometimes the evaluation team doesn't need to to write a document. They just put together a presentation of like a PowerPoint presentation. OK.
And you do a postmortem of the ATAM itself.
So at the end of the ATAM, you have this final report or presentation that has an
executive summary.

[The final report/presentation]
We we have the canned description of the ATAM. We capture a summary of the business drivers.
We have pointers to architecture description we have.
Then the description of what we find found out in terms of quality attributes, scenarios,
architectural approaches, risks, non risks, trade offs. The risk themes.
And possibly next steps. Next steps.
Often times do not involve the evaluation team that is for the software project team to
go on to address the risks.
So that is the ATAM in a nutshell.
See you in the next video.

[Questions? Paulo Merson pmerson@cmu. edu]

[junsoopark]

[Architecture views] Hello.
In this lecture, we'll start an important topic architecture views.
[Software architecture]
If you remember, this is our definition of software architecture. It was presented in week zero.
The software architecture of a system is the set of structures, plural.
Many structures needed to reason about a system reason about is open ended. It means guide development.
It means analyze the architecture, understand how to test the architecture, etc.
So these are the structures needed to reason about the system.
Each structure comprises software elements, relations among the elements and elements and
relations have properties.
This is the definition that was crafted and.
First written about in the documenting software architecture's views and beyond book. Second edition, the same definition then shows up in the third and fourth edition of
Software Architecture in Practice.
So this is the definition we're going to be working on.

[Which structures?]
So the definition says the architecture of a software system consists of several
structures, which structures?Well, there are many possible structures you can think of structures that describe code units, theirdecomposition in sub modules, uh, maybe another structure will describe the code units and their interdependencies.
What modules? What code units depend on other code units?Another structure may show components in how they interact at runtime.
Another structure may show artifacts.
There are put together for deployment. How they are packaged.
Other structures may show the runtime infrastructure showing some hardware details, OS details,etc.
Maybe if, in information systems often times you have a structure that showsdata
entities and their relationships and a domain model or data model and etc.
So.
Many possible structures.
OK, but what is an architecture view?

[Architecture view]
Well, a view is simply the representation of a structure, so a view is the documentation
of a structure is the visual artifact.
And we can have this definition of view as a representation of a set of system elements
and relationships among them.
Remember, a structure consists of elements and relations with two important
observations.
A given view does not show all the system elements it will show some of them,and a view
will constrain the types of elements and the types of relations that can be represented
in that view.
So if you have an architectural view that is showing, um, C modules, header their files,
and their dependencies,etc.
And then and we have boxes for these things in the diagram, and then you draw a line and connect a printer.
I'm not saying that is wrong, but a printer is a piece of hardware, so it it doesn't make much sense if you're showing code units.
So a given view,will prescribe specific sets of types of elements and types of relations as we're going to see a little bit in this lecture and the following lectures.
But the important thing is.
The view gives us something tangible.
So software architecture is something conceptual, every system has a software architecture.
But if you ask someone, show me the architecture of the software system, well, we can expect to see a set of views.
Oh, and here's our good friend, Eoin Woods saying that views are related to viewpoints or perspectives.
If you look around in the software architecture literature, there are people who use different terms.
So viewpoints and perspectives are similar to views. We are not going to go over a distinction.
Um, for us.
We mentioned views, but just remember there are different types of views, generic types
of views,and then when you document a specific system, you create the actual view, OK?But anyway, so that you know, if someone says my architecture has different

perspectives, you can relate that to different views.

[Boxes and lines in architecture diagrams]
And one more thing when we say, Show me your architecture, usually what people show you
is one or more diagrams showing boxes and lines.
So, um, another way to ask what are the boxes and lines in the diagram mean would be
toask what types of elements and what types of relations you have in that diagram.
OK? In other words, what kind of view is this a given diagram that has boxes and lines is
an architectural view,and the types of elements and the relations indicate what kind of
view that is.
What kind of structure it shows? All right.
So I am going to create my software architecture as a set of views, what views should I
create?

[Views suggested by different authors]
Many people have tried to answer that question,so different authors and different
organizations have over the years prescribed different fixed set of views.
Philipp Kruchten proposed in 1995 the well known 4+1 architectural model that is listed
here and on the top left.
Kruchten's 4+1 model had a logical view the process view, development view,physical view
and the plus one view that would put all of the four together.
Nick Rozansky, and Eoin Woods in their book, also proposed different set of views,and
they call them viewpoints as the category of the views you can create, viewpoint.
And more recently, especially in Europe, people have been using an approach called Arc
42, especially in Germany, I should say.
Um and Simon Brown, he is a consultant and book author.
Years ago has proposed the C4 model with context diagram, container diagram, component
diagram, and code diagram.
So all four types of users start with C hence C4.
Um, I have seen recent talks and.
Podcast episodes with Simon Brown, and he.
He's trying to explain C4 and one thing that happened is, um, in the last few years,he
always has to explain that container diagram is not about Docker containers,because the word container in recent years has been so closely associated with Docker because in Docker,you run components as Docker containers.
Anyway,So.
All of these different people have suggested different sets of views, which one should you create?Well, here I have Paul Clements saying that there's no fixed set of views that suits all cases.

[What is the “right” set of views?] In this course.
Just like in the Documenting Software Architectures book, and just like in the ISO standard for software architecture,we'll take a different approach.
To answer what is the right set of views, we use the standard answer for software engineering questions.
It depends.
But let's elaborate a little, this is too vague.
OK, so we will choose what views to create and what views to spend more time on because creating a view you can think,Oh, I'm creating a kind of diagram, but for some of them, you're going to spend more time, add more details.
So we're gonna choose what views to create based on two criteria.
First, what structures are inherent to that software system?So if I am creating an
embedded system that has no database, I'm not going to spend time creating a data
model.
If I am creating an application that runs on a single device, there's no network
communication whatsoever.
I'm not going to create an architectural view that describes network communications as in
a distributed system.
So think of what structures you have in that system, and we know it varies.
And the other criteria very, very important is you only create an architecture review if
it will benefit some stakeholder.
And remember, we talked about the stakeholders in the previous video.
So you won't spend time and money documenting an architecture viewUm, if there's no one
who's going to benefit from it, this is a recommendation.
So we go back to our gas station.
Billboard, you should document an architecture review if and only if it's needed, if
useful to someone.

[Categories of views] All right.
So if we are not going to follow any fixed set of views.
I can create any view, and I can name it the way I want, but for the sake of our
discussion around views,if you think of the universe set of views of all possible views,
at least we can organize them in broad categories.
So the first category is module views.
All the views that show the organization of implementation units, all the views that
focus on code, we can call them module views.
Then we have runtime views, also known as component and connector views. They show components and how they interact at runtime.
OK, so they describe structures that explain how the system works when it's running, of
course.
And the third category is just other views.
Very often we have there, excuse me.
A deployment structure, enlisting how the software is packaged and deployed on a runtime
infrastructure.

[Module vs component]
Now, in the previous slide, we mentioned runtime view module view.
Um, just to give you a heads up.
In this course, just like in the books and textbooks, we will use the terms module and
component with the specific meaning. Our module is an implementation unit.
It's a piece of code.
Some organization of code, can be a package, a module, a header file, a program, a
subsystem of sorts.
And a component is a software elementwith runtime presence.
So it's something that is running, a process, a thread, a service, databases, et cetera. And this is illustrated in this diagram, this is a notional diagram on the left, you have
a component in connector view listing components.
So these are runtime elements and the arrow is a pipe.
So the type of component here is a filter, so this is s a pipe and filter architecture. We'll talk about that in an another video.
Um, and the connector is a pipe.
So you see there's four components and they are connected via these pipes.
On the right hand side, we have the module view and in here each box is a module and the
arrow indicates a dependency.
So, for example, to underscore lower depends on config and it depends on stdio. So, um, different perspectives.
Different views.
Here's a question for you.
What is the relation between components and modules?Is it one to one? Is it one component
to many modules or is it one module, to many components?What do you think? In general,
the relation is many to many.
OK, so if you think of the code inside this component here to-upper.
Well, the code that you find where the code that you find inside this component
corresponds to modules main to-upper stdio config. So one too many.
Likewise.
Or, on the other hand, I should say, if you think of stdio module, the code that you find here.

Exists inside different components.
Because merge to-upper to-lower split, they all depend on a stdio.
So, in sum, in general, the relation between modules and components is many to many.

[Architecture style and architecture pattern]
And here's something that we already mentioned when we started talking about architecture
tactics in week one. So.
There's the notion of architectural style and architecture pattern.
We will use these terms indistinctively.
OK, so here's some examples of styles or patterns, layered, MVC, multi-tier
publish-subscribe, rest. Microservice.
When we were writing the book documenting software architectures, we tried to clarify what is a style what is a pattern,and we had an email thread with several authors, I think already mentioned that.
So there is no clear distinction.
I mean, there is consensual across all the in the literature, across all authors.
So the important thing is it doesn't matter if you pick, for example, publish subscribe, if you understand, publish subscribe.
If you understand how it works, the types of elements it prescribes, which are the publishers, the message queue, the subscribers.
If you understand the constraints, the trade offs involved in using that technique, publish-subscribe.
That is the important thing.
You don't need to classify it as an architectural style or as an architectural pattern.
OK.
Now, there's one thing that you should know, often times we use the architectural styles/pattern to name the architectural view.

[Types of views and architecture styles]
Remember, we said we don't need to use the fixed set of views, we create the views we
want.
Actually, you should follow two criteria.
We should document a view if the corresponding structure exists in the system andsecond criteria if there are stakeholders who will benefit from that architectureview.
All right.
But then you're going to create for each system different kinds of views.
Different specific views.
How do you name them?One thing that you can do is to use the name of the dominant architectural style or pattern represented in a given view, to name The View.
So here are some examples.
You may have the layered view of the OSGi platform, the multi-tier view of the adventure
builder system, so don't worry much about this.
It may sound abstract, but we will see several examples, many examples of architecture
views,and you'll find out this relation between the architecture style and the name of
the view.
In any case, the important thing is when you use an architectural style, an architectural
pattern.
It helps to communicate the design.
So the recommendation is, if you're using a style or pattern make that information clear
somewhere in the documentation.
The starting point might be the name of the view.
And why is that? because architectural patterns and stylesAre documented in the
literature, so people are familiar with these things.
If if you say, um, let's say you have a class diagram.
And you want to explain the design behind that class diagram to someone,so you bring up
that class diagram and he has 10 classes there and you go on and explain class by class, class A does this class Bdoes that class C does that and so on and so forth.
It will take a while, but you will explain the design.
Now, if you know that design follows the model view controller architecture pattern, and the person you are explaining the design to is familiar with MVC.
What can you do? You show that diagram, and you just say classes A, B, C and D are model classes.

E F G and H are view classes.
I and J are my controller classes.
So just by using making use of the terminology introduced by the architectural pattern, you will make the explanation much more clear.
So.
Use the patterns and styles because they bring you some benefits in the designand make sure you tell the reader in the documentation what style and pattern you're using.
In the coming lectures, we'll see tons of examples of architectural views of the different kinds and categories.
Uh, but let me say right away we have two publicly available software architecture documents where you can see examples of architectural views.
The first one here that will show up in slides that are coming in future lectures is the architecture of the farmacy food application.
This is a company in Detroit.
They have a ghost kitchen, also known as Dark Kitchen.
And the second one is the companion to the DSA book our text book. This is the architecture of the Adventure View system.
OK, so we'll talk more about architecture views in the next video.

[junsoopark]

Hello.
In the previous video, we introduced the notion of architecture views.
[Module views, module decomposition view]
And we said that a view is the documentation of an architectural structure, and remember,
software architecture consists of multiple structures.
Therefore, the software architecture document will be a collection of architectural
views.
And we said that different authors have proposed fixed set of views,but we're better off
creating the views based on the needs of the stakeholders inthe different structures
that the system has because there is no fixed set of views. That is the best for all cases.
And we mentioned that we were going to cover several possible views and for the sake
ofThe discussion we would.
Break the universe of views into three categories in the first category is the module
views, and that's what we're going to discuss starting now.

[Agenda]
So in this video, we will introduce more your views,and we will show the very first
examples that are module views that show modern decomposition greyed out are our continuation of the module viewsdiscussion that will be in the following videos.

[Module views] So in general.
Module views.
Show the structures of the system in terms of units of implementation.
That means the module views focus on quote.
The elements are called modules.
So remember, in an architectural structure, the term element in relation is generic, we
don't know what they are.
Oftentimes the elements are the boxes and the relations are the lines, but the terms are
generic.
When we talk about specific, when we talk about module views specifically,the elements
are modules and the modules represent implementation units in a given real module viewIt may be even more specific, so your modules may be Java classes, Java packages, Java interfaces, Heather Files C programs, etc.
In the relations that we find in module views belong to three categories we can say,A module A is part of B that is a part whole relation between module and sub module.
We can say that Module A depends on Module B. We'll discuss that in the next video.
In some situations, we can have a sort of specialization or generalization among
modules.
That is to say, a model A is a subtype of B.

[The Unified Modeling Language] All right.
The unified modeling language when we say UML. Oftentimes.
The reaction is like this.
I agree that UML is complicated, over complicated. Um, it is.
Modeling to a language that a lot of people avoid.
But many times they avoid it entirely just because other people are saying, Oh, UML, it's
too complicated.
But what is your UML? It is a visual language.
It means it's defined byIt has diagrams with graphical symbols.
And it is defined by a meta model with associated graphical notation.
It's not defined a language that is defined by a grammar.
Excuse me, like with a BNF description, and it is a visual language to specify design and
document artifacts of a software system.
And here's the thing when someone says, Oh, these days, a lot of people use the word
hate.
I try to avoid it by all means.
But oftentimes you see people saying, Oh, I hate UML, if someone says that to you. Uh.
I suggest you ask, OK, so what do you use instead?What is the better, a better alternative than UML?Because it turns out there's no standard language that is used for software design or description of software design.
That is widely known.
So UML is a de facto standard.
Um, it's the most widely used and widely known modeling language for software,and it is also a de jure standard, meaning it is published by an industry standard body.
In this case, the O-M-G or OMG in this case is not Oh my god, it is the object management group.
Now, UML has 14 types of diagrams, and it's just crazy.
Try to know them all, to understand them all or to use them all. Nobody does that.
So a recommendation to you is use your diagrams and symbols that the readers of the

documentation are familiar with. OK.
If you're familiar with a given type of UML diagram, um, that's good because it might help you to communicate the design,but you should only use it if other people that will consume your design diagrams are also familiar with UML.
Uh, as a side comment,a few papers have been published academic papers mentioning the types of diagrams that peopleuse the most because it has 14 types of diagrams and if you use a different criteria,15 types as a matter of fact.
But in practice, most people create use case diagrams, which are those diagrams that have the ovals and the straw man, and they show.
So there they have.
The straw man connected.
To ovals and each one was a use case, say log in. Place order.
So.
Out of all of these diagrams, the most used diagrams are use case diagrams, class
diagrams and sequenced diagrams.
So we're not going to cover use case diagrams, what we will talk about class diagrams and
later in the course also sequence diagrams.

[UML history] Bit of history.
And this is interesting in the early 90s.
Object oriented programing was established approach in popular approach for programing
and many programing,language, object oriented programing, language just got traction and
were being adopted all around.
And naturally, people found out the need to discuss object orientation at, at, at the
design level,not only at the programing coding level and different authors proposed
object oriented analysis and design methods.
In the early 90s, these different authors were proposing different, excuse me,different
notations to describe objects in relations among among objects, objects and classes, etc.
And it was kind of confusing.
I am old enough to remember those times I had the book by Jim RumbaughI also had another book by, um, Peter.
In any case,one thing that changed the course of history for these OO design notations
was that Grady Booch and Jim Rumbaugh got together and founded the rationalcompany and created the UML language in the name tells it all it was an attempt to unify modeling languages with a focus on object orientation.
Ivar Jacobson later joined them.
And as you see in this kind of diagram in this diagram, by the way, Um uses the UML
annotation.
And then UML 1.
0 got published in 1997.
So then what happened? It was a specification owned by rational and rational gave it to
the O-M-G.
So with input from the OO community and the O-M-G UML committee, they came up. I mean, then as a O-M-G standard, UML 1.
1 got published and it evolved via discussions in the O-M-G committee to 1.
2 1.
3 1.
5.
At this point, it became an ISO standard.
And the major milestone was the publication of UML 2.

0 in 2004, they changed, they added diagrams.
They changed the name of the communication diagram.
They added a lot of stuff to some of the existing diagrams, and it has been slowly
evolving since 2. 0.
So we're now at two point five. But this is a brief history of UML.

[UML extension mechanisms]
You should know UML has extension mechanisms.
It comes with a set of symbols.
And you can extend any symbol, it can be a box or a connector or a line of sort with a
stereotype.
The stereotype is some label or some name that you write in side angle brackets. And the stereotype.
Gives a special meaning to that type of element or relation.
So down below, as a quick example, this box here.
Has the stereotype filter, if it didn't have the stereotype, you would say, well, this is
a component because this is the symbol for a component.
So the dashed line with the open arrowhead like this is a dependency, but it it's not a
random dependency.
In this case, we know it's a pipe because it has the stereotype pipe, another extension
mechanism.
A mechanism by UML is the tagged value. What is that? It's simply a key and a value pair.
That is the key is the tag that you can associate to a stereotyped element.
So pipes, for example, have properties, capacity and the data what to do when the pipe is
full, what to do when a pipe is empty.
So each of these is a different tagged value. OK.
There are other extension mechanisms, namely constraints and profiles, but we're not going to discuss them.

[UML in module views - elements]
So how do you represent modules in UML or how do you represent our elements in the modu
views?Well, there are basically two types of symbols.
There's the package symbol, which is this rectangle with the top lefttab. And there is the symbol for a class, which is a straight, simple rectangle.
The class symbol may be split into compartments as seen down below.
So if you do that, you have the name of the class on the top compartment. The second compartment is four attributes in the third compartment is for the
operations. A class.
Which name is in italics is an abstract class.
But this only makes sense if you're using an OO language and you want to identify a class
asabstract, an abstract class is a class that does not contain a full implementation.
So you need a subclass of the abstract class that will contain the full implementation or
else it will be abstract on its own.
And you cannot initiate an abstract class.
And you can indicate that a class offers or provides a given interface using this symbol,
which is the lollipop symbol for an interface.
And look, this is UI element class that provides IAnimatable interface.
We can use the rectangle to show the interface itself as long as you just use the
interface to stereotype.
We'll talk more about software interfaces in the future, and we'll come back to this
notation for now. Just remember.
If it's a rectangle with a tab on top, it's a package. If it's a rectangle, it's a class.
The simple rectangle, it's a class.
And by the way, UML, does not have colors,but UML tools often use colors or they allow
you to color elements just to make the diagnosis more readable, but the color has no
meaning.
And we are looking at a UML because they're quite useful for model views. OK.
And our model views, if you use the UML annotation, are typically class diagrams.

[UML in module views - relations] All right.
The previous slide we were looking at the elements represented in UML, in this slide
we'll look at relations.
So how do we represent that is part of relation in UML.
We just use packages because the package can have sub elements.
So if you think the package is a module, the sub modules are all the boxes that you draw
inside that package.
So in here, the com dot.
sun.
ebank.
webPackage has three sub modules com.
sun.
ebank.
web.
taglib, Package and dispatcher in the context listener classes.
So you just need to draw a box that is a package and draw things inside, you'recreating a
sort of module sub module relation dependencies in your UML are shown by the dashed line
with an open arrowhead like this. And the is-a relation.
Um, there are some variations, but in UML it can be represented this class inheritance. That's what you see on the left.
So the account class has two subclasses checking account and savings account and for
class inheritance.
We used the solid line with the closed arrowhead.
And there there is also interface realization where we say that a given class realizes or
implements, a given interface.
And for that, we use the dashed line with a closed, hollow arrowhead. We'll come back at interfaces in in the future, so we'll revisit this notation.

[Agenda]
OK, so this was a generic discussion of module views.
Now let's go over several specific kinds of module views that you may or may not create
in your architecture documentation.
We'll start with module decomposition, the simplest of them all.

[Module decomposition view]
So what is, what kind of view is this? Well, it shows primarily the is part of relation
between modules.
You will show modules and sub modules and possibly sub sub modules. And so on.
When you were creating, doing module decomposition, the criteria include improve, modifiability,you don't want a single module with all the code with thousands and thousands of lines.
You want to break your software system into smaller modules and oftentimes you group modules so that they are sub modules of something larger.
It can be a subsystem, it can be a package, can be a namespace.
It doesn't matter how you call it, but we have the the general notion of modules and sub
modules.
Um, build versus buy.
It's another criteria.
Sometimes you split functionality into two modules,one that you're going to build your own in the other that you're going to buy or download from the internet because it's kind of a.
Uti functionality, and you also should consider the skills of the developers,so some modules are part of the frontend other modules are drivers that interact with devices, or the modules areHave control or logic, so and different devs,developers are familiar with different languages and technologies that are more appropriate for different kinds of modules.
One more reason to have different modules in the system.
By the way, in week one, when we covered modifiability, we talked about different tactics
and two of them were split module and refactor.
They are directly related related to the way you decompose, your software system into
modules and sub modules,which is something that is captured in a module decomposition view.

[Module decomposition view - example 1] OK.
Hey, this is our very first example of an architectural view. Um, and in this case, it's a model decomposition view.
This is for a software system of the US army.
It's an old system called ATIA-M.
And what you see here is the top level model decomposition view.
This entire system is divided into Windows apps, which are further divided into these
three other subsystems.
There are also the AITA server side web modules in the ATIA server side Java modules. A disclaimer about the many examples of design diagrams ahead.
Look, there is no need to discuss or to understand the design.
OK.
When you see an example of an architecture view, you, uh, you don't need to worry about
understanding the purpose, the logic behind each box.
What does it do? Just try to understand what kind of information the diagram conveys. OK.
Another comment disclaimer about these examples, they are real examples, and therefore
they are not perfect. OK.
And almost all of them are design diagrams.
Coming from the software systems that I helped to create or document or evaluate. Another thing the diagrams I show are not the latest version, necessarily.
And something that, uh, you realize when we get to to the end of our discussion about
modules.
Oh, sorry about views.
Is that the diagram.
Doesn't tell the whole story, so,Right here, I'm saying this is an example of a module decomposition view,but in reality, this is just a diagram for the the entire architecture view.
We need more information than just the diagram. But we'll get to that in the future.
OK, so this is an example of module decomposition view and look sometimes a givenModule is complex enough that you can't show everything in the single diagram,and then you

apply the basic concept of refinement or view refinement, if you will. And that's what we're going to do here.
So if we pick ATIA server side Java modules, we can look inside and we'll see several other modules.

[Module decomposition view - example 2] That's what you have in this other diagram.
You look, the top level box is exactly service. Server side Java modules.
And this is a different modality, composition view, which turns out to be a refinement
of the previous diagram.
OK, so here we see the sub modules.
Of the server side, Java modules.

[Module decomposition view - example 3]
And here's example, three, this is from an application called ikewiki that was created by
a startup company called ikaru,who I was part of that startup company in the late 2000s,
and we created the application and the client. Part of the system had this diagram.
I had this module decomposition.
As you can see, there are several sub modules.
Just another example.
And so far, all of these diagrams use the UML notation, just showing packages when we
have something inside and from time to time, we have classes. So here on top, we have some classes.
Here's another example.

[Module decomposition view - example 4] This is a more recent example.
This is from work.
Again, there's no need to understand what's behind each box.
What does it do?But you can see that the whole system is organized into one. So let's call them so we have here.
We have.
One big module, another module. We have this.
As well.
One more. A small one.
And then we have these. Independent modules.
So each thing that I circled is a subsystem or a module of the system in each one.
If you look inside may have sub modules, so the notation is UML, but you see there are
some symbols. Notably, there's a.
Kind of Fox head kind of logo, if you're familiar with with the tool, you know that this
is the GitLab logo.
So we were using this to indicate that this project, I mean this this whole module is
stored in a GitLab repository code repository. And these are the symbol here for subversion.
This is, I mean, it was years ago stored in a subversion code repository as well. But you see, in any case, it describes the code decomposition, the module
decomposition,and I worked on this project and I joined the team andThe manager's asked
me, Hey, look, you were the software architecture guy.
Help us to understand the architecture of this system.
If this system is 20 years old and it has grown up in many directions with code written
by many people, we don't even know where is all the code.
We don't have, like an overview picture of the entire code base.
So to address that question, I created this model decomposition view.
Which tells right away, Hey, in this um, in this picture, you see all the elements of the
system, all the code repositories, OK?Of course, if I dig deeper inside each of many of

these boxes, I will see for the details and sub sub modules, sub sub sub modules and so
on.
But this gives us an overview of the entire code base for the software system.

[Questions? Paulo Merson pmerson@cmu.
edu]
In the next video, we will make some more progress in our discussion of module views.

[junsoopark]

[Module uses view] Hello.
In this video, we continue our walk around the world of architectural views, and we are talking about module views.
[Agenda]
So in this video, we'll talk specifically about module uses views.

[Module uses view]
And this is a very important architectural view.
Issues for each module, what other modules it uses.
So it is a basic notion, if you think I'm creating a module view and you have Module A. , You want to know what are the modules it uses.
So you that's how you build this kind of view.
And then for each module you explore.
Whatmodules it uses.
When we say a module is using another module.
Well, this is typically a syntactic reference in the code.
It means, for example, what I just drew on screen for Module A to work modules B and C
need to be there.
And this usage dependency creates coupling between modules and loops should be avoided,
for example, in your design.
Uh, you don't want to have a loop like this in general.
You don't want to have too many dependencies beyond what's needed because if you have a
lot of dependencies.
What happens is when you change your module, you are affecting many other modules,and
that has ripple, rippling effect that may be a problem in maintenance in general.

[Coupling]
But coupling, uh, is something we discussed when we talked about modifiability in week
one, so this is a brief recap.
So it refers to the degree of interdependency between software elements.
It can also be seen as the probability that a modification to one module will propagate
to the other.
So we want low coupling.
We want loose coupling.
But the goal is not to remove coupling Coupling is absolutely natural.
So if you have a module that calls another the if you have them.
So if a C program calling another C program calling a function in another in a library
that's coupling and we need that to build applications.
What we want to do is to limit coupling to the minimum necessary.
And we have, so we achieve loose coupling and we avoid tight coupling or high coupling.

[Module uses view - example 1] All right.
Here's of our first example of a module uses view.
And you see the modules here, and this is the UML notation, and if you remember in UML,
we use this dashed line with the label we uses.
Uses is the basic label for usage that businesses sometimes you can use a label that is
more specific.
Maybe you can say synchronizes or uses via HDTV.
He can be something specific, so uses is kind of the the general label for this kind of
dependency.
Now you may recognize this diagram.
In fact, we saw the same diagram in the previous video when we talked about module
decomposition.
So let me bring this up over here.
So this is a slide from the previous lecture where we showed the same diagram, but then
it was only describing module decomposition.
What modules are inside other modules? So let me use that example to make the point that
if you have a module decomposition.
If you add the usage dependency, that diagram is now showing decomposition and usage
dependency, and that is very, very common.
Sometimes there are just too many usage dependencies to show, and you want to keep the
diagram clean, readable, so you only show the composition.

[Module uses view - example 2] Here's another example.
This is from the wiki.
That is the companion to the documents after architecture's book and you see here a lot
of dependencies in some of them.
Most of them are used, but you have slightly different kind of dependencies, such as use
via wsdl, w s d l, jms send.
Again, remember in these examples, there is no need to understand the design to
understand the meaning behind each box, each module or each element.
You just need to try to understand what the diagram shows.
So in this case, it's showing several packages and it's showing how each package uses one
another.

[Module uses view - example 3] Here's a third example.
A cleaner one here, there's no decomposition, it's just use this dependency, so it's
cleaner.
And look at this on the right hand side, we have the dependency structure matrix. Of the diagram on the left.
This kind of notation, tabular notation is supported by some tools.
So when you're creating the design, it's natural for you to create a diagram with boxes
and lines.
But there are tools that can read the code afterwards and create the DSM. And it's useful for some kinds of analysis.
But how does this go along with the cases?A number one means that the module in the
column uses the module in a row. So if we pick up.
This column over here, ejb, and we pick this row over here.
So this number one means that module ejb uses module common. Let's see if that's true.
So ejb is here.
Common is down below, so the one that I marked corresponds to this dependency over here.
The tools that created DSM. They.
Use the cells with integer numbers is not just zero or one.
So when there is a dependency, there will be a number a positive number one, two, three,
20 and that gives you a degree of coupling.
So if the number is too high, it means there are a lot of references. So one module is using the other in several places in the code.

[Module uses view - example 4] Here's another example.
And the notation is not UML, it's just a simple box in line diagram. I created this diagram in twenty twenty, yeah last year 2021.
This is a project from work and look.
The modules here are coarse grained.
They're large things.
So the the things in gray are external libraries.
The the elements in green are the projects that we are creating and the ones in orange
are old projects that we want to get rid of.
That's why it says undesirable library and the usage dependency here is at the kind of
software project level.
So this is a gradle or maven dependency.
So to build this project, I need this other project.

[Uses of the module uses view]
OK, so what can we use the module uses view for, excuse the pun, education of new
developers.
How is that? Well, guess what? And. True story.
More than once, I joined software projects and large software projects with, say, 8000
modules or pieces of source files.
And so first day you you go to work and you joined their project, you get an email. Hello, Paulo.
Welcome to our team.
We are going to assign you some development tasks or some bugs to fix. And this is all you need to get started.
What is that? They give me the link to the source code repository.
These days, it's a git repository in the old times.
It was a subversion repository.
Before that, it was maybe perforce or visual source safe or cvs.
Anyway, I would be given the link to the source code.
I would git clone or check out the project to my machine.
Open the source code on the ID and start looking at it reading code.
And then you navigate through the directories, the namespaces, the packages there and
start reading code,you identify the entry point like main, the main function or whatever
the entry point is.
And you read code and you read code and you read code.
So after a few days, you get a basic understand, an understanding of the whole project of
how it works.
I mean, the bigger pieces and maybe one path or another.
So and then maybe a week after reading so much code, you venture to do a bug fix or to
implement something into commit code to the repository.
So but the thing is that it takes you a few days to make a real contribution andyou do so
still not very confident that you are very familiar with the code.
Maybe after a month, you're already working on the project submitting code,but you're
still not pretty familiar with everything because it's a large project, large software
project. Maybe.

Four months from now, six months from now,you get assigned a task to implement somethin and you go to the project as you usually doand you start reading and then you reach a
part of the code that you had never seen before.
And you start digging in, you open code and you'll go and you find out, Oh, look. I didn't know we had this functionality implemented here.
I didn't know we had this util kind of function available.
So.
Because you were learning about the code by reading source files.
It takes a long time for you to get a good understanding of everything.
The issue there is that it takes longer for you to become productive.
And there's another issue there is an increased probability that you will implement
something that already exists somewhere in the code base. So.
If we change things and we produce module views, specifically, module uses views in
module decomposition views when someone joins the project. What do you do? Hello, Paulo.
Welcome to the team.
Before you start developing, let's go over the structure of the source code and we take a
look at the module,decompositions, what the the main modules, the sub launchers, the
subsystems.
We take a look at the dependencies in module uses views.
We can use refinement.
So we look at one subsystem and then there is another view, which is a refinement that
kind of explodes that view into smaller pieces. After that explanation.
You feel more confident.
About navigating across the source code and writing code yourself.
So long story to say module uses views and module decomposition views they go hand in
hand are very important for the education of new developers.
These days there is a term for that, it is onboarding.
So it's these architectural views are very important for the on boarding. They also help to guide testing and debugging.
And they help project managers when they do task allocation, when they set up project schedules,they need to find out about the dependency so that they know which one, which

modules should be developed first.
They and in that sense, they have to plan incremental development.
So the basic modules that are used by many other modules should be developed first in
incrementally impact analysis.
So when you need to make changes to a module.
Indeed, the changes affect the interfaces of a module.
You look at module users view, uh, to find out what modules, what other modules are
affected, so that's impact analysis and to guide refactoring.
Sometimes you find out, Okay, I need to break down a module into two.
So you look at the dependencies internal and external that helps to to understand how you
move things around.
And in fact, let me show you real quick.
Um.
As a diagram, it this is also from work, don't worry about understanding anything,in fact, even the comments are in Portuguese, but they don't matter.
So this was a refactoring that I worked on here about eight, 10 years ago.
We had a large library and we wanted to break it into two.
So we need to pull modules out of one library in some of the modules would stay in the
old library. And we did.
We created this diagram and this is UML.
Um, but we I colored in read the modules that should not be moved out.
So understanding the dependencies at this level in a module, simple module usesdiagram
was essential for us to have confidence about moving things around. So these kind of diagrams.
Are very useful when you do refactoring's.

[Uses view is key to incremental development] Look.
Here's an example.
I mean, very simplistic.
Modules ABC to illustrate how incremental development can make use of these kind of
diagrams.
Look at this diagram and try to answer the question what modules are required?If I want
module C in the next release, so pause the video and think.
Well, the answer is, if I want module C, I need modules H, and, modules H and I, because
C uses H.
So if I want C, I need H.
C also uses I, so I also need I and I uses J. So the answer is I need C, H, I and J.
Then I can plan in the next release.
I need C, so I need to plan for developing HI J.
But now here's another question.
You see, we added an arrow, so pause the view and think, what module do I need now if I
want C in the next release?Here's what happened.
C, now has a dependency to A and that actually creates a loop.
As you can see, A needs B, B needs G, G needs F, A needs D as in Delta D needs EBottom
line, because of this dependency, if I need C, I need all the modules in the next
release.
Of course, we are looking at modules in this diagram.
At a course level in practice, sometimes in reality, what you need is not the entire
module, what you need.
It be functions X, Y or z in a given module.
But anyway, this gives you an idea of how understanding the module, the usage of
dependencies is important for incremental development.

[junsoopark]

[Layered style]
Welcome back, Layered style.
This architectural style has been described and used since the beginning of software architecture.
[Agenda]
And it shows how to organize the overall source code in larger groups that we call the
layers.
Therefore, we can say that an architectural view that shows the organization of the
coding layers is a kind of module view of a model

[Layered style] view.
So the element is a layer.
Which is a module, in essence, but it's the layers, is a special kind of module.
It is a grouping of modules that together offer a cohesive set of services to all the
layers.
Again, a layer is a logical grouping of modules.
And the relation that we have between layers is allowed to use.
We are not indicating the usage dependencies between modules like we did in the previous
view that we discussed.
We're just saying, Hey, this is a layer and modules inside this layer are allowed to use
modules inside these other layer,but we're not explicitly indicating what are the usage
dependencies.
And the design constraint to say that your design is indeed layered is the allowed to use
relation must be uni directional.
It is very, very common to describe the organization of modules in layers for any larger
system.
However, many layered views are not well documented.
Probably the most common approach to describe the software in layers is to use a stack of
boxes,so you may have seen diagrams that just show boxes like that maybe have A, B and
C, and when you look at this and it says it's the layered design.
Our intuition is, uh, the modules inside layer A.
Can use the modules inside layer B and the modules inside layer B can use the modules
inside layers C. All good.
Well, here's a question can the modules inside layer A.
Use the modules inside layer C directly?We don't know. Because the diagram doesn't, as is, the diagram doesn't tell you.
And I should say this.
All of the arrows that I described here go.
Top to bottom, so we are still unidirectional.
And in reality, in some layer designs, a given layer is allowed to use only the next lower layer,but in other layered designs a given layer is allowedbut in other layered designs a given layer is allowed to use any lower layer.

And there's more. Sometimes people create.
What we call a side car layer. I don't know, maybe util.
And the idea is that the layers in this case, the layers on the left, are allowed to use the util layer, that's still OK.
And there's more sometimes a given layer is partitioned like there is A1, A2, A3. And then, of course, A1, A2, and A3 all can use the layer below.
But it's not clear whether, using, one layer using the layer next to it like this is
allowed or not.
Because the notation doesn't say.
So this is an issue that we need to address to create diagrams that are more express, expressive and non ambiguous.

[Layered architecture of the OSGi framework]
Here's an example of a layered design,and you see the link to the osgi architecture
documentation where you find this diagram now based on what I was mentioning,the
notation in this diagram has at least two ambiguities.
Can you pause and think what, uh, is not clear about the notation? Don't worry about the
meaning of each layer, but just a notation.
What is the issue there? There are two issues again.
So first one is, uh, OK, I my intuition is services can use life cycle, but can services
call things in here directly?So, can you skip a layers going downwards and OK, so bundles can use this, but can I have the allowed to use relation from right to left?It's not clear the notation doesn't make it clear, so the allowed to use relation is not clear in this diagram.
The second thing that is not clear in the rotation is why are some boxes in yellow andother boxes are in purple and other boxes in red and the other boxes are in gray?What is the meaning of the colors?Very, very often people use colors in design diagrams, and they want I mean, the person creating the diagram uses colors with a specific meaning.
But they don't tell that meaning in the design diagram. So we need to fix that.
In fact, I want you to I want to present you some design diagram tips.

[(Design diagram tips)]
This is slide is like a parenthesis in our architecture conversation, but it's very
important, especially for the diagrams that you're going to create. First thing.
When you create design diagrams, use consistent symbology across the entire
documentation.
For example, if you use a rectangle for class, you use the same rectangle for classes in
all your diagrams that show class.
Of course, there will be different types of diagrams showing different types of
elements.
And then you can use completely different notations, but for diagrams of the same type. Try to use the same symbols.
And in your design diagrams, you should always, always, always use add a notation key a
legend that tells the meaning of the symbols.
If you are using a standard notation like UML, you just need to say notation is UML. But if you're creating your own notation, your own boxes, using the colors that you
want.
This is what we call an informal notation that you come up with.
Well, add a notation key slash legend explaining the meaning of the symbols. And in your notation key, don't forget to indicate the meaning of lines and colors,
right?Sometimes people create a notation key.
They explain the meaning of the boxes, but they forget to talk about the arrows. And then what happens so.
If you walk into a meeting room.
And you see something like this on the whiteboard.
What do you know?Well, we know for sure.
Two people who work with Software were there talking, because when we get close to a
whiteboard, we start drawing these boxes and lines, right?But what is it that you don't
know? The meaning of this arrow.
Does it mean that a calls b? Does it mean that a sends a message to b?Or maybe B is a
data repository and A is writing on B, or maybe A is a data repository and B is reading from A.
Maybe A is instantiating B.
Maybe A is a subtype of B, an is-a relation.

Usually that kind of relation is one on top of the other, but it can be sideways as
well. So.
Please, in your design diagrams use different arrows for different types of relationsor
connectors and indicate the meaning of these arrows in your notation key. And use distinct symbols for different types of elements and different types of
relations.
So sometimes people will create a diagram and they know they need to create a notation
key.
And they use the same box for all kinds of elements and they just say draw the notation
key.
And they have like rectangle module or component something generic. So differentiate modules.
For example, if a module is a Java package.
And you have in the same system, you have other modules that are C programs,they should
have use different symbols or different colors or some different some label to
differentiate them because they're different in nature.
OK? If I have an arrow that represents a local function call.
I should have a different arrow to represent an http call because that's a completely
different kind of interaction.
And something that we already mentioned,if you use a given architectural style or
architecture pattern and make that clear in the documentation because,you know, the
patterns and the styles bring a vocabulary that helps to explain the design.
We talked about that in a previous lecture.
And I want to ask you something from now on when someone is presenting an architectural
diagram to you and there is no notation key.
Please raise your hand and ask the person to explain the meaning of the symbols. And here's the funny thing, you will realize that many times the person presenting the
design diagram does not have the answer.
Sometimes not on purpose, but we create design diagrams.
We use different symbols and colors, but we don't think about the specific meaning of the
different symbols and colors.
The corollary of that is when you are creating a design diagram if you force yourself to
have a notation key.

Naturally, you will create design diagrams that are better, better in the sense that they are more expressive,that they more clearly explaine the design because you if you draw something like this A,then Arrow B and you know you need to have the notation key.
And you need to explain what is this arrow, guess what?Just because you need to say in the notation key what it is, you need to make that design decision and sometimes it's not clear yet, and that is OK.
You can say TBD to be defined or you can just say something like http or GRPC.
Let's say these are the two options that you're investigating and you make that design
decision later.
But if you don't have a notation key, it's open ended.
It's not clear what it is.

[Layered style and modifiability] Okey, dokey.
Moving on.
Back to layers, layers can be used to describe separation of concerns, and here's a
simple example UI presentation is a concern.
And then you have the control logic, business logic data access.
OK? A layer is a logical grouping of modules that is normally not visible in the source
code.
What I'm saying is if you open the source code of the project, even though there is a
layered diagram,you won't necessarily see the layers somewhere in the source code. There's no module that says public layer x y z.
You may have classes, you may have header files and so on.
You may have directories, but the layers are not directly visible in the source code. Every time? And in the source code, you see the actual usage dependencies.
And they should be limited to the allowed to use dependencies in the layered design. So if I look at this diagram here, um.
If you look at a module that is here, so there might be, I don't know, class.
C, that is part of business logic layer.
And then over here I have Class X.
If inside the code of C, there is a call to X, I am violating the layered design. OK.
Before we move on, question to you, is there a problem with this diagram?Yes, there is no notation key.
Let's fix that.
Look, now I know that a given layer and any layer is allowed to use only the next lower layer.

[Layered style and portability]
And the layered style also helps with portability, sometimes we break a layer
horizontally to indicate different adapters or different technologies. And that's what you see over here.
So this would be the UI layer, and they all I mean, all the sub elements here or the sub
layers,if you will, interact with the system via REST calls.
So there's a rest layer.
So here we have rest services that can be called from the web UI, from the Android UI,
the iOS UI, or a command line interface client as well.
And down below, there's the domain layer that needs to interact with the database, and we
have three options.
There's a SQL database, an ElasticSearch database, and I guess data can also be stored in
flat files.
So there's file I/O.
OK, so here's a Real-World example of a layered design.

[Layered style - example 1]
It's in the DSA book documenting software architectures and is a very old design
diagram.
I think it's from the 80s.
Since then, we have been using layers and you see the layers laid out.
There's the partitioned layered andThis design diagram has something peculiar. It shows the organization of the code in layers.
And it also shows. Module decomposition.
How is that?Pause and think.
Look at the notation, key. It's using colors.
It is showing decomposition via the color key.
So the layers in white are part are sub modules, if you will,of the behavior hiding
module light gray layers are sub modules of the software decisionhiding module, and darker gray are sub modules of harder hardware hiding module.

[Layered style - example 2] Here's another example.
This is from an application that I think I already mentioned.
I helped to develop in the late 2000s when I was part of a startup company and we were
creating a product called Ikewiki.
And in this diagram, we used arrows to indicate the allowed to use relation, so there's
no ambiguity regarding what layers can use other layers.
So it is OK to use arrows in layered designs.
The important thing is that the arrows represent allow to use, of course, and you cannot
have something like this because.
You are here, you violating the layered design? OK. Now there's something peculiar.
These arrows represent allowed to use.
However, I might have at run time a call and execute, I can execute a function call going
in the other direction.
How does that work? For example, maybe I have Module A here and. It makes a call.
To module b in this other layer, and in this call, it tells b do this and that and at
the end, make a call to this function.
So B will execute and will activate function F function f may be inside A.
So there might be an activation of a, originating from B in this case, it's what we call
a callback.
This callback does not violate the layered design, because if you look at the source code
of of B,which is part of svc layer, there is no syntactic reference to the layer above. That's what we want, at runtime it will execute the function it's passed on to.
So maybe there's another module here, C, that callsB, passing as a parameter function G
saying, Hey, G is my callback and in Module B will execute, and at the end it will call
function G.
Function G may be anywhere as long as it's compiled together, or it might be like a URL
that you call someplace else.

[Layered style - example 3]
Another example of layered design, this is from the classic book, The Design of the Unix
Operating System by Maurice Bock.
This book is from 1986, and this diagram is so important that it shows in the cover of
the book I actually have a copy of that book.
I was a teenager in 1986, but when I was in college a few years later, I had that as a
textbook for an elective class that I took.
But I'm bringing this up to say that layered designs sometimes are not stack of boxes. They are concentric rings.
And in this case, the outer ring is allowed to use the inner ring, so they allow to use
relation goes in that direction.
And you still have that partition like in here.
So the outer layer has the application programs, and the C compiler, and then at this
second layeryou have many different OS programs and then you have the kernel, and inside you have the hardware.

[Layered style - example 4]
By the way, inside the same book, we have this diagram. You see, if I can find it real quick.
Figure two point one. There it is.
Let's see if it shows well on the camera.
So it's the diagram that you see on the slide.
Anyway, it is a layered design, but this one has a problem with the arrows.
In this is a common problem, I'm going to bring this up again when we talk about runtimes
views next week.
But in your design diagrams, you should avoid this: arrows that go both ways. This is.
Like a very, very common problem in design diagrams and what is the problem?If I draw.
Something like that.
I don't know if A uses B or B uses a, it's ambiguous.
So important recommendation, do not use double arrows,which are there typically because
the the person creating the diagram wants to show data flow, you should use a single
arrow for control flow.
What I'm trying to say is often times people do this, they draw a and they know a calls
B, so they draw this a calls b,but then they stop and think, Oh, but he calls B, B will
process and send results back to A, like the response, the return.
And then because of that in their mind, they need to put a second arrow.
No, you do not need that second arrow to indicate that there's data going one way and the
other.
Use the arrow direction to indicate the direction of the call, not to indicate the
direction of the data going between software elements.
It is implicit that when you make this call, you can pass on data like input arguments
and there will be return arguments.
You don't need to use double arrows because the double arrows make the diagram be
ambiguous.
Now I'm criticizing the diagram in a classic book, but I should say this is an excellent
book.
I mean, it's too old now, less relevant because it talks about technology from the 80s. But in the book author's defense, in 1986 nobody knew what was software architecture.

OK, and we didn't know about these good practices. In any case, I am criticizing the diagram.
But can I create a better rendition of the same diagram, well I can try?

[Picture 7] And here it is.
So if you compare this, this is the same diagram.
But in this case, I used a diagram tool that has color, so it looks prettier because of
that.
I wonder how so this is probably done with the ruler and a pencil and maybe a
typewriter.
So anyway, but here you see, I have a single type of arrow allowed to use and
look,there's this dashed line saying, this is the user level, this the kernel level.
I did that with the color key.
So user level layer and kernel level layer.
And in some places it was ambiguous.
Process control subsystem interacts with the file subsystem, but which one uses the
other?Well, I have the answer here.
This is clear.
It's the process control subsystem that uses the file subsystem.
It's clear in the diagram, but I had to read through the explanation in the book to find that out.
So anyway, we should try to create expressive diagrams without ambiguity and mind. Please do mind the recommendations that I presented in this lecture.
And there you go.
So we'll talk more about module views in the next video.

[junsoopark]

[MVC, data model] Hello.
This is the last video of week two.
We'll talk about the MVC style and data models.
[Agenda]

[Model-View-Controller style]
MVC is model view controller, and it is a well-known architecture style. Typically used in programs that have user interface, oftentimes a graphical user
interface or a web UI.
And it prescribes three types of elements when you create a design that follows the MVC
style.
You will create at least one model element, at least one view element, at least one
controller element.
But there might be several model elements, several view elements and several controller
elements.
We will explain the relations between these elements in the next slide.
And these are the typical constraints the view depends on model.
That means the View knows about the model and the View may know about the controller. And the controller depends on models, so the controller has syntactic references to the
model where it gets data,access its data and may depend on view, and the model does not
depend on view or controller. It is independent.
And if you're familiar with MVC.
Let me bring the question to you.
When you create an MVC architecture, are you creating a layered architecture, are model,
view, controller names of layers?Strictly speaking, the answer is no.
MVC is not layered because you don't have all the relations unidirectional. OK.
Having said that, many people who create MVC designs sometimes call, Oh, I have my mode
layer, my view layer. My controller layer.
That is not strictly speaking correct.
From an architecture point of view, so MVC is MVC, layered is another style.
l

[How MVC works]
So here's how it works in more detail.
This is for systems that have a database of sorts and have a user interface, the user
interface is the view, view elements.
So a given view, maybe a user screen showing purchase orders, the model elements
encapsulate application state so they the they have persisted data.
They might be classes that represent the the things that you have in the database. When you open the system, you will show the UI.
That means the view modules will query the model elements to get the data. And then the view can display the data, OK.
That's why we have this state query interaction here.
The View has, of course.
Buttons and other widgets on screen that the user clicks on to interact with the system. When the user clicks something, we have a user gesture.
That is sent to the system and will activate controller logic,so controller logic is all
the logic of including business logic to handle the actions performed by the user.
For example, a user may click to cancel a hotel reservation.
The View is displaying a hotel reservation and got the data from the model element, and
there is a button to cancel the reservation.
So when the user clicks that the user gesture is processed by the controller, the
controller element has the business logic.
The application behavior will process that request the user gesture and will change the
data in the database by interacting with the model element. So that's why we have this arrow here.
State change.
As a result of processing your user gesture,the controller may do this view selection interaction that is communicating to the viewhappened so that the UI can move on to another screen or refresh whatever it's showing.
Now, when we change data in the database that is interacting with the model element,the model elements, uh, in some situations, send out notifications.
So if you have a reservation that got canceled the model element that performs,that data change will send an event to the system, saying reservation one two three four was canceled.
That notification is sometimes of interest to the view.

So that's why we have this kind of arrow here saying there was a change andI'm notifying anyone, and the view gets that notification and will refresh the screen.
So this is how these elements interplay.
MVC was originally developed for small talk programs.

[MVC has several variations]
This is a, Smalltalk is a programing language and wasused to create the first generation
of graphical user interface applications.
And since small talk MVC was used in different frameworks for GUI applications, Java
swing as an example.
And these days, it's widely used in web applications. There are many variations of MVC.
Sometimes people change the layers a little bit.
So this MVP model view presenter, or MVVM model View View model, there's MVA Model V
adapter,and here's some examples of frameworks that use MVC or one of the variations. So, Spring, part of the Java world, ASP.
NET MVC framework, there's Angular,which is JavaScript or TypeScript, Ruby on Rails, and
Django.
The Django Framework, which is in Python.

[MVC style example]
And here's an example of a design that follows the MVC style.
This is a project I worked on in the 2000s when I was a researcher, a full time
researcher at the Software Engineering Institute.
We created an application based on the Eclipse IDE.
So we created several views.
These were views displaying lists of things or things in trees and sometimes an editor,
and we would get the data from the database. So this this is the view in eclipse.
So windows that are showing in the IDE.
And when someone clicks something, there would be a UI event,that UI event was captured
by the Eclipse UI event manager, which is part of the Eclipse IDE.
And Eclipse would redirect that event to an action handler, this is our controller
elements.
So the action handlers, this is the term we use in Eclipse plug-in development, but the
action handlers correspond to the controller in MVC.
They had the logic to process the user action and in doing so, it would possibly change
data.
So all the data was sort of in the back end, all inside the same program, but it was
handled by these other elements over here.
We would store the data in a kind of rules engine called Jess that had all the data, and
when things changed here, there would be notifications.
So if you look at the notation key down below, the solid line with the hollow arrowhead
is sending events.
So in any case, an abstraction that is correct is that all of these form the model. So.
When data changed here, the views would be notified and would refresh the screen.

[Agenda]
So that is the MVC style, and the last topic of week two is data model.

[Data model]
And here we are in the world of databases, systems that require large databases,
oftentimes relational databases, but not necessarily.
These could be enterprise applications.
Different kinds of data centric systems and a data model shows the structure of the data
that is manipulated in the system.
So the elements are the data entities. Such as customer, product, etc.
And relations that we show in a data model are one to one relationship between data
entities.
One to many and many to many relationships.
Sometimes you show generalization or specialization and sometimes you show aggregation,
but most of the times we focus on these relationships here. Here's an interesting question.
If we think that data model is an architecture view, is it a module view?Or is it some
other kind of view? I'm asking that question because some people who work with database systems create data models as something separate.
There's a data model on one side and then there's sort of the software architecture on the other side.
Well, let me say this.
The data model is a legitimate architecture view.
Then there's the other question, is it a module view? Is it somewhat a kind of view?Well, that is debatable.
In fact, when we were writing the book, we had that discussion.
I wrote a technical report published by the SEI discussing exactly that before the book, and that was input to the book.
So if you want to see that discussion, you can take a look at Section 9. 1 of that technical report.
I have the reference here.
However, whether the data model is a model view or an allocation view or some other kind
of view, it doesn't matter.
The important thing is if your system deals with a variety of data entities and you take
time to model the data entities and their relationships,therefore, you're creating a data model, you should think of it as a piece of design that is part of your software

architecture. OK.
So don't worry much about the classification.
And by the way, you may have noticed that in our agenda list here, I show data model and
it's not like sub bullet of module views.

[Agenda] OK.
It could be, but in practice it doesn't matter much. OK.

[Data model]

[Data Model example - Pet Shop . NET application]
It's abstract.
Here's an example.
This is the data model of the Pet Shop dot net application, very old example.
It uses an old notation known as Information Engineering, and you have the data entities
here.
So there's a purchase order in this notation.
We have this symbol here.
This is the relationship, and we know this is one too many. So one order has many line items.
So product shows up in many items of purchase orders. So it's one too many as well.
Suppliers, a company may supply many items, and so on and so forth.
So you have these relationships and there are some details here and in each box. So there's the name of the entity and then you have the different attributes.
So it's focusing on data, right?By the way, out of curiosity, this relationship here
that I highlighted. If you have.
For example, you know, let's pick that example order. And then.
Here we have. Order item.
One order has many order items, so we do this. So this this symbol here.
How do you call it?In the U. S.
, it's called. Crow's Foot.
And in Brazil, this is a curious part of the commentary.
We don't have crows, so we call that chicken foot.
So I wonder if there are crows in Korea, crows or ravens or similar birds.
I like chicken better than crows, and I like crows better than ravens.
But that is a football reference because I'm a Pittsburgh Steelers fan and one of the

rivals of the Pittsburgh Steelers is the Baltimore Ravens.
Moving on, so this is an example of a data model, very traditional kind of diagram and
uh,this kind of diagram was created in the late 70s and became popular in the 80s.

[What is the data model good for?]
And ever since, it has been used for many things.
So it is the blueprints to create the physical database.
And the data model serves as input to define schemas used in APIs and message exchanges
as well.
So that's why we have this notional diagram here.
So this elicitation of data entities helps to define the structure of the database and
also the structure of messages that send data back and forth.
The data model is also input to normalization.
That's when you try to get your database in the first normal form, second normal form,
third normal form.
So this is a data modeling technique.
Third, normal form and so on.
They also help to assess performance in data centric systems.
Sometimes you flex the normalization by merging entities by creating derived attributes,
indexing.
Defining the locking type.
So do you lock a single row?Do you lock a page on disk, the whole table?So these are all performance related questions for large databases and understanding the structure, like in the data model helps in that performance.
discussion.
The data model is, of course, a useful reference for developers.
that are creating code that access the database, and it helps with modifiability,impact analysis.
So, when you want to change a data entity, you know what are the relationships.
So there are other entities that might be affected.
As I said, the data model has been used in this kind of environment for decades.

[From data model to domain model]
It's a well known kind of architectural view or a modeling technique.
But in this century, the practice has shifted, has shifted from creating data models to
creating domain models.
The main difference is that the data model is focused on the data on the attributes of
the entities, and the domainModel has the data, but it's focused on the behavior, the
operations, the business logic.
Exposed by the data entities, and another practical difference is that traditional data
models tend to be more centralized than the domain models.
So in the old days, like in the 80s, the there was this vision.
This goal to create enterprise data models.
These would be data models that would show all the entities of a company of all,all the
information systems, if you will, and show the relationships, et cetera.
The goal there was to avoid data replication, avoid inconsistencies.
And little by little people realized that trying to create a centralized datamodel that
is super large and it's shared by multiple applications in practice. Brings more trouble than benefits.
The trend today is to create independent data models.
One per application or the term that people use these days is one per bounded context. And instead of a data mode, you create the domain models.
So not a single enterprise wide domain model, but several domain models. If and if you don't believe me, here's someone saying that at a conference. That person is saying no enterprise model, no shared database structure. There are always multiple models.
It's very hard to recognize, but this is Eric Evans giving a talk at the QCon Conference
in London.
So we create a domain model for each application or each bounded context,

[Domain-Driven Design]
bounded context is a term that comes from a domain modeling technique called domain
driven design.
And this technique was created by Eric Evans.
He published a book in 2003 that has become known as the Blue Book of DDD.
And again, DDD is a technique that will guide you to create the domain model, and it
prescribes several types of elements.
So if you're doing DDD modeling, you will model several entities value objects,
repositories, aggregates,etc.
And this is at the fine grain level called the tactical level, and the coarse-grain level, higher level of abstractionYou will create a bounded context, domain models, etc.
So this is what DDD calls the strategic level.
But don't worry, learning DDD is out of scope for our course.
I just wanted to mention this because it has become a popular topics topic since the
popularity of microservices.
But you don't need to learn DDD for our course.
You don't need to learn DDD for our studio project.
But if you want to learn more about DDD, I mentioned the blue book by Eric Evans, but I
think, this is my personal opinion,These other two books are better sources. This is by Vaughn Vernon and this is by Nick Tune and ScottI think Millet.
And here's something interesting when you do DDD modeling.

[DDD leads to a layered design]
Naturally, your code gets organized in layers.
So DDD prescribes the creation of an application layer where you find application
services, these are the types of modules inside that layer.
There's a domain layer where you find these other types of elements, and there's the
persistent layer, which can be any kind of database.
And up above, there's the UI layer, and there are actually other kinds of programs that
can interact with your application services.
So naturally, you create a layered design for each small application or in DDD terms,
each bounded context or B. C.
And in that case, one last comment.
The user interface of the application typically interacts with multiple BC's.
So this is typically on the server side.
So don't worry much about DDD for the sake of our class and for the sake of our project.
But if you want to learn more, let me know. And I'll see you in the videos for week three.

[junsoopark]

Hello.
In this video, we'll start our journey in the land of runtime views.
[Runtime views (C&C views), pipe-and-filter style]

[Agenda]
There's an introduction about runtime views and then we'll cover several runtime views. Architectural styles pipe and filter, rest and so on.
In this first video, we go all the way to pipe and filter style.

[Software architecture] Before we move on.
Remember our definition of software architecture.
It is a set of structures needed to reason about the system, which comprise software
elements, relations among them and properties of them both.
We already know that software has many structures, and we document these structures, as
architecture views.
In the previous week,we discussed module views of different kinds and they, they describe
the structure of the software system in terms of implementation units,the focus of the module views is the code.
The runtime views are different.

[Runtime views (aka C&C views) (1)]
They are also known as component and connector views.
You find that term in the book.
And these views show elements with a runtime presence.
More specifically, they show the components and their interaction mechanisms called
connectors.
If you remember, we said that in the terminology that we use in this training and in the
book.
Module is an implementation unit and a component is a runtime element.
So here are some examples of components: a REST service, a message queue consumer, bat
application,a process, a thread, an interceptor.
Data repositories are components of runtime views.
More modern components include a gRPC service, a GraphQL service, a Kafka consumer. There's also a ASP.
NET, ADO.
NET, and there are several types of connectors.
Regular procedure calls, an http call is a kind of connector, a TCP call is another kind
of connector,which, by the way, shows up in the reference implementation of the ALPR
system.
Pipes, queues topics are also connectors. They're used in one way interaction.
Shared memory can be seen as a kind of connector, a component writes to share memory or
other components.
Read from the shared memory database connectors of different kinds.
If you have a database, a component needs to interact with it,so that's a usually
platform specific connector or database specific connector and file I/O. Of course.
What else?

[Runtime views (aka C&C views) (2)] A component has ports.
This is the term we use to designate the points of interaction of a given component. They have they may have ports of different types.
And they may have multiple instances of a given port type. Port is a generic term.
OK, if you're talking about a component that listens to TCP communication, a port may
match a TCP port.
But in here, the port is a general term in the book the Clemmens, 10, uh,
textbook,there's a description of roles of connectors that connect to ports of components,We don't need that level of detail.
In practice, a description of components and identifying the ports is sufficient for architectural representation.
And here's something when we go to the white board or to miro or similar tools these days,and we start drawing boxes and lines to explain how the system works.
So maybe you go to the white board and you, you start drawing, Hey, there is.
I have my front end application here, it sends a request to Service X and it goes to the
database and then talks to Y and so on and so forth.
This kind of informal diagram, excuse me, that we create when we try to explain how the
system works, is a kind of runtime view.
OK, so we just gave it a name now, but it's not something strange. It's not something extraordinary.
A couple of recommendations.
When you're creating this kind of diagram, you should differentiate synchronous from
asynchronous calls.
As you know, a synchronous call is one that has a request.
And then there is the response you can think of, there is the call, and then there is the
return.
An asynch.
So this is oops.
An asynch call. Is one way.
So you send a message. And that's it.

You don't wait for a response, there is no response coming back.
Another thing that you should differentiate is local calls from remote calls,a local call
is an interaction between components that happens on the same machine or on the same VM
or on the same process or address space.
On the other hand, a remote call is a call that requires going over the network. As you have in a distributed system, excuse me.

[What do runtime views tell you]
So what do runtime views tell us, what do we use them for in general?Well, they explain
what are the main components of the system, the type of each one and how they
interact?They show us the data repositories that are part of the system. They explain or they highlight replication.
So having multiple instances of a given component is a runtime phenomenon.
You don't see that in a module view, which is static reflecting the code.
So if you have a component and there are multiple instances of it in the runtime view,you
can indicate that in a comment or there is the kind of universal convention when you
draw a component like this and you do this.
You indicating there are multiple instances of X, sometimes with a third one.
What components are used to process the request so you can understand the process
workflow?And what components participate as intermediaries? What is the lifecycle of a component?You may show that in runtime views, instantiation, deactivation, reactivation destruction.
Although, the runtime view,will typically depend on an an auxiliary diagram that we will discuss next week that more often isused to show lifecycle and that is a state machine diagram.
In what calls are local or remote.

[Runtime architecture styles]
In the book, we have this hierarchy of runtime architectural styles, so.
For runtime views often the view is named after the architectural style that is prevalent
in that particular view,so you may have a multi-tier view of System X Y Z.
You may have a publish subscribe view of a given system.
And so one, we're going to add the rest style to this diagram, and these are the styles
that we will discuss in more detail.

[Agenda]
We start with pipe and filter.
In this style, the component has a special name.

[Pipe-and-filter style]
It's the filter, and this is a component that has an input port.
It receives a message packet through the input port will process the data thatmessage
possibly altering the data and then will send the result to an output port.
The connector is called a pipe, which is a uni directional data conduit that has limited
capacity.
The pipe operates in first in first out manner, so it preserves the sequence of data
items.
A filter receives a message, processes that message, and sends it out through the output
port.
It goes through a pipe and then gets to the next filter that will process the. The new message.
In that sense, the filters run concurrently and the pipes are are just buffers between them, as illustrated down below generically.

[Pipe-and-filter topology] In terms of topology.
Well, we always connect a pipeTo the output port of the first filter, to the input port
of the next filter and then they form a pipeline.
So at a given moment, um, the first message will move on.
And when it reaches the other filters there, the different filters will be processing in
parallel.
A given a filter may have more than one input or output port.
What else? The design may or may not allow branching and merging, in this diagramHere you
see branching.
So there are two output ports.
A given message here that arrives may go this way or this other way after being
processed.
There is a condition in this case, and the design may or may not allow loops. And in this design, there is a loop.
This filter here sends the message after processing back to the first filter,possibly
with some condition and loops for a pipe and filter design are not a problem. We said that loops are problematic for module usage dependencies.
But that's not the case here.
Here we're talking about a different type of element, a different type of relation.

[Pipe-and-filter uses and benefits] Uses and benefits.
Commonly used in data transformation systems when you need to send a message that goes through several transformations,filters are loosely coupled and can be combined in
different topologies.
If you think.
If you have a filter G and then there is a pipe, let's try this way.
And then it goes to filter F.
OK, so a message X that arrives here,what the processing that we are doing corresponds to applying function f to the result of applying function G to X in that sense,is it it
looks like function composition.
And so we promote composability, enables reuse and can help to increase throughput because you're processing things in parallel.

[Pipe-and-filter in UML]
How can you represent pipe and filter, well in UML, this is an alternative.
UML has no built in symbols or labels or stereotypes for pipe and filter.
What you can do is in UML, there is a symbol for component, which is a regular box
rectangle with this adornment.
Here that you see down below, then you just add a stereotype to specialize the type of
component in this case,we're doing that and saying filter for pipe hereWe are also just using a stereotype for the association between the components here and we are indicating for the ports.
And by the way, UML has that symbol, which is a rectangle that you draw on on the border of a component.
This is a port.
So we have, and then you can label the ports, output, input.
And excuse me.
And you can complement the stereotype with several properties in comments.
These are the tag values, we saw that diagram we, when we mentioned how UML is extensible.

[Pipe-and-filter example]
And here's a different example not using UML, this is using informal notation.
You see the symbols for the filters and then the symbol for the pipes.
This diagram, by the way, was created a long time ago using a tool called Acme Studio,
developed at the School of Computer Science at Carnegie Mellon. And you had the symbols for pipe and filters.
You could just adjust them to your use.
But this is processing records of students.
You would go through this first filter and then you would check some condition and then
send the records.
This filter or this other filter and.
Checking prerequisites of a given that a given student has each filter here would send
that to this other filter accepted or rejected.
And if it's accepted, it would go to a format filter, sort filter and then accepted file
for the rejected the students.
This is for registration in a given class, and the records would end up in the rejected
file.
And you may say, well, the database is not a filter.
Yes, of course.
So very often we combine a given architectural style with other elements from other
styles when we create an actual architectural view.
So architecture views showing runtime, that means runtime views may show multiple
architectural styles. OK.
That's it for this lecture.

[junsoopark]

[REST - Representational State Transfer]
Rest is an acronym representational state transfer. And it was first described by Roy Fielding in his Ph. D.
dissertation.
Fielding studied at the University of California in Irvine.
In his mentor was Richard Taylor, who is a well-known academic in the field of software
architecture.
Therefore, Fielding wrote a dissertation that describes an architectural style with
architectural constraints,discusses trade offs, has diagrams with notation keys, so we
have that benefit.
In this discussion, I'll go over the basics of rest.
And if you are familiar with rest because it's a popular, popular architectural style. Just bear with me for a few minutes.
But here's how it works.
It is a client server interaction using httpThe client sends http requests to a given URL
using HTTP GET HTTP POST, etc.
The rest service will process the request and send back an HTTP response.
The response contains the data in the response body, may have headers, and it has a
status code 200 for success 400 for a syntax error. And so on.
Both request and response messages, as I mentioned, contain headers and the body. And here's something interesting.
The primordial example of.
The rest style is the world wide web since its beginning, when you would open your
browser and in the beginning was Netscape Navigator. You would type in a URL.
The browser in that case is the client that HTTP request.
It's a GET request will go to some web server where you have some component, and we can
call it a REST service that will respond with. In the old days would be basically the HTML.
OK, more information about rest, an important concept is a resource.
[REST basics in an example]
What is that? Any piece of information that matters to the system? Imagine a weather
forecast system.
In that case, the current weather for the ZIP code one five two one nine is an example of
resource temperature.
Averages for the city of Pittsburgh in May is a different resource, by the way. Temperature averages for the city of Pittsburgh in June is yet a different resource. Rest also tells you that for each resource, there's going to be a resource URI.
And here's some examples.
This first resource could be www.
myweather.
com slash current slash zip slash one five two one ninefour the second resource the URI
could be my weather dot com slash averages slash city slash Pittsburgh question mark. Month equals five.
When we say question mark, we are. It's another way to pass data on a URL.
These are.
So what we have after the question mark is a query string parameter. And by the way, I said URI.
There's a distinction between URL.
Uniform Resource Locator and URI.
Uniform Resource Identifier, strictly speaking when you are implementing these things. The URI is, for example, just this part.
Where is this? So this is the URI, the URL, is the whole thing.
But for the sake of this discussion, it doesn't matter, you can think of URL or URIEach
resource has a URI slash URL.
What else? REST also asks that you define for each resource a representation, what is
that? It is the data for the resource.
This data typically uses a machine readable format, such as JSON or XML. Here's an example.
This could be the JSON representation for the first resource current weather zip code. And then you have Celsius 12 degrees.
All right.
Then what do you do with the resources and the URI, how do you interact with the

system?And here's the, uh, the insight, or here's how rest is different.
You interact with the system with the rest of service via the HTTP operations. So if you want to create that resource, if you want to add that resource to the
system,you do HTTP post to the URL of that resource and you pass on in the request body
the representation of the resource.
If you are reading retrieving the data you do http get, if you are updating, you can do
httpput, some other operations we use post.
There's http delete as well.
If you want to delete a resource from the system and there are other verbs, it's not only
post and get, not only post, get, put and delete.
A given rest service may expose any subset of the http verbs a rest service may have only
http get, though the service may offer http get in post. Another may offer http post only.
And so on.

[REST architecture constraints]
And Roy Fielding in his dissertation described the so-called architectural constraints of
the rest style.
First one client server so in essence, rest follows the client server style.
The client application might be the browser might be some other application these days. Oftentimes.
It's a mobile app or Web application.
Will talk to the REST service, which is in the client server side.
Then he mentions beyond the client server, the design can used a layered system. Here's the thing Roy Fielding was writing his dissertation in the late 90s.
Later, another term, became well-known for what he called layered system: multi-tier.
So, when you see layered system here.
Roy Fielding is talking about multi-tier systems where you have the you have the client. It talks to.
Some service.
And then the service can talk to another service in another tier and so on. There's then stateless and cache that we are going to cover in a minute. Uniform interface, which is this notion that the interface of the services are
homogeneous in thesense that they have a subset of the http verbs and code on demand that indicates thatthe response that comes with the data with the representation of the resource maycontain executable code that is common in browsers where you call a rest service,and it replies with data and JavaScript.
But for our discussion of rest services and even for the implementation in the project,

[REST constraints - stateless]
the two constraints that are possibly useful and have more impact in practice are
stateless and cache. So let's describe that.
The stateless constraint says that the service rest services should not keep
conversational sessions state between requests.
When you talk to a rest service, you will have state will have data when it's
processing.
Once it replies with the response, it doesn't keep any data on behalf of that client.
As a consequence, all information needed to process the request should be included in the
messages.
And this is common for Web sites interacting with the browser.
And my question to you is when you interact with the browser,the website knows more abou
you because the browser sends data and sometimes that data needs to be saved on the
client side.
Where is it typically saved on the browser? What file holds sometimes session state?If
you answered cookies, you are correct.
So cookies exist because of the stateless constraint.
And this constraint promotes availability and scalability.
Mainly because each service that is sitting there and waiting for a request can process
requests from anyone.
So you can have multiple instances of the same service if you had a state full service. What would happen? That service would be dedicated to say, Alice.
Alice is shopping, and it's interacting with a given instance of a REST service.
If you had 10 people shopping at the same time, you would need 10 instances.
And so on.
But this constraint may negatively affect performance and security,because you need to
send more data back and forth between the browser or between the client.
I should say, and the rest service.
There are design alternatives and technologies so that you don't need to send all the
session data, you send a session ID and then on the server side,the rest service gets that session ID and then retrieves data about that session from a fast kind of key value data store.
And if you are familiar with that, you probably thought about tools like Memcached and

Redis.
But we don't need to go there, another constraint is cache.

[REST constraints - cache]
What is that? Well, in some situations, the service consumer can keep a cache of the data
it retrieves.
So it's doing HTTP GET, and it retrieves data.
You can cache that data unless it's marked as uncacheable.
But it can cache that data next time the client application needs the same data. Get it from the cache.
There's no need to call the service.
This constraint reduces the average response time, because if you have a hit in the cache,it is super fast, but it may increase memory utilization, especially if the cache is in memory.
In may add complexity to the situation and create the risk of consuming stale data. Of course, if you cache data and the data changed on the server,and if you're reading
from the the cached data, you may read data that is out of date. That is stale data.
For our project, the ALPR system. Think if cache makes sense.
Now, when you're creating REST services, there are a set of design guidelines that help.

[REST API design guidelines]
This is beyond the description of the architectural style itself.
I thought I should talk about it because these are common guidelines for the rest API,and
it's useful for you to create rest APIs that people more easily interact with.
In general, when you creating a type of service, you can define some design standards. So these are design standards are organization specific or project specific, you can say
in the organization I work for called TCU.
TCU has a document created by a group of people, and it's known to all the developers. At least the ones who create rest services, and that document is the design standards for
creating rest APIs. OK.
Design standards can work like that.
And this is different from industry standards, which are specifications that are
published by an industry standards body like the W3C, OSASIS, OMG. And so on.
So in the next slides, what I'm going to do is just go over some typical rest API design standards,I'm not going to cover the whole space of what matters for rest API and what I'm gonna mentionis just like an example.
OK, and creating such design standards makes sense for other technologies, not only REST.

[URL formation]
So if you're standardizing your rest APIs, one thing that is typically a good idea is to
prescribe descriptive URIs.
What is that when you read the URI you know what it does.
So I have here a first example that is not OK.
You'd have myweather.
com slash avg slash and then in curly braces, this is a variable path variable.
So the actual URL will have the value here.
So maybe the actual URL is my weather dot com slash avg slash New York slash zero three. You look at that you URL and say, What is New York? Is it the city or is it the
state?What is zero three? You can't really tell, just looking at the actual URL, a descriptive,URI would be like this my weather dot com slash averages slash city and then the value slash month and then the value.
Another good practice use a query string parameter with a question mark and then a pair of attribute and value for pagination,for filtering attributes for the search criteria.
Don't use it.
Um, if you're describing the resource.
Use it for auxiliary things.
And if you go back a couple of slides, you're going to see that in the first in the rest basics slide,I had a question mark month equals month that is violating a good practice, by the way.
So here it's corrected. Um, for.
Multiple words you can use hyphen you can use underscore you can use camel keys, lowercase only underscore is not a good idea in general,but hyphen is widely accepted and for your resources, use either singular or plural for the nouns, and resources typically correspond to things,therefore, nouns.
You choose plural or singular.
Most people suggest plural, but then you you use plural everywhere, even if you're
getting a single resource, use plural.

[HTTP methods]
What else? http methods there is get delete put patch head options, et cetera. There are good practices of when to use each method.
First thing is, you should use the methods to indicate the action.
Look at this example.
Get my weather. com slash.
Get current temp.
Look, you don't need to say get because it is the verb or the HTTP method that you're
going to apply.
The resource is the current temperature.
So this is better my weather.
com slash the current temperature.
And then you do http get on that you are.
So this is the typical recommendation you should use. Get for queries and read only operations.
No data should be modified on the resources in the server on the service.
PUT: that's for updates on resources in an itdempotent fashion.
And you may ask What is idempotent? Well, it is an operation that can be repeated, and
the effect will be the same.
So if you have a number and you multiply that number by zero, that is an idempotent
operation.
If you multiply a number by two.
That is not idempotent because if you repeat the same operation, the result will be
different unless the first number is zero.
Another example? Withdrawing $100 from an account is not an idempotent operation.
If you have $1000 in the account, and you withdraw one hundred, your balance goes down to
nine hundred if you withdraw,if you repeat the same operation, the balance will go down
to a hundred.
Right? Uh, an example of idempotent operation.
Pressing the alarm button on the vehicle, at least the vehicles I'm familiar with it. there's a button to lock the car, so locking the car iis idempotent using that device. The remote to lock the car is idempotent.
If you press, it's going to lock.

If you repeat, what's the end result the same? You can press multiple times.
If the remote for the car alarm had the single button to lock and unlock, then the
operation would be non idempotentand that would be a problem because you would press
once to lock, and then you're not sure if you, if it locked or not.
And you press again, if it was locked, it will become unlocked.
You see the problem, and that is a hint to sayidempotent operations are great for
reliability because if the client sendsan idempotent operation to the server and it's not sure that it worked fine,maybe because it timed out if it's idempotent the client can be safe to send the same request again.
So by convention, http put and http delete should be idempotent.
Then there is http Post, which is for creating a resource, can also be used for other
operations or resources,maybe some coarse grained business operation that it doesn't map to create, retrieve,update, delete something more complicated, like starting the process
of the.
The annual report that could be an http post anyway, post doesn't need to be idempotent. I'm saying that because some some literature about rest over there, they say POST is not
idempotent. Well, it can be.
If you can make post idempotent, good for you. It doesn't have to be by convention.
There is patch for a partial update.
And when you are going to update a few attributes of a given resource and it's not
necessarily idempotent.

[HTTP status codes]
What else? You can standardize the status codes, which is the code that comes in the
response indicating the result of the processing there. These are these are numbers are part of the http standard. OK? And the first recommendation is you should use them. Don't come up with your own codes.
Two hundred is the success, the default kind of success.
201 is successs for resource creation.
Specifically, when you do POST to create, say, a weather resource or to create a
customer,whatever, the response should be 201.
202 is success andPart of the processing will happen in the background asynchronously. Sometimes we call rest service, it will validate the request and will send 202 telling
you, OK, I got your request,I'm going to send it over to something else and part of the
processing will take will be taken care later.
204 is success, but the response body is empty.
This is typically used when you are doing your query and there are no records. Let's say you are sending http getto a web store service to retrieve all the purchase
orders by Paulo in November 2021.
If I didn't buy anything, the response will be empty, but that's still success. There was no error processing the request.
You can use 204 in that case.
400 This is an error all the 400s indicate an error and the client is to blame.
The error was caused because the input had some issue.
Four hundred is typically the request is not valid.
There is a syntax error in the request or the request body.
401, you don't have permission or you don't have the authentication credentials, so it's
a 401 is an authentication issue. 403 is an authorization issue.
You are authenticated, but you don't have the permission. 404, I always forget what is that? Yes, this is the famous. Resource not found, 404 is not page, not found.
It is page not found.
If the resource is a web page, but in general 404 is resource not found, 415. Um, excuse me, the content type header is unsupported.

So you asking for the data in XML in the service can only reply in JSON, for example, so I can give you that error.
422,This is a status code that many organizations use to indicate some business error or some business logic error.
For example, imagine a human resources system, you try to call a rest service to schedule vacation,and the date of your vacation is in the past that violates business logic
rule.
So you can you could reply with 422, and all the 500 errors, um, represent a problem that occurred on the server side.
So the server, something on the server side, didn't work.
In our REST services,The only code that actually makes sense is five zero zero, which we can use for unexpected errors when processing the request.
For example, your program ran out of memory, there was a null pointer exception, something like that.
Sometimes the client gets other 500 errors, for example, 502, which is bad gateway, 503 is service is unavailable, 504It's the Gateway timeout, but these other errors are typically replied by elements of the infrastructure, not your application rest service.
There is a, excuse me, a proxy or a router, something on the server side that directs the calls and it couldn't find your REST service,so it may reply with one of those errors.

[Picture 3]
Oh, here's something curious.
Short story years ago. Oh, 2017.
I was teaching a class, and I was covering REST services and I was talking about HTTP
status codes.
I was in Washington, D.
C.
, teaching a class for the Software Engineering Institute to an organization over there. And usually when I'm I travel to, oh, that was before COVID, but I used to travel and
then.
At night, I would get food somewhere and eat in the hotel room or ask for room service,so
that day I got some pizza someplace, took it to my hotel and in the evening it was
eating my pizza and I turned on the TV. And in the U.
S.
there is a show called called Jeopardy.
Used to be presented by Alex Trebek, and he passed big loss for the entertainment world,
but Jeopardy is a quiz game.
And in that game, there are three competitors, and they need to give answers to the
questions, but the way it is, the the the panel shows the answer. And you have to guess the question.
So, there are categories and there is, for example, categories capitals of the world and
then it shows.
Seoul and the competitors have to press a button.
Be quick, and then they can say, what is South Korea?Sorry.
What is South Korea's capital? That would be the proper question anyway. And at the end of the show, there is one question called Final Jeopardy.
It's the most important question.
And it works different because the contestants are all shown the same.
What would be the answer? And they need to write down what is the question in hiding?And
they have a few seconds to do that, they think.
And then the music plays and I have that music here. I don't know if it's going to go in the video.

And if you watched the show, you may recognize that's that little song.
And then they review their answer, and they have they had the opportunity to bet the
money that they had accumulatedso that they can double their earnings and maybe become
the champion of that day.
Anyway, long story short, sorry about that.
The thing is, look at this coincidence that day Jeopardy. It's the most importantAnd I talked about status codes. I was watching Jeopardy.
And this was the question.
I mean, the statement there an homage to a 1953 novel.
This number appears as an error code when a user tries to access a web page with censored content.
Do you know the answer? What is four fifty one?And I was wow, I went on to look on Wikipedia.
And indeed, here's an explanation from Wikipedia.
While more common status codes are 404, 403, 401, 500,There is 451.
It's a more recently approved error status code in the http protocol, and the number was picked as a reference to Ray Bradbury's book called.
Fahrenheit 451, here's the book cover, so it's a recent status code standardized in 2016.
By the way, you may have read the book or you may have seen the movie.
There is a reasonably recent remake of the movie Fahrenheit 451, and it's one of the
first movies by Michael B.
Jordan, now very famous actor.
OK, just to wrap up the idea of status codes, how does it translate to code the if you
are standardizing, you want to create some sort of library,

[@ExceptionHandler(BusinessException. class) @responsebody.
.
.
]
some sort of implementation mechanism for exception handling so that different types of
exceptions generate the same status code.
You standardize the status code and you standardize the format of the response body. I'm, what I'm showing here is just an example of what we have done at work and this is in
Java.
It's an old library and in that library using the Spring framework,you can create a
method and then you annotate it with @ExceptionHandler and then you indicate the
exception class.
So anywhere in my rest service, if the program raises a business exception, the execution
will stop here.
And this piece of program will generate the status code 422, which is the value of this
constant. OK.
And more important, the response body will be standardized, there's a standardized
structure, which is in this class here.
The same program that has this exception handler has several other exception handlers
that will generate other status codes,this exception handler has several other exception handlers that will generate other status codes,, which is the generic exception in
Java.
So this is like the catch all handler that is executed if none of the others more specific handlers get executed.
And sure enough, it generates 500, so internal server error is five hundred. And it also contains a standardized structure in the response body.
And this is this the structure of this class, ErrorInfo, we don't see what's inside.

[Questions? Paulo Merson pmerson@cmu. edu]
So that is it for rest.

[junsoopark]

[Peer-to-peer style, interceptors] Hello.
In this video, we'll talk about two things the peer to peer style and the interceptor pattern.
[Agenda]

[Peer-to-peer style]
Peer to peer is an architectural style where the components are called peers and they
interact primarily through or return calls on the network.
So it is an architecture style for distributed systems and there is no hierarchy between
the components.
They are all the same in the client server style. There is a hierarchy.
We didn't have a lecture about client server, but it's a well known style. So you have a server.
Component. And then.
You have client components.
And we know the client calls the server. The server never calls the client.
OK, so there is this sort of hierarchy.
They behave differently in peer to peer.
There will be multiple instances of the same component, the pews.
So we may have the peer instance number one, the peer instance number two, peer instance
number three. And so one.
At some point, Peter Easton's number one may call be released this number three some
time later. Oops.
Beauty, since No.
Three may call periods, there's no one.
And here are some examples of systems that used the view to be your style in the power
of their functionality.
Skype Whereby, which is a video conferencing tool that works on the browser if you go to
Whereby dot com, you see it.
Microsoft Teams, BitTorrent and Netflix Party, which is an application that my children
introduced to me during the pandemic.
Older systems that used peer to peer are listed down below.
Among them, an important one is Napster and I have here Shump Parker saying peer to peer
changed the music industry forever.

Well, I don't know if he ever said that. This is my speculation.
Who is Sean Parker? He is a major partner in the Mettler company.
After Zuckerberg, but before joining Facebook as an investor, he created Napster, and
Napster was,I think, the first file peer peer-to-peer network that became widely used
all around the world.
And a lot of people used Napster to share music files and b three files to anybecame so
popular that it affected sales of albums records in in audio CDs.
So the in the music industry had to adjust and adapt to the new world of digitized
songs.

[Topology and uses for P2P]
So topology and uses for future peer, well, the components are connected to a peer to
peer network.
And then they can cooperate, making calls or offering services to other components. They're all the same code, basically.
And there can be special nodes called ultra peers. Sometimes you call them ultra nodes or super nodes.
Well, they are basically the same program,but they recognize that they are running on a
machine that has larger capacity, maybe more disk space, more bandwidth.
So they the program switched to an ultra pure mode and then can connect to more piers or
offer more services.
Peer to peer networks are widely used for file sharing, voice over IP, instant messaging,
instant messaging and grid computing.
They offer great scalability and high availability.
You can add and remove nodes if one node goes down. No problem.
The same fi or resource may be provided by another peer.

[Peer-to-peer example]
You know, here's a simple example.
This is a node peer to peer network called the Gnutella network, and it does
differentiate older peers from regular peers,and they interact via request reply using
the Intel a protocol or DSP.
When this is for file sharing, so when a node wants to get the file from another node,
they communicate and then file transfer over. HP is started.
So there was the peer to peer style.

[Agenda]
If your architecture follows that style.
It's likely that you want to create a peer to peer review of your architecture. Now, moving on to something different.
The interceptor pattern in here I have David Wheeler.

[except for the problem of too many levels of. .
.
]
He was a professor at the University of Cambridge and became known for this quote. All problems in computer science can be solved by another level of engineer action. Oops! This is not a period.
There's a comma.
Oh yes, there's a compliment.
All problems in computer science can be solved by another level of interaction, except
for the problem of too many levels of interaction.
Why do we say here something about levels of interaction?

[Interceptor]
Because the interceptor is a special type of component that establishes a level of
interaction in the communication between two other components.
So the interceptor is a program, it's a component that sits between components A and B. Typically over the network and oftentimes B is a service or a is the client of the
service and A is going to call B and then there is an interceptor. So this would be the interceptor.
The call goes through the interceptor. The name helps.
What does this special component do?It listens to the communication in will intercept some messages and you can ask how does the interceptor know what message is to intercept?Well, in its configuration, we indicate well messages, usually by saying by using a network address or some URL.
So we can say this interceptor should get all the messages going to, let's say, LG dot com.
Slash.
My.
Slash star.
So all in this case, it's because going to the there's your else would be intercepted. What else? The interceptor itself does not have an interface.
That can be called explicitly.
What I'm saying is a component like a does not call the interceptor, the interceptor is
activated implicitly.
The interceptor, um, all around the different frameworks is also known as a filter, a
listener handler, you can think of it as a reverse proxy. Another term is service agent edge function as well.
And interceptors are typically implemented using platform specific APIs, and in the
general case,they can intercept the request and or the response messages they may or may not change the message.
So these are all options.
It depends.
And in the general keys, they have access to the entire message handlers and the body.
And look, the interceptor may be the messages going to a server to a service, but the interceptor itself is not a service.

Service is a component that sits there and accepts calls from other from clients and will respond to these calls.
The interceptor is listening to the communication and will intercept the messages can be the request message can be the response both in the enemy.
Just check the content.
It may change the contents and so on.
So you may be thinking, what do we use these interceptors for?

[What are interceptors used for?]
Well, here's a list of examples of things we can use the interceptors for logging the
calls transformation of the messages.
Maybe the message is has data in jaison format and you want to convert it to XML. You can convert the protocol, for example, from HD to G.
P.
S.
You can route the message.
You can do exception handling in this case,you're typically intercepting the response
and then you handle any problems that occurred whenprocessing the request because you're getting the response that might contain a problem.
Next action You can use these receptors to collect metrics for distributed tracing. That's a distributed system specific functionality to identify performance
issues,authentication and authorization and other security related processing can also
be done with interceptors.
I'll show you an example in a minute.
And circuit breaker, the circuit breaker that we discussed in week one can be
implemented as an interceptor.
So typically cross-cutting functionality or util like functionality.

[A design with interceptors]
What else? A design win interceptors can contain multiple interceptors configured in a
chain like this example.
Any see we use the green bar for the interceptor here, and the interceptor is a component
that can interact databases.
It can interact with other components itself.
So when it's processing, it could.
I mean, let's say hypothetically this, this is the routing interceptor.
It could make a call to some service to get some data and then do its thing.

[Where do interceptors run?]
Oftentimes when we talk about interceptors, people ask, yeah, but um, where do they
run?There are different options.
An interceptor can run inside the client program.
So you can configure the interceptor like a library gets compiled inside the Clyde
program,and then when there's a call, the interceptor will get that call.
The interceptor can be part of the cold component,which in notionally here saying this is a service so it can be part of the service compiled inside the service.
But the interceptor can be completely independent component that runs someplace else,some different process, some different components on the network.
So these are the runtime components, but if you think this could be running on one machine, there's going to be running on another machine.
And this could be running on a third machine.
And a variation of this last option is when you configure an interceptor as part of some
middleware platform that supports interceptors,an API gateway, a service mesh.
There are different kinds of of middleware products that operate like interceptors. OK.
By the way, here's a question for you. We just erased this.
Looking at the four options that you see here.
Think of the circuit breaker that we discussed in week one.
If you were to implement a circuit breaker.
As an interceptor, which option among these four options would not work for a circuit
breaker.
Pause and think.
You could have the circuit breaker using all these options, except for this one. Why? Because the circuit breaker detects situation when the service is down.
If the circuit breaker is inside the service, it cannot detect anything because the
circuit breaker would be down along with the service. So he has to be one of the three other options.
And.

[Typical flow of execution for interceptors]
How does the implementation of an interception look like?Well, this is Pseudocode.
And.
This is a tip.
I'm going to show you using animation.
The typical flow of execution, but look, here we have the pseudocode of a service
consumer.
This is the client down below.
We have the Service X, Y Z and you can see that the client here is calling Service X Y Z
Dot some operation.
And we have some operation here.
So let's go over the animation.
There's some logic that executes before the service call and then step two is the service
call.
One would think that the next thing to execute is some operation down below. However, there is an interceptor.
The interceptor will get the call and look, it has access to the request and the
response at this moment. The response is empty.
Only the request exists.
And in step three, it can inspect or even change the request.
And then when it's done with the request,you will send it along to the service or to the
next interceptor in the chain if there are multiple interceptors. So that is done in this pseudocode in this code.
Proceed.
Well, then the service actually executes and will process the request.
Will generate the response and send it back to the client,but the interceptor also
intercepts the response at this point, it can expect or even change the response.
By the way, I didn't say before, but the interceptor may block the request.
OK, so in step three, you may decide that the request has some issue, doesn't have the
permission to execute and you may block the request.
So the service may not even get called at all.
But in this case, we're supposing that everything is fine and the interceptor is
intercepting the request,then it intercepts the response may just inspect or even change

the response.
And finally, the client gets the results.
OK, I'm going to give you a show, you are an example.

[class ValidateJwtTokenFilter : UsernamePasswordAuthenticationFilter. .
.
]
Real-World example of an interceptor again, the way you implement this will vary a lot depending on the framework, the programing language.
The one I'm showing you is implemented using the codling language and it uses this approach.
The interceptor is compiled inside the service, and this one is validating JWT tokens for rest calls.
JWT is a format for authentication tokens, so this is a an interceptor that helps with security to make sure that the caller is authenticated.
So here's the the interceptor code.
I mean, simplified and on I am omitting some lines of code do filter.
This is actually part of the API.
You need to give the function this name the filter, and you see it receives the request
and the response and also achieve. So it tests.
Some condition in over here, it does some processing on the request, extracting the
toxin.
Then it will validate the toxin.
If everything is OK, it will set some security context indicating to the service who is
the authenticated user and then it will call chain to filter.
So this last call here is equivalent to proceed in my pseudocode in the previous slide.
And as you can guess, this interceptor does not do anything when processing the response
when he could.
I just had to add code over here rafted right after the change. Do filter call.
OK.
Let's discuss the trade offs of using interceptors in general benefits.

[Impact of using interceptors]
Well, the cross-cutting functionality gets implemented in a single element the
interceptor.
And as such, it's highly reusable.
So if you have an interceptor that does logging, you can have, for example, 20 different
surfaces.
You do not need to implement logging in the logic of the 20 services, you place the
interceptor in front of the Subsys and. In a single place, you do the logging.
This is a benefit with respect to modify ability.
Another benefit with respect to modify ability as well is the logic of the Subsys does
not get tangled with the cross-cutting logic.
Let me go back to the example I just mentioned logging logic. If I didn't have the interceptor might do any business.
Logic services would have the business logic in.
At some point I needed code to do logging.
So that code makes the logic, the business logic, slightly less readable.
Let's say you have a service that is responsible for processing images.
What you want in that service is the business logic to process images.
If you have to add lines of code to take care of logging, security controls, transaction
management, auditing, etc.
Well, the business logic gets tangled mixed with this, other auxiliary things and such. The business logic becomes less readable, so you don't have that problem with the
interceptors because the cross-cutting logic.
Is moved to the interceptors challenges, interceptors may generate coupling to a given
framework or platform because they usually. Are implemented using some API.
So there's some vendor lock in. They may become spots.
What is a spoof? Single point of failure, or they may become a bottleneck for
performance if they don't behave properly. So when you design you an interceptor.
Think if if it's sitting in front of many surfaces, it may be getting a lot of calls. So they need to be super fast and have high availability.

You may have multiple instances of the interceptors, especially if the interceptor is an independent component.
If it's compiled inside the service, then it's less of a problem. And remember, they require governance.
It is a first class citizen in the architecture.
So who is the custodian of the interceptor? Is there a versione mechanism?Are we
monitoring that intercept or is behaving well? So this is important. That's a challenge.
And look, I'm saying these are challenges.
They are not problems, OK? They are not disadvantages, necessarily.

[Another challenge of interceptors]
And there's another challenge, interesting one look. With interceptors.
That functionality is removed from the service.
And what happens, developers may not be aware of the existence of the interceptors.
They may be oblivious, not knowing that the interceptor is there.
For example, maybe someone new in the team is doing maintenance in the service that does
image processing and looking at the logic that person thinks,Wow, we should be logging
these executions of the service.
Then that person thinks, Oh, I'm going to add the logic for the service to log all the
requests.
That was not necessary because there was already an interceptor taking care of logging. OK, so this is a challenge in this challenge, by the way, resembles a challenge that
exists in a development paradigm that became widely known,well known around 20 25 years
ago in that development paradigm is code. You may have heard of it.
AOP aspect oriented programing.
In a sense, an aspect is like an interceptor at the code level, at a single VM level.
So you know, you'll be they had the same challenge and they called it obliviousness.
So when you were working on a service? The depths that developers should be aware that
there are interceptors.
So you should show the interceptors clearly in your software architecture. They are components and.
You should use a different symbol because they are a different type of component. That's it for interceptors.

[Questions? Paulo Merson pmerson@cmu. edu]

[junsoopark]

[Publish-subscribe]
Hi again, this lecture is about publish, subscribe.
[Agenda]
And it is another runtime view architecture style.
So if you create a software design that uses publish, subscribe for much of the
interaction among components,that architecture view could be your publish, subscribe view of System X or of Subsystem Z and so on.

[Publish-subscribe style]
In this architectural style, you have publisher components and subscriber components. These are your application components that you're going to create,and they will interact
with the assistance of an infrastructure component, which is the event bus also known as
event manager.
The event bus has different ports that you see down below.
Sometimes the subscribers need to subscribe to the port, to the events explicitly, excuse
me, and for that, they use the Subscribe port.
And then publishers and subscribers are running, and what happens. A publisher component will send events out.
These events go to the event bus.
The event bus will deliver the events to all of the subscribers.
Therefore, the publishers don't know about the subscribers in the subscribers, don't know
about the publishers.
They only see the events that they send to or the events that they receive from the event
bus.
In distributed systems, as we're going to discuss later in this lecture, excuse me, the
event bus is typically called message broker,and it's a specialized product on the network that can receive events or messages and then deliver the messages to the subscribers.
Kafka is a popular message broker.
Topology and uses for the publish subscribe style.

[Topology and uses for publish-subscribe]
Well, publishers are subscribers only interact through the event, but they don't know. They don't call each other.
They don't know about each other.
A given publisher can be the subscriber to other events.
Often times a subscriber receives an event.
When processing that event will publish another event that is normal.
A publisher may or may not be blocked when sending an event.
If this is a network interaction, likely it won't be blocked.
And the time a subscriber subscribes to an event that is what we call the registration
varies sometimes a subscriber. Uh.
Is compiled as a subscriber to specific events, other times when the subscriber goes up,it does the registration at initialization time and other times the registration can occur at runtime.
So a given component can subscribe to some events, then unsubscribe and then subscribe to others and so on.
These, uh, this architectural style is often used to process commands in graphical user interfaces.
We see it in some implementations of the classic observer design pattern.
We see it in the interaction of model elements with view elements in MVC.
And you also see it in mailing lists when you write an email to a mailing list,you're
publishing an email and then, uh, the recipients that are part of the list are like the
subscribers.
Social networks are also oftentimes provide a form of social net of publish subscribe. You can have, uh, people who follow.
A given profile, and they get notifications, they get a feed of posts and so on.
And an important architectural pattern and for distributed systems these days is entirely
based on publish,subscribe and we will discuss that in the next video.
I'm talking about event driven architectures.
Push notifications that we get on the cell phone, for example, are also a variation of
publish subscribe. Here's an example.
This is in an application that already showed up in another lecture as an example of

MVC.

[Publish-subscribe example]
And if you remember, this is our the view elements and when the user clicks or does
something here on The View, the program will send out a UI event. The event manager is provided by the Eclipse platform.
Eclipse ID.
And the action handler are are the subscribers, they get the UI event.
In the same design, there is also published subscribe interaction between the model
elements here in the views.
So when things change here, fact data in memory, there is a mechanism for notifying the
views.
By the way, for the first interaction that I mentioned,the views get registered and
initialization time via a configuration file, which is indicated up above.

[Difference between pub-sub and point-to-point (1)]
Now we're talking about publish subscribe, excuse me for short. That is pub-sub.
But I should tell you, I've been to the UK a few times to teach this kind of topic in
over there, a pub is something different. So be advised.
Anyway, for us pub sub is publish subscribe.
And in the literature, there is a difference between pub sub and point to point. They're very similar.
They are the building blocks for messaging asynchronous messaging.
As we're going to point out in a minute, point to point is like this there is a standard
component that will send a message to a message queue. That's the point to point queue.
And then there will be a receiver component that will get the message. The important thing is a given message is received by only one receiver. This is point to point.
Publish subscribe is more flexible, if you will.

[Difference between pub-sub and point-to-point (2)] There is a sender component.
It is also called a publisher.
It will publish messages or events to the message queue. This message queue.
Sometimes it's called the topic and there will be many receiver components, and we know
we call them subscribers.
So a given message is delivered.
To all of the subscribers, so each subscriber gets a copy of the same message in,In this
example, we have a standard component publishing messages about new employees,so data
about a new employee goes to this queue and the same record.
The same message is received by the this component that creates the user count. The other component that creates that does resource provisioning.
And the last one that creates the payroll record.

[Asynchronous messaging]
So as I mentioned, point to point and pops up are the building blocks for asynchronous
messaging patterns.
In the next video, we'll look at other messaging patterns that complement these two and
very important pub sub is these days veryoften used in distributed systems where you
have a mix of rest system, rest services in a synchronous services. The asynchronous services interact via publish subscribe.
There are trade offs in that kind of interaction.
But it has.
It has become very popular in service oriented architectures and microservice based
solutions asan alternative to traditional HTTP and RPC synchronous interaction where you
have a request.
And then there is a response with asynchronous messaging, which is a generic term and
point to point or oub sub in particular. There is no response.
You send the message and it goes to the subscribers.

[Message queues] And when we have.
Publish subscribe, we have a message queue managed by the the component that we call the event bus or event manager,and that component, in case we are talking about a
distributed system on the network, is often a message broker.
So down below, I have examples of message brokers Apache Kafka, RabbitMQ, Apache has activeMQ Artemis, as well.
On Amazon, you have sns, you have sqs and there are some others. OK.
And in IOT Networks, there are some lightweight brokers that use the MQTT protocol. So MQTT brokers are example of message brokers that support, publish.
Subscribe.
And what is the queue or topic?It is an intermediary buffer.
It gets a message from the sender or producer or publisher and then holds thatmessage until it's delivered to the receivers or queue consumers or subscribers.
However, you want to call them, the queue typically operates in first in, first out session.
The queue has a name and it is located at runtime, so it is an element of the architecture.
You can think of the queue as a component or a connector.
It doesn't really matter, but you should show in the architecture.
And in the case of this system, the key was provided by a message broker.
And guess what? There are important configuration choices for these products for your
queues, I list here some examples the queue may be persisted.

[Message queue configuration]
That means saved to disk for increased reliability for systems that process large numbers
of messages or events.
You may have the queue partitioned to improve throughput so you define a queue for
purchase orders.
But in reality, there might be like five queues or five partitions of the same queue.
And in that case, first in first, first out is preserved within a partition message.
Brokers can be clusterized to improve availability and throughput,and then a given queue
or specifically a given queue partition can be replicated. And keep synchronized.
All of that has trade off to gain in availability.
But it may affect performance, and there are many options to tune performance against
consistency and so on.
For security, you can use encryption, for example.
Kafka by default, will use plain text for the messages,but you can't turn on encryption
using tls for the communication between producer andthe message broker for the communication between the message broker and the consumers,and the communication amo servers in the cluster.
The cluster of message brokers and you can also set up, uh, requirements for authentication and authorization.
All of that will vary according to the product you were using.
n

[Example of distributed system that uses pub-sub]
Here's an example of a distributed system that uses pub sub. This diagram is from the pharmacy food architecture.
I already mentioned that in another lecture.
And over here you have a publisher,and it's sending events to inventory events and there
are three subscribers and they get the events and do some of the processing. Now you see that in this.
Design, there are other kinds of elements, there are other kinds of interactions, there
are rest calls.
So this solid line is an http call.
This is to remind us that an architecture view may show multiple architecture styles. This one is showing pub sub, but it's also showing other styles.

[@service open class ConsumerKafka(val handlerEmailMessage. .
.
]
And just to wrap up, I want to show you some code snippets. Of programs that send messages or receive messages.
I picked some examples from work.
Very simple.
And the message broker is Kafka in this case.
This is not relevant for your implementation in the project.
I just wanted to illustrate and try to show that this kind of implementation is quite
simple.
So up on top, you have a service which is a Kafka consumer.
We can tell by the name of the class and it has a function.
Listen, which is sitting there and waiting for messages.
So this is the subscriber, the receiver or the consumer of messages, and it's getting
messages from this topic.
Well, we can't see the actual name because it is coming from a configuration variable. But when he gets a message, this is the object message you call an auxiliary function
handler email message handle,which is down below, so handle here will get the message
which is in Jason, we will convert the message changes into an object. This object is of type.
Email dtoAnd we know that he has these attributes because then the the the object
created is referenced here.
So this is a message cue that gets messages that corresponds to email messages that
should be sent out.
So the receiver is a program that gets the message from the Kafka topic and translates
that into an email and sends out that email.
So the consumer here gets to the Kafka message and passes it and will extract andbuild an
email and send the email via the SMTP host as SMTP mail sender sent.
And then he gets the from address to address subject body, et cetera.
And look, this is the receiver implemented in Kotlin and using spring Kafka as the API.

[@component public class EmailSenderKafka { public. .
.
]
Look, here I have a sander of the same topic now implemented in Java,using the Apache Kafka API is a slightly different API and a different programing language.
So the program to send in this case, it looks like this it creates an object here.
Send email Kafka command, which corresponds to the data that goes in the message. Has subject, the destination email address is CC, BCC, etc.
and calls, emails sender Kafka Dot send with the message. In the email sender Kafka Sand is down below.
It will, uh.
Extract the message details from this object, create a jason representation of it. Instantiate an object, which is the producer.
This is part of the Apache Kafka API and with the producer,it will call send sending out
the message that was created by converting the object to Jason.
This is a different sender now in the groovy programing language and using spring Kafka. Similarly, it instantiate the the command, excuse me, and calls send on an email message
producer, which is down below.
This program is the one that actually sends the message in for that it uses an auxiliary
object called Kafka template.
It does template dot send.
And the instantiation has already obtained the name of the topic and the message comes
through the call here, and it was created up above.

[data class EmailDto(val version: Int, . .
.
]
OK.
I showed you the logic.
The API calls to receive a message to send a message.
But the point that I wanted to get to is, look, we had a Kotlin receiver and then we had two sender programs, one in Java and the other in Groovy.
This is a reminder that the publish subscribe interaction may happen between programs written using different languages or different platforms.
They don't.
They don't call each other directly because they only interact with the message brokeras long as they have an API to interact with the broker and they understand the name,they know the name of the topic and they know the structure of the messages that they are sending or receiving.
It all works.
And this is these are the classes describing the data structure of the messages and the data structure is the same.
Um, but here you see the different implementations on the receiver side. Here you have the implementation in Kotlin.
This is the Java center side implementation and it's seen Java, of course. And this is the groovy sender side.
Look, the.
The receiver side has all the attributes.
The sender doesn't have to have all the attributes if some attribute is optional. All right.
Don't worry too much about the code snippets here.
I just wanted to make it more real if you have any questions about that, interact with me
directly or via Piazza.

[Questions? Paulo Merson pmerson@cmu. edu]

[junsoopark]

Hello.
This is the last video about runtime views, c and c views.
[Other messaging patterns]
We'll talk about messaging patterns, so this lecture complements the discussion we had in
the previous lecture.

[Agenda]
Were we covered, publish subscribe.
We actually mentioned that asynchronous communication uses point to point or publish
subscribe interactions.
These are the basic patterns messaging parents, and now we will see some other patterns
that can be used in these kinds of solutions.

[Other messaging patterns]
There are several messaging patterns, some of them are listed here.
And many of them are described in Gregor Hohpe and Bobby Wolff's book Enterprise
Application Integration.
I showed that book in the previous lecture.
It is this half reference over here, and in this course, we will cover or mention just a few of them.

[Sync over Async]
We start with sync over async.
Which in Hohpe's book gets this name request reply.
However, I don't think that's a good name because it sounds too much like request
response or call return call reply. This is different.
The situation is you are using asynchronous communication, sending a message. Through a queue to a receiver or several receivers, the message gets processed, and at
the end, we want to send the results back to the original sender.
If you think it is like the overall transaction is synchronous in nature,but we use
asynchronous communication for that in the sense that we create one asynchronous queue for the beginningof the transaction and then a second asynchronous queue to transport
the results back to the original sender.
The there's an example down below imagine there's application a where it's taking purchase orders and there is this component.
Please order.
It sends a message to new orders.
Their message gets received by few order.
And this is a synchronous interaction.
We know it will activate some processing here.
We don't know this is part of application. Be filling the order at the end.
We want to send the results back to application a, so we create a separate queue and we send another message.
Look, these messages are purchase orders. And they get processed in different orders.
So there is no guarantee that the reply coming back the other way down belowwill arrive
in the same order that the orders arrived at the first queue up above. Therefore, we use a correlation identifier.
CI.
To identify each message going through the queue.
This is just a unique ID for, in this case, each purchase order. So we say CI 1234 for a given message.
When that one gets done, it gets processed.

One application, be the message that application B sends back is contains CI one two three four.
OK, so we use sync over async when we want to send the results of processing back to the original senderAnd we think using a separate asynchronous queue is a good idea.
However, if your requirement is just to communicate the results of processing, let's say, application B processing.
There are other alternatives because remember adding this second queue complicates the design.

[Alternatives to sync over async]
Alternatives would be you could save the results to a file or to a shared database.
So Application B could save something to some database and an application could read it. You could have a call to a service, a callback endpoint, then go back and slide.

[Sync over Async]
What would that be? An alternative design here would be.
Instead of having this queue, you could have.
A rest service here, and this program would call that rest service. This would be a callback endpoint in that case.
Email is an alternative and push notifications, so that's synch over asynch.

[Alternatives to sync over async]
What else? Let's look at a couple of patterns to improve reliability on the senders
side.

[Improving reliability (sender side)]
Remember when we have synchronous request response interaction, just like in the rest
callWe have some confidence that things were.
If you have the the the client component here and it makes a call to our service, there's
this request reply.
If the processing fails, if the service is unreachable right away, Component A finds
out.
If instead, we use asynchronous messaging.
What happens? A sends a message, but doesn't find out if the message got processed. This, um, there is a benefit, though, if in this case.
Component s is down.
This is rest, OK?If component s service s is down, this call doesn't work. With asynchronous messaging, if service s is down.
Sending a message to the queue.
Works fine.
The message will be queued up here.
Eventually, when s is back alive. You can get the message.
You see the difference.
However, what can we do if the sender cannot even connect with the remote message
broker?In this example, this message queue, if you think it's provided by a message
broker, you're mqtt broker, your Kafka broker.
What if a cannot even connect with this? Can we do anything about that?Yes, we can.
Before we move on and show a solution, do you know who is this person?You can see this is a very old picture.
This picture is over 100 years old.
This is famous writer. Franz Kafka.
And yes, the Kafka message broker product was named after him.

[Store and forward]
OK, so here's the solution or an alternative to that question.
It is the store and forward design pattern.
How does it work? Well, we have the message broker.
The main message broker, the remote message broker, that is here.
However, the client program, the sender doesn't send the messages to that message
broker.
Instead, it will send messages to a local message broker. And if you see the local message broker is running.
On the same VM on the same machine.
So the sender and the local message broker are on the same node, the same machine, the
same team.
Therefore, if one is running, likely the others up and running as well.
If we lose connectivity here, there is no problem because the sender program is sending a
message to the local queue.
If we lose connectivity, the message will queue up in the local broker.
When connection is reestablished, or the messages will be automatically forwarded to the
main message broker.

[Picture 2]
Just to illustrate, using an example of configuration in XML, this is for a product that
we used at work in the past,I think we still have a few applications in productions using this product.
It's called HornetQ.
It's a message broker by Red Hat.
And it supports what they call Jms Bridges, which is an implementation of the storing forward period.
So we cannot reconfigure a local queue by doing this. There's the queue name.
This is from work, so there's some words are Portuguese, monitoramento TCU local, in this local queuehere is configured to automatically forward all the messages to the Main Remote Queue,which is the other one down below.
And then we have all the configuration details and so on.
So the way this works and we go back the slide here, you see the dynamic is like this, the application will send a message.

[Store and forward]
To the local queue, the local queue automatically sends it to the message broker, which
automatically delivers the message to the receiver.
If one of the communication elements of the network fails, no problem. The previous queue will keep queuing up the messages.
So we increase reliability of the solution.

[Picture 2]
But you may say well,but this the tradeoff that we need to configure the whole message
broker on the same machine where I am running my standard program that. Sounds expensive.
A lot of trouble.
It might be, and then there's another option you can use the transactional outbox pattern
in this case instead of a local message broker.

[Transactional outbox]
You use a database table and in the pattern it's called the outbox table and a component
in the background that keeps reading that database table.
And that's called the message, relay? How does it work as illustrated here in this, you
amount like sequence diagram.
By the way, we'll talk about sequence diagrams in week four.
Here's the application center. It is processing a transaction.
It makes changes to the database and here saving a purchase.
Orders of business logic kind of data change.
And then it needs at this point here, it needs to send data to a receiver, which receiver
it needs to send data to fill order.
Look, please order will not send the message to the message broker. Instead, what it does is simply to insert a record in outbox.
Stable outlook stable.
Corresponds to the messages that we want to send to the message broker.
So the application just does insert into artwork stable in the data of the message, and
it's done.
It can then commit the transaction look in background.
There's the message relay program that is running in the loop and is periodically reading
the contents of the or the outbox stable.
It looks for records in the Outbox stable when he finds a record is it puts together a
messageand sends that message to the remote message broker and removes that line from
the outbox table.
And from there, the message goes to the ultimate receiver.
So there's a bonus benefit,which is the data changes corresponding to the business logic and sending a message whichis inserted into what box can be part of the same atomic transaction database transaction.
This note is correctly saying that transactional outbox is a form of story forward,both Barron's story forwards and transaction box help to increase reliability of the system on the Sanders side.

[Improving reliability (receiver side)]
We want to improve reliability on the receiver side as well.
One thing that can be done is the durable subscription, which is a configuration that
some message brokers allow.
And so that if a given subscriber is not up and running when the message was distributed
to the subscribers,there is no problem the message your broker will keep that message
later, when the subscriber gets back alive, it can receive the message.
In fact, products like Kafka can keep messages for weeks in the message queue in topic. And then when the receiver connects, you can tell, Hey, I stopped reading at this
position, that's the offset.
And then you can get all the messages that it missed when he was not running.
But there's durable subscription, but that doesn't solve the whole problem.
There's a situation which is illustrated by this mad postman.
What to do if the receiver receives a message with invalid format or structure and and it
can't process it?And look, remember, the message queue operates in fearful fashion. Remember if we had say a.
Sending a message. To be.
Gets a message it tries to process, it tries to pass the message.
It throws an exception, depending on the technology, what happens?The message is not was
not consumed.
So it goes back to the Q and then a new delivery is attempted.
If fails, just like before the message goes back to the Q, you may end up in an infinite
loop in the the queue doesn't move anymore. So we don't want that.
Before we look at the pattern, here is a term from the dictionary, that letter.
It's a letter that cannot be delivered or returned by the Post Office because of an
incorrect address or the problem.
I believe that term inspired the name of the Banner Dead letter channel.

[Dead letter channel]
What is this? It is a pattern that will solve the issue that I just mentioned. Look, how does it work? There is the the topic here.
New orders.
The message goes to the receiver, but let's say this message has a problem and it cannot
be processed.
The message gets returned to the Q in Re delivered up to in times there is a limitafter
that automatically that message with a problem goes to this auxiliary Q.
This order Q is called the dead letter Q the L Q.
So there's new orders, then there's orders, the elk in the organization we have the
proper name would be new. Borders docu.
When we have a y X-Y-Z in, we created the deal Q for it, we always do this x y z dash
the Q, that's a convention that we use.
But anyway, that way, the system can move on to process the next message because the bad
message is out of the way. But it was not discarded.
Another option would be just that's just ignore. Throw away that message.
Well, what if it is an important message?Maybe one of the bites got flipped, corrupted, but we still want to know what's in that message,we can't afford to discard the message in that situation.
We used a dead letter channel buried in created that letter.
Q OK, now the dead letter Q is supposed to have.
How many messages do you think? Add in if everything is working fine, the dead letter Q
is supposed to be empty.
All the messages go through the main queue, so the main queue may receive if you look at
it.
If you had like a viewer here, if you could inspect at runtime.
What's in here? This this was supposed to be and I am sorry.
You would see zero messages and then there's one message and then he gets delivered to
you back to zero,maybe two messages, three messages, then to them one.
The message just go temporarily here.
If the receiver is slow, you may have one two three four five.

But then when it picks up speed, then you go back to zero, etc.
But the dead letter Q if everything goes OK, has zero messages at all times.
If there is a message in the deadly Q, something bad happened.
So we need to notify the custodian someone responsible and then that person will maybe
open a program likethis one dead message receiver to get the messages from the dead
letter Q and possibly process them manually. OK.
Message brokers.
May not provide that that letter Q feature out of the box.
In that case, you can still have that there accused, but you need to implement it on the
receiver side, you know, give you an example. Kafka itself could be erased this mess here. Uh, Kafka doesn't provide that letter.
Q.
What can you do?You can create a.
You can configure a library on the receiver side that operates here when themessage arrives and if there is a problem with the message in the library,will itself send the message to the dead letter Q.

[In distributed systems, when given the choice, choose. .
.
]
That concludes the other message, you Barnum's the compliment.
Point to point in publish subscribe before we finish, I just wanted to talk about one
more thing.
In distributed systems these days.
Systems that use microservices that operate in the cloud, et cetera. When you given the choice.
This gentleman here is suggesting that you should you should choose event drivena
synchronous communication instead of rest based synchronous communication.
Who is this caricature? Who is this person, you guys, right, it's Franz Kafka that showed
before in an old picture and down below, it's me. I agree with Kafka on this one.
So much so that I wrote an article to the full Q magazine.
That's the reference you see down below with the trying to describe the six principles to
guide distributed systems design or microservice design.
And each principle has a letter and we form the acronym ideals in letter E. Represents event driven.
What I'm trying to say is that when you have a choice,

[Example of all-synchronous design]
you should choose an event driven communication instead of synchronous communication, an
in the next few slides, I'll try to explain why. First, let's pick an example.
Where there is no asynchronous communication. All communication here is synchronous.
All the communication in this diagram uses rest. And this is an application to buy.
Flight ticket using Miles, so that's called a war travel.
The the client is using a web application and at some point she looked for a flight to
buy with miles.
And found the flight, and then she clicked submit.
The Web application will submit the award travel request to the service award travel. Then we have the sequence of execution here.
Award Travel will first call mileage program booking, which will in turn call booking
booking process will return to mileage program booking,which will finish processing, will return to award travel, which will then call FAA notification, which will do some processing.
We don't see the details for each one here, but you will then return to a war travel, which will call passenger email.
Likely you will send an email, but we don't see that here.
But in any case, at some point you will return to award travel and only then award travel
will return to the web application.
And then the user here will see the result of the processing. Everything happened synchronously.
Let's.
Discuss an alternative design using events and event driven publish, subscribe design,

[Example of event-driven, pub-sub design]
and in these architectures where we use primarily event driven communication,publish
subscribe communication, we call these architectures event driven architectures already
look how he works.
The web application still makes a rest go to award travel.
There's no easy way to make the front end web application to send an asynchronous messag
through the message broker to the server side component,so this is still a rest call. But now, award travel will validate their request and send out an event award travel
requested that goes to an event bus.
You will go to one of these message cuz I'm not, uh, discriminating.
Each message queue here to simplify the diagram, but is sends that message and then it's
done.
You can immediately reply to the web application and then the the end user will see a
message.
We got your award travel request.
It's being processed.
That's what would show to be shown to the User Look Award travel request.
It is sent to the event bus and it is received by mileage program booking.
You see number three here and it also it's also received by passenger email.
That's number three here we have introduced concurrency.
There are now two receivers to subscribers of the same message and they will do things in
parallel.
They're running on different machines and so on.
In the case of mileage program booking, you will process that request. And if everything is OK, you will send a different event.
Award booking created that one is received by booking. That's step number five here.
Booking will create a locator and send out on an event booking locator created. This other event will go to two places.
You will go to the passenger email and will also go to FAA notification.
So this is how we could work if you were using event driven.
What do you gain and what do you lose? Let's discuss the trade offs, actually the
benefits and the challenges of using event driven architectures.
e

[EDA benefits]
And this slide shows why golf guy myself, we're suggesting that you should to use event
driven when possible.
There's a benefit with respect to maintainability because we know publishers and
subscribers are independent, so they're loosely coupled.
We can add subscribers easily and then we can add functionality to the system. If you if you have to do some more processing for.
Let me go back one slide.
Let's say when you create a locator, that's the event that this is the event.

[Example of event-driven, pub-sub design]
Let's say you want to have some, uh, some logic regarding auditing. What do you need to do? Just add another.
Subscriber.
Auditor component Annie will receive seven booking locator created as well.
You didn't have to change anything, you didn't have to change any of the other programs,
just added a new subscriber. That's that makes things easier.

[EDA benefits]
But the dramatic benefit is in scalability and throughput, as well as in reliability and
availability, because these subscribers are not blocked.
If processing a given event is taking too long, you won't delay the whole processing
because the original program that sends the first event,it sends the event and then it's
ready to process all the things. OK?

[In event-driven architectures (EDA), publishers. .
.
]
In this example here, let's say that the airline company is running a promotion for award travel, and there are a lot of requests coming in over here.
So a lot of people are calling.
Guess what a water which is need to send the message here, even if the processing of the request is slow.
You can still take all of the requests.
That is different from the synchronous approach because if each request that calls

[Example of all-synchronous design]
award travel needs to be synchronously processed by all the other elements.
So if the there are a lot of requests,you may not be able to process them all because it
is much slower to processeverything synchronously in the benefit with respect to
availability is if.
One of the elements here is, don't say booking, you cannot process anything because this
call would fail.
And then the whole transaction would fail in this design if bookings down temporarily.

[Example of event-driven, pub-sub design] No problem.
The messages of interest in this case are what booking created are still being sent. They will queue up here when booking is back alive.
It can get all of these messages and process all of them one by one.

[MaintainabilityPublishers and subscribers are. .
.
]
So we have these benefits.
Of course, there are challenges.

[EDA challenges (1)]
Maintainability, the event based programing model is more complex. We are introducing concurrency.
Things will run in parallel.
They may require synchronization points.
Also, something may go wrong down the road and because there is no request response, we
need some other mechanisms to avoid inconsistencies. We may need undo events.
We may need correction events.
We may need correlation identifiers and call back mechanisms as well. Testing and monitoring is more problematic.
There are more moving parts they don't execute in sequence. There is a loss of business process visibility.
This is indicated in this reference.
The thing is, with the synchronous interaction, it is easier to understand the flow,the
sequence and the there is an element that is kind of controlling the interactions for
EDA.
You send an event.
Other components will be processing it in, sending out other events that will activate
other components.
It's hard to see the overall workflow.
That's why we say we can't, um, easily understand the business process as implemented.

[EDA challenges (2)]
And there's more, because we are using a message broker.
We are creating some vendor lock in.
We we're using the specific API of that message broker, so there might be an issue with
the interoperability and portability.
If you used, grab it MQ for your solution, you may have different languages for different
Sanders and receivers.
But if you want to move to Kafka, the code that uses the rabbit MQ interaction needs to
be ported,needs to be adapted to use Kafka and the other challenges. Good user experience.
So this this is a challenge that was pointed out to me at a conference years ago when I wasexplaining these trade offs because things are happening down the road in the background.
We need to think about the interaction with the user in the example that I gave you send the request in the ADA approach quickly.
The frontend will show you, we got your request, it is being processed and then the events will happen.
In parallel, different components will be activated.
So you need to think, how do I notify my end user?You need to plan for, say, email messages or push notifications?And you can tell the user, um, your award travel request was approved, your payment was approved, a locator was generated for your ticket.
And so on. All right.

[Questions? Paulo Merson pmerson@cmu.
edu]
We got to the end of our discussion about runtime views.
We're going to move on to talk to other types of architecture reviews.