DESIGNING MICROSERVICES WITH USE CASES AND UML

Thesis

Submitted to

The College of Arts and Sciences of the

UNIVERSITY OF DAYTON

In Partial Fulfillment of the Requirements for

The Degree of

Master of Computer Science

By

Akhil Reddy Bommareddy

Dayton, Ohio

August 2023
 DESIGNING MICROSERVICES WITH USE CASES AND UML

Name: Bommareddy, Akhil Reddy

APPROVED BY:

Raghava Gowda, Ph.D.

Faculty Advisor

Mehdi R. Zargham, Ph.D.

Committee Member

James Buckley, Ph.D.

Committee Member

1
 © Copyright by

Akhil Reddy Bommareddy

All rights reserved.

2023

2
 ABSTRACT
DESIGNING MICROSERVICES WITH USE CASES AND UML

Name: Bommareddy, Akhil Reddy

University of Dayton

Advisor: Raghava Gowda, Ph.D.

In recent years microservices architecture (MSA) has been widely adopted as an alternative
to the traditional monolithic architecture in most of the commercial applications because
of the need for the extensibility of a wide variety of services and deployability. Monolithic
software architectures include Data-Centered Architectures, Data-Flow Architectures, Call
and Return Architectures, Object-Oriented Architectures, and Layered Architectures. The
monolithic approach included where all the logic and data requirements are bundled
together. In recent years large scale software applications by Amazon, Netflix, Uber, and
other organizations have felt a need to partition the functionalities into independently
deployable units which are called microservices.

In this thesis we also explore using the essential concepts of coupling, cohesion, and top-
down decomposition that are used for monolithic architectures to microservices also. One
of the major requirements for an independently deployable microservice is embedding data
components in that microservice unit. We identify use cases with data components for any
task and define them using use case descriptions, input/output designs, activity diagram,
entity descriptions for the inputs/outputs and a system sequence diagram. The system
sequence diagram triggers the logical aspects of the system with the domain classes and
data access and view classes. The completeness of the various classes is examined using
Class Responsibility Collaboration (CRC) cards informally or through detailed sequence
diagrams. Resulting refined design class diagrams are packaged into monolithic or
microservices architecture. We illustrate and implement the microservice architecture for
a Farm Produce Procurement and Sales System.

3
DEDICATION

Dedicated to my Mom, Dad, and Sister.

4
 ACKNOWLEDGMENTS

I would like to express my sincere gratitude and appreciation to my advisor Dr.

Raghava Gowda for his invaluable guidance and support throughout my research journey.

His expertise and insightful feedback have been instrumental in shaping the direction of

my study. Additionally, I am grateful for his patience and encouragement, which have

motivated me to overcome challenges and strive for excellence in my work. I would like

to thank Dr. Mehdi Zargham and Dr. James Buckley for serving on my thesis committee.

Special thanks to my family and friends for their unwavering support and understanding

during this demanding period of my academic journey.

5
 TABLE OF CONTENTS

ABSTRACT........................................................................................................................ 3

DEDICATION .................................................................................................................... 4

ACKNOWLEDGMENTS .................................................................................................. 5

LIST OF FIGURES ............................................................................................................ 8

LIST OF TABLES ............................................................................................................ 10

LIST OF ABBREVIATIONS AND NOTATIONS ......................................................... 11

CHAPTER 1 INTRODUCTION ...................................................................................... 12

1.1 Objective ................................................................................................................. 17
1.2 Contribution ............................................................................................................ 18
1.3 Significance ............................................................................................................. 18

CHAPTER 2 LITERATURE REVIEW ........................................................................... 20

2.1 HTTP and Web Frameworks: ................................................................................. 22
2.2 Cloud Computing .................................................................................................... 23
2.3 Virtualization........................................................................................................... 25
2.4 Microservices .......................................................................................................... 26

CHAPTER 3 METHODOLOGY ..................................................................................... 29

3.1 Background ............................................................................................................. 32
3.2 Requirement Gathering with Use Cases.................................................................. 32
3.3 Designing Microservice Architecture for PMS Application. .................................. 45
3.4 Comparison of Monolithic and Microservice Architecture .................................... 48
3.5 Comparison of general approach and our approach for designing microservices .. 49

CHAPTER 4 IMPLEMENTATION................................................................................. 51
4.1 Technology .............................................................................................................. 52
4.3 Environment Setup .................................................................................................. 53
6
 4.4 Project Setup ........................................................................................................... 53
4.5 Implementation........................................................................................................ 55

CHAPTER 5 SUMMARY AND FUTURE WORKS ...................................................... 60

BIBLIOGRAPHY ............................................................................................................. 66

7
 LIST OF FIGURES

Figure 1 WBS hierarchy chart for any project .................................................................. 29

Figure 2 Work Breakdown Structure for PMS application .............................................. 31

Figure 3 Use case diagram for P1 - Get Producer Data. ................................................... 35

Figure 4 Use case description for P11 – Create Producer Account. ................................. 36

Figure 5 Input Screen for P11I1 – Register Producer Account ........................................ 37

Figure 6 Output Screen for P11I2 - Producer Information. .............................................. 38

Figure 7 Activity Diagram for P11A1 – Producer Information ........................................ 39

Figure 8 ER-Diagram for P11ER1 – Producer Account and Produce Details ................. 41

Figure 9 System Sequence Diagram for P11SSD1 – Create producer Account............... 42

Figure 10 Class Diagram For P11DCD1 – Producer Account and Producer Details ....... 43

Figure 11 Detailed Sequence Diagram For P11DSD1 – Producer Account and Producer

Details ............................................................................................................................... 44

Figure 12 Package Diagram P11PD1 - Producer Microservice........................................ 45

Figure 13 Microservice for Producer Service ................................................................... 46

Figure 14 Overall Architecture Diagram for PMS Application........................................ 48

8
Figure 15 Project Structure ............................................................................................... 54

Figure 16 Database Information in environment file........................................................ 55

Figure 17 Database setup in Django project ..................................................................... 55

Figure 18 Model class for Produce ................................................................................... 56

Figure 19 serializers.py for converting model data types to python native datatypes. ..... 57

Figure 20 Creating API view in views.py......................................................................... 57

Figure 21 Testing API using Postman tool. ...................................................................... 58

Figure 22 Django admin panel .......................................................................................... 59

Figure 23 Final output for Providing Produce Details ...................................................... 60

Figure 24 Final Output for Producer ................................................................................. 60

9
 LIST OF TABLES

Table 1 Entity Table for P11E1 – Producer Account and Produce Details ...................... 40

Table 2 Comparison of Monolithic and Microservice Architecture ................................. 48

Table 3 Comparison of general approach and our approach for designing

microservices..................................................................................................................... 49

10
 LIST OF ABBREVIATIONS AND NOTATIONS

PMS Procurement Management System

SOC Service-Oriented Computing

SOA Service-Oriented Architecture

CGI Common Gateway Interface

HTTP Hypertext Transfer Protocol

HTML Hypertext Markup Language

IPC Interprocess communication

SOAP Simple Object Access Protocol

XML Extensible Markup Language

REST Representational State Transfer

API Application Programming Interface

MVC Model View Controller

MVT Model View Template

11
 CHAPTER 1

INTRODUCTION

