ingenieriadesoftware1

INGENIERIA INFORMATICA

INGENIERÍA DE SOFTWARE I

ING. CLAUDIA LORENA DIAZ CARDOZO

UNICIENCIA

ING. CLAUDIA LORENA DIAZ

INGENIERIA DE SOFTWARE I

AGOSTO 2013


QUE ES UN SOFTWARE?

Programas de cómputo y su documentación asociada: requerimientos, modelos de diseño y manuales de usuario.
El software puede ser desarrollado para un cliente en particular o para un mercado general.

El software puede ser:
 Genérico: desarrollado para venderse a múltiples clientes (Excel, Word, etc.)
 A la medida: desarrollado bajo demanda del cliente a un desarrollador específico

El software nuevo puede ser creado desarrollando nuevos programas, configurando sistemas de software
genérico o reutilizando software existente.



AGOSTO 2013


QUE ES INGENIERIA DE SOFTWARE?

Es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la
documentación asociada requerida para desarrollar, operar y mantenerlos. Para tener éxito al diseñar y construir
un software necesitaremos disciplina, un enfoque de ingeniería.
Es la disciplina o área de la Ingeniería que ofrece métodos y técnicas para desarrollar y mantener un software. La
creación del software es un proceso intrínsecamente creativo y la Ingeniería del Software trata de sistematizar
este proceso con el fin de acotar el riesgo del fracaso en la consecución del objetivo creativo por medio de
diversas técnicas que se han demostrado adecuadas en base a la experiencia previa. La ingeniería en software es
una disciplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas
iníciales de la especificación del sistema, hasta el mantenimiento de este después de que utiliza.

Los Ingenieros de Software deben:
 Adoptar un enfoque sistemático para llevar a cabo su trabajo



AGOSTO 2013


 Utilizar las herramientas y técnicas apropiadas para resolver el problema planteado, de acuerdo a las
restricciones de desarrollo y a los recursos disponibles.

La creación del software es un proceso intrínsecamente creativo y la Ingeniería del Software trata de sistematizar
este proceso con el fin de acotar el riesgo del fracaso en la consecución del objetivo creativo por medio de
diversas técnicas que se han demostrado adecuadas en base a la experiencia previa.



AGOSTO 2013


¿QUÉ ES UN PROCESO DE SOFTWARE?

Un conjunto estructurado de actividades cuya meta es el desarrollo o evolución de un software

Algunas actividades genéricas en todos los procesos de software son:
 Especificación, qué debe hacer el software y cuáles son sus especificaciones de desarrollo
 Desarrollo, producción del sistema de software
 Validación, verificar que el software cumple con lo solicitado por el cliente
 Evolución, cambiar/adaptar el software a las nuevas demandas

Estas actividades varían dependiendo de la organización y del tipo de sistema a desarrollarse.



AGOSTO 2013


ETAPAS DEL PROCESO DESARROLLO DE SOFTWARE

La ingeniería de software requiere llevar a cabo numerosas tareas agrupadas en etapas, al conjunto de estas
etapas se le denomina ciclo de vida. Las etapas comunes a casi todos los modelos de ciclo de vida son las
siguientes:

 Análisis de requisitos
Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes
piensan que ellos saben lo que el software tiene que hacer, se requiere habilidad y experiencia para reconocer
requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma
en el documento ERS.
Así mismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que
participarán en el desarrollo del software.
La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa
depende en gran medida el logro de los objetivos finales.



AGOSTO 2013


La IEEE Std. 830-1998 normaliza la creación de las especificaciones de requisitos de software.

 Diseño y Arquitectura
La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren
de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de
hoy. El rol en el cual se delegan todas estas actividades es el Ingeniero de software, es la persona que añade valor
a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas.
La arquitectura de sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y
hardware, o de software.
Un diseño arquitectónico describe en general el cómo se construirá una aplicación de software. Para ello se
documenta utilizando diagramas, por ejemplo:

Diagramas de clases: diagrama estático que describe la estructura de
un sistema mostrando sus clases, atributos y las relaciones entre ellos.
Los diagramas de clases son utilizados durante el proceso de análisis y



AGOSTO 2013


diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los
componentes que se encargaran del funcionamiento y la relación entre uno y otro.

Diagramas de base de datos: esquema de una base de
datos describe la estructura de una Base de datos, en un
lenguaje formal soportado por un Sistema administrador
de Base de datos (DBMS). En una Base de datos
Relacional, el Esquema define sus tablas, sus campos en
cada tabla y las relaciones entre cada campo y cada tabla.



AGOSTO 2013


Diagrama de despliegue: El Diagrama de Despliegue se utiliza para modelar el hardware utilizado en las
implementaciones de sistemas y las relaciones entre sus componentes. Los elementos usados por este tipo de
diagrama son nodos, componentes (representados como una caja rectangular) y asociaciones.



Diagrama de secuencia: Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una
aplicación a través del tiempo y se modela para cada caso de uso. El diagrama de secuencia contiene detalles
de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y
mensajes intercambiados entre los objetos.



AGOSTO 2013


Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser
codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qué diagramas
elaborar.

 Programación
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no
necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta



AGOSTO 2013


etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño
previamente realizado.

 Pruebas
Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del
problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma
integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por
alguien distinto al desarrollador que la programó.
En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por
personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación
entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el
software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada
por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede
fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.



AGOSTO 2013


 Documentación
Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando
por diagramas de casos de uso, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de
eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

 Mantenimiento
Fase dedicada a mantener y mejorar el software para corregir errores descubiertos e incorporar nuevos
requisitos. Esto puede llevar más tiempo incluso que el desarrollo del software inicial. Una pequeña parte de este
trabajo consiste eliminar errores; siendo que la mayor parte reside en extender el sistema para incorporarle
nuevas funcionalidades y hacer frente a su evolución.

Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio
(definidas por la alta dirección), así como la interacción con los usuarios funcionales para la recolección,
clasificación, identificación, priorización y especificación de los requisitos del software



