Actividad 3 Java uml

Aprendiz
FERNANDO GAVIRIA



Instructor
Ing. STELIA OSORIO PEUELA





Tercer Trimestre
Centro de Electricidad y Automatizacin Industrial CEAI Regional Valle
Anlisis y Desarrollo de Sistemas de Informacin
ADSI 52


Importancia de modelar antes de codificar.

Por qu modelar?
R/
Por qu nos ayuda a comprender cualquier sistema como este en su actualidad, tambin nos
ayuda a conceptualizar una solucin posible, permite una mejor comunicacin Desarrollador y
cliente, como tambin nos evita cometer ambigedades e interpretaciones errneas.

1. Explicar (muy diferente a predecir)
2. Guiar la coleccin de datos
3. Iluminar sobre dinmicas principales
4. Sugerir analogas dinmicas
5. Descubrir nuevas preguntas
6. Promover un hbito de mente cientfico
7. Relacionar resultados a rangos posibles
8. Iluminar sobre incertidumbres principales
9. Ofrecer opciones de crisis en casi tiempo real
10. Demostrar ventajas y desventajas / sugerir eficiencias
11. Poner a prueba la robustez de una teora prevaleciente a travs de perturbaciones
12. Exponer conocimiento prevaleciente como incompatible con datos disponibles
13. Entrenar a practicantes
14. Disciplinar el dilogo sobre polticas
15. Educar al pblico en general
16. Revelar que lo aparentemente simple (complejo) es complejo (simple)

Por qu construir modelos de Software?
R/
ayudan a entender, aclarar y transmitir las ideas que tiene sobre su cdigo y los requisitos del
usuario que el sistema de software debe satisfacer, adems permite ver y controlar la arquitectura
de un sistema, se puede descubrir posibilidades de simplificacin y reutilizacin y minimiza
posibles riesgos.

Por qu se deben construir modelos comprensibles antes de codificar?
R/
Porque nos ayuda a dar una interpretacin de un sistema mediante grficos o texto con modelos
explcitos que permiten fcilmente la comunicacin durante su desarrollo, que fcilmente son
interpretados por personas que no participaron en su diseo, adems es mucho ms reducido el
costo hacer una planeacin en el modelado ya que permite fcil rectificacin o retomar
nuevamente desde el inicio ya con ideas claras.






Cundo Diagramar y cundo no?

R/
Se debe diagramar cuando un grupo de personas necesitan comprender la estructura de
algo en particular en el diseo y esta finaliza en el momento en el que todos lo han
comprendido.
Cuando dos o ms personas no se han puesto de acuerdo en cmo se ha diseado un
elemento en particular y se requiere consenso en el equipo. En el debate debe haber un
tiempo prudencial, un medio de eleccin para decidir. Terminado el tiempo y tomada la
decisin se eliminara los diagramas.
Se necesitara al momento en que tengas ideas de posibles diseos en el cual los diagrama
te podrn ayudar, cuando esto te haya permitido tener la idea ya clara te deshars de los
diagramas.
Dibujaras diagramas cuando tengas que explicar algo de la estructura del cdigo o como
t lo interpretars.
Hars diagramas en la etapa final del proyecto y el usuario te lo ha solicitado como parte
de la documentacin para ser vista por otros.

Cuando No se deben hacer diagramas

No hagas diagramas por que el proceso te lo indique
No dibujar diagramas para crear documentacin compresible de la fase de diseo anterior
a la codificacin. Estos documentos casi nunca valen para nada y generan desgaste de
tiempo.
Hacer diagramas por cumplir y no sentirte mal, porque piensas que lo hacen los buenos
diseadores. Esto solo se har cuando algn proceso no entendible lo requiera.
No realizaras diagramas para que otras personas los codifiquen. Los arquitectos de
software participan en su propia codificacin de sus diseos.

Cmo hacer uso efectivo de Ulm

Cuando queremos y se requiera comunicar muchos de los conceptos y ms ideas del
diseo entre los desarrolladores y que pueden ser de gran beneficio para todos los
creadores de software.
Cuando se requiera hacer grandes guas donde se mostrar detalladamente las estructuras
del software, estas proporcionarn detalladamente referencias de la estructura del
sistema completo. Como adems servirn de herramientas de enseanza.
Creando un documento de diseo al finalizar el proyecto como ltima actividad del
equipo, este reflejara el estado del diseo y que podr ser utilizado por un nuevo equipo.

Adquiriendo el hbito de desechar diagramas uml y mejor adquirir el hbito de no crearlos
en medios persistentes. Deshacer y borrar frecuentemente lo que hacemos en pizarras o
en papel, no utilices de forma general una herramienta case o programa de dibujo, para
uml debe tener una vida corta.

Lograr mantener solo los diagramas adecuados, ya que expresan una solucin comn del
sistema como protocolos complejos que son complicados de ver el cdigo.
Mantener reas comunes convenientes y despejadas cuando las utilices
Poner los diagramas tiles en un servidor web u una base de reconocimiento de red.
Cuidadoso respecto a que diagramas son tiles y cules pueden ser modificados por
cualquier equipo como una noticia de momento
Mantener aquellos que sobrevivan un largo tiempo y son de gran valor.