In the field of software engineering, which is continuously undergoing rapid change,

software architects and researchers are always working hard to find the most efficient

methods for developing software systems or applications. Their primary objective is to

provide clients with software that is of a consistently high-quality software while also

effectively managing the team’s efforts of the team and ensuring that all members

understand have a common understanding of the project's goals and implementation

strategies.

Software development has always been viewed as a primary area of focus for software

developers, with the primary objective being to simplify and streamline the process. As a

direct consequence of this, there is a persistent push to either enhance or establish brand-

new development procedures and architectures. The use of microservices is currently

regarded as one of the most cutting-edge developments in the field of software architecture.

Microservice architecture is a style of architecture that breaks down an application into a

group of individual services that are relatively small and loosely coupled to one another.

Each service is developed to particular business function, and each service can be

independently developed, deployed, and scaled. The goal of the microservices approach

aims is to improve agility, scalability, and maintainability by decomposing a complicated

application into a series of smaller services that are easier to manage.

12
However, it is not uncommon for people and businesses to adopt microservices without

fully comprehending the principles and implications of what they are doing. This is a

common problem. This phenomenon, known as "microservice envy," takes place when

individuals embrace a trend without having a profound understanding of the complexities

and potential difficulties associated with that trend. When integrating microservices into

software architecture, it is essential to recognize the significance of having a

comprehensive understanding and careful consideration to the matter [1].

The concept behind developing applications as a collection of small, independent services,

each of which operates as its process, is at the core of the microservices architecture. These

services are designed so that they can be deployed independently with a minimal amount

of centralized management [2], and they are based on particular business capabilities.

Developers can create a set of services that are only loosely coupled when they use an

approach known as microservices. Dedicated teams can independently develop, test, and

deploy these.

In contrast to this, the traditional approach to developing software entails the construction

of monolithic applications. These applications are self-contained and can function

independently of any other applications. To achieve the same functionality offered by a

monolith, microservices should require a combination or composition of multiple services.

A monolithic application manages not only the business logic but also the data operations

and the user interfaces. This frequently results in complex and tangled codebases, which

impede continuous development and maintenance.

13
Every service in a microservices architecture runs inside its own bounded context,

determined by the business functions being used and designed using domain-driven

principles [3]. Consequently, the management of data is simplified because each service

maintains its dedicated database in which it only stores data pertinent to the achievement

of its particular goal. The ability to choose the technology stack that is best suited for each

service is one of the primary benefits of using microservices. This helps to ensure that each

service is developed in the most effective way possible for its intended purpose. In addition,

deployment of microservices can be done on demand, which allows them to overcome the

limitations of traditional monolithic architectures regarding flexibility and scalability. This

makes it possible to place more of an emphasis on rapid delivery rather than difficult

maintenance procedures.

Adopting microservices makes code management much easier, helps to keep interfaces

straightforward, and significantly reduces the complexity of software components.

Microservices align closely aligned with agile software development methodologies,

emphasizing speedy value delivery. This aspect of their design contributes to the disruptive

nature of the technology they represent. The approach known as microservices is highly

compatible with DevOps practices such as Continuous Delivery, Continuous Integration,

and Automated Building. As a result, microservices not only characterize a certain

architectural style but are also deeply matted with a given company’s organizational

structures and procedures.

However, to have a complete understanding of microservices, one must also be aware of

the limitations of this architecture and the fact that there are more appropriate solutions to
14
the problems of scalability and codebase management problems that can arise within an

application. The complexity that could delay performance is introduced when a single

application is divided into multiple distributed components that communicate over the web.

Increased latency and longer response times are common problems that can harm the user

experience and perception. As a result, implementing microservices calls for additional

work from developers and requires careful planning before it can be done.

On the other hand, the additional effort invested in microservices may not yield significant

benefits for certain applications. This is because the complexity introduced by

microservices can result in decreased productivity. The term "Microservices Premium"

describes this idea, highlighting the trade-off between the benefits and complexities of

using microservices [4].

Additional evidence for the concept of complexity in microservices comes from research

conducted by Nicola Dragoni [5]. It was hypothesized that smaller components would have

a fault density that was lower than larger ones; however, it was discovered that smaller

components frequently exhibit a higher fault density [6]. The low availability resulting

from the high level of interdependence between microservices is ultimately inevitable. In

addition, as was discussed earlier, the transmission of information across a network result

in latency, which harms performance. The community of people who work with distributed

systems is already familiar with certain challenges, such as service discovery, load

balancing, and routing; however, ensuring these mechanisms within a dynamic

microservices ecosystem adds a layer of complexity to the problem. Because of the

dynamic nature of microservices, which allows scaling based on demand, the number of
15
instances of a particular service cannot be determined in advance. As a consequence of

this, the mechanisms that were mentioned need to have the capacity to manage runtime

operations and adapt to changes in the system.

Monitoring a microservices ecosystem is a complicated process from a business and

operational point of view. Figuring out which metrics are most important and setting up

alerting systems are two of the most important things that need to be done to enable prompt

action in response to irregularities. When diagnosing problems causing anomalies, in-depth

knowledge and the ability to trace system actions are required. Reporting is frequently

automated.

Many early adopters of microservices have been transparent, sharing their experiences with

adoption and documenting their change processes while also contributing solutions to

problems they have encountered. Microservices have been utilized by well-known

businesses such as Amazon [7], [8], Netflix [9], [10], Uber [11], [12], and others [13] for

a considerable amount of time before the term became widely used.

Extensive testing is required to guarantee that a microservices-based system will function

as anticipated. This in and of itself presents a challenge because it calls for comprehensive

test coverage and frequently necessitates post-inspection of the code to guarantee its

quality. Even when designing a system to resist failures, it is essential to validate its

capacity to withstand heavy loads during peak times and prevent faults from propagating

to dependent services. Validation can be done by testing the system's ability to pass a stress

test.

16
The inherent complexity that comes with adopting the microservices architectural style is

directly tied to the challenges that have been highlighted above. Making decisions based

on accurate information is necessary to guarantee that the completed system will follow

the original proposal. Please do so to avoid subsequent problems that are difficult to rectify,

as certain decisions become non-trivially difficult to reverse during later phases of

development. If you fail to do so, this can lead to subsequent problems that are difficult to

rectify. To prevent these challenges from becoming significant concerns for architects and

developers, the first step is to dismantle the monolithic architecture and replace it with a

series of smaller architectures known as microservices. During the migration process, you

will need to get past this initial obstacle, which requires a comprehensive investigation into

the system's architecture across all of its layers, including the storage of data and the

interaction between users. To ensure a seamless transition, the migration process should be

carried out in stages, with each phase concentrating on the migration of a single service.

1.1 Objective

The main objective of this thesis is to design microservice architecture for Procurement

Management System by applying a traditional monolithic architecture design approach.

First, we identify use cases and define them. Then, we draw input/output screens and

activity diagrams. We also derive E-R diagrams to understand the data flow within the

system better. Later, object-oriented analysis and design methods were used to identify the

components with unique functionality, and later, they were partitioned into suitable

microservices. This may be like a monolithic architecture approach, but the components

17
would be services. Finally, we develop the application with suitable tools and deploy the

application. Microservices architecture allows for easier deployment and maintenance of

the system, as each service can be updated and tested independently.

