Sample Selection
SECTION 3: Architecture
A (software) architecture is the high-level plan or strategy for building an application. Our focus here is on logical architecture—the way the software is conceptually organized.
3.1 Three-Tier Architecture
We usually take a three-tier approach in building our applications [2]. As Figure 3.1 illustrates, software consists of three logical layers.
* Back tier—a server that manages persistent data stored in a database or files. (Chapter 4 presents the back tier for softcoded values.)
* Middle tier—application code that provides functionality and relies on the back tier to store and retrieve data. Developers can write application code in a programming language such as C++ or Java as well as within the database using stored procedures, triggers, and views. (Chapter 5 presents the middle tier for softcoded values.)
* Front tier—the user interface that accesses functionality, often via forms and reports. (The front tier is outside the scope of this ReadyNote.)
All three tiers ensure data integrity. The user interface checks the data entered into forms and helps users fix mistakes. The application tier performs the detailed checking. The data management tier maintains consistent data, despite access by multiple users and applications. The three-tier architecture generalizes into n-tiers when there are multiple applications. Each application can have its own user interface and data management with the application layers calling each other as appropriate.
3.2 Hardcoded Model for Populating Metadata
Metadata can be difficult to grasp. It is often helpful to prepare a hardcoded model as an intermediate step and use that to populate the metadata. Many persons understand the hardcoded model better than the metadata—they can readily see the concepts, relationships, and constraints. You can then use the hardcoded model to populate metadata.
The construction of major industrial facilities, such as power plants and refineries, involves many kinds of equipment. Each kind of equipment has its own attributes that depend on the purpose (such as simulation, equipment design, or operational data). Figure 3.2 shows a small excerpt of an equipment model that we will use as an example. The italics font for the class name (Equipment, Pump, Tank) is UML notation for an abstract superclass—a class that has no direct objects and can only be assigned objects via subclasses.
3.3 Mixing Hardcoded and Softcoded Attributes
Application classes may have hardcoded as well as softcoded values. Softcoded attributes are defined with Figure 2.1. In contrast, a hardcoded attribute is included in an application class. (Figure 1.1 illustrates the distinction.) This mixed approach lets an attribute be defined either way. It is unacceptable to have ambiguous usage, so we need a convention to determine when an attribute is hardcoded or softcoded. Our convention is to hardcode system attributes and softcode all other attributes, as Table 3.1 explains.
Given the rationale for softcoding, it is clear that you should softcode attributes that are uncertain and may not be known until runtime. For simplicity and improved performance, you can hardcode the other attributes.
Some attributes have a critical effect on queries and if you hardcode them you can improve performance. In particular, you can build database indexes for hardcoded values which can improve performance by as much as a few orders of magnitude. Softcoding is not amenable to database indexes because values from different objects and attributes are mixed together. Softcoding can be desirable when there are multiple values for an object–attribute combination. Relational database tables are flat, and hardcoding consequentially limits an object-attribute combination to at most one value.
Also softcoded values facilitate value metadata. Each value has its own record so it is easy to attach additional information. In contrast, value metadata is clumsy with hardcoded values. For example, we could add the attributes suctionPressureDataSource, suctionPressureUnitsOfMeasure, suctionPressureLastUpdate, dischargePressureDataSource, and so forth to Figure 3.2. However, you can see that the number of added attributes can quickly become unwieldy.
In summary, it is important that you have a clear policy for choosing what attributes to softcode and hardcode. Your policy can be different than we suggest, but it must be unambiguous. You are likely to have confusion and bugs if it is unclear whether an attribute should be softcoded or hardcoded.
A (software) architecture is the high-level plan or strategy for building an application. Our focus here is on logical architecture—the way the software is conceptually organized.