Resumen DSI

Flujo de Trabajo de Anlisis
Propsito General: Lograr una comprensin ms precisa de los requisitos capturados en la etapa anterior y una descripcin de los
mismos que sea ms fcil de mantener. Tambin nos ayuda a estructurar el sistema entero incluyendo su arquitectura. Se pasa del
lenguaje del cliente a un lenguaje ms formal.
Propsitos especficos:
-Lograr una estructura del sistema que sirva de entrada para las actividades de diseo e implementacin.
-Lograr una especificacin ms precisa de los requerimientos, empleando el lenguaje de desarrolladores y razonando sobre
los aspectos internos del sistema.
-Lograr una estructura mantenible de los requerimientos que faciliten su compresin, su reparacin, su modificacin y en
general su mantenimiento (Por mantenimiento entendemos dos aspectos: la flexibilidad ante cambios de requisitos, y la
posibilidad de reutilizacin)
Rol del anlisis dentro del ciclo de vida del SW
El flujo de trabajo de anlisis, trabaja ms que nada en la ltima parte de la fase de inicio, gran parte en la fase de
elaboracin y un poco en la primera parte de la construccin.
Inicio: Ayuda a planificar las iteraciones. Se plantean objetivos del proyecto
Elaboracin: En las iteraciones iniciales de la elaboracin se centra el anlisis para lograr una arquitectura robusta y estable
y facilita una comprensin en profundidad de los requisitos. Define tiempos, costos y recursos.
Construccin: Parte operativa del software. Primeras pruebas
Transicin: Corregir errores. Versiones del sistema beta. Se prepara la entrega del software

Vista Esttica del flujo de trabajo de anlisis:
Vista dinmica del flujo de trabajo de anlisis:
Diagrama desde el enfoque de sistemas:
ENTRADA PROCESO SALIDA
Requisitos adicionales
Modelo de CU
Modelo de Negocio ( MODP)
Descripcin de la arquitectura (vista
CU)
Analizar la arquitectura (Arquitecto)
Analizar los CU (Ing. C-U)
Analizar clases de anlisis (Ing. Em
Componentes)
Analizar paquetes (Ing. En
Componentes)
Modelo de Anlisis
Diagrama de clases de anlisis
Paquetes de anlisis
Realizaciones de CU
Descripcin de la arquitectura (Vista
de Anlisis)
Requisitos Especiales

Problemas que resuelve el Anlisis:
-Dependencia entre Casos de Uso. Debe lograr una independencia entre los mismos.
-Paso de un lenguaje del cliente a un lenguaje ms formal (Lenguaje desarrollador)
-Intenta estructurar el sistema, lo que permite el mantenimiento del mismo
-Paso de una estructura basada en C-U a una basada en paquetes de anlisis y clases de anlisis.

Ventajas de realizar Anlisis:
-Brinda una base que no utiliza lenguajes. Al ser un modelo conceptual, puede servir de punto de partida para realizar distintas
implementaciones
-Detecto tempranamente los errores. Mientras ms tarde detecte el error, ms costoso ser repararlo. Encontrarlo en el anlisis me
ayudara a reducir ese costo.
-Resulta ms rpida la capacitacin al incorporar nuevas personas al equipo de trabajo.
-No es tan costoso relacionado con el diseo, ya que existe una relacin de 5 a 1 con el mismo. Por cada elemento del anlisis,
existirn 5 elementos en el diseo.
-Se puede comprender los sistemas heredados a partir del modelo de anlisis. Es decir que me permite la reutilizacin. Para
aprovechar las partes que funcionan de un sistema heredado, utilizo el modelo de anlisis.
-Es ms fcil dividir tareas y asignar responsabilidades al grupo de desarrollo.

Importancia del anlisis:
Algunas empresas no realizan anlisis pero si hacen las actividades del mismo en los WF de requerimientos y diseo. Incorporarlo al
primero involucra ms formalidad en el lenguaje, lo cual es muy probable que dificulte la compresin por parte del cliente.
Incorporarlo en el segundo, a la hora de tomar decisiones puedo no tener en claro que es lo que hace el sistema y puedo tomar
caminos errneos.

Influencia del Modelo de Anlisis en el Modelo de Diseo
El modelo de anlisis se considera la entrada fundamental para las actividades de diseo subsiguientes.
-Los paquetes de anlisis y los paquetes de servicios tendrn una influencia fundamental en los subsistemas de diseo y en los
subsistemas de servicio, en las capas especficas y generales de las aplicaciones
-Las clases de anlisis servirn entrada para las clases de diseo. Las clases de anlisis y sus responsabilidades, atributos y relaciones
sirven como una entrada lgica para la creacin de las correspondientes operaciones, atributos y relaciones de las clases de diseo.
-Las realizaciones de C-U de anlisis, ayudan a crear especificaciones ms precisas para el caso d euso, sirven como entradas al
diseo de los casos de uso. Ayudarn a identificar clases de diseo que deben participar en la correspondiente realizacin de c-u de
diseo. Tambin son tiles porque esbozan una secuencia inicial de interacciones entre los objetos de diseo. Los requisitos de la
realizacin de c-u de anlisis se trataran en la correspondiente realizacin de c-u de diseo al considerar tecnologas.
-La vista de la arquitectura del modelo de anlisis se utiliza como entrada en la creacin de la vista de la arquitectura del modelo de
diseo
-Los requisitos especiales sirven para una vez que se define el lenguaje de programacin, poder completar las clases.

Tipos de Proyecto segn el anlisis:
-Aquellos en los que se utiliza el modelo de anlisis en el diseo y la implementacin, y se lo mantiene actualizado al mismo.
-Aquellos en los que se hace el modelo de anlisis hasta que se termina la fase de elaboracin y despus no se lo actualiza. Ya que al
terminar la segunda iteracin de elaboracin, la arquitectura est implementada y probada. Por lo tanto la parte ms crtica del
sistema est resuelta, las zonas de mayor riesgo ya fueron atacadas, por lo que se puede dejar de lado el anlisis.
-Aquellos en los que no se hace anlisis debido a que el dominio es muy simple. Puede suceder que el usuario entiende mucho de la
tarea, y expresa con precisin lo que quiere y al mismo tiempo, los desarrolladores tienen experiencia en el dominio, por lo tanto no
es necesario el anlisis.
Al momento de elegir entre estas alternativas influye el factor costo-beneficio de mantener el anlisis durante todo el proyecto o
dejar de actualizarlo.

Anlisis de Comportamiento del SW:
Concepto: Analiza como acta y reacciona el sistema en trmino de objetos. Analizo aspectos internos del sistema, como colaboran
los objetos a travs del paso de mensajes.
Como contribuyen las otras actividades (Trabajadores):
-Arquitecto: Al analizar la Arquitectura, el arquitecto esboza clases de entidades crticas.
-Ingeniero C-U: Al hacer las realizaciones de C-U, esboza nuevas clases, que sirven para que el Ing. en Componentes
complete el diagrama de Clase de Anlisis.
Actividad Principal: Analizar un Caso de Uso (Lo realiza el Ing. En Caso de Uso)
Artefacto: Realizacin de Caso de uso:

Anlisis de Estructura del SW:
Concepto: Analizar la forma ms eficiente del sistema incluyendo su arquitectura.
Estructura: Forma del sistema. Dentro del anlisis, la estructura esta basada en Clases de anlisis y paquetes de anlisis.
Arquitectura: Partes crticas de la estructura. El concepto de arquitectura software incluye los aspectos estticos y
dinmicos ms significativos del sistema (aspectos crticos). La arquitectura del sistema surge de las necesidades de la
empresa, como las perciben los usuarios y los inversores, y se refleja en los casos de uso. Sin embargo, tambin se ve
influenciada por muchos otros factores, como la plataforma en la que tiene que funcionar el software, los bloques de
construccin reutilizables de que se dispone, consideraciones de implementacin, sistemas heredados y requisitos no
funcionales. La arquitectura es una vista del diseo completo con las caractersticas ms importantes resaltadas, dejando de
lado los detalles.
Actividad Principal: Analizar Arquitectura
Artefacto: Descripcin de la Arquitectura, Vista del Modelo de anlisis.

Actividades:
Anlisis de la arquitectura: su propsito es esbozar el modelo de anlisis y la arquitectura mediante la identificacin de paquetes del
anlisis, clases de anlisis evidentes y requisitos especiales comunes.
-Identificacin de paquetes del anlisis:
-Identificacin de clases de entidad obvias:
-Identificacin de requisitos especiales comunes:
Analizar un Caso de Uso:
-Identificar las clases del anlisis cuyos objetos son necesarios para llevar a cabo el flujo de sucesos del CU.
-Distribuir el comportamiento del CU entre los objetos del anlisis que interactan
-Capturar requisitos especiales sobre la realizacin de los CU
Analizar una clase: los objetivos de analizar una clase son:
-Identificar y mantener las responsabilidades de una clase del anlisis, basadas en su papel en las realizaciones de CU.
-Identificar y mantener los atributos y relaciones de la clase del anlisis
-Capturar requisitos especiales sobre la realizacin de la clase del anlisis.
Analizar un paquete: los objetivos de analizar un paquete son:
-Garantizar que el paquete del anlisis es tan independiente de otros paquetes como sea posible
-Garantizar que el paquete del anlisis cumple su objetivo de realizar algunas clases del dominio o CU
-Describir las dependencias de forma que pueda estimularse el efecto de los cambios futuros.

Artefactos Anlisis:
Descripcin de la arquitectura: contiene una vista de la arquitectura del modelo de anlisis que muestra sus artefactos significativos
para la arquitectura. Los siguientes artefactos del modelo de anlisis, normalmente se consideran significativos para la arquitectura:
1. La descomposicin del modelo de anlisis en paquetes de anlisis y sus dependencias.
2. Las clases fundamentales del anlisis, como las clases de entidad que encapsulan un fenmeno importante del dominio del
problema, las clases de interfaz que encapsulan interfaces de comunicacin importantes y mecanismos de interfaz de usuario, las
clases de control que encapsulan importantes secuencias con una amplia cobertura y las clases del anlisis que son generales,
centrales y que tienen muchas relaciones con otras clases del anlisis.
3. Realizaciones de CU que describen cierta funcionalidad importante y crtica.
Vista del modelo de anlisis: Usa el diagrama de clases de Anlisis, el diagrama de paquete de anlisis y el modelo de anlisis.
Modelo de anlisis: El modelo de anlisis se representa mediante un sistema de anlisis que denota el paquete de ms alto nivel del
modelo. Dentro del modelo de anlisis, los CU se describen mediante clases de anlisis y sus objetos. Esto se representa mediante
colaboraciones dentro del modelo de anlisis que llamamos realizaciones de CU de anlisis.
Realizacin de Caso de uso:

Concepto: Colaboracin de un conjunto de objetos que se envan y reciben mensajes determinando una funcionalidad del
sistema con un propsito determinado.
Composicin:
-Descripcin textual del flujo de sucesos
-Diagrama de clases (parcial)
-Diagrama de interaccin
-Requisitos especiales
Paquete de anlisis:
Concepto: Es un elemento de agrupacin UML y permite organizar los elementos del modelo en piezas manejables.
Composicin: Puede constar de clases de anlisis, realizaciones de CU y de otros paquetes de anlisis (recursivamente).
Caractersticas Principales: Los paquetes de anlisis deberan ser cohesivos (los elementos del paquete deben estar muy
relacionados) y dbilmente acoplados (Debo reducir la cantidad de relaciones con otros paquetes).
Otras caractersticas:
Descripcin C-U
MODP
Analizar C-U
Realizacin de C-U
1. Pueden representar una separacin de intereses de anlisis.
2. Deberan crearse basndonos en los requisitos funcionales y en el dominio del problema, y deberan ser
reconocibles por las personas con conocimientos del dominio.
3. Probablemente se convertirn en subsistemas en el diseo.
Pasos para encontrar paquetes de anlisis:
1. Examinar Clases de anlisis, busque:
-Clusters de casos de uso que soportan un proceso de negocio determinado o actor. Pueden tener clases
de anlisis que se deberan empaquetar juntas.
-Los paquetes de anlisis a menudo atraviesan casos de uso.
2. Mejore el modelo de paquete para maximizar la cohesin dentro del paquete y minimizar las dependencias
entre paquetes al:
-Mover clases entre paquetes
-Aadir paquetes
-Eliminar Paquetes
-Eliminar dependencia cclicas al unir paquetes o al dividirlos para resolver clases acopladas. .
Cuando identificar paquete de anlisis:
Al inicio del anlisis:
-Sirve como herramienta de organizacin de trabajo.
-Al comienzo del anlisis no tengo demasiada informacin.
-Si lo hago aqu, no voy a saber si van a ser subsistemas de diseo.
-Al final de la fase de elaboracin debo revisar.
Al final de la fase de elaboracin:
-Tengo mayor informacin, nos encontramos en condiciones de definirlos.
-Me sirven para determinar la estructura.
Criterios para identificar paquetes de anlisis:
-Dar soporte a un proceso de negocio.
-Dar soporte a un actor
-Por funcionalidad relacionada.
Quien? Cuando?: Lo realiza el Arquitecto en el momento de analizar la estructura (Pero no se va a encargar de mantenerlo,
esto lo hace el Ing. En Componentes.)
Paquetes de servicio:
Concepto: Conjunto de acciones relacionadas brindando un servicio. Se utilizan en un nivel ms bajo de la jerarqua de paquetes de
anlisis para estructurar al sistema de acuerdo a los servicios que proporciona.
Comparacin con C-U:
-El Caso de Uso esta destinado a usuarios, el paquete de servicio apunta al cliente
-Un C-U puede utilizar uno o ms paquetes de servicios.
-Varios C-U pueden utilizar un mismo paquete de servicio.
-Si elimino un paquete de servicios debo revisar los C-U donde estaba incluido.
Caractersticas:
-Tienen bajo acoplamiento y alta cohesin.
- Son indivisibles, u obtengo todas las clases que lo conforman o ninguna.
-Es un instrumento fundamental para la reutilizacin durante el anlisis.
-Pueden ser mutuamente excluyentes o representar distintas variantes del mismo servicio.
-Jerrquicamente dentro del paquete de anlisis.
-Estn atravesados por varios C-U
Identificacin:
Momento: Al final de la fase de elaboracin. Ya que aqu tenemos mucha informacin de lo que hace el sistema.
Criterios:
-Conjunto de clases relacionadas que potencialmente en un futuro sea un servicio.
-Se ve muy claro un conjunto de clases que brindan un servicio.
Composicin: Clases.
Quin? Cuando?: El Arquitecto, cuando analiza la arquitectura.

Clase de Anlisis: Representa una abstraccin de una o varias clases y/o subsistemas del diseo del sistema. Participa en relaciones.
Estas se centran en los requisitos funcionales y pospone los no funcionales. A nivel de atributo, se define conceptualmente, se puede
especificar el tipo. A nivel comportamiento, se trabaja con responsabilidades (Servicios que debera a nivel conceptual realizar la
clase). Las relaciones y operaciones se definen a nivel conceptual.
Las clases de anlisis siempre encajan en alguno de los 3 estereotipos bsicos: de interfaz, de control o de entidad. Cada estereotipo
tiene una semntica especfica; logrndose un mtodo consistente de identificar y describir las clases de anlisis y contribuye a la
creacin de un modelo de objetos y una arquitectura robusta.
Clase Interfaz: se utilizan p/ modelar la interaccin entre el sist. y sus actores. Esta interaccin implica recibir (y presentar)
informacin y peticiones de (y hacia) los us. Estas modelan las partes del sist. q' dependen de sus actores y representan
abstracciones de ventanas, interfaces de comunicaciones o de impresoras, sensores, etc.
Clase Entidad: se utilizan p/ modelar inform. que posee una vida larga y que es persistente, y el comportamiento asociado
de algn fenmeno o concepto, como una persona, objeto o suceso. Gral// derivan de clases de entidad del negocio.
Clase Control: representan la coordinacin, transaccin y control de objetos y se usa para encapsular el control de un C-U.
Tb, para representar clculos complejos, como la lgica del negocio.
La Clase de control puede no estar, cuando interviene una sola o muy pocas entidades. Pero no es aconsejable. Si no lo
tengo, sumo sus funciones a la interfaz, produciendo un alto acoplamiento.
Tambin puede presentarse el caso de tener ms de una clase de control, cuando modelo el caso de una colaboracin
compleja, entonces colocamos varios objetos de control para simplificar la solucin.
Clases de fabricacin pura: Control e Interfaz. Surgen en el momento del anlisis y duran mientras el ciclo de vida del C-U exista.
Donde influyen los cambios:
-Cualquier cambio en la interaccin del sistema afecta en la clase de interfaz.
-Cambios en la estructura de informacin afecta a las clases de entidad.
-Cambios en las reglas de negocio, afecta a las clases de control.

Patrones:
Qu es un patrn: Un patrn es una plantilla, una buena prctica que nos llevan a resultados de calidad y nos permiten reutilizar el
conocimiento.
Planifico, ejecuto y controlo todo lo planificado. Si sale en concordancia con lo ejecutado, se documenta en patrones. Los patrones
se plantean en problemas comunes en distintos proyectos y propone una solucin comn a esos proyectos. No especifica dominio.
Ventajas:
Estn probados. Aprovecho lo ya realizado y no empiezo desde cero. Dedico el tiempo a mejorar la prctica.
Sirven como manual de referencia.
Patrones GRASP:
Concepto: Son patrones que me permiten asignar responsabilidades durante el anlisis, que es cuando necesitamos comprender
aspectos internos del sistema.
Uso: Dentro de cualquier diagrama de interaccin.
Tipos:
Patrn experto
Patrn creador
Patrn Bajo Acoplamiento
Patrn Alta Cohesin
Patrn Controlador
Patrn No Hables Con Extraos

Trabajadores
Arquitecto: es responsable de la integridad del modelo de anlisis, garantizando que este sea correcto, consistente y legible como
un todo. Tambin es responsable de la arquitectura del modelo de anlisis, es decir, de la existencia de sus partes significativas para
la arquitectura tal y como se muestran en la vista de la arquitectura del modelo.
Ingeniero de CU: es responsable de la integridad de una o ms realizaciones de CU, garantizando que cumplen con los requisitos que
recaen sobre ellos. Una realizacin de CU debe llevar a cabo correctamente el comportamiento de su correspondiente CU del
modelo de CU, y solo ese comportamiento. Esto incluye garantizar que todas las descripciones textuales y los diagramas que
describen la realizacin del CU son legibles y se ajustan a su objetivo.
Ingeniero de Componentes: define y mantiene las responsabilidades, atributos, relaciones y requisitos especiales de una o varias
clases del anlisis, asegurndose de que cada clase cumple los requisitos que se esperan de ella. Tambin mantiene integridad de
uno o varios paquetes del anlisis. Esto incluye garantizar que sus contenidos son correctos y que sus dependencias con otros
paquetes del anlisis son correctas y mnimas.
Si existe una traza directa entre los paquetes de anlisis y los subsistemas de diseo correspondientes, ste tambin debera
encargarse de esos subsistemas.

Calidad en WF de Anlisis: Gracias que el PUD es dirigido por CU, podemos garantizar la calidad a travs de la trazabilidad
entre los distintos modelos. Otro aspecto que la asegura es el que los mensajes (en el diag. de colaboracin) tengan el mismo
nombre de la operacin a la que invocan y la aplicacin de patrones.
A nivel de paquetes se asegura la calidad cuando vemos que son altamente cohesivos y dbilmente acoplados.