AGOSTO 2013


MODELOS DE PROCESOS DE SOFTWARE

La ingeniería de software dispone de varios modelos, paradigmas y filosofías de desarrollo, en los cuales se apoya
para la construcción del software:

Modelo en cascada o Clásico (modelo tradicional)

Consiste en la ejecución secuencial de una serie de fases que se suceden, lo que da nombre al modelo.
Cada fase genera documentación para la siguiente. Esta documentación debe ser aprobada.
Una fase no comienza hasta que la anterior ha terminado. Requiere disponer de unos requisitos completos y
precisos al principio del desarrollo.



AGOSTO 2013


Modelo en espiral
Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo
que aparece a la hora de desarrollar software. Para ello, se comienza
mirando las posibles alternativas de desarrollo, se opta por la de riesgo
más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir
haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas
alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que
llegue un momento en el que el producto software desarrollado sea
aceptado y no necesite seguir mejorándose con otro nuevo ciclo.



AGOSTO 2013


Modelo de prototipos
Se muestra al cliente el software en diferentes estados sucesivos de desarrollo. Este modelo pone énfasis en la
etapa de especificación de requerimientos a través de la construcción de prototipos (ejemplar o primer molde)
que aproximan al usuario a la idea final del sistema, con el objeto de clarificar los requerimientos.



AGOSTO 2013


Desarrollo iterativo e Incremental
La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de programas de manera
incremental, permitiéndole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo
anterior, incrementando, versiones entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo
del sistema, y su uso (mientras sea posible). Los pasos claves en el proceso son comenzar con una
implementación simple de los requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de
versiones hasta que el sistema completo esté implementado. En cada iteración, se realizan cambios en el diseño y
se agregan nuevas funcionalidades y capacidades al sistema.



AGOSTO 2013


Proceso Unificado
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas
Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de
iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como
resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en
desarrollo.



AGOSTO 2013


Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el
ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las
iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas
varía a lo largo del proyecto.

¿CUÁLES SON LOS ATRIBUTOS DEL SOFTWARE DE CALIDAD?



AGOSTO 2013


El software debe proveer la funcionalidad y desempeño requeridos por el usuario y debe ser mantenible,
confiable y aceptable:
 Mantenible, el software debe poder evolucionar para continuar cumpliendo con las especificaciones
 Confiable, el software no debe causar daños físicos o económicos en el caso de que falle
 Eficiente, el software no debe desperdiciar los recursos del sistema

Aceptable, el software debe ser aceptado por los usuarios para los que fue diseñado. Debe ser entendible,
utilizable y compatible con otros sistemas

¿CUÁLES SON LOS RETOS DE LA INGENIERÍA DE SOFTWARE?
 Heterogeneidad: Desarrollar técnicas para construir software que pueda hacer frente a plataformas y
ambientes de ejecución heterogéneos (diferentes tipos de Hw y Sw).



AGOSTO 2013


 Tiempos de entrega: Desarrollar técnicas que permitan reducir los tiempos de entrega del software sin
comprometer la calidad
 Confianza: Desarrollar técnicas que permitan que los usuarios confíen plenamente en el software

RESPONSABILIDAD ÉTICA Y SOCIAL

La Ingeniería de Software comprende responsabilidades que van más allá de la simple aplicación de Habilidades
técnicas.
Los ingenieros de Software deben actuar de manera honesta y ética si desean ser respetados como profesionales.
Una conducta ética es más que sólo respetar la ley.
 Confidencialidad
 Competencia
 Derechos de propiedad intelectual
 Mal uso de la computadora



AGOSTO 2013


CÓDIGO DE ÉTICA Y PRÁCTICA PROFESIONAL

La versión corta del código resume las aspiraciones a un alto nivel de abstracción; las cláusulas que se incluyen en
la versión completa proporcionan ejemplos y detalles acerca de cómo estas aspiraciones modifican nuestra
manera de actuar como profesionales de la ingeniería de software. Sin las aspiraciones los detalles pueden
convertirse en tediosos y legalistas; sin los detalles las aspiraciones pueden convertirse en altisonantes pero
vacías; juntas, las aspiraciones y los detalles forman un código cohesivo.
Los ingenieros de software deberán comprometerse a convertir el análisis, especificación, diseño,
implementación, pruebas y mantenimiento de software en una profesión respetada y benéfica. De acuerdo a su
compromiso con la salud, seguridad y bienestar social, los ingenieros de software deberán sujetarse a los ocho
principios siguientes:
 Sociedad. Los ingenieros de software actuarán en forma congruente con el interés social.



AGOSTO 2013


 Cliente y empresario. Los ingenieros de software actuarán de manera que se concilien los mejores intereses
de sus clientes y empresarios, congruentemente con el interés social.
 Producto. Los ingenieros de software asegurarán que sus productos y modificaciones correspondientes
cumplen los estándares profesionales más altos posibles.
 Juicio. Los ingenieros de software mantendrán integridad e independencia en su juicio profesional.
 Administración. Los ingenieros de software gerentes y líderes promoverán y se suscribirán a un enfoque
ético en la administración del desarrollo y mantenimiento de software.
 Profesión. Los ingenieros de software incrementarán la integridad y reputación de la profesión
congruentemente con el interés social.
 Colegas. Los ingenieros de software apoyarán y serán justos con sus colegas.
 Personal. Los ingenieros de software participarán toda su vida en el aprendizaje relacionado con la práctica
de su profesión y promoverán un enfoque ético en la práctica de la profesión.
 Reconocer que las violaciones personales de este código son incongruentes con ser un ingeniero de
software profesional. ACM/IEEE

¿QUÉ ES CASE?



AGOSTO 2013


