Software Component -

A Software Component is an element of a Software System that offers a set of Services or Features through defined interfaces.

In the UML specification, a component is a modular unit with well defined interfaces, which is replaceable within the context. Thus, a component defines its behavior in terms of provided interfaces and required; and that component will be fully replaceable by another that complies with the declared interfaces.

UML does not place any restrictions on the component's granularity, so a component can be as simple as a currency converter or as complex as a semantic help system.

A software component must have the following characteristics:

  • Be reusable.
  • Be interchangeable.
  • Have defined interfaces.
  • Be cohesive

Software Components are the cornerstone of different programming paradigms. This has generated the appearance in the market of different specifications that pose the way to construct, to use and to distribute components. Among the most widespread are:


Common Object Request Broker Architecture (CORBA) of the Object Management Group.

  • Oracle JavaBeans, servlets and Enterprise Java Beans
  • OSGi Alliance Open Services Gateway Initiative (OSGi)
  • Microsoft COM, COM +, and DCOM


Software components are useful in:

Component-Oriented Programming 

Component-oriented Programming (also called component-based) is a branch of software engineering, with an emphasis on the decomposition of already-formed systems into functional or logical components with well-defined interfaces used for communication between components.

It is considered that the level of abstraction of the components is higher than that of the objects and therefore do not share a state and communicate by exchanging messages containing data.

Object Oriented Programming 

Object Oriented Programming (OOP) is a programming paradigm that uses objects in their interactions to design applications and software. It is based on several techniques, including inheritance, cohesion, abstraction, polymorphism, coupling and encapsulation. Its use was popularized in the early 1990s. There is now a wide variety of programming languages ​​that support object orientation.

Objects are entities that have a certain state, behavior (method) and identity:

The state is composed of data or information; will be one or more attributes to which specific values ​​(data) will have been assigned.

The behavior is defined by the methods or messages to which the object knows how to respond, ie what operations can be performed with it.

Identity is a property of an object that sets it apart from the rest; in other words, is its identifier (concept analogous to that of a variable identifier or a constant).

An object contains all the information that allows to define it and to identify it in front of other objects belonging to other classes and even against objects of the same class, to be able to have values ​​well differentiated in its attributes. In turn, objects have mechanisms of interaction called methods, which favor communication between them. This communication favors the change of state in the objects themselves. This characteristic leads to treat them as indivisible units, in which state and behavior are not separated.

The methods (behavior) and attributes (state) are closely related by the set property. This property emphasizes that a class requires methods to be able to handle the attributes that it has. The programmer must think indistinctly in both concepts, without separating or giving greater importance to any of them. Doing so could produce the wrong habit of creating information-containing classes on one side and classes with methods that handle the former on the other. In this way a structured programming camouflaged in an object oriented programming language would be done.

The OOP differs from traditional structured programming, in which data and procedures are separate and unrelated, since the only thing that is sought is the processing of one input data to obtain other output. Structured programming encourages the programmer to think primarily in terms of procedures or functions, and secondly in the data structures that those procedures handle. Structured programming only writes functions that process data. Programmers using POO, however, first define objects and then send them messages asking them to perform their methods on their own.

Characteristics of the OOP


It denotes the essential characteristics of an object, where its behaviors are captured. Each object in the system serves as a model for an abstract "agent" that can perform work, inform and change its state, and "communicate" with other objects in the system without revealing how these characteristics are implemented. Processes, functions, or methods can also be abstracted, and, when they are, a variety of techniques are required to extend an abstraction. The abstraction process allows selecting the relevant characteristics within a set and identifying common behaviors to define new types of entities in the real world. The abstraction is key in the process of analysis and design oriented to objects, since through it we can arrive at a set of classes that allow to model the reality or the problem that is wanted to attack.


It means gathering all the elements that can be considered belonging to the same entity, at the same level of abstraction. This allows to increase the cohesion of the system components. Some authors confuse this concept with the principle of concealment, mainly because they are usually used together.


It is called modularity to the property that allows to subdivide an application into smaller parts (called modules), each of which must be as independent as possible of the application itself and of the remaining parts. These modules can be compiled separately, but have connections to other modules. Like encapsulation, languages ​​support modularity in a variety of ways.

Principle of Concealment

Each object is isolated from the outside, it is a natural module, and each type of object exposes an interface to other objects that specifies how they can interact with the objects of the class. Isolation protects the properties of an object against its modification by those who do not have the right to access them; only the object's own internal methods can access its state. This ensures that other objects can not change the internal state of an object unexpectedly, eliminating side effects and unexpected interactions. Some languages ​​relax this, allowing a direct access to the internal data of the object in a controlled way and limiting the degree of abstraction. The entire application is reduced to an aggregate or object puzzle.


Different behaviors, associated with different objects, may share the same name; calling them by that name will use the behavior corresponding to the object being used. Or, in other words, references and collections of objects may contain objects of different types, and invoking a behavior in a reference will produce the correct behavior for the actual type of the referenced object. When this occurs at "runtime", this latter feature is called late allocation or dynamic allocation. Some languages ​​provide more static means (at "compile time") of polymorphism, such as templates and overhead of C + + operators.


