METODOLOGIAS DEL DESARROLLO DE SISTEMAS DE INFORMACION Son mtodos que indican cmo hacer ms eficiente el desarrollo de sistemas de informacin.

Para ello suelen estructurar en fases la vida de dichos sistemas con el fin de facilitar su planificacin, desarrollo y mantenimiento. Las metodologas de desarrollo de sistemas deben definir ob!etivos, fases, tareas, productos y responsables, necesarios para la correcta reali"acin del proceso y su seguimiento. Los principales ob!etivos de una metodologa de desarrollo son

#segurar la uniformidad y calidad tanto del desarrollo como del sistema en s. Satisfacer las necesidades de los usuarios del sistema. $onseguir un mayor nivel de rendimiento y eficiencia del personal asignado al desarrollo. #!ustarse a los pla"os y costes previstos en la planificacin. %enerar de forma adecuada la documentacin asociada a los sistemas. &acilitar el mantenimiento posterior de los sistemas.

Unidad II

Pgina 1

METODO DE CASCADA 'n un modelo en cascada, un proyecto progresa a travs de una secuencia ordenada de pasos partiendo de la especificacin de requerimientos hasta el mantenimiento del mismo. 'l mtodo reali"a una revisin al final de cada etapa para determinar si est preparado para pasar a la siguiente etapa, por e!emplo, desde el anlisis de requerimientos hasta el dise(o. $uando la revisin determina que el proyecto no est listo pasar a la siguiente, permanece en la etapa actual hasta que est preparado. 'l modelo en cascada est dirigido por documentos. #yuda a locali"ar errores en las primeras etapas del proyecto a un ba!o costo. #yuda a minimi"ar los gastos de la planificacin porque permite reali"arla sin planificacin porque permite reali"arla sin problemas. &unciona especialmente bien si se dispone de personal poco cualificado o dispone de personal poco cualificado o ine)perto, porque presenta el proyecto ine)perto, porque presenta el proyecto con una estructura que ayuda a minimi"ar con una estructura el esfuer"o in*til. 'n resumen, los inconvenientes del venerado modelo en cascada hacen que sea, a menudo, un modelo poco apropiado para un proyecto de desarrollo rpido. +ncluso en los casos en los que las venta!as del modelo en cascada pura superan los inconvenientes, los modelos de cascada modificada ,con retroceso- pueden funcionar me!or. Las desventa!as del modelo se centran en las dificultades para especificar claramente los requerimientos al comien"o del proyecto, antes de que se realice ning*n traba!o de dise(o y antes de escribir ning*n cdigo. .o proporciona resultados tangibles en forma de soft/are hasta el final del ciclo de forma de soft/are del ciclo de vida de #lgunas herramientas, mtodos y actividades que abarcan varias etapas de la cascada0 estas actividades son difciles de a!ustar en las etapas discontinuas del modelo para un proyecto de desarrollo rpido, el modelo en cascada puede suponer una cantidad e)cesiva de documentacin.

Unidad II

Pgina 2