Diagramas:
Diagrama de Comunicacin:
Concepto: Diagrama que permite ver la organizacin de los objetos y conocer las interacciones a travs del paso de mensajes entre
ellos realizando una determinada funcionalidad dentro de una realizacin.
Clasificacin:
-Modela comportamiento
-Vista Dinmica
-Objetos
-Interna
-Lgica
Elementos:
-Objetos-Roles
-Enlaces
-Mensajes: nro.argumentomsg(param)->
-Notas
-Marco: Encabezado (tipo y nombre diagrama)
Pautas de construccin:
-Dentro de un caso de uso, tengo tantos diagramas de comunicacin como escenarios haya.
-En cada diagrama de comunicacin es aconsejable identificar un objeto de control.
-A la hora de llamar a otros C-U es mejor que lo haga la clase de control para reducir el acoplamiento.
-En una seleccin, previamente se pide algo.
-Cuando no trabajo con una iteracin, apunto a un objeto especifico, sin tener que nombrarlo.
Tipos de mensajes:
Sncronos: Esperan que el objeto reacciones o de respuesta.

Diagrama de Clases:
Concepto: muestra un conjunto de clases, interfaces, colaboraciones y sus relaciones. Modela la vista esttica del sistema, es decir,
modela estructura.
Clasificacin:
-Modela estructura
-Vista Esttica
-Trabaja con clases
-Interna
-Lgica
Elementos:
-Clases
-Relaciones (Asociacin, Dependencia, Agregacin, Generalizacin, Composicin)
-Nota
-Existen distintas formas de mostrar la estructura. La forma ms simple es en Clases, sino en paquetes.

Diagrama de Estado:
Concepto: Modela el ciclo de vida de un objeto. Muestra como pasa de un estado a otro ante la ocurrencia de un evento. Muestra la
reaccin del objeto. Modela una Mquina de Estado.
Clasificacin:
-Modela aspectos Dinmicos
-Modela Comportamiento
-Trabaja a nivel de Objetos
-Vista Interna
-Vista Lgica
Elementos:
-Estado: Condicin o situacin del objeto
-Evento: Acontecimiento, con tiempo y espacio, que provoca el cambio de estado.
-Transicin: Relacin entre un estado y otro a partir de un evento.
-Acciones: Reaccin que realiza el objeto frente a un evento.
-Condicin de guarda
-Nota
-Conviene utilizar un diagrama de estado cuando nos encontramos con estados significativos.
Como y para qu usamos la informacin aportada por el diagrama de estado:
-Refinamos diagrama de clase de anlisis. Agregamos comportamiento.
-Refinamos a nivel de C-U, para ver si existen C-U que soportan estos cambios de estado.

Diagrama de Secuencia:
Concepto: Diagrama de interaccin que muestra la secuencia temporal de los mensajes entre los objetos.
Clasificacin:
-Modela Vista Dinmica
-Modela Comportamiento
-Trabaja a nivel de Objetos
-Vista Interna
-Vista Lgica
Elementos:
-Objetos o roles
-Lnea de vida
-Caja de activacin o foco de control
-Mensaje: 1.msg(param):retorno
-Notas
-Tipo de operaciones
De llamada
De seal
De retorno
De creacin
De destruccin
Tipos de Acciones de Diagramas de Interaccin
-De llamada: Sncrona. Este tipo de accin es el nico que se utiliza en los diagramas de comunicacin.
-De seal: Asncrona. No espera respuesta. Activa mquinas de estado.
-De retorno
-De creacin
-De destruccin.
En el diagrama de secuencia se usan todas.
Activacin: son rectngulos largos y estrechos en la lnea de vida para indica cundo esa lnea tiene el foco de control.
Documentar diagramas de secuencia: en un diagrama de secuencia se pueden agregar scripts al situar notas debajo de la parte
izquierda. Esto hace que el diagrama sea mucho ms accesible a los grupos de decisin no tcnicos, como usuarios o expertos del
negocio. Son importantes especialmente si el diagrama es complejo.
Fragmentos combinados y operadores: todo fragmento combinado tiene un operador, uno o ms operandos y cero o ms
condiciones de proteccin. El operador determina cmo se ejecutan sus operandos. Las condiciones de proteccin son expresiones
booleanas, y el operando se ejecuta si y solo si la expresin es evaluada como verdadera.

Operadores
- opt: indica opcin. Existe solo un operando que se ejecuta si la condicin es verdadera. (Semejante a la estructura if)
- alt: indica alternativas. Se ejecuta el operando cuya condicin es verdadera. (Semejante a Switch-case)
- loop: indica bucle. Se utiliza con la intencin de representar lo que en los diagramas de comunicacin se representa con *
- break: indica condicin de corte.
- ref: indica referencia. El fragmento combinado hace referencia a otra interaccin (puede usarse por ej, en cuestiones comunes a
varios casos de uso, como la accin de validar usuario)
- par: indica paralelismo. Todos los operandos se ejecutan en paralelo. (En simultneo)
- critical: indica acciones crticas que no deben interrumpirse.
- seq: Secuencia Debil
- Strict: Secuencia estricta
- neg: negativa
- ignore: ignorar
- consider: considerar
- assert: asercin

Comparacin entre los diagramas
Aspecto Diagrama de Comunicacin
Diagrama de Secuencia Diagrama de Estado
Qu Entradas
Requiere?
Caso de Uso
MODP
Caso de Uso
Diagrama de Comunicacin
Diagrama de Clase de Anlisis
Caso de Uso
Que nos permite
refinar?
Diagrama de Clases de Diseo Diagrama de Caso de Uso
Que resalta Estructura de Datos
Trabaja la cronologa de mensajes Comportamiento dirigido por
eventos
Elementos que
posee
Objetos o roles, Mensajes, y
enlaces
Objetos o roles, Lnea de vida, Caja de
activacin, Mensajes, Operaciones.
Estados, Eventos, Transiciones,
Acciones, Condicin de guarda

Visualizacin
Debo buscar en los mensajes,
pero ocupa menos espacio.
Podemos observar rpidamente la
creacin, destruccin, y el tipo de
operaciones. Menos prctico. Se
extiende hacia abajo y a la derecha.

En que vista se utiliza Vista de diseo
Se suele utilizar en la vista de Caso de
Uso.
Vista de diseo
Vista de diseo
Permiten Ingeniera
directa e inversa?
Permiten
Isomorfismo
Isomrficos: Puedo ir de uno al otro. Manejan los mismos conceptos pero
presentan distinta informacin.

Vista Vista Interna, y Dinmica
Tipo de Diagrama De Interaccin y Comportamiento
Flujo de Trabajo de Diseo
Propsito General: Modelar el sistema y encontrar su forma, incluyendo la arquitectura para dar soporte a todos los requisitos. Por
forma entendemos la estructura. La arquitectura toca lo ms crtico de esa estructura y tambin se encarga del comportamiento.
Modelar el sistema: Antes la prioridad no era el sistema entero, lo descomponamos, ahora se lo comienza a ver como un
todo. Importa el sistema completo.
Propsitos Especficos:
-Comprender con mayor profundidad los requisitos no funcionales y las restricciones (limitaciones sobre la tecnologa a usar
y la forma de desarrollar)
-Preparar una entrada apropiada para la implementacin.
-Dividir el trabajo en partes ms manejables para asignar trabajo a distintos grupos de desarrollo para que trabajen en
forma concurrente.
-Identificar interfaces de los distintos subsistemas.
-Reflexionar sobre el diseo a partir de una notacin comn. (Agrega mayor formalidad. Simbologa para cada tecnologa)
-Crear una abstraccin sin costura de la implementacin del sistema. Por abstraccin sin costura entendemos que existe
una Relacin de 1 a 1 entre los elementos del diseo y la implementacin.
Rol del diseo en el ciclo de vida del SW:
El diseo es el centro de atencin al final de la fase de elaboracin y al comienzo de las iteraciones de construccin. Esto contribuye
a una arquitectura slida y estable y a crear un plano del modelo de implementacin.
Fase de Inicio:
-Se esboza el modelo de despliegue con nodos crticos.
-Prototipacin de la interfaz.
-Se esboza el modelo del diseo en torno a los aspectos crticos.
Fase Elaboracin:
-Intento de distribuir los componentes en cada uno de los nodos
-Trabajo con modelo de diseo y de despliegue
-Se define la cantidad de capas del modelo arquitectnico.
-Esbozo completo del modelo de despliegue.
-Asignacin de subsistemas de diseo a nodos.
-Modelo de diseo completo.
Fase de Construccin:
-Disear elementos que completan al sistema.
-A nivel arquitectura se define todos lo relacionado a cambios que impacten en la misma.
-Todo el 90% restante.
Fase de transicin:
-Pruebas lnea de base de la arquitectura.

Vista Esttica del flujo de trabajo de diseo:

Vista dinmica del flujo de trabajo de diseo:

Modelo de Anlisis
Descripcin de la arquitectura
(vista Anlisis)
Diagrama de clases del anlisis
(MODSolucin)
Modelo C-U
Requisitos Especiales
Disear la arquitectura
(Arquitecto)
Disear los CU (Ing en C-U)
Disear clases de diseo (Ing.
En Componentes)
Disear subsistemas (Ing. En
Componentes)
Modelo de Diseo
Diagrama de clases de diseo
Subsistemas de diseo
Interfaces
Realizaciones de CU de diseo:
Requisitos de Implementacin
Descripcin de la arquitectura (Vista del modelo de diseo
y del modelo de despliegue) Vista del modelo de proceso
Modelo de despliegue (Esbozo)
Modelo de Proceso

Influencia del diseo en la implementacin:
-Los subsistemas de diseo y los subsistemas de servicio sern implementados mediante subsistemas de implementacin que
contienen los verdaderos componentes.
-Las clases de diseo se implementarn mediante componentes de fichero que contendrn el cdigo fuente. Las clases activas del
diseo que representan procesos con un hilo de control se utilizarn como entrada a la hora de identificar los componentes
ejecutables.
-Las realizaciones de caso de uso de diseo se utilizarn al planificar y llevar a cabo el esfuerzo de implementacin en pasos
pequeos y manejables. Que dan como resultado construcciones. Cada construccin implementar un conjunto de realizaciones de
caso de uso o parte de ellos.
Subsistemas y sus interfaces.

Actividades:
Diseo de la arquitectura: El objetivo del diseo de la arquitectura es esbozar los modelos de diseo y despliegue y su arquitectura
mediante la identificacin de los siguientes elementos:
Nodos y sus configuraciones de red.

Clases del diseo significativas para la arquitectura, como las clases activas.
Mecanismos de diseo genricos que tratan los requisitos comunes, como los requisitos especiales sobre persistencia, distribucin,
rendimiento y dems, tal y como se capturaron durante el anlisis sobre las clases y las realizaciones de caso de uso-anlisis.
Diseo de un caso de uso: Los objetivos del diseo de un caso de uso son:
- Identificar las clases del diseo y/o los subsistemas cuyas instancias son necesarias para llevar a cabo el flujo de sucesos del caso de
uso.
- Distribuir el comportamiento del caso de uso entre los objetos del diseo que interactan y/o entre los subsistemas participantes.
- Definir los requisitos sobre las operaciones de las clases del diseo y/o sobre los subsistemas y sus interfaces.
- Capturar los requisitos de implementacin del caso de uso.
Diseo de una clase
Esbozar la clase del diseo
- Disear clases de interfaz es dependiente de la tecnologa de interfaz especfica que se utilice.
- Disear clases de entidad que representen informacin persistente (o clases que tienen otros requisitos persistentes) a menudo
implica el uso de tecnologas de BD especficas.
- Disear clases de control es una tarea delicada. Debido a que encapsulan secuencias, coordinacin de otros objetos o algunas
veces pura lgica del negocio
Diseo de un subsistema:
Los objetivos del diseo de un subsistema son:
- Garantizar que el subsistema es tan independiente como sea posible de otros subsistemas y/o de sus interfaces.
- Garantizar que el subsistema proporciona las interfaces correctas.
- Garantizar que el subsistema cumple su propsito de ofrecer una realizacin correcta de las operaciones tal y como se definen en
las interfaces que proporciona.

Diferencias Modelo de C-U, Modelo de Anlisis y Modelo de Diseo

Otras Preguntas:
1) Cmo refinar la estructura a partir del flujo de requisitos?
Para refinar la estructura, trabajo a 2 niveles. En un nivel abstracto, a partir de los Casos de Uso obtenidos del flujo de requisitos,
paso a un paquete de anlisis en el anlisis, y luego a subsistemas de diseo en el flujo de diseo.
A un nivel de bloque ms bsico (Clases), a partir del MODP, paso a las clases de anlisis, interfaz y control en el flujo de anlisis, y
luego al diagrama de clase de diseo.
En el MODP defino nicamente el atributo y el comportamiento de la clase, y tiene una relacin directa con el dominio, en el flujo de
anlisis especifico el tipo de atributo, las responsabilidades y las relaciones (nivel conceptual), y en el flujo de diseo especifico el
tipo de dato del atributo, la visibilidad del atributo, se definen los mtodos con parmetros, tipo de parmetro, retornos, tipo de
retorno y visibilidad del mtodo y en algunos casos se incluye un pseudocdigo. En cuanto a las relaciones especifico la
navegabilidad, multiplicidad, rol, y el tipo de relacin en el flujo de diseo.
2) Como varan los artefactos de acuerdo al Flujo de Trabajo
Flujo de Anlisis 1 a 5 Flujo de Diseo 1 a 1 Flujo de Implementacin
Estructura
Paquete Subsistemas (2 primeras capas)
Otros Subsistemas
Subsistemas de Implementacin
Clase de Anlisis Clases de Diseo
Interfaces
Otras Clases de Diseo

Componentes
Comport. Realizacin C-U Anlisis Realizacin C-U Diseo Planificar las construcciones
Descripcin de la
Arquitectura (Vista Modelo
de Anlisis)
Descripcin de la Arquitectura (Vista modelo de
diseo, despliegue y procesos)
Modelo de Despliegue (Se empieza a crear)
Descripcin de la Arquitectura (Vista modelo
de implementacin y despliegue)
Modelo de despliegue (se termina)

Modelo C-U Modelo de Anlisis Modelo de Diseo
Modelo Conceptual (Basado en el
negocio sobre el que se va a
implementar)
Modelo Conceptual (Abstraccin del sistema) Modelo Fsico (Plantea una
implementacin particular definiendo
tecnologa)
Modelo genrico que especifica la
vista externa del sistema y sirve de
contrato con el cliente
Modelo genrico que especifica como debera
ser implementado el sistema pero sin estar
atado a detalles de implementacin. Vista
interna del sistema.
Modelo especifico del sistema, que
especifica una forma de implementarlo.
Vista interna del sistema.
Entidades 3 estereotipos: Control, Entidad e Interfaz Cualquier cantidad de estereotipos
Descripto en el lenguaje del cliente.
Menos formalidad
Mayor Formalidad que el Modelo de C-U.
Lenguaje del desarrollador
Mayor Formalidad que el Modelo de
Anlisis. Utiliza construcciones propias de
la tecnologa a utilizar
- Menos caro de desarrollar (Relacin 1 a 5 con
el diseo)
Ms caro de desarrollar
No hay capas Menos capas, basadas en estereotipos de
clases
Ms capas basadas en la implementacin
del sistema
Esttico Dinmico (no muy centrado en la secuencia) Dinmico (muy centrado en la secuencia)
Modela funcionalidad del sistema Bosquejo del diseo del sistema Manifiesto del diseo del sistema
Mantenido toda la vida del proyecto Puede no estar mantenido luego de la
segunda iteracin de la fase de desarrollo.
Debe ser mantenido
Estructurado por Casos de Uso Estructurado por clases y paquetes
estereotipados;
Estructurado por subsistemas y clases de
diseo.
Puede tener redundancia e
inconsistencias
No puede tener redundancias ni
inconsistencias
Completamente consistente. Sin
redundancia
Modelo esencial para todo desarrollo
del sistema ya que especifica que se
debe hacer
Entrada esencial para modelar al sistema,
incluyendo la creacin del modelo de diseo
Da forma al sistema mientras preserva la
estructura base dada por el anlisis
Disear la estructura
Concepto: disear cmo va a estar organizado el sistema en trminos de componentes y relaciones (componente como
bloque de construccin). Qu partes van a componer el sistema y cmo se van a relacionar-
Organizar: identificar elementos de la estructura y como se relacionan.
Niveles de estructuracin: el sistema se estructura
- A nivel de clases de diseo nivel de Sw
- A nivel de subsistemas Aspecto funcional
- A nivel del modelo de despliegue Nivel de Hw (tecnologas de comunicacin) y Sw.
Actividad principal: Disear la arquitectura Arquitecto
Salida: Descripcin de la arquitectura
Vista del modelo de diseo
Vista del modelo de despliegue
Otras actividades que complementan:
Disear Clase.
Disear Subsistema

Disear el Comportamiento
Concepto: Disear como acta y reacciona el sistema en trminos de objetos. Diseamos como va a estar dada la
colaboracin entre los objetos a travs del paso de mensajes.
Actividad principal: Disear un C-U Ing en C-U
Salida: Realizacin de C-U de diseo

Artefactos
Modelo de diseo: El modelo de diseo es un modelo de objetos que describe la realizacin fsica de los casos de uso
centrndose en cmo los requisitos funcionales y no funcionales, junto con otras restricciones relacionadas con el
entorno de implementacin, tienen impacto en el sistema a considerar.
El modelo de diseo se representa por un sistema de diseo compuesto por subsistemas interrelacionados mediante
interfaces, se define una jerarqua de subsistemas para organizar el modelo en porciones ms manejables.
Los subsistemas de diseo y clases del diseo representan abstracciones del subsistema y componentes de la
implementacin del sistema y poseen una correspondencia directa entre el diseo y la implementacin.

Clase de diseo: Una clase de diseo es una abstraccin sin costuras de una clase o construccin similar en la
implementacin del sistema:
- El lenguaje utilizado para especificar una clase del diseo es el mismo que el lenguaje de programacin.
- A diferencia de las clases de anlisis, en las clases de diseo se especifican la visibilidad, tipo de datos y largo de los
atributos
- Las relaciones de aquellas clases del diseo implicadas con otras clases, a menudo tienen un significado directo cuando
la clase es implementada.
- Los mtodos de una clase del diseo tienen correspondencia directa con el correspondiente mtodo en la
implementacin de las clases. Si los mtodos se especifican en el diseo, se suelen especificar en lenguaje natural, o en
pseudocdigo, y por eso pueden ser utilizados como comentarios en las implementaciones del mtodo.
- Una clase de diseo suele aparecer como un estereotipo que se corresponde con una construccin en el lenguaje de
programacin.
- Una clase de diseo puede realizar y proporcionar interfaces.
- Una clase de diseo puede activarse, aunque no estn normalmente activas.

