1.2 Descripcin de los procesos actuals.

Gestin de
1.3 Diagramas UML.
Autor: Efrain Uc Salvador
2017

Informacin
- Gestin de Informacin

2
 - Gestin de Informacin

Instituto Tecnolgico Superior de Calkin en el

Estado de Campeche

Sistemas Computacionales
Ingeniera de Software
Dra. Marlene Mndez Moreno

6 Semestre
Grupo: A
Act02Par01 1er Parcial

Efrain Uc Salvador (4245)

Gestin de Informacin.

Contenido

3
 - Gestin de Informacin
Modelos de proceso software............................................................................................ 3
Codificar y corregir (Code-and-Fix)..................................................................................3
Modelo en cascada....................................................................................................... 3
Desarrollo evolutivo....................................................................................................... 4
Desarrollo formal de sistemas......................................................................................... 5
Desarrollo basado en reutilizacin...................................................................................6
Procesos iterativos........................................................................................................ 6
Desarrollo incremental................................................................................................... 7
Desarrollo en espiral...................................................................................................... 7
Diagramas de UML.............................................................................................................. 9
DIAGRAMAS DE CASOS DE USO...................................................................................... 9
DIAGRAMA DE CLASES................................................................................................. 10

DIAGRAMA DE CLASES................................................................................................ 10
DIAGRAMA DE OBJETOS............................................................................................... 11
DIAGRAMAS DE COMPORTAMIENTOS............................................................................11
Diagrama de Estados.................................................................................................. 11
Diagrama de actividad.................................................................................................... 12
DIAGRAMA DE INTERACCION. Diagrama de Secuencia.........................................................13
Diagrama de Colaboracin........................................................................................... 14
DIAGRAMA DE IMPLEMENTACION................................................................................. 15
Diagrama de componentes............................................................................................... 15
Diagrama de Despliegue................................................................................................. 15
Bibliografia....................................................................................................................... 16

Modelos de proceso software

Sommerville define modelo de proceso de software como Una representacin simplificada
de un proceso de software, representada desde una perspectiva especfica. Por su
naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software
es una abstraccin de un proceso real.
Los modelos genricos no son descripciones definitivas de procesos de software; sin
embargo, son abstracciones tiles que pueden ser utilizadas para explicar diferentes
enfoques del desarrollo de software.
Modelos que se van a discutir a continuacin:
Codificar y corregir
Modelo en cascada

4
 - Gestin de Informacin
Desarrollo evolutivo
Desarrollo formal de sistemas
Desarrollo basado en reutilizacin
Desarrollo incremental
Desarrollo en espiral

Codificar y corregir (Code-and-Fix)

Este es el modelo bsico utilizado en los inicios del desarrollo de software. Contiene dos
pasos:
Escribir cdigo.
Corregir problemas en el cdigo.
Se trata de primero implementar algo de cdigo y luego pensar acerca de requisitos,
diseo, validacin, y mantenimiento.
Este modelo tiene tres problemas principales [7]:
Despus de un nmero de correcciones, el cdigo puede tener una muy mala
estructura, hace que los arreglos sean muy costosos.
Frecuentemente, an el software bien diseado, no se ajusta a las necesidades del
usuario, por lo que es rechazado o su reconstruccin es muy cara.
El cdigo es difcil de reparar por su pobre preparacin para probar y modificar.

Modelo en cascada
El primer modelo de desarrollo de software que se public se deriv de otros procesos de
ingeniera [8]. ste toma las actividades fundamentales del proceso de especificacin,
desarrollo, validacin y evolucin y las representa como fases separadas del proceso.
El modelo en cascada consta de las siguientes fases:
1. Definicin de los requisitos: Los servicios, restricciones y objetivos son establecidos
con los usuarios del sistema. Se busca hacer esta definicin en detalle.
2. Diseo de software: Se particiona el sistema en sistemas de software o hardware.
Se establece la arquitectura total del sistema. Se identifican y describen las
abstracciones y relaciones de los componentes del sistema.
3. Implementacin y pruebas unitarias: Construccin de los mdulos y unidades de
software. Se realizan pruebas de cada unidad.

