-Because the topic of today's lecture is software architecture, - -2
-it seemed appropriate to start the lesson by asking a - -3
-world expert on this topic, what is software architecture, and - -4
-why it is important. To do that, let's fly to - -5
-California, and more precisely, Los Angeles, and visit Professor - -6
-Nenad Medvidovic. Hi, I'm here visiting Professor Nenad Medvidovic from - -7
-the University of Southern California. And Neno is one of - -8
-the world experts in software architecture, actually one of the - -9
-authors of, of a recent book which is, sort of the - -10
-book in software architecture. What I would like to discuss with - -11
-Neno is the concept of software architecture and its importance. Because - -12
-people are very familiar with the idea and the cost of the - -13
-design. And software architecture is something is very related to that, - -14
-but is less known. So I would like for Nenad to - -15
-elaborate on that, and tell us why is it important to - -16
-focus also on this specific you know, architectural aspects of the software. - -17
->> When you - -18
-build any software system, even a simple, relatively simple - -19
-one. You're going to go through, a process of making - -20
-many, many design decisions. Hundreds or thousands sometimes even tens - -21
-of thousands of design decisions, so any program that you - -22
-write at some point you get to deciding what - -23
-the interface of a particular method is going to be. - -24
-Are you're going to put in a parameter that is - -25
-an integer or a float. When you're writing your routine - -26
-about some sort you have to decide whether you're - -27
-going to use a static data structure or a - -28
-dynamic data structure. All these things are design decisions. - -29
-Many of them however, will typically, in the average - -30
-case, not really impact the success of your system - -31
-and the long term well-being of your system. But - -32
-typically the things that software engineers start struggling with - -33
-are other design decisions. Design decisions that are the equivalent - -34
-of load baring walls in a building - -35
->> Mm hm - -36
->> These are the things that, if you - -37
-don't get them right, or if you compromise - -38
-them, will in fact potentially impact how the - -39
-system operates. They might result in failures of different - -40
-kinds. They may result in a system that - -41
-is not easily maintainable and so forth. In - -42
-a sense, to make a long story short, - -43
-architectural design decisions are really the principle design decisions - -44
-in your system. These are the things that are - -45
-very important. All of the other design decisions you - -46
-could sort of tag with being important, but they're - -47
-sort of below this very important or highly important threshold. - -48
->> So if you need to change a low level design decision, sometimes - -49
-it's kind of easy to do. It might change a little structure. Is it - -50
-the case that you know, being the architecture is sort of the pillar of - -51
-the software, is that going to be much - -52
-more difficult to change an architectural decision? - -53
-And architecture is deemed to be you know, - -54
-say if you start with the wrong architecture the - -55
-software is going to, you know, necessarily be unsuccessful. - -56
-Or you can also do something that is better. - -57
->> A system could be successful and very poorly architected. Just - -58
-like a building or an airplane or a car, any other - -59
-engineering artifact could be successful but poorly architected. So success we - -60
-can separated from this, but the, the point that you make in - -61
-asking this question is an important one. The - -62
-non-architectural design decisions, should be on the - -63
-average, there are exceptions and we need to - -64
-acknowledge that there is no one size fits all - -65
-type of solution for anything in software engineering - -66
-really. But on the average, the non-architectural design decisions, - -67
-should be much easier to make. So the - -68
-scale of the consequences of making such a change. - -69
-Really can vary from very minor, highly localized - -70
-to very important and sometimes, even system wide. - -71
->> To conclude, I just like to ask you about some concept that is - -72
-we here about a lot. Which is - -73
-architectural erosion. Since, we're talking about in with - -74
-fine architecture and software evolution. So, what is, - -75
-exactly, an architectural erosion and why does that - -76
-happen? So, to go back to our non software metaphors. Imagine you buy a car. - -77
-And your car has four wheels, it has a steering wheel, it has - -78
-a nice chassis, it looks pretty nice. At one point, you end up - -79
-replacing its 150 horsepower engine with - -80
-a 250 horsepower engine because that's what - -81
-you want. And you start putting a spoiler on the back of the car - -82
-and then you replace the headlights. And then you replace the side view - -83
-mirrors with smaller ones because you want your car to be more aerodynamic. - -84
-And then you start tinkering with other things, like you cut the, maybe - -85
-the roof of the car because you want to turn it into a convertible, - -86
-et cetera. And in the end, what you have is - -87
-a car that is still your car. Looks very different, It's - -88
-structural and behavioral properties are very different And, what you - -89
-might find is that the car doesn't handle nearly as well. - -90
-For example, in a very sharp turn it might not - -91
-be able to negotiate a steep hill as well. Because you - -92
-pretty much changed it all along the way. Architectural erosion in - -93
-the case of a software system is the exact same thing - -94
-with one huge caveat. Very few, if any of us, - -95
-will ever put a new engine into our car or tinker - -96
-with the structural soundness of the car by cutting off the - -97
-roof etc. In a software system we do it all the - -98
-time. We'll add a feature. We'll change one bit of the - -99
-user interface here. We'll port it to a new platform, some - -100
-kind of a, a mobile platform, for example. And pretty soon, - -101
-what you end up with is really a software system that, - -102
-that is maybe a distant relative of your original - -103
-system. It is a mutant in many ways, because often - -104
-times these little tinkerings happen on a one off - -105
-basis. There is no over-arching vision of how you should - -106
-do this. So, you are basically going through a - -107
-subsequent set of steps where you are making locally optimal - -108
-decisions for any one of these changes and what - -109
-you might end up finding is that the globally optimal - -110
-behavior of the system is badly compromised. The structural - -111
-soundness in a sense of the system badly compromised. - -112
-The non-functional properties of the system could be seriously - -113
-affected. This is how security flaws creep into systems. This - -114
-is how reliability flaws. This is how we use - -115
-the usability of a system often times suffers. And most - -116
-importantly for software engineers, the people who actually build the - -117
-software, the maintainability of the system becomes a huge problem. - -118
-Because now you're looking at this thing, it's got all these various appendages, - -119
-its original design has pretty badly eroded and yet somehow you have to - -120
-figure out how to keep fixing it. Making sure that it operates in - -121
-a continuous fashion because many of these systems live for 20, 30, 40 years. - -122
->> Thank you so much for your insight; it is a perfect - -123
-introduction for our lesson. So we'll get to the lesson now. And. - -124
->> Thank you very much. - -125
->> Thank you. -- cgit 1.4.1