Metodologa de Anlisis, Diseo y Especificacin deSistemas de Informacin

MADESI

Ing. Hilario Machuca Gonzlez

Asuncin Paraguay

2013NDICEPortada.........................................................................................................................Indice...........................................................................................................................II1Introduccin........................................................................................................................................................................52Versin de este documento = 2.4........................................................................................................................................53Trminos y Conceptos........................................................................................................................................................54Secuencia metodolgica de construccin de modelos........................................................................................................7

4.1Crear el repositorio del proyecto.................................................................................................................................84.2Definir los modelos que se disearn..........................................................................................................................8

4.2.1El modelo de requerimientos................................................................................................................................94.2.1.1Identificar las reas de relevamiento...........................................................................................................104.2.1.2Documentar el relevamiento........................................................................................................................104.2.1.3Clasificar y agrupar el relevamiento............................................................................................................114.2.1.4Diagramar los requerimientos......................................................................................................................134.2.1.5Comprender de donde derivan los requerimientos......................................................................................134.2.1.6Diagramar el modelo global del negocio.....................................................................................................15

4.2.2Construir el Modelo de Comportamiento del sistema........................................................................................174.2.3 Diagramar los objetos de datos..........................................................................................................................194.2.4El modelo de informacin..................................................................................................................................204.2.5El Diagrama de Secuencias................................................................................................................................214.2.6El Diagrama de Despliegue................................................................................................................................23

5Resumen...........................................................................................................................................................................256Bibliografa.......................................................................................................................................................................25

6.1Libros.........................................................................................................................................................................256.2Revistas y manuales...................................................................................................................................................266.3Webgrafa...................................................................................................................................................................26

2

1 Introduccin

El modelado genrico de sistemas de informacin habra de pasar por lo quese conoce como marcos referenciales metodolgicos: esto es, un adecuadoconjunto de herramientas y mtodos que conformen un patrn aplicable deforma segmentada y no necesariamente completa sobre el dominio de losrequerimientos a modelar.

Este documento pretende servir de base proponiendo una metodologa y lastcnicas concensuadas con otros docentes y profesionales que sedesenvuelven en el escenario del uso del lenguaje UML para el diseo desistemas de informacin de gestin y de ninguna manera pretende imponercriterios sobre la metodologa a utilizar en el anlisis, diseo y especificacinde sistemas de informacin.

Nunca permita que la falta de soporte CASE lo detenga para practicaruna tcnica valiosa! [David Ruble, 1998]

El modelado es una tcnica propuesta por la Ingeniera del Software para eldiseo formal de las aplicaciones.

El Desarrollo de Software Dirigido por Modelos es una tcnica de construccindel software que concede a los modelos la mxima importancia. Los modelosya no son simples medios para describir software, sino la pieza fundamentalpara su desarrollo. Los modelos existentes en una fase (anlisis, diseo, etc...)se convierten hasta derivar a la aplicacin de una forma iterativa, tal como es elproceso propiamente aplicando el Lenguaje Unificado de Modelado.

2 Versin de este documento = 2.4

La continua evolucin de este documento es el resultado de varios dilogoscon colegas y el refinamiento sobre la teora de anlisis y diseo de sistemasde informacin, basado en la experiencia de amigos docentes yprofesionales del rea de desarrollo de software. La versin se incrementacada vez que realice una revisin a ste documento.

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 unsistema que involucre una gran cantidad de software.

UML son las siglas para Unified Modeling Language, que en castellanoquiere decir: Lenguaje de Modelado Unificado. Para comprender qu es elUML, basta con analizar cada una de las palabras que lo componen, porseparado.

3

Lenguaje: el UML es, precisamente, un lenguaje. Lo que implica queste cuenta con una sintaxis y una semntica. Por lo tanto, al modelarun concepto en UML, existen reglas sobre cmo deben agruparse loselementos del lenguaje y el significado de esta agrupacin.

Modelado: el UML es visual. Mediante su sintaxis se modelandistintos aspectos del mundo real, que permiten una mejorinterpretacin y entendimiento de ste.

Unificado: unifica varias tcnicas de modelado en una nica.

Ya que el UML proviene de tcnicas orientadas a objetos, se crea con lafuerte intencin de que este permita un correcto modelado orientado aobjetos.

Modelo: captura una vista de un sistema del mundo real. Es unaabstraccin de dicho sistema, considerando un cierto propsito. As, elmodelo describe completamente aquellos aspectos del sistema que sonrelevantes al propsito del modelo, y a un apropiado nivel de detalle.

Un modelo es una representacin abstracta de la realidad. En el caso delsoftware, la realidad que debemos representar la constituyen lasaplicaciones software que queremos construir. Los modelos por tanto, nossirven para representar cada una de las piezas que van a componer estasaplicaciones y poder comunicar esta informacin a todo el equipo dedesarrollo.

Diagrama: una representacin grfica de una coleccin de elementos demodelado, a menudo dibujada como un grafo con vrtices conectados porarcos.

Metodologa: Conjunto de procedimientos, tcnicas, herramientas y unsoporte documental que ayuda a los desarrolladores a realizar nuevosoftware.

Paquete: Los paquetes ofrecen un mecanismo general para laorganizacin de los modelos/subsistemas agrupando elementos demodelado.

