Loading...

Software Architecture: Models

Course video 10 of 41

In this module and next one, we will learn about various software development processes at a high level to understand what is involved in each of these processes. In this module, we will cover Requirements and Architecture.

Software Development Processes and Methodologies

明尼苏达大学

课程 1（共 4 门，Software Development Lifecycle 专项课程）

Software is quickly becoming integral part of human life as we see more and more automation and technical advancements. Just like we expect car to work all the time and can't afford to break or reboot unexpectedly, software industry needs to continue to learn better way to build software if it were to become integral part of human life. In this course, you will get an overview of how software teams work? What processes they use? What are some of the industry standard methodologies? What are pros and cons of each? You will learn enough to have meaningful conversation around software development processes. After completing this course, a learner will be able to 1) Apply core software engineering practices at conceptual level for a given problem. 2) Compare and contrast traditional, agile, and lean development methodologies at high level. These include Waterfall, Rational Unified Process, V model, Incremental, Spiral models and overview of agile mindset 3) Propose a methodology best suited for a given situation

查看授课大纲

教学方

Praveen Mittal
Adjunct Professor
Kevin Wendt
Teaching Specialist

脚本

[MUSIC]

Hi, in this video, we're going to take a closer look at some of the models that go

along with software architecture.

So there's a variety of models that have become essentially go-to best practice

models for a number of different common problems.

So these models are effectively best practiced solutions for commonly occurring

problems at the enterprise level, and you'll see what I mean here in a sec.

So he first one I wanted to look at is something called pipe-and-filter.

So let me give you an example of a problem that you might face in the real world.

So we have these two incoming data

sources into two relatively large

scale business logic entities.

Within this,

there are a variety of different tasks that you might have to deal with.

In order to process that data coming in.

And then of course everything out of that,

all the transformed data would continue on into further business logic.

What you might see here is what we see when we look at this from an architectural

perspective.

What I see is that A and B are shared tasks across much larger systems.

This is primarily something that we want to be able to take advantage of

at the enterprise level rather than having two separate teams

build essentially the same task twice.

because what ends up happening is that, if that task has to change in some way,

which inevitably it will, then A and

B could potentially start to diverge in how they work.

And that's not what you want to see, especially if for

example, eventually down the road, one of them has a problem and

the other one doesn't with the same data streams coming in.

That would present a really big problem that's much more difficult to debug.

So what we want to be able to do then is take a look at a solution to this which

provides for the reusability of these shared sources, these shared subsystems.

What we want to be able to do is something like this instead.

So we still have the two data sources coming in but instead now,

We want to build these subsystems now in such

a way that literally, these can be shared.

These are the same modules shared across overall systems so

that eventually, our subsystems make use of this one enter.

Now, the way we do that is with Pipe-and-Filter.

So, Pipe-and-Filter tends to mean that we eventually start to build and

look at these interfaces between the individual elements.

I want you to imagine if you're working on a Unix system,

when you end up seeing is something like information being output from one program

that can be directly inserted into the next program, and on down the line.

It's pretty simple when you think about regular text, but

we can expand this idea of solution into just about anything.

As long as it has the same format for input and

output, I can then rearrange and reuse any of these components in any order.

For example, let's say that later on down the line we realize,

we want to apply something like, Element D, but

we also want to apply that here in between parts E and F in the second subsystem.

Well, if and only if we are using a Pipe-and-Filter system,

we should know for a fact that we can nearly insert D directly into

the process flow without having to change anything.

And that only works if you are particularly focused on making sure that

the input and output formats are exactly the same.

This allows us to do a lot of different things.

So this is one example, but let me show you another one.

This one is just as common.

What you'll see instead is the incoming data being piped

across parallelized versions of A, which then all piped to B,

which piped to C, which then again parallelized,

Back to, The business logic.

Our ability to paralellize this information allow three

different processes all using that same code base of A.

All at the same time, simultaneously, allows us to very quickly get through that

set if that's the most, for example, performance heavy.

The same thing with part D.

But then if B is relatively quick, each individual process for

A can all point back to the same B process.

The ability to this, to be able to reuse or even, for example,

Reuse in a more linear version, the same process over and

over is keyed down to that Pipe-and-Filter idea.

The idea that the same input and output formats

are being used across all processes or all modules within the components.

This Pipe-and-Filter architecture is particularly useful in those cases where

we may want to expand, parallelize,

or reuse components across large systems like this.

So that's one focus in architectural style that can be applied

to something like this.

And you see that, for example, I'm compilers.

Compilers, for example, will have things like logical analysis, pair parsing,

semantic analysis, and code generation.

Those should all have essentially the same types of input and output so

they can be reused.

The next primary goal for a architectural style for shared data is Blackboard.

So a Blackboard architecture is something that might look like this where

we have some Blackboard which you can imagine the old style chalk and

white board, blackboards on the board.

It's one central place where you can go and look for information.

This is effectively using a hub of data where all of

