INFORME I

INTRODUCCION A METODOLOGIAS DE DESARROLLO DE SOFTWARE, ORIENTACION A

OBJETOS INTERFACES Y COMPONENTES.

DIMAS ALEJANDRO MORENO MENDOZA

CODIGO: 0848801882018
MARISOL LOPEZ ARENAS
CÓDIGO: 084800902018
EVELIN CAMILA ACOSTA ALVARES
CODIGO: 084801822018
LINDA KATHERINE CIFUENTES QUIÑONES
CODIGO: 084801892018

UNIVERSIDAD DEL TOLIMA

IDEAD – IBAGUÉ

TECNOLOGIA EN GESTION DE BASES DE DATOS

IBAGUE
2019
 INDICE
INTRODUCCION……………………………………………………………………………………………….….3
OBJETIVOS GENERALES………………………………………………………………………………………..4
OBJETIVOS ESPECIFICOS …………………………………………………………………………………………5
INTRODUCCION A METODOLOGIAS DE DESARROLLO DE SOFTWARE
¿Qué es una metodología de desarrollo de software?...............................................6
¿Qué nos aporta una metodología de desarrollo de software?.................................6
¿Qué metodología escoger?.......................................................................................6
Ciclo de vida del software……………………………………………………………………………………...7
Modelos de metodología…………………………………………………………………………………….…8

ORIENTACION A OBJETOS

INTERFACES……………………………………………………………………………………………………………..15
Interfaces: Aspectos sintácticos………………………………………………………………………………16
Algunas características de las Interfaces son…………………………………………………………….17
Esta interfaz contiene………………………………………………………………………………………………18.
COMPONENTES………………………………………………………………………………………………………..20
¿cómo clasificar componentes? ………………………………………………………………………………21
clasificación de componentes……………………………………………………………………………………22
¿cómo evaluar la calidad de un componente?..............................................................23
tipos de componentes………………………………………………………………………………………………23
CONCLUSIONES…………………………………………………………………………………………………………26
WEBGRAFIA………………………………………………………………………………………………………………27
 INTRODUCCION

Una metodología nos permite definir límites; Construir software complejo requiere un gran
esfuerzo: tecnología, dinero y sobre todo personas. Con este informe se quiere dar el inicio
al tema de las metodologías de desarrollo software, con el fin de dar claridad al tema con
respecto a las dudas que se puedan tener; para obtener un buen resultado frente a la
orientación a objetos interfaces y sus componentes.
Mediante a investigaciones y consultas que fueron desarrolladas por la cipa se realizó este
informe lo más claro posible con la intención de entender con claridad el tema.
 OBJETIVOS GENERALES

 Dar la introducción al tema de metodología de desarrollo de software.

 Despejar las dudas frente a orientación a objetos interfaces y componentes.

 con este informe se quiere dotar a los integrantes de la cipa de conocimientos

básicos para el desarrollo del curso.
 OBJETIVOS ESPECIFICOS

 Se busca enseñar que la metodología de desarrollo de software brinda los pasos con
sus respectivos requisitos para un software sea nuevo o modificado.

 Informar que la metodología de software aporta garantía y calidad por el

cumplimiento de sus requisitos.

 El desarrollo de la metodología de software tiene enfoques como lo son el modelo

de cascada, el prototipado, el espiral, el incremental y la RAD.

 Se aclara que los componentes para el desarrollo de software es la evolución de la

metodología orientada a objetos
 ¿Qué es una metodología de desarrollo de software?
Una metodología de desarrollo de software no es más que una serie de pasos que se
realizan de forma rigurosa tal que su resultado a partir de unos requisitos nuevos o
modificados sea un software nuevo o modificado.

Requisitos nuevos Sistema nuevos o

o modificados modificados

¿Qué nos aporta una metodología de desarrollo de software?

La gracia de una metodología es que aporta una garantía de calidad. Un producto de
software es de calidad si cumple rigurosamente con todos y cada uno de sus requisitos. Es
decir, calidad = requisitos satisfechos. Gracias a esto podemos medir la calidad de un
producto basándonos en los requisitos iniciales. También nos aporta una forma de estimar
y controlar costos. Así podemos saber cuánto vamos a tardar en realizarlo y si nos sale o no
rentable llevarlo a cabo antes de realizar la inversión completa de tiempo, dinero y esfuerzo.
También evita una gran parte de los esfuerzos perdidos en rectificar fallos que se pueden
evitar utilizando una metodología adecuada.
El modelo incluye seis diagramas: de clase, objeto, estado de transición, la interacción,
módulo, y el proceso. * Top-down programming, evolucionado en la década de 1970 por el
investigador de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo Estructurado. * Proceso
Unificado, es una metodología de desarrollo de software, basado en UML. Organiza el
desarrollo de software en cuatro fases, cada una de ellas con la ejecución de una o más
iteraciones de desarrollo de software: creación, elaboración, construcción, y las directrices.
Hay una serie de herramientas y productos diseñados para facilitar la aplicación. Una de las
versiones más populares es la de Rational Unified Process.
¿Qué metodología escoger?
Existen dos tipos principales de metodologías, las Ligeras y las Pesadas. Las primeras son
metodologías extremadamente prácticas que generalmente obvian gran parte de la
documentación y están más preparadas para utilizarse en proyectos cuyos requisitos
cambiarán constantemente durante todo el proceso.
Ejemplos de metodologías ligeras podrían ser extreme Programming (XP), SCRUM y crystal,
mientras que ejemplos de metodologías pesadas podrían ser Rational Unified Process
(RUP), ICONIX y Métrica 3.

