En UML utilizamos los diagramas Los Diagramas de Casos de Uso , los diagramas de clases, diagramas de secuencia, diagramas de estados.
Al iniciar un proyecto debemos iniciar con tener los requerimientos del usuario, entendiendo las reglas del negocio.
Despues iniciar con los diagramas de casos de uso y los formatos de casos de uso, valiendonos de los prototipos,para comunicarnos con el usuario. Por cada proceso dentro del negocio utilizar los diagramas de actividades para entender mejor el proceso como puede ser "inscribir alumno", "facturar venta" u otro.
Los casos de uso debemos verlos desde la perpectiva del negocio y utilizar verbos en infinitivo dentro de cada caso de uso.
28 comentarios:
Comentarios del Modelado en UML desde la perspectiva de los que iniciamos con la Programacion Estructurada y del nuevo paradigma POO
dentro de los casos de uso tenemos dos opciones el uso de include y extends donde :
A)"include" esta relación tiene que ser de por lo menos 2 casos de usos los cuales son llamados casos de uso padres, y casos de uso hijos, en los cuales los casos de usos padres tienen incluido los casos de uso hijos, y la condición mas importante es que los casos de usos hijos siempre se tienen que cumplir cuando se lleva a cabo el caso de uso padre.
b)"extend" esta se utiliza cuando un caso de uso hijo no forzosamente se ejecuta, o bien el caso de uso padre tiene 2 opciones a elegir, los cuales son 2 casos de uso hijos, y se ejecuta alguno de ellos dependiendo el resultado de caso de uso padre.
BUENO ANTES DE COMENZAR A BLOGGEAR HARE UN RESUMEN DE:
¿QUE ES UML?
UML
Lenguaje Unificado de Modelado
en inglés
Unified Modeling Language
Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group).
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software.
UML ofrece un estándar para escribir un "plano" del sistema (modelo),incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables.
Es importante resaltar que UML es un "lenguaje" para especificar y no para describir métodos o procesos.
Se utiliza para definir un sistema de software, para detallar los artefactos en el sistema y para
documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede
aplicar en una gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa (Lengua de Modelación
Unificada), no es programación, solo se diagrama la realidad de una utilización en un requerimiento.
Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos,
sin embargo, la orientación a objetos viene siendo un complemento perfecto de UML, pero no por eso se
toma UML sólo para lenguajes orientados a objetos
SIGUIENDO CON LAS OPCIONES EN LOS CASOS DE USO
TENEMOS EL SIGUIENTE:
----GENERALIZACION---
TERCERA FORMA DE RELACIONES ENTRE CASOS DE USO
Un caso de uso dado puede estar en una forma especializada de un caso de uso existente.
La notación es una línea solida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil factorizar comportamientos comunes, restricciones al caso de uso general, descríbelos una vez, y enfréntarte a los detalles excepcionales en los casos de uso especializados.
"Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intensión y extensión."
ORIGENES DE UML
Método de Booch. Booch 1981
OOSE (Ingeniería de Software Orientada a Objetos) Jacobson 1986
OMT (Técnicas de modelado de Objetos) Rumbaugh 1991
UML es un lenguaje basado en la notación gráfica, no es una metodología
Sirve para:
Modelar
Especificar
Construir
Documentar
Pero, por qué modelamos?
Se desea construir un edificio
¿cómo haríamos un edificio sin planos?
¿Cómo dividiríamos el trabajo entre los trabajadores?
¿Cómo relacionaríamos la tubería y la instalación eléctrica con los demás?
¿Esperaría el cliente hasta la terminación para evaluar si es lo que quiere?
Se modela:
Para manejar la complejidad
Para enfocar aspectos específicos
Es más barato
Para proponer soluciones
Mucho se ha hablado acerca de la programación orientada a objetos (poo), y cabe destacar que es o viene siendo un paradigma difícil de comprender para aquellos que nos iniciamos en otro tipo de programación (la programación estructurada), pues como es bien sabido, muchos se adaptan más fácilmente al cambio que otros.
Muchas de las veces, nos resulta difícil comprender que las cosas que antes hacíamos, ahora deben de hacerse de otra manera diferente, y es aquí entonces cuando nos aterramos al oír hablar de Clases, Entidades, Objetos, Etc. y no quiere decir que lo que antes hacíamos estuviese mal, sino que para hoy día, las tecnologías requieren de otro tipo de soluciones, soluciones más pequeñas, más rápidas, más eficientes y más Ágiles, soluciones inteligentes que se adapten al cambio y que realmente nos ayuden a resolver el problema y no a agravarlo.
Y aquí cabe destacar que este tipo de programación viene siendo más sencilla hasta cierto punto, pues es casi como una base de datos cuando le aplicamos la primera forma normal, realmente lo que debemos de hacer es dividir el problema en sus partes más pequeñas (atómicas), como bien dice el dicho “Divide y Vencerás”, yo en lo particular concibo de esta forma a la Poo y a lo que es Uml, no obstante es mi muy humilde opinión y mi forma de ver las cosas, pero de antemano lo sabemos, que todo cambio es bueno, y en el caso de cambiar de una programación estructurada a una programación orientada a objetos, no creo que sea la excepción…
Empezaremos a habler sobre UML.
El Lenguaje de Modelado Unificado (UML por sus siglas en inglés), es el estándar de la OMG (Object Management Group) para el modelado orientado a objetos y es la herramienta de modelado por las siguientes razones:
- Provee de un lenguaje de modelado expresivo y visual.
- Es independiente de lenguajes de programación y los procesos de desarrollo.
- Cubre los requerimientos de modelado de los sistemas actuales, por ejemplo, sistemas concurrentes y distribuidos.
- Está enfocado a proporcionar un lenguaje de modelado estándar y no a un proceso estándar
Hay dos tipos de diagramas en UML:
*Diagramas estructurales. Muestran la estructura estática y los elementos del sistema.
Se dividen en los siguientes diagramas:
– Clases.
– Objetos
– Componentes
– Paquetes
– Distribución
*Diagramas de comportamiento. Muestran la dinámica de la funcionalidad del sistema. Se dividen en los siguientes diagramas:
– Casos de uso
– Interacción:
• Secuencia
• Comunicación
• Tiempo
– Actividades
– Estados
¿Qué es UML? Comenzaré por decir que UML no es un lenguaje de programación, es más bien un lenguaje de propósito general para el modelado orientado a objetos, es un lenguaje de modelamiento lo que permite una abstracción del sistema y sus componentes.
Anteriormente existían diversos métodos y técnicas Orientadas a Objetos, con muchos aspectos en común pero utilizando distintas notaciones, lo que representaba inconvenientes para el aprendizaje, aplicación, construcción y uso de herramientas, etc., además de pugnas entre enfoques, lo que generó la creación del UML como estándar para el modelamiento de sistemas de software principalmente, pero con posibilidades de ser aplicado a todo tipo de proyectos. Lo que UML intenta hacer es solucionar el problema de propiedad de código que se da (daba) con los desarrolladores, al implementar un lenguaje de modelado común para todos los desarrollos se crea una documentación también común, que cualquier desarrollador con conocimientos de UML será capaz de entender, independientemente del lenguaje utilizado para el desarrollo.UML es ahora un standard, no existe otra especificación de diseño orientado a objetos. Su utilización es independiente del lenguaje de programación y de las características de los proyectos, ya que UML ha sido diseñado para modelar cualquier tipo de proyectos, tanto informáticos como de arquitectura, o de cualquier otro ramo.
A propósito de UML
Para todos los que requieren una herramienta como Microsoft Visio para poder realizar cualquier tipo de diagramas, ya sea que trabaje en el área de diseño, arquitectura , desarrollo de software o redes, existen alternativas en línea al Microsoft Visio como Gliffy Online(http://www.gliffy.com/)
Como todos sabemos Microsoft Visio es una buena herramienta para realizar cualquier tipo de diagrama, pero debemos contar con una licencia para poder utilizarla, por eso me parece una buena alternativa el poder trabajar con esta herramienta que nos permite realizar casi todo lo que podemos hacer con Microsoft Visio.
La herramienta es Gliffy Online, para poder entrar al sitio es necesario registrarnos, pero también tenemos la alternativa de probar la aplicación online sin tener que registrarnos.
La interfaz de usuario de Gliffy no se parece a la de Microsoft Visio, pero es sencilla de utilizar, además en el lado izquierdo están los botones que se clasifican según lo que queramos diagramar. Sólo tenemos arrastrar los elementos hacia la parte central de la pantalla y listo, podemos configurarla, poner característica como color, colocar texto,etc. ¿Qué te parece esta herramienta?.
Para poder Modelar con UML valdria la pena reflexionar en donde empezar si a programar con objetos que puede ser .net con C# o java o mejor iniciar con la herramienta UML.Ustedes que piensan empiezo a programar o empiezo a modelar.
Bueno, se supone que en todo proyecto, siempre hay varias etapas que se deben de seguir para el desarrollo de este; como la fase de análisis, diseño, programación, etc., esto se debe seguir si es que se quiere tener un proyecto sólido y completo.
En teoría, yo no puedo empezar a programar una aplicación, sin antes saber lo que quiero hacer, y los estándares, las normas y el UML entre otros, nos dicen que primero debemos diseñar todo lo que vamos a hacer, y plasmar esas ideas en forma gráfica (diagramas), dicho de otra forma, “modelar”.
Pero la mayoría de las veces venimos haciendo todo lo contrario, hacemos un rápido pseudo análisis del problema y nos sentamos a escribir líneas de código para tratar de darle solución al mismo, y al final de la aplicación empleamos un tipo de ingeniería inversa en la cual empezamos a plasmar en papel o más bien justificar en el, del porqué hicimos tal línea de código, por que tal conexión o porque tal registro, tabla, columna, etc.
Muchos de nosotros tal parece que todavía nos debatimos entre seguir esos estándares que nos garantizan el éxito de un proyecto o seguir al programador que todos llevamos dentro que inconscientemente solo nos dice: “Programa, programa, programa…”
Cabe mencionar que lo mas importante aquí es ver el papel que juega el cliente. Se preguntaran por que el cliente. Bueno, por que en la mayoría de las ocasiones, muchos de nosotros estamos acostumbrados a hacer lo que uno piensa y como uno lo ve, y eso es lo que plasmamos en código, y posteriormente se le enseña al cliente lo que uno ha hecho. Sin embargo, ¿cuando se tomo en cuenta lo que el cliente opinaba o lo que el cliente quería?, nunca, ¿verdad? Y no se les toma en cuenta por que pensamos que el cliente jamás entenderá nuestros tecnicismos, y tiene razón, si es una persona común, no involucrada en estos temas, jamás lo entenderá por mas que lo expliquemos. Entonces es aquí en donde concluimos que primero tiene que ser el modelado, por que en este caso, es mucho mas fácil que por ejemplo el cliente pueda entenderme un diagrama de actividades, en donde se plasme lo que el en algún momento pidió o lo que el maneja a la perfección día a día en la empresa, o un prototipo en donde se le indique cuales serían los pasos a seguir para realizar cierto procedimiento. Por lo tanto una vez que uno le haya mostrado al cliente las funciones que el sistema será capaz de realizar en base al modelado, ya con mucho mayor seguridad iniciaríamos con la programación de este. O si estoy equivocada díganmelo, a cuantos de ustedes que han realizado un sistema por pequeño que sea, el cliente les ha dicho: esto es exactamente lo que quería…
Así que aunque casi siempre seamos todologos (analistas, modeladores, programadores, etc.) y nos cueste mas trabajo y tiempo, hay que MODELAR primero….
Sobre el comentario de Modelado en UML desde la perspectiva de los que iniciamos con la Programación Estructurada y del nuevo paradigma POO, cabe mencionar que la diferencia entre cada paradigma está en el enfoque. La programación estructurada, como su nombre lo indica... pretende "separar" el pensamiento y funcionamiento por módulos con combinaciones de sentencias simples y complejas. Y en una escala más alta de abstracción, se encuentra el enfoque OO en donde cada elemento de la "realidad" es un ente, un objeto. Entonces, un conjunto de objetos que comparten características comunes forman una clase. La clase físicamente no existe, mas bien es un elemento abstracto. Para comprender mejor he aquí un ejemplo: podemos distinguir muchos tipos de autos... pero a final de cuentas... todos son autos. "Internamente" nuestro razonamiento nos dice: "que todo objeto que posea cuatro ruedas, 2, 4 o 5 puertas, techo y un motor pertenece a la categoría o clase auto". En cuestiones informáticas, se dice que la clase es la estructura base de donde cada INSTANCIA de la clase es un objeto. Y así podemos armar un conjunto de clases y subclases: Garfield es un gato, pero un gato es un animal, entonces, Gato es una subclase de animal, y Garfield es una INSTANCIA de Gato. Esto es lo que se conoce como Herencia. A la par vienen el concepto de polimorfismo y el de especificación.
El enfoque OO está dirigido también por un principio fundamental: el encapsulamiento.
La idea central del encapsulamiento es "Yo te digo superficialmente lo que se hacer y tu me dices lo que deseas saber de mi" Y esta es la manera en que cada objeto se comunica con otro: uno le dice a otro que lo que desea obtener y éste se lo hace sin darle demasiado detalles. Por ejemplo: Tu necesitas dinero, vas al banco y pides un préstamo. Le dices a la cajera (o el personal encargado) y le dices lo que deseas. A ti no te interesa saber en profundidad como es el procedimiento interno del banco para realizar el préstamo. Simplemente te dicen lo que debe serte comunicado y listo. Es decir que el encapsulamiento sirve para ocultar información a lo demás que simplemente no debe saber. Se da a conocer solo lo necesario para que otro pueda trabajar.
En pocas palabras, POO es un "nuevo" enfoque: Se ve la realidad como un gran conjunto de objetos que se relacionan y hacen su tarea apoyándose unos a otros. Para que juntos consigan un objetivo mayor del que podrían conseguir en forma aislada.
Esto no quiere decir que se haya abandonado la estructuración, aun sigue existiendo, pero con otro grado de abstracción. Cada clase debe responder a los principios de Cohesión y Acoplamiento. Una clase internamente debe estar estructurada de modo que exista un grado de "afinidad" entre sus contenidos: funciones, eventos, etc... Una clase que no sabe lo que hace es una clase que no sirve. Por otro lado, una clase que no sabe delegar información (dar a conocer su funcionamiento superficialmente) conduce a una mala modularidad.
Primero se modela y después se programa. Una vez que se sabe que, supuestamente, todo es un objeto, y cómo aprender a pensar al estilo orientado a objetos, podemos empezar a crear “buenos” diseños que aprovechen las ventajas de todos los beneficios que ofrece la POO.Para ello utilizaremos una metodología la cual consiste en un campo de muchos experimentos como son:
*XP: EXTREME PROGRAMMING (Kent Back ).
*CRYSTAL LIGHT METHODS (Alistair Cockburn).
*SCRUM
*DYNAMICS SYSTEMS DEVELOPMENT METHODS (DSDM.
*ADAPTIVE SOFTWARE DEVELOPMENT (ASD)
Así que antes de elegir un método, es importante comprender cuál es el problema que se va a resolver, y el primer paso es El análisis de requisitos dice: “Haga una lista de las directrices que usará para saber cuándo ha hecho su trabajo y el cliente estará satisfecho”. Segundo la especificación del sistema dice: “Hay una descripción de lo que hará el programa (no cómo) por satisfacer los requisitos”. El análisis de requisitos es realmente un contrato entre usted y el cliente (incluso si el cliente trabaja dentro de su compañía o es algún otro objeto o sistema). Las especificaciones del sistema son una exploración de alto nivel del problema y en algún sentido un descubrimiento de si se puede hacer y cuánto se tardará. Dado que ambos requerirán consenso entre la gente (y porque suelen cambiar todo el tiempo), creo que es mejor mantenerlos todo lo escueto posible -en el mejor de los casos, listas y diagramas básicos- para ahorrar tiempo. Podría tener otras restricciones que le exijan ampliarla en documentos más grandes, pero manteniendo el documento inicial pequeño y conciso, puede crearse en algunas sesiones de tormentas de ideas de grupo con un líder que cree la descripción dinámicamente. Esto no sólo solicita participación de todos, también fomenta aprobación inicial y llegar a acuerdos entre todos. Quizá lo más importante sea empezar el proyecto con mucho entusiasmo
¿QUE ES POO?
Existe una gran variedad de respuestas a esta pregunta, y probablemente todas ellas se pueden reducir a la misma cosa.
primeramente pensemos un momento en el paradigma de la programación tradicional.
Tradicionalmente, un problema informático se ataca produciendo algún tipo de representación de datos y procedimientos que operan sobre esos datos. Bajo este modelo, los datos son inertes, pasivos e incapaces. Están a la completa merced de un gran cuerpo procedimental, que es activo, lógico y todopoderoso.
El problema con esta aproximación es, que los programas los escriben humanos, que sólo pueden retener cierto número de detalles en sus cabezas en un momento determinado. A medida que crece el proyecto, el núcleo procedimental crece hasta un punto que se hace difícil recordar cómo funciona todo el conjunto. Pequeños lapsos de pensamiento o errores tipográficos llegan a ser errores muy ocultos. Empiezan a surgir interacciones complejas y sin intención dentro de este núcleo y el mantenimiento se convierte en algo parecido a transportar un calamar gigante intentado que ninguno de sus tentáculos te alcance la cara. Existen políticas de programación que ayudan a minimizar y localizar errores dentro de este paradigma tradicional pero existe una solución mejor que pasa fundamentalmente por cambiar la forma de trabajar.
Lo que hace la programación orientada a objetos es, delegar la mayoría del trabajo mundano y repetitivo a los propios datos; modifica el concepto de los datos que pasan de pasivos a activos. Dicho de otra forma.
* Dejamos de tratar cada pieza de dato como una caja en la que se puede abrir su tapa y arrojar cosas en ella.
* Empezamos a tratar cada pieza de dato como una máquina funcional cerrada con unos pocos interruptores y diales bien definidos.
Lo que se define anteriormente como una "máquina" puede ser, en su interior, algo muy simple o muy complejo. No se puede saber desde el exterior y no se nos permite abrir la máquina (excepto cuando estamos completamente seguros de que algo está mal en su diseño), por lo que se nos obliga a conmutar interruptores y leer los diales para interactuar con los datos. Una vez construida, no queremos tener que pensar en como funciona internamente.
Se podría pensar que estamos haciendo más trabajo nosotros mismos, pero esta forma de trabajo tiende a ser un buen método para evitar que vayan mal todo tipo de cosas.
Comencemos con un ejemplo que es demasiado simple para tener algún valor práctico pero que al menos muestra parte del concepto. Nuestro coche consta de un odómetro. Su trabajo consiste en llevar un registro de la distancia recorrida desde la última vez que se pulsó el botón de reinicialización. ¿Cómo podríamos representar esto en un lenguaje de programación? En C, el odómetro sería, simplemente, una variable numérica de tipo float. El programa manipularía esa variable aumentando el valor en pequeños incrementos y ocasionalmente la reinicializaría a cero cuando fuese apropiado. ¿Qué hay de malo en esto? Un error en el programa podría asignar un valor falso a la variable, por cualquier número de razones inesperadas. Cualquiera que haya programado en C sabe que se pueden perder horas o días tratando de encontrar ese error que una vez encontrado parece absurdamente simple. (El momento de encontrar el error es indicado por una sonora palmada en la frente).
En un contexto orientado a objetos, el mismo problema se puede atacar desde un ángulo completamente diferente. La primera cosa que se pregunta un programador al diseñar el odómetro no es "¿qué tipos de datos son los más cercanos para representar esta cosa?" sino "¿cómo se supone que actúa esta cosa?". La diferencia termina siendo profunda. Es necesario dedicar cierto tiempo a decidir para qué es exactamente un odómetro y cómo se espera que el mundo exterior interactúe con el. Se decide entonces construir una pequeña máquina con controles que permitan incrementar, reinicializar y leer su valor y nada más.
El odómetro se crea sin un mecanismo para asignarle un valor arbitrario, ¿Por qué? porque es de todos sabido que los odómetros no trabajan de esa forma. Existen sólo unas cuantas cosas que un odómetro puede hacer, y sólo permitimos esas cosas. Así, si alguien desde un programa trata de asignar algún otro valor (por ejemplo, la temperatura límite del sistema de control de climatización del vehículo) al odómetro, aparece de inmediato una indicación de lo que va mal. Al ejecutar el programa se nos dice (o posiblemente, al compilarlo dependiendo de la naturaleza del lenguaje) que No se nos permite asignar valores arbitrarios al objeto Odómetro. El mensaje podría ser menos preciso, pero sí razonablemente próximo al problema. Esto no evita el error, ¿verdad? pero apunta rápidamente en la dirección de la causa. Esta es sólo alguna de múltiples formas en las que la programación POO nos puede evitar muchas pérdidas de tiempo.
Existe, normalmente, un nivel de abstracción superior a éste porque resulta que es igual de fácil construir una factoría que hace máquinas como hacer una máquina individual. Es poco probable que construyamos un único odómetro, sino que nos preparamos para construir cualquier cantidad de odómetros a partir de un único patrón. El patrón (o si los prefieres, la factoría de odómetros) es lo que se conoce como clase y el odómetro individual sacado del patrón (o construido en la factoría) se conoce como objeto.
HE DICHO - LEGION
Continuando con la descripcion del modelado es necesario no perder de vista lo que se está intentando conseguir en esta fase: determinar el sistema que se supone que quiere hacer. La herramienta más valiosa para eso es una colección de los llamados “casos de uso”. Los casos de uso identifican características clave en el sistema que pueden revelar algunas de las clases fundamentales que se usarán. En esencia son respuestas descriptivas a preguntas como:
1. “¿Quién usará el sistema?”
2. “¿Qué pueden hacer estos actores con el sistema?”
3. “¿Cómo puede este actor hacer eso con este sistema?”
4. “¿Cómo podría alguien más hacer este trabajo si alguien más estuviera haciéndolo, o si el mismo actor tuviera un objetivo diferente?” (para revelar variaciones).
5. “¿Qué problemas podrían ocurrir mientras hace esto con el sistema?” (para revelar excepciones).
¿Cómo podemos construirlo?
En esta fase debe aparecer un diseño que describa qué clases hay y cómo interactúan. Una técnica excelente para determinar clases es la tarjeta Clase-Responsabilidad-Colaboración (Class-Responsibility-Collaboration) o CRC.
1. El nombre de la clase. Es importante que el nombre refleje la esencia de lo que hace la clase, así todo tiene sentido con un simple vistazo.
2. Las “responsabilidades” de la clase:
3. Las “colaboraciones” de la clase: ¿qué otras clases interactúan con ésta?
Las fichas CRC ayudan a realizar un acercamiento con un primer corte del diseño y que pueda obtener una visión global y después refinar su diseño.
Uno de los mayores beneficios de las tarjetas CRC es la comunicación. Se hace mejor en tiempo-real, en grupo, sin computadores.
Ramiro Tolentino Lemus.
Para realizar o desarrollar un software, primero se debe tener claro cual es el objetivo de ese software, donde, quien, y para qué se va a utilizar. Todo esto se logra mediante lo que se llama Análisis y Diseño de software. Pero para llegar a esto primero se tiene que realizar una entrevista al que va a pagar el software, y al que lo va a usar. De ahi surgenlas necesidades o requerimientos del software y en base a elo se raliza el análisis y diseño del software a desarrollar.
Para ello existen herramientas como UML para diseñar y plantear la forma en cómo funcionará nuestro software independientemente del lenguaje de programación en que se baya a programar.
Cabe mencionar que el éxito de nuestro software dependerá de un buen análisis y diseño que se realice del problema a resolver, por lo que primero epezaremos por modelar nuestro software.
Posteriormente se procederá a la programación, y esta tambien se debe analizar en el sentido de que se tiene que ver sobre qué plataforma funcionará nuestro software, si de manera local, intranet o internet, de manera centralizada o distribuida.
Definitivamente, si deseamos ahorrar tiempo, manipular la complejidad de información robusta, enfocar aspectos específicos y proponer soluciones inmediatas a nuestros clientes, debemos modelar.
¿Y qué tal si se logra algunas fases del diseño y programación en el desarrollo de sistemas a la par?
Si contamos con el valioso recurso tiempo, lo podríamos lograr con los IDES, tales como Eclipse. Un Ambiente Integrado de Desarrollo (Integrated Development Environment o IDE por sus siglas en inglés) es una herramienta utilizada por los desarrolladores de sistemas para ayudarlos durante las diferentes fases del desarrollo de sistemas. Eclipse es un IDE de código abierto (open source) que soporta muchos lenguajes de programación. Eclipse viene con un Ambiente de Desarrollo de Java (Java Development Environment o JDE) que incluye un editor de resalte de sintaxis, un compilador, un depurador, un navegador de clases y un administrador de archivo/proyecto. La funcionalidad de Eclipse puede ser extendido con plug-ins tales como plug-ins de UML para modelación Orientada a Objetos.
Entonces, ¿cuándo debemos emplear el modelado?
Según texto del libro “UML para programadores Java” de Prentice Hall:
• Cuando varias personas necesiten entender la estructura de una particular parte del diseño porque todos ellos lo estarán trabajando simultáneamente.
• Cuando dos o más personas estén en desacuerdo con un elemento particular debería ser diseñado, y quieres un consenso del equipo. Pon la discusión dentro de una caja de tiempo para elegir un significado para decidir, como un voto o un juicio imparcial.
• Cuando necesites exponer una estructura de alguna parte del código a alguien más o a ti mismo.
• Cuando este cerca al la finalización del proyecto y tus clientes tienen peticiones como parte de un flujo de documentación para otros.
Respecto a qué hacer primero ,si programar con objetos o utilizar UML ? Mi punto de vista es que no se puede llevar a cabo un proyecto de desarrollo de software si no se conoce primero que se quiere hacer, si se desconocen cuales van a ser los requerimientos del proyecto y cual es el resultado final que se desea obtener del mismo. Es decir, es una tarea infértil el querer programar a “ciegas” o quererlo realizar sin saber que se va a hacer, y ahí es donde cobra su importancia UML que en palabras más, palabras menos nos indica que todo lo que vamos a hacer primero hay que plasmarlo en forma de diagramas especificando todo lo que se requiere hacer, cada proceso y/o tarea a realizar para llegar a tener un buen proyecto y una vez que tenemos todo lo anterior, hasta entonces pasar a la programación. Por lo que la respuesta es sin temor a equivocarme primero es modelar y luego programar.
Bien trataré de explicar que el paradigma de la programación orientada a objetos se basa en la idea de un objeto, que es algo así como una combinación de variables locales y procedimientos llamados métodos que juntos conforman una entidad de programación. Está basado en varias técnicas, incluyendo herencia, modularidad, polimorfismo, y encapsulamiento.
La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar, mientras que la programación estructurada
es una forma de escribir programación de computadora de forma clara, para ello utiliza únicamente tres estructuras: secuencial, selectiva e iterativa; siendo innecesario y no permitiéndose el uso de la instrucción o instrucciones de transferencia incondicional. Que para todos aquellos que nos iniciamos en el paradigma de la programación estructurada es complicado asimilar el de la programación orientada a objetos, pero esto no quiere decir que no entendamos(o por lo menos en mi caso) que es una forma más óptima de programar, que nos permite representar todo como objetos(clases, instancias,etc.) y que al combinarlo con UML modelando dichos objetos, obtenemos mejores y más eficientes resultados(proyectos) con la ventaja de que además puede ser reutilizables.
Complementando a lo que comentaba Mendiola en días pasados sobre alternativas de software para modelar, navegando en la red me encontré por casualidad un listado de Software libre (open source) para realizar modelado.
Dentro de estas herramientas tenemos:
• ArgoUML
• Dia
• Omondo Eclipse UML
• Poseidon UML
• UMLet
• Together
• Visual Paradigm SDE
• Slime UML
Todas estas herramientas, entre otras, son de distribución comercial, gratuita y de evaluación; la mayoría permite realizar diversos diagramas basados en UML, y algunas de ellas se integran con algún otro software para poder sacar un mejor provecho al momento de modelar.
Si les interesa este documento, lo pongo a su disposición en el siguiente Vinculo:
Descargar
Espero les sirva esta información, Saludos y Hasta Pronto...
Ramiro Tolentino Lemus
Respecto al nuevo paradigma de la programación orientada a objetos y el anterior que era la programación estructurada, puedo decir que la POO es otra forma de programar en la que el concepto fundamental es "OBJETO" y un objeto representa a alguna cosa de la realidad como un coche, una escuela, edificio, persona, empleado, alumno, hospital, etc. Aqui se manejan otros conceptos como: clase,Atributos, Métodos, herencia,etc.
Estrictamente ya en la POO, un objeto es la abstracción del mundo real y que tiene atributos(características)y métodos que no son otra cosa que las acciones que el objeto realiza. Lo que son las propiedades y métodos se agrupan en algo llamado clases, y entonces podemos decir que una clase es como un prototipo o plantilla para crear objetos. Lo que se hace en las clases es extraer las características y las accines más importantes de un objeto y a partir de ello se cominenza a diseñar y programar algun software.
Al principio cuesta trabajo adaptarse a este nuevo enfoque, pero creo que es una forma más eficiente de programar, aunque no se debe menospreciar tambien a la programación estructurada porque en ella aprendimos la lógica de la programación.
Bueno, empezaré por disculparme por no haber podido entrar a tiempo y forma a este blog. Leyendo los comentarios de los compañeros diré k comparto muchas de ellas por no decir todas, empezando por comentario k hace Demetrio sobre k la POO es un paradigma difícil de comprender para aquellos que nos iniciamos en otro tipo de programación, es decir, la programación estructurada, pues en mi caso se me ha estado haciendo un poco difícil adaptarme al cambio, haciendo honor al comentario k el mismo hace en torno a k para algunos nos es mas difícil adaptarnos al cambio, pues en la programación estructurada nunca escuchamos sobre la existencia siquiera de conceptos como Clases, Entidades, Objetos, Herencia, Polimorfismo, etc, etc. y entonces, ¿La POO es una moda o..? Leyendo unos archivos proporcionados por el mtro Eduardo, dice k la poo es porque esta mas enfocado a la realidad ya que el mundo esta compuesto de objetos y "es mas fácil relacionar" y por consiguiente mas fácil de comprender.
y contestando a la pregunta del mtro. sobre si primero es modelar o primero modelar, la respuesta es obvia (después de 4 o 5 sesiones de UML), primero modelamos, es decir k si nuestro objetivo es un proyecto de software sólido debemos seguir una serie de fases: análisis, diseño, programación, etc., lo anterior sería lo ideal, pero desgraciadamente en mi caso vengo o soy producto de la programación estructura(Universidad), en donde la idea o el objetivo era obtener un producto de software de "manera rápida" sin el habito de primeramente "Arrastrar el làpiz". Precisamente producto de lo anterior se me ha estado haciendo un poco difícil adaptarme al cambio pero con un poquito más de esfuerzo estoy seguro lo lograré.
También kiero felicitar al compañero Demetrio por habernos proporcionado información en torno a otro softwares para modelar y so es muy bueno, ya k a veces "nos casamos" solamente con el primero (Visio) sin haber experimentado algunos otros.
Gracias
RAMIRO TOLENTINO LEMUS
Despues del curso que hemos tenido,podemos mencionar que UML nos permite modelar cualquier software que se baya a desarrollar, pasando por las diversas etapas de modelado del software hasta llegar a construir toda la parte de interfaz, lógica y de almacenamiento(base de datos)y con ello realizar un buen análisis y diseño para posteriormente entrar a la fase de programacióin.
Podemos decir entonces, que para que nuestro software sea de calidad, se debe realizar un buen análisis de requerimientos y continuar con el modelado que se apegue a estas necesidades del usuario que va a pagar y/o utilizar nuestro siftware.
Mas k un comentario, kiero felicitar a los compañeros por el gran esfuerzo k han o hemos hecho para salir adelante con esta materia, tambien agradecer al mtro. Eduardo por su paciencia y comprensiòn.
¡¡¡ha como aprendímos!!!
heeeeeeeee!!!
BUENO PRIMERO QUE TODO AGRADEZCO AL MTI EDUARDO VAZQUEZ ZAYAS EL HABERNOS ENSEÑADO QUE PARA REALIZAR UN SISTEMA NO SOLO ES PROGRAMAR SINO ANALIZAR EL PROBLEMA CON TODOS SUS DETALLES POSIBLES PARA QUE LA PERSONA QUE LO UTILIZE LE SEA MAS FACIL DE MANEJAR Y ENTENDER.ME COSTO APRENDERSOBRE ESTA MATERIA PERO AHORA TENGO UNA VISION UN POCO MAS CLARA SOBRE EL PARADIGMA DE POO.
Creo que me hubiera gustado tener más sesiones para poder abarcar a la par la programación orientada a objetos con el análisis y el modelado, se que fué maratónico este proyecto pero si lo hubiéramos logrado, muchas gracias a todos los compañeros, a los equipos y a nuestro maestro. Felices fiestas
Algunos beneficios que ofrece el modelado en UML:
Ofrece un proceso de modelado sin fallas durante elanálisis, para diseñar la implementación
Define una notación expresiva y consistente
Ayuda a señalar omisiones e inconsistencias
Soporta tanto análisis como diseño de pequeños y grandes
sistemas.
Pero algo que se me hace importante tambien es que UML son las siglas para Unified Modeling Language, que en castellano quiere decir: Lenguaje de Modelado Unificado. Para comprender qué es el UML, basta con analizar cada una de las palabras que lo componen, por separado.
Lenguaje: el UML es, precisamente, un lenguaje. Lo que implica que éste cuenta con una sintaxis y una semántica. Por lo tanto, al modelar un concepto en UML, existen reglas sobre cómo deben agruparse los elementos del lenguaje y el significado de esta agrupación.
Modelado: el UML es visual. Mediante su sintaxis se modelan distintos aspectos del mundo real, que permiten una mejor interpretación y entendimiento de éste.
Unificado: unifica varias técnicas de modelado en una única.
Ya que el UML proviene de técnicas orientadas a objetos, se crea con la fuerte intención de que este permita un correcto modelado orientado a objetos.
Publicar un comentario