Unidad 1:

Modelo:
¿Qué es un modelo? Es una representación, una simplificación de la realidad, captando los
aspectos importantes de lo que se está modelando desde un cierto punto de vista y
simplificando u omitiendo el resto. Son necesarios para comprender el sistema que se está
modelando.

¿Cuál es el objetivo de modelar? Modelar nos ayuda a visualizar un sistema como es o

deseamos que sea, permite especificar la estructura o el comportamiento de un sistema, nos
da una plantilla que nos guía en la construcción del sistema, documentan las decisiones que
hemos tomado.

Permite capturar y enumerar exhaustivamente los requisitos y el dominio del conocimiento, de

forma que todos puedan entenderlos. Nos ayuda para pensar en el diseño de un sistema. Nos
permite capturar las decisiones de diseño en un formato alterable independiente de los
requisitos.

UML:
¿Qué es UML? Es un lenguaje de modelado visual de propósito general, que se usa para
especificar, visualizar, construir y documentar los artefactos de un sistema de software
orientados a objetos. Pretende ser acercarse a ser un método de modelado estándar. Esta
constituida de conceptos semánticos, notación y principios generales. Permite mostrar
diferentes aspectos de un mismo sistema.

¿Por qué es un Lenguaje? Es un lenguaje porque es provee un vocabulario y reglas para

combinar los elementos de dicho vocabulario con el propósito de comunicar cómo se deben
representar los esquemas del software. Es un lenguaje de modelado esos vocabularios y reglas
se focalizan en representaciones conceptuales y físicas de un sistema.

¿Cuál es su propósito?
-Nos ayudan a visualizar un sistema como es, o como queremos que sea.
-Nos permiten especificar la estructura o el comportamiento de un sistema.
-Nos dan una plantilla que nos guía en la construcción del sistema.
-Nos ayuda a documentar las decisiones que hemos tomado.
-Busca ser un lenguaje universal.
-Busca incorporar buenas prácticas de modelado como encapsulación, separación de temas y
captura de intención del modelado, etc.
-Uno de sus objetivos es ser tan simple como fuera posible pero manteniendo la capacidad de
modelar toda gama de sistemas que se necesita construir.

Visión general de UML: ¿Para qué sirve?

Visualizar: es un modelo que facilita la comunicación. Utiliza un lenguaje gráfico y lo puede

interpretar otro desarrollador sin ambigüedad. Detrás de cada símbolo en la notación UML hay
una semántica bien definida

Especificar: permite construir modelos precisos, no ambiguos y completos. UML cubre la

especificación de todas las decisiones de análisis, diseño e implementación quede en realizarse
al desarrollar y desplegar un sistema con gran cantidad de software.
Construir: UML no es un lenguaje de programación visual, pero sus modelos pueden
conectarse de forma directa a una gran variedad de lenguajes de programación, esto permite
realizar ingeniería directa, es decir, la generación de código a partir de los modelos.

Documentar: cubre la documentación de la arquitectura de un sistema y todos sus detalles y

permite generar una serie de artefactos además del código fuente. Proporciona un lenguaje
para expresar requerimientos y pruebas. Proporciona un lenguaje para modelar las actividades
de planificación de proyectos y gestión de versiones.

¿Que no dice UML? ¿Que no es UML? UML no nos dice que modelo hay que construir y en
qué momento eso es tarea del proceso de desarrollo de software.
-No es un lenguaje de programación visual.
-No es la especificación de una herramienta o un repositorio.
-No es una metodología, método o proceso.
- no es un método completo de desarrollo.

Reglas de UML: UML tiene un número de reglas vinculadas a un modelo “bien formado”,
Modelo bien formado: semánticamente auto consistente y en armonía con sus modelos
relacionados.

UML tiene reglas semánticas para:

 Nombres: cómo llamar los elementos, relaciones y diagramas.

 Alcance: contexto que da un significado específico al nombre.
 Visibilidad: cómo se pueden ver y usar esos elementos por otros.
 Integridad: cómo se relacionan apropiada y consistentemente unos elementos con
otros.
 Ejecución: que significa ejecutar o simular un modelo dinámico.

UML también permite construir modelos que no sean “bien formados”, dado que un software
va evolucionando y pueden ser vistos por diferentes involucrados en momentos diferentes.

UML permite también construir modelos que sean:

 Abreviados: ciertos elementos se ocultan para simplificar la vista.

 Incompletos: pueden estar ausente ciertos elementos
 Inconsistentes: no se garantiza la integridad del modelo.

Modelo Conceptual UML: UML este compuesto por tres ramas

principales.

1. Bloques de construcción: estos bloques están compuestos

por sus elementos los cuales tienen relaciones y diagramas
que son el lugar donde se da uso a esos elementos y
relaciones
2. Mecanismos comunes: estos están compuestos por sus
especificaciones, sus adornos, sus divisiones comunes y
mecanismos de extensibilidad.
3. Reglas: son los acuerdos sobre los cuales se monta el
lenguaje y permite la estandarización de los modelados.
Bloques de Constricción:
Son un conjunto de elementos, relaciones y diagramas utilizadas para trabajar en el esquema
UML 2.0. estos están compuestos por elementos, relaciones y diagramas.

Elementos:
Elementos Comportamentales:

 Interaccionales: es una unidad de comportamiento centrada en el intercambio de

información observable entre elementos que se conectan entre sí. Este intercambio se
realiza con el objetivo de alcanzar un propósito especifico. Pueden ser mensajes
acciones y enlaces.
 Máquinas de estado: este comportamiento especifica las secuencias de estados por
