Universidad Tecnolgica Intercontinental

FACULTAD DE TECNOLOGA INFORMTICA

Metodologa de Anlisis, Diseo y Especificacin de Sistemas de Informacin MADESI

ORIENTADOR: Ing. Hilario Machuca Gonzlez

Asuncin Paraguay

NDICE

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

Resumen ......................................................................................................................... 1 Versin de este documento = 2.0 .................................................................................... 1 Trminos y Conceptos..................................................................................................... 1 Secuencia metodolgica de construccin de modelos..................................................... 2 4.1 Crear el repositorio del proyecto. .............................................................................. 2 4.2 Definir los modelos que se disearn ....................................................................... 3 4.2.1 El modelo de requerimientos .............................................................................. 4 4.2.1.1 Identificar las reas de relevamiento. .............................................................. 4 4.2.1.2 Documentar el relevamiento ............................................................................ 4 4.2.1.3 Clasificar u ordenar el relevamiento ................................................................ 5 4.2.1.4 Diagramar los requerimientos.......................................................................... 6 Comprender de donde derivan los requerimientos ....................................................... 7 4.2.1.5 Diagramar el modelo global del negocio o contextualizar el negocio ............... 9 4.2.2 Construir el Modelo de Comportamiento del sistema ........................................ 11 4.2.3 Diagramar los objetos de datos ....................................................................... 12 4.2.4 El modelo de informacin ................................................................................. 13 4.2.5 El Diagrama de secuencias .............................................................................. 14 4.2.6 El Diagrama de despliegue ............................................................................... 16 5 Bibliografa .................................................................................................................... 18 5.1 Libros ...................................................................................................................... 18 5.2 Revistas y manuales ............................................................................................... 18 5.3 Webgrafa ............................................................................................................... 18 1 2 3 4

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 requerimientos a modelar. Este documento pretende servir de base proponiendo una metodologa y las tcnicas concensuadas con otros docentes y profesionales que se desenvuelven en el escenario del uso del lenguaje UML para el diseo de sistemas de informacin de gestin y de ninguna manera pretende imponer criterios sobre la metodologa a utilizar en el diseo y especificacin de sistemas de informacin. Nunca permita que la falta de soporte CASE lo detenga para practicar una tcnica valiosa! [David Ruble, 1998]

2 Versin de este documento = 2.0

La continua evolucin de este documento es el resultado de varios dilogos con colegas y el refinamiento sobre la teora de anlisis y diseo de sistemas de informacin, basado en la experiencia de amigos docentes y profesionales del rea de desarrollo de software. La versin se incrementa cada vez que realice una revisin a ste documento. Siguiente versin= 2.1

3 Trminos y Conceptos
UML: Es un lenguaje estndar para escribir planos de software. Se utiliza para visualizar, especificar, construir y documentar los artefactos de un sistema que involucre una gran cantidad de software. Modelo: captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle. Metodologa: Conjunto de procedimientos, tcnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software. Diagrama: una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices conectados por arcos. Paquete: Los paquetes ofrecen un mecanismo general para la organizacin de los modelos/subsistemas agrupando elementos de modelado. Nota: es un smbolo grfico para representar restricciones o comentarios asociados a un elemento o a una coleccin de elementos, es presentada como un rectngulo con una esquina doblada junto a un comentario textual o grfico. Estereotipo: es una extensin del vocabulario de UML que permite crear nuevos tipos de bloques de construccin similares a los existentes, pero especficamente del problema que se est modelando, se representa con un nombre entre comillas francesas unas marcas como Tipos de Ingeniera: El modelado es importante, pero recordemos que el producto principal de un equipo de desarrollo es software y no diagramas. Por 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.

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. 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. 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 orientado a objetos, pero se dise con estas correspondencias en mente. Por ejemplo Star UML posee correspondencias con algunos lenguajes como C++, C# y Java.

4 Secuencia metodolgica de construccin de modelos

Los proyectos con apoyo de herramientas 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 uno o ms modelos que en conjunto forman un plano gua para la construccin del sistema. Cada modelo se refleja en un tipo de diagrama y dependen de las diferentes fases del desarrollo, estos diagramas pueden variar dependiendo del tamao y naturaleza del sistema.

