Fundamentos
del enfoque Orientado a Objetos
Lo orientado
a objetos se basa en el concepto de objeto. Un objeto es aquello que tiene
estado (propiedades más valores), comportamiento (acciones y reacciones a
mensajes) e identidad (propiedad que lo distingue de los demás objetos). La
estructura y comportamiento de objetos similares están definidos en su clase
común; los términos instancia y objeto son intercambiables. Una clase es un
conjunto de objetos que comparten una estructura y comportamiento común.
La diferencia
entre un objeto y una clase es que un objeto es una entidad concreta que existe
en tiempo y espacio, mientras que una clase representa una abstracción, la
"esencia" de un objeto, tal como son. De aquí que un objeto no es una
clase, sin embargo, una clase puede ser un objeto.
En el
enfoque Orientado a Objetos, las propiedades del objeto son claves. Los
principios del modelo OO son: abstracción, encapsulación, modularidad y
jerarquía, fundamentalmente, y en menor grado tipificación (typing), concurrencia,
persistencia. Booch en 1986, dice que si un modelo que se dice OO no contiene
alguno de los primeros cuatro elementos, entonces no es OO.
* Abstracción:Es una descripción simplificada o
especificación de un sistema que enfatiza algunos de los detalles o propiedades
del sistema, mientras suprime otros.
*Encapsulación: En el proceso de ocultar todos
los detalles de un objetoque no contribuyen a sus características esenciales.
*Modularidad:Es la propiedad de un sistema que
ha sido descompuesto en un conjunto de módulos coherentes e independientes.
*Jerarquía o herencia: Es el orden de las abstracciones
organizado por niveles.
* Tipificación: Es la definición precisa de un
objeto de tal forma que objetos de diferentes tipos no puedan ser
intercambiados o, cuando mucho, puedan intercambiarse de manera muy
restringida.
*Concurrencia: Es la propiedad que distingue un
objeto que está activo de uno que no lo está.
* Persistencia: Es la propiedad de un objeto a
través de la cual su existencia trasciende el tiempo (es decir, el objeto
continua existiendo después de que su creador ha dejado de existir) y/o el
espacio (es decir, la localización del objeto se mueve del espacio de dirección
en que fue creado).
Características Generales:
* *Un objeto se identifica por un
nombre o un identificador único que lo diferencia de los demás. Ejemplo: el
objeto Cuenta de Ahorros número 12345 es diferente al objeto Cuenta de Ahorros
número 25789. En este caso el identificador que los hace únicos es el número de
la cuenta.
*Un objeto posee estados. El
estado de un objeto está determinado por los valores que poseen sus atributos
en un momento dado.
*Un objeto tiene un conjunto de
métodos. El comportamiento general de los objetos dentro de un sistema se
describe o representa mediante sus operaciones o métodos. Los métodos se
utilizarán para obtener o cambiar el estado de los objetos, así como para
proporcionar un medio de comunicación entre objetos.
*Un objeto tiene un conjunto de
atributos. Los atributos de un objeto contienen valores que determinan el
estado del objeto durante su tiempo de vida. Se implementan con variables,
constantes y estructuras de datos (similares a los campos de un registro).
*Los objetos soportan
encapsulamiento. La estructura interna de un objeto normalmente está oculta a
los usuarios del mismo. Los datos del objeto están disponibles solo para ser
manipulados por los propios métodos del objeto. El único mecanismo que lo
conecta con el mundo exterior es el paso de mensajes.
*Un objeto tiene un tiempo de vida
dentro del programa o sistema que lo crea y utiliza. Para ser utilizado en un
algoritmo el objeto debe ser creado con una instrucción particular (New ó
Nuevo) y al finalizar su utilización es destruido con el uso de otra instrucción
o de manera automática.
Desarrollo de componentes del software
El
Desarrollo de Software Basado en Componentes (DSBC) trata de apoyar las bases
para el diseño y desarrollo de aplicaciones distribuidas basadas en componentes
software reutilizables. Esta norma cuenta en la actualidad con una utilidad,
tanto desde el panorama académico como desde el industrial, en donde su demanda
de temas es cada día mayor.
La
finalidad primordial de (DSBC) es entender los diferentes modelos de desarrollo
de software y la importancia de sus componentes y servicios. También evaluar
las diferencias entre este modelo y los estudiados anteriormente en el
transcurso de desarrollar este tipo de software.
Además
deberíamos conocer los fundamentos sobre los que se sienta el modelo y todas
las tendencias al momento de armar el software, es decir en su arquitectura.
Con este
modelo también aseguramos la calidad del producto. La filosofía de este modelo es que “es más fácil comprar
que construir” pues si algo ya está elaborado no debemos desperdiciar el tiempo
en construirlo. Pero no todo es solamente comprar pues nosotros debemos
realizar un correcto ensamblaje de los componentes para que el software pueda
funcionar correctamente.
Además
debemos saber qué clase de componentes debemos elegir pues una mala elección
nos causaría un mal funcionamiento del software. También debemos saber escoger
a quien comprar y debemos saber cómo comprar. Debemos escoger la opción más
conveniente en costos, calidad y además que opción nos servirá más para el
software que estamos desarrollando. Este modelo también tiene limitaciones ya que
no siempre se podrá encontrar los componentes adecuados para cada proyecto.
Lo más
importante que se debe tener en cuenta al definir el concepto de DSBC, es el de
diferenciar las características existentes entre el DSBC y el paradigma de
objetos, la Programación Orientada a Objetos (POO) es cuando el software puede
ser desarrollado de acuerdo a un modelo mental de un objeto real o imaginado,
mientras que el DSBC dice que el software debe ser desarrollado a partir de
componentes prefabricados. Existen varias definiciones de componentes
realizadas por expertos que han sido los encargados del desarrollo de esta
metodología, ellos han tomado como base la metodología de la programación
orientada objetos y el modelado a través de UML :
* Un componente es una parte no
trivial, casi independiente, y reemplazable de un sistema que llena claramente
una funcionalidad dentro de un contexto en una arquitectura bien definida. Un
componente se conforma y provee la realización física por medio de un conjunto
de interfaces.
* Un componente de software en
tiempo de ejecución es un paquete dinámicamente vinculado con uno o varios
programas manejados como una unidad y que son accedidos mediante interfaces
bien documentadas que pueden ser descubiertos en tiempo de ejecución.
* Un componente de software es una
unidad de composición con interfaces contractualmente especificadas y
explícitas sólo con dependencias dentro de un contexto. Un componente de
software puede ser desplegado independientemente y es sujeto a la composición
de terceros.
* Un Componente de Negocio
representa la implementación de software del concepto de un negocio “autónomo”
o un proceso de negocio. Que consiste de artefactos de software necesarios para
expresar, implementar y poner en marcha el concepto de elemento reusable de un
sistema más grande de negocios.
El
Desarrollo de Software Basado en Componentes (DSBC) trata de apoyar las bases
para el diseño y desarrollo de aplicaciones distribuidas basadas en componentes
software reutilizables. Esta norma cuenta en la actualidad con una utilidad,
tanto desde el panorama académico como desde el industrial, en donde su demanda
de temas es cada día mayor.
La
finalidad primordial de (DSBC) es entender los diferentes modelos de desarrollo
de software y la importancia de sus componentes y servicios. También evaluar
las diferencias entre este modelo y los estudiados anteriormente en el
transcurso de desarrollar este tipo de software.
Se debe cononocer los fundamentos sobre los que se sienta el modelo y todas
las tendencias al momento de armar el software, es decir en su arquitectura.
Con este
modelo también aseguramos la calidad del producto. La filosofía de este modelo es que “es más fácil comprar
que construir” pues si algo ya está elaborado no debemos desperdiciar el tiempo
en construirlo. Pero no todo es solamente comprar pues nosotros debemos
realizar un correcto ensamblaje de los componentes para que el software pueda
funcionar correctamente.
Además debemos saber qué clase de
componentes debemos elegir pues una mala elección nos causaría un mal
funcionamiento del software. También debemos saber escoger a quien comprar y
debemos saber cómo comprar. Debemos escoger la opción más conveniente en
costos, calidad y además que opción nos servirá más para el software que
estamos desarrollando. Este modelo también tiene limitaciones ya que no siempre
se podrá encontrar los componentes adecuados para cada proyecto.
Características de los componentes
Un componente de software debe
poseer las siguientes características:
*Ser reutilizable.
*Ser intercambiable.
* Poseer interfaces definidas.
*Ser cohesivos
Estándares en el proceso de
desarrollo de software
La gran cantidad de organizaciones
de desarrollo de software implementan metodologías para el proceso de
desarrollo. Muchas de estas organizaciones pertenecen a la industria
armamentística, que en los Estados Unidos necesita un certificado basado en su
modelo de procesos para poder obtener un contrato.
El estándar internacional que regula
el método de selección, implementación y monitoreo del ciclo de vida del
software es ISO 12207.
Durante décadas se ha perseguido la meta de encontrar
procesos reproducibles y predecibles que mejoren la productividad y la calidad.
Algunas de estas soluciones intentan sistematizar o formalizar la aparentemente
desorganizada tarea de desarrollar software. Otros aplican técnicas de gestión
de proyectos para la creación del software. Sin una gestión del proyecto, los
proyectos de software corren el riesgo de demorarse o consumir un presupuesto
mayor que el planeado. Dada la cantidad de proyectos de software que no cumplen
sus metas en términos de funcionalidad, costes o tiempo de entrega, una gestión
de proyectos efectiva es algo que a menudo falta
Artefactos
y Documentación
La documentación
es la debilidad más frecuente en productos e instalaciones informáticos. Los
actores que intervienen en el ciclo de vida del software desempeñan diversos
roles. Arquitectos, diseñadores, analistas, programadores, implementadores,
administradores o auditores son quienes explicitan distintos aspectos de los
productos y procesos.
El código fuente
del software, la estructura de datos y los enlaces de comunicaciones
constituyen en conjunto el paradigma de la documentación informática. Sin
embargo, cuando los modelos de arquitectura, estructuras y especificaciones de
diseño no los vinculan, sólo pueden acceder a éstos dificultosamente los
iniciados. Hay buenas prácticas para escribir código fuente pero, las
condiciones y circunstancias de cada programa y sistema son tan diversas que,
las exigencias habituales se reducen a que funcione razonablemente.
Artefactos, de acuerdo con RUP, es una pieza de
información producida, modificada o utilizada por un proceso. Artefacto son los
productos tangibles del proyecto, las cosas que los proyectos producen o
utilizan mientras se trabaja hacia el producto final. Los artefactos son
insumos utilizados para realizar actividades y, son los resultados de estas
actividades.
Son artefactos
entregables como ejecutables, el código fuente, manuales, planes y proyectos.
Productos intermedios, como documentos de arquitectura y diseño,
especificaciones de requerimientos, modelos de negocios y casos de uso. De
igual forma, son artefactos los elementos que componen los modelos y productos,
como glosarios y diccionarios, gráficos, clases o subsistemas. También, en
negocios regulados, son artefactos los instrumentos y evidencias de la gestión
informática.