Realizacin de caso de uso-diseo: Una realizacin de caso de uso-diseo es una colaboracin en el modelo de
diseo que describe cmo se realiza un caso de uso especfico, y cmo se ejecuta, en trminos de clases de diseo y sus
objetivos. Una realizacin de caso de uso-diseo proporciona una traza directa a una realizacin de caso de uso-anlisis.
Una realizacin de caso de uso-diseo proporciona una realizacin fsica de una realizacin de caso de uso-anlisis para
la que es trazada, y tambin gestiona muchos requisitos no funcionales (es decir, requisitos especiales) capturados de la
realizacin de caso de uso-anlisis. Podemos posponer algunos requisitos hasta las actividades de implementacin.
Una realizacin de caso de uso-diseo compuesta por:
- Flujo de sucesos (explicacin y descripcin textual).
- Diagramas de clases (parcial)
- Diagramas de interaccin (especficamente Diagrama de secuencia: tiene como propsito mostrar cmo se da el
paso de mensajes entre una sociedad de objetos a lo largo del tiempo).
- Subsistemas asociados a los objetos de la sociedad con sus interfaces y relaciones.
- Requerimientos de implementacin.
Elementos de un diagrama de secuencia:
- Objetos: actor, gestor, mltiple instancia, objeto concreto
- Mensajes: mensaje(parmetro:tipoParametro):retorno:tipoRetorno
- Lnea de vida
- Notas
Subsistema de diseo: Los subsistemas de diseo son una forma de organizar los artefactos del modelo de diseo en
piezas ms manejables. Un subsistema puede constar de clases del diseo, realizaciones de caso de uso, interfaces y
otros subsistemas, un subsistema puede proporcionar interfaces que representan la funcionalidad que exportan en
trminos de operaciones.
Un subsistema debera ser cohesivo; es decir, sus contenidos deberan encontrarse fuertemente asociados. Adems, los
subsistemas deberan ser dbilmente acoplados; esto es, sus dependencias entre unos y otros, o entre sus interfaces,
deberan ser mnimas.
Podemos encontrar subsistemas de servicio, que se basan en los paquetes de servicio del modelo de anlisis, pero tratan
ms aspectos que sus correspondientes paquetes de servicio.
Interfaz: Las interfaces se utilizan para especificar las operaciones que proporcionan las clases y los subsistemas del
diseo.
Una clase del diseo que proporcione una interfaz debe proporcionar tambin mtodos que realicen las operaciones de
la interfaz. Las interfaces constituyen una forma de separar la especificacin de la funcionalidad en trminos de
operaciones de sus implementaciones en trminos de mtodos. La mayora de las interfaces se consideran relevantes
para la arquitectura, debido a que definen las interacciones entre subsistemas.
Descripcin de la arquitectura (vista del modelo de diseo): La descripcin de la arquitectura contiene una vista de
la arquitectura del modelo de diseo, que muestra sus artefactos relevantes para la arquitectura.
Suelen considerarse significativos para la arquitectura los siguientes artefactos del modelo de diseo:
- La descomposicin del modelo de diseo en subsistemas, sus interfaces, y las dependencias entre ellos. Esta
descomposicin es muy significativa para la arquitectura en general, debido a que los subsistemas y sus interfaces
constituyen la estructura fundamental del sistema.
- Clases del diseo fundamentales, como clases que poseen una traza con clases del anlisis significativas, clases activas,
y clases del diseo que sean generales y centrales, que representan mecanismos de diseo genricos, y que tengan
muchas relaciones con otras clases del diseo. Basta con considerar significativas para la arquitectura a las clases
abstractas, y no a sus subclases, a menos que las subclases representen algn comportamiento interesante y
significativo para la arquitectura diferente al de la clase abstracta.
- Realizaciones de caso de uso-diseo que describan alguna funcionalidad importante y crtica que debe desarrollarse
pronto dentro del ciclo de vida del software, que impliquen muchas clases del diseo y por tanto tengan una cobertura
amplia, posiblemente a lo largo de varios subsistemas, o que impliquen clases del diseo fundamentales.
Modelo de despliegue: El modelo de despliegue es un modelo de objetos que describe la distribucin fsica del
sistema en trminos de cmo se distribuye la funcionalidad entre los nodos de cmputo.
Podemos observar lo siguiente sobre el modelo de despliegue:
- Cada nodo representa un recurso de cmputo, normalmente un procesador o un dispositivo hardware similar.
- Los nodos poseen relaciones que representan medios de comunicacin entre ellos, tales como Internet, intranet, bus, y
similares.
- El modelo de despliegue puede describir diferentes configuraciones de red, incluidas las configuraciones para pruebas
y para simulacin.
- La funcionalidad (los procesos) de un nodo se definen por los componentes que se distribuyen sobre ese nodo.
- El modelo de despliegue en s mismo representa una correspondencia entre la arquitectura software y la arquitectura
del sistema (hardware).
Descripcin de la arquitectura (vista del modelo de despliegue): La descripcin de la arquitectura contiene una vista
de la arquitectura del modelo de despliegue, que muestra sus artefactos relevantes para la arquitectura.

Trabajadores
Arquitecto: En el diseo el arquitecto es el responsable de la arquitectura y de la integridad de los modelos de diseo
y de despliegue, garantizando que los modelos son correctos, consistentes y legibles en su totalidad.
Los modelos son correctos cuando realizan la funcionalidad, y slo la funcionalidad, descrita en el modelo de casos de
uso, en los requisitos adicionales, y en el modelo de anlisis.
El arquitecto no es responsable del desarrollo y mantenimiento continuos de los distintos artefactos del modelo de
diseo. Estos se encuentran bajo la responsabilidad de los correspondientes ingenieros de casos de uso y de
componentes.
Ingeniero de casos de uso: El ingeniero de casos de uso es responsable de la integridad de una o ms realizaciones de
casos de uso-diseo, y debe garantizar que cumplen los requisitos que se esperan de ellos. Una realizacin de caso de
uso-diseo debe realizar correctamente el comportamiento de su correspondiente realizacin de caso de uso-anlisis
del modelo de anlisis, as como el comportamiento de su correspondiente caso de uso del modelo de casos de uso, y
slo esos comportamientos.
El ingeniero de casos de uso no es responsable de las clases, subsistemas, interfaces y relaciones de diseo que se
utilizan en la realizacin del caso de uso. stas son responsabilidad del correspondiente ingeniero de componentes.
Ingeniero de componentes: El ingeniero de componentes define y mantiene las operaciones, mtodos, atributos,
relaciones y requisitos de implementacin de una o ms clases del diseo, garantizando que cada clase del diseo
cumple los requisitos que se esperan de ella segn las realizaciones de caso de uso en las que participa.

Flujo de Trabajo
Los arquitectos inician la creacin de los modelos de diseo y de despliegue. Ellos esbozan los nodos del modelo de
despliegue, los subsistemas principales y sus interfaces, las clases del diseo importantes como las activas, y los
mecanismos genricos de diseo del modelo de diseo. Despus, los ingenieros de casos de uso realizan cada caso de
uso en trminos de clases y/o subsistemas del diseo participantes y sus interfaces. Las realizaciones de caso de uso
resultantes establecen los requisitos de comportamiento para cada clase o subsistema que participe en alguna
realizacin de caso de uso. Los ingenieros de componentes especifican a continuacin los requisitos, y los integran
dentro de cada clase. A lo largo del flujo de trabajo del diseo, los desarrolladores identificarn, a medida que
evolucione el diseo, nuevos candidatos para ser subsistemas, interfaces, clases y mecanismos de diseo genricos, y los
ingenieros de componentes debern refinarlos y mantenerlos.

Actividades
Diseo de la arquitectura: El objetivo del diseo de la arquitectura es esbozar los modelos de diseo y despliegue y
su arquitectura mediante la identificacin de los siguientes elementos:
- Nodos y sus configuraciones de red.
- Subsistemas y sus interfaces.
- Clases del diseo significativas para la arquitectura, como las clases activas.
- Mecanismos de diseo genricos que tratan los requisitos comunes, como los requisitos especiales sobre persistencia,
distribucin, rendimiento y dems, tal y como se capturaron durante el anlisis sobre las clases y las realizaciones de
caso de uso-anlisis.

A lo largo de esta actividad los arquitectos consideran las distintas posibilidades de reutilizacin, adems mantiene y
refina las vistas arquitectnicas.

Identificacin de nodos y configuraciones de red: las configuraciones de red habituales utilizan un patrn de tres capas
en el cual los clientes (las interacciones de los usuarios) se dejan en una capa, la funcionalidad de base de datos en otra,
y la lgica del negocio o de la aplicacin en una tercera.

Identificacin de subsistemas y de sus interfaces: Pueden ser identificados al inicio o bien a medida que el sistema va
creciendo. Por otro lado identificamos subsistemas de las capas especficas y general de la aplicacin, as como tambin
subsistemas intermedios y de software del sistema. Deberan definirse dependencias entre subsistemas si sus
contenidos estn relacionados. Si utilizamos interfaces entre subsistemas, las dependencias van hacia las interfaces, no
hacia los subsistemas. Las interfaces definen operaciones que son accesibles desde afuera del subsistema. *ver en el
libro 223-231.

Identificacin de clases del diseo relevantes para la arquitectura: evitar identificar demasiadas clases en esta etapa,
solo se necesita un esbozo de clases significativas par la arquitectura. Algunas clases del diseo pueden ser el resultado
de un esbozo con clases del anlisis.

Identificacin de mecanismos genricos de diseo: se estudian los requisitos comunes y cmo tratarlos, teniendo en
cuenta las tecnologas de diseo e implementacin disponibles.
Diseo de un caso de uso: Los objetivos del diseo de un caso de uso son:
- Identificar las clases del diseo y/o los subsistemas cuyas instancias son necesarias para llevar a cabo el flujo de
sucesos del caso de uso.
- Distribuir el comportamiento del caso de uso entre los objetos del diseo que interactan y/o entre los subsistemas
participantes.
- Definir los requisitos sobre las operaciones de las clases del diseo y/o sobre los subsistemas y sus interfaces.
- Capturar los requisitos de implementacin del caso de uso.

Identificacin de clases del diseo participantes:
- Estudiar las clases del anlisis que participan en la correspondiente realizacin de caso de uso-anlisis. Identificar las
clases del diseo que poseen una traza hacia esas clases del anlisis, creadas por el ingeniero de componentes en el
diseo de clases o por el arquitecto en el diseo arquitectnico.
- Estudiar los requisitos especiales de la correspondiente realizacin de caso de uso-anlisis. Identificar las clases del
diseo que realizan esos requisitos especiales.
- Identificar clases necesarias y asignar su responsabilidad a un ingeniero de componentes.
- Si an falta alguna clase del diseo, el ingeniero de CU debe avisar de dicha situacin a los arquitectos y a los
ingenieros de componentes.

Descripcin de las interacciones entre objetos del diseo:
Debemos describir cmo interactan los objetos del diseo. Esto se logra mediante diagramas de secuencia que
contienen las instancias de los actores, los objetos del diseo y las transmisiones de mensajes entre stos. Para crear el
diagrama de secuencia, debemos seguir paso a paso desde el inicio el flujo del CU, decidiendo qu objetos y qu
interacciones son necesarias para realizar el CU. Suele ser til crear uno por cada subflujo distinto.

Identificacin de subsistemas e interfaces participantes:
Algunas veces es mejor disear un CU en trminos de los subsistemas y/o interfaces. Debemos identificar los
subsistemas necesarios para realizar el CU.

Descripcin de interacciones entre subsistemas:
Se realiza mediante diagramas de secuencia que contiene instancias actores, subsistemas y transmisiones de mensajes.
Las lneas de vida denotan ahora subsistemas en lugar de objetos.

Captura de requisitos de implementacin:
Aqu incluimos todos los requisitos que deben tratarse durante la implementacin.

Diseo de una clase
Esbozar la clase del diseo
- Disear clases de interfaz es dependiente de la tecnologa de interfaz especfica que se utilice.
- Disear clases de entidad que representen informacin persistente (o clases que tienen otros requisitos persistentes) a
menudo implica el uso de tecnologas de BD especficas.
- Disear clases de control es una tarea delicada. Debido a que encapsulan secuencias, coordinacin de otros objetos o
algunas veces pura lgica del negocio, es necesario considerar los siguientes aspectos:
o Aspectos de distribucin: si la secuencia necesita ser distribuida y manejada por diferentes nodos de una red, se
puede requerir separar las clases del diseo en diferentes nodos para realizar la clase de control.
o Aspectos de rendimiento: puede que no sea justificable tener clases del diseo separadas para realizar la clase
de control. En cambio, la clase de control podra realizarse por las mismas clases del diseo que estn realizando
algunas clases de interfaz o clases de entidad relacionadas.
o Aspectos de transaccin: las clases de control a menudo encapsulan transacciones. Sus correspondientes
diseos deben incorporar cualquier tecnologa de manejo de transaccin existente que se est utilizando.

Identificar Operaciones:
Identificamos las operaciones que las clases de diseo van a necesitar y las describimos utilizando la sintaxis de los
lenguajes de programacin.

Identificar Atributos:
Identificamos los atributos que las clases de diseo van a necesitar y los describimos utilizando la sintaxis de los
lenguajes de programacin.

- Considerar los atributos sobre cualquier clase de anlisis.
- Los tipos de los atributos estn restringidos por el lenguaje de programacin.
- Intentar reutilizar tipos de atributos.

Identificar asociaciones y agregaciones:
Se estudia la transmisin de mensajes en los diag. de secuencia para determinar que asociaciones son necesarias. El
numero de relaciones entre clases debe estar minimizado.
- Considerar las asociaciones y agregaciones involucrando la correspondiente clase de anlisis (o clases). Algunas veces
estas relaciones (en el modelo de anlisis) implican la necesidad de una o varias relaciones correspondientes (en el
modelo de diseo) que involucre la clases de diseo.
- Refinar la multiplicidad de las asociaciones, nombres de rol, cales de asociacin, roles de ordenacin, roles de
cualificacin y asociaciones n-arias de acuerdo con el soporte del lenguaje de programacin utilizado.
- Refinar la navegabilidad de las operaciones. La direccin de las transmisiones de mensajes entre objetos se debe
corresponder con la navegabilidad de las asociaciones entre sus clases.

Identificar las generalizaciones:
Las generalizaciones deben ser usadas con la misma semntica definida en el lenguaje de programacin. Si el lenguaje
no admite generalizacin, usar asociacin y/o agregacin.

Describir los mtodos:
Los mtodos se usan en el diseo para especificar cmo se deben realizar las operaciones. Los describimos utilizando
lenguaje natural o pseudocdigo.

Describir estados:
Es importante el uso de diagramas de estado para describir las transiciones de estado de un objeto del diseo. Algunos
objetos, de acuerdo a su estado, cambian su comportamiento al recibir un mensaje.
Tratar requisitos especiales:
Ac se trata a cualquier requisito no considerado anteriormente. De ser posible, utilizar los mecanismos de diseo
identificados por el arquitecto. Se pueden posponer algunos requisitos para ser tratados en la implementacin.

Diseo de un subsistema:
Los objetivos del diseo de un subsistema son:
- Garantizar que el subsistema es tan independiente como sea posible de otros subsistemas y/o de sus interfaces.
- Garantizar que el subsistema proporciona las interfaces correctas.
- Garantizar que el subsistema cumple su propsito de ofrecer una realizacin correcta de las operaciones tal y como se
definen en las interfaces que proporciona.
Mantenimiento de las dependencias entre subsistemas: Es mejor ser dependiente de una interfaz que serlo de un
subsistema, ya que un subsistema podra ser sustituido por otro que posea un diseo interno distinto, mientras que en
ese mismo caso, no estaramos obligados a sustituir la interfaz. (No interesa cmo un subsistema lleva a cabo las
colaboraciones para dar soporte a una interfaz, siempre y cuando lo haga correctamente).
Mantenimiento de interfaces proporcionadas por el subsistema: Las operaciones definidas por las interfaces que
proporciona un subsistema deben soportar todos los roles que cumple el subsistema en las diferentes realizaciones de
caso de uso.
Mantenimiento de los contenidos de los subsistemas: Un subsistema cumple sus objetivos cuando ofrece una realizacin
correcta de las operaciones tal y como estn descritas por las interfaces que proporciona.
Tener en cuenta que:
- Por cada interfaz que proporcione el subsistema, debera haber clases del diseo u otros subsistemas dentro del
subsistema que tambin proporcionen la interfaz.
- Para clarificar cmo el diseo interno de un subsistema realiza cualquiera de sus interfaces o casos de uso, podemos
crear colaboraciones en trminos de los elementos contenidos en el subsistema. Podemos hacer esto para justificar los
elementos contenidos en el subsistema.

Calidad en el diseo
- El PUD plantea un modelo implcito que permite la trazabilidad de requisitos
- Mientras ms patrones apliquemos mayor ser la calidad, logrando modelos altamente cohesivos y dbilmente
acoplados
- Utilizando abstracciones: interfaces, subsistemas, clases de diseo
- A travs de las verificaciones:
o Que los mensajes de los diagramas de secuencia y estado tengan la misma asignatura que la operacin
o Que la clase a la cual se le realiza el DTE posea el atributo estado

Requerimientos
Concepto: Servicios que presta el sistema, y restricciones a nivel operativo.
Especificacin de requerimientos: Que es lo que hace y no hace el sistema de informacin. Que desarrollar y que no.
Fuente: +Pedido del cliente: El cliente formula lo que quiere.
+ Relevamiento: Estudio del contexto del sistema. Indagar causas de problemas
+ Especificacin previa
Caractersticas: - Validez: asegurarnos de que lo que nos plantea el usuario sea real, vlido y necesario para el sistema
- Consistencia: que no haya ambigedades (utilizando la trazabilidad)
- Completitud: que en la manera de describirlo est comprendido todo lo que implica
- Realismo: que se pueda implementar mediante las tecnologas existentes.
- Verificabilidad: Comprobar que el sistema planteado realmente hace lo que dice la documentacin.
Clasificacin
+ Del usuario: planteados de manera general, con lenguaje comn, sin especificar detalles. Pueden ser ambiguos o
inconsistentes.
+ Del sistema: Especificacin detallada de los servicios y las restricciones. Se necesita este nivel de refinamiento para el
desarrollo
Otra clasificacin (Ms utilizada):
- Del dominio: pueden ser RF y RNF que tienen que ver con la naturaleza del negocio.
- Funcionales: definen lo que hace y lo que no hace el sistema. Estn plasmados en el modelo de CU y en el diagrama de
clases.
- No funcionales: estn plasmados en los requerimientos adicionales del FT Requerimientos, en los requerimientos
especiales del FT Anlisis y en los requerimientos de implementacin del FT Implementacin. Pueden ser:

Del producto
- Fiabilidad: funciona sin errores
- Usabilidad: forma que se usa el sistema. Son verificables. Pensar en capacitacin a los usuarios, ayudas que va a tener el
sistema (en lnea, emergentes)
- Portabilidad: plataforma donde se va a ejecutar y la posibilidad de migrar a otra.
- Eficiencia: logro de objetivos optimizando los recursos
+ Rendimiento: desempeo en el mejor tiempo y la mejor manera
+ Espacio: capacidad de memoria, velocidad del procesador
Organizacionales: de la empresa, a nivel del grupo de desarrollo
- Implementacin: Construir con un lenguaje especfico, restricciones que puede tener
- Entrega: qu vamos a necesitar a nivel de Hw y de Sw. Establecer el momento de entrega
- Estndares: colores, logos, ubicacin
Externos: conexin con otros sistemas.
- Interoperabilidad: lo que hay que tener en cuenta para lograr la conexin.
- Legales: actividades regidas por la ley, por ejemplo la ley de facturacin. Apuntan a cuidar la informacin.
tica profesional privacidad
Seguridad: protege la forma en que se accede y guarda la informacin en el sistema. Restringir el acceso y el uso.