Actor es algo con comportamiento, como una persona (identificada porun rol), un sistema informatizado u organizacin, y que realiza algn tipo deinteraccin con el sistema.. Se representa mediante una figura humanadibujada con palotes. Los personajes o entidades que participarn en uncaso de uso se denominan actores.

Casos de Uso: un caso de uso modela el requisito funcional del nuevosistema o del sistema existente y las relaciones que hay entre un actor y las

4

funciones (CU) entre un usuario y el sistema. Un CU es una descripcin delos pasos o las actividades que debern realizarse para llevar a cabo algnproceso.

En el contexto de ingeniera del software, un caso de uso es una secuenciade interacciones que se desarrollarn entre un sistema y sus actores enrespuesta a un evento que inicia un actor principal sobre el propio sistema.

Relacin: es una conexin entre los elementos del modelo, existen trestipos de relaciones en un los diagramas de caso de uso

Comunica (): Relacin (asociacin) entre un actor yun caso de uso que denota la participacin del actor en dicho caso deuso.

Usa o en la nueva versin de UML: Relacin dedependencia entre dos casos de uso que denota la inclusin delcomportamiento de un escenario en otro. Por contra, utilizaremos unarelacin tipo cuando nos encontramos con una parte decomportamiento similar en dos casos de uso y no queremos repetir ladescripcin de dicho comportamiento comn.

Extiende (): Relacin de dependencia entre dos casos deuso que denota que un caso de uso es una especializacin de otro.Por ejemplo, podra tenerse un caso de uso que extienda la forma depedir azcar, para que permita escoger el tipo de azcar (normal,diettico o moreno) y adems la cantidad en las unidades adecuadas(cucharadas o bolsas). Se utiliza una relacin de tipo entre casos de uso cuando nos encontramos con un caso de usosimilar a otro pero que hace algo ms que ste (variante).

Estereotipo: es una extensin del vocabulario de UML que permite crearnuevos tipos de bloques de construccin similares a los existentes, peroespecficamente del problema que se est modelando, se representa con unnombre entre comillas francesas unas marcas como

Nota: es un smbolo grfico para representar restricciones o comentariosasociados a un elemento o a una coleccin de elementos en un diagrama.Es un modo de indicar informacin de manera adecuada, es presentadacomo un rectngulo con una esquina doblada junto a un comentario textual ogrfico.

Artefacto puede ser algo como un archivo, un programa, una biblioteca,o una base de datos construida o modificada en un proyecto. Estosartefactos implementan colecciones de componentes.

Tipos de Ingeniera: El modelado es importante, pero recordemos queel 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 elmomento oportuno, el software adecuado que satisfaga los objetivos siemprecambiantes de los usuarios y la empresa.

5

Ingeniera Directa: es el proceso de transformar un modelo en cdigo atravs de una correspondencia con un lenguaje de implementacin. Laingeniera inversa produce una prdida de informacin, porque los modelosescritos en UML son semnticamente ms ricos que cualquier lenguaje deprogramacin orientado a objetos actual. De hecho, sta es una de lasrazones por las que se necesitan modelos adems de cdigo. Lascaractersticas estructurales, como las colaboraciones, y las caractersticasde comportamiento, como las interacciones, pueden visualizarse claramenteen UML, pero no tan claramente a partir de simple cdigo fuente.

Ingeniera Inversa: es el proceso de transformar cdigo en un modelo atravs de una correspondencia con un lenguaje de programacin especfico.La ingeniera inversa produce un aluvin de informacin, parte de la cualest a un nivel ms bajo del que se necesita para construir modelos tiles. Almismo tiempo es incompleta ya que hay una prdida de informacin cuandose hace ingeniera directa de modelos a cdigos, as que no se puederecrear completamente un modelo a partir de cdigo a menos que lasherramientas incluyan informacin en los comentarios del cdigo fuente quevaya ms all de la semntica del lenguaje de implementacin.Para algunos usos de UML, los modelos realizados nunca secorrespondern con un cdigo. Por ejemplo, si se modela un proceso denegocio con diagramas de actividades, muchas de las actividadesmodeladas involucrarn a personas y no a computadoras. En la mayora delos casos, sin embargo, los modelos creados se correspondern con cdigo,al respecto UML no especfica ninguna correspondencia particular conningn lenguaje de programacin orientado a objetos, pero se dise conestas correspondencias en mente. Por ejemplo Star UML poseecorrespondencias con algunos lenguajes como C++, C# y Java.

4 Secuencia metodolgica de construccin de modelosLos proyectos con apoyo de herramientas CASE logran modelos del sistemaque permiten entender lo que el sistema har, a la vez que pueden hacerse unseguimiento de la completitud, precisin y consistencia del diseo; esto lleva adescubrir errores solo durante la fase de programacin y que slo sean erroresde programacin y no un reflejo de falta de entendimiento entre usuarios yanalistas.

Las actividades de diseo producen uno o ms modelos que en conjuntoforman un plano gua para la construccin del sistema. Cada modelo se reflejaen un tipo de diagrama y dependen de las diferentes fases del desarrollo, estosdiagramas pueden variar dependiendo del tamao y naturaleza del sistema y elresponsable de construir todos estos modelos es el analista/diseador.

6

4.1 Crear el repositorio del proyecto.Un repositorio o depsito es un sitio centralizado donde se almacena ymantiene informacin digital, habitualmente bases de datos o archivosinformticos. Los datos almacenados en un repositorio pueden distribuirse atravs de una red informtica, como Internet, o de un medio fsico, como undisco compacto. Pueden ser de acceso pblico o estar protegidos y necesitarde una autentificacin previa.

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

