En este tema  hablaremos sobre SISTEMAS DE INFORMACION.
espero y sea de tu ayuda dicha información recopilada para todos ustedes

Introducción:

Un sistema de información es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio.

El equipo computacional: el hardware necesario para que el sistema de información pueda operar.

El recurso humano que interactúa con el Sistema de Información, el cual está formado por las personas que utilizan el sistema.

Un sistema de información realiza cuatro actividades básicas: entrada, almacenamiento, procesamiento y salida de información.

Entrada de Información: Es el proceso mediante el cual el Sistema de Información toma los datos que requiere para procesar la información. Las entradas pueden ser manuales o automáticas. Las manuales son aquellas que se proporcionan en forma directa por el usuario, mientras que las automáticas son datos o información que provienen o son tomados de otros sistemas o módulos. Esto último se denomina interfases automáticas.

Las unidades típicas de entrada de datos a las computadoras son las terminales, las cintas magnéticas, las unidades de diskette, los códigos de barras, los escáners, la voz, los monitores sensibles al tacto, el teclado y el mouse, entre otras.

Almacenamiento de información: El almacenamiento es una de las actividades o capacidades más importantes que tiene una computadora, ya que a través de esta propiedad el sistema puede recordar la información guardada en la sección o proceso anterior. Esta información suele ser almacenada en estructuras de información denominadas archivos. La unidad típica de almacenamiento son los discos magnéticos o discos duros, los discos flexibles o diskettes y los discos compactos (CD-ROM).

Procesamiento de Información: Es la capacidad del Sistema de Información para efectuar cálculos de acuerdo con una secuencia de operaciones preestablecida. Estos cálculos pueden efectuarse con datos introducidos recientemente en el sistema o bien con datos que están almacenados. Esta característica de los sistemas permite la transformación de datos fuente en información que puede ser utilizada para la toma de decisiones, lo que hace posible, entre otras cosas, que un tomador de decisiones genere una proyección financiera a partir de los datos que contiene un estado de resultados o un balance general de un año base.

Salida de Información: La salida es la capacidad de un Sistema de Información para sacar la información procesada o bien datos de entrada al exterior. Las unidades típicas de salida son las impresoras, terminales, diskettes, cintas magnéticas, la voz, los graficadores y los plotters, entre otros. Es importante aclarar que la salida de un Sistema de Información puede constituir la entrada a otro Sistema de Información o módulo. En este caso, también existe una interfase automática de salida. Por ejemplo, el Sistema de Control de Clientes tiene una interfase automática de salida con el Sistema de Contabilidad, ya que genera las pólizas contables de los movimientos procesales de los clientes.

A continuación se muestran las diferentes actividades que puede realizar un Sistema de Información de Control de Clientes:

Actividades que realiza un Sistema de Información:

Entradas:

• Datos generales del cliente: nombre, dirección, tipo de cliente, etc.
• Políticas de créditos: límite de crédito, plazo de pago, etc.
• Facturas (interfase automático).
• Pagos, depuraciones, etc.

Proceso:

• Cálculo de antigüedad de saldos.
• Cálculo de intereses moratorios.
• Cálculo del saldo de un cliente.

Almacenamiento:

• Movimientos del mes (pagos, depuraciones).
• Catálogo de clientes.
• Facturas.

Salidas:

• Reporte de pagos.
• Estados de cuenta.
• Pólizas contables (interfase automática)
• Consultas de saldos en pantalla de una terminal.
• Tipos y Usos de los Sistemas de Información
  
  
  
  Durante los próximos años, los Sistemas de Información cumplirán tres objetivos básicos dentro de las organizaciones:
  1. Automatización de procesos operativos.
  2. Proporcionar información que sirva de apoyo al proceso de toma de decisiones.
  3. 
     Lograr ventajas competitivas a través de su implantación y uso.
  Los Sistemas de Información que logran la automatización de procesos operativos dentro de una organización, son llamados frecuentemente Sistemas Transaccionales, ya que su función primordial consiste en procesar transacciones tales como pagos, cobros, pólizas, entradas, salidas, etc. Por otra parte, los Sistemas de Información que apoyan el proceso de toma de decisiones son los Sistemas de Soporte a la Toma de Decisiones, Sistemas para la Toma de Decisión de Grupo, Sistemas Expertos de Soporte a la Toma de Decisiones y Sistema de Información para Ejecutivos. El tercer tipo de sistema, de acuerdo con su uso u objetivos que cumplen, es el de los Sistemas Estratégicos, los cuales se desarrollan en las organizaciones con el fin de lograr ventajas competitivas, a través del uso de la tecnología de información.
  Los tipos y usos de los Sistemas de Información se muestran en la figura 1.3.
  
  A continuación se mencionan las principales características de estos tipos de Sistemas de Información.
  Sistemas Transaccionales. Sus principales características son:
  • A través de éstos suelen lograrse ahorros significativos de mano de obra, debido a que automatizan tareas operativas de la organización.
  • Con frecuencia son el primer tipo de Sistemas de Información que se implanta en las organizaciones. Se empieza apoyando las tareas a nivel operativo de la organización.
  • Son intensivos en entrada y salid de información; sus cálculos y procesos suelen ser simples y poco sofisticados.
  • Tienen la propiedad de ser recolectores de información, es decir, a través de estos sistemas se cargan las grandes bases de información para su explotación posterior.
  • Son fáciles de justificar ante la dirección general, ya que sus beneficios son visibles y palpables.
  Sistemas de Apoyo de las Decisiones. Las principales características de estos son:
  • Suelen introducirse después de haber implantado los Sistemas Transaccionales más relevantes de la empresa, ya que estos últimos constituyen su plataforma de información.
  • La información que generan sirve de apoyo a los mandos intermedios y a la alta administración en el proceso de toma de decisiones.
  • Suelen ser intensivos en cálculos y escasos en entradas y salidas de información. Así, por ejemplo, un modelo de planeación financiera requiere poca información de entrada, genera poca información como resultado, pero puede realizar muchos cálculos durante su proceso.
  • No suelen ahorrar mano de obra. Debido a ello, la justificación económica para el desarrollo de estos sistemas es difícil, ya que no se conocen los ingresos del proyecto de inversión.
  • Suelen ser Sistemas de Información interactivos y amigables, con altos estándares de diseño gráfico y visual, ya que están dirigidos al usuario final.
  • Apoyan la toma de decisiones que, por su misma naturaleza son repetitivos y de decisiones no estructuradas que no suelen repetirse. Por ejemplo, un Sistema de Compra de Materiales que indique cuándo debe hacerse un pedido al proveedor o un Sistema de Simulación de Negocios que apoye la decisión de introducir un nuevo producto al mercado.
  • Estos sistemas pueden ser desarrollados directamente por el usuario final sin la participación operativa de los analistas y programadores del área de informática.
  Este tipo de sistemas puede incluir la programación de la producción, compra de materiales, flujo de fondos, proyecciones financieras, modelos de simulación de negocios, modelos de inventarios, etc.
  Sistemas Estratégicos. Sus principales características son:
  • Su función primordial no es apoyar la automatización de procesos operativos ni proporcionar información para apoyar la toma de decisiones.
  • Suelen desarrollarse in house, es decir, dentro de la organización, por lo tanto no pueden adaptarse fácilmente a paquetes disponibles en el mercado.
  • Típicamente su forma de desarrollo es a base de incrementos y a través de su evolución dentro de la organización. Se inicia con un proceso o función en particular y a partir de ahí se van agregando nuevas funciones o procesos.
  • Su función es lograr ventajas que los competidores no posean, tales como ventajas en costos y servicios diferenciados con clientes y proveedores. En este contexto, los Sistema Estratégicos son creadores de barreras de entrada al negocio. Por ejemplo, el uso de cajeros automáticos en los bancos en un Sistema Estratégico, ya que brinda ventaja sobre un banco que no posee tal servicio. Si un banco nuevo decide abrir sus puerta al público, tendrá que dar este servicio para tener un nivel similar al de sus competidores.
  • Apoyan el proceso de innovación de productos y proceso dentro de la empresa debido a que buscan ventajas respecto a los competidores y una forma de hacerlo en innovando o creando productos y procesos.
  Un ejemplo de estos Sistemas de Información dentro de la empresa puede ser un sistema MRP (Manufacturing Resoure Planning) enfocado a reducir sustancialmente el desperdicio en el proceso productivo, o bien, un Centro de Información que proporcione todo tipo de información; como situación de créditos, embarques, tiempos de entrega, etc. En este contexto los ejemplos anteriores constituyen un Sistema de Información Estratégico si y sólo sí, apoyan o dan forma a la estructura competitiva de la empresa.
  Por último, es importante aclarar que algunos autores consideran un cuarto tipo de sistemas de información denominado Sistemas Personales de Información, el cual está enfocado a incrementar la productividad de sus usuarios.
  Evolución de los Sistemas de Información
  De la sección anterior se desprende la evolución que tienen los Sistemas de Información en las organizaciones. Con frecuencia se implantan en forma inicial los Sistemas Transaccionales y, posteriormente, se introducen los Sistemas de Apoyo a las Decisiones. Por último, se desarrollan los Sistemas Estratégicos que dan forma a la estructura competitiva de la empresa.
  En la década de los setenta, Richard Nolan, un conocido autor y profesor de la Escuela de Negocios de Harvard, desarrolló una teoría que impactó el proceso de planeación de los recursos y las actividades de la informática.
  Según Nolan, la función de la Informática en las organizaciones evoluciona a través de ciertas etapas de crecimiento, las cuales se explican a continuación:
  • Comienza con la adquisición de la primera computadora y normalmente se justifica por el ahorro de mano de obra y el exceso de papeles.
  • Las aplicaciones típicas que se implantan son los Sistemas Transaccionales tales como nóminas o contabilidad.
  • El pequeño Departamento de Sistemas depende en la mayoría de los casos del área de contabilidad.
  • El tipo de administración empleada es escaso y la función de los sistemas suele ser manejada por un administrador que no posee una preparación formal en el área de computación.
  • El personal que labora en este pequeño departamento consta a lo sumo de un operador y/o un programador. Este último podrá estar bajo el régimen de honorarios, o bien, puede recibirse el soporte de algún fabricante local de programas de aplicación.
  • En esta etapa es importante estar consciente de la resistencia al cambio del personal y usuario (ciberfobia) que están involucrados en los primeros sistemas que se desarrollan, ya que estos sistemas son importantes en el ahorro de mano de obra.
  • Esta etapa termina con la implantación exitosa del primer Sistema de Información. Cabe recalcar que algunas organizaciones pueden vivir varias etapas de inicio en las que la resistencia al cambio por parte de los primeros usuarios involucrados aborta el intento de introducir la computador a la empresa.
  Etapa de contagio o expansión. Los aspectos sobresalientes que permiten diagnosticar rápido que una empresa se encuentra en esta etapa son:
  • Se inicia con la implantación exitosa del primer Sistema de Información en la organización. Como consecuencia de lo anterior, el primer ejecutivo usuario se transforma en el paradigma o persona que se habrá que imitar.
  • Las aplicaciones que con frecuencia se implantan en esta etapa son el resto de los Sistemas Transaccionales no desarrollados en la etapa de inicio, tales como facturación, inventarios, control de pedidos de clientes y proveedores, cheques, etc.
  • El pequeño departamento es promovido a una categoría superior, donde depende de la Gerencia Administrativa o Contraloría.
  • El tipo de administración empleado está orientado hacia la venta de aplicaciones a todos los usuarios de la organización; en este punto suele contratarse a un especialista de la función con preparación académica en el área de sistemas.
  • Se inicia la contratación de personal especializado y nacen puestos tales como analista de sistemas, analista-programador, programador de sistemas, jefe de desarrollo, jefe de soporte técnico, etc.
  • Las aplicaciones desarrolladas carecen de interfases automáticas entre ellas, de tal forma que las salidas que produce un sistema se tienen que alimentar en forma manual a otro sistema, con la consecuente irritación de los usuarios.
  • Los gastos por concepto de sistemas empiezan a crecer en forma importante, lo que marca la pauta para iniciar la racionalización en el uso de los recursos computacionales dentro de la empresa. Este problema y el inicio de su solución marcan el paso a la siguiente etapa.
  Etapa de control o formalización. Para identificar a una empresa que transita por esta etapa es necesario considerar los siguientes elementos:
  • Esta etapa de evolución de la Informática dentro de las empresas se inicia con la necesidad de controlar el uso de los recursos computacionales a través de las técnicas de presupuestación base cero (partiendo de que no se tienen nada) y la implantación de sistemas de cargos a usuarios (por el servicio que se presta).
  • Las aplicaciones están orientadas a facilitar el control de las operaciones del negocio para hacerlas más eficaces, tales como sistemas para control de flujo de fondos, control de órdenes de compra a proveedores, control de inventarios, control y manejo de proyectos, etc.
  • El departamento de sistemas de la empresa suele ubicarse en una posición gerencial, dependiendo del organigrama de la Dirección de Administración o Finanzas.
  • El tipo de administración empleado dentro del área de Informática se orienta al control administrativo y a la justificación económica de las aplicaciones a desarrollar. Nace la necesidad de establecer criterios para las prioridades en el desarrollo de nuevas aplicaciones. La cartera de aplicaciones pendientes por desarrollar empieza a crecer.
  • En esta etapa se inician el desarrollo y la implantación de estándares de trabajo dentro del departamento, tales como: estándares de documentación, control de proyectos, desarrollo y diseño de sistemas, auditoría de sistemas y programación.
  • Se integra a la organización del departamento de sistemas, personal con habilidades administrativas y preparado técnicamente.
  • Se inicia el desarrollo de interfases automáticas entre los diferentes sistemas.
  Etapa de integración. Las características de esta etapa son las siguientes:
  • La integración de los datos y de los sistemas surge como un resultado directo de la centralización del departamento de sistemas bajo una sola estructura administrativa.
  • Las nuevas tecnologías relacionadas con base de datos, sistemas administradores de bases de datos y lenguajes de cuarta generación, hicieron posible la integración.
  • En esta etapa surge la primera hoja electrónica de cálculo comercial y los usuarios inician haciendo sus propias aplicaciones. Esta herramienta ayudó mucho a que los usuarios hicieran su propio trabajo y no tuvieran que esperar a que sus propuestas de sistemas fueran cumplidas.
  • El costo del equipo y del software disminuyó por lo cual estuvo al alcance de más usuarios.
  • En forma paralela a los cambios tecnológicos, cambió el rol del usuario y del departamento de Sistemas de Información. El departamento de sistemas evolucionó hacia una estructura descentralizada, permitiendo al usuario utilizar herramientas para el desarrollo de sistemas.
  • Los usuarios y el departamento de sistema iniciaron el desarrollo de nuevos sistemas, reemplazando los sistemas antiguos, en beneficio de la organización.
  Etapa de administración de datos. Entre las características que destacan en esta etapa están las siguientes:
  • El departamento de Sistemas de Información reconoce que la información es un recurso muy valioso que debe estar accesible para todos los usuarios.
  • Para poder cumplir con lo anterior resulta necesario administrar los datos en forma apropiada, es decir, almacenarlos y mantenerlos en forma adecuada para que los usuarios puedan utilizar y compartir este recurso.
  • El usuario de la información adquiere la responsabilidad de la integridad de la misma y debe manejar niveles de acceso diferentes.
  Etapa de madurez. Entre los aspectos sobresalientes que indican que una empresa se encuentra en esta etapa, se incluyen los siguientes:
  
  
