UML (Unified Modeling Language)

Introducción

UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de facto de la industria, debido a que ha sido impulsado por los autores de los tres métodos más usados de orientación a objetos: G. Booch, I. Jacobson y J. Rumbaugh. Estos autores fueron contratados por la empresa Rational Software Co. para crear una notación unificada en la que basar la construcción de sus herramientas CASE. En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hp, Oracle o IBM, así como grupos de analistas y desarrolladores.

Esta notación ha sido ampliamente aceptada debido a que incorpora las principales ventajas de cada uno de los métodos particulares en los que se basa (principalmente Booch, OMT y OOSE). Con UML se fusiona la notación de estas técnicas para formar una herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo orientado a objetos.



Uno de los objetivos principales de la creación de UML era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario definir una notación y semántica común. En la Figura se puede ver cuál ha sido la evolución de UML hasta la creación de UML 1.3, en el que se basa este documento. Hay que tener en cuenta que el estándar UML no define un proceso de desarrollo específico, tan solo se trata de una notación.
Los modelos de UML están basados en los siguientes diagramas

• Diagrama de Estructura Estática.
• Diagrama de Casos de Uso.
• Diagrama de Secuencia.
• Diagrama de Colaboración.
• Diagrama de Estados.

Elementos comunes de todos los diagramas:

Dependencias

La relación de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento destino habría que revisar el elemento origen). Una dependencia se representa por medio de una línea de trazo discontinuo entre los dos elementos con una flecha en su extremo. El elemento dependiente es el origen de la flecha y el elemento del que depende es el destino (junto a él está la flecha).

Notas

Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Es un modo de indicar información en un formato libre, cuando la notación del diagrama en cuestión no nos permite expresar dicha información de manera adecuada. Una nota se representa como un rectángulo con una esquina doblada con texto en su interior. Puede aparecer en un diagrama tanto solo como unido a un elemento por medio de una línea discontinua. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc.

Diagramas de Estructura Estática

Los Diagramas de Estructura Estática de UML se van a utilizar para representar tanto Modelos Conceptuales como Diagramas de Clases de Diseño. Ambos usos son distintos conceptualmente, mientras los primeros modelan elementos del dominio los segundos presentan los elementos de la solución software. Ambos tipos de diagramas comparten una parte de la notación para los elementos que los forman (clases y objetos) y las relaciones que existen entre los mismos (asociaciones). Sin embargo, hay otros elementos de notación que serán exclusivos de uno u otro tipo de diagrama.

Diagrama de Casos de Uso

Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea.
Diagramas de Interacción
En los diagramas de interacción se muestra un patrón de interacción entre objetos. Hay dos tipos de diagrama de interacción: Diagramas de Secuencia y Diagramas de Colaboración.

Diagrama de Secuencia

Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo

Diagrama de Colaboración

Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere). A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboración muestran las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecución concurrentes deben determinarse explícitamente mediante números de secuencia.


Diagramas de Estado

Un Diagrama de Estados muestra la secuencia de estados por los que pasa bien un caso de uso, bien un objeto a lo largo de su vida, o bien todo el sistema. En él se indican qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera.
En cuanto a la representación, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos.

Bibliografía Recomendada
[Booch99] El Lenguaje Unificado de Modelado. G. Booch, J. Rumbaugh, I. Jacobson. Addison Wesley Iberoamericana, 1999.
[Fowler99] UML Distilled. M. Fowler, K. Scott. Addison-Wesley, 99.
[Larman99] UML y Patrones. C. Larman. Prentice Hall, 1999.
[OMG99] Unified Modeling Language Specification, v1.3. Object Management Group (OMG), 1999.
[OMG02] UML Home Page. Object Management Group (OMG). http://www.uml.org/

Created by Oscar Saavedra Rodrigo Ruminot Claudio Romero

Diagrama de flujo de datos.


