Procesos de Resolución de Problemas

...

variedad de tipos de diagramas. Cada una de estas representaciones ofrece una visión de uno

o más de los elementos del modelo.

●¿Cómo puedo estar seguro de que lo he hecho correctamente?: los productos de trabajo

del modelado del análisis deben revisarse en lo relativo a su corrección, integridad y

consistencia. Éstos deben reflejar las necesidades de todos los interesados (stakeholders) y

establecer una base desde la cual pueda conducirse el diseño.

Varias reglas prácticas que deben seguirse para crear el modelo de análisis

El modelo debe centrarse en los requisitos visibles dentro del problema o dominio de

negocio. El grado de abstracción debe ser alto de forma relativa. "No se debe perder

tiempo en detalles" que tratan de explicar cómo funcionará el sistema.

Cada elemento del modelo de análisis debe agregarse a un acuerdo general de los

requisitos de software y proporcionar una visión interna del dominio de información,

función y comportamiento del sistema.

Debe retrasarse la consideración de la infraestructura y otros modelos no funcionales

hasta el diseño. Por ejemplo, es posible que se requiera una base de datos, pero las

clases necesarias para implementarla, las funciones que se requieren para acceder a

ella y el comportamiento que se exhibirá cuando se utilice debe considerarse sólo

después de que se haya completado el análisis de dominio del problema.

● Varias reglas prácticas que deben seguirse para crear el modelo de análisis

Se debe minimizar el acoplamiento de todo el sistema. Es importante representar las

relaciones entre clases y funciones. Sin embargo, si el nivel de "interconexión" es

extremadamente alto se deben hacer esfuerzos para reducirlo.

Se debe tener la seguridad de que el modelo de análisis proporciona valor a todos

interesados. Cada circunscripción tiene su propio uso del modelo. Por los interesados

relacionados con los negocios deben utilizar el modelo para validar los requisitos; los

diseñadores, como base para el diseño; la gente de aseguramiento de la calidad, como

ayuda para planear pruebas de aceptación.

El modelo debe mantenerse tan simple como sea posible. No se deben agregar

diagramas adicionales cuando éstos no ofrezcan información nueva. No se deben

utilizar formas de notación nuevas cuando basta con una simple lista.

¿Qué es un Modelo?

Un modelo es una abstracción del sistema, especificando el sistema modelado desde

un cierto punto de vista y en un determinado nivel de abstracción. Un punto de vista es

por ejemplo una vista de especificación o una vista de diseño de sistema

Los modelos son abstracciones del sistema que construyen los arquitectos y

desarrolladores. Por ejemplo los trabajadores que modelan los requisitos funcionales,

piensan en el sistema con los stakeholders fuera de él y con los casos de usos en su

interior, no se preocupan de cómo es el sistema por dentro, solo de lo que puede hacer

para sus usuarios

Los trabajadores que construyen el diseño, piensan en los elementos estructurales

como subsistemas y clases

Un modelo es una abstracción semánticamente cerrada del sistema, es decir es una

vista autocontenida en el sentido que un stakeholder de un modelo no necesita para

interpretarlo mas información de otros modelos

Un modelo es una representación que capta los aspectos más importantes de lo que

estamos modelando y simplifica u omiten el resto. Un modelo de un sistema software

está construido en un lenguaje de modelado. Tiene semántica y notación. Incluye

gráficos y texto

Modelo del Sistema

● ¿Qué utilidad brindan los Modelos?

Para pensar el diseño de un sistema

La simplicidad de crear y de modificar modelos permite un pensamiento creativo e

innovación a bajo precio

Para explorar económicamente múltiples soluciones

Para trabajar con sistemas complejos

Los modelos son abstracciones de la realidad que nos permiten describirla en términos

comprensibles para todos los interesados

Facilitan la puesta en común y la comunicaciónquerimientos 5