Abstractions are reusable but unspecific, Specializations are specific but not reusable
Entities used to represent a domain can be "typed" to varying levels of strength, depending upon the depth of knowledge the entities are required to represent. Weakly-typed entities can be used to represent a broader variety of situations and facts, but will lack the specification to deal with variations in those situations and facts. Strongly-typed entities take into account broader diversity and variety through incorporating specific attributes and relationships, but are far less reusable than weakly-typed entities.
As an example, let's consider a planning model used to manage projects where people, equipment, buildings, and vehicles are utilized. A weakly-typed entity "Resource" can be used to model people, equipment, buildings, and vehicles, without considering their differences, usage, or behavior. A Resource, in this model, will have an availability at any moment of time, and the planning model will be able allocate or deallocate a Resource to a Task within a Project. A planning application, built from a weakly-typed model, will be able render generic views about how Resources have been allocated within a Project. Figure 1 illustrates a weakly-typed model for Resources, and an application creates views from such a model.
Fig.1: A weakly-typed model for Resource Planning where all things are modeled as Resources
Reducing all of the different types of things that participate in Projects to Resources is only useful if the system that uses such a model requires no other information about the Resources. While people and equipment are used for any 1 purpose at any given moment of time, buildings are shared resources that can be used by several people at the same time. It is also possible to allocate a number of tasks to people or equipment, and leave it to them to complete the tasks at their own pace. For instance, an individual person may receive any number of tasks at the beginning of a work week, and complete them to the best of his or her ability, while balancing their total capacity, over the course of that week. Similarly, a software application used to process tasks can be assigned several tasks simultaneously, and it can be designed to mimic human processing, by placing all of he tasks in a queue, and processing them one by one depending on available capacity. In both of these examples, Capacity emerges as a common concept, and expanding the weakly-typed model to cover "Capacity" provides the additional capability to allocate more than 1 task to the same Resource.
Fig.2: A extended weakly-typed model for Resource Planning where all things are modeled as Resources
There are other significant differences between Resources. People, for instance, have preferences on what kinds of Tasks they would like to do. They also have varying levels of skills for the same Tasks. Some equipment can require handling instructions (e.g. while a hammer is not a accompanied with instructions, jackhammers usually are), be applied within specific environments (e.g. an airplane can only go up to a certain height, or a deep-sea drill can be operated up to a specific depth), or can only be used in conjunction with other equipment (e.g. a large screwdriver cannot be used to remove small screws). A planning system that needs to understand the characteristics of equipment, or the skills of people, will need require deeper extension into these areas, resulting in a strongly-typed model. For instance, a planning system that allocates airplanes to routes will need to understand the capabilities of airplanes. It would need knowledge of the load capacity to determine how many people and how much cargo each airplane can carry. It would need knowledge of the total distance an airplane can fly with its maximum load, and the maximum distance it can fly with its optimal load. A strongly-typed model would capture all of these characteristics, and it would be capable of making decisions on the optimal resource for each task, such as determining the optimal airplane and pilot to fly a specific route. The depth of knowledge of airplanes and pilots possessed by such a planning system is achieved at a compromise in forsaking its flexibility to process other domains of knowledge (e.g. allocating software programmers to programming tasks).
Fig.3: A medium-typed model for Resource Planning, with specialized extensions for People and Equipment
Strongly-typed models, thus, are achieved at the cost forsaking reusability, and weakly-typed systems are achieved at the cost of forsaking specific knowledge of a domain. A balance between weakly-typed and strongly-typed systems can be achieved identifying universal patterns in all of the different domains that require coverage (e.g. airplane planning, ship planning, programmer planning, etc.), and then modeling attributes and relationships as weakly as possible. For instance, modeling the Capacity of a human resource and equipment has the common denominator of Load. The attributes of Load can be characteristics like Minimum Load, Maximum Load, and Optimal Load. Specializations of Load can be Carriage Load (the load that can be carried by a resource) and Processing Load for specific Tasks (the volume of a specific kind of task that can be assigned to a resource).
Avoid reflecting the Processing Model (weak or strong) in the User Interface
A common error made by System Designers is to use a Processing Model to structure how end-users will interact with the System.
A user interface that forces its users to understand its underlying abstractions turns the power of a weakly-typed model into a weak user interface. Users must be able to deal with phenomenon they are familiar with in their own environments, and a good user interface ties its elements to facts and situation users encounter in their environments. Furthermore, the reduction of people to "just resources" might be convenient for creating a flexible model for a computer system. The danger is that such a model might be applied in real life, and the distinction between people and physical equipment might be become blurred. It rests on the System Designer not to create de-humanizing solutions, although creating reductionist user interfaces often has that unintended result. A good example is the Spreadsheet, which has perhaps the most weakly-typed model possible in a software application. A spreadsheet that models all costs within an organization can reduce humans and equipment to being represented by a common denominator that isn't an intrinsic characteristic of either. Neither people or equipment have the intrinsic attribute of having a "cost", unless they are viewed through the lens of a reductionist cost model.
