El documento describe 13 tipos de diagramas UML, incluyendo diagramas de clases, componentes, objetos, estructura compuesta, despliegue, paquetes, actividades, casos de uso, estados, secuencia, comunicación, tiempos y de interacciones globales. También describe los principios y características del desarrollo ágil de software, como iteraciones cortas, colaboración con el cliente, respuesta al cambio y calidad desde el inicio.

1. Materia
DISEÑO DE SISTEMAS
Nombre Profesor
RENE DOMINGUEZ ESCALONA
Ingeniería en Software
Sistema Dual
7to Cuatrimestre
HERRERA MARTÍNEZ GUSTAVO URIEL
14140530039

2. 13 tipos de diagramas UML
Diagrama de clases
Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema
mostrando sus clases, atributos y las relaciones entre ellos.Los diagramas de clases son utilizados
durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la
información que se manejará en el sistema, y los componentes que se encargaran del
funcionamiento y la relación entre uno y otro.
Diagrama de componentes
Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado.
Un diagramade componentesrepresentacómounsistemade softwareesdivididoencomponentes
y muestra las dependencias entre estos componentes.Los componentes físicosincluyenarchivos,
cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de
Componentesprevalecenenel campode laarquitecturade software,peropuedenserusadospara
modelar y documentar cualquier arquitectura de sistema.

3. Diagrama de objetos
Los diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de los sistemas
informáticos en la metodología UML.
Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias
específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos
utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no
muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.
Una diferenciaconlosdiagramasde claseesque elcompartimientode arribavaenlaformaNombre
de objeto: Nombre de clase.
Por ejemplo, Miguel: Persona.

4. Diagrama de estructura compuesta
Un diagramade estructuracompuestaesuntipode diagramade estructuraestáticaenel Lenguaje
de ModeladoUnificado (UML), que muestrala estructurainternade una clase y lascolaboraciones
que estaestructura hace posibles.Estopuede incluirpartesinternas,puertasmediante lascuales,
las partes interactúan con cada una de las otras o mediante las cuales, instancias de la clase
interactúan con las partes y con el mundo exterior, y conectores entre partes o puertas. Una
estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempode
ejecuciónparalograralgúnpropósito.Cadaelementotiene algún rol definido en la colaboración.
Diagrama de despliegue
El Diagramade Despliegueesuntipode diagramadelLenguajeUnificadode Modeladoque seutiliza
para modelarel hardware utilizadoenlasimplementacionesde sistemasylasrelacionesentre sus
componentes.
Los elementos usados por este tipo de diagrama son nodos (representados como un prisma),
componentes(representadoscomounacajarectangularcondosprotuberanciasdel ladoizquierdo)
y asociaciones.
En el UML 2.0 loscomponentesyanoestándentrode nodos.En cambio,puede haberartefactosu
otros nodos dentro de un nodo.

5. Diagrama de paquetes
En el Lenguaje Unificado de Modelado, un diagrama de paquetes muestra cómo un sistema está
dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que
normalmente unpaqueteestápensadocomoundirectorio,losdiagramasde paquetessuministran
una descomposición de la jerarquía lógica de un sistema.
Los Paquetesestánnormalmente organizadosparamaximizarla coherenciainternadentrode cada
paquete y minimizar el acoplamientoexterno entre los paquetes. Con estas líneas maestras sobre
la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un
individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo
requerido.
Diagrama de actividades
En el Lenguaje de ModeladoUnificado,undiagramade actividadesrepresentalosflujosde trabajo
paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de
Actividades muestra el flujo de control general.
En SysML el diagrama de Actividadeshasidoextendidoparaindicarflujosentre pasosque mueven
elementos físicos (e.g., gasolina) o energía (e.g., presión). Los cambios adicionales permiten al
diagrama soportar mejor los flujos de comportamiento y datos continuos.

6. Diagrama de casos de uso
En el Lenguaje de ModeladoUnificado,undiagramade casosde usoesunaespecie de diagramade
comportamiento.
El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso
llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa
los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de
un caso de uso; sin embargo, una notación gráfica puede solo dar una vista general simple de un
caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo
confundidosconloscasos de uso.Mientras los dos conceptosestánrelacionados,loscasosde uso
son mucho más detallados que los diagramas de casos de uso.

7. Diagrama de estados
En UML, un diagrama de estados es un diagrama utilizadopara identificar cada una de las rutas o
caminos que puede tomar un flujo de información luego de ejecutarse cada proceso.
Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y en qué momento
podrían tener una variación.
El diagrama de estadospermite visualizarde una forma secuencial laejecuciónde cadauno de los
procesos.
Diagrama de secuencia