4.1 Crear el repositorio del proyecto.

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

A modo de sugerencia he creado este grupo de directorios: Observe en la figura como se ha estructurado la carpeta Repositorio_Moblelect, dentro de esta carpeta es recomendable colocar un archivo tipo texto para identificar el objeto de la carpeta, escribiendo en el archivo la lista de carpetas y artefactos que incluye dicha carpeta. A su vez cada subcarpeta debera de incluir otro archivo del mismo nombre y sucesivamente en cada carpeta o subcarpeta.

4.2

Definir los modelos que se disearn

Cuando se modela, 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 bsicos, tales como clases, interfaces, colaboraciones, componentes, nodos, dependencias, generalizaciones y asociaciones. Para nuestro trabajo utilizaremos los siguientes modelos: Modelo de Negocios Diagrama de requerimientos (IR) Diagrama de caso de uso del negocio global Modelo de objetos Diagrama de clases de objetos de datos Modelo de comportamiento Diagrama de caso de uso con CUS Diagrama de secuencias Modelo de despliegue Diagrama de despliegue

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.

Definidos los modelos ms importantes que estaremos utilizando, pasaremos a relevar, analizar y especificar los requisitos del cliente (la empresa). Para especificar estos requisitos, debemos entender el domino del negocio, y para ello nos basaremos en el relevamientos de datos que hemos estado haciendo. De este modo, pasaremos al modelo de requerimiento. 4.2.1 El modelo de requerimientos El modelo de requerimientos se base en el relevamiento de requisitos, proceso que permite 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 en el ambiente, 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 como la etapa 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 el sistema le proporcione (puede decirse que esto luego se convierte en las prestaciones del software). 4.2.1.1 Identificar las reas de relevamiento. Cuando hacemos un relevamiento, podemos basarnos en el organigrama de la empresa y a partir de alli identificar 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 o departamento de compras (tomamos como caso de estudio) El rea o departamento de ventas El rea o departamento de depsito El rea o departamento de cobranza.

4.2.1.2 Documentar el relevamiento Con la lista de reas, puede comenzar un relevamiento de los procesos de negocio de cada usuario en su rea. Observe.

Fecha nota 15/09/2005

Punto de entrevista

Usuario Departamento Ventas

Confeccionar la factura a mano lleva mucho tiempo. Es importante agilizar la confeccin de la factura de manera a ofrecer un servicio gil Andresa al cliente. Se hace necesario llevar un catalogo de productos que la empresa ofrece a sus clientes, el precio de cada producto depende de un rango de categoras del cliente que el departamento de ventas define, de esta forma podemos ofrecer precios diferenciados a clientes segn una filosofa establecida por el departamento de Marketing.

15/09/2005

Felipe

Ventas

15/09/2005

Cuando el cliente llega al la empresa y solicita un presupuesto de dos o tres muebles en conjunto, la elaboracin de un presupuesto se hace de forma manual, pero con el inconveniente de que no se pose un Lorena catalogo de productos con sus precios y el porcentaje mximo y mnimo para realizar un descuento. Cuando el cliente devuelve un mueble, de tres que se le ha vendido, surge una nueva situacin. Generalmente como todos los procesos son manuales, se deja la tarea de actualizar la ficha del cliente para Andresa despus, debido a que muchas ocasiones o lleva mucho tiempo encontrar la ficha o simplemente no se dispone de tiempo por motivos de masiva concurrencia de clientes.

Ventas

15/09/2005

Ventas

Esta forma de documentar el relevamiento no necesariamente debe hacerse por cuadros, pero permite identificar rpidamente el departamento de donde se obtuvo esa informacin. Los analistas pueden utilizar cualquier mtodo para documentar el relevamiento, incluso existen herramientas que permiten la escritura del relevamiento dentro de fichas con proforma y slo hay que llenarlas. Otra forma de documentar el relevamiento es teniendo un cuestionario ordenado de preguntas y respuestas. 4.2.1.3 Clasificar u ordenar el relevamiento Una vez realizada todas las entrevistas y estudios de los procesos de negocio puede procederse a una simplificacin con la confeccin del siguiente cuadro donde nos preguntamos que es lo que el actor necesita del sistema. Fijmosnos en el siguiente cuadro:

Trabajador/Actor Encargado de compras Encargado de compras Jefe de compras Cliente Vendedor Vendedor Jefe de Ventas

Qu necesita del sistema? Departamento Elaborar orden de compra Compras Registrar compras y actualizar cuentas a pagar Compras Elaborar lista de compras Compras Consultar precio de producto Recepcionar pedido de productos del cliente Registrar venta y actualizar ctas. de cliente Elaborar informe de ventas Ventas Ventas Ventas Ventas

O confeccionar un esquema con una lista de requerimientos como la que sigue: 1 Departamento de compras 1.1 Elaborar orden de compra 1.2 Registrar las compras y generar cuentas a pagar 1.3 Elaborar un informe de compras Departamento de ventas 2.1 Registrar las ventas e y actualizar ctas. de clientes 2.2 Recepcionar pedido de productos del cliente 2.3 Elaborar informe de ventas Departamento de cobranzas 3.1 Actualizar cta. Cte. del cliente 3.2 Elaborar lista de ctas. a cobrar 3.3 Realizar apertura/cierre de caja 3.4 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

4.2.1.4 Diagramar los requerimientos Esta lista de requerimientos es representado en un diagrama de requerimientos para documentar el relevamiento y realizar un anlisis inicial del negocio. Tomaremos como ejemplo el rea de compras. El resultado se observa en el siguiente diagrama de requerimientos.

Observe que el requerimiento gestionar compras se le ha asignado un ID = 1, esto es solo al efecto de identificarlo desde nuestra lista de requerimientos y cada objeto de requerimiento contiene datos sobre el rea donde se detect 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.

Comprender de donde derivan los requerimientos En el ambiente de los negocios existen eventos y, 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 requerimientos, por lo tanto como habamos mencionado anteriormente si nos encontramos con un modelo de requerimiento carente de informacin, no podremos alcanzar el objetivo deseado. As el diseo refinado de nuestro diagrama de requerimientos quedara como lo muestra la siguiente figura:

Modificar numeracin Ahora que tenemos nuestro diagrama de requerimiento lo suficientemente refinado pasaremos a la tarea de construir la lista de eventos, tratando de que sea sencilla y fcil de elaborar y para ello debe tenerse en cuenta que describir el evento debe ser desde el punto de vista del ambiente. Observe de nuevo el diagrama de requerimientos y vea que en cada requerimiento se ha identificado el origen, es decir el origen del requerimiento y en el atributo text se ha especificado el evento que ocasiona un requerimiento. Partiendo del modelo de requerimientos podemos comenzar la elaboracin de esta lista de eventos identificando los eventos que suceden en el mundo real y que deban causar que el sistema entre en accin y haga algo; en base al diagrama anterior podemos crear la siguiente lista de eventos. 1.1 El personal de compras recepciona el pedido de mercadera de los empleados y elabora la orden de compra. 1.2 El personal de compras recepciona factura del proveedor. 1.3 El jefe 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 recepciona el pedido de productos se compone de: Sujeto: Personal de compra Verbo: recepciona Objeto: pedido de productos. Veamos ahora sobre las ventas de productos.

1.1 El cliente hace pedido de productos 1.2 El vendedor vende producto. 1.3 El vendedor solicita informe de ventas.

Los nombres de eventos son importantes y no deben escatimarse esfuerzo para buscar la expresin del evento, y 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: El cliente hace pedido Requerimiento: Recepcionar pedido Estimulo: pedido de cliente Respuesta: presupuesto cliente