las que pasa un objeto o una interacción durante su vida en respuesta a eventos.
Refleja todos los estados de la vida útil de un objeto y van cambiando según las
interacciones que este tenga.
 Actividades: este comportamiento especifica los pasos que ejecuta un determinado
proceso, muestra una secuencia de actividades. Detalla todas las actividades o rutas
que puede tomar un objeto desde el principio de su vida útil.

Elementos Estructurales: Son las partes estáticas que representan conceptos (elementos
lógicos) o cosas materiales (elementos físicos) de un sistema.

 Clase: descripción de un conjunto de objetos que comparten los mismos atributos,

comportamientos, relaciones. Una clase cómprate una o más interfaces.
 Interfaz: colección de operaciones que especifican un servicio de una clase o
componente. Representa el comportamiento de una sola o parte de ella.
 Colaboración: representa una interacción y es una sociedad de roles y otros elementos
que colaboran para lograr un comportamiento cooperativo mayor que la suma del
comportamiento de sus elementos.
 Caso de uso: conjunto de secuencias de acciones que un sistema ejecuta y produce un
resultado observable de interés para un actor en particular.
 Clase activa: clase cuyo objetivo tiene una o más procesos o hilos de ejecución, por lo
tanto, da a lugar a actividades de control.
 Artefacto: es una parte física y remplazable de un sistema que contiene información
física. En un sistema hay diferentes tipos de artefactos de despliegue como archivos de
código fuente, ejecutables, librerías, etc.
 Nodo: es un recurso físico que existe en tiempo de ejecución y representa un recurso
computacional, que dispone de memoria y con frecuencia capacidad de
almacenamiento. Un conjunto de artefactos puede residir en un nodo.

Elementos de notación:
Notas: Un símbolo para desplegar un comentario u otra información textual, tal como el
cuerpo de un método o una restricción. Estas pueden se asociadas a cualquier elemento del
diagrama y sirven para agregar una información adicional.

Elementos de agrupación: estos dan lugar a organización en el diagrama.

Paquetes: es el principal en el UML, que permite organizar elementos en grupo, es
simplemente conceptual ya que no existe en tiempo de ejecución, existen diferentes
variaciones como de entorno, boleos y subsistemas.
Relaciones:
Estos indican como se relacionan los distintos elementos de un modelo. existen diferentes
tipos:

 Asociación: es una relación estructural que especifica que los elementos de un

elemento se conectan a los de otro.

 Dependencia: es una asociación de uno, especifica que un cambio de una

especificación puede afectar a otro elemento que lo utiliza, pero no necesariamente a
la inversa.

 Agregación: es un tipo especial de asociación, que representa una relación

completamente conceptual entre un todo y sus partes.
  Composición: Es una variación de la agregación simple, con una fuerte relación de
pertenencia y vidas coincidencias de la parte con el todo.

 Contención: es una relación que especifica que una clase esta contenida dentro de
otra.

 Realización: es una relación que especifica que una clase esta encargada de
implementar el comportamiento especificado en otra.

Reglas de UML
Un modelo está Bien Formado cuando es semánticamente auto consistente y en armonía con
sus modelos relacionados.

Semánticas:

 Nombres: como se llaman los elementos, relaciones y diagramas

 Alcance: contexto que da un significado especifico al nombre.
 Visibilidad: como se pueden ver y usar los elementos por otros.
 Integridad: como se relacionan apropiada y consistentemente unos elementos con
otros.
 Ejecución: que significa ejecutar o simular un modelo dinámico.

Los modelos que no sean bien formados son permitidos también por UML, esto porque el
software puede ir evolucionado y puede ser visto por diferentes involucrados.

Otros tipos de modelos son:

 Abreviados: ciertos elementos se ocultan para simplificar la vista.

 Incompletos: pueden estar ausentes ciertos elementos.
 Inconsistentes: que no se garantiza la integridad del modelo.

Mecanismos comunes:
1. Especificaciones: UML es algo más que un lenguaje gráfico, detrás de cada elemento de su
notación grafica hay una especificación que proporciona una explicación textual de la
sintaxis y semántica de ese bloque de construcción.
2. Adornos: la mayoría de los elementos UML tienen una notación grafica única y clara que
proporciona una representación visual de los aspectos más importantes del elemento.
Todos los elementos en la notación UML parten de un símbolo básico, al cual pueden
añadirse una variedad de adornos específicos de ese símbolo. Por ejemplo, a los atributos
y métodos de las suelen ir acompañados de un símbolo que indica si visibilidad, como +
(publico), - (privado) y # (protegido).
3. Divisiones comunes: al modelar sistemas orientados a objetos, a menudo se divide en
varias formas:
3.1. División entre clase y objeto (clasificador e instancia): un objeto es una manifestación
concreta de esa abstracción (clase).
3.2. División entre interfaz e implementación: una interfaz declara un contrato y una
implementación representa la realización de ese contrato.
3.3. División entre tipo y rol: el tipo declara la clase de una entidad, como por ejemplo un
atributo o parámetro, un rol describe el significado de una entidad en un contexto,
como una clase, un componente o una colaboración.
4. Mecanismos de extensibilidad:
En conjunto estos tres mecanismos de extensibilidad permiten configurar y extender UML
para las necesidades de un proyecto, permitiendo a UML adaptarse a nuevas tecnologías
de software:
4.1. Estereotipo: extiende el vocabulario de UML, permitiendo crear nuevos bloques de
construcción que derivan de los existentes pero que son específicos a un problema.
4.2. Valor etiquetado: extiende las propiedades de un estereotipo de UML, permitiendo
añadir nueva información en la especificación de ese estereotipo.
4.3. Restricción: extiende la semántica de un bloque de construcción UML, permitiendo
añadir nuevas reglas o modificar existentes.
Diagramas de estructura
Sirven para visualizar, especificar, construir y documentar los aspectos estáticos de un sistema,
como aquellos que representan el esqueleto del sistema como la existencia y ubicación de
clases, interfaces, colaboraciones componentes y nodos.

