Application Design & Specifications

4 minute read


I. Introduction

So far, we have defined our application purpose and described its bsuiness requirements.
As a result, the main business entities are starting to emmerge as we delve deeper and deeper into definitions and requirements.

Now it’s time to define our application design.

In this section we will use two UML diagrams, namely, class diagram and use case diagram.

Class diagram is a specific representation of entities, their attributes and their relationships.

On the other hand, Use Case Diagram is a specific representation of a users’s possible interactions with the application. It depicts what a user can do with the application.

Don’t worry if this doesn’t sound familiar to you, you’ll easily get into it as we move forward.

II. ToDo Application Design

If you carefully examine the Application definitions and business requirements, you will find out that those could be depicted by some entities and components.
Here are the main components that you might think of:

  • Two main entities, ToDoArea and ToDoTask (we are starting to give our entities significant names)
  • Four main use cases for each entity (i.e. create/delete/search/update) (a user might interact with the application in four different ways for each entity)
    • (create/delete/search/update) ToDoArea
    • (create/delete/search/update) ToDoTask
  • Two use cases that involve both ToDoArea and ToDoTask (i.e. assign/unassign) and which is dealing with update entity relationships: (a user might interact with the application in two different ways when dealing with both of entities)
    • (assign/unassign) ToDoTask(s) from a given ToDoArea

II.1- ToDoApplication Class Diagram

According to our previous study, it is safe to assume that the following class diagram could genuinely describe our main entities and their relationships.

Let’s explain what is happening here.

This class diagram describes ToDoArea entity and ToDoTask as follows:

  1. an entity named ToDoArea defines an Area and has the following seven attributes names or characteristics:
    • id : defines the entity’s identifier. Is of type number
    • name: defines the entity’s name. Is of type text
    • description: defines the entity’s description. Is of type text
    • createdBy : defines who created the entity. Is of type User
    • updatedBy : defines who updated the entity. Is of type User
    • createdAt : defines when the entity was created. Is of type date
    • updatedAt : defines when the entity was updated. Is of type date
    • a relationship with ToDoTask entity: depicted by the fact that zero or one (0..1) ToDoArea contains zero or many (0..*) ToDoTask
  2. an entity named ToDoTask defines a Task and has the following seven attributes names or characteristics:
    • id : defines the entity’s identifier. Is of type number
    • name: defines the entity’s name. Is of type text
    • description: defines the entity’s description. Is of type text
    • createdBy : defines who created the entity. Is of type User
    • updatedBy : defines who updated the entity. Is of type User
    • createdAt : defines when the entity was created. Is of type date
    • updatedAt : defines when the entity was updated. Is of type date
    • status : defines the status of the task. It could be one of these fixed values: Active, Closed or New (A task can be new, active or closed. We could have thought about other statuses; but we wanted to keep it as much simple as possible for this tutorial). Since this attribute has a set of predefined values it is of type enumeration
  3. Two services for each entity, ToDoAreaService and ToDoTaskService.

    These are the services that manage each entity.
    Please keep in mind that you don’t have to know the methods implemented by these services. All what you should know is that:

    • there are one managing service for each entity as follows:
    • ToDoAreaService managing the entity ToDoArea
    • ToDoTaskService managing the entity ToDoTask
    • these services are responsible for communicating with the backend service (backend service mock in our case)

II.2- ToDoApplication Use Cases Diagram

According to our previous study we have identified a couple of use cases that define how a given user can interact with our ToDoApplication.
Those use cases might be described by the following Use case diagram.



Again, few things are happening here.

The first use case diagram describes how a user interacts with ToDoArea entity using our application:

  • a user can View/delete/add/update a ToDoArea instance
  • a user can Assign/Unassign a ToDoTask to a ToDoArea
  • a user can Search for ToDoArea instances
  • All these actions are performed while the user is signed into the application (user is in the private context).
  • some actions includes a search for ToDoArea (View, add and update a ToDoArea are possible after executing a search action)

The second use case diagram describes how a user interacts with ToDoTask entity using our application:

  • a user can View/delete/add/update a ToDoTask instance
  • a user can Close a ToDoTask instance
  • a user can Search for ToDoTask instances
  • All these actions are performed while the user is signed into the application (user is in the private context).
  • All these actions includes a search for ToDoTask (View, add and update a ToDoTask are possible after executing a search action)

ℹ️ Believe it or not, you have done half the work of building your application. Congratulations !
Remember that a clear design specifications is key for a good application.


Now our application design is finished, it is high time we start implementing our application using Averos Designer.
Usually, developing such an application from scratch is considered as a long heavy process which involve environment preparation and hours of coding.
Using Averos Designer you will be able to build this application in minutes.

Next, we will delve deeper into Averos Designer and generate our application.

Let’s do this ! 🚀