Las siglas CASE, significan Computer Aided Assisted Automated Software Systems Engineering (Ingeniería de
Software asistida por computadoras), entonces estas herramientas son un conjunto de programas y ayudas, que
dan asistencia a analistas, Ingenieros de software y desarrolladores durante el Ciclo de vida de desarrollo de
Software.
Algunas Herramientas CASE son sólo para la etapa de Diseño, Otras son generadoras de Código, otras
herramientas de Análisis y Diseño tienen una visión de Desarrollo orientada a procesos sin la capacidad de
modelamiento, y otras proveen Herramientas para el modelamiento sin incluir los procesos de Análisis o Diseño.

 Objetivos de las Herramientas CASE
Mejorar la productividad en el desarrollo y mantenimiento del software.
Aumentar la calidad del software.
Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos.
Mejorar la planificación de un proyecto



AGOSTO 2013


Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para
los requisitos.
Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la
gestión del proyecto.
Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
Gestión global en todas las fases de desarrollo de software con una misma herramienta.

Computer-Aided herramientas de ingeniería de software son los programas que se utilizan en todas y cada una de
las fases de desarrollo de un sistema de información sistema, incluyendo el análisis, diseño y programación. Por
ejemplo, los diccionarios de datos y herramientas de diagramación ayudan en las fases de análisis y diseño,
mientras que los generadores de aplicaciones aceleran la fase de programación.
Herramientas CASE proporcionan métodos automáticos para diseñar y documentar las técnicas de programación
estructurada tradicional. El objetivo final de CASO es proporcionar un lenguaje para describir el sistema global que
es suficiente para generar todos los programas necesarios.



AGOSTO 2013


 Tipos de herramientas CASE
Los tipos generales de herramientas CASE se enumeran a continuación:
Diagramas de herramientas: permite procesos, los datos del sistema y las estructuras de control de
representación gráfica.
Visualización e informe generadores Informática: ayudar prototipo cómo los sistemas se ven y se sienten. Esto
hace que sea más fácil para el analista de sistemas para identificar las necesidades de datos y la relación.
Herramientas de análisis: comprobar automáticamente importancia, especificaciones inconsistentes o
incorrectas en los diagramas, formularios e informes.
Repositorio central: permite el almacenamiento integrado de especificaciones, diagramas, informes e
información de gestión de proyectos.
Generadores Documentación: producir documentación técnica y de usuario en formatos estándar.
Los generadores de código: permitir la generación automática de programas y datos código de definición de base
directamente de los documentos de diseño, esquemas, formularios e informes.



AGOSTO 2013


 Ventajas de las herramientas CASE.
Las herramientas CASE son fáciles de usar y hace la vida mejor.
Mejorar la calidad del sistema desarrollado.
Aumentar la velocidad con la que los sistemas están diseñados y desarrollados.
Facilidad y mejorar el proceso de prueba a través de la utilización de comprobación automatizado.
Mejorar la integración de las actividades de desarrollo a través de metodologías comunes.
Mejorar la calidad y la integridad de la documentación.
Ayudar a estandarizar el proceso de desarrollo.
Mejorar la gestión del proyecto.
Simplificar el mantenimiento del programa.
Promover la reutilización de los módulos y la documentación.



AGOSTO 2013


Mejorar la portabilidad del software a través de entornos.

 Funciones de una herramienta CASE
Análisis de: Las herramientas de análisis de casos comprueban automáticamente incompletos, inconsistentes o
en las especificaciones correctas en diagramas, formularios e informes.
Diseñe: Aquí es donde el diseño técnico del sistema se creó mediante el diseño de la arquitectura técnica - elegir
entre los diseños arquitectónicos de las telecomunicaciones, hardware y software que mejor se adapte el sistema
de la organización y las necesidades futuras. También el diseño del modelo de los sistemas - la creación gráfica de
un modelo de interfaz gráfica de usuario, el diseño de la pantalla, y bases de datos, a la colocación de objetos en
la pantalla
Generación de código: Herramienta CASE tiene generadores de código que permiten la generación automática de
programa y base de datos de código definición directamente de los documentos, esquemas, formularios e
informes.
Documentación: Herramienta CASE tiene generadores de documentación para producir documentación técnica y
de usuario en formularios estándar. Cada fase de la SDLC produce documentación. Los tipos de documentación



AGOSTO 2013


que el flujo de una cara a la siguiente variará dependiendo de la organización, las metodologías empleadas y tipo
de sistema que se está construyendo.

 Herramientas CASE más usadas
ERwin es una herramienta de diseño de base de datos. Brinda productividad en diseño, generación, y
mantenimiento de aplicaciones. Desde un modelo lógico de los requerimientos de información, hasta el modelo
físico perfeccionado para las características específicas de la base de datos diseñada.



AGOSTO 2013


ERwin establece una conexión entre una base de datos diseñada y una base de datos, permitiendo transferencia
entre ambas y la aplicación de ingeniería reversa. Usando esta conexión, genera automáticamente tablas, vistas,
índices, reglas de integridad referencial llaves primarias, llaves foraneas), valores por defecto y restricciones de
campos y dominios.



AGOSTO 2013


EasyCASE Profesional Este tipo de herramientas se usan en las fases de Análisis y Diseño de proyectos software y
ayudan a realizar y trabajar con los correspondientes diagramas (Estáticos, Dinámicos y de Comportamiento)
siguiendo un cierto modelo de trabajo (Estructurado, Orientado a Objetos, etc.). Permite capturar los detalles de
diseño de un sistema y comunicar las ideas gráficamente, para que sean fáciles de ver y entender.
Permite generar esquemas de base de datos e ingeniería reversa
Permite capturar los detalles de diseño de un sistema y comunicar las ideas gráficamente, para que sean fáciles
de ver y entender.
Para un diseño legítimo y modelado de datos, procesos y eventos, permite crear y mantener diagramas de flujo
de datos, diagramas de entidad-relación, mapas de estructura y más.
Posee herramientas de corrección avanzadas que permiten revisiones generales.
Permite re-usar diagramas o partes de diagramas para economizar el diseño de un proyecto.
Soporta una gama amplia de metodologías estructuradas, permitiendo escoger los métodos más apropiados para
realizar las tareas.