4.2 Definir los modelos que se disearn

Cuando se modela, se crea una simplificacin de la realidad para comprendermejor el sistema que se est desarrollando. Con UML, se construyen modelosa partir de bloques bsicos, tales como clases, interfaces, colaboraciones,componentes, nodos, dependencias, generalizaciones y asociaciones.

Para nuestro trabajo utilizaremos los siguientes modelos:

Modelo de NegociosDiagrama de requerimientos (IR)Diagrama de caso de uso del negocio global

Modelo de objetosDiagrama de clases de objetos de datos

Modelo de comportamientoDiagrama de caso de uso con CUS

7

Construimos modelos para comprender mejor el sistema que estamosdesarrollando

Booch, Rumbaugh, Jacobson UML 2.0 (Segunda Edicin)

Diagrama de secuencias Modelo de despliegue

Diagrama de despliegue

Para crear los modelos con Visual Paradigm, vaya hasta la pestaa deExplorador de Modelos, haga click derecho sobre el nombre del proyecto yagregue los modelos. F2 para renombrar los modelos. Vea esto en la siguientefigura.

Definidos los modelos ms importantes que estaremos utilizando, pasaremos arelevar, analizar y especificar los requerimientos del cliente (la empresa). Paraespecificar estos requisitos, debemos entender el domino del negocio, y para ellonos basaremos en el relevamiento de datos que hemos estado haciendo. De estemodo, pasaremos al modelo de requerimiento.

4.2.1 El modelo de requerimientos

El modelo de requerimientos se basa en el relevamiento de requisitos, procesoque permite descubrir, analizar, escribir y verificar los servicios y restricciones delsistema de software.

Su importancia radica en que, de la definicin de los requerimientos depender ladefinicin de las etapas subsecuentes del desarrollo de software, es decir, que sino se descubren los requerimientos en el ambiente, obligar a retrocedernuevamente a la etapa de requerimientos; esto provocara cambios en el sistemay consecuentemente retraso en la entrega del sistema. Un caso peor, es que no

8

Tal vez el principal problema al que nos enfrentamos en el desarrollo desistemas grandes y complejos es el de la ingeniera de requerimientos. statrata de establecer lo que el sistema debe hacer, sus propiedades emergentesdeseadas y esenciales, y las restricciones en el funcionamiento del sistema ylos procesos de desarrollo del software. Por lo tanto puede considerar la i n g en i e r a de requerimientos como el proceso de comunicacin entre los clientesy usuarios del software y los desarrollad o res del mismo

Ian Sonmerville Ingenieria del Software

se encontraran y especificaran todos los requerimientos del sistema en unproceso de desarrollo de software, lo cual producira la entrega de un producto desoftware incompleto o poco funcional. Se puede considerar a esta como la etapams importante de todo el proyecto, por lo tanto se deber recurrir a la tcnicams ptima para lograr obtener con claridad lo que desea el usuario que elsistema le proporcione (puede decirse que esto luego se convierte en lasprestaciones del software).

4.2.1.1 Identificar las reas de relevamiento. Cuando hacemos un relevamiento, podemos basarnos en el organigrama de laempresa y a partir de all identificar las reas en las que debe entrevistarse(entienda que cuando hablamos de reas necesariamente debe conversar conalgn personal de esa rea) y haga una lista de ellas. Veamos:

El rea de compras El rea de ventas (tomamos como ejemplo) El rea de depsito El rea de cobranza.

4.2.1.2 Documentar el relevamiento

Con la lista de reas, puede comenzar un relevamiento de los procesos de negociode cada usuario en su rea. Observe.

Fecha nota Ambiente Usuario Departamento

15/09/2005Confeccionar la factura a mano lleva mucho tiempo. Es importanteagilizar la confeccin de la factura de manera a ofrecer un servicio gilal cliente.

Andresa

Ventas

15/09/2005

Se hace necesario llevar un catalogo de productos que la empresaofrece a sus clientes, el precio de cada producto depende de un rangode categoras del cliente que el departamento de ventas define, deesta forma podemos ofrecer precios diferenciados a clientes segnuna filosofa establecida por el departamento de Marketing.

Felipe Ventas

15/09/2005

Cuando el cliente llega al la empresa y solicita un presupuesto de doso tres muebles en conjunto, la elaboracin de un presupuesto se hacede forma manual, pero con el inconveniente de que no se pose uncatalogo de productos con sus precios y el porcentaje mximo ymnimo para realizar un descuento.

Lorena Ventas

15/09/2005

Cuando el cliente devuelve un mueble, de tres que se le ha vendido,surge una nueva situacin. Generalmente como todos los procesosson manuales, se deja la tarea de actualizar la ficha del cliente paradespus, debido a que muchas ocasiones o lleva mucho tiempoencontrar la ficha o simplemente no se dispone de tiempo por motivosde masiva concurrencia de clientes.

Andresa

Ventas

Esta forma de documentar el relevamiento no necesariamente debe hacerse porcuadros, pero permite identificar rpidamente el departamento de donde se obtuvoesa informacin. Los analistas pueden utilizar cualquier mtodo para documentarel relevamiento, incluso existen herramientas que permiten la escritura delrelevamiento dentro de fichas con proforma y slo hay que llenarlas.

9

