Plagio (Conferencia ULSA 2013)

El pasado viernes 24 de mayo de 2013, se llevó a cabo la conferencia acerca del plagio en la universidad La Salle en la cual participamos algunos compañeros de la carrera de ingeniería en diseño de software.

Plagio

¿Qué es Plagio?

El plagio o deshonestidad académica, aplicado al entorno académico, es usar el trabajo, las ideas, o las palabras de otra persona como si fueran propias. Es aplicable a cualquier trabajo de clase, gráfico, esquema, examen, software, fotografía, etc. Se trata de una infracción muy seria contra la honestidad académica, un robo intelectual en el que se utiliza la destreza intelectual de otra persona como si fuera propia.

¿Cuándo se comete plagio?

·         Cuando entregamos un trabajo ajeno a un profesor como si fuera propio.

·         Al comprar un trabajo por Internet u otro procedimiento.

·         Cuando se copian sentencias, frases, párrafos o ideas de un trabajo ajeno, publicado o no, sin dar crédito al autor original.

·         Al sustituir palabras de un texto sin dar crédito al autor original.

·         Cuando se copia cualquier tipo de multimedia (gráficos, audio, vídeo, página de internet...) programa de ordenador, música, gráficos... sin dar crédito al autor original.

·         Si utilizamos frases, ideas y sentencias tomadas de múltiples fuentes para construir un trabajo nuevo.

·         Cuando nos basamos en una idea o frase de otro para escribir un trabajo nuevo y no damos crédito al autor de la idea.

¿Qué se plagia?

·         Obras científicas y literarias: tesis, artículos de revistas, etc.

·         Composiciones musicales.

·         Obras cinematográficas y audiovisuales.

·         Proyectos, planos, maquetas de obras arquitectónicas o de ingeniería.

·         Programas de ordenador.

·         Bases de datos.

·         Páginas web y obras multimedia.

·         El plagio se puede atribuir tanto a un trabajo entero como a una sola frase que provenga de la obra de un autor y que no se haya citado.

¿Qué no es plagio?

·         Los trabajos o ideas originales.

·         El conocimiento común.

·         La recopilación de los resultados de una investigación original.

Legislación contra el plagio

La Ley de Propiedad Intelectual (aprobada por Real Decreto Legislativo 1/1996, de 12 de abril y modificado por la ley 5/1998 de 12 de abril) ha provocado durante los últimos años un gran debate público motivado por las nuevas posibilidades que ofrece el mundo digital.

La segunda herramienta con la que cuentan los autores para protegerse, la Ley Orgánica 2/1984 de 26 de marzo, regula el derecho de rectificación.

Esta ley ha permitido que en el plazo de 7 días desde la publicación, el autor plagiado pueda remitir una carta de rectificación que debe ser publicada en los tres días siguientes a su recepción y si no se produce la rectificación, puede plantear una acción judicial de tramitación rápida.

También de consideración son las Directivas Comunitarias sobre la materia, especialmente la Directiva 2001/29/CE sobre derechos de autor y derechos afines en la sociedad de la información.

¿Cómo evitar el plagio?

Cita la frase o párrafo directamente del original y acredita la autoridad y fuente mediante una cita o referencia bibliográfica.

En este caso se trata de incluir en nuestro trabajo la frase o frases tomadas directamente del original. Es decir, utilizar las palabras del autor, pero:

·         Siempre entre comillas deben distinguirse perfectamente del resto del texto (cursiva, párrafos independientes, tabulación)

·         Deben ir acompañadas por una explicación o interpretación propia de dicha cita.

·         Hay que acreditar al autor mediante una referencia bibliográfica

La utilización de las citas no atenta contra los derechos de autor.

Parafrasea (resumiendo o no) las palabras originales del autor y acredita la autoridad y fuente mediante una cita o referencia bibliográfica.

Parafrasear es utilizar las ideas de otra persona, pero usándolas como si fueran propias.

Descargar PDF aquí

Proceso de Pruebas de Software

Las pruebas de software son los procesos que permiten verificar y revelar la calidad de un producto software antes de su puesta en marcha. Básicamente, es una fase en el desarrollo de software que consiste en probar las aplicaciones construidas.

Las pruebas de software se integran dentro de las diferentes fases del ciclo de vida del software dentro de la Ingeniería de software. En este sentido, se ejecuta el aplicativo a probar y mediante técnicas experimentales se trata de descubrir qué errores tiene.

Estas pruebas hay que realizarlas al comienzo del ciclo de vida del software ya que, cuando avanzamos en el ciclo de vida, más costoso sería solucionar el fallo encontrado.

Generar Plan de Pruebas

El Plan de pruebas describe la estrategia, recursos y planificación de las pruebas. La estrategia de prueba incluye la definición del tipo de pruebas a realizar para cada iteración y sus objetivos, el nivel de cobertura de prueba y el porcentaje de prueba que deberían ejecutarse con un resultado específico.

El Plan de pruebas proporciona el marco dentro del cual el equipo de prueba desarrolla las pruebas trabajando con los recursos y la planificación dada.
El Plan de pruebas proporciona la siguiente información:
La definición de los objetivos de los objetivos de las pruebas en el ámbito de la iteración.
La definición de los elementos que se van a probar.
Una explicación del enfoque o estrategia que se usará.
Los recursos y planificación necesarios.
Los resultados que se obtienen del proceso de prueba.

Diseñar Pruebas Específicas

Al igual que la etapa de análisis, el diseño de las pruebas es una parte considerable de trabajo. Durante esta fase se diseñan e implementan los casos de prueba (Test Cases). Tomando como punto de partida el resultado del análisis de pruebas, se diseñan las pruebas en detalle, indicando cuáles son los pasos o el procedimiento a seguir, las técnicas, medidas o análisis que hay que aplicar así como los conjuntos de datos de prueba que se usarán, y los resultados esperados que se producirán, para conseguir demostrar que los objetivos de la prueba se cumplen y por lo tanto verifican y validan el requisito que cubren.
El diseño de las pruebas persigue la prevención de defectos, antes de que por codificación puedan haberse llegado a producir.

Un buen diseño de pruebas previene, en consecuencia, los defectos antes de que lleguen a etapas más tardías, con el consecuente ahorro que supondrá su corrección. Un buen plan de pruebas es una valiosa herramienta para luchar contra los defectos y será la base para el refinamiento del mismo tanto por que el producto software evoluciona, como porque el propio plan es susceptible de recisión y mejora.
Atendiendo a la fase en que serán aplicadas.

Pruebas unitarias.

Pruebas de integración. Tienen como objetivo validar la correcta operación entre los diferentes módulos del sistema. El objetivo es demostrar que las interfaces de cada módulo funcionan correctamente.

Pruebas de sistema.

Verifican el correcto funcionamiento del sistema completo incluyendo casos de prueba que busquen los fallos del sistema. Son pruebas destructivas y persiguen demostrar la robustez del sistema aun en condiciones adversas. Verifican requisitos funcionales y no funcionales. 

Pruebas de aceptación del usuario.

Similares a las de sistema, pero no destructivas. Permiten demostrar que el sistema funciona en condiciones normales. 

Pruebas de regresión.

Ejecutadas al final de cada iteración y antes de las pruebas de aceptación para asegurar que funcionalidades desarrolladas en iteraciones previas no han sufrido daños.

Pruebas de humo (Smoke o Sanity Tests). Selección de pruebas de alta prioridad que en poco tiempo ayudan a identificar si un despliegue en los entornos de producción o de aceptación ha funcionado de forma correcta. 

Estas pruebas se componen de pruebas desarrolladas con técnicas más específicas, como valores límite, tablas de decisión, pruebas de penetración etc. pero por su importancia para el sistema cabe destacar las pruebas de rendimiento.

Pruebas de rendimiento
Pruebas de carga (Load). 
Pruebas de redundancia (Failover) 
Pruebas de estrés.

Pruebas de rendimiento.

Pruebas de sensibilidad a carga de red.
Pruebas de Volumen.

Etc. 
Tomar Configuración del Software a Probar

La Gestión de Configuración de Software (SCM) es una disciplina de la Ingeniería de Software que se preocupa de:

Identificar y documentar las características funcionales y físicas de los elementos de configuración.
Controlar los cambios a tales características.
Reportar el proceso de tales cambios y su estado de implantación.

Evaluar Resultados.

Una vez obtenidos los resultados, antes de informar de ellos, el investigador debe dedicar algún tiempo a una fase especial: la evaluación. Debe evaluar los resultados: ¿son lo que él quería?, ¿Es posible mejorar algo en el informe? ¿Debe ser dejado fuera algo o merece el informe publicarse en su totalidad? 

Los criterios para la labor de evaluar proyectos de investigación se pueden derivar del propósito del proyecto. Las metas diferentes para la investigación se discuten bajo el título El contexto de un proyecto de investigación. Caen generalmente en dos grupos:

·         Los blancos teóricos apuntan a promover el conocimiento colectivo en el campo apropiado del estudio. Estos blancos pertenecen a los proyectos de la investigación básica y de la investigación aplicada.

·         Los blancos prácticos apuntan a mejorar el estado del objeto del estudio o de otros objetos similares en el futuro. Son típicas en los proyectos de la investigación aplicada y del desarrollo tecnológico. 

Los resultados teóricos son a menudo relativamente difíciles de ser evaluado directamente, porque los hallazgos más valiosos contienen a menudo descubrimientos novedosos para los cuales no hay todavía criterios. Por lo tanto la evaluación debe incluir generalmente no sólo el salida final ("output") pero también todas las tareas que el investigador ha ejecutado antes de llegar los resultados finales.

Estas evaluaciones se discuten en Evaluar la entrada teórica, Evaluar datos recogidos y Evaluar la corrección del análisis.

Los resultados prácticos pueden ser evaluados a menudo directamente e también fácilmente, vea la discusión en Evaluar los resultados prácticos. Esta sola evaluación da a menudo ya una resolución clara, y en tal un acontecimiento las evaluaciones adicionales son innecesarias. Sin embargo, los resultados prácticos, incluyendo los efectos secundarios no previstos, afectan a menudo a varios grupos de gente, y no es infrecuente que varios evaluadores deben ser utilizados y éstos dan opiniones disidentes. En tal caso puede ser provechoso recurrir a los procedimientos más meticulosos enumerados arriba.

Depuración

La depuración está estrechamente relacionada con el concepto de calidad. En un sentido amplio, depurar un programa significa librarlo de errores e inconvenientes más o menos graves, que con frecuencia es un proceso mucho más costoso y arduo de lo que pudiera parecer a primera vista, en especial en programas grandes y complejos. Sin embargo, es imprescindible si queremos ofrecer al público un producto con un mínimo de calidad.
En general la depuración de un programa se completa en tres fases; es un proceso en el que el producto se va acercando a la perfección (estar libre de errores e inconvenientes graves) mediante una serie de transformaciones sucesivas que responden al esquema de la figura.

En una primera fase, cuando ya el programa está prácticamente terminado, se somete a pruebas que podríamos llamar "de laboratorio" para comprobar que todo marcha según lo esperado y sin errores.  Son pruebas que realiza el propio programador antes de dar a conocer el producto. Estas versiones se suelen denominar alfa y corresponden a un punto en que el programa todavía está en fase de gestación. En una versión alfa son de esperar todo tipo de errores y "cuelgues".

En una segunda fase, cuando el programador cree que su producto ya está suficientemente presentable y él no consigue encontrar más errores aparentes (o los ya conocidos están en proceso de depuración), se procede a la distribución del producto a una serie de probadores seleccionados ("beta testers"). Son las denominadas versiones beta, que aunque con errores esporádicos, pueden tener un comportamiento más o menos aceptable.
Finalmente, en una tercera fase, con la información, opiniones y sugerencias de los "beta testers", se procede a lanzar la primera versión pública v 1.0 del producto ("Release"),  también denominadas versiones gamma. A partir de aquí, lo normal es que se vayan recogiendo las sugerencias, cuestiones y posibles errores que hayan pasado inadvertidos en las pruebas beta y sean reportados por los usuarios. Las soluciones a estos problemas, junto con las mejoras que se vayan incorporando, son implementadas en versiones sucesivas.  Generalmente a partir de la versión 2.0 el producto se considera estable.

Análisis de Errores

Al realizar cálculos mediante algoritmos más o menos complejos, es inevitable cometer errores. Estos errores pueden ser de tres tipos:
Errores en los datos de entrada: Este tipo de error viene causado por los errores al realizar mediciones de magnitudes físicas.

Errores de redondeo: En este caso, el error aparece al operar con representaciones numéricas finitas. Se puede solucionar utilizando más decimales, pero esto conlleva utilizar más memoria (recursos). 

Errores de truncamiento (o discretización): Este tipo de error se refiere al error que se comete al utilizar un algoritmo determinado. Esto quiere decir que si se refina la discretización o se cambia el algoritmo, puede disminuir. Refinar la discretización generalmente lleva a realizar más cuentas lo que equivale a incrementar el error de redondeo y el tiempo de cálculo. 

El primer tipo de error no es analizable matemáticamente dado a que está sujeto al avance tecnológico de los aparatos de medida. El segundo y el tercer tipo de errores se pueden cuantificar de una forma aproximada utilizando expresiones adecuadas.

Descarga el PDF aquí

Modelo de Casos de Uso

Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso, actores y sus relaciones.

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.

Un diagrama de casos de uso es simplemente un tipo especial de diagrama que comparten propiedades comunes con otros diagramas – un nombre y un contenido gráfico que están dentro de un modelo. Lo que distingue un diagrama de casos de uso de los otros tipos es su particular contenido.

Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente útiles en la comunicación con el cliente.

En un caso de uso uno o más actores interaccionan con el sistema que realiza algunas acciones.

Tipos de Caso de Uso

·         Según cuál sea el nivel de detalle

o   Resumidos o de 'alto nivel': Durante la fase de inicio la mayor parte de los casos de uso deben tener esta forma.

o   Extensos: Durante la fase de elaboración los casos de uso deben escribirse de esta forma.

·         También se distingue entre:

o   Esenciales

o   De implementación, reales o concretos: hacen referencia a detalles de la interface

Elementos de un modelo de casos de uso:

·         Actores

·         Casos de uso

·         Dependencias, generalización, y relaciones de asociación.

  

 Igual que todos los diagramas, los casos de uso pueden contener notas y restricciones.

Actores

Un actor podría ser cualquier cosa que se comunica (interacciona) con el sistema y que es externo a él.

Los actores no necesariamente coinciden con los usuarios. Un usuario puede interpretar distintos roles, correspondientes a distintos actores.

Los actores representan papeles (ROLES) que interpretan personas, periféricos u otros sistemas cuando el sistema está en uso.

Un actor podría desempeñar distintos papeles dependiendo del caso de uso en que participe.

Un actor representa un conjunto coherente de papeles que los usuarios de una entidad (sistema, subsistema, clase) pueden desempeñar al interaccionar con la misma.

Tipos de Actores

Primarios: interaccionan con el sistema para explotar su funcionalidad; trabajan directa y frecuentemente con el software.

Secundarios: soporte del sistema para que los primarios puedan trabajar.

Iniciadores: no utilizan directamente el sistema pero desencadenan el trabajo de otro actor. (No aparecen en UML pero sí los consideran otros autores).

Caso de uso

Es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se está desarrollando. Se representan mediante un óvulo. Cada caso de uso debe detallarse, habitualmente mediante una descripción textual.

Asociaciones

Hay una asociación entre un  actor y un caso de uso si el actor interactúa  con el sistema para llevar a cabo el caso de uso.

Comunicación Actor-Sistema

·         Para iniciar el caso de uso (siempre los inicia un actor)

·         Para solicitar información del sistema

·         Para modificar la información del sistema

·         Para informar al sistema de que ha ocurrido algo en su entorno que le incumbe

Comunicación Sistema-Actor

·         Para comunicarle que ha sucedido algo, en el sistema, que le concierne

·         Para que le ayude a tomar una decisión necesaria para cumplir los objetivos del sistema

·         Para delegar alguna responsabilidad en el actor

Diagrama de Secuencia

El UML provee un medio gráfico para representar la interacción entre los objetos a lo largo del tiempo en los diagramas de secuencia. Éstos muestran típicamente a un usuario o a un actor y los objetos y componentes con los que interactúen durante la ejecución de un Caso de Uso. Un diagrama de secuencia representa típicamente un único escenario de Caso de Uso o flujo de eventos.

Los diagramas son una vía excelente para documentar los escenarios de uso, para capturar los objetos necesarios de manera temprana en el análisis y para verificar el uso de los objetos más tarde en el diseño. Los diagramas de secuencia muestran el flujo de mensajes de un objeto a otro y, como tales, representan los métodos y los eventos soportados por un/a objeto/clase.

El diagrama ilustrado abajo muestra un ejemplo de un diagrama de secuencia, con el usuario o actor a la izquierda iniciando un flujo de eventos y mensajes que corresponden al escenario del caso de uso. Los mensajes que pasan entre objetos se convertirán en operaciones de clases en el modelo final.

                                         

                                                                                 

Diagrama de Implementación

Un Caso de Uso es una descripción formal de la funcionalidad que el sistema tendrá cuando se construya. Un diagrama de implementación se asocia típicamente con un caso de uso para documentar qué elementos de diseño (por ejemplo, componentes y clases) implementará la funcionalidad del Caso de Uso en el nuevo sistema. Esto provee un alto grado de trazabilidad al diseñador, al cliente y al equipo que construirá el sistema. La lista de casos de uso a los que se asocia un componente o una clase documenta la funcionalidad mínima que debe ser implementada por el componente.

Ejemplos

Descarga el PDF aquí

Modelo de Casos de Uso

La mejor forma de desarrollar un buen diagrama de caso de uso es mediante entrevista directa con los usuarios o posibles futuros usuarios del sistema, poniendo atención a cada una de las actividades o pasos que se van a ir desarrollando desde un primer momento hasta un momento final.

La elaboración de diagramas de uso ayuda poderosamente a un analista a comprender la forma en que un sistema deberá comportarse, obteniendo los requerimientos desde el punto de vista del usuario.

En todo caso de uso siempre hay un actor, que es quien inicia, y luego otro actor (que puede ser el mismo que inicia el caso de uso o puede ser otro diferente), que recibirá algo por parte del sistema.

Retirar Efectivo

Actores primarios:

Cliente del Banco, Consorcio, Banco

Interesados y Objetivos:

Cliente del Banco: quiere retirar dinero de manera rápida, quiere que se anote la transacción en su cuenta de manera correcta, quiere la devolución de su tarjeta y quizá un recibo de la transacción.

Consorcio: Quiere identificar correctamente el banco del cliente y mediar en la transacción de manera eficaz.

Banco: Quiere identificar correctamente la cuenta del cliente, y anotar la transacción.

Precondiciones:

El cliente tiene una cuenta en uno de los bancos del consorcio, consorcio, ha introducido su tarjeta, y contraseña, y ésta se ha validado correctamente por el banco correspondiente. El cliente selecciona retirar efectivo.

Garantía de éxito (post-condiciones):

El cliente obtiene su dinero, la transacción se anota.

Escenario Principal de Éxito:

1. El ATM pide al cliente que teclee la cantidad.

2. El cliente teclea una cantidad.

3. El ATM comprueba que la cantidad está dentro de los límites.

4 El ATM genera una transacción y la envía al consorcio.

5. El consorcio pasa la transacción al banco.

6. El banco aprueba la transacción.

7 El banco actualiza la cuenta.

8. El banco envía al consorcio la notificación de aceptación y el nuevo  saldo de la cuenta.

9 El consorcio envía al ATM la notificación de aceptación y el

10. El ATM entrega el dinero al cliente.

11. El cliente toma el dinero.

12. El ATM pregunta al cliente si quiere un recibo.

13. El cliente contesta SI.

14. El ATM imprime un recibo y pide al cliente que lo tome.

15. El cliente toma el recibo.

16. El ATM pregunta al cliente si quiere hacer otra operación.

17. El cliente contesta NO.

18. El ATM expulsa la tarjeta de crédito e indica al cliente que la tome

19. El cliente toma la tarjeta de crédito.

20. El ATM vuelve a la situación inicial.

Flujos Alternativos:

2a. El cliente pulsa la tecla CANCELAR.

1. El ATM expulsa la tarjeta de crédito e indica al cliente que la tome.

2. El cliente toma la tarjeta de crédito.

3. El ATM vuelve a la situación inicial.

3a. La cantidad excede el límite superior o inferior, se vuelve a 1.

6a. El banco no aprueba la transacción.

1. El banco envía al consorcio la indicación de rechazo.

2. El consorcio envía al ATM la notificación de rechazo.

3. El ATM muestra un mensaje.

4. Se vuelve al caso de uso Realizar Operación para que el usuario seleccione un tipo de transacción.

Descargar presentación aquí.

Reporte Escolar: Primera Jornada Académica de la carrera de Ingeniería en Software

Conferencia: Análisis Forense

Ponente: Mtro. Jorge Agustín Zárate Pérez

El profesor Jorge nos explicó acerca de lo que es el proceso de análisis forense informático. Este proceso es uno de los más cuidadosos en el campo de la seguridad ya que el trabajo realizado puede tener consecuencias civiles o penales para otras personas. Una negligencia en la realización del análisis forense puede tener graves consecuencias.

Para que el analista forense puede realizar la investigación es necesario que siga unos pasos bien definidos, una metodología sistemática, para obtener la máxima información sin dañar los datos originales. La metodología empleada habitualmente se basa a grandes rasgos en los siguientes puntos:

Identificación del evento que desea investigarse.

Examen de las evidencias. Búsqueda de datos, filtrado y recuperación de datos ocultos, cifrados o borrados.

Análisis de las evidencias con el objetivo de alcanzar conclusiones.

Elaboración del informe que incluye el dictamen de la pericia. Asistencia como perito experto al juicio.

¿Qué es el “análisis forense informático”?

Es la conservación, identificación, extracción, análisis e interpretación de información digital con la expectativa de que los hallazgos se utilicen en la corte.

Habilidades

Revela evidencia directa en la máquina.

Asocia a una maquina con la información. Proporciona pistas para la investigación.

Muestra evidencia que corrobora o refuta alegatos o coartadas. Deja al descubierto evidencia conductual.

Donde encontrar evidencia informática.

Confiscar artículos que se detallan en la orden de cateo.

Computadoras, laptops, equipo de red (conectores e interruptores).

Periféricos: CDR, DVD-R, cámara digitales, PDA. Medios externos: CD, diskettes, memorias USB.

Notas en papel, documentos y manuales, notas auto adheribles. Antes de moverlo, documente el equipo y los periféricos. Fotografías digitales, diagramas.

¿Qué puede encontrar el analista o que le es de utilidad?

Archivos borrados.

Fragmentos de texto.

Meta archivos mejorados (archivos que se imprimieron). Meta datos mejorados (información insertada). Información en el registro de hora y fecha Mensajes de correo electrónico e historiales de conversación. Información sobre el uso del Internet (historial).

Ficheros archivados y archivos comprimidos (Zip).

Archivos codificados adjuntos a mensajes de correo electrónico. Imágenes (activas y borradas.

¿Quiénes son los intrusos? Outsiders and insiders en la actualidad hay un amplio rango de intrusos script kiddies delincuentes de cuello blanco y crimen organizado falso estereotipo del cracker intruso.

Principios forenses: Minimizar los pérdida de datos Registrar todo Verificación Descripción del sistema Recolección de evidencia Creación y análisis de una línea del tiempo

Taller: Modelado en 3D

Ponente: Mtro. Lázaro Hernández Camaño

El profesor Lázaro nos enseñó a realizar modelado de funciones en tres dimensiones. Explico que de manera general, algunos lenguajes de programación y sus compiladores ya tienen bibliotecas predefinidas para realizar esto, pero nos enseñaría el principio básico de esta programación.

Primero nos dio una explicación matemática de lo que haríamos en computadora, ya que matemáticamente se puede modelar una función en tres dimensiones (x, y, z), pero la computadora solo tiene dos ejes ya hay que transformar los tres ejes a dos solamente.

Entonces lo primero que hicimos fue crear una malla, que simulara ser tridimensional dentro de la computadora, así, de cierta forma al pasarle una función, ésta podría ser modelada en tres dimensiones. Hay que entender que cada vector en cada dimensión (xy, yz, zx) se mueve de diferente manera, pero z, como dije antes, no existe en la computadora porque esta solo tiene dos ejes, se debe simular, por lo tanto es necesario saber cuáles son sus funciones en el modelado, para simularlas en la computadora.

Después de crear la malla “tridimensional” por medio de fórmulas matemáticas (algo complejas para explicarlas), solo se le pasa una función matemática, sea la que sea y que este en función de “x” e “y”, entonces esta se puede graficar en tres dimensiones.

Diagramas (Resumen)

Resumen del capítulo 7 del libro Lenguaje Unificado de Modelado (UML)

Un diagrama es una representación gráfica de elementos que se dibujan con un grafo convexo de nodos (elementos) y arcos (relaciones).Con UML se construyen bloques de construcción como son clases, interfaces, nodos, generalizaciones, especificaciones, asociaciones, etc.

Los diagramas son estos medios para ver a estos bloques y a la vez nos ayudan a visualizar un sistema desde diferentes perspectivas.

En el contexto de software hay cinco vistas complementarias que son las más importantes para visualizar, especificar, construir y documentar una arquitectura en software.

• ·         La vista de caso de usos
• ·         La vista de diseño
• ·         La vista de procesos
• ·         La vista de implementación
• ·         La vista de despliegue

Cada una de estas vistas involucra modelado estructural, así como un modelo de comportamiento. Cada una de estas vistas permite centrar la atención en una perspectiva del sistema para poder razonar con claridad sobre las decisiones.

Un modelo es una abstracción semánticamente cerrada en un sistema, representa una simplificación completa y auto consistente de la realidad.

Un diagrama es sólo una proyección gráfica de los elementos que configuran un sistema.

Las partes estéticas de un sistema se representaran mediante uno de los cuatro diagramas siguientes:

• ·         Diagrama de clases
• ·         Diagrama de objeto
• ·         Diagrama de componentes
• ·         Diagramas de despliegue

Y para las partes estáticas se emplearán cinco diagramas adicionales

• ·         Diagramas de caso de uso
• ·         Diagramas de secuencia
• ·         Diagramas de colaboración
• ·         Diagramas de estados
• ·         Diagramas de actividades

Cada diagrama debe tener un nombre único en su contexto, que puede referirse a un diagrama específico y distinguir uno de otros.

En un mismo diagrama pueden representarse cualquier combinación de elementos de UML.

Diagramas estructurales

Los cuatro diagramas estructurales en UML existen para visualizar, especificar, construir y documentar los aspectos estáticos del sistema.

Los diagramas estructurales en UML se organizan en líneas generales alrededor de los principales grupos de elementos que aparecen al modelar un sistema.1.

• 1.    Diagrama de clases <- clases, interfaces y colaboraciones
• 2.    Diagrama de objetos <- objetos
• 3.    Diagrama de componentes <- componentes
• 4.    Diagramas de despliegue <- Nodos

Diagrama de clases. Un diagrama de clases presenta un conjunto de clases, interfaces, y colaboraciones y relaciones entre ellas. Los diagramas de clases se utilizan para describir la vista de diseño estático de un sistema.

Incluyen clases activas se utilizan para cubrir la vista de procesos estática de un sistema.

Diagrama de objetos. Un diagrama de objetos representa un conjunto de objetos y sus relaciones. Se utilizan para describir estructuras de datos, instantáneas de los elementos encontrados en los diagramas de clases. Cubren la vista de diseño estática o la vista de procesos estática de un sistema al igual que los diagramas de clases desde la perspectiva de casos reales o prototípicos.

Diagramas de componentes. Un diagrama de componentes muestra un conjunto de componentes y sus relaciones.

Se utilizan para describir a vista de implementación estática de un sistema.

Se relacionan con los diagramas de clases en que un componente se corresponde con una o más clases, interfaces o colaboraciones.

Diagramas de despliegue. Un diagrama de despliegue muestra un conjunto de nodos y sus relaciones.

Se utilizan para describir la vista de despliegue estática de una arquitectura. Se relacionan con los diagramas de los componentes en que un nodo normalmente incluye uno o más componentes.

Diagramas de comportamiento

Los diagramas de comportamiento de UML se organizan en líneas generales alrededor delas formas principales en las que se puede modelar la dinámica de un sistema.

• 1.    Diagramas de caso de uso <- organiza los comportamientos del sistema
• 2.    Diagramas de secuencia <- centrados en la ordenación temporal de los mensajes
• 3.    Diagramas de colaboración <- centrados en la organización estructural delos objetos que enviar y recibir mensajes
• 4.    Diagramas de estados <- centrados en el estado cambiante de un sistema dirigido por eventos
• 5.    Diagramas de actividades <- centrados en el flujo de control de actividades

Diagramas de caso de uso: Representa un conjunto de casos de uso y sus actores y sus relaciones.

Se utilizan para describir la vista de casos de uso estática de un sistema.

Son especialmente importantes para organizar y modelar el comportamiento del sistema.

El nombre colectivo que se da a los diagramas de secuencia y os diagramas de colaboración es el diagrama de iteración.

Diagramas de secuencia. Un diagrama de secuencia es un diagrama de interacción que resalta la ordenación temporal de los mensajes.

Presenta un conjunto de objetos y los mensajes enviados y recibidos por ellos.

Los objetos suelen ser instancias con nombre o anónimas de clases pero también pueden representar instancias de otros elementos tales como colaboraciones, componentes y nodos.

Se utilizan para describir un sistema.

Diagramas de colaboración. Un diagrama de colaboración es un diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben mensajes.

Muestra un conjunto de objetos, enlaces entre esos objetos.

Diagrama de estados.

Representa una máquina de estados, transiciones eventos y actividades.

Se utilizan para describir la vista dinámica de un sistema. Son especialmente importantes para modelar el comportamiento de una interfaz, una clase o una colaboración.

Diagramas de actividades. Muestra el flujo de actividades de un sistema. Una actividad muestra un conjunto de actividades y los objetos que actúan.

Se utilizan para ilustrar la vista dinámica de un sistema.

Son importantes para modelar la función de un sistema así como para resaltar el flujo de control entre objetos.

Técnicas de comunes de modelado

Modelado de diferentes vistas de un sistema.

Para modelar un sistema de desde diferentes vistas es necesario:

• ·         Decidir que vistas se necesitan para expresar mejor la arquitectura de sistema.
• ·         Definir qué artefactos se necesitan crear para capturar los detalles esenciales.
• ·         Decidir cuáles son los diagramas se pondrá bajo un tipo de control.

Modelado de diferentes niveles de abstracción

Hay que considerar las necesidades de las personas que utilizaran el diagrama y comenzar con un determinado modelo.

Se debe crear un diagrama de nivel de abstracción que tendrá que revelar muchos detalles, tomando en cuenta las cuatro categorías siguientes de los elementos del modelo.

• ·         Bloques de construcción y relaciones.
• ·         Adornos
• ·         Flujo
• ·         Estereotipos

Ejemplos de Diagramado UML

Se desea diseñar un diagrama de clases sobre la información de las reservas de una empresa dedicada al alquiler de automóviles, teniendo en cuenta que:

• Un determinado cliente puede tener en un momento dado hechas varias reservas.
• De cada cliente se desean almacenar su DNI, nombre, dirección y teléfono. Además dos clientes se diferencian por un código único.
• Cada cliente puede ser avalado por otro cliente de la empresa.
• Una reserva la realiza un único cliente pero puede involucrar varios coches.
• Es importante registrar la fecha de inicio y final de la reserva, el precio del alquiler de cada uno de los coches, los litros de gasolina en el depósito en el momento de realizar la reserva, el precio total de la reserva y un indicador de si el coche o los coches han sido entregados.
• Todo coche tiene siempre asignado un determinado garaje que no puede cambiar. De cada coche se requiere la matricula, el modelo el color y la marca.
• Cada reserva se realiza en una determinada agencia.

      El Ministerio de Defensa desea diseñar una Base de Datos para llevar un cierto control de los soldados que realizan el servicio militar. Los datos significativos a tener en cuenta son:

•  Un soldado se define por su código de soldado (único), su nombre y apellidos, y su graduación.
•  Existen varios cuarteles, cada uno se define por su código de cuartel, nombre y ubicación.
• Hay que tener en cuenta que existen diferentes Cuerpos del Ejército (Infantería, Artillería, Armada, ....), y cada uno se define por un código de Cuerpo y denominación.
• Los soldados están agrupados en compañías, siendo significativa para cada una de éstas, el número de compañía y la actividad principal que realiza.
• Se desea controlar los servicios que realizan los soldados (guardias, imaginarias, cuarteleros, ...), y se definen por el código de servicio y descripción

Consideraciones de diseño:

• Un soldado pertenece a un único cuerpo y a una única compañía, durante todo el servicio militar. A una compañía pueden pertenecer soldados de diferentes cuerpos, no habiendo relación directa entre compañías y cuerpos.
• Los soldados de una misma compañía pueden estar destinados en diferentes cuarteles, es decir, una compañía puede estar ubicada en varios cuarteles, y en un cuartel puede haber varias compañías. Eso si, un soldado sólo esta en un cuartel.        
• Un soldado realiza varios servicios a lo largo de la milicia. Un mismo servicio puede ser realizado por más de un soldado (con independencia de la compañía), siendo significativa la fecha de realización.

La Policía quiere crear una base de datos sobre la seguridad en algunas entidades bancarias. Para ello tiene en cuenta:

•         Que cada entidad bancaria se caracteriza por un código y por el domicilio de su Central.
•       Que cada entidad bancaria tiene más de una sucursal que también se caracteriza por un código y por el domicilio, así como por el número de empleados de dicha sucursal.
•        Que cada sucursal contrata, según el día, algunos vigilantes jurados, que se caracterizan por un código y su edad. Un vigilante puede ser contratado por diferentes sucursales (incluso de diferentes entidades), en distintas fechas y es un dato de interés dicha fecha, así como si se ha contratado con arma o n
•      Por otra parte, se quiere controlar a las personas que han sido detenidas por atracar las sucursales de dichas entidades. Estas personas se definen por una clave (código) y su nombre completo.
•        Alguna de estas personas están integradas en algunas bandas organizadas y por ello se desea saber a qué banda pertenecen, sin ser de interés si la banda ha participado en el delito o no Dichas bandas se definen por un número de banda y por el número de miembros.
•       Así mismo, es interesante saber en qué fecha ha atracado cada persona una sucursal. Evidentemente, una persona puede atracar varias sucursales en diferentes fechas, así como que una sucursal puede ser atracada por varias personas.
•      Igualmente, se quiere saber qué Juez ha estado encargado del caso, sabiendo que un individuo, por diferentes delitos, puede ser juzgado por diferentes jueces. Es de interés saber, en cada delito, si la persona detenida ha sido condenada o no y de haberlo sido, cuánto tiempo pasará en la cárcel. Un Juez se caracteriza por una clave interna del juzgado, su nombre y los años de servicio.

NOTA: En ningún caso interesa saber si un vigilante ha participado en la detención de un atracador.

Un club náutico desea tener informatizados los datos correspondientes a sus instalaciones, empleados, socios y embarcaciones que se encuentran en dicho club. El club está organizado de la siguiente forma:

·         Los socios pertenecientes al club vienen definidos por su nombre, dirección, DNI, teléfono y fecha de ingreso en el club.

·         Las embarcaciones vienen definidas por: matricula, nombre, tipo y dimensiones.

·         Los amarres tienen como datos de interés el número de amarre, la lectura del contador de agua y luz, y si tienen o no servicios de mantenimiento contratados.

·         Por otro lado, hay que tener en cuenta que una embarcación pertenece a un socio aunque un socio puede tener varias embarcaciones. Una embarcación ocupará un amarre y un amarre está ocupado por una sola embarcación. Es importante la fecha en la que una embarcación en asignada a un amarre.

·         Los socios pueden ser propietarios de amarres, siendo importante la fecha de compra del amarre. Hay que tener en cuenta que un amarre pertenece a un solo socio y que NO HAY ninguna relación directa entre la fecha en la que se compra un amarre y en la que una embarcación se asigna a un amarre.

·         El club náutico está dividido en varias zonas definidas por una letra, el tipo de barcos que tiene, el número de barcos que contiene, la profundidad y el ancho de los amarres. Una zona tendrá varios amarres y un amarre pertenece a una sola zona.

·         En cuanto a los empleados, estos vienen definidos por su código, nombre, dirección, teléfono y especialidad. Un empleado está asignado a varias zonas y en una zona puede haber más de un empleado, siendo de interés el número de barcos de los que se encarga en cada zona. Hay que tener en cuenta que un empleado puede no encargarse de todos los barcos de una zona.

Una biblioteca tiene copias de libros. Estos últimos se caracterizan por su nombre, año y autor.

·         Un libro está relacionado con una categoría (novela, teatro, poesía, ensayo) así como también con una editorial.

·         Los autores se caracterizan por su nombre y fecha de nacimiento. Se considera que el autor sólo tiene una nacionalidad.

·         Cada copia tiene un identificador, y puede estar en la biblioteca, prestada, con retraso o en reparación.

·         Los lectores pueden tener un máximo de 3 libros en préstamo.

·         Cada libro se presta un máximo de 30 días, por cada día de retraso, se impone una “multa” de dos días sin posibilidad de coger un nuevo libro.

·         Realiza un diagrama de clases para realizar el préstamo y devolución de libros.