El ciclo de vida del software es el conjunto de etapas que sigue un proyecto de software
desde su concepción hasta su finalización y cierre, inclusive los mantenimientos (es decir,
cambios o ajustes que puedan producirse una vez está implementado, nuevas versiones,
etc.)
MODELOS DE METODOLOGIA

Enfoques de desarrollo de software

Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el
desarrollo de software. Estos son los enfoques más generales, que se desarrollan en varias
metodologías específicas. Estos enfoques son los siguientes:
Metodología en cascada: Framework lineal.

el estilo del modelo en cascada, es que no podrás avanzar a la siguiente fase, si la anterior
no se encuentra totalmente terminada, pues no tiene por qué haber vuelta atrás. Vamos a
ver cuáles son las fases de desarrollo de software del modelo en cascada, para que te
puedas dar una idea.

1. Análisis de Requisitos. El primer nivel del modelo cascada, es el análisis de requisitos.

Básicamente lo que se documenta aquí, son los objetivos de lo que el software debe hacer
al terminar el desarrollo, sin entrar en detalles de la parte interna, los cuales se verán
durante el proceso. Sin embargo, es importante señalar que una ves avanzado el paso de
análisis, no puede haber vuelta atrás, pues la metodología para el diseño de software con
la cual se trabaja no lo permitirá.

2. Diseño del Sistema. Todo lo que conlleva el armado de un diseño para el sistema que
vayas a utilizar, es lo que continua después del análisis de requisitos. Aquí se elaborará lo
que es la estructura del sistema y se determinarán las especificaciones para cada una de las
partes del sistema que se planea desarrollar. Siendo del mismo modo, una fase a la cual ya
no se podrá volver después de haber bajado al nivel 3.
3. Diseño del Programa. En este punto, aún no ingresamos a lo que es la escritura de código,
sin embargo, ya se realizan los algoritmos que se van a utilizar en la programación. Si bien
recuerdas, un algoritmo no necesariamente es código, simplemente tomas una hoja de
papel y escribes el algoritmo que vas a utilizar. Esto es precisamente lo que se realiza en el
paso número 3.

4. Codificación. Seguramente como programador, esta es la parte que estabas esperando,

pues ahora es momento de empezar a escribir todo el código que será necesario para el
desarrollo del software. Para este punto, la velocidad y el tiempo que se requiera dependerá
mucho del lenguaje de programación que vayas a utilizar. Pues algunos lenguajes de
programación permiten utilizar componente, bibliotecas e incluso algunas funciones para
reutilizar código, las cuales podrán acelerar el proceso de codificación en gran manera.

5. Ejecución de Pruebas. La codificación ha terminado y ahora es momento de verificar que

nuestro sistema es realmente funciona, antes de que el cliente empiece a utilizarlo. Este es
precisamente el objetivo de la fase 5 de pruebas. Aquí es recomendable que intentes mover
lo más que se pueda tu software, con el objetivo de dañarlo intencionalmente, de este
modo, si supera las pruebas de daño realizadas por tí, entonces estará listo para el usuario
final.

6. Verificación. Después de haber realizado una gran cantidad de pruebas en la Fase 5,

debemos migrar a la verificación. Esta fase consiste en la ejecución del Software por parte
del usuario final. Si la fase cinco se realizó correcta y profundamente, el software no tendrá
ningún tipo de problema y el usuario final quedará satisfecho con el resultado.

7. Mantenimiento. Seguramente te has dado cuenta, de que las aplicaciones o el software

actual, constantemente se está actualizando. Esto se debe principalmente a que se le da
mantenimiento al software, se solucionan errores, se quitan algunos bugs, se añaden
funcionalidades, todo después de que el usuario final ya lo ha probado y utilizado en su fase
final. Esta es posiblemente una de las fases más tediosas del modelo de desarrollo de
software, pues debes estar atento a los comentarios de los usuarios, para ver qué cosas son
las que no funcionan correctamente y a las cuales hay que darles mantenimiento
Método de Prototipos

Consiste básicamente en que en base a los requerimientos y necesidades que tiene el

cliente, se realiza de forma rápida un prototipo, este no vendrá completo ni mucho menos
terminado, pero si permitirá contar con las bases necesarias para que cualquier
programador pueda seguir trabajando en el hasta llegar al código final.

etapas de desarrollo de software por las cuales tendrás que pasar, en caso de utilizar la
metodología de prototipos.

1. Planeación. A diferencia de otras metodologías, la planeación debe ser muy rápida, en

