From 8a7dfa0972c83fd811a4296e7373574bea4a28d0 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 19 Jul 2020 20:34:40 +0700 Subject: [usth/ICT2.7] Remove Udacity transcribes --- .../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 deletions(-) delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt delete mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt delete 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 deleted file mode 100644 index 89008af..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt +++ /dev/null @@ -1,47 +0,0 @@ -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 deleted file mode 100644 index bd45907..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,67 +0,0 @@ -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 deleted file mode 100644 index 4e64d4a..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt +++ /dev/null @@ -1,183 +0,0 @@ -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 deleted file mode 100644 index 6f929eb..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt +++ /dev/null @@ -1,107 +0,0 @@ -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 deleted file mode 100644 index 4fab0c6..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt +++ /dev/null @@ -1,127 +0,0 @@ -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 deleted file mode 100644 index e1e95e6..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,31 +0,0 @@ -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 deleted file mode 100644 index 465687c..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,107 +0,0 @@ -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 deleted file mode 100644 index c8de83f..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt +++ /dev/null @@ -1,115 +0,0 @@ -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 deleted file mode 100644 index 5fc4df3..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt +++ /dev/null @@ -1,111 +0,0 @@ -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 deleted file mode 100644 index 775f11c..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt +++ /dev/null @@ -1,75 +0,0 @@ -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 deleted file mode 100644 index 1cc7d89..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt +++ /dev/null @@ -1,103 +0,0 @@ -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 deleted file mode 100644 index 40fa57c..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt +++ /dev/null @@ -1,499 +0,0 @@ -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 deleted file mode 100644 index b4ee115..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt +++ /dev/null @@ -1,111 +0,0 @@ -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 deleted file mode 100644 index 05011c7..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt +++ /dev/null @@ -1,239 +0,0 @@ -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 deleted file mode 100644 index 2e8c051..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,27 +0,0 @@ -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 deleted file mode 100644 index d48320b..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt +++ /dev/null @@ -1,79 +0,0 @@ -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 deleted file mode 100644 index 927c773..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt +++ /dev/null @@ -1,39 +0,0 @@ -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 deleted file mode 100644 index d3ab75b..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt +++ /dev/null @@ -1,231 +0,0 @@ -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 deleted file mode 100644 index 2118c73..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt +++ /dev/null @@ -1,287 +0,0 @@ -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 deleted file mode 100644 index 9cd15c3..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt +++ /dev/null @@ -1,131 +0,0 @@ -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 deleted file mode 100644 index 8689e43..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt +++ /dev/null @@ -1,127 +0,0 @@ -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 deleted file mode 100644 index 13042a7..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt +++ /dev/null @@ -1,131 +0,0 @@ -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 deleted file mode 100644 index 11ecd46..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt +++ /dev/null @@ -1,51 +0,0 @@ -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 deleted file mode 100644 index edcf77e..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt +++ /dev/null @@ -1,115 +0,0 @@ -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 deleted file mode 100644 index 2313f82..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt +++ /dev/null @@ -1,131 +0,0 @@ -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 deleted file mode 100644 index 6104ae0..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt +++ /dev/null @@ -1,67 +0,0 @@ -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 deleted file mode 100644 index 0750374..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/9 - Architectural Recovery Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,35 +0,0 @@ -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