Transcript Unit-6 - WordPress.com

Unit- 6
ARCHITECTURAL
PATTERNS - III
Engineered for
Tomorrow
Presented by
Sushma Narasimhan
Asst. Professor,
Computer Science Department
Unit-VI
• Adaptable Systems
 Microkernel
 Reflection
Adaptable Systems
Definition
 Systems that evolve over time
 new functionality is added
 existing services are changed
 must support
-
new versions of OS
user-interface platforms
third-party components
libraries
new standards
hardware platforms
 provide services that differ
from customer to customer.
Contd..
• Design for change is therefore a major concern when
specifying the architecture of a software system.
• Two patterns that help when designing for change:
i) Microkernel pattern - separates a minimal functional core
from extended functionality and customer- specific parts.
ii)Reflection pattern – an application is split into two parts :
a) meta level b)base level
Unit-VI
• Adaptable Systems
 Microkernel
 Reflection
Engineered for
Tomorrow
Microkernel
 Pattern Definition
 Example Resolved
 Context
 Problem
 Solution
 Structure
 Dynamics
 Implementation
 Variants
 Known Uses
 Consequences
Microkernel
Q: What does a Microkernel do?
A: Separates a minimal functional core from extended
functionality & customer-specific parts.
• Serves as a socket for plugging in these extensions and
coordinating their collaboration.
Example
• Suppose we intend to develop a new OS for desktop
computers called Hydra.
• Design goals
 must be easily portable to the relevant hardware
platforms.
 must be able to accommodate future developments
easily.
 must be able to run applications written for other
popular OS, such as
- NeXTSTEP
- Microsoft Windows
- UNIX System V
Contd..
• User has a choice of selecting the OS from a pop-up menu.
• Should display all currently running applications within its
main window.
Fig: Hydra Operating System
Contd..
 To emulate all these OS, Hydra will integrate special servers
that implement specific views of Hydra’s functional core.
 Ex: Emulation of Microsoft Windows by a server process.
Context
• Development of several applications
 that use similar programming interfaces
 that build on the same core functionality
Problem
• Application platforms such as operating systems and graphical
user interfaces
 have a long life-span, sometimes ten years or more
 new technologies emerge and old ones change
• Following forces have to be considered when designing such
systems:
 The application platform must cope with continuous
hardware and software evolution.
 The application platform should be portable, extensible
and adaptable to allow easy integration of emerging
technologies.
Contd..
Example
• Hydra is designed to run applications that were originally
developed for popular operating systems such as Microsoft
Windows or OS/2 Warp.
• So inculcate the following forces:
• The applications in your domain need to support several
similar application platforms.
• The applications may be categorized into groups that use the
same functional core in different ways.
• The functional core of the application platform should be
separated into a component with
 minimal memory size, and
 services that consume minimal processing power
Solution
• Microkernel component
 The fundamental services of the application platform are
encapsulated in the microkernel component.
Ex: - inter-communication of components running in
separate processes
- maintaining system-wide resources such as files or
processes
- provides interfaces that enable other components
to access its functionality
• .
Contd..
• Internal servers
 Core functionality that
- cannot be implemented within the microkernel
- which increases the size or complexity should be separated
in internal servers
• External servers
 is a separate process that itself represents an application platform
 implement their own view of the underlying microkernel
• Clients
 communicate with external servers by using the communication
facilities provided by the microkernel.
Structure
The Microkernel pattern defines five kinds of participating
components:
 Internal servers
 External servers
 Adapters
 Clients
 Microkernel
Contd..
• Microkernel
 Represents the main component of the pattern.
 Implements central services such as communication
facilities or resource handling.
 Many system-specific dependencies are encapsulated
within the microkernel.
 Maintains, controls and coordinates the access to
system resources - processes or files.
Contd..
Example
• In Hydra we want to support UNIX System V and OS/2
Warp, amongst other operating systems.
• We face a problem when implementing Hydra's
process model.
 implemented in UNIX by cloning an existing process
 OS/2 Warp handles process creation totally differently
