Metodologa de Anlisis, Diseo y Especificacin de

Sistemas de Informacin
MADESI
Ing. Hilario Machuca Gonzlez
Asuncin Paraguay
2013
NDICE
Portada.........................................................................................................................I
ndice...........................................................................................................................II
1Introduccin........................................................................................................................................................................5
2Versin de este documento = 2.4........................................................................................................................................5
3Trminos y Conceptos........................................................................................................................................................5
4Secuencia metodolgica de construccin de modelos........................................................................................................7
4.1Crear el repositorio del proyecto.................................................................................................................................8
4.2Definir los modelos que se disearn..........................................................................................................................8
4.2.1El modelo de requerimientos................................................................................................................................9
4.2.1.1Identificar las reas de relevamiento...........................................................................................................10
4.2.1.2Documentar el relevamiento........................................................................................................................10
4.2.1.3Clasificar y agrupar el relevamiento............................................................................................................11
4.2.1.4Diagramar los requerimientos......................................................................................................................13
4.2.1.5Comprender de donde derivan los requerimientos......................................................................................13
4.2.1.6Diagramar el modelo global del negocio.....................................................................................................15
4.2.2Construir el Modelo de Comportamiento del sistema........................................................................................17
4.2.3 Diagramar los objetos de datos..........................................................................................................................19
4.2.4El modelo de informacin..................................................................................................................................20
4.2.5El Diagrama de Secuencias................................................................................................................................21
4.2.6El Diagrama de Despliegue................................................................................................................................23
5Resumen...........................................................................................................................................................................25
6Bibliografa.......................................................................................................................................................................25
6.1Libros.........................................................................................................................................................................25
6.2Revistas y manuales...................................................................................................................................................26
6.3Webgrafa...................................................................................................................................................................26
2
1 Introduccin
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 anlisis, 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]
El modelado es una tcnica propuesta por la Ingeniera del Software para el
diseo formal de las aplicaciones.
El Desarrollo de Software Dirigido por Modelos es una tcnica de construccin
del software que concede a los modelos la mxima importancia. Los modelos
ya no son simples medios para describir software, sino la pieza fundamental
para 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 el
proceso 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 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.
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.
UML son las siglas para Unified Modeling Language, que en castellano
quiere decir: Lenguaje de Modelado Unificado. Para comprender qu es el
UML, basta con analizar cada una de las palabras que lo componen, por
separado.
3
Lenguaje: el UML es, precisamente, un lenguaje. Lo que implica que
ste cuenta con una sintaxis y una semntica. Por lo tanto, al modelar
un concepto en UML, existen reglas sobre cmo deben agruparse los
elementos del lenguaje y el significado de esta agrupacin.
Modelado: el UML es visual. Mediante su sintaxis se modelan
distintos aspectos del mundo real, que permiten una mejor
interpretacin 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 la
fuerte intencin de que este permita un correcto modelado orientado a
objetos.
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.
Un modelo es una representacin abstracta de la realidad. En el caso del
software, la realidad que debemos representar la constituyen las
aplicaciones software que queremos construir. Los modelos por tanto, nos
sirven para representar cada una de las piezas que van a componer estas
aplicaciones y poder comunicar esta informacin a todo el equipo de
desarrollo.
Diagrama: una representacin grfica de una coleccin de elementos de
modelado, a menudo dibujada como un grafo con vrtices conectados por
arcos.
Metodologa: Conjunto de procedimientos, tcnicas, herramientas y un
soporte documental que ayuda a los desarrolladores a realizar nuevo
software.
Paquete: Los paquetes ofrecen un mecanismo general para la
organizacin de los modelos/subsistemas agrupando elementos de
modelado.
Actor es algo con comportamiento, como una persona (identificada por
un rol), un sistema informatizado u organizacin, y que realiza algn tipo de
interaccin con el sistema.. Se representa mediante una figura humana
dibujada con palotes. Los personajes o entidades que participarn en un
caso de uso se denominan actores.
Casos de Uso: un caso de uso modela el requisito funcional del nuevo
sistema 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 de
los pasos o las actividades que debern realizarse para llevar a cabo algn
proceso.
En el contexto de ingeniera del software, un caso de uso es una secuencia
de interacciones que se desarrollarn entre un sistema y sus actores en
respuesta a un evento que inicia un actor principal sobre el propio sistema.
Relacin: es una conexin entre los elementos del modelo, existen tres
tipos de relaciones en un los diagramas de caso de uso
Comunica (<<communicates>>): Relacin (asociacin) entre un actor y
un caso de uso que denota la participacin del actor en dicho caso de
uso.
Usa o <<include>> en la nueva versin de UML: Relacin de
dependencia entre dos casos de uso que denota la inclusin del
comportamiento de un escenario en otro. Por contra, utilizaremos una
relacin tipo <<uses>> cuando nos encontramos con una parte de
comportamiento similar en dos casos de uso y no queremos repetir la
descripcin de dicho comportamiento comn.
Extiende (<<extends>>): Relacin de dependencia entre dos casos de
uso que denota que un caso de uso es una especializacin de otro.
Por ejemplo, podra tenerse un caso de uso que extienda la forma de
pedir 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 <<extends>>
entre casos de uso cuando nos encontramos con un caso de uso
similar a otro pero que hace algo ms que ste (variante).
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
Nota: es un smbolo grfico para representar restricciones o comentarios
asociados a un elemento o a una coleccin de elementos en un diagrama.
Es un modo de indicar informacin de manera adecuada, es presentada
como un rectngulo con una esquina doblada junto a un comentario textual o
grfico.
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.
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.
5
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 y el
responsable 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 y
mantiene informacin digital, habitualmente bases de datos o archivos
informticos. Los datos almacenados en un repositorio pueden distribuirse a
travs de una red informtica, como Internet, o de un medio fsico, como un
disco compacto. Pueden ser de acceso pblico o estar protegidos y necesitar
de una autentificacin previa.
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.
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
7
Construimos modelos para comprender mejor el sistema que estamos
desarrollando
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 de
Explorador de Modelos, 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 requerimientos del cliente (la empresa). Para
especificar estos requisitos, debemos entender el domino del negocio, y para ello
nos basaremos en el relevamiento 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 basa 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
8
Tal vez el principal problema al que nos enfrentamos en el desarrollo de
sistemas grandes y complejos es el de la ingeniera de requerimientos. sta
trata de establecer lo que el sistema debe hacer, sus propiedades emergentes
deseadas y esenciales, y las restricciones en el funcionamiento del sistema y
los procesos de desarrollo del software. Por lo tanto puede considerar la i n g e
n i e r a de requerimientos como el proceso de comunicacin entre los clientes
y 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 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 all 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 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 negocio
de cada usuario en su rea. Observe.
Fecha nota Ambiente Usuario Departamento
15/09/2005
Confeccionar la factura a mano lleva mucho tiempo. Es importante
agilizar la confeccin de la factura de manera a ofrecer un servicio gil
al cliente.
Andres
a
Ventas
15/09/2005
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.
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
catalogo de productos con sus precios y el porcentaje mximo y
mnimo 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 procesos
son manuales, se deja la tarea de actualizar la ficha del cliente para
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.
Andres
a
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.
9
Otra forma de documentar el relevamiento es teniendo un cuestionario ordenado
de 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 negocio
puede procederse a una simplificacin con la confeccin del siguiente cuadro
donde nos preguntamos que es lo que el actor necesita del sistema. Fijmonos en
el siguiente cuadro:
O confeccionar un esquema con una lista de requerimientos como la que sigue:
1 rea 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
2 rea de ventas
2.1 Recepcionar pedido de productos del cliente
2.2 Registrar las ventas y actualizar ctas. de clientes
2.3 Registrar Devolucin de productos del cliente
2.4 Elaborar informe de ventas
3 rea de cobranzas
3.1 Realizar apertura/cierre de caja con resumen de movimiento de
caja
3.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 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
10
Trabajador/Actor Qu necesita del sistema?
Departament
o
Encargado de compras Elaborar una orden de compra Compras
Encargado de compras Registrar compras actualizando ctas. a pagar Compras
Jefe de compras Registrar nota de crdito del proveedor Compras
Vendedor Consultar precio de producto Ventas
Vendedor Recepcionar pedido de productos del cliente Ventas
Vendedor Registrar venta y actualizar ctas. de cliente Ventas
Vendedor 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 se
observa 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 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.
4.2.1.5 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.
El evento no debera de presentar palabras innecesarias, se describir de
forma especfica en una lnea como una oracin, tomemos por ejemplo el
siguiente evento:
El evento El vendedor vende productos se compone de:
11
Sujeto: Vendedor
Verbo: vende
Objeto: productos.
As el diseo refinado de nuestro diagrama de requerimientos quedara como
lo muestra la siguiente figura:
Observe de nuevo el diagrama de requerimientos y vea que en cada requerimiento
se ha identificado el origen(source), es decir el origen del requerimiento y en el
atributo text se ha especificado el evento que ocasiona un requerimiento.
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; partiendo del modelo de requerimientos podemos comenzar la
elaboracin de esta lista de eventos identificando los eventos que suceden en el
mundo real (ambiente) 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.
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 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
12
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.
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. 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
13
EVENTOS DEL AREA DE COMPRAS REQUERIMIETNOS ESTIMULOS RESPUESTA
El personal de compras elabora orden de
compra
Elaborar orden de
compra
lista de compras OC
El personal de compras recepciona factura
de proveedor
Registrar compra factura de compra SR
El personal de compras solicita informe de
compras
elaborar informe de
compras
parmetros fechas,
sucursal
Informe de
compras
EVENTOS DEL AREA DE VENTAS REQUERIMIENTOS ESTIMULOS RESPUESTA
El cliente hace pedido de productos recepcionar pedido
Pedido 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 venta
Factura o
ticket
El jefe de ventas solicita informe de ventas
elaborar informe de
ventas
Parmetros de fechas,
sucursal
Lista de
ventas
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 evento
o requerimiento
o estimulo y
o 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 para atender los requerimientos
del usuario.
4.2.1.6 Diagramar el modelo global 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 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 actores similares en jerarquas de
generalizacin/especializacin.
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 (PC, tableta, telfono) 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
14
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
Visual Paradigm y pretende mostrar cuales macroprocesos que son ejecutados en
la empresa que interactan con los actores comerciales.
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 informes.
Modulo de cobranzas
Modulo de inventario
15
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)
- Diagrama de colaboracin (por cada secuencia)
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 interactan con l, 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.
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 ms concretas. Cuando un caso de uso base tiene ciertos puntos
(puntos de extensin) en los cuales, dependiendo de ciertos criterios, se va a
realizar una interaccin adicional; el caso de uso que extiende describe un
comportamiento opcional del sistema (a diferencia de la relacin incluye que
se da siempre que se realiza la interaccin descrita)
<< Incluye >>: incluye la funcionalidad de otro caso de uso o accin en un
lugar especificado en dicho caso base. Se suele utilizar para encapsular un
comportamiento parcial comn a varios casos de uso.
En una relacin <<extends>>, un actor que lleve a cabo el caso de uso
base puede realizar o no sus extensiones. Mientras, en una relacin
<<include>> el actor que realiza el caso de uso base tambin realiza el
caso de uso incluido.
16
En general utilizaremos <<extends>> cuando se presenta una variacin del
comportamiento normal, e <<include>> cuando se repite un comportamiento
en dos casos de uso y queremos evitar dicha repeticin.
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 siguiente 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 desarrolladores
de sistema.
17
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
generaliza a otros objetos llamados 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.
Para nuestro ejemplo tomaremos rea de compras (proceso de elaborar la orden
de compra), 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
18
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 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.
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 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 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
20
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.
21
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:
La lnea de vida para el actor vendedor comienza desde que se activa la interfaz
de usuario hasta que se obtiene la impresin de la factura de venta. Observe que
los diferentes objetos slo son usados o interactan un lapso de tiempo durante la
ejecucin 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 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. Un nodo es como un elemento
fsico, que existe en tiempo de ejecucin y representa un recurso computacional
que generalmente tiene alguna memoria y, a menudo, capacidad de
procesamiento. Los nodos sirven para modelar la topologa del hardware sobre el
que se ejecuta el sistema. Un nodo representa normalmente un procesador o un
dispositivo sobre el que se pueden desplegar los componentes. Un nodo debe
tener un nombre asignado que lo distinga del resto de nodos.
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.
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
22
lenguaje de especificacin hardware de propsito general, se ha diseado para
modelar muchos de los 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, servidores, tipo tecnologa de
interconectividad y las estaciones cliente.
23
5 Resumen
Los seres humanos somos conscientes de nuestras limitaciones, y por ende
tendemos a no poder contextualizar las cosas complejas tanto de nuestras
vidas como de nuestros trabajos; tal vez la mayora de las personas que se
dedican a la construccin de software no estn acostumbrados a modelar, sin
embargo modelar es la actividad que nos ayuda a coprender o contextualizar
los sistemas complejos en su totalidad.
Luego de definir los modelos que necesitamos, pasamos a hacer un
relevamiento de informacin de qu es lo que los usuarios necesitan que se
automatice o lo que esperan del nuevo sistema, este relevamiento puede
visualizarse con los diagramas de requerimientos, a su vez cada requerimiento
nos ayuda a identificar los casos de uso (cu). Cada caso de uso nos ayuda a
identificar cules sern las GUI (interface grfica de usuario) que se
necesitarn para construir el sistema.
El comportamiento puede reflejarse en los diagramas de secuencia, aqu
debemos recordar que cada CU tiene asociado un DS (Diagrama de
Secuencia), a su vez un DS nos ayuda a identificar cules sern las tablas con
las 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 deben
ser atendidas o aplicadas por el sistema o ms puntualmente por cada GUI.
Esto nos lleva a la siguiente deduccin, cada requerimiento me ayuda a
identificar un caso de uso, cada caso de uso me ayuda a identificar cuales son
los formularios o pginas que necesito para cubrir las necesidades de
automatizacin del usuario. Los formularios (form) son trminos de
programacin de sistemas, las pginas web, tambin contienen form, cuando
hablamos de sistemas web dinmicas que trabajan con bases de datos.
El Anlisis y Diseo de Sistemas, debera de ser lo ms sencillo posible de
manera a que pueda ser interpretado por cualquier profesional del ambiente de
sistemas de informacin. Por ello, lo simple siempre resultar ms prctico
para todos en la comprensin de los requerimientos que deban ser cubiertos
para lograr la construccin del esperado sistema de gestin para los usuarios.
24
6 Bibliografa
6.1 Libros
BOCH, Grady, RUMBAUGH, James; JACOBSON, Ivar. El lenguaje
Unificado de Modelado UML-2.0. 2006. Pearson Educacin.
SONMERVILLE, Ian. Ingenieria del Software.2005. Pearson Addison
Wesley. 7 Edicin
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.
6.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.
6.3 Webgrafa
http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?articleId=15
http://glbrtlmb.blogdiario.com/i2006-09/
http://72.14.207.104/search?
q=cache:DTGrHSDXIWUJ:atari.uniandes.edu.co/burbano/mecad_c
http://www.icesi.edu.co/esn/contenido_programas.jsp?id=icesi3educc22
http://www.unmsm.edu.pe/Epg/maestrias/area_ingenieria/sistemas/ingenieria_software.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
http://www.moskitt.org/cas/openxava_que_es/
http://glbrtlmb.blogdiario.com/i2006-09/
25