Otra forma de documentar el relevamiento es teniendo un cuestionario ordenadode preguntas y respuestas o grabando la conversacin en algn medio multimedio.

4.2.1.3 Clasificar y agrupar el relevamiento

Una vez realizada todas las entrevistas y estudios de los procesos de negociopuede procederse a una simplificacin con la confeccin del siguiente cuadrodonde nos preguntamos que es lo que el actor necesita del sistema. Fijmonos enel siguiente cuadro:

O confeccionar un esquema con una lista de requerimientos como la que sigue:

1 rea de compras1.1 Elaborar orden de compra1.2 Registrar las compras y generar cuentas a pagar1.3 Elaborar un informe de compras

2 rea de ventas2.1 Recepcionar pedido de productos del cliente2.2 Registrar las ventas y actualizar ctas. de clientes2.3 Registrar Devolucin de productos del cliente2.4 Elaborar informe de ventas

3 rea de cobranzas3.1 Realizar apertura/cierre de caja con resumen de movimiento de

caja3.2 Realizar cobros de cuentas y actualizar Cta. Cte. del cliente.3.3 Realizar arqueo de caja

4 rea de depsito (inventario de bienes de cambio)4.1 Transferir productos entre depsitos y sucursales4.2 Ajustar existencia de productos luego de inventario4.3 Obtener informe de existencia mnimas4.4 Preparar planilla para inventario

4.2.1.4 Diagramar los requerimientos

Esta lista de requerimientos es representado en un diagrama derequerimientos para documentar el relevamiento y realizar un anlisis inicial

10

Trabajador/Actor Qu necesita del sistema?Departament

oEncargado de compras Elaborar una orden de compra ComprasEncargado de compras Registrar compras actualizando ctas. a pagar Compras

Jefe de compras Registrar nota de crdito del proveedor Compras

Vendedor Consultar precio de producto VentasVendedor Recepcionar pedido de productos del cliente VentasVendedor Registrar venta y actualizar ctas. de cliente VentasVendedor Registrar devolucin de productos del Cliente Ventas

Jefe de Ventas Elaborar informe de ventas Ventas

del negocio. Tomaremos como ejemplo el rea de ventas. El resultado seobserva en el siguiente diagrama de requerimientos.

Observe que el requerimiento gestionar ventas se le ha asignado un ID = 2,esto es solo al efecto de identificarlo desde nuestra lista de requerimientos ycada objeto de requerimiento contiene datos sobre el rea donde se detectel requerimiento, el tipo de requerimiento, el mtodo por el que se identificy su grado de prioridad entre los dems requerimientos. Como una forma deorganizar el diseo, puede numerar cada extensin del requerimiento, veaque en el diseo cada requerimiento posee un ID.

4.2.1.5 Comprender de donde derivan los requerimientos

En el ambiente de los negocios existen eventos y, son justamente estoseventos los que se necesitan capturar para determinar elcomportamiento del sistema a desarrollar.

Para capturar un evento que ocurre en el ambiente, debe considerarse lasintaxis sujeto-verbo-objeto y esto no es que sea una tarea sencillaespecialmente si es que no se elabor un buen relevamiento derequerimientos, por lo tanto como habamos mencionado anteriormente sinos encontramos con un modelo de requerimiento carente de informacin,no podremos alcanzar el objetivo deseado. El evento no debera de presentar palabras innecesarias, se describir deforma especfica en una lnea como una oracin, tomemos por ejemplo elsiguiente evento:

El evento El vendedor vende productos se compone de:

11

Sujeto: VendedorVerbo: vendeObjeto: productos.

As el diseo refinado de nuestro diagrama de requerimientos quedara comolo muestra la siguiente figura:

Observe de nuevo el diagrama de requerimientos y vea que en cada requerimientose ha identificado el origen(source), es decir el origen del requerimiento y en elatributo text se ha especificado el evento que ocasiona un requerimiento.

Ahora que tenemos nuestro diagrama de requerimiento lo suficientemente refinadopasaremos a la tarea de construir la lista de eventos, tratando de que sea sencillay fcil de elaborar; partiendo del modelo de requerimientos podemos comenzar laelaboracin de esta lista de eventos identificando los eventos que suceden en elmundo real (ambiente) y que deban causar que el sistema entre en accin y hagaalgo; en base al diagrama anterior podemos crear la siguiente lista de eventos.

2.1 El cliente hace pedido de productos 2.2 El vendedor vende producto. 2.3 El vendedor acepta devolucin de artculos 2.4 El vendedor solicita informe de ventas.

Los nombres de eventos son importantes y no deben escatimarse esfuerzo parabuscar la expresin del evento, y ha llegado el momento de tomar slo aquellos alos que el sistema debe responder, esto puede conseguirse mediante la confeccinde una planilla en la que podemos comparar nombre de evento, requerimiento quese cubre, y el estimulo que activa el evento. No crea que las palabras estimulo yeventos sean de significado igualitarios.

Para ordenar las ideas puede crear un esquema como sigue:

Evento: El cliente hace pedidoRequerimiento: Recepcionar pedido

12

Estimulo: pedido de clienteRespuesta: presupuesto cliente

Los eventos del ambiente son ocasionados por personas, mquinas, o sistemas ygeneran estmulos a los cuales nuestro sistema debe responder. Ya agrupados porrea en los que se observaron y debidamente refinados; esta forma de listar loseventos nos llevar a la construccin del modelo de caso de uso del negocio globalde una forma casi automtica.