AGOSTO 2013


Determina los tipos de esquemas según la metodología del proyecto seleccionada y notifica de errores a medida
que el modelo vaya construyéndose.
Soporte comprensivo al modelado de datos, procesos y eventos.
Posee desde el editor de diagramas flexible y un diccionario de los datos, así como una extensa cantidad de
reportes y análisis.
Es una herramienta multi-usuario.
Permite compartir datos y trabajar en un proyecto con otros departamentos. El equipo completo puede acceder a
proyectos localizados en el servidor de la red concurrentemente.
Para asegurar la seguridad de los datos, existe el diagrama y diccionario de los datos que bloquean por niveles al
registro, al archivo y al proyecto, y niveles de control de acceso.



AGOSTO 2013




AGOSTO 2013


Microsoft Project Es un software de administración de proyectos para asistir a administradores de proyectos en el
desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso, administrar presupuesto y
analizar cargas de trabajo.



AGOSTO 2013


JDeveloper: Primero se crea el código y después el diagrama.
PowerDesigner: Es una suite de aplicaciones para la construcción, diseño y modelado de datos a través de
diversas aplicaciones. Es la herramienta para el análisis, diseño inteligente y construcción sólida de una base de
datos y un desarrollo orientado a modelos de datos a nivel físico y conceptual, que dan a los desarrolladores
Cliente/Servidor la más firme base para aplicaciones de alto rendimiento



AGOSTO 2013


PATRÓN DE DISEÑO (design patterns)

Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de
software y otros ámbitos referentes al diseño de interacción o interfaces.
En la ingeniería de software, un patrón de diseño es una solución repetible general a un problema que ocurre
comúnmente en el diseño de software. Un patrón de diseño es una descripción o una plantilla para la forma de
resolver un problema que se puede utilizar en muchas situaciones diferentes.
Un patrón de diseño resulta ser una solución a un problema de diseño.
Un Diseño eficaz de software requiere considerar los problemas que pueden no hacerse visibles hasta más tarde
en la ejecución. La Reutilización de los patrones de diseño ayuda a evitar problemas sutiles que pueden causar
grandes problemas y mejora la legibilidad del código para los programadores y arquitectos están familiarizados
con los patrones.
Los patrones de diseño ofrecen soluciones generales, documentadas en un formato que no requiere
características específicas ligadas a un problema particular.



AGOSTO 2013


Para que una solución sea considerada un patrón debe poseer ciertas características:
 Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones
anteriores.
 Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en
distintas circunstancias.

Objetivos de los patrones
Los patrones de diseño pretenden:
 Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
 Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
 Formalizar un vocabulario común entre diseñadores.
 Estandarizar el modo en que se realiza el diseño.
 Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.



AGOSTO 2013


Asimismo, no pretenden:
 Imponer ciertas alternativas de diseño frente a otras.
 Eliminar la creatividad inherente al proceso de diseño.
 No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar
que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable.
"Abusar o forzar el uso de los patrones puede ser un error".

Tipos de Patrones

 Patrones de interfaces de usuario, esto es, aquellos que intentan definir las mejores formas de construir
interfaces hombre-máquina (Interfaz gráfica de usuario).



AGOSTO 2013


 Patrones para la construcción de sistemas empresariales, en donde se requieren especiales esfuerzos en
infraestructuras de software y un nivel de abstracción importante para maximizar factores como la
escalabilidad o el mantenimiento del sistema.
 Patrones para la integración de sistemas (véase Integración de aplicaciones empresariales), es decir, para la
intercomunicación y coordinación de sistemas heterogéneos.
 Patrones de flujos de trabajo, esto es para la definición, construcción e integración de sistemas abstractos de
gestión de flujos de trabajo y procesos con sistemas empresariales.

Estructuras o plantillas de patrones

Para describir un patrón se usan plantillas más o menos estandarizadas, de forma que se expresen
uniformemente y puedan constituir efectivamente un medio de comunicación uniforme entre diseñadores.
 Nombre del patrón. Describe el problema de diseño, junto con sus soluciones y consecuencias. Vocabulario de
diseño.



AGOSTO 2013


 Problema. Describe cuándo aplicar el patrón. Explica el problema y su contexto.
 Solución. Elementos que forman el diseño, relaciones, responsabilidades. No un diseño concreto, sino una
plantilla que puede aplicarse en muchas situaciones distintas.
 Consecuencias. Resultados, ventajas e inconvenientes de aplicar el patrón. P.ej.: relación entre eficiencia en
espacio y tiempo; cuestiones de implementación etc.

Clasificación de patrones

• De creación: Resuelven problemas relacionados con la creación de instancias de objetos. Procuran independizar
el sistema de cómo sus objetos son creados, compuestos y representados. Ayudan a que el sistema sea
independiente de cómo se crean, componen y representan los objetos.
• De estructura: Se centran en problemas relacionados con la forma de estructurar las clases.
• De comportamiento: Permiten resolver problemas relacionados con el comportamiento de la aplicación,
normalmente en tiempo de ejecución.



AGOSTO 2013


Relación de principales patrones GoF. La Banda de los cuatro. Ingenieros de IBM.
Fue hasta principios de la década de 1990 cuando los patrones de diseño tuvieron un gran éxito en el mundo de la
informática a partir de la publicación del libro Design Patterns escrito por el grupo Gang of Four (GoF) compuesto
por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides, en el que se recogían 23 patrones de diseño
comunes.

PATRONES CREACIONALES

Abstract Factory (fábrica abstracta):
Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí y haciendo
transparente el tipo de familia concreta que se esté usando.



AGOSTO 2013