esta fase no puedes demorarte mucho, pues recuerda que solamente será un prototipo por
el momento.

2. Modelado. Nuevamente, una fase que deberá ser suficientemente rápida como para que
nos quite nada de tiempo. Hacer el modelado será simple y te sigo recordando que
solamente es un prototipo, al menos por ahora.

3. Elaboración del Prototipo. Ya que contamos con la planeación de lo que vamos a realizar
y el modelado rápido, entonces es momento de elaborar el prototipo. Para esta instancia,
ya no te diré que lo debes hacer rápido, puesto que te tomará el tiempo que tenga sea
necesario elaborarlo, recuerda que este ya se muestra al cliente, así que ya es una fase
importante.
4. Desarrollo. Posterior a contar con el prototipo elaborado y mostrado al cliente, es
momento de comenzar el desarrollo. Este te tomará una gran cantidad de tiempo,
dependiendo del tamaño del proyecto y el lenguaje de programación que se vaya a utilizar.

5. Entrega y Retroalimentación. Una de las cosas con las que cuenta el modelo de
prototipos, es que, una vez entregado el proyecto, debemos darle al cliente cierta
retroalimentación sobre cómo utilizarlo y ciertamente es una fase que se encuentra dentro
de las etapas de desarrollo de software esta metodología.

6. Comunicación con el Cliente. Es importante que una ves entregado el proyecto,

tengamos cierta comunicación con el cliente, básicamente para que nos indique si el
proyecto es correcto o si desea agregarle ciertas funciones, nuestra metodología lo permite.
Si fuera en modo cascada, entonces sería algo realmente imposible de hacer.

7. Entrega del Producto Final. Por último, solamente quedará entregar el sistema elaborado
mediante esta metodología. Aquí tendrás la ventaja de que el código es reutilizable, para
que así con el prototipo ya puedas simplemente empezar de nuevo y con una buena base
de código que te acelerará el proceso.

Modelo Incremental o Iterativo y Creciente

el Modelo Incremental repite el modelo de cascada una y otra ves, pero con pequeñas
modificaciones o actualizaciones que se le puedan ir agregando al sistema. De este modo el
usuario final se ve sumamente sumergido en el desarrollo y puedes proporcionarle un
resultado óptimo.
Fases del Modelo Incremental
1. Inicialización. como en todo modelo de desarrollo, debe haber una inicialización, aquí se
puede hablar de dar una idea, de tener algunos requisitos que se buscan en el proyecto y
ciertas especificaciones que se pueden manejar. No es necesario que se haga una lista total
de requerimientos pues recordemos que el proyecto se basa en iteraciones, así que el
proyecto puede ir evolucionando poco a poco.

2. Periodos de Iteración. Durante el desarrollo del proyecto, es cuando damos inicio a las
iteraciones. La primera iteración se realiza con las características iniciales, básicamente al
final de la primera iteración, queda un pequeño prototipo de lo que será el proyecto, pero
se puede volver a inicializar la iteración y realizar modificaciones en los procesos, como el
análisis y las especificaciones o funciones que el usuario final requiere para su sistema. El
número de iteraciones que se realicen son ilimitadas y dependerá tanto del desarrollador
como del usuario final. Si nuestro objetivo es que el cliente o la persona que necesita el
trabajo quede completamente satisfecha, entonces nos veremos en la necesidad de hacer
la cantidad de iteraciones que se requieran al final del día.

3. Lista de Control. Es importante que conforme se vaya realizando cada iteración, se vaya
llevando un control de este en una lista. Como si fuera un programa que recibe
actualizaciones constantemente. Cada una de las actualizaciones o iteraciones deberá ser
documentada y de ser posible, guardada en sus respectivas versiones, para que sea sencillo
volver atrás, en caso de que una iteración no sea exitosa o el usuario ya no la requiera.

Modelo en Espiral
se trata de un modelo evolutivo, que conforme avancen los ciclos, irá incrementando el
nivel de código fuente desarrollado, un incremento en la gestión de riesgos y por supuesto
un incremento en los tiempos de ejecución y planificación del sistema, esto es lo que tiene
el modelo en espiral.

Para que tengas una idea más clara, el modelo en espiral es principalmente utilizado para
el desarrollo de grandes proyectos como la creación de un sistema operativo.

1. Determinar Objetivo. Es importante que siempre consideres una planeación inicial, esta
solo se realizará una vez. Sin embargo, el proceso de determinar objetivos se hará
constantemente durante cada iteración que se vaya realizando con el modelo espiral. Esto
se debe a que poco a poco se irá incrementando más el tamaño del manual de usuario, los
requisitos, las especificaciones e incluso las restricciones. Todo esto entra en lo que es la
tarea de objetivos y con cada vuelta en el espiral entraremos a esta tarea, la cual como
todas las demás, es fundamental.

