about summary refs log tree commit diff
path: root/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt
diff options
context:
space:
mode:
Diffstat (limited to 'usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt')
-rw-r--r--usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt499
1 files changed, 0 insertions, 499 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
deleted file mode 100644
index 40fa57c..0000000
--- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt
+++ /dev/null
@@ -1,499 +0,0 @@
-1

-00:00:00,220 --> 00:00:02,900

-Because the topic of today's lecture is software architecture,

-

-2

-00:00:02,900 --> 00:00:05,390

-it seemed appropriate to start the lesson by asking a

-

-3

-00:00:05,390 --> 00:00:08,960

-world expert on this topic, what is software architecture, and

-

-4

-00:00:08,960 --> 00:00:11,570

-why it is important. To do that, let's fly to

-

-5

-00:00:11,570 --> 00:00:14,910

-California, and more precisely, Los Angeles, and visit Professor

-

-6

-00:00:14,910 --> 00:00:19,540

-Nenad Medvidovic. Hi, I'm here visiting Professor Nenad Medvidovic from

-

-7

-00:00:19,540 --> 00:00:22,310

-the University of Southern California. And Neno is one of

-

-8

-00:00:22,310 --> 00:00:25,250

-the world experts in software architecture, actually one of the

-

-9

-00:00:25,250 --> 00:00:28,300

-authors of, of a recent book which is, sort of the

-

-10

-00:00:28,300 --> 00:00:31,660

-book in software architecture. What I would like to discuss with

-

-11

-00:00:31,660 --> 00:00:34,500

-Neno is the concept of software architecture and its importance. Because

-

-12

-00:00:34,500 --> 00:00:37,520

-people are very familiar with the idea and the cost of the

-

-13

-00:00:37,520 --> 00:00:41,240

-design. And software architecture is something is very related to that,

-

-14

-00:00:41,240 --> 00:00:43,690

-but is less known. So I would like for Nenad to

-

-15

-00:00:43,690 --> 00:00:46,350

-elaborate on that, and tell us why is it important to

-

-16

-00:00:46,350 --> 00:00:49,880

-focus also on this specific you know, architectural aspects of the software.

-

-17

-00:00:49,880 --> 00:00:50,380

->> When you

-

-18

-00:00:50,380 --> 00:00:53,220

-build any software system, even a simple, relatively simple

-

-19

-00:00:53,220 --> 00:00:56,840

-one. You're going to go through, a process of making

-

-20

-00:00:56,840 --> 00:01:00,070

-many, many design decisions. Hundreds or thousands sometimes even tens

-

-21

-00:01:00,070 --> 00:01:03,140

-of thousands of design decisions, so any program that you

-

-22

-00:01:03,140 --> 00:01:06,090

-write at some point you get to deciding what

-

-23

-00:01:06,090 --> 00:01:09,385

-the interface of a particular method is going to be.

-

-24

-00:01:09,385 --> 00:01:12,170

-Are you're going to put in a parameter that is

-

-25

-00:01:12,170 --> 00:01:15,530

-an integer or a float. When you're writing your routine

-

-26

-00:01:15,530 --> 00:01:17,400

-about some sort you have to decide whether you're

-

-27

-00:01:17,400 --> 00:01:18,900

-going to use a static data structure or a

-

-28

-00:01:18,900 --> 00:01:22,410

-dynamic data structure. All these things are design decisions.

-

-29

-00:01:22,410 --> 00:01:25,770

-Many of them however, will typically, in the average

-

-30

-00:01:25,770 --> 00:01:29,030

-case, not really impact the success of your system

-

-31

-00:01:29,030 --> 00:01:31,640

-and the long term well-being of your system. But

-

-32

-00:01:31,640 --> 00:01:35,390

-typically the things that software engineers start struggling with

-

-33

-00:01:35,390 --> 00:01:40,760

-are other design decisions. Design decisions that are the equivalent

-

-34

-00:01:40,760 --> 00:01:42,080

-of load baring walls in a building

-

-35

-00:01:42,080 --> 00:01:42,660

->> Mm hm

-

-36

-00:01:42,660 --> 00:01:43,950

->> These are the things that, if you

-

-37

-00:01:43,950 --> 00:01:45,960

-don't get them right, or if you compromise

-

-38

-00:01:45,960 --> 00:01:50,190

-them, will in fact potentially impact how the

-

-39

-00:01:50,190 --> 00:01:54,300

-system operates. They might result in failures of different

-

-40

-00:01:54,300 --> 00:01:56,780

-kinds. They may result in a system that

-

-41

-00:01:56,780 --> 00:01:59,460

-is not easily maintainable and so forth. In

-

-42

-00:01:59,460 --> 00:02:01,680

-a sense, to make a long story short,

-

-43

-00:02:01,680 --> 00:02:05,888

-architectural design decisions are really the principle design decisions

-

-44

-00:02:05,888 --> 00:02:07,900

-in your system. These are the things that are

-

-45

-00:02:07,900 --> 00:02:10,550

-very important. All of the other design decisions you

-

-46

-00:02:10,550 --> 00:02:13,520

-could sort of tag with being important, but they're

-

-47

-00:02:13,520 --> 00:02:17,730

-sort of below this very important or highly important threshold.

-

-48

-00:02:17,730 --> 00:02:21,400

->> So if you need to change a low level design decision, sometimes

-

-49

-00:02:21,400 --> 00:02:23,970

-it's kind of easy to do. It might change a little structure. Is it

-

-50

-00:02:23,970 --> 00:02:27,140

-the case that you know, being the architecture is sort of the pillar of

-

-51

-00:02:27,140 --> 00:02:29,020

-the software, is that going to be much

-

-52

-00:02:29,020 --> 00:02:32,380

-more difficult to change an architectural decision?

-

-53

-00:02:32,380 --> 00:02:34,400

-And architecture is deemed to be you know,

-

-54

-00:02:34,400 --> 00:02:36,120

-say if you start with the wrong architecture the

-

-55

-00:02:36,120 --> 00:02:39,510

-software is going to, you know, necessarily be unsuccessful.

-

-56

-00:02:39,510 --> 00:02:41,320

-Or you can also do something that is better.

-

-57

-00:02:41,320 --> 00:02:46,070

->> A system could be successful and very poorly architected. Just

-

-58

-00:02:46,070 --> 00:02:50,630

-like a building or an airplane or a car, any other

-

-59

-00:02:50,630 --> 00:02:54,700

-engineering artifact could be successful but poorly architected. So success we

-

-60

-00:02:54,700 --> 00:02:57,440

-can separated from this, but the, the point that you make in

-

-61

-00:02:57,440 --> 00:03:00,530

-asking this question is an important one. The

-

-62

-00:03:00,530 --> 00:03:04,260

-non-architectural design decisions, should be on the

-

-63

-00:03:04,260 --> 00:03:06,250

-average, there are exceptions and we need to

-

-64

-00:03:06,250 --> 00:03:09,580

-acknowledge that there is no one size fits all

-

-65

-00:03:09,580 --> 00:03:11,640

-type of solution for anything in software engineering

-

-66

-00:03:11,640 --> 00:03:15,060

-really. But on the average, the non-architectural design decisions,

-

-67

-00:03:15,060 --> 00:03:17,650

-should be much easier to make. So the

-

-68

-00:03:17,650 --> 00:03:22,600

-scale of the consequences of making such a change.

-

-69

-00:03:22,600 --> 00:03:25,880

-Really can vary from very minor, highly localized

-

-70

-00:03:25,880 --> 00:03:29,670

-to very important and sometimes, even system wide.

-

-71

-00:03:29,670 --> 00:03:33,570

->> To conclude, I just like to ask you about some concept that is

-

-72

-00:03:33,570 --> 00:03:35,110

-we here about a lot. Which is

-

-73

-00:03:35,110 --> 00:03:37,430

-architectural erosion. Since, we're talking about in with

-

-74

-00:03:37,430 --> 00:03:39,760

-fine architecture and software evolution. So, what is,

-

-75

-00:03:39,760 --> 00:03:42,090

-exactly, an architectural erosion and why does that

-

-76

-00:03:42,090 --> 00:03:47,600

-happen? So, to go back to our non software metaphors. Imagine you buy a car.

-

-77

-00:03:47,600 --> 00:03:49,810

-And your car has four wheels, it has a steering wheel, it has

-

-78

-00:03:49,810 --> 00:03:53,700

-a nice chassis, it looks pretty nice. At one point, you end up

-

-79

-00:03:53,700 --> 00:03:54,950

-replacing its 150 horsepower engine with

-

-80

-00:03:54,950 --> 00:03:56,800

-a 250 horsepower engine because that's what

-

-81

-00:03:56,800 --> 00:04:01,510

-you want. And you start putting a spoiler on the back of the car

-

-82

-00:04:01,510 --> 00:04:04,680

-and then you replace the headlights. And then you replace the side view

-

-83

-00:04:04,680 --> 00:04:08,000

-mirrors with smaller ones because you want your car to be more aerodynamic.

-

-84

