Diferencias entre Análisis y Diseño Estructurado
y Orientado a Objetos

 

Definición de Sistemas de Información

Es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio. Y considera dos elementos necesarios:

§         El equipo computacional, que es el hardware necesario para que el sistema de información pueda operar.

§         El recurso humano que interactúa con el Sistema de Información, el cual está formado por las personas que utilizan el sistema.

Regresar

Definición de Metodología

Es una versión amplia y detallada del ciclo de vida completo del desarrollo de sistemas que incluye: tareas paso a paso para cada fase; funciones individuales y en grupo desempeñadas en cada tarea, productos resultantes y normas de calidad para cada tarea y técnicas de desarrollo que se utilizarán en cada tarea.

Regresar

 

Análisis Y Diseño De Sistemas De Información

 

El análisis y diseño de sistemas se refiere al proceso de examinar la situación de una empresa con el propósito de manejarla con métodos y procedimientos más adecuados. Se puede dividir en dos: el análisis de sistemas que comprende la planificación, el levantamiento inicial de información y el estudio en detalle del sistema actual para luego recomendar o estructurar las especificaciones necesarias para el nuevo sistema; y el diseño que consiste en llevar a cabo el sistema por medio de la clasificación y empleo de la información de manera que se pueda ofrecer una alternativa mucho más viable.

En pocas palabras; “El análisis especifica qué es lo que el sistema debe hacer. El diseño establece cómo alcanzar el objetivo”. Se deben utilizar metodologías que permiten ver los sistemas en base a sus procesos, por lo menos en sistemas de procesado por lotes o secuencial. Un ejemplo de ello es la metodología estructurada. Existen otras metodologías como la orientada a objetos.

Regresar

 

Método de Análisis y Diseño Estructurado

 

Este método es una actividad de construcción de modelos. Mediante una notación que es única, se crean modelos que reflejan el flujo y el contenido de la información (datos y control); el sistema se divide funcionalmente y, según los distintos comportamientos, se establece la esencia de lo que se debe construir.

Surge a mediados de los años 70, y ha ido evolucionando introduciéndose mejoras por varios autores; en los primeros años se centraba en las aplicaciones de sistemas de información, luego a mediados de los 80 se introducen mejoras que proporcionan una notación adecuada para los aspectos de control y de comportamiento de los problemas de tiempo real (Ward y Mellor, Hatley y Pirbhai).

El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o aplicación bien sea nuevo o ya existente. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento, etc.) sin omitir ningún detalle. Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.

El Diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software. El objetivo del Diseño Estructurado es programas formados por módulos independientes unos de otros desde el punto de vista funcional. La herramienta fundamental del Diseño Estructurado es el diagrama estructurado que es de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo). Los Diagramas Estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.

 

 

Modelado de Datos

 

El modelado de datos estudia los datos independientemente del procesamiento que los transforma.

El modelado de datos responde a:

§         ¿Cuáles son las entidades de datos primarios que va a procesar el sistema.?

• ¿Cuál es la composición de cada entidad de datos y que atributos la describen.?

§         ¿Cuál es la relación entre las entidades y los procesos que las transforman.?

Para resolver estas cuestiones se realiza el diagrama entidad-relación, donde se representa la red de datos que existe en el sistema dado, indicando los datos que se introducen, se almacenan se transforman y se producen dentro de la aplicación.

 

Modelado Funcional y Flujo de Información

 

Diagramas de flujo de datos (DFD)

Herramienta que nos permite mostrar el sistema como una red de sistemas conectados entre sí por los datos. Representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida.

Diagramas de flujo de Control (DFC)

Estas ampliaciones permiten al analista reflejar el flujo de control y el procesamiento de control; muestran como fluyen los sucesos entre los distintos procesos e ilustran como los sucesos externos hacen que se activen los procesos. El DFC contiene los mismos procesos que el DFD, pero muestra el flujo de control en lugar de datos. Esta ampliación se centra menos en la creación de símbolos gráficos adicionales y más en la representación y especificación de los aspectos del software orientados al control.

 

Modelado de Comportamiento

 

