Mostrando entradas con la etiqueta diseño. Mostrar todas las entradas
Mostrando entradas con la etiqueta diseño. Mostrar todas las entradas

martes, 5 de febrero de 2013

Diccionario de datos y sus relaciones en el análisis y diseño de sistemas.


El diccionario de datos.

El diccionario de datos es una aplicación especializada de los tipos de diccionarios usados como referencia en la vida cotidiana. El diccionario de datos es una obra de consulta con información acerca de los datos (es decir, metadatos), compilada por los analistas de sistemas para guiarse en el análisis y diseño. Como un documento, el diccionario de datos recopila y coordina términos de datos específicos, y confirma lo que cada término significa para las diferentes personas en la organización. Los diagramas de flujo de datos tratados en el capítulo 7 son un excelente punto de partida para recopilar entradas para el diccionario de datos.
Una razón importante para mantener un diccionario de datos es guardar datos ordenados.
Esto significa que los datos deben, ser consistentes. Si usted guarda datos acerca del sexo de un hombre como "M" en un registro, "Masculino" en un segundo registro y como el número "1" en un tercer registro, los datos no son consistentes. Un diccionario de datos ayudará en este aspecto.
Los diccionarios de datos automatizados (parte de las herramientas CASE mencionadas anteriormente) son valiosos por su capacidad de hacer referencias cruzadas de los elementos de datos y el lugar donde se utilizan, permitiendo por tanto realizar cambios a todos los programas que comparten un elemento común, si esto fuera necesario. Esta característica suplanta el hacer cambios al azar, y evita el tener que esperar hasta que un programa deje de funcionar porque un cambio no se ha implementado en todos los programas que comparten el elemento que se ha actualizado. Evidentemente, los diccionarios de datos automatizados se vuelven importantes para los sistemas grandes que producen miles de elementos de datos que requieren catalogación y referencias cruzadas.

Relación en el análisis y diseño de sistemas.

La relación fundamental que tiene el diccionario de datos con el análisis y diseños de sistemas, es que cuando se tiene listo el diccionario de datos sirve como guía al analista para el futuro análisis y diseño de un sistema.

jueves, 31 de enero de 2013

Diseño de archivo y bases de datos.

El diseño de archivos y bases de datos incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a emplear para guardar detalles de las transacciones, datos históricos, o información de referencia. Entre las decisiones que se toman durante el diseño de archivos, se encuentran las siguientes:

a) Los datos que deben incluirse en el formato de registros contenidos en el archivo.
b) La longitud de cada registro, con base en las características de los datos que contenga.
c) La secuencia a disposición de los registros dentro del archivo (la estructura de almacenamiento que puede ser secuencial, indexada o relativa).

No todos los sistemas requieren del diseño de todos los archivos, ya que pueden existir archivos de un sistema anterior que pueden ser utilizados para el nuevo sistema y probablemente solo tenga que enlazarse el nuevo sistema al archivo maestro donde se encuentran los registros.

En lo que se refiere a las bases de datos, la mayoría de los sistemas de información ya se han implantado en sistemas de cómputos grandes o pequeños, por lo que utilizan una base de datos que puede abarcar varias aplicaciones, por esta razón estos sistemas utilizan un administrador de base de datos. En este caso el diseñador no construye la base de datos sino que consulta a su administrador para ponerse de acuerdo en el uso de esta base de datos en el sistema.

