The second case study provides an example of a software service that follows the three-layered software architecture. The service is useful for all relevant mobile platforms. The solution applies the modeling, model processing, mobile platforms-related technologies, data handling and cloud computing-related research results. These types of software services are the target of the methodology provided by the thesis.
Organizing the invoices, tracking spending and balancing our account are essential tasks when it is time for our family and/or company to manage the budget. Applying intelligent software solutions can save time and provide more accurate results. Moreover, electronic data storage provides greater security for the data. The methods used to manage our spending data can greatly affect the process of organizing your money.
The main idea of the application bundle is to provide centralized, cloud-based data storage and services, which allow the manipulation of data using different clients on a variety of platforms. The native mobile clients provide the user interface to login to the system, manage spending and insert new data. The role of mobile devices is crucial in this scenario, since they are always with us and we can use them to immediately insert new spending. The camera feature of the device can be utilized to take a photo of an invoice, a receipt, or a bill. This photo can be automatically processed by software and provide the data regarding spending.
When using a credit card, it is also common that we receive a text message to our phone with the details of our purchases. These text messages can also be automatically processed by the application. Furthermore, mobile device-based payment solutions are increasingly being used and have a notable role in the market. These solutions also allow users to use their phones instead of their bank cards.
Figure C-1 Overview of the spending tracking case study
Data Layer
The flow of the application functions that run on the mobile devices is presented in Figure C-1. Rectangles on the left represent the main screens of the user interface, while the arrow-like rectangles are functions implemented in the application. The storage of the data and the application programming interface (API), which is used as a service to manipulate this data, is provided by the server and hosted in the cloud. From the main screen, we can navigate to the login screen. To perform the login, the login function needs to reach the cloud service to authenticate the user. This is denoted by the dashed line connecting the login function to the server side. Several functions are available from the main screen. We can query our spending list, search for specific data, or add new data. From the list screen, we are able to delete some of the data. From the New Spending Form, we can reach two functions: read from camera and read from sms. These elements represent that the camera or the text messages, stored on the mobile device, can be used to initialize the data on the form regarding new spending data. Note that these two functions do not need to reach the server.
We have seen that, aside from the data storage, a server component is required to manage access to the data and provide a platform independent application programming interface.
Using this API, native clients can be implemented for the different platforms. The different artifacts, requiring development, are as follows:
‒ Based on the schema of the data, a data store needs to be initialized. For example, if the data is stored in a relational database, the appropriate tables should be created.
‒ A server component needs to be implemented, which can access the data store and provides a platform independent API for the actual functions used to manipulate the data. Besides these functions, the server should provide other services, e.g.
notifications regarding data changes or built-in user management.
‒ Native clients must be implemented for the different mobile platforms.
‒ Finally, for administration purposes, a web client is required.
Figure C-2 The architecture of the case study application
@
M obile Devices Web Clients
Data Layer
… Business Logic Layer
Through the generalization of the architecture in this concrete application, the need to specify a data model becomes apparent. In order to complete this, several data manipulation functions and clients who provide user interfaces for these functions are required. The flow of the functions needs to be defined in order to provide the client’s logic. Moreover, the structure of the client’s forms can be derived from the data model. Note that the implementation of several functions can also be derived from the data model, e.g., listing, inserting and deleting.
Moreover, several services, such as user management, are not specific to this application.
This is clear that, in providing two domains, we can make better use of the concept of domain-specific modeling. Within the first domain, we can model data schemata and the needed functions (data manipulation model). In the second domain, we can specify platform independent and high-level descriptions of the flow regarding the client’s functions (function flow model). Having completed the function flow model, the three layers of the architecture above can be generated automatically.
‒ The schema of the data storage can be generated from the data manipulation model.
‒ The code of the server component can be generated from the data manipulation model and the function flow model. The source code for several, simple data manipulation tasks can be automatically generated, e.g., deleting data, inserting new data, listing of data, etc. Naturally, if a more complex application-specific login needs to be implemented, it must be manually provided by the developer.
‒ The code of the mobile clients is also based on both models. The function descriptions provide the connections between the different pages. Meanwhile, the structure of the forms, used to display data, can be generated from the data manipulation model.
Figure C-3 Data manipulation in the case study
Assume that the function flow of our original budget tracking application is modeled as it is presented in Figure C-1. A sample model of the data manipulation is provided in Figure C-3.
The rectangle in the middle provides the description of a simple data item we will store. For
Spending value: integer creation: datetime comment: text
list search delete
add
User management
E-mail notification manipulate manipulate manipulate
manipulate
notify authorize
each transaction we provide its numerical value, its creation date, and a comment. This is also specified that four functions are needed (add, list, search and delete) for data manipulation.
Moreover, we attach two further components for this data, which are provided by the framework: User management and Email notification.
As the language of the two modeling domains becomes more powerful, the whole concept becomes more efficient and less code needs to be added manually. We highlight that this solution allows the code generation for different mobile platforms and also supports the service-side realization of the whole solution. However, custom validations and/or further custom behavior, which requires to manually extend the implementation, are also worthy of further examination.
The case study highlights the capabilities of our research areas when they are applied jointly.
This also underpins that in the case of the software industry, only research groups and implementation groups can have a relevant role. This is because individuals cannot collect and maintain a deep knowledge throughout several areas, e.g. in the field of modeling, model processing, mobile platforms, energy efficient development, data technologies and cloud computing.