Universidad Tecnolgica Intercontinental

La Universidad sin Fronteras

FACULTAD DE TECNOLOGIA INFORMATICA Y CIENCIAS EXACTAS

CARRERA DE INGENIERA EN SISTEMAS INFORMTICOS

Tcnica de Construccin, Diagramacin y Especificacin de Sist. De Inf. Con Star UML

FACILITADOR: Ing. Hilario Machuca

Asuncin Paraguay 2009

NDICE Portada...................................................................................................................................................... I ndice.......................................................................................................................................................II

1 2 Resumen .......................................................................................................................................................... 1 Tipos de Ingenieras ........................................................................................................................................ 2 2.1 Ingeniera Directa .................................................................................................................................... 3 2.2 Ingeniera inversa .................................................................................................................................... 3 3 Secuencia Metodolgica de construccin de diseos ...................................................................................... 3 3.1 Definir el repositorio del proyecto........................................................................................................... 4 3.2 Definir Tipo de ingeniera ....................................................................................................................... 5 3.3 Definir los modelos que se disearn ...................................................................................................... 5 3.4 El modelo del negocio ............................................................................................................................. 6 3.5 El modelo de requerimientos ................................................................................................................... 8 3.6 Como descubrir los requerimientos para diagramar ................................................................................ 9 3.7 Cmo llegar diagramar el Modelo de Negocio Global con Caso de de uso .......................................... 13 3.8 El modelo de casos de usos ................................................................................................................... 14 3.9 El modelo de objetos ............................................................................................................................. 14 3.10 El modelo de informacin ..................................................................................................................... 15 3.11 El modelo de secuencias........................................................................................................................ 16 3.12 El modelo de colaboracin .................................................................................................................... 16 3.13 Escenarios y necesidades del cliente (Prototipado de ventanas)............................................................ 18 3.14 El modelo de despliegue........................................................................................................................ 19 3.15 Conclusin............................................................................................................................................. 19 3.16 Versin de este documento 1.7........................................................................................................... 20 4 Bibliografa.................................................................................................................................................... 21 4.1 Libros..................................................................................................................................................... 21 4.2 Revistas y manuales............................................................................................................................... 21 4.3 Web site................................................................................................................................................. 21

II

1 Resumen
El modelado genrico de sistemas de informacin habra de pasar por lo que se conoce como marcos referenciales metodolgicos: esto es, un adecuado conjunto de herramientas y mtodos que conformen un patrn aplicable de forma segmentada y no necesariamente completa sobre el dominio de los problemas a modelar. Este trabajo pretende servir de base para la elaboracin de una metodologa concensuada entre docentes y profesionales que se desenvuelven en el escenario de la iniciacin del uso del lenguaje UML para el diseo de sistemas informticos de gestin, cubriendo la carencia actual en la metodologa estructurada sobre el modelado de objetos. De ninguna manera pretende imponer criterios sobre la metodologa a utilizar en el diseo y diagramacin de sistemas de informacin.
Nunca permita que la falta de soporte CASE lo detenga para practicar una tcnica valiosa! [David Ruble, 1998]

2 Tipos de Ingenieras
El modelado es importante, pero recordemos que el producto principal de un equipo de desarrollo es software y no diagramas. Po supuesto, la razn por la que se crean modelos es para entregar, en el momento oportuno, el software adecuado que satisfaga los objetivos siempre cambiantes de los usuarios y la empresa. Para algunos usos de UML, los modelos realizados nunca se correspondern con un cdigo. Por ejemplo, si se modela un proceso de negocio con diagramas de actividades, muchas de las actividades modeladas involucrarn a personas y no a computadoras. En la mayora de los casos, sin embargo, los modelos creados se correspondern con cdigo, al respecto UML no especfica ninguna correspondencia particular con ningn lenguaje de programacin de programacin orientado a objetos, pero se dise con estas correspondencias en mente. Vea la siguiente figura como Star UML posee correspondencias con algunos lenguajes.

Fig. 1 Observe como Star UML hace Referencia a Lenguajes como C++, C# y Java

2.1

Ingeniera Directa
La ingeniera Directa es el proceso de transformar un modelo en cdigo a travs de una correspondencia con un lenguaje de implementacin. La ingeniera inversa produce una prdida de informacin, porque los modelos escritos en UML son semnticamente ms ricos que cualquier lenguaje de programacin orientado a objetos actual. De hecho, sta es una de las razones por las que se necesitan modelos adems de cdigo. Las caractersticas estructurales, como las