EL MODELO RELACIONAL.
  • Todos los datos se representan en tablas.
           o    Incluso los resultados de cualquier consulta son otra tabla.
  • Las tablas están compuestas por filas y columnas.
  • Las filas y las columnas, en principio, carecen de orden (p.ej., el orden en el que se muestren las filas y las columnas no importa).
           o    Las filas sólo se ordenan si se le indica a la base de datos que lo haga, mediante el correspondiente comando. De no ser así, el orden será arbitrario, y puede cambiar en caso de tratarse de una base datos dinámica.

           o    El orden de las columnas lo determina cada consulta.
  • Cada tabla tiene una clave primaria, un identificador único, compuesto por una o más columnas.
  • La mayoría de las claves primarias están formadas por una única columna (p.ej., CIUDAD_ID). 
  • Para establecer una relación entre dos tablas es necesario incluir, en forma de columna, en una de ellas la clave primaria de la otra. A esta columna se le llama clave secundaria.
  • Estos dos conceptos --clave primaria y secundaria-- son los más importantes en el diseño de bases de datos. Es importante dedicarles tiempo, para entender bien en qué consisten y cómo funcionan.
  • Cualidades de un buen diseño de base de datos.
  • Reflejar la estructura del problema en el mundo real.
  • Ser capaz de representar todos los datos esperados, incluso con el paso del tiempo.
  • Evitar el almacenamiento de información redundante.
  • Proporcionar un acceso eficaz a los datos.
  • Mantener la integridad de los datos a lo largo del tiempo.
  • Ser claro, coherente y de fácil comprensión.
  • Nota: A veces, estos objetivos pueden ser contradictorios.

INTRODUCCIÓN AL MODELO ENTIDAD/RELACIÓN.
  • El modelo Entidad/Interrelación (E/R): un método de diseño de bases de datos.
  • Muestra de una versión simplificada.
  • Representa los datos mediante una serie de entidades que disponen de atributos.
  • Una entidad es una clase de objetos o conceptos claramente dentificable.
  • Las entidades establecen interrelaciones con otras entidades.
  • El resultado de este proceso es una base de datos normalizada que facilita el acceso a los datos y evita su duplicado. 
Nota: en su mayor parte, el diseño formal de una base de datos se centra en la normalización de la base y en asegurar que el diseño se ajuste a un nivel de normalización (p.ej., first normal form, second normal form,etc.). Este nivel de formalidad va mucho más allá, pero es importante saber que existen tales formalidades.
Nota: en su mayor parte, el diseño formal de una base de datos se centra en la normalización de la base y en asegurar que el diseño se ajuste a un nivel de normalización (p.ej., first normal form, second normal form,etc.). Este nivel de formalidad va mucho más allá, pero es importante saber que existen tales formalidades.

PROCESO DEL DISEÑO EN MODELO ENTIDAD / RELACIÓN.
  • Identificar las entidades que debe presentar la base de datos.
  • Determinar las cardinalidades de las interrelaciones establecidas entre las distintas entidades y clasificar estas interrelaciones entre los siguientes tipos:

             o    Uno a uno (p.ej., una parcela sólo tiene una dirección).
             o    Uno a muchos (p.ej., en una parcela pueden ocurrir varios incendios).
             o    Muchos a muchos (p.ej., la venta de parcelas: una misma parcela la pueden vender varios propietarios y cada propietario puede vender varias parcelas).
  • Dibujar el diagrama Entidad/Interrelación.
  • Determinar los atributos de cada entidad.
  • Definir la clave primaria (única) de cada entidad.

PASO DEL MODELO E/R AL DISEÑO DE LA BASE DE DATOS.
  • Las entidades entre las que hay una interrelación uno a uno se deben fusionar en una sola entidad.
  • Una vez hecho esto, cada una de las entidades que quedan se convierte en una tabla con una clave primaria y una serie de atributos, de los cuales algunos pueden ser claves secundarias. 
  • Las interrelaciones uno a muchos se transforman en atributo y clave secundaria de la tabla que representa a la entidad situada del lado de la interrelación correspondiente a muchos.
  • Las interrelaciones muchos a muchos entre dos entidades pasan a ser una tercera tabla con claves secundarias procedentes de ambas entidades. Estas claves secundarias deberán formar parte de la clave primaria de la tabla en la que se convierte la interrelación, cuando corresponda.
  • Hay una serie de herramientas disponibles en el mercado que pueden automatizar el proceso de conversión de un modelo E/R en un esquema de base de datos.


Diseño de archivo y bases de datos por Kendall y Kendall:

Diseño de entradas, procesos y salidas.


Diseño de entradas: 

(Diseñar el sistema de recopilación de datos)


