Existing design-scape for software application design
The state of software application designing is currently subjective. There exists a definition of a loose set of aggregates such as design principles, design patterns for common problems, predefined architectures, that can be aggregated to design applications, but, no standardised design strategy exists. In general, the software’s resilience and flexibility depends highly on the architect designing the application.
Some existing design strategies include SOLID for Object Oriented design, functional design concept, java structural patterns, behavioural patterns, flow based design, microservices based design, MVC design pattern and so on. As it can be seen, each of these are applied in some part of the application design and multiple of them need to be combined to achieve a complete application design.
Disadvantages of the existing design-scape
When such a highly subjective environment exists, it becomes difficult to enforce standards that can be followed objectively to prevent loss of software quality over time. Hence, it is observed that when the application is in its infancy, with just a few core architects working on the design it maintains the high level of conformance to the principles put in place, but as the application expands in functionality and time, the design principles are discarded and quick fixes added and patterns are easily violated and adapted for non-intended purposes, degrading the application’s quality fast.
The current software application scape is a rapidly changing with the introduction of SaaS. Features of the software needs to change as fast as the thought occurs to ensure that it can be tested in the market, before a full scale development is initiated for the feature. It is also seen that as products are deployed in the market, learnings are got which need to be adapted into the software fast to investigate the adoption of the feature and incrementally modified so that lesser used features can be dropped and popular features can be worked upon for easier adoption.
Such rapidity can only be achieved by use of WYSWIG tools for software development that generate code for what is designed. But, where the design methodology itself is independent of the features, and existing principles and patterns defined are for technology oriented problems as opposed to function oriented, developing a WYSWIG tool is a far-call.
What is needed is a standardised strategy for software design at its various levels of design related to the business requirements defined, so that once such a design is done, code can be generated automatically reducing the time to market. Trials of various feature changes then becomes just a matter of changing the requirements which then generates the appropriate code.
Standardising designing with FSM
What is a finite state machine? From wikipedia “It is an abstract machine that can be in exactly one of a finite number of states at any given time.” How can we use this in application design? Applications have multiple business data objects that can adapt finite state machines. For eg., a Transportation Management System has a primary business object called “Shipment” which goes through various states within the application based on events that occur on the shipment in real-life.
Most applications have state machines inherently embedded in them. It is just that it is not explicitly designed in that manner to make use of the advantages of state machines. For eg., the “Shipment” object typically has a “status” field and is set to various strings such as “created”, “loading”, “in-transit” and so on, till it goes to the “completed” status. A developer sets this manually within the handler for the request that changes the state of the object. A high level look at the code does not bring out with clarity the various states through which the “Shipment” object will go through and the various events that changes the “Shipment” object status.
So, what do we lose when we do not recognise the state machine of the business object? Even in a state machine we will obviously add the “status” column and update it appropriately? Business features and functions operate based on states of business objects. By shifting focus away from this, we have traded the advantage of designing and coding close to a business function to design and code close to a technology. This has cost us the time required to translate requirements from business oriented to technology oriented design. What advantage does designing with technology give us? Why do we need this intermediate step? Why not use business requirement as a design for coding?
PoC It online is based on a platform that inherently supports state machine based designing which gives it the advantage of easy code generation. Try it now here.
Published on Java Code Geeks with permission by Raji Sankar, partner at our JCG program. See the original article here: Standardising software application designing Opinions expressed by Java Code Geeks contributors are their own. |
Quite a detailed article.
There are problems, which are more complex than FSM. You cannot standardize something on FSM, which needs Turing machine.