2. Análisis de Riesgo. Una etapa donde incluso una lluvia de ideas podría ayudar, el análisis
de riesgos. Aquí deberás tener en cuenta todo aquello que pueda dañar a tu proyecto, ya
sea que se trate de ciertas amenazas o de posibles daños que se puedan ocasionar, teniendo
además un Plan B por así decirlo, para que en caso de que ocurra algo inesperado, tener a
la mano la solución para continuar con el proyecto. En esta fase del modelo espiral,
podemos agregar lo que son la creación de prototipos, pues siempre es bueno tener un
respaldo de nuestro código, se esta forma en caso de que algo malo suceda, volvemos a la
versión anterior. Así que cada vez que vayamos a ingresar a la fase de pruebas e
implementación, será necesario contar con un prototipo que nos respalde.

3. Desarrollar, Validar y Probar. Básicamente en esta fase, la forma en que se estará

desarrollando el proyecto, dependerá del análisis de riesgos, pues siempre se va a ir
desarrollando el proyecto enfocándose en los riesgos que podemos evitar en nuestro
software, es decir, si la situación de riesgo más obvia se encuentra en la interfaz del usuario,
entonces hay que trabajar con prototipos para este enfoque, creando evoluciones
proporcionales, para ir evitando ese tipo de riesgos. Esto no significa que ignoremos el resto
del proyecto o del desarrollo, sin embargo, el modelo en espiral si acomoda un poco más
las prioridades al momento, independientemente de todo lo demás. Por lo que siempre en
cada vuelta o iteración que se le dé al modelo de espiral, tu avance siempre dependerá del
análisis de riesgo, hasta que este sea mínimo y el desarrollo pueda continuar de forma
normal.

4. Planificación. Antes de proceder a realizar otra iteración o vuelta a la espiral, debemos

prestar atención a lo que sucedió en la vuelta anterior. Debemos analizar detalladamente
si los riesgos encontrados ya tuvieron solución, lo cual debe ser lo ideal, puesto que ahora
habría que analizar más especificaciones y más requisitos del sistema para continuar con el
desarrollo. Básicamente la fase de planificación nos servirá para determinar el avance de
nuestro proyecto y indicar hacia dónde vamos a dirigirnos en la próxima iteración.
RAD: Desarrollo Rápido de Aplicaciones (Rapid Aplicación Development)

A diferencia de otras metodologías para el desarrollo de software, la metodología RADo

desarrollo rápido de aplicaciones, no cuenta con una serie de fases ordenadas por así
decirlo. Aunque si está basada en lo que es el modelo de cascada y la creación de prototipos,
sin embargo, el proceso es muy independiente a contar con ciertas fases estipuladas como
los modelos que hemos visto anteriormente.

DISEÑO ORIENTADO A OBJETOS

El diseño orientado a objetos (DOO) es una fase de la metodología orientada a objetos para
el desarrollo de software.
Su uso induce a desarrolladores y programadores a pensar en términos de objetos, en vez
de procedimientos, cuando planifican el código.
Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La
"interfaz del objeto", esto es, las formas de interactuar con el objeto, también se definen
en esta etapa.
Un programa orientado a objetos se caracteriza por la interacción de esos objetos.
El diseño orientado a objetos es la disciplina que define los objetos y sus interacciones para
resolver un problema de negocio que fue identificado y documentado durante el análisis
orientado a objetos (AOO).
INTERFAZ
El término interfaz no se refiere a las interfaces gráficas. Las interfaces son una manera
de describir qué debería hacer una clase sin especificar el cómo.
Una interfaz es la descripción de uno o más servicios (métodos) que posteriormente
alguna clase puede implementar (y así mismo ofrecer).
Por ejemplo, si un alumno sabe alemán, tenemos idea de lo que él es capaz. Además de
ser persona (herencia) él cumple la interfaz “interprete de alemán”. También podríamos
decir que él es un “interprete de alemán” (la misma relación que en herencia).
Otro Ejemplo: si usted se entera que alguien es salvavidas, él sabrá responder ante una e
mergencia en el agua. Por una parte, está la descripción de qué sabe hacer un salvavidas
y por otro hay personas que tienen esas “implementaciones” y
lo mismo se puede pensar para personas que tienen certificación Java.

En java cada clase puede tener solo una clase base (en java no hay herencia múltiple).
Se cumple también el principio de sustitución. Instancias de la clase que implementa una I
nterfaz pueden ser usadas donde se espera una instancia de la interfaz. Es similar a usar
una instancia de una subclase cuando se espera un objeto de la clase base.
No se permite crear instancias (objetos) de una Interfaz. Por la misma razón que no se p
uede crear instancias de clases abstractas, no se tienen la implementación. new InterfazX
();
Todos los métodos de una Interfaz son públicos. No es necesario indicarlo.
Pueden incluir constantes. En este caso son siempre public static final.

Interfaces: Aspectos sintácticos

Se debe de tener en cuenta dos cosas: si la interfaz no existe, debemos definirla y la segunda
es que luego debemos de implementar la interfaz en alguna clase.

Una interfaz es un conjunto de métodos abstractos y de constantes cuya funcionalidad es