Los eventos de nuestro caso de estudio se listan en el siguiente cuadro, fjesecomo queda la siguiente tabla donde se ordenan los eventos, el estimulo queproduce y a que requerimiento atiende y una posible respuesta hacia el ambientede parte del sistema.

Hemos demostrado como llegar a refinar el diagrama de requerimientos y comoesta nos conduce a una lista de eventos para determinar los estmulos que debenser atendidos por el sistema y reaccionar a un estimulo; nos damos cuenta de queello se compone de datos y estos sern ingresados al sistema para que setransforme y produzca una salida vlida para el usuario. Los estmulos identificanlos datos que se requieren para activar la reaccin del sistema, a su vez elprocesamiento de estmulos puede provocar respuestas hacia el ambiente.La lista de eventos entonces ayuda a un diseo ms exacto y la manera en quedebe reaccionar el sistema al detectar un estimulo ocasionado por un eventoexterno 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

13

EVENTOS DEL AREA DE COMPRAS REQUERIMIETNOS ESTIMULOS RESPUESTAEl personal de compras elabora orden de compra

Elaborar orden de compra lista de compras OC

El personal de compras recepciona facturade proveedor Registrar compra factura de compra SR

El personal de compras solicita informe de compras

elaborar informe de compras

parmetros fechas, sucursal

Informe decompras

EVENTOS DEL AREA DE VENTAS REQUERIMIENTOS ESTIMULOS RESPUESTA

El cliente hace pedido de productos recepcionar pedidoPedido que se compone de datos de cliente, del producto precios, impuestos

presupuesto

El Vendedor realiza las ventas registrar venta Datos del cliente, productos, fecha de ventaFactura o

ticket

El jefe de ventas solicita informe de ventas elaborar informe de ventas

Parmetros de fechas, sucursal

Lista deventas

una compra a crdito? Es este el evento? Estas situaciones deben expresar lascuatro partes que se ha visto en el cuadro anterior y deben ser identificados comosigue:

o eventoo requerimientoo estimulo yo la respuesta que genera al ambiente.

De sta forma ser ms sencilla la tarea de descubrir eventos y respuestas paradeterminar el comportamiento de nuestro sistema para atender los requerimientosdel usuario.

4.2.1.6 Diagramar el modelo global del negocio

En la etapa inicial de un proyecto de desarrollo de software, antes de ladeterminacin de requerimientos, surge la importancia de la obtencin deinformacin sobre el ambiente del negocio, la cual nos proporcionara un panoramadetallado de la estructura y organizacin de la empresa, identificacin de usuariosparticipantes, el entorno tecnolgico en que se encuentra y sobre todo nos permiteconsiderar las referencias para el sistema de informacin en estudio, desde elpunto de vista de reglas, normativas, leyes o recomendaciones que se deben teneren 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 comportamientosque formarn parte de l, y cuales sern ejecutados por entidades externas.

Hay que identificar los actores en torno al sistema, considerando qu gruposrequieren ayuda del sistema para llevar a cabo su tarea; qu grupos sonnecesarios para ejecutar las funciones del sistema.

Hay que organizar a los actores similares en jerarquas degeneralizacin/especializacin.

Basados en los puntos mencionados ms arriba, pase primero a dibujar elrectngulo que representar al sistema, luego dibuje el actor en base su modelo derequerimientos y que se encuentra especificado en los atributos de origen y queson justamente quienes podran interactuar directamente con el sistema. Si loprimero que incluyo como entidad externa es al cliente, debe hacerse estapregunta: Interacta el cliente de forma directa con el sistema? Esto quiere decirque si el cliente se expone ante una estacin de trabajo (PC, tableta, telfono) enel 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 elmodelo del negocio. De otra forma no podr encontrar sentido a su diseo yestara 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 enconcordancia con la cantidad de requerimientos padres de cada diagrama derequerimiento que estuvo diseando, como nombre del CU se coloca el nombre del

14

Requerimiento padre; por ejemplo Requerimiento Gestionar compras, otroRequerimiento Gestionar ventas y sucesivamente para cada requerimiento padrede nuestro diagrama de requerimientos.

Luego comience por unir por medio de la asociacin a cada actor con el CU quecorresponde a su rea, esto lo puede corroborar nuevamente observando cadarequerimiento y su origen en el diagrama de requerimientos.

La siguiente figura es una vista del modelo global del negocio confeccionado conVisual Paradigm y pretende mostrar cuales macroprocesos que son ejecutados enla empresa que interactan con los actores comerciales.

Observe que los actores comerciales proveedor y cliente no aparecen en el diseode modelo caso de uso del negocio. Observe cada figura elptica del modelo denegocio 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 delsistema a construir.

Pasemos a detallar entonces los mdulos y que segn este diseo son:

Modulo de compras Modulo de ventas Modulo de informes. Modulo de cobranzas Modulo de inventario

15

4.2.2 Construir el Modelo de Comportamiento del sistemaEl modelo de comportamiento se representa por tres diagramas y que son comosigue:

- Diagrama de caso de uso por cada requerimiento- Diagrama de secuencias (por cada caso de uso)- Diagrama de colaboracin (por cada secuencia)

Los casos de uso muestran la visin funcional del programa. Son como una formade especificar el comportamiento del sistema. Representan una forma fcil deexpresar cmo algo o alguien que hace uso del sistema interactan con l, estopermite visualizar recursos que el sistema proporciona.

