/ Development  

How to make abstraction, generalization and subtyping possible

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

This time we are taking a deeper dive in our Project-case from where we already created 2 entities. The ‘Project’ and the ‘ToDo’. They are tightly related to each other with the advances option on the ‘ToDo’ entity that is telling us that a project can’t be deleted when it is referenced by a project…Nicely done so far, but there is more to do so…

Let get right into it…

And the first thing we need to do is make an entity plan what type of entities could be created and used in our application. As this is the fundament of our application it is good to make a proper overview. This view gives us good information on how the entities are connected to each other and how they will work together. Such a plan has a name and we call it an ‘Entity Relationship Model‘ and is based on the data-driven design for implementing business objects. Big words for something simple. It can only take some discussion before you reach the final state of your diagram that matches your case.

For our project-case we will use this model. It is crafted from the nicely available draw.io website.

erd_001

Some explanation:

  • SecretProject is a ‘subtype’ from Project. Both can be created as an entity instance, but ‘secret’ means something….’secret’! This is also called a hierarchical structure with parent (supertype) and child (subtype). Or in other words (to complete all the terminology) generalization (more generic) and specialization (more specific). The advantage of subtyping is that all the information of the supertype is inherited. In the AppWorks platform is this all the Building Blocks created on the parent entity like for example the properties, but also the forms etc.!
  • The same is done for the Member/Developer extension. But the extra part is the {A} reference. This means that the Member is abstract. And this means you can’t create an instance of the Member entity. Very handy if this is required!
  • The other lines between the entities are the relations and the notation of what kind of relation it is. So, the Member entity has a 1..N relation to the ToDo entity. And it is an optional relation as noted with the small circle on the ToDo side of the relation. The Category to the Task relation is also a 1..N, but this time it is required (you probably see why….right?).
  • Then we have the hasParent/hasChild relation. These relations are more tightly together and belong to each other. We can also refer to these relations like a ‘repeating item’. So, the ‘ToDo’ entity can have optional Tasks applied, but when the ToDo item is deleted all the tasks will also be removed automatically.

Now let’s start low-coding in our environment. Spin-up the VM, login with the Developer role and open the workspace of your choice.

The first thing you might have noticed is that we already created 2 entities and they are also related to each other (with the toOne/toMany…remember?). But as you checked out the above image the relation is not crafted like it is documented…Shame on us, but this is also a good practice and the relation we created is almost the same as we restricted the deletion of the project when ‘ToDo’ items are referenced to it!

Enter the entities folder created from the previous posts and right click the ‘project’ entity. From the context menu you can select ‘Create subtype’. Save the new entity with name ‘project_secret’. We didn’t use the name ‘secret_project’ as we want to be more in line with the naming conventions! You might have noticed that you already see some ‘Building Blocks’ on the entity. Where would they be inherited from?

Next is the ‘Member’ entity. Right click the entity folder and create a new one. Save it with name ‘member’. With the ‘Member’ entity open click on the small ‘entity properties’ icon and make the entity ‘Abstract’.

erd_002

Now we can starts creating the ‘Developer’, ‘Reviewer’ and ‘Tester’ entities. They are subtypes from the ‘Member’ entity, so you know what to do now! Prefix the naming of these 3 entities with ‘member_’ so we know what the parent entity is.

Now we will add a ‘Tasks’ entity to the ‘ToDo’ entity. This time we don’t create a new entity, but we will open the ‘ToDo’ entity and add a new relationship like this:

erd_003

After clicking on the ‘Add’ button for the relationship you see something like this:

erd_004

What you see here is that the AppWorks Platform created a new entity with the name ‘HasChildTask’. You will not see this one in your project folder as it is an ‘internal’ created entity. How to open this one for adding Building Blocks? Just click on the link ‘HasChildTask’. To make it a tight connection with the parent ‘ToDo’ entity we create a new ‘has a parent’ relation on this ‘HasChildTask’ entity to the ‘ToDo’ entity like this:

erd_005

You see that the entity naming is not exactly ‘Task’ like in our ERM diagram, but it is more important to have a proper relationship naming. Later we will see that this name will be overruled with labels that will be available for the end-user and there it will indeed be ‘Task’

Next is the ‘Category’ entity. Create a new one from the entities folder and save it with name ‘category’. It all should like now like this:

erd_006

Most relations are already created by now, but we still missing some relationships.

  • Category to Task (= HasChildTask!) (and vice versa)

    • On the Category

    erd_007

    • On the HasChildTask (Don’t forget to make it bidirectional!)

    erd_008

  • Member to ToDo (and vice versa)

    • On the Member

    erd_009

    • On the ToDo (Also here; make it bidirectional!)

    erd_010

  • Project to Member (and vice versa)

    • On the Project

    erd_011

    • On the Member

    erd_012

Now we add some ‘special treatment’ to the created relationships as every relation has on ‘Advanced configuration’ which allows us to restrict users the deletion of an instances entity when it is referenced by another entity! By default, this option is enabled, but in some cases, we want to disable this option.

For example, the relation from ‘Project’ to ‘Member’ with the name ‘ToManyMember’. We don’t want users to delete our members when they are related to a ‘Project’!

It’s same for the ‘ToDo’ relation to ‘Member’. We also don’t want users to delete member when they are connected to a ‘ToDo’ item. And on this same ‘ToDo’ entity we have created a relation to the ‘Project’. We also don’t want to delete a ‘Project’ when it is referenced by a ‘ToDo’ item.

These settings make it all more tightly together on the highest level. Make sure that this fundament is correctly implemented so the project is nice and steady structured!

And this earns us the big ‘DONE’ for this post. We learned about creating new entities, creating ‘special treated’ relationships and building the fundaments of our project. Subtyping with the optional abstraction is key in reusability and now we know more about generalization with specialization. Not that hard if you know the context and usability within the product.

I will see in the next post where will start learning about validation, publication and testing. Have a good one and don’t forget to subscribe to get updates on the activities happening on this site.