WORKFLOW DE ANALISIS

1- Construya un cuadro comparativo que describa las características del modelo de análisis y el modelo
de requerimientos.
MODELO DE REQUERIMIENTOS
• Describe la funcionalidad del
sistema como un conjunto de
casos de uso. Incluye también la
descripción de la arquitectura.
• Descripto como un conjunto de
casos de uso.
• Puede contener inconsistencias y
redundancias.
• Posee un conjunto de casos de
uso que serán descriptos con mas
profundidad en el modelo de
análisis.
• Esta desarrollado en lenguaje del
cliente
• Describe la vista externa del
sistema.
• Utilizado como contrato entre el
cliente y el desarrollador sobre lo
que debe hacer y no el sistema.
MODELO DE ANÁLISIS
• Esboza la funcionalidad del
sistema a través de un conjunto
de clases de análisis y de objetos
de análisis. Incluye la descripción
de la arquitectura. Sirve como una
primera aproximación al diseño.
• Descripto por clases de análisis,
objetos de análisis y paquetes
estereotipados.
• No debe contener redundancias ni
inconsistencias.
• Posee realizaciones de casos de
uso que describen cada uno de los
casos de uso del modelo de
requerimientos.
• Esta desarrollado en lenguaje del
programador.
• Describe la vista interna del
sistema.
• Utilizado como una primera
aproximación al diseño.

2- Explique porque es necesario considerar al análisis como una etapa diferente a la captura de
requisitos en el diseño o de la implementación.
El análisis es necesario considerarlo como una etapa diferente ya que a través de el podemos obtener
una visión mas general de lo que el sistema realiza, tenemos una idea mas clara de los requerimientos
principales que se deben cumplir y además les sirve a los desarrolladores para concentrarse en lo mas
importante que tiene el sistema y no tanto en los detalles. Ya que en la elaboración del sistema
primero se deben considerar que se cumplan las funcionalidades principales y luego darles lugar a los
detalles. En el análisis se refinan los requerimientos capturados en el modelo de requerimientos, se
capturan las clases mas relevantes para el dominio y se ilustra como los objetos interactúan dentro de
cada caso de uso identificado en el modelo de requerimientos. Además, el modelo de análisis es la
entrada principal al modelo de diseño que luego se encargara de estructurar los requerimientos no
funcionales e irse quedando con lo mas relevante para el sistema.
3- Explique en que casos el PUD recomienda la realización del modelo de análisis y que rol tiene el
análisis en el contexto del ciclo de vida del proceso unificado de desarrollo como proceso iterativo e
incremental.
El análisis se centra en la etapa de elaboración del ciclo de vida del software, en donde se comienza a
analizar lo necesario para luego pasar a la construcción y transición del sistema. En esta etapa se
analiza la arquitectura necesaria, los requerimientos que se deben cumplir, en que lenguaje se va a
desarrollar, etcétera. El PUD recomienda el análisis cuando se requiera que los desarrolladores tengan
una visión mas general del sistema, ya que llegado el momento vienen desarrolladores nuevos les
 permitirá entender el sistema de forma más general y rápida sin tener que centrarse en los detalles;
también, ya que, en algunos casos, los sistemas pueden obtener distintas alternativas de diseño o
implementación, con el análisis se ilustra una visión general de todas esas alternativas de una forma
mas organizada.
4- Dadas las características del PUD: conducido por casos de uso, centrado en la arquitectura e iterativo
e incremental. Explique como se aplican en el workflow de análisis.
La etapa del análisis se encuentra luego del workflow de requerimientos, en donde se ingresa un
modelo de casos de uso describiendo las funcionalidades principales del sistema, haciendo alusión a
que el sistema debe estar conducido por casos de uso, durante el análisis se refinan los requerimientos
y se realizan los casos de uso en términos de la interacción entre sus objetos y clases de análisis. Con
esto se va incrementando el desarrollo del software a través de una serie de pasos iterativos. Por otro
lado la estructura modelada durante la etapa del análisis sirve como una primera entrada al modelo de
diseño, en donde se establecerán los artefactos significativos para la arquitectura y se tomaran las
decisiones para comenzar a diseñarla basándose en la entrada proveniente del workflow de análisis.
5- Explique cuales son los artefactos del workflow de análisis y describa los diagramas de UML 2.0 que
se utilizan para describirlos.
1- MODELO DE ANALISIS: nos permite refinar los requerimientos capturados en el modelo de
requerimientos. Nos proporciona una estructura que nos permite ver la parte interna del sistema, esta
estructura esta centrada en el mantenimiento y es la que se mantiene, o se trata de mantener, durante
todo el ciclo de vida del software. El arquitecto es el encargado de realizar este modelo como una
primera etapa del flujo de trabajo del análisis, garantizando que este sea correcto, comprensible y
legible como un todo. Con correcto se hace referencia a que proporcione la funcionalidad que se
espera de el y solo esa funcionalidad. Los diagramas de UML utilizados para el modelo de análisis son
diagramas de clases, diagramas de secuencia/comunicación, diagramas de paquetes.
2- CLASE DE ANALISIS: son abstracciones de clases y/o subsistemas del diseño del sistema. Poseen
atributos y métodos de alto nivel. Se centran en los requerimientos no funcionales. Las clases de
análisis son provenientes de las clases de dominio mas relevantes y siempre poseen una clasificación,
pueden ser de interfaz, entidad o control. Las clases de interfaz nos sirven de intermediario entre los
actores y las clases de control, ya que ellas no pueden comunicarse directamente, generalmente
proporcionan pantallas, interfaces y se encargan también de visualizar todo lo necesario dentro de
cada caso de uso. Las clases de control son aquellas que realizan las funcionalidades y principios
generales del sistema, interactúan con el resto de las clases consiguiendo lo que se pide, son aptas
para la realización de cálculos, búsquedas, emisiones, etcétera. Las clases de entidad son aquellas
clases provenientes generalmente del dominio del problema que poseen la capacidad de ser
persistentes, la única diferencia que presentan frente a las clases de dominio es que trabajan con
objetos del análisis que interactúan en ellas. Las clases de análisis se describen en los diagramas de
clases de UML.
3- PAQUETE DE ANALISIS: nos sirven para agrupar los artefactos en piezas mas manejables. Un paquete
de análisis debe ser lo mas independiente como sea posible, además se debe garantizar que cumpla
con los requerimientos para los que se diseñó. Estos se pueden identificar mediante la separación del
trabajo o a medida que evoluciona el software como una medida de organización. Los paquetes se
describen en un diagrama de paquetes de UML 2.0.
4- REALIZACIONES DE CASOS DE USO: describen a través de una secuencia de interacciones de objetos un
caso de uso concreto definido en el modelo de casos de uso del workflow de requerimientos. Contiene
una descripción textual en una plantilla que describe los pasos que va siguiendo el caso de uso para
 ejecutarse, un diagrama de clases de análisis que describe las clases de análisis participantes y un
diagrama de interacción que puede ser un diagrama de secuencia o uno de comunicación que describe
la interacción de los objetos del análisis con las clases y los mensajes que estos se envían.
5- DESCRIPCION DE LA ARQUITECTURA: la arquitectura contiene una vista de la arquitectura del análisis
que muestra los artefactos significativos para ella. Estos son, la descripción del modelo de análisis en
paquetes, la identificación de las clases y los objetos participantes, y las realizaciones de casos de uso.
UML 2.0
1- ¿Cuáles son los diagramas de UML 2.0 que modelan objetos (instancias de clases)? Describa cada uno
de ellos y mencione en que workflow del proceso unificado se los puede utilizar.
• Diagrama de objetos: modelan un conjunto de objetos instanciados junto con las relaciones que
y los mensajes que ellos intercambian. Este diagrama se utiliza en el workflow de
requerimientos.
• Diagrama de secuencia: muestra a través de una secuencia de pasos ordenados la interacción
de objetos para cumplir una correspondiente realización de un caso de uso concreto. Este
diagrama hace alusión al tiempo en el que se envían los mensajes. Se utiliza en el workflow de
diseño y en el de análisis.
• Diagrama de comunicación: muestra a través de un hilo de mensajes ordenados la interacción
de objetos para cumplir también un correspondiente caso de uso concreto. La diferencia que
tiene este con el diagrama de secuencia es que este se enfoca en el orden de los mensajes y no
en el tiempo. También es utilizado en el workflow de análisis.
2- ¿Qué modelan los diagramas de interacción? Describa cada uno de ellos.
Los diagramas de interacción modelan la parte dinámica del sistema. Describen como interactúan los
objetos y los mensajes que se intercambian entre ellos. Ellos son:

• Diagrama de secuencia: muestra un conjunto de objetos intercambiando mensajes, un conjunto

de clases de análisis participantes y un actor que interactúa con ellos. Este tipo de diagrama se
centra en la ordenación en el tiempo de los mensajes. Cada objeto posee una línea de vida que
describe la duración en el tiempo que tiene el objeto y de la cual salen los mensajes que este
envía. Además, posee un foco de control que describe cuanto tiempo dura en ejecutarse el
mensaje que este ha enviado.
• Diagrama de comunicación: muestra un conjunto de objetos intercambiando mensajes, al igual
que el diagrama de secuencia, con la diferencia de que este se centra en la ordenación de los
mensajes. Cada uno de los mensajes posee un numero según su orden de envió y en el
diagrama se representa un camino entre los objetos que muestra como se comunican las
clases.
• Diagrama de actividad: ilustra un conjunto de actividades que realiza un objeto durante un
cierto periodo de tiempo para cumplir una funcionalidad especifica.
• Diagrama de casos de uso: se ilustra como un conjunto de casos de uso con un objetivo bien
definido junto con los actores que realizan cada uno de ellos. Además, se especifican las
relaciones y los casos de uso que son extensiones de otros.
• Diagramas de estados: ilustran a través de una maquina de estados, todas las posibles
transiciones de estado por la que puede pasar una determinada clase junto con los casos de uso
que ejecutan dichas transiciones.
 3- Explique los conceptos y diferencias entre MODELO, VISTA Y DIAGRAMA. Ejemplifique
MODELO: es la representación simplificada de un sistema, elaborada para predecir, controlar y comprender el
funcionamiento del sistema. Por ejemplo, un modelo de requerimientos, que describe cada uno de los
requerimientos solicitados por los clientes, junto con las clases participantes. Cabe aclarar que cada uno de los
modelos contiene diagramas de UML para poder representar el sistema desde diferentes perspectivas.
DIAGRAMA: es la representación de una perspectiva del sistema que se ilustra la mayoría de las veces como
un grafo conexo de nodos y arcos. Nos permite visualizar partes del sistema e ilustrar como estas funcionan,
cada uno de los elementos que componen los diagramas tienen elementos con un significado particular y
están definidos de acuerdo a reglas de modelado. Un ejemplo de diagrama es un diagrama de clases. En el
cual se ilustran las clases participantes con sus atributos, métodos y relaciones.
VISTA: es la representación del sistema desde diferentes perspectivas, ilustran los artefactos que tienen más
significación para la arquitectura de este. Las vistas son 5 y se ilustran a través de diagramas. Un ejemplo de
vista es la vista de funcionalidad que ilustra un diagrama de casos de uso para su parte estática y un diagrama
de secuencia o comunicación para su parte dinámica e intenta describir una primera aproximación de la
arquitectura de este, sirve para realizar pruebas de arquitectura y además cada uno de los casos de uso que
están dentro de la vista representan la abstracción de una funcionalidad importante para la arquitectura.

4- Mencione y describa los diagramas de UML 2.0 que se clasifican como diagramas de estructura.
Los diagramas de estructura tienen que ver con la representación de las partes estáticas del sistema. Ellos
son:

• Diagramas de clases: se ilustran como un conjunto de clases que poseen atributos, métodos y
relaciones.
• Diagramas de componentes: ilustran un conjunto de componentes que son piezas de codigo
preelaborado que encapsulan los comportamientos a través de las interfaces. Las relaciones
existentes entre los componentes y los subsistemas a los que estos pertenecen.
• Diagramas de objetos: ilustran un conjunto de objetos relacionados y los mensajes que estos
intercambian.
• Diagramas de paquetes: ilustran un conjunto de paquetes relacionados entre ellos. Cada uno de
los paquetes con los objetos y clases relacionados.
• Diagrama de despliegue: muestra un conjunto de nodos relacionados y artefactos que residen
en ellos.
• Diagramas de artefactos: muestran los componentes físicos del computador, los componentes
de hardware, bases de datos, etcétera.
5- Explique como esta compuesto el modelo conceptual de UML 2.0 y describa en términos generales
los elementos que lo componen.
El modelo conceptual de UML este compuesto por elementos, relaciones y diagramas. Cada uno de ellos
cuentan con una serie de reglas de elaboración que UML tiene y sirven para entender y comprender el
funcionamiento de cada elemento.
Los elementos poseen cuatro tipos:
 • Elementos de comportamiento: son aquellos que ilustran las partes dinámicas del sistema,
como lo son las actividades, maquina de estados.
• Elementos estructurales: son aquellos que ilustran las partes estáticas de los sistemas y son los
que se incluyen dentro de los diagramas para componerlos. Ellos son los casos de uso, las
clases, los objetos, componentes, nodos, etcétera.
• Elementos de anotación: son aquellos para agregar notas o aclaraciones en cada uno de los
diagramas o partes del sistema que se desea aclarar. Uno de los elementos mas utilizados para
esto es la nota.
• Elementos de agrupación: nos permite organizar el sistema en partes más comprensibles por
ellos. Un ejemplo de estos son los paquetes.
PATRONES GRASP

1- ¿Cuál es la utilidad de los patrones GRASP? Explique su propósito y realice un ejemplo propio en el
que explique el patrón controlador y un ejemplo que no lo use.
Los patrones, antes que nada, se pueden definir como una descripción detallada de un problema general, que
se repite en varias ocasiones dentro de un mismo con, junto con la solución a este problema. En el caso de los
patrones GRASP sirven para aplicar y describir principios de diseño y asignarles responsabilidades a los
objetos. En otras palabras, sirven para reutilizar clases.
El patrón CONTROLADOR sirve como intermediario entre la interfaz y el algoritmo que la implementa.
También es el encargado de asignarle el comportamiento a la clase que posea los datos y los métodos para
realizarlo. Este patrón sugiere que la capa de lógica de negocios tiene que estar separada de la capa de
presentación. Los beneficios que trae son que aumenta el potencial para reutilizar y además nos permite
razonar sobre el estado de los casos de uso.
2- ¿Para qué se aplican los patrones GRASP? Explique en que etapa del flujo de trabajo del análisis se
utilizan.
Los patrones GRASP se aplican para poder aplicar los principios de diseño, asignarles responsabilidades a
los objetos y además reutilizar las clases. Estos patrones se deben tener en cuenta durante todo el
desarrollo del sistema, ya que al aplicar los principios de diseño vamos a lograr un sistema que sea
eficiente, escalable y modificable. Principalmente se tienen en cuenta en las etapas de elaboración y
construcción estos patrones, ya que durante estas etapas se analiza y construye el software en cuestión.
3- Menciona los patrones GRASP, describa su utilidad, desarrolle un ejemplo propio en el que se
aplique un patrón CREADOR Y BAJO ACOPLAMIENTO.
• CREADOR: este patrón tiene como propósito que, si una clase A tiene los elementos para crear
una clase B, entonces A será la encargada de crear a B. Con esto queremos decir que le
debemos asignar la creación de clases a aquellas clases que tengan los datos y métodos
necesarios para hacerlo. Los beneficios que trae aplicar este patrón principalmente es la
reducción del acoplamiento.
• EXPERTO: este patrón establece que los métodos se deben colocar en la clase que posea los
datos para cumplirlos. Es decir, se deben colocar en cada clase los métodos de acuerdo con los
atributos que esta tenga y responsabilidades para poder cumplirlos. Los beneficios que trae
este patrón es que se mantiene el encapsulamiento de la información y se distribuyen
correctamente los comportamientos entre las clases.
 • BAJO ACOPLAMIENTO: el propósito de este patrón es que las clases se mantengan relacionadas
únicamente con aquellas que posean un vinculo directo. En otras palabras, se deben lograr que
las dependencias sean mínimas, ya que en el caso en que se desee configurar una clase o los
elementos de ella, afecte a la menor cantidad de elementos. Los beneficios que trae este
patrón son la facilidad para entender el sistema, aumento de la capacidad para reutilizar y que
los cambios no afectan a los demás elementos del sistema.
• ALTA COHESION: este patrón establece que los elementos dentro de una clase deben estar
relacionados entre ellos, en otras palabras, deben ser cohesivos. Los beneficios que trae la
aplicación de este patrón es que se aumenta el acoplamiento, la reutilización y la facilidad para
entender el diseño.
DISEÑO ARQUITECTONICO

1- Explique 3 patrones arquitectónicos de la vista de ejecución y en qué caso recomienda la aplicación

de cada uno de ellos.
LAYERED
Descripción Este patrón describe al sistema a través de una organización de capas
lógicas. En donde cada capa actúa como una maquina virtual de la capa
que esta por debajo de ella. Cada capa posee una funcionalidad y puede
utilizar las capas que se encuentran adyacentes a ella también.
Aplicación Se utiliza cuando se requiere hacer divisiones dentro del entorno de
trabajo o cuando el sistema tiene requerimientos multinivel.
Ventajas Se puede reemplazar la capa completa siempre y cuando posean las
mismas características.
Desventajas Es muy difícil organizar el sistema en capas bien diferenciadas, en
muchas ocasiones las capas inferiores requieren funcionalidades de las
superiores.
CLIENTE-SERVIDOR
Descripción Consiste en un conjunto de servicios brindados para un conjunto de
clientes. Estos servicios se encuentran en servidores a los que los clientes
acceden a medida que requieren la utilización de los servicios.
Aplicación Se utiliza en sistemas que tienen una base de datos compartidas o
variable.
Ventajas Los servidores se distribuyen a lo largo de una red, lo que en muchas
ocasiones les facilita a los clientes la instalación del sistema. Ya que por
causa de esto pueden acceder a los servidores que necesiten sin tener
que instalar el sistema completo.
Desventajas La red puede contener errores o virus que se propagarían afectando
todos los servidores. En otras palabras, es mucho más difícil tener un
control de los errores que se podrían producir.

PUBLISH-SUSCRIBE
Descripción Un emisor publica un evento y otros se subscriben a ellos. En un tópico
de este patrón puede haber uno o mas publicantes y a los eventos los
pueden recibir uno o mas receptores.
Aplicación Se utiliza en sistemas que permitan las relaciones muchos a uno, uno a
muchos y muchos a muchos.
 Ventajas Desacopla los publicantes de los receptores, lo que produce un bajo
acoplamiento.
Desventajas El bus de eventos genera una capa de indirección que afecta la
performance de sistema.

MESSAGING
Descripción Desacopla emisores de receptores utilizando una cola de mensajes
intermedia. Un emisor envía un mensaje y sabe que eventualmente será
recibido.
Aplicación Es apropiado para aplicaciones donde la conectividad es transitoria. Se
utiliza cuando los clientes envían mensajes y no requieren una respuesta
inmediata de ellos.
Ventajas Bajo acoplamiento.
Desventajas El bus de eventos genera una capa intermedia entre emisores y
receptores que afecta la performance del sistema.

AGENTE
Descripción Los emisores y los receptores se conectan como rayos y el agente actúa
como un concentrador de mensajes. Este patrón conecta los emisores y
los receptores a través de puertos, en donde un mensaje es redirigido al
correspondiente puerto de salida. También realiza conversiones
necesarias de formato desde un puerto a otro.
Aplicación Se utiliza en aplicaciones a donde se requieran conversiones de formato
entre una entrada y una salida.
Ventajas Al mantener el bajo acoplamiento, los emisores pueden conservar su
formato nativo y los receptores también obtendrán los mensajes en un
formato que sea correctamente visible para ellos.

2- Explique que son los requerimientos no funcionales, que dificultades encontramos asociadas a los
requerimientos no funcionales a la hora de diseñar software y como impactan en el modelado de la
arquitectura.
Los requerimientos no funcionales son un conjunto de atributos de calidad y cualidad que tienen un impacto
grande en el modelado de la arquitectura. Y esto se debe a que un problema con un requerimiento no
funcional por falta de cumplimiento nos va a conducir a un problema grande en el sistema, por lo que son tan
críticos como los funcionales. Ayudan a cumplir las necesidades del cliente en cuanto a los detalles que no
tienen atribución al funcionamiento del sistema. Son también llamados requerimientos de calidad. Se ajustan
a tres áreas:

• Restricciones técnicas: son aquellos que tienen relación dentro de las funcionalidades del
sistema, pero respecto a lo técnico de este, como por ejemplo el manejo de servidores o
equipos de hardware requeridos.
• Restricciones de negocio: son aquellos que también están dentro del ambiente empresarial,
pero tienen más que ver con las reglas de negocio que tiene el ambiente a donde se va a
implementar el sistema.
 • Atributos de calidad del sistema: son aquellos deseos que el cliente con respecto al sistema,
que muchas veces no afectan el desarrollo de estos, sino que tiene mas que ver con la
satisfacción de este.
Las desventajas o problemas que tienen los requerimientos no funcionales son que no hay ni buenas, ni malas
soluciones a la hora de tratar con ellos, sino que existen las soluciones óptimas. Otro problema que antes es
mencionado es que evadir los requerimientos funcionales puede traer complicaciones grandes como si se
tratara de los requerimientos funcionales.
3- Enuncie cuales son las etapas del proceso de diseño arquitectónico y describa detalladamente la
etapa de validación, indicando como se lleva a cabo, que herramientas se utilizan, especificando sus
características y cuales se emplean en cada caso.
El proceso de diseño arquitectónico consta de asignar el modelo de diseño a una tecnología especifica.
Identifica los componentes principales del sistema y los introduce dentro de una tecnología para luego
producir como salida un modelo arquitectónico que muestra los componentes arquitectónicos mas
importantes conectados entre sí. Posee tres etapas:

• Proceso de identificación de los requerimientos arquitectónicos y priorización: durante esta

etapa se trata de diseñar un modelo de requerimientos que nos conduzca al diseño
arquitectónico y su priorización. Como primera etapa se toman los requerimientos no
funcionales y de los involucrados y con ellos se forman los requerimientos arquitectónicos.
Luego se producirá un documento como salida. Para terminar se los prioriza de acuerdo con
tres categorías:
- Alta: son aquellos que tienen un alto impacto, que de ellos depende el diseño de la
arquitectura.
- Media: son aquellos que se tienen en cuenta en algunas áreas del sistema.
- Baja: son los deseos de los clientes, que no conducen normalmente al diseño del sistema.
• Proceso de diseño arquitectónico: incluye la definición de una estructura de componentes junto
con las responsabilidades que tendrán cada uno de ellos. En esta etapa primero se elige un
framework que puede constar de uno o más patrones arquitectónicos para definir y empezar a
diseñar la arquitectura, luego se conducirá a distribuir los componentes, teniendo en cuenta
que componentes se van a utilizar, las dependencias entre ellos, la información que van a
manejar, etcétera.
• Validación: en esta etapa se ponen sobre la mesa los requerimientos existentes y los que se
pueden predecir en un futuro. Existen dos maneras de validar que un sistema esta
correctamente diseñado:
- Uso de escenarios: cuenta con una serie de casos de prueba que validaran el sistema en
cada uno de los contextos de los casos de prueba.
- Uso de prototipos: un prototipo es una primera aproximación del sistema funcionando,
ayuda a brindarle al usuario una primera impresión del sistema. Un prototipo sirve para
probar las distintas funcionalidades que tiene un sistema, y en algunos casos se lo introduce
como interfaz final del sistema, en casos que se quiera probar.
4- Explique porque se utilizan las vistas para modelar la arquitectura, que vistas se utilizan y que
diagramas de UML se emplean para modelar cada vista.
El modelo 4+1 de vistas arquitectónicas nos sirve para descubrir la arquitectura de sistemas de software. Las
vistas nos permiten visualizar al sistema desde diferentes puntos de vista, ya sea de los usuarios, arquitectos,
desarrolladores, analistas, etcétera.
Las vistas que conforman el modelo 4+1 son:

• Vista de funcionalidad: se ilustra como un conjunto de casos de uso o escenarios que permiten
visualizar la interacción entre los objetos y procesos del sistema. Esta vista comienza con la
delimitación de los casos de uso principales provenientes del workflow de requerimientos.
Además, sirve para comenzar a delimitar la arquitectura y ser una primera prueba de prototipos
de esta. Para representar su parte estática se utiliza un diagrama de casos de uso y su parte
dinámica en este caso, se puede representar con un diagrama de secuencia o incluso uno de
comunicaciones.
• Vista de diseño: tiene como propósito mostrar clases, subsistemas e interfaces para cumplir con
los casos de uso identificados en la vista de funcionalidad. Esta enfocada en distribuir la
funcionalidad y la estructura del sistema. Su parte estática se la representa con un diagrama de
componentes, mientras que su parte dinámica con un diagrama de secuencia.
• Vista de procesos: se enfoca en el aspecto dinámico de los sistemas, ilustrando los procesos
que esta cuenta y como se comunican entre ellos. Hace hincapié en aspectos como rentabilidad
y concurrencia. Esta vista se utiliza cuando el sistema posee procesos automáticos. La parte
estática se representa mediante un diagrama de actividad y la parte dinámica mediante uno de
secuencia.
• Vista de implementación: nos muestra el sistema desde una perspectiva del programador y esta
enfocado en la administración de los artefactos de software. Utiliza un diagrama de paquetes o
de componentes para visualizar la parte estática y uno de secuencia para su parte dinámica.
• Vista de despliegue: esta relacionada con la topología de los componentes de software que se
encuentran en la capa física, así como las conexiones físicas que hay entre estos componentes.
Ilustra la distribución de los procesos y componentes a través de nodos del sistema. Para la
parte estática se utiliza un diagrama de despliegue y para la parte dinámica uno de secuencia.
5- Mencione y describa en términos generales los patrones para diseñar arquitecturas distribuidas de
software.
1- ARQUITECTURA MAESTRO ESCLAVO: se utiliza en sistemas a donde se requiere importante cumplir con
los tiempos de procesamiento. En estos casos se asigna un proceso maestro que es el encargado de
proporcionar la coordinación, gestión y manejo de cada uno de sus procesos esclavos. Se utiliza
también cuando en los sistemas distribuidos es fácilmente identificar cual es el proceso maestro y
también asignarle a este cada uno de los procesos esclavos.
2- ARQUITECTURA CLIENTE-SERVIDOR: ilustra al sistema como un conjunto de servidores a los que los
clientes acceden para utilizar los servicios que están dentro de ellos. Cada uno de estos servidores se
encuentran distribuidos a través de una red. Los sistemas cliente-servidor requiere que exista una
separación clara entre las capas de presentación, lógica de negocios, y base de datos en el sistema, ya
que esto permita que se distribuyan en diferentes computadoras.
3- ARQUITECTURA CLIENTE-SERVIDOR EN DOS NIVELES: el sistema se implementa en un solo servidor mas
un numero indefinido de clientes que usan dicho servidor. Existen dos modelos dentro de este patrón:
• Modelo cliente liviano: en donde todas las tareas se realizan en el servidor, mientras que el
cliente solo contiene la capa de presentación de este. En este caso, tiene el problema de que el
 servidor se sobrecargue de trabajo y no funcione correctamente. Aunque también posee la
ventaja de que los clientes hacen uso de este con mas facilidad ya que es más fácil de entender.
• Modelo de cliente pesado: en donde todas las tareas son realizadas en la capa del cliente y el
servidor solo realiza lo relacionado a estructuras de bases de datos y gestión de estas. Esto
también trae problemas, en donde los clientes requieren capacitación para saber usarlo y
también personal capacitado que los instale en cada una de sus computadoras. Aunque
también tiene la ventaja de que el servidor no va a sufrir ninguna sobrecarga de información.
4- ARQUITECTURA CLIENTE-SERVIDOR MULTINIVEL: en esta arquitectura las diferentes capas son
procesos separados que pueden ejecutarse en diferentes servidores del sistema. Se considera un
servidor que se encargue de presentación, otro de lógica de negocios y otro para la base de datos. Con
esto se solucionarían los problemas de cliente pesado y liviano.
5- ARQUITECTURA DE COMPONENTES DISTRIBUIDOS: consiste en diseñar un sistema como un conjunto
de servicios, sin tratar de asignar dichos servicios a capas bien estructuradas. En este patrón se ilustra
los componentes y objetos en interacción que proporcionan las interfaces para cumplir con cada uno
de los servicios. Tiene como ventajas que es más fácil la distribución de las funcionalidades e incluso se
pueden agregar recursos. Aunque también son más difíciles de implementar y mas costosos.
6- PEEPER-TO-PEEPER: el patrón entre pares ilustra el sistema como un conjunto de nodos distribuidos a
través de una red. En este caso no existen ni clientes ni servidores, sino que cada nodo puede
comportarse como tal y realizar los cálculos y funciones necesarias a medida que se vayan requiriendo.
7- MAP REDUCE: se utiliza en sistemas a donde se requieren grandes procesamientos de datos como una
red social o motores de búsqueda de internet. Se toman estos conjuntos grandes de datos y se los
almacena en conjuntos mas chicos en ficheros globales. En este patrón solo debe asegurarse que cada
uno de los trabajadores cumpla realmente su función.
8- MIRRORED: en esta arquitectura se duplica el hardware idéntico para que en el caso de que uno falle el
otro pueda continuar por su cuenta aumentando la disponibilidad.
9- RACK: los servidores se acomodan en pilas para no ocupar tanto espacio. Todas las computadoras de la
pila se conectan a la misma red y la red tiene varias conexiones a internet.
10- FARM: muchas computadoras son ubicadas en la misma habitación, dentro de la habitación puede
haber una o mas arquitecturas RACK. Se las piensa como un recurso que puede alojar cualquier
aplicación.

FLUJO DE TRABAJO DE DISEÑO

1. En el contexto del PUD: describa en qué consiste el modelo de diseño, cuáles son los diagramas de
UML que se utilizan para construir los artefactos del modelo y destaque cuáles son las diferencias
con el modelo de análisis.
En el modelo de diseño se trata de diseñar y modelar la estructura que le de forma al sistema. Se aplican
principios y técnicas para realizarla con el suficiente nivel de detalle para que permite su representación
física. El modelo de diseño toma como entrada el modelo de análisis, y trata de mantener esta estructura
durante todo su trabajo. Dentro del PUD el modelo de diseño abarca principalmente la etapa de
elaboración, así como también las primeras iteraciones de la etapa de construcción en lo que abarca la
parte de la arquitectura. Es un proceso de transformar un modelo lógico es un modelo físico teniendo en
cuenta las reglas de negocio. Los artefactos del modelo de diseño son:
• MODELO DE DISEÑO: es el proceso de transformar un modelo lógico en un modelo físico
teniendo en cuenta los requerimientos no funcionales y haciéndolo con el suficiente nivel de
detalle como para que permita su realización física. Describe como los requerimientos
funcionales y no funcionales tienen impacto en el sistema a considerar. Sirve como una primera
 abstracción al modelo de implementación. Los diagramas utilizados son: diagramas de clases de
diseño generalmente, diagramas de componentes, etcétera.
• CLASE DE DISEÑO: son aquellas clases que se especificaron con el suficiente nivel de detalle
como para poderse implementar. Son especificadas mediante un lenguaje de programación,
por lo que poseen una correspondencia directa con el codigo. Tienen atributos, métodos,
relaciones también definidas mediante un lenguaje de programación. Poseen las características
de ser completas y sencillas, es decir, que contienen la funcionalidad para las que fueron
diseñadas y solo esa funcionalidad completa y concisa. Este artefacto se ve plasmado en los
diagramas de clases de diseño.
• SUBSISTEMAS: son una forma de organizar los artefactos del diseño en piezas mas manejables.
Los subsistemas deben contener las menores dependencias posibles, así como estos deben
proporcionar las interfaces correctas según la funcionalidad que tienen a su cargo y deben
contener las operaciones correctas para llevar a cabo dichas interfaces. Existen dos formas de
obtener los subsistemas, una puede ser como una forma de dividir el trabajo y la otra es que a
medida que la evolución del desarrollo del software avance se vean obligado a dividir la
estructura. Los diagramas en los que estos artefactos están presentes son los diagramas de
componentes.
• INTERFACES: estos artefactos especifican las operaciones definidas por las clases y los
subsistemas de diseño. Constituyen una forma de separar la funcionalidad de la operación de
su implementación. Estos artefactos se ven reflejados en los diagramas de componentes.
• REALIZACIONES DE CASO DE USO DE DISEÑO: reflejan el curso de los diferentes casos de uso
realizados en el modelo de análisis. Este artefacto posee como entrada las realizaciones de
casos de uso de análisis y se trata de conservar las estructuras que ellos tienen definida durante
toda la realización de caso de uso que tienen asociada. Dentro de cada realización de caso de
uso hay una descripción textual que muestra el flujo que tiene el caso de uso y su desarrollo, un
diagrama de clases que especifica las clases de diseño participantes con sus atributos, métodos
y relaciones y un diagrama de interacción que muestra la secuencia de interacciones entre los
objetos junto con los mensajes que estos se envían entre ellos.
• DESCRIPCION DE LA ARQUITECTURA: la arquitectura se describe mediante la descripción de la
vista de la arquitectura, en este caso se ve plasmada la vista arquitectónica de diseño que se
trata de mostrar clases, interfaces, subsistemas, etcétera para implementar los casos de uso
plasmados en la vista de casos de uso. Además, trata aspectos tales como concurrencia,
rendimiento y flexibilidad. Dentro de esta vista se ilustra para la parte estática un diagrama de
componentes, y la parte dinámica un diagrama de secuencia.
• MODELO DE DESPLIEGUE: distribuye la funcionalidad del sistema como un conjunto de nodos
en una red. Para este modelo hay que tener en cuenta que nodos, cuantos nodos se necesitan,
las conexiones que van a tener los nodos, etcétera.
• DESCRIPCION DE LA ARQUITECTURA DE DESPLIEGUE: describe mediante la vista de despliegue
que muestra los artefactos importantes para la arquitectura mediante un conjunto de nodos en
una red virtual.
2. ¿cuáles son los trabajadores que intervienen en el workflow de diseño? Describirlos y explique los
artefactos por los que cada uno es responsable.
Los trabajadores que intervienen en el workflow de diseño son:

• ARQUITECTO: es el encargado de diseñar el modelo de diseño y de que este sea correcto,

comprensible y legible como un todo. Con correcto se hace referencia a que proporcione la
funcionalidad por la que fue diseñado y solo esa funcionalidad. Además, el arquitecto es el
encargado de la arquitectura del sistema, de todos los artefactos que son significativos para
 ella. Los artefactos que este tiene a cargo son: el modelo de diseño, modelo de despliegue,
