Studying and applying model driven architecture in software development Nghiên cứu và ứng dụng kiến trúc hướng mô hình trong phát triển phần mềm
INTRODUCTION
Research background
In today's fast-paced technological landscape, software plays a crucial role in driving business growth and maintaining a competitive advantage It serves as the backbone of diverse operations, boosting efficiency and fostering innovation This importance is not limited to the private sector; for governments, software development is essential for national economic advancement and enhancing citizens' quality of life.
The impact of software on modern business practices is immense, facilitating daily operations and strategic decision-making As companies aim to meet market demands and technological advancements, dependable software solutions are essential However, developing such software involves significant complexity, requiring considerable investments of time, money, and human resources, along with the risk of project failure Therefore, it is crucial to implement effective methodologies to streamline the development process and minimize risks.
Model-Driven Architecture (MDA), introduced by the Object Management Group (OMG) in 2001, offers a promising solution to streamline and improve the software development process By emphasizing high-level models and abstract representations, MDA simplifies the transition from conceptual designs to executable applications, effectively tackling the challenges faced in traditional software development.
Objectives of the research
The main objectives of this research are threefold:
Identify Patterns in Model-Driven Architecture: To explore the various patterns inherent in MDA and understand their roles and applications in software development
Study Object-Oriented Analysis and Design Methods: To delve into the methodologies of object-oriented analysis and design as applied within the framework of model-driven architecture
Apply These Methods to Real Systems: To practically implement the learned methods and theories in the development of a real-world system, specifically in the context of a garment company
This research aims to bridge the gap between theoretical models and practical applications, demonstrating how MDA can be leveraged to create efficient, reliable, and scalable software solutions.
Scope and limitations of the research
This research focuses on the Model-Driven Architecture (MDA) approach, a sophisticated method for application software development established by the Object Management Group (OMG) MDA highlights the importance of modeling in software development, promoting a structured approach that improves portability, cross-functionality, and reusability These objectives are accomplished by separating concerns and utilizing distinct models at different stages of the development process.
Key components of MDA include:
Computation Independent Model (CIM): This model captures the system's requirements and functionalities without delving into computational details
Platform Independent Model (PIM): This model represents the system's architecture, abstracting away platform-specific details to ensure flexibility and adaptability
Platform Specific Model (PSM): This model incorporates platform-specific information, providing a concrete blueprint for implementation on a specific technology stack
This research offers an in-depth analysis of models and transformations related to MDA, focusing on their practical application for creating a real system within a garment company It seeks to enhance understanding of MDA's implementation while acknowledging potential challenges, such as resource availability and the intricacies of accurately modeling every facet of a real-world system.
This research aims to enhance software development practices by addressing key objectives and limitations, providing valuable insights and practical solutions for practitioners and organizations By leveraging Model-Driven Architecture, the study contributes to the broader field of software development, helping to improve development processes effectively.
LITERATURE REVIEW
Application model
An application architecture serves as a blueprint outlining the organization of a software application and its interconnections to fulfill either business or user needs
It plays a crucial role in guaranteeing scalability and reliability while aiding enterprises in identifying any functional deficiencies
Application architecture defines how applications interact with components such as middleware, databases, and other applications Although these architectures generally follow established software design principles, they often do not conform to formal industry standards.
Application architecture outlines the design patterns and techniques used in developing an application, providing a roadmap and best practices for creating a well-structured solution By utilizing software design patterns, developers can implement reusable solutions to common challenges, ensuring efficient and effective application development.
Effective application development relies on a solid architectural framework, but it also requires careful implementation decisions that may not be clearly defined To achieve a well-structured application architecture, developers often utilize various software development patterns, including domain-driven architecture, model-driven architecture, event-driven architecture, and microservices.
Model-Driven Architecture (MDA) emphasizes the development of abstract models that can be converted into executable code, aiming to decouple the specification of system functionality from its implementation on specific technology platforms Utilizing high-level models, often represented in UML, MDA defines the system's structure and behavior, enabling automatic transformation into code suitable for various platforms.
Domain-Driven Design (DDD) is a software development methodology that prioritizes a thorough understanding of the business domain, allowing for effective modeling within the software It fosters collaboration between technical experts and domain specialists to develop a comprehensive domain model that accurately represents the underlying business logic.
EDA is a design paradigm where the flow of the system is determined by events
An event is a significant change in state, and the architecture is designed to detect, capture, and respond to these events EDA promotes loose coupling and asynchronous communication between components
Microservices architecture divides a system into small, autonomous services that can be developed, deployed, and scaled independently Each microservice focuses on a specific business function and interacts with others via clearly defined APIs.
MDA Focuses on high-level models and abstracting system functionality from platform-specific details
DDD Focuses on creating a rich domain model closely aligned with business logic
EDA Focuses on the flow of events and the asynchronous communication between loosely coupled components
Microservices Focuses on breaking down the system into small, independently deployable services
MDA Relies heavily on automated tools for model transformation and code generation
DDD Relies on deep collaboration between domain experts and developers to build a robust domain model
EDA Relies on detecting and responding to events to drive the system's behavior
Microservices Relies on independent development and deployment cycles for each service, often using CI/CD pipelines
MDA depends on the ability to manage and transform models efficiently
Long-term maintenance requires keeping models and generated code in sync
DDD is managed through bounded contexts Maintenance focuses on evolving the domain model and keeping it aligned with business changes
EDA is achieved through asynchronous event processing and loose coupling Maintenance involves managing event schemas and ensuring backward compatibility
Microservices straightforward as each service can be scaled independently
Maintenance involves managing the dependencies and communication between services
MDA provides flexibility with platform-independent models, though it may be limited by the capabilities of modeling and transformation tools DDD is highly adaptable to business changes thanks to its emphasis on the domain model, but it can introduce complexity in large systems EDA offers significant flexibility through loose coupling and asynchronous communication, yet it necessitates careful management of event flows and state.
Microservices Highly flexible and adaptable, allowing teams to innovate and deploy independently, but requires robust inter-service communication and monitoring
Table 2.1 Comparison MDA with other software development methodologies
When comparing Model-Driven Architecture (MDA) with Domain-Driven Design (DDD), Event-Driven Architecture (EDA), and Microservices, it's evident that each methodology offers unique advantages for specific scenarios MDA is particularly effective in environments that prioritize high-level abstraction and platform independence DDD shines in complex business domains that require a strong alignment between business logic and software design EDA is advantageous for systems that demand responsiveness and scalability through event-driven interactions Meanwhile, Microservices are optimal for architectures that benefit from the independent deployment and scaling of distinct functionalities.
Reasons to choose MDA over other models:
- General and flexible approach: MDA provides a more general and flexible software development approach compared to other models This allows for easy adaptation to complex requirements and development environments
MDA significantly enhances software development efficiency through high automation and robust reuse capabilities By automatically generating code from models, MDA minimizes the time and effort needed for development Furthermore, its strong reuse features boost productivity and promote consistency in both software design and deployment.
- Clean, maintainable architectures: MDA helps create clean, maintainable application architectures by separating models from code This makes it easier to understand and maintain the system over the long term
MDA is highly regarded for its adaptability and automation features, which foster clean and maintainable architectures by separating models from code These advantages position MDA as the perfect solution for my project, promoting efficient development, enhanced productivity, and sustainable system management over time.
Overview of MDA
MDA, or Model Driven Architecture, is an international standard established by the Object Management Group (OMG) that emphasizes a model-based approach to software development Its primary goal is to enhance consistency across software projects and minimize discrepancies between various platforms MDA categorizes system specification models from high-level abstractions to detailed representations, offering transformation rules that facilitate the conversion between different models.
Figure 1 Architecture of model-driven architecture [2]
MDA-driven development offers significant advantages by enabling the creation of applications across various middleware platforms directly from a base model, thereby reducing issues that may arise during the development process, particularly during the transition from Platform Independent Models (PIM) to Platform Specific Models (PSM) By utilizing support tools and code templates, MDA minimizes manual coding errors and enhances the viability of the software product Central to MDA is the emphasis on modeling, which abstracts and represents different facets of a software system, facilitating the achievement of critical development goals.
Model-Driven Architecture (MDA) allows developers to concentrate on high-level design concepts instead of getting lost in implementation specifics By generating models that illustrate various perspectives of the system, MDA helps to simplify complexities and enhances communication among diverse stakeholders.
One significant benefit of Model-Driven Architecture (MDA) is its capacity to decouple system functionality from the underlying technology platform This platform independence enables developers to construct models that outline the system's behavior and structure in a technology-agnostic manner, facilitating the transformation of these models into specific implementations tailored to various platforms as required.
MDA enhances software development by promoting the reuse of standardized models and transformations, allowing developers to create libraries of reusable components that can be integrated into various projects Furthermore, it fosters interoperability by establishing a common framework for the integration of diverse systems and components, streamlining the development process and improving efficiency.
Model-Driven Architecture (MDA) streamlines the automation of development tasks by utilizing model transformations By establishing rules and mappings across different abstraction levels, MDA enables developers to automatically generate code, configuration files, and other essential artifacts from higher-level models This process significantly reduces manual coding efforts and minimizes the potential for errors.
Model-Driven Architecture (MDA) improves system adaptability by decoupling system specifications from implementation details This approach allows developers to update and maintain systems throughout their lifecycle by modifying models instead of directly altering the code, ensuring the integrity and functionality of the system remain intact amidst changing requirements and technological advancements.
• CIM - Computation Independent Model represents the system at the business level
• PIM - Platform Independent Model describes system functions but is independent of the technology platforms that execute the system
• PSM - Platform Specific Model describes system functions according to a specific technology platform selected to implement the system
This process transitions from an abstract business model to a concrete design and implementation model, utilizing UML to effectively represent and model both business aspects and software system engineering.
Visual modeling
Visual modeling in software development involves utilizing specific languages and tools to create diagrams and models that effectively illustrate and communicate the structure, functionality, and interactions within software systems.
Visual modeling is crucial in software design, development, and deployment, as it enables development teams and stakeholders to easily and effectively understand and interact with the system.
Here are some common types of visual modeling in software development:
• Workflow Diagrams: Workflow diagrams describe the steps and processes in the system's working process It illustrates the interactions between components and workflows in the system
Class diagrams are essential for illustrating the architecture of a software system, showcasing classes, their properties, methods, and the relationships among them They provide a clear understanding of the system's structure and the interactions between its objects, making them a vital tool for software design and analysis.
• Sequence Diagrams: Sequence diagrams describe messages and interactions between objects over a time series It illustrates the activities and interactions during the implementation of a specific function of the system
• Activity Diagrams: Activity diagrams describe processes and activities in the system over time It helps to understand and visualize the workflow and processes in the system
• State Diagrams: State diagrams describe states and transitions between states in the system It helps understand and track the state of objects and how they change over time
Various diagrams and visual models are used to create a global and detailed view of the software system, making design, development and testing easier and more efficient.
Principles of visual modeling
Visual modeling has four basic principles as follows:
Visual modeling should prioritize simplicity and clarity, ensuring that it remains easy to understand By avoiding unnecessary complexity, the model helps prevent confusion among users, facilitating effective communication and comprehension among project members.
Visual modeling must be contextually appropriate and compatible with its intended use, adhering to established standards and rules within the relevant field By ensuring compliance with these standards, the model achieves consistency and enhances its potential for reusability.
Visual modeling should be designed to be intuitive and engaging, capturing user interest and encouraging interaction By incorporating colors, charts, images, and other visual elements, the model becomes more appealing and easier to comprehend.
Visual modeling should be flexible and scalable, enabling effortless adjustments in response to evolving requirements or systems Additionally, it must accommodate the integration of extra information and details as necessary, ensuring it remains effective and relevant.
The principles outlined ensure that visual modeling effectively conveys information, aligns with specific goals and contexts, appeals to users, and allows for easy adaptation and extension when necessary.
MODEL DRIVEN ARCHITECTURE
Models in MDA
3.1.1 The model is independent of the CIM calculation operation
The Computational Independent Model (CIM) is an important aspect of the Model-Driven Architecture (MDA) approach CIM represents a software model that is not directly related to specific computational operations
Figure 2 Computational Independent Model Concepts [3]
CIM emphasizes system specification in language that resonates with business professionals, resulting from collaborative efforts between business analysts and the end users of the system As such, CIM is often referred to as the scope model or business model.
3.1.2 Model independent of technology platform (PIM)
Platform Independent Model (PIM) is an important aspect of the Model Driven Architecture (MDA) approach PIM represents a software model that is not dependent on any particular technology platform [4]
PIM, or Platform Independent Model, emphasizes the logical and functional characteristics of a software application, independent of the deployment environment It generates an abstract model that outlines the software system's components, interfaces, processes, and data flows, providing a comprehensive overview.
3.1.3 The Platform Specific Model (PSM)
The Platform Specific Model (PSM) is an important part of the Model-Driven Architecture (MDA) approach PSM represents a software model created based on a specific technology platform [5]
PSM emphasizes the detailed characteristics of various technology platforms, including Java, NET, iOS, and Android It encompasses key components such as data structures, language syntax, APIs (Application Programming Interfaces), and the technical specifications necessary for each platform.
The primary objective of PSM is to develop a deployable model tailored for a specific platform, encompassing essential components such as source code, configuration settings, and other elements necessary for creating applications compatible with that platform.
Paradigm shift in MDA
In Model-Driven Architecture (MDA), model transformation is executed using specialized tools and processes, encompassing three key stages The first stage involves the conversion from a Computation Independent Model (CIM) to a Platform Independent Model (PIM) The second stage transitions the PIM into a Platform Specific Model (PSM), and the final stage focuses on the deployment of the system.
The conversion from Customer Information Management (CIM) to Product Information Management (PIM) involves utilizing transformation tools and processes to redefine business concepts and relationships This transformation creates platform-independent concepts and relationships within the PIM model, ensuring its flexibility and compatibility across various technology platforms.
The transition from Product Information Management (PIM) to Product Service Management (PSM) involves converting the PIM model into a PSM model tailored for specific technology platforms like NET, Java, or C++ This transformation utilizes specialized tools and processes to translate the concepts and relationships defined in the PIM into distinct components and structures within the PSM framework.
The system implementation phase follows the development of the PSM model, where the specific model is executed using the appropriate technology, programming languages, and tools tailored to the selected technology platform.
Through the stages of model transformation, MDA helps reduce dependence on specific technology platforms and increases reuse, allowing flexible and efficient system development on many different platforms
Object-oriented software analysis and design methods applying MDA
The object-oriented software analysis and design method utilizing model-driven architecture focuses on developing software systems through the principles of object-oriented programming (OOP) and the unified modeling language (UML) This approach encompasses several key steps essential for effective software development.
Requirements analysis involves gathering and evaluating the needs and expectations of users, customers, and stakeholders regarding the system to be developed This process encompasses various aspects, including functionality, performance, security, scalability, and maintainability It aligns with the CIM model, which reflects the business requirements and processes of the system.
Architectural design involves defining the system's components, layers, interfaces, and their relationships, serving as an abstraction to manage complexity and facilitate communication among elements System architecture can be effectively illustrated using UML diagrams, including class, component, and deployment diagrams This aligns with the PIM model, which represents the computational aspects of the system.
Detailed design involves defining the properties, methods, interactions, and behaviors of classes and objects within a system It serves as a comprehensive design plan that outlines the system's components and their integration to fulfill specific requirements This phase can be illustrated using UML diagrams, including sequence, activity, state, and use case diagrams In alignment with the PSM model, detailed design represents the technical facets of the system.
Installation involves writing source code for classes and objects within a system based on a detailed design This process can utilize object-oriented programming languages, including Java, C#, C++, and Python Additionally, source code can be generated from Platform Specific Models (PSM) using suitable tools and techniques.
Testing is the process of evaluating the quality and functionality of a system through various techniques and tools It encompasses several types, including unit testing, integration testing, user acceptance testing, performance testing, and security testing Utilizing appropriate tools and techniques from PSM, testing ensures that systems meet required standards and perform effectively.
3.3.1 Determine the content of the CIM model
The CIM model emphasizes the interaction between a system and its surrounding environment, highlighting the relationships among various actors and the system itself It outlines scenarios for system usage without providing a detailed definition of the internal static structure By offering an abstract framework, the CIM model aids in understanding and articulating the business aspects of the system effectively.
The CIM model does not include details about how the system is implemented or the technology used, but focuses on understanding and describing the business aspects of the system
3.3.2 Convert CIM model to PIM a Convert CIM components into PIM analysis elements
In this step, the system analyst identifies all analysis layers involved in each use case implementation, including boundary classes, control classes, and entity classes, while also analyzing the coordination of behaviors across these classes.
• Each actor/use case pair will have one or more boundary classes (Boundary Class)
• Each use case will be converted into a control class (Control Class) This class will contain all business operations of the system
• The information processed by the control layer in a use case is managed and stored in one or more entity classes (Entiny Class)
• The behavior of each use case is shown through a Sequence Diagram with participating actors and classes
Identify the analysis layers of the use case
Defining analysis classes is about identifying classes that are capable of implementing the behavior described in the use case It include:
• Boundary classes: represent components that communicate with entities outside the system These classes handle data import/export and interaction with users or external systems
Control classes are essential components in a system that manage and regulate the flow of information They are responsible for handling logic, making decisions, and distributing requests between the boundary layer and the entity layer, ensuring efficient communication and processing within the system.
• Entity classes: represent objects in the field of the system These classes contain properties and methods to describe and manipulate actual objects in the system
Analysis layers are often defined based on requirements analysis, domain understanding, and system use cases They help define how to organize and implement system behavior to meet user requirements
Distribute behavior to analysis classes
Once the analysis classes are identified, the system analyst must allocate the use case behavior to these classes and model the communication relationships among their instances to effectively execute the use case This task distribution to the analysis layers is a critical step in the process.
- Based on analytical class patterns
+ For boundary layers: distributes behaviors related to communication with agents
+ For entity classes: distribute behaviors containing data encapsulated in an abstraction
+ For control classes: distribute behavior specific to a use case or important part of the event flow
- Based on which layer has the necessary data to perform the tasks
+ If a class has data to perform a task, attach the task to the data
+ If multiple classes have data to perform a task then:
- Assign tasks to one of those classes and add relationships to the remaining classes
- Create a new class, assign tasks to that new class, and add relationships to the classes needed to perform that task
- Assign the task in a controller class and add relationships to the classes needed to perform that task
In the analysis phase, the system analyst meticulously details the properties of each analysis layer and elucidates the interconnections between them This involves identifying the dependencies of each analysis class on other classes, as well as recognizing events occurring within other analysis classes that impact the overall system By thoroughly describing these properties and relationships, a clearer understanding of the system's architecture is achieved, facilitating more effective design and implementation.
16 the analysis class needs to know, and information that the analysis class needs to know analysis as management tasks
• The properties of the analysis layer are described as follows:
Attribute name: attribute type = Initial value
• Dependency relationship: When the source class is used or refers to all information and behavior of the target class, it is a dependency relationship
• Association relationship: Between analysis classes, when two or more classes are linked to each other but they can also be considered independently, it is an association relationship
• Aggregation relationship: Between analysis classes, when 2 or more classes are related to each other and this class is a part of the other class, it is an aggregation relationship
• Generalization relationship: A class that has an inheritance relationship with another class is a class that shares structure or behavior with one or more other classes
• Composition relationship: When an entire class is created or destroyed, a part class of it is also create or lost, then that is an integration relationship
Represent the interaction between analysis classes
After identifying the analysis classes and determining the tasks of the classes, the interaction relationships between the classes need to be represented through diagrams
• Represents the interactive relationships between analysis classes
Representing the collaborative relationship between analysis classes is shown through a sequence diagram or a communication diagram
• Overview of relationships between analysis classes
+ Build a diagram showing an overview of the relationships between the main analysis classes participating in implementing the use case (VOPC - View Of Participating Classes)
+ Identify the analysis classes involved in executing the use case
To effectively analyze data relationships, it is crucial to identify the type and quantity of objects within each analysis class, such as many-to-many, one-to-many, or one-to-one relationships Subsequently, these analysis elements must be transformed into design elements within the Platform Independent Model (PIM).
In the transition from analysis classes to design elements within the PIM model, we analyze the interactions among these classes to identify corresponding design elements This phase aims to understand the communication between analysis layers, leading to the creation of essential design components, including design classes, packages, and subsystems.
• Boundary class in analysis can be converted into user interface classes in design, to manage interactions between the system and users
• Control class in analysis can be converted into processing classes in design, to implement processing logic and control data flow in the system
• Entity class in analysis can be converted into object class in design, to store and manage data of entities
Represent the interaction between design elements
• Represents the interactive relationships between design classes
Our analysis revealed interactions between classes based on functional and process requirements In the design phase, we can utilize sequence diagrams to illustrate these interaction relationships among design classes This approach helps manage class interactions effectively while maintaining a clear separation between the user interface, logic processing, and data storage.
• Represents an overview of the relationships between design classes
3.3.3 Convert PIM model to PSM
Model transformation in Model-Driven Architecture (MDA) facilitates the conversion of Platform-Independent Model (PIM) elements into Platform-Specific Model (PSM) elements by leveraging information from the PSM model alongside specific technology platforms such as NET or J2EE It is essential to choose the appropriate technology platform for effective system implementation.
DEVELOP APPLICATION
Overview of company
Phuong Dong Garment JSC, founded in 1988, is a leading garment manufacturer with a significant market presence in Europe, America, and Asia The company offers a diverse range of products, including sweatshirts and fleece pants (53%), bags and backpacks (22%), jeans (10%), workwear (10%), and men's suits (5%) With a dedicated workforce of 3,500 employees, Phuong Dong Garment JSC continues to uphold its reputation in the industry.
Figure 4 Image of Phuong Dong Garment JSC [6]
The company boasts international certifications including WRAP and SMETA, and has secured long-term contracts with prominent clients like Decathlon, Mango, and Zara Additionally, a new factory has been established in Cho Gao District, Tien Giang province, featuring 18 production lines dedicated to backpacks and 18 for clothing.
Learn about the company's system operations
Table 4.1 Accounting operations for garment companies
The above accounting operations are intended to ensure that the production process always takes place according to the correct procedure
Step 1: The accountant checks and monitors the data of warehouse receipts and warehouse receipts for materials, tools, and supplies in the detailed accounting book
Step 2: The general accountant compiles the import and export general book, prepares a list, a table to calculate the actual prices of materials and tools, a table of allocation of materials and tools from invoices/ cum delivery note of the seller to enter the detailed accounting book of payment with the seller in the voucher journal
Step 3: Based on the material allocation table, tools and equipment, summary table of exported materials, salary allocation table The accountant collects costs and calculates product cost
Step 4: The accountant submits the product cost calculation sheet to the Chief
To edit content, the accountant must withdraw the submission sent to the Chief Accountant if the request has not yet been approved, subsequently returning to steps 2 or 3 of the process.
Step 5: The chief accountant receives the request and approves it
• If approved, the accountant receives notification and transfers the cost summary and product price calculation to relevant parties (production department and sales department)
• If you do not agree to review, the Chief Accountant returns the content to the Accountant and returns to step 2 or 3
Step 1: Accountants track each order, check daily import and export documents to clearly understand the inventory quantity of raw materials and supplies, to ensure continuous operation of the production process
Step 2: Accountants prepare reports on finished goods imported and exported from warehouse for each order
Step 3: The accountant checks and statistics the quantity of machinery, equipment and supplies in the warehouse and at the same time checks the quality of assets to prepare a fixed asset depreciation table
Step 4: The accountant submits the fixed asset depreciation schedule to the Chief
If the Chief Accountant has not approved the request, the accountant can withdraw the content sent for editing and return to the previous steps in the process.
Step 5: The chief accountant receives the request and approves it
• If approval is accepted, the accountant will receive notification that the request has been approved
• If you do not agree to review, the Chief Accountant returns the content to the Accountant and returns to step 3
Step 1: The accountant coordinates with the human resources department and the line manager to clearly understand the list of workers and register a personal tax code for each worker
Step 2: The accountant summarizes the work, actual working hours and overtime of each worker, depending on the working position and the price of each divided step to calculate the exact salary for each worker
Step 3: The accountant prepares the monthly payroll and prepares payment slips
Step 4: The accountant submits the payroll and payment slips to the Chief Accountant for approval
If you need to make changes to the content, the accountant will retract the submission sent to the Chief Accountant, provided that the Chief Accountant has not yet approved the request, and will revert to step 3 in the process.
Step 5: The chief accountant receives the request and approves it
• If approved, the accountant issues salary to the employee
• If you do not agree to review, the Chief Accountant returns the content to the Accountant and returns to step 3
Step 6: The chief accountant accounts for salary and insurance costs for the garment company
Introducing an overview of the accounting management system in a garment
Actors participating in the system
Based on the basic operations of the system, use cases can be grouped into the following packages: “warehouse accounting management”, “product cost management”, “labor management”, “management” salary”, “system management”
Figure 6 Define a package of use cases
Figure 7 Use case diagram for warehouse accounting process
Use Case name warehouse accounting management
This use case describes the process of raw materials and asset management, including tracking inventory quantities, preparing import/export reports for finished goods, and managing fixed asset depreciation
Actor Accountant, Chief Accountant, director
The accountants have access to the accounting system and are responsible for managing orders, inventory, and fixed asset depreciation
Accountant must have to the system Main Stream
1 Accountants track each order, check daily import and export documents to clearly understand the inventory quantity of raw materials and supplies, to ensure continuous operation of the production process
2 Accountants prepare reports on finished goods imported and exported from warehouse for each order
3 The accountant checks and statistics the quantity of machinery, equipment and supplies in the warehouse and at the same time checks the quality of assets to prepare a fixed asset depreciation table
4 The accountant submits the fixed asset depreciation schedule to the Chief Accountant for approval
If the Chief Accountant has not approved the request, the accountant can withdraw the content submitted for editing and return to steps 2 or 3 in the process.
5 The chief accountant receives the request and approves it
• If approval is accepted, the accountant will receive notification that the request has been approved
• If you do not agree to review, the Chief Accountant returns the content to the Accountant and returns to step 2 or 3
Post-conditions Orders are accurately tracked and managed
Reports on finished goods imported and exported are prepared The fixed asset depreciation schedule is submitted for approval
If an accountant needs to modify the fixed asset depreciation schedule without approval from the Chief Accountant, they must retract their request and revert to either Step 2, which involves preparing reports, or Step 3, where they verify the quantity and quality of the assets.
If the Chief Accountant rejects the fixed asset depreciation schedule, the accountant must revise the content, leading to a return to either the report preparation stage or the asset quantity and quality verification stage.
Figure 8 Use case diagram for product cost management
Use Case name raw materials accounting process
This use case involves the process of checking and monitoring warehouse data, compiling import/export records, calculating product costs, and obtaining approval from the Chief
The accountants have access to the accounting system and are responsible for monitoring warehouse data, calculating product costs, and obtaining approval from the Chief Accountant
Accountant must have to the system Main Stream
1 The accountant checks and monitors the data of warehouse receipts and warehouse records for materials, tools, and supplies in the detailed accounting book
2 The general accountant compiles the import and export general book, prepares a list and tables to calculate the actual prices of materials and tools They also create a table for the allocation of materials and tools based on invoices or delivery notes from the seller, which is entered into the detailed accounting book of payment with the seller in the voucher journal
3 Based on the material allocation table, tools and equipment, summary table of exported materials, salary allocation table, etc., the accountant collects costs and calculates the product cost
4 The accountant submits the product cost calculation sheet to the Chief Accountant for approval
If the accountant wants to edit the content and the Chief Accountant has not approved the request, the accountant withdraws the content and goes back to Step 2 or Step 3
5 The Chief Accountant receives the request and reviews it
Upon approval from the Chief Accountant, the accountant is notified and subsequently shares the cost summary and product price calculations with the production and sales departments.
If the Chief Accountant does not approve the request, the Chief Accountant returns the content to the accountant, and the process goes back to Step 2 or Step 3
Warehouse data is accurately monitored and recorded
Import and export records are compiled and maintained
Product costs are calculated and approved
If an accountant needs to modify the product cost calculation sheet without approval from the Chief Accountant, they must retract the changes and revert to either Step 2, which involves compiling records, or Step 3, where they collect costs and calculate product costs.
If the Chief Accountant rejects the product cost calculation sheet, it is sent back to the accountant, prompting a return to either Step 2, which involves compiling records, or Step 3, where costs are collected and product costs are calculated.
Figure 9 Use case diagram for salary accounting process
This use case focuses on collaborating with the human resources department to calculate salaries based on hours worked and job positions It includes preparing payroll and payment slips, securing approval from the Chief Accountant, issuing salaries, and accounting for both salary and insurance expenses.
Actor Accountant, Human Resources Department, Line Manager, Chief
The accountant works closely with the human resources department and line managers to manage payroll processing, ensuring proper approvals and accurate accounting of salary and insurance costs Access to the payroll system is essential for this collaboration.
1 The accountant coordinates with the human resources department and the line manager to understand the list of workers and register a personal tax code for each worker
2 The accountant summarizes the work, actual working hours, and overtime of each worker based on their working position and the price of each step This is done to calculate the exact salary for each worker
3 The accountant prepares the monthly payroll and generates payment slips
4 The accountant submits the payroll and payment slips to the Chief Accountant for approval
If the accountant wants to edit the content and the Chief Accountant has not approved the request, the accountant withdraws the content and returns to Step 3
The Chief Accountant receives the request and reviews it
If the Chief Accountant approves the request, the accountant issues the salary to the employees
If the Chief Accountant does not approve the request, the Chief Accountant returns the content to the accountant, and the process goes back to Step 3
5 The Chief Accountant accounts for salary and insurance costs for the garment company
Personal tax codes are registered for each worker
Salaries are accurately calculated and issued to employees
Salary and insurance costs are accounted for
If the accountant seeks to modify the payroll and payment slips but has not received approval from the Chief Accountant, they must retract the changes and revert to Step 3, which involves preparing the payroll and payment slips.
If the Chief Accountant rejects the payroll and payment slips, the documents are sent back to the accountant, prompting a return to Step 3 for the preparation of payroll and payment slips.
Figure 10 Use case diagram for system administration functions
Use case name System management
Summary Allows management and decentralization of system access to employees, performing data management, backup, and restore functions
Context The system administrator logs into the system and manages related functions
The system administrator has the ability to log into the system to efficiently manage users, including adding, editing, and deleting accounts Additionally, they oversee the backup and restoration of system data, while also managing materials and departmental operations.
Detailed design analysis of a Warehouse accounting management use case
Warehouse accounting management is a crucial aspect of the accounting management system, enabling authorized personnel, such as accountants, to efficiently manage inventory Key operations include overseeing goods, monitoring and verifying orders, tracking and analyzing quantities, editing and submitting relevant information, and generating reports on imports and exports.
The detailed content of the analysis and design steps for the use case
Section 4 of Chapter 4 discusses "Warehouse Accounting Management," outlining the application of design analysis steps from Chapter 3 for this specific use case The accompanying table succinctly summarizes these steps, providing a clear overview of the methodology employed in warehouse accounting management.
Step Content and implementation results
1 Determine the content of the CIM
1.1 Identify key abstractions: The main abstraction is “Report”, which has a one-to-many relationship with “materials” of the use case “Inventory Accounting Management”
1.2 Identify actors and use cases:
In case of used: Warehouse accounting management
1.3 Represents the interaction between actors and use cases:
Sequence diagrams show the main flow of events + Create report
Activity diagrams show the branching flow of events + Select the same IDnumber item
+ Leave one of the following fields blank: Place_of_use, Quantity_in, OriginalPrice_in, RemainingValue_in, Quantity_dif, OriginalPrice_dif, RemainingValue_dif
2.1 Identify the analysis layers of the use case:
• Entity class: ReportDB 2.2 Represent the interaction between the analysis layers identified in section 2.1 through diagrams for the accountant agent:
Sequence diagrams follow the main flow of events + Create report
Activity diagrams show the branching flow of events + Select the same ReportID item
+ Leave one of the following fields blank: Place_of_use, Quantity_in, OriginalPrice_in, RemainingValue_in, Quantity_dif, OriginalPrice_dif, RemainingValue_dif
Overview chart of relationships between analysis layers
3.1 Definition of UI subsystem “ReportUI”
3.2 Definition of the BUS business subsystem “ReportWeb”
3.3 Define the DAO data retrieval subsystem “ReportDAO” corresponding to the entity class “ReportDB”
3.4 Represent the interaction between the design subsystems defined in steps 3.1, 3.2, 3.3 for the functions + Create Report, Edit report, Delete report
3.5 Represents an overview of the relationships between the design subsystem packages involved in the use case:
• Package RE_PRE contains the UI subsystem “ReportUI”
• Package RE_BUS contains the BUS subsystem “ReportWeb”
• Package inventory_DAO contains the DAO subsystem “ReportDAO”
4 Design the data model: map the entity class “Report” to the data table model
Detailed content of steps to analyze and design the use case "Warehouse
The following details the business specification of the use case "Warehouse accounting management" and the steps to perform analysis and design of the use case
4.5.1 Business specification for use case of Warehouse Accounting Management a Main line of events
The use case of "Inventory accounting management" is done when accountants need to create, edit information, delete inventory report information and fixed asset depreciation records
The system requires the reporter user to select the function to perform (create, update, delete information)
Once the user requests, one of the following events will be performed:
- If the user selects “Add new”, the “Create report” function will be performed
- If the user selects “Update”, the “Edit report” function will be performed
An inventory order needs to be made before the employee performs the inventory
The system requires the user to select information for a fixed asset inventory record: "employee name" and "job assignment date"
The system displays information about previously filled materials
+ According to accounting books: Quantity_Ab, Original price_Ab,
• The user selects "Report" and
• The user selects "Report" and fills in the following information after inventory:
+ Remaining value (according to accounting books)
+ According to inventory: Quantity_in, Original price_in, Remaining value_in
+ Difference: Quantity_dif, Original price_dif, Remaining value_dif
• User uses command to save record information
• The system displays the fixed asset inventory report
• The user will update information on the fixed asset inventory report (the record has not been submitted to the director)
• The system displays information of the selected Fixed Asset Inventory Record
+ Remaining value (according to accounting books)
+ According to inventory: Quantity_in, Original price_in, Remaining value_in + Difference: Quantity_dif, Original price_dif, Remaining value_dif
• The user edits and updates the necessary information and then saves the information
• The system notifies changes to the fixed asset inventory record information successfully
• The system displays information about the fixed asset inventory record that has just been edited b The stream of events branches
Do not select employees to conduct inventory
The admin must choose an employee to perform inventory tasks; failure to do so will prompt the system to display the message, "Need to select inventory person."
Select the same Fixed asset name
Once the inventory order is placed, it appears on the employee's page If the user chooses the same product name for inventory, the system will show a message stating, "Materials have been inventoried," and permit the user to make another selection.
Leave one of the following fields blank: Leave one of the following fields blank: Place_of_use, Quantity_in, OriginalPrice_in, RemainingValue_in, Quantity_dif, OriginalPrice_dif, RemainingValue_dif
If a user fails to fill in any required fields, the system will prompt them with the message "This field is required," allowing them to re-enter the necessary information.
4.5.2 Determine the content of the CIM model a Identify key abstractions
Figure 12 Identify relationships between key abstractions
Figure 13 Identify relationships between key abstractions b Represents the interaction between actors and use cases
Represent the interaction between the actor “Accountant” and the use case “Report” through diagrams:
• Sequence diagrams show the main flows of events
• Activity diagram shows the branching flow of events
+ Do not select employees to conduct inventory
+ Select the same IDnumber item
+ Leave one of the following fields blank: Place_of_use, Quantity_in, OriginalPrice_in, RemainingValue_in, Quantity_dif, OriginalPrice_dif, RemainingValue_dif
Figure 14 Sequence diagram showing the relationship between analysis layers in the
(Note: controller class “ReportControl” and entity class “ReportDB” are from use case “Materials Management”)
Figure 15 Sequence diagram showing the relationship between analysis classes in the function "Delete an inventory record"
Do not select employees to conduct inventory
Figure 16 Activity diagram showing branching event flow "Do not select employees to conduct inventory".
Figure 17 Activity diagram showing branching event flow " Select the same Material "
Leave one of the following fields blank: Place_of_use, Quantity_in, OriginalPrice_in, RemainingValue_in, Quantity_dif, OriginalPrice_dif, RemainingValue_dif
Figure 18 Activity diagram showing branching event flow “Leave the fields blank”
4.5.3 Convert CIM model to PIM model
Identify the analysis layers of the use case
The analytics layers of the “Report Management” use case include:
Figure 19 Sequence diagram showing the relationship between analysis layers in the
Figure 20 Sequence diagram showing the relationship between analysis layers in the "edit report" function
4.5.4 Convert PIM model to PSM model a Defines the UI subsystem
The user interface subsystem includes events of operations on the interface of
Materials Management facilitates data collection and display through its interface, serving as a control mechanism to transmit information to the "ReportWeb" business subsystem within the business layer.
The User Interface (UI) subsystem for the "Materials Management" function enables managers and employees to efficiently manage production plan information This functionality includes capabilities for adding and updating reports, as well as searching for inventory materials, streamlining the overall materials management process.
Steps to perform the function:
1 Materials management page: Managers or employees access the product management page by logging into the system and navigating to the production plan management section This page displays a list of available production plans and management options
2 Search Materials Inventory: User can search Materials Inventory using the search field The Materials management page displays a search box that allows users to enter information such as the material name or inventory person's name
3 Search for inventory record information: Users can search for inventory record information using the search field The Report page displays a search box that allows users to enter information such as the material name or inventory person's name
4 Create inventory orders: Directors/managers can create new inventory orders by clicking the "Create inventory orders" button on the Report page The inventory order creation page displays a form asking the user to select detailed information such as the inventory person's name and date
5 Update inventory information: Users can update information of an inventory record by editing directly on the Report interface and then saving the edited record
6 Display list of inventory records: The Report page displays a list of inventory records in an easy-to-read layout, including basic information such as production plan name, inventory person, and status
51 b Definition of the BUS business subsystem
BUS interface subsystem for "Materials Management" function:
Description: This function allows managers or employees to manage information about reports, including adding, updating, searching inventory reports
Steps to perform the function:
1 Report management page: Managers or employees access the report management page by logging into the system and navigating to the report management section This page displays a list of available inventory reports and management options
2 Search for inventory reports: Users can search for reports by entering information such as inventory material names or employee names in the search field The BUS interface subsystem receives the search request and returns the appropriate results
3 Add inventory report: User can add new inventory report by clicking
"Perform inventory" button on the management page The BUS interface subsystem displays a form asking the user to enter detailed information about the report such as name, select date
4 Update inventory report: Users can edit information of a Report by clicking on the line that needs to be edited with the report in the list The BUS interface subsystem will allow users to save information to update reporting information
5 Display detailed information: When the user selects to update the report successfully, the BUS interface subsystem displays detailed information about the report such as record code, report name, and inspected material name inventory, content of inventory reports and other information
52 c Define the DAO data retrieval subsystem
DAO (Data Access Object) data retrieval subsystem for the "Report Management" function
This function utilizes the DAO subsystem to access report-related data from the database, offering methods for Create, Read, and Update operations on the report table.
Steps to perform the function:
1 DAO initialization: The web system initializes a DAO object for reporting, connects to the database, and sets connection parameters
System Testing
I used Microsoft Excel to write test cases for my application It includes 12 different test cases for functions of website
Functional testing is a type of black box testing that generates test cases based on the specifications of a software application or component This approach focuses on evaluating the functions by inputting specific values and checking the corresponding outputs, while largely disregarding the internal workings of the application.
The process aims to identify discrepancies between the software's external specifications and its actual performance These external specifications define the precise behavior of the software from the user's viewpoint
Figure 35 Test case for login and logout functionality
Figure 36 Test case for inventory order creation function
Figure 37 Test case for the function of creating a new inventory
Figure 38 Test case for inventory record search function
Figure 39 Test case for create employee function
Figure 40 Test case for employee search function
Figure 41 Test case for employee edition function
Figure 42 Test case for employee delete function
Figure 43 Test case for material creation function
Figure 44 Test case for material search function
Figure 45 Test case for material edition function
Figure 46 Test case for material delete function
Scalability and long-term maintenance
When developing systems using Model-Driven Architecture (MDA), scalability and long-term maintenance are essential considerations Strategic planning and implementation are vital to ensure the system can grow without becoming unwieldy By breaking the system into smaller, manageable modules, clarity and control are maintained, allowing for independent development, testing, and maintenance Incorporating automated testing into the development process helps prevent errors from model changes, while CI/CD pipelines further enhance scalability and reliability by automating these tests.
Effective long-term maintenance of an MDA-based system is crucial for ensuring its functionality, efficiency, and adaptability to evolving requirements Key to this process is comprehensive documentation of models, code generation, and customizations, which aids in understanding the system's architecture and simplifies maintenance Regularly reviewing and refactoring models and generated code is essential for maintaining code quality and addressing new demands, thereby preventing the buildup of technical debt Additionally, continuous performance monitoring and user feedback collection are vital for identifying improvement areas, ensuring the system evolves in accordance with user needs and technological advancements.
To ensure the longevity and efficiency of MDA-based systems, organizations should prioritize scalability and long-term maintenance This proactive strategy not only strengthens the system's adaptability over time but also optimizes the return on investment in MDA technologies.
Summary of chapter
This chapter focuses on system and feature design, encompassing system models, use case diagrams, sequence diagrams, activity diagrams, and website interfaces These components collaborate to create a robust, user-centered platform that aligns with the project's functionality and user experience objectives As development progresses, these design elements will serve as a roadmap, guiding implementation and ensuring the successful realization of the website's goals.