colaboraciones, y las caractersticas de comportamiento, como las interacciones, pueden visualizarse claramente en UML, pero no tan claramente a partir de simple cdigo fuente.

2.2

Ingeniera inversa
La ingeniera inversa es el proceso de transformar cdigo en un modelo a travs de una correspondencia con un lenguaje de programacin especfico. La ingeniera inversa produce un aluvin de informacin, parte de la cual est a un nivel ms bajo del que se necesita para construir modelos tiles. Al mismo tiempo es incompleta ya que hay una prdida de informacin cuando se hace ingeniera directa de modelos a cdigos, as que no se puede recrear completamente un modelo a partir de cdigo a menos que las herramientas incluyan informacin en los comentarios del cdigo fuente que vaya ms all de la semntica del lenguaje de implementacin.

3 Secuencia Metodolgica de construccin de diseos

Una herramienta CASE (ingeniera de software asistida por computadora) ayuda a los administradores de proyectos de ingeniera de software en las actividades de gestin, anlisis, diseo y codificacin de software.

Los proyectos encarados con un apoyo de CASE logran modelos del sistema que permiten entender lo que el sistema har, a la vez que pueden hacerse un seguimiento de la completitud, precisin y consistencia del diseo, esto lleva a descubrir errores solo durante la fase de programacin y que slo sean errores de programacin y no un reflejo de falta de entendimiento entre usuarios y analistas.

Las actividades de diseo producen un modelo que en conjunto forman un plano gua para la construccin y prueba del sistema. Cada modelo se refleja en un tipo de diagrama o un conjunto de diagramas y dependen de las diferentes fases del desarrollo, estos diagramas pueden variar dependiendo del tamao y naturaleza del sistema.

3.1

Definir el repositorio del proyecto

Para poder vincular cada diagrama con un documento de especificacin es importante crear una estructura de directorio repositorio donde puedan colocarse los diferentes artefactos que documentarn el sistema en si.

A modo de sugerencia he creado este grupo de directorios:

Observe en la figura que el directorio Repositorio Moble posee un archivo de texto leeme.txt, es recomendable colocar un archivo de este tipo para identificar el objeto del directorio, escribiendo en el archivo la lista de directorios y artefactos que incluye dicho directorio. A su vez cada subdirectorio debera de incluir otro archivo del mismo nombre y sucesivamente en cada directorio o subdirectorio.

3.2

Definir Tipo de ingeniera

Para nuestro ambiente, tenemos bien definido el tipo de ingeniera que aplicamos, ya que generalmente los educandos realizan la prctica de diseo de sistemas de cero, es decir que el diseo de sistemas se realiza desde el principio sin la observacin de sistemas existentes.

Fig. 2 Vea como indicar el tipo de ingeniera

3.3

Definir los modelos que se disearn

Cuando se modela algo, se crea una simplificacin de la realidad para comprender mejor el sistema que se est desarrollando. Con UML, se construyen modelos a partir de bloques de construccin bsicos, tales como clases, interfaces, colaboraciones, asociaciones. Para nuestro ejemplo utilizaremos los siguientes modelos: Modelo de Negocios Modelo de comportamiento Modelo de objetos Modelo de despliegue componentes, nodos, dependencias, generalizaciones y

Para crear los modelos con StarUML slo haga click derecho sobre el nombre del proyecto y agregue los modelos. F2 para renombrar los modelos. Vea esto en la siguiente figura.

Fig. 3 Vea como agregar modelos

3.4

El modelo del negocio

En la etapa inicial de un proyecto de desarrollo de software, antes de la determinacin de requerimientos, surge la importancia de la obtencin de

informacin de las caractersticas del negocio, la cual nos proporcionara un panorama detallado de la estructura y organizacin de la empresa, identificacin de usuarios participantes, el entorno tecnolgico en que se encuentra y sobre todo nos permite considerar las referencias para el sistema de informacin en estudio, desde el punto de vista de reglas, normativas, leyes o recomendaciones que se deben tener en cuenta a lo largo de todo el proceso de desarrollo. Las entrevistas a usuarios y conversaciones son el punto de partida para obtener el panorama general del negocio, cuestiones como naturaleza del negocio que pueden ser inversiones nacionales o extranjeras, seguros, importacin o exportacin, produccin de materia prima y otros; nos darn una idea de qu debemos manejar para saber como

