Modularisation

What is Modularisation?

The breaking apart of something into many different parts than can then be completed as "modules". These modules are then combined to build the "big thing". It is analogous with the hardware of a computer- the machine can be disassembled into various components such as the HDD, PSU, Motherboard and so on. These on turn can be broken downs into smaller and smaller sub-systems. With software we can take the same approach.

A problem must be viewed at multiple levels. Each one of them has its benefits. The different levels in software design or development are as follows:

Big Picture or a Theme.
Modules/System.
Sub Modules/Subsystems.
Features.
Sub features.
Business Rules.

A clear example of modularisation is a website- each site is broken down into parts – pages or files, images etc. You may also see a similarity with the sitemap or DOM.

Each page is broken into parts – header, body, footer. Each of these could be further broken into more pieces:

Header
- Logo
- Navbar
  - Buttons
Body
- Headings
- Images
- Lists
- Links
- Tables
- Paragraphs of text
Footer
- (C) Name & Year
- Sitemap
- Social media icons

Even taking one of these elements, such as the buttons, we can break that into the text component and the a href component, and each of these we could divide again into characters, or the url part of the address... and so on, and so on.

When you look at all of these, it is very clear that you would only code one page at a time, insert one image at a time, type in paragraphs each at a time. This makes sense, but not only for web.

You should approach writing code in the very same way. Start with the simplest, smallest part you can write and have working, and add a little more each time. The way we do this with files we write, is using functions. Later we can also use classes and methods.

How are we using modularisation?

You may have used imports, such as math, time, random. These are called builtin modules (aka libraries) in Python. What they really are, is files (for the most part).

Inside these files, there are a number of functions such as:

sqrt() # in the math module

randrange() # in the random module

sleep() # in the time module.

When we import "parts" from other modules, we are only taking the "bits we want". When we import a function from a module, we make a space in your file for a function from another file.

You can similarly import a variable e.g. from math import pi means that the value of pi is available in your own code.

You could even import a class from another file, and that comes with special functions called methods. You've already used those too. You've used instances of the <class str> from the first time you did a print("Hello") because that thing you printed is a string. You've possibly used string methods such as choice.lower() and choice.upper() which are methods (functions) that operate only on strings.

Often, MODULE = FILE

Later you will write functions (and classes) in files, and import them into other programs.

All we are doing here is breaking a program into smaller "pieces" to make it easier to create- similar to the way we build a computer, table, bed, car, rocket and so on... piece by piece assembled over time.

In OOP, we break things into Objects: here the bare class diagrams are showing the relationship between an instance of a game, and a Player. It says- One game can have 1 to many Players. Thinking about this kind of relationship is called multiplicity. One player can have many lives. One Player has one score (yes- the player has the score- not the game 😉 ).

What about the Player info on the screen? Should (or could) this be another module? Is it part of the game, or the Player? Both? Can't be both (or can it?)- so where does this module or piece of info go? These are some of the questions that arise when breaking something down and deciding where pieces go.

The role of top-down design in different industries

A variety of industries benefit from top-down design techniques. When it comes to engineering, three of the most relevant are Product Design and Development, Computer Science, and Management and Organization.

Product Design and Development: A bottom-up approach is okay when you have more ready-made components that fit together. However, if your product requires components with custom materials and geometry, and budget-saving simulations, the top-down approach is a great fit.

Computer Science: Modern machines can’t run without capable and reliable software. The time spent writing code modules must be done with a good understanding of the overall purpose of the software and how each module contributes to that purpose. Top-down design ensures that this understanding is fully developed at the beginning of the project before a single module is written. Communications systems software may have millions of lines of code, made up of thousands of sub-systems, files, functions and so on. The ability to work at the module level means that teams of developers can collaborate in developing new products, features or improved programs.

Management and Organization: Directing a large organization requires a lot of decisions every day. This is a case where a combination of methods contributes to a vibrant, loyal company culture. Leadership, with their strategic vision, make decisions for the good of the organization’s long-term goals. However, the company also benefits when leadership is open to ideas and feedback sent up from employees.

Benefits of Top-Down Design

It helps to identify systems and subsystems.
Bring in more clarity on communication between two systems or subsystems.
Comprehensive list of features and sub-features along with all business rules.
No room for mistakes in implementing user requirements. High quality can be achieved.
Ensure to arrive at a correct estimate.
Easy to code as we have clearly defined expectations at all levels.
Nonfunctional will help to make sure it performs, secured.

Page updated

Google Sites

Report abuse