Diagramas de Secuencias

Karla Cevallos | INGENIERA DEL SOFTWARE https://ingsotfwarekarlacevallos.wordpress.
com/author/karlacevallos/
INGENIERA DEL SOFTWARE
Portafolio Digital || ESPAM MFL
Autor: Karla Cevallos
KarlaCevallos h p://inteligenciaarticialkarlacevallos.wordpress.com
UML: Diagrama de Secuencia
Resumen de la clase dictada la semana del 6-10

de Julio del 2015
1. INTRODUCCIN
El lenguaje unicado de modelado UML Se utiliza para denir un sistema,

mediante el uso de objetos que forman parte de l as como, las relaciones
estticas o dinmicas que existen entre ellos.
Dentro de los diagramas de comportamiento en UML que permiten enfatizar las

interacciones entre los objetos se encuentran los diagramas de secuencias, este
describe el comportamiento del sistema y las operaciones que se realizan
representando los objetos y los mensajes que se intercambian, ya que en un
sistema real y funcional los objetos interactan entre s, y tales iteraciones
suceden con el tiempo que se asigna, es decir que el diagrama de secuencias de
UML es una mecnica de interaccin en base a los tiempos.
A continuacin se detallan las caractersticas de los diagramas de secuencias y

los elementos que lo conforman.
2. OBJETIVO
Conocer sobre los diagramas de secuencia en UML, sus caractersticas,

funcionamiento y elementos que los componen.
3. MARCO TERICO
1 de 40 27/03/2017 15:19
Karla Cevallos | INGENIERA DEL SOFTWARE https://ingsotfwarekarlacevallos.wordpress.com/author/karlacevallos/
3.1. Diagrama de Secuencias
Un diagrama de secuencias muestra la interaccin de un conjunto de objetos de

una aplicacin a travs del tiempo, en el cual se indicaran los mdulos o clases
que formaran parte del programa y las llamadas que se hacen cada uno de ellos
para realizar una tarea determinada, por esta razn permite observar la
perspectiva cronolgica de las interacciones. Es importante recordar que el
diagrama de secuencias se realiza a partir de la descripcin de un caso de uso.
Entre las ventajas que tiene la elaboracin de un diagrama de secuencias estn

