[usth/ICT2.7] Engineer software

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