METODO ESPIRAL 's un modelo de ciclo de vida orientado a riesgos que divide un proyecto soft/are en mini1 proyectos. $ada mini proyecto se centra en uno o ms riesgos importantes hasta que todos estn controlados. 2espus de controlar todos los riesgos ms importantes, el modelo en espiral finali"a del mismo modo que el ciclo de vida en cascada. 3todo 2esarrollo en 'spiral &uncionamiento Se parte de una escala peque(a en medio de la espiral, se locali"an los riesgos, se genera un plan para mane!ar los riesgos, y a continuacin se establece una apro)imacin a la siguiente interaccin. $ada iteracin supone que el proyecto pasa a una escala superior. Se avan"a un nivel en el 'spiral, se comprueba que se tiene lo que se desea, y despus se comien"a a traba!ar en el siguiente nivel $on cada iteracin a travs del espiral se construye sucesivas versiones de soft/are cada ve" ms completas. 'n cada bucle alrededor del espiral, la culminacin del anlisis de riesgo resulta una decisin de 4seguir5 o 4no seguir5. $ada interaccin en el mtodo espiral lleva consigo los seis pasos que a continuacin se nombran 2eterminar ob!etivos, alternativas y lmites, +dentificar y resolver riesgos, 'valuar alternativas, %enerar las entregas de esa iteracin, y comprobar que son correctas. 'n el modelo en espiral, las primeras iteraciones son las menos costosas. Supone menos gasto desarrollar el concepto de operacin que reali"ar el desarrollo de los requerimientos, y tambin es menos costoso desarrollar los requerimientos que llevar a cabo el desarrollo del dise(o, la implementacin del producto y la prueba del mismo. 'n cada $uadrante del 3todo espiral se reali"a las siguientes actividades Planificacin 2eterminacin de ob!etivos, alternativas, restricciones, y elaboracin del plan de desarrollo para el ciclo actual. #nlisis de 6iesgos 'valuacin de las alternativas, identificacin y resolucin de riesgos. Se decide si se sigue o no con el proyecto +ngeniera Pgina 3

Unidad II

2esarrollo del producto siguiendo un modelo del ciclo de vida o cascada, prototipo, etc. 'valuacin por el cliente, 7aloracin de resultados. METODO PROTOTIPO 'ste mtodo hace que el usuario participe de manera ms directa en la e)periencia de anlisis y dise(o que cualquiera de los ya presentados. La construccin de prototipos es muy efica" ba!o las circunstancias correctas. Sin embargo, al igual que los otros mtodos, el mtodo es *til slo si se emplea en el momento adecuado y en la forma apropiada. 89u es un prototipo: 'l prototipo es un sistema que funciona, no solo una idea en el papel, desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. #l igual que cualquier sistema basado en computadora, est constituido por soft/are que acepta entradas, reali"a clculos, produce informacin ya sea impresa o presentada en una pantalla, o que lleva a cabo otras actividades significativas. 's la primera versin, o iteracin, de un sistema de informacin. Lo usuarios eval*an el dise(o y la informacin generada por el sistema. Lo anterior slo puede hacerse con efectividad si los datos utili"ados, al igual que las situaciones, son reales. Por otra parte, deben esperarse cambios a medida que el sistema es utili"ado. 6a"ones para desarrollar prototipos de sistemas Los requerimientos de informacin no siempre estn bien definidos. 's probable que los usuarios cono"can slo ciertas reas de la empresa donde se necesiten me!oras o cambios en los procedimientos actuales. ;ambin es posible que recono"can la necesidad de tener me!or informacin para administrar ciertas actividades pero que no estn seguros cual de esta informacin ser la adecuada. Los requerimientos del usuario pueden ser demasiado vagos aun al formular el dise(o. 'n otros casos, es probable que una investigacin de sistemas bien llevada necesite del desarrollo de nueva tecnologa. Los prototipos permiten evaluar situaciones e)traordinarias donde los encargados de dise(ar e implantar sistemas no tienen informacin ni e)periencia, o tambin donde e)isten situaciones de riesgo y costo elevados, y aquellas donde el dise(o propuesto es novedoso y a*n no se demuestra es la factibilidad de que los vendedores enven ordenes de pedido al sistema de cmputo de la compa(a desde el sitio donde efect*an la operacin por medio de terminales porttiles enla"adas a telfonos p*blicos. Para probar el concepto los administradores y encargados de sistemas pueden optar por construir una versin en peque(a escala del soft/are, adquirir unas cuantas terminales y seleccionar un grupo de vendedores. 'l prototipo proporcionar informacin preliminar sobre la funcionalidad del concepto. 'l prototipo es, en realidad, un modelo piloto o de prueba, en general, los analistas de sistemas encuentran que los prototipos tienen mayor utilidad ba!o las siguientes condiciones

Los encargados de dise(ar e implantar sistemas nunca han desarrollado uno con las caractersticas del sistema propuesto. Se conoce slo una parte de las caractersticas esenciales del sistema0 las dems no son identificables a pesar de un cuidadoso anlisis de requerimientos. Pgina 4

Unidad II

La e)periencia con el uso del sistema a(adir una lista significativa de requerimientos que el sistema debe satisfacer. Las diferentes versiones del sistema evolucionan con la e)periencia al igual que el desarrollo adicional y el refinamiento de sus caractersticas. Los usuarios del sistema participan en el proceso de desarrollo.

Los pasos a seguir en el proceso de desarrollo de prototipos son los siguientes +dentificar los requerimientos de informacin que el usuario conoce !unto con las caractersticas necesarias del sistema. 2esarrollar un prototipo que funcione. <tili"ar el prototipo anotando las necesidades de cambios y me!oras. 'sto e)pande la lista de los requerimientos de sistemas conocidos. 6evisar el prototipo con base en la informacin obtenida a travs de la e)periencia del usuario. 6epetir los pasos anteriores las veces que sea necesario hasta obtener un sistema satisfactorio.

METODOLOGIAS APLICABLES AL DESARROLLO DE SISTEMAS INFORMACIN ADMINISTRATIVOS 1.- CICLO DE VIDA TRADICIONAL EN EL DESARROLLO DE SISTEMAS $orresponde a una metodologa que es utili"a hace muchos a(os, es considerada como la base para la creacin de nuevos mtodos en el desarrollo de sistemas. 'sta es una temtica secuencial, donde se va pasando por distintas etapas hasta llegar a la operacin definitiva del sistema. 'sta metodologa es poco fle)ible debido a que se debe terminar una etapa por completo antes de pasar a la otra. Percepcin de l nece!id d de "n SIA 2entro de una organi"acin a menudo se plantea interrogantes acerca de la conveniencia de desarrollar un S+#, ya sea para me!orar un S+# e)istente, o para apoyar mecani"adamente un grupo de actividades manuales, o para elevar la eficiencia y=o efectividad de un sistema administrativo, o para satisfacer alguna otra ra"n similar.

Unidad II

Pgina 5

'stas interrogantes se generar constantemente en cada una de las funciones de la organi"acin y responden a la inquietud ya sean por me!orar los esquemas de administracin y operacin, o por solucionar problemas coyunturales de manipulacin de informacin.

'l propsito de esta etapa es la transformacin de estas ideas preliminares e interrogantes en una identificacin y delimitacin precisa del rea problema involucrado0 de este modo la organi"acin puede detectar si e)iste realmente la necesidad de estudiar el desarrollo de un nuevo S+#, o la modificacin de uno e)istente, y evaluar la conveniencia de proseguir el estudio en ms detalle. 'n esta etapa se debe hacer un estudio y anlisis del actual sistema, con el ob!etivo de ver cmo funciona este o para ver donde se puede me!orar o implementar una nueva funcin. 'ste punto es desarrollado por un grupo de personas en los cuales participan usuarios directos, indirectos, especialistas en informtica, etc. La labor del grupo es la recopilacin y anlisis de informacin, para formular respuestas sobre el tema. 'l resultado final se dirige a los mandos superiores, los cuales decidirn la continuidad del estudio. La documentacin final de esta etapa deber contener los siguientes puntos 2efinicin del problema original, de acuerdo a la versin dada por sus iniciadores. #ntecedentes aportados por los usuarios para validar la e)istencia del problema. 2efinicin del mbito que cubri el estudio. 2escripcin de la situacin actual y estructura administrativa que lo soporta Planteamiento del problema. >ustificacin de por qu el problema no es ,o no ha sido- resuelto por los otros sistemas e)istentes. #lternativas de solucin, con la correspondiente descripcin ,para cada una de ellas- de las venta!as, desventa!as, costos, beneficios estimados e impacto organi"acional. 6ecomendaciones sobre el curso de accin a seguir ,termino del estudio, o iniciar la etapa de 'studio de &actibilidad-.

E!#"di$ de F c#i%ilid d. 'l propsito de esta etapa es evaluar el riesgo e impacto que la solucin propuesta para el proyecto, tiene sobre los planes y esquemas de administracin de la organi"acin0 al mismo tiempo debe preparase una programacin de actividades y un presupuesto para llevar a cabo las otras etapas del proyecto. 2esde el punto de vista de los resultados que los administradores esperan obtener de esta etapa, se distinguen cuatro tipos de factibilidades la econmica ,8es conveniente, en cuanto a los costos y beneficios que genere, llevar a cabo el proyecto:-, la tcnica ,8disponemos de los recursos y de las herramientas tcnicas y metodolgicas necesarias para desarrollar el proyecto:-, la operacional ,8dispondremos de los recursos y de la decisin necesaria para operar y construir el S+# solucin:- y la legal ,el proyecto se enmarca dentro de las normas y reglas internas como e)ternas-. 2e estos cuatro tipos, la factibilidad econmica es, qui"s, la ms comple!a pero al mismo tiempo la Unidad II Pgina 6

que ms se a!usta para emplear tcnicas rigurosas0 la factibilidad tcnica es un problema de solucin directa y para la cual los e)pertos, generalmente, disponen de los antecedentes tecnolgicos correspondientes, en cambio la factibilidad operacional es, a menudo, una cuestin de relaciones humanas y de poltica empresarial. 's conveniente se(alar que para un buen desarrollo ordenado de un S+#, se debe calendari"ar cada una de las etapas que involucra la puesta en marcha de un S+#. Para esto se debe utili"ar las diferentes herramientas que permiten esto, una de ellas se denomina carta %antt. <na carta %antt es un sistema de cronograma del proyecto o actividad a reali"ar. Si descomponemos la palabra 4$ronograma5 tenemos $rono es igual o significa tiempo y %rama es igual a dibu!o, por lo tanto, se entiende como carta %antt un dibu!o de las actividades a travs del tiempo. Las cartas %antt proporcionan detalladamente el tiempo de duracin de las actividades que se van a desarrollar dentro de la formulacin del proyecto, a su ve" permite reordenar la matri" lgica en caso de posibles inconsistencias. Las cartas %antt se desarrollan tomando en cuanta dos variables, en primera instancia tenemos las actividades a reali"ar dentro de la formulacin de alg*n proyecto, en segundo lugar tenemos la variable tiempo, la cual puede ser e)presada en horas, das, semanas, semestres, a(os, etc. Para poder desarrollar una carta %antt, es necesario definir las actividades involucradas en el proyecto las cuales pueden ser de mucha variabilidad, dependiendo de las actividades que se desarrolle. '!emplo 2esarrollo e implementacin de un S+# en una organi"acin.

'tapas o #ctividades

;iempo en 3eses

a) bcdef) g)