Diagrama de despliegue:
Muestra un conjunto de nodos y sus relaciones. Se utilizan para describir la vista de despliegue
estática de un sistema.

Muestra la configuración de los nodos de procesamiento en tiempo de ejecución y su relación

y los artefactos que residen en ellos. Las relaciones entre nodos puede ser asociación y/o
dependencia.
se utiliza para:

 Describir la configuración principal de una aplicación

 Diseñar la configuración de hardware y software en un sistema embebido
 Examinar aspectos involucrados en la instalación del sistema de producción
 Examinar dependencias que tiene el sistema con otros sistemas de ambiente de
producción

Diagrama de Objetos:
Muestran un conjunto de objetos y sus relaciones y son usados para representar el estado de
un sistema en un momento de tiempo. Es similar al diagrama de clases, pero sus valores son
los cargados en ese momento. Contiene objetos con nombre y segundo de un “:” la clase al
que pertenece, y además tiene vínculos entre los objetos.
Diagrama de clases:
Nos presenta una vista estática del sistema. Es el diagrama más común de desarrollo de
software. Nos sirve para representar el diseño lógico físico del mismo. Este diagrama nos
permite conocer las clases, en la cual están comprendidas por un título, sus atributos, métodos
y relaciones entre sí.

Diagrama de paquetes:
Describe distintos paquetes lógicos que forman la aplicación. Un paquete es un conjunto de
elementos de UML, ya sean clases, casos de uso, relaciones, otros paquetes, etc. Cada paquete
tiene un símbolo similar a una carpeta. Los paquetes pueden tener dependencias, es decir que
un paquete origen tiene una dependencia de un paquete destino.

Diagrama de componentes:
Es un diagrama de estructura estático, físico. Se usa para mostrar las definiciones estructura
interna y dependencia de componentes. Contiene componentes, interfaces y relaciones de
asociación, generalización realización y/o dependencia.

Diagrama de estructura compuesta:

Contiene clases, interfaces paquetes y sus relaciones y proporciona una vista lógica de todo o
parte de un sistema de software, muestra la estructura interna incluida las partes y
contenedores de un clasificador estructurado. Es decir, muestra la estructura interna de un
clasificador que puede ser cualquier cosa como una clase comúnmente. Muestra la parte
interna y la relaciones de este y el comportamiento de el mismo.

Diagramas de comportamiento:
Se emplean para visualizar, especificar, construir y documentar los apsectos dinámicos de un
sistema. Involucra aspectos como el flujo de mensajses a lo largo del tiempo o el movimiento
físico de componentes en una red.

Diagrama de actividad:
Son de comportamiento, dinámico y lógico. Se usan para mostrar una operación, una regla, un
caso de uso, proceso de negocio o de software. Esta muestra el conjunto de actividades y el
flujo de secuencia que desglose de actividad en actividad, y los objetos que actúan y que son
afectados. Contiene nudos, flujos y objetos.

Diagrama de clases de uso:

Son de comportamiento estático y lógico. Comunica el alcance del caso de uso y una
descripción de todo o una parte de los requerimientos de un sistema u organización. Muestra
el conjunto de casos de usos, actores y sus relaciones. Muestra un conjunto de casos de uso y
actores y sus relaciones. Organizan y modelan el comportamiento del sistema. Cubren la vista
de casos de uso estática de un sistema.

Diagrama de máquina de estados:

Es de comportamiento, dinámico y lógico. Explora el comportamiento complejo de unas clases,
actor, subsistema o componente y sirve para modelar sistemas en tiempo real. Este
compuesto por estados, transiciones, evento y actividades.

Diagramas de interacción:
Son de comportamiento, dinámico, lógico. Proveen una vista
Máquina de estados:
La máquina de estados es un modelo de comportamiento, el cual está centrado en el
comportamiento de la clase a la cual se está modelando.

En el workflow de requerimientos conseguimos como salida el modelo de requerimientos, el

cual nos da diferentes artefactos del dominio del problema (modelo de casos de uso, modelo
de domino, descripción de interfaces de usuario, descripción de la arquitectura), para resolver
cada uno de estos modelos se usan diferentes herramientas de UML, como lo son los
diagramas de casos de uso, clases, prototipos, story boards.

Con este modelo de requerimientos terminado se usa para el hacer el modelo de análisis, en
este workflow en adelante se empieza a desarrollar el domino de la solución. En este workflow
nos centramos en los casos de uso funcionales. Los artefactos de salida de este modelo de
análisis son:

Las clases de análisis, tenemos las clases del dominio traídos del modelo anterior, en estas
clases de análisis tenesmo clases de fabricación pura los cuales nos ayudan a poder dar
solución al problema planteado algunos son los boundary y controlador. Estas clases de
análisis las podemos seguir modelando con el diagrama de clases o el diagrama de máquina de
estados.

Las realizaciones de caso de usos de análisis, es un análisis en detalle del caso de uso, para
poder encontrar todos los comportamientos y relaciones entre objetos y clases para cumplir
con estos casos de uso, para esto se usan los diagramas de comunicación y secuencia.

Los paquetes de análisis nos sirven para poder empaquetar ya encerrar los tipos de clases de
análisis fabricados en este workflow.

¿Como está compuesto un objeto?