• Hydra is therefore designed to supply basic services
for both the mechanisms.
Contd..
Internal server
• Also known as a Sub-system.
• Extends the functionality provided by the microkernel.
• Example: device drivers that support specific graphics cards
are implemented by internal servers.
• The microkernel invokes the functionality of internal servers
via service requests.
Contd..
External server
• Also known as a personality
• Is a component that uses the microkernel for implementing its
own view of the underlying application domain.
• Each of these external servers runs in a separate process.
• It receives service requests from client applications , interprets
these requests, executes the appropriate services and returns
results to its clients.
• For implementation, external servers need to access the
microkernel's programming interfaces.
Contd..
Contd..
Example
• In Hydra, we want to implement an OS/2 Warp external server
and a UNIX System V external server.
• Both these servers use the mechanisms of the underlying
microkernel to implement a complete set of OS/2 Warp and
UNIX System V system calls.
Contd..
Client
• Is an application that is associated with exactly one external
server.
• Only accesses the programming interfaces provided by the
external server.
• Every communication with an external server must be hardcoded into the client code.
• Such a tight coupling between clients and servers, however,
leads to various disadvantages:
 Does not support changeability very well.
 If external servers emulate existing application platforms,
client applications developed for these platforms will not
run without modification.
Contd..
Contd..
Adapters
• Also known as emulators.
• Represent the interfaces between clients and their external
servers to protect clients from direct dependencies.
• If the external server implements an existing application
platform, the corresponding adapter mimics the programming
interfaces of that platform.
• Protect clients from the specific implementation details of the
microkernel.
• Whenever a client requests a service from an external server
 the adapter forwards the call to the appropriate server.
Contd..
Example
• Due to encapsulation by an adapter, a Hydra client associated
with the OS/2 Warp external server does not know whether it
is running on a native OS/2 Warp system or on a Microkernel
system that provides an OS/2 Warp external server.
• It just uses the OS/2 system calls.
• What happens 'behind the scenes' is hidden by the adapter.
• The microkernel, collaborates with external servers, internal
servers and adapters.
• Each client is associated with an adapter used as a bridge
between the client and its external server.
Contd..
Fig: Static structure of a Microkernel system
• Internal servers are only accessible by the microkernel
component.
Dynamics
• The dynamic behavior of a Microkernel system depends on the
functionality, it provides for inter-process communication.
Scenario I
• Demonstrates the behavior when a client calls a service of its
external server:
 The client requests a service from an external server by
calling the adapter.
 The adapter constructs a request and asks the microkernel
for a communication link with the external server.
 The microkernel determines the physical address of the
external server and returns it to the adapter.
Contd..
 Now the adapter establishes a direct communication link to
the external server.
 The adapter sends the request to the external server using a
remote procedure call.
 The external server receives the request, unpacks the
message and delegates the task to one of its own methods.
 After completing the requested service, the external server
sends all results and status information back to the adapter.
 The adapter returns to the client, which in turn continues
with its control flow.
Contd..
Fig: Scenario - I
Contd..
Scenario II
• Illustrates the behavior of a Microkernel architecture when an
external server requests a service that is provided by an
internal server.
• The external server sends a service request to the microkernel.
• A procedure of the programming interface of the microkernel
is called to handle the service request. During method
execution the microkernel sends a request to an internal server.
• After receiving the request, the internal server executes the
requested service and sends all results back to the
microkernel.
• The microkernel returns the results back to the external
server.
Contd..
• Finally, the external server retrieves the results and continues
with its control flow.
Fig: Scenario II
Implementation
To implement a Microkernel system, carry out the following steps:
1. Analyze the application domain
 If you do not have detailed knowledge about the external
servers, that will be implemented, then
- perform a domain analysis
- identify the core functionality necessary for implementing
external servers
2. Analyze external servers
 Analyze the policies external servers are going to provide.
 Example : In Hydra operating system, external servers are: UNIX System V,