DISEO ARQUITECTNICO
Proceso de diseo inicial que establece un marco para el control y comunicacin de los componentes, buscando satisfacer todos los
RQs, produciendo la descripcin de la arquitectura.
Se toman decisiones acerca de: estilos arquitectnicos a usar, distribucin del sistema, identificacin de mdulos, estrategias de
control, evaluacin y documentacin.
Un estilo arquitectnico es un patrn de organizacin del sistema. Incluye elegir la arquitectura adecuada, descomponer en
mdulos, identificar los componentes y su agrupacin en subsistemas, decidir cmo se controlar la ejecucin del sistema modelo
de control.
Ventajas:
Punto de discusin con stakeholders;
Anlisis del sistema;
Reutilizacin de SW a gran escala en procedimientos similares;
Gestin de la complejidad generando abstracciones claves.
Resultado > documento de diseo arquitectnico que incluye:
-Modelo estructural esttico que muestre los subsistemas o componentes que han sido desarrollados como unidades separadas.
-Modelo de procesos dinmico que muestre cmo se organiza el sistema en procesos en tiempo de ejecucin.
-Modelo de interfaz que defina los servicios ofrecidos por cada subsistema a travs de su interfaz pblica.
-Modelos de relaciones que muestren las relaciones entre los subsistemas
-Modelo de distribucin que muestre cmo se distribuyen los subsistemas entre las computadoras.

Descripcin del proceso de Arquitectura
Arquitectura: conjunto de decisiones significativas
acerca de la organizacin de un sistema de software,
la seleccin de los elementos estructurales que
componen el sistema y las interfaces entre ellos,
junto con su comportamiento que se especifica en
las colaboraciones entre esos elementos, la
composicin de estos elementos estructurales y de
comportamiento en subsistemas progresivamente
mayores y el estilo arquitectnico que gua la
organizacin. Se incluyen las restricciones y
compromisos de uso, funcionalidad,
funcionamiento, flexibilidad al cambio, reutilizacin,
comprensin, economa, y tecnologa, as como
aspectos estticos.
Requerimientos Arquitectnicos: Requerimientos que afectan a la arquitectura. Deben ser priorizados.
Elegir el framework de la arquitectura: Buscar un modelo arquitectnico que encaje en el proyecto. Debemos aplicar los
patrones arquitectnicos: n tier client / server messaging publish-subscribe Broker Process Cordinator
Distribuir Componentes: El component es el resultado fsico del proceso de desarrollo. Puede ser reutilizado.
-Definir Componentes
-Comunicacin entre componentes:
Identificar componentes crticos
Como se insertan dentro del framework de la arquitectura
Identificar interfaces
Definir responsabilidad de los componentes
Determinar dependencias entre componentes
Sistemas distribuidos -> Particin de componentes.

Requerimientos no funcionales considerados crticos para la Arquitectura
Rendimiento: implica la eficiencia, es decir realizar el objetivo con el uso mnimo de recursos. Sommerville indica que se deben
generar componentes de grano grueso, para minimizar las interacciones entre subsistemas ante operaciones crticas.
Proteccin: se relaciona con la capacidad del sistema para resistir ataques externos que pueden haber sido creados de alguna
manera no prevista por los desarrolladores y logran vencer la proteccin incorporada. Es la valoracin de la probabilidad de que el
sistema pueda resistir intrusiones accidentales o premeditadas. Sommerville plantea colocar los recursos ms crticos en capas
inferiores del sistema, para dificultar el acceso a los mismos por caminos no vlidos.
Seguridad autorizacin para el acceso de recursos desde un punto de vista interno al sistema. Sommerville propone generar un
sistema centralizado de seguridad, que maneje los mecanismos de seguridad en todo el sistema.
Disponibilidad: la disponibilidad de un sistema es la probabilidad de que est activo y en funcionamiento y sea capaz de
proporcionar servicios tiles en cualquier momento. Sommerville plantea el uso de redundancia en los componentes crticos del
sistema.
Mantenibilidad: medida que se usan los sistemas, surgen nuevos requerimientos. Es importante mantener la utilidad de un sistema
cambindolo para adaptarlo a estos nuevos requerimientos. Un software mantenible es un software que puede adaptarse para
tener en cuenta los nuevos requerimientos con un coste razonable y con una baja probabilidad de introducir nuevos errores en el
sistema al realizar los cambios correspondientes. Sommerville plantea el uso de una granularidad ms fina, donde los componentes
son independientes entre s.

*Granularidad: Grado de refinamiento ejemplo que pasa de grano grueso a grano fino: antes tombamos el estado de una clase
como un atributo. Luego pasamos a separarlo en una clase aparte. El paso siguiente es tomar una estructura de clases para dar
soporte a los estados
2. Cul es el conflicto que se plantea? Cul es el lineamiento de la solucin?
Se presenta conflicto entre el rendimiento y los otros requerimientos.
Rendimiento-mantenibilidad: el uso de componentes de grano grueso mejora el rendimiento, mientras que el
uso de componentes de grano fino mejora la mantenibilidad. La solucin ms adecuada sera encontrar un punto
intermedio, lo cual puede lograrse usando diferentes estilos arquitectnicos para diferentes partes del sistema.
Rendimiento-disponibilidad: manejar la redundancia de datos de la disponibilidad
Rendimiento-proteccin: con el fin de mejorar la proteccin, debera usarse una arquitectura estructurada en
capas, con los recursos ms crticos protegidos en las capas ms internas. Pero esto se convierte en un inconveniente
para el rendimiento, ya que si hay muchas capas, un servicio solicitado desde la capa superior puede tener que ser
interpretado varias veces en diferentes capas antes de ser procesado. Para evitar este problema, las aplicaciones tienen
que comunicarse directamente con las capas interiores en lugar de usar los servicios proporcionados por las capas
adyacentes.
Rendimiento-seguridad

Vistas arquitectnicas
Modelo: representacin de la realidad completa del sistema
Vista: proyeccin del sistema contemplando un aspecto en particular
Punto de vista: descripcin de una vista.
Existen 3 clasificaciones para las vistas
1) - De Funcionalidad: se plasma a travs del modelo de CU (al usuario se muestra el diagrama sin relaciones de
inclusin, extensin o generalizacin). Muestra los CU esenciales o crticos mediante
- De Diseo: muestra clases y relaciones entre clases.
- De Despliegue:
A nivel de Hardware: muestra la distribucin del sistema y caractersticas computacionales
A nivel de SW y Componentes: muestra componentes y sus relaciones. Muestra nodos y esbozo de
componentes en ellos.
2) (Segn UML) vistas a travs de diagramas: - De estructura
- De comportamiento
3) (Segn UML) vistas a nivel de la arquitectura
Se pueden agregar vistas de seguridad o de datos y se pueden quitar vistas segn
el tipo de software.

*Cul es la vista que emplea diagramas de clases con clases activas?: vista de procesos
Validacin de la arquitectura:
Tcnicas: + validar a travs de los escenarios (RNF): es manual
+ validar usando prototipos del sistema (versiones de prueba): permite pruebas a nivel conceptual o a
nivel tecnolgico.

Organizacin del sistema
Refleja la estrategia bsica usada para estructurar el sistema. Se basa en decisiones tomadas al comienzo del diseo arquitectnico.
1) El modelo de repositorio
Todos los datos se almacenan en una base de datos central a la que se puede acceder desde todos los subsistemas. Contrapuesto al
modelo en que cada subsistema mantiene su propia BD y los datos se intercambian con el paso de mensajes.
Ventajas:
Eficiente para compartir grandes cantidades de datos;
Los subsistemas que producen datos no necesitan saber cmo estos sern usados luego.
Las actividades de seguridad estn centralizadas.
Desventajas:
La evolucin puede ser difcil si se necesita cambiar el modelo de datos;
Impone la misma poltica para todos los subsistemas; puede complicarse la integracin de nuevos subsistemas que no
compartan el mismo modelo.
Difcil distribucin sobre varios equipos.

2) Modelo clienteservidor
La aplicacin se modela como un conjunto de servicios y servidores asociados, ms clientes que acceden para usar esos servicios y
una red que permite el acceso mediante llamadas a procedimientos remotos usando un protocolo de peticinrespuesta.
Los servidores no necesitan conocer la identidad de los clientes ni su nmero. El cliente por su lado es simplemente una interfaz de
usuario integrada con esos servicios y construida con un navegador Web; necesita conocer servidores disponibles pero ignora la
existencia de otros clientes.
Ventajas:
Fcil de distribuir;
Fcil de ampliar o actualizar;
No requiere igual modelo de datos.
Desventajas:
Puede provocar problemas de rendimiento;
Limita la flexibilidad del diseo.

3) Modelo de capas
Sistema organizado en capas, cada una de las cuales proporciona un conjunto de servicios. La ms comn es la estructura de tres
capas: la de presentacin de la informacin al usuario y dems interacciones con l, la de procesamiento de la aplicacin y la capa
de gestin de datos relacionada con la BD.
Ventajas:
Soporta desarrollo incremental;
Es portable y evoluciona fcilmente;
Al cambiar las interfaces de una capa slo se afecta la capa adyacente;
Fcil proporcionar implementaciones multiplataforma.
Desventajas:
La estructuracin de los sistemas puede resultar difcil;
Problemas de rendimiento al requerirse mltiples niveles de interpretacin de comandos.

Descomposicin modular
Un mdulo es normalmente un componente de un subsistema que proporciona y utiliza servicios a otros mdulos. A diferencia de
los subsistemas, no se consideran independientes. Al tener componentes ms pequeos, permite usar estilos alternativos de
descomposicin.
Estrategias al descomponer un subsistema en mdulos:

Descomposicin orientada a objetos: se descompone en un conjunto de objetos dbilmente acoplados que se comunican; los
mdulos son objetos con estado privado y operaciones interfaces definidas.
Ventaja:
Implementacin independiente que al modificarse no afecta otros objetos;
Fcilmente comprensible;
Reutilizacin de objetos;
Desventajas:
Un cambio en la interfaz de un objeto afecta a los dems objetos que la utilizan;
Difcil de representar como objetos entidades complejas.
Descomposicin orientada a flujos de funciones: descomposicin en mdulos funcionales que aceptan datos y los transforman en
datos de salida. Las transformaciones pueden ejecutarse secuencialmente o en paralelo y los datos pueden ser procesados de a uno
o en lote.
Ventajas:
Reutilizable;
Intuitivo;
El sistema evoluciona en forma directa aadiendo nuevas transformaciones;
Sencillo de implementar.
Desventajas:
Difcil de describir;
Menos abstracto;
Exige formato comn para transferir datos;
Incrementa sobrecarga del sistema.

Estilos de control
Control de subsistemas > entrega de servicios en el lugar y momento correctos.
Modelos de control:
Centralizado: Un subsistema tiene toda la responsabilidad para controlar, iniciar y detener a otros subsistemas. Tipos:
Modelo de llamadaretorno: Jerarqua descendente de subrutinas que pasan el control a niveles inferiores; aplicable a
sistemas secuenciales. De naturaleza rgida y restrictiva. Ventajas: Simple de analizar; Desventaja: Las excepciones se
vuelven tediosas de manejar.
Modelo del gestor: Un componente se disea como un gestor del sistema y controla el inicio, parada y coordinacin del
resto de los procesos del sistema mediante la verificacin de variables de estado; para sistemas concurrentes de tiempo
real.

Basado en eventos: Cada subsistema puede responder a eventos generados externamente, fuera de su control. Tipos:
Modelo de transmisin (broadcast): Un evento se transmite a todos los subsistemas. Ventaja: De evolucin simple;
Desventaja: Los subsistemas no conocen si los eventos se manejarn o cundo.
Modelo dirigido por interrupciones: Las interrupciones son detectadas por un manejador que las enva a algn otro
componente especfico para procesarlas. Se aplica a entornos en tiempo real. Eficaz para integrar subsistemas distribuidos.
Soporta comunicaciones punto a punto mensajes explcitos de un subsistema a otro. Ventaja: Respuestas rpidas;
Desventajas: Difcil de programar, validar y cambiar si est limitado por el HW.

Arquitecturas de dominios especfios
Arquitectura de dominio especfico de aplicacin:
Modelos genricos: A partir de varios sistemas reales. Encapsulan caractersticas bsicas. Sirven para reutilizarse directamente.
Modelas de referencia: Son ms abstractos y describen una clase ms amplia de sistemas. Arquitectura ideal que incluye todas las
caractersticas que los sistemas podran incorporar. Sirven para comunicar conceptos de dominio y comparar o evaluar.

4) Arquitecturas distribuidas
Un sistema distribuido es aquel en el que el procesamiento de informacin se distribuye sobre varias computadoras.
Ventaja:
Comparticin de recursos;
Apertura > diseados sobre protocolos estndar;
Concurrencia;
Escalabilidad > incrementar capacidad del sistema aadiendo nuevos recursos;
Tolerancia a defectos (fallos de HW y SW cadas);
Los componentes pueden implementarse en diferentes lenguajes, tipos de procesadores, con diferentes protocolos de
comunicacin.
Desventajas:
Complejidad > Requiere SW para controlar las diferentes partes middleware;
Seguridad > Escuchas indeseadas, integridad de datos;
Mantenibilidad > Propagacin de defectos de una mquina a otra;
Impredecibilidad > Respuesta depende de carga total del sistema, organizacin y carga de red.

Modelos aplicables:
Arquitecturas multiprocesador: El sistema SW se divide en procesos ejecutables en procesadores diferentes. Comn en grandes
sistemas de tiempo real.
Arquitecturas clienteservidor: Aplicacin del modelo clienteservidor explicado anteriormente para un sistema de varias
computadoras.
El modelo ms simple es el de dos capas, un uno o mltiples servidores idnticos y un conjunto de clientes. Puede ser:
Modelo de cliente ligero: Todo el procesamiento y gestin de datos se lleva a cabo en el servidor. Desventaja: elevada
carga de procesamiento en el servidor y la red.
Modelo de cliente rico: El servidor es responsable slo de la gestin de datos. Ventaja: distribuye procesamiento.
Desventaja: de gestin compleja.
Existe una variante multicapa en la que se aaden al sistema servidores adicionales para permitir acceso a diferentes BD. Un
servidor de integracin recoge los datos distribuidos y los presenta a la aplicacin. Son sistemas ms escalables.

Arquitecturas de objetos distribuidos: Los componentes son objetos con interfaces definidas que proporcionan servicios. Otros
objetos hacen llamadas a esos servicios sin distinciones lgicas entre clientes y servidores. Los objetos se distribuyen a travs de
computadoras en red y se comunican por medio del middleware, que proporciona una interfaz "transparente".
Ventajas:
Permite retrasar decisiones sobre cmo y dnde se deberan proporcionar los servicios;
Arquitectura abierta, permite aadir fcilmente nuevos recursos;
Sistema flexible y escalable;
Es posible reconfigurar el sistema en forma dinmica.
La nica desventaja es que son ms complejas de implementar.

CORBA: es un estndar que permite que diversos componentes de software escritos en mltiples lenguajes de programacin y que
corren en diferentes computadoras, puedan trabajar juntos; es decir, facilita el desarrollo de aplicaciones distribuidas en entornos
heterogneos. Es un conjunto de estndares para middleware.

4) Computacin distribuida interorganizacional
Arquitecturas peertopeer
Sistemas descentralizados en los que los clculos pueden llevarse a cabo en cualquier nodo de la red, sin hacer distincin entre
clientes y servidores. Ventaja: potencia computacional y disponibilidad de almacenamiento a travs de una red de computadoras
potencialmente enorme.
Para aplicaciones cooperativas que soportan trabajo distribuido.
Los nodos no slo son elementos funcionales sino que adems son interruptores de comunicaciones que pueden encaminar datos y
seales de control de un nodo a otro.
Ventajas: Altamente redundante > tolerante a defectos y nodos desconectados.
Desventaja: Sobrecargas de sistema.

Arquitectura de sistemas orientados a servicios
Tiene el propsito de hacer accesible la informacin a otros programas definiendo y publicando una interfaz de servicio Web. La
provisin del servicio es independiente de la aplicacin que utiliza el servicio.
Diferencias con arquitectura de objetos distribuidos:
Los servicios pueden ofertarse por cualquier proveedor de servicio dentro o fuera de una organizacin;
Informacin pblica para cualquier usuario;
Las aplicaciones pueden retrasar el enlace de los servicios hasta que estn en ejecucin;
Construccin de nuevos servicios enlazando viejos;
Las aplicaciones pueden hacerse ms pequeas, reactivas y adaptar su operacin de acuerdo con su entorno;
Estn dbilmente acopladas y el enlace a los servicios puede cambiar durante la ejecucin.

Flujo de Trabajo de Implementacin

Propsito General: Implementar la arquitectura y el sistema como un todo a nivel de componente.
-Se planifican las construcciones que se van a llevar a cabo en cada iteracin. (al final de cada iteracin hay una construc).
-Implementar todo el sistema incluida la arquitectura en componentes. Asignamos componentes a nodos.
-Implementamos clases y subsistemas de diseo.
Clases ->Componentes. Subsistemas -> Subs de Implementacin (Relacin 1 a 1)
-Se hacen pruebas de unidad a los componenetes (nos adelantamos al flujo de prueba)

Rol de la implementacin dentro del ciclo de vida del SW
El flujo de trabajo de implementacin, trabaja ms que nada en la ltima parte de la fase de elaboracin, gran parte en la
fase de construccin y un poco en la primera parte de la transicin.
Elaboracin: Implementacin lnea base ejecutable de la arquitectura.
Construccin: La implementacin es el centro de esta fase. Se llevan a cabo las distintas construcciones.
Transicin: Implementaciones que surgen a partir de la correccin de errores.

Vista Esttica del flujo de trabajo de implementacin:
Vista dinmica del flujo de trabajo de implementacin:
Modelo de CU
Modelo de Diseo
Modelo de Despliegue (esbozo)
Diseo, Vista Despliegue)
Implementacin de la Arquitectura
Integrar el Sistema
Implementar un Subsistema
Implementar una Clase
Realizar pruebas de unidad
Modelo de Implementacin
Componentes
Plan de integracin
Subs de Implementacin
Modelo de despliegue
Mod de despliegue e implementacin)

Artefacto: Es una parte fsica y reemplazable de un sistema que existe a nivel de la plataforma de implementacin. Grficamente un
artefacto se representa como un rectngulo con la palabra clave <<artifact>>
Artefacto de despliguege: Son los artefactos necesarios y suficientes para formar un sistema ejecutable.
Artefactos producto del trabajo: Productos que quedan al final del proceso de desarrollo. Se utilizan para crear el sistema
ejecutable (cdigos de fuente, archivos de datos, etc) a partir de los cuales se crean los Artefactos de despliegue.
Artefactos de ejecucin: Se crean como consecuencia de un sistema en ejecucin.
Stub: Esqueleto de un componenete. Se utiliza para agilizar construcciones.

Artefactos
Modelo de implementacin: Describe como los elementos del diseo, como las clases, se implementan en trminos de
componentes, como ficheros de cdigo fuente, ejecutables, etc. Tambin cmo se organizan los componentes de acuerdo con los
mecanismos de estructuracin y modularizacin disponibles en el entorno de implementacin y en el lenguaje de programacin
utilizados, y cmo dependen los componentes unos de otros.
Componente: Un componente es el empaquetamiento fsico de los elementos de un modelo, como son clases del modelo de
diseo.
Los componentes tienen las siguientes caractersticas:

Los componentes tienen relaciones de traza con los elementos del modelo que implementan.
Es normal que un componente implemente varios elementos, por ejemplo, varias clases.
Los componentes proporcionan las mismas interfaces que los elementos del modelo que implementan.
Puede haber dependencias de compilacin entre componentes, denotando qu componentes son necesarios para compilar un
componente determinado.
Stubs: es un componente que puede ser utilizado minimizar el nmero de componentes nuevos necesarios en cada nueva versin
(intermedia) del sistema, simplificando as los problemas de integracin y las pruebas de integracin. Favorece la reutilizacin.
Subsistema de implementacin: Deberan seguir la traza uno a uno de sus subsistemas de diseo correspondientes.