Los casos de uso son una forma visual de describir los distintos escenarios quesirven para mostrar momentos de interaccin de los actores con el sistema. Unactor podra ser un usuario, un administrador o un vendedor, y es representadopor la figura de una personita con los brazos extendidos de forma horizontal. Unade las ventajas de los casos de usos es que establecen un punto de referenciacomn entre el programador y el cliente o el jefe que encarga el desarrollo ypermiten documentar de manera sencilla y entendida por cualquiera ajeno a lainformtica.

Los casos de uso son fciles de construir, solo debemos representar, trabajadoresdel negocio y actores del negocio con forma de personita, las acciones delsistema con elipses, que deber contener un texto descriptivo del caso de uso,adems representar las interacciones entre los actores y los procesos del negociocon una lnea. Las acciones del sistema pueden estar relacionadas entre smediante las etiquetas:

>: una accin se especializa por medio de otra serie deacciones ms concretas. Cuando un caso de uso base tiene ciertos puntos(puntos de extensin) en los cuales, dependiendo de ciertos criterios, se va arealizar una interaccin adicional; el caso de uso que extiende describe uncomportamiento opcional del sistema (a diferencia de la relacin incluye quese da siempre que se realiza la interaccin descrita)>: incluye la funcionalidad de otro caso de uso o accin en unlugar especificado en dicho caso base. Se suele utilizar para encapsular uncomportamiento parcial comn a varios casos de uso.

En una relacin , un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relacin el actor que realiza el caso de uso base tambin realiza el caso de uso incluido.

16

En general utilizaremos cuando se presenta una variacin delcomportamiento normal, e cuando se repite un comportamientoen dos casos de uso y queremos evitar dicha repeticin.

Los casos de usos son una representacin visual de los requerimientosfuncionales

Para representar un CUN, puede referenciar por cada requerimiento del diagramade requerimiento o hacer un modelo de casos de uso por mdulos de subsistema,en ese caso debe vincular el requerimiento padre de los requerimientos deldiagrama de requerimientos a un modelo de caso de uso como se muestra en lasiguiente figura:

En la siguiente figura puede observarse que representar los casos de uso delsistema tiene una correspondencia con el diagrama de requerimientos diseadoanteriormente.

Esta secuencia correlativa, nos ayuda a identificar de una forma sencilla lasFuturas GUI de usuario que deberan de ser construidas por los desarrolladoresde sistema.

17

4.2.3 Diagramar los objetos de datos

La modelizacin orientada a objetos se centra en el desarrollo de una coleccin deobjetos discretos que incorporan tanto estructura de datos como comportamiento.Los objetos ejecutan o reciben operaciones que representan las interaccionesentre objetos. El centro de atencin es la construccin de definiciones de objetosque puedan organizarse en una jerarqua de clases con altos niveles deabstraccin. Los objetos pueden agruparse mediante agregaciones, y puedentener relaciones y atributos (propiedades) de forma similar al modelo entidadrelacin. De hecho, el modelo de datos (ERD) constituye la base de los conceptosorientados a objetos (entidades y atributos). Una entidad es un objeto quegeneraliza a otros objetos llamados atributos, en la implementacin de losdiseos conceptuales, una entidad, se convierte en una tabla dentro de una basede datos, y un atributo se convierte en un campo dentro de una tabla; la tabla es unobjeto que agrega campos.

Para nuestro ejemplo tomaremos rea de compras (proceso de elaborar la ordende compra), como se ve en la siguiente figura:

Mencionamos en este punto que el modelado de objetos de datos, es una tareaparalela al diseo de todo el proyecto, por lo que este modelo es importante tenerya para continuar con nuestro proyecto, cuyo paso siguiente es el de construir elmodelo 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 ymanejado con prudencia, de esta afirmacin surge la importancia de elaborar un

18

buen modelo de informacin, que sin lugar a duda es el que determinar el xito detodo proyecto.

El modelado de la informacin es el que forma la base del diseo de la base dedatos relacional, la cual esta formada por un serie de conceptos, procedimientos ytcnicas para el buen modelado de objetos que la conforman. El modelo entidad-relacin es el modelo conceptual ms utilizado para el diseo debases de datos, el cual esta est formado por un conjunto de conceptos quepermiten describir la realidad mediante un conjunto de representaciones grficas ylingsticas. Los elementos esenciales del modelo son las entidades acerca de lascuales el sistema necesita recordar hechos especficos, los atributos y lasrelaciones 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 nombreaparece en el interior. Un nombre de entidad slo puede aparecer una vez en elesquema conceptual.

Relacin Es una asociacin entre dos o ms entidades. Cada relacin tiene unnombre que describe su funcin. Las relaciones se representan grficamentemediante lneas rectas y su nombre define como se relacionan.

Las entidades que estn involucradas en una determinada relacin se denominanentidades participantes. La cardinalidad con la que una entidad participa en unarelacin, especifica el nmero mnimo y el nmero mximo de correspondencias enlas que puede tomar parte cada ocurrencia de dicha entidad. La participacin deuna entidad en una relacin es obligatoria (total) si la existencia de cada una desus ocurrencias requiere la existencia de, al menos, una ocurrencia de la otraentidad participante. Si no, la participacin es opcional (parcial). Las reglas quedefinen la cardinalidad de las relaciones son las reglas de negocio.

