Professional Documents
Culture Documents
NDICE.
Introduccin a la asignatura ................................................................................................................ 3
Metodologas de desarrollo de software. ........................................................................................... 4
Clasificacin de las metodologas.................................................................................................... 4
Metodologas estructuradas. .......................................................................................................... 4
Metodologas no estructuradas. ..................................................................................................... 5
Modelo en cascada.......................................................................................................................... 7
Modelo basado en prototipos. ........................................................................................................ 8
Modelo incremental. ....................................................................................................................... 9
Modelo en espiral.......................................................................................................................... 12
Desarrollo rapido de aplicaciones (RAD). ...................................................................................... 14
Modelo RUP. .................................................................................................................................. 16
Programacin extrema (XP). ......................................................................................................... 17
Agil MSF (Microsoft Solution FrameWork).................................................................................... 19
Otros enfoques de desarrollo de software.................................................................................... 22
Ventajas y desventajas. ................................................................................................................. 23
Unidad II. Administracin de requerimientos. .................................................................................. 27
Estudio de factibilidad. .................................................................................................................. 27
Factibilidad Tcnica. ...................................................................................................................... 27
Factibilidad Econmica. ................................................................................................................. 30
Factibilidad Operativa. .................................................................................................................. 37
Obtencin y anlisis de requerimientos........................................................................................ 38
Validacin de requerimientos. ...................................................................................................... 50
Unidad III. Anlisis y modelado de desarrollo de software con UML. .............................................. 52
Introduccin al UML. ..................................................................................................................... 52
Diagramas de casos de uso. .......................................................................................................... 53
Relaciones de Casos de Uso. ...................................................................................................... 54
Diagrama de clases. ....................................................................................................................... 56
Diagrama de secuencia. ................................................................................................................ 57
Diagrama de colaboracin............................................................................................................. 58
Diagrama de estado. ..................................................................................................................... 59
Bibliografa ........................................................................................................................................ 60
Introduccin a la asignatura
Programar es divertido, pero desarrollar software de calidad es difcil. Entre las ideas
esplendidas, los requisitos o la visin, y un producto software funcionando, hay mucho
ms que programar. El anlisis y el diseo que definen cmo solucionar el problema, que
programar, y la expresin de este diseo de forma que sea fcil de comunicar, revisar,
implementar y evolucionar constituyen la parte central de este documento.
En la actualidad se cuenta con diversas tipos de metodologas para el desarrollo de
software, lo cual genera una gran problemtica obre cual debemos de utilizar a la hora de
disear un software, para esto es necesario conocer una, y as poder elegir correctamente
la ms adecuada segn la necesidad que se tenga. En el presente documento se dan a
conocer las tecnologas de desarrollo de software ms utilizadas as como su
funcionamiento, con el fin de solucionar la necesidad de documentar un proyecto de
carcter tecnologico.
La Ingenieria de software es una disciplina o rea de la Informatica o ciencias de la
computacin que ofrece mtodos y tcnicas para desarrollar y mantener software de
calidad que resuelvan problemas de todo tipo. Hoy en da es cada vez ms frecuentemente
la consideracin de la Ingenieria del software como una nueva rea de las Ingenieria, y el
ingeniero del software comienza a ser una profesin implantada en el mundo laboral
internacional con derechos, deberes y responsabilidades que cumplir, junto a una, ya,
reconocida consideracin social ene l mundo empresarial y por suerte para esas personas
con brillante futuro.
La Ingenieria del software trata con reas muy diversas de la informtica y de las ciencias
de la computacin, tales como construccin de compiladores, sistemas operativos o
desarrollos de intranet/internet, abordando todas las fases del ciclo de vida del desarrollo
de cualquier tipo de sistemas de informacin y aplicables a una infinidad de reas tales
como: negocios, investigacin cientfica, medicina y produccin, logstica, banca, control
de trfico, meteorologa, el mundo del derecho, la red de redes internet, redes intranet y
extranet.
Metodologas no estructuradas.
Metodologas orientadas a objeto.
La orientacin a objetos unifica procesos y datos encapsulndolos en el concepto de
objetos.
Tiene dos enfoques distintos:
Revolucionario, puro u ortodoxo. Rompen con las metodologas tradicionales.
Ejemplos: Metodologas OOD de Booch, CRC/RDD de Wirfs-Brock.
Sintetiza o evolutivo. Toman como base los sistemas estructurados y conforman
elementos de uno u otro tipo.
Ejemplos: Metodologia OMT de Rumbourgh.
El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la dcada de 1960
para desarrollar a gran escala funcional de sistemas de negocio en una poca de grandes
conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas
de informacin en una muy deliberada, estructurada y metdica, reiterando cada una de
las etapas del ciclo de vida. Los sistemas de informacin en torno a las actividades
resueltas pesadas para el procesamiento de datos y rutinas de clculo.
1970s.
1980s.
Structured Systems Analysis and Design Methodology (SSADM) desde 1980.
Structured Analysis and Design Technique (SADT) desde 1980.
Ingenieria de la informaicon (IE/IEM) desde 1981.
1990s.
Nuevo milenio.
Modelo en cascada.
En ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada,
es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el
desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la
finalizacin de la etapa anterior.
Analisis de requisitos.
Dieo del sistema.
Diseo del programa.
Codificacin.
Pruebas.
Implantacin.
Mantenimiento.
Este modelo utiliza tramos como puntos de transicin y de carga. Al usar el modelo de cascada, se
necesitara completar un conjunto de tareas en forma de fase para despus continuar con la fase
proxima. El modelo en cascada trabaja perfectamente para los proyectos en los cuales los
Plan rapido.
Modelado, diseo rpido.
Desarrollo, entrega y retroalimentacin.
Comunicacin.
Entrega del desarrollo final.
Modelo incremental.
En trminos generales, se puede distinguir, en la Figura 4, los pasos generales que sigue el
proceso de desarrollo de un producto software. En el modelo de ciclo de vida
seleccionado, se identifican claramente dichos pasos. La descripcin del sistema es
esencial para especificar y confeccionar los distintos incrementos hasta llegar al producto
global y final. Las actividades concurrentes (especificacin, desarrollo y validacin)
sintetizan el desarrollo pormenorizado de los incrementos, que se har posteriormente.
El incremental es un modelo de tipo evolutivo que est basado en varios ciclos Cascada
Realimentados aplicados repetidamente, con una filosofa iterativa. En la Figura 5 se
muestra un refino del diagrama previo, bajo un esquema temporal, para obtener
finalmente el esquema del modelo de ciclo de vida Iterativo Incremental, con sus
actividades genricas asociadas. Aqu se observa claramente cada ciclo cascada que es
aplicado para la obtencin de un incremento; estos ltimos se van integrando para
obtener el producto final completo. Cada incremento es un ciclo Cascada Realimentado,
aunque, por simplicidad, en la Figura 5 se muestra como secuencial puro.
Se observa que existen actividades de desarrollo (para cada incremento) que son
realizadas en paralelo o concurrentemente, as por ejemplo, en la Figura, mientras se
realiza el diseo detalle del primer incremento ya se est realizando en anlisis del
segundo. La Figura 5 es slo esquemtica, un incremento no necesariamente se iniciar
durante la fase de diseo del anterior, puede ser posterior (incluso antes), en cualquier
tiempo de la etapa previa. Cada incremento concluye con la actividad de operacin y
mantenimiento (indicada como Operacin en la figura), que es donde se produce la
entrega del producto parcial al cliente. El momento de inicio de cada incremento es
dependiente de varios factores: tipo de sistema; independencia o dependencia entre
incrementos (dos de ellos totalmente independientes pueden ser fcilmente iniciados al
mismo tiempo si se dispone de personal suficiente); capacidad y cantidad de profesionales
involucrados en el desarrollo; etc.
Bajo este modelo se entrega software por partes funcionales ms pequeas, pero
reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel
que ya fue entregado.6
Como se muestra en la Figura 5, se aplican secuencias Cascada en forma escalonada,
mientras progresa el tiempo calendario. Cada secuencia lineal o Cascada produce un
incremento y a menudo el primer incremento es un sistema bsico, con muchas funciones
suplementarias (conocidas o no) sin entregar.
El cliente utiliza inicialmente ese sistema bsico, intertanto, el resultado de su uso y
evaluacin puede aportar al plan para el desarrollo del/los siguientes incrementos (o
versiones). Adems tambin aportan a ese plan otros factores, como lo es la priorizacin
(mayor o menor urgencia en la necesidad de cada incremento en particular) y la
dependencia entre incrementos (o independencia).
10
Luego de cada integracin se entrega un producto con mayor funcionalidad que el previo.
El proceso se repite hasta alcanzar el software final completo.
Siendo iterativo, con el modelo incremental se entrega un producto parcial pero
completamente operacional en cada incremento, y no una parte que sea usada para
reajustar los requisitos (como si ocurre en el modelo de construccin de prototipos).10
El enfoque incremental resulta muy til cuando se dispone de baja dotacin de personal
para el desarrollo; tambin si no hay disponible fecha lmite del proyecto por lo que se
entregan versiones incompletas pero que proporcionan al usuario funcionalidad bsica (y
cada vez mayor). Tambin es un modelo til a los fines de versiones de evaluacin.
Nota: Puede ser considerado y til, en cualquier momento o incremento incorporar
temporalmente el paradigma MCP como complemento, teniendo as una mixtura de
modelos que mejoran el esquema y desarrollo general.
11
Modelo en espiral.
El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo
que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y
sistemticos del Modelo Cascada. Proporciona potencial para desarrollo rpido de
versiones incrementales. En el modelo Espiral el software se construye en una serie de
versiones incrementales. En las primeras iteraciones la versin incremental podra ser un
modelo en papel o bien un prototipo. En las ltimas iteraciones se producen versiones
cada vez ms completas del sistema diseado.
El modelo se divide en un nmero de Actividades de marco de trabajo, llamadas regiones
de tareas. En general existen entre tres y seis regiones de tareas (hay variantes del
modelo). En la Figura 6 se muestra el esquema de un Modelo Espiral con 6 regiones. En
este caso se explica una variante del modelo original de Boehm, expuesto en su tratado de
1988; en 1998 expuso un tratado ms reciente.
12
Regin 3 - Tareas necesarias para evaluar los riesgos tcnicos y de gestin del
proyecto.
Regin 4 - Tareas para construir una o ms representaciones de la aplicacin software.
Regin 5 - Tareas para construir la aplicacin, instalarla, probarla y proporcionar
soporte al usuario o cliente (Ej. documentacin y prctica).
Regin 6 - Tareas para obtener la reaccin del cliente, segn la evaluacin de lo creado
e instalado en los ciclos anteriores.
Las actividades enunciadas para el marco de trabajo son generales y se aplican a cualquier
proyecto, grande, mediano o pequeo, complejo o no. Las regiones que definen esas
actividades comprenden un conjunto de tareas del trabajo: ese conjunto s se debe
adaptar a las caractersticas del proyecto en particular a emprender. Ntese que lo listado
en los tems de 1 a 6 son conjuntos de tareas, algunas de las ellas normalmente dependen
del proyecto o desarrollo en s.
Proyectos pequeos requieren baja cantidad de tareas y tambin de formalidad. En
proyectos mayores o crticos cada regin de tareas contiene labores de ms alto nivel de
formalidad. En cualquier caso se aplican actividades de proteccin (por ejemplo, gestin
de configuracin del software, garanta de calidad, etc.).
Al inicio del ciclo, o proceso evolutivo, el equipo de ingeniera gira alrededor del espiral
(metafricamente hablando) comenzando por el centro (marcado con en la Figura 6) y
en el sentido indicado; el primer circuito de la espiral puede producir el desarrollo de
una especificacin del producto; los pasos siguientes podran generar un prototipo y
progresivamente versiones ms sofisticadas del software.
Cada paso por la regin de planificacin provoca ajustes en el plan del proyecto; el coste y
planificacin se realimentan en funcin de la evaluacin del cliente. El gestor de proyectos
debe ajustar el nmero de iteraciones requeridas para completar el desarrollo.
El modelo espiral puede ir adaptndose y aplicarse a lo largo de todo el Ciclo de vida del
software (en el modelo clsico, o cascada, el proceso termina a la entrega del software).
Una visin alternativa del modelo puede observarse examinando el eje de punto de
entrada de proyectos. Cada uno de los circulitos () fijados a lo largo del eje representan
puntos de arranque de los distintos proyectos (relacionados); a saber:
13
Cuando la espiral se caracteriza de esta forma, est operativa hasta que el software se
retira, eventualmente puede estar inactiva (el proceso), pero cuando se produce un
cambio el proceso arranca nuevamente en el punto de entrada apropiado (por ejemplo,
en mejora del producto).
El modelo espiral da un enfoque realista, que evoluciona igual que el software; 11 se adapta
muy bien para desarrollos a gran escala.
El Espiral utiliza el MCP para reducir riesgos y permite aplicarlo en cualquier etapa de la
evolucin. Mantiene el enfoque clsico (cascada) pero incorpora un marco de trabajo
iterativo que refleja mejor la realidad.
Este modelo requiere considerar riesgos tcnicos en todas las etapas del proyecto;
aplicado adecuadamente debe reducirlos antes de que sean un verdadero problema.
El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de
Sistemas Operativos (complejos); tambin en sistemas de altos riesgos o crticos (Ej.
navegadores y controladores aeronuticos) y en todos aquellos en que sea necesaria una
fuerte gestin del proyecto y sus riesgos, tcnicos o de gestin.
14
15
Modelo RUP.
El Proceso Unificado de Rational (Rational Unified Process en ingls, habitualmente
resumido como RUP) es un proceso de desarrollo de software desarrollado por la
empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje
Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el
anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologas adaptables al contexto y necesidades de cada organizacin.
Tambin se conoce por este nombre al software, tambin desarrollado por Rational, que
incluye informacin entrelazada de diversos artefactos y descripciones de las diversas
actividades. Est incluido en el Rational Method Composer (RMC), que permite la
personalizacin de acuerdo con las necesidades.
Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y
una especificacin ms detallada, el Rational Unified Process, que se vendiera como
producto independiente.
16
17
18
Visin: En esta fase se debe realizar un estudio de lo que pretendemos en el futuro que
haga nuestra aplicacin o nuestro proyecto para ello debemos realizar un documento de
estrategia y alcance donde debe quedar pactada la necesidad de funcionalidad y servicio
que se debe contar en la solucin. Debemos crear los equipos de trabajo junto con el plan
de trabajo, Para asegurar el xito del proyecto es importante tener en cuenta el anlisis de
riesgos y plan de contingencia.
Planificacin: En esta fase bsicamente debemos concretar claramente cmo va a estar
estructurada nuestra solucin para ello debemos crear un documento de planificacin y
diseo de la arquitectura, disear las pruebas de concepto donde se plantean los
diferentes escenarios para probar la validez de los criterios utilizados para el diseo,
debemos establecer mtricas.
19
20
Escalable: Puede organizar equipo tan pequeo entre 3 o 4 personas, asi como
tambin proyectos que requieren 50 personas a ms.
Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
Tecnologa Agnstica: Porque puede ser usada para desarrollar solucione basadas
sobre cualquier tecnologa.
Modelos de planificacin en MSF.
MSF se compone de varios modelos encargados de planificar las diferentes partes
implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del proyecto, modelo
de equipo, modelo de proceso, modelo de gestin del riesgo, modelo de diseo de
proceso y finalmente el modelo de la aplicacin.
Modelo de arquitectura del proyecto.
Diseado para acortar la planificacin del ciclo de vida. Este modelo define las pautas para
construir proyectos empresariales a travs del lanzamiento de versiones.
Modelo de equipo.
Este modelo ha sido diseado para mejorar el rendimiento del equipo de desarrollo.
Proporciona una estructura flexible para organizar los equipos de un proyecto. Puede ser
escalado dependiendo del tamao del proyecto y del equipo de personas disponibles.
Modelo de proceso: Diseado para mejorar el control del proyecto, minimizando el riesgo,
y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de
pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la
liberacin de versiones y explicando su relacin con el modelo de equipo.
21
22
Ventajas y desventajas.
Modelo en cascada.
Variantes.
Existen variantes de este modelo; especialmente destacamos la que hace uso
de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento,
verificando que el sistema final est libre de fallos.
Desventajas.
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala
implementacin del modelo, lo cual hace que lo lleve al fracaso.
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala
implementacin del modelo, lo cual hace que lo lleve al fracaso.
El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso
de prueba y hasta que el software no est completo no se opera. Esto es la base para que
funcione bin.
Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al
rediseo nueva programacin del codigo afectado, aumentando los costos del desarrollo.
Modelo basado en prototipos.
Ventajas.
Este modelo es til cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, procesamiento o
salida.
Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del
software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un
sistema operativo o de la forma que debera tomar la interaccin humanomquina.
La construccin de prototipos se puede utilizar como un modelo del proceso
independiente, se emplea ms comnmente como una tcnica susceptible de
implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos.
Sin importar la forma en que ste se aplique, el paradigma de construccin de prototipos
ayuda al desarrollador de software y al cliente a entender de mejor manera cul ser el
resultado de la construccin cuando los requisitos estn satisfechos. De esta manera, este
ciclo de vida en particular, involucra al cliente ms profundamente para adquirir el
producto
23
Modelo espiral.
Ventajas.
Este modelo requiere considerar riesgos tcnicos en todas las etapas del proyecto;
aplicado adecuadamente debe reducirlos antes de que sean un verdadero
problema.
El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de
Sistemas Operativos (complejos); tambin en sistemas de altos riesgos o crticos
(Ej. navegadores y controladores aeronuticos) y en todos aquellos en que sea
necesaria una fuerte gestin del proyecto y sus riesgos, tcnicos o de gestin.
Desventajas.
Es difcil convencer a los grandes clientes que se podr controlar este enfoque evolutivo.
Este modelo no se ha usado tanto, como el Cascada (Incremental) o MCP, por lo que no
se tiene bien medida su eficacia, es un paradigma relativamente nuevo y difcil de
implementar y controlar.
Desventajas.
24
Modelo RUP.
Principales caractersticas.
Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo
y cmo)
Pretende implementar las mejores prcticas en Ingeniera de Software
Desarrollo iterativo
Administracin de requisitos
Uso de arquitectura basada en componentes
Control de cambios
25
Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para
aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento.
Las pruebas han de garantizar que en la refactorizacin no se ha introducido
ningn fallo.
Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el
desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo promueve
el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las
frecuentes pruebas de regresin garantizan que los posibles errores sern
detectados.
Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando
todo funcione se podr aadir funcionalidad si es necesario. La programacin
extrema apuesta que es ms sencillo hacer algo simple y tener un poco de trabajo
extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca
utilizarlo.
La simplicidad y la comunicacin son extraordinariamente complementarias. Con
ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer.
Cuanto ms simple es el sistema, menos tendr que comunicar sobre ste, lo que
lleva a una comunicacin ms completa, especialmente si se puede reducir el
equipo de programadores.
26
27
sistema propuesto, adems hay que agregar que estos componentes se encuentran en el
mercado actualmente a unos precios bajos.
En el siguiente cuadro se muestra la descripcin del hardware disponible en la
Organizacin y que fue utilizado para el diseo, construccin y puesta en marcha del
sistema REDAIC.
28
29
Como resultado de este estudio tcnico se determin que en los actuales momentos, la institucin
posee la infraestructura tecnolgica (Hardware y Software) necesaria para el desarrollo y puesta en
funcionamiento el sistema propuesto.
Factibilidad Econmica.
A continuacin se presenta un estudio que dio como resultado la factibilidad econmica
del desarrollo del nuevo sistema de informacin. Se determinaron los recursos para
desarrollar, implantar y mantener en operacin el sistema programado, haciendo una
evaluacin donde se puso de manifiesto el equilibrio existente entre los costos intrnsecos
del sistema y los beneficios que se derivaron de ste, lo cual permiti observar de una
manera ms precisa las bondades del sistema propuesto.
Anlisis costos Beneficios.
Este anlisis permiti hacer una comparacin entre la relacin costos del sistema actual, y
los costos que tendra un nuevo sistema, conociendo de antemano los beneficios que la
ciencia de la informtica ofrece.
Como se mencion anteriormente en el estudio de factibilidad tcnica, la organizacin
contaba con las herramientas necesarias para la puesta en marcha del sistema, por lo cual
el desarrollo de la propuesta no requiri de una inversin inicial.
30
31
32
33
34
35
36
Factibilidad Operativa.
La factibilidad operativa permite predecir, si se pondr en marcha el sistema propuesto,
aprovechando los beneficios que ofrece, a todos los usuarios involucrados con el mismo,
ya sean los que interactan en forma directa con este, como tambin aquellos que reciben
informacin producida por el sistema. Por otra parte, el correcto funcionamiento del
sistema en cuestin, siempre estar supeditado a la capacidad de los empleados
encargados de dicha tarea.
37
38
39
40
Adems de los stakeholders del sistema, ya hemos visto que los requerimientos pueden venir del
dominio de la aplicacin y de otros sistemas que interactan con el sistema a especificar. Todos
stos se deben considerar durante el proceso de obtencin de requerimientos.
41
42
43
44
45
46
47
48
49
Validacin de requerimientos.
50
51
52
La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un
mecanismo de organizacin, un conjunto de casos de uso coherente y consistente
promueven una imagen fcil de comprender del comportamiento del sistema, un
entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo.
53
54
notacin, es una flecha de punta abierta con lnea discontinua, desde el caso de uso
extensin al caso de uso extendido, con la etiqueta extend. Esto puede ser til para
lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento
del sistema y su extensin.
"La extensin, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la
extensin son los ejemplos o instancias de los conceptos."
Documentan el comportamiento de un sistema desde el punto de vista de un usuario
En otras palabras ser utilizado cuando un caso de uso sea similar a otro pero con ciertas
variaciones, un ejemplo claro es que se necesite comprar azcar y podemos seleccionar de
entre azcar rubia, blanca o su unidad de medida bolsa, kilo.
Generalizacin.
"Entonces la Generalizacin es la actividad de identificar elementos en comn entre
conceptos y definir las relaciones de una superclase (concepto general) y subclase
(concepto especializado). Es una manera de construir clasificaciones taxonmicas entre
conceptos que entonces se representan en jerarquas de clases. Las subclases
conceptuales son conformes con las superclases conceptuales en cuanto a la intencin y
extensin."
En la tercera forma de relaciones entre casos de uso, existe una relacin
generalizacin/especializacin. Un caso de uso dado puede estar en una forma
especializada de un caso de uso existente. La notacin es una lnea slida terminada en un
tringulo dibujado desde el caso de uso especializado al caso de uso general. Esto se
asemeja al concepto orientado a objetos de sub-clases, en la prctica puede ser til
factorizar comportamientos comunes, restricciones al caso de uso general, describirlos
una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.
55
Diagrama de clases.
56
Diagrama de secuencia.
57
Diagrama de colaboracin.
Muestra cmo las instancias especficas de las clases trabajan juntas para conseguir un
objetivo comn.
Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de
un objeto a otro. Dicha implementacin es llamada "enlace".
58
enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicacin. Cuando
se instancia una comunicacin, los objetos estn ligados a los roles de clasificador y los
enlaces a los roles de asociacin. El rol de asociacin puede ser desempeado por varios
tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales
del procedimiento. Los smbolos de enlace pueden llevar estereotipos para indicar enlaces
temporales.
Diagrama de estado.
Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto
durante su vida en una aplicacin en respuesta a eventos (por ejemplo, mensajes
recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. Tambin
ilustran qu eventos pueden cambiar el estado de los objetos de la clase. Normalmente
contienen: estados y transiciones. Como los estados y las transiciones incluyen, a su vez,
eventos, acciones y actividades, vamos a ver primero sus definiciones.
Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas
explicativas y restricciones.
59
Bibliografa
Booch G. Rumbaugh j., J. I. (2000). El lenguaje Unificado de Modelado. Guia del usuario. Madrid:
Addison Wesley.
Larman, C. (2003). IEEE recommended practice for software requierements specifications (8301998). Espaa: IEEE Computer Society.
60