1.2 Contribution

1) By combining the benefits of traditional monolithic architecture design for

microservices, the described process enables the development of an agile and

adaptable system. The modular nature of microservices allows for quick iterations

and updates, enabling faster responses to changing business needs and

technological advancements.

2) Using elicitation techniques such as use case identification, input/output screens,

and activity diagrams ensures a user-centric design approach. By understanding and

incorporating user requirements from the early stages, the microservice architecture

can be tailored to provide a more intuitive and effective user experience.

3) The object-oriented analysis and design methods contribute to identifying

components with unique functionality. This enables partitioning these components

into suitable microservices, resulting in a modular and scalable architecture. This

approach allows for flexible scaling of individual services based on demand and

facilitates the development of new services as needed.

1.3 Significance

The significance of following the described process for developing a microservice

architecture lies in its systematic and structured approach to designing the Procurement
18
Management System. By first identifying and defining use cases, the assigned development

team clearly understands the system's functional requirements. Drawing input/output

screens and activity diagrams helps visualize the system's behavior and user interactions,

ensuring a user-centric design and deriving E-R diagrams aids in comprehending the data

flow within the system, facilitating data modeling and database design decisions. The

object-oriented analysis and design methods assist in identifying the components with

unique functionality, which are then partitioned into suitable microservices. This approach

allows for a more precise and modular design, enhancing the system's scalability and

maintainability. Finally, deploying the application using microservices enables

independent testing and updates for each service, simplifying maintenance.

19
 CHAPTER 2

LITERATURE REVIEW

This chapter mainly discusses the concepts of component-based software, service-oriented

computing, HTTP and web frameworks, cloud computing, and virtualization. These

concepts made it easier to develop, deploy, and manage microservices. The concept of

component-based software helped break down software applications into smaller, self-

contained components. This made it easier to develop microservices, which are also self-

contained. Service-oriented computing defines software as a collection of services, similar

to microservices. HTTP and web frameworks make it easier to develop and deploy

microservices, as they provide a standardized protocol for exchanging data over the

Internet. Cloud computing and virtualization provide a scalable and reliable infrastructure

for hosting microservices. Overall, combining these technologies and approaches has

revolutionized how software is developed and deployed, enabling organizations to build

complex systems.

Developing software in modular, self-contained components that focus on a single scope

has long been an aim. Combining these reusable components, which communicate via

documented interfaces, enables the creation of systems [14]. To overcome this issue,

component-based software became a popular concept in the late 1990s [15]. A software

package, web service, web resource, or module that contains a group of connected

functions or data is referred to as a component [16]. It represents a sub-domain of the

system as a modular, coherent, and reusable element.

20
The emergence of Service-Oriented Computing (SOC), which sought to accomplish the

required separation of concerns, resulted from the progress of software architecture

paradigms. With the introduction of the web, software became more and more focused on

it, and the idea of "services" became more important. Experts agreed that the web needed

to change to enable automated interactions better, as it was initially designed for human

usage [17]. The idea of "services" was created as a result of these automated interactions,

which would include machines interacting with one another to accomplish a task. The

services were developed as individual software components specifically adapted for use on

the web.

Adopting the services concept had several benefits. First of all, load balancing and

replication made services easily scalable. Second, services could be combined to create

more complicated services since they were modular and reusable. Thirdly, once a service's

interface was developed, external entities might use it as is, simplifying development. Only

a service's inputs and outputs were important; its internal operations were no longer a

priority. Standard communication protocols made service integration easier [5].

As businesses grew more dependent on software and the Internet, it became clear that

software design must be closely coordinated with the organizational business topology.

The architecture of a system started as a representation of the organization's procedures,

infrastructure, and information flows. Developing software emphasizing business

capabilities led to the creation of Service Oriented Architecture (SOA) [18], which

eventually became the strategy of choice for software development.

21
Although there is still some disagreement about whether microservices are merely a subset

of SOA, it is generally accepted that the two ideas are interconnected. Although they are

not the same, microservices can be considered a means to implement SOA [19].

2.1 HTTP and Web Frameworks:

The Web 2.0 evolution has provided a community-focused strategy that prioritizes user-

service interactions and offers more dynamic functionality. Because of this transition, the

individual components that go into making up the web are now more complicated. In the

beginning, web servers used a program called CGI to provide static data in response to

HTTP requests. However, as new frameworks appeared, programmers started creating

components to provide dynamic content. This dynamic behavior was made feasible by

integrating executable code with the code for the HTML interface. This allowed for the

delivery of tailored content based on data collected from other services.

These frameworks also offered developers a clearer distinction between view and

application logic. As a result, the MVC paradigm soon gained popularity and is now

commonly utilized with frameworks like Rails, AngularJS, and React. Interprocess

communication (IPC) technology adapted as the web continued to develop. Initially

regarded as a standard, the SOAP protocol enabled IPC over HTTP. It soon became clear

that this new paradigm's primary goal was not simply to provide content to browsers.

Because of this, text-based serialization formats like XML and JSON were popular among

services that performed activities or communicated data with other services. Developers

migrated to lighter and more adaptable protocols like REST when the SOAP protocol and

22
WS-* standards grew more complicated and intricately tied to implementations in

application servers. The Microservices Style is built upon these ideas.

2.2 Cloud Computing

Over the course of development's history, there have been numerous important shifts in the

kinds of resources that are readily available to developers. New models for Cloud

Computing have arisen after the initial emergence of Grid Computing. According to

customer demand, these models offered resources as general utilities that users could rent

and release via the Internet. This shift was largely driven by the web's popularity, providing

opportunities for further development.

Cloud services altered the traditional worries of businesses over physical resources by

making an "infinite" pool of resources available with no upfront expenses, low operational

costs, and on-demand provisioning. Monitoring is still vital, but careful planning and

estimation of physical resource utilization, as well as the subsequent allocation of resources

in accordance with those calculations, are no longer required. Resource availability was

made a provider's duty. As a result, businesses might shift their attention to creating better

services and providing people with better products.

The widespread availability of important cloud service providers such as Amazon's AWS,

Microsoft's Azure, and Google's Cloud Platform, amongst others, brought a unique

perspective on applications, namely the economic element of these software programs. As

resources became more readily accessible on demand, architects started to wonder why

entire applications were scaled up, raising overall costs, rather than judiciously scaling only
23
the components that needed more capacity for the workload. This way of thinking gave

rise to the idea of microservices, which are segments of software that may be independently

deployed.

Recent developments in cloud computing have brought about capabilities that work well

with applications built on microservices. For example, access to particular resources can

be limited, enabling services to cater to just designated entities while going unnoticed by

outside sources. Instead of relying exclusively on authentication, this can be accomplished

using network isolation. Additionally, simple procedures can be used to dynamically

modify the number of active instances during periods of high load. The cloud infrastructure

also makes it easier to schedule operations to run at particular times or respond to specified

events without continuously using up needless resources and to maintain updated data

replicas automatically.

The widespread adoption of these technologies does, however, raise the prospect of

confined contracts with specific vendors. Each vendor creates their proprietary technology

due to the need for uniformity across cloud resource providers. Consequently, making a

long-term commitment to a specific vendor and expanding one's technological stack based

on that vendor's offerings can result in difficulties if the decision is made to switch