El subsistema de implementacin debera definir dependencias anlogas hacia otros subsistemas de implementacin o interfaces.
El subsistema de implementacin debera proporcionar las mismas interfaces.
El subsistema de implementacin debera definir qu componentes o, recursivamente, qu subsistemas de implementacin dentro
del subsistema deberan proporcionar las interfaces proporcionadas por el subsistema. Adems, estos componentes contenidos
deberan seguir la traza de las clases correspondientes en el subsistema de diseo que implementan.
Interfaz: Un componente que implementa una interfaz ha de implementar correctamente todas las operaciones definidas por la
interfaz. Un subsistema de implementacin que proporciona una interfaz tiene tambin que contener componentes que
proporcionen la interfaz y otros subsistemas que proporcionen la interfaz.
Descripcin de la arquitectura (vista del modelo de implementacin):
La descripcin de la arquitectura contiene una vista del modelo de implementacin, el cual representa sus artefactos significativos
arquitectnicamente.
Los siguientes artefactos son considerados en el modelo de implementacin significativos arquitectnicamente:

La descomposicin del modelo de implementacin en subsistemas, sus interfaces y las dependencias entre ellos.
Componentes claves, como los componentes que siguen la traza de las clases de diseo significativas arquitectnicamente, los
componentes ejecutables y los componentes que son generales, centrales, que implementan mecanismos de diseo genricos de
los que dependen muchos otros componentes.
Plan de Integracin de Construcciones: Es importante construir el software incrementalmente en pasos manejables, de forma que
cada paso d lugar a pequeos problemas de integracin o prueba. El resultado de cada paso es llamado construccin, que es una
versin ejecutable del sistema, usualmente una parte especfica del sistema. Cada construccin es entonces sometida a pruebas de
integracin antes de que se cree ninguna otra construccin.
La integracin incremental es para la integracin del sistema lo que el desarrollo iterativo controlado es para el desarrollo de
software en general. Ambos se centran en un incremento bastante pequeo y manejable de la funcionalidad.
Un plan de integracin de construcciones describe la secuencia de construcciones necesarias en una iteracin. Describe lo siguiente
para cada construccin:

La funcionalidad que se espera que sea implementada en dicha construccin. Consiste en una lista de casa de uso o escenarios o
parte de ellos, como se discuti en captulos anteriores. Esta lista puede tambin referirse a otros requisitos adicionales.
Las partes del modelo de implementacin que estn afectadas por la construccin.

Trabajadores
Arquitecto: es responsable de la integridad del modelo de implementacin y asegura que el modelo como un todo es correcto,
competo y legible.
El modelo es correcto cuando implementa la funcionalidad descrita en el modelo de diseo y en los requisitos adicionales, y slo
esta funcionalidad.
Un resultado importante de la implementacin es la asignacin de componentes ejecutables a nodos. El arquitecto es responsable
de esta asignacin, la cual se representa en la vista de la arquitectura del modelo de despliegue.
Ingeniero de componentes: Define y mantiene el cdigo fuente de uno o varios componentes, garantizando que cada
componente implementa la funcionalidad correcta.
El ingeniero de componentes necesita garantizar que los contenidos de los subsistemas de implementacin son correctos, que sus
dependencias son otros subsistemas o interfaces son correctas y que implementan correctamente las interfaces que proporcionan.
Integrador de sistemas: Tiene como responsabilidad planificar la secuencia de construcciones necesarias en cada iteracin y la
integracin de cada construccin cuando sus partes han sido implementadas.

Flujo de Trabajo
Este proceso es iniciado por el arquitecto esbozando los componentes clave en el modelo de implementacin. A
continuacin, el integrador de sistemas planea las integraciones de sistema necesarias en la presente iteracin como una secuencia
de construcciones. Para cada construccin el integrador de sistemas describe la funcionalidad que debera ser implementada y qu
partes del modelo de implementacin se vern afectadas. Los requisitos sobre los subsistemas y componentes en la construccin
son entonces implementados por ingenieros de componentes. Los componentes resultantes son probados y pasados al integrador
de sistemas para su integracin. Entonces, el integrador de sistemas integra los nuevos componentes en una construccin y la pasa a
los ingenieros de pruebas de integracin para llevar a cabo pruebas de integracin. Luego, los desarrolladores inician la
implementacin de la siguiente construccin, tomando en consideracin los defectos de la construccin anterior.
Implementacin de la arquitectura:
El propsito de la implementacin de la arquitectura es esbozar el modelo de implementacin y su arquitectura mediante:

La identificacin de componentes significativos arquitectnicamente, tales como componentes ejecutables.
La asignacin de componentes a los nodos en las configuraciones de redes relevantes.

El mayor reto durante la implementacin es crear dentro de los subsistemas de implementacin los componentes que implementen
los subsistemas de diseo correspondientes.
La asignacin de componentes a nodos es muy importante para la arquitectura del sistema, y debera ser representada en una vista
de la arquitectura del modelo de despliegue.
Integrar el sistema:
Los objetivos de la integracin del sistema son:
Crear un plan de integracin de construcciones que describa las construcciones necesarias en una iteracin y los requisitos de cada
construccin.
Integrar cada construccin antes de que sea sometida a pruebas de integracin.

Planificacin de una construccin: Se debe tener en cuenta los siguientes criterios:

1. Una construccin debera aadir funcionalidad a la construccin previa implementando casos de uso completos o escenarios de
stos. Las pruebas de integracin de la construccin estarn basadas en estos casos de uso y escenarios; es ms fcil probar
casos de uso completos que fragmentos de stos.
2. Una construccin no debera incluir demasiados componentes nuevos o refinados. Si no es as, puede ser muy difcil integrar la
construccin y llevar a cabo las pruebas de integracin. Si fuera necesario algunos componentes pueden implementarse como
stubs para minimizar el nmero de nuevos componentes introducidos en la construccin.
3. Una construccin debera estar basada en la construccin anterior, y debera expandirse hacia arriba y hacia los lados de la
jerarqua de subsistemas. Esto significa que la construccin inicial debera empezar en las capas inferiores; las construcciones
subsiguientes se expanden entonces haba arriba a las capas general de la aplicacin y especfica de aplicacin. La razn
fundamental de esto es simplemente que es difcil implementar componentes en las capas superiores antes de que estn
colocados y funcionando adecuadamente los componentes necesarios en las capas inferiores.

Manteniendo estos criterios en mente, uno puede empezar a evaluar los requisitos, tales como los casos de uso, que han de ser
implementados.
En cualquier caso, es importante identificar los requisitos apropiados a implementar en una construccin y dejar el resto de los
requisitos para construcciones futuras.
Implementar un subsistema:
El propsito de implementar un subsistema es el de asegurar que un subsistema cumple su papel en cada construccin, tal y como
se especifica en el plan de integracin de la construccin.

Mantenimiento de los contenidos de los subsistemas: Un subsistema cumple su propsito cuando los requisitos a ser
implementados en la construccin actual y aqullos que afectan al subsistema estn implementados correctamente por los
componentes dentro del subsistema.
Implementar una clase:
El propsito de la implementacin de una clase es implementar una clase de diseo en una componente fichero. Esto incluye lo
siguiente:

Esbozo de los componentes de fichero: Es decir, especificar el componente fichero y considerar su mbito. Los componentes
fichero elegidos deberan facilitar la compilacin, instalacin y mantenimiento del sistema.
Generacin de cdigo a partir de las clases de diseo
Implementacin de operaciones: Incluye la eleccin de un algoritmo y unas estructuras de datos apropiadas de las acciones
requeridas por el algoritmo. Los estados descritos para la clase de diseo pueden influenciar el modo en que son implementadas
las operaciones, ya que sus estados determinan su comportamiento cuando sta recibe un mensaje.
Comprobar si los componentes ofrecen las interfaces apropiadas
Realizar prueba de unidad:
El propsito de realizar la prueba de unidad es probar los componentes implementados como unidades individuales. Se llevan a
cabo los siguientes tipos de prueba de unidad:

La prueba de especificacin, o prueba de caja negra, que verifica el comportamiento de la unidad observable externamente.
La prueba de estructura, o prueba de caja blanca, que verifica la implementacin interna de la unidad.

Tambin se realizan pruebas sobre las unidades, como pruebas de rendimiento, utilizacin de memoria, carga y capacidad. Adems,
se realizan pruebas de integracin y sistema para asegurar que los diversos componentes se comportan correctamente cuando se
integran.

Realizacin de pruebas de especificacin: Se realiza para verificar el comportamiento del componente sin tener en cuenta cmo se
implementa dicho comportamiento en el componente.
Realizacin de prueba de estructura: El ingeniero de componentes debera asegurarse de probar todo el cdigo durante las pruebas
de estructura, lo que quiere decir que cada sentencia ha de ser ejecutada al menos una vez.

Flujo de Trabajo de Prueba

Propsito General: Probar en todos los niveles todo lo que se ha diseodo e implementado. Probar las construcciones que hemos
llevado a cabo en el flujo anterior.
-Planificar las pruebas a nivel de sistema y planificar las pruebas de integracin del sistema.
-Disear los casos de prueba, los procedimientos de prueba y definir que componentes se van a automatizar.
-Ejecutar las diferentes pruebas y evaluar los resultados y tomar medidas en relacin a los resultados.
Rol de la prueba dentro del ciclo de vida del SW
Inicio: Se planifican las pruebas.
Elaboracin: Pruebas de la lnea base de la arquitectura.
Construccin: Centro de la actividad. Pruebas a las construcciones.
Transicin: Pruebas de regresin y aceptacin.
Vista Esttica del flujo de trabajo de prueba:
Vista dinmica del flujo de trabajo de prueba:
Modelo de CU
Modelo de Diseo
Modelo de implementacin
Modelo de Despliegue
Descripcin de la arquitectura (Todas
las vistas)
Planificar Prueba
Disear Prueba
Implementar Prueba
Realizar pruebas de integracin
Realizar pruebas de Sistema
Evaluar Pruebas
Modelo de Prueba
C-U de prueba
Procedimientos de prueba
Componentes de prueba
Plan de prueba
Evaluacin de prueba
Defectos

Artefactos
Modelo de pruebas: Describe cmo se prueban los componentes ejecutables (como construcciones) en el modelo de
implementacin con pruebas de integracin y de sistema.
El modelo de pruebas es una coleccin de casos de prueba, procedimientos de prueba y componentes de prueba. Si el modelo es
grande puede introducirse paquetes para manejar su tamao.
Caso de prueba: Un caso de prueba especfica una forma de probar el sistema, incluyendo la entrada o resultado con la que se ha
de probar y las condiciones bajo las que ha de probarse.
Los siguientes son casos de prueba comunes:
- Un caso de prueba que especifica cmo probar un caso de uso o un escenario especfico de un caso de uso. Especifica una prueba
del sistema como caja negra, es decir, una prueba del comportamiento observable externamente del sistema.
- Un caso de prueba que especifica cmo probar una realizacin de caso de uso-diseo o un escenario especfico de la realizacin.
Especifican una prueba del sistema como una caja blanca, es decir, una prueba de interaccin interna entre los componentes del
sistema.
Procedimiento de prueba: Especifica cmo realizar uno o varios casos de pruebas o partes de stos. Se puede reutilizar un
procedimiento de prueba para varios casos de prueba, as como tambin reutilizar varios procedimientos de prueba para un caso de
prueba.
Componente de prueba: Automatiza uno o varios procedimientos de prueba o partes de ellos.
Los componentes de prueba pueden ser desarrollados utilizando un lenguaje de guiones o un lenguaje de programacin, o pueden
ser grabados con una herramienta de automatizacin de pruebas.
Los componentes de prueba se utilizan para probar los componentes en el modelo de implementacin, proporcionando entradas de
prueba, controlando y monitorizando la ejecucin de los componentes a probar e informando de los resultados de pruebas.
Plan de Pruebas: describe las estrategias, recursos y planificacin de la prueba.
Defecto: Un defecto es una anomala del sistema, como por ejemplo un sntoma de un fallo software o un problema descubierto
en una revisin.
Evaluacin de prueba: Es una evaluacin de los resultados de los esfuerzos de prueba, tales como la cobertura del caso de
prueba, la cobertura de cdigo y el estado de los defectos.

Trabajadores
Diseador de pruebas: es el responsable de la integridad del modelo de pruebas, asegurando que cumpla con su propsito.
Tambin planea las pruebas (deciden los objetivos apropiados y la planificacin de las pruebas). Adems, seleccionan y describen los
casos de pruebas y los procedimientos de prueba necesarios y son los responsables de la evaluacin de las pruebas de integracin y
de sistema cuando estas se ejecutan. O sea que no lleva a cabo las pruebas, sino que las preparan y las evalan.
Ingeniero de Componentes: son responsables de los componentes de prueba que automatizan algunos de los procedimientos de
prueba.
Ingeniero de pruebas de integracin: son responsables de realizar las pruebas de integracin que se necesitan para cada
construccin producida en el workflow de implementacin. Estas pruebas de integracin se realizan para verificar que los
componentes integrados en una construccin funcionan correctamente juntos. Tambin documenta los defectos en los resultados
de las pruebas de integracin.
Ingeniero de pruebas de sistema: es responsable de realizar las pruebas de sistema necesarias sobre una construccin que
muestra el resultado de una iteracin completa. Estas pruebas de sistema se llevan a cabo principalmente para verificar las
interacciones entre los actores y el sistema, por ello, se derivan a menudo de los casos de prueba que especifican cmo probar los
CU.
El ingeniero de pruebas de sistema se encarga de documentar los defectos en los resultados de las pruebas de sistema.

Flujo de Trabajo
Los ingenieros de pruebas inician esta tarea planificando el esfuerzo de prueba en cada iteracin, y describen entonces los casos de
prueba necesarios y los procedimientos de prueba correspondientes para llevarlos a cabo. Si es posible, los ingenieros de
componentes crean a continuacin los componentes de prueba para automatizar algunos de los procedimientos de prueba. Todo
esto se hace para cada construccin entregada como resultado del flujo de trabajo de implementacin.
Con estos casos, procedimientos y componentes de prueba como entrada, los ingenieros de pruebas de integracin, y de sistema
prueba cada construccin y detectan cualquier defecto que encuentren en ellos. Los defectos sirven como realimentacin tanto para
otros flujos de trabajo, como el de diseo y el de implementacin, como para los ingenieros de pruebas para que lleven a cabo una
evaluacin sistemtica de los resultados de las pruebas.

Planificar Prueba:
Se planifican los esfuerzos de prueba en una iteracin llevando a cabo estas tareas:
- Describir una estrategia de prueba.
- Estimar los requisitos para el esfuerzo de la prueba.
- Planificar el esfuerzo de la prueba.
Ningn sistema puede ser probado completamente; por tanto, se debera identificar los casos, procedimientos y componentes de
prueba con un mayor retorno a la inversin en trminos de mejora de calidad.
Disear prueba:
- Identificar y describir los casos de prueba.
- Identificar y estructurar los procedimientos de prueba

Diseo de los casos de prueba de integracin: estos casos de prueba se usan para verificar que los componentes interaccionan
entre s de la manera correcta. Se consideran como entrada los diagramas de interaccin de las realizaciones de CU.
Diseo de los casos de prueba de sistema: las pruebas de sistema se usan para probar que el sistema funciona correctamente
como un todo. Se prueban combinaciones de CU instanciados bajo condiciones diferentes.
Diseo de los casos de prueba de regresin: Algunos casos de prueba de construcciones anteriores pueden ser usados para
pruebas de regresin en construcciones subsiguientes.
Identificacin y estructuracin de los procedimientos de prueba: se intentan reutilizar procedimientos de prueba existentes
tanto como sea posible

Implementar una prueba: Se refiere a automatizar los procedimientos de prueba creando componentes de prueba si fuera
posible.
Realizar pruebas de integracin: Se realizan las pruebas de integracin necesarias para cada una de las construcciones creadas en
una iteracin, se recopilan los resultados de las pruebas y se informa a los ingenieros de componentes y a los diseadores de
pruebas los defectos encontrados.
Realizar prueba del sistema: Se realizan las pruebas del sistema necesarias para cada una de las construcciones creadas en una
iteracin y se recopilan los resultados de las pruebas.
Evaluar una prueba: Su propsito es evaluar los esfuerzos de las pruebas en una iteracin. Los diseadores de pruebas evalan
los resultados de la prueba comparando los resultados obtenidos con los esbozados en el plan de la prueba. Metricas: % de casos de
prueba completados y la fiabilidad del sistema.

*Tipos de Tests (Pruebas)
Test de Operacin: Es el ms comn. El sistema es probado en operacin normal.
Tests de Escala completa: Se ejecuta el sistema al mximo: valores mximos, muchos equipos conectados, muchos usuarios, etc.
Tests de Performance o de capacidad: Mide la capacidad de procesamiento del sistema.
Tests de Sobrecarga: determina cmo se comporta el sistema cuando es sobrecargado.
Tests Negativos: El sistema se usa intencionalmente de forma incorrecta. Se prueban casos especiales.
Tests basados en requerimientos: Se rastrean directamente desde la especificacin de requerimientos.
Tests Ergonmicos: Son importantes si el sistemas ser usado por gente inexperta.
Tests de Documentacin del Usuario: Se prueba la documentacin del sistema.
Tests de Aceptacin: Es ejecutado por la organizacin que solicita el sistema.

Prueba alfa: se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como
observador del usuario y registrando los errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado.
Prueba beta: se llevan a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba
alfa, el desarrollador no est presente normalmente. As, la prueba beta es una aplicacin en vivo del software en un entorno que no
puede ser controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta e informa a
intervalos regulares al desarrollador.
Prueba Piloto: Se prueba una parte del sistema.

Validacin: Estamos construyendo el sistema correcto? El sistema satisface los requerimientos del usuario?
Verificacin: Estamos construyendo correctamente el producto? El producto lleva a cabo lo especificado?

Niveles de Prueba
Pruebas de Unidad: Es el nivel de prueba ms bajo. Involucra: clases, bloques, paquetes de servicio, procedimientos y subrutinas.
Consiste de:
- Prueba de especificacin o Caja Negra: verifican el comportamiento de la interfaz de la unidad. Es importante ver si se produce una
salida, y si es la correcta.
- Prueba estructural o de caja blanca: Se verifica que la estructura interna se la correcta. Es preferible hacer esta prueba al ltimo.
- Prueba basada en estados: Prueba la interaccin entre las operaciones de una clase, monitoreando los cambios que tienen lugar en
los atributos de los objetos. Basarse en los diagramas de transicin de estados. Se puede utilizar una matriz de estados, en donde
tenemos los estados como columnas y los estmulos en las filas. Se debe verificar que todos los estados se pueden alcanzar con
alguna combinacin de operaciones, en caso contrario hay alguna falla en el diseo de la clase.
Pruebas de Integracin: Involucra: CU. Determinan si las unidades desarrolladas trabajan correctamente juntas. Se realizan varias
de estas pruebas a distintos niveles. Estas pruebas son necesarias porque al combinar las unidades pueden aparecer nuevas fallas, y
porque la combinacin aumenta el nmero de caminos posibles. Estas pruebas se realizan probando los CU, desde dos puntos de
vista: uno interno (basado en diagramas de interaccin) y uno externo (basado en las descripciones del modelo de requerimientos).
Para un CU se hacen las siguientes pruebas:
- Pruebas del curso bsico (curso normal).
- Pruebas de cursos alternativos.
- Pruebas de documentacin de usuarios.