la de determinar el funcionamiento de una clase, es decir, funciona como un molde o como
una plantilla. Al ser sus métodos abstractos estos no tienen funcionalidad alguna, sólo se
definen su tipo, argumento y tipo de retorno.
La construcción de una Interfaz es la siguiente:

Para declarar una o más Interfaces ponemos, a la derecha del nombre de la clase, la palabra
clave "implements" seguido de los nombres de las interfaces separadas por comas.:
También es posible heredar e implementar al mismo tiempo:

Algunas características de las Interfaces son:

 Las Interfaces solo pueden tener visibilidad de package o public.
 Todos los métodos declarados en una Interfaz son public y abstract, si no se le
indica, Java lo pondrá implícitamente.
 Los métodos de una Interfaz no pueden ser estáticos, ya que estos deben ser
redefinidos, y al ser estáticos les sería imposible.
 Todos los atributos declarados en una Interfaz son "public static final" y deberán
tener asignado un valor constante. Todos los nombres de constantes van
en "MAYÚSCULAS"
 Una clase puede implementar una o más interfaces.
 Una Interfaz puede heredar de una o varias interfaces, pero no pueden
implementar NADA. Como sabemos, las clases solo pueden heredar de otra clase,
pero las Interfaces pueden hacer herencias múltiples.
 Todas las clases que implementen una interfaz deben de redefinir todos los métodos
de esa interfaz.
 Las interfaces no tienen constructor, por lo que no es posible crear objetos con el
operador "new" de ésta.
 Si se implementa en una clase una Interfaz, y esta Interfaz hereda de otra, la clase
deberá implementar todos los métodos de la interfaz que implementa y de los
métodos que esta hereda.
 Para la herencia de las interfaces se pone la palabra clave extends y se ponen todas
las interfaces que se deseen separadas por comas.
  Una Interfaz puede ocultar constantes y métodos heredados de otras Interfaces si
los vuelve a declarar en la clase que hereda.
Ejemplo:

Esta interfaz contiene:

 2 atributos constantes NUMERO1 y NUMERO2. Podemos evidenciar que un
atributo es declarado como "final" y otro no, pues bien, aunque no se lo pongamos,
java nos lo incluye implícitamente, con lo cual, aunque o esté puesto, sigue
siendo "final"
 4 métodos. Dijimos anteriormente que los métodos de una interfaz deben
ser "public" y "abstract", pero en este ejemplo no están, ya que, como en el caso
de los atributos, java nos pone los métodos "public" y "abstract" implícitamente.
 Creamos una clase con método MAIN e implementamos la interfaz Operaciones.
 Posteriormente deberemos redefinir sus métodos. Veréis que en el tipo de retorno
obtengo los atributos de la interfaz Operaciones y puesto que no podemos crear
objetos de la interfaz, ya que no utiliza constructores, hacemos su llamada a los
atributos como:
 Operaciones.NUMERO1
 Operaciones.NUMERO2.
 Esto es debido a que son estáticos e inmutables. Este tipo de llamada también la
vimos en la clase Math
 Posteriormente en la MAIN creamos un objeto de la clase Principal y llamamos a
todos sus métodos y los mostramos por pantalla.
Una cosa que me gustaría dejar más o menos clara, y es que en la MAIN creamos un objeto
de la clase Principal para llamar a sus métodos y no hacemos la llamada simplemente. Esto
es debido a que la MAIN es un método estático y como tal solo puede aceptar atributos y
métodos estáticos como los métodos que redefinimos de la interfaz no pueden ser
estáticos, creo un objeto de la propia clase y los voy llamando. En temas posteriores haré
una entrada para explicar mejor la palabra reservada "static".
COMPONENTES
Los componentes para el desarrollo de software no es un concepto nuevo; para muchos
autores simplemente es la evolución de la metodología orientada a objetos. De hecho,
muchas de las características de los componentes para el desarrollo parten de la idea del
diseño orientado a objetos, Pero la historia del desarrollo de software basado en
componentes proviene aún desde más Componentes de Software. Uno de los logros de la
revolución industrial fue el desarrollo por componentes, surgiendo a partir de la necesidad
de estandarizar los elementos de los productos realizados en línea, como los automóviles.
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 en artefactos de software
necesarios para expresar, implementar y poner en marcha el concepto de elemento
reusable de un sistema más grande de negocios.
Sin embargo, más allá de estas definiciones existen algunas características claves para que
un elemento pueda ser catalogado como componente:
– Identificable: Debe tener una identificación que permita acceder fácilmente a sus
servicios y que permita su clasificación.
– Auto contenido: Un componente no debe requerir de la utilización de otros para finiquitar
la función para la cual fue diseñado.
– Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones
u otro componente que lo remplace y mejore.
– Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a
lo largo de su implementación.
– Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar, pero
su implementación sí.
– Bien Documentado: Un componente debe estar correctamente documentado para
facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
– Es genérico: Sus servicios debe servir para varias aplicaciones.
– Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación.
– Independiente de la plataforma: Hardware, Software, S.O.

