ANÁLISIS Y DISEÑO DE SISTEMAS
Jimmy Leonel Vicente Guayanay
Jorge Gustavo Tandazo Cueva
Jimmy José Jaramillo Narvaez
Bryan Alberto Requenes Troya
Edmundo José Pezantes Urrego
Facultad de la Energía, las Industrias y los Recursos Naturales No
Renovables Carrera de Ingeniería en Sistemas/Computación
Julio, 2020
Loja, Ecuador
Metodología
Iconix
Historia
Fue elaborado por Doug Rosenberg y Jacobson que ha dado
soporte y conocimiento a la metodología ICONIX desde 1993.
Iconix
ICONIX es una metodología pesada-ligera de desarrollo de software,
unifica un conjunto de métodos de orientación a objetos con el objetivo
de tener un control escrito sobre el ciclo de vida de un proyecto.
Características Principales
Iterativo e
Incremental
● Se organiza en series de
mini-proyectos cortos
Trazabilidad
● Capacidad de seguir una
relación entre los
diferentes artefactos de
software producidos.
Dinámica del UML
● Ofrece un uso dinámico
del UML.
Fases de Iconix
1
Análisis
de
requisitos
2
Análisis
y
diseño
prelim
inar
3
Diseño
4
Im
plem
entación
Fases de Iconix
1 Análisis de requisitos
● Se realiza un levantamiento de todos
los requisitos que en principio deberían
ser parte del sistema
● Se debe capturar información sobre lo
que les gusta y lo que les desagrada a
los usuarios
Se lo puede resolver a través de las
siguientes técnicas:
● Modelo del dominio
● Prototipación rápida
● Modelo de Casos de Uso
Pasos a seguir:
1. Identificar objetos del dominio
2. Prototipo rápido
3. Identificar caso de uso
4. Organizar casos de uso en grupos
Meta: revisión de requerimientos
Fases de Iconix
1 Análisis de requisitos
Requisitos de usuario
Funcionales No Funcionales
1. Registrar usuario(DNI, NOMBRE EMPLEADO, APELLIDO
EMPLEADO, DIRECCIÓN, TELÉFONO, CELULAR, CORREO, TÍTULO,
CARGO, USUARIO, CONTRASEÑA)
2. Registrar proyectos(NOMBRE PROYECTO, CLIENTE,
DESCRIPCIÓN, TIEMPO ESTIMADO, CANT FASES, FECHA_INICIAL,
FECHA_FINAL, PRESUPUESTO)
3. Registrar fases de un
proyecto(NOMBRE_BASE,DESCRIPCION,TIEMPO ESTIMADO,
FEHCA_INICIO, FECHA_FINAL PRESUPUESTO)
4. Asignar un usuario a un proyecto(fase)
5. Registrar hora de ingreso y hora de salida del sistema por
dia
1. Acceder mediante un usuario y clave
2. El administrador puede designar los usuarios a las diferentes
fases
3. El administrador puede crear proyectos
4. El administrador puede registrar usuario
Fases de Iconix
1 Análisis de requisitos
● Modelo del dominio
Abstracción de los objetos y las
relaciones de agregación y
generalización que existen entre
ellos.
Utiliza un diagrama de clases de
alto nivel.
Ejemplo:
Enfoques para desarrollar el modelo de dominio
1 Análisis de requisitos
10) Enfocar objetos del mundo real(problemas del dominio)
9) Relaciones entre objetos(herencias y agregaciones)
8) Limitar el esfuerzo para construir el modelo de dominio
7) Organizar clases
6) No confundir el modelo de dominio con el modelo de datos
5) No confundir el modelo de dominio con una tabla de base de datos
4) Usar el modelo de dominio como un glosario de términos
3) Diagramar el MD antes del DUC
2) Dont expect (Diagrama de clases sea el final de su diagrama de dominio)
1) No ubicar screem, GUI classe dentro del MD
Fases de Iconix
1 Análisis de requisitos
● Prototipación rápida
Se intenta, en la medida de lo
posible, presentar un prototipación
rápida de las interfaces del sistema,
diagramas de navegación, entre
otros, para dar a los clientes una
mayor comprensión del sistema
propuesto.
Fases de Iconix
1 Análisis de requisitos
● Prototipación rápida
Fases de Iconix
1 Análisis de requisitos
● Modelo de Casos de Uso
El modelo de caso de uso comprende los
actores, el sistema y los propios casos de uso.
Los casos de uso permiten a los usuarios
estructurar y articular sus deseos
Enfoques para desarrollar el modelo de dominio
1 Análisis de requisitos
1. Seguir la regla de 2 párrafos
2. Organizar los UC en Diagrama
3. Escribir su UC en voz pasiva
4. Escribir el UC usando event/response flow
5. Use los GUI prototipos
6. Recuerde el UC ejecución de comportamiento
7. Escribir UC en el contexto del modelo del objeto
8. Escribir UC sustantivo/verbo/sustantivo
9. Referencias al modelo del dominio por el nombre
10. Referencia los boundary class por nombre
Fases de Iconix
2 Análisis y diseño preliminar
Pasos a seguir:
1. Escribir descripciones de casos de uso
● curso principal y alterno
2. Análisis de robustez
● Identificar grupos de objetos que realizan escenario
● Actualizar diagramas de clases del dominio
Meta: Revisión del diseño preliminar
❖ de usuario hacia el sistema
❖ de datos hacia el sistema
Fases de Iconix
2 Análisis y diseño preliminar
● Descripción de casos de Uso
Se describen los casos de uso con un flujo
principal de acciones y posibles flujos alternos
Fases de Iconix
2 Análisis y diseño preliminar
Fases de Iconix
2 Análisis y diseño preliminar
● Diagrama de Robustez
Es un híbrido entre diagrama de
clases y diagrama de actividades.
Se realiza un diagrama de
robustez, en donde se debe
ilustrar las interacciones
existentes entre los objetos
participantes de un caso de uso.
Componentes:
● Objetos fronterizos
● Objetos Controladores
● Objetos entidad
Diagrama de Robustez
● Diagrama de Robustez
Componentes:
● Objetos fronterizos
● Objetos Controladores
● Objetos entidad
Conexiones
● Boundary - Controller
● Entity - Controller
● Controller Controller
Fases de Iconix
3 Diseño
Pasos a seguir:
1. Asignar comportamiento
2. Para cada caso de uso
● Identificar mensajes y métodos
● Dibujar diagramas de secuencias
● Actualizar clases
3. Terminar el modelo
4. Verficar el cumpliento de los requerimientos
Meta: Revisión crítica del diseño
Fases de Iconix
3 Diseño
● Diagrama de secuencias
● Es el núcleo del modelo dinámico y
muestra todos los cursos alternos que
pueden tomar los casos de uso
● Especifica el comportamiento. La
representación se concentra sobre la
expresión de las interacciones
● Se componen de 4 elementos que
son: el curso de acción, los objetos,
los mensajes y los métodos
Pasos a seguir:
1. Escribir el código
2. Realizar pruebas
Meta: Entrega del sistema
4 Implementación
Fases de Iconix
Ventajas Desventajas
● Desarrollo incremental e iterativo y la
relativa facilidad con que se puede utilizar
en otras metodologías de desarrollo u otras
técnicas
● Satisface la mayor parte de los requisitos
del cliente
● Usa un análisis de robustez que reduce la
ambigüedad al describir los casos.
● Es usado en proyectos más ligeros que los
usados en RUP
● Proporciona suficientes requisitos y
documentación de diseño, pero sin parar el
análisis
● Es refinado y actualizado a lo largo del
proyecto
● Es necesario tener información rápida y
puntual de los requisitos, del diseño y de
las estimaciones
● No puede ser usado para proyectos
grandes
● Se debe de conocer los diagramas de UML
● Gran parte de la información la podemos
encontrar en inglés, lo cual requiere
establecer muy bien su comprensión
Iconix
Referencias:
[1] L. Olivia et al., “Aplicación de la metodología semi-ágil ICONIX para el
desarrollo de software: implementación y publicación de un sitio WEB para una
empresa SPIN-OFF en el Sur de Sonora, México”.
[2] “Manual Introductorio de Iconix: 1-¿Qué es Iconix?”
[3] C. Rebeca, P. De San, y M. Oliva, “Metodología ICONIX”.
[4] B. Chica y E. Xavier, “CD-5411”.
[5] D. Rosenberg y M. Stephens, Use case driven object modeling with UML:
Theory and Practice. 2007.
Metodología ICONIX