encarar el proyecto de nuestro cliente. No tema en solicitar copias de organigramas o algn documento que le ayude a adentrarse en las funciones de cada rea del negocio.

Moble-up, es el emprendimiento de negocio iniciado por dos personas en la dcada de los 90, dedicndose a la produccin de sillas, sillones de metal con partes de frmica y juegos de comedor del mismo material. La produccin se basa en la compra de materia prima que incluye partes como tornillos, caos de hierro, cordones de plstico, tapones de plsticos, insumos para la produccin como

electrodos, pintura para metales, hojas de sierra para los cortes, lija y otros. El pago de honorarios al personal se realiza semanalmente y de acuerdo a la produccin que logra cada personal de Moble-up.

Luego del cierre de los bancos, la empresa fue afectada por escasez de circulante, lo que motivo a buscar nuevas formas de ingreso. La produccin tuvo una cada; lo que creo el retiro del personal en aquel entonces, esta situacin llevo a la empresa a la venta de los muebles con pagos fraccionados. Para cumplir con este nuevo enfoque de negocio, se contrataron cobradores y se empez a adquirir modelos de muebles de otros fabricantes.

El nuevo enfoque tomado por Moble-up, tuvo sus resultados en un tiempo muy reducido, teniendo que ampliar las instalaciones e incluso arrendar otras dependencias para manejar el crecimiento y mejorar la atencin al cliente. Al ao de la nueva forma de trabajo, el movimiento de compras y ventas se haba triplicado y la cantidad de clientes ha aumentado tanto que se ha vuelto una situacin difcil de controlar de forma manual. Las cuentas por cobrar de clientes se registran de forma manual en fichas que son confeccionadas para el efecto y que son entregadas al personal de cobranza para el correspondiente registro de cobros de cuotas del cliente.

Con esta forma de control, en muchas oportunidades se desconoca el vencimiento de las cuentas de clientes, se desconoca la existencia real de los productos ofrecidos por Moble-up. Moble-up a menudo deba pasar la vergenza de cambios en los precios segn el vendedor, puesto que no dispona de un catalogo de precios de productos. Esta situacin generaba la perdida de cierre de una venta.

En la siguiente figura puede observarse un modelo del negocio de Moble-up, este modelo es inicial, puesto que a primera vista podemos rescatar como los actores del negocio se relacionan con los procesos del negocio. Este modelo de negocio fue

diseado con visual paradigm 6.0 y no pretende que sea el definitivo ya que conforme se empape con los procesos del negocio ir refinando el diseo.

3.5

El modelo de requerimientos
El modelo de requerimientos parte del relevamiento de requisitos, en donde se lleva acabo el proceso de descubrir, analizar, escribir y verificar los servicios y restricciones del sistema de software. Su importancia radica en que, de la definicin de los requerimientos depender la definicin de las etapas subsecuentes del desarrollo de software, es decir, que si no se descubren los requerimientos que se encuentran en el ambiente repercute de forma negativa debido a que como si son encontrados en una etapa avanzada del desarrollo, obligar a retroceder nuevamente a la etapa de requerimientos, esto provocara cambios en el sistema y consecuentemente retraso en la entrega del sistema. Un caso peor es, que no se encontraran y especificaran todos los requerimientos del sistema en un proceso de desarrollo de software, lo cual producira la entrega de un producto de software incompleto o poco funcional. Se puede considerar a esta etapa como la ms importante de todo el proyecto, por lo tanto se deber recurrir a la tcnica ms

ptima para lograr obtener con claridad lo que desea el usuario que proporcione el sistema a desarrollar.

Observe ahora su modelo de negocios e identifique las reas en las que debe entrevistarse (entienda que cuando hablamos de reas necesariamente debe conversar con algn personal de esa rea) y haga una lista de ellas. Veamos: El rea de compras El rea de ventas El rea de depsito El rea de cobranza.

Con la lista de reas, puede comenzar un relevamiento de requerimientos de cada usuario en su rea.

3.6

Como descubrir los requerimientos para diagramar