providers. Because of this circumstance, the replacement of technologies is required, which

makes the question of vendor portability a delicate and complicated one. Before Docker

attained its popularity, Amazon had its proprietary virtualization method called Amazon

Machine Image (AMI), which serves as an illustration. AMI is exclusive to the AWS

platform even though it shares a basic similarity with Docker images. As a result, an
24
organization would need to adopt a separate virtualization technology if it wanted to switch

to a platform from a different vendor.

2.3 Virtualization

The use of virtualization technologies and techniques, which aim to supply computing

resources as a utility, has made it possible for new cloud computing models to develop.

This was made possible by the exploitation of these technologies and techniques. However,

traditional virtualization technologies have historically been a source of difficulty in terms

of the complexity of their use and the efficiency with which they utilize resources.

Consequently, using these tools to host small components such as microservices was not a

realistic choice because the total process did not produce significant benefits.

Fortunately, these issues have been resolved by the evolution of operating-system-level

virtualization solutions known as containers. Containers provide a lightweight and flexible

alternative to standard virtualization technologies, needing fewer resources while giving

outstanding performance. They offer this advantage because containers are a lightweight

and flexible alternative. Docker has become an industry standard because it enables

developers to easily execute programs within containers, alongside other apps on the same

host, in a secure manner. This makes Docker an attractive option for businesses.

As a result of this new information, software engineers are reevaluating the processes they

use to create software and thinking more carefully about the distinctions between deploying

programs as monoliths and as microservices. Docker and containerization have made it

possible to run a streamlined program inside of a container alongside other apps while
25
maintaining a high level of security and making it easier to perform efficient administration

tasks.

2.4 Microservices

Having established the origins and driving factors behind microservices, we can now

explore their advantages and disadvantages more comprehensively. This will enable us to

elucidate their definitions and underlying philosophies in detail.

Several authors have provided their own definitions of microservices, each with their

unique perspectives. Some researchers have described microservices as a greenfield

approach, emphasizing creating new systems from scratch. Others have focused on the

brownfield approach, which involves migrating existing monolithic applications to a

microservices architecture. By exploring these various definitions and perspectives, we can

better understand the benefits and challenges of microservices architecture.

We will also look into the various definitions of microservices provided by other

researchers and practitioners. According to Martin Fowler [1], a well-known software

engineer and author, microservices architecture is an approach where a single application

is built as a suite of small services, each running in its process and communicating with

lightweight mechanisms. Other researchers have defined microservices architecture to

break down monolithic applications into smaller, more manageable services that can be

developed and deployed independently.

26
According to Hilbrich [20], the greenfield approach to microservices architecture involves

the development of new systems using microservices-based architecture from the ground

up. This approach is often seen as the ideal way to implement microservices, allowing for

greater flexibility and scalability. However, it also presents several challenges, such as the

need for a highly skilled development team and the potential for increased complexity.

On the other hand, the brownfield approach involves migrating existing monolithic

applications to a microservices architecture. This approach is often seen as a more practical

way to implement microservices, allowing organizations to leverage their existing systems

and infrastructure. However, it also presents several challenges, such as the need for careful

planning and execution to avoid disrupting existing systems and processes.

Given the diverse range of definitions provided by different authors regarding

microservices, it becomes apparent that there is no universally agreed-upon definition. The

concept of microservices is characterized by its versatility and adaptability, allowing for

interpretation and implementation based on specific contexts and requirements.

Consequently, it is crucial to approach microservices with a comprehensive understanding

of the various perspectives and insights put forth by different authors, allowing for a

nuanced and contextualized interpretation of the concept.

As a result of careful consideration, we have made the decision to adopt a traditional

approach to developing a microservice architecture. This approach mirrors the

development process typically employed for monolithic architectures, which involves

defining use cases, activity diagrams, and input and output screens to encompass the entire

27
application. Subsequently, we will utilize Entity-Relationship (ER) diagrams and employ

an object-oriented methodology to break down the application's use cases into individual

microservices based on their distinct functionalities. This approach will ensure a systematic

and structured development process for our microservice architecture.

28
 CHAPTER 3

METHODOLOGY

This chapter shows how we derive monolithic and microservice architectures using use

cases and UML. First, we start by considering the work breakdown structure, which shows

the decomposition of the system into smaller components. This decomposition allows us

to identify the different use cases and their relationships within the system.

The WBS is a top-down decomposition of software development activities that includes

everything from Managing projects to delivering the system. WBS is the key tool for

project managers in planning, estimating, organizing, and operating various activities in

different phases of software development. We focus mainly on the "2. Do Systems

Analysis" aspect of the WBS. The traditional approach for decomposing any task is guided

by function, time, and event (external, internal, or state events). There is no guarantee that

these decomposition techniques would ensure complete independence concerning essential

data each component can hold.

Work Breakdown Structure (WBS): The WBS, as exemplified by [21] for any project, is

categorized into the following hierarchy chart (Page 179).

Figure 1 WBS hierarchy chart for any project

29
The same WBS can be shown in an indented form as follows:

1. Manage Project

2. Do System Analysis

3. Develop Software

4. Verify System

5. Validate System

6. Perform CM

7. Prepare Technical Publications

8. Deliver System

For naming WBS components, we will also use verbs that would be carried to the lower

levels of use cases. Some of the components of the WBS structure and corresponding

microservices for the Procurement Management System and their breakdown to some of

the use cases P11, P12, etc., are shown in following Figure 2.

The tasks listed under the WBS are from the organization point of view. Generally, use

cases are represented from the actor’s point of view. One has to be careful in naming WBS

tasks and use cases from these perspectives otherwise it may lead to some confusion for

example for produce the producer needs to get advance payment that can be a use case such

as “Get Payment for Produce” in producer point of view. The same use case could be

represented as “Pay for Produce” in admin point of view. In WBS to avoid confusion we

should use an admin point of view. In the below WBS from Figure 2, we have used admin’s

point of view.

30
 Figure 2 Work Breakdown Structure for PMS application

Once we have a clear understanding of the use cases, we can create UML diagrams

depicting the interactions and dependencies between these components. These diagrams

serve as a blueprint for both monolithic and microservice architectures, guiding the

development process toward a robust and scalable system design.

Steps followed in this methodology to derive a monolithic and microservice architecture:

1. Identifying use cases using the WBS

2. Grouping the Use Cases which are related to a specific subsystem.

The below steps are followed for each use case:

a) Providing Use Case Description

b) Create an Activity Diagram for the use case.

c) Create a Sequence Diagram

31
 d) Create a Detailed Sequence Diagram

e) Create a Domain Class Diagram

f) Create a Package Diagram

3.1 Background

The Farm Produce Procurement and Sales System (PMS) is mainly for Plantations with

the goals of enhancing the efficiency of the crop purchasing and selling process and

improving the overall effectiveness of the activities linked to Plantation. PMS is a service-

based platform that enables users to locate professionals that offer services at plantations,

as well as professionals who provide services such as product procurement and product

sales. This platform offers the chance for freelance professionals to become microservice

entrepreneurs for the PMS platform by selling their services as products and the agricultural

goods they have bought. The proposed PMS can easily be defined as an integrated approach

for managing e-commerce-related tasks and workforce management-related tasks.

Many independent e-commerce applications provide services for procuring and selling

