METODOLOGÍA UML

UML es un lenguaje para especificar, construir, visualizar y documentar las partes de un sistema de software orientado a objetos.

UML es un lenguaje estandar de modelamiento de componentes de un desarrollo de aplicaciones, pero no un modelo de desarrollo a seguir. Para esto existen otros metodos de modelaje como OMT (Objetc Modelling Technique) o Booch, en los que se definen procesos completos.

[Leer mas...]

RUP - PROCESO UNIFICADO RACIONAL

The Rational Unified Process® (Proceso unificado de Rational – RUP) está basado en una integración del trabajo de tres metodologistas, Ivar Jacobson, Grady Booch and James Rumbaugh. Estos metodologistas, fueron reunidos por Rational para formar un marco de metodologías unificadas, cohesivas y comprehensivas de desarrollo de sistemas de software. Su trabajo, que producen durante varios años y basados en metodologías probadas, han dado a lugar a importantes normas en la comunidad de desarrollo, incluida la aceptación general de los Casos de Uso y del Lenguaje de Modelado Unificado (Unified Modeling Language – UML).

El Proceso Unificado tiene tres características distintivas. Estas características son:

• Dirigido por Casos de Uso: El proceso utiliza Casos de Uso para manejar el proceso de desarrollo desde la Incepción hasta el Despliegue.
• Centrado en Arquitectura: El proceso busca entender los aspectos estáticos y dinámicos más significativos en términos de arquitectura de software. La arquitectura se define en funcion de las necesidadfes de los usuarios y se determina a partir de los Casos de Uso base del negocio.
• Iterativo e Incremental: El proceso reconoce que es práctico dividir grandes proyectos en proyectos más pequeños o mini-proyectos. Cada mini-proyecto comprende una iteración que resulta en un incremento. Una iteración puede abarcar la totalidad de los flujos del proceso. Las iteraciones son planificadas en base a los Casos de Uso.

[Leer más...]

SEGUIMIENTO ACADEMICO

Haciendo uso de la herramienta Enterprice Architect, he rediseñado los casos de uso para este ejercicio.

Pulse aquí para descargar el arhivo-paquete

ARQUITECTURA BAJO CAPAS

La programación por capas es un estilo de programación en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño.

La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, sólo se ataca al nivel requerido sin tener que revisar entre código mezclado.

Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que basta con conocer la API que existe entre niveles.

En el diseño de sistemas informáticos actual se suele usar las arquitecturas multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables.

El diseño más utilizado actualmente es el diseño en tres niveles (o en tres capas):

1. Capa de presentación: es la que ve el usuario, presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso. Esta capa se comunica únicamente con la capa de negocio. También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" para el usuario.
2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos para almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación.
3. Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

Todas estas capas pueden residir en un único ordenador, si bien lo más usual es que haya una multitud de ordenadores en donde reside la capa de presentación (son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o más ordenadores. Así, si el tamaño o complejidad de la base de datos aumenta, se puede separar en varios ordenadores los cuales recibirán las peticiones del ordenador en que resida la capa de negocio.

[Pulse aquí para ver el ejercicio]

DIAGRAMAS UML (Exposiciones)

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente.

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
* Diagrama de despliegue
* Diagrama de paquetes

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

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)

DIAGRAMA DE COMPONENTES

Lo que distingue el Diagrama de Componentes de otro tipo de diagramas es sin duda su contenido. Normalmente contiene componentes, interfaces y relaciones entre ellos.

Los componentes perteneces a un mundo físico, es decir, representan a un bloque de construcción al modelar aspectos físicos de un sistema.

Cada componente debe tener un nombre que lo distinga de los demás. Al igual que las clases los componentes pueden enriquecerse con compartimientos adicionales que muestran sus detalles.
[Leer mas...]

CASOS DE USO

Estos son algunos casos de uso que se presentan entre actores y acciones.

[Pulse aquí para ver los casos de uso]

Temas vistos con el Ing. Sergio Vargas

• Diagrama de casos de uso, con inclusiones y exclusiones. Algo de herencia, multiplicidad y asociación.
• Diagrama de clases.
• Diagrama de secuencias.

¿PARA QUÉ SIRVE UML?

En los principios de la programación, los desarrolladores no realizaban análisis profundos sobre el tema a resolver. El código del programa se escribía conforme se iba requiriendo. Los tiempos cambian y esta manera de aventurar en el desarrollo de software es inapropiada en los negocios de alto riesgo.

Hoy en día el cliente debe de comprender que es lo que realizará el equipo de desarrolladores, que sea capaz de señalar cambios si sus necesidades no son comprendidas con claridad.

El UML está compuesto de diversos elementos gáficos que se combinan para conformar diagramas. La finalidad de estos es presentar diferentes perspectivas de un sistema al que se le denomina modelo.

[Leer más...]

---

CASOS DE USO

Es una técnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario.

Describe la acciones de un sistema para que pueda ser utilizado por personas en general y no solo por expertos en computación.

Los diagramas de casos de uso (DCU) se componen básicamente de un actor, una acción, inclusiones y exclusiones.

[Leer más...]

Ejemplo

---

VENTAJAS

• Diseño sólido de las acciones del usuario en un sistema.
• Interpretación del desarrollo facil para el cliente.
• Medición de tiempo, costo, recursos y prioridades de un desarrollo.
• Lenguaje fácil de comunicación entre los usuarios y desarrolladores.

DESVENTAJAS

• Error en el desarrollo de un proceso por mala interpretación de la necesidad del cliente
• El cliente puede cambiar los procesos en este modelo.
• El modelamiento puede comprender otras áreas con procesos cambiantes o en desarrollo.
• Las inclusiones y exclusiones en los casos de uso pueden confundir la lectura de los diagramas para el usuario.