4. Integracin y pruebas del sistema: Se integran todas las unidades. Se prueban en

conjunto. Se entrega el conjunto probado al cliente.
5. Operacin y mantenimiento: Generalmente es la fase ms larga. El sistema es
puesto en marcha y se realiza la correccin de errores descubiertos. Se realizan
mejoras de implementacin. Se identifican nuevos requisitos.
La interaccin entre fases puede observarse en la Figura 5. Cada fase tiene como
resultado documentos que deben ser aprobados por el usuario.

5
 - Gestin de Informacin
Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la
correccin de los problemas encontrados en fases previas.

Desarrollo evolutivo
La idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial,
exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el
sistema adecuado. En la Figura 6 se observa cmo las actividades concurrentes:
especificacin, desarrollo y validacin, se realizan durante el desarrollo de las versiones
hasta llegar al producto final.
Una ventaja de este modelo es que se obtiene una rpida realimentacin del usuario, ya
que las actividades de especificacin, desarrollo y pruebas se ejecutan en cada iteracin.

Figura 1: Modelo de desarrollo evolutivo.

Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los
requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se
tiene ms claras. El sistema evoluciona conforme se aaden nuevas caractersticas
propuestas por el usuario.
Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y
trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo
exploratorio, se comienza por definir los requisitos que no estn claros para el usuario
y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de
definir estos requisitos.

6
 - Gestin de Informacin
Desarrollo formal de sistemas
Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un
programa ejecutable.

Figura 2: Paradigma de programacin automtica.

La Figura 7 ilustra un paradigma ideal de programacin automtica. Se distinguen dos
fases globales: especificacin (incluyendo validacin) y transformacin. Las caractersticas
principales de este paradigma son: la especificacin es formal y ejecutable constituye el
primer prototipo del sistema), la especificacin es validada mediante prototipacin.
Posteriormente, a travs de transformaciones formales la especificacin se convierte en la
implementacin del sistema, en el ltimo paso de transformacin se obtiene una
implementacin en un lenguaje de programacin determinado. , el mantenimiento se
realiza sobre la especificacin (no sobre el cdigo fuente), la documentacin es generada
automticamente y el mantenimiento es realizado por repeticin del proceso (no mediante
parches sobre la implementacin).
Observaciones sobre el desarrollo formal de sistemas:
Permite demostrar la correccin del sistema durante el proceso de transformacin.
As, las pruebas que verifican la correspondencia con la especificacin no son
necesarias.
Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y
confiabilidad importantes.
Requiere desarrolladores especializados y experimentados en este proceso para
llevarse a cabo.

Desarrollo basado en reutilizacin

Como su nombre lo indica, es un modelo fuertemente orientado a la reutilizacin. Este
modelo consta de 4 fases ilustradas en la Figura 9. A continuacin se describe cada fase:
1. Anlisis de componentes: Se determina qu componentes pueden ser utilizados para
el sistema en cuestin. Casi siempre hay que hacer ajustes para adecuarlos.
2. Modificacin de requisitos: Se adaptan (en lo posible) los requisitos para concordar
con los componentes de la etapa anterior. Si no se puede realizar modificaciones en
los requisitos, hay que seguir buscando componentes ms adecuados (fase 1).

7
 - Gestin de Informacin
3. Diseo del sistema con reutilizacin: Se disea o reutiliza el marco de trabajo para el
sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para
disear o determinar este marco.
4. Desarrollo e integracin: El software que no puede comprarse, se desarrolla. Se
integran los componentes y subsistemas. La integracin es parte del desarrollo en
lugar de una actividad separada.

Las ventajas de este modelo son:

Disminuye el costo y esfuerzo de desarrollo.
Reduce el tiempo de entrega.
Disminuye los riesgos durante el desarrollo.

Figura 3: Desarrollo basado en reutilizacin de componentes

Desventajas de este modelo:

Los compromisos en los requisitos son inevitables, por lo cual puede que el software
no cumpla las expectativas del cliente.
Las actualizaciones de los componentes adquiridos no estn en manos de los
desarrolladores del sistema.
Procesos iterativos
A continuacin se expondrn dos enfoques hbridos, especialmente diseados para el
soporte de las iteraciones:
Desarrollo Incremental.
Desarrollo en Espiral.

Desarrollo incremental
Mills sugiri el enfoque incremental de desarrollo como una forma de reducir la repeticin
del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones
en los requisitos hasta adquirir experiencia con el sistema (ver Figura 10). Es una
combinacin del Modelo de Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar
las decisiones hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o
evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar.
Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

8
 - Gestin de Informacin

Figura 4: Modelo de desarrollo iterativo incremental.

Entre las ventajas del modelo incremental se encuentran:
Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden
empezar a usarlo desde el primer incremento.
Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las
entregas del sistema.
Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en
cada incremento.
Las partes ms importantes del sistema son entregadas primero, por lo cual se
realizan ms pruebas en estos mdulos y se disminuye el riesgo de fallos.
Algunas de las desventajas identificadas para este modelo son:
Cada incremento debe ser pequeo para limitar el riesgo (menos de 20.000 lneas).
Cada incremento debe aumentar la funcionalidad.
Es difcil establecer las correspondencias de los requisitos contra los incrementos.
Es difcil detectar las unidades o servicios genricos para todo el sistema.

Desarrollo en espiral
El modelo de desarrollo en espiral es actualmente uno de los ms conocidos y fue
propuesto por Boehm. El ciclo de desarrollo se representa como una espiral, en lugar de
una serie de actividades sucesivas con retrospectiva de una actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
1. Definicin de objetivos: Se definen los objetivos. Se definen las restricciones del
proceso y del producto. Se realiza un diseo detallado del plan administrativo. Se
identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos.
2. Evaluacin y reduccin de riesgos: Se realiza un anlisis detallado de cada riesgo
identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos
dudosos. Se llevan a cabo los pasos para reducir los riesgos.
3. Desarrollo y validacin: Se escoge el modelo de desarrollo despus de la evaluacin
del riesgo. El modelo que se utilizar (cascada, sistemas formales, evolutivo, etc.)
depende del riesgo identificado para esa fase.
4. Planificacin: Se determina si continuar con otro ciclo. Se planea la siguiente fase del
proyecto.

9
 - Gestin de Informacin

El ciclo de vida inicia con la definicin de los objetivos. De acuerdo a las restricciones se
determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra
las alternativas. Se evalan los riesgos con actividades como anlisis detallado,
simulacin, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.

Figura 5: Modelo de desarrollo en Espiral

Diagramas de UML.
DIAGRAMAS DE CASOS DE USO

Los Casos de Uso no forma parte de la llamada Fase de Diseo, sino parte de la fase de
Anlisis, respondiendo el interrogante Qu? De forma que al ser parte del anlisis ayuda
a describir que es lo que el sistema debe hacer.

10
 - Gestin de Informacin
Estos diagramas muestran operaciones que se esperan de una aplicacin o sistema y
como se relaciona con su entorno, es por ello que se ve desde el punto de vista del
usuario. Describen un uso del sistema y como ste interacta con el usuario.

Los casos de usos se representan en el diagrama por unas elipses la cual denota un
requerimiento solucionado por el sistema.
El conjunto de casos de usos representa la totalidad de operaciones que va a desarrollar el
sistema. Por ltimo a estas elipses lo acompaa un nombre significativo de manera de
rtulo.

