TALLER DE SISTEMAS DE CASO DE UNOS DE EMPRESA





Taller de documentación de

Requisitos - Casos de uso

Empresa de transportes

1. Enunciado

Una empresa de transporte de mercancías por carretera tiene a su disposición

una flota propia de camiones y una serie de conductores particulares que tienen camión

propio. Cada camión tiene una fecha de alta como vehículo, una matrícula y un peso

máximo que puede transportar.

Cada conductor particular puede tener en su propiedad varios camiones, y tiene

su propia tarifa de precio por kilo y kilómetro. Los camiones correspondientes a la flota

de la empresa se asignan dinámicamente a los conductores que ésta tiene en nómina, y

tienen todos la misma tarifa que es estipulada por la propia empresa. Cada conductor,

por tanto, puede estar trabajando por cuenta propia o por cuenta ajena. De los mismos se

guardará además, nombre, apellidos, DNI, dirección, provincia, población y teléfono.

Todo conductor (particular o contratado) tiene un código único asignado

automáticamente por el sistema.

La empresa opera sobre un conjunto de ciudades las cuales están enlazadas por

carretera entre sí. El sistema de información conocerá el número de kilómetros entre

cada ciudad que está unida directamente por carretera y el tiempo medio que se tarda en

recorrer dicho tramo. Cada carretera se identifica a través de un número de carretera

único introducido por el operador. La empresa puede tener en estas ciudades un parque

donde almacenar remolques cargados o descargados. Cada remolque tiene una

matrícula, un peso y, caso de estar cargado, un peso de la carga.

A la empresa llegan pedidos. Un pedido consta de un número, una fecha, CIF del

cliente y varias líneas de pedido. Cada línea consiste en un remolque, el volumen de la

carga en kilos, la ciudad de partida, la ciudad de destino, la fecha de partida y la de

destino.

Existe una tabla de movimientos de caja con los campos fecha, importe, un

campo lógico que indique si es un pago o un ingreso, y un identificador del pedido si

fuera un ingreso, o del conductor pagado, si fuera un pago.

2. Diagramas de caso de uso



Figura 1. Diagrama de casos de uso del sistema







Figura 2. Diagrama de casos de uso del subsistema de camiones









Figura 3. Diagrama de casos de uso del subsistema de conductores









Figura 4. Diagrama de casos de uso del subsistema de gestión de caja








Figura 5. Diagrama de casos de uso del subsistema de gestión de remolques

Figura 6. Diagrama de casos de uso del subsistema de gestión de trayectos

Figura 7. Diagrama de casos de uso del subsistema de pedidos

Figura 8. Diagrama de casos de uso del subsistema de rutas



DEPENDENCIAS/RELACIONES DE CASOS DE USOS

DEPENDENCIAS/RELACIONES DE CASOS DE USOS

En muchas ocasiones el uso de características avanzadas de los casos de uso generan dudas en los equipos de desarrollo. La razón básica es que estos modelos deben ser claros antes que cualquier otra cosa, lo que lleva a evitar el uso de las relaciones de inclusión y extensión, entre otras características.

Sin embargo, por muy de acuerdo que podamos estar con el deseo de claridad y sencillez, existen situaciones en que hacer uso de una relación avanzada entre casos de uso mejora en lugar de reducir, la claridad del modelo de requisitos. De ahí por tanto que todo analista de requisitos debe comprender perfectamente el significado de estas relaciones. En el presente post abordamos la relación de extensión <<extend>>.

Técnicamente como para el glosario, la relación de extensión <<extend>> se define como:

Relación <<extend>> Un caso de uso extiende a otro cuando sin alterar a este, se incorpora su funcionalidad como parte integral del primero. Se denota con una relación que apunta del caso extendido al caso base y la conexión se hace o bien al principio del flujo de eventos principal del caso base o en alguno de los puntos de extensión que este haya definido.

La notación gráfica es la siguiente:





Fig. 1 - Relación de extensión <<extend>>





La relación del ejemplo significa que un caso de uso ya existente (el caso “A”) se aprovecha en la definición de un segundo caso (el caso “B”). Dado que la reutilización que requerimos agrega funcionalidad pero no altera al caso base, se ha optado por la relación de extensión. Dicha relación se ha denotado gráficamente con una flecha de dependencia desde el caso extendido (el caso “B”) al caso base (el caso “A”). La dependencia la hemos estereotipado con <<extend>> para que quede claro lo que pretendemos decir.

A nivel de los flujos de eventos, se podría decir que el flujo principal del caso base no se ve alterado, pero que en cambio, el flujo de eventos del caso extendido hace referencia al primero, de manera tal que no puede ser entendido en ausencia de los pasos del caso base.

A fin de contar con un ejemplo completo, consideremos un sistema de compras electrónico. Digamos que este sistema va a atender tanto a clientes finales como a clientes corporativos, permitiendo que adquieran productos en nuestra tienda en línea. La diferencia será que los clientes corporativos hacen compras masivas, quizás programando la entrega a lo largo de un periodo de tiempo de lo que compraron. Esta visión la podemos expresar en el siguiente diagrama:



Fig. 2 – Ejemplo de relación <<extend>> en un sistema
de tienda electrónica en Internet



Ahora si vamos al caso de uso base “Compra artículo (UC-0100)” podríamos tener la funcionalidad de escoger el artículo a comprar y el de pagar con tarjeta de crédito, por ejemplo. Esta funcionalidad esta disponible a los clientes finales, tal como se ve en el diagrama.

Por su parte, los clientes corporativos pueden escoger el artículo a comprar y el modo de pago: digamos tarjetas de crédito. Además el caso de uso captura también la funcionalidad de programar la entrega parcial de lo comprado a lo largo de un periodo de tiempo. Dado que gran parte del caso de uso “Compra masiva (UC-0200)” es idéntica a la encontrada en el caso del cliente final, optamos por reutilizar la especificación por vía de la relación de extensión.

Los criterios a aplicar para saber si la relación de extensión es aplicable son los siguientes:

1. Hay cuando menos un caso base y un caso extendido.
2. El caso base no se ve modificado por la existencia del caso extendido.
3. El caso base es un caso concreto atado a cuando menos un actor.
4. El caso extendido incorpora al caso base por completo.

La relación de extensión guarda relación con todos los restantes tipos de reutilización que están definidas para los casos de uso; en particular la relación es muy intima con la relación de inclusión <<include>> sin embargo la diferencia primordial entre <<extend>> e <<include>> es la modificación del caso base. Extensión no implica cambio, en tanto que la inclusión añade funcionalidad al caso base.

Otra relación, la herencia, es similar también a la extensión. En este caso la diferencia es que la herencia cambia o puede cambiar, la naturaleza de lo dicho en el caso base. Por ejemplo, podemos decir que aquello que fue llamado “artículo” en el caso base es ahora referido más detalladamente como “libro” o “juguete”. La herencia de casos de uso reutiliza al caso base sí, pero nos permite alterar la semántica de los detalles; algo que la relación de extensión (ni la de inclusión) pueden hacer.

Por tanto concluyamos: la relación de extensión permite reutilizar una especificación pero sin modificar al caso base.

UML

EJEMPLOS DE (UML)

 

EJEMPLO DE BANCO

EJEMPLO DE UNA BIBLIOTECA

PROCESOS DE NEGOCIOS

PROCESOS DE NEGOCIOS

Un proceso de negocio es un conjunto de tareas relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio definido. Cada proceso de negocio tiene sus entradas, funciones y salidas. Las entradas son requisitos que deben tenerse antes de que una función pueda ser aplicada. Cuando una función es aplicada a las entradas de un método, tendremos ciertas salidas resultantes.

Es una colección de actividades estructurales relacionadas que producen un valor para la organización, sus inversores o sus clientes. Es, por ejemplo, el proceso a través del que una organización ofrece sus servicios a sus clientes.

Un proceso de negocio puede ser parte de un proceso mayor que lo abarque o bien puede incluir otros procesos de negocio que deban ser incluidos en su función. En este contexto un proceso de negocio puede ser visto a varios niveles de granularidad. El enlace entre procesos de negocio y generación de valor lleva a algunos practicantes a ver los procesos de negocio como los flujos de trabajo que efectúan las tareas de una organización. Los procesos poseen las siguientes características:

-Pueden ser medidos y están orientados al rendimiento

-Tienen resultados específicos

-Entregan resultados a clientes o “stakeholders”

-Responden a alguna acción o evento específico

-Las actividades deben agregar valor a las entradas del proceso.

Definiciones

La norma internacional ISO-9001 define un proceso como “una actividad que utiliza recursos, y que se gestiona con el fin de permitir que los elementos de entrada se transformen en resultados” (ISO, 2000; pp. 6). Oscar Barros hace una importante distinción, al introducir el concepto de valor agregado en la definición de proceso, señalando que “un proceso es un conjunto de tareas lógicamente relacionadas que existen para conseguir un resultado bien definido dentro de un negocio; por lo tanto, toman una entrada y le agregan valor para producir una salida. Los procesos tienen entonces clientes que pueden ser internos o externos, los cuales reciben a la salida, lo que puede ser un producto físico o un servicio. Éstos establecen las condiciones de satisfacción o declaran que el producto o servicio es aceptable o no” (Barros, 1994; pp.56).

Reglas de negocio

 

Las Reglas del Negocio o Conjunto de Reglas de Negocio describe las políticas, normas, operaciones, definiciones y restricciones presentes en una organización y que son de vital importancia para alcanzar los objetivos misionales.

Ejemplos de reglas de negocio: "Un cliente al que facturamos más de 10.000 al año es un cliente de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a 3.000".
Las organizaciones funcionan siguiendo múltiples reglas de negocio, explícitas o tácitas, que están embebidas en procesos, aplicaciones informáticas, documentos, etc. Pueden residir en la cabeza de algunas personas o en el código fuente de programas informáticos.
En los últimos años se viene observando una tendencia a gestionar de forma sistemática y centralizada las reglas de negocio, de modo que sea fácil y sencillo consultarlas, entenderlas, utilizarlas, cambiarlas, etc. Para ello se puede utilizar un motor de reglas de negocio. El motor de reglas de negocio es un sistema que se configura para dar servicio a las necesidades de negocio a través de la definición de objetos y reglas de negocio, el software se rige por flujos que derivan responsabilidades a los distintos cargos de la empresa repartiendo así el trabajo equitativamente y cuantitativamente, cuando, quien y donde tiene que desempeñar la tarea asignada.

Requerimientos

Determinación de requerimientos

La determinación de los requerimientos es el estudio del sistema actual del negocio a fin de encontrar como trabaja y donde debe mejorase. Los estudios del sistema son el resultado de una evaluación para conocer como funcionan los métodos actuales o si son necesarios o posibles algunos ajustes; elaborar preguntas en relación con los sistemas manuales y los computarizados.

Dado que los analistas de sistemas no trabajan como gerentes o empleados en los departamentos para usuarios (como mercadotecnia, contabilidad, venta, compra o producción), no tienen los mismos conocimientos sobre hechos y datos que los gerentes y usuarios de esas áreas; por lo tanto un paso inicial en la investigación es entender la situación.

Existen ciertos tipos de requerimientos tan fundamentales que son comunes a todas las situaciones. Contestar los grupos específicos de preguntas que analizan esta secciones, permitirá comprender estos requerimientos básicos.

Uso de los diagramas de caso de usos

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores.En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo

Objetivo

Conocer una herramienta de modelado para la solución de problemas utilizando

pragramación orientada a objetos.

Conocer los diferentes tipos de diagramas para análisis y diseño básicos en UML

Utilizar una de las herramientas para elaborar diagramas UML

¿Que es UML?

El Lenguaje de Modelado Unificado (UML - Unified Modeling Language)

es un lenguaje gráfico de propósito general, estándar de la industria para visualizar,

especificar y documentar cada una de las partes que comprende el Desarrollo de

Sistemas a través del uso de diagramas y texto de soporte.

¿Para que sirve?

Visualizar como es un sistema o como queremos que sea.

Especificar la estructura y/o comportamiento de un sistema.

Hacer una plantilla que guíe la construcción de los sistemas

Documentar las decisiones que hemos tomado

Para esta práctica usaremos los diagramas de casos de uso, diagramas de secuencia, y

los diagramas de clase.

Los diagramas de casos de uso y de secuencia, nos servirán para realizar el análisis

necesario para poder hacer un diseño basado en diagramas de clase.

TÉCNICAS DE RECOLECCIÓN DE DATOS

INTRODUCCIÓN

La recolección de datos se refiere al uso de una gran diversidad de técnicas y herramientas que pueden ser utilizadas por el analista para desarrollar los sistemas de información, los cuales pueden ser la entrevistas, la encuesta, el cuestionario, la observación, el diagrama de flujo y el diccionario de datos.
Todas estos instrumentos se aplicará en un momento en particular, con la finalidad de buscar información que será útil a una investigación en común. En la presente investigación trata con detalle los pasos que se debe seguir en el proceso de recolección de datos, con las técnicas ya antes nombradas.

TÉCNICAS PARA HALLAR DATOS

Los analistas utilizan una variedad de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionarios, inspección de registros (revisión en el sitio) y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa.

LA ENTREVISTA

Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán más adelante. Sin embargo, las entrevistas no siempre son la mejor fuente de datos de aplicación.

¿Qué es una encuesta?

Se ha dicho que Estados Unidos ya no es una "sociedad industrial", sino una "sociedad de información". Esto es, nuestros mayores problemas y tareas ya no giran principalmente en la producción de bienes y servicios necesarios para nuestra supervivencia y comodidad
Hoy en día la palabra "encuesta" se usa más frecuentemente para describir un método de obtener información de una muestra de individuos. Esta "muestra" es usualmente sólo una fracción de la población bajo estudio.

cuestionario

Los cuestionarios proporcionan una alternativa muy útil para la entrevista; si embargo, existen ciertas características que pueden ser apropiada en algunas situaciones e inapropiadas en otra. Al igual que la entrevistas, deben diseñarse cuidadosamente para una máxima efectividad.

Diccionario de datos

Los diccionarios de datos son el segundo componente del análisis del flujo de datos. En sí mismos los diagramas de flujo de datos no describen por completo el objeto de la investigación. El diccionario de datos proporciona información adicional sobre el sistema. Esta sección analiza que es un diccionario de datos, por qué se necesita en el análisis de flujo de datos y como desarrollarlo. Se utilizará el ejemplo del sistema de contabilidad para describir los diccionarios de datos.
Un diccionario de datos es una lista de todos los elementos incluido en el conjunto de los diagramas de flujo de datos que describen un sistema. Los elementos principales en un sistema, estudiados en las secciones anteriores, son el flujo de datos, el almacenamiento de datos y los procesos. El diccionario de datos almacena detalles y descripciones de estos elementos.

Descripción de los Datos en el Diccionario

Cada entrada en el diccionario de dato consiste en un conjunto de detalles que describen los datos utilizados o producidos en el sistema. Cada articulo se identifica por un nombre de dato, descripción, sinónimo y longitud de campo y tiene valores específicos que se permiten para éste en el sistema estudiado.

Nombre de los Datos

Para distinguir un dato de otro, los analista les asigna nombre significativos que se utilizan para tener una referencia de cada elemento a través del proceso total de desarrollo de sistemas. Por lo tanto, debe tenerse cuidado para seleccionar, en forma significativa y entendible, los nombres de los datos, por ejemplo la fecha de factura es más significativa si se llama FECHA FACTURA que si se le conoce como ABCXXX.

Descripción de los Datos

Establece brevemente lo que representa el dato en el sistema; por ejemplo, la descripción para FECHA-DE-FACTURA indica que es la fecha en la cual se está preparando la misma (para distinguirla de la fecha en la que se envió por correo o se recibió.
Las descripciones de datos se deben escribir suponiendo que a gente que los lea no conoce nada en relación del sistema. Deben evitarse termino especiales o argot, todas las palabras deben se entendible para el lector

Diagramas de Casos de Uso

Diagramas de Casos de Uso

Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto

de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales del

sistema, es decir, representan las funciones que un sistema puede ejecutar.

Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente

útiles en la comunicación con el cliente.

Definición y Usos

Un diagrama Uso-Caso describe lo que hace un sistema desde el punto de vista de un observador externo, debido a esto, un diagrama de este tipo generalmente es de los más sencillos de interpretar en UML, ya que su razón de ser se concentra en un Que hace el sistema, a diferencia de otros diagramas UML que intentan dar respuesta a un Como logra su comportamiento el sistema.

Un Uso-Caso esta muy relacionado con lo que pudiera ser considerado un escenario en el sistema, esto es, lo que ocurre cuando alguien interactúa con el sistema: "Acude un mesero a colocar la orden, la orden es tomada por el cocinero, y posteriormente se abona a la cuenta del cliente el cargo".

Un Uso-Caso es empleado con más frecuencia en alguna de las siguientes etapas :

• Determinación de Requerimientos: Por lo general nuevos requerimientos de sistema generan nuevos usos-casos, conforme es analizado y diseñado el sistema.
• Comunicación con el Cliente: Debido a la sencillez de este tipo de diagramas, son fáciles de emplear para comunicarse con el cliente final del proyecto.
• Generación de pruebas de Sistemas: A través de los diagramas uso-caso se pueden generar una serie de pruebas de sistema.

En la siguiente sección se describen los diversos elementos que componen un diagrama Uso-Caso.

TIPOS DE DIAGRAMAS UML

TIPOS DE DIAGRAMAS UML

    

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.

Diagrama de clases

Un diagrama de clases es un tipo  de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura conceptual de un dominio  - Soluciones de diseño en una arquitectura - Componentes de software orientados a objetos

Diagrama de componentes
Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado.

Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

Diagrama de objetos

Los diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de los sistemas informáticos en la metodología UML.

Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.

Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma Nombre de objeto:" Nombre de clase ".

Diagramas de comportamientos

Diagrama de secuencia

Muestran las interacciones entre un conjunto de objetos, ordenadas según el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboración, es decir son instancias concretas de una clase que participa en la interacción. El objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede ser destruido durante la ejecución de la interacción. Un diagrama de secuencia representa una forma de indicar el período durante el que un objeto está desarrollando una acción directamente o a través de un procedimiento.

En este tipo de diagramas también intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operación del objeto destino. Existen distintos tipos de mensajes según cómo se producen en el tiempo: simples, síncronos, y asíncronos.

Los diagrama de secuencia permiten indicar cuál es el momento en el que se envía o se completa un mensaje mediante el tiempo de transición, que se especifica en el diagrama.

Diagrama de colaboración

Muestra la interacción entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan información similar, pero en una forma diferente.

Formando parte de los diagramas de colaboración nos encontramos con objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interacción, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad.

Un enlace es una instancia de una asociación que conecta dos objetos de un diagrama de colaboración. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La existencia de un enlace entre dos objetos indica que puede existir un intercambio de mensajes entre los objetos conectados.

Los diagramas de interacción indican el flujo de mensajes entre elementos del modelo, el flujo de mensajes representa el envío de un mensaje desde un objeto a otro si entre ellos existe un enlace. Los mensajes que se envían entre objetos pueden ser de distintos tipos, también según como se producen en el tiempo; existen mensajes simples, sincrónicos, balking, timeout y asíncronos.

Durante la ejecución de un diagrama de colaboración se crean y destruyen objetos y enlaces.

Diagramas de actividad

Son similares a los diagramas de flujo de otras metodologías . En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son estados de acción (estados con una acción interna y una o más transiciones que suceden al finalizar esta acción, o lo que es lo mismo, un paso en la ejecución de lo que será un procedimiento) y las transiciones vienen provocadas por la finalización de las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementación de un caso de uso o de un método (que tiene el mismo significado que en cualquier otra metodología ). Los diagramas de actividad se utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del sistema.

Diagramas de estado

Representan la secuencia de estados por los que un objeto o una interacción entre objetos pasa durante su tiempo de vida en respuesta a estímulos (eventos) recibidos. Representa lo que podemos denominar en conjunto una máquina de estados. Un estado en UML es cuando un objeto o una interacción satisface una condición, desarrolla alguna acción o se encuentra esperando un evento.

Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia de un evento se dice que ha sufrido una transición, existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Además una transición puede ser interna si el estado del que parte el objeto o interacción es el mismo que al que llega, no se provoca un cambio de estado y se representan dentro del estado, no de la transición. Como en todas las metodologías  se envían mensajes, en este caso es la acción de la que puede enviar mensajes a uno o varios objetos destino.

(LENGUAJE UNIFICADO DE MODELADO UML)

LENGUAJE UNIFICADO DE MODELADO UML

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (Tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

 ¿Qué es UML?

El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para expresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño.

La estandarización de un lenguaje de modelado es invaluable, ya que es la parte principal del proceso de comunicación que requieren todos los agentes involucrados en un proyecto informático. Si se quiere discutir un diseño con alguien más, ambos deben conocer el lenguaje de modelado y no así el proceso que se siguió para obtenerlo.

 Objetivos del UML 2.0

Al momento de desarrollar el nuevo estándar 2.0 del UML, la OMG se propuso, entre otros, dosobjetivos que podríamos considerar principales debido a la influencia de éstos en la versión final delestándar. Estos objetivos son:

1.Hacer el lenguaje de modelado mucho más extensible de lo que era.

2.Permitir la validación y ejecución de modelos creados mediante el UML.

UML 2.0 se desarrolla sobre la base de estos dos objetivos, causando un quiebre respecto a versionesanteriores. Para entender la razón del quiebre y el por qué de esta evolución tan marcada,
nosprofundizaremos un poco en la historia y definición misma del UML

Casos de Uso (Use Case)

Introducción

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

• Actor.
• Casos de Uso.
• Relaciones de Uso, Herencia y Comunicación.

Elementos

Actor:

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

Relaciones:

Asociación

• Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

• Dependencia o Instanciación
  
  
  
  Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada 

• Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso   (<<uses>>)   o de Herencia  (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).

uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

MODELOS DE CICLO DE VIDA

Ciclo de Vida del Software

Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.

El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 años atrás, el modelo cascada ha sido sujeto a numerosas críticas, debido a que es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software más rápidamente, o más incrementalmente o de una forma más evolutiva, o precediendo el desarrollo a escala total con algún conjunto de prototipos rápidos.

Definición de un Modelo de Ciclo de Vida

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.

Un modelo de ciclo de vida del software:

• Describe las fases principales de desarrollo de software.
• Define las fases primarias esperadas de ser ejecutadas durante esas fases.
• Ayuda a administrar el progreso del desarrollo, y
• Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.

Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.

 

Alternativas de Modelos de Ciclo de Vida

Modelo Cascada

Este es el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida. La visión del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuye a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase. Las flechas muestran el flujo de información entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrás representan la retroalimentación.

El modelo de ciclo de vida cascada, captura algunos principios básicos:

• Planear un proyecto antes de embarcarse en él.
• Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.
• Documentar los resultados de cada actividad.
• Diseñar un sistema antes de codificarlo.
• Testear un sistema después de construirlo.

Una de las contribuciones más importantes del modelo cascada es para los administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.

CICLO DE VIDA DE UN SISTEMA DE INFORMACIÓN

CICLO DE VIDA DE UN SISTEMA DE INFORMACIÓN

INTRODUCCIÓN

En la actualidad para muchas organizaciones, los sistemas de información basados en computadoras son el corazón de las actividades cotidianas y objeto de gran consideración en la toma de decisiones, las empresas consideran con mucho cuidados las capacidades de sus sistemas de información cuando deciden ingresar o no en nuevos mercados o cuando planean la respuesta que darán a la competencia

CICLO DE VIDA DE UN SISTEMA DE INFORMACION

El ciclo de vida de un sistema de información es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista y del usuario.
Según James Senn, existen tres estrategias para el desarrollo de sistemas: el método clásico del ciclo de vida de desarrollo de sistemas, el método de desarrollo por análisis estructurado y el método de construcción de prototipos de sistemas. Cada una de estas estrategias tienen un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada.

CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS

1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.

2). Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:

¿Qué es lo que hace?
¿Cómo se hace?
¿Con que frecuencia se presenta?

Definición

1). Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:

¿Qué es lo que hace?

¿Cómo se hace?

¿Con que frecuencia se presenta?

¿Qué tan grande es el volumen de transacciones o decisiones?

¿Cuál es el grado de eficiencia con el que se efectúan las tareas?

¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?

2). Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.

3). Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.

Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.

4). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.

Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.

INGENIERÍA DE SISTEMAS

Sistemas de Información

La ingeniería de sistemas o ingeniería de los sistemas o ingeniería en sistemas es un modo de enfoque interdisciplinario que permite estudiar y comprender la realidad, con el propósito de implementar u optimizar sistemas complejos. Puede verse como la aplicación tecnológica de la teoría de sistemas a los esfuerzos de la ingeniería, adoptando en todo este trabajo el paradigma sistémico. La ingeniería de sistemas integra otras disciplinas y grupos de especialidad en un esfuerzo de equipo, formando un proceso de desarrollo estructurado.

Sistema de información

Un sistema de información (SI) es un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su uso posterior, generados para cubrir una necesidad u objetivo. Dichos elementos formarán parte de alguna de las siguientes categorías:

-personas
-datos
-actividades o técnicas de trabajo
-Recursos materiales en general (generalmente recursos informáticos y de comunicación, aunque no necesariamente).

Tipos de sistemas de información

Debido a que el principal uso que se da a los SI es el de optimizar el desarrollo de las actividades de una organización con el fin de ser más productivos y obtener ventajas competitivas, en primer término, se puede clasificar a los sistemas de información en:

• Sistemas Competitivos
• Sistemas Cooperativos
• Sistemas que modifican el estilo de operación del negocio

Esta clasificación es muy genérica, y en la práctica no obedece a una diferenciación real de sistemas de información reales, ya que en la práctica podríamos encontrar alguno que cumpla varias (dos o las tres) de las características anteriores. En los subapartados siguientes se hacen unas clasificaciones más concretas (y reales) de sistemas de información.

 

Investigación de operaciones

Es una rama de las Matemáticas consistente en el uso de modelos matemáticos, estadística y algoritmos con objeto de realizar un proceso de toma de decisiones. Frecuentemente, trata el estudio de complejos sistemas reales, con la finalidad de mejorar (u optimizar) el funcionamiento del mismo. La investigación de operaciones permite el análisis de la toma de decisiones teniendo en cuenta la escasez de recursos, para determinar cómo se pueden maximizar o minimizar los recursos.

1. Una organización es un sistema formado por componentes que se interaccionan, unas de estas interacciones pueden ser controladas y otras no.
2. En un sistema la información es una parte fundamental, ya que entre las componentes fluye información que ocasiona la interacción entre ellas. También dentro de la estructura de los sistemas se encuentran recursos que generan interacciones.
Los objetivos de la organización se refieren a la eficacia y eficiencia con que las componentes pueden controlarse, el control es un mecanismo de autocorrección del sistema que permite evaluar los resultados en términos de los objetivos establecidos.
3. La complejidad de los problemas que se presentan en las organizaciones ya no encajan en una sola disciplina del conocimiento, se han convertido en multidisciplinario por lo cual para su análisis y solución se requieren grupos compuestos por especialistas de diferentes áreas del conocimiento que logran comunicarse con un lenguaje común.
4. La investigación de operaciones es la aplicación de la metodología científica a través de modelos matemáticos, primero para representar al problema y luego para resolverlo. La definición de la sociedad de investigación de operaciones de la Gran Bretaña es la siguiente:
La investigación de operaciones es el ataque de la ciencia moderna a los complejos problemas que surgen en la dirección y en la administración de grandes sistemas de hombres, máquinas, materiales y dinero, en la industria, en los negocios, en el gobierno y en la defensa.

Definición y Significado de Investigación de Operaciones

*La Investigación de Operaciones aspira a determinar el mejor curso de acción, o curso óptimo, de un problema de decisión con la restricción de recursos limitados.

*Como tecnica para la resolución de problemas, investigación de operaciones debe visualizarse como una ciencia y como un arte.

Como Ciencia radica en ofrecer técnicas y algoritmos matemáticos para resolver problemas de decisión adecuada.

Como Arte debido al éxito  que se alcanza en todas las fases anteriores y posteriores a la solución de un modelo matemático, depende de la forma apreciable de la creatividad y la habilidad personal de los analistas encargados de tomar las decisiones.
En un equipo de Investigación de Operaciones es importante la habilidad adecuada en los aspectos científicos y artísticos de Investigación de Operaciones. Si se destaca un aspecto y no el otro probablemente se impedirá la utilización efectiva de la Investigación de Operaciones en la práctica.

• La Investigación de Operaciones en la Ingeniería de Sistemas se emplea principalmente en los aspectos de coordinación de operaciones y actividades de la organización o sistema que se analice, mediante el empleo de modelos que describan las interacciones entre los componentes del sistema y de éste con este con su medio    ambiente
• En la Investigación de Operaciones la parte de "Investigación" se refiere a que aquí se usa un enfoque similar a la manera en la que se lleva a cabo la investigación en los campos científicos establecidos. La parte de "Operaciones" es por que en ella se resuelven problemas que se refieren a la conducción de operaciones dentro de una organización.

 

Ingeniería de sistemas cognitivos

La ingeniería de sistemas cognitivos es una rama de la ingeniería de sistemas que trata los entes cognitivos, sean humanos o no, como un tipo de sistemas capaces de tratar información y de utilizar recursos cognitivos como la percepción, la memoria o el procesamiento de información. Depende de la aplicación directa de la experiencia y la investigación tanto en psicología cognitiva como en ingeniería de sistemas. La ingeniería de sistemas cognitivos se enfoca en cómo los entes cognitivos interactúan con el entorno. La ingeniería de sistemas trabaja en la intersección de:

1. El desarrollo de la sociedad en esta nueva era
2. Los problemas impuestos por el mundo
3. Las necesidades de los agentes (humano, hardware, software)
4. La interacción entre los varios sistemas y tecnologías que afectan (y/o son afectados por) la situación.

Algunas veces designados como ingeniería humana o ingeniería de factores humanos, esta rama además estudia la ergonomía en diseño de sistemas. Sin embargo, la ingeniería humana suele tratarse como otra especialidad de la ingeniería que el ingeniero de sistemas debe integrar.
Habitualmente, los avances en ingeniería de sistemas cognitivos se desarrollan en los departamentos y áreas de Informática, donde se estudian profundamente e integran la inteligencia artificial, la ingeniería del conocimiento y el desarrollo de interfaces hombre-máquina (diseños de usabilidad) de la ciencia

El Ingeniero de sistemas habitualmente aprende a programar, para dirigir a programadores y al momento de la creacion de un programa debe saber y tener en cuenta los metodos básicos como tal, por eso es importante que aprenda a programar pero su función realmente es el diseño y planeacion, y todo lo referente al sistema o redes, su mantenimiento y efectividad, respuesta y tecnología.