El diagrama de flujo de datos (DFD), es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por "conductos" y "tanques de almacenamiento" de datos. Siendo éste, una de las herramientas más comúnmente usadas, sobre todo por sistemas operacionales en los cuales las funciones del sistema son de gran importancia y son más complejos que los datos que éste maneja.
Es importante tener en mente: los DFD no sólo se pueden utilizar para modelar sistemas de sistemas de proceso de información, sino también como manera de modelar organizaciones enteras, es decir, como una herramienta para la planeación estratégica y de negocios.
Los componentes de un diagrama típico de flujo de datos:
Proceso.
Flujo.
Almacén.
Terminador.


Proceso
El primer componente del DFD se conoce como proceso. Los sinónimos comunes son burbuja, función, transformación. El proceso muestra una parte del sistema que transforma entradas en salidas. El proceso se representa gráficamente como un círculo, como se muestra en la primera figura. Algunos analistas prefieren usar un óvalo o un rectángulo con esquinas redondeadas, como se muestra en la segunda figura . Y otros prefieren usar un rectángulo, como se muestra en la tercera figura . Las diferencias entre estas tres formas son puramente cosméticas, aunque obviamente es importante usar la misma forma de manera consistente para representar todas las funciones de un sistema.





Ejemplos de procesos.

Nótese que el proceso se nombra o describe con una sola palabra, frase u oración sencilla. Un buen nombre para un proceso generalmente consiste en una frase verbo-objeto tal como validar entradas o calcular impuesto. En algunos casos, el proceso contendrá el nombre de una persona o un grupo (por ejemplo, un departamento o una división de una organización), o de una computadora o un aparato mecánico.



Flujo
Un flujo se representa gráficamente por medio de una flecha que entra o sale de un proceso; un ejemplo se muestra en la figura:
Ejemplo de un flujo:

El flujo se usa para describir el movimiento de bloques o paquetes de información de una parte del sistema a otra.
En la mayoría de los sistemas que modele como analista, los flujos realmente representan datos, es decir, bits, caracteres, mensajes, números de punto flotante y los diversos tipos de información con los que las computadoras pueden tratar.
Nótese que el flujo de la figura tiene nombre. El nombre representa el significado del paquete que se mueve a lo largo del flujo. Un corolario de esto es que el flujo sólo lleva un tipo de paquete, como lo indica su nombre.
Los flujos muestran también la dirección: una cabeza de flecha en cualquier extremo (o posiblemente ambos) del flujo indica si los datos (o el material) se está moviendo hacia adentro o hacia fuera de un proceso (o ambas cosas). El flujo que se muestra en la figura (a) por ejemplo, indica claramente que el número se está mandando hacia el proceso denominado Validar números telefónicos. Y el flujo denominado honorarios de entrega de choferes de la figura (b) claramente indica que es una salida generada por el proceso Generar honorarios de entrega de choferes. Los datos que se mueven a lo largo de dicho flujo viajarán ya sea a otro proceso (como entrada) o a un almacén o a un terminador. El flujo de dos cabezas que se muestra en la figura (c) es un diálogo, es decir, un empacado conveniente de dos paquetes de datos (una pregunta y una respuesta) el mismo flujo. En el caso de un diálogo, los paquetes de cada extremo de la flecha deben nombrarse, como se ilustra en la figura (c).

(a):Flujo de entrada.

(b):Flujo de salida.

(c): Flujo de diálogo.

Almacén.
El almacén se utiliza para modelar una colección de paquetes de datos en reposo. Se denota por dos líneas paralelas, como lo muestra la figura. De modo característico el nombre que se utiliza para identificar al almacén es el plural del que se utiliza para los paquetes que entran y salen del almacén por medio de flujos.

Representación gráfica de un almacén:

Para el analista con conocimiento de proceso de datos es tentador referirse a los almacenes como archivos o base de datos; pero un almacén también pudiera consistir en datos almacenados en tarjetas perforadas, microfilm, microfichas, discos ópticos, etc. y un almacén también puede ser un conjunto de fichas de papel en una caja de cartón, nombres y domicilios en un directorio, diversos archivos en un archivero, o varias formas no computarizadas.
Aparte de la forma física que toma el almacén, también existe la cuestión de su propósito: ¿Existe el sistema por causa de un requerimiento fundamental del usuario o por algún aspecto conveniente de la realización del sistema?. En el primer caso, la base de datos existe como un área de almacenamiento diferida en el tiempo, necesaria entre dos procesos que ocurren en momentos diferentes.
Los almacenes se conectan por flujos a los procesos. Así, el contexto en el que se muestra en un DFD es uno de los siguientes (o ambos):
Un flujo desde un almacén.
Un flujo hacía un almacén.