El modelado del comportamiento es uno de los principios fundamentales de todos los métodos de análisis de requisitos. El Diagrama de transición de Estado representa el comportamiento de un sistema que muestra los estados y los sucesos que hacen que el sistema cambie de estado.

 

Diccionario de Datos

 

El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista tengan una misma comprensión de las entradas, salidas, almacenes de datos y cálculos intermedios.

Se podría decir que el modelo de análisis estructurado toma la siguiente forma:

Diccionario de datos: contiene definiciones de todos los objetos de datos consumidos y producidos por el software.

Diagrama entidad-relación: representa las relaciones entre entidades de datos. Los atributos de cada entidad se pueden describir mediante la Descripción de datos.

Diagrama de flujo de datos (DFD): sirve para dos propósitos, indica como se transforman los datos a medida que se avanza en el sistema; y representa las funciones que transforman el flujo de datos. En la Especificación de proceso se encuentra un descripción de cada función representada en el DFD.

Diagrama de transición de estados (DTE): indica como se comporta el sistema como consecuencia de sucesos externos. La Especificación de control detalla mas información sobre los aspectos de control del software.

 

Características del Método Estructurado

 

§         Los productos de análisis han de ser de mantenimiento muy sencillo. Esto concierne concretamente al documento final (Especificación de requisitos del software).

§         Se deben tratar los problemas de gran tamaño mediante algún método efectivo de partición.

§         Siempre que sea posible, se deben utilizar gráficos.

§         Se deben diferenciar las consideraciones lógicas (esenciales) y las físicas (de implementación).

 

 

Desventajas del Método Estructurado

 

§         Esta metodología clásica presenta ciertos problemas, que han ido haciéndose cada vez más graves, a medida que se construían aplicaciones y sistemas informáticos más complejos, entre los que destacan los siguientes:

§         Modelo mental anómalo. Nuestra imagen del mundo se apoya en los seres, a los que asignamos nombres sustantivos, mientras la programación clásica se basa en el comportamiento, representado usualmente por verbos.

§         Es difícil modificar y extender los programas, pues suele haber datos compartidos por varios subprogramas, que introducen interacciones ocultas entre ellos.

§         Es difícil mantener los programas. Casi todos los sistemas informáticos grandes tienen errores ocultos, que no surgen a la luz hasta después de muchas horas de funcionamiento.

§         Es difícil reutilizar los programas. Es prácticamente imposible aprovechar en una aplicación nueva las subrutinas que se diseñaron para otra.

Regresar

 

Método de Análisis y Diseño Orientado A Objetos

 

El Análisis Orientado a Objetos (AOO) se define como "un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema", los objetos son entidades tangibles que muestran un comportamiento bien definido.

Todo esto quiere decir que el análisis orientado a objetos parte de entidades tangibles halladas en el problema, tales entidades varían dependiendo de los diversos casos prácticos, pero en todos los casos son elementos reales que toman parte del problema de forma directa.
El Diseño Orientado a Objetos (DOO) "es el método que lleva a una descomposición Orientado a Objetos. Aplicando DOO, se crea software resistente al cambio y escrito con economía de expresión. Se logra un mayor nivel de confianza en la corrección del software a través de la división inteligente de su espacio de estados. En última instancia, se reducen los riesgos inherentes al desarrollo de sistemas.
Los modelos del diseño orientado a objetos reflejan la importancia de plasmar explícitamente las jerarquías de clases y objetos del sistema que se diseña. Estos modelos cubren también el espectro de las decisiones de diseño relevantes que hay que considerar en el desarrollo de un sistema complejo, y así animan a construir implantaciones que posean los atributos de los sistemas complejos bien formados.

 

Etapas

 

1) Análisis de Requerimientos (Modelo Conceptual)

En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual se va a presentar la solución que se está buscando. Se examina los requisitos desde la perspectiva de los objetos y clases del dominio del problema.

Actividades de esta etapa:

§         Diagramar los casos de usos los cuales son una descripción de la secuencia de interacciones que se producen entre un actor y el sistema cuando el actor usa el sistema para llevar a cabo una tarea específica.

§         Detallar o describir la información de entrada y salida de cada caso de uso por medio de Diagramas de interacción de detalle (de secuencia o colaboración). 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. 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).