descripción de la arquitectura con las correspondientes vistas arquitectónicas.
• INGENIERO EN CASOS DE USO: es el encargado de realizar cada uno de los casos de uso en
términos de clases de análisis y objetos de análisis, así como también las responsabilidades de
ella y los mensajes intercambiados por los objetos. Es el encargado de mantener la integridad
de las realizaciones de casos de uso (artefacto del workflow de diseño) y de asegurarse de que
estas cumplan los requerimientos que tienen asociados.
• INGENIERO EN COMPONENTES: es el encargado de definir las responsabilidades, atributos,
métodos u operaciones de cada una de las clases de análisis, así como también de las relaciones
y requerimientos que estas tienen asociados. También es el encargado de mantener la
integridad de cada uno de los subsistemas, haciendo que estos sean lo mas independientes
posibles y que además realicen correctamente cada una de las funcionalidades definidas por
sus interfaces. Los artefactos como antes se mencionaron a los que este trabajador hace
alusión son las clases de análisis, los subsistemas e interfaces.

3. ¿cuál es el rol del diseño en el ciclo de vida iterativo e incremental propuesto por el PUD? Compare
el modelo de análisis con el modelo de diseño según lo propuesto en el PUD
El rol del diseño en el ciclo iterativo e incremental propuesto por el PUD se concentra generalmente en la
etapa de la elaboración y en la concesión de la arquitectura en las primeras etapas de la construcción. En la
etapa de elaboración lo que realiza es tratar de cumplir tanto los requerimientos funcionales y no funcionales
sobre la estructura de análisis que recibió como entrada convirtiéndola en un dispositivo con el suficiente nivel
de detalle como para que se pueda programar. En si en el modelo de diseño se tratan de aplicar principios y/o
técnicas para construir un dispositivo que sea lo suficientemente completo para que al entrar a la etapa de
implementación se pueda programar. Las diferencias con el modelo de análisis son:

MODELO DE ANALISIS MODELO DE DISEÑO

- Es un modelo lógico.
- Menos formal
- Menos caro de implementar.
- Dinámico (no hace mucha referencia en la
secuencia)
- Modela la solución en términos lógicos.
- Tiene tres estereotipos de clases definidos:
interfaz, entidad y control
- Genérico respecto al diseño.
- Bosquejo del sistema, incluyendo su
arquitectura.
- Puede no estar mantenido durante todo el
ciclo de vida del software.
- Sirve como entrada al workflow de diseño.
- Es un modelo físico.
- Mas formal
- Mas caro de implementar.
- Dinámico (hace hincapié en la secuencia).
- Modela la solución en términos físicos
- Tiene infinitos estereotipos de clases ya que
las mismas dependen de los lenguajes de
programación.
- No es genérico, es una primera aproximación
a la implementación.
- Manifiesto del sistema, incluyendo su
arquitectura.
- Debe estar mantenido durante todo el ciclo
de vida del software.
- Sirve como una primera aproximación a la
implementación.
PRINCIPIOS DE DISEÑO
4. Realice un cuadro comparativo para explicar características, ventajas y desventajas de las relaciones
de generalización, realización y agregación/composición.
HERENCIA COMPOSICION
Es una relación de
especificación/generalización en
donde un objeto especificado se basa
en la especificación de otro objeto
generalizado. En otras palabras, una
clase padre va a compartir sus
métodos y atributos con cada una de
sus clases hijos. Esta relación permite
definir implementaciones en
términos de otra, lo que se conoce
como reutilización de caja blanca, ya
que las estructuras internas de las
clases son visibles.
VENTAJAS:
- Es fácil de implementar.
- Permite cambiar las
implementaciones heredadas
en las clases.
- Aumenta la reutilización.
- Se define en tiempos de
compilación.
DESVENTAJAS:
- Rompe en encapsulamiento.
- Produce un alto
acoplamiento.
- No permite modificar las
implementaciones en tiempo
de ejecución.
REALIZACION
Es una relación todo-parte, en donde
cada parte tiene vida independiente.
Cada parte pertenece al menos a un
todo. La composición requiere que
los objetos tengan interfaces bien
definidas. Esta relación compone o
ensambla los componentes con el fin
de obtener funcionalidades más
complejas, lo que se conoce como
reutilización de caja negra. Ya que se
ocultan los detalles de
implementación.
VENTAJAS:
- Se define en tiempos de
ejecución.
- No rompe el
encapsulamiento.
- Posee un bajo acoplamiento.
DESVENTAJAS:
- La composición por si misma
no es polimórfica.
- Construir un sistema basado
en la composición es mucho
más costoso y difícil de
implementar.
Es una relación entre clasificadores
en donde un objeto clasificador
establece un contrato que garantiza
que otro clasificador lo cumplirá. Se
utiliza entre interfaces y
colaboraciones. Normalmente la
realización se utiliza para representar
la relación entre una interfaz y la
clase que la implementa.
VENTAJAS:
- Es mucho mas flexible y
robusta que la herencia.
- Proporciona un mecanismo
para establecer contratos.
DESVENTAJAS:
- No proporciona reutilización
de codigo.

5. Definir principio de diseño y explicar los principios de diseño básicos.

Un principio de diseño se puede definir como una técnica o herramienta utilizada para construir un sistema
que sea extensible, escalable y fácil de modificar. Los principios básicos de diseño son:
• No te repitas: significa que no se deben repetir clases ni componentes en los sistemas, no debe
haber redundancias, sino que para ello se deben implementar los conceptos de herencias o
polimorfismo.
• Si tu estructura esta basada en objetos, pedirles a ellos que trabajen para vos, en otras
palabras, a los objetos no se le deben pedir datos, sino que se le debe pedir a los objetos que
realicen trabajos para vos.
• Encapsulamiento variado, este principio hace referencia a que se debe mantener el
encapsulamiento fijo del que varía. Lo que implica colocar los métodos y atributos fijos en una
clase y los que varíen en otra. Ya que en el momento de realizar cambios se afectaría a la menor
cantidad de objetos.
6. De una definición aplicable al proceso de diseño y explique detalladamente qué aspectos del
software se diseñan
En el proceso de diseño de un sistema de información se trata de la definición de la arquitectura y de la
estructura tecnológica junto con cada uno de los detalles de los componentes que le darán soporte al sistema.
Los aspectos a tener en cuenta para diseñar son:
 • ARQUITECTURA: conjunto de decisiones que se toman para cumplir con los requerimientos del
producto. Se ilustra a través de vistas arquitectónicas. Define una relación entre los principales
elementos del programa. Toma los requerimientos no funcionales y los aplica dentro del
modelo de diseño.
• BASES DE DATOS: se encarga de traducir los requerimientos del sistema estructuras de bases de
datos. Para esto se cuenta con el problema de impedancia, debido a que los objetos se deben
transformar en tablas del modelo de base de datos para ser almacenados y que persistan en el
tiempo y viceversa en el caso de que se los quiera recuperar.
• PROCESOS: se encarga de transformar los elementos estructurales de la arquitectura del
programa en una descripción procedimental de los componentes del software. Tiene en cuenta
aspectos como la rentabilidad, fiabilidad, concurrencia, etcétera.
• INTERFACES: son las que describen como se comunica el sistema consigo mismo, con los
sistemas relacionados y con los usuarios, en otras palabras, como se relaciona el sistema con el
ambiente.
• ENTRADA/SALIDA: describe las entradas que puede aceptar el sistema junto con las salidas que
emitirá. Existen tres formas de procesar las salidas:
- En lotes: las transacciones se van almacenando en lotes y se procesan todas juntas.
- En línea: a medida que van ocurriendo, las transacciones se van procesando.
- En tiempo real: es una especia de sistema en línea, pero pueden modificar el ambiente a donde esta
inmerso.
• PROCEDIMIENTOS MANUALES: es la adaptación del sistema dentro del entorno del negocio.
7. ¿qué son los principios SOLID? Explique cada uno de ellos.
Los principios SOLID son principios de diseño que nos permiten definir un sistema mantenible y escalable, que
posea un codigo fácil de modificar y que evolucione en el tiempo. Ellos son:
S= PRINCIPIO DE RESPONSABILIDAD UNICA: se trata de que cada clase tiene una única responsabilidad y toda
la información dentro de ella debe hacer referencia a esa funcionalidad. Lo que mantiene el encapsulamiento
dentro de cada una de las clases.
O= PRINCIPIO DE ABIERTO/CERRADO: este principio dice que el codigo debe estar abierto a la extensión, pero
cerrado a la modificación, es decir, el codigo se puede extender todas las veces que se requiera para que el
sistema evolucione, pero nunca permitir que este se modifique en función a sus funcionalidades anteriores.
L=PRINCIPIO DE SUSTITUCION DE LISKOV: este principio hace alusión a la herencia de clases. En una estructura
de herencia bien formada, una clase padre se puede comportar como clase hijo y viceversa según los
comportamientos que se requieran.
I=PRINCIPIO DE SEGREGACION DE INTERFACES: un cliente de una entidad solo debe conocer los métodos de
esa entidad y a los que ella se encuentra relacionada y nada más. Como una forma de mantener el bajo
acoplamiento.
D=PRINCIPIO DE INVERSION DEPENDIENTE: este principio se refiere a que el codigo no debe depender de los
detalles de implementación para hacerlo testeable, escalable y mantenible.
8. Explique los principios de diseños vinculados con el concepto de acoplamiento
El acoplamiento tiene que ver con cuan relacionados están las clases, componentes, etcétera. Dentro de las
claves para diseñar un buen sistema esta la que dice que el acoplamiento debe ser bajo, es decir, las
dependencias existentes entre los diferentes elementos del sistema deben ser mínimas y únicamente las
necesarias. Los principios de diseño relacionados con este concepto son PRINCIPIO DE SUSTITUCION DE
LISKOV y el PRINCIPIO DE SEGREGACION DE INTERFACES.
8. Explique los principios de diseño vinculados con el concepto de cohesión
El concepto de cohesión hace referencia a que los datos y los métodos dentro de una clase deben estar
puramente relacionados así se pueden cumplir correctamente. Los principios vinculados a la cohesión son
dentro de los SOLID, el de PRINCIPIO DE RESPONSABILIDAD UNICA, PRINCIPIO DE ABIERTO/CERRADO. Dentro
de los básicos también podemos destacar el principio de PEDIRLE A LOS OBJETOS QUE TRABAJEN PARA VOS,
NO LES PIDAS DATOS.
ESTRATEGIAS DE PROTOTIPADO Y ENSAMBLADO DE COMPONENTES
1. Describa alguna de las circunstancias donde desaconseje el uso de la estrategia de ensamblado de
componentes.
La estrategia de ensamblado de componentes se desaconseja cuando:
• Cuando se desconoce el codigo fuente y es necesario trabajar con él.
• Cuando se requieren licencias dentro de la aplicación que no se pueden obtener.
• Cuando no existen componentes que cumplan con los requerimientos que se encuentran
especificados.
• Cuando las propiedades emergentes puedan dejar un componente inservible.
2. Describa en qué consiste la estrategia de ensamblado de componentes y de una opinión al respecto
del uso de esta estrategia para el desarrollo del software.
Las estrategias de ensamblado de componentes es una decisión arquitectónica o de modelo que nos
permite identificar los componentes que se van a requerir, las relaciones e incluso hasta la granularidad de
estos. Comienza con la identificación de las clases principales que pueden transformarse luego en
componentes y se las almacena en una biblioteca comparando que dentro de ella no se encuentren y se
produzcan redundancias. Mi opinión con respecto a la estrategia de ensamblado de componentes es que
son efectivas para la reutilización del codigo del software, ya que cada uno de los componentes consisten
en piezas de codigo reutilizable que permiten aumentar la calidad y reducir costos en el desarrollo de los
sistemas de información. Además, posee como ventaja también la simplificación de las pruebas, se
prueban cada uno de los componentes de manera mas sencilla que probar un sistema completo haciendo
con esto un sistema mantenible en el tiempo y escalable. También cabe aclarar que es desaconsejable
cuando no se conoce el codigo interno de los componentes, ya que muchas veces se requieren realizar
cambios que producirían errores y fallos en el mantenimiento de estos a lo largo del tiempo.
3. Explique qué tipos de prototipos pueden construirse durante el desarrollo del software y que
ventajas y desventajas tiene utilizar prototipos.
La estrategia de prototipado consiste en un modelo que se recomienda elegir cuando se va a construir
una aplicación en donde el dominio no es conocido, el lenguaje de programación nunca se ha utilizado,
la tecnología utilizada es desconocida, el ambiente del usuario es extraño, etcétera. Construir un
prototipo abarca un 10% de la aplicación que permite probar una funcionalidad específica del sistema
y mostrarle al usuario una primera versión de este. Las ventajas que trae la utilización de prototipos
son:
• Aumento de la productividad
• Desarrollo planificado
• Brindarle al usuario una primera impresión del sistema funcionando adecuadamente.
Las desventajas que trae este tipo de estrategia son:
• Los clientes al visualizar los prototipos creen que es el sistema funcionando cuando es algo muy
lejano a eso.
• Requiere participación activa del usuario para evaluarlo.
Los tipos de prototipos que existen son:
• Prototipos de interfaz de usuario: son aquellos que se ilustran a través de pantallas brindadas a
cada uno de los usuarios.
• Prototipos de funcionalidades: ilustran cada una de las funcionalidades principales que tiene el
sistema.
• Prototipos arquitectónicos: se encargan de ilustrar las decisiones arquitectónicas tomadas
durante el desarrollo del sistema.
 • Modelo de requerimientos: son aquellos prototipos que ilustran los requerimientos reflejados