Percepcin de la necesidad 'studio de factibilidad 2ise(o lgico 2ise(o &sico $onstruccin Prueba e implementacin Puesta en marcha ,operacin y mantencin-

? @ A A A @ @

<na ve" definidas las actividades y la fi!acin de tiempo por cada etapa, se procede al dise(o.

Unidad II

Pgina 7

CARTA GANTT $

E# p ! Perp. .ecesidad 'st. &actibilidad 2ise(o Lgico 2ise(o &sico $onstruccin Prueba +mplem. Puesta 3archa

Me!e! E

?H

??

?@

?B

?A

#l desarrollar una carta %antt en la formulacin de proyectos nos permite definir, ordenar y controlar de me!or forma cada paso productivo del proyecto. 1. Di!e&$ L'ic$ de "n SIA (ANALISIS). 'l propsito de esta etapa es identificar, caracteri"ar y especificar el con!unto de decisiones y=o actividades organi"acionales apoyadas por el S+#, y los correspondientes requerimientos de informacin. 'n otras palabras definiremos el papel que !ugar el S+# dentro de los esquemas de administracin de la organi"acin, al mismo tiempo se especificaran los procedimientos administrativos que permitirn la manipulacin y uso de la informacin. Las entradas para esta etapa provienen de dos direcciones, la primera emana de las pautas entregadas por el comit de informtica, indicando los resultados del estudio de factibilidad, en la cual se establecen los ob!etivos, mbitos, restricciones y recursos asignados al proyecto. La segunda corresponde aquella informacin y documentacin que se tenga sobre los actuales procedimientos administrativos de la empresa.