Un objeto tiene una identidad, que nos permite
diferenciar un objeto de otro, tiene
comportamiento que es lo que puede hacer este
objeto y como ultimo tiene el estado que es:
Estado= Atributo+ valor
( en un momento de tiempo )
Los atributos que en los que nos centramos en la construcción de este modelo, son los
atributos variables, que al cambiar su valor hacen que el objeto se comporte de forma
diferente.

Máquina de estados:
Es un grafo de estado y transiciones. Esta está vinculada a una clase y describe la respuesta de
una instancia de la clase a los eventos que recibe. La máquina de estados modela todas las
posibles historias de vida de un evento de una clase. Cuando el objeto detecta un evento
responde de una manera dependiendo de su estado actual.

 Evento: un evento es un tipo de ocurrencia significativa que tiene lugar en un tiempo y

espacio. Se modela si su ocurrencia tiene consecuencias. Estos pueden tener
parámetros que caractericen la ocurrencia de un evento individual. Se pueden separar
en diferentes tipos: eventos de señal, llamada, cambio, tiempo.
 Estado: una máquina de estados se define como un conjunto de estados con un
nombre, estos son unidos mediante transiciones que conectan dos estados. Un estado
puede tener tres formas. La primera forma es un conjunto de valores similares en
cierta forma, o un objeto en espera de un vento, o un periodo de tiempo donde el
objeto realiza un a actividad.

 Transición: es la respuesta de un objeto en un estado a una ocurrencia de un evento.

La transición este compuesto por un evento, una condición de guarda, un efecto y un
estado destino.

 Pseudo estados: es un estado concreto o de inicio o final

 Estados compuestos: un estado simple no tiene estructura interna, solo un conjunto
de transiciones y posibles actividades de entrada y salida. Un estado compuesto es
aquel que se ha descompuesto en regiones las cuales contienen uno o más sub
estados directos.
Diagrama de comunicación y diagrama de clases de análisis:
Un diagrama de comunicación es una herramienta usa da en la vista dinámica de las
realizaciones de caso de uso (obtenidas en el workflow de requerimientos), es una parte del
modelo de análisis, es decir el modelado de la solución. Del modelo de requerimientos se hace
uso de los casos de uso y la vista de clases del dominio del problema. Con estos dos recursos
podemos sacar la información necesaria para hacer nuestro diagrama de comunicación.

Clases de análisis:
En este caso por el uso de estereotipo, se crearon estos nuevos tipos de clases de análisis, que
están estereotipados. Es decir que estas clases no son parte de UML, pero son usadas para el
dominio de la solución y en esta ocasión son estandarizadas por la comunidad de uso de UML.

Visibilidad:
Para que un objeto pueda comunicarse con otro debe verlo, es decir tener visibilidad sobre el.
Existen dos tipos de visibilidad:

 Visibilidad de atributos: es cuando una clase tiene un atributo referencial, es decir que
su atributo es una referencia a un objeto de otra clase. De esto tiene acceso a los datos
del objeto referenciado y se puede interactuar o comunicarse con otro. Esto es una
relación o visibilidad estructural, por asociación, agregación o composición.
  Visibilidad de parámetros: es una visibilidad dinámica, la cual solo existe en tiempo de
ejecución, es menos acoplado. En este caso la visibilidad solo se puede hacer cuando el
objeto “B” se manda a si mismo por parámetro a “A” para que este se pueda
comunicar con él, es decir que se podrá dar una relación A->B siempre que exista una
relación B->A, y se pueda mandar a si mismo como referencia por parámetros para
que el otro objeto lo pueda usar.

Diagrama de comunicación:
Un diagrama de comunicación modela los objetos y enlaces involucrados en la implementación
de una interacción e ignora el resto. En este se ven todos los enlaces entre los objetos
involucrados en el contexto.

Los mensajes se muestran mediante flechas etiquetadas, cada mensaje tiene un numero de
secuencia y como opcional una condición. También posee la dirección o flujo del mensaje. Este
mensaje que esta enviado tiene que estar presente en los métodos del objeto receptor.

También los mensajes pueden tener un “*” que los precede, esto es decir que se ejecuta más
de una vez o en todos los objetos.

Siempre hay un actor presente en el sistema, que es el que interactúa o da origen al caso de
uso.

Diagrama de secuencia:
Esta muestra la interacción de objetos en colaboración para un caso de uso. Cada objeto o rol
tiene un título de cabecera y una línea vertical, la cual es discontinua indicando el tiempo de
vida del objeto, cuando el objeto se encuentra en tiempo de ejecución de un procedimiento la
línea será doble. La relación entre los objetos y sus líneas de tiempo de vida, se hace mediante
los mensajes. En el caso particular de esta materia no graficamos los mensajes de respuesta.
Un mensaje es graficado como una flecha desde la línea de vida de un objeto a la línea de vida
de otro. estas flechas se organizan cronológicamente hacia abajo del diagrama. Los mensajes
asíncronos se grafican con una flecha de punta abierta y los síncronos de punta cerrada.

la principal diferencia entre este diagrama y el anterior, es que este se centra solo en los
mensajes, mientras que el anterior se encargaba de los enlaces.
Este diagrama de secuencia muestra las interacciones entre líneas de vida como una secuencia
de eventos ordenada en el tiempo. Y esta más centrada en el envío de mensajes.

Estructuras de control:
Tenemos estructuras de control, para poder hacer más claro o dar funcionalidades al diseño, el
único que compete a esta materia es el Frame de loop. Los Frame encierran un parte del
diseño de secuencia y especifica ciertas características o actividades dentro de ese marco. En
este caso el frame de loop se hace referencia que una parte del diseño se ejecutara en bucle
hasta recorrer todos los objetos o cumplir una condición.

Proceso Unificado de Desarrollo