Otro elemento fundamental de estos diagramas son los actores la cual representa a un
usuario del sistema, que necesita o interacta con algn caso de uso, la que tambin
es acompaado por un nombre. Por ltimo tenemos los flujos de eventos que corresponde
a la ejecucin normal y exitosa del caso de uso.

DIAGRAMA DE CLASES

En UML el diagrama de clases es uno de los tipos de diagramas o smbolo esttico y tiene
como fin describir la estructura de un sistema mostrando sus clases, atributos y relaciones
entre ellos.

Estos diagramas son utilizados durante el proceso de anlisis y diseo de los sistemas
informticos, en donde se intentan conformar el diagrama conceptual de la informacin que
se manejar en el sistema.

11
 - Gestin de Informacin

Como ya sabemos UML es un modelado de sistema Orientados a Objetos, por ende los
conceptos de este paradigma se incorporan a este lenguaje de modelado.

DIAGRAMA DE CLASES

Los diagramas de clases tienen las

siguientes caractersticas:
Las clases define el mbito de
definicin de un conjunto de
objetos.
Cada objeto pertenece a una clase.
Los objetos se crean por
instanciacin de las clases.

DIAGRAMA DE OBJETOS

Forma parte de la vista esttica del sistema. En este diagrama se modelan las instancias
de las clases del Diagrama de Clases. Este diagrama cabe aclarar que cuenta con objetos
y enlaces. En estos diagramas tambin es posible encontrar las clases para tomar como
referencia su instanciacin.

12
 - Gestin de Informacin

En otras palabras el Diagrama de Objetos muestra un conjunto de objetos y sus relaciones

en un momento concreto. Los Diagramas de Objetos son realmente tiles para modelar
estructuras de datos complejas

DIAGRAMAS DE COMPORTAMIENTOS

Diagrama de Estados.

Un estado es una condicin durante la vida de un objeto, de forma que cuando dicha
condicin se satisface se lleva a cabo alguna accin o se espera por un evento.
El estado de un objeto se puede caracterizar por el valor de uno o varios de los atributos
de su clase, adems, el estado de un objeto tambin se puede caracterizar por la
existencia de un enlace con otro objeto.

El diagrama de estados engloba todos los mensajes que un objeto puede enviar o recibir,
en otras palabras es un escenario que representa un camino dentro de un diagrama.

Como caracterstica de estos diagramas siempre cuentan con dos estados especiales, el
inicial y el final, con la particularidad que este diagrama puede tener solo un estado inicial
pero varios estados finales.

Una transicin entre estados representa un cambio de un estado origen a un estado

sucesor destino que podra ser el mismo que el estado origen, dicho cambio de estado
puede estar aparejado con alguna accin. Adems las acciones se asocian a las
transiciones y se consideran que ocurre de forma rpida e interrumpible.

13
 - Gestin de Informacin

Los elementos que componen estos diagramas son:

Crculo lleno, apuntando el estado inicial.

Crculo hueco que contiene un crculo lleno ms pequeo en el interior, indicando el
estado final.
Rectngulo redondeado dividido por una lnea horizontal, indicado los estados, en la
parte de arriba se encuentra el nombre del estado y abajo se indica la actividad que
realiza.
Flecha, la cual denota la transicin, el nombre del evento que causa esta transicin
etiqueta el cuerpo de la flecha.

Diagrama de actividad.

Un Diagrama de Actividades representa un flujo de trabajo paso a paso de negocio y

operacionales de los componentes en un sistema.

En UML 1, un diagrama de actividades es una variacin del Diagrama de Estados UML

donde los estados representan operaciones y las transiciones representan las actividades
que ocurren cuando la operacin es completa.

En la actualidad, el diagrama de actividades en UML 2.0 es similar al aspecto del diagrama

en UML 1, solo que ahora la semntica est basada en lo que se conoce como Redes de
Petri. En UML 2.0, el diagrama general de interaccin est basado en el diagrama de
Actividad.

14
 - Gestin de Informacin

Componentes:
Inicio: el inicio de un diagrama de actividades es representado por un crculo de
color negro slido.
Actividad: Una actividad representa la accin que ser realizada por el sistema la
cual representa dentro de un valo.
Transicin: Una transicin ocurre cuando se lleva acabo el cambio de una actividad
a otra, la transicin es representada simplemente por una lnea con una flecha en su
terminacin para indicar su direccin.

DIAGRAMA DE INTERACCION.

Diagrama de Secuencia.

Un Diagrama de Secuencias muestra una interaccin ordenada segn la secuencia temporal de eventos y
el intercambio de mensajes. Los diagramas diagramas de secuencia ponen especial nfasis en el orden y
el momento en el que se envan los mensajes a los objetos.

15
 - Gestin de Informacin

En los diagramas de Secuencias los elementos estn representados por lneas

intermitentes verticales, con el nombre del objeto en la parte ms alta.

Los mensajes pueden ser o bien sncronos, el tipo normal de llamada del mensaje donde
se pasa el control a objeto llamadohasta que el mtodo finalize, o asncronos donde se
devuelve el control directamente al objeto que realiza la llamada.

Los mensajes sncronos tienen una caja vertical en un lateral del objeto invocante que
muestra el flujo del control del programa.

Diagrama de Colaboracin.

Un diagrama de colaboracin, se puede decir que es una forma alternativa al diagrama de secuencias a la
hora de mostrar un escenario.
Este tipo de diagrama muestra las interacciones que ocurren entre los objetos que participan en una
situacin determinada.
A diferencia del diagrama de secuencia, el diagrama de colaboracin se enfoca en la relacin entre los
objetos y su topologa de comunicacin.

En estos diagramas los mensajes enviados de un objeto a otro se representa mediante flechas,
acompaado del nombre del mensaje, los parmetros y la secuencia del mensaje.

Estos diagramas estn indicados para mostrar una situacin o flujo de programa especfico y son
considerados uno de los mejores diagramas para mostrar o explicar rpidamente un proceso dentro de la
lgica del programa.

16
 - Gestin de Informacin
DIAGRAMA DE IMPLEMENTACION

Diagrama de componentes
Lo que distingue el Diagrama de Componentes de otro tipo de diagramas es sin duda su
contenido. Normalmente contiene componentes, interfaces y relaciones entre
ellos.Los componentes perteneces a un mundo fsico, es decir, representan a un bloque de
construccin al modelar aspectos fsicos de un sistema.

Cada componente debe tener un nombre que lo distinga de los dems. Al igual que las
clases los componentes pueden enriquecerse con compartimientos adicionales que
muestran sus detalles.

Diagrama de Despliegue
Bsicamente este tipo de diagrama se utiliza para modelar el Hardware utilizado en la
implementacin del sistema y las relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos, componentes y asociaciones.
En el UML 2.0 los componentes ya no estn dentro de nodos, en cambio puede
haber artefactos (archivo, un programa, una biblioteca o Base de datos) u otros nodos
dentro de nodos.

Adems los Diagramas de Despliegue muestran la configuracin en funcionamiento del

sistema incluyendo su software y su hardware. Para cada componente de un diagrama es
necesario que se deba documentar las caractersticas tcnicas requeridas, el trfico de
red, el tiempo de respuesta, etc.

17
 - Gestin de Informacin
Bibliografia.

https://sg.com.mx/revista/1/procesos-software#.WMeLp1U1_IU

http://yaqui.mxl.uabc.mx/~molguin/as/IngSoft%201-4.pdf

http://ingenieriadesistemas-shirley.blogspot.mx/2012/05/tipos-de-diagramas-uml.html

https://www.uaeh.edu.mx/scige/boletin/tlahuelilpan/n9/r1.html

http://perso.club-internet.fr/brouardf/SGBDRmerise.htm

http://www.map.es/csi/metrica3/

http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html

http://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.doc

18