Está en la página 1de 3

DISEO, CONDUCCIN CON CASOS DE USO.

Iconix es un proceso que se encuentra entre el caso de RUP y XP, siendo ambas un conjunto de metodologas para el
desarrollo de software. En casi impulsado, carece de una gran cantidad de sobrecarga que RUP trae. Siendo
relativamente pequeo y estrecho, como XP. Tambin se hace uso racionalizado de UML, manteniendo un enfoque
claro en la trazabilidad de los requisitos. Respecto a los casos de usos impulsados trata los casos de usos especficos,
fcilmente comprensibles para que un equipo de proyecto pueda utilizar para impulsar el esfuerzo de desarrollo.
En la lectura se muestra un diagrama que representa la esencia de un enfoque racionalizado de desarrollo de software,
as como un conjunto de diagramas UML y algunas tcnicas que son llevadas a cabo para codificar de forma eficiente y
rpida. De la cual se muestran dos casos para el uso de modelado de objetos, estn son dinmica y esttica.
As mismo en la lectura se da una breve explicacin sobre el tema del modelado de dominio, que forma parte del
segundo artculo. Menciona que es la tarea de determinar las clases que podrn representar las cosas y conceptos
relacionados con el desarrollo de un sistema, para poder resolver el problema del diseo. Aunque el modelado de
dominio hace mayor hincapi en RUP y en XP.
El utilizar el modelado de casos ayuda para iniciar la construccin de un dinmico modelo de soluciones para el sistema
propuesto e implica trabajar en el interior de las necesidades de los usuarios.
En anlisis de robustez implica analizar el texto narrativo de casos de uso. La primer participacin es la identificacin del
conjunto de objetos que van a participar en los casos de uso, para despus clasificar los objetos en funcin de los roles
que desempean. As mismo sirve como diseo preliminar dentro del proceso, proporcionando el eslabn perdido entre
el anlisis y el diseo detallado. Para ello se necesita conocer algunos trminos, siendo:
Objetos directos. Es lo que los actores utilizan en la comunicacin con el sistema.
Objetos de entidad. Por lo general son los objetos del modelo de dominio.
Controladores. Sirve como pegamento entre los objetos de contorno y los objetos de entidad.
En el modelado de la interaccin es la fase en que se construyen los hilos que tejen sus objetos juntos, permitiendo
observar como el nuevo sistema lleva a cabo un comportamiento til. Los diagramas de secuencia permiten a los
diseadores realizar tres tareas fundamentales:
1. Asignar comportamiento entre objetos de contorno, objetos de entidad y los controladores que se convertirn en
objetos completos en el modelo.
2. Asignar comportamiento entre objetos de contorno, objetos de entidad, y los controladores que se convertirn en
objetos de pleno derecho en el modelo.
3. Finalizar la distribucin de las operaciones entre las clases.
Los diagramas detallados de clase a nivel de diseo resultan de la interaccin de modelos que representan una base
adecuada para pasar a la fase de codificacin de un proyecto. Y tres de las caractersticas ms significativas de este
enfoque son:
En primer lugar, es iterativo e incremental. Mltiples iteraciones se producen entre el desarrollo del modelo de dominio
y la identificacin y el anlisis de los casos de uso. El modelo esttico se refina progresivamente durante las iteraciones
sucesivas a travs del modelo dinmico (compuesto por los casos de uso, anlisis de robustez y diagramas de secuencia).
En segundo lugar el enfoque. Ofrece un alto grado de trazabilidad. A cada paso en el camino, usted se refiere de nuevo a
los requisitos de alguna manera. Nunca hay un punto en el que el proceso le permite alejarse demasiado de las
necesidades del usuario. La trazabilidad se refiere tambin al hecho de que puede realizar un seguimiento de los objetos
de escaln en escaln como el anlisis se funde con el diseo.
En tercer lugar el enfoque ofrece el uso racionalizado de UML. Al centrarse en un subconjunto del UML grandes ya
menudo difcil de manejar, un equipo de proyecto tambin puede atajar "parlisis de anlisis" en el pase.

