Our approach to decomposition

This briefing is based on the Vectis Games project described earlier.

Understanding Decomposition, Abstraction, and Modularisation

Our metaphor: Menu Design

We're going to explore some fundamental concepts in software development: Decomposition, Abstraction, and Modularisation. These are crucial for building complex digital solutions like the prototype website you'll be developing for Vectis Games. We'll approach this using a top-down method, starting with something you're all familiar with: website menu options.

The goal is to break down the overall problem into smaller, more manageable pieces, to think about what details are necessary at different stages, and to identify independent parts of the system.

Let's look at the "layers" of decomposition we can apply to the Vectis Games website:

Layer 1: Top-Level Menu Options (High-Level Abstraction)

Imagine you're a user visiting the Vectis Games website for the first time. What are the main sections you'd expect to see in the navigation menu? These represent the broadest categories of information and functionality, providing a high-level overview of what the site offers.

For the Vectis Games prototype, your top-level menu might look like this:

• Home: This would be the general landing page for the site.
• Hardware: This section would provide information on high-end PC hardware.
• PC Games: This is where users would find information about Vectis's own PC games and potentially select them.
• Tools/Information: This section could house various utility and informational resources, such as currency exchange rates or health and safety guidelines.
• Support: This menu option would lead users to help resources, like FAQs. -Account: This is where clients would register and log in securely.

At this stage, we're looking at the highest level of abstraction. Each of these menu options represents a significant module or a major component of the entire system.

Layer 2: Sub-Menu Options / Page Sections (Further Decomposition)

Now, let's take each of those top-level menu options and break them down further. What specific types of content or features would you expect to find within each of those main sections? This is where we start to decompose the broader categories into more specific sub-sections or individual pages.

Hardware

• Hardware Information
• Bespoke Systems Design Advice

PC Games

• Browse Games (to allow logged-in clients to select games)
• Selected Games Cost Display (showing a running cost of selected games)
• PEGI Ratings Information (classifying PC Games)

Tools/Information

• Real-time Currency Exchange Rates
• Health and Safety for PC Builders

Support

• Frequently Asked Questions (FAQs)

Account

• Register (for clients to register securely)
• Login (for clients to log in securely)

At this second layer, you can see how the broad abstractions from Layer 1 are being decomposed into more manageable and specific parts. Each sub-menu or page section still represents a distinct module that serves a particular purpose.

Layer 3: Functional Elements within Pages (Detailed Decomposition and Modularity)

Finally, let's dig deeper into what functionalities and data each sub-menu option or page will actually contain. This is where the concept of modularity becomes very clear, as each of these elements can often be seen as a distinct function, component, or data requirement within your code.

Hardware Information

• Display product categories (e.g., CPUs, GPUs, Motherboards)
• Display product details (specifications, images, prices)

Bespoke Systems Design Advice

• Input fields for user preferences/requirements
• Logic for generating system recommendations

Browse Games

• Display a list of games (e.g., with thumbnails, titles)
• Display detailed information for a selected game (description, genre, price, PEGI rating)
• "Add to selection" functionality

Selected Games Cost Display

• Display a list of games the user has selected
• Calculate and display the total running cost
• Dynamic update as games are added/removed

PEGI Ratings Information

• Display different PEGI rating categories
• Provide explanations for each rating criterion

Real-time Currency Exchange Rates

• Integration with an external API to fetch live data
• Display the exchange rate information (e.g., in a table or chart)

Health and Safety for PC Builders

• Display guidelines and information (e.g., as text, bullet points)
• Potentially include illustrations or diagrams

FAQs

• Search functionality for common questions
• Categorised topics for easier navigation
• Expandable sections for answers

Register

• User input fields (e.g., username, password, email)
• Validation logic for input data
• Integration with a database to store new user accounts

Login

• User input fields (username, password)
• Authentication logic to verify user credentials
• Session management for logged-in users

This layer helps you visualise the individual functional components that will need to be developed, and it naturally connects to the functional and non-functional requirements you've already identified.

Benefits of This Approach Introducing decomposition, abstraction, and modularisation through menu design is incredibly useful for several reasons:

Relatable Starting Point: Everyone uses websites and understands menus. This familiar context makes the abstract concepts of breaking down a system much easier to grasp.

Clear Top-Down Structure: It guides you through a logical progression, starting from the broad user experience and then systematically drilling down into specific features. This helps you manage the complexity of a large project.

Understanding Abstraction Levels: You can clearly see how different "layers" represent different levels of detail or "abstraction." Layer 1 is very general, while Layer 3 is highly specific. Understanding these levels is key to good software design.

Natural Modularisation: By identifying distinct menu items and sub-sections, you are inherently thinking about independent "modules" of the system. Each of these modules can often be developed, tested, and maintained somewhat independently, which is a core principle of good software engineering.

Direct Link to Requirements: This method provides a clear bridge between the client's requested features (your functional requirements) and the actual structure of the digital solution. You can directly map each requirement to a specific part of your decomposed system.

Foundation for Design: This structured thinking forms a strong foundation for your design documents, including visual/interface designs, data requirements, and even test strategies, as you've already started to outline the content and flow.

Early Problem Identification: Breaking down the problem this way helps you identify potential complexities or challenges within specific modules much earlier in the development process. This is crucial for effective planning and risk mitigation.

By adopting this top-down approach, you'll be well-prepared to design a robust and well-organised digital solution for Vectis Games. This exercise will help you effectively plan your code implementation, which needs to be in at least two appropriate languages for front-end and back-end processes.