dr. juan jos© aranda aboy aspectos avanzados de la tecnolog­a de objetos 1....

Download Dr. Juan Jos© Aranda Aboy Aspectos Avanzados de la Tecnolog­a de Objetos 1. Introducci³n

Post on 07-Feb-2015

5 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • Diapositiva 1
  • Dr. Juan Jos Aranda Aboy Aspectos Avanzados de la Tecnologa de Objetos 1. Introduccin
  • Diapositiva 2
  • Dr. Juan Jos Aranda Aboy Contenidos Calidad de Software: Qu es un buen sistema? Se tienen buenos sistemas? Cmo son los buenos sistemas? Cmo se construye un buen sistema? Modularidad. Tipos abstractos de datos. El proceso de desarrollo. Sistema, diseo, modelo, diagrama.
  • Diapositiva 3
  • Dr. Juan Jos Aranda Aboy Objetivos especficos Definir qu se entiende por un buen sistema. Caracterizar la problemtica de los sistemas existentes. Conocer cmo el enfoque de anlisis y diseo orientado a objetos contribuye a la construccin de buenos sistemas.
  • Diapositiva 4
  • Dr. Juan Jos Aranda Aboy Introduccin Programar es divertido, pero desarrollar software de calidad es difcil. Entre las ideas esplndidas, los requisitos o la visin, y un producto software funcionando hay un gran espacio y tiempo. El Anlisis y el Diseo definen cmo solucionar el problema: qu programar. Su resultado debe ser fcil de comunicar, revisar, implementar y evolucionar. Nuestro objetivo estar focalizado en la Ingeniera de Software orientada a objetos como la manera en que se utiliza esta tecnologa para realizar anlisis efectivos que permitan diseos e implementaciones eficientes de buenos sistemas.
  • Diapositiva 5
  • Dr. Juan Jos Aranda Aboy Qu es un buen sistema? Un buen sistema, de alta calidad, es aquel que cumple las necesidades de sus usuarios: til y aprovechable: Resuelve el problema planteado. Hace la vida de los usuarios mas fcil mejor. Confiable: Tiene pocos errores. Flexible: Se adapta a los cambios que van apareciendo en las necesidades de los usuarios, permitiendo su mantenimiento. Accesible: Tanto para compra como para mantenimiento. Disponible: Tiene que ejecutarse sobre el hardware y Sistema Operativo disponibles. Debe entregarse a tiempo.
  • Diapositiva 6
  • Dr. Juan Jos Aranda Aboy Se tienen buenos sistemas? Los avances del software han revolucionado nuestra vida: la manera en que nos comunicamos, aprendemos como nos entretenemos, la banca, los cuidados de salud, etc. Sin embargo, tambin encontramos fallos, algunos drsticos, como por ejemplo: Explosin de Ariane 5 debido a una serie de fallos de software.Ariane 5 Pacientes con sobre dosis de radiaciones producto de un software complejo, mal documentado y poco revisado. (Therac-25)Therac-25 etc... Documentacin sobre fallos: Forum On Risks To The Public In Computers And Related SystemsForum On Risks To The Public In Computers And Related Systems
  • Diapositiva 7
  • Dr. Juan Jos Aranda Aboy Realidades y Promesas Realidades: Como promedio, los grandes proyectos duran un 50% mas de lo planificado. Las tres cuartas partes de los fallos de un gran proyecto son operativos. La cuarta parte de los grandes proyectos se cancela. Promesas: Las nuevas tecnologas prometen reducir los tiempos de desarrollo y aumentar la tasa de xito de los proyectos...
  • Diapositiva 8
  • Dr. Juan Jos Aranda Aboy Cmo son los buenos sistemas? Hay un lmite de cuanto puede entender un ser humano de una sola vez. Debe poderse emprender una tarea de desarrollo de mantenimiento sin entender todo el sistema. Es importante controlar la complejidad del sistema: Pensar en el sistema como un conjunto de mdulos. Identificar dependencias entre mdulos.
  • Diapositiva 9
  • Dr. Juan Jos Aranda Aboy Modularidad Un mdulo, en sentido amplio, puede ser cualquier elemento identificable del sistema que tiene sentido por si mismo: Archivos Subrutinas Funciones de biblioteca Clases, en un lenguaje orientado a objetos Programas subsistemas con relativa independencia Otras estructuras Identificado un buen mdulo, se puede contemplar su reutilizacin como un componente.
  • Diapositiva 10
  • Dr. Juan Jos Aranda Aboy Conceptos asociados Dependencia y acoplamiento Cohesin Interfaz Encapsulamiento Abstraccin
  • Diapositiva 11
  • Dr. Juan Jos Aranda Aboy Dependencia y acoplamiento El mdulo A depende del mdulo B si cualquier cambio en el mdulo B implica que tambin haya que modificar al mdulo A. Se dice que A es un cliente de B, que B acta como servidor de A. Es comn que un mismo mdulo sea tanto cliente como servidor, o sea, que dependa de otros mdulos y que existan mdulos que dependan de l. Incluso es posible una dependencia circular, lo que debe evitarse, ya que impide la reutilizacin. La dependencia se conoce a veces como acoplamiento. Un sistema con muchas dependencias tiene fuerte acoplamiento. Los buenos sistemas tienen dbil acoplamiento, porque los cambios en una parte del sistema tienen menor probabilidad de propagacin a travs del mismo.
  • Diapositiva 12
  • Dr. Juan Jos Aranda Aboy Encapsulamiento Para aprovechar el dbil acoplamiento de un sistema es muy importante poder identificar qu mdulos estn acoplados. Tambin se deben comprobar los cambios en un mdulo, lo que pudiera ser caro. Idealmente, debe conocerse con certeza cules mdulos de un sistema podran verse afectados por un cambio en un mdulo dado. Una vez establecidos los lmites entre mdulos: Qu suposiciones pueden hacer los clientes de un determinado mdulo? Qu servicios se supone que va a proporcionar? Qu mdulos son clientes de un mdulo dado?
  • Diapositiva 13
  • Dr. Juan Jos Aranda Aboy Interfaces La Interfaz de un mdulo define algunas de sus caractersticas, de las que sus clientes pueden depender. El resto del sistema puede utilizar al mdulo solamente de las maneras permitidas pos sus interfaces. Por tanto: la interfaz encapsula conocimiento sobre el mdulo. Si un mdulo cambia internamente sin modificar su interfaz, dicho cambio no conllevar que haya que realizar ningn otro cambio en ninguna otra parte del sistema.
  • Diapositiva 14
  • Dr. Juan Jos Aranda Aboy Sintaxis y semntica En muchos lenguajes de programacin el mdulos cliente analiza la dependencia sintctica: qu tipos de datos tiene declarada la interfaz del mdulo servidor. Lo ideal es poder comprobar igualmente la dependencia semntica: si la interfaz documenta fielmente las suposiciones que pueden conjeturarse sobre el mdulo, realizara una especificacin del mdulo, que explica qu pueden asumir los clientes sobre su comportamiento, no solamente la sintaxis acerca de cmo interactuar con l.
  • Diapositiva 15
  • Dr. Juan Jos Aranda Aboy Dependencias de contexto Es til saber todas las dependencias que existen, adems de las dependencias que estn documentadas en los mdulos del sistema. Este conocimiento clarifica: Cules servicios proporciona cada mdulo. Cules servicios necesitar un mdulo para funcionar. Los servicios necesitados por un mdulo se denominan dependencias de su contexto, y pueden expresarse en funcin de interfaces. Las dependencias de contexto de un mdulo y la interfaz propia del mdulo constituyen un contrato que describe las responsabilidades de dicho mdulo: Si el contexto proporciona lo que el mdulo necesita, entonces l garantiza proporcionar los servicios descritos en su interfaz.
  • Diapositiva 16
  • Dr. Juan Jos Aranda Aboy Beneficios La modularidad con interfaces definidas facilita la comprensin del sistema, as como su posible modificacin, ya que reduce lo que se necesita saber del mismo: En un desarrollo en equipo, los desarrolladores de cdigo que utilizan un mdulo slo deben comprender su interfaz, no cmo funciona, de manera que sean mas productivos. Se introducen menos errores, ya que los desarrolladores tienden a conocer lo que realmente necesitan saber y pueden ignorar de forma segura otros aspectos del sistema. Los errores son mas fciles de encontrar tanto en desarrollo como en mantenimiento, debido a que no se examinan mdulos irrelevantes. Una vez que exista un mdulo con documentacin de lo que proporciona y de lo que requiere, es posible pensar en su reutilizacin.
  • Diapositiva 17
  • Dr. Juan Jos Aranda Aboy Mdulos e interfaces Un mdulo puede tener varias interfaces, lo que facilita identificar de la manera mas sencilla posible cuales seran los cambios requeridos si ocurriesen cambios en otros mdulos. El empleo de varias interfaces para documentar un mdulo permite precisar cuales servicios necesita un determinado cliente. Esta idea es til tanto para mantenimiento como para reutilizacin. Conclusin parcial: Un buen sistema est formado por mdulos encapsulados.
  • Diapositiva 18
  • Dr. Juan Jos Aranda Aboy Abstraccin: fuerte cohesin Los mdulos correctos tienen la propiedad de que sus interfaces proporcionan una abstraccin de algn elemento conocido de manera intuitiva que puede, no obstante, ser difcil de implementar. Se dice que este tipo de mdulos tiene una fuerte cohesin. La interfaz se abstrae de las cosas que el desarrollador no tiene que conocer para utilizar el mdulo. El mdulo realiza un conjunto coherente de acciones, pero -dentro de lo posible- el desarrollador del cliente est protegido de la informacin irrelevante relativa a cmo el mdulo cumple sus funciones.
  • Diapositiva 19
  • Dr. Juan Jos Aranda Aboy Informacin oculta La informacin oculta no tiene inters para los programadores del cliente. Precisando: Abstraccin: Cuando un cliente de un mdulo no necesita saber mas de lo que muestra su interfaz. Encapsulamiento: Cuando un cliente de un mdulo no es capaz de saber mas de lo que hay en la interfaz. La situacin en que la interfaz proporciona medios de interaccin con algunos datos sin revelar su formato interno es normal tanto en el desarrollo orientado a objetos como en el estilo de tipo de datos abstractos.
  • Diapositiva 20

View more >