Automation Solutions Using Design Patterns

Introduction

A design pattern is, essentially, a way of structuring development in a logically consistent and modular way, across solutions, that aims to enable the reusability of solution components and increase their longevity. In traditional software development, design patterns are used together with architectural patterns to structure code in a manner that aims to instil general and consistent approaches to development, to increase performance, minimize business risk, and ensure high availability.

For this reason, exception handling and testing often form part of the development approach—which can be transferred to developing automation solutions, especially using products that enable such approaches, like UiPath. 

Background context 

There are many design patterns that can be implemented within a solution and ultimately depend on how the development team aims to solve a problem. The selection of the design pattern is one step in a much larger process that retrospectively spans across a large part of the solution preparation, design, and development. This process is kicked off by the solution architect’s decision of the defined architecture style, which leads to the selection of an appropriate architectural pattern and then the design pattern. 

Architecture style 

Architecture style refers to the principles that design and development-level decisions should be made off. There are many architectural styles to choose from and are often narrowed down based on what the main focus of the solution would be. Some of the more common selections would include object-orientated architectures, data-centric architectures, and layered architectures—there are many others out there too. 

Object-orientated and data-centered architectures would fit into automation environments quite well as object-orientation is focused on achieving modularisation and high reusability of code, while data-centricity focus heavily on architecting a solution around its input and output data.

For automation projects, as presented by UiPath, processes could be built as iterative, linear, or transactional processes. The selection of one of those would also form part of the architecture style. The architecture style will narrow down the wide range of architectural patterns that exist based on the patterns that adhere to the principles of the selected architecture style.  

Architecture pattern

The architectural pattern is selected as part of the solution design phase and is closely linked to the principles that form the selected architectural style. The architecture pattern typically denotes how a solution can be implemented from a high-level architecture. There are many different types of architectural patterns that exist and are extensively used.

The 2-tier and 3-tier patterns would work quite well as architecture patterns as the separate the core elements of the solutions into different tiers: client applications (or even logic in other instances) and data sources (2-tier) or data, presentation and business/domain logic (3-tier). 

Design Pattern

The design pattern is traditionally selected as part of the development phase of solution development, although there definitely are advantages to deciding as part of the design phase as well, especially in an automation environment. Design patterns are categorically placed within the following categories: behavioural, structural and creative patterns.

Patterns, like the repository pattern, are typically used in cases where the degree of obfuscation between data access and business/domain logic are separated into multiple levels to enable the ability to swap out data sources or logic blocks without severely impacting the solution, thus maintaining the longevity of the solution, even when introducing change.

The concept is definitely appropriate in the automation landscape where processes may be retrofitted to work across Enterprise Resource Planning (ERP) systems as well as different data sources/structures.

It's important that tests and exception handling be included as part of solution development while aligning to the selected patterns. 

Is REFramework considered a pattern?

 As great as Robotic Enterprise (RE) Framework is at standardizing the approach to processing by including exception handling, REFramework is more of a template than it is a pattern. The logic to be applied within the Process.xaml file of the REFramework can still be broken out further into an approach specified by a selection of patterns. Implementation of a pattern within the REFramework can be retemplatised.

Why implement patterns into automation solutions in UiPath?

There are multiple advantages of implementing design patterns in automation solutions within UiPath. Some of which include maintaining the longevity of projects when change is introduced, easily, enhancing processes by changing data sources instead of redeveloping solutions, increasing performance (if applied correctly), guaranteeing high availability, providing stability, and establishing consistency across solutions. It does, however, increase development time which may be unnecessary for very small, temporary processes. In such a case, maintaining the balance is important and needs to be considered before applying a design pattern.

Getting started with design patterns in UiPath

Getting started with design patterns in UiPath requires a lot of thought and decision making. To make the most appropriate decision, a solution architect requires some in depth knowledge about the different options that are available.

Being a solution architect in the automation space is equally important as being a solution architect for traditional software development due to the knowledge required to make these kinds of decisions. Everyone has to start somewhere, though—a good way to start is to see how it can be implemented. Check out a free template available on the UiPath Marketplace.