las siguientes:
(h ps://ingsotfwarekarlacevallos.les.wordpress.com/2015/07/14.png)
Figura 1: Ventajas de los Diagramas de Secuencia
3.2. Elementos de un Diagrama de Secuencias
3.2.1. Rol de la Clase
El rol de la clase describe la manera en que un objeto se va a comportar en el

contexto. No se listan los atributos del objeto.
Figura 2: Objeto de una clase
3.2.2. Activacin
Los cuadros de activacin representan el tiempo que un objeto necesita para

completar una tarea.
2 de 40 27/03/2017 15:19
Figura 3: Activacin de una clase
3.2.3. Mensajes
Los mensajes son echas que representan comunicaciones entre objetos. Las
medias echas representan mensajes asincrnicos. Los mensajes asincrnicos son
enviados desde un objeto que no va a esperar una respuesta del receptor para
continuar con sus tareas.
Figura 4: Mensajes
3.2.4. Lneas de Vida
Las lneas de vida son verticales y en lnea de puntos, ellas indican la presencia del
objeto durante el tiempo.
3 de 40 27/03/2017 15:19
Figura 5: Linea de vida
3.2.5. Destruccin de Objetos
Los objetos pueden ser eliminados tempranamente usando una echa etiquetada
<<destruir>> que apunta a una X.
Figura 6: Destruccin de objetos
3.2.6. Loops
Una repeticin o loop en un diagrama de secuencias, es representado como un

rectngulo. La condicin para abandonar el loop se coloca en la parte inferior
entre corchetes [ ].
4 de 40 27/03/2017 15:19
Figura 7: Loop
3.2. Ejemplo
En el siguiente ejemplo se muestra la secuencia que sigue un usuario del metro

para comprar un ticket:
Figura 8: Ejemplo de la secuencia de un usuario del metro para comprar un

ticket
4. CONCLUSIN
Como se mencion anteriormente los diagramas de clases representan

informacin esttica de sistema, pero ya en un sistema funcional, los objetos
interactan entre s con el tiempo, esto se puede representar mediante un
diagrama de secuencias.
El objetivo de UML es ser capaz de describir el comportamiento de un sistema,

subsistema u operacin particular mediante un diagrama de secuencia el cual
muestra la interaccin de un conjunto de objetos en una aplicacin a travs del
tiempo y se modela para cada caso de uso, esto facilita como se distribuyen las
tareas entre los componentes.
5. BIBLIOGRAFA
Gutierrez, D. 2011. UML Diagrama de Secuencia. Universidad de los Andes.(En

lnea). Consultado el 8 de Jul. 2015. Formato PDF. Disponible
en:h p://www.codecompiling.net/les/slides
/UML_clase_06_UML_secuencia.pdf (h p://www.codecompiling.net/les/slides
/UML_clase_06_UML_secuencia.pdf)
Grau, X y Snchez, M. s/f. Desarrollo Orientado a Objetos con UML. (En lnea).
VE. Consultado el 8 de Jul. 2015. Formato PDF. Disponible en:
h p://www.uv.mx/personal/maymendez/les/2011/05/umlTotal.pdf
(h p://www.uv.mx/personal/maymendez/les/2011/05/umlTotal.pdf)
5 de 40 27/03/2017 15:19
Nez. 2000. Modelado de objetos con UML. (En lnea). VE. Consultado el 8 de
Jul. 2015. Formato PDF. Disponible en: h p://exa.unne.edu.ar/informatica
/anasistem1 (h p://exa.unne.edu.ar/informatica/anasistem1)
Kendall, K y Kendall, J. 2011. Anlisis y diseo de sistemas. 8 ed. Mxico.

Pearson Education. p 600
7 JULIO, 2015 KARLA CEVALLOS DEJA UN

COMENTARIO
UML: Relaciones entre clases
Resumen de la clase dictada la semana del 29 de

Junio 3 de Julio del 2015
1. INTRODUCCIN
Como se mencion anteriormente los diagramas de clases describen los tipos de

objetos de un sistema as como las relaciones que pueden existir, es por esto que
se convierten en la tcnica ms utilizada para el modelado conceptual de un
sistema software. Los diagramas de clases son deniciones estticas del sistema
y representan una instantnea del estado del sistema en un momento dado, este
va a ser creado y renado durante las fases de anlisis y diseo del proyecto,
estando presente como gua en la implementacin del sistema.
Las relaciones que existen en un diagrama de clases permiten denir las

dependencias entre clases, es decir si una clase es necesaria para la
implementacin de otra. A continuacin se analizan las diferentes relaciones que
se pueden implementar en un diagrama de clases.
2. OBJETIVO
Conocer las relaciones que pueden existir dentro de un diagrama estructural

como lo es el diagrama de clases.
3. MARCO TERICO
3.1. Utilidad de un Diagrama de Clase
El propsito de un diagrama de clase es describir las clases que conforman el

modelo de un determinado sistema. Se puede decir que existen tres perspectivas
diferentes desde las cuales se pueden utilizar los diagramas de clase:
6 de 40 27/03/2017 15:19
Figura 1: Perspectivas desde las cuales se elabora un diagrama de clases
3.2. Relaciones entre clases
Dentro de las relaciones entre clases que existen se pueden denir las siguientes:
Figura 2: Clasicacin de las relaciones que pueden existir en un diagrama de

clases
3.2.1. Asociaciones
Las asociaciones representan las relaciones ms generales entre clases, es decir,

las relaciones con menor contenido semntico. Para UML una asociacin va a
describir un conjunto de vnculos entre las instancias de las clases.
Las asociaciones pueden ser binarias (conectan dos clases) o n-arias (conectan n
clases), aunque lo ms normal en un modelo es utilizar slo relaciones binarias
7 de 40 27/03/2017 15:19
(en general, y sin entrar en detalles, se puede armar que una relacin n-aria
puede modelarse mediante un conjunto nito de relaciones binarias).
La forma de representar las asociaciones binarias en UML es mediante una lnea

que conecta las dos clases. En general, las asociaciones son bidireccionales, esto
es, no tienen un sentido asociado.
Ejemplo:
Si tenemos la clase perro y persona las siguientes relaciones podran darse:
Figura 3: Ejemplo de asociacin
La cual muestra que una persona es propietaria de uno o varios perros pero estos
son solo de esta persona.
3.2.1.1. Composicin
La composicin implica que los componentes de un objeto slo pueden

pertenecer a un solo objeto agregado, de forma que cuando el objeto agregado es
destruido todas sus partes son destruidas tambin.
Ejemplo:
A una empresa la componen empleados.
Figura 4: Ejemplo de composicin
3.2.1.2. Agregacin
La agregacin es una asociacin con unas connotaciones semnticas ms

denidas: la agregacin es la relacin parte-de, que presenta a una entidad como
un agregado de partes (en orientacin a objeto, un objeto como agregado de
otros objetos).
Ejemplo:
8 de 40 27/03/2017 15:19
Una empresa tiene clientes
Figura 5: Ejemplo de agregacin
3.2.2. Herencia
La herencia es la tpica relacin de generalizacin/especializacin entre clases. En

UML la herencia se representa mediante una echa, cuya punta es un tringulo
vaco. La echa que representa a la herencia va orientada desde la subclase a la
superclase.
Cuando de una superclase se derivan varias subclases existen dos notaciones

diferentes, aunque totalmente equivalentes, para su representacin.
Figura 6: Ejemplo de herencia simple
3.2.2.1. Herencia mltiple
UML permite implementar la herencia mltiple cuando una clase hereda

directamente de varias clases.
Ejemplo:
9 de 40 27/03/2017 15:19
Un profesor emrito puede ser un profesor como tambin un conferenciante
Figura 7: Ejemplo de herencia mltiple
4. CONCLUSIN
El diagrama de clases pertenece a la categora de diagramas de estructura de

UML, este debe ser capaz de ofrecer los mecanismos necesarios para capturar y
modelar la abstraccin de un sistema desde diferentes puntos de vista ya que
representa la denicin esttica del sistema. Se puede presentar de diferentes
maneras entre las cuales tenemos el modelo conceptual donde se denen las
caractersticas del problema, especicacin donde se denen las interfaces del
diagrama para simplicarlo e implementacin donde se muestran tal y como
aparecen las clases en el entorno de programacin.
Dentro de un diagrama de clases se pueden relacionar las clases con una

asociacin que dene un vnculo que puede darse entre ciertas clases,
composicin donde las clases son fundamentales para la implementacin de otra
clase, agregacin donde se utilizan clases que no son esenciales para su
funcionamiento y la herencia que es la relacin de generalizacin que se utiliza
para heredar caractersticas de una clase a otra.
5. BIBLIOGRAFA
Guidi, F. s/f. Diagramas de Clase Uml.Universidad Catlica de Chile. (En lnea).

Consultado, 10 de Jun. 2015. Formato PDF. Disponible en: h p://eii.ucv.cl
/pers/guidi/cursos/estructuras/pdf/SE-DiagramasDeClasesUML.pdf
Gutirrez, D. 2011. UML Diagramas de clases. (En lnea). VE. Consultado, 10 de

Jun. 2015. Formato PDF. Disponible en: h p://www.codecompiling.net
(h p://www.codecompiling.net/)

Pealvo, G; Francisco, J; Aguilar, P. 2010. UML 1.1. Un lenguaje de modelado

estndar para los mtodos de ADOO. RPP, N36.
2 JULIO, 2015 KARLA CEVALLOS DEJA UN

COMENTARIO
10 de 40 27/03/2017 15:19
UML: Diagrama de Clases
Resumen de la clase dictada la semana del 8-12

de Junio del 2015
1. INTRODUCCIN
Dentro del leguaje unicado de modelado UML se encuentran varios diagramas

que permiten representar las diferentes reas de un proyecto de software para
denir mejor su funcionamiento, entre estos encontramos los diagramas de clase
que denen la estructura esttica del sistema.
El concepto de clase se reere a las cosas que existen y nos rodean, las mismas
que crean categoras lo que seran las clases; estas al ser una categora cuenta con
atributos y mtodos que realiza es decir la actividad.
Los diagramas de clases trabajan bajo las metodologas orientadas a objetos para
descubrir las clases, atributos, mtodos y relaciones entre las clases, la
programacin ocurre a nivel de clase, ya que el denir clases es una de las tareas
ms importantes del anlisis orientado a objetos. A continuacin se analiza de
forma ms detallada los diagramas clases u su papel fundamental en los
proyectos de software.
2. OBJETIVO
Conocer sobre los diagramas de clase, su estructura, funcionamiento y el papel

que tienen dentro del desarrollo de un proyecto de software.
3. MARCO TERICO
3.1. Diagrama de clases
Este tipo de diagrama de UML se utiliza para representar la estructura esttica

del programa, las clases se representan mediante un rectngulo. En el formato
ms simple, el rectngulo puede incluir slo el nombre de la clase, pero tambin
puede incluir atributos y mtodos. Los atributos son lo que la clase conoce sobre
las caractersticas de los objetos, y los mtodos (tambin llamados operaciones)
son lo que la clase sabe acerca de cmo hacer las cosas. Los mtodos son
pequeas secciones de cdigo que trabajan con los atributos.
11 de 40 27/03/2017 15:19
Figura 1: Estructura de una clase
Las cosas que existen y que nos rodean se agrupan naturalmente en categoras.
Una clase es una categora o grupo de cosas que tienen atributos (propiedades) y
acciones similares. Un ejemplo puede ser la clase Aviones que tiene atributos
como el modelo de avin, la cantidad de motores, la velocidad de crucero
y la capacidad de carga til. Entre las acciones de las cosas de esta clase se
encuentran: acelerar, elevarse, girar, descender, desacelerar.
Nota: En un diagrama de clases, los mensajes pblicos (al igual que los atributos
pblicos) se muestran con un signo positivo (+) al inicio del nombre
correspondiente.
3.1.1. Atributos
En un diagrama de clases los atributos son lo que la clase conoce sobre las
caractersticas de los objetos, estos pueden ser pblicos, privados o protegidos.
A continuacin se muestran algunas de las caractersticas de los atributos:
Figura 2: Caractersticas del Diagrama de Clases
12 de 40 27/03/2017 15:19
3.1.1. Mtodos
Los mtodos tambin llamados operaciones son los que denen las actividades
que va a realizar la clase es decir los procesos. Dentro de una clase se puede
realizar el ocultamiento de informacin que signica que los mtodos de los
objetos deben estar disponibles para otras clases, por lo que comnmente los
mtodos son pblicos, lo cual signica que se pueden invocar desde otras clases.
Los mtodos tambin tienen parntesis despus de su nombre, lo cual indica que
se pueden pasar datos como parmetros junto con el mensaje.
Existen dos tipos de mtodos: estndar y personalizados que se denen a

continuacin:
Figura 3: Tipos de Mtodos
3.1.1. Tipos de clases
Las clases se dividen en cuatro categoras: de entidad, de interfaz, abstracta y de

control. A continuacin se explican estas categoras:
13 de 40 27/03/2017 15:19
Figura 4: Tipos de Clases
4. CONCLUSIN
Dentro de la programacin orientada a objeto se trabaja con clases (que no son

ms que categoras de las cosas que nos rodean), atributos (caractersticas de los
objetos) y mtodos (acciones que puede realizar la clase). Una clase es la parte
ms importante dentro del anlisis orientado a objeto y presenta las
caractersticas del sistema pero no muestra ningn procesamiento en especial, es
decir que los diagramas de clase son utilizados para denir la funcionabilidad
del software (como estarn compuestas las clases para que el programador
pueda desarrollar su trabajo).
Para la presentacin de los diagramas de clases existen diferentes formatos, uno

de estas es presentar solo los nombres de las clases con sus relaciones sin
atributos o mtodos, esto se realiza cuando el diagrama es muy extenso o
complicado Existen varios tipos de clases con diferentes caractersticas, entre
estas encontramos las clases abstractas que denen los mtodos pero no la
implementacin del los mismos, las interfaces que al igual que las clases
abstractas denen los atributos comunes de otras clases, las entidades que
denen el objeto y son muy utilizadas en los diagramas entidad-relacion y por
ultimo las clases de control que nos permiten denir mtodos que deben
14 de 40 27/03/2017 15:19
ser ejecutados correctamente para poder utilizar los mtodos de otras clases.
5. BIBLIOGRAFA
Garcia, F y Aguila, P. 2010. Diagramas de Clase en UML 1.1.(En lnea).

Consultado, 10 de Jun. 2015. Formato PDF. Disponible en: h p://gredos.usal.es
/jspui/bitstream/10366/121969/3/DIA_GarciaPenalvo_Pard.pdf
Guidi, F. s/f. Diagramas de Clase Uml.Universidad Catlica de Chile. (En lnea).

Consultado, 10 de Jun. 2015. Formato PDF. Disponible en: h p://eii.ucv.cl
/pers/guidi/cursos/estructuras/pdf/SE-DiagramasDeClasesUML.pdf
Gutirrez, D. 2011. UML Diagramas de clases. (En lnea). VE. Consultado, 10 de

Jun. 2015. Formato PDF. Disponible en: h p://www.codecompiling.net
(h p://www.codecompiling.net)

11 JUNIO, 2015 KARLA CEVALLOS DEJA UN

COMENTARIO
UML: Casos de Uso
Resumen de la clase dictada la semana del 1-5 de

Junio del 2015
1. INTRODUCCIN
En base a lo que hemos revisado anteriormente nos damos cuenta que existen
diferentes metodologas que nos permiten desarrollar software de calidad
enfocadas a las necesidades que se tengan.
Dentro de un proyecto de software existen diferentes etapas, una de estas

independientemente de la metodologa que se est utilizando es la
comunicacin con el cliente, ya que es fundamental para denir los
requerimientos de software porque muchas veces lo que se plantea no es lo que
el cliente espera, es por esto que se denen formas de presentar al cliente una
perspectiva de lo que ser el software una vez terminado.
Existen diferentes formas de representar la funcionalidad del software sin estar

terminado, una de estas es el Lenguaje Unicado de Modelado UML, que es
el sistema de modelado de software ms conocido y utilizado en la actualidad;
est compuesto por diversos elementos grcos que se combinan para
conformar diagramas, adems se encuentra respaldado por el OMG (Object
Management Group) que se dedica al cuidado y establecimiento de estndares
de tecnologas orientadas a objetos.
Dentro de UML se pueden encontrar diversos diagramas que permiten

representar las diversas perspectivas de un sistema, a las cuales se les conoce
como modelo que es una representacin simplicada de la realidad. Los Casos
15 de 40 27/03/2017 15:19
de Uso son diagramas que permiten representar que har el sistema pero no
como funciona, a continuacin se analiza su implementacin en los proyectos de
software.
2. OBJETIVO
Conocer sobre los diagramas de Caso de Uso, sus componentes y la

implementacin que tienen dentro de un proyecto de software.
3. MARCO TERICO
3.1. UML
Lenguaje Unicado de Modelado UML, es el lenguaje de modelado de

sistemas de software ms conocido y utilizado en la actualidad. Se lo puede
denir como un lenguaje grco para visualizar, especicar, construir y
documentar un sistema.
UML ofrece un estndar para describir un plano del sistema (modelo),

incluyendo aspectos conceptuales tales como procesos de negocio, funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programacin,
esquemas de bases de datos y compuestos reciclados. Algunas de las
caractersticas de UML se denen a continuacin:
Figura 1: Caractersticas de los diagramas UML
Existen diferentes versiones de UML que se presentaron a lo largo del tiempo,

este se estandarizo desde el ao 2005, y es aprobado por la ISO. UML cuenta con
varios tipos de diagramas, los cuales muestran diferentes aspectos de las
entidades representadas, estos se clasican segn su estructura o
comportamiento de la siguiente manera:
16 de 40 27/03/2017 15:19
Figura 2: Clasicacin de los diagramas UML
3.2. Diagrama de Casos de Uso
Un caso de uso es una descripcin de las acciones de un sistema desde el punto

de vista del usuario. Es una herramienta valiosa dado que es una tcnica de
aciertos y errores para obtener los requerimientos del sistema, justamente desde
el punto de vista del usuario.
Los diagramas de caso de uso modelan la funcionalidad del sistema usando

actores y casos de uso. Los casos de uso son servicios o funciones provistas por
el sistema para sus usuarios.
3.2.1. Smbolos de los casos de uso
Sistema: El rectngulo representa los lmites del sistema que contiene los casos de
uso. Los actores se ubican fuera de los lmites del Sistema.
17 de 40 27/03/2017 15:19
Figura 3: Sistema de Casos de Uso
Caso de uso: Se representan con valos. La etiqueta en el valo indica la funcin

del sistema.
Figura 4: Casos de Uso
Actor: Un diagrama de caso de uso contiene los smbolos del actor y del caso de
uso, junto con lneas conectoras. Los actores son similares a las entidades
externas; existen fuera del sistema. El trmino actor se reere a un rol especco
de un usuario del sistema.
Figura 5: Actor que inicia el caso de uso
Por ejemplo:
Un actor puede ser un empleado, pero tambin puede ser un cliente en la tienda
de la empresa. Incluso cuando es la misma persona en el mundo real, se
representa como dos smbolos distintos en un diagrama de caso de uso, ya que
la persona interacta con el sistema en distintos roles.
18 de 40 27/03/2017 15:19
Figura 6: Caractersticas de los actores
3.3. Relaciones
Las relaciones entre un actor y un caso de uso, se dibujan con una lnea simple.
Para relaciones entre casos de uso, se utilizan echas etiquetadas incluir o
extender. Una relacin incluir indica que un caso de uso es necesitado por
otro para poder cumplir una tarea. Una relacin extender indica opciones
alternativas para un cierto caso de uso.
(h ps://ingsotfwarekarlacevallos.les.wordpress.com/2015/07/esta.png)
Figura 7: Ejemplo de Casos de Uso
19 de 40 27/03/2017 15:19
3.3.1. Relaciones de los casos de uso
Las relaciones activas se conocen como relaciones de comportamiento y se

utilizan principalmente en los diagramas de casos de uso. Hay cuatro tipos
bsicos de relaciones de comportamiento: comunica, incluye, extiende y
generaliza.
Figura 8: Relaciones entre los Casos de Uso
3.4. Documentacin de los casos de uso
Existen dos formas principales de documentar un caso de uso:
Un diagrama en UML
Un documento detallado
Documentar casos de usos no es una tarea fcil que se pueda dominar de un da

para otro, requiere de tiempo, disciplina y experiencia, sin embargo podemos
denir una serie de pasos identicables para escribir los casos de uso.
Figura 9: Pasos para la documentacin de los Casos de Uso
Formato de la documentacin de caso de uso para los actores que participen:
20 de 40 27/03/2017 15:19
Figura 10: Documentacin de los actores dentro de los Casos de Uso
Documentacin de un caso de uso:
Figura 10: Documentacin de los Casos de Uso
4. CONCLUSIN
El diagrama de modelado UML es un estndar muy utilizado en la actualidad, y

est conformado por varios diagramas que denen las diferentes
21 de 40 27/03/2017 15:19
funcionalidades u objeto de un proyecto de software, a este proceso se le conoce

como modelo que es una representacin simplicada de la realidad.
Los diagramas en UML se clasican segn su estructura o comportamiento, estos

ltimos se reeren a la forma en que se ejecutan las instrucciones o como se dan
las actividades dentro del sistema. Los diagramas de estructura denen como se
encuentra el software estructurado, un ejemplo de esto es el diagrama de
componentes que dene las diferentes partes que conforman el sistema para que
funcione.
Dentro de los diagramas UML encontramos los diagramas de casos de uso,

estos describen que ara el sistema pero no de qu forma lo ara, son ideales para
denir los requerimientos especcos y mostrarlos al cliente de tal forma que
este pueda plantear sus ideas y correcciones de una mejor manera, ya que
muchas veces el cliente no est seguro de lo que desea o como quiere que
funcione.
5. BIBLIOGRAFA
Berzal, C. 2004. . El lenguaje Unicado de Modelado (UML). Consultado 2 de

Jun. 2015. Formato PDF. Disponible en:h p://elvex.ugr.es/decsai/java/pdf
/3E-UML.pdf (h p://elvex.ugr.es/decsai/java/pdf/3E-UML.pdf)
Gutirrez, J. 2008. Diagramas UML de casos de uso y de requisitos. (En lnea). ES.
Consultado 2 de Jun. 2015. Formato PDF. Disponible en: h p://www.lsi.us.es
/~javierj/cursos_cheros/metricaUML/CasosUsoUML.pdf (h p://www.lsi.us.es
/~javierj/cursos_cheros/metricaUML/CasosUsoUML.pdf)

Merseguer, J. 2010. Diagramas de Casos de Uso. (En lnea). Consultado, 2 de Jun.

2015. Formato PDF. Disponible en:h p://webdiis.unizar.es/~jmerse
/IS-2/CasosdeUso.pdf (h p://webdiis.unizar.es/~jmerse/IS-2/CasosdeUso.pdf)
WEB 2.0. 2014. Inteligencia de negocios. (En lnea). Consultado, 2 de Jun. 2015.
Formato PDF. Disponible en: h p://inteligenciadenegociosval.blogspot.com
(h p://inteligenciadenegociosval.blogspot.com)
4 JUNIO, 2015 KARLA CEVALLOS DEJA UN

COMENTARIO
Metodologa de Desarrollo gil: XP

y Scrum
Resumen de la clase dictada la semana 4-8 de

Mayo del 2015
22 de 40 27/03/2017 15:19
1. INTRODUCCIN
Las metodologas de desarrollo gil buscan elaborar software totalmente

funcional en el tiempo o plazo establecido para el desarrollo del proyecto.
Utilizan un proceso gil, es decir que si los requerimientos del software cambian
en cualquier etapa en la que se encuentre el proyecto, el equipo debe adaptar el
producto a estos cambios ya que la agilidad como tal es la respuesta efectiva al
cambio. Existen deferentes metodologas de desarrollo gil tales como:
programacin extrema XP, Scrum, Cristal entre otras, todas con el mismo
objetivo pero con diferentes formas de trabajo.
La programacin extrema XP est enfocada al desarrollo en equipo, es por esto

que dene un conjunto de valores que deben tener, adems incluye al cliente
como parte fundamental ya que sin l no se tendran los requerimientos del
producto. Scrum al igual que XP tiene un equipo de trabajo, la nica diferencia
es que divide el equipo en scrum master (lder), DBA (administrador dela base
de datos), Programadores, diseadores y el product owner (el cliente).
A continuacin se denen ms caractersticas de las metodologas de desarrollo

agil XP y Scrum, as como tambin las ventajas y desventajas que puede tener el
desarrollo gil.
2. OBJETIVO
Conocer sobre las caractersticas, ventajas y desventajas de las metodologas de

desarrollo gil XP y Scrum.
3. MARCO TERICO
3.1. Programacion Extrema (XP)
La programacin extrema (XP) es el enfoque ms utilizado del desarrollo de

software gil. Aunque las primeras actividades con las ideas y los mtodos
asociados a XP ocurrieron al nal de la dcada de 1980 Una variante de XP
llamada XP industrial [IXP] se propuso en una poca ms reciente. IXP mejora la
XP y tiene como objetivo el proceso gil para ser usado especcamente en
organizaciones grandes.
3.1.1 Valores XP
XP dene un conjunto de valores que establecen el fundamento para todo trabajo

realizado como parte de XP. Cada uno de estos valores se usa como un motor
para actividades, acciones y tareas especcas de XP.
23 de 40 27/03/2017 15:19
Figura 1: Valores XP
3.1.2 El proceso XP
La programacin extrema usa un enfoque orientado a objetos como paradigma

preferido de desarrollo, y engloba un conjunto de reglas y prcticas que ocurren
en el contexto de cuatro actividades estructurales: planeacin, diseo,
codicacin y pruebas.
(h ps://ingsotfwarekarlacevallos.les.wordpress.com/2015/05/marcoxp.jpg)
Figura 2: Proceso XP
3.1.2.1. Planeacin
La actividad de planeacin (tambin llamada juego de planeacin) comienza

escuchando actividad para recabar requerimientos que permite que los
miembros tcnicos del equipo XP entiendan el contexto del negocio para el
software y adquieran la sensibilidad de la salida y caractersticas principales y
funcionalidad que se requieren.
24 de 40 27/03/2017 15:19
Escuchar lleva a la creacin de historias por parte del usuario, estas son tomadas
por los desarrolladores para modelar los requisitos (Pressman, R. 2010).
Los clientes y desarrolladores trabajan juntos para decidir cmo agrupar las
historias en la siguiente entrega (el siguiente incremento de software) que
desarrollar el equipo XP. Una vez que se llega a un compromiso sobre la
entrega (acuerdo sobre las historias por incluir, la fecha de entrega y otros
aspectos del proyecto), el equipo XP ordena las historias que sern desarrolladas
en una de tres formas:
Figura 3: Denicin del orden de ejecucin de las historias
A medida que avanza el trabajo, el cliente puede agregar historias, cambiar el

valor de una ya existente, descomponerlas o eliminarlas. Entonces, el equipo XP
reconsidera todas las entregas faltantes y modica sus planes en consecuencia.
3.1.2.2. Diseo
El diseo XP sigue rigurosamente el principio MS (mantenlo sencillo). Un diseo

sencillo siempre se preere sobre una representacin ms compleja. Adems, el
diseo gua la implementacin de una historia conforme se escribe: nada ms y
nada menos. Se desalienta el diseo de funcionalidad adicional porque el
desarrollador supone que se requerir despus.
XP estimula el uso de las tarjetas CRC como un mecanismo ecaz para pensar en
el software en un contexto orientado a objetos. Las tarjetas CRC (clase-
responsabilidad-colaborador) identican y organizan las clases orientadas a
objetos que son relevantes para el incremento actual de software. Las tarjetas
CRC son el nico producto del trabajo de diseo que se genera como parte del
proceso XP (Pressman, R. 2010).
25 de 40 27/03/2017 15:19
Figura 4: Tarjetas CRC
3.1.2.3. Codificacin
Un concepto clave durante la actividad de codicacin (y uno de los aspectos del

que ms se habla en la XP) es la programacin por parejas. XP recomienda que
dos personas trabajen juntas en una estacin de trabajo con el objeto de crear
cdigo para una historia. A medida que las parejas de programadores terminan
su trabajo, el cdigo que desarrollan se integra con el trabajo de los dems. En
ciertos casos, esto lo lleva a cabo a diario un equipo de integracin. En otros, las
parejas de programadores tienen la responsabilidad de la integracin. Esta
estrategia de integracin continua ayuda a evitar los problemas de
compatibilidad de interfaces y brinda un ambiente de prueba de humo que
ayuda a descubrir a tiempo los errores (Lpez , P y Francisco, R. s/f.)
3.1.2.4. Pruebas
La creacin de pruebas unitarias antes de que comience la codicacin es un

elemento clave del enfoque de XP, ya que esto asegura la calidad del software.
3.1.3 XP industrial
IXP es la evolucin orgnica de XP. Est imbuida del espritu minimalista,

centrado en el cliente y orientado a las pruebas que tiene XP. IXP diere sobre
todo de la XP original en su mayor inclusin de la gerencia, el papel ms amplio
de los clientes y en susprcticas tcnicas actualizadas.
Evaluacin de la factibilidad
Comunidad del proyecto
Calicacin del proyecto
Administracin orientada a pruebas
Aprendizaje continuo
Despus de entregar un incremento de software, el equipo XP realiza una

revisin tcnica especializada que se llama retrospectiva y que examina los
temas, eventos y lecciones aprendidas
3.1.4 El debate XP
Como se mencion anteriormente existen quienes se encuentran a favor de la
26 de 40 27/03/2017 15:19
implementacin de las metodologas giles y quienes preeren las metodologas

tradicionales, a continuacin se muestran algunos de los puntos en desacuerdo
que generan debates entre los desarrolladores.
Figura 5: Problemas que pueden darse en XP
3.2. Scrum
Es un mtodo de desarrollo gil de software concebido por Je Sutherland y su

equipo de desarrollo a principios de la dcada de 1990. Los principios Scrum son
congruentes con el maniesto gil y se utilizan para guiar actividades de
desarrollo dentro de un proceso de anlisis que incorpora las siguientes
actividades estructurales: requerimientos, anlisis, diseo, evolucin y entrega.
Dentro de cada actividad estructural, las tareas del trabajo ocurren con un
patrn del proceso llamado sprint. El trabajo realizado dentro de un sprint (el
nmero de stos que requiere cada actividad estructural variar en funcin de la
complejidad y tamao del producto) se adapta al problema en cuestin y se
dene y con frecuencia se modica en tiempo real por parte del equipo Scrum
(Pressman, R. 2010).
27 de 40 27/03/2017 15:19
Figura 6: Metodologa de desarrollo gil Scrum
Scrum acenta el uso de un conjunto de patrones de proceso del software que

han demostrado ser ecaces para proyectos con plazos de entrega muy
apretados, requerimientos cambiantes y negocios crticos. Cada uno de estos
patrones de proceso dene un grupo de acciones de desarrollo:
Figura 7: Proceso Scrum
28 de 40 27/03/2017 15:19
4. CONCLUSIN
Un proceso gil es aquel donde el equipo de trabajo se encuentra preparado para

los cambios que puedan suscitare, ya que la agilidad es la respuesta efectiva al
cambio. Los desarrolladores a travs de las metodologas agiles buscan
desarrollar el producto en el tiempo establecido de una manera ms informal,
donde las funcionalidades se realicen antes de cualquier documentacin.
La programacin extrema XP es una de las ms utilizadas por los desarrolladores

agiles, esta dene un conjunto de valores que debe tener el equipo:
Comunicacin, sin no existe no se podrn denir los requerimientos de software
lo que lleva a elaborar un producto que no sea quizs lo que el cliente esperaba.
Simplicidad, es imprtate resolver los requerimientos primero antes de agregar
cualquier funcionabilidad extra. Retroalimentacin, a medida que el proyecto
avanza el equipo aprende y puede reutilizar los recursos (por recursos me
reero al software ya desarrollado) para las nuevas funcionalidades. Valenta,
estar preparado para los cambios que se den en cualquier etapa del proyecto as
incluyan un cambio total de los requerimientos. Respeto, es lo ms importante
en cualquier equipo.
La metodologa de desarrollo agil Scrum dene un conjunto de acciones de

desarrollo para la elaboracin del proyecto: retraso, sprint, demostraciones
preliminares y reuniones srum, cada una de estas se realizan en cada iteracin
que sera la presentacin de un nuevo incremento de software.
5. BIBLIOGRAFA
Lpez , P y Francisco, R. s/f. INGENIERA DEL SOFTWARE. (En lnea). VE.

Consultado, 6 de Mayo de 2015. Formato PDF. Disponible en:
h p://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-i/materiales-
de-clase-1/is1-t02-trans.pdf (h p://ocw.unican.es/ensenanzas-tecnicas
/ingenieria-del-software-i/materiales-de-clase-1/is1-t02-trans.pdf)
Rodrguez, E. 2012. Conceptos bsicos de Ingeniera de Software. (En lnea). VE.

Consultado, 6 de Mayo de 2015. Formato PDF. Disponible en:
h p://www.tamps.cinvestav.mx/~ertello/swe/sesion01.pdf
(h p://www.tamps.cinvestav.mx/~ertello/swe/sesion01.pdf)
Pacheco, I y Garca, J. 2008. Una Metodologa Basada en Prcticas Efectivas para

Desarrollar Software Educativo.MX. Postgraduate Department, Technological
University of the Mixtec Region. vol.11 no.4 . (En lnea). Consultado, 6 Mayo de
2015. Formato PDF. Disponible en: h p://www.scielo.org.ve
/scielo.php?script=sci_ar ext&pid=S0798-40652010000400003&lang=pt
Pressman, R. 2010. Ingeniera del Software Un Enfoque Prctico. 7ma ed.

University ofConnecticut. McGraw-Hill Interamericana Editores, S.A.
8 MAYO, 2015 KARLA CEVALLOS DEJA UN

COMENTARIO
Metodologa de Desarrollo
29 de 40 27/03/2017 15:19
gil: Introduccin
Resumen de la clase dictada la semana 4-8 de

Mayo del 2015
1. INTRODUCCIN
Como sabemos existen diferentes metodologas de desarrollo de software, las

mismas que se utilizan segn los requerimientos de producto que se est
realizando. Estas metodologas permiten seguir un conjunto de pasos que
acerquen cada vez ms al objetivo de entregar un software totalmente funcional
y a tiempo.
La metodologa de desarrollo gil busca desarrollar software a medida en el

tiempo o plazo establecido, para esto se realizan las actividades necesarias; la
caracterstica ms importante de un proceso gil es que si los requerimientos
cambian en cualquier punto de desarrollo que se encuentre el proyecto, el
equipo debe estar preparado y adaptar el software a estos nuevos
requerimientos.
Este tipo de metodologa se adapta ms a lo que sucede en el mundo real, ya que

los requerimientos en un proyecto nunca son estticos, a veces el cliente cambia
de opinin haciendo que lo desarrollado hasta ese momento quede obsoleto; en
un proceso gil el equipo debe tomar estos requerimientos como un adicional y
adaptar lo que ya tena desarrollado para no perder el trabajo.
En un proceso gil se busca lo que comnmente se conoce como

funcionalidades primero, es decir busca entregar software totalmente
funcional en cada interaccin independientemente de su interfaz. A
continuacin se denen ms caractersticas, ventajas y desventajas de la
metodologa de desarrollo gil.
2. OBJETIVO
Conocer sobre la metodologa de desarrollo gil, sus caractersticas, ventajas,

desventajas y porque los programadores preeren utilizar un proceso gil en sus
proyectos.
3. MARCO TERICO
3.1. Qu es la agilidad?
La agilidad dentro de un proyecto de software es una respuesta efectiva al

cambio, esta recomienda las estructuras de equipo y las actitudes que hacen ms
fcil la comunicacin (entre los miembros del equipo, tecnlogos y gente de
negocios, entre los ingenieros de software y sus gerentes, etc.); pone el nfasis en
la entrega rpida de software funcional y resta importancia a los productos
intermedios del trabajo (lo que no siempre es bueno); adopta al cliente como
parte del equipo de desarrollo y trabaja para eliminar la actitud de nosotros y
30 de 40 27/03/2017 15:19
ellos que todava invade muchos proyectos de software; reconoce que la

planeacin en un mundo incierto tiene sus lmites y que un plan de proyecto
debe ser exible (Pressman, R. 2010) (Pea, A. 2006)
Entre las caractersticas ms importantes de la metodologa de desarrollo gil se

encuentran las siguientes:
Figura 1: Caractersticas ms importantes de la metodologa de desarrollo gil
3.2. La agilidad y el Costo de Camino
El costo del desarrollo de software se incrementa en forma no lineal a medida

que el proyecto avanza, ya que los requerimientos pueden cambiar en cualquier
estado que se encuentre el proyecto. Los costos aumentan con rapidez, y no son
pocos el tiempo y el dinero requeridos para asegurar que se haga el cambio sin
efectos colaterales no intencionados.
Las metodologa de desarrollo gil permite que el equipo de software haga

cambios en una fase tarda de un proyecto de software sin que haya un efecto
notable en el costo y en el tiempo.
31 de 40 27/03/2017 15:19
Figura 2: Costo del Camino
3.3. Que es un Proceso gil?
Un proceso gil se caracteriza porque aborda las siguientes suposiciones que

pueden darse dentro del proyecto.
Figura 3: Proceso Agil
Un proceso de software gil debe adaptarse incrementalmente. Para lograr la

adaptacin incremental, un equipo gil requiere retroalimentacin con el cliente
(de modo que sea posible hacer las adaptaciones apropiadas). Un catalizador
ecaz para la retroalimentacin con el cliente es un prototipo operativo o una
porcin de un sistema operativo. As, debe instituirse una estrategia de
desarrollo incremental. Deben entregarse incrementos de software (prototipos
ejecutables o porciones de un sistema operativo) en periodos cortos de tiempo,
de modo que la adaptacin vaya a ritmo con el cambio (impredecible). Este
enfoque iterativo permite que el cliente evale en forma regular el incremento
de software, d la retroalimentacin necesaria al equipo de software e inuya en
las adaptaciones del proceso que se realicen para aprovechar la
retroalimentacin.
3.3.1. Principios de agilidad
Se denen 12 principios que debe tener la agilidad, aunque no todos los procesos
32 de 40 27/03/2017 15:19
agiles los utilizan ya que ignoran algunos de ellos.
Figura 4: Principios de la Agilidad
3.2.3. La poltica del desarrollo gil
Hay mucho debate sobre los benecios y aplicabilidad del desarrollo de

software gil como oposicin a los procesos ms convencionales. Aunque nadie
est contra la agilidad. La pregunta real es: cul es la mejor forma de lograrla?
De igual importancia: cmo construir software que satisfaga en el momento las
necesidades de los clientes y que tenga caractersticas de calidad que permitan
ampliarlo y escalarlo para que tambin las satisfaga en el largo plazo?.
33 de 40 27/03/2017 15:19
No hay respuestas absolutas a ninguna de estas preguntas. Aun dentro de la

metodologa gil hay muchos modelos de proceso propuestos, cada uno con un
enfoque algo diferente para el problema de la agilidad. Dentro de cada modelo
hay un conjunto de ideas (los agilistas las llaman tareas del trabajo) que
representan un alejamiento signicativo de la ingeniera de software tradicional.
No obstante, muchos conceptos giles slo son adaptaciones de algunos que
provienen de la buena ingeniera de software (Pressman, R. 2010).
3.2.4. Factores humanos
El desarrollo gil se centra en los talentos y habilidades de los individuos, y

adapta el proceso a personas y equipos especcos. (Cockburn y Highsmith,
2001)
El punto clave de esta armacin es que el proceso se adapta a las necesidadesde

las personas y del equipo, no al revs.
Si los miembros del equipo de software son los que van a generar las
caractersticas del proceso que van a aplicarse a la elaboracin de software, entre
ellos debe existir cierto nmero de caractersticas clave, mismas que debe
compartir el equipo gil como tal:
34 de 40 27/03/2017 15:19
Figura 5: Factores Humanos
4. CONCLUSIONES
Dentro del desarrollo de un proyecto de software existen varios eventos que

pueden ocurrir, uno de estos es que los requerimientos funcionales que se
denieron en un principio para el producto cambien, esto trae consigo costos
inesperados en el proyecto y prdida de tiempo.
Las metodologas de desarrollo gil buscan entregar software a medida y en el

tiempo o plazo establecido sin importar que los requerimientos cambien en
cualquier etapa del proyecto ya que utiliza el principio de la agilidad que es la
respuesta efectiva al cambio.
Dentro de un proceso gil el equipo de trabajo debe estar preparado para

cualquier suceso que se d dentro del proyecto, muchas veces el equipo debe
lidiar con la noticia de que los objetivos que se trazaron alcanzar desde el inicio
no son los mismos que el cliente espera.
Aunque la metodologa de desarrollo gil tiene el mismo enfoque que las

metodologas tradicionales (entregar software funcional en el tiempo
establecido), existen quienes toman a esta como un juego de los nuevos
programadores ocasionando una disputa entre los desarrolladores agiles y los
tradicionales.
Las metodologas de desarrollo gil se centran en el trabajo en equipo, es poresto

que denen varias caractersticas que debe tener, la comunicacin como tal es
muy importante no solo entre los miembros del equipo si no tambin con el
cliente; los proceso agiles reconocen al cliente como un integrante ms del
equipo as como los programadores o diseadores.
5. BIBLIOGRAFA
Laguna, M. sf. Ingeniera del Software I. (En lnea). VE. Consultado, 14 de abril
de 2015. Formato PDF. Disponible en: h p://www.infor.uva.es/~mlaguna
/is1/apuntes/1-intro.pdf (h p://www.infor.uva.es/~mlaguna/is1/apuntes
/1-intro.pdf)
35 de 40 27/03/2017 15:19
Pea, A. 2006. Ingeniera de Software: Una Gua para Crear Sistemas de

Informacin. (En lnea). VE. Consultado, 14 de abril de 2015. Formato PDF.
Disponible en: h p://www.wolnm.org/apa/articulos/ingenieria_software.pdf
(h p://www.wolnm.org/apa/articulos/ingenieria_software.pdf)

Olgin, M. 2004. Anlisis Orientado a Objetos Ingeniera del Software. (En lnea).
VE. Consultado, 14 de abril de 2015. Formato PDF. Disponible en:
h p://yaqui.mxl.uabc.mx/~molguin/as/IngSoft%201-4.pdf
(h p://yaqui.mxl.uabc.mx/~molguin/as/IngSoft%201-4.pdf)
6 MAYO, 2015 KARLA CEVALLOS DEJA UN

COMENTARIO
Modelos de Procesos: Especializado
Resumen de la clase dictada la semana 27 de

Abril- 1 de Mayo del 2015
1. INTRODUCCIN
Un modelo de proceso es un conjunto de actividades, tareas y acciones que se

realizan con el n de alcanzar el desarrollo completo de un proyecto de
software.
Existen diferentes modelos de proceso tales como los prescriptivos que se

utilizan cuando los requerimientos de software se encuentran bien denidos, los
especializados que incluyen las caractersticas de uno o ms modelos
tradicionales y se utilizan cuando el enfoque del proyecto se encuentra bien
denido.
Dentro de los modelos de proceso especializado podemos encontrar el desarrollo

basado en componentes, los mtodos formales y el desarrollo orientado a
aspectos, este ltimo se encuentra an en etapa de desarrollo ya que busca
denir la forma de especicar, disear y construir aspectos ( mecanismos ms
all de subrutinas y herencia para localizar la expresin de una preocupacin
global).
A continuacin se denen las caractersticas del modelo de proceso

especializado, adems del proceso unicado y los modelos de proceso personal
y de equipo que tiene un enfoque dirigido al trabajo en equipo por as decirlo.
2. OBJETIVO
Conocer sobre los modelos de proceso especializados su clasicacin y en qu

proyectos se utiliza, adems de analizar el desarrollo de software a travs del
proceso unicado o el modelo de proceso personal y de equipo.
36 de 40 27/03/2017 15:19
3. MARCO TERICO
3.1. Modelos de proceso Especializados
Los modelos de proceso especializado tienen muchas de las caractersticas de

uno o ms de los modelos tradicionales que se presentaron en las secciones
anteriores. Sin embargo, dichos modelos tienden a aplicarse cuando se elige un
enfoque de ingeniera de software especializado o denido muy
especcamente.
Los modelos de proceso especializados son los siguientes:
Figura 1: Modelos de proceso especializados
3.2. El proceso Unificado
El proceso unicado es un intento por obtener los mejores rasgos y caractersticas

de los modelos tradicionales del proceso del software, pero en forma que
implemente muchos de los mejores principios del desarrollo gil de software. El
proceso unicado reconoce la importancia de la comunicacin con el cliente y
los mtodos directos para describir su punto de vista respecto de un sistema.
Sugiere un ujo del proceso iterativo e incremental, lo que da la sensacin
evolutiva que resulta esencial en el desarrollo moderno del software.
37 de 40 27/03/2017 15:19
Figura 2: Modelos de proceso Unicado
La fase de concepcin del PU agrupa actividades tanto de comunicacin con el

cliente como de planeacin. Al colaborar con los participantes, se identican los
requerimientos del negocio, se propone una arquitectura aproximada para el
sistema y se desarrolla un plan para la naturaleza iterativa e incremental del
proyecto en cuestin.
3.3. Modelos de proceso Personal y de equipo
El mejor proceso del software es el que est cerca de las personas que harn el
trabajo. Si un modelo del proceso del software se ha desarrollado en un nivel
corporativo u organizacional, ser ecaz slo si acepta una adaptacin
signicativa para que cubra las necesidades del equipo de proyecto que en
realidad hace el trabajo de ingeniera de software.
3.3.1. Proceso personal del software
El proceso personal del software (PPS) pone el nfasis en la medicin personal tanto
del producto del trabajo que se genera como de su calidad. Adems, el PPS
responsabiliza al profesional acerca de la planeacin del proyecto (por ejemplo,
estimacin y programacin de actividades) y delega en el practicante el poder de
controlar la calidad de todos los productos del trabajo de software que se
desarrollen. El modelo del PPS dene cinco actividades estructurales:
38 de 40 27/03/2017 15:19
Figura 3: Modelos de proceso Personal
3.3.2. Proceso del equipo de software
El objetivo de ste es construir un equipo autodirigido para el proyecto, que se

organice para producir software de alta calidad.
Los objetivos que se denen para el proceso del equipo de software son los
siguientes:
Formar equipos autodirigidos que planeen y den seguimiento a su trabajo,

que establezcan metas y que sean dueos de sus procesos y planes.
Mostrar a los gerentes cmo dirigir y motivar a sus equipos y cmo ayudarlos
a mantener un rendimiento mximo.
Acelerar la mejora del proceso del software, haciendo del modelo de madurez
de la capacidad, CMM,23 nivel 5, el comportamiento normal y esperado.
Brindar a las organizaciones muy maduras una gua para la mejora.
Facilitar la enseanza universitaria de aptitudes de equipo con grado

industrial.
El PES dene las siguientes actividades estructurales: inicio del proyecto,diseo

de alto nivel, implementacin, integracin y pruebas, y post mrtem. Como
sus contrapartes del PPS (observe que la terminologa es algo diferente), estas
actividades permiten que el equipo planee, disee y construya software en
forma disciplinada, al mismo tiempo que mide cuantitativamente el proceso y el
producto. La etapa post mrtem es el escenario de las mejoras del proceso.
4. CONCLUSIONES
Los modelos de proceso especializados permiten utilizar las caractersticas de los

modelos de proceso tradicionales, haciendo que el desarrollo de software se
adapte mejor a los inconvenientes que pueden suscitarse en el mundo real.
El desarrollo de software basado en componentes est orientado a lareutilizacin

de cdigo, ya que esto permite a los programadores ahorrar recursos como
tiempo y costos, el desarrollo de mtodos formales utiliza especicaciones
matemticas para denir los requerimientos es por esto que es muy utilizado en
proyectos de control de aeronaves. El modelo de proceso orientado a aspectos se
encuentra an en desarrollo, las caractersticas que lo denen son que es una
combinacin del modelo evolutivo y el concurrente; utiliza la programacin
orientada a aspectos que busca denir y disear requerimientos de aspectos que
son aquellas preocupaciones globales que tienen algn efecto a travs de la
arquitectura del software.
39 de 40 27/03/2017 15:19
Los modelos de mtodos formales buscan utilizar las caractersticas de las

metodologas de desarrollo gil ya que reconoce la importancia de la
comunicacin con el cliente y su punto de vista de lo que ser el software. Los
modelos de proceso formales personales y de equipo hace nfasis en el trabajo
en equipo por as decirlo, ya que los proyectos que tienen xito son aquellos
donde todos los involucrados se encuentra activos durante el desarrollo.
5. BIBLIOGRAFA
Castillo, I; Francisca, L; Ma eo, A. 2010. VEN. La orientacin a aspectos y el

nuevo estndar SQuaREpara requisitos de software. Universidad Nacional
Experimental Sur del Lago. v.25 n.4. (En lnea). Consultado, 14 de abril de 2015.
Formato PDF. Disponible en: h p://www.scielo.org.ve
/scielo.php?script=sci_ar ext&pid (h p://www.scielo.org.ve
/scielo.php?script=sci_ar ext&pid)
Pacheco, I y Garca, J. 2008. Una Metodologa Basada en Prcticas Efectivas para

Desarrollar Software Educativo.MX. Postgraduate Department, Technological
University of the Mixtec Region. vol.11 no.4 . (En lnea). Consultado, 14 de abril de
2015. Formato PDF. Disponible en: h p://www.scielo.org.ve
/scielo.php?script=sci_ar ext&pid=S0798-40652010000400003&lang=pt

29 ABRIL, 2015 KARLA CEVALLOS DEJA UN

COMENTARIO
INGENIERA DEL SOFTWARE
BLOG DE WORDPRESS.COM.
40 de 40 27/03/2017 15:19

Diagramas de Secuencias

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Diagramas de Secuencias

Diunggah oleh

Hak Cipta:

Format Tersedia

Karla Cevallos | INGENIERA DEL SOFTWARE https://ingsotfwarekarlacevallos.wordpress.

INGENIERA DEL SOFTWARE

Portafolio Digital || ESPAM MFL

Autor: Karla Cevallos

UML: Diagrama de Secuencia

Resumen de la clase dictada la semana del 6-10

El lenguaje unicado de modelado UML Se utiliza para denir un sistema,

Dentro de los diagramas de comportamiento en UML que permiten enfatizar las

A continuacin se detallan las caractersticas de los diagramas de secuencias y

Conocer sobre los diagramas de secuencia en UML, sus caractersticas,

3.1. Diagrama de Secuencias

Un diagrama de secuencias muestra la interaccin de un conjunto de objetos de

Entre las ventajas que tiene la elaboracin de un diagrama de secuencias estn

Figura 1: Ventajas de los Diagramas de Secuencia

3.2. Elementos de un Diagrama de Secuencias

3.2.1. Rol de la Clase

El rol de la clase describe la manera en que un objeto se va a comportar en el

Figura 2: Objeto de una clase

Los cuadros de activacin representan el tiempo que un objeto necesita para

Figura 3: Activacin de una clase

3.2.4. Lneas de Vida

Figura 5: Linea de vida

3.2.5. Destruccin de Objetos

Figura 6: Destruccin de objetos

Una repeticin o loop en un diagrama de secuencias, es representado como un

En el siguiente ejemplo se muestra la secuencia que sigue un usuario del metro

Figura 8: Ejemplo de la secuencia de un usuario del metro para comprar un

Como se mencion anteriormente los diagramas de clases representan

El objetivo de UML es ser capaz de describir el comportamiento de un sistema,

Gutierrez, D. 2011. UML Diagrama de Secuencia. Universidad de los Andes.(En

Kendall, K y Kendall, J. 2011. Anlisis y diseo de sistemas. 8 ed. Mxico.

7 JULIO, 2015 KARLA CEVALLOS DEJA UN

UML: Relaciones entre clases

Resumen de la clase dictada la semana del 29 de

Como se mencion anteriormente los diagramas de clases describen los tipos de

Las relaciones que existen en un diagrama de clases permiten denir las

Conocer las relaciones que pueden existir dentro de un diagrama estructural

3.1. Utilidad de un Diagrama de Clase

El propsito de un diagrama de clase es describir las clases que conforman el

Figura 1: Perspectivas desde las cuales se elabora un diagrama de clases

3.2. Relaciones entre clases

Figura 2: Clasicacin de las relaciones que pueden existir en un diagrama de

Las asociaciones representan las relaciones ms generales entre clases, es decir,

La forma de representar las asociaciones binarias en UML es mediante una lnea

Si tenemos la clase perro y persona las siguientes relaciones podran darse:

Figura 3: Ejemplo de asociacin

La composicin implica que los componentes de un objeto slo pueden

A una empresa la componen empleados.

Figura 4: Ejemplo de composicin

La agregacin es una asociacin con unas connotaciones semnticas ms

Una empresa tiene clientes

Figura 5: Ejemplo de agregacin

La herencia es la tpica relacin de generalizacin/especializacin entre clases. En

Cuando de una superclase se derivan varias subclases existen dos notaciones

Figura 6: Ejemplo de herencia simple

3.2.2.1. Herencia mltiple

UML permite implementar la herencia mltiple cuando una clase hereda

Un profesor emrito puede ser un profesor como tambin un conferenciante

Figura 7: Ejemplo de herencia mltiple

El diagrama de clases pertenece a la categora de diagramas de estructura de

Dentro de un diagrama de clases se pueden relacionar las clases con una

Guidi, F. s/f. Diagramas de Clase Uml.Universidad Catlica de Chile. (En lnea).

Gutirrez, D. 2011. UML Diagramas de clases. (En lnea). VE. Consultado, 10 de

Kendall, K y Kendall, J. 2011. Anlisis y diseo de sistemas. 8 ed. Mxico.