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
Software Design: Modularity
Loading...
來自 University of Minnesota 的課程
Software Development Processes and Methodologies
140 個評分
從本節課中
Software Development Processes : Part 2
In this module, we will learn about processes that are used to implement the software, verify and validate the software, deploy the software and maintain the software.
與講師見面
Praveen MittalAdjunct Professor
College of Science and Engineering
Kevin WendtTeaching Specialist
Department of Computer Science and Engineering
In this video, we'll take a closer look at what we mean when we say modularity.
When we talk about modularity,
we're primarily talking about these four things.
Coupling, cohesion are measures of how well modules work together and how well
each individual module meets
a certain single well-defined task and they tend to go together,
so we'll talk about them separately.
Information hiding describes our ability to abstract
away information and knowledge in a way that allows us to
complete complex work in parallel without having to know
all the implementation details concerning how the task will be completed eventually.
And then data encapsulation refers to the idea that we
can contain constructs and concepts within a module,
allowing us to much more easily understand and manipulate
the concept when we're looking at it in relative isolation.
The reality is that software development is
the most complex thing we as humans have ever done.
Building a bridge is hard, but you can see it.
You can roll a truck across it,
watch and see if the bridge collapses or sways or cracks while you're doing it.
There are physical world properties that it must adhere to,
that we can leverage to ensure we've done our job.
Software isn't like that.
You may never know there's a huge crack down the main line of
your program just waiting for you to enter the wrong value and collapse in front of you.
Attempting to hold the entire concept of
a large scale program in your mind all at once is a fool's errand.
We have no choice but to break the problem down into smaller parts.
Which we might then be able to comprehend.
To do that properly, we're going to focus on three concepts, three listed here.
Decomposability. Essentially it's
the ancient possibly Roman concept of divide and conquer.
When the problem is too large and complex to get a proper handle on it,
breaking it down into smaller parts until
you can solve the smaller part is the way to go.
Then you just solve all the smaller parts.
But then we have to put all those smaller parts back
together and that's where composability comes into play.
This is often not as simple as one would like.
If you don't believe me ask NASA.
The Mars Climate Orbiter disintegrated during
its mission because of a mistake in units with one module using
pound seconds and the other using
Newton's seconds when calculating its thrusters total impulse values.
It's the little things that make this so difficult.
We're talking about taking a complex thing to begin
with and then making it even more complex by
adding who knows how many intersection points
between different developers or even developer teams.
The likelihood of a miscommunication just makes it all the more difficult.
So we try to focus on ease of understanding by
breaking down the components we hope to provide an ease of understanding,
which will then hopefully lead to an ease of communication.
When it comes to information hiding,
all we want is the ability to use something by
understanding what it does but not necessarily how.
This tends to work well until the understanding of what it does is strained.
Take Rand. What does the function rand do?
You might answer that it provides you with a random number but that's not quite right.
For most purposes, it generates a random enough value for most uses,
but in reality, rand is a pseudo random number generator.
It's based off of a seeded value and isn't exactly random.
So when you need true randomness,
it doesn't quite fit the bill but it does work in
many typical situations where true randomness isn't quite necessary.
Here's another example. Have you ever used the internal sort function in your language?
Do you know how it sorts the values?
Is it quicksort or merge sort or insertion sort or bubble sort?
Well, I hope it's not bubble sort but really you don't know.
And for the most part, you don't really care.
In most situations, all you want is that when you provide the array it gets sorted.
As long as it gets sorted and there isn't a performance issue,
the information hiding is perfectly acceptable.
You know how to use it and what it does behind the scenes doesn't concern you.
Because of data encapsulation,
protecting the data from unauthorized access and maintaining integrity is a key point.
The developer of a module has the best idea of how and
when the attributes should be modified,
and then we try to allow them to maintain as much control as is possible.
Nobody else is allowed to mess with that data.
If it gets corrupted,
it must have been done by the module, that's the intent.
And by robust here,
I mean that chances are that new additions aren't going to break the current design.
So when we talk about modularity,
we're really talking about breaking down and reassembling all these components.
So when it comes to coupling, cohesion,
information hiding, and data encapsulation,
they are just qualities,
different perspectives on what modularity really means.