§         Definir la interfaz inicial del sistema (si es aplicable), lo cual puede hacerse por medio de un diagrama de estados el cual muestra la secuencia de estados por los que pasa un caso de uso o un objeto a lo largo de su vida, indicando qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera. También puede definirse una interfaz inicial por medio de una descripción textual del funcionamiento, diagramas de interacción o de un prototipo funcional.

§         Desarrollar el modelo del mundo mediante un diagrama de estructura estática de clases. Se deben identificar Clases Elementos físicos y lógicos dentro del sistema a modelar, comenzando por la clase del objeto más general (el mundo) Top-down, encontrando sus componentes hasta llegar a clases de tipos básicos.

§         Validar los modelos o restricciones descritas para las clases. Para cada clase evaluar la completitud de las restricciones, desarrollar objetos ejemplo que cumplan con las restricciones y que no sean válidos en el mundo real.

 

2) Diseño del sistema (Diagrama de Clases)

En esta etapa se define una subdivisión en aplicaciones del sistema (si es lo suficientemente grande) y la forma de comunicación con los sistemas ya existentes con los cuales debe interactuar.

Actividades:

§         Definir componentes del sistema, las aplicaciones y su ubicación. Representarlos por medio de nodos, componentes y objetos activos (representando las aplicaciones) dentro de los nodos.

§         Definir mecanismos de comunicación. Expresarlos por medio de asociaciones de dependencia entre los nodos, componentes o aplicaciones y, si es conocido, agregar un estereotipo para definir el protocolo de comunicación requerido. Agregar notas con restricciones, rendimiento esperado y demás detalles de las conexiones.

§         Particularizar los casos de uso a la arquitectura planteada. Refinar los casos de uso ya existentes de la etapa anterior para adecuarse a la arquitectura planteada.

§         Validar arquitectura. Comprobar la validez técnica, económica y organizacional de la propuesta.

 

3) Diseño detallado

En esta etapa se adapta el análisis a las características específicas del ambiente de implementación y se completan las distintas aplicaciones del sistema con los modelos de control, interfaz o comunicaciones, según sea el caso

Actividades:

§         Detalles de implementación del modelo del mundo: Completar detalles de las clases, atributos, diseño de asociaciones, métodos, etc

§         Desarrollar el modelo de interfaz: Enlazar las clases de interfaz con las clases del modelo del mundo

§         Desarrollar los modelos de control, persistencia y comunicaciones

 

4) Implementación y pruebas

Se desarrolla el código de una manera certificada.

Actividades:

§         Definir estándares de programación

§         Codificación y pruebas unitarias: Revisiones de código

§         Pruebas de módulos y de sistema: Se aplican algunos casos de prueba para el Procedimiento de instalación.

 

Características de la Orientación a Objetos

 

§         Abstracción: Denotación de características fundamentales.

§         Ocultación: Encapsulamiento de la implementación.

§         Modularidad: Fragmentación en componentes individuales.

§         Jerarquía: Clasificación de las abstracciones.

§         Tipificación: Caracterización de propiedades de una serie de entidades.

§         Concurrencia: Existencia de objetos activos.

§         Persistencia: Trascendencia en tiempo y/o espacio.

 

Ventajas de la Orientación a Objetos

 

Las principales ventajas del método orientado a objetos descansan en su posibilidad de hacer frente a dos temas esenciales: Gestión de la complejidad y Mejora de la Productividad en el proceso de desarrollo del software, los cuales son gestionadas a través de las siguientes estrategias:

§         Escribir código reutilizable

§         Escribir código posible de mantener

§         Depurar módulos de código existentes

§         Compartir código con otros

La complejidad se reduce y la productividad se mejora cuando se pueden volver a utilizar un código de alta calidad. Los mecanismos orientados a objetos en particular la herencia fomentan la reutilización así como el mantenimiento de sistemas.

Regresar

 

Enfoque Estructurado Vs. Enfoque Orientado a Objetos

 