farm produce in the market, which differs from the proposed PMS application. PMS can

be used for complete plantation needs such as procurement, sales, workforce management,

and so on.

3.2 Requirement Gathering with Use Cases

The Word use case has been used in multiple ways by software development personnel,

assigning various meanings such as an example, function, or instance of system use. One

32
of the early books on use cases [22] with some specific notations for describing use cases.

In our approach, we ensure manual processes are not represented as use cases, and each

use case has at least appropriate inputs/outputs in forms, screens, or report formats. We

derived entities for these inputs and made them a part of the use case.

The term "Procurement System" refers to an e-commerce system that was taken into

account as part of our modeling. This system buys goods directly from producers, such as

farm produce and other artifacts, and then sells them to wholesalers. The top-down

decomposition may include the following few subsystems/tasks:

• P11 Create Producer Account.

• P12 Get Produce Details.

• P21 Get Produce Availability.

• P22 Place Procurement Order.

• P31 Get Sales order.

• P32 Get Payment for Sales.

• P33 Deliver Produce to Buyer.

These can be partitioned to use cases. The following naming convention has been used to

understand better and relate it with the use case. The naming convention used in this

document is as follows:

• Name for Use case diagram: P1, P2, etc.

• Use case description: P11, P12, etc.

• Activity Diagram for P11: P11A1, P11A2, etc.

33
 • Input screens for P11: P11I1, P11I2, etc.

• Output screens for P11: P11O1, P11O2, etc.

• Entities for P11: P11E1, P11E2, etc. (Normalize the entities with the repeating

groups)

• System Sequence Diagram for P11: P11SSD1, P11SSD2, etc.

• Class Diagram for P11: P11C1, P11C2, etc.

The first two use cases related to the Producer, which consist of registering the Producer,

providing produce availability are shown in Figure 3. Each use case will consist of the

following:

a) Use case description.

b) Input/output screens, forms/reports.

c) Activity diagram.

d) Entity table for input/output entities

e) ER-diagram.

f) SSD (System Sequence Diagram)

This use case diagram can be used to identify which actor is associated with the selected

use cases. Here we have considered the common use cases related to the Producer. The

three selected use cases below are the main functionalities the Producer can perform.

34
 Figure 3 Use case diagram for P1 - Get Producer Data.

a) Use Case Description:

A use case description is a textual representation of the steps and interactions involved in

a particular use case. It explains how the system will behave when the user or actor

performs a specific action. The use case description for creating a producer account would

include entering personal information and providing produce information. It also specifies

the information related to the actors involved in the use case, such as the Producer and

other relevant stakeholders.

In the use case description shown below in Figure 4, the activities flow has been

incorporated to easily identify what data needs to be exchanged while performing this

functionality. Additionally, the use case description may outline any necessary validations

or constraints to be considered during the account creation process.

35
 Figure 4 Use case description for P11 – Create Producer Account.

b) Input/Output Screens:

The input screens for creating a producer account typically include fields for entering

personal information such as name, address, contact details, and possibly identification

documents. The user would also be prompted to provide specific product information, such

as the type of crops they specialize in.

36
 Figure 5 Input Screen for P11I1 – Register Producer Account

The output screens would then confirm the successful creation of the account and provide

the Producer with their unique login credentials. It may also display any additional steps

or requirements that must be completed before the account can be fully activated. This

provides the Producer with a clear understanding of the necessary information and steps to

use the account.

37
 Figure 6 Output Screen for P11I2 - Producer Information.

c) Activity diagram:

The activity diagram would illustrate the actions involved in creating a producer account.

It would show the steps of inputting personal information, selecting the type of crops, and

confirming the successful creation of the account. Additionally, it may depict any

additional steps or requirements that need to be completed before the account can be fully

activated, such as verifying email or completing a registration form. This visual

representation helps to simplify and streamline the account creation process for producers.

38
 Figure 7 Activity Diagram for P11A1 – Producer Information

d) Entities table for input/output entities:

Mapping entities using the Input/output Diagram (I/O Diagram) is a visual representation

that shows the flow of data between different entities within a system. It helps to identify

the inputs and outputs of each entity, allowing for a better understanding of how

information is exchanged and processed. By mapping entities using an I/O diagram,

producers can easily identify the necessary inputs for their account creation process and

ensure that all required information is provided. Based on the Input/output screen, the

derived entity table is shown below in Table 1. In this entity table, the initial dependencies

are identified, and we perform normalization to eliminate any redundant data and improve

the system's overall efficiency. This process involves breaking down the entity table into

smaller, more manageable tables, each representing a distinct entity with its attributes.
39
 Table 1 Entity Table for P11E1 – Producer Account and Produce Details

Entity: producerAccount = producerID + govtID + lastName + firstName +

P11E1 MI + address1 + address2 + city + state + postalCode + country +

mobilePhone + email + date + verifiedBy

Entity: produceDetails = producerID + govtID + lastName + {produceType +

produceName + quantityByWeight + pricePerUnitWeight +
P11E2 availabilityDate + availableLocation}

3rd NF:

producerProduce = producerID + govtID + lastName + produceID

produce = producerID + produceID + produceType + produceName +
quantityByWeight + pricePerUnitWeight + availabilityDate +
availableLocation

e) ER-diagram:

Using the entity table as a starting point, the normalization process involves identifying the

functional dependencies between attributes and determining the appropriate table structure.

This ensures that each table is focused on a specific entity and its related attributes,

promoting data integrity, and reducing update anomalies. Furthermore, normalization helps

optimize storage space by eliminating redundant data, resulting in improved performance

and easier database system maintenance. Later ER diagram is created to represent the

relationships between the entities in the database visually. This diagram provides a clear

overview of how different tables are connected and allows for easier understanding and

analysis of the database structure. Additionally, the ER diagram serves as a blueprint for
40
designing and implementing the database system, making it an essential tool in database

development.

Figure 8 ER-Diagram for P11ER1 – Producer Account and Produce Details

41
f) System Sequence Diagram:

A system sequence diagram (SSD) is another important tool to illustrate the flow of

interactions between the system and external actors, helping to identify the necessary inputs

and outputs for each system function. This is the starting point for object-oriented analysis

and design. From this point onwards, domain classes are identified for each use case. The

domain class attributes and methods are further verified with an informal approach using

Class Responsibility Collaboration (CRC) cards or a formal approach by drawing a

Detailed Sequence Diagram (DSD).

Figure 9 System Sequence Diagram for P11SSD1 – Create producer Account

42
 Figure 10 Class Diagram For P11DCD1 – Producer Account and Producer Details

Detailed Sequence Diagram shows the specific sequence of events and interactions

between different objects or components in a system. We can be used to visualize the flow

of control and data between various components, helping us identify potential bottlenecks

or areas for optimization. It can also be used as a communication tool between developers

and stakeholders, ensuring a shared understanding of system behavior and functionality.

43
 Figure 11 Detailed Sequence Diagram For P11DSD1 – Producer Account and Producer Details

We can derive the package structure and class diagrams from the use case realization,

which provides a high-level overview of the system's architecture and the relationships

between different modules. These diagrams help us identify the key components and their

interactions, allowing us to design and implement the system more effectively.

Additionally, they can serve as documentation for future maintenance and enhancements,

making it easier for new developers to understand the system's structure and make changes

