Pattern:
Layers


Author

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal

Intent

"The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction." (Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996)

Motivation

The idea behind the Layers pattern is to structure your system into an appropriate number of layers and place them on top of each other. Start at the lowest level of abstraction--call it Layer 1. This is the base of your system. Work your way up the abstraction ladder by putting Layer J on top of Layer J-1 until you reach the top level of functionality--call it Layer N. Note that this does not prescribe the order in which to actually design layers, it just gives a conceptual view. It also does not prescribe whether an individual Layer J should be a complex subsystem that needs further decomposition, or whether it should just translate requests from Layer J+1 to requests to Layer J-1 and make little contribution of its own. It is however essential that within an individual layer all constituent components work at the same level of abstraction. Most of the services that Layer J provides are composed of services provided by Layer J-1. In other words, the services of each layer implement a strategy for combining the services of the layer below in a meaningful way. In addition, Layer Js services may depend on other services in Layer J. For a more detailed Motivation description for this pattern see: Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996.

Known Uses

This pattern has been used on the following systems: Virtual Machines. The lower levels, virtual machine, insulate the higher levels from low-level details or varying hardware. (Example: Java Virtual Machine - JVM) Code written in Java is transformed into platform-neutral binary code. JVM is platform-specific in that there are different implementations of the JVM for each operating system and processor. The Java binary code is delivered to the JVM for interpretation. This two-step translation process allows platform-neutral source code and the delivery of binary code, while maintaining platform independency. APIs (Application Programming Interface). The API layer encapsulates lower layers of frequently-used functionality. An API is usually a flat collection of function specifications such as UNIX system calls (i.e. open() or sbrk()) or operations in the C standard library (i.e. printf() or fopen()). Information Systems (IS) is a business software domain. The layers include from top to bottom: Presentation, Application logic, Domain, and Database. Included in those layers are the user interface, application, model of the conceptual structure of the problem domain, and the database which holds the company-specific data. Windows NT has the following layers: System services (interface layer between the subsystems and the NT Executive), Resource management layer (contains modules such as Object Manager, Security, Local Procedure Calls, etc.), Kernel (takes care of basic functions; i.e. interrupt and exception handling, etc.), Hardware Abstraction Layer (hides hardware differences between machines of different processor families), and Hardware. The principles of the Layers pattern are relaxed as the Kernel and the I/O manager access the underlying hardware directly for better efficiency. (Custer, H., Inside Windows NT, Microsoft Press, 1993.)

See Also

Microkernel and Presentation-Abstraction-Control patterns

Thumbnail

Keywords

behavioral patterns, Layers pattern, Presentation-Abstraction-Control pattern, Microkernel pattern, Buschmann patterns, layer, system decomposition

Business Domains

any system providing layers to abstract complexity

Problem Forces

frequent change requests/requirements changeglobal system task decomposes naturally into several processing stagesneed to layer subsystemsneed to provide abstraction between subsystem and client

Benefits

enhanced maintainability and extensibility of the systemreusabilitysupport for standardization

Liabilities

can be expensive on system resources if large volume of datarestricted efficiency

Implementation Files

Simple implementation of the pattern. Layer.javaSimple implementation of the pattern. layers.h



Generated on Fri Oct 20 11:13:17 GMT+02:00 2000 by Framework Studio