Terminador.
El terminador gráficamente se representa como un rectángulo, como se muestra en la figura. Los terminadores representan entidades externas con las cuales el sistema se comunica. Comúnmente, puede ser una persona, o un grupo, por ejemplo, una organización externa o una agencia gubernamental, o un grupo o departamento que esté dentro de la misma compañía u organización, pero fuera del control del sistema que se está modelando. En algunos casos, un terminador puede ser otro sistema, como algún otro sistema computacional con el cual se comunica éste.

Representación gráfica de un terminador :

Existen tres cosas importantes que debemos recordar acerca de los terminadores:
Son externos al sistema que se está modelando.
Es evidente que ni el analista ni el diseñador del sistema están en posibilidades de cambiar los contenidos de un terminador o la manera en que trabaja.
Las relaciones que existan entre los terminadores no se muestran en el modelo de DFD.

A continuacion un ejemplo de un DFD realizado por nosotros de una orden de compra:

Integrantes: Sonia Bello, Joel Jil, Myckel Uribe.

Diagramas Entidad-Relación (E/R)

Introducido por Peter Chen en 1976, el modelo entidad-relación (E/R) es uno de los modelos más utilizado para el diseño conceptual de bases de datos por ejemplo SQL. Estos diagramas pueden ser usados para planteamientos de todo tipo pero se enfoca básicamente para modelamiento de datos (industria del Sw). Una de las ventajas del diseño E/R es que se expresa de forma grafica lo cual permite una fácil lectura, pero esto depende de la notación que se este usando para diagramarlos, pudiendo ser simbología de cardinalidad, diagrama Entidad/Relación, etc. la diferencia que se tienen entre cada una, es en la cantidad de datos que se pueden obtener de las entidades, a estos datos se les llaman atributos; pero la ventaja mas importante es que podemos hacer relaciones entre distintas entidades, las cuales se pueden referirse a otras entidades o así misma (recursividad). Un ejemplo que describe lo anteriormente dicho

La lectura para estos diagramas es obvia, en el primer ejemplo se puede decir que un alumno cursa (o puede cursar) un ramo y para el segundo modelo decimos que personas compran (o pueden comprar) casas, autos, etc.

Definiciones.-

Como ya se pudo distinguir, por cada entidad no se especifican nombre, edad, sexo, carrera, UA o cualquier otro dato que podríamos obtener de un alumno (como es el caso del ejemplo 1).

Entendiendo anterior la definición formal de entidad, relación, atributo:

Entidad: Cualquier objeto, real o abstracto, que existe en un contexto determinado o puede llegar a existir y del cual deseamos guardar información, por ejemplo: "RAMO", "ALUMNO",etc. Las entidades las podemos clasificar en:
- Regulares (Fuertes): aquellas que existen por sí mismas y que la existencia de un ejemplar en la entidad no depende de la existencia de otros ejemplares en otra entidad.
- Débiles: son aquellas entidades en las que se hace necesaria la existencia de ejemplares de otras entidades distintas para que puedan existir ejemplares en esta entidad.


Relación (interrelación): Se entiende por relación a la asociación, vinculación o correspondencia entre entidades. Por ejemplo, entre la entidad "ALUMNO" y la entidad "RAMO" podemos establecer la relación "CURSA" por que el profesor imparte cursos. Al igual que las entidades las interrelaciones se pueden clasificar en regulares y débiles, según estén asociando dos tipos de entidades regulares o una entidad débil con otra de cualquier tipo. Las interrelaciones débiles se subdividen en dos grupos:

- En existencia: cuando los ejemplares de la entidad débil no pueden existir si desaparece el ejemplar de la entidad regular del cual dependen.
- En identificación: cuando, además de ser una relación en existencia, los ejemplares de la entidad débil no se pueden identificar por sí mismos y exigen añadir el identificador principal de la entidad regular del cual dependen para ser identificados.

Atributos: Las entidades se componen de atributos que son cada una de las propiedades o características que tienen las entidades.


Simbología de cardinalidad.-

Como anteriormente se dijo existen varias formas de representar los diagramas de Entidad-Relación, una de esta es la simbología de cardinalidad. La cardinalidad es la proporción de relaciones entre objetos. Por ejemplo, una factura tiene varias lineas de detalle, esta relación es de 1 a n.

En cambio una empresa puede tener cero o varios departamentos (producción, finanzas, etc.), esta relación de uno o cero a muchos departamentos.

La todos los programadores usan la misma simbología de cardinalidad. Unos utilizan simplemente números y letras para mostrar la proporcionalidad de relaciones y otros utilizan símbolos geométricos.

La siguiente representación es por simbología geométrica:

La diagramación en el modelo E/R es riguroso si uno utiliza una forma de representar solo debe representar de esa manera sin combinar ninguno de los otros tipos de diagramas existentes. La utilización de la simbología anteriores puede combinar entre ellas según sea necesario esto lo hacemos ubicando al principio y al final una de los cuatro tipos de relación ya dados, de esta manera se obtienen relaciones uno a uno, uno a muchos, uno a cero o uno, etc.

En el ejemplo anterior se demuestran posibles combinaciones que se pueden hacer, la lectura de esta es la siguiente:

· Un profesor puede tener ninguna o varias asignaturas.
· Varios o un profesor puede tener un o muchos alumnos.
· Varios o un alumno puede tener una o varias asignaturas.

sitos de interes:

http://www3.uji.es/~mmarques/f47/apun/node1.html

http://www.programacion.com/tutorial/entidadrelacion/

http://www.monografias.com/trabajos14/tecnolcomp/tecnolcomp2.shtml

redactado por: josé valenzuela y Cia.

*Nombre de la tecnica: Nassi-Shneiderman Charts

*Autor(es): I. Nassi y B. Shneiderman en 1972

*Introduccion: En años recientes la programación estructurada ha emergido como tecnología de programación avanzada. Durante este tiempo, muchas herramientas se han desarrollado para facilitar el uso del programador de la programación estructurada. Una de estas herramientas, los organigramas estructurados se convirtió por I. Nassi y B. Shneiderman en 1972, está probando su valor en la fase del diseño y la fase de la codificación del desarrollo de programa.

*Proposito: Las cartas de N-S partieron para el reemplazo del diagrama de flujo o mapa tradicional el cual se implementa para hacer mapas mas detallados y para la documentacion. La carta N-S nos da una vista mas logica y estructurada del programa. Las cartas de N-S, representan estructuras de programa que tienen un punto de entrada y de salida, estan compuestas por estructuras de mando secuencial, de seleccion y repeticion. Es una alternativa de los diagramas de flujo y pseudocódigo, entre estas tecnicas el mapa N-S es el mas facil de leer y convertir para programar el codigo, sin embargo, es solo una herramienta de plan de procedimiento y no puede usarse para diseñar estructuras de datos.

*Caracteristicas:
(i) Ventajas:
1.- Son faciles de leer graficamente.
2.- Son una mejora de los diagramas de flujo y el pseudocodigo (segun los autores).
3.- Es facil convertir de carta N-S a codigo estructurado (pseudocodigo) & diagrama de flujo.
4.- Facilidad de aprendizaje de este tipo de carta.
5.-Facil uso de los editores estructurados.

(ii) Desventajas:
1.- Es una herramiento pobre para mostrar estructuras de alto nivel.
2.- Aunque es facil de leer, no siempre es facil de diagramar, puede tomar tres o cuatro veces mas tiempo para diagramar una carta N-S que para escribir el pseudocodigo equivalente.
3.- No esta orientado a bases de datos, no se une a un modelo de datos o a un diccionario de datos.
4.- Aunque pueda mostrar los componentes procesales basicos, no muestran las interfaces que conectan estos componentes.
5.- Considerando que es muy dificil mostrar el anidado en un diagrama de flujo tradicional, en la carta de N-S es totalmente facil.