OS/2 Warp, Microsoft Windows & NeXTSTEP.
Contd..
3. Categorize the services
 Whenever possible, group all the functionality into
semantically-independent categories.
 Example: In Hydra the core categories are –
operating systems are memory management, process
management, I/O & communication services.
4. Partition the categories
 Separate the categories into services that should be part of
the microkernel, and those that should be available as
internal servers.
Contd..
categories
services provided by
microkernel
services provided by
internal servers
 In Hydra, the microkernel provides services
- process management
- memory management
- communication
- low-level I/O
Internal servers provide additional services
- page fault handlers
- drivers or file systems
Contd..
5. Find a consistent and complete set of operations and
abstractions for every category you identified in step 1.
 Example : In Hydra, operations such as the creation of
processes or threads are handled differently by operating
systems like UNIX or Microsoft Windows.
 Hydra supports both by providing the following services:
- Creating and terminating processes and threads.
- Stopping and restarting them.
- Reading from or writing to process address spaces.
- Catching and handling exceptions.
- Managing relationships between processes or threads.
- Synchronizing and coordinating threads.
Contd..
6. Determine strategies for request transmission and retrieval
 Microkernel may provide several alternatives:
 Asynchronous
communication
v/s
synchronous
communication
 One-to-one, a many-to-one or a many-to-many relationship
 Low-level communication facilities such as messagepassing or shared memory
 Compare design patterns such as Forwarder-Receiver &
Client-Dispatcher-Server
Contd..
• Example: Hydra provides two basic communication facilities:
 Synchronous Remote Procedure Calls (RPCs)
 Asynchronous Mailboxes
7. Structure the microkernel component
 Design the microkernel using the Layers pattern
to separate system-specific parts from systemindependent parts of the microkernel.
 Example: In our Hydra project, we use object-oriented
techniques to implement the microkernel:
Contd..
 Lower-most layer
- low-level objects that hide hardware-specific
details(bus architecture) from other parts of the
microkernel.
 Intermediate layer
- provide the primary services(memory management, process
management).
 Uppermost layer
- comprises all the functionality that the microkernel exposes
publicly represents the gateway to the microkernel services for any
process.
Contd..
8. To specify the programming interfaces of the microkernel, you
need to decide how these interfaces should be accessible
externally.
 microkernel is implemented as a module
- use method calls to invoke the methods of the
microkernel.
 microkernel is implemented as a separate process
- use existing communication facilities to transmit
requests from components to the microkernel.
 Example : In Hydra, microkernel component is part of
each user process. Services are therefore accessible by
conventional system calls.
Contd..
9. The microkernel manages all system resources - memory
blocks, devices or device contexts.
 using a handle to an output area in a graphical user
interface implementation.
 In Hydra OS, handles refer to objects that are instances of
a resource class.
 Each object offers a uniform interface to control access to
a specific resource.
10. Design and implement the internal servers as separate processes
or shared libraries.
 In Hydra, device drivers, authentication servers & page
fault handlers are implemented as internal servers.
Contd..
11. Implement the external servers
 Each external server is implemented as a separate process
that provides its own service interface.
 The internal architecture of an external server depends on
the policies it comprises.
 In Hydra, the following external servers will be developed:
- A full implementation of Microsoft’s Win32 and Win16
APIs.
- The complete functionality provided by IBM OS/2 Warp
2.0.
- An implementation of OpenStep.
- All relevant UNIX System V interfaces specified by
X/Open.
Contd..
12. Implement the adapters
 Design the adapter either as
- a conventional library that is statically linked to the
client during compilation, or as
- a shared library dynamically linked to the client on
demand.
- The Proxy pattern can therefore be used to implement
an adapter.
13. Develop client applications or use existing ones for the
ready-to-run Microkernel system.
 Example: In Hydra, we can develop Microsoft Windows