Existen ya varios modelos que permiten entender los componentes de software, para poder
encontrar los componentes que determinada aplicación necesita.
¿CÓMO CLASIFICAR COMPONENTES?
La clasificación de componentes es un proceso extenso, ya que un componente involucra
en sí mismo varios atributos relevantes. En este segmento se expone una serie de variables
que podrían considerarse criterios de clasificación de componentes:
CLASIFICACIÓN DE COMPONENTES.
1. Tamaño El tamaño de los componentes puede ser medido por medio de las métricas
utilizadas en diseño orientado a objetos. Esto significa que la medición del tamaño de un
componente puede ser medido a través de:
• Líneas de Código (LDC)
• Orientadas a Función Componentes de Software 6 “Si un componente resulta ser
demasiado grande en tamaño, el proceso de aseguramiento de calidad del mismo será más
complicado y exigente para el desarrollador.
2. Complejidad: En algunas ocasiones, son utilizadas métricas de tamaño para evaluar la
complejidad, pero es recomendable hacer uso de otro tipo de métricas. “Si un componente
es demasiado trivial no podrá sacársele mayor provecho en su reutilización, y si el
componente es demasiado complejo será difícil asegurar su calidad”.
3. Métricas de Complejidad: Las métricas más utilizadas para medir la complejidad de los
componentes, combina uno de los métodos más reconocidos para medir la complejidad de
métodos o algoritmos desarrollado por Tomas McCabe, “Complejidad Ciclomática”, este
método mide el número de decisiones lógicas en un segmento de código. A continuación,
nombramos cuatro diferentes técnicas para medir la complejidad de un componente:
• CPC (Component Plain Complexity): Mide la complejidad del componente por medio de
la suma de clases, clases abstractas e interfaces, la complejidad de clases y métodos.
• CSC (Component Static Complexity): Se centra en la estructura interna del componente
por medio de una visión estática del mismo, utilizando variables como la relación entre las
clases y el peso de cada relación.
• CDC (Component Dynamic Complexity): Se centra en el número de mensajes que pasan
dentro del componente por medio de una visión dinámica, evaluando variables como la
frecuencia en el intercambio de mensajes entre clases y la complejidad de los mensajes.
• CCC (Component Cyclomatic Complexity): Esta medida de complejidad es utilizada cuando
el componente ya ha sido finalizado. Utiliza como variables el código desarrollado, la suma
de las clases, interfaces, métodos definidos en cada una de las interfaces. A diferencia del
método CCC, los métodos anteriores CPC, CSC, CDC utilizan para sus cálculos los diagramas
de clase, la interacción de los diagramas y el diagrama de componentes.
- Mantenibilidad “La mantenibilidad de un sistema es la facilidad con la cual puede ser
modificado frente a cambios en el ambiente, requerimientos funcionales o especificaciones
funcionales”. Para los componentes de software esta es una característica de vital
importancia, ya que su propia naturaleza los obliga a tener la capacidad de adaptarse a
diferentes entornos. Generalmente, las métricas que se utilizan para medir la
mantenibilidad utilizan variables que miden los atributos, el comportamiento y el flujo de
trabajo, entre otros.
-Reusabilidad Componentes de Software 7 La reusabilidad de un componente se puede
medir a partir de dos diferentes perspectivas.
• Cómo puede un componente ser reutilizado: Este tipo de medida tiene en cuenta las
siguientes variables: El número de cada método de interfaz que puede proveer funciones
en común entre varias aplicaciones en un dominio, el número de métodos declarados en la
interface que pertenecen al componente.
• Cómo es re - usado un componente en una aplicación particular: Las variables que se
miden para este objetivo en particular son: Las líneas de código re - utilizadas por el
componente en una aplicación, el total de líneas entregados en la aplicación. La
combinación de estas dos variables resulta el porcentaje de funcionalidad que aporta el
componente dentro de toda la aplicación.
4. Frecuencia de re – uso El número de veces que ha sido utilizado un componente dentro
de distintas aplicaciones, es sin lugar a duda el mejor indicador de frecuencia de re– uso.
Cabe anotar que este atributo puede ser solo medido en componentes que ya han sido
expuestos al mercado.
5. Confiabilidad Es la probabilidad de falló en el funcionamiento del componente dentro de
cierto escenario operacional.
¿CÓMO EVALUAR LA CALIDAD DE UN COMPONENTE?
“La calidad dentro de la Ingeniería de Sistemas se define como la totalidad de aspectos y
características de un producto o servicio que tiene que ver con su habilidad de satisfacer las
necesidades declaradas o implícitas”. La calidad de los componentes de software puede ser
el factor decisivo para la selección de los componentes que entrarán a ser parte de un nuevo
sistema, es decir, si dos componentes son candidatos para hacer parte de una aplicación y
muestran la misma funcionalidad, el nivel de calidad que implemente cada uno de ellos será
el elemento sobre el cuál se base la decisión final. Algunos de los elementos que pueden
dar al usuario una idea del nivel de calidad de un componente son:
• Funcionalidad
• Interfaz
• Usabilidad
• Pruebas
• Seguridad
TIPOS DE COMPONENTES
Framework: Los frameworks de componentes proporcionan servicios que soportan un
modelo de componentes. Estos modelos de componentes son patrones que permiten
interactuar entres si de acuerdo al problema que resuelven y permiten la extensibilidad del
framework y su funcionalidad, estos son aplicados a dominios específicos, lo cual hace que
el framework también lo sea, se dice que un framework es una aplicación incompleta y
Componentes de Software genérica, sobre la cual las aplicaciones que se implementan (las
que soporta) son las que le dan el estado final definiendo una funcionalidad específica y
propia. Las principales ventajas que ofrecen los frameworks son la reducción del costo en
el proceso de desarrollo de aplicaciones software para dominios específicos, y la mejora de
la calidad del producto final. Existen tres tipos de Frameworks, los Frameworks de caja
blanca exigen al usuario un conocimiento muy profundo de su estructura interna y pueden
llevar aparejados los problemas que acarrea la herencia, como pueden ser las anomalías de
la herencia. Por otro lado, los Frameworks de caja negra enfrentan problemas de la
programación orientada a componentes, como son la composición tardía o la clarividencia
(previsión de los posibles usos futuros del Framework). Esto significa que cualquiera de los
dos necesita de un entendimiento técnico del framework sobre el cual se quiere trabajar y
una previa evaluación de sus características principales y su descripción. La elección de un
framework es un proceso de ingeniería de software y de este depende el producto final que
se quiera desarrollar. La mala elección de éste conllevará a un desarrollo complejo y fuera
del domino. Es necesario integrar los conceptos de DSBC y la ingeniería de dominio para
llegar a un desarrollo satisfactorio. Utilizar un Framework no es una tarea que se debe
tomar a la ligera, es necesario la utilización y condensación de conocimientos para que este
pueda ser utilizado como un componente. No es necesario conocer todos los tipos de
Frameworks existentes, pero sí es necesario saber cómo éstos ofrecen sus servicios. La
arquitectura de los Frameworks se basa en el uso de patrones de software, los cuales
simplifican su construcción y permiten su extensión, los patrones no solo se convierten en
los constructores del framework, sino que constituyen la manera de interactuar con este.
La manera más común de desarrollar una aplicación sobre un framework es a través de los
patrones, los cuales por medio de sus interfaces nos permiten interactuar con él y adaptarlo
a la aplicación.
Bussines Component: Los componentes de negocio, son aquellos componentes
especializados en prestar alguna clase de servicio, enfocado a un dominio en particular. Los
componentes de negocio son aquellos componentes que generan el valor agregado y se
enfocan a las necesidades de los clientes. Un componente de negocio es aquel que realiza
o provee al cliente de la funcionalidad necesaria en su aplicación para resolver sus
necesidades y cumplir con sus requerimientos. Este tipo de componentes se sitúan por lo
general en el último escalafón dentro del desarrollo basado en componentes, ya que estos
son los que darán la funcionalidad propia del negocio a la aplicación, estos componentes
están soportados por lo general bajo un framework en particular, el cual permite que el
componente de negocio se desempeñe y cumpla con su objetivo, lo cual implica que
además de las características propias de un componente de software, tenga también las
características adicionales del framework sobre el cual está soportado. Un componente de
negocio no le da particularidad a una aplicación, ni realiza Componentes de Software 9 por
sí solo la funcionalidad de una aplicación; es la integración entre el framework y por lo
general varios componentes de negocio, los que le dan la particularidad de todo un
desarrollo. Los componentes de negocio permiten interactuar con otros a través de
protocolos ya estandarizados inherentes al framework sobre el cual están soportados,
como por ejemplo J2EE. Los componentes de negocio necesitan de un nivel de
especificación más allá del establecido por el framework o los patrones. Los niveles de
especificación de los componentes de negocio resultan útiles, ya que cada nivel se enfoca
a un aspecto de la especificación del negocio y direcciona diferentes roles en el desarrollo
como desarrollador de componentes, documetador, jefe de proyecto, etc. Esto ayuda en la
búsqueda del componente necesario que se adapte al dominio y prevea la funcionalidad
que se busca, desde diferentes niveles de conocimientos. Existen siete distintos niveles,
cada uno con un aspecto en específico direccionado al negocio:
Nivel de Marketing: Características de la organización y el negocio, condiciones técnicas.
Nivel de tarea: Ayuda a las tareas del negocio que corresponden al dominio de la aplicación.
Propósito de la aplicación.
Nivel de terminología: Definición de conceptos del dominio de la aplicación.
Nivel de Calidad: Criterios de calidad, procedimientos y categorías de medidas, niveles de
servicio.
Nivel de interacción: Secuencias de dependencias a través de servicios del mismo
componente de negocio y de diferentes componentes de negocio.
Nivel de Comportamiento: Pre y postcondición, invariantes.
Nivel de Interfaces: Servicios, parámetros, tipos de datos y excepciones. Por medio de estos
niveles la búsqueda de un componente de negocio resulta más rápida y fácil, acelerando el
proceso de DSBC.
 CONCLUSIONES