Las especificaciones de entrada describen la manera en que los datos ingresarán al sistema para su procesamiento.  Las características de diseño de la entrada pueden asegurar la confiabilidad del sistema y producir resultados a partir de datos exactos, o también pueden dar como resultado la producción de información errónea.  Asimismo, el diseño de la entrada determina sí el usuario puede interactuar con el sistema de manera eficiente.  El diseño de la entrada es el enlace que une al sistema de información con el mundo y sus usuarios.  Algunos aspectos del diseño cambian, lo que depende si el sistema está orientado hacia lotes o en línea.  Pero sin considerar el sistema, existen aspectos generales en la entrada que todos los analistas deben tener en cuenta.

El diseño de la entrada consiste en el desarrollo de especificaciones y procedimientos para la preparación de datos, la realización de los pasos necesarios para poner los datos de una transacción en una forma utilizable para su procesamiento, así como la entrada de éstos.  La entrada de estos los datos se logra al instruir la computadora para que los lea ya sea de documentos escritos o impresos, o por personas que los escriben directamente en el sistema.

Controles de la cantidad de entrada. 
Existen varias razones que explican por qué un buen diseño debe controlar la cantidad de datos en la entrada.  Primero, las operaciones de preparación y entrada dependen de las personas.  Dado que los costos de la mano de obra son altos, los asociados con la preparación e ingreso de los datos también lo son altos.  Disminuir los requerimientos de datos puede reducir los costos y ocurrir lo mismo con los costos de mano de obra.  Segundo, la fase de entrada puede ser un proceso lento que toma mucho más tiempo que el que necesitan las computadoras para llevar a cabo sus tareas.  De hecho, la computadora quizá permanezca sin hacer nada durante el tiempo en que se preparan los datos y la entrada para su procesamiento.  Al disminuir los requerimientos de la entrada, el analista puede acelerar todo el proceso desde la captura de datos hasta que los resultados llegan a manos de los usuarios.
  • Evitar Retrasos. Un retraso en el procesamiento, que es un resultado de las operaciones de preparación o de entrada de datos, recibe el nombre de cuello de botella.  Evitar los cuellos de botella debe ser siempre uno de los objetivos que el analista persiga al diseñar la entrada.
  • Evitar errores de datos. En cierto sentido la tasa de errores depende de la cantidad de datos, ya que entre más pequeña sea ésta, menores serán las oportunidades para cometer errores.  Es común encontrar en las operaciones de venta al por menor una tasa promedio del 3% de error en las operaciones de entrada de datos.  Si el volumen de datos es de 10,000 transacciones por semana, entonces se presentarán aproximadamente 300 errores.  A pesar de lo anterior, el analista puede reducir el número de errores al disminuir el volumen de datos que deben ingresarse por cada transacción.  El analista también puede modificar las tasas de error de una operación a través del diseño de la entrada, ya que la forma en que deben ingresar los datos puede tener efectos sobre la incidencia de los errores.  Otro aspecto del control de errores es la necesidad de detectarlos cuando éstos se presentan.  Las verificaciones y balances en los programas para entrada de datos, denominadas técnicas de validación de entradas, también descubren errores en la entrada.
  • Evitar pasos adicionales. Algunas veces el volumen de transacciones y la cantidad de datos en preparación, o en el trabajo de entrada de datos, es algo que no se puede controlar.  Cuando no es posible reducir el volumen de transacciones, el analista debe asegurar que el proceso sea lo más eficiente posible.  El analista experimentado también evitará diseños para la entrada que traigan como consecuencia una mayor cantidad de pasos a seguir.  El efecto que trae consigo ya sea añadir o quitar un paso cuando se alimentan los cheques al proceso bancario, será multiplicado muchas veces en el transcurso de un día de trabajo.
  • Mantener la sencillez del proceso. Quizá el mejor consejo para los analistas es alcanzar todos los objetivos ya mencionados en la forma más sencilla posible.  Claro está que al incluir tantos controles sobre los errores las personas puedan tener dificultades al emplear el sistema.  En otras palabras. el control de los errores puede obstruir la tarea.  El sistema mejor diseñado se ajusta a las personas que lo utilizarán y al mismo tiempo, proporcionarán métodos para el control de los errores.  La simplicidad funciona y es aceptada por los usuarios.  En contraste, cuesta trabajo que los usuarios acepten diseños para la entrada que sean complejos o confusos, y no existe ninguna garantía para el éxito al instalar un sistema complejo.  En consecuencia, es aconsejable evitar la complejidad cuando hay opciones más sencillas.
  • Validación dela entrada. Los diseños de las entradas tienen como finalidad reducir la posibilidad de cometer errores o equivocaciones durante la entrada de datos.  Sin embargo, siempre debe suponer que se presentarán errores. Estos deben detectarse durante la entrada y corregirse antes de guardar los datos o procesarlos.  Es mucho más difícil corregir datos equivocados después de almacenarlos que antes de hacerlo.  De hecho los datos equivocados se olvidan con frecuencia hasta que alguien utilice un reporte basado en esos datos y cuestiona su exactitud y validez.