Es un conjunto de actividades o procesos o tareas que logran transformar los requerimientos
de un cliente en un sistema de SW. El proceso unificado (PUD): Es un marco de desarrollo de
software. Se define como un entorno genérico de proceso que se puede especializar según las
necesidades que tengamos en cada proyecto. Es un proceso de desarrollo de software que
utiliza UML para preparar todos los esquemas de un sistema de software.

Características:
 Dirigido por CU: se utilizan para establecer el comportamiento deseado del sistema,
para verificar y validar la arquitectura del sistema, para las pruebas y para la
comunicación entre las personas involucradas en el proyecto. Los CU guían el proceso
de desarrollo. Los CU se utilizan para capturar los requerimientos para desarrollarlos a
través de los distintos WF en las distintas fases. El CU que mapea un requerimiento, lo
llevamos como hilo conductor a lo largo de todos los WF del proceso, manteniendo
una trazabilidad (responde al cliente sobre cierto requerimiento en qué etapa se
encuentra, en que se transformó, nivel de avance)
 Centrado en la arquitectura: se utiliza para conceptualizar, construir, gestionar y hacer
evolucionar el sistema en desarrollo. Nos da una visión general de que puede y no
puede hacer el sistema, que es utilizado como cimiento. Se avanza con vistas
 arquitectónicas desde el WF de Requerimientos. Vamos haciendo evolucionar el sw
teniendo en cuenta a la arq desde el 1er momento.
 Iterativo: involucra la gestión de un flujo de versiones ejecutables. Repite el proceso de
trabajo
 Incremental: se integran las versiones, y cada nuevo ejecutable incorpora mejoras
incrementales sobre los otros. Evolución del producto

Iterativo e incremental, ¿Que es? Es el ciclo de vida que el proceso unificado de desarrollo
(PUD) recomienda. Tiene fases, las cuales identifican los momentos de evolución del proyecto,
se trabaja con iteraciones, que entregan una versión del producto. Tenemos la libertad de
elegir otro ciclo de vida, un proceso se puede trabajar con diferentes ciclos de vida.

Dirigido por casos de uso y centrado en la arquitectura van de la mano, xq la funcionalidad y la

arquitectura se condicionan entre sí, a veces un RNF determina que la arquitectura se
comporte de una determinada manera u otra. Ej: q el sistema sea web o Mobile, cliente liviano
(no se debe instalar nada), es un RNF que impacta en la arquitectura.

Otra característica del PUD, es que cada WF genera como salida un modelo. El WF de diseño
nos entrega 2 modelos, uno que se centra en el software (modelo de diseño) y otro en el
hardware (modelo de despliegue), que hace falta para darle soporte al sw que diseñamos.
Nosotros no diseñamos hw, se encarga de la distribución de componentes de sw en que
elementos de hw lo vamos a alojar.

Fases: intervalo de tiempo entre dos hitos importantes del proceso, muestran/determinan
momentos de evolución del producto en el proyecto.

1. Inicio: contribuye a la planificación de los incrementos. El momento de evolución para

salir del inicio y entrar a la fase de elaboración es cuando tiene claro el dominio del
problema.
2. Elaboración: se especifican en detalle la mayoría de los CU (requerimientos) y se
diseña la arquitectura. Contribuye a obtener una estructura robusta y estable, facilita
una comprensión más profunda de los requerimientos
3. Construcción: se crea el producto.
4. Transición: el producto se convierte en versión beta. Un número reducido de usuarios
con experiencia lo prueba e informa los defectos y deficiencias. Los desarrolladores los
corrigen e incorporan mejoras.

Iteración: conjunto bien definido de actividades, con un plan y criterios de evaluación bien
establecidos, que acaba en un sistema que puede ejecutarse, probarse y evaluarse.

Modelo de Análisis:
En este modelo se analizan los requisitos que se describieron en la captura de requerimientos,
refinándolos y estructurándolos, para conseguir una compresión mas precisa de los requisitos
y una descripción de los mismos que sea fácil de mantener y nos ayude a estructurar el sistema
entero.

Ósea que lo fundamental del modelo de análisis es resolver los casos de usos analizando los
requisitos con mayor diferencia, y con su principal diferencia es que el enfoque esta dado
desde el lenguaje de los desarrolladores, con mayor formalización.

Este empieza al final de la fase de inicio y es foco principal de la fase de elaboración. En esta
fase la mayor parte de la actividad va sobre crear modelos que capturan el comportamiento.
El workflow de análisis se centra en que hay que hacer, pero deja el cómo al workflow de
diseño. El límite entre estos dos workflow suele ser bastante vago.

En consecuencia, se analizan aspectos internos al sistema y se estructuran los requerimientos

de manera que facilite su comprensión, preparación, modificación y su mantenimiento. La
estructura está centrada en el mantenimiento y en aspectos como la flexibilidad ante cambios
y reutilización.

El modelo de análisis hace abstracciones y evita resolver algunos problemas y tratar algunos
requerimientos que pensamos que es mejor en posponer al diseño y a la implementación. Por
ello, no siempre se puede conservar la estructura proporcionada por el análisis, ya que el
diseño debe considerar la plataforma de implementación: lenguaje de programación, sistemas
operativos, frameworks, sistemas heredados, etc.

El modelo de análisis, también nos ayuda a estructurar los requerimientos y nos proporciona
una estructura centrada en el mantenimiento, en aspectos tales como la flexibilidad ante los
cambios y la reutilización. Esta estructura también sirve como entrada en las actividades de
diseño e implementación, ya que se trata de preservar dicha estructura mientras le damos
forma al sistema. Por esto, el modelo de análisis puede considerarse una primera
aproximación al modelo de diseño, aunque es un modelo por sí mismo.