applications by accessing the services of the Microsoft
windows external server.
Variants
1.
Microkernel System with indirect Client-Server
connections
 A client that wants to send a request/message to an
external server asks the microkernel for a communication
channel.
 After the requested communication path has been
established, client-server communication takes place
indirectly, using the microkernel as a message backbone.
2. Distributed Microkernel System
 Every machine in a distributed system uses its own
microkernel implementation.
 From the user's viewpoint the whole system appears as
a single microkernel system-the distribution remains
transparent to the user.
Uses/Applications
i) Mach
 was developed at Carnegie Mellon University in 1986.
 Mach microkernel forms a base on which other operating
systems can be emulated.
ii) Amoeba
 consists of two basic elements:
- the microkernel itself and
- a collection of servers used to implement the majority
of Amoeba's functionality.
iii) Chorus
 commercially-available Microkernel system developed by
the French research institute INU
 specifically for real-time applications.
Contd..
iv) Windows NT
 was developed by Microsoft as an operating system for
high- performance servers.
 It offers three external servers, an OS/2 1 .x server, a
POSIX server and a Win32 server.
v) MKDE(Microkernel Datenbank Engine)
 Introduces an architecture for database engines
 The microkernel is responsible for providing fundamental
services.
 Various external servers run on top of the microkernel and
provide different conceptual views of the underlying
microkernel.
Consequences
Benefits of the Microkernel pattern:
i) Portability
 A Microkernel system offers a high degree of portability.
 No need to port external servers or client applications , if
you port the Microkernel system to a new software or
hardware environment.
 Microkernel can be migrated to a new hardware
environment by modifications to the hardware-dependent
parts.
Contd..
ii) Flexibility and Extensibility
 To implement an additional view, all you need to do is add
a new external server.
 Extending the system with additional capabilities only
requires the addition or extension of internal servers.
iii) Separation of policy and mechanism
 The microkernel component provides all the mechanisms
necessary to enable external servers to implement their
policies.
 Strict separation of policies & mechanisms increases the
maintainability and changeability of the whole system.
Contd..
Distributed variant of the Microkernel architecture offers the
following additional benefits:
i) Scaleability
 Easy to scale the Microkernel system to the new
configuration whenever a new machine is added to the
network.
ii) Reliability
 Two issues are important in achieving reliability:
availability and fault tolerance.
 Availability - The same server can be run on more than one
machine.
Contd..
 If a server or a machine fails, the failure does not
necessarily impact an application.
 Fault tolerance - Distributed systems hide failures from a
user.
iii) Transparency
 Each component can access other components, without
needing to know their location.
 Details of inter-process communication with servers are
hidden from clients by the adapters & the microkernel.
Contd..
Liabilities of the Microkernel architectural framework:
i) Performance
 Compare a monolithic software system designed to offer
a specific view with a Microkernel system supporting
different views.
 The performance of the former will be better in most cases.
ii) Complexity of design and implementation
 Analyzing or predicting the basic mechanisms provided by
a microkernel component becomes difficult sometimes.
 The separation between mechanisms and policies requires
in-depth domain knowledge and considerable effort
during requirements analysis and design.
Unit-VI
• Adaptable Systems
 Microkernel
 Reflection
Engineered for
Tomorrow
Reflection
 Pattern Definition
 Example Resolved
 Context
 Problem
 Solution
 Structure
 Dynamics
 Implementation
 Variants
 Known Uses
 Consequences
Reflection Pattern
Definition
• Provides a mechanism for changing structure and behavior of
software systems dynamically.
• Supports the modification of fundamental aspects
- type structures & function call mechanisms
• An application is split into two parts.
 A meta level provides information about selected system
properties and makes the software self-aware.
 A base level includes the application logic.
Its implementation builds on the meta level.
• Also known as Open Implementation, Meta-Level
Architecture
Example
• Consider a C++ application that needs to write objects to disk
and read them in again.
• We must specify how to store and read every type in the
application.
• Many solutions to this problem exist:
 implementing type-specific store and read methods expensive and error-prone.