Los analistas de sistemas deciden los siguientes detalles del diseño de entradas.

1. Qué datos ingresan al sistema.
2. Qué medios utilizar.
3. La forma en que se deben disponer o codificar los datos.
4. El diálogo que servirá de guía a los usuarios para dar entrada a los datos.
5. Validación necesaria de datos y transacciones para detectar errores.
6. Métodos para llevar a cabo la validación de las entradas y los pasos a seguir cuando se presentan errores.

Las decisiones de diseño para el manejo de entradas, especifican la forma en que serán aceptados los datos para su procesamiento por computadora. Los analistas deciden si los datos serán proporcionados directamente, quizá a través de una estación de trabajo, o por el uso de documentos, como talones de venta, cheques bancarios o facturas, donde los datos a su vez son transferidos hacia la computadora para su procesamiento.

Diseño de procedimientos: 
(Diseñar el sistema de procesamiento de datos)

Los procedimientos especifican qué tareas deben efectuarse al utilizar en sistema y quiénes son los responsables de llevarlas a cabo. Entre los procedimientos importantes se encuentran:
  • Procedimientos para entrada de datos. Métodos para la captura de datos de las transacciones y su ingreso en el sistema de información.
  • Procedimientos durante la ejecución. Pasos y acciones emprendidos por los operadores del sistema y, en ciertos casos, por los usuarios finales que interactúan con el sistema para alcanzar los resultados deseados.
  • Procedimientos para el manejo de errores. Acciones a seguir cuando se presentan resultados inesperados.
  • Procedimientos de seguridad y respaldo. Acciones para proteger al sistema y sus recursos contra posibles daños.


Diseño de las salidas:
(Diseño del sistema de informes y producción de documentos)

El término salida, como es probable que el lector lo conozca, se refiere a los resultados e información generados por el sistema. Para muchos usuarios finales, la salida es la única razón para el desarrollo del sistema y la base sobre la que ellos evaluarán la utilidad de la aplicación. En la realidad, muchos usuarios no operan el sistema de información y tampoco ingresas datos en él, pero utilizan la salida generada por el sistema. Cuando diseñan la salida, los analistas deben de realizar lo siguiente:
  • Determinar qué información presentar.
  • Decidir si la información será presentada en forma visual, verbal o impresa y seleccionar el medio de salida.
  • Disponer la presentación de la información en un formato aceptable.
  • Decidir cómo distribuir la salida entre los posibles destinatarios.
Para llevar a cabo las actividades antes mencionadas, se requieren decisiones específicas tales como el empleo de formatos ya impresos cuando se preparan reportes, cuántas líneas planear sobre una página impresa o si se debe emplear gráficas y colores.

 La salida es la única razón para el desarrollo del sistema y la base sobre la que ellos evaluarán la utilidad de la aplicación.  En la realidad, muchos usuarios no operan el sistema de información y tampoco ingresan datos en él, pero utilizan la salida generada por el sistema.

El diseño de la salida de la computadora debe avanzar en una forma organizada y bien pensada: tiene que desarrollarse correctamente mientras que al mismo tiempo se garantice que cada elemento de la salida está diseñado para que las personas encuentren que el sistema es fácil de emplear.

El termino salida se utiliza para denotar cualquier información, ya sea impresa o en una pantalla.  Cuando los analistas diseñan la salida:
  • Identifican la salida específica que es necesaria para satisfacer los requerimientos de la información.
  • Seleccionan los métodos para presentar la información.
  • Crean los documentos, reportes u otros formatos que contienen la información producida por el sistema.