Los eventos del ambiente son ocasionados por personas, mquinas, o sistemas y generan estmulos a los cuales nuestro sistema debe responder. Ya agrupados por rea en los que se observaron y debidamente refinados; esta forma de listar los eventos nos llevar a la construccin del modelo de caso de uso del negocio global de una forma casi automtica. Los eventos de nuestro caso de estudio se listan en el siguiente cuadro, fjese como queda la siguiente tabla donde se ordenan los eventos, el estimulo que produce y a que requerimiento atiende y una posible respuesta hacia el ambiente de parte del sistema.

EVENTOS DEL AREA DE COMPRAS El personal de compras elabora orden de compra

REQUERIMIETNOS Elaborar orden de compra

ESTIMULOS lista de compras factura de compra parmetros fechas, sucursal ESTIMULOS pedido de cliente venta de productos Parmetros de fechas, sucursal

RESPUESTA OC SR Informe de compras RESPUESTA presupuesto Factura o ticket Lista de ventas

El personal de compras recepciona factura Registrar compra de proveedor El personal de compras solicita informe de compras EVENTOS DEL AREA DE VENTAS El cliente hace pedido de productos El Vendedor realiza las ventas El jefe de ventas solicita informe de ventas elaborar informe de compras REQUERIMIENTOS recepcionar pedido registrar venta elaborar informe de ventas

Hemos demostrado como llegar a refinar el diagrama de requerimientos y como esta nos conduce a una lista de eventos para determinar los estmulos que deben ser atendidos por el sistema y reaccionar a un estimulo; nos damos cuenta de que ello se compone de datos y estos sern ingresados al sistema para que se transforme y produzca una salida vlida para el usuario o el grupo del usuarios. Los estmulos identifican los datos que se requieren para activar la reaccin del sistema, a su vez el procesamiento de estmulos puede provocar respuestas hacia el ambiente. 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 sistema. La siguiente expresin podra no ser realmente un evento: el sistema debe devolver un pagar por la deuda contrada por el cliente El analista detectar que el documento pagar es una respuesta hacia el ambiente, pero cul es el evento que lo origin? Se espera entonces que alguien realice una compra a crdito? Es este el evento? Estas situaciones deben expresar las cuatro partes que se ha visto en el cuadro anterior y deben ser identificados como sigue: o o o o evento requerimiento estimulo y la respuesta que genera al ambiente.

De sta forma ser ms sencilla la tarea de descubrir eventos y respuestas para determinar el comportamiento de nuestro sistema. 4.2.1.5 Diagramar el modelo global del negocio o contextualizar el 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 sobre el ambiente 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.

Para construir el modelo del negocio o modelar el contexto de un sistema: Hay que identificar las fronteras del sistema decidiendo los comportamientos que formarn parte de l, y cuales sern ejecutados por entidades externas. Hay que identificar los actores en torno al sistema, considerando qu grupos requieren ayuda del sistema para llevar a cabo su tarea; qu grupos son necesarios para ejecutar las funciones del sistema. Hay que organizar a los generalizacin/especializacin. actores similares en jerarquas de

Basados en los puntos mencionados ms arriba, pase primero a dibujar el rectngulo que representar al sistema, luego dibuje el actor en base su modelo de requerimientos y que se encuentra especificado en los atributos de origen y que son justamente quienes podran interactuar directamente con el sistema. Si lo primero que incluyo como entidad externa es al cliente, debe hacerse esta pregunta:Interacta el cliente de forma directa con el sistema? Esto quiere decir que si el cliente se expone ante una estacin de trabajo (generalmente pc) en el que debe accionar algo para que sea ejecutada una ventana para realizar algo. Si la respuesta es si, pues entonces es vlido que el actor cliente figure en el modelo del negocio. De otra forma no podr encontrar sentido a su diseo y estara mirando al cielo preguntndose Qu es lo que hace este actor aqu? Luego coloque una figura elptica que representa el caso de uso de negocio en concordancia con la cantidad de requerimientos padres de cada diagrama de requerimiento que estuvo diseando, como nombre del CU se coloca el nombre del Requerimiento padre; por ejemplo Requerimiento Gestionar compras, otro Requerimiento Gestionar ventas y sucesivamente para cada requerimiento padre de nuestro diagrama de requerimientos. Luego comience por unir por medio de la asociacin a cada actor con el CU que corresponde a su rea, esto lo puede corroborar nuevamente observando cada requerimiento y su origen en el diagrama de requerimientos. La siguiente figura es una vista del modelo global del negocio confeccionado con StarUML en la versin 5.0 y pretende mostrar cuales macroprocesos que son ejecutados en la empresa interactan con los actores comerciales.