Atributos El tercer componente principal del modelo de informacin son losatributos, que representan a todos los elementos de datos del sistema. Cadahecho acerca de una entidad constituye un atributo.

Los atributos pueden ser simples o compuestos. Un atributo simple es un atributoque tiene un solo componente, que no se puede dividir en partes ms pequeasque tengan un significado propio. Un atributo compuesto es un atributo con varioscomponentes, cada uno con un significado por s mismo. Un grupo de atributos serepresenta mediante un atributo compuesto cuando tienen afinidad en cuanto a susignificado, o en cuanto a su uso.

19

En el siguiente ejemplo se presenta el DER de ventas.

4.2.5 El Diagrama de Secuencias

Un modelo de secuencias es un tipo de modelo de interaccin junto con eldiagrama de colaboracin, el diagrama se secuencias se expresa por medio de undiagrama de secuencias que muestra las interacciones entre los objetosorganizadas en una secuencia temporal. En particular muestra los objetosparticipantes en la interaccin y la secuencia de mensajes intercambiados.Representa una interaccin, un conjunto de comunicaciones entre objetosorganizadas visualmente por orden temporal. A diferencia de los diagramas decolaboracin, los diagramas de secuencia incluyen secuencias temporales pero noincluyen las relaciones entre objetos. Pueden existir de forma de descriptor(describiendo todos los posibles escenarios) y en forma de instancia (describiendoun escenario real). Dentro del conjunto de mensajes representados dispuestos en una secuenciatemporal, cada rol en la secuencia se muestra como una lnea de vida, es decir,una lnea vertical que representa el rol durante cierto plazo de tiempo, con lainteraccin completa. Los mensajes se muestran como flechas entre lneas devida. Un diagrama de secuencia puede mostrar un escenario, es decir, una historiaindividual de transaccin. Un uso de un diagrama de secuencia es mostrar lasecuencia 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

20

tiempo avanza hacia abajo dentro de la pgina (se pueden invertir los ejes si sedesea). Con frecuencia slo son importantes las secuencias de mensajes pero enaplicaciones de tiempo real el eje temporal puede ser una mtrica. La ordenacinhorizontal de los objetos no tiene ningn significado. Cada objeto representa una columna distinta, se pone un smbolo de objeto al finalde la flecha que representa el mensaje que ha creado el objeto; est situada en elpunto vertical que denota el instante en que se crea el objeto. Esta se conocecomo lnea de vide del objeto. Se pone una X grande en el punto en que deja deexistir el objeto o en el punto en que el objeto se destruye a s mismo. Para elperiodo durante el cual est activo el objeto, la lnea de vida se ampla para seruna lnea doble continua. Si el objeto se llama a s mismo, entonces se superponeotra copia de la doble lnea para mostrar la doble activacin. El orden relativo delos objetos no tiene significado an cuando resulta til organizarlos de modo quese minimice la distancia de las flechas.

Cada mensaje se representa mediante una flecha horizontal que va desde la lneade vida del objeto que envi el mensaje hasta la lnea de vida del objeto que harecibido el mensaje. Si un mensaje requiere un cierto tiempo para llegar a sudestino, entonces la flecha del mensaje se dibuja diagonalmente hacia abajo.Un diagrama de secuencia tambin se puede mostrar en forma de descriptor, en elcual los constituyentes son roles en lugar de objetos. Este diagrama muestra en elcaso general, no una sola ejecucin del mismo. Los diagramas del nivel dedescriptores se dibujan sin subrayados porque los smbolos denotan roles y noobjetos individuales.

Lnea de vida de un objeto (lifeline): La lnea de vida de un objetorepresenta la vida del objeto durante la interaccin. En un diagrama desecuencia un objeto se representa como una lnea vertical punteada con unrectngulo de encabezado y con rectngulos a travs de la lnea principal quedenotan la ejecucin de mtodos (activacin). El rectngulo de encabezadocontiene 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 seencuentra desarrollando alguna operacin, bien sea por s mismo o por mediode delegacin a alguno de sus atributos. Se denota como un rectngulodelgado sobre la lnea de vida del objeto.

Mensaje: El envo de mensajes entre objetos se denota mediante unalnea slida dirigida, desde el objeto que emite el mensaje hacia el objeto quelo ejecuta.

Tiempos de transicin: En un entorno de objetos concurrentes o dedemoras en la recepcin de mensajes, es til agregar nombres a los tiemposde salida y llegada de mensajes.

21

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

La lnea de vida para el actor vendedor comienza desde que se activa la interfazde usuario hasta que se obtiene la impresin de la factura de venta. Observe quelos diferentes objetos slo son usados o interactan un lapso de tiempo durante laejecucin del proceso de registrar la venta de productos.

4.2.6 El Diagrama de Despliegue

Es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza paramodelar el hardware utilizado en las implementaciones de sistemas y lasrelaciones entre sus componentes. Los elementos usados por este tipo dediagrama son nodos (representados como prisma), componentes (representadoscomo caja rectangular con dos protuberancias) y asociaciones.En el UML 2.0 los componentes ya no estn dentro de nodos. En cambio, puedehaber artefactos u otros nodos dentro de un nodo. Un nodo es como un elementofsico, que existe en tiempo de ejecucin y representa un recurso computacionalque generalmente tiene alguna memoria y, a menudo, capacidad deprocesamiento. Los nodos sirven para modelar la topologa del hardware sobre elque se ejecuta el sistema. Un nodo representa normalmente un procesador o undispositivo sobre el que se pueden desplegar los componentes. Un nodo debetener un nombre asignado que lo distinga del resto de nodos.

