Objective
Business requirements are necessarily partial and biased and symbolic representations must be defined accordingly, which means to remove irrelevant contexts and features.
Scope
Artifacts are said to be abstract when they cannot be directly mapped to actual counterparts. Applied to analysis models it means categories descriptions without extension as business objects; applied to design models it means classes to be used to create software components; power-types are dual, being both descriptions and surrogates. Strictly speaking symbolic representations (aka surrogates) should always be concrete, at least at requirement levels; abstract representations are one step up in abstraction layers, already detached from business requirements, but not yet the source of system implementations. They should not be confused with partial descriptions, which are one step down towards the description of system components.
From an engineering point of view, that requires some justification, namely (1) how do they appear along the modeling process and, (2) why are they needed afterwards. Roles and partitions are to answer the how, architectures the why.
Partitions and Roles
Roles describe the part played by objects into activities and, by so doing, roles put the focus on some aspects while ignoring the remainder. As such there is not enough justification to introduce object abstractions which cannot emerge until aspects can be detached from their native context in order to be used within different ones.
Whereas roles can introduce abstraction from activity perspective, subsets and partitions do the same from the object perspective by factoring out features whose values are set uniformly by subsets of objects or activities. Here again, that’s not enough to justify abstractions, until those subsets can be associated to additional features.
Object Variants
Hence, depending on identification mechanisms and usage, variants at requirements level can be described by partitions, subsets, or roles.
Activity Variants
Behavior variants are associated to extension points and can should be described on the same principles as object variants if models are to be consolidated at analysis level. From that point of view controls may be seen as a kind of abstraction since they describe behaviors shared by all variants.
From Requirements to Analysis Models
Broadly speaking, system architectures can be described as the set of resources and constraints with which business processes have to make do. Along that line of reasoning, the architectural contents of models are due to be fully detached of any reference to actual business objects and processes, ie without extension. In other words architectural features are meant to be described by abstract representations, and that is the main rationale behind abstract qualifiers in analysis models.
Hence, the problem is to understand how such a rationale should govern the translation of requirements models into analysis ones, i.e how the roles, subsets and partitions obtained from requirements should be mapped into types and subtypes defined by analysis:
- Given a single set of identified objects, specialization will add specific descriptions to its subsets.
- Given different sets of objects, each with its own identification mechanism, generalization will introduce an abstract description to be applied to all sets.
It must be noted that specialization and generalization are not symmetric: while the former add to existing descriptions without modifying them, that is not the case for the latter which introduces shared features with possible impact on native ones.
As mentioned before, architecture is first and foremost a matter of coupling constraints between contexts and system representations, persistent or transient. Given a rigorous identification of persistency and transient units and built-in traceability, built-in checks can be performed on abstractions introduced with analysis models:
- If identifiers are managed independently in requirements models, they must remain as such in analysis types and subtypes.
- Conversely, if requirements objects are governed by the same identification mechanism, it must be represented as such by analysis types and subtypes.
As far as identification mechanisms are concerned, traceability may be applied both across model layers (e.g requirements > analysis > design) and abstraction levels, and the later open the way to external consistency validation using the Liskov Substitution Principle.