-00:04:08,000 --> 00:04:10,620

-And then you start tinkering with other things, like you cut the, maybe

-

-85

-00:04:10,620 --> 00:04:13,380

-the roof of the car because you want to turn it into a convertible,

-

-86

-00:04:13,380 --> 00:04:15,990

-et cetera. And in the end, what you have is

-

-87

-00:04:15,990 --> 00:04:19,810

-a car that is still your car. Looks very different, It's

-

-88

-00:04:19,810 --> 00:04:23,650

-structural and behavioral properties are very different And, what you

-

-89

-00:04:23,650 --> 00:04:27,260

-might find is that the car doesn't handle nearly as well.

-

-90

-00:04:27,260 --> 00:04:29,670

-For example, in a very sharp turn it might not

-

-91

-00:04:29,670 --> 00:04:31,910

-be able to negotiate a steep hill as well. Because you

-

-92

-00:04:31,910 --> 00:04:35,760

-pretty much changed it all along the way. Architectural erosion in

-

-93

-00:04:35,760 --> 00:04:38,620

-the case of a software system is the exact same thing

-

-94

-00:04:38,620 --> 00:04:41,480

-with one huge caveat. Very few, if any of us,

-

-95

-00:04:41,480 --> 00:04:44,970

-will ever put a new engine into our car or tinker

-

-96

-00:04:44,970 --> 00:04:47,390

-with the structural soundness of the car by cutting off the

-

-97

-00:04:47,390 --> 00:04:50,260

-roof etc. In a software system we do it all the

-

-98

-00:04:50,260 --> 00:04:53,530

-time. We'll add a feature. We'll change one bit of the

-

-99

-00:04:53,530 --> 00:04:57,088

-user interface here. We'll port it to a new platform, some

-

-100

-00:04:57,088 --> 00:05:00,990

-kind of a, a mobile platform, for example. And pretty soon,

-

-101

-00:05:00,990 --> 00:05:03,750

-what you end up with is really a software system that,

-

-102

-00:05:03,750 --> 00:05:06,990

-that is maybe a distant relative of your original

-

-103

-00:05:06,990 --> 00:05:10,500

-system. It is a mutant in many ways, because often

-

-104

-00:05:10,500 --> 00:05:12,986

-times these little tinkerings happen on a one off

-

-105

-00:05:12,986 --> 00:05:15,610

-basis. There is no over-arching vision of how you should

-

-106

-00:05:15,610 --> 00:05:19,060

-do this. So, you are basically going through a

-

-107

-00:05:19,060 --> 00:05:21,980

-subsequent set of steps where you are making locally optimal

-

-108

-00:05:21,980 --> 00:05:25,240

-decisions for any one of these changes and what

-

-109

-00:05:25,240 --> 00:05:29,140

-you might end up finding is that the globally optimal

-

-110

-00:05:29,140 --> 00:05:32,100

-behavior of the system is badly compromised. The structural

-

-111

-00:05:32,100 --> 00:05:34,952

-soundness in a sense of the system badly compromised.

-

-112

-00:05:34,952 --> 00:05:38,510

-The non-functional properties of the system could be seriously

-

-113

-00:05:38,510 --> 00:05:42,390

-affected. This is how security flaws creep into systems. This

-

-114

-00:05:42,390 --> 00:05:44,250

-is how reliability flaws. This is how we use

-

-115

-00:05:44,250 --> 00:05:48,420

-the usability of a system often times suffers. And most

-

-116

-00:05:48,420 --> 00:05:50,920

-importantly for software engineers, the people who actually build the

-

-117

-00:05:50,920 --> 00:05:54,950

-software, the maintainability of the system becomes a huge problem.

-

-118

-00:05:54,950 --> 00:05:59,130

-Because now you're looking at this thing, it's got all these various appendages,

-

-119

-00:05:59,130 --> 00:06:03,170

-its original design has pretty badly eroded and yet somehow you have to

-

-120

-00:06:03,170 --> 00:06:06,850

-figure out how to keep fixing it. Making sure that it operates in

-

-121

-00:06:06,850 --> 00:06:11,380

-a continuous fashion because many of these systems live for 20, 30, 40 years.

-

-122

-00:06:11,380 --> 00:06:13,840

->> Thank you so much for your insight; it is a perfect

-

-123

-00:06:13,840 --> 00:06:16,500

-introduction for our lesson. So we'll get to the lesson now. And.

-

-124

-00:06:16,500 --> 00:06:17,920

->> Thank you very much.

-

-125

-00:06:17,920 --> 00:06:18,300

->> Thank you.