Wie kann OOAD Ihnen helfen, skalierbare und wartbare Cloud-Anwendungen zu entwerfen?

We often encounter situations where the requirement states "Build an umbrella", but we discover that the developer has written code to "Stop the rain". We sometimes over complicate object-oriented requirements because the mindset is that more is better than less. This is definitely not true where cloud applications are considered. There are no takers for a bloated, over-featured, confusing cloud application. The statement of a requirement should be clear, concise, brief and consistent with the conversations we are having with the stakeholder(s). To make this process exciting, we can use pictures & flow charts, story boards/user stories, etc. The idea is to be able to apply OO techniques to translate requirement to code.

Once the classes are finalized & their relationships marked out, in the form of Class Diagrams, we are closer to identifying the objects in the system. Use case diagrams would have already been drawn to visualize the interactions between external systems & the system being designed. There can be many interfaces playing dual roles of a class as well as an actor. So, we need perspective of when an actor is another internal design component, and when it is just an actor/client interface. Based on the number of objects, the cloud application’s size will vary. If size is a strongly defined to be between such & such a number (necessary to understand the storage needs at the cloud server), the OOAD design process should include this check as well.

Objects have state, behavior & identity. This also means they interact between each other to achieve certain objectives they were designed for. There are static / compile time interactions. There are dynamic / run time interactions. There are statutory templates in diagrammatic form defined to document object interactions of both types. The granularity of the interactions in the cloud application decides the scalability, security & flexibility. One should design exception handling logic also at this stage. Whether you code in C++ or modern Object-Oriented Programming Languages, it is important to understand the proficiency of the language in handling run-time behaviors of objects while collaborating with each other.

How does your software on the cloud interact with customers, meaning which standards? What is the frequency of requests it can handle? Are there chances it may fail to service some customer due to known issues / memory lack / exception raised? What is the tolerated volume of requests? If a user is in a remote area, can he use your cloud app? What is the accepted downtime of your cloud app? Do you have reliable backup of user data? Is data security & privacy given top priority? How do you protect your app from hackers? Is there 24*7 support for your app? Are there chatbots employed to support customers? These questions are answered by an architecture diagram which is designed by the system architect, business analyst & functional engineers.

Writing the code is the easiest step of development process of a scalable & maintainable cloud app. Cloud applications have been around for more than a decade. There are plenty of mature tools available that will help convert your documents/diagrams into skeleton code. After that, the coding team needs to write the executable logic & test cases, review the code & structure the build process (depending on iterative logic). But this app may have some challenges the team has not seen before, for example – a sudden spurt in volume of user base expected, or server space concerns, etc. Scalability needs to be implemented in iterative coding processes, releasing beta versions of the app & testing them (unit, system, user acceptance, integration).

Componentization is one of the strong points of OOAD. As opposed to one huge section of code & an xml document being uploaded to a server like in the earlier years (App Server), cloud services platforms can be configured to choose & pick the components they will host, based on geography, app space & memory needs. Logic & results of technical analysis (complete architecture) determine the deployment design of the component. Studying cloud service logs helps the team maintain the app, while sticking to service level agreements. Redundant components help the team schedule downtime, so that high availability is possible. Performance metrics such as response time, lifecycle of a component, etc. should be analyzed & improvement plans designed.

While working on a customer relationship management project at the Milton Keynes public council (back in 2006), I was a senior Java developer in a team that was new to each other, all of us contractors. The project head was also an Indian, however he brought a few members familiar to him with him. So, there were social challenges as well apart from technical ones during the progress of the project. Technical coverage is not just achieved by choosing OOAD as the development paradigm. People & process have to align with scalability goals to develop a maintainable app. It took some hiccups, many meetings & arguments but domain expertise (CRM) and willingness to work hard was a common theme & as a team, we succeeded in making the app go live.