Usar este patrón cuando:
 Un sistema que deba ser independiente de cómo se crean, componen y representan sus productos.
 Un sistema que deba ser configurado con una familia de productos entre varias.
 Una familia de objetos producto relacionados que está diseñada para ser usada conjuntamente, y es necesario
hacer cumplir esta restricción.



AGOSTO 2013


Factory Method (método de fabricación):
Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al
usuario la casuística, es decir, la diversidad de casos particulares que se pueden prever, para elegir el subtipo que
crear.

Singleton (instancia única):



AGOSTO 2013


Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a
dicha instancia.
Hay veces que es importante asegurar que una clase tenga una sola instancia, por ejemplo:
 Un gestor de ventanas
 Una única cola de impresión
 Un único sistema de ficheros

Builder (constructor virtual): abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso
en un único punto.

Prototype (prototipo): crea nuevos objetos clonándolos de una instancia ya existente.



AGOSTO 2013


Este patrón puede ser utilizado cuando se requiere que objetos o estructuras de objetos sean idénticos o se
parezcan mucho a otros objetos o estructuras existentes.

PATRONES ESTRUCTURALES

Composite (Objeto compuesto):



AGOSTO 2013


El patrón Composite sirve para construir objetos complejos a partir de otros más simples y similares entre sí,
gracias a la composición recursiva y a una estructura en forma de árbol.
Esto simplifica el tratamiento de los objetos creados, ya que al poseer todos ellos una interfaz común, se tratan
todos de la misma manera.

Facilita la creación de jerarquías de objetos donde cada objeto se puede tratar de forma independiente o como
un conjunto de objetos anidados a través de la misma interfaz.
Este patrón puede ser utilizado cuando Se necesitan representaciones jerárquicas de objetos.



AGOSTO 2013


Adapter o Wrapper (Adaptador o Envoltorio): Convierte la interfaz de una clase en otra interfaz que el cliente
espera. Adapter permite a las clases trabajar juntas, lo que de otra manera no podría hacerlo debido a sus
interfaces incompatibles. Se utiliza para transformar una interfaz en otra, de tal modo que una clase que no
pudiera utilizar la primera, haga uso de ella a través de la segunda.

Aplicabilidad del Patron Adapter:
 Se desea usar una clase existente, y su interfaz no se iguala con la necesitada.
 Cuando se desea crear una clase reusable que coopera con clases no relacionadas, es decir, las clases no tienen
necesariamente interfaces compatibles.



AGOSTO 2013


Bridge (Puente): El patrón Bridge, también conocido como Handle/Body, es una técnica usada en programación
para desacoplar una abstracción de su implementación, de manera que ambas puedan ser modificadas
independientemente sin necesidad de alterar por ello la otra.

Decorator (Decorador): Añade dinámicamente funcionalidad a un objeto. Permite no tener que crear subclases
incorporando la nueva funcionalidad, sino otras que la implementan y se asocian a la primera.
Este patrón puede ser utilizado cuando:



AGOSTO 2013


• El comportamiento de objetos debe ser dinámicamente modificable.
• Las funcionalidades específicas no deben residir en la parte alta de la jerarquía de objetos.
Aplicabilidad
 Añadir objetos individuales de forma dinámica y transparente
 Responsabilidades de un objeto pueden ser retiradas
 Existe la necesidad de extender dinámicamente la funcionalidad de un objeto y quizás quitar la funcionalidad
extendida.



AGOSTO 2013


Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un
subsistema. Es un patrón de diseño de software comúnmente usado con la programación orientada a objetos.
Una fachada puede:
Hacer una biblioteca de software fácil de usar, entender y probar, ya que la fachada tiene métodos convenientes
para tareas comunes; hacer que la biblioteca más legible, por la misma razón; reducir la dependencia de código
fuera en el funcionamiento interno de una biblioteca, ya que la mayoría de código utiliza la fachada, lo que
permite una mayor flexibilidad en el desarrollo del sistema.



AGOSTO 2013


Flyweight (Peso ligero): sirve para eliminar o reducir la redundancia cuando tenemos gran cantidad de objetos
que contienen información idéntica, además de lograr un equilibrio entre flexibilidad y rendimiento (uso de
recursos). Reduce en gran cantidad el peso de los datos en un servidor.
Ejemplo:
Necesitamos representar gráficamente muchas pelotas idénticas que rebotan en los bordes de una ventana, así
que creamos una clase que tenga por atributos el radio y el color con que se dibujará la pelota y otra para las
coordenadas.
Aunque las coordenadas son distintas, las pelotas son iguales: el radio y el color se repetirán en cada instancia,
desperdiciando memoria.
Crear una clase que contendrá la información común (radio y color) y otra clase que contendrá las coordenadas
concretas de cada pelota. En el caso que tuviéramos varios grupos de pelotas, y dentro de cada uno de los cuales
se compartieran el radio y el color, se puede utilizar Flyweight, de tal modo que en el momento en que se le
soliciten instancias de la clase atributos de la pelota se encuentre el solicitado (radio y color que el solicitado),
compruebe si ya existe un PelotaFlyweight con ese radio y color, y devuelva esa referencia o, en caso de que no
exista, la cree y la registre.



AGOSTO 2013


Proxy: El patrón Proxy es un patrón estructural que tiene como propósito proporcionar un intermediario de un
objeto para controlar su acceso.
Se requiere que la apertura de un documento sea rápida, mientras que la creación de algunos objetos (imágenes
de gran tamaño) es lenta. En este caso no es necesario crear todos los objetos con imágenes nada más abrir el
documento porque no todos los objetos son visibles. Interesa por tanto retrasar el coste de crear e inicializar un
objeto hasta que es realmente necesario (por ejemplo, no abrir las imágenes de un documento hasta que no son
visibles). La solución que se plantea para ello es la de cargar las imágenes bajo demanda. La respuesta es utilizar
un objeto proxy. Dicho objeto se comporta como una imagen normal y es el responsable de cargar la imagen bajo
demanda.



