Te damos la bienvenida al blogger american sprint espero que lo disfrutes y adquieras conocimientos y te diviertas satisfaciendo tus necesidades a la hora de investigar y de interactuar con los vídeos y/o juegos que te ofrece esta pagina.

martes, 5 de abril de 2011

Foro de los casos de uso

               Ejercicio

1) Comentar en el foro sobre casos de uso.

               Solución

1)         Casos de Uso.

En ingeniería del software, un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.

Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué). De forma que al ser parte del análisis nos ayudan a describir qué es lo que es sistema debe hacer. Los Casos de Uso son qué hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cómo este interactúa con el usuario.

Si te has enfrentado alguna vez a UML normalmente habrás visto algún diagrama de clases y esperarás que los Casos de Uso sean también una forma visual de representar la información. Sin embargo estás muy equivocado, si bien los casos de usos se pueden agrupar en diagramas, los diagramas no son lo importante. Voy a repetirlo para que quede claro, "Los diagramas no son lo importante". Se que alguno estará impaciente con los diagramas, así que luego los trataré. Pero primero vayamos con lo realmente interesante.

Archivo:Notacion Caso de Uso.svg

Si lo primordial de los casos de uso (use case) no son los diagramas, entonces ¿que es lo importante? Lo realmente útil de los casos de uso es el documento que describe el caso de uso (use case), en este documento se explica la forma de interactuar entre el sistema y el usuario.

  1. Pasos para la Definición de un Caso de Uso:
  • ID
  • NOMBRE
  • REFERENCIAS CRUZADAS
  • CREADO POR
  • ULTIMA ACTUALIZACION POR
  • FECHA DE CREACION
  • FECHA DE ULTIMA ACTUALIZACION
  • ACTORES
  • DESCRIPCION
  • TRIGGER
  • PRE-CONDICION
  • POST-CONDICION
  • FLUJO NORMAL
  • FLUJOS ALTERNATIVOS
  • INCLUDES
  • FRECUENCIA DE USO
  • REGLAS DE NEGOCIO
  • REQUERIMIENTOS ESPECIALES
  • NOTAS Y ASUNTO

Foro de la UML

                    Ejercicio

1) Comentar sobre el foro de la UML

                    Solución


1)           
          UML "lenguaje modular de unidad".

(Unifed Modeling Languaje) El lenguaje para modelamiento unificado (UML), es un lenguaje para la especificación, visualización, construcción y documentación de los artefactos de un proceso de sistema intensivo. Fue originalmente concebido por la Corporación Rational Software y tres de los más prominentes métodologistas en la industria de la tecnología y sistemas de información: Grady Booch, James Rumbaugh, y Ivar Jacobson (“The Three Amigos”). El lenguaje ha ganado un significante soporte de la industria de varias organizaciones vía el consorcio de socios de UML y ha sido presentado al Object Management Group (OMG) y aprobado por éste como un estándar (noviembre 17 de 1997).

Estereotipo de la UML:

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.

  • Para ello utiliza varios tipos diferentes de diagramas, por ejemplo, en UML 2.0 hay 13 tipos de diagramas. Estos diagramas se pueden diferenciar en tres categorías:


- Diagramas de estructura:

Diagrama de clases
Diagrama de componentes
Diagrama de objetos
Diagrama de estructura compuesta (UML 2.0)
Diagrama de despliegue
Diagrama de paquetes

-Diagramas de comportamiento:

Diagrama de actividades
Diagrama de casos de uso
Diagrama de estados

-Diagramas de interacción:

Diagrama de secuencia
Diagrama de comunicación
Diagrama de tiempos (UML 2.0)
Diagrama de vista de interacción (UML 2.0)

"Algunos programas gratuitos para modelar en UML son:"

ArgoUML, Dia, gModeler, MonoUML, StarUML, TCM, Umbrello Herramienta, UMLet.


lunes, 4 de abril de 2011

Tipos de vistas de la UML

                         Ejercicio

1) Enumere los tipos de vistas de la UML

                          Solución

1)      
               Tipos de vistas de la UML

1)  Vista estatica: La vista estatica  modela los conceptos del domino de la aplicación, asi como los conceptos internos inventados como parte de la implementación de la aplicación. esta visión es estatica porque no describe el comportamiento del sistema dependiente del tiempo, que se describe en otras vistas  los componentes principales de la vista estática son las clases y sus relaciones: asociación, generación, y varias clases de dependencia, tales como realización de uso.