8. El diagrama de secuenciaesun tipo de diagrama usado para modelarinteracciónentre objetosen
un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace
diagrams", "event scenarios" o "timing diagrams"
Diagrama de comunicación
En el Lenguaje Unificado de Modelado (UML) 2.0, un diagrama de comunicación es una versión
simplificada del diagrama de colaboración de la versión de UML 1.x.
Un diagrama de comunicación modela las interacciones entre objetos o partes en términos de
mensajes en secuencia. Los diagramas de comunicación representan una combinación de
información tomada desde el diagrama de clases, secuencia, y diagrama de casos de uso
describiendo tanto la estructura estática como el comportamiento dinámico de un sistema.
Diagrama de tiempos
Un diagrama de tiempos o cronograma es una gráfica de formas de onda digitales que muestra la
relación temporal entre varias señales, y cómo varía cada señal en relación a las demás.
Un cronograma puede contenercualquiernúmerode señalesrelacionadasentre sí.Examinandoun
diagrama de tiempos, se puede determinar los estados, nivel alto o nivel bajo, de cada una de las
señalesencualquierinstante de tiempoespecificado,yel instante exactoenque cualquierade las
señales cambia de estado con respecto a las restantes.

9. Diagrama global de interacciones
Un diagramaglobal de lasinteracciones(eninglés:interactionoverviewdiagram)esunade lastrece
clases de diagramas en el Lenguaje de Modelado Unificado (UML), un lenguaje de modelamiento
para software y otros sistemas.

10. DESARROLLO ÁGIL DE SOFTWARE
El Desarrollo ágil de Software es un paradigma de las Metodologías De Desarrollo basado en
procesos ágiles. Los procesos ágiles de desarrollo de software, conocidos anteriormente como
metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías
tradicionales enfocándose en la gente y los resultados.
El procesoágil usaunenfoquebasadoenelValorparaconstruirsoftware,colaborandoconel cliente
e incorporando los cambios continuamente.
Es un marco de trabajo conceptual de la ingeniería de software que promueve iteracionesen el
desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo
ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo.
Manifiesto ágil
Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y
ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su interacción, por encima de los procesos y las herramientas.
El software que funciona, por encima de la documentación exhaustiva.
La colaboración con el cliente, por encima de la negociación contractual.
La respuesta al cambio, por encima del seguimiento de un plan.
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.
Valores del Manifiesto Ágil
Valorar más a los individuos y su interacción que a los procesos y las herramientas
Este es posiblemente el principio más importante del manifiesto. Por supuesto que los procesos
ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero sin
personas con conocimiento técnico y actitud adecuada, no producen resultados.
Las empresassuelenpredicarmuyaltoque susempleadossonlomás importante,perolarealidad
es que en los años 90 la teoría de producción basada en procesos, la re-ingeniería de procesos ha
dado a éstosmás relevanciade laque puedentenerentareas que debengran parte de su valoral
conocimiento y al talento de las personas que las realizan.

11. Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la
organización,alosequiposyalaspersonas;ynoal revés.Ladefensaaultranzade losprocesoslleva
a postularque con ellosse puedenconseguirresultadosextraordinariosconpersonasmediocres,y
lociertoes que este principioespeligrosocuandolostrabajosnecesitancreatividade innovación.
Valorar más el software que funciona que la documentación exhaustiva
Poderveranticipadamente cómosecomportanlasfuncionalidadesque seesperansobreprototipos
osobre partesyaelaboradasdelsistemafinalofrece un"feedback"muyestimulanteyenriquecedor
que genera ideas y posibilidades imposiblesde concebir en un primer momento, y difícilmente se
podrían incluiral redactarun documentode requisitosdetalladosantes de comenzar el proyecto.
El manifiesto no afirma que no hagan falta. Los documentos son soporte de documentación,
permitenlatransferenciadelconocimiento,registraninformaciónhistórica,yenmuchascuestiones
legalesonormativassonobligatorios,perose resaltaque sonmenosimportantesquelosproductos
que funcionan. Menos trascendentales para aportar valor al producto.
Losdocumentosnopuedensustituir,ni puedenofrecerlariquezaygeneraciónde valorque se logra
con la comunicación directa entre las personasy a través de la interacción con los prototipos. Por
eso, siempre que sea posible debe preferirse, y reducir al mínimo indispensable el uso de
documentación, que genera trabajo que no aporta un valor directo al producto.
Si la organizaciónylosequiposse comunicanatravésde documentos,ademásde perderlariqueza
que da la interacción con el producto, se acaba derivando a emplear a los documentos como
barricadas entre departamentos o entre personas.
Valorar más la colaboración con el cliente que la negociación contractual
Las prácticas ágilesestánespecialmente indicadasparaproductosdifícilesde definircondetalleen
el principio,oque si se definieranasítendríanal final menosvalorque si se van enriqueciendocon
retro-información continua durante el desarrollo. Tambiénpara los casos en los que los requisitos
van a ser muy inestables por la velocidad del entorno de negocio.
Para el desarrolloágil el valordel resultadonoesconsecuenciade habercontroladounaejecución
conforme a procesos, sino de haber sido implementado directamente sobre el producto. Un
contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre

12. responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y
proveedor.
En el desarrolloágil el clienteesunmiembromásdel equipo,que se integraycolaboraenel grupo
de trabajo. Los modelos de contrato por obra no encajan.
Valorar más la respuesta al cambio que el seguimiento de un plan
Para un modelode desarrolloque surge de entornosinestables,que tienencomofactorinherente
al cambioyla evoluciónrápidaycontinua,resultamuchomásvaliosalacapacidadde respuestaque
la de seguimientoyaseguramientode planespre-establecidos.Losprincipalesvaloresde lagestión
ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa:
planificación y control para evitar desviaciones sobre el plan.
Principios ágiles
Los principios fundamentales de una metodología ágil se pueden resumir:
Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de
software de valor.
Son bienvenidoslosrequisitoscambiantes,inclusosi llegantarde al desarrollo.Losprocesoságiles
se doblegan al cambio como ventaja competitiva para el cliente.
Entregar con frecuenciasoftware que funcione,enperiodosde unparde semanashastaun par de
meses, con preferencia en los periodos breves.
Las personasdel negocioylosdesarrolladoresdebentrabajarjuntosde formacotidianaatravésdel
proyecto.
Construcciónde proyectosentorno a individuosmotivados,dándoleslaoportunidadyel respaldo
que necesitan y procurándoles confianza para que realicen la tarea.
La forma más eficiente yefectivade comunicar informaciónde idayvueltadentrode unequipode
desarrollo es mediante la conversación cara a cara.
El software que funciona es la principal medida del progreso.
Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y
usuarios deben mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica enaltece la agilidad.

13. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
En intervalosregulares,el equiporeflexionasobrelaformade sermásefectivoyajustasuconducta
en consecuencia.
Características de un desarrollo ágil
Proceso iterativo e incremental
Mitigación del riesgo mediante iteraciones fijas
Mejora continua
Calidad desde el primer día
Priorización de requerimientos de acuerdo a su valor
Equipos dedicados y auto-gestionados
Colaboración continua con el cliente
Incorporar al cambio
Prácticas de desarrollo modernas
El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de
una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de
requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar
demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es
tener un demo (sin errores) al final de cada iteración.Al final de cada iteración el equipo vuelve a
evaluar las prioridades del proyecto.
Los métodos Agiles enfatizan las comunicaciones cara a cara a través de la documentación. La
mayoría de losequiposAgilesestánlocalizadosenunasimpleoficinaabierta.Laoficinadebe incluir
revisores,diseñadoresde iteración,escritoresde documentaciónyayudaydirectoresde proyecto.

14. LAS ACTIVIDADES ESPECÍFICAS DE LA ETAPA DE ANÁLISIS DE SISTEMAS
Es un conjunto o disposición de procedimientos o programas relacionados de manera que juntos
forman una sola unidad. Un conjunto de hechos, principios y reglas clasificadas y dispuestas de
manera ordenada mostrando un plan lógico en la unión de las partes. Un método, plan o
procedimientode clasificaciónparahaceralgo.Tambiénesunconjuntooarreglodeelementospara
realizarunobjetivopredefinidoenel procesamientodelaInformación.Estose llevaacaboteniendo
en cuenta ciertos principios:
Debe presentarse y entenderse el dominio de la información de un problema.
Defina las funciones que debe realizar el Software.
Represente el comportamiento del software a consecuencias de acontecimientos externos.
Divida en forma jerárquica los modelos que representan la información, funciones y
comportamiento.

15. BIBLIOGRAFIA
[1] Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J. “Agile software development methods
Review and
analysis”. VTT Publications. 2002.
[2] Beck, K.. “Extreme Programming Explained. Embrace Change”, Pearson Education, 1999.
Traducido al
español como:“Una explicaciónde laprogramaciónextrema.Aceptar el cambio”,AddisonWesley,
2000.
[3] Coad P.,Lefebvre E.,De Luca J. “Java ModelingInColorWith UML: Enterprise Componentsand
Process”.
Prentice Hall. 1999.
[4] Cockbun, A. “Agile Software Development”. Addison-Wesley. 2001.
[5] Fowler, M., Beck, K., Brant, J. “Refactoring: Improving the Design of Existing Code”. Addison-
Wesley. 1999
[6] Highsmith J., Orr K. “Adaptive Software Development: A Collaborative Approach to Managing
Complex
Systems”. Dorset House. 2000.
[7] Jeffries, R., Anderson, A., Hendrickson, C. “Extreme Programming Installed”. Addison-Wesley.
2001
[8] Poppendieck M., Poppendieck T. “Lean Software Development: An Agile Toolkit for Software
Development
Managers”. Addison Wesley. 2003.
[9] SchwaberK., Beedle M.,Martin R.C. “Agile Software DevelopmentwithSCRUM”. Prentice Hall.
2001.
[10] StapletonJ.“DsdmDynamicSystemsDevelopmentMethod:The MethodinPractice”. Addison-
Wesley. 1997