Metodología ICONIX

  • 2.
    ANÁLISIS Y DISEÑODE SISTEMAS Jimmy Leonel Vicente Guayanay Jorge Gustavo Tandazo Cueva Jimmy José Jaramillo Narvaez Bryan Alberto Requenes Troya Edmundo José Pezantes Urrego Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables Carrera de Ingeniería en Sistemas/Computación Julio, 2020 Loja, Ecuador
  • 3.
  • 4.
    Historia Fue elaborado porDoug Rosenberg y Jacobson que ha dado soporte y conocimiento a la metodología ICONIX desde 1993.
  • 5.
    Iconix ICONIX es unametodología pesada-ligera de desarrollo de software, unifica un conjunto de métodos de orientación a objetos con el objetivo de tener un control escrito sobre el ciclo de vida de un proyecto.
  • 6.
    Características Principales Iterativo e Incremental ●Se organiza en series de mini-proyectos cortos Trazabilidad ● Capacidad de seguir una relación entre los diferentes artefactos de software producidos. Dinámica del UML ● Ofrece un uso dinámico del UML.
  • 7.
  • 8.
    Fases de Iconix 1Análisis de requisitos ● Se realiza un levantamiento de todos los requisitos que en principio deberían ser parte del sistema ● Se debe capturar información sobre lo que les gusta y lo que les desagrada a los usuarios Se lo puede resolver a través de las siguientes técnicas: ● Modelo del dominio ● Prototipación rápida ● Modelo de Casos de Uso Pasos a seguir: 1. Identificar objetos del dominio 2. Prototipo rápido 3. Identificar caso de uso 4. Organizar casos de uso en grupos Meta: revisión de requerimientos
  • 9.
    Fases de Iconix 1Análisis de requisitos Requisitos de usuario Funcionales No Funcionales 1. Registrar usuario(DNI, NOMBRE EMPLEADO, APELLIDO EMPLEADO, DIRECCIÓN, TELÉFONO, CELULAR, CORREO, TÍTULO, CARGO, USUARIO, CONTRASEÑA) 2. Registrar proyectos(NOMBRE PROYECTO, CLIENTE, DESCRIPCIÓN, TIEMPO ESTIMADO, CANT FASES, FECHA_INICIAL, FECHA_FINAL, PRESUPUESTO) 3. Registrar fases de un proyecto(NOMBRE_BASE,DESCRIPCION,TIEMPO ESTIMADO, FEHCA_INICIO, FECHA_FINAL PRESUPUESTO) 4. Asignar un usuario a un proyecto(fase) 5. Registrar hora de ingreso y hora de salida del sistema por dia 1. Acceder mediante un usuario y clave 2. El administrador puede designar los usuarios a las diferentes fases 3. El administrador puede crear proyectos 4. El administrador puede registrar usuario
  • 10.
    Fases de Iconix 1Análisis de requisitos ● Modelo del dominio Abstracción de los objetos y las relaciones de agregación y generalización que existen entre ellos. Utiliza un diagrama de clases de alto nivel. Ejemplo:
  • 11.
    Enfoques para desarrollarel modelo de dominio 1 Análisis de requisitos 10) Enfocar objetos del mundo real(problemas del dominio) 9) Relaciones entre objetos(herencias y agregaciones) 8) Limitar el esfuerzo para construir el modelo de dominio 7) Organizar clases 6) No confundir el modelo de dominio con el modelo de datos 5) No confundir el modelo de dominio con una tabla de base de datos 4) Usar el modelo de dominio como un glosario de términos 3) Diagramar el MD antes del DUC 2) Dont expect (Diagrama de clases sea el final de su diagrama de dominio) 1) No ubicar screem, GUI classe dentro del MD
  • 12.
    Fases de Iconix 1Análisis de requisitos ● Prototipación rápida Se intenta, en la medida de lo posible, presentar un prototipación rápida de las interfaces del sistema, diagramas de navegación, entre otros, para dar a los clientes una mayor comprensión del sistema propuesto.
  • 13.
    Fases de Iconix 1Análisis de requisitos ● Prototipación rápida
  • 14.
    Fases de Iconix 1Análisis de requisitos ● Modelo de Casos de Uso El modelo de caso de uso comprende los actores, el sistema y los propios casos de uso. Los casos de uso permiten a los usuarios estructurar y articular sus deseos
  • 15.
    Enfoques para desarrollarel modelo de dominio 1 Análisis de requisitos 1. Seguir la regla de 2 párrafos 2. Organizar los UC en Diagrama 3. Escribir su UC en voz pasiva 4. Escribir el UC usando event/response flow 5. Use los GUI prototipos 6. Recuerde el UC ejecución de comportamiento 7. Escribir UC en el contexto del modelo del objeto 8. Escribir UC sustantivo/verbo/sustantivo 9. Referencias al modelo del dominio por el nombre 10. Referencia los boundary class por nombre
  • 16.
    Fases de Iconix 2Análisis y diseño preliminar Pasos a seguir: 1. Escribir descripciones de casos de uso ● curso principal y alterno 2. Análisis de robustez ● Identificar grupos de objetos que realizan escenario ● Actualizar diagramas de clases del dominio Meta: Revisión del diseño preliminar ❖ de usuario hacia el sistema ❖ de datos hacia el sistema
  • 17.
    Fases de Iconix 2Análisis y diseño preliminar ● Descripción de casos de Uso Se describen los casos de uso con un flujo principal de acciones y posibles flujos alternos
  • 18.
    Fases de Iconix 2Análisis y diseño preliminar
  • 19.
    Fases de Iconix 2Análisis y diseño preliminar ● Diagrama de Robustez Es un híbrido entre diagrama de clases y diagrama de actividades. Se realiza un diagrama de robustez, en donde se debe ilustrar las interacciones existentes entre los objetos participantes de un caso de uso. Componentes: ● Objetos fronterizos ● Objetos Controladores ● Objetos entidad
  • 20.
    Diagrama de Robustez ●Diagrama de Robustez Componentes: ● Objetos fronterizos ● Objetos Controladores ● Objetos entidad Conexiones ● Boundary - Controller ● Entity - Controller ● Controller Controller
  • 21.
    Fases de Iconix 3Diseño Pasos a seguir: 1. Asignar comportamiento 2. Para cada caso de uso ● Identificar mensajes y métodos ● Dibujar diagramas de secuencias ● Actualizar clases 3. Terminar el modelo 4. Verficar el cumpliento de los requerimientos Meta: Revisión crítica del diseño
  • 22.
    Fases de Iconix 3Diseño ● Diagrama de secuencias ● Es el núcleo del modelo dinámico y muestra todos los cursos alternos que pueden tomar los casos de uso ● Especifica el comportamiento. La representación se concentra sobre la expresión de las interacciones ● Se componen de 4 elementos que son: el curso de acción, los objetos, los mensajes y los métodos
  • 23.
    Pasos a seguir: 1.Escribir el código 2. Realizar pruebas Meta: Entrega del sistema 4 Implementación Fases de Iconix
  • 24.
    Ventajas Desventajas ● Desarrolloincremental e iterativo y la relativa facilidad con que se puede utilizar en otras metodologías de desarrollo u otras técnicas ● Satisface la mayor parte de los requisitos del cliente ● Usa un análisis de robustez que reduce la ambigüedad al describir los casos. ● Es usado en proyectos más ligeros que los usados en RUP ● Proporciona suficientes requisitos y documentación de diseño, pero sin parar el análisis ● Es refinado y actualizado a lo largo del proyecto ● Es necesario tener información rápida y puntual de los requisitos, del diseño y de las estimaciones ● No puede ser usado para proyectos grandes ● Se debe de conocer los diagramas de UML ● Gran parte de la información la podemos encontrar en inglés, lo cual requiere establecer muy bien su comprensión Iconix
  • 25.
    Referencias: [1] L. Oliviaet al., “Aplicación de la metodología semi-ágil ICONIX para el desarrollo de software: implementación y publicación de un sitio WEB para una empresa SPIN-OFF en el Sur de Sonora, México”. [2] “Manual Introductorio de Iconix: 1-¿Qué es Iconix?” [3] C. Rebeca, P. De San, y M. Oliva, “Metodología ICONIX”. [4] B. Chica y E. Xavier, “CD-5411”. [5] D. Rosenberg y M. Stephens, Use case driven object modeling with UML: Theory and Practice. 2007.