Prueba de Sistema: se prueba el sistema completo. Se divide en:
- Pruebas de instalacin: verifican que el sistema puede ser instalado en la plataforma del cliente y que funcionara correctamente.
- Pruebas de configuracin: verifican que el sistema funciona correctamente en diferentes configuraciones(ej:de red)
- Pruebas negativas: intentan provocar que el sistema falle y as mostrar sus debilidades.
- Pruebas de estrs: identifican problemas con el sistema cuando hay recursos insuficientes.

*Estrategias de Prueba
Lo ms comn es realizar las estrategias de prueba en el orden inverso al que se realiza el diseo y la implementacin. Podemos ir
realizando pruebas conforme vamos terminando los diseos, es decir la implantacin y la prueba se realizan en forma intercalada e
incremental. Hay varias maneras:
Top-Down: Primero desarrollamos las interfaces entre subsistemas y luego se reemplaza con el cdigo real, esto permite probar
el flujo completo en niveles superiores en primer lugar, y en segundo lugar ir a niveles inferiores.
Botton-Up: Es preferible este modo en los niveles ms bajos. Minimiza las necesidades de implementar clases piloto slo para
pruebas, ya que las unidades certificadas trabajan como servidores.

Flujo de Trabajo de Despliegue

Propsito General: Hacer la entrega del producto al usuario. Presentar el software. El centro de su actividad se encuentra al final de
la fase de transicin.

Los artefactos, roles, y actividades del flujo dependen de acuerdo al modo de despliegue:
-Software a medida
-Software embebido en Hardware
-Software a travs de internet
-Software enlatado.

Trabajadores
Gerente de despliegue: planifica y organiza el despliegue. Es responsable del programa de soporte a las pruebas beta y de
asegurarse que el producto esta empaquetado apropiadamente para su envio.
Gerente de proyecto: es el que funciona de intermediario con los clientes, el responsable de aprobar los despliegues basados en
retroalimentacin y pruebas de evaluacin resultantes , as tambin como de la aceptacin del cliente para la entrega del producto.
Escritor tcnico: planea y produce el material de soporte al usuario final.
Desarrollador de curso: planea y produce el material de capacitacin.
Artista Grafico: es el responsable por todos los trabajos de arte relacionados al producto.
Tester: ejecuta pruebas de aceptacin y es el responsable de asegurarse que el producto fue probado adecuadamente.
Implementador: crea los scripts de instalacin y los artefactos relacionados que ayudaran al usuario final a instalar el producto.

Artefactos
El despliegue tiene un campo muy amplio, desde el despliegue de sistemas a medida hasta software que puede ser descargado de la
web. Dado este amplio rango de productos, los artefactos listados debajo pueden ser requeridos o no, dependiendo del modo de
despliegue.

Release: el artefacto clave es el producto terminado, que puede consistir en:
- El software ejecutable, en todos los casos.
- Artefactos de instalacin: scripts, herramientas, archivos, guas, informacin de licencia.
- Release notes: notas que describen el producto terminado al usuario final.
- Material de Soporte: como los manuales de usuario, operaciones y mantenimiento.
- Manuales de Capacitacin

En el caso de productos manufacturados, se requieren artefactos adicionales para crear el producto como:
La lista completa de tems a ser incluidos en el producto manufacturado
Empaquetamiento
Dispositivos de almacenamiento: el material en el cual el producto ser vendido, como por ejemplo: CDs

Otros artefactos de despliegue usados en el desarrollo del producto, pero no necesariamente entregados al cliente son:
Prueba de resultados
Resultados de retroalimentacin (para prueba de betas)
Resumen de pruebas de evaluacin

Flujo de Trabajo
Planear el Despliegue: dado que un despliegue exitoso est definido por la voluntad del cliente de usar el nuevo software, el
planeamiento del despliegue no solo debe tener en cuenta cmo y cundo entregar el nuevo software, sino tambin debe
asegurarse que el usuario final tiene toda la informacin necesaria para recibir el nuevo software adecuadamente y comenzar a
usarlo. Para asegurarse de eso, los planes de despliegue incluyen una prueba de la beta del programa, para ir asesorando al usuario
de forma temprana a travs de las betas que todava estn en construccin.
el planeamiento de despliegue general del sistema requiere un alto grado de colaboracin y preparacin del cliente. Una conclusin
exitosa del proyecto del software puede ser impactada severamente por factores fuera del desarrollo mismo del software, tales
como el edificio donde se instalar el software, la infraestructura de hardware fuera de lugar y usuarios que no estn lo
suficientemente preparados para adaptarse al nuevo software.
Desarrollo de material de soporte: el material de soporte cubre toda la informacin que ser requerida por el usuario final para
instalar, operar, usar y mantener el sistema. Tambin incluye material de capacitacin para que todos los usos posibles que se le
pueda dar al sistema sean efectivos.
Prueba del producto en el lugar de desarrollo: esta prueba determina si el producto tiene la madurez suficiente para ser
entregado como producto final o como distribucin para beta-testers.
El testeo de betas se hace para pulir un amplio rango de detalles, permitiendo al usuario final retroalimentar y mejorar el producto
antes de su entrega final y en el caso de sistemas desarrollados a medida, la prueba beta puede ser una instalacin piloto en el lugar
donde se instalara el sistema.
Crear el producto final: hay que asegurarse que el producto est preparado para la entrega al cliente. El producto final consiste
en todo lo que el usuario final necesitara para instalar y ejecutar el software finalmente.
Prueba Beta del producto final: esto requiere que el producto sea instalado por el cliente, quien proveer informacin sobre su
performance y usabilidad.
En el contexto del desarrollo iterativo, el beta testing es esencial para asegurarse que las expectativas del cliente fueron satisfechas
y la informacin provista por el usuario, se retroalimente a la prxima iteracin del desarrollo.
Probar el producto en el lugar de instalacin: el producto debe ser instalado y probado por el cliente. Basndonos en las
iteraciones y pruebas anteriores, en esta prueba no deberamos encontrarnos con sorpresas y debera ser solo una formalidad para
que el cliente acepte el sistema.
Empaquetar el producto: estas actividades opcionales describen lo que debe pasar para producir un producto de software
empaquetado. En este caso, el producto final se guarda como producto maestro para su produccin en masa y luego empaquetado
en cajas con la lista de contenidos para su envo al cliente.

Patrones de Diseo
Concepto: Son una forma de nominar, explicar y evaluar un diseo general y recurrente en un determinado contexto, en un sistema
orientado a objetos, a travs de una descripcin de las clases e instancias participantes de una estructura, sus roles, colaboraciones y
distribucin de responsabilidades.
Son descripciones de clases y objetos relacionados que estn particularizados para resolver un problema de diseo general en un
determinado contexto.
Describen un problema comn a distintos dominios as como la solucin a ese problema, de manera que no sea necesario generar
cada vez una solucin distinta.
Beneficios de aplicar patrones de diseo:
-Sistemas ms flexibles, elegantes y reutilizables
-Me permiten enriquecer el vocabulario de los desarrolladores
-Permiten aplicar la experiencia previa de los buenos diseadores
-Resuelven problemas concretos de diseo
-No afectan a la arquitectura
-Se logran diseos modulares y comprensibles
-Ayudan a refinar los mdulos
-No poseen dependencia con el lenguaje de programacin por lo que pueden ser aplicados en cualquiera.
-Mejoran la documentacin y el mantenimiento de sistemas existentes
-Aplicar en mayor medida los patrones de diseo aumenta la calidad del software.
Estrategias para seleccionar un patrn:
-Pensando en que problema soluciona el patrn
-Analizando el propsito de los patrones
-Conociendo el propsito del patrn, buscamos propsitos similares
-Analizando las relaciones entre patrones
-Pensando en aquellos aspectos del sistema que pueden presentar rediseo
-Pensando en los cambios que podran producirse en el software
Que problemas resuelven los patrones?
-Me permiten encontrar objetos y crear clases de objetos de fabricacin pura
-Me permiten identificar interfaces
-Manejar distintos niveles de granularidad
-Me permiten implementar las interfaces
-Me permiten manejar la reutilizacin
Como aplicar el patrn seleccionado
-Se debe comprender el patrn (leerlo)
-Entender su estructura, roles, colaboraciones,etc
-Identificar los componentes concretos del patrn en nuestro caso
-Implementar el patrn
Elementos de un patrn:
Nombre: Describe en una o dos palabras el diseo junto con sus soluciones y consecuencias
Problema: Describe cuando aplicar el patrn, explica el problema y su contexto. Puede describir problemas concretos de diseo.
Solucin: Describe los elementos, el diseo, las relaciones, responsabilidades y colaboraciones.
Consecuencias: Ventajas, resultados y/o inconvenientes de aplicar el patrn. Son fundamentales para evaluar las alternativas de
diseo.
Aspectos que no se contemplan en estos patrones de diseo:
Concurrencia
Sistemas distribuidos
Sistemas de tiempo real
Dominios especficos
Construccin de interfaces de usuarios
El uso de bases de datos
La escritura de controladores de dispositivos.
Clasificacin:
PROPSITO
Qu hace el patrn?
De creacin
Proceso de creacin de un objeto
Estructurales
Composicin de clases u
objetos
De comportamiento
Modo en que las clases y objetos interactan y se
reparten las responsabilidades
m
b
i
t
o

d
o
n
d
e

s
e

a
p
l
i
c
a
?

CLASE
Trata relaciones entre clases
y subclases
Delegan alguna parte del
proceso de creacin de
objetos en subclases.
Usan la herencia
para componer
clases.
Usan la herencia para describir algoritmos y
flujos de control.
OBJETO
Trata con relaciones entre
objetos
Delegan alguna parte del
proceso de creacin de
objetos en otro objeto.

Describen formas
de ensamblar
objetos.

Describe como cooperan un grupo de
objetos para realizar una tarea que ninguno
de ellos la puede realizar por s solo.

Propsitos patrones:
Patrunes de Creacin:
Factory Method: Define una interfaz para crear un objeto, pero permite a las subclases decidir la clase a instanciar (instanciacin
diferida a las subclases)

Singleton: Asegurar que una clase tiene una nica instancia y asegurar un acceso global.
Builder: Separa la construccin de un objeto complejo de su representacin, as que el mismo proceso de construccin puede crear
diferentes representaciones.
Prototype: tiene como finalidad crear nuevos objetos duplicndolos, clonando una instancia creada previamente.
Abstract Factory: Proporciona una interfaz para crear familias de objetos relacionados o dependientes sin especificar la clase
concreta.

Estructurales:
Adapter: Se utiliza para adaptar o transformar una interfaz en otra, de tal modo que una clase que no pudiera utilizar la primera,
haga uso de ella a travs de la segunda.
Fachada: Proporciona una nica interfaz a un conjunto de interfaces de un subsistema. Define una interfaz de ms alto nivel que
facilita el uso de un subsistema
Composite: Componer objetos en estructuras jerrquicas para representar jerarquas todo-parte. Permite a los clientes manejar a
los objetos primitivos y compuestos de forma uniforme.
Bridge: Desacoplar una abstraccin de su implementacin de modo que los dos puedan cambiar independientemente.
Proxy: Proporcionar un sustituto de un objeto para controlar el acceso a dicho objeto
Decorator: Responde a la necesidad de aadir dinmicamente funcionalidad a un Objeto. Esto nos permite no tener que crear
sucesivas clases que hereden de la primera incorporando la nueva funcionalidad, sino otras que la implementan y se asocian a la
primera.
Flyweight: Reduce la redundancia cuando gran cantidad de objetos poseen idntica informacin.

Comportamiento:
Template Method: Define el esqueleto de un algoritmo en una operacin, difiriendo algunos pasos a las subclases. Permite a las
subclases redefinir ciertos pasos de un algoritmo sin cambiar la estructura del algoritmo.
Interpreter: Dado un lenguaje, define una gramtica para dicho lenguaje, as como las herramientas (intrprete del lenguaje)
necesarias para interpretarlo. Se usa para definir un lenguaje para representar expresiones regulares que representen cadenas a
buscar dentro de otras cadenas. Adems, en general, para definir un lenguaje que permita representar las distintas instancias de una
familia de problemas.

State: Permite a un objeto cambiar su comportamiento cuando cambia su estado. El objeto parece cambiar de clase
Strategy: Define una familia de algoritmos, encapsula cada uno y permite intercambiarlos. Permite variar de algoritmos de forma
independiente a los clientes que los usan.
Visitor: Permite definir nuevas operaciones sobre una jerarqua de clases sin modificar las clases sobre las que opera.
Command: Encapsula un mensaje como un objeto, permitiendo parametrizar los clientes con diferentes solicitudes, aadir a una
cola las solicitudes y soportar funcionalidad deshacer/rehacer.
Chain of Responsibility: Permite establecer una cadena de objetos receptores a travs de los cuales se pasa una peticin formulada
por un objeto emisor. Cualquiera de los objetos receptores puede responder a la peticin en funcin de un criterio establecido.
Se utiliza, por ejemplo, cuando en funcin del estado del sistema las peticiones emitidas por un objeto deben ser atendidas por
distintos objetos receptores.
Observer: Define una dependencia uno-a-muchos entre objetos, de modo que cuando cambia el estado de un objeto, todos los
dependientes automticamente son notificados y actualizados.
Iterator: Proporciona una forma para acceder a los elementos de una estructura de datos sin exponer los detalles de la
representacin.
Memento: Captura y exterioriza el estado interno de un objeto, sin violar el encapsulamiento, de modo que el objeto puede ser
restaurado a ese estado ms tarde.
Mediator: Coordina las relaciones entre sus asociados. Permite la
interaccin de varios objetos, sin generar acoples fuertes en esas
relaciones. Su intencin es definir un objeto que encapsule como
interacta un conjunto de objetos. Cuando muchos objetos
interactan con otros objetos, se puede formar una estructura
muy compleja, con objetos con muchas conexiones con otros
objetos. Para evitar esto el patrn Mediator encapsula el
comportamiento de todo un conjunto de objetos en un solo
objeto.

Causas de Rediseo: Para disear un sistema que sea robusto, hay que tener en cuenta cmo puede necesitar cambiar el sistema
a lo largo de su vida. El rediseo afecta a muchas partes del sistema, por lo que los cambios no previstos siempre resultan costosos.
Los patrones de diseo ayudan a evitar esto al asegurar que un sistema pueda cambiar de formas concretas. Cada patrn de diseo
deja que algn aspecto de la estructura vare independientemente de otros.
A continuacin se presentan algunas de las causas comunes de rediseo, y los patrones que ayudan a resolverlas:
Crear un objeto especificando su clase explcitamente: Especificar el nombre de clase al crear un objeto nos liga a una
implementacin concreta. Para evitarlo, debemos crear los objetos indirectamente.
Patrones: Abstract Factory, Factory Method, Prototype.
Dependencia de operaciones concretas: Cuando especificamos una operacin, nos ligamos a una forma de atender la peticin. Esto
se puede evitar mediante el uso de patrones:
Patrones: Chain of Responsibility, Command
Dependencia de plataformas de Hardware o Software: El software que depende de una plataforma concreta ser ms difcil de
portar a otras plataformas. Es importante disear sistemas que limiten las dependencias de plataforma
Patrones: Abstract Factory, Bridge
Dependencia de las representaciones o implementaciones de objetos: Los clientes de un objeto que saben como se representa,
almacena, localiza o implementa quizs deban ser modificados cuando cambie dicho objeto. Ocultar esta informacin a los clientes
previene cambios en cascada.
Patrones: Abstract Factory, Bridge, Memento, Proxy
Dependencias algortmicas: Muchas veces los algoritmos varan en la vida del software. Los objetos que dependen de un algoritmo
debern variar cuando este cambie. Estos algoritmos deberan estar aislados.
Patrones: Builder, Iterator, Strategy, Template Method, Visitor.
Fuerte Acoplamiento: Las clases que estn fuertemente acopladas son difciles de reutilizar por separado. Por lo tanto se
recomienda el bajo acoplamiento. Los patrones hacen uso de tcnicas como acoplamiento abstracto y la estructuracin en caas para
reducir el acoplamiento
Patrones: Abstract Factory, Bridge, Chain of Responsibility, Command, Facade, Mediator, Observer
Aadir funcionalidad mediante la herencia: Definir una subclase tambin requiere de un profundo conocimiento de la clase padre, y
la clase hija podra quedar ligada a la clase padre, siendo que cambios en la implementacin de la clase padre, requiera modificar las
clases hijas. La composicin de objetos y delegacin proporcionan alternativas flexibles a la herencia, al costo de hacer ms
complejo el entendimiento.
Patrones: Bridge, Chain of responsibility, Composite, Decorator, Observer, Strategy
Incapacidad para modificar clases: Aveces hay que modificar clases que no pueden ser modificadas. Los patrones de diseo ofrecen
formas de modificar las clases en tales circunstancias.
Patrones: Adapter, Decorator, Visitor.

Toolkits: Es un conjunto de clases relacionadas y reutilizables diseadas para proporcionar funcionalidad til de propsito general.
Mecanismos de reutilizacin:
Herencia: La herencia de clases permite definir una implementacin en trminos de otra. Se la denomina reutilizacin de caja
blanca, ya que con la herencia, las interioridades de las clases padres suelen hacerse visibles a las sublcases.
Ventajas:
-Se define estticamente en tiempo de compilacin y es sencilla de usar.
-Hace que sea ms fcil modificar la implementacin que esta siendo reutilizada.
Desventajas
-No se pueden cambiar las implementaciones heredadas de las clases padre en tiempo de ejecucin.
-Como la herencia expone a una subclase los detalles de la implementacin de su padre, suele decirse que la herencia rompe el
encapsulamiento.
-La implementacin de una subclase se liga de tal forma a la implementacin del padre, que cualquier cambio en la implementacin
de la clase padre obligar a modificar la clase hija.
Composicin: Representa una alternativa a la herencia. Ahora la nueva funcionalidad se obtiene ensamblando objetos para obtener
funcionalidades mas complejas. Requiere que los objetos a componer tengan interfaces bien definidas.
Este tipo de reutilizacin se denomina caja negra, porque los detalles internos de los objetos no son visibles.
Ventajas:
-Se define dinmicamente en tiempo de ejecucin a travs de objetos que tienen referencias a otros objetos. Como se accede a los
objetos solo a travs de sus operaciones, no se rompe el encapsulamiento. Cualquier objeto puede ser reemplazado por otro del
mismo tipo en tiempo de ejecucin.
-Como la implementacin de un objeto se escribitra en trminos de interfaces de objetos, las dependencias de implementacin
sern menores.
Desventajas:
-Un diseo basado en la composicin de objetos tendr ms objetos, y el comportamiento del sistema depender de sus relaciones
en vez de estar definido en una clase.
Tipos parametrizados: Esta tcnica permite definir un tipo sin especificar todos los otros tipos que usa. Los tipos sin especificar se
proporcionan como parmetros cuando se va a usar el tipo parametrizado. Por ejemplo yo puedo utilizar una lista que trabaje con
cualquier tipo de objetos, y a la hora de crearla en tiempo de ejecucin, le paso por parmetro el tipo de datos a contener.

Que enfoque a utilizar depende de las restricciones del diseo e implementacin que posea el dominio.

Delegacin:
Es un modo de lograr que la composicin sea tan potente para la reutilizacin como lo es la herencia. Con la delegacin dos son los
objetos encargados de tratar una peticin: un objeto receptor delega operaciones en su delegado. El receptor se pasa a s mismo al
delegado para que la operacin delegada pueda referirse a l.
La principal ventaja de la delegacin es que hace que sea ms fcil combinar comportamiento en tiempo de ejecucin y cambiar la
manera en que estos se combinan.
La delegacin tiene el inconveniente radica en que el software dinmico y altamente parametrizado es ms difcil de entender que el
esttico. Posee tambin ineficiencias en tiempo de ejecucin.
El uso de la delegacin funciona mejor cuando se usa con patrones estndares. Los patrones State, Strategy, y Visitor se basan en
ella. En el state, un objeto le delega peticiones a un objeto Estado que representa su estado actual pasndose el mismo como
referencia. En el patrn Strategy un objeto delega una peticin a un objeto que representa una estrategia para llevarlo a cabo.