Este informe nos da a conocer lo que aporta la metodología de desarrollo de software y así
mismo sus fases ya que cada una organiza a la metodología con la ejecución de una o más
iteraciones. Los resultados de la investigación de la metodología del diseño de software son,
hacer saber que el ciclo de vida del software es el conjunto de etapas que sigue un proyecto
desde su concepción hasta su finalización y cierre, es tener en claro que cuenta con
enfoques los cuales se desarrollan en varias metodologías específicas, es saber que el uso
del diseño orientado a objetos induce a desarrolladores y programadores a pensar en
términos objetivos en vez de procedimiento cuando planifican el código y así lograr con
éxito el desarrollo y la ejecución de nuestro software.
 WEB GRAFÍA

http://ima.udg.edu/~sellares/EINF-ES2/Present1011/MetodoPesadesDocumentacio.pdf
(INTRODUCCIÓN DE DESARROLLO DE SOFTWARE)

https://okhosting.com/blog/metodologias-del-desarrollo-de-software/
(METOLOGIAS DE SOFTWARE)

http://picarcodigo.blogspot.com/2012/10/interfaces.html
(EXPLICACIÓN DE INTERFACES)

http://profesores.elo.utfsm.cl/~agv/elo329/1s10/lectures/JavaInterfaces_InternalClasses.
pdf
(TEMA INTERFACES)