AGOSTO 2013


PATRONES DE COMPORTAMIENTO

Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes
para que los objetos realicen la tarea indicada. El patrón de diseño Chain of Responsibility es un patrón de
comportamiento que evita acoplar el emisor de una petición a su receptor dando a más de un objeto la
posibilidad de responder a una petición. Para ello, se encadenan los receptores y pasa la petición a través de la
cadena hasta que es procesada por algún objeto.
El patrón Cadena de Responsabilidad debe usarse cuando:
 Hay más de un objeto que puede manejar una petición.
 Se quiere enviar una petición a un objeto entre varios sin
especificar explícitamente el receptor.
 El conjunto de objetos que pueden tratar una petición
debería ser especificado dinámicamente.



AGOSTO 2013


Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de
conocer el contenido de la misma.
 Facilita la parametrización (valores conocidos y aceptados por todos) de las acciones a realizar.
 Independiza el momento de petición del de ejecución.
 Implementa CallBacks, especificando que órdenes queremos que se ejecuten en ciertas situaciones de otras
órdenes. Es decir, un parámetro de una orden puede ser otra orden a ejecutar.
 Soportar el "deshacer".
 Desarrollar sistemas utilizando órdenes de alto nivel que se construyen con operaciones sencillas (primitivas).
 Se independiza la parte de la aplicación que invoca las órdenes de la implementación de los mismos.
 Al tratarse las órdenes como objetos, se puede realizar herencia de las mismas, composiciones de órdenes
(mediante el patrón Composite).
 Se facilita la ampliación del conjunto de órdenes

Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas
necesarias para interpretarlo. Se usa para definir un lenguaje para representar expresiones regulares que



AGOSTO 2013


representen cadenas a buscar dentro de otras cadenas. Además, en general, para definir un lenguaje que permita
representar las distintas instancias de una familia de problemas.

Iterator (Iterador): El patrón de diseño Iterador, define una interfaz que declara los métodos necesarios para
acceder secuencialmente a un grupo de objetos de una colección. Este patrón de diseño permite recorrer una
estructura de datos sin que sea necesario conocer la estructura interna de la misma.
El patrón surge del deseo de acceder a los elementos de un contenedor de objetos (por ejemplo, una lista) sin
exponer su representación interna. Además, es posible que se necesite más de una forma de recorrer la
estructura siendo para ello necesario crear modificaciones en la clase.
La solución que propone el patrón es añadir métodos que permitan recorrer la estructura sin referenciar
explícitamente su representación. La responsabilidad del recorrido se traslada a un objeto iterador.



AGOSTO 2013


Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que
funcionan como un conjunto.

Memento (Recuerdo): es un patrón de diseño, cuya finalidad es almacenar el estado de un objeto (o del sistema
completo) en un momento dado de manera que se pueda restaurar en ese punto de manera sencilla. Para ello se
mantiene almacenado el estado del objeto para un instante de tiempo en una clase independiente de aquella a la



AGOSTO 2013


que pertenece el objeto (pero sin romper la encapsulación), de forma que ese recuerdo permita que el objeto sea
modificado y pueda volver a su estado anterior.
Se usa este patrón cuando se quiere poder restaurar el sistema desde estados pasados y por otra parte, es usado
cuando se desea facilitar el hacer y deshacer de determinadas operaciones, para lo que habrá que guardar los
estados anteriores de los objetos sobre los que se opere (o bien recordar los cambios de forma incremental).
Ejemplos: Base de datos ejército (Rango)
Editores gráficos

Observer (Observador): Definir una dependencia uno-a-muchos entre objetos, de tal forma que cuando el objeto
cambie de estado, todos sus objetos dependientes sean notificados automáticamente. Se trata de desacoplar la
clase de los objetos clientes del objeto, aumentando la modularidad del lenguaje, creando las mínimas
dependencias y evitando bucles de actualización (espera activa o polling). En definitiva, normalmente, usaremos



AGOSTO 2013


el patrón Observador cuando un elemento “quiere” estar pendiente de otro, sin tener que estar encuestando de
forma permanente si éste ha cambiado o no.

State (Estado): El patrón de diseño State se utiliza cuando el comportamiento de un objeto cambia dependiendo
del estado del mismo. En determinadas ocasiones, cuando el contexto en el que se está desarrollando requiere
que un objeto tenga diferentes comportamientos según el estado en que se encuentra, resulta complicado poder
manejar el cambio de comportamientos y los estados de dicho objeto, todos dentro del mismo bloque de código.
El patrón State propone una solución a esta complicación, creando básicamente, un objeto por cada estado
posible del objeto que lo llama.



AGOSTO 2013


Por ejemplo: una alarma puede tener diferentes estados, como desactivada, activada, en configuración.
Definimos una interfaz Estado_Alarma, y luego definimos los diferentes estados.
Permite a un objeto alterar su comportamiento según el estado interno en que se encuentre. Altera el original.

Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en
tiempo de ejecución. El patrón Estrategia (Strategy) es un patrón de diseño para el desarrollo de software. Se
clasifica como patrón de comportamiento porque determina como se debe realizar el intercambio de mensajes
entre diferentes objetos para resolver una tarea. El patrón estrategia permite mantener un conjunto de



AGOSTO 2013


algoritmos de entre los cuales el objeto cliente puede elegir aquel que le conviene e intercambiarlo
dinámicamente

según

sus necesidades.

Ejemplo: Software de Oficinas de Tours-agencias de viajes

Template Method (Método plantilla): Este patrón define el funcionamiento general de un algoritmo en una
operación de una clase, delegando en otras clases, a través de herencia o dependencia entre clases, la



AGOSTO 2013


implementación específica de cada uno de sus pasos. Permite que estas clases redefinan ciertos pasos del
algoritmo sin cambiar su comportamiento general, adaptándose cada una de ellas a una necesidad específica.