if needed. This package diagram is a project in MVT architecture, which stands for Model-

View-Template. It illustrates how the system's components are organized into three main

layers: the model layer, responsible for managing data and business logic; the view layer,

responsible for presenting information to users; and the template layer, responsible for

generating dynamic web pages. This can serve as an individual service or as part of a larger

system, allowing developers to easily integrate and customize the functionality based on
44
their specific requirements. This can be considered a microservice, as other use cases have

no functional dependencies. The only common requirement is that the microservice must

be able to communicate with other services through APIs or messaging protocols.

Figure 12 Package Diagram P11PD1 - Producer Microservice

3.3 Designing Microservice Architecture for PMS Application.

The package diagram derived from the use case realization of the Producer provides a

visual representation of the different components in the MVT (Model View Template)
45
pattern. It helps to illustrate how the subsystem is organized and how the different modules

or packages interact. This package diagram can be considered a microservice as it

encapsulates a specific functionality within the larger system. It allows for independent

deployment and scalability, making it easier to maintain and update the producer account

subsystem without affecting other parts of the system. Providing a common database for

this producer subsystem, the package diagram ensures that data is shared and consistent

across all modules. Additionally, it allows for efficient communication between different

components by defining clear interfaces and dependencies.

Figure 13 Microservice for Producer Service

This producer microservice is independent and can be deployed and scaled separately from

other system components. It is designed to handle specific tasks related to Managing

producer profiles, such as creating and updating producer information, providing produce
46
information such as available produce name, type, quantity, price, available date, and

requesting payment for the Produce available.

Like the Producer, the order microservice manages and processes vendor orders. It

communicates with the producer microservice through an API gateway to retrieve

necessary information about the products and their availability.

In the below architecture diagram from Figure 14, Each microservice is derived from the

use case realization as followed in Chapter 3.4 for the producer account. Containerizing

each package with an individual database, as shown below, can act as an independent

service. There is a need for a common API gateway to handle the communication between

these microservices and external clients. This API gateway will provide a unified interface

for clients to access the functionalities of different microservices, ensuring seamless

integration and scalability of the overall system.

When users access the system, they will interact with the API gateway, which will route

their requests to the appropriate microservice. This allows for a simplified and streamlined

user experience, as they only need to interact with one interface instead of multiple

individual services. The API gateway can also handle authentication and authorization,

ensuring that only authorized users can access the system's functionalities.

47
 Figure 14 Overall Architecture Diagram for PMS Application

3.4 Comparison of Monolithic and Microservice Architecture

Table 2 Comparison of Monolithic and Microservice Architecture

Monolithic Architecture Microservice Architecture

Tightly coupled system. Independent development, deployment,
and maintenance of components.
Scaling as a whole. Independent scaling of individual
components based on demand.
Limited flexibility and extensibility due to Greater flexibility and extensibility to add,
tight coupling. modify, or replace microservices without
impacting the entire system.
Relies on a single deployment. Ability to deploy individual microservice
in different environments (e.g., mobile,
cloud, web).
Complex management and maintenance Simplified management and maintenance
due to interconnected components. with decentralized teams responsible for
specific microservices.
48
3.5 Comparison of general approach and our approach for designing microservices

Table 3 Comparison of general approach and our approach for designing microservices.

Design Approach General Approach Proposed Approach

Design Various methodologies can be used Using use cases and UML

Methodologies such as domain-driven design,

reactive design, API first approach,

etc.

Emphasis Emphasizes high-level Emphasizes capturing

architectural considerations and functional requirements

principles and visualizing system

structure and interactions.

Communication Communication between the teams Communication and

and Collaboration may rely on verbal and written collaboration through

communication (user stories), visual representation of the

documentation and architectural system using use cases,

diagrams. UML diagram and ER-

diagrams.

Granularity Microservices boundaries may not Microservice boundaries

be defined clearly, or it may not be are clearly defined based on

consistent. use cases and functional

requirements.

49
Design Artifacts Design artifacts may vary based on UML diagrams such as use

the methodology chosen. Common case diagram, input/output

artifacts that are used include screens, system sequence

architecture diagram. diagram, domain class

diagram, sequence

diagram, and ER-diagram.

System Only provides high-level Provides a more detailed

Understanding understanding of the system and comprehensive

and functionality and components. understanding of system

Documentation functionalities and help in

better documentation which

helps during up scaling the

application.

Maintenance and May require additional effort and Facilitates maintenance and

Upgrades planning for maintenance as the upgrades through clear and

documented consist only high-level detailed documentation.

information.

50
 CHAPTER 4

IMPLEMENTATION

As described before, there are several tools and techniques that support application

development using microservice architecture. These tools include Python Django, Java

Spring Boot, Node.js Express, etc. These frameworks provide developers with the tools

and libraries to build and deploy microservices efficiently. Additionally, these tools offer

scalability, fault tolerance, and easy integration with other services, making them ideal for

developing complex applications in a distributed environment. Some advanced tools are

also available, such as Kubernetes and Docker, which help manage and orchestrate

microservices at scale. These tools enable developers to easily deploy, scale, and manage

their microservices in a containerized environment, ensuring high availability and efficient

resource utilization.

There are a lot of concerns during the tool selection that developers need to consider. One

of the main concerns is the compatibility and integration of these tools with existing

infrastructure and technologies. It is important to ensure that the selected tools can

seamlessly work with other application stack components. Developers should also evaluate

the learning curve and support available for these tools, as well as their community

adoption and active development. By carefully considering these concerns, developers can

make informed decisions and choose the most suitable tools for their microservices

architecture. There should also be careful consideration of some aspects, such as the

increased complexity of debugging and monitoring multiple services and the potential for

increased network latency due to communication between services. Additionally, ensuring

51
data consistency and maintaining security across multiple microservices can be

challenging. However, with proper planning and implementation of best practices, these

concerns can be mitigated, allowing organizations to leverage the benefits of microservices

architecture fully.

Considering the communication of microservices, we should evaluate the performance and

scalability of the selected tools. It is crucial to choose tools that can efficiently handle high

volumes of data and requests and support various communication protocols such as HTTP,

TCP, or messaging queues. Additionally, we should consider the security features offered

by these tools to ensure the confidentiality and integrity of data exchanged between

microservices.

API design and documentation is another important aspect to consider in microservices

architecture. We should carefully design and document APIs to ensure clear

communication and interoperability between different microservices. This includes

defining the endpoints, request/response formats, authentication mechanisms, and error-

handling strategies. Well-designed APIs can greatly enhance the usability and

maintainability of a microservices-based system.

4.1 Technology

For implementing the Procurement Management System, we have opted Python Django

framework as it is suitable for Microservice architecture and provides a robust and scalable

solution. Additionally, Django's built-in features, such as authentication, database

management, and template engine, make it easier to develop and maintain the system. We
52
use PostgreSQL as our database management system, offering advanced features and

strong data integrity. This combination of Python Django and PostgreSQL ensures efficient

data storage and retrieval, enhancing the overall performance of the Procurement

Management System.

4.3 Environment Setup

To set up the environment required for developing a Procurement Management System

using the Python Django framework. Start by installing Python, which can be downloaded

from the official Python website. Once Python is installed, installing the Django framework

is a straightforward process. To install Django by running the command "pip install