En el mbito de los negocios existen eventos que para un experto en software el es como el pan de cada da, son justamente estos eventos los que se necesitan capturar para determinar el comportamiento del sistema a desarrollar.

Para capturar un evento que ocurre en el ambiente, debe considerarse la sintaxis sujeto-verbo-objeto y esto no es que sea una tarea sencilla especialmente si es que no se elabor un buen relevamiento de datos.

De acuerdo al relevamiento realizado en cada rea pueden redactarse lista de eventos por cada rea que puede tomar la siguiente forma: 1.1 El personal de compras hace pedidos al proveedor. 1.2 El personal de compras recepciona factura del proveedor. 1.3 El personal de compras solicita informe de compras

Como se muestra en este ejemplo una lista de eventos no debera presentar palabras innecesarias, se escribir el evento de forma especfica en una lnea y para que sea verdaderamente til deber estar agrupada y ordenada correspondiente a cada actividad de la estructura organizativa del negocio. Queda demostrado que el primer evento El personal de compras hace pedidos al proveedor se compone de:

Sujeto: El personal de compras Verbo: hace Objeto: pedidos al proveedor. Los nombres de eventos son importantes y no deben escatimarse esfuerzo para buscar la expresin del evento. Ha llegado el momento de tomar slo aquellos a los que el sistema debe responder, esto puede conseguirse mediante la confeccin de una planilla en la que podemos comparar nombre de evento, requerimiento que se cubre, y el estimulo que activa el evento. No crea que las palabras estimulo y eventos sean de significado igualitarios.

Para ordenar las ideas puede crear un esquema como sigue Evento: Personal de compra elabora orden de compra Requerimiento: elaborar orden de compra Estimulo: lista de compra Respuesta: Orden de compra

El cuadro completo de los eventos de nuestro caso de estudio es como se muestra, fjese como queda la siguiente tabla donde se ordenan los eventos, el estimulo que produce y a que requerimiento atiende

evento El personal de compras elabora orden de compra

requerimiento Elaborar orden de compra

estimulo lista de compras factura de compra parmetros fechas, sucursal

El personal de compras recepciona factura Registrar compra de proveedor El personal de compras solicita informe de compras elaborar informe de compras

No se debe caer en el error de que el diagrama de requerimientos es el modelo de eventos, tal vez el analista pueda encontrar las herramientas grficas para demostrar un modelo adecuado para el modelo de eventos, pero por ahora nos bastara la utilizacin de la tabla anterior para continuar con nuestro trabajo de disear el diagrama de requerimientos. Hemos demostrado como llegar a los requerimientos.

La lista de eventos entonces ayuda a un diseo ms exacto y la manera en que debe reaccionar el sistema al detectar un estimulo ocasionado por un evento externo al

10

sistema. De sta forma ser ms sencilla la tarea de descubrir eventos y respuestas para determinar el comportamiento de nuestro sistema.

Una vez obtenido todos los requerimientos de forma especifica y objetiva se deber organizar el documento de tal forma que estn agrupados los requerimientos por cada rea, puede observarse como se han refinado los requerimientos como sigue:.

Departamento de compras 1.1 1.2 1.3 Elaborar orden de compra Registrar las compras Elaborar un informe de compras

Departamento de ventas 2.1 2.2 2.3 Recepcionar pedido de productos del cliente Registrar las ventas y actualizar ctas. de clientes Elaborar informe de ventas

Departamento de cobranzas 3.1 3.2 3.3 3.4 Elaborar lista de ctas. a cobrar Actualizar cta. CTE. del cliente Realizar apertura/cierre de caja Elaborar resumen de movimiento de caja

rea de depsito (inventario de bienes de cambio) 4.1 Transferir productos entre depsitos y sucursales 4.2 Ajustar existencia de productos luego de inventario 4.3 Obtener informe de existencia mnimas 4.4 Preparar planilla para inventario

Esta lista de requerimientos del cliente es representado en un diagrama de requerimientos para documentar el relevamiento y realizar ya un anlisis inicial del negocio. Siguiendo con nuestro ejemplo tomaremos slo el rea de compras. El resultado se observa en el siguiente diagrama de requerimientos.

11

