Refactor Monolithic Model into Software Application with Services
Refactoring a monolithic model into a modular set of components is an iterative and exploratory process. You continuously analyze and refine component boundaries and interactions to create alignment with both functional and nonfunctional requirements:
Define functional boundaries for each component.
Evaluate scalability requirements.
Align components with the development workflow and team structure.
Determine execution event types and corresponding interface types to manage and synchronize data across components.
When migrating this monolithic model to a service-oriented architecture, it is important to recognize that you can refactor the application multiple ways, each with its own benefits and trade-offs.
Mapping Core Functions to Modular Components
This example focuses on refactoring the application based on functional boundaries. Consider the main functions of the application: the electric vehicle control application manages motor torque arbitration and power by determining the amount of motor torque and brake pressure to command. In this example, the monolithic model is refactored into a main application component and various service components. Communication methods and interfaces are determined based on data flow and types of interactions within the model.
Energy Management Component — Manages the motor and torque arbitration. This component serves as the main controller. It acts as a client that requests services from other components based on real-time needs and system state.
Vehicle Dynamics Service Component — This component provides real-time inputs necessary for dynamic vehicle control. The Energy Management component uses client-server communication to interact with the Vehicle Dynamics Service component because it needs to actively request up-to-date data at specific times to make control decisions.
Battery Management System Service (BMS) Component — This component calculates the battery state of charge, power limits, and battery state based on driver mode. The Energy Management component uses client-server communication because it must query the BMS on demand to obtain the latest battery parameters for optimal energy management.
Brake Pedal Torque Request Service Component — This component outputs the brake pedal torque request. It uses sender-receiver communication because the Energy Management component does not invoke it directly, but instead receives the broadcast signal from the brake control system.
This diagram visually highlights which subsystems of the monolithic model are refactored into the respective service components.
To open the model, run this command.
open("EvPwrCntrllrEM.slx");In the next step, you Create Architecture Model and Service Interface, author a software architecture model to visually represent the components.
