From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 24 May 2020 16:34:31 +0700 Subject: [usth/ICT2.7] Engineer software --- .../1 - Lesson Overview - lang_en_vs4.srt | 47 ++ ...ctural Recovery Quiz Solution - lang_en_vs4.srt | 67 +++ .../11 - Real World Example - lang_en_vs6.srt | 183 ++++++++ .../12 - More Examples - lang_en_vs6.srt | 107 +++++ .../13 - Final Example - lang_en_vs4.srt | 127 ++++++ ...4 - Architectural Design Quiz - lang_en_vs4.srt | 31 ++ ...tectural Design Quiz Solution - lang_en_vs4.srt | 107 +++++ .../16 - Architectural Elements - lang_en_vs5.srt | 115 +++++ ...onnectors, and Configurations - lang_en_vs5.srt | 111 +++++ .../18 - Configuration Example - lang_en_vs5.srt | 75 ++++ ...ent Architectural Perspective - lang_en_vs5.srt | 103 +++++ ...terview with Nenad Medvidovic - lang_en_vs6.srt | 499 +++++++++++++++++++++ .../20 - Architectural Styles - lang_en_vs5.srt | 111 +++++ ...Types of Architectural Styles - lang_en_vs5.srt | 239 ++++++++++ ...2 - Architectural Styles Quiz - lang_en_vs4.srt | 27 ++ ...tectural Styles Quiz Solution - lang_en_vs5.srt | 79 ++++ .../24 - P2P Architectures - lang_en_vs5.srt | 39 ++ .../25 - Napster Example - lang_en_vs4.srt | 231 ++++++++++ .../26 - Skype Example - lang_en_vs5.srt | 287 ++++++++++++ .../27 - Takeaway Message - lang_en_vs5.srt | 131 ++++++ ...hat is Software Architecture? - lang_en_vs6.srt | 127 ++++++ ...4 - General Definition of SWA - lang_en_vs6.srt | 131 ++++++ ...e vs Descriptive Architecture - lang_en_vs5.srt | 51 +++ .../6 - Architectural Evolution - lang_en_vs5.srt | 115 +++++ ...7 - Architectural Degradation - lang_en_vs6.srt | 131 ++++++ .../8 - Architectural Recovery - lang_en_vs4.srt | 67 +++ ...- Architectural Recovery Quiz - lang_en_vs4.srt | 35 ++ 27 files changed, 3373 insertions(+) create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/9 - Architectural Recovery Quiz - lang_en_vs4.srt (limited to 'usth/ICT2.7/P3L1 Software Architecture Subtitles') diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt new file mode 100644 index 0000000..89008af --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt @@ -0,0 +1,47 @@ +1 +00:00:00,360 --> 00:00:02,910 +Hello, and welcome to the third part + +2 +00:00:02,910 --> 00:00:06,426 +of our software engineering course. In this mini-course, + +3 +00:00:06,426 --> 00:00:09,250 +we will discuss software design. We will + +4 +00:00:09,250 --> 00:00:13,170 +also introduce the Unified Software Process. And we + +5 +00:00:13,170 --> 00:00:15,730 +will work on a more complex project, + +6 +00:00:15,730 --> 00:00:18,330 +in which we will develop a distributed software + +7 +00:00:18,330 --> 00:00:22,960 +system that involves multiple different platforms. In + +8 +00:00:22,960 --> 00:00:25,730 +our first lesson of this mini-course, in particular, + +9 +00:00:25,730 --> 00:00:28,150 +we will talk about software architecture. A + +10 +00:00:28,150 --> 00:00:31,650 +software engineering discipline whose goal is to lay + +11 +00:00:31,650 --> 00:00:34,980 +the foundation on which to build successful + +12 +00:00:34,980 --> 00:00:38,130 +and long lasting software systems. So let's begin. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..bd45907 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,67 @@ +1 +00:00:00,120 --> 00:00:03,210 +The first sentence is definitely false. Prescriptive architecture + +2 +00:00:03,210 --> 00:00:06,530 +and descriptive architecture tend to diverge as systems evolve, + +3 +00:00:06,530 --> 00:00:08,960 +and sometimes, even when the system is first developed, + +4 +00:00:08,960 --> 00:00:10,680 +as we will see in some of the upcoming + +5 +00:00:10,680 --> 00:00:14,340 +examples. Conversely, the second sentence is true. By + +6 +00:00:14,340 --> 00:00:18,150 +adding unnecessary elements to the architecture, architectural drift can + +7 +00:00:18,150 --> 00:00:22,470 +transform an otherwise clean architecture into a complex sub-optimal, + +8 +00:00:22,470 --> 00:00:25,960 +and often ugly, architecture. The third sentence is false. + +9 +00:00:25,960 --> 00:00:30,540 +Architectural erosion and architectural drift are, indeed, different phenomena. + +10 +00:00:30,540 --> 00:00:32,940 +But they both result in a less than ideal, and + +11 +00:00:32,940 --> 00:00:36,160 +in some cases, highly degraded architecture. And the fourth + +12 +00:00:36,160 --> 00:00:39,600 +sentence is also false, as we discussed a minute ago. + +13 +00:00:39,600 --> 00:00:42,050 +Just tweaking at the code is very unlikely to + +14 +00:00:42,050 --> 00:00:44,930 +improve the code. Quite the opposite, actually. The best way + +15 +00:00:44,930 --> 00:00:48,420 +to repair a degraded architectural design is to first, understand + +16 +00:00:48,420 --> 00:00:51,110 +the current architecture, and then, try to fix it in + +17 +00:00:51,110 --> 00:00:52,280 +a more principled way. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt new file mode 100644 index 0000000..4e64d4a --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt @@ -0,0 +1,183 @@ +1 +00:00:00,210 --> 00:00:02,770 +Now to drive home some of the points that I just + +2 +00:00:02,770 --> 00:00:05,920 +made, I would like to show you a few real world examples + +3 +00:00:05,920 --> 00:00:09,150 +of architectures that kind of went astray. The first example I + +4 +00:00:09,150 --> 00:00:11,970 +want to use is an example from the Linux kernel. Actually, from + +5 +00:00:11,970 --> 00:00:15,260 +an earlier version of the Linux kernel. A research group studied + +6 +00:00:15,260 --> 00:00:17,020 +the documentation of Linux, and also + +7 +00:00:17,020 --> 00:00:19,440 +interviewed several Linux developers. And by + +8 +00:00:19,440 --> 00:00:21,710 +doing that, they were able to come up with a software + +9 +00:00:21,710 --> 00:00:25,260 +architecture of Linux at different levels of obstruction. So the one that + +10 +00:00:25,260 --> 00:00:27,365 +I'm showing you here on the left, is the + +11 +00:00:27,365 --> 00:00:31,120 +software architecture at the level of Linux's main subsystems. So + +12 +00:00:31,120 --> 00:00:34,540 +this is the prescriptive architecture of Linux at the level + +13 +00:00:34,540 --> 00:00:38,060 +of Linux's main subsystems. So the researchers, after identifying this + +14 +00:00:38,060 --> 00:00:40,420 +architecture, they showed it to the developers, and the + +15 +00:00:40,420 --> 00:00:43,180 +developers agreed that, that was indeed the architecture of the + +16 +00:00:43,180 --> 00:00:46,540 +system. The researchers then studied the source code of Linux + +17 +00:00:46,540 --> 00:00:50,380 +and reverse engineered its actual architecture. So the architecture as + +18 +00:00:50,380 --> 00:00:54,020 +implemented, it's descriptive architecture. And this one here, on the + +19 +00:00:54,020 --> 00:00:56,610 +right, is the result. And as you can see, they found + +20 +00:00:56,610 --> 00:01:00,940 +a number of differences or violations between the prescriptive architecture and + +21 +00:01:00,940 --> 00:01:04,080 +the descriptive architecture. In particular, if we look at this architecture, + +22 +00:01:04,080 --> 00:01:06,820 +we can see that pretty much everything talks to everything else, + +23 +00:01:06,820 --> 00:01:09,010 +which is, in general, not a good thing. And in addition + +24 +00:01:09,010 --> 00:01:11,890 +to that, there are also several things that don't really make + +25 +00:01:11,890 --> 00:01:15,630 +much sense. For example the library calls the file system and + +26 +00:01:15,630 --> 00:01:19,290 +also the network interface which doesn't make much sense. Another thing + +27 +00:01:19,290 --> 00:01:21,850 +that is kind of weird is the fact that file system + +28 +00:01:21,850 --> 00:01:25,250 +calls the kernel initialization code. Which is also a little bit + +29 +00:01:25,250 --> 00:01:28,100 +weird. So basically, the bottom line here is that not even + +30 +00:01:28,100 --> 00:01:32,020 +the developers realized how the actual architecture of the system was, + +31 +00:01:32,020 --> 00:01:35,170 +and how it was different from the architecture they have conceived. + +32 +00:01:35,170 --> 00:01:37,870 +And in fact another interesting thing here is the reaction of + +33 +00:01:37,870 --> 00:01:41,020 +the developers when they were shown the actual architecture. So basically + +34 +00:01:41,020 --> 00:01:44,110 +they justified the differences by saying things such as, well you + +35 +00:01:44,110 --> 00:01:47,120 +know it had to be done fast, and therefore I changed it + +36 +00:01:47,120 --> 00:01:50,110 +and then I didn't have time to go back and update the documentation + +37 +00:01:50,110 --> 00:01:52,800 +and things of this sort. And by the way these are exactly some + +38 +00:01:52,800 --> 00:01:55,640 +of the reasons that we mentioned early on in the lesson for the + +39 +00:01:55,640 --> 00:01:58,410 +discrepancy between prescriptive and descriptive software + +40 +00:01:58,410 --> 00:01:59,990 +architecture. So one last thing that I + +41 +00:01:59,990 --> 00:02:02,840 +want to mention here as an aside and we can get back to + +42 +00:02:02,840 --> 00:02:06,495 +that later is the fact that you can probably clearly show how representing + +43 +00:02:06,495 --> 00:02:10,880 +software architectures graphically can be extremely useful, because it allows + +44 +00:02:10,880 --> 00:02:14,140 +for easily seeing the structure of the system. Look at different + +45 +00:02:14,140 --> 00:02:17,140 +views identify problematic points and so on. And we will see + +46 +00:02:17,140 --> 00:02:19,740 +how that can be useful in many cases also later on. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt new file mode 100644 index 0000000..6f929eb --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt @@ -0,0 +1,107 @@ +1 +00:00:00,180 --> 00:00:03,090 +As another example, I want to show you the architecture of the + +2 +00:00:03,090 --> 00:00:06,290 +iRods system. This is a data grid system that was built by + +3 +00:00:06,290 --> 00:00:09,720 +a biologist. And it's a system for storing and accessing big + +4 +00:00:09,720 --> 00:00:11,910 +data. So what I'm going to do, I'm going to do the same thing + +5 +00:00:11,910 --> 00:00:14,010 +that I did for the Linux system. I'm going to show you + +6 +00:00:14,010 --> 00:00:18,080 +here, on the left hand side, this clean prescriptive architecture for the + +7 +00:00:18,080 --> 00:00:21,000 +iRODS system. And I'm going to show you here on the right the + +8 +00:00:21,000 --> 00:00:22,660 +actual architecture of the system. The + +9 +00:00:22,660 --> 00:00:25,780 +descriptive architecture of iRODS. So here, + +10 +00:00:25,780 --> 00:00:27,640 +even if we don't go in and look at the details, you + +11 +00:00:27,640 --> 00:00:31,800 +can see very easily that the system is badly drifted and eroded + +12 +00:00:31,800 --> 00:00:34,500 +with respect to the way it was supposed to be. Continuing + +13 +00:00:34,500 --> 00:00:36,500 +with the examples. What I want to show you now is the + +14 +00:00:36,500 --> 00:00:39,980 +view of the complete architecture of HADOOP. As many of you probably + +15 +00:00:39,980 --> 00:00:44,210 +already know, HADOOP is an open source software framework for storage and + +16 +00:00:44,210 --> 00:00:47,990 +large scale processing of data sets. It's very broadly used. And here + +17 +00:00:47,990 --> 00:00:50,820 +is a picture of the architecture, and I hope you can see it + +18 +00:00:50,820 --> 00:00:54,290 +because the architecture is so complex and so broad and so + +19 +00:00:54,290 --> 00:00:57,050 +intertwined, and in order to be able to represent it here + +20 +00:00:57,050 --> 00:00:59,690 +in one page, I had to zoom out quite a bit. + +21 +00:00:59,690 --> 00:01:02,120 +But also in this case, you don't really have to look + +22 +00:01:02,120 --> 00:01:05,640 +at details. The important point here is that in this software architecture + +23 +00:01:05,640 --> 00:01:09,540 +61 out of the 67 components in the system have circular + +24 +00:01:09,540 --> 00:01:12,570 +dependencies. Which means that they depend on each other in a + +25 +00:01:12,570 --> 00:01:15,820 +circular way and this is normally not a good thing and also + +26 +00:01:15,820 --> 00:01:18,790 +in this case a few developers when shown the diagram had no + +27 +00:01:18,790 --> 00:01:22,120 +idea that the structure of the system was so complex and messy. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt new file mode 100644 index 0000000..4fab0c6 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt @@ -0,0 +1,127 @@ +1 +00:00:00,220 --> 00:00:02,130 +I'm going to conclude this set of examples with + +2 +00:00:02,130 --> 00:00:04,750 +a system that you might also know, Bash. And in + +3 +00:00:04,750 --> 00:00:08,000 +case you don't, Bash is a Unix shell written as + +4 +00:00:08,000 --> 00:00:11,000 +a free software replacement for the traditional Bourne shell, also + +5 +00:00:11,000 --> 00:00:13,690 +called sh. So what I'm showing here is the + +6 +00:00:13,690 --> 00:00:17,950 +descriptive architecture of the command component of Bash. So, is + +7 +00:00:17,950 --> 00:00:22,170 +the architecture, as implemented, of the command component of Bash. + +8 +00:00:22,170 --> 00:00:25,390 +And the component is the one here sort of highlighted + +9 +00:00:25,390 --> 00:00:28,120 +in gray. And what you can see here, these names are + +10 +00:00:28,120 --> 00:00:31,640 +the sub components of the command component. And if we look at + +11 +00:00:31,640 --> 00:00:35,000 +this architecture, two design problems of the component can kind of jump + +12 +00:00:35,000 --> 00:00:37,870 +at us. The first one is the lack of cohesion within the + +13 +00:00:37,870 --> 00:00:40,830 +component. So, if you look here, you can see that only + +14 +00:00:40,830 --> 00:00:44,820 +a few connections exist between the sub-components. And having a low cohesion + +15 +00:00:44,820 --> 00:00:47,430 +is normally not a good thing for a design. The second thing + +16 +00:00:47,430 --> 00:00:50,860 +that we can note is the high coupling. The component has tons + +17 +00:00:50,860 --> 00:00:54,200 +of connections with other components. They're, these edges that are + +18 +00:00:54,200 --> 00:00:57,890 +leaving the components and going towards other parts of the system. + +19 +00:00:57,890 --> 00:01:01,190 +So basically, this component has low cohesion and high coupling, which + +20 +00:01:01,190 --> 00:01:04,730 +is exactly the opposite of how a good design should be. + +21 +00:01:04,730 --> 00:01:07,410 +Given the structure, it is clear that anytime you change + +22 +00:01:07,410 --> 00:01:09,970 +this component you might need to change a bunch of other + +23 +00:01:09,970 --> 00:01:13,440 +components in the system. And of course, when changing other components + +24 +00:01:13,440 --> 00:01:15,910 +in the system, you might also need to chance the command + +25 +00:01:15,910 --> 00:01:19,060 +component as well. And along similar lines, to understand this + +26 +00:01:19,060 --> 00:01:21,890 +component you probably need to look at many other parts of + +27 +00:01:21,890 --> 00:01:24,690 +the system, which is also less than ideal. And one + +28 +00:01:24,690 --> 00:01:27,580 +important point here is that with all these examples, I'm not + +29 +00:01:27,580 --> 00:01:30,500 +really trying to criticize any specific system, what I'm trying + +30 +00:01:30,500 --> 00:01:34,380 +to show instead, is how complex software architectures can be, and + +31 +00:01:34,380 --> 00:01:37,040 +how much they can degrade over time. And this is true + +32 +00:01:37,040 --> 00:01:39,660 +for most systems, not just the ones that I showed you. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..e1e95e6 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt @@ -0,0 +1,31 @@ +1 +00:00:00,110 --> 00:00:02,330 +At this point, we have seen some examples of + +2 +00:00:02,330 --> 00:00:05,070 +things that might go wrong with the software architecture. So + +3 +00:00:05,070 --> 00:00:07,220 +I'd like to ask you also to recap some of + +4 +00:00:07,220 --> 00:00:10,800 +the concepts that we've touched upon. What are ideal characteristics + +5 +00:00:10,800 --> 00:00:13,526 +of an architectural design? And I'm showing you three possibilities + +6 +00:00:13,526 --> 00:00:16,970 +here: scalability, low cohesion, and low coupling. And some of + +7 +00:00:16,970 --> 00:00:20,260 +these concepts we did not explicitly define, but we talked + +8 +00:00:20,260 --> 00:00:22,400 +about it when discussing the examples that we just saw. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..465687c --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,107 @@ +1 +00:00:00,110 --> 00:00:02,540 +So, let's look at these three characteristics one by + +2 +00:00:02,540 --> 00:00:06,660 +one. Scalability for software architecture is its ability to handle + +3 +00:00:06,660 --> 00:00:09,320 +the growth of the software system. For example, for a + +4 +00:00:09,320 --> 00:00:12,610 +web based system, scalability could be the ability to handle + +5 +00:00:12,610 --> 00:00:15,620 +a larger workload by adding new servers to the system. + +6 +00:00:15,620 --> 00:00:19,508 +Scalability is therefore an important characteristic of a software architecture, + +7 +00:00:19,508 --> 00:00:21,938 +especially for the kinds of systems that can grow over + +8 +00:00:21,938 --> 00:00:24,990 +time. So, we're going to mark it as an ideal characteristic. + +9 +00:00:24,990 --> 00:00:27,901 +Cohesion is a measure of how strongly related are + +10 +00:00:27,901 --> 00:00:30,920 +the elements of a module. Clearly, we should shoot + +11 +00:00:30,920 --> 00:00:33,760 +for high and not low cohesion when developing a + +12 +00:00:33,760 --> 00:00:37,100 +system. We want to develop modules whose elements cooperate to + +13 +00:00:37,100 --> 00:00:40,480 +provide the specific piece of functionality rather than modules + +14 +00:00:40,480 --> 00:00:43,410 +consisting of a bunch of elements that provide different + +15 +00:00:43,410 --> 00:00:47,040 +unrelated pieces of functionality. Therefor, low cohesion is definitely + +16 +00:00:47,040 --> 00:00:49,980 +not something that we want. We want high cohesion instead. + +17 +00:00:49,980 --> 00:00:53,040 +As for coupling, coupling is a concept related to cohesion + +18 +00:00:53,040 --> 00:00:55,070 +and is also a measure. In this case though, it + +19 +00:00:55,070 --> 00:00:58,130 +is a measure of how strongly related are the different + +20 +00:00:58,130 --> 00:01:01,830 +modules in a system. Low coupling, which is often correlated with + +21 +00:01:01,830 --> 00:01:05,570 +high cohesion, is an important and ideal characteristic of a + +22 +00:01:05,570 --> 00:01:08,660 +software architecture as it indicates that the different modules in + +23 +00:01:08,660 --> 00:01:12,220 +the system are independent from one another. Each module provides + +24 +00:01:12,220 --> 00:01:15,300 +a specific piece of functionality and it can provide it without + +25 +00:01:15,300 --> 00:01:17,530 +relying too much on other modules. + +26 +00:01:17,530 --> 00:01:19,960 +Basically, systems characterized by low coupling + +27 +00:01:19,960 --> 00:01:23,330 +and high cohesion, are systems that are easier to understand, and to maintain. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt new file mode 100644 index 0000000..c8de83f --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt @@ -0,0 +1,115 @@ +1 +00:00:00,170 --> 00:00:02,770 +Now that we have discussed a few foundational aspects + +2 +00:00:02,770 --> 00:00:05,410 +of software architectures, and we have looked at some real + +3 +00:00:05,410 --> 00:00:07,900 +world examples that help us to illustrate some of these + +4 +00:00:07,900 --> 00:00:10,560 +points, to discuss some of these aspects. I want to + +5 +00:00:10,560 --> 00:00:13,730 +introduce and define the different elements that compose a software + +6 +00:00:13,730 --> 00:00:17,700 +architecture and also talk about architectural styles. So let's start + +7 +00:00:17,700 --> 00:00:20,190 +by discussing a software architecture's + +8 +00:00:20,190 --> 00:00:22,880 +elements. A software system's architecture + +9 +00:00:22,880 --> 00:00:26,690 +typically is not, and should not be, a uniform monolith. + +10 +00:00:26,690 --> 00:00:28,770 +On the contrary, an architecture should be a + +11 +00:00:28,770 --> 00:00:32,910 +composition and interplay of different elements. In particular, + +12 +00:00:32,910 --> 00:00:34,510 +as we quickly mentioned at the beginning of + +13 +00:00:34,510 --> 00:00:36,970 +the lesson, there are three main types of elements + +14 +00:00:36,970 --> 00:00:40,160 +in an architecture. Processing elements, data elements, and + +15 +00:00:40,160 --> 00:00:44,580 +interaction elements. Processing elements are those elements that implement + +16 +00:00:44,580 --> 00:00:48,260 +the business logic and perform transformations on data. + +17 +00:00:48,260 --> 00:00:51,760 +Data elements, also called information or state, are those + +18 +00:00:51,760 --> 00:00:54,180 +elements that contain the information that is used + +19 +00:00:54,180 --> 00:00:57,440 +and transformed by the processing elements. And finally, + +20 +00:00:57,440 --> 00:01:00,030 +the interaction elements are the glue that holds + +21 +00:01:00,030 --> 00:01:02,760 +the different pieces of the architecture together. Now, + +22 +00:01:02,760 --> 00:01:06,030 +the processing elements and the data are contained + +23 +00:01:06,030 --> 00:01:10,350 +into the system components, whereas the interaction elements + +24 +00:01:10,350 --> 00:01:13,900 +are maintained and controlled by the system connectors. + +25 +00:01:13,900 --> 00:01:17,100 +And components and connectors get all cooked together + +26 +00:01:17,100 --> 00:01:19,980 +into a systems configuration, which models + +27 +00:01:19,980 --> 00:01:22,940 +components, connectors and their relationships. So + +28 +00:01:22,940 --> 00:01:24,850 +now, let's look at components, connectors + +29 +00:01:24,850 --> 00:01:26,770 +and configurations in a little more detail. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt new file mode 100644 index 0000000..5fc4df3 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt @@ -0,0 +1,111 @@ +1 +00:00:00,250 --> 00:00:02,350 +And let's start with software components. A + +2 +00:00:02,350 --> 00:00:06,700 +software component is an architectural entity that encapsulates + +3 +00:00:06,700 --> 00:00:09,940 +a subset of the system's functionality and or + +4 +00:00:09,940 --> 00:00:13,180 +the system's data. So basically components typically provide + +5 +00:00:13,180 --> 00:00:16,100 +application specific services. In addition to that, a + +6 +00:00:16,100 --> 00:00:19,650 +software component also restricts access to that subset + +7 +00:00:19,650 --> 00:00:23,570 +via an explicitly defined interface. And, in addition, + +8 +00:00:23,570 --> 00:00:25,610 +which I'm not showing here, a component + +9 +00:00:25,610 --> 00:00:28,010 +can also have explicitly defined dependencies + +10 +00:00:28,010 --> 00:00:30,990 +on its required execution environment. In complex + +11 +00:00:30,990 --> 00:00:33,680 +systems, interactions might become more important and + +12 +00:00:33,680 --> 00:00:36,220 +challenging than functionality. And this is why + +13 +00:00:36,220 --> 00:00:40,000 +connectors are very important architectural elements. A + +14 +00:00:40,000 --> 00:00:42,935 +software connector is an architectural building block + +15 +00:00:42,935 --> 00:00:46,990 +tasked with effecting and regulating interactions among + +16 +00:00:46,990 --> 00:00:50,980 +components. So basically, connectors typically provide application + +17 +00:00:50,980 --> 00:00:54,610 +independent interaction facilities. And it's worth noting here + +18 +00:00:54,610 --> 00:00:57,530 +that in many software systems, connectors might simply be + +19 +00:00:57,530 --> 00:01:01,140 +procedure calls or shared data accesses. So all constants + +20 +00:01:01,140 --> 00:01:03,589 +that we're familiar with. But consider that much more + +21 +00:01:03,589 --> 00:01:06,690 +sophisticated and complex connectors are also possible. And + +22 +00:01:06,690 --> 00:01:10,310 +components and connectors are composed in a specific way + +23 +00:01:10,310 --> 00:01:13,510 +in a given system architecture to accomplish that system's + +24 +00:01:13,510 --> 00:01:17,400 +objective And this is expressed through an architectural configuration. + +25 +00:01:17,400 --> 00:01:21,070 +More precisely, an architectural configuration, or topology, is a + +26 +00:01:21,070 --> 00:01:25,630 +set of specific associations between the components and connectors + +27 +00:01:25,630 --> 00:01:28,380 +of a software system's architecture. So now, let's look + +28 +00:01:28,380 --> 00:01:30,880 +at an example that brings all of this together. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt new file mode 100644 index 0000000..775f11c --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt @@ -0,0 +1,75 @@ +1 +00:00:00,180 --> 00:00:02,880 +What I'm showing here is what an architectural configuration of + +2 +00:00:02,880 --> 00:00:05,460 +a system might look like in practice. And as you + +3 +00:00:05,460 --> 00:00:08,560 +can see, the configuration includes a set of components, which + +4 +00:00:08,560 --> 00:00:12,200 +are these rectangles over here. The components have various kinds of + +5 +00:00:12,200 --> 00:00:15,460 +ports, which are the ones marked here on the components + +6 +00:00:15,460 --> 00:00:17,760 +with different graphical representations. And + +7 +00:00:17,760 --> 00:00:19,760 +the components communicate through various + +8 +00:00:19,760 --> 00:00:22,860 +types of connectors, which are the grey elements here which + +9 +00:00:22,860 --> 00:00:25,570 +as you can see are used to connect the different components. + +10 +00:00:25,570 --> 00:00:28,180 +And something else that you can notice by looking at + +11 +00:00:28,180 --> 00:00:30,720 +this configuration is the fact that you can also have + +12 +00:00:30,720 --> 00:00:34,980 +hierarchically decomposable components. For example, if you look at the strategy + +13 +00:00:34,980 --> 00:00:39,250 +analyzer component, you can see that it has three subcomponents: one, + +14 +00:00:39,250 --> 00:00:42,110 +two, and three and two internal connectors as part of + +15 +00:00:42,110 --> 00:00:44,832 +it. And it is worth recalling here that a component + +16 +00:00:44,832 --> 00:00:47,152 +diagram as we said when first discussed in UML in + +17 +00:00:47,152 --> 00:00:51,230 +the course, can also be used to represent an architectural configuration. + +18 +00:00:51,230 --> 00:00:52,920 +So sometimes you will see architectural + +19 +00:00:52,920 --> 00:00:56,250 +configurations represented as UML component diagrams. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt new file mode 100644 index 0000000..1cc7d89 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt @@ -0,0 +1,103 @@ +1 +00:00:00,180 --> 00:00:03,100 +A system cannot fulfill its purpose until it is + +2 +00:00:03,100 --> 00:00:06,727 +deployed. And deploying a system involves physically placing the + +3 +00:00:06,727 --> 00:00:09,960 +system's executable modules on the hardware devices on which + +4 +00:00:09,960 --> 00:00:12,490 +they are supposed to run. So when you do that, + +5 +00:00:12,490 --> 00:00:16,132 +you're basically mapping your components and connectors to specific + +6 +00:00:16,132 --> 00:00:19,810 +hardware elements. Here in this diagram, for instance, I'm + +7 +00:00:19,810 --> 00:00:22,160 +showing the same components that we saw in the + +8 +00:00:22,160 --> 00:00:25,400 +previous diagram, but we see them deployed on a laptop, + +9 +00:00:25,400 --> 00:00:28,620 +which is depicted here in this way, and on two + +10 +00:00:28,620 --> 00:00:32,820 +smartphones that are represented here, or PDAs, if you wish. + +11 +00:00:32,820 --> 00:00:34,730 +So why do we this, why do we create + +12 +00:00:34,730 --> 00:00:38,540 +a deployment perspective for our architecture? Well, because the deployment + +13 +00:00:38,540 --> 00:00:41,710 +view of an architecture can be critical in assessing whether + +14 +00:00:41,710 --> 00:00:44,920 +the system will be able to satisfy its requirement. Because + +15 +00:00:44,920 --> 00:00:47,860 +doing this mapping allows you to discover and assess other + +16 +00:00:47,860 --> 00:00:50,840 +characteristics of your system that you might not have considered + +17 +00:00:50,840 --> 00:00:53,440 +up to now. For instance, using a deployment view like this + +18 +00:00:53,440 --> 00:00:57,030 +one and knowing the characteristics of the hardware devices, one might + +19 +00:00:57,030 --> 00:01:00,056 +be able to assess the system in terms of available memory. + +20 +00:01:00,056 --> 00:01:02,610 +Is there going to be enough memory available to run the system, + +21 +00:01:02,610 --> 00:01:06,140 +for example, on this device? Power consumption. Is the power consumption + +22 +00:01:06,140 --> 00:01:09,270 +profile going to be larger than what the device can handle? + +23 +00:01:09,270 --> 00:01:12,580 +Or again the required network bandwidth. Does the system have enough + +24 +00:01:12,580 --> 00:01:16,170 +network bandwidth to enable the required interactions? And so on. So all + +25 +00:01:16,170 --> 00:01:19,140 +of these characteristics, all of these qualities, you can assess when + +26 +00:01:19,140 --> 00:01:22,730 +you do this final mapping of the components to the hardware elements. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt new file mode 100644 index 0000000..40fa57c --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt @@ -0,0 +1,499 @@ +1 +00:00:00,220 --> 00:00:02,900 +Because the topic of today's lecture is software architecture, + +2 +00:00:02,900 --> 00:00:05,390 +it seemed appropriate to start the lesson by asking a + +3 +00:00:05,390 --> 00:00:08,960 +world expert on this topic, what is software architecture, and + +4 +00:00:08,960 --> 00:00:11,570 +why it is important. To do that, let's fly to + +5 +00:00:11,570 --> 00:00:14,910 +California, and more precisely, Los Angeles, and visit Professor + +6 +00:00:14,910 --> 00:00:19,540 +Nenad Medvidovic. Hi, I'm here visiting Professor Nenad Medvidovic from + +7 +00:00:19,540 --> 00:00:22,310 +the University of Southern California. And Neno is one of + +8 +00:00:22,310 --> 00:00:25,250 +the world experts in software architecture, actually one of the + +9 +00:00:25,250 --> 00:00:28,300 +authors of, of a recent book which is, sort of the + +10 +00:00:28,300 --> 00:00:31,660 +book in software architecture. What I would like to discuss with + +11 +00:00:31,660 --> 00:00:34,500 +Neno is the concept of software architecture and its importance. Because + +12 +00:00:34,500 --> 00:00:37,520 +people are very familiar with the idea and the cost of the + +13 +00:00:37,520 --> 00:00:41,240 +design. And software architecture is something is very related to that, + +14 +00:00:41,240 --> 00:00:43,690 +but is less known. So I would like for Nenad to + +15 +00:00:43,690 --> 00:00:46,350 +elaborate on that, and tell us why is it important to + +16 +00:00:46,350 --> 00:00:49,880 +focus also on this specific you know, architectural aspects of the software. + +17 +00:00:49,880 --> 00:00:50,380 +>> When you + +18 +00:00:50,380 --> 00:00:53,220 +build any software system, even a simple, relatively simple + +19 +00:00:53,220 --> 00:00:56,840 +one. You're going to go through, a process of making + +20 +00:00:56,840 --> 00:01:00,070 +many, many design decisions. Hundreds or thousands sometimes even tens + +21 +00:01:00,070 --> 00:01:03,140 +of thousands of design decisions, so any program that you + +22 +00:01:03,140 --> 00:01:06,090 +write at some point you get to deciding what + +23 +00:01:06,090 --> 00:01:09,385 +the interface of a particular method is going to be. + +24 +00:01:09,385 --> 00:01:12,170 +Are you're going to put in a parameter that is + +25 +00:01:12,170 --> 00:01:15,530 +an integer or a float. When you're writing your routine + +26 +00:01:15,530 --> 00:01:17,400 +about some sort you have to decide whether you're + +27 +00:01:17,400 --> 00:01:18,900 +going to use a static data structure or a + +28 +00:01:18,900 --> 00:01:22,410 +dynamic data structure. All these things are design decisions. + +29 +00:01:22,410 --> 00:01:25,770 +Many of them however, will typically, in the average + +30 +00:01:25,770 --> 00:01:29,030 +case, not really impact the success of your system + +31 +00:01:29,030 --> 00:01:31,640 +and the long term well-being of your system. But + +32 +00:01:31,640 --> 00:01:35,390 +typically the things that software engineers start struggling with + +33 +00:01:35,390 --> 00:01:40,760 +are other design decisions. Design decisions that are the equivalent + +34 +00:01:40,760 --> 00:01:42,080 +of load baring walls in a building + +35 +00:01:42,080 --> 00:01:42,660 +>> Mm hm + +36 +00:01:42,660 --> 00:01:43,950 +>> These are the things that, if you + +37 +00:01:43,950 --> 00:01:45,960 +don't get them right, or if you compromise + +38 +00:01:45,960 --> 00:01:50,190 +them, will in fact potentially impact how the + +39 +00:01:50,190 --> 00:01:54,300 +system operates. They might result in failures of different + +40 +00:01:54,300 --> 00:01:56,780 +kinds. They may result in a system that + +41 +00:01:56,780 --> 00:01:59,460 +is not easily maintainable and so forth. In + +42 +00:01:59,460 --> 00:02:01,680 +a sense, to make a long story short, + +43 +00:02:01,680 --> 00:02:05,888 +architectural design decisions are really the principle design decisions + +44 +00:02:05,888 --> 00:02:07,900 +in your system. These are the things that are + +45 +00:02:07,900 --> 00:02:10,550 +very important. All of the other design decisions you + +46 +00:02:10,550 --> 00:02:13,520 +could sort of tag with being important, but they're + +47 +00:02:13,520 --> 00:02:17,730 +sort of below this very important or highly important threshold. + +48 +00:02:17,730 --> 00:02:21,400 +>> So if you need to change a low level design decision, sometimes + +49 +00:02:21,400 --> 00:02:23,970 +it's kind of easy to do. It might change a little structure. Is it + +50 +00:02:23,970 --> 00:02:27,140 +the case that you know, being the architecture is sort of the pillar of + +51 +00:02:27,140 --> 00:02:29,020 +the software, is that going to be much + +52 +00:02:29,020 --> 00:02:32,380 +more difficult to change an architectural decision? + +53 +00:02:32,380 --> 00:02:34,400 +And architecture is deemed to be you know, + +54 +00:02:34,400 --> 00:02:36,120 +say if you start with the wrong architecture the + +55 +00:02:36,120 --> 00:02:39,510 +software is going to, you know, necessarily be unsuccessful. + +56 +00:02:39,510 --> 00:02:41,320 +Or you can also do something that is better. + +57 +00:02:41,320 --> 00:02:46,070 +>> A system could be successful and very poorly architected. Just + +58 +00:02:46,070 --> 00:02:50,630 +like a building or an airplane or a car, any other + +59 +00:02:50,630 --> 00:02:54,700 +engineering artifact could be successful but poorly architected. So success we + +60 +00:02:54,700 --> 00:02:57,440 +can separated from this, but the, the point that you make in + +61 +00:02:57,440 --> 00:03:00,530 +asking this question is an important one. The + +62 +00:03:00,530 --> 00:03:04,260 +non-architectural design decisions, should be on the + +63 +00:03:04,260 --> 00:03:06,250 +average, there are exceptions and we need to + +64 +00:03:06,250 --> 00:03:09,580 +acknowledge that there is no one size fits all + +65 +00:03:09,580 --> 00:03:11,640 +type of solution for anything in software engineering + +66 +00:03:11,640 --> 00:03:15,060 +really. But on the average, the non-architectural design decisions, + +67 +00:03:15,060 --> 00:03:17,650 +should be much easier to make. So the + +68 +00:03:17,650 --> 00:03:22,600 +scale of the consequences of making such a change. + +69 +00:03:22,600 --> 00:03:25,880 +Really can vary from very minor, highly localized + +70 +00:03:25,880 --> 00:03:29,670 +to very important and sometimes, even system wide. + +71 +00:03:29,670 --> 00:03:33,570 +>> To conclude, I just like to ask you about some concept that is + +72 +00:03:33,570 --> 00:03:35,110 +we here about a lot. Which is + +73 +00:03:35,110 --> 00:03:37,430 +architectural erosion. Since, we're talking about in with + +74 +00:03:37,430 --> 00:03:39,760 +fine architecture and software evolution. So, what is, + +75 +00:03:39,760 --> 00:03:42,090 +exactly, an architectural erosion and why does that + +76 +00:03:42,090 --> 00:03:47,600 +happen? So, to go back to our non software metaphors. Imagine you buy a car. + +77 +00:03:47,600 --> 00:03:49,810 +And your car has four wheels, it has a steering wheel, it has + +78 +00:03:49,810 --> 00:03:53,700 +a nice chassis, it looks pretty nice. At one point, you end up + +79 +00:03:53,700 --> 00:03:54,950 +replacing its 150 horsepower engine with + +80 +00:03:54,950 --> 00:03:56,800 +a 250 horsepower engine because that's what + +81 +00:03:56,800 --> 00:04:01,510 +you want. And you start putting a spoiler on the back of the car + +82 +00:04:01,510 --> 00:04:04,680 +and then you replace the headlights. And then you replace the side view + +83 +00:04:04,680 --> 00:04:08,000 +mirrors with smaller ones because you want your car to be more aerodynamic. + +84 +00:04:08,000 --> 00:04:10,620 +And then you start tinkering with other things, like you cut the, maybe + +85 +00:04:10,620 --> 00:04:13,380 +the roof of the car because you want to turn it into a convertible, + +86 +00:04:13,380 --> 00:04:15,990 +et cetera. And in the end, what you have is + +87 +00:04:15,990 --> 00:04:19,810 +a car that is still your car. Looks very different, It's + +88 +00:04:19,810 --> 00:04:23,650 +structural and behavioral properties are very different And, what you + +89 +00:04:23,650 --> 00:04:27,260 +might find is that the car doesn't handle nearly as well. + +90 +00:04:27,260 --> 00:04:29,670 +For example, in a very sharp turn it might not + +91 +00:04:29,670 --> 00:04:31,910 +be able to negotiate a steep hill as well. Because you + +92 +00:04:31,910 --> 00:04:35,760 +pretty much changed it all along the way. Architectural erosion in + +93 +00:04:35,760 --> 00:04:38,620 +the case of a software system is the exact same thing + +94 +00:04:38,620 --> 00:04:41,480 +with one huge caveat. Very few, if any of us, + +95 +00:04:41,480 --> 00:04:44,970 +will ever put a new engine into our car or tinker + +96 +00:04:44,970 --> 00:04:47,390 +with the structural soundness of the car by cutting off the + +97 +00:04:47,390 --> 00:04:50,260 +roof etc. In a software system we do it all the + +98 +00:04:50,260 --> 00:04:53,530 +time. We'll add a feature. We'll change one bit of the + +99 +00:04:53,530 --> 00:04:57,088 +user interface here. We'll port it to a new platform, some + +100 +00:04:57,088 --> 00:05:00,990 +kind of a, a mobile platform, for example. And pretty soon, + +101 +00:05:00,990 --> 00:05:03,750 +what you end up with is really a software system that, + +102 +00:05:03,750 --> 00:05:06,990 +that is maybe a distant relative of your original + +103 +00:05:06,990 --> 00:05:10,500 +system. It is a mutant in many ways, because often + +104 +00:05:10,500 --> 00:05:12,986 +times these little tinkerings happen on a one off + +105 +00:05:12,986 --> 00:05:15,610 +basis. There is no over-arching vision of how you should + +106 +00:05:15,610 --> 00:05:19,060 +do this. So, you are basically going through a + +107 +00:05:19,060 --> 00:05:21,980 +subsequent set of steps where you are making locally optimal + +108 +00:05:21,980 --> 00:05:25,240 +decisions for any one of these changes and what + +109 +00:05:25,240 --> 00:05:29,140 +you might end up finding is that the globally optimal + +110 +00:05:29,140 --> 00:05:32,100 +behavior of the system is badly compromised. The structural + +111 +00:05:32,100 --> 00:05:34,952 +soundness in a sense of the system badly compromised. + +112 +00:05:34,952 --> 00:05:38,510 +The non-functional properties of the system could be seriously + +113 +00:05:38,510 --> 00:05:42,390 +affected. This is how security flaws creep into systems. This + +114 +00:05:42,390 --> 00:05:44,250 +is how reliability flaws. This is how we use + +115 +00:05:44,250 --> 00:05:48,420 +the usability of a system often times suffers. And most + +116 +00:05:48,420 --> 00:05:50,920 +importantly for software engineers, the people who actually build the + +117 +00:05:50,920 --> 00:05:54,950 +software, the maintainability of the system becomes a huge problem. + +118 +00:05:54,950 --> 00:05:59,130 +Because now you're looking at this thing, it's got all these various appendages, + +119 +00:05:59,130 --> 00:06:03,170 +its original design has pretty badly eroded and yet somehow you have to + +120 +00:06:03,170 --> 00:06:06,850 +figure out how to keep fixing it. Making sure that it operates in + +121 +00:06:06,850 --> 00:06:11,380 +a continuous fashion because many of these systems live for 20, 30, 40 years. + +122 +00:06:11,380 --> 00:06:13,840 +>> Thank you so much for your insight; it is a perfect + +123 +00:06:13,840 --> 00:06:16,500 +introduction for our lesson. So we'll get to the lesson now. And. + +124 +00:06:16,500 --> 00:06:17,920 +>> Thank you very much. + +125 +00:06:17,920 --> 00:06:18,300 +>> Thank you. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt new file mode 100644 index 0000000..b4ee115 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt @@ -0,0 +1,111 @@ +1 +00:00:00,210 --> 00:00:01,569 +The last topic I want to cover in + +2 +00:00:01,569 --> 00:00:04,939 +this lesson is architectural styles. So, let's see + +3 +00:00:04,939 --> 00:00:07,400 +what those architectural styles are. There are certain + +4 +00:00:07,400 --> 00:00:10,240 +design choices that when applied in a given context + +5 +00:00:10,240 --> 00:00:14,420 +regularly result in solutions with superior properties. What + +6 +00:00:14,420 --> 00:00:17,290 +this means is that, compared to other possible alternatives, + +7 +00:00:17,290 --> 00:00:20,952 +these solutions are more elegant, effective, efficient, dependable, + +8 +00:00:20,952 --> 00:00:25,560 +evolve-able, scale-able, and so on. Architectural styles capture exactly + +9 +00:00:25,560 --> 00:00:28,490 +these solutions. They capture idioms that we can + +10 +00:00:28,490 --> 00:00:30,870 +use when designing a system. For a more formal + +11 +00:00:30,870 --> 00:00:34,160 +definition, let's look how Mary Shaw and David Garlan + +12 +00:00:34,160 --> 00:00:37,480 +define a architectural style. They say that an architectural + +13 +00:00:37,480 --> 00:00:40,000 +style defines a family of systems in terms + +14 +00:00:40,000 --> 00:00:43,550 +of a pattern of structural organization; a vocabulary of + +15 +00:00:43,550 --> 00:00:47,880 +components and connectors and constraints on how these components + +16 +00:00:47,880 --> 00:00:50,620 +and connectors can be combined. So in summary we + +17 +00:00:50,620 --> 00:00:53,650 +can say that an architectural style is a named collection + +18 +00:00:53,650 --> 00:00:57,680 +of architectural design decisions applicable in a given context. And I + +19 +00:00:57,680 --> 00:01:00,100 +want to stress that it is important to study and + +20 +00:01:00,100 --> 00:01:04,670 +know these architectural styles for several reasons. Because knowing them allows + +21 +00:01:04,670 --> 00:01:07,660 +us to avoid reinventing the wheel. It also allows us + +22 +00:01:07,660 --> 00:01:10,330 +to choose the right solution to a known problem and in + +23 +00:01:10,330 --> 00:01:12,910 +some cases it even allows us to move on and + +24 +00:01:12,910 --> 00:01:16,400 +discover even more advanced styles if we know the basic ones. + +25 +00:01:16,400 --> 00:01:19,340 +So we should be familiar with architectural styles, what + +26 +00:01:19,340 --> 00:01:22,000 +they are, and in which context they work, and + +27 +00:01:22,000 --> 00:01:23,800 +in which context they do not work. So as + +28 +00:01:23,800 --> 00:01:26,090 +to be able to apply them in the right situations. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt new file mode 100644 index 0000000..05011c7 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt @@ -0,0 +1,239 @@ +1 +00:00:00,130 --> 00:00:02,410 +So what does it mean to know architectural styles? There + +2 +00:00:02,410 --> 00:00:06,390 +are many many, many architectural styles. So we cannot cover them + +3 +00:00:06,390 --> 00:00:08,730 +all here. What I want to do instead is, I want to + +4 +00:00:08,730 --> 00:00:10,960 +mention a few of those. And then I want to go in + +5 +00:00:10,960 --> 00:00:13,300 +more depth, on one of them. So the first item I + +6 +00:00:13,300 --> 00:00:17,420 +want to mention is pipes and filters. And pipes and filters indicate + +7 +00:00:17,420 --> 00:00:21,110 +an architectural style in which a chain of processing elements, which + +8 +00:00:21,110 --> 00:00:25,410 +can be processes, threads, co-routines, is arranged so that the output + +9 +00:00:25,410 --> 00:00:28,420 +of each element is the input of the next one + +10 +00:00:28,420 --> 00:00:31,840 +and usually with some buffering in between consecutive elements. A + +11 +00:00:31,840 --> 00:00:34,120 +typical example of this, if you're familiar with Unix are + +12 +00:00:34,120 --> 00:00:37,900 +Unix pipes, that you can use to concatenate Unix commands. + +13 +00:00:37,900 --> 00:00:40,310 +Another style I want to mention is the event driven + +14 +00:00:40,310 --> 00:00:43,540 +one. An event driven system typically consists of event + +15 +00:00:43,540 --> 00:00:46,590 +emittors, like the alarm over here, and event consumers, like + +16 +00:00:46,590 --> 00:00:50,720 +the fire truck, down here, and consumers are notified when events + +17 +00:00:50,720 --> 00:00:53,810 +of interest occurr and have the responsibility of reacting + +18 +00:00:53,810 --> 00:00:56,676 +to those events. A typical example will be a GUI, + +19 +00:00:56,676 --> 00:00:59,950 +in which widgets generate events and listeners listen to those + +20 +00:00:59,950 --> 00:01:02,550 +events and react to them. For example, they react to + +21 +00:01:02,550 --> 00:01:05,060 +the push of a button. A very commonly used + +22 +00:01:05,060 --> 00:01:09,250 +architectural style is Publish-subscribe, represented by the paper boy. Over + +23 +00:01:09,250 --> 00:01:12,420 +here. And this is an architectural style in which senders + +24 +00:01:12,420 --> 00:01:15,870 +of messages, they're called publishers, do not send messages directly + +25 +00:01:15,870 --> 00:01:19,330 +to specific recievers. Instead, they publish messages with one + +26 +00:01:19,330 --> 00:01:22,530 +or more associated texts without knowledge of who will + +27 +00:01:22,530 --> 00:01:26,810 +receive such messages. Similarly subscribers will express interest in + +28 +00:01:26,810 --> 00:01:29,340 +one or more tags. And will only receive messages of + +29 +00:01:29,340 --> 00:01:32,095 +interest according to such tags. A typical example of + +30 +00:01:32,095 --> 00:01:35,240 +a publish-subscribe system, will be Twitter. And I'm pretty + +31 +00:01:35,240 --> 00:01:36,835 +sure that most of you are familiar with the + +32 +00:01:36,835 --> 00:01:41,170 +client-server architecture. In which computers in a network, assume one + +33 +00:01:41,170 --> 00:01:43,930 +of two roles. The server provides the resources and + +34 +00:01:43,930 --> 00:01:47,630 +functionality. And the client initiates contact with the server, + +35 +00:01:47,630 --> 00:01:50,920 +and requests the use of those resources and functionality. + +36 +00:01:50,920 --> 00:01:53,340 +Also in this case, a typical example would be + +37 +00:01:53,340 --> 00:01:56,470 +email, in which an email server provides email storage + +38 +00:01:56,470 --> 00:01:59,390 +and management capabilities, and an email client will use + +39 +00:01:59,390 --> 00:02:02,580 +those capabilities. You may also be familiar with peer-to-peer, + +40 +00:02:02,580 --> 00:02:06,530 +or P2P, systems. A P2P system is a type + +41 +00:02:06,530 --> 00:02:10,850 +of decentralized and distributed network system in which individual nodes + +42 +00:02:10,850 --> 00:02:14,220 +in the network, that are called peers, act as independent + +43 +00:02:14,220 --> 00:02:17,940 +agents that are both suppliers and consumers of resources. This + +44 +00:02:17,940 --> 00:02:20,700 +is in contrast to the centralized client-server model, where client + +45 +00:02:20,700 --> 00:02:23,660 +nodes interact with the central authority. And I'm not going to + +46 +00:02:23,660 --> 00:02:26,030 +say anything more about peer-to-peer, because I'm going to show you + +47 +00:02:26,030 --> 00:02:28,940 +two examples, of peer-to-peer systems in the rest of the + +48 +00:02:28,940 --> 00:02:32,040 +lesson. And you probably have at least heard of rest. + +49 +00:02:32,040 --> 00:02:33,990 +Which in this case is not an invitation to + +50 +00:02:33,990 --> 00:02:36,970 +relax as the graphic might indicate. But rather stands for + +51 +00:02:36,970 --> 00:02:41,400 +Representational State Transfer. REST is a hybrid architectural style + +52 +00:02:41,400 --> 00:02:45,150 +for distributed hypermedia systems, that is derived from several other + +53 +00:02:45,150 --> 00:02:48,210 +network based architectural styles. And that is characterized by + +54 +00:02:48,210 --> 00:02:51,970 +uniform connector interface, and even if I'm not going to say + +55 +00:02:51,970 --> 00:02:54,230 +anything else about the rest, I wanted to mention + +56 +00:02:54,230 --> 00:02:57,440 +it, because it is an extremely well known architectural style. + +57 +00:02:57,440 --> 00:02:59,300 +And the reason for this is that REST is + +58 +00:02:59,300 --> 00:03:03,310 +very widely used, because it is basically the architectural style + +59 +00:03:03,310 --> 00:03:06,050 +that governs the world wide web. So we use it + +60 +00:03:06,050 --> 00:03:08,330 +all the time when we browse the internet, for instance. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..2e8c051 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt @@ -0,0 +1,27 @@ +1 +00:00:00,090 --> 00:00:02,630 +Consider now the following architectural styles + +2 +00:00:02,630 --> 00:00:04,356 +that we just saw: pipes and filters, + +3 +00:00:04,356 --> 00:00:09,310 +event-driven, publish-subscribe, client-server, peer-to-peer, and rest. + +4 +00:00:09,310 --> 00:00:11,150 +I'm showing you here, a list of + +5 +00:00:11,150 --> 00:00:15,220 +four different systems, and I would like for you to mark here which + +6 +00:00:15,220 --> 00:00:18,750 +architectural style, or styles, characterize Each of + +7 +00:00:18,750 --> 00:00:21,510 +these systems. Again, mark all that apply. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt new file mode 100644 index 0000000..d48320b --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt @@ -0,0 +1,79 @@ +1 +00:00:00,150 --> 00:00:02,680 +Okay, let's start with the Android Operating System. The Android + +2 +00:00:02,680 --> 00:00:07,170 +system, heavily based on the generation and handling of events, + +3 +00:00:07,170 --> 00:00:10,640 +so it is mostly an event driven system. However, it + +4 +00:00:10,640 --> 00:00:13,870 +also has some elements of publish, subscribe, in the way + +5 +00:00:13,870 --> 00:00:17,480 +elements in the system can register for elements of interest. + +6 +00:00:17,480 --> 00:00:20,570 +So we can mark both styles here. So what about + +7 +00:00:20,570 --> 00:00:23,449 +Skype? We haven't discussed Skype yet. So here we probably + +8 +00:00:23,449 --> 00:00:25,019 +had to take a little bit of a wild guess. + +9 +00:00:25,019 --> 00:00:27,068 +But as we will see in more detail in the + +10 +00:00:27,068 --> 00:00:29,736 +rest of the lesson. Skype is mainly a peer to + +11 +00:00:29,736 --> 00:00:34,035 +peer architecture, with some minimal elements of a client server + +12 +00:00:34,035 --> 00:00:37,770 +architecture. For example, when you start Skype and sign in + +13 +00:00:37,770 --> 00:00:40,420 +to a conceptually centralized server. So let's move to the + +14 +00:00:40,420 --> 00:00:42,930 +World Wide Web. As we just discussed, the Word Wide + +15 +00:00:42,930 --> 00:00:46,255 +Web is based on a rest architecture. And because rest + +16 +00:00:46,255 --> 00:00:50,170 +style, is a hybrid derived from other architectural styles, including the + +17 +00:00:50,170 --> 00:00:53,960 +client server architectural styles. Both of those styles apply here. + +18 +00:00:53,960 --> 00:00:57,465 +And finally Dropbox is by and large, a client server + +19 +00:00:57,465 --> 00:01:01,904 +architecture. As conceptually, we upload our documents to a Dropbox + +20 +00:01:01,904 --> 00:01:05,370 +central server, and get the files from the same server. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt new file mode 100644 index 0000000..927c773 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt @@ -0,0 +1,39 @@ +1 +00:00:00,170 --> 00:00:02,110 +We're not going to be able to study indepth + +2 +00:00:02,110 --> 00:00:05,590 +any of the architectural styles that we just discussed. However, I + +3 +00:00:05,590 --> 00:00:08,790 +want to at least discuss two representative examples of P2P + +4 +00:00:08,790 --> 00:00:12,100 +architectures. Because, these are systems that you probably used, or at + +5 +00:00:12,100 --> 00:00:14,090 +least, you used one of them. And, they will allow + +6 +00:00:14,090 --> 00:00:17,590 +me to highlight some interesting points. So, as we just mentioned, + +7 +00:00:17,590 --> 00:00:22,450 +P2P systems are decentralized resource sharing and discovery systems. And the + +8 +00:00:22,450 --> 00:00:25,370 +two systems that I want to discuss, and that are representative + +9 +00:00:25,370 --> 00:00:29,630 +of this kind of architectures, are Napster and Skype. And you may or + +10 +00:00:29,630 --> 00:00:32,920 +may not be familiar with Napster, but I'm pretty sure that you know Skype. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt new file mode 100644 index 0000000..d3ab75b --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt @@ -0,0 +1,231 @@ +1 +00:00:00,160 --> 00:00:03,160 +So let's start by considering Napster. In it's first + +2 +00:00:03,160 --> 00:00:07,210 +incarnation, Napster was a peer-to-peer file sharing system. And + +3 +00:00:07,210 --> 00:00:10,200 +it was mostly used, actually, to illegally share mp3s. + +4 +00:00:10,200 --> 00:00:12,630 +Which is also why it got sued and later + +5 +00:00:12,630 --> 00:00:16,129 +on, it basically ceased operations. But nevertheless, I think + +6 +00:00:16,129 --> 00:00:19,710 +Napster is an interesting example of mixed architecture. And + +7 +00:00:19,710 --> 00:00:22,020 +I'm going to illustrate the way Napster works by showing + +8 +00:00:22,020 --> 00:00:25,820 +you, here, the basic configuration of Napster and the interactions + +9 +00:00:25,820 --> 00:00:28,950 +between its elements. So let's look at how such interaction + +10 +00:00:28,950 --> 00:00:32,250 +can take place for the three peers shown here. And + +11 +00:00:32,250 --> 00:00:34,430 +in this case Peer A and B are the only + +12 +00:00:34,430 --> 00:00:37,290 +ones really involved in the action. So let's look at + +13 +00:00:37,290 --> 00:00:40,700 +a typical sequence of events for the Napster system. We + +14 +00:00:40,700 --> 00:00:44,340 +have Peer A that will start by registering, here, with + +15 +00:00:44,340 --> 00:00:47,530 +the content directory. Peer B will also register with the + +16 +00:00:47,530 --> 00:00:50,970 +content directory. And when these two peers register, the content directory + +17 +00:00:50,970 --> 00:00:54,370 +will know what kind of content they can provide. Later on, + +18 +00:00:54,370 --> 00:00:57,660 +Peer A will request a song. And one first observation that + +19 +00:00:57,660 --> 00:01:00,550 +we can make, based on this interaction, is the fact that, + +20 +00:01:00,550 --> 00:01:03,900 +up to now, this is a purely client-server system. This is + +21 +00:01:03,900 --> 00:01:06,530 +the client. This is the client. And this is the server. + +22 +00:01:06,530 --> 00:01:10,320 +And the interaction is a typical client-server interaction. But now we're + +23 +00:01:10,320 --> 00:01:12,410 +at the point in which things start to change a little + +24 +00:01:12,410 --> 00:01:16,008 +bit. At this point, after Peer A has requested the song, + +25 +00:01:16,008 --> 00:01:18,820 +the peer and content directory will look up its + +26 +00:01:18,820 --> 00:01:22,730 +gigantic index and will see that Peer B actually has + +27 +00:01:22,730 --> 00:01:24,850 +the song that Peer A requested. So it will + +28 +00:01:24,850 --> 00:01:27,690 +send to Peer A a handle that Peer A can + +29 +00:01:27,690 --> 00:01:31,052 +use to connect directly to Peer B. So this + +30 +00:01:31,052 --> 00:01:34,540 +is where the system is no longer a client-server system. + +31 +00:01:34,540 --> 00:01:37,890 +Because at this point, the two peers are connected directly. + +32 +00:01:37,890 --> 00:01:41,000 +So at this point, we have a peer-to-peer interaction. And, + +33 +00:01:41,000 --> 00:01:43,770 +after getting the request from Peer A, then Peer B + +34 +00:01:43,770 --> 00:01:47,170 +will start sending the content to Peer A. And I said + +35 +00:01:47,170 --> 00:01:50,660 +earlier that one of the useful things about representing an + +36 +00:01:50,660 --> 00:01:52,440 +architecture and interaction within an + +37 +00:01:52,440 --> 00:01:54,580 +architecture graphically, is the fact that + +38 +00:01:54,580 --> 00:01:57,550 +it allows you to spot possible problems. And in this + +39 +00:01:57,550 --> 00:02:00,666 +case, by representing the Napster architecture in this way, and by + +40 +00:02:00,666 --> 00:02:03,300 +studying how things work, we can see that there's an + +41 +00:02:03,300 --> 00:02:06,010 +issue with the architecture of Napster that will not make this + +42 +00:02:06,010 --> 00:02:10,020 +architecture scale. As some of you might have already noticed, this peer + +43 +00:02:10,020 --> 00:02:13,720 +and content directory is a single point of failure, and is very + +44 +00:02:13,720 --> 00:02:17,230 +likely to cause problems when the number of peers grows too large. + +45 +00:02:17,230 --> 00:02:19,890 +Because at that point, there are going to be too many requests to + +46 +00:02:19,890 --> 00:02:22,840 +the peer and content directory, and the peer and content directory is + +47 +00:02:22,840 --> 00:02:25,460 +unlikely to be able to keep up with all the requests. So + +48 +00:02:25,460 --> 00:02:27,840 +some changes in the architecture will have to be made. In the + +49 +00:02:27,840 --> 00:02:31,310 +case of Napster, we didn't see this problem occurring because, as I said + +50 +00:02:31,310 --> 00:02:34,420 +earlier, Napster got sued and ceased operation before the problem + +51 +00:02:34,420 --> 00:02:37,650 +actually manifested. Now looking at the system for an architecture-style + +52 +00:02:37,650 --> 00:02:40,560 +perspective, we can see that Napster was a hybrid architecture + +53 +00:02:40,560 --> 00:02:43,920 +with both client-server and peer-to-peer elements. And something I would + +54 +00:02:43,920 --> 00:02:45,870 +like to stress here, is that this is not at + +55 +00:02:45,870 --> 00:02:49,400 +all uncommon. So in real world nontrivial architectures, it is + +56 +00:02:49,400 --> 00:02:52,470 +very common to see multiple styles used in the same + +57 +00:02:52,470 --> 00:02:56,209 +system. The next system that we will consider, Skype, is instead, + +58 +00:02:56,209 --> 00:02:59,885 +an example of a well-designed, almost purely peer-to-peer system. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt new file mode 100644 index 0000000..2118c73 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt @@ -0,0 +1,287 @@ +1 +00:00:00,220 --> 00:00:03,040 +So even if you're too young to have used Napster, + +2 +00:00:03,040 --> 00:00:06,150 +I'm pretty sure that most of you know and use Skype, + +3 +00:00:06,150 --> 00:00:10,180 +a Voice Over IP and instant messaging service. Many of + +4 +00:00:10,180 --> 00:00:13,790 +you, however, probably don't know how Skype works. To understand that, + +5 +00:00:13,790 --> 00:00:16,360 +let's have a look at Skype's architecture, which I'm sketching + +6 +00:00:16,360 --> 00:00:19,890 +here, and which is a peer-to-peer architecture with a small twist. + +7 +00:00:19,890 --> 00:00:22,300 +So first of all, by looking at the architecture we can + +8 +00:00:22,300 --> 00:00:25,600 +see that whereas Napster was a client-server system with an element + +9 +00:00:25,600 --> 00:00:29,960 +of peer-to-peer, Skype is a much more decentralized system. Why + +10 +00:00:29,960 --> 00:00:31,940 +is that? Well, if we look here, we can see + +11 +00:00:31,940 --> 00:00:34,720 +that there is a login server -- this node over + +12 +00:00:34,720 --> 00:00:38,670 +here -- and that means that every Skype user has to register + +13 +00:00:38,670 --> 00:00:42,000 +with this centralized service. But that's the only interaction of + +14 +00:00:42,000 --> 00:00:44,930 +this kind within Skype. After you log in, all you + +15 +00:00:44,930 --> 00:00:47,580 +get is a connection through a super node like this + +16 +00:00:47,580 --> 00:00:50,760 +one. So, what are super nodes? Super nodes are highly reliable + +17 +00:00:50,760 --> 00:00:54,680 +nodes with high bandwidth that are not behind a firewall + +18 +00:00:54,680 --> 00:00:58,180 +and that runs Skype regularly, which means that nodes that shut + +19 +00:00:58,180 --> 00:01:01,540 +down Skype occasionally will not qualify as super nodes. And one + +20 +00:01:01,540 --> 00:01:04,239 +interesting thing about super nodes is that they're not owned by + +21 +00:01:04,239 --> 00:01:07,990 +Skype. They're just regular nodes that get promoted by Skype to + +22 +00:01:07,990 --> 00:01:11,500 +super nodes, and that know about each other. So basically Skype + +23 +00:01:11,500 --> 00:01:13,710 +has an algorithm that looks at the nodes in the system + +24 +00:01:13,710 --> 00:01:15,880 +and decides whether a node can be a super node or + +25 +00:01:15,880 --> 00:01:18,932 +not based on its characteristics. So now that we've discussed + +26 +00:01:18,932 --> 00:01:22,040 +super nodes, let's see what will happen if peer two wanted + +27 +00:01:22,040 --> 00:01:25,091 +to communicate with peer three. So let's represent this by + +28 +00:01:25,091 --> 00:01:27,956 +creating a dashed line between peer two and peer three. In + +29 +00:01:27,956 --> 00:01:30,980 +this case, peer two will contact this super node, which + +30 +00:01:30,980 --> 00:01:33,750 +is super node A. And super node A, based on its + +31 +00:01:33,750 --> 00:01:36,570 +knowledge of the Skype network and the position of the super + +32 +00:01:36,570 --> 00:01:40,930 +nodes, will contact and route the communication through super node C, + +33 +00:01:40,930 --> 00:01:44,100 +which will in turn route the communication to peer three. + +34 +00:01:44,100 --> 00:01:46,620 +And in that way peer two and peer three will be + +35 +00:01:46,620 --> 00:01:50,740 +able to communicate with each other. And this will happen just + +36 +00:01:50,740 --> 00:01:53,970 +as if peer two and peer three were connected directly, as + +37 +00:01:53,970 --> 00:01:57,760 +peers, even though the communication goes through two super nodes. Another + +38 +00:01:57,760 --> 00:02:00,470 +thing that is important to know about the behavior of Skype + +39 +00:02:00,470 --> 00:02:03,760 +is that, if the link between super nodes A and C + +40 +00:02:03,760 --> 00:02:05,950 +were to go down. So let's assume that there is a + +41 +00:02:05,950 --> 00:02:10,840 +problem with this link, then Skype will automatically, or automagically + +42 +00:02:10,840 --> 00:02:14,550 +reroute the communication through super node B, which will in + +43 +00:02:14,550 --> 00:02:17,950 +turn reroute it super node C, which will again reroute + +44 +00:02:17,950 --> 00:02:20,020 +to peer three. So peer two and three will still + +45 +00:02:20,020 --> 00:02:22,550 +be connected, but this time they will be going through + +46 +00:02:22,550 --> 00:02:25,620 +three super nodes. And just in case you wondered, this + +47 +00:02:25,620 --> 00:02:28,620 +is exactly what happens when you are talking over Skype. + +48 +00:02:28,620 --> 00:02:31,790 +The quality of the communication degrades, and you are reconnected. + +49 +00:02:31,790 --> 00:02:34,880 +So there is this rerouting going on through different nodes. So + +50 +00:02:34,880 --> 00:02:37,640 +although this architecture is more effective than the Napster's one, it + +51 +00:02:37,640 --> 00:02:40,640 +is not without problems. For example, you might remember that a + +52 +00:02:40,640 --> 00:02:44,640 +few years ago, Skype went down for about 36 hours. And + +53 +00:02:44,640 --> 00:02:47,880 +later on it was discovered that the cause was the algorithm + +54 +00:02:47,880 --> 00:02:51,460 +used by Skype to determine which nodes could be super nodes. + +55 +00:02:51,460 --> 00:02:54,330 +And remember, as I said, that one requirement for these nodes + +56 +00:02:54,330 --> 00:02:57,130 +is that have to up all the time. So what happened + +57 +00:02:57,130 --> 00:03:00,420 +is most of the super nodes were running on Windows machines, + +58 +00:03:00,420 --> 00:03:03,820 +and Microsoft pushed a critical patch that required a reboot to + +59 +00:03:03,820 --> 00:03:06,860 +be installed. So a large number of machines, and therefore a + +60 +00:03:06,860 --> 00:03:10,150 +large number of super nodes were down roughly at the same + +61 +00:03:10,150 --> 00:03:13,980 +time throughout the globe. And Skype's algorithm for determining super nodes + +62 +00:03:13,980 --> 00:03:17,230 +didn't have enough nodes to work with. So the whole system + +63 +00:03:17,230 --> 00:03:19,790 +crashed and burned. So the message I want to give here, + +64 +00:03:19,790 --> 00:03:22,340 +is that when you have a large peer to peer distributed + +65 +00:03:22,340 --> 00:03:24,650 +system, such as this one, such as Skype, + +66 +00:03:24,650 --> 00:03:27,200 +these kind of perfect storms can happen. Because you + +67 +00:03:27,200 --> 00:03:29,560 +are not really in control. Because the control + +68 +00:03:29,560 --> 00:03:33,170 +is distributed. So the algorithms become more complex. So + +69 +00:03:33,170 --> 00:03:35,140 +to wrap up our Skype example, in case + +70 +00:03:35,140 --> 00:03:37,280 +you are interested, Skype then fixed the issue by + +71 +00:03:37,280 --> 00:03:39,950 +changing the algorithm for identifying super nodes. And + +72 +00:03:39,950 --> 00:03:44,084 +more recently actually, Skype ditched peer-to-peer super nodes altogether. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt new file mode 100644 index 0000000..9cd15c3 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt @@ -0,0 +1,131 @@ +1 +00:00:00,100 --> 00:00:02,620 +And I want to conclude this lesson with three takeaway + +2 +00:00:02,620 --> 00:00:06,190 +messages. The first one is that having an effective architecture is + +3 +00:00:06,190 --> 00:00:09,450 +fundamental in a software project. Or as I say here, + +4 +00:00:09,450 --> 00:00:13,050 +a great architecture is a ticket to a successful project. To + +5 +00:00:13,050 --> 00:00:15,290 +put it in a different way, although a great architecture + +6 +00:00:15,290 --> 00:00:17,940 +does not guarantee that your project will be successful, having a + +7 +00:00:17,940 --> 00:00:21,930 +poor architecture will make it much more difficult for your project + +8 +00:00:21,930 --> 00:00:25,280 +to be successful. The second message is that an architecture cannot + +9 +00:00:25,280 --> 00:00:28,120 +come about in a vacuum. You need to understand + +10 +00:00:28,120 --> 00:00:30,550 +the domain of the problem that you're trying to solve + +11 +00:00:30,550 --> 00:00:33,480 +in order to define an architectural solution that fits the + +12 +00:00:33,480 --> 00:00:37,220 +characteristics of the problem. So a great architecture reflects a + +13 +00:00:37,220 --> 00:00:40,500 +deep understanding of the problem domain. And finally, a great + +14 +00:00:40,500 --> 00:00:44,630 +architecture is likely to combine aspects of several simpler architectures. + +15 +00:00:44,630 --> 00:00:47,880 +It is typical for engineers to see problems that are + +16 +00:00:47,880 --> 00:00:50,590 +new, but such that parts of the problems have already + +17 +00:00:50,590 --> 00:00:53,540 +been solved by someone else. An effective engineer should + +18 +00:00:53,540 --> 00:00:56,270 +therefore, first of all, know what is out there, + +19 +00:00:56,270 --> 00:00:59,760 +know the solution space. Second, an engineer should understand + +20 +00:00:59,760 --> 00:01:02,420 +what has worked well and what has failed miserably in + +21 +00:01:02,420 --> 00:01:05,870 +similar occasions in the past. And finally, an effective + +22 +00:01:05,870 --> 00:01:10,100 +engineer should be able to suitably combine existing solutions appropriately + +23 +00:01:10,100 --> 00:01:12,870 +to come up with an effective overall solution for + +24 +00:01:12,870 --> 00:01:15,750 +the specific problem at hand. And this is just as + +25 +00:01:15,750 --> 00:01:18,960 +true in the context of software architectures. When defining a software + +26 +00:01:18,960 --> 00:01:22,330 +architecture, you should innovate only as much as you need to and + +27 +00:01:22,330 --> 00:01:24,850 +reuse as much as you can. As we said early in the + +28 +00:01:24,850 --> 00:01:27,770 +lesson, by doing so, that is, by innovating only as much as + +29 +00:01:27,770 --> 00:01:30,100 +you need to and reusing as much as you can, you will + +30 +00:01:30,100 --> 00:01:32,960 +be able to avoid reinventing the wheel. You will be able to + +31 +00:01:32,960 --> 00:01:37,320 +choose the right solution to known problems. And identify suitable solutions for + +32 +00:01:37,320 --> 00:01:40,925 +new problems. So ultimately, you will be able to realize an effective + +33 +00:01:40,925 --> 00:01:44,080 +software architecture that will help the success of your project. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt new file mode 100644 index 0000000..8689e43 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt @@ -0,0 +1,127 @@ +1 +00:00:00,140 --> 00:00:02,460 +After this interesting conversation with Neno, let me start + +2 +00:00:02,460 --> 00:00:06,060 +the lesson by defining what a software architecture is. + +3 +00:00:06,060 --> 00:00:07,600 +And to do that, I'm going to use two + +4 +00:00:07,600 --> 00:00:11,030 +seminal definitions. The first one is from Dewayne Perry + +5 +00:00:11,030 --> 00:00:13,990 +and Alex Wolf. And they define a software architecture + +6 +00:00:13,990 --> 00:00:17,940 +as elements, form and rationale. In this definition, the + +7 +00:00:17,940 --> 00:00:21,300 +elements are the what, which means the processes, data, + +8 +00:00:21,300 --> 00:00:25,430 +and connectors that compose a software architecture. The form + +9 +00:00:25,430 --> 00:00:27,780 +is the how, the set of properties of + +10 +00:00:27,780 --> 00:00:32,030 +in relationships among these elements. And, finally, the rationale + +11 +00:00:32,030 --> 00:00:35,390 +is the why, the justification for the elements and + +12 +00:00:35,390 --> 00:00:38,440 +their relationships. The second definition I want to use + +13 +00:00:38,440 --> 00:00:40,710 +is from Mary Shaw and David Garland. And + +14 +00:00:40,710 --> 00:00:43,480 +they defined a software architecture as a level of + +15 +00:00:43,480 --> 00:00:47,300 +design that involves four main things, a description of + +16 +00:00:47,300 --> 00:00:50,860 +elements from which these systems are built, the interactions + +17 +00:00:50,860 --> 00:00:54,800 +among those elements, the patterns that guide their composition, and + +18 +00:00:54,800 --> 00:00:58,320 +finally, the constraints on these patterns. As you can see, these + +19 +00:00:58,320 --> 00:01:01,420 +definitions are fairly similar and there are many more alternative + +20 +00:01:01,420 --> 00:01:04,870 +definitions of software architecture. In fact, if we try to search + +21 +00:01:04,870 --> 00:01:08,540 +the term software architecture, we get over two million entries. + +22 +00:01:08,540 --> 00:01:10,670 +And if we look at the images in the results of + +23 +00:01:10,670 --> 00:01:13,110 +the search this is what we get. And I like this + +24 +00:01:13,110 --> 00:01:16,120 +sort of graphical depiction because it gives you a clear idea + +25 +00:01:16,120 --> 00:01:19,300 +the software architecture are prevalent concept, given the number of + +26 +00:01:19,300 --> 00:01:22,600 +results. But they also show you clearly, that software architecture are + +27 +00:01:22,600 --> 00:01:25,550 +complex entities, if you look at some of these pictures. + +28 +00:01:25,550 --> 00:01:28,930 +And ultimately, they show that software architecture are presented in all + +29 +00:01:28,930 --> 00:01:31,700 +kinds of ways including in 3D, if you look at this + +30 +00:01:31,700 --> 00:01:34,970 +picture. We cannot clearly cover all of these definitions in one + +31 +00:01:34,970 --> 00:01:37,340 +lesson. So what I will do instead, is to introduce + +32 +00:01:37,340 --> 00:01:40,750 +a very general definition that encompasses most of the existing ones. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt new file mode 100644 index 0000000..13042a7 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt @@ -0,0 +1,131 @@ +1 +00:00:00,110 --> 00:00:03,240 +I'm going to define a software systems architecture as + +2 +00:00:03,240 --> 00:00:07,660 +the set of principal design decisions about the system. Where + +3 +00:00:07,660 --> 00:00:10,950 +principal here, implies a degree of importance, that grants + +4 +00:00:10,950 --> 00:00:14,810 +a design decision architectural status. And the point here, as + +5 +00:00:14,810 --> 00:00:17,060 +we discussed with Neno early on, is that when + +6 +00:00:17,060 --> 00:00:20,210 +building a system, we make tons of design decisions, and + +7 +00:00:20,210 --> 00:00:22,470 +most of them do not affect the architecture of + +8 +00:00:22,470 --> 00:00:25,270 +the system. For example, the effect of choosing a for + +9 +00:00:25,270 --> 00:00:27,640 +loop, instead of a while loop, in the code, or the + +10 +00:00:27,640 --> 00:00:30,140 +fact of deciding that we are going to use data structure A + +11 +00:00:30,140 --> 00:00:33,620 +instead of data structure B. Some decisions however, do affect the + +12 +00:00:33,620 --> 00:00:37,470 +architecture of the system. And in some cases the distinction between these + +13 +00:00:37,470 --> 00:00:40,600 +two kinds of design decisions is clear. In some other cases + +14 +00:00:40,600 --> 00:00:43,340 +it is much fuzzier and it depends on the context. The + +15 +00:00:43,340 --> 00:00:46,000 +bottom line here, is that if you believe that something is + +16 +00:00:46,000 --> 00:00:50,380 +an important design decision, that becomes an architectural decision. That is a + +17 +00:00:50,380 --> 00:00:53,960 +decision that impacts a system's architecture. In this spirit, + +18 +00:00:53,960 --> 00:00:56,650 +we can see a software architecture as the blueprint + +19 +00:00:56,650 --> 00:00:58,390 +for a software system, that we can use to + +20 +00:00:58,390 --> 00:01:01,320 +construct and evolve the system. And the key point + +21 +00:01:01,320 --> 00:01:05,300 +about software architecture is that this blueprint encompasses every + +22 +00:01:05,300 --> 00:01:08,600 +facet of the system under development. It encompasses its + +23 +00:01:08,600 --> 00:01:11,540 +structure, of course, but not only. It also involves + +24 +00:01:11,540 --> 00:01:15,420 +the behavior of the system, the interactions within the system, + +25 +00:01:15,420 --> 00:01:18,880 +and the non-functional properties of the system. And we will see + +26 +00:01:18,880 --> 00:01:21,960 +how this happens in the rest of the lesson. Another important + +27 +00:01:21,960 --> 00:01:25,590 +point about software architecture is that there is a temporal aspect + +28 +00:01:25,590 --> 00:01:27,570 +to it. And the point here is that you don't build the + +29 +00:01:27,570 --> 00:01:30,660 +software architecture in a single shot, but you do it iteratively, + +30 +00:01:30,660 --> 00:01:34,100 +over time. So, basically, you go from having no architecture to + +31 +00:01:34,100 --> 00:01:37,330 +your final architecture. So, at any point in time, there is + +32 +00:01:37,330 --> 00:01:40,550 +a software architecture, but it will change over time. And this happens + +33 +00:01:40,550 --> 00:01:44,780 +because design decisions are made, unmade and changed over a system's lifetime. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt new file mode 100644 index 0000000..11ecd46 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt @@ -0,0 +1,51 @@ +1 +00:00:00,120 --> 00:00:02,200 +We can look at the software architecture from two + +2 +00:00:02,200 --> 00:00:07,120 +main standpoints. There are prescriptive and descriptive software architectures. + +3 +00:00:07,120 --> 00:00:09,900 +So what does that mean? A prescriptive architecture captures + +4 +00:00:09,900 --> 00:00:12,620 +the design decisions that are made prior to the + +5 +00:00:12,620 --> 00:00:15,398 +system's construction. This is what we normally call the + +6 +00:00:15,398 --> 00:00:18,280 +as-conceived software architecture. Conversely, + +7 +00:00:18,280 --> 00:00:20,550 +a descriptive architecture describes how + +8 +00:00:20,550 --> 00:00:23,010 +the system has actually been built. So it's based + +9 +00:00:23,010 --> 00:00:25,860 +on observing the system as it is and extracting + +10 +00:00:25,860 --> 00:00:28,200 +the architecture from the observation. This is what we call + +11 +00:00:28,200 --> 00:00:31,890 +the as-implemented software architecture. And one key point here is + +12 +00:00:31,890 --> 00:00:35,780 +that often, these two architectures, the prescriptive and the descriptive + +13 +00:00:35,780 --> 00:00:39,290 +architectures end up being different. So let's see why that happens. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt new file mode 100644 index 0000000..edcf77e --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt @@ -0,0 +1,115 @@ +1 +00:00:00,090 --> 00:00:02,810 +To do that let's look at how architectural evolution + +2 +00:00:02,810 --> 00:00:06,880 +occurs in practice. Ideally when a system evolves, its prescriptive + +3 +00:00:06,880 --> 00:00:09,340 +architecture should be modified first. Just like when you + +4 +00:00:09,340 --> 00:00:12,170 +modify a building. You change the blueprint and then you + +5 +00:00:12,170 --> 00:00:13,940 +change the actual building. You don't go the other + +6 +00:00:13,940 --> 00:00:17,820 +way around. In software, unfortunately this rarely ever happens in + +7 +00:00:17,820 --> 00:00:21,706 +practice. In practice the system, and therefore it's descriptive + +8 +00:00:21,706 --> 00:00:25,150 +architecture are often directly modified. Like in this case that + +9 +00:00:25,150 --> 00:00:27,870 +I'm showing here. So what happens is that the architecture + +10 +00:00:27,870 --> 00:00:32,259 +as conceived does not change. Whereas the architecture as implemented, does + +11 +00:00:32,259 --> 00:00:35,600 +change. And therefore these two things start diverging. And this really + +12 +00:00:35,600 --> 00:00:38,720 +happens for a number of reasons. So I'm just going to list + +13 +00:00:38,720 --> 00:00:41,740 +a few of those reasons here. In some cases it + +14 +00:00:41,740 --> 00:00:45,620 +just happens for plain sloppiness. I need to make this modification + +15 +00:00:45,620 --> 00:00:47,290 +and I don't really want to go back and look at + +16 +00:00:47,290 --> 00:00:50,610 +the prescriptive architecture modified. I'm just going to make the change, and + +17 +00:00:50,610 --> 00:00:53,800 +maybe I'll fix the description later. And then you never really get + +18 +00:00:53,800 --> 00:00:56,950 +to it. In other cases you do this because of the perception + +19 +00:00:56,950 --> 00:01:00,290 +of short deadlines. If you have to do something by this afternoon, + +20 +00:01:00,290 --> 00:01:01,300 +you're not going through a four + +21 +00:01:01,300 --> 00:01:03,410 +month software architecture review, you normally just + +22 +00:01:03,410 --> 00:01:06,460 +get to it, and do it. In some cases a prescriptive architecture + +23 +00:01:06,460 --> 00:01:09,510 +is not even present, so there's a lack of documentation. So in these + +24 +00:01:09,510 --> 00:01:12,450 +cases, clearly, you cannot go and modify something that does not even + +25 +00:01:12,450 --> 00:01:15,880 +exist, and so you jump directly to the code and start modifying that. + +26 +00:01:15,880 --> 00:01:18,280 +And as I said there's many, many more + +27 +00:01:18,280 --> 00:01:21,080 +other reasons why that happen. But important point here is + +28 +00:01:21,080 --> 00:01:23,770 +that it does happen and it does happen often + +29 +00:01:23,770 --> 00:01:27,250 +and the result is that prescriptive and descriptive architectures diverge. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt new file mode 100644 index 0000000..2313f82 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt @@ -0,0 +1,131 @@ +1 +00:00:00,150 --> 00:00:02,790 +And there are two important and related concepts that + +2 +00:00:02,790 --> 00:00:04,790 +have to do with the way software architecture + +3 +00:00:04,790 --> 00:00:08,109 +evolves. The first one is Architectural Drift, which is + +4 +00:00:08,109 --> 00:00:12,140 +the introduction of architectural design decisions that are orthogonal to + +5 +00:00:12,140 --> 00:00:15,870 +a system's prescriptive architecture. That is, they're not included + +6 +00:00:15,870 --> 00:00:20,080 +in, encompassed by, or implied by the prescriptive architecture. + +7 +00:00:20,080 --> 00:00:22,300 +And the result of Architectural Drift is that you + +8 +00:00:22,300 --> 00:00:25,220 +start from a clean architecture, like the one that I'm + +9 +00:00:25,220 --> 00:00:28,830 +showing here, and then you start adding pieces without following a clear plan. + +10 +00:00:28,830 --> 00:00:32,229 +Like, for example, here, we add an additional room here, but we don't really + +11 +00:00:32,229 --> 00:00:34,380 +do it in the right way so we need to add something else + +12 +00:00:34,380 --> 00:00:37,090 +to keep it stable. And then maybe we want some more room so we + +13 +00:00:37,090 --> 00:00:40,310 +add a tent. And then another side of the house, it doesn't really + +14 +00:00:40,310 --> 00:00:43,540 +follow the same architecture but it doesn't matter, we just put it there because + +15 +00:00:43,540 --> 00:00:46,690 +we want to expand. And maybe then we want to put something classic + +16 +00:00:46,690 --> 00:00:48,210 +there, even though it doesn't really fit + +17 +00:00:48,210 --> 00:00:50,520 +the overall design and the overall architecture. + +18 +00:00:50,520 --> 00:00:52,160 +So I think you get my point, the fact + +19 +00:00:52,160 --> 00:00:56,210 +that the architecture then becomes unnecessarily complex, hard to understand + +20 +00:00:56,210 --> 00:00:58,410 +and ultimately awkward, just like the one that I'm + +21 +00:00:58,410 --> 00:01:00,880 +showing here, that goes from the original building into this + +22 +00:01:00,880 --> 00:01:04,870 +final monstrosity. The second concept is Architectural Erosion, which + +23 +00:01:04,870 --> 00:01:08,560 +is the introduction of architectural design decisions that violate a + +24 +00:01:08,560 --> 00:01:12,070 +system prescriptive architecture. So in this case, that we were + +25 +00:01:12,070 --> 00:01:14,070 +introducing decisions that were orthogonal, + +26 +00:01:14,070 --> 00:01:15,580 +here, were introducing this decisions + +27 +00:01:15,580 --> 00:01:17,410 +that don't comply with the prescriptive + +28 +00:01:17,410 --> 00:01:20,140 +architecture. And the result of Architectural Erosion + +29 +00:01:20,140 --> 00:01:22,590 +is typically a poor architecture an + +30 +00:01:22,590 --> 00:01:24,550 +architecture that is going to have problems in + +31 +00:01:24,550 --> 00:01:27,040 +the future. So both Architectural Drift + +32 +00:01:27,040 --> 00:01:29,640 +and Architectural Erosion take you away in + +33 +00:01:29,640 --> 00:01:32,940 +different ways from what you think your software architecture is or should be. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt new file mode 100644 index 0000000..6104ae0 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt @@ -0,0 +1,67 @@ +1 +00:00:00,180 --> 00:00:03,560 +And sometimes, architectural drift and erosion gets you so + +2 +00:00:03,560 --> 00:00:06,450 +far away from the point where your software architecture should + +3 +00:00:06,450 --> 00:00:10,476 +be, that your architecture is completely degraded. And at this + +4 +00:00:10,476 --> 00:00:13,290 +point, you have two main options. The first option is + +5 +00:00:13,290 --> 00:00:17,140 +to keep frantically tweaking the code. And this normally leads + +6 +00:00:17,140 --> 00:00:20,370 +to disaster. Why? Because you only make things worse. You + +7 +00:00:20,370 --> 00:00:22,570 +don't know exactly what you are changing and therefore, you're + +8 +00:00:22,570 --> 00:00:25,570 +basically stabbing in the dark, trying to fix your system. + +9 +00:00:25,570 --> 00:00:27,580 +The other possiblity is that you can try to + +10 +00:00:27,580 --> 00:00:29,830 +determine the software system architecture + +11 +00:00:29,830 --> 00:00:31,710 +from its implementation level artifacts, + +12 +00:00:31,710 --> 00:00:34,520 +so you try to derive what the architecture is + +13 +00:00:34,520 --> 00:00:36,610 +and try to fix it, once you have derived the + +14 +00:00:36,610 --> 00:00:39,266 +architecture. And this is what is normally called, architectural + +15 +00:00:39,266 --> 00:00:44,210 +recovery, determining a software architecture from an implementation and fixing + +16 +00:00:44,210 --> 00:00:46,410 +it. And as you can imagine, this is normally + +17 +00:00:46,410 --> 00:00:49,330 +a more recommended way to go than the first solution. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/9 - Architectural Recovery Quiz - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/9 - Architectural Recovery Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..0750374 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/9 - Architectural Recovery Quiz - lang_en_vs4.srt @@ -0,0 +1,35 @@ +1 +00:00:00,120 --> 00:00:03,070 +Now that we discussed some important concepts about + +2 +00:00:03,070 --> 00:00:05,060 +software architectures, I would like for you to + +3 +00:00:05,060 --> 00:00:07,290 +tell me which of the following sentences is + +4 +00:00:07,290 --> 00:00:11,420 +true. Prescriptive architecture and descriptive architecture are typically the + +5 +00:00:11,420 --> 00:00:15,970 +same. Architectural drift results in unnecessarily complex architectures. + +6 +00:00:15,970 --> 00:00:20,320 +Architectural erosion is less problematic than architectural drift. And + +7 +00:00:20,320 --> 00:00:22,660 +the best way to improve a degraded architecture, + +8 +00:00:22,660 --> 00:00:25,250 +is to keep fixing the code until the system + +9 +00:00:25,250 --> 00:00:29,270 +starts looking and behaving as expected. Which of these sentences is true? -- cgit 1.4.1