Diagrama N-S.


Secuencia o proceso.


Secuencia o proceso paralelo
(Es decir varios a la vez)


Condicion por casos (Menu)


Seleccion.


Repeticion a traves de una condicion
(Do while & do until)

*Fase del Desarrollo que apoya: Las cartas de Nassi-Shneiderman son los medios de asistir a la fase del diseño determinar y definir los algoritmos apropiados por el que los procedimientos identificados puedan ser observados (tecnica a nivel funcional).

Links de ayuda: En ingles.
http://www.smartdraw.com/resources/centers/software/nassi.htm
http://www.sichemsoft.nl/indexuk.html
file:///C:/DOCUME~1/BEN~1.UMD/LOCALS~1/Temp/FrontPageTempDir/www.easycode-software.com


por Felipe Cid - Francisco Flores - Juan Carreño -

FLUJOGRAMA

Es una de las primeras técnicas de diagramación de algoritmos. Debido a su simpleza y a su vez fácil comprensión la convierte en una de las técnicas más solicitadas al momento de representar un algoritmo. Gracias a su fácil manejo esta ha sido implementada en procesos de programación, enfocada principalmente a un tipo estructurado. Hay que hacer notar que el flujograma no constituye una técnica estructurada, ya que esta no presenta un sistema jerarquizado de procesos y es tan solo secuencia.

¿Cual es el proposito del Flujograma?
Uno de los principales propósitos del flujograma es ayudar a una mejor comprensión y un rápido análisis de algoritmos, haciendo énfasis en sus procesos. Tal como lo indica su nombre consta de flujos de datos los cuales pueden ser procesados por distintos tipos de módulos que se presentan como operadores secuenciales, selectivos y repetitivos.

Caracteristicas

Entre las características más destacables del flujograma esta la muestra en forma clara y lógica de módulos que representan procesos, estos a su vez son fáciles de dibujar , leer y modificar. Además es detallado y puede ser generado a partir de un pseudocódigo. Como desventaja el flujograma no muestra la entrada o salida de datos para cada uno de sus procesos y como ya se menciono antes no presenta a sus módulos de forma jerárquica.
Hay que mencionar que existen dos principales tipos de flujograma, existe el flujograma de sistemas y flujograma de programas. El flujograma de sistemas muestra al usuario los datos de entrada, los procesos (sin especificar estos) y las salidas de manera que se caracteriza por que cada modulo representa un subprograma logrando así poder diagramar un programa completo sin mayores dificultades. El flujograma de programas muestra al usuario los procesos internos de los datos ingresados de forma secuencial y detallada sin mostrar los datos ingresados y las salidas sino solo el procesamiento de estos.
El diagrama de flujo o flujograma esta presente en la fase de diseño del programa para la resolución de un algoritmo siendo así indispensable para el análisis de los procesos.

Enlaces
http://www.infomipyme.com/Docs/GENERAL/Offline/GDE_04.htm
http://www.mailxmail.com/curso/informatica/programacionestructurada/capitulo8.
http://www.ilustrados.com/publicaciones/EpyAVEAyuudydVzsQh.php

Nombre de la tecnica: Diagrama de Michael Jackson.

Autor: Michael Jackson.

Proposito: Esta es una metodología creada por Michael Jackson de nacionalidad Inglesa. Esta metodología está basada en que estructuralmente el programa depende o se encuentra en función de la estructura de los datos que se manejan. Michael Jackson se ayuda con la implementación de módulos, siguiendo un orden jerárquico de acuerdo a los diferentes niveles en que se encuentra. Cada módulo se convierte en un dato o en un conjunto de datos. Gracias al desarrollo de estas estructuras se pueden podremos desarrollar otras que intervengan en el diseño del programa. Este método determina la lectura de arriba hacia abajo y de izquierda a derecha. Los problemas a resolver por medio de este método, deben seguir un determinado número de pasos:

1° Se definen los datos de entrada y salida.

2° A partir de diferentes estructuras de datos se crea la del programa.

3° El método posee recursos que pueden ser explotados a fin de obtener resultados.

4° Finalmente, se escribe el pseudocódigo y se codifica.

Caracteristicas: El diagrama Jackson representa una cadena de datos de entrada que abandonan el programa por salidas de una arquitectura de caracteres. Este digrama usa los mismos datos como el diagrama de Warnier. Esta representado solo por el diagrama jerarquico de datos estructurados; Tiende a quebrar y a ser muy dificultoso para aplicar a programas complejos. no tiene condiciones o variables de seleccion de control casos estructurados o loop estructurados. Los detalles del diseño, diagrama de jackson tiene forma de pseudocodigo (Estructura de texto) haciendo dificil su entendimiento. Nosotros preferimos el uso con cuatro lenguajes de generacion o HOS metodologia (Mas riguroso) . Otra caracteristica es que esta compuesta por cuatro componenentes basicas:

1. Secuencia: Se escribe en una secuencia ordenada en partes que ocurren en un especifico orden de izquerda a derecha.
2. Iteracion: Los módulos son ejecutados desde cero hasta n veces. Cuando existe un proceso repetitivo, se indica con un asterisco (*).
3. Seleccion: Uno de los módulos es seleccionado entre todos para ser ejecutado. El proceso se indica por medio de la letra O ubicado en el costado superior derecho que indica las partes de las componentes seleccionadas.
4. Elementario se dibujan en un diagrama de arbol estructurado como una caja rectangular el mas bajo nivel parte en el diseño.

Link de Interes:

http://www.dsic.upv.es/~alimartin/Publications_archivos/Tesis%20Maestria.pdf

Publicado por:

Karen Vidal M.

Daniela Muñoz A.

Blas Soto.

Nombre de la Técnica:

(Hierarchical Input-Process-Output)
HIPO DIAGRAMAS.

Autor:
International Business Machines Corporation o IBM.

Propósito:

La hipótesis en la que HIPO se basa es que es fácil perder la pista de la función deseada de un sistema o componente de un sistema grande. Esta es una razón por la que es difícil comparar los sistemas existentes contra sus especificaciones originales (y por lo tanto, porque pueden ocurrir fallas incluso en los sistemas técnicamente bien formulados).
Desde el punto e vista del usuario, una sola función puede a menudo extenderse a varios módulos, por lo tanto, el interés del analista es entender, describir y documentar los módulos y su interacción de forma que se obtenga el detalle suficiente, pero que no se pierda de vista el panorama general.
El diagrama HIPO son descripciones graficas del sistema, en vez de prosa o narrativa.

Características:

1. HIPO es una técnica que utiliza una serie de diagramas para mostrar el insumo, producto y las funciones de un sistema. Este muestra lo que el sistema hace pero no como lo hace.
2. Existen tres clases de diagramas HIPO: tabla de contenido visual, los diagramas detallados y los diagramas generales.
3. La tabla de contenido visual es el nivel superior del diagrama de HIPO. Es una estructura en forma de árbol que muestra los componentes generales de un sistema. No ofrece información de control ni describe los datos en el sistema.
4. En el diagrama general se describen las entradas, los procesos y las salidas de los componentes principales del sistema.
5. El diagrama detallado provee de la información necesaria para entender cuales son las entradas, procesos llevados a cabo y las salidas de un componente funcional.

Fase del Desarrollo que apoya:

Esta técnica da un enfoque al diseño de documentación de software para producir las especificaciones funcionales de un programa de arriba hacia abajo (jerarquía) y también reduce la complejidad del sistema, debido a que cada uno de sus componentes pueden ser manejado por separado.

Link de interés (inglés):

http://www.shk-dplc.com/cfo/articles/litigate.htm

Tabla Visual de Contenido

Diagrama General HIPO

Publicado por: Samuel Provoste S.