10

Observe que los actores comerciales proveedor y cliente no aparecen en el diseo de modelo caso de uso del negocio. Observe cada figura elptica del modelo de negocio y se dar cuenta de que esto puede considerarse como los macro-procesos dentro de la empresa y que ms tarde se convertirn en mdulos del sistema a construir. Pasemos a detallar entonces los mdulos y que segn este diseo son: Modulo de compras Modulo de ventas Modulo de cobranzas Modulo de inventario Modulo de informes.

4.2.2 Construir el Modelo de Comportamiento del sistema El modelo de comportamiento se representa por tres diagramas y que son como sigue: Diagrama de caso de uso por cada requerimiento Diagrama de secuencias (por cada caso de uso)

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 que hace uso del sistema e interacta con el, esto permite visualizar 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. Un actor podra ser un usuario, un administrador o un vendedor, y es representado por la figura de una personita con los brazos extendidos de forma horizontal. 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 y permiten documentar de manera sencilla y entendida por cualquiera ajeno a la informtica.

11

Los casos de uso son fciles de construir, solo debemos representar, trabajadores del negocio y actores del negocio con forma de personita, las acciones del sistema con elipses, que deber contener un texto descriptivo del caso de uso, adems representar las interacciones entre los actores y los procesos del negocio con una lnea. Las acciones del sistema pueden estar relacionadas entre s mediante las etiquetas: << Extiende >>: una accin se especializa por medio de otra serie de acciones mas concretas << Incluye >>: incluye la funcionalidad de otro caso de uso o accin. Los casos de usos son una representacin visual de los requerimientos funcionales Para representar un CUN, puede referenciar por cada requerimiento del diagrama de requerimiento o hacer un modelo de casos de uso por mdulos de subsistema, en ese caso debe vincular el requerimiento padre de los requerimientos del diagrama de requerimientos a un modelo de caso de uso como se muestra en la siguiente figura:

En la figura puede observarse que representar los casos de uso del sistema tiene una correspondencia con el diagrama de requerimientos diseado anteriormente. Esta secuencia correlativa, nos ayuda a identificar de una forma sencilla las Futuras GUI de usuario que deberan de ser construidas por los Developers de sistema.

4.2.3 Diagramar los objetos de datos 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). Una entidad es un objeto que generalizar otros objetos como atributos, en la implementacin de los diseos conceptuales, una entidad, se convierte en una tabla dentro de una Base de Datos, y un atributo se convierte en un campo dentro de una tabla; la tabla es un objeto que agrega campos.

12

Para nuestro ejemplo tomaremos 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 interaccin utilizando un diagrama de secuencias. 4.2.4 El modelo de informacin Los datos son el activo de informacin central del negocio y debe ser modelado y manejado con prudencia, de esta afirmacin surge la importancia de elaborar un buen modelo de informacin, que sin lugar a duda es el que determinar el xito de todo proyecto. El modelado de la informacin es el que forma la base del diseo de la base de datos relacional, la cual esta formada por un serie de conceptos, procedimientos y tcnicas para el buen modelado de objetos que la conforman. El modelo entidad-relacin es el modelo conceptual ms utilizado para el diseo de bases de datos, el cual esta est formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones grficas y lingsticas. Los elementos esenciales del modelo son las entidades acerca de las cuales el sistema necesita recordar hechos especficos, los atributos y las relaciones que existen entre estos grupos de hechos (entidades). Entidad Cualquier tipo de objeto o concepto sobre el que se recoge informacin: cosa, persona, concepto abstracto, suceso, evento. Por ejemplo: coches, casas, empleados, clientes, empresas, oficios, comprar, vender, etc. Las entidades se representan grficamente mediante rectngulos y su nombre aparece en el interior. Un nombre de entidad slo puede aparecer una vez en el esquema conceptual. Relacin Es una asociacin entre dos o ms entidades. Cada relacin tiene un nombre que describe su funcin. Las relaciones se representan grficamente mediante lneas rectas y su nombre define como se relacionan. Las entidades que estn involucradas en una determinada relacin se denominan entidades participantes. La cardinalidad con la que una entidad participa en una relacin, especifica el nmero mnimo y el nmero mximo de correspondencias en las que