Un sistema de información debe alcanzar uno o más de los siguientes objetivos:

1. Expresar información relacionada con actividades pasadas, estado actual o protecciones para el futuro.
2. Señalar eventos importantes, oportunidades, problemas o advertencias.
3. Iniciar una acción.
4. Confirmar una acción.

El buen diseño de la salida de los sistemas, no puede ser desarrollado en forma independiente del uso que se dará a la salida.  En otras palabras, no se puede clasificar como buena una salida estéticamente atractiva o que haga uso de una nueva tecnología, a menos que satisfaga las necesidades de la organización y de sus usuarios.  El propio proceso de diseño comienza cuando el analista de sistemas identifica la salida que debe producir el sistema (un proceso que se inicia durante la determinación de requerimientos).

Aspectos importantes de las Salidas.
Cuatro preguntas, a las que debe darse respuestas en forma completa y apropiada, ayudan a los expertos de diseño de sistemas a comprender mejor lo que debe ser la salida de un nuevo sistema:

¿Quiénes Recibirán La Salida?
El usuario, ¿forma o no parte de la organización?, Quizá los usuarios externos tengan requerimientos específicos que no se pueden cambiar y que dictan los requerimientos de contenido, formato y medio de presentación.  Tal vez las organizaciones decidan presentar la misma información en forma diferente cuando ésta es enviada a los usuarios tanto externos como internos.

¿Cuántos Detalles Son Necesarios?
Pocos detalles son necesarios para indicarle a alguien que renové una licencia de manejo (nombre, dirección, fecha de renovación, cuota y una identificación de la salida como aviso de renovación).  Sin embargo, un informe trimestral de venta de ventas contiene muchos detalles con formatos diferentes que son de ayuda para trasmitir un mensaje (qué sucedió, cómo ocurrió y cuál fue el resultado) a todos los usuarios.  Asimismo, la cantidad de datos también sugiere si deben emplear métodos de impresión o de presentación en una pantalla.

¿Cuántos Y Que Tan Frecuente Es La Salida?
El calendario junto con la oportunidad de la salida, son guías específicas del diseño.  Algunas salidas se producen con poca frecuencia y sólo cuando aparecen ciertas condiciones: la emisión del aviso de renovación de licencia puede ocurrir cada 4 años, la emisión de una notificación de pago sucede cuando el saldo de la cuenta está vencido. sin embargo, la organización puede requerir cada mes una salida que indique todas las licencias que deben renovarse el próximo mes, o una salida cada semana que señale todas aquellas cuentas cuyo saldo se venció durante la semana. 

¿Qué Método Utilizar?
¿Debe ser impresa o presentada en pantalla?  La salida impresa se emplea con bastante frecuencia.  Sin embargo, si un sistema da respuestas del tipo sí o no a las consultas, a menudo es apropiado presentar la respuesta en una pantalla, algunos sistemas emplean una salida de audio para informarles sobre un nuevo número telefónico o el cambio de éste.



jueves, 29 de noviembre de 2012

Análisis, análisis estructurado y orientado a objeto


El analista de sistemas es imprescindible en cualquier organización, debido al abanico de destrezas que éste posee y los beneficios que le produce. se encarga no sólo estudiar la organización y desarrollar un sistema automatizado, es más que eso, la labor del analista de sistemas es también la de asesorar, supervisar, recomendar y modificar procesos internos y algunas veces de modificar la estructura misma de la empresa, con el propósito de lograr los objetivos que se proponen. 

El analista de sistemas también tiene dentro de sus actividades el análisis y diseño de sistemas el cual 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." (senn, 1992, p.11). Ésta actividad 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. 

Todo análisis y diseño de sistemas liderizado o no por un analista de sistemas posee fases que pueden dividirse de forma lógica en elementos discretos pero, que innegablemente son continuos, de alguna manera cíclica. es aquí donde pueden ser utilizadas diferentes metodologías entre las cuales se pueden mencionar: el análisis y diseño estructurado y el análisis y diseño orientado a objeto. 

la investigación que se presenta a continuación define las dos metodologías mencionadas anteriormente así como también, las diferencias que existen entre ellas. por último se presenta un caso práctico donde se plantea un ejemplo de cómo se puede utilizar la metodología orientada a objeto en un proyecto web que le sirva a la empresa donde laboro. 

Análisis y diseño estructurado. 

Muchos especialistas en sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. el método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de: 1) la división del sistema en componentes y 2) la construcción de un modelo del sistema. el método incorpora elementos tanto de análisis como de diseño. 

Análisis estructurado. 

El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. no se establece cómo se cumplirán los requerimientos o la forma en que se implantará la aplicación. más bien permite que las personas observen los elementos lógicos (lo que hará el sistema) separado de los componentes físicos (computadoras, terminales, sistemas de almacenamiento, etc.). Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado. 

Elementos del análisis estructurado. 

Descripción gráfica: utiliza símbolos o iconos para crear un modelo gráfico del sistema. Sin introducir procesos manuales o informatizados, archivos, entre otros. 

Diagramas de flujo de datos: tienen la misión de mostrar las fuentes y destinos de los datos, identificar y dar nombre a los procesos, dar nombre a los grupos de datos que relacionan una función con otra, señalar los almacenes de datos a los que se tiene acceso. 

Diccionario de datos: se definen flujo de datos, procesos y almacenes de datos. 

Diseño estructurado. 

El diseño estructurado, otro elemento del análisis estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software. la meta del diseño estructurado es crear programas formados por módulos independientes unos de otros desde el punto de vista funcional. este enfoque no sólo conduce hacia mejores programas sino que facilita el mantenimiento de los mismos cuando surja la necesidad de hacerlo. 

El diseño estructurado es una técnica específica para el diseño de programas y no un método de diseño de compresión. es decir, no indica nada relacionado con el diseño de archivos o bases de datos, la presentación de entradas o salidas, la secuencia de procesamiento o el hardware que dará soporte a la aplicación. Esta técnica conduce a la especificación de módulos de programa que son funcionalmente independientes. 

La herramienta fundamental del diseño estructurado es el diagrama de flujo de datos, los diagramas estructurados son 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. Estas especificaciones funcionales para los módulos se proporcionan a los programadores antes que dé comienzo la fase de escritura de código. 

Empleo del análisis y diseño estructurado con otros métodos. 

Se combina, con bastante frecuencia, con el método de ciclo de vida clásico de desarrollo de sistemas. Por ejemplo los analistas pueden optar por desarrollar diagramas de flujo de datos como una forma para documentar las relaciones entre componentes durante la investigación detallada de algún sistema existente. Así mismo, se pueden definir los archivos y datos en un diccionario centralizado de datos de acuerdo con las reglas del análisis estructurado. 

Análisis y diseño orientado a objetos. 

Las técnicas orientadas a objetos permiten que el software se construya a partir de objetos de comportamiento específico. los propios objetos se pueden construir a partir de otros, que a su vez pueden estar formados por otros objetos. 

El análisis de sistemas en el mundo orientado a objetos se realiza al estudiar los objetos en un ambiente, así como los eventos que interactúan con dichos objetos. El diseño del software se realiza al volver a utilizar clases de objetos ya existentes y, en caso necesario, al construir nuevas clases. al modelar una empresa, los analistas deben identificar sus tipos de objetos y las operaciones que hagan que los objetos se comporten en determinada forma. 

Las técnicas orientadas a objetos se pueden utilizar como medios para el diseño sencillo de sistemas complejos. El sistema se puede ver como una colección de objetos, donde cada uno de ellos puede llegar a tener varias posibilidades. Las operaciones que modifican el estado son relativamente sencillas. los objetos se construyen a partir de otros objetos. Los sistemas se construyen a partir de otros componentes probados con un formato definido para las solicitudes de las operaciones del componente. El analista orientado a objetos ve el mundo como objetos (con estructuras de datos y métodos) y eventos que activan operaciones, las cuales modifican el estado de los objetos. Las operaciones aparecen como objetos que hacen solicitudes a otros objetos. El analista crea diagramas de la estructura de los objetos y de los eventos que los modifican. El modelo del diseñador es similar al modelo del analista, pero se toma con el detalle suficiente como para crear el código. el análisis y diseño orientado a objetos intenta lograr la reutilización masiva de las clases de objetos. Modela el mundo en términos de objetos que tienen propiedades y comportamientos, y eventos que activan operaciones que modifican el estado de los objetos. los objetos interactúan de manera formal con otros objetos. 

