APLICANDO CONCEPTOS

Después de analizar los diferentes elementos relacionados con el análisis y diseño orientado a objetos podemos hacer la aplicación a nuestro proyecto pedagógico, donde el tema es desarrollar una sistema de información para el área de salud mental correspondiente a la secretaria de salud del municipio de Pasto.  

CASO DE USO:

APLICACIÓN DE CONCEPTOS

A continuación vamos a ver con un ejemplo la forma de representar un diagrama de secuencias; tomemos la pulsación en un teclado de un carácter alfanumérico en una aplicación de procesos de textos. El carácter debería aparecer inmediatamente en la pantalla. Veamos en detalle que es lo que ocurre:

1. La interfaz gráfica de Usuario (GUI) notifica al sistema operativo que se oprimio una tecla. 
2. El sistema operativo notifica a la CPU. 
3. El sistema Operativo actualiza la GUI. 
4. La CPU notifica a la tarjeta de video. 
5. La tarjeta de vídeo envia un mensaje al monitor.
6. El monitor presenta el caracter alfanumerico en la pantalla, con lo que se hara visible al usuario.

TABLA DE REQUERIMIENTOS:

DIAGRAMA DE SECUENCIA:

En este ejemplo de secuencia nos muestra un grupo de mensajes asíncronos. Ningún objeto aguarda la respuesta para continuar. 

DIAGRAMA DE PAQUETES:

EJEMPLO Y TABLA DE FUNCIONES

Teniendo en cuenta   que los requisitos son  capacidades y condiciones con las cuales debe ser conforme  el sistema y más ampliamente  el proyecto, hemos elaborado una tabla   en la cual se identifica los requisitos primordiales  en un sistema cualquiera:

TIPO	REQUISITO	OBLIGATORIO
		SI	NO
Funcional	seguridad	X
Facilidad  de uso	Factores humanos, ayuda, documentación	X
Fiabilidad	Capacidad de recuperar  algún fallo	X
Rendimiento	Menor tiempo de respuesta	X
Legalidad	licencia		X
Interfaz	Restricción para interactuar con sistemas externos		X

  EJEMPLO DE APLICACIÓN

      DESCRIPCIÓN DEL PROBLEMA

En una empresa de comunicaciones   se da  muy regularmente  el envió de mensajes  entre objetos en relación con el tiempo (comunicación  vía  móvil)

-           

      TABLA DE REQUERIMIENTOS

REQUISITO	OBLIGATORIO
	SI	NO
Conexión a red existente	X
Aviso llamada entrante	X
Buen funcionamiento  de los parlantes del móvil	X
Buen funcionamiento  de loa auriculares	X
Moderno modelo del móvil		X
Pertenecer  a algún plan		X

-                                                                                                                        DIAGRAMA DE SECUENCIA

                                                                                                                                                                               

LEVANTAMIENTO DE REQUERIMIENTOS

El siguiente escenario es tí­pico: Un consultor trabaja con los usuarios para describir los procesos de negocio que serán soportados por el software. El equipo de desarrollo recibe la descripción del consultor pero no están familiarizados con los términos de negocio y consideran la descripción demasiado informal. Los desarrolladores escriben su propia descripción desde un punto de vista técnico. El usuario no entiende esta descripción pero la acepta para que el proyecto avance. El resultado puede ser un sistema que desde el punto de vista del usuario es difícil de usar y que no cumple con sus expectativas.

Parte de este problema es metodológico, y en parte es intrínseco a las caracterí­sticas de los usuarios. Algunas de las problemáticas que se presentan:

• Los usuarios no saben que es lo que quieren
• Los usuarios no aceptan como un compromiso los requerimientos escritos
• Los usuarios insistirán en nuevos requerimientos después de fijar costos y agendas.
• Los usuarios no están disponibles y la comunicación con ellos es lenta
• Los usuarios no participan en revisiones de avance.
• Los usuarios no entienden el proceso de desarrollo y no les interesa.

Existen herramientas y metodologías para el levantamiento de requerimientos. Casos de uso y UML son medios para formalizar este proceso. Que diagramas UML es apropiado usar dependerá del sistema a desarrollar. 

Una guía simple en términos de la complejidad del sistema: 

• Aplicación mono usuario
  • Diagrama de casos de uso.
  • Diagrama de clases.
  • Diagrama de interacción.
• Aplicación mono usuario, con manejo de eventos:
  • Añadir: Diagrama de estados.