13

puede tomar parte cada ocurrencia de dicha entidad. La participacin de una entidad en una relacin es obligatoria (total) si la existencia de cada una de sus ocurrencias requiere la existencia de, al menos, una ocurrencia de la otra entidad participante. Si no, la participacin es opcional (parcial). Las reglas que definen la cardinalidad de las relaciones son las reglas de negocio. Atributos El tercer componente principal del modelo de informacin son los atributos, que representan a todos los elementos de datos del sistema. Cada hecho acerca de una entidad constituye un atributo. Los atributos pueden ser simples o compuestos. Un atributo simple es un atributo que tiene un solo componente, que no se puede dividir en partes ms pequeas que tengan un significado propio. Un atributo compuesto es un atributo con varios componentes, cada uno con un significado por s mismo. Un grupo de atributos se representa mediante un atributo compuesto cuando tienen afinidad en cuanto a su significado, o en cuanto a su uso. En el siguiente ejemplo se presenta el DER orden de compra.

4.2.5 El Diagrama de secuencias Un modelo de secuencias es un tipo de modelo de interaccin junto con el diagrama de colaboracin, el diagrama se secuencias se expresa por medio de un diagrama de secuencias que muestra las interacciones entre los objetos organizadas en una secuencia temporal. En particular muestra los objetos participantes en la interaccin y la secuencia de mensajes intercambiados. Representa una interaccin, un conjunto de comunicaciones entre objetos organizadas visualmente por orden temporal. A diferencia de los diagramas de colaboracin, los diagramas de secuencia incluyen secuencias temporales pero no incluyen las relaciones entre objetos. Pueden existir de forma de descriptor (describiendo todos los posibles escenarios) y en forma de instancia (describiendo un escenario real). Dentro del conjunto de mensajes representados dispuestos en una secuencia temporal, cada rol en la secuencia se muestra como una lnea de vida, es decir, una lnea vertical que

14

representa el rol durante cierto plazo de tiempo, con la interaccin completa. Los mensajes se muestran como flechas entre lneas de vida. Un diagrama de secuencia puede mostrar un escenario, es decir, una historia individual de transaccin. Un uso de un diagrama de secuencia es mostrar la secuencia del comportamiento de un caso de uso. Un dilogo de secuencia posee dos dimensiones: la vertical representa el tiempo, la horizontal representa los objetos que participan en la interaccin. En general, el tiempo avanza hacia abajo dentro de la pgina (se pueden invertir los ejes si se desea). Con frecuencia slo son importantes las secuencias de mensajes pero en aplicaciones de tiempo real el eje temporal puede ser una mtrica. La ordenacin horizontal de los objetos no tiene ningn significado. Cada objeto representa una columna distinta, se pone un smbolo de objeto al final de la flecha que representa el mensaje que ha creado el objeto; est situada en el punto vertical que denota el instante en que se crea el objeto. Esta se conoce como lnea de vide del objeto. Se pone una X grande en el punto en que deja de existir el objeto o en el punto en que el objeto se destruye a s mismo. Para el periodo durante el cual est activo el objeto, la lnea de vida se ampla para ser una lnea doble continua. Si el objeto se llama a s mismo, entonces se superpone otra copia de la doble lnea para mostrar la doble activacin. El orden relativo de los objetos no tiene significado an cuando resulta til organizarlos de modo que se minimice la distancia de las flechas. Cada mensaje se representa mediante una flecha horizontal que va desde la lnea de vida del objeto que envi el mensaje hasta la lnea de vida del objeto que ha recibido el mensaje. Si un mensaje requiere un cierto tiempo para llegar a su destino, entonces la flecha del mensaje se dibuja diagonalmente hacia abajo. Un diagrama de secuencia tambin se puede mostrar en forma de descriptor, en el cual los constituyentes son roles en lugar de objetos. Este diagrama muestra en el caso general, no una sola ejecucin del mismo. Los diagramas del nivel de descriptores se dibujan sin subrayados porque los smbolos denotan roles y no objetos individuales. Lnea de vida de un objeto (lifeline): La lnea de vida de un objeto representa la vida del objeto durante la interaccin. En un diagrama de secuencia un objeto se representa como una lnea vertical punteada con un rectngulo de encabezado y con rectngulos a travs de la lnea principal que denotan la ejecucin de mtodos (activacin). El rectngulo de encabezado contiene el nombre del objeto y el de su clase, en un formato NombreObjeto: NombreClase. Activacin: Muestra el perodo de tiempo en el cual el objeto se encuentra desarrollando alguna operacin, bien sea por s mismo o por medio de delegacin a alguno de sus atributos. Se denota como un rectngulo delgado sobre la lnea de vida del objeto. Mensaje: El envo de mensajes entre objetos se denota mediante una lnea slida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta. Tiempos de transicin: En un entorno de objetos concurrentes o de demoras en la recepcin de mensajes, es til agregar nombres a los tiempos de salida y llegada de mensajes.