Contd..
• Persistence and application functionality are strongly
interwoven
 Example: we can provide a special base class for
persistent objects from which application classes are
derived, with inherited store and read methods overridden.
 Changes to the class structure require us to modify these
methods within existing application classes.
• Here the focus is on
 Developing a persistence component that is independent of
specific type structures.
 To have dynamic access to the internal structure of C++ objects.
Contd..
Context
• Building systems that support their own modification a priori.
Problem
• Software systems evolve over time.
• They must be open to modifications in response to changing
technology and requirements.
• Designing a system that meets a wide range of different
requirements, a priori can be an overwhelming task.
• Several forces are associated with this problem:
i) Changing software is tedious, error prone, and often
expensive.
ii) Adaptable software systems usually have a complex
inner structure.
Contd..
iii) More the techniques that are necessary for keeping a
system changeable, more awkward and complex its
modification.
 parameterization, sub-classing, mix-ins, or copy and
paste
iv) Changes can be of any scale
 providing shortcuts for commonly used commands to
adapting an application framework for a specific customer.
 Even fundamental aspects of software systems can
change.
- the communication mechanisms between components
Solution
• Make the software self-aware, and make selected aspects of
its structure and behavior adaptable and changeable.
• This leads to an architecture that is split into two major parts:
 a meta level
 a base level
• The meta level provides a self-representation of the software
to give it knowledge of its own structure and behavior
• Consists of so-called meta-objects.
• Meta-objects encapsulate and represent information about
the software.
• Examples include type structures, algorithms, or sseven
function call mechanisms.
Contd..
• The base level defines the application logic.
• Its implementation uses the meta-objects to remain
independent of those aspects that are likely to change.
• Meta-object protocol (MOP) - interface is specified for
manipulating the meta-objects.
 allows clients to specify particular changes (modification
of the function call mechanism).
 responsible for checking the correctness of the change
specification, & for performing the change
Structure
Meta level consists of a set of meta-objects.
• Each meta-object encapsulates selected information about a
single aspect of the structure, behavior, or state of the base
level.
• There are three sources for such information:
It can be provided by the run-time environment of the system
- C++ type identification objects.
• It can be user-defined, such as the function call mechanism.
• It can be retrieved from the base level at run-time.
Ex: information about the current state of computation
Contd..
Contd..
Base level models and implements the application logic of the
software.
• Its components represent the various services the system offers
as well as their underlying data model.
• Specifies the fundamental collaboration and structural
relationships between its components.
• The base level uses the information and services provided by
the meta-objects.
 location information about components & function call
mechanisms.
Contd..
Contd..
• Meta-object protocol (MOP] serves as an external interface to
the meta level, and facilitates the implementation of a system
using reflective pattern.
• Example:
 a user may specify a new function call mechanism for
communication between base-level components.
 the user provides the meta-object protocol with the code of
this new function call mechanism.
 the meta-object protocol then performs the change,
- generates an appropriate meta-object
- compiles the generated meta-object,
- dynamically links it with the application
- updates all references of the 'old' meta-object to the 'new' one.
Contd..
Structure
• The architecture is a layered system with 2 layers
- i) meta level ii)base level
• Each of which provides its own interface.
• The base-level layer specifies the user interface for exploiting
application functionality.
• The meta-level layer defines the meta-object protocol to
modify the meta-objects.
• In contrast to a layered architecture, there are mutual
dependencies between both layers.
• The base level builds on the meta-level, and vice-versa.
Contd..
Fig: General structure of a reflective architecture
Dynamics
Scenario I
• Illustrates the collaboration between base level and meta level
when reading objects stored in a disk file.
• The scenario is divided into six phases:
i) The user wants to read stored objects.
 The request is forwarded to the read ( ) procedure of the