del sistema.

4. Describa los atributos de usabilidad que se consideren para evaluar una interfaz de usuario.
• Aprendizaje: este atributo nos permite saber que tan rápido es capaz un usuario de realizar
tareas dentro del sistema sin cometer errores.
• Velocidad de funcionamiento: este atributo nos permite medir el trabajo del sistema frente al
uso de la comunidad de usuarios. Se tienen en cuenta aspectos tales como el rendimiento
frente a las consultas, rapidez, concurrencia, etcétera.
• Robustez: indica que tan tolerante es el sistema a fallas y errores que cometan sus usuarios.
• Adaptación: nos permite visualizar que tan adaptable es el sistema a los distintos ambientes en
los que se lo puede incluir.
• Recuperación: este atributo ilustra que tan rápido es posible que el sistema se recupere frente
a un error o falla interna.
5. Describa los atributos de la interacción humano-maquina.
1. Uso y contexto: problemas de adaptación y uso que poseen los usuarios frente al
sistema. Dentro de ellos están:
• Trabajo y organización social: dentro del trabajo debe haber asistencia social y modelos de
interacción humana.
• Áreas de trabajo: se deben encontrar bien diferenciadas las áreas de trabajo en una empresa.
• Compatibilidad y mejora entre el humano y el sistema: mejores sobre la compatibilidad de los
usuarios con los sistemas y su uso.
2- Características humanas: comprensión de los seres humanos como procesadores de información,
requerimientos físicos y psicológicos.
• Humanos como procesadores de la información: características de cómo los humanos procesan
la información.
• Lenguaje de comunicación e interacción: características del lenguaje utilizado por el cliente.
• Ergonomía: son las características antropométricas y fisiológicas de los usuarios.
3-Sistemas computarizados y arquitectura de la interfaz: componentes especializados para la
interacción:
• Dispositivos input y output: son las características de los dispositivos de entrada y salida que
poseen los usuarios.
• Gráficos del sistema: son gráficos que se utilizan para visualizar características o rendimientos
del sistema.
• Arquitectura del dialogo: arquitectura del software y los estándares de las interfaces.
• Técnicas del dialogo: características utilizadas para que los usuarios comprendan el lenguaje del
usuario.
• Genero del dialogo: metáforas del contenido e interacción.
4- Proceso de construcción: construcción y evaluación de interfaces.
• Casos de prueba y ejemplos de funcionalidades del sistema.
• Técnicas y métodos de evaluación.
• Técnicas y procedimientos de implementación.
6. Mencione que plantean las heurísticas de Nielsen respecto del diseño de interfaces de usuario.
• Visibilidad del estado del sistema: el sistema debe poder mostrarle al usuario el estado de las
operaciones que esta realizando de una manera correcta para que el usuario comprenda
adecuadamente.
• Relación del sistema con el ambiente real: el sistema debe ser acorde con la realidad de los
usuarios y también con el ambiente de trabajo en donde este se va a desarrollar.
 • Libertad y control: debe proveer las funcionalidades de hacer y deshacer en el caso de que un
usuario cometa un error o sea de forma no intencional. Ya que la función deshacer nos
permitiría librarnos de una serie de errores comúnmente realizados por los usuarios.
• Ayuda y detección de errores: se deben prevenir los errores comúnmente realizados por los
usuarios a través de mensajes informativos.
• Ayuda y documentación: se deben implementar la documentación necesaria para la
comprensión de todo el sistema en una forma que sea fácil acceder para los usuarios y que este
al alcance de ellos sin tener que estarla recordando.
• Prevención de errores: se deben prevenir los errores comunes a través de mensajes de alerta o
informativos a los usuarios.
• Diseño estático y mínimo: el diseño de las interfaces del sistema debe contener lo que el cliente
requiera o necesite para su funcionamiento y nada más. No debe proporcionar botones o
funcionalidades de más.
• Consistencia y estándares: el sistema debe ser consistente con sus funcionalidades y estas
deben estar relacionadas adecuadamente, para evitar redundancias e inconsistencias que a la
larga nos afectarían en nuestro software.
• Reconocer antes que recordar: los usuarios deben tener todo el tiempo las funcionalidades del
sistema a la disposición, así como la documentación necesaria. No tienen que estar recordando.
• Flexibilidad y eficiencia: se debe permitir que el usuario adopte al sistema para sus usos
frecuentes.
7. Reglas de sheirderman.
• Buscar la consistencia: el sistema debe ser consistente con las cosas que ofrece y cada una de
las cosas que se han requerido por los clientes.
• Permitir el uso de SHORTOUTS: el sistema debe poder usarse por cualquier tipo de usuario,
desde usuarios capacitados hasta discapacitados.
• Dar retroalimentación: por cada acción del usuario el sistema le debe devolver algo a cambio.
• Prevenir errores comunes: alertar errores comunes con mensajes por pantalla o inhabilitación
de los botones.
• Diseñar diálogos que tengan fin: las funciones del sistema deben conducir a algo, no deben
quedarse en instancias sin lograr nada a cambio.
• Permitir que el control sea interno
• Reducir la carga de la memoria intermedia
• Permitir deshacer acciones con facilidad: los usuarios deben poder hacer y deshacer las
acciones con facilidad y esto se consigue con el uso de mensajes de prevención y confirmación.
DISEÑO DE PERSISTENCIA
1. ¿En qué consiste el problema de la impedancia? Explique cómo se mapean clases en un esquema de
Bases de Datos Relacionales. Desarrolle un ejemplo propio, que incluya todas las posibilidades de
mapeo para las relaciones.
El problema de la impedancia básicamente consiste en el hecho de tener que almacenar los objetos en la base
de datos. Un primer inconveniente que esto trae aparejado es que la estructura del modelo relacional permite
almacenar objetos con tipos de datos primitivos, lo que genera inconvenientes en el caso de los objetos
complejos. Un segundo problema seria que se genera un fuerte acoplamiento entre la aplicación y el motor de
base de datos. Y, por último, un tercer problema sería la representación de la herencia. Para comenzar a
almacenar la estructura orientada a objetos dentro del modelo relacional brindado por una base de datos, se
comienza con identificar las clases que se desean almacenar e irlas asignándolas a tablas. El proceso de mapeo
de una clase consta de las siguientes etapas:
 1. Asigna una tabla para la clase.
2. Cada atributo de la clase se convierte en una columna de la tabla. En el caso de que
haya atributos compuestos se dividen en columnas o se asigna otra tabla a que se hará
referencia mediante el uso de claves primarias y foráneas.
3. La tabla va a tener una columna que sea la identificatoria de la tabla o la clave primaria.
La misma debe ser única y mínima.
4. Cada instancia de una clase se transformará en una fila de la tabla.
5. Las asociaciones de uno que tiene la clase pasaran a conectarse con la tabla que
corresponda a la otra clase a través de claves primarias y foráneas. En el caso de
asociaciones de a muchos se creará una tabla que una estas dos tablas cuya clave
primaria serán las identificatorias de las tablas unidas.
2. Explique las características o los criterios que debería soportar la Base de Datos Orientada a Objetos.
Los motores de bases de datos orientadas a objetos son una de las soluciones del problema de la impedancia.
Ya que estos se almacenan como tales, no requieren ninguna conversión de dato. Estos tipos de bases de
datos utilizan directamente el lenguaje de programación orientado a objetos que tiene el programa para
almacenar los objetos dentro de la base de datos. Los criterios que este tipo de base de datos debe tener son:
1- Objetos compuestos: las bases de datos orientadas a objetos deben permitir el
almacenamiento de objetos compuestos dentro de ellas.
2- Jerarquía: deben poder respetar las jerarquías de las relaciones de cada clase.
3- Extensibilidad: deben permitir la extensión de los tipos de datos.
4- Ligadura tardía: deben soportar la reescritura y ligadura tardía.
5- Tipología: deben adaptarse a cada uno de los tipos que tengan los objetos.
6- Identidad de los objetos: deben poseer una manera de asignarle una única identidad a los
objetos que participan de ella.
7- Encapsulamiento: deben mantener el encapsulamiento de los objetos, haciendo que estos
conserven su información y estructura.
8- Completitud: el lenguaje de programación debe poder soportar todas las funciones y cálculos
realizados por las clases.
3. Dado el Principio de Identidad de los Objetos, ¿cómo evitamos tener objetos duplicados al
materializarlos desde los datos de un registro persistente? Explique y presente un ejemplo concreto.
Los objetos deben mantener su identidad dentro de la base de datos, esto se logra a través del uso de las
claves primarias. Cuando se mapea una clase como una tabla de la base de datos se le debe asignar a la misma
una columna identificatoria, que contenga la clave mínima y única de cada uno de los objetos. Con esto se
prevé el problema de que alguno se pueda repetir. Por ejemplo, en el caso de las personas, se las va a
identificar con el numero de documento. En donde cada instancia de la clase, ósea, cada persona que se
almacene en la tabla de la base de datos tendrá su numero de documento que servirá para identificarla de
todas las demás que se encuentran en la misma tabla de la misma base de datos.

4. Realice un cuadro comparativo explicando ventajas y desventajas y alcances de los dos esquemas
utilizados para resolver la persistencia de clases a bases de datos relacionales en el contexto del
diseño del software.
 ESQUEMA DE PERSISTENCIA SUPER OBJETO PERSISTENTE
El esquema de persistencia consiste en un conjunto Como todos los objetos que son almacenados dentro
reutilizable de clases que les brindan servicios a los de una base de datos poseen una funcionalidad de
objetos persistentes. Es el encargado de transformar persistencia común, se diseño un objeto que
los objetos en registros de bases de datos para contenga esa funcionalidad conocido como bloque,
almacenarlos y también de traducirlos luego para este bloque contiene un framework. Este bloque
recuperarlos. abstracto es heredado por todas las clases que
VENTAJAS: deben poder almacenar información en la base de
• Bajo acoplamiento. datos y el framework se especializa para cada clase
• Posee una alta cohesión. en especial.
• Fácil de extender. VENTAJAS:
DESVENTAJAS • Es sencilla y rápida.
• Es difícil de implementar. DESVENTAJAS:
• Requiere mas trabajo de diseño. • Como los lenguajes de programación
normalmente permiten el uso
únicamente de herencia simple, se
tiene que utilizar la realización.
• Alto acoplamiento.
• Se abren las clases para añadirles
funcionalidades que no les
corresponden, lo que afecta el
comportamiento y la cohesión de
estas.

