1 files changed, 499 insertions, 0 deletions
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.