junsoopark
commented
1 year ago [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.
[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.