On the Importance of Naming in Software Systems part IV
In my previous posts on naming I have laid the foundation for a framework for naming in software systems. This post is mostly a rehashing of those previous ideas and is intended to both codify and consolidate the definitions of terms upon which I have chosen and created to build a naming framework. It also serves as a single location to concisely reference these ideas. To gain more insight into the background and development of these ideas see my previous three posts: "A Survey of the Conventional Wisdom on Software Naming", "More Thoughts on Formal Approaches to Naming in Software", and "Software System Morphology". The definitions are as follows:
Structural
- Name – The Signifier that consists of a string of characters that refers to a System Referent.
- Name Unit Separator – is a mechanism to separate name units within a Name, this can be an explicit character such as "-" or "_". It can also be in implicit mechanism such as the use of Camel Case within the name.
- Name Unit – Is the smallest lexical unit of a Name usually separated by a Separator (Name Unit Separator) and is used to describe the lexical structure of the Name.
- Named Scope Context – this is the location of the Name within the system, e.g. where the name usage occurs.
- System Referent – This is the actual instance of a thing that is named and is used in the system. See System Referent Type for specific types of System Referents.
- System Referent Type - This is the specific type or class, as in classification, of what a System Referent is in a system some examples include:
- Classes
- Variables (local, instance, static)
- Methods
- Method Parameters
- Packages
- Database Tables, Columns, Triggers, Stored Procedures, etc.
- HTML Files, CSS Files, Javascript Files, Config Files, all files
- Directories
- Urls
- Documents
- XML Elements and Attributes
- CSS Classes
Semantic
- System Morpheme – This is a conceptual unit of meaning in a system that is used in a name, it is distinguished from a Name Unit in that a morpheme can consist of one or more Name Units.
- System Natural Language Set – This is the set of Natural Languages used to create the names. It is often English but it need not be and a system could include components or be constructed in a way that might include hybridization between multiple natural languages.
- Problem Domain - This is the Semantic Domain that describes problem area for which the system solution is targeted. This would be a set of concepts and System Morphemes that apply to the problem domain. For example a financial system would be built using the relevant financial terms and language concepts.
- Solution Domain – This is the Semantic Domain that describes concepts that are used to implement the system including System Morphemes that apply to the solution domain. This might include things like terms that describe Design Patterns, data structures, etc.
As you can see from above these Ideas can be separated into two categories: Structural and Semantic. However the two categories are not completely independent of each other so there is some overlap and interdependence. The structural ideas include: Name Unit, Named Scope Context, System Referent, and a System Referent Type. Each Name has these properties as attributes. A name has a lexical structure made up of Name Units, and refers to a System Referent of some System Referent Type and has one or more locations given by its Named Scope Context(s).
The semantics of the names which has the "unit" described by the System Morpheme idea has semantic properties which will fall into either the Problem Domain or the Solution Domain. The expression of these concepts is dependent on the System Natural Language Set, in other words the natural languages that are used to construct meaningful names for concepts in both the Problem Domains and the Solution Domains.
This is the current state of my thinking on this. These ideas will be refined and might change over time, the objective is to develop something that is useful and that both supports and can be validated by a more analytic approach.