Taller

resumen del libro de uml EL PROCESOS UNIFICADO DE DESARROLLO DE

SOFWARE

Aprendices

Daymer David Salazar Castillo

Jair André Mejía Ramírez

Ángel David Gómez Boada

ADSI

FICHA

1761282

Instructor

Pedro Ariza

SERVICIO NACIONAL DE APRENDIZAJE SENA

CENTRO DEL DESARROLLO RURAL Y MINERO – CEDRUM

TECNOLOGÍA ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACION

CÚCUTA 2020
CAPITULO 3 UN PROCESOS DIRIGIDO POR CASOS DE USOS
Unos de los objetivos del proceso unificado es la guiacion para los desarrolladores para una
implementación de distribución de eficiencia de un sistema que se ajusta a las necesidades
del cliente una de las eficiencias con la que se mide en términos de coste, calidad, y tiempo
de desarrollo uno de los pasos de la determinación de las necesidades de un cliente hasta la
implementación del usuario de formar que puedan comunicarse fácilmente a todas las
personas de discernir esto nos obliga a que tengamos algún modo de capturar las
necesidades de forma que se pueda comunicarse fácilmente con todas las personas
implicadas en el proyecto . Después debemos ser capaces de diseñar una implementación
funcional que se ajusta esas necesidades debemos verificar que las necesidades del cliente
se han cumplido totalmente mediante pruebas del sistema a estas complejidades, el proceso
se describe como una serie de flujos de trabajo que se construyen mediante el sistema
gradualmente.

3.1 desarrollo dirigido por casos de uso en pocas palabras

Los desarrolladores crean un modelo de análisis que utiliza el modelo de casos de uso como
entrada. Cada caso de uso en el modelo de casos de uso se traducirá en una realización de
caso de uso en el modelo de análisis. La dualidad caso de uso realización de caso de uso
es la base de una trazabilidad directa entre los requisitos y el análisis. Tomando los
casos de uso uno a uno, los desarrolladores pueden identificar las clases que participan
en la realización de los casos de uso. Por ejemplo, el caso de uso Sacar Dinero puede
realizarse por parte de las clases

3.2 Porque Casos De Usos

Proporcionan un medio
sistemático e intuitivo de
capturar requisitos
funcionales centrándose en el valor
añadido para el usuario.
 Dirigen todo el proceso de
desarrollo debido a que la
mayoría de las
actividades como el análisis, diseño
y prueba se llevan a cabo partiendo
de los
casos de uso. Esta característica es
aún más evidente cuando la
arquitectura
se ha estabilizado en el proyecto.
después del primer conjunto de
iteraciones
1. Proporcionan un medio sistemático e intuitivo de capturar requisitos
funcionales centrándose en el valor añadido para el usuario.
2. Dirigen todo el proceso de desarrollo debido a que la mayoría de las
actividades como el análisis, diseño y prueba se llevan a cabo partiendo de los casos de uso.
Esta característica es aún más evidente cuando la arquitectura se ha estabilizado en el
proyecto. Después del primer conjunto de iteraciones
3.2.1 para capturar los requisitos que aportan valor añadido
La idea de caso de uso permite la identificación del software que cumple con los objetivos
del usuario. Los casos de uso son las funciones que proporciona un sistema para añadir
valor a sus usuarios. Tomando la perspectiva de cada tipo de usuario, podemos capturar
los casos de uso que necesitan para hacer su trabajo. Por otro lado, si comenzamos
pensando en un conjunto de buenas funciones del sistema sin pensaren los casos de uso
que emplean los usuarios concretos, será difícil decir si esas funciones son importantes o
incluso si son buenas.
3.2.2 para dirigir el proceso
Los casos de uso no sólo inician un proceso de desarrollo, sino que lo enlazan. También
tenemos que estar seguros de que capturamos los casos de uso correctos de forma que los
usuarios obtengan los que realmente quieren. La mejor forma de conseguir esto es, por
supuesto, hacer un buen trabajo durante el flujo de los requisitos.

3.3.3 para idear la arquitectura y más

Los casos de uso también nos ayudan a idear la arquitectura. Mediante la selección del
conjunto correcto de casos de uso los casos de uso significativos arquitectónica mente para
llevarlo a cabo durante las primeras iteraciones, podemos implementar un sistema con una
arquitectura estable, que pueda utilizarse en muchos ciclos de desarrollo
subsiguientes
3.3 la captura de casos de uso
3.3.1 el modelo de casos de uso representa los requisitos funcionales
La captura de casos de uso El modelo de casos de uso representa los requisitos funcionales
El modelo de casos de uso ayuda al cliente, a los usuarios y a los desarrolladores allegar a
un acuerdo sobre cómo utilizar el sistema.
1. La mayoría de los sistemas tienen muchos tipos de usuarios.
2. Cada tipo de usuario se representa mediante un actor.
3. Los actores utilizan el sistema al interactuar con los casos de uso.
3.3.2 los actores son el entorno del sistema
Los actores se comunican con el sistema mediante el envío y recepción de mensajes hacia y
desde el sistema según éste lleva a cabo los casos de uso. A medida que definimos lo que
hacen los actores y lo que hacen los casos de uso, trazaremos una clara separación entre
las responsabilidades de los actores y las del sistema. Esta separación nos ayuda a
delimitar el alcance del sistema
3.3.3 los casos de uso especifican el sistema
Identificamos los casos de uso examinando cómo los usuarios necesitan utilizar el
sistema para realizar su trabajo {para un modo de estructurar los casos de uso basado en
objetivos. Cada uno de esos modos de utilizar el sistema que añaden valor al usuario es un
caso de uso candidato.
3.4 análisis diseño e implementación para realizar los casos de uso
3.4.1 creación del modelo de análisis a partir de los casos de uso
En los modelo de análisis crece incrementalmente a medida que se analizan más y más
casos de uso. En cada iteración, elegimos un conjunto de casos de uso y los reflejamos en el
modelo de análisis. Construimos el sistema como una estructura de clasificadores (clases de
análisis) y relaciones entre ellas.

3.4.2 cada clase debe cumplir todo sus roles de colaboración

Los desarrolladores responsables de analizar y realizar los casos de uso son
los responsables de especificar los roles de las clases. Un desarrollador responsable de una
clase agrupa todos los roles de la clase en un conjunto completo de
responsabilidades para la clase, y después los integra en un conjunto consistente de
responsabilidades
3.4.3 creación del modelo de diseño a partir del modelo de análisis
De igual forma que el modelo de análisis, el modelo de diseño también
define clasificadores (clases, subsistemas e interfaces), relaciones entre esos clasificadores,
y colaboraciones que llevan a cabo los casos de uso (las realizaciones de casos de uso).Sin
embargo, los elementos definidos en el modelo de diseño son las “contra partidas de
diseño” de los elementos, más conceptuales, definidos en el modelo de análisis,
3.4.4 los subsistemas agrupan a las clases
Los subsistemas pueden diseñarse descendente o ascendentemente. Cuando se hace de
manera ascendente, los desarrolladores proponen subsistemas basados en las clases que ya
han identificado; proponen subsistemas que empaquetan las clases en unidades con líneas
funciones claramente definidas.

3.4.5 creación del modelo de implementación a partir del modelo de diseño

Durante el flujo de trabajo de implementación desarrollamos todo lo necesario para obtener
un sistema ejecutable: componentes ejecutables, componentes de fichero (código fuente,
guiones Shell. etc.), componentes de tabla (elementos de la base de datos), etc.
 3.5 prueba de los casos de uso

Los procedimientos de prueba también pueden derivarse de los casos de uso. Los
defectos hallados se analizan para localizar' el problema. Después estos problemas
se priorizan y se corrigen por orden de importancia

Los procedimientos de prueba

también pueden derivarse de los
casos de uso. Los
Los procedimientos de prueba
también pueden derivarse de los
casos de uso. L
1.6 Resumen

En Las Líneas de la arquitectura desarrolladoras en las fases de elaboración

sobrevive n forma de una descripción de la arquitectura esta descripción se obtiene
de versiones de los diferentes modelos que son resultado de la fase de elaboración
como se obtiene muestras la descripción de la arquitectura es un extracto o en
nuestros términos

CAPITULO 4 UN PROCESO CENTRADO EN LA ARQUITECTURA

El cual se enfoca principalmente en más cosas para conseguir un sistema de trabajo. Esas
“cosas" son la arquitectura. Podemos pensar que la arquitectura de un sistema es la
visión común en la que todos los empleados (desarrolladores y otros usuarios) deben estar
de acuerdo, o como poco, deben aceptar. La arquitectura nos da una clara perspectiva del
sistema completo, necesaria ¡rara controlar el desarrollo. En consecuencia, necesitamos una
arquitectura que describa los elementos del modelo
4.1 la arquitectura en pocas palabras
La arquitectura software está afectada no sólo por la estructura y el
Comportamiento, sino también por el uso, la funcionalidad, el rendimiento, la
Flexibilidad, la reutilización, la facilidad de comprensión, las restricciones y
Compromisos económicos y tecnológicos, y la estética.

En La arquitectura software abarca decisiones importantes sobre:

1. La organización del sistema software.
2. Los elementos estructurales que compondrán el sistema y sus interfaces, junto con sus
comportamientos, tal y corno se especifican en las colaboraciones entre estos elementos

4.2 porque es necesaria la arquitectura

Uno de los sistema software grande y complejo requiere una arquitectura para que
los desarrolladores puedan progresar hasta tener una visión común. Un sistema software es
difícil de abarcar visualmente porque no existe en un mundo de tres dimensiones. Es a
menudo único y sin precedente en determinados aspectos

4.2.1 compresión del sistema

Para que una organización desarrolle un sistema, dicho sistema debe ser comprendido por
todos los que vayan a intervenir en él. El hacer que los sistemas modernos sean
comprensibles es un reto importante por muchas razones:
1. Abarcan un comportamiento complejo.
2. Operan en entornos complejos.
3. Son tecnológicamente complejos.
4. A menudo combinan computación distribuida, productos y plataformas comerciales y
reutilizan componentes y mareos de trabajo.
5. Deben satisfacer demandas individuales y de la organización. Dividir el trabajo de
desarrollo en varios proyectos, que están a menudo separados geográficamente.
4.2.2 organización del desarrollo
Es la que define explícitamente estas interfaces, haciendo
Que sea posible la reducción en la comunicación. Una interfaz bien definida “comunica"
Eficientemente a los desarrolladores de ambas partes que necesitan saber sobre lo que
Los otros equipos están haciendo

4.2.3 fomento de reutilización

Como el fontanero, los desarrolladores capaces de reutilizar conocen el dominio del
Problema y qué componentes especifica como adecuados la arquitectura. Los
Desarrolladores piensan en cómo conectar esos componentes para cumplir con los
Requisitos del sistema y realizar el modelo de casos de uso

4.2.4 evolución del sistema

Una de las evoluciones del sistema es de que cualquier sistema de un

Tamaño considerable evolucionará. Evolucionará incluso aunque aún este en
Desarrollo. Más tarde, cuando esté en uso, el entorno cambiante provocará futuras
Evoluciones.

4.3 caso de uso y arquitectura

Uno de los caso de uso y la arquitectura es que se construye una arquitectura que nos
permita implementar los casos de uso de una forma económica, ahora y en el futuro

4.4 los pasos hacia una arquitectura

La línea base de la arquitectura es un sistema “pequeño y flaco”

Este sistema tiene las versiones de todos los modelos que un sistema terminado
contiene al final de la fase de construcción. Incluye el mismo esqueleto de subsistemas,
componentes y nodos que un sistema definitivo, pero no existe toda la musculatura. No
obstante, contiene comportamiento y código ejecutable.