2)  Vistas de los casos de uso: La vista de los casos de uso modela el sistema  según lo perciben los usuarios externos, llamados actores. un caso de uso es una unidad coherente de funcionalidad, expresada como transaacción entre los actores y el sistema. el prposito de la vista de casos de uso es enumerar a los actores y los casos de uso, y demostrar que actores paraticpan en cada caso de uso.

3)  vista de interacción: La vista de interacción describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema. un rol de clasificador, o simplemente "rol" es una descripción de un objeto, que desempeña un determinado papel dentro de unainteracción, distinto de los objetos de la misma clase.

4) Vistas de maquinas de estados: Una máquina de estados de uso modela las posibles historias de vida de un objeto de una clase. una máquina de estados contiene los estados conectados por transacciones. cada estado modela un periodo de tiempo, durante la vida de un objeto, en el que satisface ciertas condiciones. cuando ocurre un evento, se puede desencantar una transacción que lleve el objeto a un nuevo estado.


5) Vistas de actividades: Un grafo de actividades es una variante de ua maquina de estados, que muestra las actividades de computación implicados en la ejecucíon  de un calculo. un estado de actividad representa una actividad: un paso en el flujo de trabajo o la ejecución de una operación. un grafo de actividades describe grupos secuenciales y concurrentes de actividades. los grafos de actividades se muestran en diagramas de actividades.

6) Vistas fisicas: Las vistas anteriores modelan los conceptos de la aplicación desde un punto de vista lógico. las vistas físicas modelan las estructuras de la implementación de la aplicación por si misma, su organización en componentes, y su despliegue en modos de ejecución.estas vistas proporcionan una oprtunidad de establecer correspondencias entre las clases y los componentes de implementación y modos.  

7) Vistas de gestión de modelo: La vista de gestión de modelo modela la organización del modelo en sí mismo. un modelo abarca un conjunto de paqutes que contiene los elementos del modelo, tales como clases,máquinas de estados, y casos de uso. los paquetes pueden contener otros paquetes: por lo tanto, un modelo señala un paquete raíz, que contiene indirectamente todo el contenido del modelo.


Comportamiento dinámico de la UML

                Ejercicio

1) Que es un comportamiento dinámico de la UML

                Solución

1)
      Comportamiento dinámico de la UML

El compotamiento dinamico describe el comportamiento de un sistema en el tiempo. el comportamiento se´puede describir como una serie de cambios a las fotos de un sistema dibujadas a partir de la visión estatica. las vistas de comportamiento dinamico incluyen vista de la maquina de estados, la vista de actividad, y la vista de interacción.




Vistas de la UML

                  Ejercicio

1) que es una vista de la UML

                    Solución

1)          
                Vistas de la UML.

No hay ninguna linea entre los difrentes conceptos y las construcciones en UML, pero por conveniencia nosotros los dividimos en varias vistas. una vista es simplemente un subconjunto de UML , que modela construcciones que representan un aspecto de un sitema. la división en diversas vistas es algo arbitraria, pero esperamos que sea intuitiva. la gestión del modelo  describe la organización de los propios modelos en unidades jerárquicas. el paquete es la unidad generíca de organización para los modelos. Los paquetes especiales incluyen a los modelos y a los subsistemas. La vista de gestión del modelo cruza las otras vistas y las organiza para el trabajo de desarrollo y el control de configuración.

 


Significado de un modelo

                   
                      Ejercicio
1.) Diga el Significado de un modelo
             
                         Solución
1)                      
            Significado de un modelo.
    Un modelo es un generador de potenciales  configuraciones de sistemas,los posibles sistemas son sus extensiones o valores. idealmente, todas las configuraciones consistentes con el modelo deberian ser posibles. a veces, sin embargo, no es posible representar todas las restricciones dentro de un modelo. un modelo es también una descripción de la estructura generíca y del significado de un sistema.


domingo, 3 de abril de 2011

Funcionamiento de la UML

                       
                      Ejercicio
1) Para que sirven los modelos. Enumere.
                      Solución
     A) Funcionamiento: Los modelos se usan para muchos propositos:
1) Para capatar y enumerar exhautivamente los requisitos y el dominio de conocimiento, de forma que todos los implicados puedan entenderlos y estar con ellos. los diversos modelos de un sistema de sosftware pueden capturar requisitos sobre su dominio de aplicación, las formas en que los usuarios,lo utilizarán, su división en modulos, los patrones  comunes usados en su construcción, y otras cosas. Los implicados incluyen al arquitecto, a los analistas, a los programadores,al encargo del pryecto, alos clientes, alos inversores, alos usuarios finales, y alos operadores. 