• Al llegar a esta etapa, la Informática dentro de la organización se encuentra definida como una función básica y se ubica en los primeros niveles del organigrama (dirección).
• Los sistemas que se desarrollan son Sistemas de Manufactura Integrados por Computadora, Sistemas Basados en el Conocimiento y Sistemas Expertos, Sistemas de Soporte a las Decisiones, Sistemas Estratégicos y, en general, aplicaciones que proporcionan información para las decisiones de alta administración y aplicaciones de carácter estratégico.
• En esta etapa se tienen las aplicaciones desarrolladas en la tecnología de base de datos y se logra la integración de redes de comunicaciones con terminales en lugares remotos, a través del uso de recursos computacionales.

Hola, en este espacio vamos a  hablar sobre UML !

Aquí  encontraras todo tipo de información necesaria para como hacer tus diagramas uml y la importancia que tiene cada una de ella  en nuestro entorno y para nuestra vida cotidiana.. 

A continuación daremos paso a paso toda la información necesaria que te sera útil.. :

Agregación, Composición, Interfaces y Realización

Agregaciones

En ocasiones una clase consta de otras clases. Éste es un tipo especial de relación conocida como agregación o acumulación. Los componentes y la clase que constituyen son una asociación que conforman un todo. En la hora 2, "Orientación a objetos", mencioné que su computadora es un conjunto de elementos que consta de gabinete, teclado, ratón, monitor, unidad de CD-ROM, una o varias unidades de disco duro, módem, unidad de disquete, impresora y, posiblemente, altavoces. Además de las unidades de disco, el gabinete contiene la memoria RAM, una tarjeta de vídeo y una tarjeta de sonido (tal vez algunos otros elementos).

Puede representar una agregación como una jerarquía dentro de la clase completa (por ejemplo el sistema computacional) en la parte superior, y los componentes por debajo de ella. Una línea conectará el todo con un componente mediante un rombo sin relleno que se colocará en la línea más cercana al todo. La siguiente figura le muestra el sistema de cómputo como una agregación.

Una asociación por agregación se representa por una línea entre el componente y el todo con un rombo sin relleno que conforma al todo.

Aunque este ejemplo le muestra cada componente correspondiente a un todo, en una agregación éste no será necesariamente el caso. Por ejemplo: en un sistema casero de entretenimiento, un control remoto podría ser un componente de una televisión, aunque también podría ser un componente de una reproductora de casetes de vídeo.

Restricciones en las agregaciones

En ocasiones el conjunto de componentes posibles en una agregación se establece dentro de una relación O. En ciertos restaurantes, una comida consta de sopa o ensalada, el plato fuerte y el postre. Para modelar esto, utilizaría una restricción: la palabra O dentro de llaves con una línea discontinua que conecte las dos líneas que conforman al todo, como lo muestra la siguiente figura.

Puede establecer una restricción a una agregación para mostrar que un componente u otro es parte del todo.

Composiciones

Una composición es un tipo muy representativo de una agregación. Cada componente dentro de una composición puede pertenecer tan sólo a un todo. Los componentes de una mesa de café (la superficie de la mesa y las patas) establecen una composición. El símbolo de una composición es el mismo que el de una agregación, excepto que el rombo esta relleno (vea la siguiente figura).

En una composición, cada componente pertenece solamente a un todo. Un rombo relleno representa esta relación.

Contextos

Cuando modele un sistema podrían producirse, con frecuencia, agrupamientos de clases, como agregaciones o composiciones. En tal caso, deberá enfocar su atención en un agrupamiento o en otro, y el diagrama de contexto le proporciona la característica de modelaje que requiere para tal fin. Las composiciones figuran en gran medida dentro de los diagramas de contexto. Un diagrama de contexto es como un mapa detallado de alguna sección de un mapa de mayores dimensiones. Pueden ser necesarias varias secciones para capturar toda la información detallada.

He aquí un ejemplo: suponga que está creando un modelo de una camisa y la forma en que se podría combinar con algún atuendo y un guardarropa. Un tipo de diagrama de contexto (vea la siguiente figura) le mostrará la camisa como un gran rectángulo de clase, con un diagrama anidado en el interior, el cual le muestra cómo los componentes de la camisa están relacionados entre sí. Este es un diagrama de contexto de composición (dado que la sola camisa reúne a cada componente se le denomina de composición).

Un diagrama de contexto de composición le muestra los componentes de una clase como un diagrama anidado dentro de un enorme rectángulo de clase.

El diagrama de contexto de composición enfoca la atención en la camisa y sus componentes. Para mostrar la camisa en el contexto del guardarropa y de algún atuendo, tendrá que ampliar su ámbito. Un diagrama de contexto del sistema lo hará por usted. Podrá mostrar la forma en que la clase Camisa se conecta con las clases Guardarropa y Atuendo, como se ve en la siguiente figura.

Un diagrama de contexto del sistema le muestra los componentes de una clase y la forma en que la clase se relaciona con las otras que hay en el sistema.

Podrá ver de cerca alguna otra clase y presentar sus detalles en algún otro diagrama de contexto.

Interfaces y realizaciones UML 

A las clases abstractas puras, es decir, a las clases que no contienen ninguna implementación, se les llama interfaces. En UML una interfaz es una colección de operaciones que sirven para especificar los servicios de una clase o un componente. Una interfaz sólo contiene las cabeceras de las operaciones, no su implementación. (Una interfaz de UML se corresponde con una clase virtual pura de C++ y con una “interface” de Java). Gráficamente una interfaz se puede representar de forma expandida como una clase estereotipada con la etiqueta <> o, en su forma abreviada, con una figura en forma de piruleta. En los diagramas de clases se suele utilizar la forma expandida para representar las interfaces. La forma abreviada generalmente se usa en los diagramas de componentes. Hay dos relaciones que pueden existir entre una clase y una interfaz: la dependencia y la realización. La dependencia entre una clase y una interfaz tiene el mismo significado y representación que entre dos clases, indica que la clase usa la interfaz.  Para que una interfaz se pueda usar hace falta que otra clase implemente las operaciones que la interfaz especifica. A esta relación entre la interfaz y la clase que la implementa se le llama realización. La realización indica que la clase implementa todas las operaciones de la interfaz. Gráficamente la realización se representa como una generalización con la línea discontinua.

Visibilidad

El concepto de visibilidad está muy relacionado con las interfaces y la realización. La visibilidad se aplica a atributos u operaciones, y establece la proporción en que otras clases podrán utilizar los atributos y operaciones de una clase dada (o en operaciones de una interfaz). Existen mes niveles de visibilidad: Nivel público. en el cual la funcionalidad se extiende a otras clases. En el nivel protegido la funcionalidad se otorga sólo a las clases que se heredan de la clase original. En el nivel privado sólo la clase original puede utilizar el atributo u operación. En una televisión, modificarVolumen() y cambiarCanal() son operaciones públicas, en tanto que dibujarImagenEnPantalla() es privada. En un automóvil, acelerar() y frenar() son operaciones públicas, pero actualizarKilometraje() o actualizarMillaje() es protegida. 
El nivel publico se representa con un signo de suma (+), el protegiso con un numeral (#) y el nivel privado con un guion (-).

Uso de Relaciones UML II

1. Cuando la multiplicidad de una asociación es de uno a muchos, con frecuencia se presenta un reto muy particular: la búsqueda. Cuando un objeto de una clase tiene que seleccionar un objeto particular de otro tipo para cumplir con un papel en la asociación, la primera clase deberá atenerse a un atributo en particular para localizar al objeto adecuado.Por ejemplo, cuando usted realiza una reservación en un hotel, el hotel le asigna un número de confirmación. Si usted quiere hacer preguntas respecto a la reservación, deberá proporcionar el número de confirmación.
   
   

   

   Un calificador en una asociación resuelve el problema de la busqueda.

   Asociaciones Reflexivas

   En ocasiones, una clase es una asociación consigo misma. Esto puede ocurrir cuando una clase tiene objetos que pueden jugar diversos papeles. Un OcupanteDeAutomovil puede ser un Conductor o un Pasajero. En el papel del conductor, el OcupanteDeAutomovil puede llevar ninguno o más OcupanteDeAutomovil, quienes jugarán el papel de pasajeros.
   
   En una asociación reflexiva, trazará la linea de la clase hacia si misma y podrá incluir los papeles , nombre de la asociación y su dirección , así como su multiplicidad 
   
   
   
   

   
   Herencia y Generalización

   
   

   Herencia es el mecanismo por el cual  entidades más específicas (de subclases) incorporan atributos y relaciones definidos para entidades más generales (de superclase). 

   
   

   En la generalización, una clase secundaria (hija) es sustituible por una clase principal (madre). Es decir, donde quiera que se haga referencia a la clase madre, también se hace referencia a la clase hija. Sin embargo, en el caso contrario no es aplicable.

   

   Una jerarquia de herencia en el reino animal.

   Clases abstractas

   Son clases que no proveen objetos a nuestro sistema, aunque estas clases se suelen utilizar como clases principales ya que de estas se derivan las clases que proveen objetos a nuestro sistema.

   
   Dependencias 

   En otro tipo de relación, una clase utiliza a otra. A esto se le llama dependecia. El uso más común de una dependencia es mostrar que la firma de la operación de una clase utiliza a otra clase.

   
   

   
   

   
   

2. Asociaciones

   Cuando las clases se conectan entre sí de forma conceptual, esta conexión se conoce como asociación. Por ejemplo la asociación de un jugador y un equipo. Podra caracterizar tal asociación con la frase: "Un jugador participa en un equipo". UML representa esa asociación con una línea que conecta ambas clases, con el nombre de la asociación ("participa en") justo sobre la linea y la dirección de la relación con un triángulo relleno que apunta en a dirección apropiada.

   Dentro de las asociaciónes puede dar más detalles de la relación si así lo desea como agregar en papel que juega cada clase en la relación e inclusive varias clases se pueden relacion entre sí.

   

   Pueden asociarse diversas clases con una en particular.

   
   

   
   

   
   

   
   

   

   Una asociación entre un jugador y un equipo
   con su respectivos roles.

   
   
   
   
   
   
   
   

   Restricciones en las asociaciones 

   En ocaciones una asociación entre dos clases debe seguir cierta regla. Ésta se indica al establecer una restricción junto a la línea de asociación. Por ejemplo: un Cajero atiende a un Cliente, pero cada Cliente es atendido en el orden en que se encuentre en la formación. 

   

   Otro tipo de restricción es la relación O (distinguida como {Or}) en una línea discontinua que conecte a dos líneas de asociación.Por ejemplo: un estudiante de educación media superior que elegirá entre un curso académico o uno comercial.

   

   Clases de asociación 

   Una asociación, al igual que una clase, puede contener atributos y operaciones. De hecho, cuando éste sea el caso, usted tendrá una clase de asociación. Puede concebir a una clase de asociación de la misma forma en que lo haría con una clase estándar, y utilizará una línea discontinua para conectarla a la línea de asociación. Una clase de asociación puede tener asociaciones con otras clases. El siguiente muestra una clase de asociación para la asociación “Participa en” entre un jugador y un equipo. La clase de asociación, Contrato, se asocia con la clase DirectorGeneral.

   
   

   

   Vinculos

   Así como un objeto es una instancia de una clase, una asociación también cuenta con instancias. Si podemos imaginar a un jugador específico que juega para un equipo específico, la relación “Participa en” se conocerá como vínculo, y usted lo representará como una línea que conecta a dos objetos. Tal como tuvo que subrayar el nombre de un objeto, deberá subrayar el nombre de un vínculo.
   
   

   

   Un vínculo es la instancia de una asociación.

   Multiplicidad 

   La multiplicidad señala la cantidad de objetos de una clase que pueden relacionarse con un objeto de una clase asociada.

   

   Ejemplos de multiplicidad representadas por UML

UML Aplicado a la Orientacion de Objetos

Uso de la orientación a objetos

Concepción de una clase

El nombre de la clase es, por convención, una palabra con la primera letra en mayúscula y normalmente se coloca en la parte superior del rectángulo. Si el nombre de su clase consta de dos palabras, se unen y cada una inicia con mayúscula.

Atributos

Un atributo es una propiedad o característica de una clase y descibe un rango de valores que la podrá contener en los objetos de la clase. Una clase podrá contener varios o ningún atributo.Si el atributo consta de una palabra se escribe en minúsculas y si el nombre contiene más de una palabra, cada palabra será unida a la anterio y comenzará con una letra may´puscula, a excepción de la primer palabra que comenzará en minúscula.

Operaciones 

Una operación es algo que la clase puede realizar, o que usted (u otra clase) pueden hacer a una clase. De la misma manera que el nombre de un atributo, el nombre de una operación se escribe en minísculas si consta de una sola palabra. Si el nombre constara de más de una palabra, se unen y inicie todas con mayúscula exceptuando la primera.

Responsabilidades y restricciones

El símbolo de clase le permite establecer otro tipo de información de sí misma. En un área bajo la lista de operaciones, podrá mostrar la responsabilidad de la clase. La responsabilidad es una descripción de lo que hará la clase, es decir, lo que sus atributos y operaciones intentan realizar en conjunto. Una lavadora, por ejemplo, tiene la responsabilidad de recibir ropa sucia y dar por resultado ropa limpia.

La idea es incluir información sufiente para describir una clase de forma inequívoca.

Una manera más formal es agregar una restricción, un texto libre bordeado por llaves; este texto especifica una o varias reglas que sigue la clase.

                                                       

Notas adjuntas

Por encima y debajo de los atributos , operaciones , responsabilidades y restricciones, se puede agregar mayor infromación a una clase en la figura de notas adjuntas.

UML Orientación a Objetos (Terminos)

Un objeto es la instancia de una clase (o categoría). Usted y yo, por ejemplo, somos instancias de la clase Persona. Un objeto cuenta con una estructura, es decir atributos (propiedades) y acciones. Las acciones son todas las actividades que el objeto es capaz de realizar. Los atributos y acciones, en conjunto, se conocen como características o rasgos.

Abstracción.- La abstracción se refiere a quitar las propiedades y acciones de un objeto para dejar sólo aquellas que sean necesarias.

Herencia.- Como instancia de una clase, un objeto tiene todas las características de la clase de la
que proviene. A esto se le conoce como herencia.

Polimorfismo.- En ocasiones una operación tiene el mismo nombre en diferentes clases. Por ejemplo, podrá abrir una puerta, un periódico, un regalo o una cuenta en el banco, en cada uno de estos casos, realizará una operación diferente.

Encapsulamiento o Encapsulación.-  La esencia del encapsulamiento es que cuando un objeto trae consigo su funcionalidad, esta última se oculta.

Envió de mensajes.- En un sistema los objetos trabajan en conjunto. Esto se logra mediante el envió de mensajes entre ellos. Un objeto envía a otro un mensaje para realizar una operación, ye el objeto receptor ejecutara la operación.

Asociaciones.- Los objetos también se relacionan entre sí. Por ejemplo, cuando enciende su TV, en términos de orientación de objetos, usted se asocia con su TV.

Tipos de relaciones en diagramas de casos de uso. UML.

Antes de nada diremos que los casos de uso fueron ideados por Jacobson a principios de los noventa y están inspirados en el concepto de escenario, el cual ya había sido utilizado para describir procesos. Los casos de uso especifican un comportamiento deseado del sistema, representan requisitos funcionales del mismo. Es importante resaltar que describen qué hace el sistema, no cómo lo hace. UML nos dice que: “Un caso de uso especifica un conjunto de secuencias de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor”. Los casos de uso nos sirven de base para elaborar los aspectos funcionales del pliego de condiciones y nos dan soporte en las etapas de modelado, desarrollo y validación de software.

Elementos de un caso de uso:

• Conjunto de secuencias de acciones, cada secuencia representa un posible comportamiento del sistema.
• Actores, se tratan de los roles que pueden jugar los agentes que interactúan con el sistema. Los roles son jugados por personas, dispositivos, u otros sistemas. Podríamos distinguir entre actores primarios, para los cuales el objetivo del caso de uso es esencial y actores secundarios, que interactúan con el caso de uso, pero cuyo objetivo no es esencial.
• Variantes, son versiones especializadas, un caso de uso que extiende a otro o un caso de uso que incluye a otro

Como veremos a continuación, en los diagramas de casos de uso se muestran: casos de uso (representados en forma de elipses), actores (en forma de personajes) y  relaciones (en forma de líneas y/o flechas). UML define cuatro tipos de relaciones en los diagramas de casos de uso:

• Comunicación: Relación (asociación) entre un actor y un caso de uso. El estereotipo de la relación de comunicación es: <<communicate>> aunque generalmente no se estipula ningún nombre, como podemos apreciar en el siguiente ejemplo de comunicación:

• Inclusión: Un caso de uso base incorpora explícitamente el comportamiento de otro en algún lugar de su secuencia. La relación de inclusión sirve para enriquecer un caso de uso con otro y compartir una funcionalidad común entre varios casos de uso, también puede utilizarse para estructurar un caso de uso describiendo sus subfunciones. El caso de uso incluido existe únicamente con ese propósito, ya que no responde a un objetivo de un actor.

Estas relaciones se representan mediante una flecha discontinua con el estereotipo <<include>>. Algunos casos de uso típicos de inclusión son: comprobar, verificar, buscar, validar, autentificar o login… En principio, no deberíamos abusar de este tipo de relación, para no hacer una descomposición funcional del sistema. A partir de UML 1.3 la relación <<include>> reemplazó al denominado <<uses>>.

Veamos un ejemplo de inclusión entre casos de uso:

• Extensión: Un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso en el lugar especificado indirectamente por este otro caso de uso. En el caso de uso base, la extensión se hace en una serie de puntos concretos y previstos en el momento del diseño, llamados puntos de extensión, los cuáles no son parte del flujo principal. La relación de extensión sirve para modelar: la parte opcional del sistema, un subflujo que sólo se ejecuta bajo ciertas condiciones o varios flujos que se pueden insertar en un punto determinado. Este tipo de relación produce confusión y no debería utilizarse en exceso. Conviene su uso sólo para insertar un nuevo comportamiento no previsto en un caso de uso existente. Estas relaciones se representan mediante una flecha discontinua con el estereotipo <<extend>>.

Veamos un ejemplo de extensión:

En este ejemplo usamos la relación de extensión entre los casos de uso Abrir acción de mejora y Resolver consulta. En este caso tendremos el punto de extensión “resolución retrasada” (en el caso de uso Resolver consulta) debido a que cuando haya pasado un tiempo estipulado por la organización (por ejemplo 3 días laborales) se abrirá una acción de mejora para dejar constancia del retraso y realizar posteriormente las acciones pertinentes, de ahí que digamos que el caso de uso Abrir acción de mejora es una subfunción de uso que puede extender al caso de uso Resolver consulta.

• Especialización y generalización de los casos de uso: Un caso de uso (subcaso) hereda el comportamiento y significado de otro, es decir las relaciones de comunicación, inclusión y extensión del super-caso de uso. En muchas ocasiones este super-caso de uso es abstracto y corresponde a un comportamiento parcial completado en el subcaso de uso. O dicho de otra manera, Los casos de uso “hijo” son una especialización del caso de uso “padre”. En la medida de lo posible debería evitarse puesto que produce cierta confusión en algunas ocasiones.

Veamos un ejemplo de generalización:

Como podemos ver en este último ejemplo también pueden existir vínculos de generalización o herencia entre actores. Los actores especializados (Abogado y Psicólogo) heredan los casos de uso del actor general (Profesional). La punta de flecha apunta al actor más general. Hay que reseñar que los actores especializados pueden tener otros casos de uso propios que no estarán disponibles para los demás actores. Este tipo de herencia entre actores si que se usa frecuentemente puesto que nos simplifica considerablemente el diagrama, nos ahorra un número importante de relaciones de comunicación entre actores y casos de uso y nos sirve para esclarecer visualmente la jerarquía entre actores del sistema.

Introducción al Lenguaje de Modelado Unificado

En los principios de la computación, los programadores no realizaban análisis muy profundos sobre el problema por resolver. Si acaso, garabateaban algo en una servilleta. Con frecuencia comenzaban a escribir el programa desde el principio, y el código necesario se escribía conforme se requería. Aunque anteriormente esto agregaba un aura de aventura y atrevimiento al proceso, en la actualidad es inapropiado en los negocios de alto riesgo.

Hoy en día, es necesario contar con un plan bien analizado. Un cliente tiene que comprender qué es lo que hará un equipo de desarrolladores; además tiene que ser capaz de señalar cambios si no se han captado claramente sus necesidades (o si cambia de opinión durante el proceso). A su vez, el desarrollo es un esfuerzo orientado a equipos, por lo que cada uno de sus miembros tiene que saber qué lugar toma su trabajo en la solución final.

Conforme aumenta la complejidad del mundo, los sistemas informáticos también deberán crecer en complejidad. En ellos se encuentran diversas piezas de hardware y software que se comunican a grandes distancias mediante una red, misma que está vinculada a bases de datos que, a su vez, contienen enormes cantidades de información. Si desea crear sistemas que lo involucren con este nuevo milenio ¿cómo manejará tanta complejidad?

La clave está en organizar el proceso de diseño de tal forma que los analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo del sistema comprendan y convengan con él. El UML proporciona tal organización.

Clasificación de los sistemas de información

Los sistemas de información, de manera general se pueden clasificar de tres formas según sus propósitos generales, en este sentido Peralta (2008) clasifica los sistemas de información en tres tipos fundamentales: (1) Sistemas transaccionales; (2) Sistemas de Soporte a la Toma de Decisiones, Sistemas para la Toma de Decisión de Grupo, Sistemas Expertos de Soporte a la Toma de Decisiones y Sistema de Información para Ejecutivos y (3) Sistemas estratégicos.

Sistemas transaccionales: Son Sistemas de Información que logran la automatización de procesos operativos dentro de una organización ya que su función primordial consiste en procesar transacciones tales como pagos, cobros, entradas, salidas, etc.

Sistemas de Soporte a la Toma de Decisiones, Sistemas para la Toma de Decisión de Grupo, Sistemas Expertos de Soporte a la Toma de Decisiones y Sistema de Información para Ejecutivos: Son Sistemas de Información que apoyan el proceso de toma de decisiones.

Sistemas Estratégicos: Son sistemas de información desarrollado en las organizaciones con el fin de lograr ventajas competitivas, a través del uso de la tecnología de información.

En dependencia del enfoque (tres en total), según reporta Peña (2006), los sistemas de información se pueden agrupar en una cierta clasificación, que brinda una idea esencial de su estructura y funcionamiento.

De acuerdo al elemento principal de proceso de la información, los sistemas de información pueden ser de tres tipos (Manual, Mecanizadas y Bath):

Manuales: cuando el hombre auxiliado por cierto equipo (máquinas de escribir, sumadoras, archivos, etc.) realiza las principales funciones de recopilación, registro, almacenamiento, cálculo y generación de información.

Mecanizadas: cuando cierta maquinaria realiza las principales funciones de procesamiento. Para los sistemas mecanizados que hacen uso de un computador, de acuerdo al tipo de interacción Hombre-Máquina, los sistemas de información pueden ser de dos tipos (Batch y en Línea]: Batch: el usuario proporciona los datos necesarios para la ejecución de un proceso y espera a que el computador termine la tarea para recibir los resultados; En Línea: existe un diálogo directo entre el usuario y el computador durante la ejecución de un proceso.

En cuanto a la organización física de los principales recursos de procesamiento de datos, los sistemas de información pueden ser de tipo:

Procesos centralizados: los recursos se encuentran ubicados en un área física determinada, por lo que su acceso se realiza en las misma instalación o desde lugares retirados, mediante líneas de comunicación de datos (telefónicas, microondas, satélite, etc.).

Proceso distribuido: los recursos se encuentran diseminados en diversos lugares de una zona territorial (ciudad, país, continente, etc.), por lo que el procesamiento se realiza en el propio lugar donde se originan los datos, existiendo la posibilidad de compartir información entre las diversas instalaciones, mediante la información de una “Red de Comunicación”..

INTRODUCCIÓN

                      

SISTEMA DE INFORMACIÓN

Nuestra sociedad se encuentra repleta de ejemplos de sistemas, tales como una máquina expendedora de café, una fábrica de productos manufacturados, un vehículo, un archivo para documentos, nuestra columna vertebral, etc. En el caso de las máquinas de café o bebidas, podemos analizar su funcionamiento para comprender mejor el concepto de sistema. Las monedas entran en el sistema, se compara su valor con el de la bebida seleccionada (objetivo del sistema) y si ambos valores son iguales, se expide la bebida.

En lo que respecta a los sistemas propiamente dichos hay un amplio consenso en cuanto a las características que deben tener y maneras de obrar, sin embargo no ocurre lo mismo con el concepto de sistema de información, del cual existen muchas definiciones, matices y escuelas. De todas formas, hablando en términos generales, podemos decir que un sistema de información es un conjunto de componentes que interaccionan entre sí para alcanzar un fin determinado, el cual es satisfacer las necesidades de información de dicha organización. Estos componentes pueden ser personas, datos, actividades o recursos materiales en general, los cuales procesan la información y la distribuyen de manera adecuada, buscando satisfacer las necesidades de la organización.

El objetivo primordial de un sistema de información es apoyar la toma de decisiones y controlar todo lo que en ella ocurre. Es importante señalar que existen dos tipos de sistema de información, los formales y los informales; los primeros utilizan como medio para llevarse a cabo estructuras sólidas como ordenadores, los segundos son más artesanales y usan medios más antiguos como el papel y el lápiz o el boca a boca.

El estudio de los sistemas de información surgió como una subdisciplina de las ciencias de la computación, con el objetivo de racionalizar la administración de la tecnología dentro de las organizaciones. El campo de estudio fue avanzando hasta pasar a ser parte de los estudios superiores dentro de la administración.

Desde un punto de vista empresarial, los sistemas de información pueden clasificarse de diversas formas. Existen, por ejemplo, sistemas de información gerencial (con el fin de resolver conflictos en empresas), sistemas de procesamiento de transacciones (que se encargan de manejar la información en el contexto de los intercambios comerciales), sistemas de información ejecutiva (para los directivos), sistemas de soporte a decisiones (analizan los distintos factores que hacen al negocio para decidir qué rumbo tomar), sistemas de automatización de oficinas (aplicaciones que ayudan en el trabajo administrativo) y sistemas expertos (que emulan el comportamiento de un especialista en un dominio concreto).

Según los autores Laudon y Laudon, profesores de Administración de Empresas, un sistema de información es un organismo que recolecta, procesa, almacena y distribuye información. Son indispensables para ayudar a los gerentes a mantener ordenada su compañía, a analizar todo lo que por ella pasa y a crear nuevos productos que coloquen en un buen lugar a la organización. Esta definición es una de las únicas que manifiesta la exigencia de que un sistema de información tenga componentes, aunque no especifica cuáles deban ser, posiblemente porque intenta englobar todas las posibles variantes de este concepto.

Cabe resaltar que el concepto de sistema de información suele ser utilizado como sinónimo de sistema de información informático, aunque no son lo mismo. Este último pertenece al campo de estudio de la tecnología de la información y puede formar parte de un sistema de información como recurso material. De todas formas, se dice que los sistemas de información tratan el desarrollo y la administración de la infraestructura tecnológica de una organización.

Casos de uso 

Considerando lo vital que es la gestión de requisitos y lo populares y útiles que son los casos de uso, nunca esta de más intentar una explicación de la técnica. Así que supongamos a un sistema pequeño que nos sirva de ejemplo: el teléfono de un hogar promedio. En dicho sistema, es de interés realizar llamadas de voz, o en otras palabras, el sistema tiene entre sus objetivos el de permitir al usuario del mismo comunicarse remotamente por medio de conexiones de voz.

Primero hemos de identificar al actor. En este caso es claramente el operador o usuario del teléfono. Tendremos en cuenta siempre que cada actor admite solamente cierto tipo de comunicación, impone sus propios requisitos sobre el sistema y exige una funcionalidad bajo ciertas condiciones. Pero para facilitar las cosas podemos simplemente indicarlo; quizás incluso recurriendo a un formalismo gráfico tomado de UML.

Fig. 1 – Ejemplo sencillo de un Actor

Ahora podemos identificar cual es la actividad precisa que queremos expresar en nuestro modelo. Digamos que estamos hablando de las llamadas de voz. Así que decimos:

“El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema indica el estado de error y de progreso en la conexión”.

El párrafo previo contiene la esencia de la situación de llamar por teléfono. A esta breve descripción le llamamos Caso de Uso por cuanto describe la interacción entre un actor -el usuario- y el sistema -el teléfono- indicando el requisito funcional que se exige al sistema.

Ahora bien, ciertamente es difícil referirse a este caso de uso diciendo cada vez el párrafo completo. Por esto le vamos a poner un nombre y un código de identificación. Digamos que le llamamos llamada de voz y que le colocamos el código CS-0100.

Además es claro que antes de hacer la llamada de voz es necesario que el teléfono este colgado así que podemos pensar en una precondición: el teléfono ha de estar colgado.

Armados con estos datos, podemos construir una tabla que resuma lo que tenemos en nuestro caso de uso:

Código: CS-0100.
Nombre: Llamada de voz.
Actores: Usuario.
Descripción: El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema indica el estado de error y de progreso en la conexión.
Precondición: El teléfono está colgado.
Postcondición: Ninguna.

Tabla 1 – Detalle de un sencillo Caso de Uso

Y aún más, podemos construir un atractivo diagrama con el fin de comunicar lo que hemos hecho con los clientes.

Fig. 2 – Sencillo ejemplo de un Modelo de Casos de Uso

Si bien en la representación gráfica no aparecen ni la precondición ni la descripción, si en cambio nos ha permitido indicar que el caso de uso (el ovalo) esta en el alcance del proyecto, al haberlo colocado dentro del rectángulo que define los límites del sistema. Por cierto, a dicho rectángulo lo llamamos sujeto en la especificación de UML.

Si en la revisión con los stakeholders identificamos que el caso de uso CS-0100 (el del ejemplo) merece ser detallado más cuidadosamente, entonces y solo entonces, podemos invertir algo de tiempo en la creación de los flujos de eventos. Observemos aquí, que la línea que une al actor con el caso de uso en el modelo gráfico quiere justamente hacer referencia al flujo de eventos.

Al flujo de eventos lo construimos como una tabla, indicando el número del paso el sujeto que realiza la acción y el paso de información que se hace. En aquellos pasos en que estemos hablando del sistema también vamos a indicar la operación o cálculo que este ha de efectuar con los datos. Por otra parte, el flujo de eventos lo vamos a iniciar, casi sin excepción, con el actor.

Flujo Principal:
Paso 1 – Usuario: Levanta el auricular.
Paso 2 – Sistema: Da el tono de marcado.
Paso 3 – Usuario: Indica el número de teléfono.
Paso 4 – Sistema: Realiza la conexión. Da tono de aviso en tanto se levanta el teléfono del lado contrario de la conexión. Permite la conversación al hacerse efectiva la conexión.
Paso 5 – Usuario: Conversa y al finalizar esta, tranca el teléfono.
Paso 6 – Sistema: Termina la conexión.

Tabla 2 – Flujo principal del Caso de Uso

Claro que no siempre las llamadas de voz se corresponden con este flujo de eventos. Sin embargo en un día feliz, cuando todo sale sin problemas, es de esta manera en que sucede. A lo que ocurre en todos los demás casos los vamos a tratar por medio de los flujos alternativos.

Los flujos alternativos pueden ser vistos como una forma de manejo de errores o bien, como un medio para especificar el comportamiento del sistema en caso de un error. Siendo así el caso, una forma de indicarlo es decir una aserción sobre un paso y la acción a tomar cuando esta se viola. Entre las posibles acciones podríamos tener: terminar el caso de uso, saltar a otro paso, presentar un reporte y continuar, etc.

Digamos entonces para efectos del ejemplo, que queremos especificar el comportamiento del sistema cuando el operador a indicado un número inexistente. El siguiente flujo alternativo trata esa situación:

Flujo alternativo: Número incorrecto
Paso 3 – El sistema: Presenta tono de error y el caso de uso termina.

Tabla 3 – Flujo alternativo del Caso de Uso

Aceptando que claramente es posible indicar tantos flujos alternativos como sean necesarios, además de especificar post condiciones y requisitos no-funcionales relacionados, tenemos entonces un caso de uso sencillo modelado quizás más completamente que lo que en realidad vale la pena. Pongamos todo junto:

Código: CS-0100.
Nombre: Llamada de voz.
Actores: Usuario.
Descripción: El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema indica el estado de error y de progreso en la conexión.
Precondición: El teléfono está colgado.
Postcondición: Ninguna.
Diagrama:

Flujo Principal:
Paso 1 – Usuario: Levanta el auricular.
Paso 2 – Sistema: Da el tono de marcado.
Paso 3 – Usuario: Indica el número de teléfono.
Paso 4 – Sistema: Realiza la conexión. Da tono de aviso en tanto se levanta el teléfono del lado contrario de la conexión. Permite la conversación al hacerse efectiva la conexión.
Paso 5 – Usuario: Conversa y al finalizar esta, tranca el teléfono.
Paso 6 – Sistema: Termina la conexión.

Flujo alternativo: Número incorrecto
Paso 3 – El sistema: Presenta tono de error y el caso de uso termina.

Tabla 4 – Caso de Uso completo

Un modelo de casos de uso es entonces una especificación de funcionalidad desde el punto de vista de la interacción del sistema con sus actores, apoyada en la representación gráfica para facilidad de comunicación pero constituida principalmente por texto.

De momento es todo. Mucho más se puede decir sobre los casos de uso: características avanzadas como la relación de extensión y la relación de inclusión; pero en casi todos los casos priva que mientras más sencillo mantengamos la especificación mejor, lo sencillo se entiende más, y la especificación de requisitos ha de entenderse bien. Que tan sofisticado lo hagamos no es ni de lejos, tan importante como la claridad

.

Diagrama de casos de flujo

En un diagrama de casos de uso no se muestran los casos de uso en detalle; solamente se resumen algunas de las relaciones entre los casos de uso, los actores y los sistemas. En concreto, en el diagrama no se muestra el orden en que se llevan a cabo los pasos para lograr los objetivos de cada caso de uso. Esos detalles pueden describirse en otros diagramas y documentos, que pueden vincularse a cada caso de uso. Para obtener más información, vea en este tema la sección Describir los casos de uso en detalle.

En las descripciones que se proporcionen de los casos de uso se usarán diversos términos relacionados con el dominio en el que trabaja el sistema, como Ventas, Menú, Cliente, etc. Es importante definir de manera clara estos términos y sus relaciones y, para ello, puede resultar útil un diagrama de clases de UML. Para obtener más información, vea Diagramas de clases de UML: Instrucciones.

Los casos de uso solamente se usan para los requisitos funcionales de un sistema. Otros requisitos, como las reglas de negocio, los requisitos de calidad del servicio y las restricciones de implementación, deben representarse por separado. La arquitectura y los detalles internos también deben describirse por separado. Para obtener más información sobre cómo definir los requisitos de usuario, vea Requisitos del usuario de modelos.

Los ejemplos que se usan en este tema están relacionados con un sitio web en el que los clientes pueden hacer pedidos de comida de restaurantes locales.

• Un actor (1) es una clase de persona, organización, dispositivo o componente de software externo que interactúa con el sistema. Los actores del ejemplo son cliente, restaurante, sensor de temperatura y titular de tarjeta de crédito.
• Un caso de uso (2) representa las acciones que uno o varios de los actores realizan a fin de conseguir un objetivo determinado. Los casos de uso del ejemplo son “Pedir menú”, “Actualizar menú” y “Procesar pago”.
  En un diagrama de casos de uso, casos de uso están asociados (3) a los actores que los realizan.
• El sistema (4) es aquello que se está desarrollando. Puede ser un pequeño componente de software cuyos actores simplemente son otros componentes de software; puede ser una aplicación completa; o puede ser un gran conjunto de aplicaciones distribuidas que se implementan en muchos equipos y dispositivos. Los subsistemas del ejemplo son “Sitio web de pedidos de menú”, “Empresa de entrega de menús” y “Versión 2 del sitio web”.
  En un diagrama de casos de uso pueden mostrarse los casos de uso que el sistema o sus subsistemas 
• El propósito principal de un diagrama de casos de uso es mostrar quién interactúa con el sistema y los principales objetivos que se logran con él.
  • Cree Actores que representen clases de personas, organizaciones, otros sistemas, software o dispositivos que interactúan con el sistema o subsistema.
    • Para obtener información sobre cómo se dibujan actores y otros elementos, vea Editar modelos y diagramas UML.
    • En cada uno de los conjuntos de objetivos, identifique los actores en función de su tipo o rol, aun cuando las entidades o personas físicas sean las mismas. Por ejemplo, “Restaurante” y “Cliente” son actores diferentes, aunque un empleado del restaurante podría ocasionalmente actuar como cliente.
  • Crear Casos de uso para cada uno de los objetivos que los actores pretendan conseguir con el sistema.
    • Asigne un nombre y una descripción para los casos de uso; use palabras que el actor pueda entender y no emplee términos relacionados con la implementación.
  • Use Asociaciones para vincular actores con casos de uso.

  Herencia entre actores

  
  Puede dibujar un vínculo de Generalización entre actores. El actor especializado (“Cliente de club” en el ejemplo) hereda los casos de uso del actor general (“Cliente” en el ejemplo). La punta de flecha debe apuntar al actor más general, como “Cliente”. Cuando cree el vínculo, apunte primero al actor más especializado.
  El actor especializado puede tener otros casos de uso propios que no están disponibles para el resto de actores.

  Precaución
  No genere bucles de relaciones de generalización en los que, como resultado, un actor se generalice a sí mismo. Los bucles pueden producir errores.

• 
  
• Los casos de uso incluidos se pueden compartir. En el ejemplo, los casos de uso “Pedir un menú” y “Suscribirse a revistas” incluyen “Pagar”.

  

  El objetivo y los escenarios de un caso de uso incluido deben tener sentido por sí mismos, de modo que puedan incluirse en casos de uso que se diseñen posteriormente.

  La descomposición de los casos de uso en elementos incluyentes y elementos incluidos resulta útil para lograr los siguientes objetivos:

  • Estructurar las descripciones del caso de uso en diferentes niveles de detalle.
  • Evitar repetir escenarios compartidos en distintos casos de uso.

  Definir el orden de los pasos detallados

  En el diagrama de casos de uso no aparece ninguna información sobre el orden en que deben realizarse los pasos más detallados, ni sobre si son siempre todos necesarios.

  Si desea especificar con claridad el orden de los pasos, puede usar un artefacto para asociar un documento independiente al caso de uso incluyente. En el ejemplo siguiente, se muestra un diagrama de actividades asociado al caso de uso “Pedir un menú”. Si lo desea, también puede usar un documento de texto que contenga una lista de pasos o una secuencia de capturas de pantalla. Para obtener más información, vea Describir los casos de uso en detalle.

  Tenga en cuenta estas convenciones de nomenclatura cuando use un diagrama de actividades:

  • El nombre de la actividad global es el mismo que el caso de uso incluyente.
  • Las acciones del diagrama de actividades tienen los mismos nombres que los casos de uso incluidos.

  Para obtener más información, vea Diagramas de actividades UML: Instrucciones.

  

  Compartir los objetivos con la relación de generalización

  Use una relación de generalización para mostrar que un caso de uso especializado es un mecanismo específico de lograr los objetivos expresados por otro caso de uso general. La punta de flecha abierta debe apuntar al caso de uso más general.

  

  Por ejemplo, “Pagar” es una generalización de “Pagar con tarjeta de crédito” y “Pagar en efectivo”.