De acuerdo con esto, podemos considerar una superclase Automóvil en la cual se define un método plantilla
Desplazar desde el cual se llama a la operación primitiva CambiarMarcha que es implementada de una forma en
la subclase "AutomovilManual", y de otra forma en la subclase "AutomovilAutomatico".
Permite que ciertos pasos de un algoritmo definido en una operación de una superclase, sean redefinidos en las
subclases sin necesidad de tener que sobrescribir la operación entera.



AGOSTO 2013


Cuando contamos con un algoritmo con varios pasos que no cambian, de modo que dichos pasos invariantes
serían implementados en una superclase, dejando la implementación de los pasos que cambian para las
subclases.
Para evitar la replicación de código mediante generalización: se factoriza el comportamiento común de varias
subclases en una única superclase.



AGOSTO 2013


En él se muestra una clase plantilla JuegoTemplate con un método jugar() que define el comportamiento general
de cualquier juego. Igual que antes, el juego comienza y cada uno de los jugadores va haciendo su jugada hasta
que se cumple una condición que da fin al juego y se muestra el resultado. Estas operaciones son llevadas a cabo
por una instancia de una clase que implementa la interfaz Juego, interfaz que especifica los métodosque deben
ser implementados por cada juego específico. Las clases Parchis y Ajedrez implementan la interfaz Juego y definen
el comportamiento específico de estos juegos.

Visitor (Visitante): Permite aplicar una o más operaciones a un conjunto de objetos en tiempo de ejecución,
desacoplando dichas operaciones de la estructura del objeto. Este patrón puede ser utilizado cuando la estructura
del objeto no se puede cambiar, pero sí las operaciones que realiza y se utiliza ampliamente en intérpretes,
compiladores y procesadores de lenguajes, en general.
El patrón visitor es una forma de separar el algoritmo de la estructura de un objeto.



AGOSTO 2013


FRAMEWORKS

Es un esquema (un esqueleto, un patrón) para el desarrollo y/o la implementación de una aplicación. Se refiere a
“ambiente de trabajo, y ejecución”. Los framework son soluciones completas que contemplan herramientas de
apoyo a la construcción (ambiente de trabajo o desarrollo) y motores de ejecución (ambiente de ejecución).
Por ejemplo en PHP, supongamos que deseas validar la casilla de mail ingresada por el usuario. Hay que revisar
que tenga el símbolo arroba (@) y que después del arroba tenga un dominio válido. Si se realiza con un
framework, por ejemplo CodeIgniter, simplemente utilizas una función la validación "mail_valid" que viene en la
librería "form_validation" nativa del Framework y ya te aseguras que la dirección de mail ingresada es válida, o
no... Un framework te ayuda a no reinventa r la rueda, en vez de tener que crear una función que valide si un
string es en email valido el framework CodeIgniter y ya te proporciona la solución.
En ese orden de ideas, un framework, es un conjunto de herramientas que facilitan el trabajo diario gracias a la
reutilización de código, y el uso de técnicas de trabajo que se basan en "standards". Ofrecen una jerarquía de
directorios, unas librerías de código básico y reutilizable: (validación de formularios, trabajar con las base de
datos, etc.), es decir, el código que cualquier proyecto puede necesitar y que por lo tanto, no tiene sentido



AGOSTO 2013


reprogramar, si no crear un código que funcione, y que todos lo usen, para mejorarlo y trabajar todos sobre lo
mismo, para que de esta manera cualquiera lo reutilice en un futuro.
Estos frameworks ahorran mucho trabajo... La creación de clases automáticas, mapeo de tu base de datos, etc
depende un poco de cada framework.
Ejemplo
Framework foreach en PHP
Un arreglo realiza la siguiente búsqueda o recorrido: Primero compara si el array está lleno o vacío, entonces hay
otras sentencias antes. Este es el ciclo del recorrido con la impresión de los registros.
Si Frente ≤ Final, entonces:
Apuntador <-- Frente
Repetir mientras Apuntador ≤ Final
Imprimir Array [Apuntador]
Apuntador <-- Apuntador + 1



AGOSTO 2013


Fin del ciclo
El constructor foreach proporciona un modo sencillo de iterar sobre arrays. Foreach funciona sólo sobre arrays y
objetos, y emitirá un error al intentar usarlo con una variable de un tipo diferente de datos o una variable no
inicializada. Existen dos sintaxis:
foreach (expresión_array as $valor)
Cuando foreach inicia su ejecución, el puntero interno del array se pone automáticamente en el primer elemento
del array. Recorre el array dado por expresión_array. En cada iteración, el valor del elemento actual se asigna a
$valor y se muestra y el puntero interno del array avanza una.
El término framework tiene una acepción más amplia, en donde además de incluir una biblioteca de componentes
reutilizables, es toda una tecnología o modelo de programación que contiene máquinas virtuales, compiladores,
bibliotecas de administración de recursos en tiempo de ejecución y especificaciones de lenguajes.

VENTAJAS DE LA UTILIZACIÓN DE UN FRAMEWORK:



AGOSTO 2013


1. El desarrollo rápido de aplicaciones. Los componentes incluidos en un framework constituyen una capa que
libera al programador de la escritura de código de bajo nivel.
2. La reutilización de componentes software al por mayor. Los frameworks son los paradigmas de la reutilización.
3. El uso y la programación de componentes que siguen una política de diseño uniforme. Un framework
orientado a objetos logra que los componentes sean clases que pertenezcan a una gran jerarquía de clases, lo
que resulta en bibliotecas más fáciles de aprender a usar.
4. Otra ventaja de los frameworks, y en especial de esta acepción amplia, es la portabilidad de aplicaciones de una
arquitectura a otra.
5. Desde el punto de vista del desarrollo de software, un framework es una estructura de soporte definida, en la
cual otro proyecto de software puede ser organizado y desarrollado.
6. El programador no necesita plantearse una estructura global de la aplicación, sino que el framework le
proporciona un esqueleto que hay que "rellenar".
7. Facilita la colaboración. Cualquiera que haya tenido que "pelearse" con el código fuente de otro programador
(¡o incluso con el propio, pasado algún tiempo!) sabrá lo difícil que es entenderlo y modificarlo; por tanto, todo
lo que sea definir y estandarizar va a ahorrar tiempo y trabajo a los desarrollos colaborativos.
8. Es más fácil encontrar herramientas (utilidades, librerías) adaptadas al framework concreto para facilitar el
desarrollo.



