Preparing Your Next Big Software Feature: Think Like a Software Architect

In my role as a senior software engineer at Orange Business, I’ve often faced new challenges in our projects. Whether it’s adding a new feature or changing an existing solution.

In that case, success requires a good organization, effective communication with domain experts, having a deep understanding of the project, and creating a clear technical vision along with (the only source of knowledge 😄) the functional specification page, mostly a Confluence page.

So, how to confidently begin this process?

The functional spec

Feature-driven development (FDD) is an agile software development methodology that focuses on designing and building software systems one feature at a time. It’s a process-driven approach that emphasizes clear and well-defined features as the primary units of work.

We use the FDD method.

When a new feature is coming, we kick it off with meetings involving different teams. We discuss and understand the requirements thoroughly. The outcome? A detailed functional spec page.

Now, the first thing to do is simple: READ, UNDERSTAND, CLARIFY and ASK QUESTIONS about this page. Take a moment, relax, and read it carefully. Feel free to take some notes if it helps. Try to imagine yourself as the user.

Don’t just skim through the screenshots or diagrams 🚫 Read it, just READ IT.

The Abstraction

In object-oriented analysis, abstraction means simplifying complex systems by concentrating on the most important characteristics of objects and ignoring less important stuff. This helps make a simplified, general picture of how objects work together in a system.

When you read a functional spec, the first thing to do is to figure out the abstraction.

Typically, you follow these steps:

1. Identify Keywords: When reading the functional spec, find and highlight keywords, also known as “Objects,” and understand what they mean.
2. Ask Questions: Once you’ve identified the main objects, start asking questions and seek answers. After that, fine-tune your understanding.
3. Establish Relationships: Create connections between these objects. Use design patterns; they’re incredibly useful. They help prevent duplicate code in objects.
4. Continuous Refinement: Remember, at every step, keep refining your understanding and design.

Conceptual class diagram

A conceptual class diagram is like a basic map in object-oriented design. It illustrates the main building blocks (classes) in a system and how they’re connected, without getting into the fine details of how they work. It’s a high-level view.

Once you’ve turned the requirements into an objects abstraction, you create the conceptual class diagram.

Perhaps you’re hearing this for the first time 🤯 this diagram is not just for developers; they should also make sense to experts in the field. If it’s not, it means your diagram might not be clear enough or it might not align with the requirements.

In this phase, put yourself in the shoes of a domain expert. Think about the problem the way they would think about it.

Creating a Conceptual class diagram can sometimes be tricky for developers, especially when dealing with certain types of relationships like 1:N, N:1, or N:N.

In such situations, it’s a good practice to turn to design patterns (we will talk about that later).

• For 1:N or N:1 relationships, you’ll likely need some kind of collection, so choose the right one for the job.
• N:N relationships are more challenging. Most developers use a middle class as a solution. This approach works well, but it’s crucial to name it appropriately. Avoid generic names like “ClassAClassB.” Instead, give it a meaningful name that aligns with your project’s functional specifications. Your class diagram should communicate effectively, just like your functional spec does.

		Attends
|Student|   N <—----------———> N |Courses|
									
											|
											|
											|
											↓
|Student|   <—-------->  |ClassSchedule|   <-------———> |Courses|

Design patterns

Discussing design patterns after creating the conceptual class diagram is a good practice. If you see that there’s an expensive object or an object that can be in many forms for example, you should definitely consider using these design patterns:

1. Singleton Design Pattern: This pattern ensures there’s only one instance of a class, which can be useful for managing authentication and global settings in your feature.
2. Abstract Factory Design Pattern: This pattern helps you create families of related objects without specifying their exact classes. It’s handy when you need to create different objects based on authentication methods.
3. Factory Design Pattern: This pattern is useful for creating objects without specifying the exact class of object that will be created. It’s handy for generating various types of objects in your feature.

Design patterns are reusable solutions for common problems. In most situations, you can rely on well-structured patterns to help you.

Go back to the functional spec

We need to update the functional specification (no kidding!), and you’ll actually be creating a new version of it. This new version will include your abstractions.

For instance, if you realize that creating a ’CourseSchedule’ class between ’Student’ and ’Course’ is essential, you’ll insert this in the functional spec. And ensure that it’s easy for the domain expert to understand. After that, you’ll need to present this new version to them. This way, you can show them how you’ve solved the problem.

Object attributes

So far, we haven’t set the attributes for our class. First, let’s consider encapsulation by deciding what data to display or keep hidden. After that, we should identify the unique keys for our object and all other attributes and methods.

Remember, the new changes shouldn’t disrupt the existing functions. You’ll likely need some interfaces to manage communication between the client and your object, so be sure to document those too.

Implementation

This will be the final part, in my view, where we will create:

1. Use Case Diagram: A visual tool that shows how a system interacts with its users or other systems.
2. Activity Diagram: A flowchart-like diagram that illustrates the workflow or activities within a system or process.
3. Sequence Diagram: A diagram that displays the interactions and order of messages between objects or components in a system.
4. List Object Methods Called by the Client: A list of functions or actions that the client can perform on an object or component.
5. Message Broker or Middleware (If needed): Software that helps different parts of a system communicate and share data efficiently.
6. Validation of Request: Ensuring that the incoming data or requests are correct and meet predefined criteria.
7. Database Queries: Commands or requests sent to a database to retrieve or manipulate data stored in it.
8. …

Conclusion

Finally, when getting ready to create a new feature, it’s crucial to have a solid knowledge of Object-Oriented Programming (OOP) skills. Additionally, you should understand Object-Oriented Analysis (OOA) and Object-Oriented Design (OOD), all while having a strong knowledge of the domain or subject that you’re working on. This combination of skills and knowledge will set you up for success in feature development.