En cuanto a la forma de desarrollar el análisis las metodologías son radicalmente diferentes desde su enfoque, la primera está orientada a procesos, tomando una visión donde los datos se consideran separadamente de los procesos que los transforman, dando más importancia a la descomposición funcional del sistema, y por tanto a los diagramas de procesos, esto puede parecer que lleva de manera más directa a la implementación del sistema, pero con frecuencia éste suele ser más frágil. Si cambian los requerimientos un sistema basado en descomposición funcional puede requerir una reestructuración masiva.

Por el contrario el enfoque orientado a objeto se centra en primer lugar en identificar los objetos del dominio de aplicación y después en establecer procedimientos que los manejen. Aunque esto pueda parecer más indirecto el software orientado a objeto se mantiene mejor ante los cambios de requerimientos porque se basa en la estructura subyacente del dominio de aplicación en vez de los requerimientos funcionales de un determinado problema.

 

 

Análisis y Diseño Estructurado (ADE)

 

• El Análisis se refiere al "extremo inicial" de un proyecto de desarrollo de sistemas, durante el tiempo en que los requisitos del usuario son definidos y documentados.

 

• El Análisis estructurado introduce el uso de las herramientas de documentación gráficas para producir un tipo diferente de especificación funcional: "la especificación estructurada".

 

 

Conceptos que se relacionan con el Análisis Estructurado

 

• Símbolos gráficos; iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.
• Diccionario de datos; descripciones de todos los datos utilizados en el sistema.
•  Descripciones de procesos y procedimientos; declaraciones formales que emplean técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.
• Reglas; estándares para describir y documentar el sistema en forma correcta y completa.

 

Fase de Diseño

 

En esta fase, el diseño estructurado produce el modelo de diseño con los siguientes elementos:

• Diseño de datos. Transforma el modelo de dominio de la información creado durante el análisis, en las estructuras de datos necesarias para implementar el software. Los objetos de datos y las relaciones definidas en el diagrama entidad-relación y el contenido detallado de datos del diccionario de datos constituyen la base para el diseño de datos.
• Diseño arquitectónico. Define la relación entre los principales elementos estructurales del programa. Se obtiene a partir del modelo de análisis y de la interacción de subsistemas definidos dentro del modelo de análisis.
• Diseño de interfaz. Describe como se comunica el software consigo mismo, con los sistemas que operan con él y con los operadores que lo emplean. Los diagramas de flujo de datos y control proporcionan la información necesaria para el diseño de la interfaz.
• Diseño procedimental. Transforma elementos estructurales de la arquitectura del programa en una descripción procedimental de los componentes del software. Se obtiene a partir de la especificación del proceso, la especificación del control y el diagrama de transición de estados

 

Análisis y Diseño Orientado a Objetos (ADOO)

 

Es un método de análisis que examina los requerimientos desde la perspectiva de clase y objetos encontrada en el vocabulario original del problema. Se fundamenta en un conjunto de cinco principios básicos:

• Modelar el dominio de la información.
• Describir la función del módulo.
• Representar el comportamiento del modelo.
• Dividir el modelo para mostrar más detalles.

 

En este tipo de análisis los modelos iniciales representan la esencia del problema, mientras que los últimos aportan detalles de la implementación.

 

Características del Análisis Orientado a Objetos

 

Identidad: Los datos están cuantificados en entidades discretas y distinguibles denominadas objetos. Estos pueden ser tangibles o intangibles.
Clasificación: Los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupan para formar una misma clase, se dice que cada objeto es una instancia de su propia clase, y una clase es una abstracción que describe propiedades importantes para una aplicación y se olvida del resto.
Polimorfismo: Significa que una misma operación puede comportarse de modos distintos en distintas clases, una operación es una acción o transformación que se aplica a un objeto.
Herencia: Comparte atributos y operaciones entre clases tomando como base una relación jerárquica, es decir que se puede definir una clase que después producirá subclases, sabiendo que todas las subclases adquirirán todas y cada una de las propiedades de su super-clase y le agrega además sus propiedades exclusivas.

 

Fase de Diseño

