DIAGRAMA DE CASOS DE USO

Diagrama de Casos de Uso

Diagrama de Secuencias

Diagrama de Clases

HERRAMIENTAS DE MODELADO Y GENERACION DE CÓDIGO APARTIR DE DIAGRAMAS

La Herramienta que utilizaré para crear mis diagramas de caso de uso, diagrama de clases diagramas de secuencia y diagramas de componentes será Visual Paradigm For UML V8.3 ya que esta herramienta comparada con las demás expuestas en este post, es la que más carácterisiticas posee, entre ellas la integración de archivos de Excel o el uso de base de datos o la generación de planes de trabajo, además de los muchos lenguajes de programación que soporta.

CUADRO COMPARATIVO

Software	Disponibilidad	Características	Lenguajes que soporta
Dia con Dia2Code	El programa puede ser descargado desde du página oficial: http://projects.gnome.org/dia/ y desde: http://live.gnome.org/Dia	*Dia es una aplicación gráfica de propósito general para la creación de diagramas, desarrollada como parte del proyecto GNOME. Está concebido de forma modular, con diferentes paquetes de formas para diferentes necesidades. Dia está diseñado como un sustituto de la aplicación comercial Visio de Microsoft. Se puede utilizar para dibujar diferentes tipos de diagramas. Actualmente se incluyen diagramas entidad-relación, diagramas UML, diagramas de flujo, diagramas de redes, diagramas de circuitos eléctricos, etc. El formato para leer y almacenar gráficos es XML (comprimido con gzip, para ahorrar espacio).Puede producir salida en los formatos EPS, SVG y PNG. También conviene recordar que Dia, gracias al paquete dia2code, puede generar el esqueleto del código a escribir, si utilizáramos con tal fin un UML	Ada, c, cpp, idl, java, php, python, shp, sql.
Umbrello	Se puede obtener de: http://uml.sourceforge.net/ *Manual de Umbrello en español: http://docs.kde.org/stable/es/kdesdk/umbrello	Umbrello es una herramienta libre para crear y editar diagramas UML, que ayuda en el proceso del desarrollo de software. Fue desarrollada por Paul Hensgen, y está diseñado principalmente para KDE, aunque funciona en otros entornos de escritorio. Umbrello maneja gran parte de los diagramas estándar UML pudiendo crearlos, además de manualmente, importándolos a partir de código en C++, Java, Python, IDL, Pascal/Delphi, Ada, o también Perl (haciendo uso de una aplicación externa). Así mismo, permite crear un diagrama y generar el código automáticamente en los lenguajes antes citados, entre otros. El formato de fichero que utiliza está basado en XMI. También permite la distribución de los modelos exportándolos en los formatos DocBook y XHTML, lo que facilita los proyectos colaborativos donde los desarrolladores no tienen acceso directo a Umbrello o donde los modelos van a ser publicados vía web.	Umbrello UML Modeller viene provisto con soporte para la generación de código en ActionScript, Ada, C++, CORBA IDL, Java™, JavaScript, PHP, Perl, Python, SQL y XMLSchema.
ArgoUml	Se puede descargar directamente desde aquí: http://argouml-downloads.tigris.org/nonav/argouml-0.32.2/ArgoUML-0.32.2-setup.exe	ArgoUml es una aplicación OpenSource utilizada en el modelaje de sistemas, mediante la cual se realizan diseños en UML llevados a cabo en el análisis y pre-diseño de Sistemas de Software. *Multiplataforma (Java 1.2) *Meta modelo de UML estándar *Diagramas de Clase *Diagramas de Estado *Diagramas de Casos de uso *Diagramas de Actividad *Diagramas de Colaboración *Diagramas de Despliegue *Diagramas de Secuencia Soporte para bases de datos *Exporta los diagramas a distintos formatos *Generación de código (parcial) *Soporte cognitivo: -Proactivo (criticas de diseño, listas de cosas por hacer, correcciones automáticas) -Comprensión y solución del problema (perspectivas navegacionales, vistas superpuestas, representaciones alternativas de diseño: gráficos, texto, tablas)	La generación de código no ofrece tantas opciones como en los programas anteriores (sólo genera código Java y la propia notación UML 1.3), no soporta la inclusión de ficheros de licencia o cabeceras, etc. El enfoque de ArgoUML es totalmente hacia UML como notación y el diseño de aplicaciones orientadas a objeto. Puede ser utilizado junto con Eclipse(IDE).

CATALOGO DE REQUERIMIENTOS

REQUISITOS DETECTADOS PARA EL SISTEMA

Se han detectado 2 requisitos principales los cuales pueden ser divididos en subrequisitos.

*El sistema debe de capturar la información del medio ambiente

*El sistema debe de transformar la información adquirida del medio ambiente en instrucciones que el cliente pueda entender.

Si nos damos cuenta el primer requisito se puede dividir en más requisitos ya que la captura de información del medio ambiente se puede hacer de distintas formas y con distinto hardware.

El segundo requisito ya es algo más entendible para nosotros los ingenieros en sistemas, ya que nos podemos dar una mejor idea de cómo procesar la información adquirida del medio ambiente y hacerla entendible al usuario.

Nota. Se pondrán más requisitos conforme se vayan haciendo más específicas las áreas de investigación del proyecto y se eviten grandes ramificaciones.

INGENIERIA DE REQUERIMIENTOS PARTE 3

Para la parte de validación de requerimientos se tienen las siguientes técnicas:

Reviews o Walk-throughs. Esta técnica nos puede ser de gran ayuda al momento de estar realizando el proyecto, ya que consiste en la revisión de la documentación de la definición de requisitos y así validar que los requisitos son válidos.

Auditorías.  Esta técnica nos será de gran ayuda ya que solo revisa una muestra de los resultados obtenidos comparándolos con todos los documentos obtenidos de instituciones.

Matrices de trazabilidad. Esta técnica consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo. Es necesario ir viendo qué objetivos cubre cada requisito, de esta forma se podrán detectar inconsistencias u objetivos no cubiertos.

Prototipos. Algunas propuestas se basan en obtener de la definición de requisitos prototipos que, sin tener la totalidad de la funcionalidad del sistema, permitan al usuario hacerse una idea de la estructura de la interfaz del sistema con el usuario (Olsina, 1999).

Esto es fundamental en el proyecto, ya que se tiene planeado ir paso  por paso y esta técnica nos ayuda a hacer eso.

INGENIERIA DE REQUERIMIENTOS PARTE 2

Para la etapa de definición de requerimientos se tienen las siguientes técnicas:

Lenguaje natural: Resulta una técnica muy ambigua para la definición de los requisitos. Consiste en definir los requisitos en lenguaje natural sin usar reglas para ello. A pesar de que son muchos los trabajos que critican su uso, es cierto que a nivel práctico se sigue utilizando.

Esta técnica en lo particular pareciera ser lo que la gente común pudiera usar pero, para un proyecto de nivel licenciatura no es lo más deseable ya que no está bien fundamentado su uso.

Glosario y ontologías: La diversidad de personas que forman parte de un proyecto software hace que sea necesario establecer un marco de terminología común. Esta herramienta es muy útil, en especial si se maneja un número grande de nuevos términos técnicos.

Plantillas o patrones. Esta técnica, recomendada por varios autores, tiene por objetivo el describir los requisitos mediante el lenguaje natural pero de una forma estructurada. Una plantilla es una tabla con una serie de campos y una estructura predefinida que el equipo de desarrollo va cumplimentando usando para ello el lenguaje del usuario.

Esta técnica es apropiada para el proyecto en el sentido que es más entendible poner los requisitos en lenguaje natural y partir de ahí hacia requisitos más técnicos.

Escenarios. La técnica de los escenarios consiste en describir las características del sistema a desarrollar mediante una secuencia de pasos (Liu & Yu, 2001). La representación del escenario puede variar dependiendo del autor. Esta representación puede ser casi textual o ir encaminada hacia una representación gráfica en forma de diagramas de flujo (Weidenhaupt, Pohl, Jarke & Haumer, 1999). El análisis de los escenarios, hechos de una forma u otra, pueden ofrecer información importante sobre las necesidades funcionales de sistema (Lowe & Hall, 1999).

Esta técnica puede ser una forma de hallar errores, de prevenirlos y darle más y mejor funcionalidad al sistema final. Ya que se entiende que un escenario puede derivarse la la pregunta: ¿Qué pasa si…?

Lenguajes Formales: Otro grupo de técnicas que merece la pena resaltar como extremo opuesto al lenguaje natural, es la utilización de lenguajes formales para describir los requisitos de un sistema.

INGENIERIA DE REQUERIMIENTOS PARTE 1

Al querer desarrollar cualquier sistema se necesita tener en cuenta los requerimientos que el sistema necesite y las técnicas que se necesitarán para poder obtener los requisitos,  los requerimientos deben de pasar por un procedimiento de aprobación y dicho proceso consta de 3 partes:

1.       Captura

2.       Definición

3.       Validación

Para la parte de la captura de requerimientos se tienen las siguientes técnicas:

Entrevistas. Las entrevistas le permiten al analista tomar conocimiento del problema y comprender los objetivos de la solución buscada.

Básicamente, la estructura de la entrevista abarca cuatro pasos: identificación de los entrevistados, preparación de la entrevista, realización de la entrevista y documentación de los resultados (protocolo de la entrevista).

La entrevista es la metodología principal a usar para la captura de requerimientos de mi proyecto, ya que obtendría información de primera mano y de la gente a la que está enfocada el proyecto.

Brainstorming (Tormenta de ideas). Consiste en la mera acumulación de ideas y/o información sin evaluar las mismas.

Como técnica de captura de requisitos es sencilla de usar y de aplicar, puesto que no requiere tanto trabajo en grupo como éste.

Además suele ofrecer una visión general de las necesidades del sistema, pero normalmente no sirve para obtener detalles concretos del mismo, por lo que suele aplicarse en los primeros encuentros.

Concept Mapping. Los concept maps (Pan, Zhu & Johnson, 2001) son grafos en los que los vértices representan conceptos y las aristas representan posibles relaciones entre dichos conceptos. Esta metodología parecía ser buena opción para el proyecto pero debido a que el proyecto puede tener ramificaciones muy amplias, entonces los concept maps se harían confusos y poco entendibles.

Sketches y Storyboards. La misma consiste en representar sobre papel en forma muy esquemática las diferentes interfaces al usuario (sketches). Estos sketches pueden ser agrupados y unidos por enlaces dando idea de la estructura de navegación (storyboard).

Esta metodología pareciera ser la ideal pero solo al principio del proyecto. Esto para irse dando una mejor idea de cómo se va a hacer cada parte de la interfaz con el usuario, luego seria innecesaria.

Casos de uso. Aunque inicialmente se desarrollaron como técnica para la definición de requisitos (Jacobson, 1995), algunos autores proponen casos de uso como técnica para la captura de requisitos (Pan, Zhu & Johnson, 2001 y Liu & Yu, 200). Los casos de uso permiten mostrar el contorno (actores) y el alcance (requisitos funcionales expresados como casos de uso) de un sistema.

Esta metodología seria apropiada para el proyecto, en especial en saber cómo sería la interacción del usuario con el sistema.

Cuestionarios y Checklists: Esta técnica requiere que el analista conozca el ámbito del problema en el que está trabajando. Consiste en redactar un documento con preguntas cuyas respuestas sean cortas y concretas, o incluso cerradas por unas cuantas opciones en el propio cuestionario (Checklist).  Al parecer es muy similar a la entrevista, así que será innecesario ya que no se obtendría información nueva o relevante a la ya obtenida con la entrevista.

Comparación de terminología: Esta técnica es utilizada en forma complementaria a otras técnicas para obtener consenso respecto de la terminología a ser usada en el proyecto de desarrollo. Para ello es necesario identificar el uso de términos diferentes para los mismos conceptos (correspondencia), misma terminología para diferentes conceptos (conflictos) o cuando no hay concordancia exacta ni en el vocabulario ni en los conceptos (contraste) (Pan, Zhu & Johnson, 2001). Sin duda esta técnica es muy útil para evitar malentendidos, pero es muy probable que el usuario final no llegue a utilizar la terminología que yo necesitaré utilizar, así que bastaría con entender los tecnicismos manejados en el proyecto. 

BENEFICIARIOS

Se pretende beneficiar a todas aquellas personas ciegas o con discapacidad visual que debido a su condición física son permanente dependientes de sus familiares o de terceros y su integración social es muy limitada.