[usth/ICT2.7] Remove Udacity transcribes

author: Nguyễn Gia Phong <mcsinyx@disroot.org> 2020-07-19 20:34:40 +0700
committer: Nguyễn Gia Phong <mcsinyx@disroot.org> 2020-07-19 20:34:40 +0700
commit: 8a7dfa0972c83fd811a4296e7373574bea4a28d0 (patch)
tree: 16d37247e8b909ce5f885affd2b2473faab891fd /usth/ICT2.7/P3L1 Software Architecture Subtitles
parent: dc6f57c3af35f599abab2c4bac950654282cb519 (diff)
download: cp-8a7dfa0972c83fd811a4296e7373574bea4a28d0.tar.gz
27 files changed, 0 insertions, 3373 deletions
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
-&gt;&gt; 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
-&gt;&gt; Mm hm
-
-36
-00:01:42,660 --> 00:01:43,950
-&gt;&gt; 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
-&gt;&gt; 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
-&gt;&gt; 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
-&gt;&gt; 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
-&gt;&gt; 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
-&gt;&gt; Thank you very much.
-
-125
-00:06:17,920 --> 00:06:18,300
-&gt;&gt; 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?
author	Nguyễn Gia Phong <mcsinyx@disroot.org>	2020-07-19 20:34:40 +0700
committer	Nguyễn Gia Phong <mcsinyx@disroot.org>	2020-07-19 20:34:40 +0700
commit	8a7dfa0972c83fd811a4296e7373574bea4a28d0 (patch)
tree	16d37247e8b909ce5f885affd2b2473faab891fd /usth/ICT2.7/P3L1 Software Architecture Subtitles
parent	dc6f57c3af35f599abab2c4bac950654282cb519 (diff)
download	cp-8a7dfa0972c83fd811a4296e7373574bea4a28d0.tar.gz