Observe que el requerimiento gestionar compras se le ha asignado un ID = 1, esto es solo a los efectos de identificarlo desde nuestra lista de requerimientos y cada objeto de requerimiento contiene datos sobre el rea donde se detecto el requerimiento, el tipo de requerimiento, el mtodo por el que se identific y su grado de prioridad entre los dems requerimientos. Como una forma de organizar el diseo, puede numerar cada extensin del requerimiento, vea que en el diseo cada requerimiento posee un ID. La siguiente figura es una vista modelo del negocio confeccionado con StarUML en la versin 5.0 y pretende mostrar cuales macroprocesos (paquetes) que son ejecutados en la empresa interactan con los actores comerciales.

12

Fjese como los actores comerciales proveedor y cliente no poseen las lneas de relacin con los subsistemas del sistema. Ahora que conocemos cuales subsistemas se deben encarar, podemos disear el modelo de caso de uso del negocio por cada rea, a su vez estos CUN por rea me permite generar casi automtico un Modelo de negocio global con el diagrama de CU. (Esto se muestra en seminario Taller) Para nombrar los CUN por rea refirase a las funciones de cada rea o de cada departamento. Por ejemplo, la funcin principal del departamento de ventas es administrar las ventas, la de compras es la de gestionar y realizar las compras de productos, y para cada rea su funcin principal.

3.7

Cmo llegar diagramar el Modelo de Negocio Global con Caso de de uso

Si la organizacin de nuestros requerimientos se ha hecho de forma estructural, el camino para la construccin del modelo de caso del negocio global ser muy sencillo. Tome a los actores del ambiente y colquelos en el diseo, luego coloque los casos de uso del negocio que corresponda a cada rea y arrstrelo en la pgina del diagrama, las relaciones entre CU y Actor se incluirn automticamente. Vea ahora como queda el modelo casos de uso del negocio.

13

Observe que los actores comerciales proveedor y cliente ya no aparecen en el diseo de modelo caso de uso del negocio

3.8

El modelo de casos de usos

Los casos de uso muestran la visin funcional del programa. Son como una forma de especificar el comportamiento del sistema. Representan una forma fcil de expresar cmo algo o alguien hace uso del sistema e interacta con el, esto nos permite ver los recursos que el sistema proporciona. Los casos de uso son una forma visual de describir los distintos escenarios que sirven para mostrar momentos de interaccin de los actores con el sistema. Una de las ventajas de los casos de usos es que establecen un punto de referencia comn entre el programador y el cliente o el jefe que encarga el desarrollo de y permiten documentar de manera sencilla y entendida por cualquiera ajeno a la informtica.

Para representar los diagramas del Modelo de Casos de Uso nuevamente nos referiremos a nuestro modelo de requerimientos, punto de partida para encontrar los casos de usos del negocio, as cada requerimiento se puede convertir en un caso de uso.

El caso de uso registrar compra

3.9

El modelo de objetos
La modelizacin orientada a objetos se centra en el desarrollo de una coleccin de objetos discretos que incorporan tanto estructura de datos como comportamiento. Los objetos ejecutan o reciben operaciones que representan las interacciones entre objetos. El centro de atencin es la construccin de definiciones de objetos que puedan organizarse en una jerarqua de clases con altos niveles de abstraccin. Los objetos pueden agruparse mediante agregaciones, y pueden tener relaciones y atributos (propiedades) de forma similar al modelo entidad relacin. De hecho, el modelo de datos (ERD) constituye la base de los conceptos orientados a objetos (entidades y atributos)

14

Para nuestro ejemplo tomaremos slo una parte de todo nuestro proyecto, y siguiendo con nuestra lnea de ejemplo nos abocamos a disear los objetos de datos del rea de compras, como se ve en la siguiente figura:

Mencionamos en este punto que el modelado de objetos de datos, es una tarea paralela al diseo de todo el proyecto, por lo que este modelo es importante tener ya para continuar con nuestro proyecto, cuyo paso siguiente es el de construir el modelo de comportamiento utilizando un diagrama de secuencias y/o de colaboracin.

3.10 El modelo de informacin

El modelado de la informacin forma la base del diseo de la base de datos

relacional. Para construir nuestro modelo de informacin podemos basarnos inicialmente en nuestro diagrama de objetos de datos, luego ir refinando a medida que se entra en detalles en el anlisis y diseo de sistemas En el siguiente ejemplo se presenta el DER de compra.

15

3.11 El modelo de secuencias