AGOSTO 2013


LAS DESVENTAJAS DE LOS FRAMEWORKS SON:
1. La dependencia del código fuente de una aplicación con respecto al framework. Si se desea cambiar de
framework, la mayor parte del código debe reescribirse.
2. La demanda de grandes cantidades de recursos computacionales debido a que la característica de reutilización
de los frameworks tiende a generalizar la funcionalidad de los componentes. El resultado es que se incluyen
características que están "de más", provocando una sobrecarga de recursos que se hace más grande en cuanto
más amplio es el campo de reutilización.

Los frameworks suelen incluir:
• Soporte de programas.
• Bibliotecas.
• Lenguaje de scripting.
• Software para desarrollar y unir diferentes componentes de un proyecto de desarrollo de programas.



AGOSTO 2013


Los frameworks permiten:
• Facilitar el desarrollo de software.
• Evitar los detalles de bajo nivel, permitiendo concentrar más esfuerzo y tiempo en identificar los
requerimientos de software.

TIPOS DE FRAMEWORKS
Una de las formas en que se puede clasificar a los frameworks es según la forma en que se pueden desarrollar
aplicaciones a partir de él. Existen tres tipos de frameworks:


Frameworks de Caja Blanca: El framework es posible a través de la creación de nuevas clases. Estas clases y el
código correspondiente se pueden introducir por herencia o composición. Se agregan nuevas funcionalidades
creando una subclase de una clase que ya existe en el framework. Para usar frameworks de caja blanca el
desarrollador de aplicaciones debe conocer muy bien cómo funciona el framework.



Frameworks de Caja Negra: Producen instancias usando scripts de configuración del framework, con los cuales
se configura la aplicación final. Tienen la ventaja que no se requiere que el desarrollador de aplicaciones
conozca los detalles internos del framework, por lo cual son mucho más fáciles de usar.



AGOSTO 2013




Frameworks de Caja Gris: La mayoría de los frameworks son de Caja Gris, que son aquellos que contienen
elementos de Caja Blanca y Caja Negra, que algunas partes se implementan vía herencia o composición, y otras
a través de configuración de parámetros.

PROPIEDADES DESEABLES DE UN FRAMEWORK
Los frameworks son hechos para ser usados en aplicaciones específicas, por lo cual lo más importante que debe
cumplirse es la reusabilidad, que significa que las ideas, el diseño y el código son desarrollados una vez, y luego
usados para resolver muchos problemas, consiguiendo así productividad, confiabilidad y calidad. Un buen
framework debe tener ciertas propiedades que lo hacen más reusable.


Fácil de Usar: Se refiere a la capacidad que tiene el desarrollador de aplicaciones para usar el framework, el
cual debe ser comprensible y debe facilitar el desarrollo de aplicaciones. Los frameworks son para ser reusados,
pero aún uno muy bien diseñado, puede no ser usado si es difícil de entender. Para ayudar a la comprensión, el
framework debe ser documentado con la descripción de los hotspots( ejemplos de aplicaciones y ejemplos, que
el desarrollador pueda usar).



Extensibilidad: Si nuevos componentes o propiedades pueden ser agregados a un framework fácilmente, se
dice que este es extensible. Un aunque sea fácil de usar, debe ser extensible. Un framework puede contar con



AGOSTO 2013


una lista definida y acotada de características, y puede ser muy fácil de comprender y usar, pero su reusabilidad
es mayor si es fácilmente extensible para incluir nuevas operaciones.


Flexibilidad: Es la capacidad de usar el framework en más de un contexto. Esto se refiere a la cobertura de
dominio del framework. Los frameworks que pueden ser usados en múltiples dominios, como por ejemplo un
framework de interfaz de usuario, son especialmente flexibles. Si un framework es aplicable a un dominio
amplio, o a varios dominios, entonces este será reusado por más desarrolladores. Sin embargo, la flexibilidad
debe ser balanceada con la facilidad de uso.



Completitud: La completitud se refiere a que el framework cubra todas los posibles problemas/aplicaciones del
dominio especificado. Aunque los frameworks generalmente sean incompletos, ya que no cubren todas las
posibles variaciones de un dominio, cierta completitud es una propiedad deseable. Actualmente no existen
mecanismos que permitan saber el grado de completitud de un framework.



Consistencia: Debe haber convenciones respecto a los conceptos y definiciones que se usan a lo largo del
framework. Se debe usar nombres consistentemente en todo el framework, para facilitar la comprensión de los
desarrolladores y ayudarlos a reducir errores en su uso.

Tipos de Usuarios



AGOSTO 2013


Se pueden identificar tres roles distintos en el desarrollo y uso de frameworks:
• Diseñadores de Framework: Desarrollan el framework original
• Usuarios del Framework: También llamados desarrolladores de aplicaciones, usan (reúsan) el framework para
desarrollar aplicaciones para problemas específicos del dominio.
• Mantenedores del Framework: Refinan y redesarrollan el framework para cumplir con nuevos requerimientos
que hayan surgido.



AGOSTO 2013

ingenieriadesoftware1

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à ingenieriadesoftware1

Similaire à ingenieriadesoftware1 (20)

Dernier

Dernier (20)

ingenieriadesoftware1