Entonces algunos de sus principales características son:

 Descripto en el lenguaje del desarrollador.

 Vista interna del sistema.
 Estructurado por clases y paquetes estereotipados.
 Utilizado por los desarrolladores para saber cómo debería ser diseñado e
implementado el sistema.
 No contiene redundancias e inconsistencias entre requisitos.
 Explica como llevar a cabo las funcionalidades del sistema, primera aproximación al
diseño.
 Define realizaciones de caso de uso.

Desde la vista del proyecto se puede decir que su propósito es:

 Describir los resultados del análisis y mantener la consistencia de este modelo a lo

largo de toda la vida del software.


Objetivo del análisis:

 Especificación precisa de los requerimientos.
 Descripción con el lenguaje de los desarrolladores, es decir con un mayor formalismo y
se ve los funcionamientos internos del sistema.
 Estructura de los requisitos de modo que se facilita su comprensión, preparación,
modificación y mantenimiento.
 Es una primera aproximación del modelo de diseño, y es una entrada fundamental al
workflow de diseño, ya que debe ser mantenible el sistema en su conjunto y no solo la
descripción de sus requisitos.

Cuando hacer análisis

 Mediante la realización separada del análisis, en lugar de llevarlo a cabo como parte
integrada en el diseño y la implementación, podemos analizar sin grandes costes una
 gran parte del sistema. Se puede utilizar el resultado para planificar el trabajo de
diseño e implementación subsiguiente en varios incrementos sucesivos, donde cada
incremento sola diseña e implementa una pequeña parte del sistema, o quizá en varios
incrementos concurrentes.
 El análisis proporciona una visión más general del sistema que puede ser más difícil de
obtener mediante el estudio de los resultados del diseño y la implementación, debido
a que contienen demasiados detalles. Una visión general como esa puede ser muy
valiosa para recién llegados al sistema o para desarrolladores que en general
mantienen el sistema.
 Algunas partes del sistema tienen diseños y/o implementaciones alternativas. El
modelo de análisis puede proporcionar una vista conceptual, precisa y unificadora de
esas implementaciones alternativas.
 El sistema se construye utilizando un sistema heredado complejo. La reingeniería de
este sistema heredado, o de una parte él, puede hacerse en términos del modelo de
análisis de manera que los desarrolladores puedan comprender el sistema heredado
sin tener que profundizar en los detalles de su diseño e implementación, y construir el
nuevo sistema utilizando el heredado como un bloque de construcción reutilizable.

Papel del análisis en el ciclo de vida del software:

Las primeras iteraciones de este workflow se centran en el análisis, es decir tener una
arquitectura estable, sólida y que facilita la comprensión en profundidad. El propósito y
objetivo del análisis debe alcanzarse en al momento del proyecto. La maneta de emplear el
análisis se puede definir dependiendo el proyecto y se aplican 3 variantes básicas.

1. El proyecto utiliza el modelo de análisis para describir los resultados del análisis y
mantiene la consistencia de este a lo largo de todo el ciclo de vida del software. Esto
puede hacerse de manera continua en cada interacción del proyecto.
2. El proyecto utiliza el modelo de análisis para describir los resultados del análisis, pero
considera a este modelo como una herramienta transitoria e intermedia. Cuando el
diseño e implementación están en marcha, se deja de actualizar el análisis.
3. El proyecto no utiliza el modelo de análisis para describir los resultados del análisis. En
cambio, el proyecto analiza los requisitos como parte integrada en la captura de
requerimientos o diseño.

Artefactos:
Modelo de análisis:
El modelo de análisis es un sistema de análisis que denota el paquete de mas alto nivel del
modelo, es decir, las colaboraciones dentro del modelo del modelo de análisis de todos los
artefactos que este tiene. Es una forma de organizar el modelo de análisis en parte mas
manejables que representan abstracciones de subsistemas y capas completas del diseño.

Clases de análisis:
Es una abstracción de una o varias clases del diseño del sistema, dicha abstracción posee las
siguientes características:

 Se centra en el tratamiento de los requerimientos funcionales y pospone los no

funcionales.
 Una clase de análisis no define interfaz de operaciones, este se define mediante
responsabilidades, que son una descripción textual de un conjunto cohesivo del
comportamiento de una clase.
  La clase de análisis también define atributos de alto nivel, conceptuales y reconocibles
en el dominio del problema.
 Participa en relaciones, aunque estas son más conceptuales que las de diseño e
implementación.
 Estas siempre encajan en uno de los tres estereotipos básicos. Estos son
estandarizados en UML, y se utilizan para ayudar a los desarrolladores a distinguir el
ámbito de las clases.

Se puede decir que las clases de análisis capturaran atributos candidatos para las clases de
diseño. Las operaciones también se especifican en alto nivel y estas se convertirán en
operaciones en el diseño.

Las clases de análisis posen la siguiente estructura:

 Nombre
 Atributos
 Operaciones
 Visibilidad (generalmente no se muestra)
 Estereotipos
 Valores etiquetados

1. Clase de interfaz: se utilizan para modelar la interacción del sistema con sus actores.
Esto es recibir información y peticiones de los usuarios y los sistemas externos.
Este modela la parte del sistema que depende de sus actores, entonces son los límites
del mismo. Este representa abstracciones de ventanas, formularios, paneles, interfaces
de comunicación, impresoras etc.
 2. Clase de entidad: se utilizan para modelar información con una vida larga y que suele