http://pegasus.javeriana.edu.co/~jcpymes/Docs/DSBC.pdf
(TEMA COMPONENTES)

https://www.google.com/search?q=metodologia+de+desarrollo+de+software&rlz=1C1NH
XL_esCO686CO686&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjBvcO51KfhAhXLx1kKH
WepD-MQ_AUIDigB&biw=1366&bih=625#imgrc=z6GDvTCxlDHpnM:
(IMAGEN DE METODOLOGIA DE DESARROLLO DE SOFTWARE)

https://www.google.com/search?rlz=1C1NHXL_esCO686CO686&biw=1366&bih=625&tb
m=isch&sa=1&ei=4DieXPzILcLX5gLYrbiADw&q=modelo+de+cascada&oq=MODELO+&gs_l=
img.1.4.35i39l2j0i67l5j0l2j0i67.109296.110552..113763...0.0..0.229.1322.0j5j2......1....1..g
ws-wiz-img.IHYaA0ibei4#imgrc=8v52uYL4PD07gM:
(IMAGEN DE MODELO METODOLOGIA DE CASCADA)

https://www.google.com/search?rlz=1C1NHXL_esCO686CO686&biw=1366&bih=625&tb
m=isch&sa=1&ei=VDmeXPXVH8XI5gL3sL-
gDw&q=METODO+PROTOTIPOS&oq=METODO+PROTOTIPOS&gs_l=img.3..0i8i30.73183.8
5729..86024...0.0..0.237.2770.0j16j1......1....1..gws-wiz-
img.......35i39j0i67j0j0i24.essMiAKEe0U#imgrc=In9lGP2GlnMtkM:
(IMAGEN DE MODELO METODOLOGIA DE PROTOTIPOS)

https://www.google.com/search?rlz=1C1NHXL_esCO686CO686&biw=1366&bih=625&tb
m=isch&sa=1&ei=qzmeXIPdOdCHggf1oZ_4DQ&q=METODO+INCREMENTAL&oq=METODO
+INCREMENTAL&gs_l=img.3..0l2j0i24l5.149985.152922..153661...0.0..0.257.2050.0j10j1...
...1....1..gws-wiz-img.......0i8i30.iYIQtar4y4w#imgrc=07WSCyLH1X23BM:
(IMAGEN DE MODELO METODOLOGIA INCREMENTAL)
https://www.google.com/search?rlz=1C1NHXL_esCO686CO686&biw=1366&bih=625&tb
m=isch&sa=1&ei=RjqeXNDpKsKO5wLMmaSoDw&q=METODO+ESPIRAL&oq=METODO+ESP
IRAL&gs_l=img.3..0l3j0i8i30l3j0i24l3.27795.29653..30102...0.0..0.217.1214.0j6j1......1....1..
gws-wiz-img.......0i10i24.IJ6wuWp0d6Y#imgrc=bEdkkbQQMfmMPM:
(IMAGEN DE MODELO METOLOGIA EN ESPIRAL)

https://www.google.com/search?rlz=1C1NHXL_esCO686CO686&biw=1366&bih=625&tb
m=isch&sa=1&ei=AzueXI6vNI2n5gKM-
L34Dw&q=metodologia+rad+fases&oq=METODOLOGIA+RAD+&gs_l=img.1.0.0j0i30j0i24l7.
41901.41901..43045...0.0..0.172.172.0j1......1....1..gws-wiz-img.q29kEVRlNaw#imgrc=Sm-
Xrl_BRYDGgM:
(IMAGEN DE MODELO ETODOLOGIA DE RAD)