Dsi p1

Diseo Estructurado de Sistemas de Informacin
1.1.3 Diseo de mdulos [2]

El concepto de modularidad se ha ido exponiendo desde hace casi cinco dcadas en el software de computadora. La arquitectura de computadora expresa la modularidad; es decir, el software se divide en componentes nombrados y abordados por separado, llamados frecuentemente mdulos, que se integran para satisfacer los requisitos del problema. Se ha afirmado que La modularidad es el nico atributo del software que permite gestionar un programa intelectualmente. El software monoltico (es decir, un programa grande formado por un nico modulo) no puede ser entendido fcilmente por el lector. La cantidad de rutas de control, la amplitud de referencias, la cantidad de variables y la complejidad global har que el entendimiento este muy cerca de ser imposible. Para ilustrar este punto, tomemos en consideracin el siguiente argumento basado en observaciones humanas sobre la resolucin de problemas. Pensemos que C(x) es una funcin que define la complejidad percibida de un problema x, y que E(x) es una funcin que define el esfuerzo (oportuno) que se requiere para resolver un problema x. para dos problemas p1 y p2, si C(p1) > C(p2) Implica que E(p1) > E(p2) (3.1b) (3.1a)
En general, este resultado es por intuicin obvio. Se tarda ms en resolver un problema difcil. Mediante la experimentacin humana en la resolucin de problemas se ha averiguado otra caracterstica interesante. Esta es,
76 Diseo estructurado
C(p1 + p2) > C(p1) + C(p2)
(3.2)
La ecuacin 3.2 implica que la complejidad percibida de un problema que combina p1 y p2, es mayor que la complejidad percibida cuando se considera cada problema por separado. Teniendo en cuenta la ecuacin (3.2) y la condicin implicada por la ecuacin (3.1) se establece que E(p1 + p2) > E(p1) + E(p2) (3.3)
Esto lleva a una conclusin: divide y vencers es ms fcil resolver un problema complejo cuando se rompe en piezas manejables. El resultado expresado en la ecuacin 3.3 implica que es importante en lo que respecta a la modularidad y al software. Es, de hecho, un argumento para la modularidad. Es posible concluir de la ecuacin (3.3) que si subdividimos el software indefinidamente, el esfuerzo que se requiere para desarrollarlo sera mnimo. Desgraciadamente, intervienen otras fuerzas, que hacen que esta conclusin sea (tristemente) falsa. Como muestra la figura 3.4, el esfuerzo (costo) para desarrollar un mdulo software individual disminuye a medida que aumenta el nmero total de mdulos. Dado el mismo conjunto de requisitos: tener ms mdulos conduce a un tamao menor de mdulo. Sin embargo, a medida que aumenta el nmero de mdulos, tambin crece el esfuerzo (costo) asociado con la integracin de mdulos. Estas caractersticas conducen tambin a la curva total del costo o esfuerzo que se muestra en la figura. Existe un nmero M de mdulos que dara como resultado un costo mnimo de desarrollo, aunque no tenemos la sofisticacin necesaria para predecir M con seguridad.
Costo de Esfuerzo
Regin de costo mnimo
Costo total del software
Costo de Integracin
Costo/ modulo
Nmero de mdulos
Figura 3.4 Esfuerzo Costo en modularidad

Pressman Roger S. Ingeniera del software, Ed. Mc Graw Hill, 5 edicin
Las curvas de la Figura 3.4 proporcionan en efecto una gua til cuando se tiene en consideracin la modularidad. La modularidad deber aplicarse, pero teniendo cuidado de estar prximo a M. Se deber evitar modularizar de ms o de menos. Cuando se tiene en consideracin la modularidad surge otra pregunta importante. Cmo se define un modulo con un tamao adecuado? La respuesta se, encuentra en los mtodos utilizados para definir los mdulos dentro de un sistema. Meyer define cinco criterios que nos permitirn evaluar un mtodo de diseo en relacin con la habilidad de definir un sistema modular efectivo: Capacidad de descomposicin modular. Si un mtodo de diseo proporciona un mecanismo sistemtico para descomponer el problema en subproblemas, reducir la complejidad de todo el problema, consiguiendo de esta manera una solucin modular efectiva.
Capacidad de empleo de componentes modulares . Si un mtodo de diseo permite ensamblar los componentes de diseo (reusables) existentes en un sistema nuevo, producir una solucin modular que no inventa nada ya inventado.
Capacidad de comprensin modular . Si un mdulo se puede comprender como una unidad autnoma (sin referencias a otros mdulos) ser ms fcil de construir y de cambiar.
Continuidad modular. Si pequeos cambios en los requisitos del sistema provocan cambios en los mdulos individuales, en vez de cambios generalizados en el sistema, se minimizar el impacto de los efectos secundarios de los cambios.
Proteccin modular. Si dentro de un mdulo se produce una condicin absurda y sus efectos se limitan a ese mdulo, se minimizar el impacto de los efectos secundarios inducidos por los errores.
Finalmente, es importante destacar que un sistema se puede disear modularmente, incluso aunque su implementacin deba ser monoltica. Existen situaciones (por ejemplo, software en tiempo real, software empotrado) en donde no es admisible que los subprogramas introduzcan sobrecargas de memoria y de velocidad por mnimos que sean (por ejemplo, subrutinas, procedimientos). En tales situaciones el software podr y deber disearse con modularidad como filosofa predominante. El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente del programa puede no tener un aspecto modular a primera vista, se ha mantenido la filosofa y el programa proporcionar los beneficios de un sistema modular.
1.1.3.1 Diseo Modular Efectivo [2]

La modularidad se ha convertido en un enfoque aceptado en todas las disciplinas de ingeniera. Un diseo modular reduce la complejidad, facilita los cambios (un aspecto crtico de la capacidad de mantenimiento del software), y da como
resultado una implementacin ms fcil al fomentar el desarrollo paralelo de las diferentes partes de un sistema. El concepto de independencia funcional es la suma de la modularidad y de los conceptos de abstraccin y ocultacin de informacin. En referencias obligadas sobre el diseo del software, Pamas y Wirth sugieren a las tcnicas de refinamiento que mejoran la independencia de mdulos. Trabajos posteriores de Stevens, Wyers y Constantine consolidaron el concepto. La independencia funcional se consigue desarrollando mdulos con una funcin determinante y una aversin a una interaccin excesiva con otros mdulos. Es necesario disear el software de manera que cada mdulo trate una subfuncin de requisitos y tenga una interfaz sencilla cuando se observa desde otras partes de la estructura del programa. Por qu es importante la independencia? El software con una modularidad efectiva, es decir, mdulos independientes, es ms fcil de desarrollar porque la funcin se puede compartimentar y las interfaces se simplifican (tengamos en consideracin las ramificaciones cuando el desarrollo se hace en equipo). Los mdulos independientes son ms fciles de mantener (y probar) porque se limitan los efectos secundarios originados por modificaciones de diseo/cdigo; porque se reduce la propagacin de errores; y porque es posible utilizar mdulos usables. En resumen, la independencia funcional es la clave para un buen diseo y el diseo es la clave para la calidad del software. La independencia se mide mediante dos criterios cualitativos: la cohesin y el acoplamiento. La cohesin es una medida de la fuerza relativa funcional de un mdulo. El acoplamiento es una medida de la independencia relativa entre los mdulos.
1.1.3.2 Cohesin [2]

La cohesin es una extensin natural del concepto de ocultacin de informacin (la informacin que esta dentro de un modulo debe ser inaccesible a otros mdulos que no necesiten esa informacin). Un mdulo cohesivo lleva a cabo una sola tarea dentro de un procedimiento de software, lo cual requiere poca interaccin con los procedimientos que se llevan a cabo en otras partes de un programa. Dicho de manera sencilla, un mdulo cohesivo deber (idealmente) hacer una sola cosa. La cohesin se puede representar como un espectro. Siempre debemos buscar la cohesin ms alta, aunque la parte media del espectro suele ser aceptable. La escala de cohesin no es lineal. Es decir, la parte baja de la cohesin es mucho peor que el rango medio, que es casi tan bueno como la parte alta de la escala. En la prctica, un diseador no tiene que preocuparse de categorizar la cohesin en un mdulo especfico. Ms bien, se deber entender el concepto global, y as se debern evitar los niveles bajos de cohesin al disear los cdigos.
1.1.3.2.1 Niveles de cohesin

Cohesin Casual o Coincidental [8] [9] [2] La cohesin casual ocurre cuando existe poca o ninguna relacin entre los elementos de un mdulo. La cohesin casual establece un punto cero en la escala de cohesin. Es muy difcil encontrar mdulos puramente casuales. Puede aparecer como resultado de la modularizacin de un programa ya escrito, en el cual el programador encuentra un determinada secuencia de instrucciones que se repiten de forma aleatoria, y decide por lo tanto agruparlas en una rutina.
Otro factor que influenci muchas veces la confeccin de mdulos casualmente cohesivos, fue la mala prctica de la programacin estructurada, cuando los programadores mal entendan que modularizar consista en cambiar las sentencias GOTO por llamadas a subrutinas Finalmente diremos que si bien en la prctica es difcil encontrar mdulos casualmente cohesivos en su totalidad, es comn que tengan elementos casualmente cohesivos. Tal es el caso de operaciones de inicializacin y terminacin que son puestas juntas en un mdulo superior. Debemos notar que si bien la cohesin casual no es necesariamente perjudicial (de hecho es preferible un programa casualmente cohesivo a uno lineal), dificulta las modificaciones y mantenimiento del cdigo. Cohesin Lgica [8] [9] [2] Los elementos de un mdulo estn lgicamente asociados si puede pensarse en ellos como elementos que pertenecen a la misma clase lgica de funciones, es decir aquellas que pueden pensarse como lgicamente juntas. Por ejemplo, se puede combinar en un mdulo simple todos los elementos de procesamiento que caen en la clase de "entradas", que abarca todas las operaciones de entrada. Podemos tener un mdulo que lea desde consola una tarjeta con parmetros de control, registros con transacciones errneas de un archivo en cinta, registros con transacciones vlidas de otro archivo en cinta, y los registros maestros anteriores de un archivo en disco. Este mdulo que podra llamarse "Lecturas", y que agrupa todas las operaciones de entrada, es lgicamente cohesivo. La cohesin lgica es ms fuerte que la casual, debido a que representa un mnimo de asociacin entre el problema y los elementos del mdulo . Sin embargo podemos ver que un mdulo lgicamente cohesivo no realiza una funcin especfica, sino que abarca una serie de funciones.
Cohesin Temporal [8] [9] [2] Cohesin Temporal significa que todos los elementos de procesamiento de una coleccin ocurren en el mismo perodo de tiempo durante la ejecucin del sistema . Debido a que dicho procesamiento debe o puede realizarse en el mismo perodo de tiempo, los elementos asociados temporalmente pueden combinarse en un nico mdulo que los ejecute a la misma vez. Existe una relacin entre cohesin lgica y la temporal, sin embargo, la primera no implica una relacin de tiempo entre los elementos de procesamiento. La cohesin temporal es ms fuerte que la cohesin lgica, ya que implica un nivel de relacin ms: el factor tiempo. Si embargo la cohesin temporal an es pobre en nivel de cohesin y acarrea inconvenientes en el mantenimiento y modificacin del sistema. Un ejemplo comn de cohesin temporal son las rutinas de inicializacin (start-up) comnmente encontradas en la mayora de los programas, donde se leen parmetros de control, se abren archivos, se inicializan variables contadores y acumuladores, etc. Cohesin de Procedimiento [8] [9] [2] Elementos de procesamiento relacionados procedimentalmente son elementos de una unidad procedimental comn. Estos se combinan en un mdulo de cohesin procedimental que implica una secuencia de ejecucin de los pasos . Una unidad procedimental comn puede ser un proceso de iteracin (loop) y de decisin, o una secuencia lineal de pasos. En este ltimo caso la cohesin es baja y es similar a la cohesin temporal, con la diferencia que la cohesin temporal no implica una determinada secuencia de ejecucin de los pasos.
Al igual que en los casos anteriores, para decir que un mdulo tiene solo cohesin procedimental, los elementos de procesamiento deben ser elementos de alguna iteracin, decisin, o secuencia, pero no deben estar vinculados con ningn principio asociativo de orden superior. La cohesin procedimental asocia elementos de procesamiento sobre la base de sus relaciones algortmicas o procedimentales. Este nivel de cohesin comnmente se tiene como resultado de derivar una estructura modular a partir de modelos de procedimiento como ser diagramas de flujo, o diagramas Nassi-Shneiderman. Cohesin de Comunicacin [8] [9] [2] Ninguno de los niveles anteriores est fuertemente vinculado a una estructura de problema en particular. Cohesin de Comunicacin es el menor nivel en el cual se encuentra una relacin entre los elementos de procesamiento que es especficamente dependiente del problema.
b c
Figura 3.5 Asociacin por comunicacin

Decir que un conjunto de elementos de procesamiento estn vinculados por comunicacin significa que todos los elementos operan sobre el mismo conjunto de datos de entrada o de salida. En el diagrama de la figura 3.5 podemos observar que los elementos de procesamiento a, b, y c, estn asociados por comunicacin sobre la corriente de datos de entrada, en tanto que b, c, y d se vinculan por los datos de salida. Los diagramas de flujo de datos (DFD) son un medio objetivo para determinar si los elementos en un mdulo estn asociados por comunicacin. Las relaciones por comunicacin presentan un grado de cohesin aceptable. La cohesin por comunicacin es comn en aplicaciones comerciales. Algunos ejemplos pueden ser: un mdulo que imprima o grabe un archivo de transacciones; un mdulo que reciba datos de diferentes fuentes, y los transforme y ensamble en una lnea de impresin.
Cohesin Secuencial [8] [9] [2] En este nivel de cohesin, los datos de salida (resultados) de un elemento de procesamiento sirven como datos de entrada al siguiente elemento de procesamiento. En trminos de un diagrama de flujo de datos de un problema, la cohesin secuencial combina una cadena linear de sucesivas transformaciones de datos. Este es claramente un principio asociativo relacionado con el dominio del problema. Cohesin Funcional [8] [9] [2] En el lmite superior del espectro de relacin funcional encontramos la cohesin funcional. simple. En trminos prcticos podemos decir que cohesin funcional es aquella que no es secuencial, por comunicacin, por procedimiento, temporal, lgica, o casual . Los ejemplos ms claros y comprensibles provienen del campo de las matemticas. Un mdulo para realizar el clculo de raz cuadrada ciertamente ser altamente cohesivo, y probablemente, completamente funcional. No es probable que haya elementos superfluos ms all de los absolutamente esenciales para realizar la funcin matemtica, y no es probable que elementos de procesamiento puedan ser agregados sin alterar el clculo de alguna forma. En contraste un mdulo que calcule raz cuadrada y coseno, es improbable que sea enteramente funcional (deben realizarse dos funciones ambiguas). En un mdulo completamente funcional, cada elemento de procesamiento, es parte integral de, y esencial para, la realizacin de una funcin
En adicin a estos ejemplos matemticos obvios, usualmente podemos reconocer mdulos funcionales que son elementales en naturaleza. Un mdulo llamado LEER-REGISTRO-MAESTRO, o TRATAR-TRANS-TIPO3, presumiblemente sern funcionalmente cohesivos, en cambio TRATAR-TODAS-TRANS presumiblemente realizar ms de una funcin y ser lgicamente cohesivo. Llegamos a la conclusin que no es necesario determinar el nivel preciso de cohesin. Ms bien, es importante intentar conseguir una cohesin alta y
reconocer cuando hay poca cohesin para modificar el diseo del software y
conseguir una mayor independencia funcional.
1.1.3.3 Acoplamiento [2]

El acoplamiento es una medida de interconexin entre mdulos dentro de una estructura de software. El acoplamiento depende de la complejidad de interconexin entre los mdulos, el punto donde se realiza una entrada o referencia a un mdulo, y los datos que pasan a travs de la interfaz. Los cuatro factores principales que influyen en el acoplamiento entre mdulos son: Tipo de conexin entre mdulos: Los sistemas normalmente conectados, tienen menor acoplamiento que aquellos que tienen conexiones patolgicas. Complejidad de la interfaz: Esto es aproximadamente igual al nmero de producto diferentes pasados (no cantidad de datos). Ms producto, mayor acoplamiento. Tipo de flujo de informacin en la conexin: los sistemas con acoplamiento de datos tienen menor acoplamiento que los sistemas con acoplamiento de control, y estos a su vez menos que los que tienen acoplamiento hbrido. Momento en que se produce el ligado de la Conexin: Conexiones ligadas a referentes fijos en tiempo de ejecucin, resultan con menor acoplamiento que cuando el ligado tiene lugar en tiempo de carga, el cual tiene a su ver
menor acoplamiento que cuando el ligado se realiza en tiempo de linkageedicin, el cual tiene menos acoplamiento que el que se realiza realiza en tiempo de compilacin, todos los que a su vez tiene menos acoplamiento que cuando el ligado se realiza en tiempo de codificacin. En el diseo del software, intentamos conseguir el acoplamiento ms bajo posible. Una conectividad sencilla entre los mdulos da como resultado un software ms fcil de entender y menos propenso a tener un efecto ola causado cuando ocurren errores en un lugar y se propagan por el sistema.
Estructura de datos
Estructura de datos
a
Datos (variables)
Indicador de control
h rea de datos globales
Figura 3.6 Tipos de acoplamiento

La figura 3.6 proporciona ejemplos de diferentes tipos de acoplamiento de mdulos. Los mdulos a y d son subordinados a mdulos diferentes. Ninguno est relacionado y por tanto no ocurre un acoplamiento directo. El mdulo c es subordinado al mdulo a y se accede a l mediante una lista de argumentos por la que pasan los datos. Siempre que tengamos una lista convencional simple de argumentos (es decir, el paso de datos; la existencia de correspondencia uno a uno entre elementos), se presenta un acoplamiento bajo (llamado acoplamiento de datos) en esta parte de la estructura. Una variacin del acoplamiento de datos,
llamado acoplamiento de marca (stamp), se da cuando una parte de la estructura de datos (en vez de argumentos simples) se pasa a travs de la interfaz. Esto ocurre entre los mdulos b y a. En niveles moderados el acoplamiento se caracteriza por el paso de control entre mdulos. El acoplamiento de control es muy comn en la mayora de los diseos de software y se muestra en la figura. 3.6 en donde un indicador de control (una variable que controla las decisiones en un mdulo superior o subordinado) se pasa entre los mdulos d y e. Cuando los mdulos estn atados a un entorno externo al software se dan niveles relativamente altos de acoplamiento. Por ejemplo, la E/S acopla un mdulo a dispositivos, formatos y protocolos de comunicacin. El acoplamiento externo es esencial, pero deber limitarse a unos pocos mdulos en una estructura. Tambin aparece un acoplamiento alto cuando varios mdulos hacen referencia a un rea global de datos. El acoplamiento comn, tal y como se denomina este caso, se muestra en la Figura 3.6. Los mdulos c, g y k acceden a elementos de datos en un rea de datos global (por ejemplo, un archivo de disco o un rea de memoria totalmente accesible). El mdulo c inicializa el elemento. Ms tarde el mdulo g vuelve a calcular el elemento y lo actualiza. Supongamos que se produce un error y que g actualiza el elemento incorrectamente. Mucho ms adelante en el procesamiento, el mdulo k lee el elemento, intenta procesado y falla, haciendo que se interrumpa el sistema. El diagnstico de problemas en estructuras con acoplamiento comn es costoso en tiempo y es difcil. Sin embargo, esto no significa necesariamente que el uso de datos globales sea malo. Significa que el diseador del software deber ser consciente de las consecuencias posibles, del acoplamiento comn y tener especial cuidado de prevenirse de ellos. El grado ms alto de acoplamiento, acoplamiento de contenido, se da cuando un mdulo hace uso de datos o de informacin de control mantenidos dentro de los lmites de otro mdulo. En segundo lugar, el acoplamiento de contenido ocurre
cuando se realizan bifurcaciones a mitad de mdulo. Este modo de acoplamiento puede y deber evitarse.
1.1.4 Descomposicin en procesos [2]

Las fases que generalmente caracterizan al proceso del software son: definicin desarrollo y soporte, se aplican a todo software. El problema es seleccionar el modelo de proceso apropiado para la ingeniera del software que debe aplicar el equipo. El gestor del proyecto debe decidir que modelo de proceso es el ms adecuado para: 1. Los clientes que han solicitado el producto y la gente que realizara el trabajo; 2. Las caractersticas del producto en si y 3. El entorno del proyecto en el que trabaja el equipo de software. Cuando se selecciona un modelo de proceso, el equipo define entonces un plan de proyecto preliminar basado en conjunto de actividades estructurales. Una vez establecido el plan preliminar, empieza la descomposicin del proceso. Es decir, se debe crear un plan completo reflejando las tareas requeridas a las personas para cubrir las actividades estructurales. Un equipo debera tener un grado significativo de flexibilidad en la eleccin del paradigma de ingeniera de software que resulte mejor para el proyecto y de las tareas de ingeniera del software que conforman el modelo de proceso una vez elegido. Un proyecto cuando es relativamente pequeo se debe realizar con un enfoque secuencial lineal. Si hay limites de tiempo muy severos y le problema se puede compartir, el modelo apropiado es el DRA. Si se tiene el tiempo limitado lo mas apropiado es tomar una estrategia incremental.
Una vez que hemos elegido el modelo de proceso, la Estructura Comn de Procesos (ECP) se adapta a el. En todos los casos, la ECP (comunicacin con el cliente, planificacin, anlisis de riesgo, ingeniera, construccin, entrega y evaluacin del cliente) puede adaptarse al paradigma. Funcionara para modelos lineales, para modelos iterativos e incrementales, para modelos de evolucin e incluso para modelos concurrentes o de ensamblaje de componentes. El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organizacin. Las tareas de trabajo reales si varan. La descomposicin del proceso comienza cuando el gestor del proyecto pregunta Cmo vamos a realizar esta actividad ECP? Un proyecto simple requiere las siguientes tareas para la actividad de comunicacin con el cliente: 1. Desarrollar una lista de aspectos que se deben aclarar 2. Reunirse con el cliente para aclara los aspectos de la lista 3. Desarrollar en conjunto una exposicin del mbito del proyecto 4. Revisar el alcance del proyecto con todos los implicados 5. Modificar el alcance del proyecto cuando se requiera. Este tipo de acontecimientos pueden ocurrir en un periodo de menos de 48 hrs. Representan una descomposicin del problema apropiado para proyectos pequeos relativamente sencillos. Si se considera un proyecto ms complejo que tenga un mbito ms amplio y un mayor impacto comercial. Un proyecto como se podra requerir las siguientes tareas para la actividad de comunicacin con el cliente: 1. Revisar la peticin del cliente 2. Planificar y programar una reunin formal con el cliente 3. Realizar una investigacin para definir soluciones propuestas y enfoques existentes. 4. Prepara un plan de trabajo y una agenda para la reunin formal
5. Realizar la reunin 6. Desarrollar conjuntamente mini-especificaciones que reflejen la informacin, funcin y caractersticas de comportamiento del software 7. Revisar todas las mini-especificaciones para comprobar correccin , su consistencia la ausencia de ambigedades 8. Ensamblar las mini-especificaciones de un documento de alcance del proyecto 9. revisar ese documento general con todo lo que pueda afectar 10. modificar el documento de alcance del proyecto cuando se requiera su
1.2 El enfoque orientado a objetos

El anlisis orientado a objetos (AOO) y el diseo orientado a objetos (DOO) constituyen un enfoque distinto de desarrollo de sistemas. Estas tcnicas se basan en los conceptos de la programacin orientada a objetos, que han sido codificados en UML (Lenguaje Unificado de Modelacin), un lenguaje estandarizado de modelacin en el cual los objetos generados no solo incluyen cdigo referente a los datos sino tambin instrucciones acerca de las operaciones que se realizaran sobre los datos. EL Paradigma Orientado a Objetos es una disciplina de ingeniera de desarrollo y modelado de software que permite construir ms fcilmente sistemas complejos a partir de componentes individuales. Objetos + Mensajes = Programa El proceso Orientado a Objetos se mueve a travs de una espiral evolutiva que comienza con la comunicacin con el usuario. Es en esta parte donde se define el dominio del problema y se identifican las clases bsicas del problema. La
planificacin y el anlisis de riesgos establecen una base para el plan de proyecto OO. El trabajo tcnico asociado con la ingeniera del software OO sigue las siguientes tareas: 1. 2. 3. 4. 5. 6. Identificar clases candidatas Buscar clases en biblioteca Extraer nuevas clases si existen Desarrollar las clases sino existen Aadir las nuevas clases a la biblioteca Construir n-esima iteracin del sistema
La ingeniera de software hace hincapi en la reutilizacin. Por lo tanto las clases se buscan en una biblioteca (de clases existentes) antes de construirse Las Caractersticas del Enfoque Orientado a Objetos son: a) Objeto: Los datos estn cuantificados en entidades discretas y distinguibles llamadas objetos. b) Clase: Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupa para formar una clase. c) Atributo: Describen la clase o el objeto de alguna manera d) Mensajes: Medio por el cual interactan los objetos e) Polimorfismo: Significa que una misma operacin puede comportarse de modos distintos en distintas clases. f) Herencia: Compartir atributos y operaciones entre clases tomando como base una relacin jerrquica. Objeto Un objeto es una unidad de cdigo compuesto de variables y mtodos relacionados.
Un objeto encapsula datos, operaciones, otros objetos, constantes y otra informacin relacionada. Pueden ser: Entidades externas, ocurrencias o eventos, papeles o roles, unidades organizacionales, lugares, estructuras. Los Objetos tienen caractersticas y comportamientos. Mantiene sus
caractersticas en una o ms "variables", e implementa su comportamiento con "mtodos". Un mtodo es una funcin o subrutina asociada a un objeto. Cuando a las caractersticas del objeto le ponemos valores decimos que el objeto tiene estados. Las variables almacenan los estados de un objeto en un determinado momento. Para ser considerado como valido un objeto debe de tener las siguientes caractersticas:

Informacin retenida Servicio necesario Atributos mltiples Atributos comunes Operaciones comunes Requisitos esenciales
Clase La clase es un modelo o prototipo que define las variables y mtodos comunes a todos los objetos de cierta clase. Una clase es una descripcin generalizada que describe una coleccin de objetos con caractersticas similares. Todos los objetos que existen dentro de una heredan sus atributos y las operaciones disponibles para la manipulacin de los atributos.
Una superclase es una coleccin de clases y una instancia de una clase . Una instancia de una clase es otra forma de llamar a un objeto. En realidad no existe diferencia entre un objeto y una instancia. Slo que el objeto es un trmino ms general, pero los objetos y las instancias son ambas representacin de una clase. Atributo Los Atributos estn asociados a clases y objetos, ellos describen la clase y el objeto de alguna manera. Un atributo puede tomar un valor definido por un dominio enumerado. En la mayora de los casos, un dominio es simplemente un conjunto de valores especficos. En situaciones ms complejas el dominio puede ser un conjunto de clases. Mensajes Los mensajes son el medio a travs del cual los objetos intercambian informacin. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta una operacin. Un objeto es intil si est aislado . El medio empleado para que un objeto interacte con otro son los mensajes. Hablando en trminos un poco ms tcnicos, los mensajes son invocaciones a los mtodos de los objetos. Encapsulamiento El encapsulamiento significa que toda la informacin de un objeto se encuentra empaquetada bajo un nombre y puede reutilizarse como una especificacin o componente de un programa. El encapsulamiento consiste en unir en la clase las caractersticas y comportamientos, esto es, las variables y mtodos. Es tener todo esto es una sola
entidad. En los lenguajes estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la abstraccin y el ocultamiento. La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las Clases como cajas negras donde slo se conoce el comportamiento pero no los detalles internos, y esto es conveniente porque nos interesar ser conocer qu hace la clase pero no ser necesario saber cmo lo hace. EL Ocultamiento es la capacidad de ocultar los detalles internos del comportamiento de una Clase y exponer slo los detalles que sean necesarios para el resto del sistema. [7] El ocultamiento permite 2 cosas: restringir y controlar el uso de la Clase. Restringir porque habr cierto comportamiento privado de la Clase que no podr ser accedido por otras Clases. Y controlar porque daremos ciertos mecanismos para modificar el estado de nuestra Clase y es en estos mecanismos dnde se validarn que algunas condiciones se cumplan. En Java el ocultamiento se logra usando las palabras reservadas: public, private y protected delante de las variables y mtodos. Herencia La herencia consiste en que una clase puede heredar sus variables y mtodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, aparte de los atributos y mtodos propios, tiene incorporados los atributos y mtodos heredados de la superclase. De esta manera se crea una jerarqua de herencia. La herencia reduce el trabajo de la programacin usando fcilmente objetos comunes. Solo es necesario declarar que la clase A hereda de la clase B y despus proporcionar cualquier detalle
adicional. Los atributos y comportamientos de la clase B son parte de la clase A y no requiere ninguna programacin adicional. [7] Polimorfismo El polimorfismo permite que un nmero de operaciones diferentes tengan el mismo nombre. Esto reduce el acoplamiento entre objetos, haciendo a cada uno ms independiente.
1.2.1 Anlisis
El AOO ha sido muy exitoso en derribar problemas que se resisten al anlisis estructurado, como las interfaces de usuario. El AOO proporciona una transicin sin igual hacia el DOO y la programacin en lenguajes como Smalltalk, Ada y C++, y es el mtodo de anlisis preferido cuando los mtodos orientados a objetos van a ser utilizados posteriormente en la vida del sistema. Adems, los partidarios del AOO argumentan que los objetos dentro de un sistema son ms fundamentales (importantes, necesarios) para su naturaleza que las funciones que proporciona. Las especificaciones basadas en los objetos sern ms adaptables que las especificaciones basadas en las funciones. Los mtodos que marcan las directrices del AOO son: Coad-Yourdon Tcnica de modelado de objetos de Rumbaugh (Object Modelling Technique OMT) Shlaer-Mellor Booch ROOM Fusin
Coad y Yourdon Coad y Yourdon describen un mtodo de Anlisis Orientado a Objetos basado en cinco actividades principales: Definicin de las clases y objetos Identificacin de estructuras Identificacin de temas Definicin de atributos Definicin de servicios
Estas actividades son usadas para construir cada capa de un modelo de objetos de cinco niveles. Los objetos existen en el mbito del problema. Las clases son abstracciones de objetos. Los objetos son instancias de clases. La primera tarea del mtodo es identificar las clases y los objetos. La segunda tarea del mtodo es identificar las estructuras. Se reconocen dos tipos de estructuras: estructuras de generalizacin especializacin y estructuras globales [whole-part]. El primer tipo de estructura es como un rbol genealgico: es posible la herencia entre los miembros de una estructura. El segundo tipo de estructura es utilizado para modelar relaciones de entidades (por ejemplo: cada motor contiene una armadura). Los modelos grandes y complejos pueden necesitar una organizacin temtica, con cada (asunto, atributo, en lugar de tema) tema dedicado a un aspecto particular del problema. Por ejemplo, el modelo de objetos de un vehculo de motor puede tener una perspectiva mecnica o una perspectiva elctrica. Los atributos caracterizan a cada clase. Por ejemplo, un atributo de una mquina puede ser el numero de cilindros. Cada objeto tendr un valor para ese atributo. Los servicios definen lo que los objetos hacen. Definir los servicios es equivalente a definir las funciones del sistema.
La importancia fundamental del mtodo de Coad y Yourdon es su descripcin breve y concisa, as como el uso de textos generales como fuentes para las definiciones; de modo que las definiciones se enmarcan dentro del sentido comn y reducen el empleo de modismos. La debilidad principal del mtodo es su notacin compleja, la cual es difcil de utilizar sin el apoyo de una herramienta. Algunos usuarios del mtodo Coad-Yourdon han utilizado la dotacin de diagramacin de OMT en su lugar. Tcnica de Modelado de Objetos La Tcnica de Modelado de Objetos (OMT, Object Modelling Technique) transforma la definicin del problema del usuario (como la que se documenta en un Documento de Requerimientos del Usuario) en tres modelos: Modelo de objetos Modelo dinmico Modelo funcional
Los tres modelos en conjunto crean el modelo lgico requerido por los Estndares de Ingeniera de Software. El modelo de. El procedimiento para construirlo es el siguiente: Identificacin de los objetos Identificacin de las clases de objetos Identificacin de las asociaciones (ejemplo: las relaciones) entre objetos Identificacin de los atributos de los objetos Uso de herencia para organizar y simplificar la estructura de clases Organizacin de las clases y asociaciones estrechamente acopladas dentro de mdulos Acompaar a cada objeto con breves descripciones textuales
Los tipos ms importantes de asociacin son la adicin (es parte de) y la generalizacin (es un tipo de). El modelo dinmico muestra el comportamiento del sistema, especialmente la secuencia de interacciones. El procedimiento para construirlo es el siguiente: Identificar las secuencias de eventos dentro del mbito del problema y documentarlo en el seguimiento (rastreo) de eventos Construir un diagrama de transicin de estados para cada objeto que sea afectado por los eventos, mostrando los mensajes que fluyen, las acciones que son realizadas y los cambios en el estado de los objetos que tienen lugar cuando ocurren los eventos. El modelo funcional muestra la forma en que se obtienen los valores, sin considerar el momento en que sean computadas. El procedimiento para construirlo no requiere el uso de la descomposicin funcional, sino de: Identificar la entrada y salida de valores que el sistema recibe y produce Construir diagramas de flujo de datos que muestren la forma en que los valores de salida son computados a partir de los valores de entrada Identificar los objetos que son utilizados como almacenes de datos Identificar las operaciones de los objetos que comprenden cada proceso
El modelo funcional es sintetizado a partir de las operaciones de objetos, en vez de descomponerlo desde una funcin de alto nivel. Las operaciones de los objetos pueden ser definidos en cualquier etapa durante el modelado. Los aspectos ms importantes del OMT son sus capacidades simples aunque poderosas de notacin as como su madurez. Ha sido aplicado en varios proyectos por sus autores antes de ser publicado. La principal debilidad es la falta de tcnicas para integrar los modelos de objetos, los modelos dinmicos y los modelos funcionales.
Schlaer y Mellor Schlaer y Mellor comienzan el anlisis identificando el mbito del problema del sistema. Cada mbito es un mundo separado habitado por sus propias entidades conceptuales u objetos. Los mbitos ms grandes son divididos en subsistemas. Despus, cada mbito o subsistema es analizado de forma separada en tres etapas: Modelado de la informacin Modelado de estado Modelado de procesos
Las tres actividades de modelado crean en conjunto el modelo lgico requerido por los Estndares de Ingeniera de Software. El objetivo del modelado de informacin es identificar: Los objetos dentro del sistema Los atributos de cada objeto Las relaciones entre cada objeto
El modelo de informacin es documentado mediante diagramas y definiciones de objetos, atributos y relaciones. El objetivo del modelo de estado es identificar: Los estados de cada objeto, y las acciones que se realizan sobre ellos Los eventos que causan que los objetos pasen de un estado a otro Las secuencias de estados que forman el ciclo de vida de cada objeto Las secuencias de mensajes que comunican los eventos que fluyen entre los objetos y los subsistemas
Los modelos de estado son documentados mediante diagramas de modelo de estados (mostrando las secuencias de estados), diagramas de modelos de comunicacin de objetos (mostrando los mensajes que fluyen entre los estados), y listas de eventos. El objetivo del modelo de proceso es identificar: Las operaciones de cada objeto requeridas durante cada accin Los atributos de cada objeto que son almacenados en cada accin
Los modelos de proceso son documentados mediante diagramas de accin de flujo de datos, mostrando las operaciones y el flujo de datos que ocurren en cada accin, y los diagramas de modelo de acceso de objeto, mostrando el acceso de datos entre objetos. Los procesos complejos tambin deben ser descritos. La fuerza del mtodo Schlaer-Mellor es su madurez (sus autores declaran haber estado desarrollndolo desde 1979) y la existencia de tcnicas para integrar los modelos de informacin, los modelos de estado y los modelos de proceso. La principal debilidad del mtodo es su complejidad. Booch Booch modela un diseo orientado a objetos desde un punto de vista lgico, el cual define las clases, los objetos y sus relaciones; y desde un punto de vista fsico, que define la arquitectura de mdulos y procesos. La perspectiva lgica corresponde al modelo lgico que deben construir los ingenieros de software de acuerdo a los requerimientos de los estndares de Ingeniera de Software. El mtodo orientado a objetos de Booch tiene cuatro pasos: 1. Identificacin de clases y objetos a un nivel dado de abstraccin 2. Identificacin de la semntica de estas clases y objetos 3. Identificacin de las relaciones entre esas clases y objetos 4. Implementacin de las clases y objetos
Las primeras tres etapas deben ser completadas dentro de la etapa de Requerimientos del Sistema. La ltima etapa es realizada dentro de las fases de AD y DD. Booch sostiene que el proceso de diseo orientado a objetos no es deductivo [top-down] ni inductivo [bottom Up], sino algo que l denomina roundtrip gestalt design [diseo gestalt (conocimiento) de viaje redondo]. El proceso desarrolla un sistema a manera de incrementos e iteraciones. A los usuarios del mtodo de Booch se les advierte que deben integrar las fases SR y AD en una sola fase de modelado. Booch ofrece cuatro tcnicas para la documentacin de la perspectiva lgica: Diagramas de clase: consiste en un conjunto de clases y relaciones entre ellas. Puede contener clases, clases paramtricas, utilidades y metaclases. Los tipos de relaciones son asociaciones, contenencia, herencia, uso, instanciacin y metaclase. Diagramas de objetos: muestra objetos en el sistema y su relacin lgica. Pueden ser diagramas de escenario, donde se muestra cmo colaboran los objetos en cierta operacin; o diagramas de instancia, que muestra la existencia de los objetos y las relaciones estructurales entre ellos Diagramas de estado-transicin: muestran los estados posibles de cada clase, as como los eventos que ocasionan las transiciones de un estado a otro Diagramas de tiempo: aumenta un diagrama de objetos con informacin acerca de eventos externos y tiempo de llegada de los mensajes
Los libros de Booch sobre mtodos orientados a objetos han sido descritos por Stroustrup, el inventor de C++, como los nicos y mejores libros sobre el tema. Este cumplido revela los diversos alcances y la profundidad de un buen anlisis y prctica de diseo en sus escritos. Sin embargo, la notacin de Booch es molesta y hay pocas herramientas disponibles.
ROOM ROOM es una metodologa de Modelado Orientada a Objetos en Tiempo Real desarrollado por la compaa Object Time Developer. Esta metodologa ofrece varios puntos importantes: La complejidad esencial de reactivar sistemas es suficientemente alta para requerir conceptos de modelado especializado. ROOM toma ventajas de muchos desarrollos recientes de la tecnologa de computadoras (mtodos formales, el paradigma de objetos, interfaces grficas al usuario) Tambin, ROOM fue diseado explcitamente para tomar ventaja de la automatizacin basada en computadoras de las dems actividades mecnicas de desarrollo. Esto proporciona un potencial nico para beneficios significativos en productividad y calidad Estructura del modelado Utiliza sintaxis grfica para una fcil comprensin Abstracciones para tratar con fenmenos arquitectnicos de alto nivel de grandes sistemas de tiempo real. Protocolo basado en mltiples interfaces Objetos concurrentes (actores) Estructuras dinmicas Estructuras reproducidas
Modelado del comportamiento Alto nivel basado en sintaxis grfica Utiliza mquinas de estado jerrquicas; Permite elegir el modelado poderoso de capacidades, al tiempo que permite implementaciones automatizadas avanzadas y eficientes
Prioridad basada en la manipulacin de eventos para tratar con requerimientos de tiempo real Incorpora la industria de lenguajes de programacin estndar (por ejemplo: C++) para detalles especficos.
Experiencia Ms de cien diferentes proyectos industriales han utilizado ROOM Varios dominios de aplicacin:Incluyendo generacin de cdigo automtico completo Fusin El Mtodo Fusin est considerado como uno de los mtodos de desarrollo de Segunda Generacin. Proporciona elementos de desarrollo para y con reusabilidad y reingeniera. Los siguientes mtodos o tcnicas han influido en Fusin: OMT (Rumbaugh, 1991): El modelo Objeto es casi similar que en OMT. El modelo operacional es anlogo al modelo funcional en OMT; los diagramas de flujo de datos de OMT no son apropiados de acuerdo con Coleman y han sido formalizados con pre y post condiciones. Mtodos formales: pre y post condiciones son adoptados para describir formalmente qu es lo que hace un sistema. CRC: CRC extendido con informacin de comunicacin ha influenciado en grficas de interaccin de objetos. Diseo OO con Aplicaciones (Booch,1991):La visibilidad de las grficas son influenciadas por informacin de visibilidad en los diagramas Objeto de Booch. Fusin se basa en un pequeo pero comprensivo conjunto de tcnicas para creacin de diagramas bien definidas para la descripcin de las etapas de anlisis
y diseo. Fusin consiste de 3 fases: anlisis, diseo e implementacin . Fusin tambin proporciona reglas para verificar la consistencia e integridad del desarrollo de los modelos. En la fase de anlisis se define el comportamiento propuesto del sistema. Los modelos en esta fase describen las clases de objetos, las relaciones entre clases, las operaciones que pueden ser ejecutadas en el sistema y permite la realizacin de secuencias de esas operaciones. En la fase de diseo, los modelos producidos muestran la forma en que las operaciones del sistema son implementadas por objetos interactivos, referencias entre clases, relaciones de herencia, atributos de clases y operaciones en clases. En la fase de implementacin, la herencia, la referencia y los atributos de las clases son implementados en clases de un lenguaje de Programacin. Las interacciones entre objetos son programados como mtodos pertenecientes a la clase. Las mquinas estado (State Machines) son implementadas para reconocer secuencias permitidas de operaciones. En sus actividades se encuentran la codificacin, ejecucin y revisin. Fusin mantiene un diccionario de datos, un repositorio donde las diferentes entidades del sistema pueden ser nombradas y descritas.
1.2.2 Diseo [12][13]

El Diseo Orientado a Objetos (DOO) es un enfoque del diseo de software basado en objetos y clases. Un objeto es una abstraccin de algo en el dominio de un problema o su implementacin, reflejando las capacidades de un sistema para proporcionar informacin acerca de l mismo, interactuar con l o con ambos; es un encapsulamiento de valores de atributo y sus servicios exclusivos. Una clase describe un conjunto de objetos con atributos y servicios comunes. Un objeto es
una instancia de una clase, y el acto de crear un objeto se denomina: instantiation. Las clases pueden ser entidades con tipos de datos abstractos, como el Paquete de Telemetra y Espectro, as como entidades ms simples con tipos de datos primitivos como nmeros reales, enteros y cadenas de caracteres. Una clase es definida por sus atributos y servicios. Por ejemplo, la clase Espectro tendra atributos como frecuencia mnima, frecuencia media, frecuencia mxima y servicios tales como calibrar. Las clases pueden ser divididas en subclases. Por ejemplo, pueden existir varios tipos de Paquetes de Telemetra, y pueden ser creadas subclases de Paquete de Telemetra tales como Paquete de Fotmetro y Paquete de Espectmetro. Las subclases comparten caractersticas familiares, y el DOO permite para ello, que las subclases hereden operaciones y atributos de sus padres. Esto conduce hacia sistemas modulares y estructurados, que requieren menos cdigo para ser implementados. El cdigo comn es automticamente localizado de una manera top-down. Los mtodos de diseo orientado a objetos, a diferencia de otros, ofrecen un mejor soporte para la reutilizacin. El mecanismo tradicional de reus bottom-up donde es perfectamente posible que un mdulo de aplicacin llame a un mdulo de librera. Adems, la caracterstica de herencia permite el reuso top-down de los atributos y las operaciones de la superclase. El DOO combina servicios e informacin, con esto incrementa la modularidad. Las estructuras de control y datos pueden ser definidas de una manera integrada. Otras caractersticas del enfoque orientado a objetos, adems de las clases, los objetos y la herencia son la transmisin de mensajes y el polimorfismo. Los objetos envan mensajes a otros objetos para dirigir sus servicios. Los mensajes tambin son utilizados para transmitir informacin. El polimorfismo es la capacidad, al momento de la ejecucin del programa, para referirse a las
instancias de varias clases. El polimorfismo es a menudo implementado para permitir enlaces dinmicos. Las caractersticas de la orientacin a objetos como polimorfismo recaen en la asignacin dinmica de memoria. Esto puede hacer imprevisible el desempeo del software orientado a objetos. Debe tenerse cuidado al momento de programar aplicaciones de tiempo real para asegurar que las funciones que deben completarse dentro de un lmite definido tengan su procesamiento completamente definido al momento de la compilacin y no durante la ejecucin. El DOO es ms efectivo cuando se implementa mediante lenguajes de programacin orientado a objetos que soporten la definicin de objeto, herencia, intercambio de mensajes y polimorfismo. Smalltalk, C++, Eiffel y Object Pascal soportan todas estas caractersticas. Las tcnicas orientadas a objetos han demostrado ser mucho ms satisfactorias para la implementacin de software conducido por eventos, como las Interfaces Grficas de Usuario (GUIs), que los mtodos estructurados. Muchas herramientas CASE para los mtodos estructurados han sido mejoradas para las tcnicas orientadas a objetos. Si los mtodos orientados a objetos van a ser utilizados, esto debe hacerse a todo lo largo del ciclo de vida. Esto significa que el DOO solamente debe ser seleccionado para la fase AD si el Anlisis Orientado a Objetos (OOA) ha sido utilizado en la fase de SR. La transicin del anlisis al diseo, y de este a la programacin es una de las mayores ventajas de los mtodos orientados a objetos, ya que facilita la interaccin. Uno de los primeros trabajos realizados por Booch, describe una tcnica para el diseo orientado a objetos. En la prctica los resultados no han sido satisfactorios. La perspectiva del anlisis estructurado est basado en las funciones y en los datos, y el enfoque de la orientacin a objetos
est basada es clases, objetos, atributos y servicios. Estos enfoques son muy diferentes y es difcil mantenerlos en mente simultneamente. Al igual que el diseo estructurado, el diseo orientado a objetos no es un mtodo nico, sino un nombre para designar una clase de mtodos. Los miembros (Members) de esta clase incluyen: Booch; Diseo Jerrquico Orientado a Objetos (HOOD); Coad-Yourdon; Tcnica del Modelado de Objetos (OMT) Shlaer-Mellor.
En seguida se describe cada uno de ellos. Booch Booch cre el diseo orientado a objetos, y contina jugando un papel principal en el desarrollo del mtodo. Booch modela un diseo orientado a objetos en trminos de un enfoque lgico, el cual define las clases, los objetos y sus relaciones, y un enfoque fsico, el cual define la arquitectura de mdulos y procesos. El enfoque lgico corresponde al modelo lgico que requieren los estndares de la Ingeniera del Software para construir en la fase de SR. El enfoque fsico corresponde al modelo fsico que estos mismos estndares requieren para construir en la fase AD. Booch proporciona dos tcnicas de diagramacin para documentar el enfoque fsico: Diagramas de mdulo, son utilizados para mostrar la asignacin de clases y objetos hacia los mdulos, como los programas, paquetes y tareas en el
diseo fsico (el trmino mdulo en el mtodo de Booch es utilizado para describir cualquier componente del diseo); Diagramas de procesos, muestran la asignacin de mdulos hacia los procesadores de hardware. Los libros de Booch en Diseo Orientado a Objetos contienen muchos anlisis sobre la prctica del buen diseo. Sin embargo, la notacin de Booch puede llegar a ser molesta y existen pocas herramientas disponibles. HOOD HOOD (Hierarchical Object-Oriented-Design) El diseo jerrquico orientado a objetos (HOOD) es miembro de una familia de mtodos orientados a objetos que tratan de integrar la orientacin a objetos con los mtodos de diseo estructurado. La jerarqua sigue naturalmente a la divisin del objeto raz del nivel ms alto. Al igual que en el diseo estructurado, las parejas de datos fluyen entre componentes del software. La principal diferencia entre HOOD y los mtodos estructurados es que los componentes del software obtienen su identidad de su correspondencia con cosas en el mundo real, en vez de las funciones que el sistema tiene que realizar. HOOD fue originalmente diseado para utilizarse con Ada, aunque Ada no soporta la herencia, y no es un lenguaje de programacin orientado a objetos. Este no es un problema serio para el diseo HOOD, porque el mtodo no utiliza clases para estructurar los sistemas. HOOD no tiene un mtodo de anlisis complementario. El modelo lgico normalmente es construido utilizando el anlisis estructurado. La transformacin del modelo lgico al modelo fsico es difcil, haciendo difcil la construccin de un diseo coherente.
HOOD ha sido incluido en aplicaciones Ada. Cuenta ya con un nicho, pero es poco probable que llegue a tener una difusin y un apoyo tan amplio por parte de las herramientas como, por ejemplo, OMT
Coad y Yourdon Coad y Yourdon han publicado un enfoque integral para el anlisis y diseo orientado a objetos. Un diseo orientado a objetos es construido a partir de 4 componentes: Componente del mbito del problema; Componente de interaccin humana; Componente de administracin de tareas; Componente de administrador de datos.
Cada componente est compuesto de clases y objetos. El componente del mbito del problema est basado en el modelo (lgico) construido con el AOO en la fase de anlisis. Define el tema de estudio del sistema y sus responsabilidades. Si el sistema va a ser implementado en un lenguaje orientado a objetos, la correspondencia entre las clases y los objetos del mbito del problema sern uno a uno, y el componente del mbito del problema podr ser programado directamente. Sin embargo, el refinamiento substancial del modelo lgico es normalmente requerido, resultando en la incorporacin de ms atributos y servicios. Las consideraciones de reuso, y la no disponibilidad de un lenguaje de programacin totalmente orientado a objetos, pueden hacer que el diseo del componente del mbito del problema parta de un ideal representado por el modelo de AOO. Los componentes poco amigables en la interaccin humana envan y reciben mensajes a y desde el usuario. Las clases y objetos en el componente de interaccin humana tiene nombres que son tomados desde el lenguaje de interfaz del usuario, por ejemplo: una ventana y un men. Muchos sistemas tendrn hilos mltiples de ejecucin, y el diseador debe construir un componente de manejo de tareas para organizar el procesamiento. El
diseador necesita definir tareas como manejo de eventos (event-driven) o manejo del tiempo (clock-driven), as como sus prioridades de manera crtica. El componente de la administracin de datos proporciona la infraestructura para guardar y recuperar objetos. Puede ser un simple sistema de archivos, un sistema de administracin de bases de datos relacional, o igualmente un sistema de administracin de bases de datos orientado a objetos. Los cuatro componentes juntos hacen el modelo fsico del sistema . En el nivel ms alto, todos los diseos de Coad y Yourdon Orientado-a-Objetos tienen la misma estructura. Las clases y los objetos son organizados en la generalizacin-especializacin y en las estructuras completas (wholepart). Las estructuras de generalizacin especializacin son familiar de rboles, con hijos heredando los atributos de sus padres. Estructuras de partes completas (whole-part) son formadas cuando un objeto es descompuesto. La fuerza de los mtodos Coad y Yourdon son sus instrucciones, descripciones breves y su uso de texto general como fuentes de definiciones, as que las definiciones se ajustan al sentido comn y el jargon es minimizado. El significado de debilidad del mtodo es su notacin compleja, la cual es difcil de utilizarla sin herramientas de soporte. Algunos usuarios han utilizado en lugar del mtodo Coad-Yourdon la notacin de diagramacin de OMT. OMT La Tcnica de Modelacin de Objetos (Object Modelling Technique OMT) en el diseo tiene un alto nivel estratgico y decisin para resolver los problemas. Los problemas grandes se deben ver desde el punto de anlisis y diseo, este sistema se divide en subsistemas, a su vez este subsistema puede ser dividido en otros
subsistemas de manera que puedan ser manejados y cada componente pueda se comprensible. En esta etapa se deben crear estrategias, formular una arquitectura para el sistema y las polticas que deben guiarla adems un detalle del diseo. Se deben tener en cuenta los siguientes aspectos: Distinguir una arquitectura Elegir una implementacin para un control externo Si se usa base de datos elegir el paradigma de administracin de base de datos Determinar oportunidades para el reuso Elegir estrategia para interaccin de datos Elegir una forma de identificar los objetos Detallar el diseo
Durante el diseo del sistema se debe hacer un cuadro de estrategias y decisiones arquitecturales, tener una idea ms precisa de clases y mtodos individuales. Adicionalmente se puede mejorar el modelo de diseo para mejorar la implementacin. Se debe considerar los siguientes pasos: Uso de transformaciones para simplificar y optimizar el modelo de objetos desde el anlisis. Elaborar un modelo de objeto Elaborar un modelo funcional Evaluar la calidad del diseo del modelo Implementacin
El diseo es trasladado a un lenguaje de programacin actual y cdigo de base de datos. Este paso puede ser aplicado y considerado durante el anlisis y diseo
Shlaer y Mellor Shlaer y Mellor describen un Lenguaje de Diseo Orientado a Objetos (OODLE), derivado de la notacin de Booch y Buhr. Existen cuatro tipos de diagramas: Diagrama de Clases que muestran relaciones de utilizacin (cliente/servidor) y de amigos entre clases. Grfica de la estructura de Clase (class) que muestran el aspecto externo de la clase de forma similar a Booch.; Diagrama de Dependencias muestran la estructura de los mtodos de la clase, el flujo de datos y de control; Diagrama de Herencia: representan la herencia.
Existe un diagrama de clase para cada clase. El diagrama de clase define las operaciones y atributos de la clase. La grfica de la estructura de clase define la estructura del mdulo de la clase (class), el control y flujo de datos entre los mdulos de las clases. Existe una grfica de la estructura de la clase para cada clase. Los diagramas de Dependencia muestran las dependencias entre clases, las cuales pueden ser: Cliente - servidor; Amigables.
Una dependencia cliente-servidor existe cuando una clase (el cliente) llama en las operaciones a otras clases (el servidor). Una dependencia de amistad existe cuando una clase accede al dato interno de otra clase. Esto es una violacin de informacin ocultacin. Los diagramas de herencia muestran la herencia de relaciones entre clases.
BIBLIOGRAFA
[1] [2] [3] Sommerville, Ian (2005), Ingeniera de software, Ed. Addison Wesley 7 Edicion. Pressman Roger S. Ingeniera del software, Ed. Mc Graw Hill, 5 edicin Kendall Kenneth E. & Kendall Julie E., Anlisis y diseo de sistemas, Ed. Prentice Hall 6 edicin
REFERENCIAS WEB
[4] Instituto Nacional de Estadstica e Informtica, Realidad Virtual Tecnologa Orientada a Objetos [5] [En lnea], Per [Consulta: Septiembre de 2006], <http://www.inei.gob.pe/biblioineipub/bancopub/inf/lib5040/IND.htm> Tejerina Martn, Monografas Lucas Morea, Sinexi SA, Programacin Orientada a Objetos, [Consulta: Marzo de 2006] <http://www.monografias.com/trabajos14/progorie/ progorie.shtml> [6] Departamento de Auditoria Informtica UNAM, Metodologas de Ingeniera de Software [En lnea], Mxico [Consulta: Marzo de 2006] <http://sistemas.dgsca.unam.mx/publica/ pdf/metodologias.PDF> [7] [8] Ciberaula, Tecnologa Orientada a Objetos [En lnea], Madrid Espaa [Consulta: Marzo de 2006], <http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/> A.U.S. GustavoTorossi, Apuntes de diseo estructurado: Cohesin [En lnea], Provincia de Chaco Republica de Argentina [Consulta: Marzo de 2006] <http://www.chaco.gov.ar/ utn/disenodesistemas/apuntes/de/Unidad_5.html> [9] Fernando Berzal, Cohesin y Acoplamiento [En lnea], Espaa [Consulta: Marzo de 2006], <http://elvex.ugr.es/decsai/java/pdf/4D-cohesion.pdf> [10] A.U.S. GustavoTorossi, Apuntes de diseo estructurado: Acoplamiento [En lnea], Provincia de Chaco Republica de Argentina [Consulta: Marzo de [En 2006] linea], <http://www.chaco.gov.ar/utn/disenodesistemas/apuntes/de/Unidad_4.html> [11] Creative Commons, Iagp3.html> [12] Javier Alberto Moya Espinoza, Copyright Ilustrados, Metodologa OMT [En lnea], [Consulta: Marzo de 2006] <http://www.ilustrados.com/publicaciones/EpZVVyAky uqpxfFpAs.php [13] Instituto Tecnolgico de la Laguna, Analisis y Diseo Orientado a Objetos Mtodos y Modelos [En lnea], Mxico[Consulta: Marzo de 2006], <http://www.itlalaguna.edu.mx/ academico/carreras/sistemas/Analisis%20y%20dise%F1o%20orientado%20a %20objetos/cap2.pdf#search=%22metodo%20hood%22
Metodologas usadas en ingeniera del software
Murcia Espaa [Consulta: Marzo de 2006], <http://www.um.es/docencia/barzana/IAGP/

Dsi p1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dsi p1

Uploaded by

Copyright:

Available Formats

Diseo Estructurado de Sistemas de Informacin

1.1.3 Diseo de mdulos [2]

Diseo Estructurado de Sistemas de Informacin

C(p1 + p2) > C(p1) + C(p2)

Diseo Estructurado de Sistemas de Informacin

Regin de costo mnimo

Costo total del software

Figura 3.4 Esfuerzo Costo en modularidad

Diseo Estructurado de Sistemas de Informacin

1.1.3.1 Diseo Modular Efectivo [2]

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

1.1.3.2 Cohesin [2]

1.1.3.2.1 Niveles de cohesin

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

Figura 3.5 Asociacin por comunicacin

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

1.1.3.3 Acoplamiento [2]

Diseo Estructurado de Sistemas de Informacin

h rea de datos globales

Figura 3.6 Tipos de acoplamiento

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

1.1.4 Descomposicin en procesos [2]

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

1.2 El enfoque orientado a objetos

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

100 Diseo estructurado

Diseo Estructurado de Sistemas de Informacin

101 Diseo estructurado

Diseo Estructurado de Sistemas de Informacin

102 Diseo estructurado

Diseo Estructurado de Sistemas de Informacin

103 Diseo estructurado

Diseo Estructurado de Sistemas de Informacin

Diseo Estructurado de Sistemas de Informacin

105 Diseo estructurado

Diseo Estructurado de Sistemas de Informacin

1.2.2 Diseo [12][13]

106 Diseo estructurado

Diseo Estructurado de Sistemas de Informacin

107 Diseo estructurado

Diseo Estructurado de Sistemas de Informacin

108 Diseo estructurado

Diseo Estructurado de Sistemas de Informacin

109 Diseo estructurado

Diseo Estructurado de Sistemas de Informacin

110 Diseo estructurado

Diseo Estructurado de Sistemas de Informacin

111 Diseo estructurado

Diseo Estructurado de Sistemas de Informacin