Django" in the terminal or command prompt using the package installer (pip command).

Additionally, using a virtual environment to isolate the project's dependencies and avoid

conflicts with other Python projects is recommended. This will ensure that all the necessary

packages and dependencies are installed correctly for your project.

For PostgreSQL, you will need to download and install PostgreSQL on your machine. Once

installed, you can configure Django to use PostgreSQL as the database backend by

updating the settings.py file in your Django project. This will allow you to take advantage

of PostgreSQL's advanced features and performance for your project.

4.4 Project Setup

As we are developing applications from scratch, we will need to create a new Django

project by running the command "Django-admin start project PMSapplication" in the

53
terminal. This will generate your project's necessary files and folders, as shown in Figure

15. You can also create a virtual environment to isolate your project's dependencies and

ensure a clean development environment.

Figure 15 Project Structure

Once the project is created and the necessary files and folders are generated, you can

configure the database settings in the project's settings.py file, as shown in Figure 16. This

includes specifying PostgreSQL as the database engine and providing the database name,

username, password, and host information, as shown in Figure 17. By utilizing

PostgreSQL's advanced features, such as support for JSON data types and full-text search

capabilities, you can enhance the functionality and performance of your application.

54
 Figure 16 Database Information in environment file

Figure 17 Database setup in Django project

4.5 Implementation

Considering the methodology from Chapter 3, we have to create three microservices for

our application: user, product, and order management. Here we have created 3 Django apps

for each microservice. Each app will have its models, views, and serializers to handle the

specific functionality of that microservice. Separating the application into these smaller

services can achieve better scalability and maintainability.

55
The database schema for each microservice has been derived during the design phase,

ensuring each service has tables and relationships that align with its specific functionality.

Attributes for each database are derived based on the functionality of the service, as

mentioned in the entity table, and those attributes will be used in model classes to represent

the data in the microservice, as shown in Figure 18. This ensures that each microservice

has its isolated data storage and can operate independently.

Figure 18 Model class for Produce

serializers.py as shown in Figure 19, should be created in the Django project, this file helps

us to convert the native datatypes used in the models.py file to python datatypes. By

converting the native datatypes to python datatypes that can be easily rendered into any

content types such as XML, JSON, or any other. These content types can be used with

GET, POST, PUT, PATCH, DELETE, HEAD methods of API functionality. After creating

56
serializers.py we must create an API view in the views.py file as shown in Figure 20. Now,

url.py as shown in Figure 21 should be created to define the routes and map them to the

corresponding functions or views. This file will handle incoming requests and direct them

to the appropriate endpoints within the microservice. It is important to properly document

these endpoints and their functionality to facilitate integration with other services or clients.

Additionally, testing should be conducted to ensure that the API endpoints are functioning

correctly and providing the expected responses.

Figure 19 serializers.py for converting model data types to python native datatypes.

Figure 20 Creating API view in views.py.

Input for the API endpoints should include the parameters and data required for each

endpoint. This information can be provided through query parameters, request headers, or

request bodies, depending on the requirements of the endpoint. It is also important to

57
consider authentication and authorization mechanisms to secure the API endpoints and

restrict access to authorized users or clients. We can test the created API using tools like

Postman or we can also test it using CURL, Python terminal, etc. Here to test the API

Postman tool is used as shown in Figure 21. Django admin panel can be used to manage

and monitor the API endpoints, as shown in Figure 22, allowing administrators to perform

tasks such as creating, updating, and deleting data. Additionally, logging and error handling

should be implemented to track and handle any issues that may arise during API endpoint

usage.\

Figure 21 Testing API using Postman tool.

58
 Figure 22 Django admin panel

After creating the Model, view, and API endpoints, we must create templates for rendering

the data in a user-friendly format. These templates can be customized to match the design

and branding of the application, providing a seamless user experience. Additionally, client-

side validation can be implemented to ensure that any data entered by users through the

templates is valid and meets the required criteria. This will help prevent any potential errors

or inconsistencies in the submitted data. These templates are placed within the front-end

framework of the application, allowing for easy integration and dynamic rendering of the

data. By utilizing these templates, developers can save time and effort in designing and

formatting the data presentation and ensure a consistent and visually appealing user

interface.

Moreover, regular updates and improvements to these templates can be made without

affecting the underlying functionality of the application, providing flexibility for future

enhancements. The outcome after developing the user interface is shown in Figure 23 and

Figure 24. This application can be viewed and tested in real-time, allowing developers to

make any necessary adjustments or modifications before deployment. This allows for a
59
seamless and efficient development process, resulting in a polished and user-friendly

interface that meets the needs and expectations of the end-users.

Figure 23 Final output for Providing Produce Details

Figure 24 Final Output for Producer.

60
 CHAPTER 5

SUMMARY AND FUTURE WORKS

As discussed in the earlier chapters, various methods, and approaches such as domain-

driven approach, event-driven approach, greenfield approach, brownfield approach and

many others can be used to design a microservice architecture. Each of these approaches

has its own advantages and considerations, focusing on different aspects of microservice

design. Through the analysis of these approaches and methodologies, it is evident that there

is no universal solution that can be applied to all cases when it comes to designing

microservices. It requires careful evaluation of specific requirements and business

objectives to determine the most suitable methodology for designing microservices.

In the literature review, we have discussed about few approaches that are similar to the

methodology provided in this thesis such as greenfield approach, brownfield approach

from the paper titled "GreenMicro: Identifying Microservices from Use Cases in

Greenfield Development" [23]. This paper has provided an overview of a methodology that

utilizes use cases for identifying microservices in greenfield development. While the paper

offers valuable insights into the general approach for designing microservices using unique

functionality of the use cases, it does not explore into the specific details of the

methodology.

Similarly, there are other papers such as [24] that discuss methodologies using functional

decomposition UML for designing microservices. This approach involves the 4SRS (Four

Step Rule Set) method consists of component creation, component elimination, component

61
packaging, and component association. However, the method described in this paper

provides a high-level perspective and does not provide a step-by-step or in-depth

explanation on how this proposed methodology can be applied to derive a microservice

architecture.

In contrast to these approaches, this thesis has provided a comprehensive approach by

elaborating on the methodology and providing a detailed, step-by-step explanation. The

thesis specifically focuses on a use case related to PMS application, providing a practical

example that enhances the understanding and applicability of the methodology.

The proposed methodology in thesis is described in thorough and detailed manner using

use cases, input/output screen, forms, or report, activity diagram, system sequence diagram,

detailed sequence diagram, domain class diagram, ER-diagram, and package diagram. This

approach starts by considering the work breakdown structure which shows decomposition

of the system into smaller components. This decomposition allows us to identify the

different use cases and their relationships within the system. By deriving/defining use cases

from WBS it is ensured that each use case consists of appropriate input/output screens,

form, or report. This leads to an appropriate data entity incorporated with each use case.

For each use case we also the design process that involves deriving design classes through

the analysis of system sequence diagrams and packaging these classes into a three-tier

architecture consisting of presentation, business logic, and data access layers.

Furthermore, the thorough examination of all packages for their suitability for

microservices ensures that the resulting system aligns with the fundamental principles of

62
microservice design. This includes considerations such as loose coupling, service

autonomy, and scalability. A similar approach can also be used for designing monolithic