Persistencia
Concepto: Capacidad de mantener los datos durante el tiempo. Los objetos de entidad poseen un ciclo de vida que sobrepasa la
ejecucin del sistema.
Tipo de almacenamiento:
-Base de datos orientada a objetos
-Base de datos relacionales
-Otros
Problema de impedancia: Como transformar una representacin de datos en otra con un esquema diferente.

Framework: Conjunto de clases (abstractas y concretas) que colaboran entre s y se pueden utilizar como plantilla para solucionar
una familia de problemas relacionados.
Framework de Persistencia: Conjunto extensible de clases e interfaces que colaboran para proporcionar un servicio de persistencia.
Funciones:
-Almacenar y recuperar objetos en un medio de almacenamiento persistente.
-Confirmar y deshacer las transacciones
Servicioes:
-Funcionalidad especfica pero transversal a todo el sistema. Se traduce en un subsistema
-Se ubica en la capa intermedia
-Es un subsistema basado en un framework de persistencia
Caractersticas:
-Extensible: Se puede extender un comportamiento especfico de la aplicacin agregando subclases.
-Contiene clases concretas y abstractas que definen las interfaces a las que debe ajustarse, interaccin de objetos y otras
variantes
-Tiene clases abstractas que podran contener tanto mtodos abstractos como concretos
-Principio de Hollywood: No nos llame, nosotros lo llamaremos. El framework define la Interfaz de una clase y uno la debe
implementar, y luego el framework usa esa interfaz cuando la necesita.
-Ofrece un alto grado de reutilizacin, mucho ms que con clases individuales
Indicadores de calidad de un framework de persistencia: Los indicadores de calidad es la aplicacin de patrones de diseo en la
construccin del framework.
Caractersticas de las BDOO:
Objetos complejos: Debera soportar la nocin de objetos complejos
Identidad de objetos: Cada objeto debe tener una identidad independiente de sus valores internos
Encapsulamiento: Debe soportar el encapsulamiento de datos y comportamiento en los objetos
Tipos o Clases: Debera soportar un mecanismo de estructuracin, en forma de tipos o clases.
Jerarqua: Debera soportar la nocin de herencia
Ligadura tarda: Debera soportar sobre escritura y ligadura tarda
Completitud: El lenguaje de manipulacin debera ser capaz de expresas cada funcin calculable
Extensibilidad: Debera ser posible agregar nuevos tipos

Mapeo Objeto-Relacional:
Ideas a desarrollar (Framework de persistencia)
Correspondencia (mapping): Correspondencia entre los distintos esquemas de representacin
Objeto---------Relacional
Clase Relacin
Atributo Columna(Campos)
Objeto Registro
Identidad de objeto: Identificador nico que vincula objetos con registros.
Materializacin y desmaterializacin:
Materializacin: Registro a Objeto
Desmaterializacin: Objeto a Registro
Conversor de BD: Es quien se encarga de los procesos de materializacin y desmaterializacin
Cach: Almacn de objetos materializados en esta memoria por cuestiones de rendimiento.
Esquema de
representacin I
Esquema de
representacin II
?
Mapeo
Estado de transaccin de los objetos: El estado de los objetos para saber si se modificaron en funcin de su estado almacenado.
Operaciones de transaccin: confirmar y deshacer
Materializacin Peresoza: No todos los objetos se materializan a la vez, se hace bajo demando, cuando se los necesita.
Proxies virtuales: Referencia inteligente utilizada para la materializacin perezosa.

Patrones
-Patrn de transformacin de clase a relacin: Definir una tabla por cada clase de objetos persistentes. Los atributos simples de los
objetos contienen datos primitivos. Y los atributos complejos deben representarse como Mltiples columnas o campo lista o realizar
otra relacin)
-Patrn Identificador de Objetos (OID): Propone asignar un OID a cada registro y objeto (o proxy de objeto)
-Representacin de las relaciones de los objetos en tablas
Asociaciones:
1a1: colocar una referencia externa en una o ambas tablas.
1aN: los N tendrn una referencia externa (FK) al 1.
NaN: crear una tabla intermedia.
-Fachada: Proporciona interfaz para el acceso al servicio de persistencia.
-Patrn Conversor (Mapper) de base de datos o Intermediario (Broker): Propone crear una clase responsable de materializar y
desmaterializar los objetos. Utiliza otros objetos para establecer la correspondencia con los objetos persistentes.
-Bridge: Para no ligarnos a una implementacin.
-Template Method: Define la estructura bsica para materializar un objeto, y permite a las subclases definir la manera de crear el
objeto a partir del almacenamiento.
-Gestin de cach: Rendimiento. Est asociado a los intermediarios. Propone que sea el conversor de base de datos el responsable
de mantener este cach y as aumentar el rendimiento.
-State: Guarda el estado de los objetos, para reconstruir en caso de deshacer transacciones.
-Command: Encapsular transacciones, cada sentencia SQL es un Command.
-Proxy Virtal: Se utilizar para la materializacin perezosa. Es una referencia inteligente que controla que solo se realicen las
operaciones necesarias. Es un proxy para el sujeto al que se quiere acceder, que materializa el sujeto real cuando se referencia por
primera vez.

EspecProd
LieneaDeVenta
Cantidad: Integer
getSubtotal(): Float
EspecificacionProducto
Descripcin: Texto
Precio: Dinero
.
1*
Public class LineaDeVenta
{
Private int cantidad; // Atributo simple
Private EspecificacionProducto especProc; // Atributo de referencia

Public Float getSubtotal()
Mapeo del diseo a la implementacin

Objetivo: Transformar los artefactos del diseo en cdigo en un lenguaje de programacin Orientado a Objetos.
Transformacin de los diseos en cdigos
Los artefactos UML creados durante el diseo, se utilizarn como entrada en el proceso de generacin de cdigo.
La implementacin en un lenguaje O.O. requiere la estructura de cdigo fuente para:
Definir clases e interfaces
Definir mtodos.

Generacin en Java
1. Creacin de las definiciones de las clases a partir de los diagramas de clases de diseo (DCDs): Para crear una definicin de
clase bsica en un lenguaje de programacin OO es suficiente con lo que describen los DCDs: Nombres de las clases o interfaces,
las superclases, signatura de los mtodos y de los atributos simples de una clase.
a) Definicin de una clase con mtodos y atributos simples: La transformacin de la definicin de los atributos bsicos y los
mtodos de una clase a Java, es directa.

b) Aadir atributos de referencia
Un atributo de referencia es un atributo que referencia a otro objeto (no a un primitivo)
Los atributos de referencia de una clase se deducen de las asociaciones y la navegabilidad de un diagrama de clases.
c) Atributos de referencia y nombres de los roles: Cada extremo de una asociacin se denomina rol. El nombre del rol
identifica al rol y a su naturaleza. Si en el DCD esta explicito el rol, se utiliza ese nombre para definir el atributo de
referencia durante la generacin del cdigo.

d) Transformacin de los atributos: En algunos casos la transformacin de los atributos desde el diseo al cdigo se hace en
diferentes lenguajes.

LieneaDeVenta
Cantidad: Integer
{
Private int cantidad;

Public Float getSubtotal()
Venta
fecha: Fecha
hora : Hora
getTotal(): Float
Public class Venta
{
// En java, la clase java.util.Date combina
la informacin del da con la hora

Private Date fechaHora = new Date();

2. Creacin de mtodos a partir de los diagramas de Interaccin: Un diagrama de interaccin muestra los mensajes que se enva
como respuesta a la invocacin de un mtodo. La secuencia de estos mensajes se traduce en una serie de sentencias en la
definicin del mtodo.
3. Clases contenedoras/colecciones en el cdigo: La multiplicidad en un DCD indica que un objeto mantiene visibilidad hacia otro
grupo de objetos.
En los lenguajes de programacin OO esto se modela introduciendo un contenedor o coleccin. Donde la clase del lado del
1(uno) define un atributo de referencia que apunta a la instancia del contenedor, que contiene instancias de la clase del lado del
* (muchos).

4. Manejo de excepciones y errores: En el desarrollo de una aplicacin, es aconsejable tener en cuenta el manejo de las
excepciones durante el diseo y la implementacin. En UML las excepciones se representan como mensajes asincrnicos en los
diagramas de interaccin.
5. Orden de implementacin: Es necesario implementar las clases desde la menos a la mas acoplada.
6. Programar Probando: En la prctica se escribe el cdigo de las pruebas de unidad antes que el cdigo que se va a probar
(Programar Probando Primero): Se escribe un poco de cdigo de prueba, luego un poco de cdigo de produccin, despus
cdigo de prueba y as sucesivamente.
Ventajas:
Se escriben realmente las pruebas de unidad: si fuese opcional, nadie lo hara.
Satisfaccin para los programadores: tienen un sentimiento de logro al pasar las pruebas.
Verificacin demostrable: a travs de las pruebas
Aclaran las interfaces y los comportamientos de la clase antes de la implementacin de las mismas.

EspecProd
LieneaDeVenta
Cantidad: Integer
EspecificacionProducto
Descripcin: Texto
Precio: Dinero
.
1*
{

Private List EspecificacionProducto = new ArrayList()
Estrategias de cambio en el software

1. Mantenimiento del software: Cambios del SW en respuesta de los cambios de requerimiento. La estructura permanece estable.
2. Transformacin arquitectnica: Cambia y mantiene el sw conforme cambia la arquitectura.
3. Reingeniera de Software: Cambia el sw para hacerlo mas fcil de comprender y cambiar. Comprende modificaciones
estructurales, pero no agrega ms funcionalidad.

Dinmica de la evolucin del software
Es el estudio de los cambios en el sistema.
Propone un conjunto de leyes que se refieren a estos cambios. Estas son:
a) Cambio continuo: El mantenimiento del sistema es un proceso inevitable ya que el entorno del sistema cambia, surgen nuevos
requerimientos y el sistema debe modificarse.
b) Incremento de la complejidad: Cuando los sistemas cambian, su estructura se degrada y la complejidad aumenta. Por eso se
deben emplear recursos extra para preservar y simplificar la estructura sin agregar funcionalidad (mantenimiento preventivo).
c) Evolucin prolongada del programa: La evolucin del programa es un proceso autoregulatorio. Los atributos del sistema (como
el tamao o los errores reportados) son aproximadamente invariables para cada entrega del sistema. Esta ley sugiere que los
sistemas grandes tengan una dinmica por s mismos establecida en una etapa inicial en el proceso de desarrollo. sta
determina las tendencias generales del proceso de mantenimiento del sistema y limita el nmero de posibles cambios al
sistema. Una vez que el sistema excede algn tamao mnimo acta de la misma forma que una masa inercial. Su tamao inhibe
el cambio principal puesto que los cambios introducen nuevas fallas que degradan la funcionalidad del sistema.
d) Estabilidad organizacional: En el tiempo de vida de un programa, su tasa de desarrollo es aproximadamente constante e
independiente de los recursos dedicados al desarrollo del sistema. Esta ley indica que muchos de los proyectos de programacin
grandes trabajan en los que se denomina un estado saturado. Un cambio a los recursos o al personal tiene efectos
imperceptibles en la evolucin a corto plazo del sistema.
e) Conservacin de la familiaridad: En el tiempo de vida del sistema, el cambio incremental en cada entrega es aproximadamente
constante. Esta ley se refiere a los incrementos del cambio en cada versin del sistema. Agregar nueva funcionalidad a un
sistema inevitablemente introduce nuevas fallas en el sistema. Por lo tanto, un incremento en la funcionalidad de una versin
significa que se seguir por versiones adicionales donde se reparen las nuevas fallas del sistema.

1. Mantenimiento del software: Es el proceso general para cambiar un sistema despus de que se entreg.
Existen tres tipos de mantenimiento de software:
1. Mantenimiento para reparar las fallas de software
Costo de la correccin de errores en:
La Codificacin: baratos
El Diseo: costosos, involucran la reescritura de varios componentes
Los Requerimientos: Los ms costosos, es necesario un rediseo amplio del sistema.
2. Mantenimiento para adaptar el software a nuevos entornos operativos
Se requiere cuando cambian algunos aspectos del entorno del sistema, como el hardware o el sistema operativo.
3. Mantenimiento para agregar o modificar la funcionalidad del sistema
Es necesario cuando los requerimientos del sistema cambian como respuesta a los cambios organizacionales o de negocios.

En la prctica no existe una clara distincin entre estos tipos de mantenimientos.
Los costos de mantenimiento son altos porque es costoso incorporar funcionalidad despus e que el sistema est en operacin
que implementar la misma durante el desarrollo.
Las buenas tcnicas de ingeniera de software contribuyen a una reduccin de los costos de mantenimiento.

2. Evolucin arquitectnica: Muchas compaas se enfrentan a la necesidad de evolucionar sus sistemas centralizados
(mainframe) a sistemas distribuidos (cliente-servidor), ya que estos ltimos son a menudo la solucin ms costeable. Existen
varios factores que contribuyen a este cambio:
a) Los costos de hardware: Los costos de adquirir y mantener un sistema distribuido son menores que los costos de comprar
una computadora mainframe.
b) Las expectativas de la interfaz de usuario: Los mainframe proveen interfaces basadas en formularios. Muchos usuarios
esperan interfaces grficas y una interaccin ms fcil con el sistema.
c) El acceso distribuido a los sistemas: Las compaas distribuyen su organizacin en lugar de mantener todos los recursos en
un solo lugar. Se reducen los costos del hardware, las interfaces son ms efectivas y el trabajo es distribuido.

Sin embargo, modificar la arquitectura de un sistema heredado no es fcil y es muy costoso. Por eso antes de migrar se debe
evaluar si los beneficios superan a los gastos.
Una dificultad fundamental es que los sistemas centralizados no estn estructurados de tal manera que los componentes
arquitectnicos bsicos puedan identificarse y separarse de los otros componentes. Los recursos de la interfaz de usuario, los
servicios y los accesos a datos estn entrelazados. En situaciones como esta el sistema heredados se congela y el complemento
se empaqueta como servidor, la interfaz de usuario se reimplementa en el cliente y el middleware de propsito especial traduce
las peticiones del cliente en interacciones con el sistema legado sin cambio.
Aunque la interfaz y sus servicios suministrados estn integrados, se los considera como si estuviesen organizados en varias
capas lgicas. Capas:
Presentacin: Despliegue y organizacin de las pantallas presentadas a los usuarios.
Validacin de datos: Comprobacin de datos de entrada
Control: Manejo de las secuencias de operacin desde y hacia el usuario.
Servicio: Suministra los clculos bsicos provistos por la aplicacin.
Base de datos: Almacenamiento y administracin de los datos.

3. Reingeniera de software: La ingeniera directa inicia con una especificacin del sistema y contina con el diseo y la
implementacin de un nuevo sistema.
La reingeniera inicia con un sistema existente y el proceso de desarrollo para el reemplazo se basa en la comprensin y la
transformacin del sistema original.
En otras palabras, la reingeniera de software se refiere a reimplementar sistemas heredados para hacerlos ms mantenibles.
Comprende la redocumentacin del sistema, la organizacin y reestructura del sistema, la traduccin del sistema a un lenguaje
de programacin ms moderno, y la modificacin y actualizacin de la estructura y los valores de los datos del sistema. La
funcionalidad del software no se cambia, y normalmente la arquitectura tampoco.
Ventajas:
a) Riesgo reducido: Existe un alto riesgo en volver a desarrollar software esencial para una organizacin.
b) Costo reducido: El costo de la reingeniera es mucho menor que los costos de desarrollar un nuevo software.

Los factores principales que afectan los costos de reingeniera son:
a) La calidad del software al que se aplica reingeniera. Entre ms baja sea la calidad ms altos sern los costos.
b) Las herramientas de apoyo disponibles para la reingeniera.
c) La amplitud de la conversin de datos requerida. Si se requiere convertir grandes volmenes de datos entonces el costo
del proceso aumenta.
d) La disponibilidad de personal experto. Si el personal responsable de dar mantenimiento al sistema no se involucra en el
proceso se incrementan los costos.
e) La principal desventaja de la reingeniera de software es que existen lmites prcticos hasta los que se puede extender la
mejora de un sistema. Aunque la reingeniera mejora la mantenibilidad, el sistema con reingeniera probablemente no ser
tan mantenible como un sistema nuevo desarrollado utilizando mtodos de ingeniera de software modernos.

Actividades del proceso de reingeniera:
a) Traduccin del cdigo fuente: Conversin automtica de un programa escrito en un lenguaje de programacin a otro
lenguaje. Esto es necesario debido a cambios de HW, cambios de las polticas organizacionales, poca habilidad del personal,
falta de sw de apoyo.
b) Ingeniera inversa: Proceso de analizar el sw con el objetivo de recuperar su diseo e implementacin. La entrada es el
cdigo fuente.
c) Mejora de la estructura del programa: Remplaza las estructuras de control no estructuradas (Ej: goto) con ciclos while y
condicionales. Esto se puede automatizar.
d) Modularizacin del programa: Proceso de reorganizar un programa con el fin de que las partes relacionadas se ubiquen
conjuntamente y se consideren como un solo modulo. As se eliminan las redundancias, se optimizan las relaciones y se
simplifica su interfaz.
e) Mdulos diferentes: Abstraccin de datos, mdulos de HW, mdulos funcionales, mdulos de apoyo al proceso.
f) Reingeniera de datos: El almacenamiento, la organizacin y el formato de los datos tienden a evolucionar para reflejar
cambios en el sw. El proceso de analizar y reorganizar las estructuras y los valores de los datos de un sistema para hacerlos
ms comprensibles se llama Reingeniera de datos.
Razones para modificar los datos:
Degradacin de la calidad de los datos
Limites inherentes al programa (Ej: Restricciones internas sobre cantidad de datos a procesar)
Evolucin arquitectnica.

Diseo de la interfaz de usuario
Reglas para el diseo de interfaz:
- Dar control al usuario
- Reducir la carga de la memoria del usuario
- Lograr que la interfaz sea consistente
- Lograr que la interfaz sea consistente (debe realizar devolucin sobre la accin del usuario)
- Direccionalidad (camino de la interfaz, ir paso a paso)
- Esttica
- Claridad
- Indulgencia (que el usuario pueda en algn momento cancelar el CU)

En el mejor de los casos, una interfaz difcil de utilizar provocar que los usuarios cometan muchos errores. El en peor de l os
casos, los usuarios simplemente se rehusarn a utilizar el sistema de sw sin tomar en cuenta su funcionalidad. Si la informacin se
presenta de una forma confusa o engaosa, los usuarios no comprendern el significado de la informacin. Esto puede provocar que
se genere una serie de acciones que corrompan los datos o que cause una falla catastrfica en el sistema.
Las ventajas de las GUIs son:
1. Son relativamente fciles de aprender y utilizar.
2. Para interactuar con el sistema, los usuarios cuentan con pantallas mltiples. Es posible ir de una tarea a otra sin perder de
vista la informacin generada durante la primera tarea.
3. Es posible interactuar rpidamente y tener acceso inmediato a cualquier punto de la pantalla.
El proceso de construccin de prototipos inicia con una simple interfaz en papel antes de ir al desarrollo de los diseos de las
pantallas que simulan la interacin del usuario.

