The Taligent Operating Environment

By David Sharp, Richard D. Hoffman and Mary Beth Kelley

AIXpert August 93

This article is the first of a two-part series. It provides a brief overview of object technology and discusses the basic design philosophy of the Taligent operating environment. The second part, to appear in the next issue of AIXpert , will discuss frameworks and strategies for assimilating Taligent's technology into the marketplace.

In 1991, IBM, Apple Computer, and Motorola joined together as they entered into five history-making initiatives that will dramatically impact software development:

Joint design of the PowerPC chip
Formation of the PowerOpen Consortium
Formation of Taligent, a separate company
Formation of Kaleida Labs, a separate company
Cooperative effort for interconnectivity between Apple and IBM products

IBM and Apple initially discussed a possible collaborative effort to design a low-cost, high-performance RISC chip (these discussions eventually led to the PowerPC), but the talks soon broadened to include other areas of mutual interest. One of these areas was the promise of a fully object-oriented approach to application development. Not only did IBM and Apple have uncannily common views in this area, but they both had significant efforts underway to turn their object-oriented vision into reality.

Within Apple, a team of more than 100 object-oriented programmers were working on a future operating system environment, code-named Pink, that was fully object-oriented. At IBM, a group of object-oriented programmers were working on a similar model at the application level. IBM also had a significant investment in Patriot Partners, a joint effort with Metaphor(TM) to develop an object-oriented layer on top of existing operating systems. By combining their efforts, what better chance would IBM and Apple have for affecting the industry?

Thus, Taligent was founded in March 1992 as an independent system software company. The name Taligent is a combination of the words "talent" and "intelligent." The company is developing a revolutionary system software environment built entirely with object-oriented technology. Taligent's goals are to dramatically improve the pace of software development, to ignite a new generation of horizontal and vertical applications, and to create an environment that accelerates the development of innovative hardware technologies and products.

Overview of Object Technology

Taligent will provide a completely object-oriented system software environment. To understand how this system will be built, a review of some basics about object-oriented programming is necessary.

Objects

The basic building block of object-oriented technology is a programmable object that represents an abstraction of a real-world object's state and behavior. A set of data elements represent the state, while methods--a set of functions that can directly access and change the state--represent the behavior.

For example, to represent an employee as an object in an application, the employee's state could be represented by name, job grade, salary, and department¹. The behavior would consist of valid ways to change the employee's state. The object could look similar to Figure 1 (text).

The object's methods provide its interface. These are the only ways to alter the object's state. Programs that use the object's interface are called clients. Because the data is hidden from the outside, objects encapsulate their data.

A strength of the object model is that new items can be added to the state without changing the interface. If SocialSecurityNumber needs to be included in an employee's record, it can be added to the object without inconveniencing the clients of the current interface. The implementation of the object's methods can also be changed without changing the interface. For example, Salary can be computed from job grade. The Salary item can be eliminated, and GetSalary() can be changed to reflect the new computation. Contrast this with procedural programming, where if Salary were accessed directly throughout the program, the developer would have to make a change at each place it is accessed.

Classes

Usually if one object is needed for a program, several others of the same type will also be needed. Reproducing the object definitions (shown in Figure 1) for each employee represented in the program would be a tedious task that could result in errors. But it is easy to abstract the information about an object into a class and to use that class as a template for the object. Thus, the object in Figure 1 becomes the abstract class shown in Figure2 (text).

Notice that a class has no life of its own. It exists only to make object definitions possible:

    Class Employee: Employee1, Employee2, Employee3

Employee1, Employee2, and Employee3 have the same interface, but each Employee object needs its own state so that it can be distinguished from other Employee objects. Object derived from a given class are called instances of that class.

Figure 3 shows the relationships among objects, classes, and the real world.

Figure 3. Abstraction and instantiation: classes and objects

Messages

When the representation of the object's state is unknown to its clients, it is often called information hiding. When information hiding occurs, clients communicate with an object solely through the interface.

Client-object communication can be thought of as a series of messages in which each message represents an instruction to the object to execute one of its methods. The returned value of the method is the response to the message. Sometimes messaging is accomplished figuratively by direct invocation of methods; sometimes literal messages are sent through a communications medium. Figure 4 illustrates this relation.

Figure 4. Messaging between objects

Inheritance

Relationships between objects can also be abstracted. The "is a" relationship is particularly useful; for example, "a poodle is a dog," or "a manager is an employee." In object-oriented programming, a technique called inheritance exploits this relationship to create new classes from old ones.

For example, if a Manager object needs to be supported in the model, an item such as IsManager can be added to the Employee class. New methods can be added to handle manager-only behavior. Conditional processing can be added to existing methods in which managers must be distinguished from non-managers. (In fact, this is exactly how a non-object-oriented program would be coded.) However, this approach presents several difficulties:

Each time a new attribute is added to the class, new methods must be added. The number of these specialized methods increase with the class, until the class contains a large and confusing set of methods that are not often used.
The code inside the methods that must handle special cases will also increase as the class grows, resulting in the loss of some advantages of the object-oriented model.
The opportunity for error grows as the class becomes more cluttered with special cases.

Alternately, the developer can subclass or create a new class based on an existing class. The existing class is usually called the parent. In this example, a Manager class can be created as a subclass of the Employee class as follows:

         Class:       Manager
         Parent:      Employee
         State:       String         DeptManaged
         Methods:     String         GetEmployeeList()
                      Number         GetSalary()

Because the Manager class is descended from the Employee class, it inherits the state and interface of Employee. Even if it is not specified explicitly, the Manager class includes the elements Name, Salary, Grade, and Dept, as well as the methods that act on them.

Notice that GetSalary() appears again in the definition of the Manager class. The example assumes that a manager's salary will be calculated differently from that of a non-manager. When subclassing, the developer is allowed to override methods of the parent class with new methods that have the same name. There is no ambiguity here because the developer knows (and the compiler knows) to use the method that is most closely associated with the object being used.

Figure 5 illustrates inheritance. Some systems support a model called single inheritance, in which subclasses can have only one parent. Other systems (such as Taligent) support multiple inheritance, which allows subjects to inherit data and methods from more than one parent.

Figure 5. Inheritance

Polymorphism

Since managers' salaries are calculated differently from employees' salaries, consider the following example. To display the summary of an employee, which consists of that employee's name, department, job grade, and salary, traditionally different summary functions for each class are needed:

       If IsManager(Emp) then
            SummarizeManager(Emp)
       else
            SummarizeEmployee(Emp)

This has the same disadvantage proposed for classes without inheritance. Eventually, many classes and subclasses will turn a program into a morass of if-then-else statements and specialized functions. Instead, the developer can take advantage of two aspects of the inheritable model:

Members of a given class are also members of the parent class. (Inheritance implements an "is a" relationship.)
Functions of a class can be overridden with those for a subclass, but the developer must trust that the appropriate function will be invoked at the right time.

Thus, the developer can code the summarize-employee function as follows:

       Procedure: Summarize(Employee Emp)
            Display Emp.GetName()
            Display Emp.GetGrade()
            Display Emp.GetDept()
            Display Emp.GetSalary()

The system will ensure that the right GetSalary() method will be invoked, depending on the subclass of the employee being summarized. This technique is called polymorphism.

The code for Summarize would not look different even if it were created before the Manager subclass was created. This illustrates the great power of polymorphism: it allows the specialized behavior of new classes to be used in existing procedures, even if they were written without knowledge of the new subclass. Taligent uses this feature extensively to provide frameworks for basic activities that can later be extended in ways not considered by the original designers.

Summary of Object-Oriented Concepts

The techniques of abstraction, encapsulation, inheritance, and polymorphism form the foundation of object-oriented programming. They allow the developer to do the following:

Simplify designs by abstracting those attributes, and only those attributes, of real-world systems that the developer wishes to model
Reduce opportunities for error and confusion by encapsulating the attributes and behavior of real-world items into objects
Reuse and extend the models with inheritance
Reduce redundancy and increase flexibility through polymorphism

Taligent makes full use of all these techniques to provide users with a powerful, extensible system.

Taligent's Approach to Object Technology

Taligent has set a philosophical and technical framework for the development efforts behind its operating environment. As a philosophy, the company intends to deliver a system software platform that realizes the full promise of object technology. Taligent's approach is not to use screen icons masquerading as objects or to use large, existing procedural code encapsulated with object code. It is more than object libraries on top of monolithic operating systems. Taligent's operating environment will be distinguished from other system software platforms by its unique architectural approach and the comprehensive use of objects and frameworks. This approach and use provides a single software development paradigm.

From a technical design perspective, the Taligent operating environment, when released, will have the following characteristics:

Development productivity: As a breakthrough in software development productivity and innovation, Taligent will employ frameworks throughout the system to address all levels of system and application services. The following is a useful definition of a framework as used in this article: "An abstract class is a design for a single object. A framework is the design of a set of objects that collaborate to carry out a set of responsibilities. Thus, frameworks are larger scale designs than abstract classes. Frameworks are a way to reuse ... high-level design." ²
Because frameworks are developed using the very techniques that make object programming useful to the program building blocks themselves, frameworks remove much of the complexity of today's object-based systems. They allow developers to focus their unique skills and domain knowledge on solving the application problem.
Taligent frameworks will provide standard interfaces. Third parties can plug their specific implementation of a technology innovation into these standard interfaces without fear of incompatibility.
Once an innovation is plugged into the Taligent operating environment, any developer can leverage its capabilities to create even more innovations. The framework concept will allow all developers to contribute to the environment, ensuring a free-market approach to innovation.
Open and extensible at all levels: For the first time, third parties will be able to add value to the application, system software, and development environments. This will create new opportunities for developers to incorporate best-of-breed, plug-and-play capabilities into the Taligent environment. Examples of these capabilities are color, animation or video technologies, and new development tools. In addition, Taligent is designing the environment to operate in the international market so that it will be globally open for extension by software and system vendors.
Extensive native functionality: Taligent's environment will include those features that have their greatest value when integrated at the base level rather than added as an option. All applications benefit because they can rely on features that are integrated as part of the system software.
Portable, adaptable, and scalable: Taligent's environment will be processor independent. An entire range of hardware, from very high-performance workstations to low-cost notebook systems, will be assured of software compatibility and interoperability. At the same time, the environment will encourage hardware innovation to take new shapes and sizes.
Integrated development tools: Taligent will offer a suite of development tools designed for rapid application development and customization. These tools will range from viewers and editors to debuggers and languages. They will employ a framework that allows third parties to create tools that can be quickly integrated into Taligent's development environment.
Compatibility and investment protection: Support for existing environments will protect current software investments. The Taligent operating environment will provide a way to use both data and applications from existing system software platforms.

The Taligent Solution

Taligent intends to deliver product offerings with the following functionality:

A modern desktop operating system
Extensive class libraries
Application and system frameworks
An extensible development environment

The architecture of Taligent's operating environment is simplified in Figure 6. The operating environment is implemented on top of a modern microkernel, with object interfaces presented to the higher level services above the microkernel. The microkernel layer contains hardware-specific code that can be modified or replaced to target the Taligent operating environment to other hardware platforms.

Figure 6. Taligent operating enviroment

An application and services environment is on top of the microkernel. Applications and services, such as the desktop and file support, reside in this section. They are constructed by inheriting needed functionality from one or more base classes in the provided class library and by applying additional functionality as needed. Frameworks are provided throughout this application section. They represent a collection of classes brought together to perform some useful higher level services that may be needed to simplify building an application. Figure 6 also depicts an important concept of openness, in which all interfaces and services in the application section are available to any developer. As an example, the same interfaces and frameworks used to implement the Taligent development environment are available to other developers. From an architectural point of view, frameworks in the application and system layer are pervasive, and they open the Taligent operating environment to third parties and users.

Taligent's strategy for helping tools developers tackle the complexity of the 1990s software world incorporate three critical elements:

Combining objects into a library of highly reusable, richly expressive, and integrated frameworks
Extending these frameworks into the system services level of the environment
Creating an object-oriented development environment specifically and intimately connected to the framework approach to software design

Part two of this article, to appear in the next issue of AIXpert, will more fully explain frameworks and will discuss Taligent's and IBM's strategy to assimilate Taligent's technology into the marketplace.

Note: Special thanks go to the Taligent employees contributing to "The Intelligent Use of Objects" and to Mike Potel, Taligent's vice president of Technology Development, for clarifying work that was liberally used in developing this article.

David Sharp , Taligent, Inc., 10725 North DeAnza Boulevard, Cupertino, CA 95014. Mr. Sharp manages Taligent's Project Office and has responsibility for Taligent's relationship with its investors. He joined Taligent as a founder from IBM where he had managed knowledge based systems and programming languages development at IBM's Santa Teresa Programming Center. He has a BS in Engineering from North Carolina State University.

Richard D. Hoffman , IBM Corporation, 11400 Burnett Road, Mail Stop 9370, Austin, TX 78758. Mr. Hoffman is IBM's technical liason to Taligent. He is responsible for the exchange of technical information and the resolution of technical issues between IBM and Taligent. Mr. Hoffman holds a BSc from the University of Sheffield in the U.K. and a PhD in Mathematics from the University of Texas.

Mary Beth Kelley , IBM Corporation, 11400 Burnett Road, Mail Stop 9370, Austin, TX 78758. Ms. Kelley is the IBM senior manager of the Taligent Project Office where she is responsible for owning IBM's relationship with Taligent. She is also the planning and strategy manager for the Object Technology Products Business Area, part of IBM's Personal Software Products Division. She has a BA from the University of Texas and has completed the University of Texas Management Institute program.

1 The level of abstraction is important and depends on the purposes for which the object is being modeled. For example, most businesses are not interested in a employee's blood type. But this information could be required for workers in a hospital.

2 Johnson, Ralph E., and Vincent F. Russo, Reusing Object-Oriented Designs. University of Illinois and Purdue University. 1991.

[ Aug93 TOC | Next Article ]