persistence component.
ii) Procedure read() opens the data file and calls an internal
readObject() procedure.
Contd..
iii) Procedure readObject( ) calls the metaobject that is
responsible for the creation of objects.
The 'object creator' metaobject instantiates an 'empty'
object of the previously-determined type.
 It returns a handle to this object and a handle to the
corresponding run-time type information (RTTI) metaobject.
iv) Procedure readObject( ) requests an iterator over the data
members of the object to be read from its corresponding
meta-object.
Contd..
v) Procedure readobject( ) reads the type identifier for the
next data member.
 If the type identifier denotes a built-in type, the
readobject ( ) procedure directly assigns the next data
item from the file to the data member, based on the
data member's size and offset within the object.
 Otherwise readobject( ) is called recursively.
 After reading the data, the read ( ) procedure closes
the data file & returns the new objects to the client
that requested them.
Contd..
Fig: Scenario I
Contd..
Scenario II
• illustrates the use of the metaObject protocol when adding type
information to the meta level.
• Consider a class library used by the application that changes to
a new version with new types.
• The scenario is divided into six phases which are performed for
every new type:
i) A client invokes the metaObject protocol to specify run-time
type information for a new type in the application.
ii) The metaObject protocol creates a metaObject of class
type-info for this type.
Contd..
iii) The client calls the metaObject protocol to add extended type
information.
 To handle the inheritance relationship, the metaObject
protocol creates meta-objects of class baseInfo.
iv) The metaObject protocol is provided with the name and type
of every data member.
 For every data member the metaObject protocol creates an
object of class dataInfo.
v) The client invokes the metaObject protocol to modify
existing types, that include the new type as a data member.
Contd..
vi) Finally, the client calls the
metaobject protocol to adapt
the 'object creator' metaobject.
The persistence component must be
able to instantiate an object
of the new type when reading
persistent data.
Contd..
Implementation
Guidelines for implementing a reflective architecture:
i) Define a model of the application
• Analyze the problem domain and decompose it into an
appropriate software structure.
• Answer the following questions:







Which services should the software provide?
Which components can fulfill these services?
What are the relationships between the components?
How do the components co-operate or collaborate?
What data do the components operate on?
How will the user interact with the software?
Follow an appropriate analysis method when specifying the model.
Contd..
ii) Identify varying behavior
• Analyze the model developed in the previous step &
determine which of the application services may vary and
which remain stable.
• The following are examples of system aspects that often vary:
 Real-time constraints
- deadlines, time-fence protocols, algorithms for detecting deadline
misses
 Transaction protocols
- optimistic & pessimistic transaction control in accounting systems
Contd..
 Inter-process communication mechanisms
- remote procedure calls and shared memory.
 Behavior in case of exceptions
- handling of deadline misses in real-time systems.
 Algorithms for application services
- country-specific VAT calculation
iii)Identify structural aspects of the system, which, when
changed, should not affect the implementation of the base
level.
 type structure of an application
 its underlying object model
 distribution of components in a heterogenous network.
Contd..
iv) Identify system services that support both the variation of
application services identified in step 2 and the independence
of structural details identified in step 3.
 Examples of basic system services are:
- Resource allocation
- Garbage collection
- Page swapping
- Object creation
v) Define the meta-objects
 For every aspect identified in the three previous steps,
define appropriate metaobjects.
 Encapsulating behavior is supported by several domainindependent design patterns
- Objectifier, Strategy, Bridge, Visitor, and Abstract Factory
Contd..
 The metaobjects that provide the run-time type information
for our persistence component are:
type-info - C++ standard library class used for identifying
types.
extTypeInfo - provides access to Information about the
size, super classes, and data members of a class.
BaseInfo - offers functions for accessing type information
about a base class of a class, as well as to determine its
offset in the class layout.
DataInfo - includes functions that return the name of a
data member, its offset and its associated type_info object.
Contd..
vi) Define the metaObject protocol.
 Support
- a defined and controlled modification and extension of the
meta- level
- a modification of relationships between base-level
components and meta-objects
 There are two options for implementing the metaObject