Principios de diseo de la interfaz de usuario
Los diseadores de interfaces de usuario deben tomas en cuenta las capacidades fsicas y mentales de la gente que utilizar el sw.

Principio Descripcin
Familiaridad del
usuario
La interfaz debe utilizar trminos y conceptos que se toman de la experiencia
de las personas que ms utilizan el sistema.
Consistencia
Siempre que sea posible, la interfaz debe ser consistente en el sentido de que
las operaciones comparables se activan de la misma forma.
Mnima sorpresa El comportamiento del sistema no debe provocar sorpresa a los usuarios.
Recuperabilidad
La interfaz debe incluir mecanismos para permitir a los usuarios recuperarse
de los errores. Estos mecanismos pueden ser: configuracin de acciones
destructivas y proveer un recurso para deshacer.
Gua al usuario
Cuando los errores ocurren, la interfaz debe proveer retroalimentacin
significativa y caractersticas de ayuda sensible al contexto.
Diversidad de
usuarios
La interfaz debe proveer caractersticas de interaccin apropiada para los
diferentes tipos de usuarios del sistema.

Interaccin del usuario
Una interfaz de usuario coherente debe integrar la interaccin del usuario y la presentacin de la informacin.
La interaccin del usuario implica emitir comandos y datos asociados al sistema de cmputos.
Diversas formas de integracin:

Estilo de interaccin Principales ventajas Principales desventajas
Manipulacin
directa
- Interaccin rpida e intuitiva.
- Fcil de aprender.
- Puede ser difcil de implementar.
- Slo es adecuada donde existe una metfora
visual para las tareas y objetos.
Seleccin de mens
- Evita errores del usuario.
- Se requiere teclear poco.
- Lenta para usuarios experimentados.
- Puede llegar a ser compleja si existen
muchas opciones en el men.
Llenado de
formularios
- Introduccin de datos sencilla.
- Fcil de aprender.
- Ocupa mucho espacio en pantalla.
Lenguaje de
comandos
- Poderoso y flexible.
- Difcil de aprender.
- Administracin de errores pobre.
Lenguaje natural
- Accesible a usuarios casuales.
- Fcil de ampliar.
- Se requiere teclear ms.
- Los sistemas de comprensin de lenguaje
natural no son fiables.

Presentacin de la informacin
Puede ser simplemente una representacin directa de la informacin de entrada o presentarla grficamente.
El diseador debe tomar en cuenta varios factores:
1) El usuario est interesado en informacin precisa o en las relaciones entre los diferentes valores de los datos?
2) Qu tan rpido cambian los valores de la informacin? Se indicarn de forma inmediata al usuario los cambios en un
valor?
3) El usuario debe llevar a cabo una accin en respuesta a los cambios de la informacin?
4) El usuario necesita interactuar con la informacin desplegada va una interfaz de manipulacin directa?
5) La informacin que se va a desplegar es textual o numrica? Son importantes los valores relativos de los elementos de la
informacin?

La informacin se representa como texto cuando se requiere informacin numrica precisa y la informacin cambia
relativamente lento. Por lo general, se utiliza la representacin grfica si los datos cambian rpidamente o si las relaciones entre los
datos son significativos.
Cuando se tiene que presentar grandes cantidades de informacin, se pueden utilizar las visualizaciones abstractas para vincular
los elementos de los datos relacionados.

o Color en el diseo de la interfaz
Todos los sistemas interactivos, excepto los sistemas especializados con pantallas pequeas, permiten despliegues a color y las
interfaces de usuario utilizan el color de diferentes formas. En algunos sistemas el color se utiliza simplemente para resaltar, en
otros para mostrar las diferentes capas en un diseo.

Soporte al usuario
El abastecimiento de la gua del usuario cubre tres reas:
- Los mensajes producidos por el sistema en respuesta a las acciones del usuario (mensajes de error): son la primera marca que
reciben los usuarios de un sistema de sw. Al hacer un trabajo, los usuarios inexpertos pueden cometer errores y de forma inmediata
tiene que comprender el mensaje de error resultante. Cuando se disean, se toman en cuenta el conocimiento y la experiencia de
los usuarios.
- El sistema de ayuda en lnea: cuando a los usuarios se les presenta un mensaje de error y no lo comprenden, van
inmediatamente al sistema de ayuda por informacin. Estos sistemas proveen varios puntos diferentes de entrada a los usuarios.
Permiten al usuario entrar al sistema de ayuda en el punto inicial de jerarqua del mensaje y navegar por la informacin. Pueden
entrar al sistema de ayuda para obtener la explicacin de un mensaje de error o requerir la explicacin de un comando particular de
la aplicacin.
- La documentacin suministrada con el sistema: no es estrictamente parte del diseo de la interfaz de usuario pero es
recomendable disear el apoyo de ayuda en lnea junto con la documentacin en papel. Los manuales del sistema proveen
informacin ms detallada de la ayuda en lnea y se disean de tal forma que puedan ser utilizados por diferentes clases de usuarios
del sistema. Para satisfacer a estas clases de usuarios diferentes y a los diferentes niveles de experiencia de los usuarios, existen al
menos cinco documentos que se entregan con un sistema de sw. stos son: una descripcin funcional, un documento de instalacin,
un manual introductorio, un manual de referencia y un manual de administrador.

Evaluacin de la interfaz
Es el proceso de valorar la forma en que se utiliza una interfaz y verificar que cumple sus requerimientos. Es parte del proceso de
verificacin y validacin de sistemas de sw. Puede ser un proceso caro.

UML 2.0:
Que es?: Lenguaje de Modelado Unificado. Al ser un lenguaje contiene sintxis y semntica. Se acepta mundialmente el lenguaje en
1995. Nos permite visualizar, especificar, construir y documentar sistemas orientados a objetos. Proporciona un vocabulario y una
serie de reglas para combinar las palabras y facilitar la comunicacin.
UML indica cmo crear y leer modelos pero no dice que modelos se deben crear ni cuando, por eso hace falta un proceso.

Objetivos:
- Visualizar: UML, es un lenguaje grfico. Nos permite ver el concepto a travs de un elemento. Mostrar la realidad a travs de los
modelos, facilita la comunicacin.
-Especificar: Cubre todas las descripciones del anlisis, diseo e implementacin que deben desarrollarse en sistemas complejos.
-Construir: A partir de los elementos, genera un cdigo bsico, a partir del cual de trabaja.
-Documentar: UML nos permite ir armando la documentacin a medida que se va avanzando en el proyecto. Documentar es dejar
asentado las distintas caractersticas de un sistema (la documentacin asegura la calidad).
Caractersticas:
-Para poder aprovechar toda la funcionalidad del lenguaje, debe utilizarse en procesos de desarrollo unificado, es decir que
sean Iterativos e incrementales, basados en casos de uso y centrados en la arquitectura.
-Puede utilizarse en otros procesos que no sean el unificado, pero no se aprovechara al mximo.
-UML es el lenguaje, PUD es el proceso.
Relacin PDU y UML: UML es un lenguaje, mientras que PDU comprende la metodologa. El lenguaje me permite ir traduciendo en
modelos el proceso. UML no dice como realizar las actividades a modelar, sino que eso lo define el proceso.

Modelo Conceptual: Bloques de Construccin
Elementos
Estructurales: en su mayora son la parte esttica de un modelo, representa cosas que son conceptuales o materiales. Sus
elementos son siete:
1- Clase: descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica.
Una clase implementa una o ms interfaces.
2- Interfaz: es una coleccin de operaciones que especifican un servicio de una clase o componente. Describe el
funcionamiento visible externamente de ese elemento.
3- Colaboracin: define una interaccin y es una sociedad de roles y otros elementos que colaboran para proporcionar un
comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos.
4- Caso de Uso: es una descripcin de un conjunto de secuencias de acciones que un sistema ejecuta y produce un
resultado de inters para el actor.
5- Clase activa: es una clase cuyos objetos tienen uno o ms procesos o hilos de ejecucin y por lo tanto pueden dar origen
a actividades de control.
6- Componente: es una parte fsica y remplazable de un sistema que conforma con un conjunto de interfaces y proporciona
la implementacin de dicho conjunto.
7- Nodo: es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional.
8-Artefacto.
De comportamiento: representan la parte dinmica de un modelo. Representan comportamiento en el tiempo y espacio.
1- Diagrama de Interaccin: es un comportamiento que comprende un conjunto de mensajes intercambiados entre un
conjunto de objetos, dentro de un contexto para alcanzar un propsito especfico.
-Diagrama de comunicacin
-Diagrama de secuencia
-Vista Interaccin
-Vista de tiempo
2- Mquina de estados: es un comportamiento que especifica la secuencia de estados por las que pasa un objeto o una
interaccin durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos.
3- Diagrama de Actividad
4- Diagrama de Caso de Uso
De agrupacin: se utiliza para organizar los modelos. Posee un elemento que se denomina paquete, que sirve para organizar
elementos en grupos y se lo representa como una carpeta.
- Paquetes: en el 2.0 se formalizo este modelo, en el 1.4 ya estaba.
De anotacin: son la parte explicativa de los modelos. Son comentarios que sirven para describir, clarificar y hacer observaciones
sobre un elemento de un modelo. Su elemento principal es la nota, que es un smbolo para mostrar restricciones y comentarios
junto a un elemento o una coleccin de elementos.

Relaciones
Generalizacin: es una relacin de especializacin/generalizacin en la cual los objetos del elemento especializado (hijo)
pueden sustituir a los objetos del elemento general (padre). El hijo comparte la estructura y el comportamiento del padre. Una
generalizacin es una relacin de clases, no de objetos.
Asociacin: es una relacin estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. Una
asociacin puede refinarse con la navegabilidad, la multiplicidad y un rol.
Agregacin: es un tipo especial de asociacin. Es una relacin estructural entre el Todo y sus Partes. Existe la parte por ms
que no exista el todo.
Dependencia: es una relacin semntica entre dos elementos, en la cual un cambio en un elemento independiente puede
afectar a la semntica del elemento dependiente.
Realizacin: relaciona casos de uso con colaboraciones
Las relaciones como herencia, asociacin y agregacin son estticas, las cuales se implementan por medio de punteros. La
dependencia utiliza un puntero temporal, a diferencia de las anteriores.
Composicin: No existe la parte sin el todo.
Contencin: Mostrar composicin de los modelos.

Diagramas
Un diagrama es un grafico que representa elementos y sus relaciones. Cada uno de los diagramas mostrara al sistema desde una
perspectiva diferente.
Diagrama de clases: muestra un conjunto de clases, interfaces, colaboraciones y sus relaciones. Modela la vista esttica del
sistema, es decir, modela estructura.
Diagrama de objetos: muestra un conjunto de objetos y sus relaciones. Los DO representan instantneas de instancias de los
elementos encontrados en los DC.
Diagrama de casos de uso: muestra un conjunto de casos de uso, actores y sus relaciones. Con este diagrama se construye el
modelo de casos de uso del SI.
Diagrama de interaccin: muestra un conjunto de objetos, relaciones y mensajes. Este diagrama es usado cuando los flujos
alternativos son pocos y hay muchos objetos de entidad involucrados. Dentro de este diagrama hay dos tipos:
1. Diagrama de colaboracin: resalta la organizacin estructural de los objetos que envan y reciben mensajes. Muestran las
conexiones y mensajes de comunicacin entre objetos y son mejores para la comprensin de todos los efectos de un objeto
dado.
2. Diagrama de secuencia: resalta la ordenacin temporal de los mensajes. Muestran y hacen explicita la secuencia de eventos
y son mejores que los diagramas de actividad para escenarios ms complejos.
Estos dos diagramas son isomorfos, es decir, se puede tomar uno y transformarlo en el otro.
Diagrama de estados: muestra una maquina de estados, que consta de estados, transiciones, eventos y actividades.
Diagrama de actividades: muestra el flujo de actividades dentro de un sistema.
Diagrama de componentes: muestra la organizacin y las dependencias entre un conjunto de componentes.
Diagrama de despliegue: muestra la configuracin de los nodos de procesamiento en tiempo de ejecucin y los componentes que
residen en ellos.
Los diagramas de clases, de objetos, de casos de uso, de componentes y de despliegue cubren la vista esttica del sistema. Los
diagramas de interaccin, de estados, de actividades cubren la vista dinmica del sistema.

Reglas para combinar esos boques
Un modelo bien formado es aquel que es autoconsistente y est en armona con todos sus modelos relacionados. UML establece
reglas semnticas para:
Los nombres: significa como nombrar a los elementos, relaciones y diagramas.
La visibilidad: como se ven y usan esos elementos.
La integracin: como relacionar elementos con otros en forma apropiada.
Los modelos construidos de sistemas complejos tienden a evolucionar por esta razn es comn que los desarrolladores construyan
modelos abreviados (ocultando ciertos elementos), incompletos e inconsistentes (no se garantiza la integridad del modelo).

Mecanismos comunes
Se usan para una mejor comprensin y claridad de los modelos. Se dividen en cuatro:
Especificaciones: aclaraciones narrativas, que significa alguna cosa del diagrama. Ej. nota
Adornos: diferenciacin dentro de la sintaxis de los diagramas. Ej. Clases- Clases activas
Divisiones comunes: diferenciar una clase de un objeto y una interfaz de una implementacin.
Mecanismos de extensibilidad: sirven para extender el lenguaje de manera controlada, pueden ser:
- Estereotipos: smbolos para diferenciar clases.

- Valores etiquetados: aade nueva informacin en la especificacin de un elemento con una nota.
- Restricciones: reglas o limitaciones para aclarar el modelo con una nota

PROCESO DE VALIDACIN DE REQUERIMIENTOS

EL PROCESO DE VALIDACION DE REQUERIMIENTOS
La validacin consiste en demostrarle al cliente que el conjunto de requerimientos documentados define el sistema que l
solicito.
Es importante porque un error en la especificacin de requerimientos significa volver a realizar el trabajo de diseo,
codificacin y prueba es decir perdida de tiempo y dinero.
El documento de especificacin durante la validacin es sometido a diferentes tipos de verificaciones (principal diferencia
entre validacin y verificacin):
1) Verificacin de validez: Un usuario puede pensar que se necesita llevar a cabo ciertas funciones, pero el
razonamiento y anlisis identifican que se requieren funciones adicionales y diferentes.
2) Verificacin de consistencia: No debe haber contradicciones en el documento. Esto es, no debe haber
restricciones contradictorias o descripciones diferentes de la misma funcin del sistema.
3) Verificacin de integridad: El documento debe incluir todas las funciones y restricciones propuestas por el
usuario.
4) Verificaciones de realismo: Usando el conocimiento de la tecnologa existente los requerimientos deben
verificarse para asegurarse que se pueden implementar. Deben tenerse en cuenta el presupuesto y la
calendarizacin del desarrollo del sistema.
5) Verificabilidad: Para evitar discusiones los requerimientos del sistema se deben redactar de tal forma que sean
verificables.

Tcnicas de validacin:
1) Revisin
2) Creacin de prototipos
3) Generacin de casos de pruebas
4) Anlisis de consistencia automtica

Prototipos

Versin inicial del sistema que se utiliza para demostrar conceptos, probar opciones de diseo y de forma general,
enterarse ms acerca del problema y sus posibles soluciones.
El desarrollo rpido de prototipos es esencial ya que se controlan los costos y los usuarios pueden experimentar con el
prototipo durante las primeras etapas del proceso del desarrollo. Los prototipos ayudan a obtener requerimientos, a
validarlos, a capacitar a los usuarios y a probar el sistema.
Ventajas: al construir prototipos en el proceso de desarrollo,
- Mejora la utilizacin del sistema
- Mejora la calidad del diseo
- Mejora el acoplamiento entre el sistema y las necesidades del usuario
- Mejora el mantenimiento del sistema
- Reduce el esfuerzo durante el desarrollo

Construccin del prototipo

1- Construccin de prototipos evolutivos: Inicia con un sistema simple que implementa los requerimientos ms
importantes. El prototipo aumenta a medida que se agregan requerimientos. En muchos casos no existe un
documento formal de requerimientos. El objetivo es entregar un sistema funcin, por eso se dejan de lado los
requerimientos de prioridad alta hasta cuando lo requieran los usuarios. La prioridad la decide o define el usuario.
Adems se deben desarrollar con estndares de calidad.
2- Construccin de prototipos desechables: Ayudan a refinar y clasificar la especificacin del sistema. El prototipo
se escribe, evala y modifica. Una vez redactada la especificacin el prototipo ya no es til y se desecha. El
objetivo es validar o derivar los requerimientos del sistema. Se hace prototipos de los requerimientos que no se
comprendan bien.

PROTOTIPOS

Un prototipo es una versin inicial del sistema de software que se utiliza para demostrar los conceptos, probar las
opciones de diseo y, de forma general, enterarse ms acerca del problema y sus posibles soluciones.
Un prototipo de software apoya a dos actividades del PIR:
Obtencin de requerimientos: pueden proponer nuevos requerimientos del sistema.
Validacin de requerimientos: puede relevar errores y omisiones en los requerimientos propuestos.

La construccin de prototipos puede utilizarse como un anlisis de riesgo y una tcnica de reduccin. Un riesgo
importante en el desarrollo de software son los errores y omisiones de requerimientos.
El desarrollo de un prototipo del sistema tiene otras ventajas:
Se identifican las discrepancias entre los desarrolladores del software y los usuarios.
El personal del desarrollo de software puede darse cuenta de que los requerimientos son inconsistentes y/o
estn incompletos.
Se dispone rpidamente de un sistema que funciona y demuestra la factibilidad y usabilidad de la aplicacin a
administrar.
El desarrollo de un prototipo conduce a mejorar la especificacin del sistema. Tambin se utiliza para otros propsitos:
Capacitar al usuario.
Probar el sistema.

Prototipos evolutivos y desechables

La construccin de prototipos evolutivos inicia con un sistema relativamente simple que implementa los
requerimientos ms importantes del usuario. Dicho prototipo se aumenta o cambia en cuanto se descubren nuevos
requerimientos.
En contraste, el enfoque de construccin de prototipos desechables es para ayudar a refinar y clasificar la
especificacin del sistema. El prototipo se escribe, evala y modifica.
Existe una diferencia entre los objetivos de la construccin de prototipos evolutivos y la de prototipos desechables:
El objetivo de la construccin de prototipos evolutivos es entregar a los usuarios finales un sistema funcional.
El objetivo de la construccin de prototipos desechables es validar o derivar los requerimientos del sistema.
Los requerimientos que son precisos nunca deben estar en el prototipo.

Prueba alfa: se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como
observador del usuario y registrando los errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado.
Prueba beta: se llevan a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba
alfa, el desarrollador no est presente normalmente. As, la prueba beta es una aplicacin en vivo del software en un entorno que no
puede ser controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta e informa a
intervalos regulares al desarrollador.
Prueba Piloto: Se prueba una parte del sistema.

Validacin: Estamos construyendo el sistema correcto? El sistema satisface los requerimientos del usuario?
Verificacin: Estamos construyendo correctamente el producto? El producto lleva a cabo lo especificado?

Pruebas de regresin: son aquellas pruebas cuyo objetivo es comprobar por qu ha dejado de funcionar algo que ya
funcionaba. El objetivo de las pruebas de regresin es no tener que volver atrs.
Pruebas de aceptacin: son pruebas funcionales, pero vistas directamente desde el cliente. Digamos que son aquellas
pruebas que demuestran al cliente que la funcionalidad est terminada y funciona correctamente.

Resumen DSI

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Resumen DSI

Uploaded by

Copyright:

Available Formats

Flujo de Trabajo de Anlisis

You might also like