Because the topic of today's lecture is software architecture,
it seemed appropriate to start the lesson by asking a
world expert on this topic, what is software architecture, and
why it is important. To do that, let's fly to
California, and more precisely, Los Angeles, and visit Professor
Nenad Medvidovic. Hi, I'm here visiting Professor Nenad Medvidovic from
the University of Southern California. And Neno is one of
the world experts in software architecture, actually one of the
authors of, of a recent book which is, sort of the
book in software architecture. What I would like to discuss with
Neno is the concept of software architecture and its importance. Because
people are very familiar with the idea and the cost of the
design. And software architecture is something is very related to that,
but is less known. So I would like for Nenad to
elaborate on that, and tell us why is it important to
focus also on this specific you know, architectural aspects of the software.
>> When you
build any software system, even a simple, relatively simple
one. You're going to go through, a process of making
many, many design decisions. Hundreds or thousands sometimes even tens
of thousands of design decisions, so any program that you
write at some point you get to deciding what
the interface of a particular method is going to be.
Are you're going to put in a parameter that is
an integer or a float. When you're writing your routine
about some sort you have to decide whether you're
going to use a static data structure or a
dynamic data structure. All these things are design decisions.
Many of them however, will typically, in the average
case, not really impact the success of your system
and the long term well-being of your system. But
typically the things that software engineers start struggling with
are other design decisions. Design decisions that are the equivalent
of load baring walls in a building
>> Mm hm
>> These are the things that, if you
don't get them right, or if you compromise
them, will in fact potentially impact how the
system operates. They might result in failures of different
kinds. They may result in a system that
is not easily maintainable and so forth. In
a sense, to make a long story short,
architectural design decisions are really the principle design decisions
in your system. These are the things that are
very important. All of the other design decisions you
could sort of tag with being important, but they're
sort of below this very important or highly important threshold.
>> So if you need to change a low level design decision, sometimes
it's kind of easy to do. It might change a little structure. Is it
the case that you know, being the architecture is sort of the pillar of
the software, is that going to be much
more difficult to change an architectural decision?
And architecture is deemed to be you know,
say if you start with the wrong architecture the
software is going to, you know, necessarily be unsuccessful.
Or you can also do something that is better.
>> A system could be successful and very poorly architected. Just
like a building or an airplane or a car, any other
engineering artifact could be successful but poorly architected. So success we
can separated from this, but the, the point that you make in
asking this question is an important one. The
non-architectural design decisions, should be on the
average, there are exceptions and we need to
acknowledge that there is no one size fits all
type of solution for anything in software engineering
really. But on the average, the non-architectural design decisions,
should be much easier to make. So the
scale of the consequences of making such a change.
Really can vary from very minor, highly localized
to very important and sometimes, even system wide.
>> To conclude, I just like to ask you about some concept that is
we here about a lot. Which is
architectural erosion. Since, we're talking about in with
fine architecture and software evolution. So, what is,
exactly, an architectural erosion and why does that
happen? So, to go back to our non software metaphors. Imagine you buy a car.
And your car has four wheels, it has a steering wheel, it has
a nice chassis, it looks pretty nice. At one point, you end up
replacing its 150 horsepower engine with
a 250 horsepower engine because that's what
you want. And you start putting a spoiler on the back of the car
and then you replace the headlights. And then you replace the side view
mirrors with smaller ones because you want your car to be more aerodynamic.
And then you start tinkering with other things, like you cut the, maybe
the roof of the car because you want to turn it into a convertible,
et cetera. And in the end, what you have is
a car that is still your car. Looks very different, It's
structural and behavioral properties are very different And, what you
might find is that the car doesn't handle nearly as well.
For example, in a very sharp turn it might not
be able to negotiate a steep hill as well. Because you
pretty much changed it all along the way. Architectural erosion in
the case of a software system is the exact same thing
with one huge caveat. Very few, if any of us,
will ever put a new engine into our car or tinker
with the structural soundness of the car by cutting off the
roof etc. In a software system we do it all the
time. We'll add a feature. We'll change one bit of the
user interface here. We'll port it to a new platform, some
kind of a, a mobile platform, for example. And pretty soon,
what you end up with is really a software system that,
that is maybe a distant relative of your original
system. It is a mutant in many ways, because often
times these little tinkerings happen on a one off
basis. There is no over-arching vision of how you should
do this. So, you are basically going through a
subsequent set of steps where you are making locally optimal
decisions for any one of these changes and what
you might end up finding is that the globally optimal
behavior of the system is badly compromised. The structural
soundness in a sense of the system badly compromised.
The non-functional properties of the system could be seriously
affected. This is how security flaws creep into systems. This
is how reliability flaws. This is how we use
the usability of a system often times suffers. And most
importantly for software engineers, the people who actually build the
software, the maintainability of the system becomes a huge problem.
Because now you're looking at this thing, it's got all these various appendages,
its original design has pretty badly eroded and yet somehow you have to
figure out how to keep fixing it. Making sure that it operates in
a continuous fashion because many of these systems live for 20, 30, 40 years.
>> Thank you so much for your insight; it is a perfect
introduction for our lesson. So we'll get to the lesson now. And.
>> Thank you very much.
>> Thank you.