Para disear el diagrama de secuencias necesariamente debera de tener el diagrama de objetos de datos ya terminado en gran parte y siguiendo con nuestro ejemplo tendramos nuestro diagrama de esta forma:

15

La lnea de vida para el actor personal de compras comienza desde que se activa la interfaz de usuario hasta que se obtiene la impresin de la orden de compra. Observe que los diferentes objetos slo son usados o interactan un lapso de tiempo durante la ejecucin del la tarea de registrar el pedido de compra de productos. 4.2.6 El Diagrama de despliegue Es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes. Los elementos usados por este tipo de diagrama son nodos (representados como prisma), componentes (representados como caja rectangular con dos protuberancias) y asociaciones. En el UML 2.0 los componentes ya no estn dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo. Este tipo de diagrama debemos tambin aadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre sern entre los nodos y por ejemplo con una base de datos. Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto ms amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programacin, a un sistema operativo, un ordenador o un cluster de terminales. La mayora de las veces el modelado de la vista de despliegue implica modelar la topologa del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificacin hardware de propsito general, se ha diseado para modelar muchos de los

16

aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema. La siguiente figura muestra un ejemplo de un diagrama de despliegue con una vista de accesos de clientes desde Internet, puertos del servidor, tipo tecnologa de interconectividad e incluso configuraciones de performance del servidor y las estaciones cliente.

En esta figura, se muestra otra disposicin de nodos en el diagrama de despliegue con otra categora de redes.

17

5 Bibliografa
5.1 Libros
SCHACH, Stephen. 2005. Anlisis y diseo orientado a objetos con uml y el proceso unificado. Mxico.Mac Graw Hill. 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. YOURDON, Edgar. 1989. Anlisis estructurado moderno. Mxico. Prentice Hall.

5.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.

5.3

Webgrafa
http://72.14.207.104/search?q=cache:DTGrHSDXIWUJ:atari.uniandes.edu.co/burban o/mecad_c http://www.icesi.edu.co/esn/contenido_programas.jsp?id=icesi3educc22 http://www.unmsm.edu.pe/Epg/maestrias/area_ingenieria/sistemas/ingenieria_softwa re.htm 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.inei.gob.pe/biblioineipub/bancopub/inf/lib5040/TECN08.htm http://www.programacion.com/articulo/inukisoft http://www.monografias.com/trabajos12/docmento/docmento.shtml http://www.programacion.com/java/articulo/joa_patrones1/ http://www.programacion.com/java/articulo/joa_patrones1/#joa_patrones1_software http://www.visual-paradigm.com/product/vpuml/demos/ http://office.microsoft.com/es-hn/visio/HP815502823082.aspx http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=15 http://www.altova.com/umodel.html

18