Unidad II

Pgina 8

<n punto importante es aquel que se(ala que el proceso de dise(o lgico y de dise(o fsico no son necesariamente secuenciales0 esto indica que no se debe terminar completamente el primero para comen"ar con el segundo. ')iste mucha iteracin entre ambos procesos.

Sistema de #dministracin
Proceso de Manipulacin

Proceso de toma de Decisiones

2atos

+nformacin

2ecisin

Sistema de +nformacin #dministrativo Relacin sistema de administracin vs sistema de informacin administrativo Sistema de administracin $on!unto interrelacionado de elementos ,mtodos, procedimientos, decisiones, etc.-, mediante los cuales una organi"acin planifica, e!ecuta, controla y decide las actividades por las cuales permita alcan"ar sus metas y ob!etivos. Sistema de informacin administrativo $on!unto interrelacionado de elementos ,mtodos, procedimientos de manipulacin de informacin y de uso de informacin, etc.-, mediante los cuales apoya ,con informacin- al proceso de toma de decisiones.

2. Di!e&$ F(!ic$ de "n SIA (DISEO). 'n esta etapa se buscara generar la alternativa solucin al problema de cmo mane!ar y procesar computari"adamente la informacin. Ibtenidas las especificaciones de lo que ser el sistema, es necesario determinar las responsabilidades que sern dadas a la parte computacional del sistema y cuales procedimientos y procesos sern reali"ados manualmente. 'l propsito fundamental del proceso de dise(o fsico consiste en decidir y especificar las caractersticas de los elementos que intervendrn en el procesamiento computari"ado de los datos, de modo que stos Unidad II $umplan con los requerimientos definidos en el dise(o lgico0 estos se refieren a asegurar la efectividad del sistema computacional. Pgina 9

Se a!usten a las normas y restricciones que impone la organi"acin. 'sto conduce a la factibilidad del dise(o y a su compatibilidad con el medio en que estar inserto.

'n primer trmino se debe definir los modos de procesos a usar ,batch, on1line, real1time, time1sharing, etc.-, los elementos de hard/are que sern necesarios emplear, los paquetes y programas que sern de apoyo al sistema, la forma en que se agrupar la informacin que se genere en el proceso ,archivos, bases de datos, etc.-, los medios en los cuales se almacenarn dichos archivos y programas, las forma en que estar almacenada la informacin. 2e esta definicin se desprende que el dise(o fsico es un proceso de toma de decisiones ,normalmente comple!o- que cuenta con un con!unto de antecedentes de entrada, y que debe producir un con!unto de especificaciones de salida. 'l proceso mismo est enmarcado por la funcin ob!etivo que se persiga. En#r d ! ,#ntecedentesde los a- 3arco %eneral 1 Plan de +nformtica 1 3todos y normas b- 2isponibilidades y 6estricciones 1 Jard/are 1 Soft/are 1 6ecursos c- 6equerimientos definidos en 'l dise(o lgico d- Itras entradas 1 #plicaciones similares 1 $aractersticas de #ctual mercado S lid ! ,'specificacin 'lementos que componen el dise(o elegidoa- Jard/are a utili"ar b- Soft/are a utili"ar c- 3odelo de datos d- Irgani"acin fsica de los 2atos e- ;ipo de procesamiento f- 3odo de operacin

Proceso de Diseo Fsico

). C$n!#r"ccin *DESARROLLO+ 'l ob!etivo de esta etapa, es la de producir los distintos programas de aplicacin que han sido especificados durante la etapa de dise(o fsico del S+#. 'stos resultados deberan alcan"arce dentro de las restricciones y pla"os establecidos por el desarrollo del proyecto. 'n caso de que la organi"acin decida, por ra"ones de costo y=o carencia de los recursos humanos necesarios, no llevar a cabo la construccin del total o parte del apoyo del soft/are para el sistema, esta fase debe establecer el balance entre las caractersticas de las necesidades de la Unidad II Pgina 10

organi"acin, con las caractersticas de los paquetes ofrecidos en el mercado. ')isten dos problemas que es necesario atacar, el primero apunta a la eficiencia del soft/are para resolver las necesidades de la organi"acin y el segundo al respaldo ofrecido por los fabricantes de los programas.

Para el primer problema debemos preocuparnos de ?. @. B. A. 7er si el paquete realmente funciona como dicen los fabricantes. 7er si los programas traba!an con los datos nuestros, resolviendo problemas tipos. 7er si el sistema es compatible con nuestros hard/are y soft/are de la empresa. $omparar tiempos de respuestas y accesos a la informacin. Para el segundo problema debemos preocuparnos de ?. @. B. A. C. Solvencia tcnica de los fabricantes Itras e)periencias que se hayan tenido con el uso de los programas ofrecidos 3antencin ofrecida Precio de los programas Posibilidad de modificacin de los programas, con el ob!etivo de que se adapten en me!or forma a las caractersticas de nuestra organi"acin D. 2ocumentacin ofrecida E. 'ntrenamiento ofrecido a los usuarios F. 6estricciones que presenta el sistema. ,. Pr"e% - P"e!# en M rc. 2urante la prueba, el sistema se utili"a en forma e)perimental para asegurar que el soft/are no falle0 es decir, 9ue corra de acuerdo a sus especificaciones y a la manera que los usuarios esperan que lo haga. Se e)aminan datos especiales de prueba en la entrada del procesamiento y los resultados para locali"ar algunos problemas inesperados. Puede permitirse tambin a un grupo limitado de usuarios que utilice el sistema, de manera que los analistas puedan captar si tratan de utili"arlo en forma no planeadas. 's preferible detectar cualquier anomala antes de que la empresa ponga en marcha el sistema y dependa de l. 'n muchas compa(as la prueba se lleva a cabo por personas diferentes a aquellos que los escriben en forma original0 es decir si se utili"an personas que no conocen como se dise(aron ciertas partes de los programas, se asegura una mayor y ms completa prueba, adems de ser imparcial, lo que da a un soft/are ms confiable. $uando el personal de sistemas verifica y pone en uso el nuevo equipo, entrena al personal usuario0 instala la nueva aplicacin y constituye los archivos de datos que se necesiten, entonces el sistema est puesto en marcha. 2e acuerdo con el tama(o de la empresa que emplear la aplicacin y el riesgo asociado con su uso, los desarrolladores del sistema pueden escoger una prueba piloto para la operacin del sistema solamente en un rea de la compa(a0 por e!emplo, en un departamento o slo con una o dos personas. # veces corrern en forma paralela tanto el sistema anterior como el nuevo para comparar Unidad II Pgina 11

los resultados de ambos0 en otras situaciones, los desarrolladores pararn por completo el sistema anterior un da y al siguiente empe"arn a utili"ar el nuevo. $omo se puede apreciar, cada estrategia para la puesta en marcha tiene sus mritos, que dependen de la situacin del negocio considerado. Sin importar la estrategia para la puesta en marcha que se haya utili"ado, los desarrolladores tendrn que asegurarse que el uso inicial del sistema est libre de problemas. <na ve" instalada, con frecuencia la aplicacin se utili"a por muchos a(os0 sin embargo, tanto la empresa como los usuarios cambiarn, y el medio ambiente ser diferente tambin a travs del tiempo. Por lo tanto, la aplicacin indudable mente necesitar mantenimiento0 es decir, se harn cambios y modificaciones al soft/are, y a los archivos o procedimientos para cubrir los requerimientos nuevos de los usuarios. Los sistemas de la empresa y el medio ambiente de los negocios estn en continuo cambio. Los sistemas de informacin deben mantenerse de la misma forma0 es este sentido, la propuesta en marcha es un proceso continuo. Oper cin del Si!#e/ Se supone que a estas alturas el sistema ya est en funcionamiento, de acuerdo a lo que fue dise(ado. La operacin rutinaria del sistema se mantiene en la medida que no surgan problemas mayores en el sistema que obligue a cambios subtanciales o que, debido a cambios en la organi"acin misma, el sistema deba ser modificado para satisfacer las nuevas necesidades. M n#encin del Si!#e/ 'sta etapa satisface las nuevas necesidades producidas durante la e!ecucin del S+#. Permitiendo la innovacin o me!ora de mdulos o procedimientos de este para continuar con la entrega de informacin. ;anto esta etapa como la anterior se desarrollan en paralelo durante toda la vida *til del S+#.

Unidad II

Pgina 12

C$ncep#$! B0!ic$! de Orien# cin

O%1e#$

O%1e#$!

<n ob!eto podra ser real o abstracto, por e!emplo una organi"acin, una factura, una figura en un dibu!ador, una pantalla de usuario, un avin, un vuelo de avin, etc. 'n el anlisis y dise(o orientados a ob!etos ,II-, interesa el comportamiento del ob!eto. Si se construye soft/are, los mdulos de soft/are II se basan en los tipos de ob!etos. 'l soft/are que implanta el ob!eto contiene estructuras de datos y operaciones que e)presan dicho comportamiento. Las operaciones se codifican como mtodos. Las representacin en soft/are II del ob!eto es entonces una coleccin de tipos de datos y ob!etos. 'ntonces, dentro del soft/are orientado a ob!eto, un ob!eto es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los mtodos que controlan dichos datos. <n ob!eto puede estar compuesto por otros ob!etos. 'stos *ltimos a su ve" tambin pueden estar compuestos por otros ob!etos. 'sta intrincada estructura es la que permite construir ob!etos muy comple!os. Tip$ de O%1e#$ Los conceptos que poseemos se aplican a tipos determinados de ob!etos. Por e!emplo, empleado se aplica a los ob!etos que son personas empleadas por alguna organi"acin. #lgunas instancias de empleado podran ser >uan Pre", >os 3artne", etc. 'n el anlisis orientado a ob!etos, estos conceptos se llaman tipos de ob!etos0 las instancias se llaman ob!etos. #s, un tipo de ob!eto es una categora de ob!eto, mientras que un ob!eto es una instancia de un tipo de ob!eto. 'n el mundo de las bases de datos e)isten los tipos de entidad, como cliente o empleado. ')isten muchas instancias de cada tipo de entidad ,como >uan Pre" o >os 3artne" para el tipo de entidad empleado-. 2el mismo modo, en II se define tipos de ob!etos e instancias de tipo de ob!eto. Sin embargo, el trmino ob!eto tiene diferencias fundamentales con el trmino entidad, ya que la entidad slo se refiere a los datos, mientras que ob!eto se refiere a los datos y a los mtodos mediante los cuales se controlan a los propios datos. 'n II, la estructura de datos y los mtodos de cada tipo de ob!eto se mane!an !untos. .o se puede tener acceso o control de la estructura de datos e)cepto mediante los mtodos que forman parte del tipo de ob!eto. M2#$d$!

Unidad II

Pgina 13

Los mtodos especifican la forma en que se controlan los datos de un ob!eto. Los mtodos en un tipo de ob!eto slo hacen referencia a la estructura de datos de ese tipo de ob!eto. .o deben tener acceso directo a las estructuras de datos de otros ob!etos. Para utili"ar la estructura de datos de otro ob!eto, deben enviar un mensa!e a ste. 'l tipo de ob!eto empaca !untos los tipos de datos y su comportamiento. <n ob!eto entonces es una cosa cuyas propiedades estn representadas por tipos de datos y su comportamiento por mtodos. <n mtodo asociado con el tipo de ob!eto factura podra ser aquel que calcule el total de la factura. Itro podra transmitir la factura a un cliente. Itro podra verificar de manera peridica si la factura ha sido pagada y, en caso contrario, a(adir cierta tasa de inters. Enc p!"l d$ 'l empaque con!unto de datos y mtodos se llama encapsulado. 'l ob!eto esconde sus datos de los dems ob!etos y permite el acceso a los datos mediante sus propios mtodos. 'sto recibe el nombre de ocultamiento de informacin. 'l encapsulamiento evita la corrupcin de los datos de un ob!eto. Si todos los programas pudieran tener acceso a los datos de cualquier forma que quisieran los usuarios, los datos se podran corromper o utili"ar de mala manera. 'l encapsulado protege los datos del uso arbitrario y no pretendido. 'l encapsulado oculta los detalles de su implantacin interna a los usuarios de un ob!eto. Los usuarios se dan cuenta de las operaciones que puede solicitar del ob!eto, pero desconocen los detalles de cmo se lleva a cabo la operacin. ;odos los detalles especficos de los datos del ob!eto y la codificacin de sus operaciones estn fuera del alcance del usuario. #s, encapsulado es el resultado ,o acto- de ocultar los detalles de implantacin de un ob!eto respecto de su usuario. 'l encapsulado, al separar el comportamiento del ob!eto de su implantacin, permite la modificacin de sta sin que se tengan que modificar las aplicaciones que lo utili"an.

Men! 1e!

Unidad II

Pgina 14

Para que un ob!eto haga algo, le enviamos una solicitud. 'sta hace que se produ"ca una operacin. La operacin e!ecuta el mtodo apropiado y, de manera opcional, produce una respuesta. 'l mensa!e que constituye la solicitud contiene el nombre del ob!eto, el nombre de una operacin y, a veces, un grupo de parmetros. La programacin orientada a ob!etos es una forma de dise(o modular en la que con frecuencia el mundo se piensa en trminos de ob!etos, operaciones, mtodos y mensa!es que se transfieren entre tales ob!etos. <n mensa!e es una solicitud para que se lleve a cabo la operacin indicada y se produ"ca el resultado. Los ob!etos pueden ser muy comple!os, puesto que pueden contener muchos subob!etos, stos a su ve" pueden contener otros, etc. La persona que utilice el ob!eto no tiene que conocer su comple!idad interna, sino la forma de comunicarse con l y la forma en que responde.

Cl !e 'l trmino clase se refiere a la implantacin en soft/are de un tipo de ob!eto. 'l tipo de ob!eto es una nocin de concepto. 'specifica una familia de ob!etos sin estipular la forma en que se implanten. Los tipos de ob!etos se especifican durante el anlisis II. #s, una clase es una implantacin de un tipo de ob!eto. 'specifica una estructura de datos y los mtodos operativos permisibles que se aplican a cada uno de sus ob!etos. 3erenci

Unidad II

Pgina 15

<n tipo de ob!eto de alto nivel puede especiali"arse en tipos de ob!eto de ba!o nivel. <n tipo de ob!eto puede tener subtipos. Por e!emplo, el tipo de ob!eto persona puede tener subtipos estudiante y empleado. # su ve", el tipo de ob!eto estudiante puede tener como subtipo estudiante de pregrado y estudiante de postgrado, mientras que empleado puede tener como subtipo a acadmico y administrativo. ')iste de este modo una !erarqua de tipos, subtipos, subsubtipos, etc. <na clase implanta el tipo de ob!eto. <na subclase hereda propiedades de su clase padre0 una sub1subclase hereda propiedades de las subclases0 etc. <na subclase puede heredar la estructura de datos y los mtodos, o algunos de los mtodos, de su superclase. ;ambin tiene sus mtodos e incluso tipos de datos propios. Asociaciones de Objetos. 's importante modelar la forma como los ob!etos se asocian entre s. #dems es necesario identificar el significado de la asociacin y la cantidad de ob!etos con los que un ob!eto dado puede y debe asociarse ,cardinalidad-.

6epresentacin para la #sociacin entre dos ;ipos de Ib!etos. <n ob!eto del tipo persona posee cero o muchos ob!etos del tipo vehculo. <n ob!eto del tipo vehculo es de un y slo un ob!eto del tipo persona. Jerarquas de Generalizacin. <na de las vas de sentido com*n por las que el hombre organi"a su volumen de conocimiento es el de las !erarquas, de lo ms general a lo ms especfico.

6epresentacin de una >erarqua de generali"acin, para el tipo de ob!eto Persona. 'n las !erarquas se habla de subtipo o especiali"acin de un supertipo o generali"acin. 'n el caso anterior, persona es el supertipo para 'mpleado y 'studiante, que son sus subtipos. Por otra parte, 'mpleado es el supertipo para los subtipos '!ecutivo y 7endedor. Los subtipos ,niveles inferiores de la !erarqua- heredan las caractersticas de sus supertipos, adems, cada instancia de un tipo de ob!eto lo es tambin de sus supertipos. 4er r5"( ! C$/p"e!# !. <n ob!eto se denomina comple!o si est formado por otros. Las !erarquas $ompuestas permiten reali"ar agregaciones de ob!etos. Unidad II Pgina 16

6epresentacin de una >erarqua $ompuesta. <n ob!eto del tipo edificio se compone de a lo menos un ob!eto del tipo piso. # su ve" un ob!eto del tipo piso se compone de a lo menos un ob!eto del tipo pasillo, podra tener varios ,o ninguno- ob!etos del tipo ba(o y oficina. Diagramas de relacin entre los objetos. Los tipos de ob!etos estn relacionados con otros tipos de ob!eto. Por e!emplo, un empleado traba!a en una sucursal, o un cliente reali"a un pedido de varios productos.

2iagrama de 6elacin entre ob!etos. <n ob!eto del tipo cliente puede ordenar muchos ob!etos del tipo pedidos, y un ob!eto del tipo pedido es ordenado por un y slo un ob!eto del tipo cliente. <n ob!eto del tipo producto est en muchos o ning*n ob!eto del tipo pedido, mientras que un ob!eto del tipo pedido tiene al menos un ob!eto del tipo producto. P$lil/$r6i!/$ 'l polimorfismo se refiere a la posibilidad de definir m*ltiples clases con funcionalidad diferente, pero con mtodos o propiedades denominados de forma idntica, que pueden utili"arse de manera intercambiable mediante cdigo cliente en tiempo de e!ecucin.

Unidad II

Pgina 17

Unidad II

Pgina 18