protocol:
i) Integrate it with the meta-objects.
ii) Implement the metaObject protocol as a separate
component.
Contd..
vii) Draw the base level
 Implement the functional core and user interface of the
system according to the analysis model developed in
step 1.
 Use meta-objects to keep the base level extensible and
adaptable.
 Connect every base-level component with meta-objects that
provide system information on which they depend.
 Provide base-level components with functions for
maintaining the relationships with their associated metaobjects.
Variant of Reflective System
1. Reflection with several meta levels
• Changes to the run-time type information of a particular type
requires that updation of the 'object creator' meta-object.
• To coordinate such changes, introduce separate meta-objects,
and-conceptually-a meta level for the meta level.
• Such a software system has an infinite number of meta levels in
which each meta level is controlled by a higher one, and where
each meta level has its own metaObject protocol.
• Ex: RbCl programming language
Known Uses/ Applications
i) CLOS
• Classic example of a reflective programming language.
• Operations defined for objects are called generic functions.
• Their processing is referred to as generic function invocation.
• Generic function invocation is divided into three phases:
 First determines the methods that are applicable to a given
invocation.
 Sorts the applicable methods in decreasing order of
precedence.
 Finally sequences the execution of the list of applicable
methods.
Contd..
ii) MIP
• Is a run-time type information system for C++.
• The functionality of MIP is separated into four layers:
 The first layer includes information and functionality that
allows software to identify and compare types.
 The second layer provides more detailed information about
the type system of an application.
 The third layer
- provides information about relative addresses of data members,
- offers functions for creating 'empty' objects of user-defined types.
 The fourth layer provides full type information,
- about friends of a class, protection of data members, or argument
and return types of function members.
Contd..
iii) PGen
• Is a persistence component for C++ that is based on MIP.
• Allows an application to store and read arbitrary C++ object
structures.
iv) NEDIS
• Car-dealer system , which uses reflection to support its
adaptation to customer- and country-specific requirements.
• Includes a meta level called run-time data dictionary.
v) OLE 2.0
• Provides functionality for exposing and accessing type
information about OLE objects and their interfaces.
• This information can be used to dynamically access structural
information about OLE objects, & to create invocations of
OLE interfaces.
Consequences
Benefits of a Reflection architecture:
i) No explicit modification of source code
• No need to touch existing code when modifying a reflective
system.
• Just specify a change by calling a function of the metaObject
protocol.
• By passing the new code to the meta level as a parameter of
the metaObject protocol.
ii) Changing a software system is easy
• The metaObject protocol provides a safe and uniform
mechanism for changing software.
Contd..
• Hides all specific techniques such as the use of visitors, factories
and strategies from the user.
• Hides the inner complexity of a changeable application.
iii) Support for many kinds of change
• Meta-objects can encapsulate every aspect of system behavior,
state and structure.
• An architecture based on the reflection pattern, potentially
supports changes of almost any kind or scale.
• Even fundamental system aspects can be changed,
 function call mechanisms or type structures.
Contd..
Liabilities of a Reflection architecture:
i) Modifications at the meta level may cause damage
• Even the safest metaObject protocol does not prevent users
from specifying incorrect modifications.
• Such modifications may cause serious damage to the
software or its environment.
ii) Increased number of components
• A reflective software system may include more metaobjects
than base-level components.
iii) Lower efficiency
• Reflective software systems are usually slower than nonreflective systems.
• This is caused by the complex relationship between the base
level and the meta level.
Contd..
iv) Not all potential changes to the software are supported
• Although a reflection architecture helps with the development
of changeable software, only changes that can be performed
through the metaObject protocol are supported.
• Example : changes or extensions to base-level code
v) Not all languages support reflection
• A Reflection architecture is hard to implement in some
languages, such as C++.
 offers little or no support for reflection
 impossible to exploit the full power of reflection, such as
adding new methods to a class dynamically