architecture by tight coupling of the derived packages into a single component.

This approach not only ensures the successful implementation of the microservices but also

enhances the overall understanding and documentation of the system. It enables effective

communication between developers, facilitates future enhancements or modifications, and

supports the scalability and maintainability of the PMS microservice architecture.

The implementation of the Procurement Management System (PMS) microservices using

Python Django has been partially carried. The development process involved translating

the designed microservice architecture, which incorporated use cases, domain classes, and

system sequence diagrams, into functional code by using Django framework. The

implementation consists of the two microservices product service, purchase service.

Django's robust features and capabilities, such as its ORM (Object-Relational Mapping)

and built-in authentication system, have greatly facilitated the development process. By

implementing the microservices using Python Django, the system has benefited from the

language's versatility, robustness, and extensive libraries and frameworks.

Throughout the implementation, careful attention was given to adhering to the principles

of microservice design, such as loose coupling and service autonomy. Each microservice

was developed as an independent module with interfaces, enabling seamless

communication and scalability.

63
In future work, there are several areas that can be explored to enhance the derived

microservice architecture and extend its applicability to other domains. Firstly, deriving

packages for other use cases of PMS application can help to identify common patterns and

functionalities that can be reused across different microservices. This would promote code

reusability and facilitate the development of new microservices by using existing

components. Additionally, conducting a thorough analysis of dependencies and

interdependencies between microservices could help optimize the system's overall

performance and scalability.

Secondly, focusing on a detailed implementation phase would be beneficial. This involves

exploring into the implementation specifics of each microservice, such as selecting

appropriate programming languages, frameworks, and tools to build and deploy the

microservices. Detailed research should be done on the important aspects such as security

measures, data storage and retrieval, and communication protocols to ensure the robustness

and reliability of the system.

Deployment strategies also deserve attention in future work. Exploring containerization

technologies like Docker and orchestration frameworks like Kubernetes could facilitate the

deployment and management of microservices in a scalable and efficient manner. This

would enable seamless scaling and handling of high loads, ensuring the system's

responsiveness and availability.

Furthermore, evaluating the proposed approach in comparison with other existing

approaches for microservice architecture design would be valuable. Conducting

64
comparative studies with alternative methodologies, such as domain-driven design (DDD),

or API-first approach, would provide insights into the strengths and weaknesses of each

approach and their applicability to different contexts. Comparative evaluations could focus

on factors such as development time, maintainability, performance, and scalability to

determine the most suitable approach for different use cases.

Additionally, gathering feedback and insights from other practitioners who have

implemented similar microservice architectures would provide valuable real-world

perspectives. Collaborating with organizations that have adopted microservices and

collecting data on their experiences, challenges, and lessons learned would further enrich

the understanding and applicability of the proposed approach.

65
 BIBLIOGRAPHY

[1] Lewis, J., & Fowler, M. (2014, March 25). Microservices. martinfowler.com.

https://martinfowler.com/articles/microservices.html

[2] Jamshidi, P., Pahl, C., Mendonça, N. C., Lewis, J., & Tilkov, S. (2018). Microservices:

The journey so far and challenges ahead. IEEE Software, 35(3), 24-35.

[3] Fowler, M. (2014, January 15). bliki: BoundedContext. martinfowler.com.

https://martinfowler.com/bliki/BoundedContext.html

[4] Carneiro Jr, C., Schmelmer, T., Carneiro, C., & Schmelmer, T. (2016). Microservices:

The what and the why. Microservices From Day One: Build robust and scalable software

from the start, 3-18.

[5] Dragoni, N., Giallorenzo, S., Lafuente, A. L., Mazzara, M., Montesi, F., Mustafin, R.,

& Safina, L. (2017). Microservices: yesterday, today, and tomorrow. Present and ulterior

software engineering, 195-216.

[6] Yin, K., & Du, Q. (2021). On representing resilience requirements of microservice

architecture systems. International Journal of Software Engineering and Knowledge

Engineering, 31(06), 863-888.

[7] Villamizar, M., Garcés, O., Castro, H., Verano, M., Salamanca, L., Casallas, R., & Gil,

S. (2015, September). Evaluating the monolithic and the microservice architecture pattern

66
to deploy web applications in the cloud. In 2015 10th Computing Colombian Conference

(10CCC) (pp. 583-590). IEEE.

[8] Montesi, F., & Weber, J. (2016). Circuit breakers, discovery, and API gateways in

microservices. arXiv preprint arXiv:1609.05830.

[9] Tonse, S. (2018). Scalable microservices at Netflix. challenges and tools of the trade.

[10] Vučković, J. (2020). You are not netflix. Microservices: Science and Engineering,

333-346.

[11] Fowler, S. J. (2016). Production-ready microservices: building standardized systems

across an engineering organization. " O'Reilly Media, Inc.".

[12] Shkuro, Y. (2019). Mastering Distributed Tracing: Analyzing performance in

microservices and complex systems. Packt Publishing Ltd.

[13] Aksakalli, I. K., Celik, T., Can, A. B., & Tekinerdogan, B. (2021). Systematic

approach for generation of feasible deployment alternatives for microservices. IEEE

Access, 9, 29505-29529.

[14] Papazoglou, M. P., & Van Den Heuvel, W. J. (2006). Service-oriented design and

development methodology. International Journal of Web Engineering and Technology,

2(4), 412-442.

[15] Hasselbring, W. (2018). Software architecture: Past, present, future. The Essence of

Software Engineering, 169-184.

67
[16] Kreger, H. (2001). Web services conceptual architecture (WSCA 1.0). IBM software

group, 5(1), 6-7.

[17] Wei, Y., & Blake, M. B. (2010). Service-oriented computing and cloud computing:

Challenges and opportunities. IEEE Internet Computing, 14(6), 72-75.

[18] Valipour, M. H., AmirZafari, B., Maleki, K. N., & Daneshpour, N. (2009, August). A

brief survey of software architecture concepts and service oriented architecture. In 2009

2nd IEEE International Conference on Computer Science and Information Technology (pp.

34-38). IEEE.

[19] Kwan, A., Jacobsen, H. A., Chan, A., & Samoojh, S. (2016, October). Microservices

in the modern software world. In Proceedings of the 26th Annual International Conference

on Computer Science and Software Engineering (pp. 297-299).

[20] M. Hilbrich and F. Lehmann, "Discussing Microservices: Definitions, Pitfalls, and

their Relations," 2022 IEEE International Conference on Services Computing (SCC),

Barcelona, Spain, 2022, pp. 39-44, doi: 10.1109/SCC55611.2022.00019.

[21] Fairley, R. E. (2011). Managing and leading software projects. John Wiley & Sons.

[22] Cockburn, A. (2001). Writing Effective Use Cases. Germany: Addison-Wesley.

[23] Bajaj, D., Goel, A., & Gupta, S. C. (2022). GreenMicro: Identifying Microservices

From Use Cases in Greenfield Development. IEEE Access, 10, 67008-67018.

68
[24] Santos, N., Salgado, C. E., Morais, F., Melo, M., Silva, S., Martins, R., ... & Pereira,

M. (2019, September). A logical architecture design method for microservices

architectures. In Proceedings of the 13th European Conference on Software Architecture-

Volume 2 (pp. 145-151).

69