El modelado sirve no solamente para los grandes sistemas, aun en
aplicaciones de pequeño tamaño se obtienen beneficios de modelado, sin embargo
es un hecho que entre más grande y más complejo es el sistema, más importante
es el papel de que juega el modelado por una simple razón: "El hombre hace
modelos de sistemas complejos porque no puede entenderlos en su
totalidad".
UML es una técnica para la especificación sistemas en todas sus fases.
Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño
antecesores y, precisamente, los padres de UML son Grady Booch, autor del
método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de
los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de
1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de
industrias alrededor del mundo: hospitales, bancos, comunicaciones,
aeronáutica, finanzas.
LENGUAJE UNIFICADO DE MODELADO
La finalidad de los diagramas es presentar
diversas perspectivas de un sistema, a las cuales se les conoce como modelo.
Recordemos que un modelo es una representación simplificada de la realidad; el
modelo UML describe lo que hará un sistema, pero no dice cómo implementar dicho
sistema.
DIAGRAMAS DE CASO DE USO.
El diagrama de casos de usos representa
gráficamente los casos de uso que tiene un sistema. Se define un caso de uso
como cada interacción supuesta con el sistema a desarrollar, donde se representan
los requisitos funcionales. Es decir, se está diciendo lo que tiene que hacer
un sistema y cómo.
DIAGRAMAS DE CLASES.
Los diagramas de clases describen la
estructura estática de un sistema. Las cosas que existen y que nos rodean se
agrupan naturalmente en categorías. Una clase es una categoría o grupo de cosas
que tienen atributos (propiedades) y acciones similares. Un ejemplo puede ser
la clase “Aviones” que tiene atributos como el “modelo de avión”, “la cantidad
de motores”, “la velocidad de crucero” y “la capacidad de carga útil”. Entre
las acciones de las cosas de esta clase se encuentran: “acelerar”, “elevarse”,
“girar”, “descender”, “desacelerar”. Un rectángulo es el símbolo que representa
a la clase, y se divide en tres áreas. Un diagrama de clases está formado por
varios rectángulos de este tipo conectados por líneas que representan las
asociaciones o maneras en que las clases se relacionan entre sí.
DIAGRAMA DE FLUJO DE DATOS
Los diagrma de flujos son una manera de
representar visualmente el flujo de datos a través de sistemas de tratamiento
de información. Los diagramas de flujo describen que operaciones y en que
secuencia se requieren para solucionar un problema dado.
Un diagrama de flujo u organigrama es una
representación diagramática que ilustra la secuencia de las operaciones que se
realizarán para conseguir la solución de un problema. Los diagramas de flujo se
dibujan generalmente antes de comenzar a programar el código frente a la
computadora. Los diagramas de flujo facilitan la comunicación entre los
programadores y la gente del negocio. Estos diagramas de flujo desempeñan un
papel vital en la programación de un problema y facilitan la comprensión de
problemas complicados y sobre todo muy largos. Una vez que se dibuja el diagrma
de flujo, llega a ser fácil escribir el programa en cualquier idioma de alto
nivel. Vemos a menudo cómo los diagramas de flujo nos dan ventaja al momento de
explicar el programa a otros. Por lo tanto, está correcto decir que un diagrama
de flujo es una necesidad para la documentación mejor de un programa complejo.
Diagrama de Contexto: Nivel 0
En el diagrama de contexto se caracterizan
todas las interacciones que realiza un sistema con su entorno (entidades
externas), estas pueden ser otros sistemas, sectores internos a la
organización, o factores externos a la misma. Se dibuja un sólo proceso que
representa al sistema en cuestión y se escribe su nombre en dicha burbuja como
un sustantivo común más adjetivos. De él solamente parten los flujos de datos
que denotan las interrelaciones entre el sistema y sus agentes externos, no
admitiéndose otros procesos ni almacenamientos en el dibujo.
Resulta de gran utilidad para los niveles
posteriores de análisis como herramienta de balanceo. Y es conocido como el
Diagrama de Flujo de Datos DFD de Nivel "0"
Diagrama de Nivel Superior: Nivel 1
En el diagrama de nivel superior se plasman
todos los procesos que describen al proceso principal. En este nivel los
procesos no suelen interrelacionarse directamente, sino que entre ellos debe
existir algún almacenamiento o entidad externa que los una. Esta regla de
construcción sirve como ayuda al analista para contemplar que en un nivel tan
elevado de abstracción (DFD Nivel 1) es altamente probable que la información
que se maneja requiera ser almacenada en el sistema aunque no esté especificado
por un requisito funcional , siendo en realidad un requisito-no funcional.
Diagrama de Detalle o Expansión: Nivel 2
En un diagrama de nivel 2 o mayor, comienzan
a explotarse las excepciones a los caminos principales de la información dado
que aumenta progresivamente el nivel de detalle. De aquí en adelante se
permiten los flujos entre procesos.
El DFD (Diagrama De Flujo De Datos) nivel 2
puede considerarse el máximo para ser validado en forma conjunta con el usuario
dado que en los niveles posteriores el alto grado de complejidad del diagrama
puede resultar de muy difícil lectura para personas ajenas al equipo de
sistemas. También se recomienda el diagrama de nivel superior.
No hay comentarios.:
Publicar un comentario