ser persistente del sistema. En la mayoría de los casos, las clases de entidad se derivan
directamente de una clase de entidad del negocio (o de una clase del dominio). Una
diferencia fundamental entre clases de entidad y clases de entidad de negocio es que
las primeras consideran objetos manejados por el sistema. En consecuencia, las clases
de entidad reflejan la información de un modo que beneficia a los desarrolladores al
diseñar e implementar el sistema, incluyendo su soporte de persistencia. Modelan
información relevante para el dominio y que dura en el tiempo, siendo candidatas a
ser persistentes mediante bases de datos. Suelen tener comportamiento complejo
relativo a la información que representan, de esta forma aíslan los cambios en la
información.
3. Clases de control: Representan coordinación, secuencia, transacciones y control de
otros objetos y se usan con frecuencia para encapsular el control de un caso de uso
concreto. También suelen ser derivaciones y cálculos concretos.
Los aspectos dinámicos del sistema se modelan con clases de control, debido a que
ellas manejan y coordinan las acciones y los flujos de control principales, y delegan
trabajo a otros objetos. Son el nexo entre las clases de entidad y de interfaz, ya que
éstas no se relacionan directamente
Realización de caso de usos:
Es una colaboración dentro del modelo de análisis que describe como se lleva a cabo y se
ejecuta un caso de uso determinado en termino de las clases de análisis y sus objetos en
interacción. Posee una descripción textual del flujo de sucesos, diagramas de clases que
muestran sus clases de análisis participantes y diagramas de interacción que muestra la
realización de un flujo o escenario particular en termino de interacciones de objetos de
análisis. Es decir que la realización de casos de uso consta de conjuntos de clases que realizan
el comportamiento especificado en un caso de uso. Convirtiendo un caso de uso en una
especificación funcional, en diagramas de clases y diagramas de interacción, que son una
especificación de alto nivel del sistema.

Se centra en los requisitos funcionales, dejando los RNF para el diseño e implementación.

La realización de casos de uso consta básicamente en tomar una especificación y requisitos

asociados y modela como se puede realizar esto por interacción entre instancias de las clases
de análisis identificadas.

Las interacciones son unidades de comportamiento para demostrar como el comportamiento

especificado por el acaso de uso se puede realizar por instancias de calases de análisis pasando
mensajes de uno a otro.

Las líneas de vida representan un solo participante o instancia de una clase en una interacción.

Los mensajes representan un tipo específico de comunicación entre dos líneas de vida. Cuando
una línea de vida recibe una llamada esta es una petición para invocar a una operación que
tiene la misma que recibe el mensaje.

Diagrama de clases: unas clases de análisis y sus objetos normalmente participan en varias
realizaciones de casos de uso. Es importante durante el análisis coordinar todos los requisitos
sobre unas clases y sus objetos que pueden tener diferentes casos de uso, para eso
adjuntamos diagramas de clases a las realizaciones de caso de uso mostrando sus participantes
y relaciones.
Diagramas de interacción: la secuencia de acciones comienza cuando un actor invoca el caso
de uso mediante él envió de algún tipo de mensaje al sistema, el objeto de interfaz recibirá el
mensaje del actor y lo enviara a algún otro objeto y los objetos implicados interactuaran para
llevar a cabo el caso de uso. En estos diagramas de colaboración mostramos las interacciones
entre objetos creando enlaces entre ellos y añadiendo mensajes a estos enlaces. Existen 4
tipos de diagramas de interacción, pero nos centraremos en 2. Los cuales están especificados
más arriba.

Paquete de análisis:
Proporcionan un medio para organizar los artefactos del modelo de análisis en piezas
manejables. Estos tienen que ser cohesivos, y débilmente acoplados. Y tienen las siguientes
características:

 Sirven para representar una separación de intereses de análisis.

 Se deben crear basándose en los requisitos funcionales y el dominio del problema,
y ser reconocibles por los conocedores del domino.
 Estos se convierten en subsistemas en las dos capas de aplicación superiores del
modelo de diseño. Y podrían llegar a reflejar una capa completa del primer modelo
de diseño.

Cada paquete debe tener su propio espacio de nombre y debe ser único.

Descripción de la arquitectura:
Este contiene una vista de la arquitectura del modelo de análisis. Que muestra sus artefactos
significativos para la arquitectura. Como los siguientes:

 La descomposición del modelo de análisis en paquetes y sus dependencias.

 Las clases fundamentales del análisis.
 Las realizaciones de caso de uso que describen una funcionalidad importante y critica,
es decir que tienen una cobertura amplia y muchas clases de análisis y generalmente
se encuentran al principio del ciclo de vida del software.

Trabajadores:
Arquitecto:
Es el responsable de la integridad del modelo, garantizando que este sea correcto consistente
y legible como un todo, esto puede requerir mantenimiento tras varias iteraciones en sistemas
grandes, y puede llegar a delegar esta tarea, pero sigue bajo su responsabilidad. El modelo de
análisis es correcto cuando realiza la funcionalidad descripta en el modelo de casos de uso.

Es responsable también de la arquitectura del modelo de análisis, es decir la existencia de sus

partes significativas para la arquitectura como tal.

no es responsable del desarrollo y mantenimiento continuo de los diferentes artefactos, esto

se encargan los otros trabajadores.

Ingeniero de casos de uso:

Es el responsable de la integridad de las realizaciones de caso de uso, y garantizando que se
cumplen los requisitos de los mismos.

La realización de casos de uso debe garantizar las descripciones textuales y diagramas son
legibles y se corresponden con el objetivo del caso de uso.
No es responsable de las clases de análisis ni las relaciones del caso de uso.

Este es entonces el responsable tanto en el análisis como en el diseño de los casos de uso.

