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.