path: root/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt

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.