2) Para pensar en un diseño de un sistema: un modelo de un sistema software ayuda  a los desarroladores a explorar varias arquitecturas y soluciones de diseño facilmente antes de escribir un codigo. un buen lenguaje de modelado permite que el diseñador consiga la arquitectura correcta antes de que comience el diseño tallado.

3) Para capturar decisiones del diseño en una forma mutable a aprtir de los requisitos: Un modelo de un sistema software puede captar el comportamiento externo de un sistema y la información del dominio del mundo real representado por el sistema. otro modelo muestra las clases y las operaciones internas,que implementan el comportamiento externo. hay muchas maneras de implementar el comportamiento, el modelo final de disño muestra un acercamiento que el diseñador cree correcto.

4) Para generar productos aprovechables para el trabajo: Un modelo de un sistema software se puede utilizar para generar las declaraciones de clase,los cuerpos de procedimiento,las interfaces de usuario,las bases de datos, los escenarios de uso válidos o los guiones de configuración.




5) Para organizar, encontrar, filtrar ,recuperar, examinar, y corregir la información en grandes sistemas: un modelo de sistema de software organiza la información en varias vistas: estructura estatica, maquinas de estado, interacciones, requisitos etc. cada vista es una proyección del modelo completo para un propósito determinado. mantener un modelo, de cualquier tamaño, es imposible sin tener una herramienta de edición, que maneje el modelo.

6) Para explorar económicamente múltiples soluciones: Las ventajas y los riesgos de diversos métodos de diseño de un sistema grande permiten  que se proponga y comparen varios diseños. Los modelos no se construyen al detalle, por supuesto, pero incluso un modelo rudimentario puede exponer muchas cuestiones que el diseño  final debe tener en cuenta. modelar permite considerar varios diseños, con un coste pequeño al implementar cualquiera de ellos.

7) Para domesticar los sistemas complejos: un modelo de sistema software grande permiote ocuparse de la complegidad que es demasiado dificil de tratar directamente. un modelo se puede abstener a un nivel que sea comprensible a los seres humanos sin perder detalles. un modelo puede determinar el impacto potencial de un cambio antes de que se haga, explorando dependencias en el sistema.

Modelo de la UML

                          Ejercicio

1) Que es un modelo de la UML

                        Solución

1) Modelo de la UML: un modelo es una representación grafica, en cierto medio de algo en el mismo u otro medio.el modelo capta los aspectos importantes de lo que estamos modelando, desde cierto punto de vista, y simplifica u omite el resto. la ingenieria, la arquitectura, y muchos otros campos creativos usan modelos.

Un modelo de un sistema de software esta constituido por en un lenguaje de modelado, como UML. el modelo tiene sematica y notación y puede adoptar varios formatos que incluyen texto y graficos. el modelo pretende ser mas fácil de usar para ciertos propósitos que el sistema final.

martes, 29 de marzo de 2011

Tipos de diagramas de la UML


                    Ejercicio
1) Enumere los tipos de diagrama de UML y defínalos? (copie en el blog la imagen que se encuentra  en Wikipedia).        
              
         Solución
1)   Diagramas de la UML:

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha.

1) Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:
  • Diagrama de clases
  • Diagrama de componentes
  •  Diagrama de objetos
  • Diagrama de estructura compuesta (UML 2.0)
  • Diagrama de despliegue
  • Diagrama de paquetes
1) 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

Archivo:Diagrama de clases.svg

2) 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.
Debido a que estos son más parecidos a los diagramas de casos de usos estos son utilizados para modelar la vista estática y dinamica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.

 


3) 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.

4) Un diagrama de estructura compuesta es un tipo de diagrama de estructura estática en el Lenguaje de Modelado Unificado (UML), que muestra la estructura interna de una clase y las colaboraciones que esta estructura hace posibles. Esto puede incluir partes internas, puertas mediante las cuales, las partes interactúan con cada una de las otras o mediante las cuales, instancias de la clase interactúan con las partes y con el mundo exterior, y conectores entre partes o puertas. Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de ejecución para lograr algún propósito. Cada elemento tiene algún rol definido en la colaboración.

 5) El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.
Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.
En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo.
Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un cluster de terminales.

Archivo:UML Deployment Diagram.svg
 6) El diagrama de paquetes muestra cómo un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema.
Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.


 
 2)   Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:
  • Diagrama de actividades
  • Diagrama de casos de uso
  • Diagrama de estados

1) diagrama de actividades:En el Lenguaje de Modelado Unificado, un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.
En SysML el diagrama de Actividades ha sido extendido para indicar flujos entre pasos que mueven elementos físicos (e.g., gasolina) o energía (e.g., presión). Los cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos.


2) diagrama de casos de uso :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.


3)  diagrama de estados: En UML, un diagrama de estados es un diagrama utilizado para identificar cada una de las rutas o caminos que puede tomar un flujo de información luego de ejecutarse cada proceso.
Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y en qué momento podrían tener una variación.
El diagrama de estados permite visualizar de una forma secuencial la ejecución de cada uno de los procesos.


3) Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:
  • Diagrama de secuencia
  • Diagrama de comunicación, que es una versión simplificada del Diagrama de colaboración (UML 1.x)
  • Diagrama de tiempos (UML 2.0)
  • Diagrama global de interacciones o Diagrama de vista de interacción (UML 2.0)

 El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"


               

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes

2) diagrama de comunicación: 
Un diagrama de comunicación modela las interacciones entre objetos o partes en términos de mensajes en secuencia. Los diagramas de comunicación representan una combinación de información tomada desde el diagrama de clases, secuencia, y diagrama de casos de uso describiendo tanto la estructura estática como el comportamiento dinámico de un sistema.
Los diagramas de comunicación y de secuencia describen información similar, y con ciertas transformaciones, pueden ser transformados unos en otros sin dificultad.
Para mantener el orden de los mensajes en un diagrama de comunicación, los mensajes son etiquetados con un número cronológico y colocados cerca del enlace por el cual se desplaza el mensaje. Leer un diagrama de comunicación conlleva comenzar en el mensaje 1.0, y seguir los mensajes desde un objeto hasta el siguiente, sucesivamente.

3) Un diagrama de tiempos o cronograma es una gráfica de formas de onda digitales que muestra la relación temporal entre varias señales, y cómo varía cada señal en relación a las demás.

Archivo:Diagrama de tiempos.png

4) Un diagrama global de las interacciones (en inglés: interaction overview diagram) es una de las trece clases de diagramas en el Lenguaje de Modelado Unificado (UML), un lenguaje de modelamiento para software y otros sistemas.

Descripción:
El diagrama global de las interacciones es un diagrama de comportamiento, más precisamente, uno de los cuatro diagramas de interacción. Muestra una cierta vista sobre los aspectos dinámicos de los sistemas modelados. Aunque un diagrama global de las interacciones es una representación gráfica de una interacción, éste se distingue fuertemente de los diagramas de secuencia y de comunicación, dos de los otros diagramas de interacción. De hecho, algunos elementos gráficos del diagrama global de las interacciones están tomados del diagrama de actividades, otro diagrama de comportamiento para el modelado de actividades.
Archivo:Iau-diagramm-1.png


Un cronograma puede contener cualquier número de señales relacionadas entre sí. Examinando un diagrama de tiempos, se puede determinar los estados, nivel alto o nivel bajo, de cada una de las señales en cualquier instante de tiempo especificado, y el instante exacto en que cualquiera de las señales cambia de estado con respecto a las restantes.
El propósito primario del diagrama de tiempos es mostrar los cambios en el estado o la condición de una línea de vida (representando una Instancia de un Clasificador o un Rol de un clasificador) a lo largo del tiempo lineal. El uso más común es mostrar el cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estímulos aceptados. Los eventos que se reciben se anotan, a medida que muestran cuándo se desea mostrar el evento que causa el cambio en la condición o en el estado.

finalidad del diagrama

               Ejercicio
1) ¿Que es un diagrama y cual es su finalidad?.
               
                 Solución
1)            
             DIAGRAMAS DE LA UML
Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En concre-to, un diagrama ofrece una vista del sistema a mode-lar. Para poder representar correctamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas. UML incluye los siguientes diagramas:



                
                • Diagrama de casos de uso.
                 • Diagrama de clases.
                 • Diagrama de objetos.
                 • Diagrama de secuencia.  
                 • Diagrama de colaboración.
                 • Diagrama de estados.
                 • Diagrama de actividades.
                 • Diagrama de componentes.
                 • Diagrama de despliegue.

Los diagramas más interesantes (y los más usados) son los de casos de uso, clases y secuencia, por lo que nos centraremos en éstos. Pare ello, se utilizará ejem-plos de un sistema de venta de entradas de cine por Internet.  

Objetivos de la UML.

                  Ejercicio
1) Escribe los Objetivos de la UML.
                     Solución
1)     
              Objetivos de la UML.
Otro objetivo de este modelado visual es que sea independiente del lenguaje de implementación, de tal forma que los diseños realizados usando UML se pueda implementar en cualquier lenguaje que soporte las posibilidades de UML (principalmente lenguajes orientados a objetos).
UML es además un método formal de modelado. Esto aporta las siguientes ventajas:

      • Mayor rigor en la especificación.

      • Permite realizar una verificación y validación del modelo realizado.

     • Se pueden automatizar determinados procesos y permite generar código a partir de los mode-los y a la inversa (a partir del código fuente ge-nerar los modelos). Esto permite que el modelo y el código estén actualizados, con lo que siem-pre se puede mantener la visión en el diseño, de más alto nivel, de la estructura de un proyecto.

historia de la UML

                       Ejercicio
1) Breve resumen de la historia del UML.
                        Soluciòn
1)                 
                 HISTORIA DE LA UML
 
El lenguaje UML comenzó a gestarse en octubre de 1994 [1], cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investiga-dores en el área de metodología del software). El ob-jetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Mode-lling Tool ). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas su-yas. Estas tres personas son conocidas como los "tres amigos". Además, este lenguaje se abrió a la colabora-ción de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML.


Esta primera versión se ofreció a un grupo de tra-bajo para convertirlo en 1997 en un estándar del OMG (Object Management Group http://www.omg.org). Este grupo, que gestiona estándares relacionados con la tecnología orientada a objetos (metodologías, bases de datos objetuales, CORBA, etc.), propuso una serie de modificaciones y una nueva versión de UML (la 1.1), que fue adoptada por el OMG como estándar en noviembre de 1997. Desde aquella versión han habido varias revisiones que gestiona la OMG Revision Task Force. La última versión aprobada es la 1.4. En estos momentos se está desarrollando una nueva versión en la que se incluirán cambios importantes (principalmente añadir nuevos diagramas) que conducirán a la versión 2.0 planificada para fines del 2002.

necesidad de la UML

                              Ejercicio
1) ¿Porque es necesario el UML?
                             Solución
1) Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros desarrolladores sino tam-bién para servir de apoyo en los procesos de análisis de un problema. Con este objetivo se creo el Lenguaje Unificado de Modelado (UML: Unified Modeling Lan-guage). UML se ha convertido en ese estándar tan an-siado para representar y modelar la información con la que se trabaja en las fases de análisis y, especialmente, de diseño.

UML "Unidad modular del lenguaje"

                                 ejercicio

1) ¿Que es la UML?

                                   soluciòn

1) El lenguaje UML "Unidad modular del lenguaje"  tiene una notación gráfica muy expresiva que permite representar en mayor o menor medida todas las fases de un proyecto informático: desde el análisis con los casos de uso, el diseño con los diagramas de clases, objetos, etc., hasta la imple-mentación y configuración con los diagramas de des-pliegue.


 

UML es ante todo un lenguaje. Un lenguaje pro-porciona un vocabulario y una reglas para permitir una comunicación. En este caso, este lenguaje se cen-tra en la representación gráfica de un sistema.
Este lenguaje nos indica cómo crear y leer los mo-delos, pero no dice cómo crearlos. Esto último es el objetivo de las metodologías de desarrollo.
Las objetivos de UML son muchos, pero se pue-den sintetizar sus funciones:

           • Visualizar: UML permite expresar de una for-ma gráfica un sistema de forma que otro  lo puede entender.
           
            • Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción.
           
           • Construir: A partir de los modelos especifica-dos se pueden construir los sistemas diseñados.

          • Documentar: Los propios elementos gráficos sirven como documentación del sistema des-arrollado que pueden servir para su futura re-visión.
 

domingo, 27 de marzo de 2011

Requerimientos funcionales y no funcionales

                             Ejercicio

1) Realiza 10 ejemplos de requerimientos funcionales y 10 requerimientos no funcionales

                            Solución

1)  Requerimientos funcionales:


2)  Requerimientos no funcionales:



martes, 22 de marzo de 2011

Determinación de Requerimientos

                        Ejercicio 
1) Elaborar un mapa conceptual con el tema de la determinación de requerimientos.


                        Solución
1)  Determinación de requerimientos.


Estadística de las preguntas

                       Ejercicio 
1) Elaborar 10 gráficas de las 10 preguntas correspondientes a la encuesta realizada anteriormente


                         Solución 
1) Gráficas de las encuestas:


   1) Encuesta # 1:




   2) Encuesta # 2:


3) Encuesta # 3: 


4) Encuesta # 4:


5) Encuesta # 5: 




6) Encuesta # 6:


7) Encuesta # 7:


8) Encuesta # 8:


9) Encuesta # 9: 


10) Encuesta # 10: