PREGUNTAS Y RESPUESTAS SOBRE LA METODOLOGIA ICONIX EN INGENIERIA DE SOFTWARE

Tienes alguna duda? Aclaración? Aportes?   ICONIX NOS HA SALVADO LA VIDA A MUCHOS pero comprenderlo y dominarlo exige más: Inteligencia Colectiva.  Ahora es momento de las PREGUNTAS Y RESPUESTAS.

ESCRIBE TU PREGUNTA AQUI 

MODELO DE DOMINIO EN ICONIX

En el desarrollo de software, recurrimos al modelo de dominio como una herramienta para iniciar lo que al final se llamará el DIAGRAMA DE CLASES

Iconix no es como RUP, sino que busca ir adaptandose al proyecto de acuerdo a lo que va aprobando el ciente, como tal, no podemos ir de frente a realizar un Diagrama de Clases sin tener errores, por ello  para no hacernos problemas recurrimos al MODELO DE DOMINIO, que es un esbozo de un DIAGRAMA DE CLASES.

El modelo de Dominio sería como el bosquejo de un ingeniero de Edificios antes de ir al Plano del Edificio.
Al principio el cliente pedirá  una construcción con sala en un lugar, cocina en otro y el ingeniero solo irá dibujandolo, luego de ver si lo que el cliente  pide es factible lo incluirá con algunas modificaciones técnicas, llegando al plano final, con el plano recién inician a construir el edificio, es parecido en ingeniería de software.

Se puede ir de frente al DIAGRAMA DE CLASES?

plan de tesis original utilizando iconix

ICONIX es la metodología que está de moda por su fácil aplicación y rápida producción de software de calidad. En la presente web, explicaremos lo punto esenciales de la metodología
Sabemos que iconix tiene 4 fases: Análisis de Requerimientos Análisis y Diseño Preliminar Diseño Pruebas Pero en ést clase, les mostraré los 9 pasos esenciales para desarrollar dichas fases, de hecho explicaré la figura que aparece arriba. 1. Conversamos con el cliente y dibujamos como podría ser el software y principalmente lo que haremos será dibujar interfaces y el cliente nos dirá, que se necesita un boton para que cada empleado ingrese, o que necesita ver la hora, entonces haremos un bosquejo. 2. Con lo que apuntamos en el paso 1, empezaremos a separar en acciones o CASOS DE USO, e iremos dibujando los muñequitos para ver si es lo que el cliente espera que realice. 3. Con lo poco que sabemos dibujamos un MODELO DEL DOMINIO. El modelo de dominio es un DIAGRAMA DE CLASES EN BOSQUEJO, no le ponemos ni las propiedades ni los métodos, solo los NOMBRES, allí lo dejamos en bosquejo y volvemos a nuestros Diagramas de Caso de Uso para agarrarlo de donde más le duele y exprimirlo. 4. Cada CASO DE USO se pasa a algo todavía más ilustrativo a un DIAGRAMA DE ROBUSTEZ, se preguntarán porqué?. Resulta que, dibujar botoncitos no hace nada, hacer el diagrama de casos de uso, nos ayuda a entender al cliente, de hecho el cliente ve el diagrama de CASO DE USO y dice, si es cierto, eso pasa. Ejm. El empleado llega y se tiene que identificar colocando su contraseña. Pero el diagrama de Caso de Uso , no te dice como funcionará a un nivel más cercano a lo que la computadora pueda entender, entonces allí es donde en lugar de dibujar muñequitos dibujamos unos círculos con diferentes características. Son lo objetos, son 3 y nada más. Objeto Frontera, Objeto Entidad, Objeto Control. Vale decir todo lo que necesitamos. Es mágico y simple saber que con ésto objetos podemos representar una acción ( A veces parece ocioso, ya que, al principio parece redundante, es más la primera vez que lo ví, dije, si será uno tonto para no entender lo que hace una persona como para dibujar un diagrama de robustez, es obvio. Pero luego descubrirá que hay cosas que por muy obvias tienen que ser muy bien comprendidas y sobre todo evitar que existan errores y vaciós, en éso el diagrama de robustez, robustece tu entendimiento del problema o CASO DE USO para luego darselo a entender a la computadora) 5. Cada DIAGRAMA DE ROBUSTEZ se refina aún más y se pasa a DIAGRAMAS DE SECUENCIA, y para que?. Bueno En los diagramas de SECUENCIA podemos darnos cuenta si el código que desarrollemos funcionará adecuadamente en el tiempo. 6. Con lo que hemos encontrado en los DIAGRAMAS DE ROBUSTEZ Y DIAGRAMAS DE SECUENCIA, nos damos cuenta que nuestro bosquejo del DIAGRAMA DE CLASES PUEDE SER MEJORADO, quitaremos algunos elementos y colocaremos otros. 7. Al fin tendremos EL DIAGRAMA DE CLASES. (MODELO DE CLASES) y con ello vamos a codificar. 8. CODIFICAR, Después de tantos diagramas recién podemos codificar ( Y uno que quiere codificarlo ya de inmediato, no apresurarse entonces) 9. PLAN DE PRUEBAS. Todavía no está listo el software, ahora debemos someterlo a las PRUEBAS, que pasa si el cliente coloca su contraseña y se equivoca,por ejemplo. Las PRUEBAS nos ayudarán a encontrar todavía más errores que a pesar de nuestros diagramas puedan haberse escapado. Quizá con tantos diagramas el software éste tan bien hecho que no necesite corregirse, pero es muy probable que existan errores, entonces habrá que corregirlos y al fin poder entregar un buen producto al cliente. .

PASOS A SEGUIR EN LA METODOLOGIA ICONIX PARA EL DESARROLLO DE SOFTWARE

·         Análisis de requisitos

1)      Modelo de dominio

2)      Prototipación rápida

3)      Modelo de casos de uso

·         Análisis y diseño preliminar

1)      Descripción de casos de uso

2)      Diagrama de robustez

·         Diseño

1)      Diagrama de secuencia

2)      Completar el modelo estático

·         Implementación

1)      Utilizar un diagrama de componentes

2)      Escribir / Generar código

3)      Realización de pruebas

DESARROLLO DE UNA WEB CON ICONIX

   En el siguiente ejemplo desarrollaremos una página web con la metodología iconix, de ésta manera podremos conocer cuales son los pasos a seguir:

   El área de turismo de American, una empresa dedicada a diversos servicios,  contrata la realización de un sistema web que permita  manejar destinos turísticos, turistas y servicios.

   Se procederá así:

1 : ANALISIS DE REQUERIMIENTOS:

  Evidentemente, al iniciar un trabajo no sabemos como hacerlo pero si para qué, aunque todavía no está muy claro. También debemos saber que el sistema  no debería admitir ciertos datos, ejm, no se puede viajar a 2 ciudades al mismo tiempo.

  Todo lo anterior se centra en el ANALISIS DE REQUERIMIENTOS

  El análisis de requerimientos además se clasifica en 2 :

  Requerimientos Funcionales

  Requerimientos No funcionales.

 Y cuál es la diferencia entre ambos?.

Requerimientos Funcionales (Requisitos Funcionales) son todos aquellos requisitos, condiciones, que son necesarios para el funcionamiento del sistema en sí, es decir lo que debe permitirse y no permitirse en el sistema, lo que el sistema debe hacer . Recordemos que esto se puede definir en el mismo momento de iniciar el proyecto o puede venir  ya como parte del contrato (El cliente quiere que sea así)

Requerimientos No funcionales ( Requisitos No funcionales) Son aquellas  condiciones que no afectan directamente al sistema pero si a su entorno, por ejemplo , que el software corra en todas las plataformas, windows, mac, etc.

Modelo del dominio :

Me han estado preguntando sobre el Modelo del Dominio, lo haré simple: Un modelo de dominio es un diagrama de clases sin detalles, sin atributos ni métodos, es solo un esbozo, recordemos que apenas si estamos empezando a conocer el sistema, solo nos ayuda a hacernos idea de lo que podría ser el Diagrama de clases más adelante.

 Dominar una cosa significa comprenderlo completamente, es eso mismo el modelo del dominio, comprender qué se desea del sistema y qué cosas intervienen. Esto es esencial, ya que de no tenerlo claro, se perderá el tiempo.  Modelo del dominio : dominar  el problema.(ponerle límites, para no irse por las ramas, como a tanta gente le gusta, empiezan a hablar, y luego esto, y luego esto más y que nos iremos a Japón, que ......, nada de demás). Debemos añadir algo importante, el dominio aquí no significa que nosotros lo dominaremos de primer intento, ese es el objetivo pero entiendase bien que dominio de dominio es el esbozo del diagrama de clases, OK.

Siguiente paso:

Modelo de Casos de Uso.

El modelo de Casos de Uso  se logra a partir de una serie de pasos.

Debemos preguntarnos:

Quiénes utilizarán el sistema?   De allí sacaremos a los actores

Qué hacen los usuarios?          De allí sacamos los casos de uso.

Por ejemplo :   Qué hace un editor en una página web?

Escribe y diagrama los artículos, por lo tanto, el actor será  Editor y el caso de uso será  Escribir un artículo

Qué hace un visitante a nuestra web?.

Navega y elige qué tema leer, por lo tanto el actor será Invitado y el caso de uso Navegar

Que hace el administrador de la web?

Da permisos para que los usuarios ingresen, por lo tanto  el actor será Administrador y el caso de uso Dar Permiso a Usuarios

Nos preguntaremos por cada detalle del funcionamiento del sistema hasta que todo quede claro, de allí tendremos un diagrama de Casos de Uso.

EL MODELO DEL DOMINIO

   Es posible que  muchos de los alumnos que recién inician con el ICONIX no estén familiarizados con el modelo del dominio, de hecho no se toca mucho en el RUP.

  No hay que hacerse problemas, el modelo de dominio es solo un  un DIAGRAMA DE CLASES SIN DETALLES  ( Sin atributos, Sin métodos), solo muestra las relaciones.

  El Modelo del dominio es apenas un bosquejo inicial de lo que deseamos realizar, por ello no debe causar mayor preocupación y solo aplicar los conocimientos de  la elaboración de los diagramas de Clases

RAZONES PARA UTILIZAR ICONIX

  Había un tiempo, y aun hoy es posible que podamo entregarnos de frente a la codificación de software, bueno para un pequeño proyecto, qué sentido tiene planificar, analizar, diseñar, etc. Total acaso nos pagaran tanto esfuerzo y es más acaso no lo termnarán pirateando.

  Ciertamente un programador se enfrenta a todos estos desánimos y no tiene tanta fé como los academicos en el engorroso desarrollo de software.

  Diagrama de Robustez, diagrama de secuencia, vaya perdida de tiempo, ya entiendo por qué Bill Gates y Mark Zuckerberg salieron corriendo de las universidades y se dedicaron a desarrollar sus softwares prácticos reales y rápidos. De estar en la universidad todavía seguro estarián estancados en el proceso de RUP o Iconix. 

 Lo cierto es que las Universidades solo cumplen su función, total de donde van a vivir tantos docentes universitarios, alguna mentira tienen que inventar. 

Desarrollar software en éste sentido se hace cada vez más engorroso, es como pensar y analizar como comer una manzana. De razón Steve Jobs  fué práctico y  lejos de analizar, diseñar, cogió la manzana y le dió su mordisco.

Y con todo vale la pena utilizar iconix.

Bueno, si, y mucho.

Primero para lograr el grado, el título y la maestría y el doctorado 

Lo cierto es que el software es todo un mundo complejo, es como estructurar un gran edificio, si es desalentador no ver el edificio si avanza o no. Todo parece teoría, todo es árido y lo peor es que todo parece tan obvio. 

Casos de Uso?, para que. Ni que fuera un tonto para no saber que es lo que hace un cliente para comprar, ni lo que hace el cajero para despachar. Pero la verdad, es que nuestro super software nos permite dominarlo, aunque para ello de niños tuvimos que aprender  y con 11 años en la escuela y otros tantos en la universidad , pues todo parece fácil aunque de primeras no lo es.

El asunto es sencillo, las computadoras son bebés, no saben nada del mundo, tendrán sus RAM y calcularán  pero no saben como hacer las cosas, es por ello que tenermos que prepararles el purecito para que puedan entender lo que tienen que hacer, y si solo le decimos haz esto, pues ellas, las computadoras no entenderán  y lo harán mal.

Por ello es importante iconix, tenemos que  analizar, y luego diseñar un prototipo, luego diseñar, probar y comprobar si la computadora lo va ha entender , por eso existen pruebas. 

Y luego de todo , las computadoras lo hacen casi perfecto, pero ni de lejos sueñes que con eso termino. No para nada, necesitarán revisiones, adaptaciones en fin. Y bueno eso es lo maravilloso de la Ingeniería de Software, nosotros los ingenieros de software somos los bondadosos padres que le enseñan el mundo a las computadoras y luego ellas nos enseñan su mundo  y crecen y aprenden y hacen cosas que ni nos imaginabamos.