Programación orientada a objeto. 

La programación orientada a objetos no es un concepto nuevo, sus inicios y técnicas de programación se iniciaron a principios de los 70. se puede definir programación orientada a objetos (oops) como una técnica de programación que utiliza objetos como bloque esencial de construcción. la oops, es un tipo de programación más cercana al razonamiento humano. La oops surge como una solución a la programación de grandes programas, y para solventar el mantenimiento de dichas aplicaciones, ya que en la programación estructura el más mínimo cambio supone la modificación de muchas funciones relacionadas, en cambio con la oops solo es cuestión de añadir o modificar métodos de una clase o mejor, crear una nueva clase a partir de otra (herencia). 

Objeto: 

Los objetos son las cosas físicas y conceptuales que encontramos en el universo alrededor de nosotros. Hardware, software, documentos, seres humanos, los conceptos son todos los ejemplos de los objetos.

Clases: 

Las clases son como plantillas o modelos que describen como se construyen ciertos tipos de objeto. Cada vez que se construye un objeto de una clase, se crea una instancia de esa clase ("instance"). Una clase es una colección de objetos similares y un objeto es una instancia de una clase. Se puede definir una clase como un modelo que se utiliza para describir uno o más objetos del mismo tipo. 

Herencia: 

Una característica muy importante de los objetos y las clases es la herencia, una propiedad que permite construir nuevos objetos (clases) a partir de unos ya existentes. Esto permite crear "sub-clases" denominadas clases derivadas que comparten las propiedades de la clase de la cual derivan (clase base). las clases derivadas heredan código y datos de la clase base, asimismo incorporan su propio código y datos especiales. se puede decir que la herencia permite definir nuevas clases a partir de las clases ya existentes. 

Polimorfismo: 

En un sentido literal, polimorfismo significa la cualidad de tener más de una forma. En el contexto de poo, el polimorfismo se refiere al hecho de que una simple operación puede tener diferente comportamiento en diferentes objetos. En otras palabras, diferentes objetos reaccionan al mismo mensaje de modo diferente. Los primeros lenguajes de poo fueron interpretados, de forma que el polimorfismo se contemplaba en tiempo de ejecución. Por ejemplo, en c++, al ser un lenguaje compilado, el polimorfismo se admite tanto en tiempo de ejecución como en tiempo de compilación. 

Diferencias análisis y diseño estructurado y orientado a objeto. 

- la metodología de análisis y diseño estructurado, examinan los sistemas desde el punto de vista de las funciones o tareas que deben realizar, tareas que se van descomponiendo sucesivamente en otras tareas más pequeñas y que forman los bloques o módulos de las aplicaciones. En la orientación a objeto, por su parte, cobra mucho más importancia el aspecto de "modelado" del sistema, examinando el dominio del problema como un conjunto de objetos que interactúan entre sí. 

- en la metodología de análisis y diseño estructurado se produce una división entre los dos elementos de un sistema: funciones que llevan a cabo los programas y datos que se almacenan en archivos o bases de datos. y por otro lado, la orientación al objeto da un enfoque unificado de ambos aspectos, que se unen en los objetos. 

- en la metodología de análisis y diseño estructurado las herramientas que utilizan para el análisis son: diagramas de flujos de datos, diccionarios de datos, diagramas entidad-relación, diagramas de transición de estado, especificaciones de procesos. en las metodologías orientadas a objetos se emplean distintos modelos que depende de la metodología, entre los principales están modelo de objetos, modelo de estado u objeto-estado, entre otros. 

Además, podemos agregar otras diferencias secundarias tales como: 

- se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo orientado al objeto. 

- aparece una nueva forma de concebir los lenguajes de programación y su uso al incorporarse bibliotecas de clases y otros componentes reutilizables. 

- hay un alto grado de interacción y solapamiento, lo que lleva a una forma de trabajo muy dinámica.
 

Reloj