Diseo de conducir: El Dominio del Problema
El dominio del problema se refiere a las cosas del mundo real, con relacin a los problemas respecto al sistema que se
est diseando para ser resuelto. La tarea del modelado de dominio se refiere a descubrir los objetos o clases que
representan esas cosas y conceptos.
La serie de casos de uso impulsada modelado de objetos nos permite conectar las partes estticas y dinmicas del
modelo, la cual es esencial si vamos a conducir nuestro diseo de aplicacin hacia adelante desde los casos de uso. El
modelo de dominio sirve como glosario que los escritores de casos de uso pueden utilizar en las primeras etapas.
Respecto al proceso de Iconix, el modelado de dominio implica trabajar hacia el exterior de los requisitos de datos para
construir un modelo esttico del dominio del problema relevante para el sistema propuesto. Este enfoque de adentro
hacia afuera contrasta con el enfoque de afuera hacia adentro como se toman hacia los requerimientos del usuario.
Respecto a los elementos clave de Modelado de dominio lo primero que debes hacer al construir un modelo esttico del
sistema, determinando las clases apropiadas que reflejen con fidelidad las abstracciones reales que presenta el dominio
del problema. Si ejecuta bien esta actividad, no slo tendr una base slida sobre la que construir el sistema, sino
tambin excelentes perspectivas para la reutilizacin de los sistemas que sern diseados y construidos en el tiempo.
Las mejores fuentes de clases es probable que sean el planteamiento del problema de alto nivel, los requisitos de nivel
inferior y el conocimiento experto del espacio del problema. A medida que se trabaja, se refinan las listas; poco a poco,
los sustantivos y sintagmas nominales se convertirn en objetos y atributos, mientras que los verbos y frases verbales se
convertirn en operaciones y asociaciones. Posesivos ("su", "nuestro" y "ellos") tienden a indicar que los nombres deben
ser atributos, en lugar de objetos.
Se deber tamizar a travs de su lista de clases de candidatos y eliminar los elementos innecesarios. As mismo se
buscan las clases que son redundantes, irrelevante, errnea o imprecisa. Las clases no esenciales tambin pueden
representar conceptos fuera del alcance del modelo o representar acciones a pesar de que estn redactadas como
sustantivos.
Se deber tomar algunas decisiones iniciales sobre la generalizacin ("tipo de" o "es un" relaciones entre las clases),
mientras que la construccin de su diagramas de la clase. Si lo necesita, y que se sienta cmodo hacerlo en esta etapa,
generalizar a ms de un nivel de una subclase. Se debe buscar tipo de declaraciones que son verdaderas en el mundo
real. Modelado de dominio es tambin el rea adecuada para las decisiones sobre las agregaciones ("parte de" o "tiene"
relaciones entre clases).
Al igual que un diagrama entidad-relacin ERD, el modelo de dominio, actualizado para mostrar las asociaciones,
relaciones estticas entre pares de clases, que debera ser una afirmacin verdadera sobre el espacio del problema,
independiente del tiempo (es decir, esttica). Este modelo sirve como base de su modelo de clase esttica.
Los errores de modelado de dominio ms comunes, que la mayora de los estudiantes comete son los siguientes:
1. No realice parametrizacin prematura, que implica la construccin de soluciones frescas de los patrones, que tienen
poca o ninguna relacin con problemas de los usuarios.
2. No crear una correlacin uno a uno entre las clases de dominio y las tablas de bases de datos relacionales.
3. No saltar directamente a las construcciones de implementacin tales como las relaciones de amistad y clases
parametrizadas.
4. No utilice nombres difciles de entender para sus clases.
5. No suponga una estrategia de implementacin especfico sin modelar el espacio del problema.
6. No debatir si se debe utilizar la agregacin o composicin para cada uno de su parte de las asociaciones.
7. No optimizar el cdigo para la reutilizacin antes de asegurarse de que haya satisfecho los requisitos del usuario.
8. No asignar operaciones a clases sin explorar casos de uso y diagramas de secuencia.
9. No hagas un sustantivo exhaustivo tal y anlisis verbo que se pasa a lo largo del camino.
10. No asigne inmediatamente multiplicidades a las asociaciones.