Un modelo de secuencias es un tipo de modelo de interaccin junto con el diagrama de colaboracin, el modelo se secuencias se expresa por medio de un diagrama de secuencias que muestra las interacciones entre los objetos organizados en una secuencia temporal. En particular muestra los objetos participantes en la interaccin y la secuencia de mensajes intercambiados.

Para disear el diagrama de secuencias necesariamente debera de tener el diagrama de objetos de datos. Arrastre el actor desde el caso de uso que

corresponda y luego cada uno de los objetos de datos desde el explorador de modelos.

3.12 El modelo de colaboracin

El uso del diagrama de colaboracin es mostrar la implementacin de una operacin. La colaboracin muestra los parmetros y las variables locales de la operacin, as como asociaciones ms permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el paso de seales del programa. Un diagrama de secuencia muestra secuencias en el

16

tiempo como dimensin geomtrica, pero las relaciones son implcitas. Un diagrama de colaboracin muestra relaciones entre roles geomtricamente y relaciona los mensajes con las relaciones, pero las secuencias temporales estn menos claras. La construccin del diagrama de colaboracin se realiza de forma automtica a partir de nuestro diagrama de secuencia. Pero la herramienta STARUML presenta un error en esta parte del programa, cuando se le da la orden de convertir un diagrama de secuencia a diagrama de colaboracin.

Antes de realizar esta operacin asegrese de grabar todo el trabajo. Luego realizar la conversin del diagrama de secuencia a de colaboracin. Cerrar la aplicacin StarUML luego volver a ejecutarlo. El diagrama de colaboracin se puede encontrar en el mismo nivel de jerarquas donde se encontraba el diagrama de secuencias.

Se puedo luego mover al paquete de Diagramas de colaboracin creando primero un diagrama de colaboracin vaco. Cortar el anterior, posicionar sobre el nuevo diagrama de colaboracin y hacer click derecho para pegar el diagrama de colaboracin confeccionado automticamente.

Arreglar el diseo.

En ese sentido nuestro diagrama quedara como se muestra en la siguiente figura:

17

3.13 Escenarios y necesidades del cliente (Prototipado de ventanas)

Cuando se utiliza el proceso unificado, en vez de construir un prototipo rpido se muestran al cliente los casos de uso, o con ms precisin, los diagramas de interaccin que reflejan las clases que realizan los escenarios del caso de caso de uso. El cliente puede comprender cmo se comportar el sistema de informacin. No obstante, hay un rea donde un prototipo rpido es superior a un escenario y sta es la interfase del usuario. No hay manera de que un escenario pueda describir una pantalla tan bien como lo hace un prototipo rpido. Para crear prototipazo de ventanas puede valerse de cualquier lenguaje de programacin y construir el modelo de ventana que el usuario final estara manejando. Actualmente existen muchas herramientas case que incluyen esta prestacin para la construccin de prototipos de interfase de usuario.

18

3.14 El modelo de despliegue

3.15 Conclusin
Uno de los objetivos del modelado es describir el sistema que se est desarrollando a un nivel de detalle que permita controlar partes de un modulo con otro y determinar durante este ciclo de vida de desarrollo que no se haya omitido partes que son inherentes a otras. Al respecto, controlar que los modelos sean

correspondientemente satisfactorios o por lo menos en un grado aceptable permitir obtener un producto final utilizable. El especialista en diseos y modelos debe considerar que un modelo que no sigue alguna semntica estandarizada, bien podra crear modelos no vlidos que llevara a un modelo no aplicable en el desarrollo del producto que se busca o necesita.

19

Luego de una serie de vaivn de preguntas, entrevistas y mltiples cambios en cada uno de los diagramas el analista se encuentra frente a un conjunto de diagramas que en algunos casos por si solos carecen de sentido alguno, pero que en suma hacen a todo el proyecto. Esta serie de modelos puestos sobre la mesa de trabajo comienzan a tener sentido recin cuando se comienza a desarrollar el software, aclaro que no es una regla que deba tenerse todos los diagramas para comenzar el desarrollo del producto, sino que cada diagrama adquiere importancia cuando se empieza el trabajo de la construccin del software.

Los modelos en agrupacin reflejan las tres capas que luego se considera como parte de la arquitectura del software, estos modelos son tenidos en cuenta cuando se desarrolla sistemas de gestin para la toma de decisiones para empresas, y se puede generalizar como sigue:

A) Una vista de datos, B) Una vista del negocio C) Una vista del comportamiento

Estas capas son totalmente interdependientes y aunque se construyan de forma separada estn altamente relacionados en lo que conocemos como las reglas del negocio.

3.16 Versin de este documento 1.7

Este documento ha tenido una evolucin resultado de varios dilogos con colegas y el refinamiento sobre la teora, basado en la experiencia de amigos docentes y profesionales del rea de desarrollo de software. A partir de esta versin mi sugerencia es la aumentar la versin cada vez que realice una revisin a ste documento. De ste modo la siguiente versin ser 1.8

20

4 Bibliografa
4.1 Libros
BOCH Grady, RUMBAUGH James, JACOBSON Ivar. 2003. El Lenguaje Unificado de Modelado. Espaa. Addison Wesley . 2. Edicin LARMAN, Craig. 2003. Uml y Patrones. Pearson Educacin. GAMMA, Erich, HELM, Richard, JOHNSON, Ralph, and VLISSIDES, John. 2003. Patrones de diseo. Mxico. Addison Wesley POMMIER, Jorge T. Anlisis de requerimientos orientado a los objetivos. Mxico. Prentice Hall PRESSMAN, Roger. 2002. Ingeniera del software un enfoque prctico. Mxico. Mac Graw Hill. 5 Edicin. RUBLE, David. 1998. Anlisis y diseo prctico de sistemas para sistemas cliente servidor con Gui. Mxico. Prentice Hall. SCHACH, Stephen. 2005. Anlisis y diseo orientado a objetos con UML y el proceso unificado. Mxico. Mac Graw Hill. YOURDON, Edgar. 1989. Anlisis estructurado moderno. Mxico. Prentice Hall.

4.2

Revistas y manuales
Ministerio de Administraciones Pblicas. Anlisis del sistema de informacin. Metodologa Mtrica Versin 3. Per. Mundo Linux Nro: 40. 2002. Revistas Profesionales S.L. Espaa.

4.3

Web site http://www.umsanet.edu.bo/docentes/teran

http://weblog.mendoza.edu.ar/actinform/archives/004744.html http://www.eside.deusto.es/postgrado/dissc/default.asp?lang=SP http://www.icesi.edu.co/esn/contenido_programas.jsp?id=icesi3educc22 http://directo.uniovi.es/catalogo/FichaAsignatura.ASP?asignatura=7803 http://www.ctv.es/USERS/belmont/indexoo.htm http://www.tic.udc.es/~fbellas/teaching/adoo/ http://www.esoft.cl/pages/parte2a.html http://www.inei.gob.pe/biblioineipub/bancopub/inf/lib5040/TECN08.htm http://www.altana.es/master/ http://www.programacion.com/articulo/inukisoft http://www.itba.edu.ar/capis/webcapis/OldWeb/ancis5.html http://www.univernet.net/aulas/informatica/poo/cap-vi.htm http://www.dei.inf.uc3m.es/docencia/p_s_ciclo/pa/web/practicas/pfeb/pa-pfeb.pdf http://www.sparxsystems.cl/uml_patterns.html http://www.sparxsystems.cl/create_uml_patterns.html http://www.sparxsystems.cl/import_uml_patterns.html

21

http://www.sparxsystems.cl/use_uml_patterns.html http://www.programacion.com/java/articulo/joa_patrones1/ http://www.programacion.com/java/articulo/joa_patrones1/#joa_patrones1_software http://www.willydev.net/descargas/WillyDEV_JoseLuis_Diagramas_REP.pdf http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art163.asp http://www.ati.es/gt/LATIGOO/OOp96/Ponen12/atio6p12.html http://www.visual-paradigm.com/product/vpuml/demos/ http://www.dsic.upv.es/~uml/curso.pdf http://www.ciao.es/Rational_Rose_Enterprise_Edition__Opinion_612900 http://arantxa.ii.uam.es/~saiz/poo-cuarto/curso-actual/transp/ingenieria-softwareoo.PPT http://www.techeras.com/pdf/Syllabus_BPM_y_UML_para_Desarrolladores_de_Soft ware_con_RUP.pdf http://www.fi.uba.ar/materias/7572/PatronesAnalisis.pdf http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=15 http://www.yoprogramo.com/articulo4.php http://www.creangel.com/uml/secuencia.php

22