Mastering Mobile App Development: The Importance of System Analysis & Drawing Diagrams

When developing mobile apps, it’s important to find a balance between solving current issues and preparing for future changes. This balance involves designing the system in a way that can easily accommodate future needs while keeping it organized and avoiding unnecessary features.

To achieve success, there are several important factors to consider.

First, it’s crucial to understand the needs of the customers. This involves gathering information about what the customers want and expect from the app.

Secondly, establishing clear lines of communication with the customers is vital. It’s important to have open and effective communication channels to discuss requirements, provide updates, and address any concerns or feedback.

Lastly, fostering mutual understanding is key. Developers should work towards building a shared understanding with the customers regarding the app’s functionality, design, and objectives. This helps ensure that the final product meets the customer’s requirements and aligns with their vision.

To highlight the key considerations for developers:

Clear Communication with Customer(Customer here could be Product/Analyst):
When a customer brings you a new feature or changes, understanding their needs is crucial. Communication is your best friend in this process. Sometimes, developers might hesitate to ask questions when faced with unclear visions or lackluster requirements. But here’s the thing: asking questions is key to ensuring everyone is on the same page.

So, let’s remember to ask ourselves a few important questions:

• What value does this feature bring to customers? (Understand what is going on.)
• What’s the purpose behind implementing it? (Eliminate assumptions.)
• How should we handle different scenarios, such as success and error cases? ( e.g. how does caching fit into the equation?- offline behavior)

To bridge the communication gap, it’s essential to have direct conversations with analysts. An effective approach is Behavior-Driven Development (BDD), where meaningful discussions take precedence over getting bogged down by tools. By focusing on delivering maximum value through BDD, the entire team can align with customer needs.

Now, let’s zoom in on some crucial factors to consider during system analysis:

1. Backward Compatibility: Take a moment to think about how your app will affect loyal customers using previous versions.
2. Offline Support: How you can support offline functionality. Should data be cached? And how can you gracefully handle situations where the internet connection is weak or nonexistent?
3. Stability and Scalability: It’s important to evaluate the stability of your feature. Consider the number of users expected to utilize it. You might think of implementing an automatic request scheduler for frequently visited pages to ensure smooth performance.
4. Collaboration for Success: Bringing the entire team together backend and frontend developers, and mobile developers — is crucial for effective decision-making. Even if different programming languages are involved, aligning the approach across teams fosters efficient development. Remember, clear communication is vital to keep the team motivated and on the same track.

Building Effective Architecture through Communication:
To facilitate system analysis, maybe using BDD, creating use cases, and utilizing flowcharts. These tools help establish a shared understanding of requirements. Keep in mind that investing time in refining requirements pays off in preventing costly mistakes during development. And all the above tools only matter when the aim is not to think about which tool to use, but instead, think about the value that the feature brings the customer, and dig deep.

Boosting Value through Effective Communication:
When a team excels at communicating needs to one another and across different teams, everyone benefits! You’ll find more satisfaction in your work and increase your team’s value, ultimately leading to reduced costs for the business.

Understanding use cases, including various scenarios and offline support, empowers your team to make informed decisions. Visual representations, such as quick diagrams, can work wonders in conveying ideas among developers. Once the whole team is on the same page for the feature and its needs, then it is time for the system analysis. There is no good system design with a poor understanding of the needs of the customer. Good architecture starts with good communication.

Now that we’ve established effective communication within the team, it’s time to dive into the analysis and design phase.

Drawing Diagrams — Modular Design

Let’s take a practical example: Suppose we need to display the latest user posts, similar to an Instagram feed. After aligning with the product requirements, we understand that we’ll be working on the following use cases:

1. Happy Path: Displaying the user’s feed without any issues.
2. Offline Mode: Handling the situation when the user is offline by implementing a caching mechanism to store and display previously fetched data.
3. Low Internet Connectivity: Addressing scenarios where the user has a poor network connection. We need to define error case scenarios to handle these situations gracefully (Sad path).

Considering these use cases, here are some additional technical requirements we need to think about:

• Cache Mechanism: Implementing a caching mechanism to store posts locally and for example, refresh the cache every two minutes (Cache policy).
• Automatic Request Scheduler: Even if the user doesn’t manually pull to refresh, we can add an automatic request scheduler to periodically fetch new posts.
• Public Access: Allowing users who are not logged in to still view public posts (Authorization Decorator Design Pattern would be handy in this case).
• Backend Synchronization: Collaborating with the backend team, we might need to implement a circuit breaker operation to handle excessive requests and ensure the system remains stable (Using a circuit breaker approach).