• Aplicación cliente servidor:
  • Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.
• Aplicación compleja distribuida:
  • Todos.

Para una aplicación sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicación compleja unos nueve tipos. El diagrama de casos de uso puede modelar el contexto de un sistema o los requisitos del mismo. Se puede extender la colección de elementos base de UML utilizando estereotipos.

DIAGRAMA DE PAQUETES

Paquete que proporciona los medios para

organizar los artefactos en piezas manejables.

•Es un mecanismo de agrupamiento que tiene

que se altamente cohesivo internamente y con

las interacciones mínimas con otros paquetes.

•Puede clases, casos de uso, otros diagramas,

paquetes, …., ARTEFACTOS.

•Desde afuera solo se puede acceder a los

elementos públicos de los artefactos que

contiene.

EJEMPLO:

 

...UML (Lenguaje Unificado de Modelado)...

Es la sucesión de una serie de métodos de un análisis y diseño orientadas a objetos, en otras palabras es un lenguaje de modelado que permite la representación conceptual y física de un sistema, indica los pasos que se deben seguir para llegar a un diseño.

Se necesitaba un lenguaje que fuese gráfico, a fin de especificar y documentar un sistemas de software, de un modo estándar incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema; se necesitaba un lenguaje que cumpliera que con los desarrollos de software se hagan bajo una arquitectura en capas y se formalice como un lenguaje estándar y unificado, es decir que cada una de las partes que comprende el desarrollo de todo software orientado a objetos se visualice, especifique y documente con lenguaje común, fue así como surgió UML el cual cumple con los anteriores requerimientos de: Especificar, visualizar, construir y documentar fases de un sistema de software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir. 

UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. Un sistema se modela como una colección de objetos discretos que interactúan para realizar un trabajo que finalmente beneficia a un usuario externo.


Información basada en:


* http://blog.smaldone.com.ar/2006/11/17/por-que-uml-no-sirve/
* http://www.docirs.cl/uml.htm

BLOQUES DE CONSTRUCCIÓN DE LENGUAJE

*Elementos del Lenguaje: estructurales, comportamiento, agrupación, anotación. 

*Relaciones entre los elementos: dependencia, asociación, generalización, realización. 

*Diagramas: clases, objetos, casos de uso, secuencia, colaboración, estados, actividades, componentes, despliegue.


Después de conocer el concepto de UML y los bloques en los los que  se encuentra dividido, nos permitimos ampliar la información acerca del bloque diagrama,  y, asi especificamente el de secuencia. 

DIAGRAMA DE SECUENCIA

Es un tipo de diagrama usado para modelar interacción entre objetos en un sistema mostrando de manera explicita la secuencia de estímulos ordenada temporalmente, representa el envió de mensajes entre objetos en relación con el tiempo.

El diagrama de secuencia se utiliza para describir los distintos escenarios derivados de los casos de uso. Para mas claridad hay que notar que un escenario es una secuencia especifica de acciones que ilustra un comportamiento (instancia de caso de uso) , un caso de uso puede tener muchos escenarios.

Un diagrama de secuencia tiene:

* Objetos con sus lineas de vida

* Mensajes intercambiados entre objetos en una secuencia ordenada.

-Linea de vida activa. la cual puede ser opcional.

EJEMPLO DE DIAGRAMA DE SECUENCIA

ELEMENTOS DEL DIAGRAMA DE SECUENCIA

• OBJETOS: Se representan mediante una linea vertical llamada linea de vida, en la parte superior se coloca un rectángulo con el nombre del objeto o la clase, en caso de que el objeto sea destruido antes de terminar el diagrama se representa la terminación mediante un aspa.  
• 
  
• FOCO DE CONTROL O ACTIVACIÓN: Se representa mediante un rectángulo superpuesto a la linea de vida del objeto, su tamaño depende de la duración de la acción realizada por el objeto, la parte superior indica el inicio de la acción, la parte inferior indica la terminación.
•  
• MENSAJES: Se representa mediante una linea horizontal entre las lineas de vida entre los objetos que intercambian los mensajes, es posible añadir a los mensajes condiciones o interacciones.

Información tomada de:

*http://www.ingenieria.cl/escuelas/informatica/apuntes_curso_uml/DIAGRAMA%20DE%20SECUENCIAsinfundo.pdf

* http://es.wikipedia.org/wiki/Diagrama_de_secuencia

* http://www.di.uniovi.es/-dediego/is/recursos/d_int.pdf