these components then use some form of shared data or

shared processing across all components.

So when you have important shared data that you, again,

probably don't want you global variables for, you something like a blackboard.

That piece of functionality will then maintain integrity of that data, or

integrity of the operations across many calls from many different components.

So the components don't really talk to each other.

They talk to the blackboard.

So when they need to communicate with each other, they really don't.

They communicate with the blackboard, serving as some kind of a message queue or

some other form of data repository that each component can then make use of.

So what we'll have here is our provided interface which

needs to be very well defined so that any component can use it.

Now, the tendency out of these blackboard interfaces tend to be very, very big.

They seem to include a lot of functionality that other

components don't use.

There is some loss of ease of use,

understandability, maintainability when it comes to that sort of thing.

But if the most important aspect is the shared data,

this architectural style might be useful and thinking in this format might be good.

We also have things like layered architectures.

Layered architectures are very, very common.

You've likely seen some form of this throughout your time.

But you might see something like business logic layer being separated from a data

layer, the application layer, And

then your tech or what we typically call the infrastructure layer at the bottom.

What we are typically talking about here are things like,

we want to make sure to separate these layers for one particular reason.

And another one that we see sometimes is rather than business,

you might also see the UI layer listed here.

So when you think about hearing something like,

MVC, Or the ISO model for internet topology,

you might hear a lot of different layered architectures being talked about.

What we're trying to do here is separate somewhat core elements of

the architecture, core elements of the entire system into layers such that

we can modify or vary, for example, the data layer in a way that's different

than how we used it before without necessarily affecting application and

business layer that we have actually in here.

Interfaces both provided and required in between the layers that

perfectly protect each other, each external layer from changes within so

that we can make changes to the data later without having to change anything else.

That we can make changes to the application layer without having to change

anything else.

This is particularly true, for example, when we commonly change the UI layer.

If I'm changing the User Interface layer, I shouldn't have to modify the data layer

in any way when I do that, and that's very common, that you want to update the UI.

This is also true if you want to, for example,

switch from MariaDB to something from MySQL, or Cassandra, or

Mongoose or something like that at the infrastructure layer.

I should be able to do that without necessarily impacting or

changing any of the code at the application level.

So thinking in a layer architecture is also a way that you can partition

your system.

Another one that you've likely heard about is Client-Server.

The Client-Server is very, very straightforward,

you have yourself your laptop.

And then you go out to the cloud, and

then somewhere over here is the Google server, and you talk to that.

The internet is the primary example of a Client-Server architecture.

What we're talking about here is that primary, or shared, or stored,

or persisted information is stored on a server, and

potentially a lot of operations and programming goes there too.

And the client nearly uses that service in order to perform whatever task it is.

So a lot of times the UI ends up being pushed to the client.

And over time, we've seen a lot of changes in this model.

For example, the use of AJAX and JavaScript very heavily on the client's

side has shifted this idea away from a pure, thin client,

fat server model into more of a either mixed model or even fat client,

thin server kind of model depending on the kind of programming that ends up happening

on the client on your laptop when you load a webpage for example.

Thinking in this format, changes the way you are going to build your system because

now you need to think about the kinds of things that happen here on the server

versus the kinds of things that are going to happen on the client.

And lastly, we might want to look at something like an event manager.

So this is going to look similar to our blackboard, but

it's going to have some pretty key differences.

So we have our event manager and

then each component is listed here.

Now, what we tend to look at is that the event provides an interface for

the components to be able to use.

But then also the event manager uses each of these components

based on the events, so it's always based off of some component fires an event.

That event is handled by the event manager which then decides which component will

handle that event.

So in each individual case, a component will be called by something,

potentially the event manager.

It will decide that this event has happened, it will push that event to

the event manager, which will then find the correct component to handle that

event, usually through adding attaching handlers to the event manager.

Which will then, in turn, call the component, which will then run,

decide what event has occurred, and

then continue to use the event manager in that loop over, and over, and over.

This is primarily focused on things that are event based.

When you're looking at waiting for some event to occur, and

then having some action in response to that.

These software architecture models are best practice solutions.

So these were just a couple of examples.

There are many others of architectural models that you should use

if your problem can be fit into this kind of a solution.

You should, because they are best practices, and

potentially code frameworks that already exist that will help you

build into one of these architectural models.

It's also good to see these models as a way of knowing how best to partition

the work so that you can find the best people, the right amount of hardware and

software, and work with the budgeting and estimation of timelines to make sure

that your software project will be in the best position it can be for a success.

关于 Coursera

课程、专项课程和在线学位均由全世界一流大学和教育机构的顶尖授课教师教授。

Join a community of 40 million learners from around the world

Earn a skill-based course certificate to apply your knowledge

Gain confidence in your skills and further your career

Coursera 致力于普及全世界最好的教育，它与全球一流大学和机构合作提供在线课程。

© 2019 Coursera Inc. 保留所有权利。

通过 App Store 下载

通过 Google Play 获取