Para los sistemas orientados a objetos es posible definir un diseño en pirámide con las siguientes cuatro capas:
Subsistema. Contiene una representación de cada uno de los subsistemas que le permiten al software conseguir los requisitos definidos por el cliente e implementar la infraestructura técnica que los soporta.
Clases y Objetos. Contiene las jerarquías de clases que permiten crear el sistema utilizando generalizaciones y especializaciones mejor definidas incrementalmente. También contiene representaciones de diseño para cada objeto.
Mensajes. Contiene los detalles que permiten a cada objeto comunicarse con sus colaboradores. Establece las interfaces externas e internas para el sistema.
Responsabilidades. Contiene las estructuras de datos y el diseño algorítmico para todos los atributos y operaciones de cada objeto.

Regresar

 

Tabla de Diferencias

 

 

Regresar

 

Descripción De La Propuesta (Caso Práctico)

 

El desarrollo del portal www.investigaciones.edu;  para el departamento de investigación y pasantías del Instituto Universitario de Tecnología “Juan Pablo Pérez Alfonzo” le permitirá al departamento acceder de forma controlada a la información sobre los procesos académicos que se realizan en el mismo.

Del mismo modo, el portal propuesto esta basado en tecnología Web que ofrecen una serie de ventajas, beneficios, y oportunidades para los usuarios del mismo, donde pueden conocer todo  relacionado con los procesos que realiza el departamento, tales como: servicios que ofrece el departamento tanto a los profesores como a los alumnos, ubicación,  contactos,  resúmenes, entre otros.

 

Además, el portal propuesto  pretende funcionar como un instrumento que permite aligerar, buscar, controlar y suministrar un fácil manejo de los procesos        realizados en el departamento por los usuarios como lo son:

 

• Horarios.
• Cronogramas de Actividades.
• Entrega de notas de Planificación.
• Reuniones.
• Foros de Discusión.
• Material de Apoyo (Metodologías).
• Técnicas de Recolección de Datos.
• Información acerca de Empresas que buscan pasantes y viceversa.
• Material Bibliográfico para la consulta e investigación de trabajos de grado.
• Encuestas.
• Chat.
• Información del Departamento (Misión, Visión, Quienes son, Políticas, etc.).

 

Por otro lado, el portal www.investigaciones.edu, posee componentes de seguridad que permiten  al  departamento de investigaciones y pasantías por medio de un login y un password, no permitir la entrada a personas no autorizadas, las cuales son de uso exclusivo para el personal denominado Administrador.

 

CASOS DE USOS

 

            Por medio de los casos de usos, se modelan para todos los procesos del portal www.investigaciones.edu, además de una descripción textual y una secuencia de los pasos que se pueden realizar en el portal, esto se realiza con el propósito de tener un mejor entendimiento de la propuesta.

 

            A continuación se exponen los casos de usos en los cuales se pueden observar el modo en que se llevan a cabo los procesos dentro del portal propuesto:

 

Casos de usos – Acceso al portal.

 

 

 

Casos de usos – Acceso al portal.

 

 

Casos de usos – Acceso al portal.

 

NOMBRE DEL PROCESO		ACCESO AL PORTAL
ACTORES INTERNOS			ACTORES EXTERNOS
12	Si el usuario selecciona el icono de Eventos se desplegará una ventana donde vera todas las actividades que se realizaran en el departamento durante todo el semestre.
13	Al escoger el icono de Foros se despliega una página con los diferentes canales de foro que tiene el portal.
14	Si el usuario selecciona el links de Talleres el usuario tendrá toda la información sobre los últimos 2 o 3 talleres realizados y de los que se realizaran.
15	Si selecciona Servicios Académicos el usuario podrá conocer la información de todos los servicios que tengan que ver con el departamento
16	Si el usuario selecciona Administración se despliega una página donde el usuario podrá ingresar sus datos de usuario administrativo registrado para poder acceder a las páginas administrativas del departamento.
17	Si el usuario selecciona las encuesta podrá opinar sobre el tema en que se este realizando en la misma
18	Si el usuario selecciona el icono de Regístrate se desplegara una ventana donde podrá introducir sus datos para registrarse como usuario y de esta manera acceder a algunos canales del portal.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Diagrama de casos de usos Acceso a la página principal del portal.

 

 

Administración de Usuarios.

 

 

Diagrama de casos de usos Administrador usuarios.

 

 Administración de Canales.

 

 