Align with designers and backends to have a boundary contract between them:
At this stage, you can understand the components that the designer will give you: Such as on the page, there will be posts, posts will have images(UIImage), titles(labels), comments(collectionView), etc. Without seeing the whole design you can agree on the UI components, and can prepare a boundary contract that you will get from remote API. You may provide an example response JSON data to the backend team so that they will understand better, and there will be no room left for assumptions.

JSON contract with the backend team could be like the below:
endpoint: get/feed/userId: UUID
status: 200
success data:

{
"items":[{
"postID": "an UUID",
"likeCount":5,
"comments": [], //optionals
"imageURLs": ["https:…","https:…"]}]
}

Here you can differentiate the optional and required parameters with UI and backend team.

After agreeing on the UI components with designers and sharing the example response JSON data with the backend team, now it is time to work with the mobile team.

Pairing up with team members:
Before diving into coding, it’s good practice to pair up with a team member. After pairing, one person can focus on the UI part while the other works on the API and data persistence. Here to align with the teammate, protocols could be used as a boundary contract between modules. During system analysis, to prevent any misunderstandings both team members should agree on the abstract representation of the code.

Let’s settle on the boundary contract with the teammates for the posts:

PostItem:

• imageUrls: An array of strings representing the URLs of the post images.
• postId: A string identifier for the post.
• likeCount: An integer indicating the number of likes for the post.
• comments: An array of comments associated with the post.

Comment:

• commentId: A string identifier for the comment.
• commentedUserId: The ID of the user who made the comment.
• comment: The actual comment text.

During your pairing session, you may explore further details, such as:

• SSL Pinning: Considering SSL pinning to match certificates for enhanced security.
• APICircuitBreaker: Implementing a retry mechanism to prevent overloading and system failure. The circuit breaker monitors the health of the API and temporarily stops sending requests if issues are detected. This allows the system to recover and prevents further problems.
• Automatic Request Scheduler: Developing a system that automatically sends HTTP requests at specified intervals, such as every two minutes. This ensures our app remains up-to-date with the latest posts without relying on manual pull-to-refresh actions.

By discussing and clarifying these details during the system analysis phase, you and your team can establish a solid foundation for the upcoming development tasks.

The time, the development has been done, the code should merge and work altogether, since the team abided by the protocols that were written in the design phase.

Here is how the design could be:

system analysis

During the system analysis and design phase, it’s essential to visualize the architecture of your mobile app. In the drawing, I've assigned different colors to each module, signifying their independence and deployability. This approach aligns perfectly with the principles of clean architecture.

Clean architecture promotes modularity by ensuring that higher-level modules do not depend on lower-level ones, and vice versa. Instead, all modules rely on abstractions, creating a clear separation of concerns. This decoupling allows for flexibility and maintainability, as changes made to one module do not impact others. So it enables the whole team to work independently for the same feature.

By designing the app with independent and deployable modules, we establish a solid foundation for scalability and extensibility. Each module serves a specific purpose and can be modified or replaced without affecting the overall system. This modularity enhances testability and enables seamless integration of new features or updates in the future.

Keep in mind that when creating the architecture diagram, it’s important to remember that its purpose is to have clear communication within the team before diving into the code.

Drawing the architecture diagram should be a quick process, taking around 10 to 15 minutes at most. Its main goal is to establish a shared understanding among team members and ensure everyone is on the same page regarding the app’s structure and module dependencies.

Using the diagram as extensive documentation can be costly and burdensome. Software is constantly evolving, and relying solely on a static diagram for documentation can quickly become outdated and difficult to maintain. Instead, it’s better to view the diagram as a starting point, allowing for flexibility and adaptability as the software evolves.

By keeping the diagram as a sketch or visual aid, you can save time and effort. The team can see how the communication will occur through the modules, also possible problems can be detected beforehand (For example: retain cycles). The diagram will be a helpful tool for initial communication and collaboration, ensuring a solid foundation for the development process.

Clean architecture is all about modularity and flexibility. Divide your code into independent modules that can be easily switched out or reused across different applications. Remember, there’s no one-size-fits-all solution! Tailor your architecture and system analysis to meet the unique needs of each app. The more you explore different approaches, the broader your range of options becomes for addressing app-specific requirements.

In conclusion, system analysis is a powerful tool in mobile app development. It enables you to understand and fulfill customer needs effectively. By prioritizing clear communication, embracing collaboration, and following solid architectural principles, you’ll craft efficient, scalable, and maintainable mobile applications. So go forth and conquer the world of app development!

Links:
https://rozeridilar.com/2023/05/29/mastering-mobile-app-development-the-importance-of-system-analysis-drawing-diagrams/
https://www.essentialdeveloper.com/articles/consequences-of-ineffective-communication-in-ios-teams
https://www.youtube.com/watch?v=CYO0Ibs0FIM&ab_channel=AndreyTech
https://www.goodreads.com/book/show/296981.Object_Oriented_Software_Engineering