CASO DE USO:
Mediante este blog pretendemos ampliar conocimientos acerca de todo lo relacionado con el análisis y diseño orientado a objetos.
Buscar este blog
martes, 12 de abril de 2011
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.
martes, 1 de marzo de 2011
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:
TABLA DE REQUERIMIENTOS:
DIAGRAMA DE SECUENCIA:
- La interfaz gráfica de Usuario (GUI) notifica al sistema operativo que se oprimio una tecla.
- El sistema operativo notifica a la CPU.
- El sistema Operativo actualiza la GUI.
- La CPU notifica a la tarjeta de video.
- La tarjeta de vídeo envia un mensaje al monitor.
- 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.
sábado, 19 de febrero de 2011
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 |
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
miércoles, 16 de febrero de 2011
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:
sábado, 5 de febrero de 2011
...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.
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
* http://www.di.uniovi.es/-dediego/is/recursos/d_int.pdf
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.
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.di.uniovi.es/-dediego/is/recursos/d_int.pdf
Suscribirse a:
Entradas (Atom)