Columns

Where do components come from?

• By John D. Williams
• June 1, 2001

It seems like a simple question. Obviously, the stork brings them. Or maybe it's a little more complicated than that. The use of component technology continues its rapid rise. Sam Patterson of ComponentSource estimates that the component market needs between 20,000 and 40,000 components to hit critical mass. Currently we are only about one-third of the way there. Where will all the components developers need come from? Clearly, they will have to build many of them themselves. If they want to get real value from their work, some of the components they create need to be reusable. It's not enough to guess which ones might be reused elsewhere. It's better to have a process that can truly help to determine which components have reuse value.

One way to do this is to look at a domain architecture and see what components should be common to applications within the domain. Unfortunately, many companies don't have domain architectures. The Software Engineering Institute (SEI) has defined a domain engineering process that can help create a domain architecture. Domain engineering consists of domain analysis, domain design and domain implementation. The SEI defines domain analysis as "the process of identifying, collecting, organizing and representing the relevant information in a domain, based upon the study of existing systems and their development histories, knowledge captured from domain experts, underlying theory and emerging technology within a domain." In short, domain analysis is gathering and organizing information about a domain. Domain design is understood as "the process of developing a design model from the products of domain analysis and the knowledge gained from the study of software requirement/design reuse and generic architectures." A generic architecture can support most applications within a domain. Domain implementation is "the process of identifying reusable components based on the domain model and generic architecture." This fits within the SEI's product line architecture approach. This process should help to identify which components have the most reuse value. This only partially answers our question. Some reusable components can be found in your domain architecture. Existing domain knowledge and information modeling techniques provide input to the domain analysis process. There are some approaches within knowledge engineering that can provide input into domain analysis and help us identify component candidates.

Knowledge engineering has much in common with component engineering. It focuses on reuse. The information gathered in this process is similar to that in domain analysis, but from a different perspective and with a different emphasis. There are some new concepts here, but I believe they can be applied usefully to component engineering. Just as there are multiple methodologies in the component world, the same is true for knowledge engineering. The methodology we'll explore briefly here is called CommonKADS. But let's first take a brief look at knowledge engineering and how it works.

To define knowledge engineering we need to examine some of its principles. Years ago, knowledge engineering was thought of as something akin to scooping knowledge out of an expert's head and putting it into a form a computer could use. This analogy is not accurate. Knowledge engineering is about constructing models that show various aspects of a chosen domain. Knowledge-based systems have proven to be more complex and context-dependent than many people originally thought. For this reason, a modeling-based approach provides a good method of identifying and organizing knowledge.

As with component analysis, knowledge engineering initially works at a higher level of abstraction. You don't want to be dragged down into implementation details. Your original focus should be on a conceptual structure of knowledge. This focus covers the breadth of real-world knowledge in the knowledge domain—organization, processes, people, behavior and systems. Modeling at this level is independent of implementation issues. Systems that are derived from this conceptual level are viewed as structure-preserving systems.

Another principle is rooted in the belief that knowledge has a structure that can be analyzed by identifying specific knowledge types and roles. Understanding knowledge isn't simple, but, while it is rich and complex, it is not random or chaotic. Knowledge engineering operates on the principle that knowledge has a stable internal structure. Knowledge engineers believe that this structure can provide the basis for modeling. Modeling lets us arrange knowledge into categories, structures and patterns. These parts of knowledge can play different roles in problem solving. This combination of types and roles gives us the organization of knowledge.

Knowledge projects are managed and developed iteratively. Like component engineering, you can't learn everything you need to know at one time. Iteration is required to plumb the depths of a domain's knowledge. The rigid waterfall approach isn't flexible enough to uncover the breadth of structures in a knowledge domain. Rapid prototyping is too ad hoc to create meaningful structures of knowledge. Iteration allows a thorough and deep approach to gather information.

Let's look at how CommonKADS organizes knowledge. There are several models in the CommonKADS aspect model structure. The first set of models defines the context of the knowledge domain and organizational environment. The first model is the organizational model, which helps you analyze the organization and understand the opportunities for, and the impacts of, knowledge systems. The organizational model has two levels. The first is organized by problems and opportunities, organizational context and solutions. The second level is focused on more specific categories: structure, process, people, resources, knowledge, culture and power.

The second context model is the task model. These tasks are business processes and their various subprocesses. The task model is broken into task, organization, goal and value, objects handled, timing and control, agents, knowledge and competence, resources, and quality and performance. Using these attributes, the model looks at inputs, outputs, pre- and post-conditions, as well as other aspects of the task.

The third context model is the agent model. Typically, when we think of agents, we think of software agents. While these could be included, agents in this model are the executors of a task. An agent may be a person or a machine, an information system or a software agent. The model's agent attributes are name, organization, involved in, communicates with, knowledge, other competencies, and responsibilities and constraints.

The next two models, knowledge and communication, provide the conceptual description of problem-solving functions and data. The knowledge model details the types and structure of knowledge used to perform a task. It characterizes the role different structures of knowledge play in problem solving. Knowledge is broken into task, implicit and domain knowledge. This model is a key for communicating between experts and system users.

The communication model characterizes agents' interactions and the transactions between them. Its attributes are transaction identifier, information object, agents involved, communication plan, constraints and information exchange specifications. It is above the implementation level and is conceptual in nature.

The design model is at the artifact level. In this model, the requirements defined in the other aspect models are turned into architecture for a software system. This model and the modeling work of component engineering overlap. The design model uses UML notation.

In knowledge engineering, you can think of this collection of models as an ontology. Here, an ontology is defined as a formal specification of a shared conceptualization. Think of it as an abstract model of some phenomenon in the world. In this model, you capture the type of concepts used and the constraints on them. This type of information can provide valuable input into domain architectures. Currently, companies are using domain ontologies to define business domains and drive the underlying systems that support them. One area where this is happening is in the B2B domain. Ontologies also provide meaningful communication between systems. They can provide the basis of understanding and mapping from one framework to another.

So where do components come from? One answer is ontologies. You can build an ontology, develop domain architectures and templates from it, and create component-based systems that facilitate the sharing of information based on the ontology. This approach can be a valuable addition to the current set of tools for defining and building component-based systems.