Ingeniero de componentes:
Define y mantiene las responsabilidades, atributos, relaciones y requisitos de las clases de
análisis asegurándose que cada clase cumple con los requisitos que se esperan de acuerdo a
las realizaciones de caso de uso en las que participa.

También es el encargado de mantener la integridad de los paquetes de análisis, garantizando

que sus contenidos son correctos y dependencias también.

Flujo de trabajo:

Los arquitectos empiezan con la creación del modelo de análisis y los ingenieros de caso de uso
realizan cada caso de uso en termino de clases de análisis exponiendo los requisitos y
comportamientos de cada clase. El ingeniero de componentes especifica estos requerimientos
y crea las responsabilidades, atributos y relaciones de clases de análisis. Y posteriormente se
encargará de los paquetes de análisis.

1. Los arquitectos comienzan con la creación del modelo de análisis, identificando los
paquetes de análisis principales, las clases de entidad evidentes y los requerimientos
comunes.
2. Los ingenieros de caso de uso realizan cada caso de uso en término de las clases de
análisis participantes exponiendo los requerimientos de comportamiento de cada
clase.
3. Los ingenieros de componentes especifican estos requerimientos de comportamiento
y los integran dentro de cada clase creando responsabilidades, atributos y relaciones
consistentes para cada clase.
4. Durante el análisis, los arquitectos identifican de manera continua nuevos paquetes de
análisis, clases y requerimientos comunes a medida que el modelo evoluciona, y los
ingenieros de componentes refinan y mantienen continuamente los paquetes del
análisis.
Análisis de la arquitectura:

Sirve para esbozar el modelo de análisis y la arquitectura mediante los siguientes pasos:

 Identificación de paquetes de análisis: proporcionan un medio para organizar el

modelo de análisis organizar el modelo de análisis en piezas mas pequeñas y
manejables. Esto se hace de manera natural basándonos en los requisitos funciones y
dominio del problema, que nos ayudan a separar en paquetes de análisis. Para ello, se
asigna un número de casos de uso a un paquete y luego se realiza la funcionalidad
correspondiente a ese paquete.
 Identificación de clases de entidad obvias: se hace una propuesta preliminar de las
clases de entidad más importantes, basándonos en las clases del dominio o entidades
del negocio.
 Identificación de requisitos especiales comunes: son requisitos que parecen durante
el análisis y es importante anotar de forma que pueda ser tratado adecuadamente en
las subsiguientes actividades de diseño e implementación.
Analizar un caso de uso:

 Identificación de clases de análisis: identificamos las clases de control, entidad e

interfaz necesarias para realizar los casos de uso y esbozamos sus nombres
responsabilidades, atributos y relaciones. Los casos de uso no siempre están lo
suficientemente detallados para identificar todas las clases de análisis. Por lo tanto,
puede que en esta etapa tengamos que refinar las descripciones de los casos de uso en
lo referente al interior del sistema.
 Descripción de interacciones entre objetos del análisis: acá describimos como
interactúan los correspondientes objetos de análisis, mediante diagramas de
colaboración que contienen las instancias de sus actores y objetos de análisis y
enlaces. Esto se hace para cada flujo o subflujos del caso de uso.
 Captura de requisitos especiales: en este caso recogeremos todos los requisitos sobre
una realización de casos de uso que se identifican en el análisis, pero deberían tratarse
en el diseño e implementación, como los requisitos no funcionales.
Analizar una clase:
  Identificar responsabilidades: las responsabilidades de una clase pueden recopilarse
combinando todos los roles que cumple en diferentes realizaciones de caso de uso.
Esto se hace mediante el estudio de los diagramas de clase e interacción.
 Identificación de atributos: un atributo especifica una propiedad de una clase de
análisis, y es necesaria para las responsabilidades de su clase y debemos agregarlas.
 Identificación de asociaciones y agregaciones: el ingeniero de componentes deberá
estudiar los enlaces entre objetos empleados en los diagramas de colaboración para
determinar que asociaciones son necesarias.
 Identificación de generalizaciones: las generalizaciones deben usarse en el análisis
para extraer comportamiento compartido y común entre varias clases de análisis, y
debe ser en un alto nivel y conceptual.
 Captura de requisitos especiales: recogeremos todos los requisitos de una clase de
análisis que se han identificado en el análisis, pero deben tratarse en el diseño e
implementación.

Analizar un paquete:

 Garantizar que el paquete de análisis es tan independiente de otros paquetes como

sea posible.
 Garantizar que el paquete cumple con su objetivo de casos de uso.
 Describir las dependencias de forma que pueda estimarse el efecto de los cambios
futuros.

Patrones GTASP:
Los patrones GRASP constituyen un apoyo para la enseñanza que ayuda a uno a entender el
diseño de objetos esencial y aplica el razonamiento para el diseño de una forma sistemática,
racional y explicable. Este enfoque para la comprensión y utilización de principios de diseño se
basa en los patrones de asignación de responsabilidades.

La asignación de responsabilidades es extremadamente importante en el diseño de objetos. La

decisión acerca de la asignación de responsabilidades, a menudo tiene lugar en la creación de
diagramas de interacción y con seguridad durante la programación. Los patrones son pares
problema/solución, con un nombre que codifican buenos consejos y principios relacionados
con frecuencia con la asignación de responsabilidades.
Es importante aplicar estos principios durante la creación de diagramas de interacción ya que
permiten construir una base de cómo se diseñará el sistema.

GRASP es General Responsibility Assignment Software Pattersns.

Los patrones que conoceremos son 5:

 Experto.
 Creador
 Alta cohesión
 Bajo acoplamiento
 Controlador

Experto:
Creador:
Bajo Acoplamiento:
Alta Cohesión:
Controlador: