Archive for junio, 2010


Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

Principios de desarrollo

  • Adaptar el proceso
    El proceso deberá adaptarse a las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subformal.
  • Equilibrar prioridades
    Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.
  • Demostrar valor iterativamente
    Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados
  • Colaboración entre equipos
    El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.
  • Elevar el nivel de abstracción
    Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.
  • Enfocarse en la calidad
    El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente. 

Principales características

  • Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
  • Pretende implementar las mejores prácticas en Ingeniería de Software
  • Desarrollo iterativo
  • Administración de requisitos
  • Uso de arquitectura basada en componentes
  • Control de cambios
  • Modelado visual del software
  • Verificación de la calidad del software

Fuente: Wikipedia (http://es.wikipedia.org/wiki/RUP)

Anuncios

Un diagrama de flujo de datos (DFD por sus siglas en español e inglés) es una representación gráfica del “flujo” de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas. Este contexto a nivel de DFD se “explotó” para mostrar más detalles del sistema que se está modelando.

Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador original del diseño estructurado, basado en el modelo de computación de Martin y Estrin: “flujo gráfico de datos” . Los diagramas de flujo de datos (DFD) son una de las tres perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador de un proyecto y los usuarios finales tendrán que ser informados y consultados en todas las etapas de una evolución del sistema. Con un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que el sistema funcione, lo que el sistema va a lograr, y cómo el sistema se pondrá en práctica. El antiguo sistema de diagramas de flujo de datos puede ser elaborado y se comparó con el nuevo sistema de diagramas de flujo para establecer diferencias y mejoras a aplicar para desarrollar un sistema más eficiente. Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario final una idea física de cómo resultarán los datos a última instancia, y cómo tienen un efecto sobre la estructura de todo el sistema. La manera en que cualquier sistema es desarrollado puede determinarse a través de un diagrama de flujo de datos. El desarrollo de un DFD ayuda en la identificación de los datos de la transacción en el modelo de datos.

Fuente: Wikipedia (http://es.wikipedia.org/wiki/DFD)

Ejemplo 1:
Procesamiento de Esquelas

Ejemplo 2:
Facturacion

Ejemplo 3:

UML es un conjunto de herramientas, que permite modelar, analizar y diseñar sistemas orientados a objetos.  No es la única notación que existe, pero es el estándar actual del llamado Object Management Group (OMG)

UML se expresa a través de elementos de construcción, de relaciones y de diagramas que contienen elementos y relaciones. Conocer esta estructura general ayuda a la comprensión del lenguaje en su conjunto y facilita prescindir de los detalles, hasta que no sean necesarios.

Bloques de Construcción UML

  • Elementos
  • Relaciones
  • Diagramas

Elementos 

Hay cuatro tipos de elementos en UML

  1. Elementos estructurales: son la parte estática de los modelos de UML. Representan cosas que son conceptuales o materiales. Hay siete tipos de elementos estructurales:

    Clase: Representa un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.

    Interfaz: Define un conjunto de especificaciones de operaciones.

    Colaboración: Define una iteración y es una sociedad de roles y otros elementos que colaboran  cooperativamente.

    Caso de uso: Conjunto de secuencia de acciones que se ejecutan y el resultado es de interés para un actor en particular.

    Clase activa: Son similares a las clases excepto que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos.

    Componente: Es empaquetamiento físico de diferentes elementos lógicos como clases, interfaces, y colaboraciones.

    Nodo: Es elemento físico es decir un recurso computacional.

  2. Elementos de comportamiento: Son las partes dinámicas de los modelos. Representan comportamiento en el tiempo y en el espacio. Hay dos tipos de elementos de comportamiento:

    Interacciones: Conjunto de mensajes intercambiados entre objetos.

    Estado: Identifica un período de tiempo del objeto (no instantáneo) en el cual el objeto esta esperando alguna operación, recibe cierto tipo de estímulos y especifica la secuencia de estado por las que pasa un objeto.

  3. Elementos de agrupación: Son las partes organizativas de los modelos de UML, es decir, las cajas en las que puede descomponerse un modelo. Sólo hay un elemento de agrupación.

    Paquete: Mecanismo de propósito general para organizar elementos.

  4. Elementos de anotación: Son la parte explicativa de los modelos de UML. Son comentarios que se pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo.

    Nota: Sirve para hacer comentarios a un conjunto de elementos.

Relaciones

  Hay cuatro tipos de relaciones en UML:

  1. Dependencia: Relación entre dos elementos uno independiente a otro dependiente y puede afectar la semántica.
  2. Generalización: Son conexiones entre objetos (rol, multiplicidad, calificador).
  3. Asociación: Especificación en donde el hijo comparte la estructura y el comportamiento del padre.
  4. Realización: Es una relación semántica entre clasificadores.

Diagramas

  1. Diagrama de Caso de Uso

    Un diagrama de Casos de Uso 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. Está 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.Un Diagrama de Casos de Uso 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

    Composición

    Actor: Un actor representa quien o que inicia una acción dentro del sistema, en otras palabras, es simplemente un rol que es llevado acabo por una persona o cosa. Un Actor en un diagrama Casos de Usos es representado por una figura en forma de persona.
    Uso-Caso: El uso-caso en sí es representado por un ovalo que describe la funcionalidad a grosso modo que se requiere por el sistema.
    Comunicación: Este elemento representa la relación que existe entre un Uso-Caso y un Actor, dicho elemento es representado simplemente por una linea recta que se extiende de la figura del actor hacia el ovalo del uso-caso.
    Limite de Sistema (System Boundry): Empleado para delimitar los limites del sistema, y representado por un rectángulo con color de fondo distintivo.
    Generalización : Una generalización indica que un uso-caso (ovalo) es un caso especial de otro caso, en otros términos, representa una relación padre-hijo, donde el hijo puede ser suplido directamente por el padre en cualquier momento. Este elemento es representado por una linea con flecha que se extiende del uso-caso hijo hacia el uso caso padre (general).
    Inclusión : Una inclusión es utilizada para indicar que un uso-caso (ovalo) depende de otro caso, dicho de otra manera, significa que la funcionalidad de determinado caso se requiere para realizar las tareas de otro. Este elemento es representado por una linea punteada con flecha y comentario <<include>> que se extiende del uso-caso base hacia el uso caso de inclusión.
    Extensión : Una extensión representa una variación de un uso-caso a otro, aunque similar a una generalización, una extensión representa una dependencia especifica, mientras una generalización no implica que los usos-casos dependen uno del otro. Este elemento es representado por una linea punteada con flecha y comentario <<extend>> que origina del uso-caso base hacia el uso caso de extensión.

    Un Diagrama de Clases muestra un conjunto de clases, interfaces,  colaboraciones y relaciones. Cubren la vista de diseño estático de un sistema. Cuando incluyen clases activas cubren la vista de procesos estáticos

     

  2. Diagrama de Clases

    Un Diagrama de Clases muestra un conjunto de clases, interfaces,  colaboraciones y relaciones. Cubren la vista de diseño estático de un sistema. Cuando incluyen clases activas cubren la vista de procesos estáticos

    Relacion de Asociacion

    – Rol: Se identifica con un nombre al  final de la línea y describe la semántica de la relación en el sentido indicado. Cada asociación tiene dos roles; cada rol es una dirección y puede estar representado en el nombre de la clase.

    Multiplicidad: Describe la cardinalidad de la relación, es decir, cuantos objetos de esa clase pueden participar en la relación dada.

  3. Diagrama de Objetos

    Muestran un conjunto de objetos y sus relaciones representan instantáneas de instancias de los elementos encontrados en los diagramas de clase. Cubren la vista de diseño y proceso estático de un sistema.

  4. Diagrama de Secuencia

    Es un diagrama de interacciones que resalta la ordenación temporal de los mensajes. Es importante mencionar que los diagramas de interacción es  un conjunto de objetos y sus relaciones, incluyendo los mensajes que pueden ser enviados entre ellos.

  5. Diagrama de Colaboracion

    Es un diagrama de interacción que resalta la organización estructural de los objetos,  que envían y reciben mensajes de las iteraciones que están indicadas por un número. A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales) y ciclos en la ejecución.

  6. Diagrama de Estados

    Muestra una máquina de estados, que consta de estados transiciones, eventos y actividades. Cubren la vista dinámica de un sistema y el comportamiento de una interfaz, clase, colaboración y resaltan el comportamiento dirigido por eventos de un objeto.

    Muestra el conjunto de estado por los cuales pasa un objeto durante su vida en una aplicación junto con los cambios que permiten pasar de un estado a otro. Esta representado principalmente por los siguientes elementos: estado, elemento y transición.

    Eventos: Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. 

    Condición que toma el de verdadero o falso.
    Recepción de una señal o mensaje de otro objeto en el modelo.
    -Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular.

    Transición: Es una relación de tres o más estados en una transición de múltiples fuentes o múltiples destinos.

  7. Diagrama de Actividades

    Muestra el flujo de actividades dentro de un sistema. Cubren la vista dinámica, son importantes al modelar el funcionamiento del un sistema y resaltan el flujo de control de objetos.

    Un diagrama de actividades es un diagrama de estados, casi todos los estados son estados de acción, y casi todas las transiciones son enviadas al terminar la acción ejecutada en el estado anterior. Generalmente modelan los pasos de un algoritmo y puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto.

    Sirven para representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos. Los elementos que conforman el diagrama son: acción y transición.

    Transición: Es la relación entre dos estados y se encuentran unidos por flechas. Indican que un objeto que está en el primer estado, realizará una acción especificada y entrará en el segundo estado cuando un evento implícito ocurra y unas condiciones especificas sean satisfechas.

  8. Diagrama de Componentes

    Muestra la organización y las dependencias entre un conjunto de componentes, cubren la vista de implementación estática. Se relacionan con diagramas de clase en que un componente se corresponde  con una o más clases, interfaces o colaboraciones. Representa las componentes físicas de la aplicación.

  9. Diagrama de Despliegue

    Muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Su relación con los diagramas de componentes en que un nodo incluye, uno o mas componentes.

Existen varios lenguajes para o notaciones en el medio para graficar un proceso de negocio.

En este blog definiremos los siguientes:

  • UML – Lenguaje Unificado de Modelado (” Unified Modeling Language“).
  • DFD – Diagrama de Flujo de Datos (“Data Flow Diagram“).
  • RUP – Proceso Unificado Racional (“Rational Unified Process”)