EVOLUCIÓN DE SOFTWARE
5. ¿Que plantean las leyes de Lehman? Explique en qué contexto son aplicables.
Las leyes de Lehman son un conjunto de leyes empíricas que se han establecido para la evolución del
software. Establecen una brecha entre lo que se desea desarrollar y lo que es conveniente para el sistema.
Normalmente son utilizadas durante el proceso de mantenimiento. Ellas son:
1. Complejidad creciente: añadir muchas funcionalidades al sistema hace que estos se
vuelvan mas complejos de mantener y mas costosos.
2. Problema del programa grande: algunos atributos como el tamaño, los tipos de
inversión y la cantidad de errores son cosas que normalmente no cambian entre las
diferentes versiones que tiene el programa.
3. Conservación de la familiaridad: se debe mantener siempre el sistema logrando nunca
perder la satisfacción de los clientes.
4. Cambio continuo: un sistema esta continuamente en cambio, ya sea por cambios en el
codigo, en sus requerimientos, o en su ambiente de trabajo. Se debe hacer frente a cada
uno de esos cambios.
5. Extensión organizacional: en muchas ocasiones hacer cambios en el personal puede
traer afectado al sistema. Ya que un personal que ha trabajado con él, que conoce su
documentación va a poder realizar los cambios más rápidamente que uno que recién es
contratado en la empresa.
6. Crecimiento continuo: a medida que el ambiente de trabajo de los sistemas va
creciendo el sistema debe irse adaptando a esos cambios.
7. Declive de la calidad: se debe tener en cuenta que al realizar los cambios dentro del
sistema la calidad de este se conserve o incluso aumente. Ya que en muchos casos al
introducir nuevas funcionalidades puede influir de manera mala en la calidad de estos.
 8. Sistemas de retroalimentación: los procesos de evolución siempre deben introducir
sistemas de retroalimentación, de manera que al aplicar algún cambio tengan algo a
cambio.
6. Describa brevemente los tres tipos principales de mantenimiento del software ¿por qué en
ocasiones es difícil diferenciarlos?
• Mantenimiento correctivo: es aquel que se implementa cuando el sistema requiere algún
cambio relacionado al software. Estos pueden ser baratos como cambios en el codigo, o incluso
costosos como cambios en los requerimientos que requeriría un rediseño del sistema.
• Mantenimiento adaptativo: este tipo de mantenimiento se aplica cuando se requiere algún
cambio en la plataforma o evolución del hardware en el sistema.
• Mantenimiento evolutivo: este tipo de mantenimiento se aplica a medida que los procesos de
negocio van evolucionando.
En muchos casos es muy difícil diferenciarlos ya que no es muy difícil obtener que cambios hay que realizarse
en el sistema. Hay muchas ocasiones en que los cambios que se quieren realizar no están claros, entonces los
desarrolladores deben estudiar y analizar cada pedido para saber a donde deben implementar el cambio. Otro
caso sería, analizar cómo aplicar ese cambio de manera que no produzca altos costos ni altos tiempos sin
funcionamiento de este.
7. ¿Cuáles son las estrategias de evolución de Software? ¿En qué caso recomendaría la utilización de
cada una de ellas?
Las estrategias de evolución de software son 3:
• Mantenimiento: es realizar cambios sobre un sistema que ya ha sido entregado. Los cambios
pueden ser sencillos como el cambio de líneas de codigo o incluso incluir nuevos
requerimientos o funcionalidades dentro del sistema. Esta estrategia se recomienda cuando la
calidad del sistema es alta y tiene un alto impacto en el mercado.
• Reingeniería: implica desarrollar un sistema nuevo, aplicando sistemas heredados, a partir de
uno que ya existe. Dentro de la ingeniería se puede contener el esbozo de la arquitectura
nuevamente, la Modularizacion del programa, cambios en la estructura de la base de datos,
modernizar el lenguaje de programación, etcétera. Esta estrategia se recomienda utilizar
cuando la calidad del sistema es baja, pero tiene un alto valor en el negocio.
• Refactorización: implica realizar cambios en el sistema para evitar la degradación. Esta técnica
incluye la eliminación de códigos duplicados, métodos largos, sentencias “case”, etcétera. No es
una técnica que sea costosa ni trae aparejados cambios en el sistema, pero no permite que se
le agreguen nuevas funcionalidades.

8. ¿Que implica hacer reingeniería de Software? ¿Qué beneficios presenta respecto de la sustitución
del SW?
La reingeniería de software implica realizar nuevamente ingeniería, aplicando sistemas heredados a un
sistema que ya existe. Hacer reingeniería implica esbozar nuevamente la arquitectura, modificación en el
control y estructura de la base de datos e incluso cambios en el lenguaje de programación en el que esta
desarrollado el sistema. Dentro de las actividades que comprende la reingeniería tenemos:
• Modularizacion del programa: en donde se agrupan partes del programa para evitar
inconsistencias.
• Actualización del lenguaje de programación utilizado durante el desarrollo de este.
• Reingeniería de datos: en donde se actualizan y modifican las estructuras y los datos contenidos
en la base de datos.
Las ventajas que trae aplicar reingeniería con respecto a desarrollar un sistema nuevo son:
 • Reducción de los riesgos: ya que pueden cometerse errores que dentro del sistema heredado
ya se han solucionado. Además, se corren los riesgos de que el tiempo que lleve desarrollar el
nuevo sistema sea demasiado y los clientes no estén de acuerdo con ello.
• Reducción de los costos: realizar un sistema nuevo es mucho mas costoso que aplicar
reingeniería. Ya que debe empezarse desde el principio instalando, capacitando el personal,
etcétera.
9. Realice un cuadro comparativo explicando cada una de las ventajas, desventajas y alcances de las
tres formas de evolución de software.
MANTENIMIENTO REINGENIERIA REFACTORIZACION
El mantenimiento consiste en realizar Implica la realización de ingeniería, Implica el freno de la degradación
cambios dentro de un sistema que ya aplicando sistemas heredados. Es una del sistema mediante la aplicación
se ha entregado. Esto puede incluir forma de construir un sistema nuevo a de cambios. Esta técnica incluye la
cambios sencillos como lo pueden ser partir de uno ya existente. Hacer eliminación de los códigos
cambios en el codigo o algún cambio reingeniería puede significar esbozar la duplicados, de los métodos largos,
mas complejo y costoso como lo es un arquitectura, modificar la estructura de etcétera.
cambio en los requerimientos. El los datos contenidos en la base de VENTAJAS:
alcance que tiene esta estrategia es datos e incluso modificar el lenguaje de - No es costosa
cuando el sistema tiene una alta programación. La reingeniería se aplica - No es difícil de
calidad y un alto valor en el negocio. sobre cualquier parte de un sistema de implementar.
El mantenimiento actúa sobre todo el información. Se recomienda la DESVENTAJAS:
sistema en cuestión. utilización de esta cuando la calidad del - No permite la incorporación
VENTAJAS: sistema es baja, pero posee un alto de nuevas funcionalidades
- Permiten el desarrollo de impacto en el negocio. al sistema.
nuevas funcionalidades. VENTAJAS:
- Muchos cambios no son - Reducción de los riesgos.
costosos. - Reducción de los costos.
DESVENTAJAS: DESVENTAJAS:
- Algunos cambios no son - No es posible aplicar pasar de
predecibles y pueden generar un sistema de lenguaje
altos costos. funcional a uno orientado a
objetos.
- Grandes cambios pueden traer
aparejados otros problemas.
- Los sistemas con reingeniería
son mucho menos mantenibles
que un sistema nuevo.

10. ¿Cuáles son los principales factores que afectan a los costos de la evolución del Software?
Los factores respecto a los costos de la evolución del software varían dependiendo el cambio que hay que
realizarle al sistema. Por ejemplo, en el caso de que se requiera algún nuevo requerimiento que incluya una
nueva funcionalidad del sistema, influye muchos costos ya que se requiere que los desarrolladores, analistas e
ingenieros, reestablezcan los requerimientos, las decisiones arquitectónicas tienen que variar, cambiar el
codigo, las interfaces, en otras palabras, cambiar el diseño del sistema, volver a rediseñarlo, implementarlo y
probarlo. Entonces, con esto se puede decir que los factores serian el costo empleado en personal, tiempo,
hardware necesario, etcétera.
PATRONES DE DISEÑO
5. Explique la siguiente afirmación “Programar hacia la interfaz, no hacia la implementación”. Indique
al menos un patrón de diseño en el que se compruebe la aplicación de este principio.
La herencia de clases busca definir implementaciones en términos de otras. En donde una clase abstracta
padre le comparte los atributos y métodos a cada una de las clases hijos que tiene asociadas. Cuando la
herencia esta bien definida cualquiera de las clases hijos pueden responder a algún pedido relacionado a la
interfaz de la clase abstracta padre, ya que ellos por herencia poseen los mismos métodos que esta. Cada una
de las clases hijos va a refinar o añadir nuevas responsabilidades, pero nunca va a poder cambiar las que tiene
heredadas por defecto. De este modo, utilizando las interfaces y no programando hacia la implementación nos
beneficiaria en cuanto al desconocimiento de los tipos de los objetos, se desconocen las clases que
implementan dichos objetos y se ahorrarían la definición de variables como instancias de clases concretas. De
este modo con especificar las interfaces se van a cumplir los métodos esperados por cualquiera de las clases
que participen dentro de la herencia. Los patrones de creación son los que principalmente ilustran al sistema
en términos de sus interfaces y no a través de la implementación. Uno de los ejemplos de patrones de
creación es el SINGLETON, el cual proporciona una única instancia de una clase y además, establece un punto
de acceso global a ella.
6. Considere la siguiente afirmación “Las dos técnicas más comunes para reutilizar funcionalidad en
sistemas OO son la herencia de clases y la composición de objetos”. Realice una comparación del
resultado de aplicar uno u otro mecanismo a fin de obtener diseños reutilizables.
Las dos relaciones además de la delegación utilizadas para la reutilización en el diseño son la herencia y la
composición. En el caso de la herencia es una relación de especificación/generalización, en donde define una
implementación en términos de otra, lo que se conoce reutilización de caja blanca. Llamada así porque los
comportamientos internos de las clases son visibles. Esta relación se representa en tiempos de compilación, es
sencilla de aplicar y nos permite cambiar las implementaciones de las clases heredadas, aunque también trae
algunos contras, como que la misma al utilizar reutilización blanca rompe el encapsulamiento y genera un alto
acoplamiento.
La composición, por otro lado, es una relación de todo-parte, en donde cada parte pertenece al menos a un
todo y cada parte además tiene vida independiente. Esta relación ensambla o compone objetos con la
finalidad de obtener funcionalidades más complejas, técnica conocida como reutilización de caja negra.
Llamada así ya que los comportamientos internos de cada clase son ocultos. La composición se define en
tiempos de ejecución y requiere que sus objetos tengan interfaces bien definidas, además, trae beneficios
como que no genera alto acoplamiento ni rompe el encapsulamiento. Las desventajas que puede tener la
aplicación de esta relación es que un sistema basado en composición es mucho mas complejo de diseñar y
lleva mas tiempo que uno basado en herencia.
7. Según el libro de patrones de diseño GAMMA, los patrones de diseño nos ayudan a: determinar los
objetos, definir la granularidad, especificar las interfaces de los objetos, especificar la
implementación de los objetos, favorecer la reutilización y diseñar para el cambio. Explique cada una
de las afirmaciones.
• Determinar los objetos: descomponer un sistema en objetos es complejos ya que entran en
juego aspectos tales como rendimiento, encapsulamiento, flexibilidad, concurrencia, etcétera.
Muchos de los objetos provienen del workflow de análisis, pero muchos de ellos también se
generan durante el diseño y no poseen equivalencia con el mundo real. Los patrones de diseño
nos ayudan a encontrar los objetos correctos para lograr un buen diseño, un ejemplo de esto
son los patrones STRATEGY Y STATE.
• Definir la granularidad: los objetos también varían en tamaño y numero, por lo que es muy
difícil obtener una idea bien clara de cuales son los mas importantes. En este caso también
 actúan los patrones de diseño buscando las mejores alternativas para llegar a un buen diseño
del sistema de información.
• Especificar interfaces de los objetos: las operaciones de los objetos normalmente poseen un
nombre de la operación, los objetos que se pasan por parámetro y el valor de retorno. A esto se
lo denomina signatura o firma. Al conjunto de las firmas se la conoce como interfaz. Las
interfaces son muy importantes dentro de los objetos ya que estos se conocen a partir de ellos
y, además, estas proporcionan las operaciones que estos pueden realizar. Las interfaces
separan la funcionalidad de su implementación. A la asociación en tiempo de ejecución entre
una petición de un objeto y una de sus operaciones se la conoce como enlace dinámico. El
enlace dinámico nos permite que los objetos trabajen utilizando polimorfismo, el cual nos
ayuda a de funcionar y desacoplar los contenidos de los objetos. Muchos de los patrones de
diseño trabajan aplicando polimorfismo uno de los ejemplos claves es el ITERADOR.
• Especificar la implementación de los objetos: como ya sabemos los objetos se implementan
mediante clases. Los objetos son instancias de una clase, estas son las que especifican los datos
y operaciones que estos poseen. En el momento de crear una clase se crea un espacio para los
datos internos del objeto y se asignan las operaciones en función de estos datos. De una misma
clase se pueden obtener varias instancias. Las clases pueden ser concretas o abstractas, las
clases abstractas son aquellas que definen interfaces de uso común. Estas clases son
normalmente usadas en la herencia, cuando la clase abstracta padre comparte todos sus
atributos y métodos con cada una de sus clases hijos. Los patrones de diseño utilizan la
herencia y realización de clases para reutilizar métodos.
• Favorecer la reutilización: las dos técnicas más comunes de reutilización son:
- Herencia vs composición: en el caso de la herencia, lo que busca es definir una implementación en
términos de otra, lo que se denomina reutilización de caja blanca, ya que sus operaciones y datos
internos son visibles. Esto genera que la misma rompa el encapsulamiento y genere un alto
acoplamiento. En cambio, la composición, trabaja en tiempo de ejecución, componiendo o
ensamblando objetos con la idea de obtener funcionalidades más complejas, denominado como
reutilización de caja negra, ya que cada uno de los comportamientos internos no son visibles. Debido a
esto, la composición es una relación que no rompe el encapsulamiento ni genera alto acoplamiento.
- Delegación: es una relación que se utiliza para hacer que la composición sea tan potente para la
reutilización como lo es la herencia. Consiste en dos objetos, uno que es el delegado, el cual asigna las
operaciones a al otro objeto que tiene delegado para él. Esta relación tiene como ventaja que permite
que los comportamientos de los objetos puedan cambiar en tiempos de ejecución e incluso realizar
combinaciones entre ellos. La desventaja que esto posee que es mucho mas compleja de diseñar y
tiene inconvenientes en tiempos de ejecución.
• Diseñar para el cambio: los diseños de los sistemas deben estar en constante atención acerca
de los cambios que estos tienen encima, como los requerimientos nuevos que se podrían
obtener en un futuro. Los patrones de diseño son los encargados de aplicar correctamente esos
cambios para no generar inconvenientes en el diseño de nuestro sistema.
8. ¿Qué principios de diseño están afectados al patrón “Strategy”?
El patrón SRATEGY define una familia de algoritmos, encapsula cada uno de ellos y los hace
intercambiables, permite que un algoritmo varié de acuerdo con el cliente que lo este usando. Este
patrón se necesitan varias variantes de un algoritmo, cuando se desean ocultar algunos detalles de los
clientes y cuando muchas clases relacionadas difieren en su comportamiento. Utiliza una clase interfaz
estrategia que posee una composición con una clase contexto (en muchos casos es el gestor),
asociadas a la clase interfaz se encuentran las interfaces de todas las variantes de los algoritmos que
aparecen dentro del dominio. Los principios asociados a este patrón son NO TE REPITAS, PRINCIPIO DE
INVERSION DEPENDIENTE, PRINCIPIO DE SEGREGACION DE INTERFACES. El primero se aplica en cuanto
 a que las operaciones definidas por la clase interfaz estrategia son realizadas por cada una de las
estrategias que esta tiene relacionada utilizando la relación de “realización”, como una manera de no
repetir el comportamiento en cada clase. En segundo lugar, se aplica este principio en que en este
patrón se utilizan las interfaces de las clases abstractas dejando de lado los detalles de
implementación, haciendo un codigo más flexible, fácil de utilizar y testeable. En tercer lugar, se
menciona este principio debido a que cada clase tiene conocimiento de si misma y de las demás en las
que se relacione y nada más.
9. ¿Cómo se clasifican los patrones de diseño según el libro de GAMMA? Explique los propósitos de los
patrones de diseño y en que casos los aplicaría.
PATRONES DE CREACION: son aquellos que tienen como propósito abstraer el proceso de creación de
los objetos, haciendo un sistema independiente de cómo se crean, mantienen e implementan sus
objetos. Todos estos patrones encapsulan el comportamiento y se enfocan en las interfaces de sus
clases sin hacer tanto hincapié en la implementación. Hay dos tipos:
• Patrones de creación de clases: usan la herencia para abstraer el proceso de creación.
• Patrones de creación de objetos: delegan el proceso de creación a otros objetos.
Los patrones de creación son:
- SINGLETON: el cual tiene como propósito obtener una única instancia de una clase y, además,
proporcionar un punto de acceso global a ella. Este patrón es utilizado cuando se requiere que una
clase tenga una única instancia dentro del dominio, como por ejemplo una cola de impresión, a la cual
los clientes puedan acceder a ella a partir de un punto de acceso global de forma uniforme y ordenada.
Este patrón estáticamente tiene una única clase Singleton que se encarga de realizar todas las
funciones.
- BUILDER: desacopla el proceso de representación de la construcción, de manera que con un mismo
proceso de construcción se puedan generar muchas representaciones. Este patrón es utilizado cuando
se requiere que una misma representación, ya sea de un informe, reporte, estadístico, etcétera; pueda
ser visible en diferentes pantallas de la misma forma a través de la creación de constructores que
tendrán las funciones para crear cada parte de ellos y visualizarlas en la interfaz. Estáticamente este
patrón contiene un contexto (que generalmente suele ser el gestor), un director (encargado de la
construcción de cada parte del reporte, informe), un constructor (el cual crea el director y setea cada
una de las partes que se desean crear antes de enviárselas a la interfaz), una interfaz (es la encargada
de setear las partes e imprimir finalmente lo que se requiere). Cabe aclarar que, en la mayoría de los
casos, existe mas de un constructor, debido a que el formato soportado dentro del sistema es mas de
uno. En este caso, se deben construir también la cantidad de interfaces por constructor.
PATRONES DE COMPORTAMIENTO: estos son aquellos que designan las responsabilidades a objetos y
establecen la comunicación entre ellos. Por lo que, no solo son patrones de objetos sino también de
comunicación de objetos. Existen dos tipos:
• Patrones de comportamiento de clases: usan la herencia para distribuir el comportamiento
entre clases.
• Patrones de comportamiento de objetos: usan la realización para distribuir el comportamiento
entre objetos.
Los patrones de comportamiento son:
- STATE: es aquel que describe como cambia el comportamiento de un objeto cada vez que cambia su
estado interno. Este patrón es utilizado cuando el objeto considerado sufre cambios en su estado
interno debido a diferentes causas. Estáticamente, este patrón contiene un contexto (formado
normalmente por el gestor y la clase de entidad que posee el cambio de estado), la clase abstracta
estado, y todos los posibles estados asociados a la clase abstracta usando la herencia.
- STRATEGY: es aquel que define una familia de algoritmos, encapsula cada uno de ellos y los hace
intercambiables, haciendo que cada algoritmo varié en función del cliente que lo esta usando. Este
 patrón de utiliza cuando un algoritmo posee variantes, cuando muchas clases relacionadas difieren en
su comportamiento y cuando se requiere que los clientes no visualicen los detalles de los algoritmos.
Estáticamente, este patrón cuenta con un contexto, seguido de una interfaz estrategia a la cual se
encuentran relacionadas cada una de las estrategias mediante realización.
- ITERADOR: proporciona un método de búsqueda secuencial dentro de los objetos sin exponer su
representación interna. Este patrón se utiliza cuando se requieren búsquedas dentro del objeto, con la
aplicación o no de filtros. Estáticamente, este patrón consta de una clase lista (la cual hereda un
método de crear un iterador), una clase de iterador (un iterador por cada búsqueda que se realice) y
una interfaz relacionada a dicho iterador. Además, se debe contar con el contexto y las clases de
entidad de las que se quieren realizar las búsquedas.
- OBSERVER: define una relación uno a muchos entre objetos, de manera que cuando cambie el estado
de uno de ellos se actualicen automáticamente todos los objetos que dependen de él. Este patrón se
utiliza normalmente cuando se quiere anunciar o notificar algún cambio de estado o en la estructura
interna de un objeto sin conocer a cuantos objetos hay que cambiar ni cuales son. Estáticamente este
patrón se define con un sujeto concreto que posee los cambios de estado, un interfaz sujeto (la cual
conoce a sus observadores y proporciona las interfaces para agregar y quitar observadores), un
observador concreto (subscribe cada uno de los objetos que se van a actualizar), una interfaz del
observador (es la que proporciona la actualización, publicación, anuncio, etcétera).
- TEMPLATE METHOD: define una operación de esqueleto de un algoritmo, delegando sus pasos en cada
una de sus clases hijas, permitiéndoles a estas que redefinan los pasos, pero nunca pueden cambiar el
esqueleto central. Este patrón se usa cuando se desean implementar partes de un algoritmo que no
cambia, cuando se repite el comportamiento en cada clase y debe factorizarse y para controlar las
extensiones. Estáticamente, este patrón contiene una clase abstracta con el método del esqueleto y las
operaciones primitivas y una o muchas clases hijas concretas con las operaciones primitivas heredadas.
PATRONES DE ESTRUCTURA: son los encargados de ensamblar o componer objetos para obtener
funcionalidades mas complejas. Existen dos tipos:
• Patrones de estructura de clases: usan la herencia para obtener comportamientos mas
complejos.
• Patrones de estructura de objetos: usan la realización para obtener funcionalidades mas
complejas.
Los patrones de estructura son:
- COMPOSITE: proporciona una estructura de árbol para representar jerarquías de parte-todo, en donde
se busca que los objetos simples y compuestos no sean distinguidos en cuanto a sus diferencias. Este
patrón se utiliza cuando se quieren obviar las diferencias entre objetos compuestos y simples y cuando
se requiere construir una estructura de árbol. Estáticamente, este patrón contiene una clase entidad o
contexto, una interfaz componente, un producto simple y un producto compuesto.
WORKFLOW DE IMPLEMENTACION
1. ¿Cuáles son los propósitos de la implementación y su papel en el ciclo de vida iterativo e
incremental?
La implementación lo que busca lograr es tomar los elementos del modelo de diseño e implementarlo en
forma de componentes como archivos ejecutables o codigo fuente. También podemos decir que la
implementación busca desarrollar el sistema a partir de pasos pequeños y manejables, debido a que esto
le conducirá a pruebas más controlables y errores mas pequeños. Este workflow también tiene a su
encargo implementar cada una de las clases de diseño y subsistemas y asignarlos a nodos en un diagrama
de despliegue.
Dentro del ciclo iterativo e incremental propuesto por el PUD la implementación se encuentra
principalmente en la etapa de la construcción, aunque también esta presente en la etapa de la elaboración
cuando se esboza la parte física de la arquitectura y también en la etapa de la transición frente a errores
posteriores.
2. Defina los artefactos del workflow de implementación asociando los trabajadores a cada uno de
ellos.
- MODELO DE IMPLEMENTACION: el modelo de implementación se enfoca principalmente en como los
elementos del modelo de diseño son implementados como componentes de codigo fuente o archivos
ejecutables. Describe como se organizan los componentes de acuerdo con los mecanismos de
estructuración y Modularizacion descriptos por cada uno de los lenguajes de programación utilizados para
el desarrollo del sistema. El actor que esta a cargo de este artefacto es el arquitecto, el cual es el
encargado de que el modelo mantenga la integridad, sea correcto y legible como un todo. Con correcto se
hace referencia a que proporcione las funcionalidades para las que fue diseñado y solo esas
funcionalidades.
- COMPONENTES: son piezas de codigo preelaborado que sirve para cumplir requerimientos, empaquetar
elementos como por ejemplo las clases de diseño. El encargado de este artefacto es el ingeniero en
componentes quien define la funcionalidad que este va a tener y cuales van a ser sus relaciones, así como
también es responsable de que cumpla los requerimientos que tiene asociado y que posea las mínimas
dependencias entre los demás componentes.
- SUBSISTEMAS DE IMPLEMENTACION: son un artefacto que nos permite organizar el codigo en piezas
mas manejables. Los subsistemas están correspondidos con una medida de empaquetamiento que seria
como un paquete en Java o un proyecto en C#. Además, cada uno de los subsistemas esta relacionado con
un subsistema de diseño, en donde se debe cumplir que las interfaces sean iguales y las dependencias
también. Los encargados de este artefacto son los ingenieros en componentes, en donde se aseguran de
que los subsistemas proporcionen las interfaces correctas, y que posean cada una de las operaciones para
lograrlas de forma correcta.
- INTERFACES: es el artefacto que permite la especificación de la funcionalidad de un componente o
subsistema de la implementación. Tiene la capacidad de separar la funcionalidad del componente de su
especificación. La interfaz nos permite ver la funcionalidad de los componentes, pero nunca saber los
detalles de la implementación. El encargado de este artefacto es el ingeniero en componentes, donde
debe verificar que las interfaces tengan los componentes adecuados o subsistemas para llevarlas a cabo.
- DESCRIPCION DE LA ARQUITECTURA: la arquitectura se describe mediante vistas, en este caso, la vista de
implementación nos muestra al sistema desde una perspectiva del desarrollador y administra los
artefactos de software, los organiza. Los artefactos significativos para la arquitectura es la descomposición
del sistema en subsistemas, donde cada subsistema este contenido por componentes que realicen
interfaces.
- PLAN DE CONSTRUCCION: como ya hemos mencionado, el sistema se organiza en pasos manejables y
pequeños a la hora de desarrollarlo. Cada uno de esos pasos se denomina construcción. Normalmente en
cada iteración se trataba una funcionalidad dada por una única construcción, aunque últimamente se
empezó a visualizar que las funcionalidades pueden ser lo suficientemente complejas como para ser
tratadas en una única construcción. Debido a esto, se utilizan más de una construcción para cumplir una
funcionalidad dentro de una iteración. Al conjunto de las construcciones con las respectivas
funcionalidades que tiene cada una de ellas se la denomina plan de construcción. Cabe aclarar que
ninguna construcción se crea sin que se haya probado y dejado lista la que se estuvo programando
anteriormente. Este artefacto esta a cargo del integrador de sistemas, quien establece las funcionalidades
necesarias y el orden en que se va a establecer cada construcción.
3. Defina el flujo de trabajo de la implementación explicando brevemente cada etapa.
1- El arquitecto diseña el modelo de implementación tomando como entrada el modelo de diseño.
Identifica los componentes principales y los asigna a los nodos principales.
2- El integrador de sistemas estudia las funcionalidades con respecto a resoluciones de casos de uso
concretos o incluso basándose en construcciones que se hayan realizado anteriormente. Una vez
planificadas las funcionalidades que se adaptaran a las construcciones elabora el plan de
 construcciones estableciendo cada uno de los componentes necesarios en cada iteración para elaborar
las construcciones.
3- El ingeniero en componentes implementa los componentes y subsistemas especificados en el plan de
acción.
4- Los componentes son probados y enviados al integrador de componentes para que los integre dentro
del plan de construcción.
5- Los desarrolladores inician la implementación de la construcción tomando como entrada la
construcción anterior.
WORKFLOW DE PRUEBA
1. Defina los artefactos del workflow de prueba junto con sus trabajadores.
- MODELO DE PRUEBA: describe como los elementos implementados durante el modelo de
implementación son sometidos a pruebas tanto de integración como de sistema. Las pruebas de
integración son con respecto a la integración de los componentes dentro del plan de construcciones de
la implementación y las pruebas de sistema son las relacionadas al sistema completo. Los trabajadores
relacionados a este tipo de artefactos son los diseñadores de sistemas, quienes son los encargados de
mantener la integridad del modelo y de que este se vea como un todo.
- CASOS DE PRUEBA: especifican una forma de probar un elemento, incluyendo la entrada y la salida de
estos. En algunos casos se toma un caso de uso y en función de eso se crea un caso de prueba, lo que
se conoce como prueba de caja negra, ya que se prueba como funciona exteriormente el mismo. O, en
otro caso, se toma una realización de caso de uso de diseño y se elabora un caso de prueba en relación
con eso, lo que se llama prueba de caja blanca, debido a que se prueba como funciona internamente.
El trabajador asociado a este tipo de artefactos es el diseñador de sistemas, quien es el encargado de
diseñar los casos de prueba en función al elemento que se desea probar.
- PROCEDIMIENTOS DE PRUEBA: es el que nos permite visualizar como se van a llevar a cabo los casos de
prueba. El actor representante de este artefacto también es el diseñador de prueba, quien define los
procedimientos de prueba en función a los casos de prueba creados anteriormente.
- COMPONENTE DE PRUEBA: sirve para automatizar los procedimientos de prueba. Los encargados de
este artefacto son los ingenieros en componentes, quien realizan las pruebas a los componentes por
separado.
- PLAN DE PRUEBA: es la evaluación, planificación de las pruebas necesarias a realizar sobre los
diferentes elementos del sistema.
- DEFECTOS: son anomalías que se presentan durante la realización de las pruebas.
- EVALUACION DE PRUEBA: son los resultados obtenidos de cada una de las pruebas realizadas sobre los
sistemas. Este artefacto sirve de entrada muchas veces para el workflow de implementación
detallando que cosas deben cambiarse o mejorarse.
2. Describa el flujo de trabajo del workflow de prueba mencionando los artefactos
significativos en cada paso.
1- El diseñador de pruebas planea las pruebas que va a realizar sobre el modelo de prueba proveniente
del modelo de implementación. Describiendo las estrategias y los pasos a utilizar.
2- El diseñador de pruebas elabora los casos de prueba tanto de integración como de sistema y los
procedimientos que estos van a seguir para cumplirse. Para establecer esto estudia los casos de uso y
especificaciones de casos de uso identificando las necesarias y que tipo de prueba realizarle a cada
una. Luego que tiene cada uno de los casos de prueba necesarios procede a la elaboración de los
procedimientos de prueba haciendo enfoque en que sean reutilizables, es decir que los mismos
procedimientos puedan utilizarse en otros casos de prueba.
3- Los ingenieros en componentes crean los componentes de prueba que automatizaran los
procedimientos de prueba creados anteriormente.
4- Los ingenieros en pruebas de integración y los ingenieros en pruebas de sistemas realizan su trabajo
sobre los componentes y casos de prueba y obtienen los resultados.
 5- Finalmente, los desarrolladores obtienen los resultados de las pruebas que serán enviados a los
responsables del modelo de diseño o implementación en caso de que se requieran cambios antes de
pasar al despliegue del producto.
3. Mencione las etapas de la prueba describiendo brevemente cada una de ellas.
• Pruebas de desarrollo: este tipo de pruebas son realizadas dentro del ambiente de los
programadores a medida que van desarrollando el sistema, dentro de estas están las que se
realizan por unidad (probando cada unidad del sistema de forma minuciosa), las de
componentes (en donde se toma cada componente y se le aplican las pruebas necesarias) y
finalmente, la de sistema, que abarca la prueba final del sistema entero funcionando como un
todo.
• Pruebas de versión: son pruebas realizadas dentro del ambiente de trabajo de un equipo de
prueba. Dentro de este tipo de pruebas se encuentran las pruebas de requerimientos y de
rendimiento. Las primeras detallan cuanto cumple el sistema los requerimientos especificados
por los clientes y la segunda el rendimiento frente al uso del sistema.
• Pruebas de usuario: son las pruebas que realiza cada usuario dentro de su ambiente. Dentro de
ella están las alfas, en donde los usuarios prueban el sistema dentro del ambiente del
programador, las betas, en donde los usuarios prueban ya el sistema solos, y la gama, en donde
el usuario implementa el sistema dentro del ambiente de trabajo y lo prueba, devolviendo las
evaluaciones de este.
WORKFLOW DE DESPLIEGE
1. Describa los trabajadores del workflow de despliegue.
- GERENTE DE DESPLIGUE: es el encargado de planificar y organizar el despliegue. Este se debe asegurar
que el producto este empaquetado correctamente para su envió.
- GERENTE DE PROYECTO: es el encargado de que el proyecto se envíe correctamente, es el
intermediario con los clientes. También se debe asegurar que el cliente esta en correctas condiciones
para recibir el producto.
- ESCRITOR TECNICO: planea y produce material de soporte para los usuarios.
- DESARROLLADOR DE CURSOS: es el encargado de los cursos de capacitación brindados para los
usuarios.
- ARTISTA GRAFICO: es el encargado de las interfaces graficas brindadas a los usuarios.
- TESTER: es el encargado de probar todo el producto antes de ser entregado a los clientes.
- IMPLEMENTADOR: es quien realiza los scripts necesarios de instalación.
2. Mencione el flujo de trabajo del workflow de despliegue.
- PLAN DE DESPLIEGUE: consiste en que los gerentes de despliegue y de proyecto evalúen el producto y además
de verificar que este correctamente listo para ser empaquetado, verifiquen que el ambiente del cliente esta
preparado para recibir al producto en las correctas condiciones y que además el cliente este lo suficientemente
capacitado como para utilizar el producto.
- DESARROLLAR MATERIAL DE SOPORTE: el escritor técnico junto con el desarrollador de capacitación debe
mantener listos los manuales y ayudas para los usuarios del sistema, de modo que puedan hacerlo de manera
eficiente.
- PROBAR EL PRODUCTO EN EL AMBIENTE DE DESARROLLO: los testeros deben probar el producto de todas las
formas que encuentren necesarias antes de enviarlas al ambiente del cliente. Ya que ellos serán los responsables
en caso de que se encuentren fallas a la hora de implementarlo en el ambiente de trabajo.
- CREAR LA RELEASE: la reléase va a contener todo lo que el cliente necesite para instalar y utilizar el sistema.
- BETA TEST DE LA RELEASE: esto requiere que el producto sea instalado en el ambiente del cliente. Esto es
importante ya que nos permite saber las expectativas que le genero el producto al cliente y las devoluciones que
el tiene sobre este.
- PROBAR EL PRODUCTO EN EL AMBIENTE DEL CLIENTE: el producto es correctamente instalado y se lo entrega al
cliente para que comience a utilizarlo.