Diagramas de caso de uso

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 interactúan (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.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local. (htt4)

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.

Qué es UML

 El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación. UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. (htt1)

 • Diagramas de Casos de Uso para modelar los procesos ’business’.

• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.

 • Diagramas de Colaboración para modelar interacciones entre objetos.

• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.

• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones. • Diagramas de Clases para modelar la estructura estática de las clases en el sistema.

 • Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.

 • Diagramas de Componentes para modelar componentes.

• Diagramas de Implementación para modelar la distribución del sistema.

UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares. En 1996, el Object Management Group (OMG), un pilar estándar para la comunidad del diseño orientado a objetos, publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares. UML, en su versión 1.0, fue propuesto como una respuesta a esta petición en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versión 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento OMG UML versión 1.1. El OMG está actualmente en proceso de mejorar una edición técnica de esta especificación, prevista su finalización para el 1 de abril de 1999. (htt)

Extensiones UML

Los mecanismos de de extensibilidad incorporados permiten a UML ser una especie de especificación abierta que puede cubrir aspectos de modelado no especificados en el documento

1.1. Estos mecanismos permiten extender la notación y semática de UML.

2.3.1. Esteroetipos Los estereotipos son el mecanismo de extensibilidad incorporado más utilizado dentro de UML. Un estereotipo respresenta una distinción de uso. Puede ser aplicado a cualquier elemento de modelado, incluyendo clases, paquetes, relaciones de herencia, etc.

Por ejemplo, una clase con estereotipo ’actor’ es una clase usada como un agente externo en el modelado de negocio. Una clase patrón es modelada como una clase con estereotipo parametrizado, lo que significa que puede contener parámetros.

2.3.2. Extensiones de Modelado de Negocio Un documento separado dentro de la especificación UML define clases y estereotipos de asociación específicos que extienden UML hasta cubrir conceptos de modelado de negocio. Esto incluye ’stereotyping’ una clase como un actor, un trabajador (’both internal and case’), o una entidad, y ’stereotyping’ una asociación como una comunicación simple, o una subcripción entre un origen y un objetivo. (htt2)

2.3.3. Lenguaje restrictivo (constraint) de objetos (OCL) Una imagen puede describir muchas palabras. De igual modo, un modelo gráfico puede describir una cierta parte del comportamiento, después de la cual es necesario rellenar detalles adicionales con palabras. Describiendo algo con palabras, sin embargo, casi siempre desemboca en ambiguedades; por ejemplo, "¿que quería decir cuando escribió eso?". El Lenguaje Restrictivo (constraint) de Objetos (OCL) está incorporado en UML como un estándar para especificar detalles adicionales, o precisar detalles en la estrucutura de los modelos. Desarrollado dentro de la IBM Insurace Division como un lenguaje de modelado de negocio, el OCL es un lenguaje formal diseñado para ser fácil de leer y de escribir. OCL es más funcional que el lenguaje natural, pero no tan preciso como un lenguaje de programación - no puede ser usado para escribir lógicas de lógica de programación o control de flujo. Puesto que OCL es un lenguaje para la expresión pura, sus declaraciones están garantizadas de no tener efectos laterales - simplemente transportan un valor y nunca pueden cambiar el estado del sistema. (htt3)

ANÁLISIS DE REQUERIMIENTOS 

La siguiente etapa del proceso de ingeniería de requerimientos es la obtención y análisis de requerimientos. En esta actividad, los ingenieros de software trabajan con los clientes y los usuarios finales del sistema para determinar el dominio de la aplicación, qué servicios debe proporcionar el sistema, el rendimiento requerido del sistema, las restricciones hardware, etcétera.

[Sommerville, 2005] presenta el modelo de la figura 2.2 de (Robertson y Robertson, 1999) para mostrar que los requerimientos pueden extraerse de muchas maneras, sugiere ser creativos en la forma de averiguar qué es lo que los clientes quieren, y propone:

• Revisar la situación actual.
• Trabajar en el ámbito del usuario para comprender el contexto, los problemas y las relaciones.
• Entrevistar a los usuarios actuales y potenciales.
• Realizar un video para mostrar como podría funcionar el nuevo sistema.
• Investigar en documentos existentes.
• Conducir tormentas de ideas con los usuarios actuales y potenciales.
• Observar las estructuras y los patrones.
• 

La obtención y análisis de requerimientos pueden afectar a varias personas de la organización. El término stakeholder (sin traducción al español) se utiliza en la Ingeniería de Software para referirse a cualquier persona o grupo que se verá afectado por el sistema, directa o indirectamente.http://www.conocimientosweb.net/dcmt/ficha25211.html

ESTUDIO DE FACTIBILIDAD (ESQUEMA APLICABLE PARA NUEVOS PRODUCTOS) 1. Determinación de la Factibilidad Factibilidad: se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas señalados, la factibilidad se apoya en 3 aspectos: básicos: • Operativo. • Técnico. • Económico. El éxito de un proyecto está determinado por el grado de factibilidad que se presente en cada una de los tres aspectos anteriores. Estudio de Factibilidad: Sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello tomar la mejor decisión, si procede su estudio, desarrollo o implementación. Objetivos de un Estudio de Factibilidad. • Auxiliar a una organización a lograr sus objetivos. • Cubrir las metas con los recursos actuales en las áreas técnicas, económicas y operativas.

DEFINICIÓN DE OBJETIVOS DEL PROYECTO: La investigación de factibilidad en un proyecto que consiste en descubrir cuáles son los objetivos de la organización, luego determinar si el proyecto es útil para que la empresa logre sus objetivos. La búsqueda de estos objetivos debe contemplar los recursos disponibles o aquellos que la empresa puede proporcionar, nunca deben definirse con recursos que la empresa no es capaz de dar. En las empresas se cuenta con una serie de objetivos genéricos que determinan la posibilidad de factibilidad de un proyecto sin ser limitativos. Estos objetivos son los siguientes: • Reducción de errores y mayor precisión en los procesos. • Reducción de costos mediante la optimización o eliminación de recursos no necesarios. • Integración de todas las áreas y subsistemas de la empresa. • Actualización y mejoramiento de los servicios a clientes o usuarios. • Aceleración en la recopilación de datos. • Reducción en el tiempo de procesamiento y ejecución de tareas. • Automatización u optimización de procedimientos manuales. • Reinversión social de sus excedentes, con igualdad sustantiva entre sus integrantes.

http://proyectos.aragua.gob.ve/descargas/ESTUDIOFACTIBILIDADECON%C3%93MICA.pdf

   CASO DE VIOLACIÓN DE DATOS



Aquí los casos a los que el IFAI les impuso una sanción:

 Impuso a Pharma Plus, S.A. de C.V. una sanción de dos millones 45 pesos, por la violación al principio de información, al omitir el elemento de identidad en el Aviso de Privacidad.

A Sport City, S.A. de C.V., una multa equivalente a un millón 246 mil 600 pesos, por no señalar en el Aviso de Privacidad las opciones y medios que debe ofrecer a los titulares para ejercer los derechos ARCO.

A Banco Nacional de México, cinco multas por un monto total de 16 millones 155 mil 936 pesos, al evidenciar negligencia en la tramitación y respuesta de una solicitud de cancelación y oposición de datos personales; dar tratamiento a datos personales en contravención a los principios establecidos en la Ley; continuar con el uso ilegítimo de los datos personales cuando se ha solicitado el cese de los mismos por el Instituto o los titulares y por no cumplir con la solicitud del titular para el acceso, rectificación, cancelación u oposición al tratamiento de sus datos personales, sin razón fundada. A Caja Popular Cristo Rey, S.C. de R.L. de C.V., multas por dos millones 181 mil 550 pesos, por recabar datos de carácter financiero y patrimonial, sin contar con el consentimiento del titular y por no permitir a los titulares el ejercicio de sus derechos.

Finalmente, el más reciente de los casos, y único en el cual el infractor es un particular, correspondió a una sanción impuesta a un médico por 41 mil 874 pesos, por haber transferido datos personales sensibles sin contar con el consentimiento del titular, y no haber señalado expresamente en su Aviso de Privacidad las opciones y medios que ofrecía para limitar el uso o divulgación de los mismos.

Política Organizacional

Es la orientación o directriz que debe ser divulgada, entendida y acatada por todos los miembros de la organización, en ella se contemplan las normas y responsabilidades de cada área de la organización. Las políticas son guías para orientar la acción; son lineamientos generales a observar en la toma de decisiones, sobre algún problema que se repite una y otra vez dentro de una organización. En este sentido, las políticas son criterios generales de ejecución que complementan el logro de los objetivos y facilitan la implementación de las estrategias. Las políticas deben ser dictadas desde el nivel jerárquico más alto de la empresa.

Normas

Son reglas específicas que se deben seguir o a que se deben ajustar las conductas, tareas, o actividades en una organización para poder llevar a cabo el cumplimiento de una política organizacional. Cabe destacar que forman parte del contenido de las políticas organizacionales.

Tipos de políticas

Generales; son las que aplica a todos los niveles de la organización, son de alto impacto o criticidad, por ejemplo: políticas de presupuesto, políticas de compensación, política de la calidad, política de seguridad integral, entre otras.

Específicas; son las que aplican a determinados procesos, están delimitadas por su alcance, por ejemplo: política de ventas, política de compras, política de seguridad informática, políticas de inventario, entre otras.