The classes are not isolated, but are related to each other, forming a ranking hierarchy. Objects inherit the properties and behavior of all classes to which they belong. Inheritance organizes and facilitates polymorphism and encapsulation, allowing objects to be defined and created as specialized types of preexisting objects. They can share (and extend) their behavior without having to re-implement it. This is usually done by grouping the objects in classes and these in trees or trellises that reflect a common behavior. When an object inherits from more than one class, it is said that there is multiple inheritance.

Garbage Collection

The collection of garbage or garbage collector is the technique by which the objects environment is responsible for automatically destroying, and therefore unlinking the associated memory, the objects that have remained without any reference to them. This means that the programmer should not worry about allocating or releasing memory, as the environment will allocate it when creating a new object and release it when no one is using it. In most of the hybrid languages ​​that were extended to support the Object Oriented Programming Paradigm such as C ++ or Object Pascal, this feature does not exist and memory must be explicitly deasigned.

Service Oriented Architecture (SOA) 

The 'Service Oriented Architecture' (SOA) is a software architecture concept that defines the use of services to support business requirements.

It allows the creation of highly scalable information systems that reflect the business of the organization, in turn provides a well defined form of exposure and invocation of services (commonly but not exclusively web services), which facilitates the interaction between different systems or of third parties.

SOA defines the following software layers:

  • Basic applications - Systems developed under any architecture or technology, geographically dispersed and under any property figure;
  • Exposure of functionalities - Where the functionalities of the application layer are exposed in the form of services (generally as web services);
  • Integration of services - Facilitate the exchange of data between elements of the application layer oriented to internal or collaborative business processes;
  • Process composition - Which defines the process in terms of the business and its needs, and which varies according to the business;
  • Delivery - where services are deployed to end users.

SOA provides a methodology and framework to document business capabilities and can support integration and consolidation activities.

Unlike object-oriented architectures, SOAs are made up of weakly coupled and highly interoperable application services. In order to communicate with each other, these services are based on a formal definition independent of the underlying platform and programming language (eg, WSDL). The interface definition encapsulates (hides) the particularities of an implementation, which makes it independent of the manufacturer, programming language, or development technology (such as Java Platform or Microsoft .NET). With this architecture, it is intended that the software components developed be very reusable, since the interface is defined following a standard; thus, a C # service could be used by a Java application. In this sense, some authors define SOA as a Super-Abstraction.

The benefits that an organization adopting SOA can obtain are:

  • Improvement in the times of realization of changes in processes.
  • Easy to evolve to business models based on outsourcing.
  • Ease of approach to business models based on collaboration with other entities (partners, suppliers).
  • Power to replace elements of the SOA application layer without disruption in the business process.
  • Ease of integration of dissimilar technologies.

Aspect-Oriented Programming

Aspect Oriented Programming (POA) is a relatively recent paradigm of programming that intends to allow an adequate modularization of the applications and to allow a better separation of incumbencias. Thanks to the POA you can encapsulate the different concepts that make up an application in well defined entities, eliminating the dependencies between each of the modules. In this way, the concepts can be better reasoned, the code dispersion is eliminated and the implementations become more understandable, adaptable and reusable. Several technologies with different names are aimed at achieving the same objectives and thus the term POA is used to refer to several related technologies such as adaptive methods, composition filters, subject-oriented programming or multidimensional separation of competencies.

The main objective of the POA is the separation of the functionalities within the system:

  • On the one hand common functionalities used throughout the application.
  • On the other hand, the functionalities of each module.

Each common functionality will be encapsulated in an entity.

Basic Concepts of Aspect-Oriented Programming

  • Aspect is a cross-cutting functionality that will be implemented in a modular way and separate from the rest of the system. The most common and simple example of an aspect is the logging within the system, since it necessarily affects all parts of the system that generate an event.
  • Join point is a point of execution within the system where an appearance can be connected, such as a call to a method, the throwing of an exception, or the modification of a field. The aspect code will be inserted into the application's execution stream to add its functionality.
  • Advice is the implementation of the appearance, that is, it contains the code that implements the new functionality. They are inserted into the application at the crossing points.
  • Pointcut (Cut Points) defines the Tips to be applied to each Crossing Point. It is specified by Regular Expressions or by name patterns (of classes, methods or fields), and even dynamically at runtime according to the value of certain parameters.
  • Introduction allows you to add methods or attributes to existing classes. An example in which it would be useful is the creation of an Audit Board that maintains the date of the last modification of an object, through a variable and a method setUltimaModificacion (date), that could be introduced in all the classes (or only in some) to provide them with this new functionality.
  • Target is the recommended class, the class that is the subject of a council. Without AOP, this class should contain its logic, as well as the logic of the aspect.
  • Proxy is the object created after applying the Board to the Target Object. The rest of the application will only have to support the Target Object (pre-AOP) and not the Resultant Object (post-AOP).
  • Weaving is the process of applying Aspects to Target Objects to create new Resulting Objects at the specified Crossing Points. This process can occur throughout the life cycle of the Target Object:

o Aspects in Compile Time, which needs a special compiler.
o Aspects in Load Time, Aspects are implemented when the Receiving Object is loaded. Requires a special ClassLoader.
o Aspects in Execution Time.


You May Also Like