There is nothing in the roadmap for setting up blueprint to document base classes (abstract) that your concrete classes can inherit from and then provide properties for defining views.
One of the underlying principles of blueprint is to keep the authoring aspects as simple as possible so that it is more approachable for business users. While blueprinting and defining UI for process steps while working with the business, I try to defer most conversations about the underlying structure except with lists or obvious data entities that show up along the way. The goal being to capture the information users need to complete a step as completely as possible and avoid being derailed by spending too much time talking about structure. There is, of course, a balancing act with that.
Once we have catalogued the data needed for a case, I go back and define the supporting structures working with the business to name the entities that attributes belong to. I’ll get that structure set up on my blueprint, update the views to use it and remove the scalars that got added to my case.
To address the question about using abstract classes, you called out vehicle and suggested subclassing for a specific type of vehicle, which could potentially be things like motorcycle, truck, car, boat. In principle, subclassing would allow us to override views in a baseclass on the fly when looking at a list of vehicles that contained all of the subclass instances in it.
Based on recent experience, I have verified that constellation can get upset when you try to overload this way. It seems to be ok if your base class contains all the properties for all the subclasses and then your subclassed view just uses parent class attributes. But when you add new attributes to your subclass and try to overload a view, especially if you are running transactions with it, Pega has a habit of kicking off errors. (I can provide more details on my experience with polymorphism and constellation, if you need.)
So, back to collecting properties from a parent, inheritance is nice but it complicates things more than they want blueprinters to have to deal with. Speaking for myself, I’ll often have people duplicate properties rather than add them to Org-Layer-Data- or Org-Layer-Work- simply because it is easier to understand what is used where. Also, if you can use composition (embedded pages), rather than inheritance you will get the availability of properties - but I also understand there are times where having a parent class and subclasses is better. In that circumstance, I would likely create the UI using the embedded base class and then add in the sub classes post-import and extend them as needed. Of course, if you are trying to leverage polymorphism specializing UI on the child classes but having them all show in a page list in constellation, you will likely encounter trouble. From a blueprinting perspective, even if you could set up the specialized relationship, there is no way to set up UI on a data class and then inherit and override it in a subclass and identifying content for process steps is one of the primary goals for blueprinting.