Este tipo de diagrama debemos tambin aadir que no van a existir actores pararelacionarse con los nodos (no es un diagrama de casos de uso) si no que lasrelaciones que pueda haber siempre sern entre los nodos y por ejemplo con unabase de datos.

La mayora de las veces el modelado de la vista de despliegue implica modelar latopologa del hardware sobre el que se ejecuta el sistema. Aunque UML no es un

22

lenguaje de especificacin hardware de propsito general, se ha diseado paramodelar muchos de los aspectos hardware de un sistema a un nivel suficientepara que un ingeniero software pueda especificar la plataforma sobre la que seejecuta el software del sistema.La siguiente figura muestra un ejemplo de un diagrama de despliegue con unavista de accesos de clientes desde Internet, servidores, tipo tecnologa deinterconectividad y las estaciones cliente.

23

5 Resumen

Los seres humanos somos conscientes de nuestras limitaciones, y por endetendemos a no poder contextualizar las cosas complejas tanto de nuestrasvidas como de nuestros trabajos; tal vez la mayora de las personas que sededican a la construccin de software no estn acostumbrados a modelar, sinembargo modelar es la actividad que nos ayuda a coprender o contextualizarlos sistemas complejos en su totalidad.Luego de definir los modelos que necesitamos, pasamos a hacer unrelevamiento de informacin de qu es lo que los usuarios necesitan que seautomatice o lo que esperan del nuevo sistema, este relevamiento puedevisualizarse con los diagramas de requerimientos, a su vez cada requerimientonos ayuda a identificar los casos de uso (cu). Cada caso de uso nos ayuda aidentificar cules sern las GUI (interface grfica de usuario) que senecesitarn para construir el sistema.

El comportamiento puede reflejarse en los diagramas de secuencia, aqudebemos recordar que cada CU tiene asociado un DS (Diagrama deSecuencia), a su vez un DS nos ayuda a identificar cules sern las tablas conlas que debemos trabajar durante el desarrollo de la GUI. Cada CU, posee un documento denominado CUS (Caso de Uso del Sistema)donde se detallan las especificaciones sobre las reglas de negocio que debenser atendidas o aplicadas por el sistema o ms puntualmente por cada GUI.

Esto nos lleva a la siguiente deduccin, cada requerimiento me ayuda aidentificar un caso de uso, cada caso de uso me ayuda a identificar cuales sonlos formularios o pginas que necesito para cubrir las necesidades deautomatizacin del usuario. Los formularios (form) son trminos deprogramacin de sistemas, las pginas web, tambin contienen form, cuandohablamos de sistemas web dinmicas que trabajan con bases de datos. El Anlisis y Diseo de Sistemas, debera de ser lo ms sencillo posible demanera a que pueda ser interpretado por cualquier profesional del ambiente desistemas de informacin. Por ello, lo simple siempre resultar ms prcticopara todos en la comprensin de los requerimientos que deban ser cubiertospara lograr la construccin del esperado sistema de gestin para los usuarios.

24

6 Bibliografa

6.1 Libros

BOCH, Grady, RUMBAUGH, James; JACOBSON, Ivar. El lenguajeUnificado de Modelado UML-2.0. 2006. Pearson Educacin. SONMERVILLE, Ian. Ingenieria del Software.2005. Pearson AddisonWesley. 7 EdicinSCHACH, Stephen. 2005. Anlisis y diseo orientado a objetos con UML yel 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 HallPRESSMAN, Roger. 2002. Ingeniera del software un enfoque prctico.Mxico. Mac Graw Hill. 5 Edicin.RUBLE, David. 1998. Anlisis y diseo prctico de sistemas para sistemascliente servidor con GUI. Mxico. Prentice Hall. YOURDON, Edgar. 1989. Anlisis Estructurado Moderno. Mxico. PrenticeHall.

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

6.3 Webgrafa

http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=15http://glbrtlmb.blogdiario.com/i2006-09/http://72.14.207.104/search?q=cache:DTGrHSDXIWUJ:atari.uniandes.edu.co/burbano/mecad_chttp://www.icesi.edu.co/esn/contenido_programas.jsp?id=icesi3educc22http://www.unmsm.edu.pe/Epg/maestrias/area_ingenieria/sistemas/ingenieria_software.htmhttp://directo.uniovi.es/catalogo/FichaAsignatura.ASP?asignatura=7803http://www.ctv.es/USERS/belmont/indexoo.htmhttp://www.tic.udc.es/~fbellas/teaching/adoo/http://www.inei.gob.pe/biblioineipub/bancopub/inf/lib5040/TECN08.htmhttp://www.programacion.com/articulo/inukisofthttp://www.monografias.com/trabajos12/docmento/docmento.shtmlhttp://www.programacion.com/java/articulo/joa_patrones1/http://www.programacion.com/java/articulo/joa_patrones1/#joa_patrones1_softwarehttp://www.visual-paradigm.com/product/vpuml/demos/http://office.microsoft.com/es-hn/visio/HP815502823082.aspxhttp://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=15http://www.altova.com/umodel.htmlhttp://www.moskitt.org/cas/openxava_que_es/http://glbrtlmb.blogdiario.com/i2006-09/

25