Diagrama de casos de usos Administrador de canales.

 

 

 

Acceso a Foros.

NOMBRE DEL PROCESO		ACCESO A FOROS
PASO	DESCRIPCION
1	El usuario se conecta a la página de foros, en la misma se muestran los foros disponible, los mensajes existentes, los foros disponibles, el ultimo mensaje respondido, y el usuario que respondió.
2	Si el usuario selecciona unos de los foros en particular, muestra una página donde muestra toda la información existente en el portal sobre ese foro, en este se cuenta con dos botones que son regresar a todos los foros y crear un nuevo mensaje.
3	Si el usuario selecciona el botón de mensaje nuevo, se muestra un nuevo formulario para crear un nuevo foro si el usuario tiene sesión iniciada.
4	Si el usuario selecciona algunos de los mensajes mostrados en el foro se despliega una página con el mensaje y todas las respuestas al mismo.
5	Si el usuario selecciona el botón de responder mensaje se despliega una ventana donde le permite responder mensajes solo si tiene una sesión iniciada.

Diagrama de casos de usos El usuario accesa a foros.

 

 

Diagrama de casos de usos del portal para los administradores.

 

Regresar

 

Bibliografía

 

• Kendal & Kendall, Kenneth y Julie. (1997) Análisis y Diseño de Sistemas. Tecera Edición Editorial Prentice Hall. Mexico.
• Senn, James A. (1992) Análisis y Diseño de Sistemas de Información. Segunda Edición. Editorial McGrawHill. México.
• Sergio M FernándezSastre, Fundamentos del diseño y la programación orientada a objetos, editorial McGraw Hill.
• Sommerville I , Ingeniería de software,  editorial Addison-Wesley.

 

Regresar

 

Infografía

 

http://www.monografias.com/trabajos16/lenguaje-modelado-unificado/lenguaje-modelado-unificado.shtml: El presente artículo describe la evolución de las notaciones que dieron lugar a UML (Lenguaje de Modelado Unificado), detalla ampliamente sobre el surgimiento de la Ingeniería del Software, expone los principios de modelado en que se fundamenta la notación de UML, asimismo muestra y explica como el UML adopta el RUP(Proceso Unificado de Desarrollo) para modelar las actividades de un proyecto. Finalmente se propone la organización de los diagramas a utilizar en las diferentes etapas del desarrollo de los sistemas de información.

 

http://www.cs.ualberta.ca/~pfiguero/soo/metod/ : Esta página muestra la comparación y descripción de tres metodologías de desarrollo de software Orientado por Objetos.

 

http://www.utp.ac.pa/articulos/analisis_e.html: En este artículo se expondrán los tópicos relacionados a la transición por la que ha tenido que pasar el Análisis Estructurado. Según Pressman "Fue la aparición del diseño y la programación estructurada alrededor de los años 60´s la que dieron cabida al surgimiento del análisis estructurado, ya que existía la necesidad de utilizar una notación gráfica para representar los datos y los procesos que los transforman". Es por ello que surgen una serie de temas afines tales como: herramientas automatizadas (CASE), prototipos, diagramas de entidad-relación etc. Pero las preguntas que todos nos hacemos: ¿qué nos espera en un futuro no muy lejano del análisis estructurado con la introducción de nuevas variantes? ¿desaparecerá o se mantendrá?.

 

http://exa.unne.edu.ar/depar/areas/informatica/anasistem2/public_html/apuntes/maf/cap2.htm: Este Web Site muestra como La labor del análisis involucra el modelado del sistema que desea el usuario, hay muchos tipos diferentes de modelos que se pueden elaborar, como modelos diferentes puede hacer de una casa nueva un arquitecto. Los modelos de análisis de sistema son representaciones abstractas de lo que al final será una combinación de hardware y software.

 

http://www.vico.org/: Este Site muestra como Un sistema es algo "compuesto", una construcción realizada por manos y herramientas siguiendo las directrices de un propósito. La palabra se aplica casi exclusivamente a abstracciones con el fin de captar la totalidad de una realidad. A través de la notación UML podemos comunicar y compartir el conocimiento de una arquitectura

Regresar