Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Guia de Ingenieria Del Software
Guia de Ingenieria Del Software
Adems de los programas y los datos, los usuarios necesitan tambin una explicacin de
cmo usar el programa.
Documentos como manuales de usuario y de operacin son necesarios para permitir a los
usuarios operar con el sistema.
Los documentos tambin son requeridos por las personas encargadas de mantener el
software para entender el interior del software y modificarlo, en el caso en que sea
necesario.
Tipos de software
El software puede dividirse en dos grandes categoras:
Software de aplicaciones: se usan para proveer servicios a clientes y ejecutar negocios
de forma ms eficiente. El software de aplicaciones puede ser un sistema pequeo o uno
grande integrado. Como ejemplos de este tipo de software estn: un sistema de cuentas,
un sistema de planificacin de recursos
Software de sistemas: el software de sistemas se usa para operar y mantener un
sistema informtico. Permite a los usuarios usar los recursos del ordenador directamente
y a travs de otro software. Algunos ejemplos de este tipo de software son: sistemas
operativos, compiladores y otras utilidades del sistema.
INGENIERA DEL SOFTWARE
Historia
El trmino ingeniera del software apareci por primera vez en la conferencia de ingeniera
de software de la OTAN en 1968 y fue mencionado para provocar el pensamiento sobre la
crisis de software del momento. Desde entonces, ha continuado como una profesin y
campo de estudio dedicado a la creacin de software de alta calidad, barato, con capacidad
de mantenimiento y rpido de construir. Debido a que el campo es todava relativamente
joven comparado con otros campos de la ingeniera, hay todava mucho trabajo y debate
sobre qu es realmente la ingeniera del software, y si se merece el ttulo de ingeniera. Ha
crecido orgnicamente fuera de las limitaciones de ver el software slo como programacin.
Mientras que el trmino ingeniera del software fue acuado en una conferencia en 1968, los
problemas que intentaba tratar empezaron mucho antes. La historia de la ingeniera del
software est entrelazada con las historias contrapuestas de hardware y software.
Cuando el ordenador digital moderno apareci por primera vez en 1941, las instrucciones
para hacerlo funcionar estaban conectadas dentro de la maquina. Las personas
relacionadas con la ingeniera rpidamente se dieron cuenta de que este diseo no era
flexible e idearon la arquitectura de programa almacenado o arquitectura von Neumann. De
esta forma la primera divisin entre hardware y software empez con la abstraccin
usada para tratar la complejidad de la computacin.
Los lenguajes de programacin empezaron a aparecer en la dcada de 1950 y este fue otro
paso importante en la abstraccin. Los lenguajes principales como Fortran, Algol y Cobol se
lanzaron a finales de los 50s para tratar con problemas cientficos, algortmicos y de negocio
respectivamente. Dijsktra escribi Go to Statement Considered Harmful en 1968 y David
Parnas introdujo el concepto clave de la modularidad y encapsulacin en 1972 para ayudar
a los programadores a tratar con la complejidad de los sistemas de software. Un sistema
software para gestionar el hardware, denominado sistema operativo tambin se introdujo,
ms notablemente por Unix en 1969. En 1967, el lenguaje Simula introdujo el paradigma de
la programacin orientada a objetos.
Estos avances en software se encontraron con ms avances en el hardware. A mediados de
los 70s, la microcomputadora fue introducida, haciendo econmico a los aficionados a
obtener una computadora y escribir software para l. Esto sucesivamente condujo al famoso
ordenador personal o PC y Microsoft Windows. El ciclo de vida de desarrollo de software o
SDLC tambin empez a aparecer como un consenso para la construccin centralizada de
software a mediados de los 80s. A finales de los 70s y principios de los 80 se vieron varios
lenguajes de programacin orientados a objetos inspirados en Simula, incluyendo C++,
Smalltalk y Objective C.
El software open source empez a aparecer a principios de los 90s en la forma de Linux y
otros software introduciendo el bazaar o el estilo descentralizado de construccin de
software. Despus aparecieron Internet y la World Wide Web a mediados de los 90s
cambiando de nuevo la ingeniera del software. Los sistemas distribuidos ganaron dominio
como forma de disear sistemas y el lenguaje de programacin Java se introdujo como otro
paso en la abstraccin, teniendo su propia mquina virtual. Varios programadores
colaboraron y escribieron el manifiesto gil que favoreci procesos ms ligeros para crear
software ms barato y en menos tiempo.
Etapas
La ingeniera de software requiere llevar a cabo numerosas tareas, dentro de etapas como
las siguientes:
Anlisis de requisitos
Extraer los requisitos de un producto software es la primera etapa para crearlo. Mientras que
los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere habilidad
y experiencia en la ingeniera del software para reconocer requisitos incompletos, ambiguos
o contradictorios. El resultado del anlisis de requisitos con el cliente se plasma en el
documento Especificacin de Requisitos. Asimismo, se define un diagrama de
entidad/relacin, en el que se plasman las principales entidades que participarn en el
desarrollo de software.
La captura, anlisis y especificacin de requisitos (incluso pruebas de ellos), es una parte
crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han
ideado modelos y diversos procesos de trabajo para estos fines. Aunque an no est
formalizada, se habla de la Ingeniera de Requisitos.
Realizar un diseo.
Documentar.
Asuncin de responsabilidades.
Nunca dejes que tu jefe o cliente te convenza para hacer un mal trabajo.
No puedes cambiar todo de una vez. Identifica los cambios que se traduzcan en los
mayores beneficios, y comienza a implementarlos.
Capas
El enfoque de ingeniera del software cuenta con un compromiso organizacional con la
calidad porque no es posible incorporar la ingeniera del software en una organizacin que
no est centrada en conseguir calidad.
La ingeniera del software es una tecnologa multicapa. Se puede ver como un conjunto de
componentes estratificados, que reposan sobre ese enfoque de calidad.
Figura 2.
Procesos
El fundamento de la ingeniera del software es la capa de proceso. El proceso define un
marco de trabajo para un conjunto de reas clave de proceso que se deben establecer para
la entrega efectiva de la tecnologa de la ingeniera del software.
La capa de proceso define el proceso que se usar para construir el software y las
actividades y tareas que un jefe de proyecto tiene que gestionar. Por lo tanto, las reas
claves del proceso forman la base del control de gestin de proyectos del software y
establecen el contexto en el que se aplican los mtodos tcnicos, se obtienen productos de
trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se
asegura la calidad y el cambio se gestiona adecuadamente. El proceso de la ingeniera del
software es la unin que mantiene juntas las capas de tecnologas y que permite un
desarrollo racional y oportuno de la ingeniera del software.
Mtodos
La capa de proceso identifica las tareas de ingeniera que se deben realizar para construir
software de alta calidad.
La siguiente capa, la capa de mtodos se centra en las actividades tcnicas que se deben
realizar para conseguir las tareas de ingeniera. Proporciona el cmo y cubre las
actividades de ingeniera fundamentales.
Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo,
construccin de programas, pruebas y mantenimiento. Los mtodos de la ingeniera del
software dependen de un conjunto de principios bsicos que gobiernan cada una de las
reas de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas.
La construccin de software implica una amplia coleccin de actividades tcnicas. La capa
de mtodos contiene los mtodos definidos para realizar esas actividades de forma
eficiente. Se centra en cmo se han de realizar las actividades tcnicas. Los personas
involucradas usan los mtodos para realizar las actividades de ingeniera fundamentales
necesarias para construir el software.
Herramientas
La capa de herramientas proporciona soporte a las capas de proceso y mtodos
centrndose en el significado de la automatizacin de algunas de las actividades manuales.
Las herramientas se pueden utilizar para automatizar las siguientes actividades:
La automatizacin ayuda a eliminar el tedio del trabajo, reduce las posibilidades de errores,
y hace ms fcil usar buenas prcticas de ingeniera del software. Cuando se usan
herramientas, la documentacin se convierte en una parte integral del trabajo hecho, en vez
de ser una actividad adicional. De ah que la documentacin no se tenga que realizar como
actividad adicional. Las herramientas se pueden utilizar para realizar actividades de gestin
de proyecto as como para actividades tcnicas.
CICLOS DE VIDA DE DESARROLLO DEL SOFTWARE
CICLOS DE VIDA
El ciclo de vida es el conjunto de fases por las que pasa el sistema que se est
desarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado
(muere). Tambin se denomina a veces paradigma.
Entre las funciones que debe tener un ciclo de vida se pueden destacar:
Definir un esquema que sirve como base para planificar, organizar, coordinar,
desarrollar
Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas
que se pueden planificar. Segn el modelo de ciclo de vida, la sucesin de fases puede
ampliarse con bucles de realimentacin, de manera que lo que conceptualmente se
considera una misma fase se pueda ejecutar ms de una vez a lo largo de un proyecto,
Las caractersticas (contenidos) de las fases en que dividen el ciclo. Esto puede
depender del propio tema al que se refiere el proyecto, o de la organizacin.
Define las fases primarias esperadas de ser ejecutadas durante esas fases
En cada una de las etapas de un modelo de ciclo de vida, se pueden establecer una serie
de objetivos, tareas y actividades que lo caracterizan. Existen distintos modelos de ciclo de
vida, y la eleccin de un modelo para un determinado tipo de proyecto es realmente
importante; el orden es uno de estos puntos importantes.
Existen varias alternativas de modelos de ciclo de vida. A continuacin se muestran algunos
de los modelos tradicionales y ms utilizados.
Modelo en cascada
Es el enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del
software, de forma que el inicio de cada etapa debe esperar a la finalizacin de la
inmediatamente anterior.
El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se ve
fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida.
Se cree que el modelo en cascada fue el primer modelo de proceso introducido y seguido
ampliamente en la ingeniera el software. La innovacin estuvo en la primera vez que la
ingeniera del software fue dividida en fases separadas.
La primera descripcin formal del modelo en cascada se cree que fue en un artculo
publicado en 1970 por Winston W. Royce, aunque Royce no us el trmino cascada en este
artculo. Irnicamente, Royce estaba presentando este modelo como un ejemplo de modelo
que no funcionaba, defectuoso.
En el modelo original de Royce, existan las siguientes fases:
1. Especificacin de requisitos
2. Diseo
3. Construccin (Implementacin o codificacin)
4. Integracin
5. Pruebas
6. Instalacin
7. Mantenimiento
Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una forma
puramente secuencial.
REQUISITOS
DISEO
IMPLEMENTACIN
PRUEBAS
MANTENIMIENTO
Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria, sigue siendo
el paradigma ms seguido a da de hoy.
Modelo en V
El modelo en v se desarroll para terminar con algunos de los problemas que se vieron
utilizando el enfoque de cascada tradicional. Los defectos estaban siendo encontrados
demasiado tarde en el ciclo de vida, ya que las pruebas no se introducan hasta el final del
proyecto. El modelo en v dice que las pruebas necesitan empezarse lo ms pronto posible
en el ciclo de vida. Tambin muestra que las pruebas no son slo una actividad basada en
la ejecucin. Hay una variedad de actividades que se han de realizar antes del fin de la fase
de codificacin. Estas actividades deberan ser llevadas a cabo en paralelo con las
actividades de desarrollo, y los tcnicos de pruebas necesitan trabajar con los
desarrolladores y analistas de negocio de tal forma que puedan realizar estas actividades y
tareas y producir una serie de entregables de pruebas. Los productos de trabajo generados
por los desarrolladores y analistas de negocio durante el desarrollo son las bases de las
pruebas en uno o ms niveles. El modelo en v es un modelo que ilustra cmo las
actividades de prueba (verificacin y validacin) se pueden integrar en cada fase del ciclo de
vida. Dentro del modelo en v, las pruebas de validacin tienen lugar especialmente durante
las etapas tempranas, por ejemplo, revisando los requisitos de usuario y despus por
ejemplo, durante las pruebas de aceptacin de usuario.
El modelo en v es un proceso que representa la secuencia de pasos en el desarrollo del
ciclo de vida de un proyecto. Describe las actividades y resultados que han de ser
producidos durante el desarrollo del producto. La parte izquierda de la v representa la
descomposicin de los requisitos y la creacin de las especificaciones del sistema. El lado
derecho de la v representa la integracin de partes y su verificacin. V significa Validacin y
Verificacin.
INGENIERA
DE REQUISITOS
Validar requisitos
DISEO DEL
SISTEMA
VALIDACIN
DEL SISTEMA
Verificar
diseo
VERIFICACIN
DEL SISTEMA
VERIFICACIN
DEL SOFTWARE
DISEO DEL
SOFTWARE
CODIFICACIN
Realmente las etapas individuales del proceso pueden ser casi las mismas que las del
modelo en cascada. Sin embargo hay una gran diferencia. En vez de ir para abajo de una
forma lineal las fases del proceso vuelven hacia arriba tras la fase de codificacin, formando
una v. La razn de esto es que para cada una de las fases de diseo se ha encontrado que
hay un homlogo en las fases de pruebas que se correlacionan.
Modelo iterativo
Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo
que surge entre las necesidades del usuario y el producto final por malos entendidos
durante la etapa de recogida de requisitos.
Consiste en la iteracin de varios ciclos de vida en cascada. Al final de cada iteracin se le
entrega al cliente una versin mejorada o con mayores funcionalidades del producto. El
cliente es quien despus de cada iteracin evala el producto y lo corrige o propone
mejoras. Estas iteraciones se repetirn hasta obtener un producto que satisfaga las
necesidades del cliente.
ANLISIS
ANLISIS
DISEO
ANLISIS
DISEO
CODIFICACIN
DISEO
CODIFICACIN
PRUEBAS
CODIFICACIN
PRUEBAS
PRUEBAS
Versin 2
Versin 1
Versin 3
Este modelo se suele utilizar en proyectos en los que los requisitos no estn claros por parte
del usuario, por lo que se hace necesaria la creacin de distintos prototipos para
presentarlos y conseguir la conformidad del cliente.
Modelo de desarrollo incremental
El modelo incremental combina elementos del modelo en cascada con la filosofa interactiva
de construccin de prototipos. Se basa en la filosofa de construir incrementando las
funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada
mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento
del software.
ANLISIS
ANLISIS
DISEO
ANLISIS
DISEO
CODIFICACIN
CODIFICACIN
PRUEBAS
CODIFICACIN
PRUEBAS
Figura 6.
DISEO
PRUEBAS
producto operativo con cada incremento. Los primeros incrementos son versiones
incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y
tambin una plataforma para la evaluacin.
Modelo en espiral
El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en
1985, utilizado de forma generalizada en la ingeniera del software. Las actividades de este
modelo se conforman en una espiral, cada bucle representa un conjunto de actividades. Las
actividades no estn fijadas a priori, sino que las siguientes se eligen en funcin del anlisis
de riesgos, comenzando por el bucle anterior.
Boehm, autor de diversos artculos de ingeniera del software; modelos de estimacin de
esfuerzos y tiempo que se consume en hacer productos software; y modelos de ciclo de
vida, ide y promulg un modelo desde un enfoque distinto al tradicional en Cascada: el
Modelo Evolutivo Espiral. Su modelo de ciclo de vida en espiral tiene en cuenta fuertemente
el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las
posibles alternativas de desarrollo, se opta por la de riesgos ms asumibles y se hace un
ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelven a
evaluar las nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, as hasta que
llegue un momento en el que el producto software desarrollado sea aceptado y no necesite
seguir mejorndose con otro nuevo ciclo.
Este modelo de desarrollo combina las caractersticas del modelo de prototipos y el modelo
en cascada. El modelo en espiral est pensado para proyectos largos, caros y complicados.
Esto modelo no fue el primero en tratar el desarrollo iterativo, pero fue el primer modelo en
explicar las iteraciones.
Este modelo fue propuesto por Boehm en 1988 en su artculo A Spiral Model of Software
Development and Enhancement. Bsicamente consiste en una serie de ciclos que se
repiten en forma de espiral, comenzando desde el centro. Se suele interpretar como que
dentro de cada ciclo de la espiral se sigue un modelo en cascada, pero no necesariamente
ha de ser as.
Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por
ejemplo, la creacin de un sistema operativo.
Al ser un modelo de ciclo de vida orientado a la gestin de riesgos se dice que uno de los
aspectos fundamentales de su xito radica en que el equipo que lo aplique tenga la
necesaria experiencia y habilidad para detectar y catalogar correctamente riesgos.
Tareas:
Para cada ciclo habr cuatro actividades:
1. Determinar o fijar objetivos:
a. Fijar tambin los productos definidos
especificacin, manual de usuario.
obtener:
requerimientos,
DETERMINAR
OBJETIVOS
EVALUAR
RIESGOS
PLANIFICAR
DESARROLLAR
Y PROBAR
La tarea de anlisis de riesgos: para evaluar riesgos tanto tcnicos como de gestin
Modelo UML
Qu es UML?
UML es el primer mtodo en publicar una meta-modelo en su propia notacin, incluyendo la
notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata pues de un
meta-modelo auto-referencial (cualquier lenguaje de modelado de propsito general debera
ser capaz de modelarse a s mismo).
UML es un lenguaje estndar que sirve para escribir los planos del software, puede utilizarse
para visualizar, especificar, construir y documentar todos los artefactos que componen un
sistema con gran cantidad de software. UML puede usarse para modelar desde sistemas de
informacin hasta aplicaciones distribuidas basadas en Web, pasando por sistemas
empotrados de tiempo real.
UML es solamente un lenguaje por lo que es slo una parte de un mtodo de desarrollo
software, es independiente del proceso aunque para que sea optimo debe usarse en un
proceso dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental.
UML es un lenguaje por que proporciona un vocabulario y las reglas para utilizarlo, adems es
un lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la
representacin conceptual y fsica del sistema.
UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante grficos o
mediante texto obteniendo modelos explcitos que ayudan a la comunicacin durante el
desarrollo ya que al ser estndar, los modelos podrn ser interpretados por personas que no
participaron en su diseo (e incluso por herramientas) sin ninguna ambigedad. En este
contexto, UML sirve para especificar, modelos concretos, no ambiguos y completos.
Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga de ellos:
Elementos estructurales.
Elementos de comportamiento.
Elementos de agrupacin
Elementos de anotacin.
Las relaciones, a su vez se dividen para abarcar las posibles interacciones entre elementos
que se nos pueden presentar a la hora de modelar usando UML, estas son: relaciones de
dependencia, relaciones de asociacin, relaciones de generalizacin y relaciones de
realizacin.
Se utilizan diferentes diagramas dependiendo de qu, nos interese representar en cada
momento, para dar diferentes perspectivas de un mismo problema, para ajustar el nivel de
detalle..., por esta razn UML soporta un gran numero de diagramas diferentes aunque, en la
practica, slo se utilicen un pequeo nmero de combinaciones.
UML proporciona un conjunto de reglas que dictan las pautas a la hora de realizar asociaciones
entre objetos para poder obtener modelos bien formados, estas son reglas semnticas que
afectan a los nombres, al alcance de dichos nombres, a la visibilidad de estos nombres por
otros, a la integridad de unos elementos con otros y a la ejecucin, o sea la vista dinmica del
sistema.
UML proporciona una serie de mecanismos comunes que sirven para que cada persona o
entidad adapte el lenguaje a sus necesidades, pero dentro de un marco ordenado y siguiendo
unas ciertas reglas para que en el trasfondo de la adaptacin no se pierda la semntica propia
de UML. Dentro de estos mecanismos estn las especificaciones, que proporcionan la
explicacin textual de la sintaxis y semntica de los bloques de construccin.
Otro mecanismo es el de los adornos que sirven para conferir a los modelos de ms
semntica, los adornos son elementos secundarios ya que proporcionan ms nivel de detalle,
que quiz en un primer momento no sea conveniente descubrir. Las divisiones
comunes permiten que los modelos se dividan al menos en un par de formas diferentes para
facilitar la comprensin desde distintos puntos de vista, en primer lugar tenemos la divisin
entre clase y objeto (clase es una abstraccin y objeto es una manifestacin de esa
Interfaz
Una interfaz es una coleccin de operaciones que especifican un servicio de una determinada
clase o componente. Una interfaz describe el comportamiento visible externamente de ese
elemento, puede mostrar el comportamiento completo o slo una parte del mismo. Una interfaz
describe un conjunto de especificaciones de operaciones (o sea su signatura) pero nunca su
implementacin. Se representa con un circulo, , y rara vez se encuentra aislada sino que ms
bien conectada a la clase o componente que realiza.
Interfaz
Colaboracin
Define una interaccin y es una sociedad de roles y otros elementos que colaboran para
proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de
sus elementos. Las colaboraciones tienen una dimensin tanto estructural como de
comportamiento. Una misma clase puede participar en diferentes colaboraciones. Las
colaboraciones representan la implementacin de patrones que forman un sistema. Se
representa mediante una elipse con borde discontinuo.
Colaboracin
Casos de Uso
Un caso de uso es la descripcin de un conjunto de acciones que un sistema ejecuta y que
produce un determinado resultado que es de inters para un actor particular. Un caso de uso
se utiliza para organizar los aspectos del comportamiento en un modelo. Un caso de uso es
realizado por una colaboracin. Se representa como en la figura 6, una elipse con borde
continuo.
Caso de uso
Clase Activa
Es una clase cuyos objetos tienen uno o ms procesos o hilos de ejecucin por lo y tanto
pueden dar lugar a actividades de control. Una clase activa es igual que una clase, excepto que
sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos.
Se representa igual que una clase, pero con lneas ms gruesas
Clase activa
Componentes
Un componente es una parte fsica y reemplazable de un sistema que conforma con un
conjunto de interfaces y proporciona la implementacin de dicho conjunto. Un componente
representa tpicamente el empaquetamiento fsico de diferentes elementos lgicos, como
clases, interfaces y colaboraciones.
Componente
Nodos
Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso
computacional que, por lo general, dispone de algo de memoria y, con frecuencia, de
capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo.
Nodo
Estos siete elementos vistos son los elementos estructurales bsico que se pueden incluir en
un modelo UML. Existen variaciones sobre estos elementos bsicos, tales como
actores, seales, utilidades (tipos de clases), procesos e hilos (tipos de clases activas) y
aplicaciones, documentos, archivos, bibliotecas, pginas y tablas (tipos de componentes).
Elementos de comportamiento
Los elementos de comportamiento son las partes dinmicas de un modelo. Se podra decir que
son los verbos de un modelo y representan el comportamiento en el tiempo y en el espacio.
Los principales elementos son los dos que siguen.
Interaccin
Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un
conjunto de objetos, dentro de un contexto particular para conseguir un propsito especfico.
Una interaccin involucra otros muchos elementos, incluyendo mensajes, secuencias
de accin (comportamiento invocado por un objeto) y enlaces (conexiones entre objetos). La
representacin de un mensaje es una flecha dirigida que normalmente con el nombre de la
operacin.
Mquinas de estados
Es un comportamiento que especifica las secuencias de estados por las que van pasando los
objetos o las interacciones durante su vida en respuesta a eventos, junto con las respuestas a
esos eventos. Una mquina de estados involucra otros elementos como son estados,
transiciones (flujo de un estado a otro), eventos (que disparan una transicin) y actividades
(respuesta de una transicin)
Elementos
de
comportamiento
Interaccin
Comprende un conjunto de
mensajes
que
se
intercambian
entre
un
conjunto de objetos, para
cumplir
un
objetivo
especifico.
Mquinas
de
estados
Especifica la secuencia de
estados por los que pasa un
objeto o una interaccin, en
respuesta a eventos.
Elementos de agrupacin
Forman la parte organizativa de los modelos UML. El principal elemento de agrupacin es
el paquete, que es un mecanismo de propsito general para organizar elementos en grupos.
Los elementos estructurales, los elementos de comportamiento, incluso los propios elementos
de agrupacin se pueden incluir en un paquete.
Un paquete es puramente conceptual (slo existe en tiempo de desarrollo). Grficamente se
representa como una carpeta conteniendo normalmente su nombre y, a veces, su contenido.
Elementos
de
agrupacin
Elementos de anotacin
Los elementos de anotacin son las partes explicativas de los modelos UML. Son comentarios
que se pueden aplicar para describir, clasificar y hacer observaciones sobre cualquier elemento
de un modelo.
El tipo principal de anotacin es la nota que simplemente es un smbolo para mostrar
restricciones y comentarios junto a un elemento o un conjunto de elementos.
Elementos
de
notacin
Relaciones
Existen cuatro tipos de relaciones entre los elementos de un modelo
UML. Dependencia, asociacin, generalizacin y realizacin,
estas
se
describen
a
continuacin:
Dependencia
Es una relacin semntica entre dos elementos en la cual un cambio a un elemento (el
elemento
independiente) puede afectar a la semntica del otro elemento (elemento dependiente). Se
representa como una lnea discontinua, posiblemente dirigida, que a veces incluye una
etiqueta.
Dependencia
Asociacin
Es una relacin estructural que describe un conjunto de enlaces, los cuales son conexiones
entre objetos. La agregacin es un tipo especial de asociacin y representa una relacin
estructural entre un todo y sus partes. La asociacin se representa con una lnea continua,
posiblemente dirigida, que a veces incluye una etiqueta. A menudo se incluyen otros adornos
para indicar la multiplicidad y roles de los objetos involucrados.
Asociacin
Generalizacin
Realizacin
Es una relacin semntica entre clasificadores, donde un clasificador especifica un contrato
que otro clasificador garantiza que cumplir. Se pueden encontrar relaciones de realizacin en
dos sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de
uso y las colaboraciones que los realizan. La realizacin se representa como una mezcla entre
la generalizacin y la dependencia, esto es, una lnea discontinua con una punta de flecha
vaca.
Realizacin
D
iagramas
Los diagramas se utilizan para representar diferentes perspectivas de un sistema de forma que
un diagrama es una proyeccin del mismo. UML proporciona un amplio conjunto de diagramas
que normalmente se usan en pequeos subconjuntos para poder representar las cinco vistas
principales de la arquitectura de un sistema.
Diagramas de Clases
Muestran un conjunto de clases, interfaces y colaboraciones, as como sus relaciones. Estos
diagramas son los ms comunes en el modelado de sistemas orientados a objetos y cubren la
vista de diseo esttica o la vista de procesos esttica (s incluyen clases activas).
Diagrama de Clases
Diagramas de Objetos
Muestran un conjunto de objetos y sus relaciones, son como fotos instantneas de los
diagramas de clases y cubren la vista de diseo esttica o la vista de procesos esttica desde
la perspectiva de casos reales o prototpicos.
Objetos
Casos de Uso
Colaboracin
Diagramas de Estados
Muestran una maquina de estados compuesta por estados, transiciones, eventos y actividades.
Estos diagramas cubren la vista dinmica de un sistema y son muy importantes a la hora de
modelar el comportamiento de una interfaz, clase o colaboracin.
Estados
Diagramas de Actividades
Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades
dentro de un sistema. Los diagramas de actividades cubren la parte dinmica de un sistema y
se utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre
objetos.
Actividades
Diagramas de Componentes
Muestra la organizacin y las dependencias entre un conjunto de componentes. Cubren la vista
de la implementacin esttica y se relacionan con los diagramas de clases ya que en un
componente suele tener una o ms clases, interfaces o colaboraciones
Diagramas de Despliegue
Representan la configuracin de los nodos de procesamiento en tiempo de ejecucin y los
componentes que residen en ellos. Muestran la vista de despliegue esttica de una arquitectura
y se relacionan con los componentes ya que, por lo comn, los nodos contienen uno o ms
componentes.
Diagrama de Despliegue
Arquitectura
El desarrollo de un sistema con gran cantidad de software requiere que este sea visto desde
diferentes perspectivas. Diferentes usuarios (usuario final, analistas, desarrolladores,
integradores, jefes de proyecto...) siguen diferentes actividades en diferentes momentos del
ciclo de vida del proyecto, lo que da lugar a las diferentes vistas del proyecto, dependiendo de
qu interese ms en cada instante de tiempo.
La arquitectura es el conjunto de decisiones significativas sobre:
La organizacin del sistema
Seleccin de elementos estructurales y sus interfaces a travs de los cuales se
constituye el sistema.
progresivamente ms grandes.
El estilo arquitectnico que gua esta organizacin: elementos estticos y dinmicos y
sus interfaces, sus colaboraciones y su composicin.
La una arquitectura que no debe centrarse nicamente en la estructura y en el comportamiento,
sino que abarque temas como el uso, funcionalidad, rendimiento, capacidad de adaptacin,
reutilizacin, capacidad para ser comprendida, restricciones, compromisos entre alternativas,
as como aspectos estticos. Para ello se sugiere una arquitectura que permita describir mejor
los sistemas desde diferentes vistas, donde cada una de ellas es una proyeccin de la
organizacin y la estructura centrada en un aspecto particular del sistema.
La vista de casos de uso comprende la descripcin del comportamiento del sistema tal y como
es percibido por los usuarios finales, analistas y encargados de las pruebas y se utilizan los
diagramas de casos de uso para capturar los aspectos estticos mientras que los dinmicos
son representados por diagramas de interaccin, estados y actividades.
La vista de diseo comprende las clases, interfaces y colaboraciones que forman el vocabulario
del problema y de la solucin. Esta vista soporta principalmente los requisitos funcionales del
sistema, o sea, los servicios que el sistema debe proporcionar. Los aspectos estticos se
representan mediante diagramas de clases y objetos y los aspectos dinmicos con diagramas
de interaccin, estados y actividades.
La vista de procesos comprende los hilos y procesos que forman mecanismos de
sincronizacin y concurrencia del sistema cubriendo el funcionamiento, capacidad de
crecimiento y el rendimiento del sistema. Con UML, los aspectos estticos y dinmicos se
representan igual que en la vista de diseo, pero con el nfasis que aportan las clases activas,
las cuales representan los procesos y los hilos.
La Vista de implementacin comprende los componentes y los archivos que un sistema utiliza
para ensamblar y hacer disponible el sistema fsico. Se ocupa principalmente de la gestin de
configuraciones de las distintas versiones del sistema. Los aspectos estticos se capturan con
los diagramas de componentes y los aspectos dinmicos con los diagramas de interaccin,
estados y actividades.
La vista
de
despliegue de
un
sistema
contiene
los
nodos
que
forman
la topologa hardware sobre la que se ejecuta el sistema. Se preocupa principalmente de
la distribucin, entrega e instalacin de las partes que constituyen el sistema. Los aspectos
estticos de esta vista se representan mediante los diagramas de despliegue y los aspectos
dinmicos con diagramas de interaccin, estados y actividades
Ciclo de Vida
Se entiende por ciclo de vida de un proyecto software a todas las etapas por las que pasa un
proyecto, desde la concepcin de la idea que hace surgir la necesidad de disear un sistema
software, pasando por el anlisis, desarrollo, implantacin y mantenimiento del mismo y hasta
que finalmente muere por ser sustituido por otro sistema.
Aunque UML es bastante independiente del proceso, para obtener el mximo rendimiento de
UML se debera considerar un proceso que fuese:
Dirigido por los casos de uso, o sea, que los casos de uso sean un artefacto bsico para
establecer el comportamiento del deseado del sistema, para validar la arquitectura, para las
pruebas y para la comunicacin entre las personas involucradas en el proyecto.
Centrado en la arquitectura de modo que sea el artefacto bsico para conceptuar, construir,
gestionar y hacer evolucionar el sistema.
Un proceso iterativo, que es aquel que involucra la gestin del flujo de ejecutables del
sistema, e incremental, que es aquel donde cada nueva versin corrige defectos de la anterior
e incorpora nueva funcionalidad. Un proceso iterativo e incremental se denomina dirigido por el
riesgo, lo que significa que cada nueva versin se ataca y reducen los riesgos ms
significativos para el xito del proyecto.
Este proceso, dirigido a los casos de uso, centrado en la arquitectura, iterativo e incremental
pude descomponerse en fases, donde cada fase es el intervalo de tiempo entre dos hitos
importantes del proceso, cuando se cumplen los objetivos bien definidos, se completan los
artefactos y se toman decisiones sobre si pasar o no a la siguiente fase.
En el ciclo de vida de un proyecto software existen cuatro fases. La iniciacin, que es cuando
la idea inicial est lo suficientemente fundada para poder garantizar la entrada en la fase
de elaboracin, esta fase es cuando se produce la definicin de la arquitectura y la visin
del producto. En esta fase se deben determinar los requisitos del sistema y las pruebas sobre
el mismo.
Posteriormente se pasa a la fase de construccin, que es cuando se pasa de la base
arquitectnica ejecutable hasta su disponibilidad para los usuarios, en esta fase se reexaminan
los requisitos y las pruebas que ha de soportar. La transicin, cuarta fase del proceso, que es
cuando el software se pone en mano de los usuarios. Raramente el proceso del software
termina en la etapa de transicin, incluso durante esta fase el proyecto es continuamente
reexaminado y mejorado erradicando errores y aadiendo nuevas funcionalidades no
contempladas.
Un elemento que distingue a este proceso y afecta a las cuatro fases es una iteracin, que es
un conjunto bien definido de actividades, con un plan y unos criterios de evaluacin, que
acaban en una versin del producto, bien interna o externa.
Caso Prctico
Requerimientos
No
Consultas / Informes
R01
R02
R03
No
Almacenamiento
R04
R05
R06
R07
R08
R09
R10
R11
R12
R13
No
No
Procesamiento
R14
Diagramas de Casos de Uso
Ejemplo