Research

User base

We needed to conduct research to deduce what the large majority of our user base would be, so that we could design our applications UI and functionality to be pleasing and intuitive for our expected users, where we concluded the following:

Parent users would simply be both dads and moms that:

• Have children
• Are primary caregivers for their children
• Are busy enough such that they don't have time to look after their children full time.
• In households that consist of a mother and father, the mother will handle most of the au pair related duties.

From the criteria mentioned above we expect the large majority of parent users to fit the inferred profiles below:

• Both mothers and fathers
• 20-23 year old moms who had children early and have to work long hours
• 24-30 year old mothers/fathers who work full time and need to have their young children looked after during the day, take to and from school
• 30+ year old parents who need an au pair intermittently when they would otherwise have left a young child alone.

An au pair user would use the application to handle the complication of finding suitable families to care for. Typically au pairs are female (according to studies, approximately 90%) and in a typical age range from low twenties to mid thirties.

From to the criteria mentioned above, we expect the large majority of au pair users to fit the inferred profiles below:

• 18-22 year olds as graduates looking for a starter job, who would perhaps au pair for smaller families.
• 22-35 year old females who au pair full time for larger families.
• 18-35 males who may also au pair for small/large families.

Technical

Tech Stack

Frontend - Angular ionic

Component-based architecture focuses on the decomposition of the design into individual functional or logical components that represent well-defined communication interfaces containing methods, events, and properties. It provides a higher level of abstraction and divides the problem into sub-problems, each associated with component partitions. This is why we chose to go with Angular ionic as its component-based framework allows us to translate our subsystems into pages that will form our presentation and view layer in MVC and Layered Architectural style

Backend - Spring-boot (Java)

Components within the layered architecture pattern are organized into horizontal layers, each layer performing a specific role within the application, The most common layers are presentation, business, persistence, and database. This is why we chose to go with Spring-boot as it provides a good framework to subdivide our backend into isolated layers for each data collection, with each collection having a controller a repository a model, and a service that allows complete data flow from the database through the backend to the frontend with a request-response methodology.

Database - MongoDB

The choice of layered and component-based architecture styles pushed us in the direction of scalability and flexibility for our data model. This is why we chose MongoDB. It provides a more scalable and flexible database due to its document-oriented approach. Its dynamic schema, along with its BSON data, provides a higher-performing database with a larger variety of types. This all together ensures we can have an evolving data schema, which minimizes the possibility of downtime, and future proofs the reliability of the application's database. Mongo DB also works well with Springboot and provides libraries to use at the data access layer to perform CRUD operations on the collections

Hosting - AWS

Due to the constraint of the application needing to be multi-platform, we have chosen AWN for its fast delivery and complete control over the server allowing us to configure the OS language and more, to better suit our application and ensure its reliability of it.

Architecture

Component Based

The Au Pair needs to be created in a small window of time, so creating each component from scratch for each page would be tedious and time consuming.

For this reason, The Au Pair uses a component-based architecture, whereby using Angular will allow us to easily create components and reuse them for different pages. This allows us to spend less time creating pages and re-coding components if they have already been created.

Not only does a component-based architecture allow us to develop The Au Pair at an increased rate, but it also allows us to easily update and change components without changing the functionality of an entire page. This also provides an easy means to ensure consistency, such that if a component is used in multiple places, updating the component once will reflect on all pages that use that component.

These desired standards of developing efficiently in a small time frame, and creating an application that is consistent, are important qualities for The Au Pair and will help us ensure that we adhere to our architectural design strategy (Quality Driven Development).

Model-View-Controller

The Au Pair’s data flow is split into 2 stages, from the database to the backend and from the backend to the frontend.

For this reason, The Au Pair uses an MVC architecture pattern as it allows us to have a separate internal representation of information from what is presented to the user and allows us to have more control over how the data is transferred from the model to the view.

This also allows us to have shared data between different users and separate views and can be configured on a session-by-session basis.

Along with the above, it enables us to have all communication between the backend and frontend as well as the backend to the databases centralized by means of controllers and repositories ensuring a single point of access on both sides creating a more secure data flow.

Layered Pattern (4-tier)

The Au Pair is a complex system of interconnecting components and services. Without any structure to separate these components and services, it would be difficult to create components and data for the functionality of the application.

To aid in this separation of concerns, The Au Pair has a layered architecture, allowing for different layers which include the Presentation layer, Application layer, Business Logic layer, and database access layer. Each layer in The Au Pair provides services to the next higher layer.

The Presentation layer is used for the front end which The Au Pair utilizes for the user interface. The Application layer is the controller where requests are sent. The Data access layer translates objects to database objects and the Business logic layer is where all operations happen, including Create, Read, Update and Delete (CRUD) operations.

The Au Pair uses the layered pattern for the separation of concerns and to create structure in the development of the application.

Service Oriented Pattern

The Au Pair needs to provide users with lots of data, and this data needs to be provided consistently for each of the different types of users and views. Not only does it need to be provided consistently, but due to time constraints, it needs to be reusable and easy to understand for the whole team to be able to get the data without prior knowledge of how it is provided.

For this reason, a service-oriented pattern has been chosen. The service-oriented pattern means that the business logic of providing data is moved into services, where each of these services is separated from the other and deals with different discrete portions of the business logic. These services are to be exposed using a standard network protocol to send requests, which will be a Restful HTTP protocol.