Ivar Jacobson en UML, MDA, y el futuro de las metodologas

1. Ivar t eres una leyenda, t has estado trabajando en cosas durante tantos aos, qu vas a hacer hoy? Hoy mi objetivo sigue siendo en la mejora de las mejores prcticas de desarrollo de software. Y estoy trabajando en lo que yo llamara proceso de desarrollo de software de ltima generacin, y tambin estoy trabajando con orientacin aspecto de desarrollo de software que sera probablemente dos de las cosas ms importantes. Tengo una serie de cosas de menor importancia que los que trabajo.

2. Cules son algunos de los problemas con el movimiento AGILE? En primer lugar todos somos Agile ; que todos pretendemos que somos Agile hoy. Decir que usted no es gil, es como decir que usted no es potente. As que estamos todos gil. Y yo personalmente he escrito artculos sobre cosas como un rotundo " s" a los procesos giles. Pero tambin a la prxima gran cosa, que es el ttulo de un documento . As que todos respaldamos los principios giles , todos podemos suscribir el manifiesto gil , que no est de acuerdo que el software de trabajo es ms importante que la documentacin , por lo que no es el punto . La verdadera diferencia es que cuando se habla de los mtodos de algunos realmente clasifican a s mismos como los mtodos giles y otros no hagan eso , pero en realidad hay todo un espectro , hay procesos bsicos unificados que he estado trabajando durante tantos aos y giles versiones de procesos unificados . Y en realidad no creo que debe haber algo ms que las versiones giles de procesos unificados para ser franco . Y lo mismo con los mtodos giles , algunos mtodos giles son ms como tradicional en proceso tambin. Y eso es todo el espectro. Pero si hablamos de la diferencia fundamental real entre los diferentes mtodos de hoy damos los mtodos giles extremos y tomamos , por otro lado, el proceso unificado racional , por ejemplo , la gran diferencia es la forma de lidiar con el conocimiento , ambos estn de acuerdo en que necesitamos conocimiento , ambos coinciden en que tenemos la experiencia para desarrollar un buen software. Necesitamos personas competentes para hacerlo. Sin la gente que realmente desarrollamos nada . Pero la forma en que trata el conocimiento es diferente fundamental. Con los mtodos giles que se basan principalmente en el conocimiento tcito . No es un mundo maravilloso ser capaz de confiar en el conocimiento tcito ? Lo que usted tiene en la cabeza es til . El otro enfoque se bas en el conocimiento explcito , sobre todo , no slo porque no hay nadie que slo pueden confiar en el conocimiento explcito y el conocimiento explcito se estructura de un modo u otro , puede ser que en el proceso unificado de un meta- modelo , el proceso de meta- modelo que describe los diferentes tipos de artefactos, y cmo se relacionan y as sucesivamente. As que esa es la diferencia fundamental. Las otras cosas son: la tomamos prestada una de la otra , la tomo prestada de los mtodos giles buenas ideas, como primera prueba de diseo y cosas por el estilo , o el desarrollo basado en pruebas , que toman prestado de nosotros como historias de usuario y otras ideas tambin. Y as es como debe ser. La diferencia fundamental es exactamente eso : si confiar en el conocimiento tcito o de confiar en el conocimiento explcito . 3. Cul es la diferencia fundamental entre el conocimiento tcito y explcito? Un mtodo que se basa en el conocimiento tcito , cmo te ense eso? Cmo sabes lo que es , ya que slo est en la cabeza de la gente? Cmo , si pones a un equipo que todos vienen con el conocimiento tcito , cmo conseguir que se pongan de acuerdo sobre lo que debemos hacer? Y si usted no sabe lo que el conocimiento para basar su proyecto en , cmo es posible crecer ese conocimiento? Cmo es posible , [ hay herramientas ] , si usted no sabe el conocimiento y las herramientas que vas a trabajar? As que ese es el problema en primer lugar con los mtodos que se basan en el conocimiento tcito . Si usted toma un proceso unificado , el problema fundamental de que , en realidad se tiene que seleccionar qu parte del proceso unificado que debe utilizar. El proceso unificado es un marco , marco de proceso comprende un montn de cosas que usted puede escoger y elegir , y te dejan que el proyecto para identificar qu escoger y elegir . Eso lleva tiempo . Usted necesita saber el proceso para

decidir realmente lo que voy a utilizar . Y eso no es fcil. Entonces usted tiene que aprender lo que debe usar , y hay que aplicar los conocimientos . Y, finalmente, hay que controlarlo , sino que significa cambiar porque nada es estable. Eso no lo hace un proceso gil , por lo que el proceso unificado se percibe a causa de este tamao no ser gil. Y como he dicho durante muchos aos nunca he credo que un proceso unificado o proceso unificado racional como tal, sera aplicable a todo el mundo y el desarrollo de software, ya que en realidad requiere un esfuerzo para adoptarlo. Dije hace algo como 15 a 20 aos, cuando yo crea que un mximo del 10-15% de la poblacin jams adoptarlo (y eso no suena bien no?) , Pero saba que en ese momento hay una manera de cambiarlo . Y eso es lo que es realmente el futuro de un proceso unificado gracias a que est basado en el conocimiento explcito , hay un futuro . Si no se bas en el conocimiento explcito , pero el conocimiento tcito no puedo ver cmo puede evolucionar eso. Cules sern los mtodos giles ver en diez aos? Quiero decir , cmo hacer crecer estos mtodos por lo que realmente se mueven para producir un software mejor , ms rpido y con mayor calidad y con ms diversin ?
4. Usted dijo que un proceso como el unificado nunca puede ser adoptado por ms de

10% de la poblacin desarrollador. Por qu? La razn es que la inversin que se necesita para aprender un proceso unificado como lo es hoy , es un poco , los equipos pequeos altos , pequeas campaas se encuentran demasiado caro para invertir en ese tipo de formacin, y las herramientas y as sucesivamente. As que no lo hacen . Las empresas ms grandes lo hacen y lo hacen en todo el mundo todo el tiempo. Eso significa que puedo estar equivocado en donde contamos con programadores , pero creo que los equipos ms grandes pueden hacerlo, pero los equipos ms pequeos no lo har . Sin embargo hay una manera de cambiar eso. Pero en este momento creo que cuesta adoptar algo. Hay que estudiar , porque hay algo que estudiar. Con los mtodos giles no hay mucho que estudiar, los libros finos , hermosos libros , pero nada! Mientras que si usted va al proceso unificado , en particular, proceso unificado racional no hay nadie que alguna vez ser capaz de leerla en su totalidad . As que , pero si intenta realmente aprender, se necesita algn tiempo . Si vas a entrenar, porque el entrenamiento en el mismo, se necesita tiempo para ir a travs de las clases y aprender de ello y, por ltimo , si usted quiere adoptarlo , no hay manera de que pueda adoptar sin tener entrenadores o mentores que le ayudan . Yo ni siquiera tratar de adoptar proceso unificado sin tener las personas que lo han hecho antes. Es demasiado caro y demasiado arriesgado para hacerlo. Pero as es como lo es hoy , no va a ser as en el futuro.
5. Cul ser el proceso de prxima generacin?

Creo firmemente que el proceso de prxima generacin ser lo que yo llamo un proceso inteligente e inteligente es bsicamente gil + + + , que significa que tiene las propiedades de la agilidad , pero en realidad tambin ayudar a utilizar el conocimiento. Imaginemos que , de alguna manera mgica , podramos ensear a la gente y aprender de personas para ensear proceso unificado , para aplicar proceso unificado , para su control , etc Podramos ensearles a hacer eso. Y slo la parte del proceso unificado que realmente necesita y slo cuando lo necesite justo en el InContext derecho cuando necesita que significa pequeos fragmentos de conocimiento , procedentes cuando lo necesita y no antes. Imagnese que usted puede conseguir esto, entonces importa el tamao de un proceso? Importa si un proceso es de 50.000 pginas, 100.000 pginas, un milln de pginas realmente quiero como un gran proceso como el conocimiento de lo posible , pero quiero que se sirve cuando lo necesito y no antes. As que el tamao, cuanto ms grande mejor , no como solemos decir ahora hoy en da con los mtodos giles , mientras menos, mejor . Debido a que el conocimiento , en el supuesto de que el conocimiento realmente te da algo , ese es el comienzo de un proceso inteligente , que usted obtenga el conocimiento cuando se necesita , no antes. As que la tecnologa para hacer que eso significa agentes inteligentes o tecnologa similar. Los agentes inteligentes son como en cualquier papel que usted juega , usted no slo tener un programador de par , la pareja es en realidad el agente , usted tiene un par analista , diseador pares, pares arquitecto, director del proyecto par , cualquier cosa. Y eso significa que usted puede conseguir apoyo para hacer su trabajo en cualquier momento . Por lo que tiene , bsicamente, un mentor virtual esperando por ti, para estar listo para ayudarle en cualquier momento . Y hay evidencia cientfica de que una pareja de un mentor humana combinada con un mentor virtual es mucho ms eficaz que slo mentores humanos , entrenadores humanos. Hay un montn de evidencia cientfica , puedo darte referencia.

6. Lo que en realidad es un agente inteligente, es como el clip de papel en Microsoft

Word? No. Ese es el ejemplo exacto de algo que no queremos que la gente piense siquiera en , cuando piensan en los agentes inteligentes . Estos son intrusivos . Los agentes inteligentes son , quiero decir que usted puede considerar la tierra de una pieza / piezas de software y se puede considerarlo como un componente o como clase y crear instancias de ella y una instancia de tal cosa es ayudar al ser humano en hacerlo / reproduccin algn papel en particular en el desarrollo de software . Como hacer los requisitos o las pruebas y as sucesivamente. El software aqu es similar a la de otros programas pero tiene ms , sino que tiene, est impulsada no slo por el cdigo de procedimiento , pero en realidad por las reglas . Estas reglas han formulado explcitamente objetivos. Por ejemplo , el objetivo podra ser la produccin de un componente, ste no debe ser slo un componente, pero es un buen componente. Y luego estn las reglas de cmo creamos buenos componentes y stos unidad a desarrollar un buen componente . As que los agentes son nada realmente espectacular en usted, est en lo alto de la experiencia y el conocimiento que hemos tenido durante 20 aos , al igual que el sistema de expertos , los sistemas basados en normas y as sucesivamente. Pero ahora que ha sido formada por componentes , por lo que los problemas con estos sistemas antiguos eran que se convirtieron en sistemas monolticos y usados y son difciles de cambiar y control. Ahora les hemos componentizado y el truco es encontrar buenos agentes . Pero eso es similar a encontrar objetos buenos , buenos componentes as hay algunas reglas para identificar buenos agentes tambin, y algunas tcnicas para hacer eso .
7. Puede describir lo que esto podra ser como en un proyecto? Usted tiene, digamos,

un proyecto de 30 hombres estn construyendo un sitio de comercio electrnico en lnea, dnde los agentes encajan, cul podra ser similar en el tiempo? Los agentes estn all para apoyar a las personas que desarrollan software en diferentes roles. Normalmente habr un agente para ayudarle a hacer el uso de los casos, si usted hace un proceso unificado y despus de que el agente conocer que es una buena utilizacin de los casos es. Y hemos programado esta agentes para hacer lo que creemos que son buenas formas de hacer los casos de uso. Podra ser, si usted piensa que una buena manera de hacer un buen uso de los casos es hacer una historia de usuario, una versin muy ligera de casos de uso, usted puede hacer eso. Si es una buena manera de escribir un caso de uso ms preciso con condicin previa, post-condicin y definir todas las cosas diferentes que luego se convertirn en los casos de prueba, entonces se hace eso. Porque, bsicamente, casos de uso son los casos de prueba, por lo que es un montn de reglas de cmo hacer buenos casos de prueba. As que tendrs que para bsicamente todos los papeles que desempeamos en el desarrollo de software siguiendo luego las mejores prcticas de lo que creemos que es bueno las mejores prcticas.
8. Qu pasa con la programacin en parejas, sin duda la interaccin humana es ms

eficiente que la interaccin hombre-mquina? Hay pruebas cientficas de que en algunos casos los seres humanos en realidad no lo hacen tan buen trabajo, slo , pero en realidad si se trabaja con algunos mentores virtuales en lugar de mentores humanos se obtiene un resultado mucho ms productivo. Les puedo decir por experiencia propia que si utiliza los entrenadores para ayudar a la gente a adoptar cualquier tipo de metodologa, estos entrenadores suelen tener las mismas preguntas una y otra vez. As, por ejemplo las personas que trabajan con procesos unificados que han respondido a la pregunta " Qu es una buena prueba de los casos? " un centenar de veces y entonces tienen que discutir cmo hacer un caso de prueba y as sucesivamente. Son cosas elementales. Eso se convirti en aburrido y que no les gusta hacer eso, as que si usted puede en lugar de tener un mentor virtual que lleva toda esta carga , para discutir lo que este conocimiento bien conocido es , en lugar de utilizar los seres humanos para hacer eso. Y en realidad que el mentor virtual nunca se cansa , es disponible da y noche para trabajar. En cambio, los mentores humanos estn haciendo cosas ms avanzadas , como la " gestin del cambio " , cmo cambiar la organizacin, cmo hacer que la gente y adoptar los principios de desarrollo de software y as sucesivamente. Eso es mucho ms cualificado , que es nuestra propia experiencia. As que cuando entramos y trabajamos con un equipo, en vez tenemos menos mentores humanos en una organizacin y en su lugar todo el mundo tiene un mentor

virtual, y se obtiene un mejor resultado y es mucho ms rentable para la empresa. La otra cosa es que, si nos fijamos en l , existen resultados cientficos , creo que en la Universidad de Penn State , que, efectivamente, han medido y estudiado lo que sucede en un sistema de control de mando , cmo reaccionan los usuarios cuando se encuentran en una situacin de lucha , y el resultado fue que los seres humanos , cuando estn en una situacin normal , sin estrs, trabajan muy bien juntos , no es un problema real, pero en cuanto se meten en situaciones de estrs , toman decisiones equivocadas y que en realidad , hay un alto riesgo que hacen cosas que matan a la gente . As , mientras que con los mentores virtuales o agentes para ayudar , obtienen un resultado mucho mejor . As que creo que la programacin en parejas , si eso es transmitir el conocimiento de un experto a un chico nuevo menos expertos , es bsicamente una forma muy cara de hacerlo, porque podemos hablar de boca en boca, en la que si usted tiene un experto que debera tal vez entrenar a todo el equipo o al menos una parte del equipo , en lugar de entrenar a una persona a la vez. Y tambin es muy aburrido con este tipo de ensear la misma cosa una y otra vez. Personalmente nunca me aguanto , y s que muchas otras personas que no quieran hacerlo. As que creo , no excluira a tener algn tipo de apoyo en cuanto a la programacin en parejas pero es probablemente ms eficaz disponer de un experto para trabajar con mucha gente. Y luego la parte social de la misma , no podemos hablar de eso , yo realmente no quiero entrar en eso .
9. Pero en realidad qu es esto un proceso de tomar? No es tambin depende del

equipo: si tienes un buen equipo o un mal equipo, ser el proceso de realmente hacer una diferencia? Lo hace . Porque, en primer lugar, yo no considero a proceso ya que la mayora de la gente, me considero como un proceso de conocimiento, el conocimiento -base. No se trata de controlar . Cuando empec a desarrollar Objectory que se convirti en proceso unificado racional. Lo hice no porque , en realidad no saba mucho acerca de la gestin del proyecto , que era jefe de proyecto , pero yo no saba mucho acerca de las reglas para hacer eso , as que nunca pens en pasar un montn de energa en la formalizacin de la materia proceso aburrido , lo que todos los desarrolladores piensan que es aburrido y el odio. Me concentr slo en una cosa, que yo realmente quera hacer : cmo hacer cosas buenas , buenas , buenas interfaces de componentes , buenas operaciones, cualesquiera que sean buenos atributos , buen cdigo , los buenos casos de prueba , los buenos casos de uso y as sucesivamente, todos los de estas cosas. Nunca he visto a nadie en realidad dijo formalmente en cualquier libro de cualquier sustancia , hasta que lo logramos. As que eso es realmente lo que yo estaba interesado pulg No mire al proceso que la gestin de proyectos o algo para gerentes , considerar la tierra a base de conocimientos . As que, por supuesto, si usted est bien informado , a desarrollar mejor software, pero si no ests bien informado. Para m esa es la respuesta simple.
10. Est de acuerdo que XP est impulsado en gran medida por los desarrolladores,

mientras unificado es ms impulsado por los administradores? En realidad no, yo no hago eso . Creo que es una percepcin y que un proceso unificado , bsicamente, que realmente no puedo tener un proyecto de cualquier naturaleza en la que han costos involucrados , la gente quiere que le pague el dinero para hacer el trabajo , la gestin desarrollada est involucrado , sino que quieren , por supuesto, asegurarse de que obtienen algo por su dinero. Pero en todos los proyectos de procesos unificados , que yo sepa , en lo que respecta a la labor tcnica est impulsado por los expertos, los tcnicos , por lo que no veo ninguna diferencia con la programacin extrema en ese sentido . Hay una percepcin de que ahora vamos yo dije eso. Una de las cosas que no he visto en muchos aos, pero estamos de vuelta en la actualidad , es que hay tanta religin acerca de la metodologa , y durante los primeros aos 90 , cuando tuvimos todos estos diferentes mtodos sobre cmo hacer desarrollo orientado a objetos de software, usted sabe que haba un Grady Booch , Rumbaugh , yo tena mi libro , haba diez de nosotros , que ha silenciado por completo desde hace muchos aos , y era la guerra religiosa , ahora estamos de regreso y tienen guerra religiosa de nuevo porque se convierte en religiosa cuando se tiene un gran cantidad de argumentos que no estn realmente basados en hechos. Trato de permanecer fuera de estas discusiones y centrarse en la discusin de lo que realmente creo que puedo medir o tener pruebas para .

11. As que apelara que incluso el ganador final de todas estas guerras religiosas es

UML, sin embargo, hoy est siendo criticado. Qu opina al respecto? Aceptar. Primero vamos a decir que s que es cierto que tuvimos que crear a finales de los aos 90 una propuesta de norma y que fue adoptado y que fue , como usted sabe , se inici originalmente por Grady Booch , Rumbaugh Ian y yo. Luego nos dieron un montn de adopcin. Bsicamente, cada metodologa en ese momento dio su propia notacin y de hecho trabaj duro con ellos para asegurarse de que podan usar UML para sustituir a nuestra propia notacin y nuestro propio idioma. En ese campamento haba otro competidor que era muy grave y que era STL , STL es el predecesor de UML que se convirti en el estndar de las telecomunicaciones en 1976 , y luego '80 y as sucesivamente. De hecho he participado en el desarrollo de STL , por lo que fue mi primer lenguaje de modelado , bsicamente , que se convirti en un estndar. Lo que hicimos , sabamos que hemos desarrollado un nuevo tipo de lenguaje, porque normalmente estas lenguas se desarrollan sin tener una semntica detallados subyacentes; razn es lenguaje debe ser capaz de trabajar en frente de muchos otros idiomas como , en ese momento nos hablado de CHILL , ADA y as sucesivamente. Podran haber muchas otras semnticas subyacentes y usted no quiere que eso se reflejar en el lenguaje de modelado . Pero UML gan ese voto tambin, as que ahora STL es parte del UML , incluido en la familia de UML. As UML ha sido todo un xito en la familia lenguaje de modelado . Ahora cul es la crtica contra UML ? De dnde viene? Definitivamente viene de la gente que nunca ha usado el lenguaje de modelado , y se trata de personas que han estado trabajando con la semntica formal de los lenguajes formales . Bueno, yo lo he hecho a m mismo tambin, hice mi doctorado en lenguaje formal de la semntica formal , y cuando lo hicimos la STL solamos semntica formal que en realidad utiliz mtodo de desarrollo de Viena para especificar tanto la sintaxis , la sintaxis abstracta , la sintaxis concreta , la semntica esttica, la semntica dinmica y funcionamiento , y nos hicieron bajar a los detalles nitty Gritty . Con UML no ir tan lejos , porque de verdad nos sentimos que muy pocas personas leen semntica matemticos formales . Pero tuvimos sintaxis abstracta , tuvimos semntica esttica de una manera formal. Ahora sigues y te ves en la programacin. Cuntos lenguajes de programacin por ah alguna vez han tenido una semntica formal ? Muy pocos de ellos . Creo que estas lenguas no son realmente utilizadas. Tiene C + + tiene una semntica formal ? De ninguna manera! Ni siquiera C tiene . A lo mejor tiene . JAVA ? Hay semntica formal con Java? De ninguna manera! As que hemos todava la gente utilice estas lenguas con xito. As que la crtica principal a UML es que no es lo suficientemente precisa. Bueno esa es una crtica que viene de la gente que nunca he usado ese lenguaje de modelado . Entonces la crtica proviene de los proveedores , que en realidad quieren desarrollar su propio lenguaje de modelado . Eso es muy natural tambin. Tiene que ver con su inters en que los clientes bloqueados en su solucin y no tanto sobre la lengua . Si hay un problema con el idioma , podan arreglarlo. Ahora hay una crtica relevante , y ese es el tamao de UML. UML 2.0 ha llegado a ser muy grande , se ha vuelto pesado , es muy difcil de aprender y estudiar. As que , qu hacer al respecto? Bueno, con el agente inteligente que lo arregles . Usted sabe que la derecha ? Los agentes inteligentes fijan mucho. Ahora , dicho esto no creo que estas son las balas de plata , pero en realidad le ayudan en la adopcin de las cosas, que no resuelven otros problemas pero ayudan a que adopte, que le ayudan a aprender , que le ayudarn a aplicar tecnologas.
12. UML parece estar convirtindose en un lenguaje de programacin. Es apropiado?

Qu opina al respecto? Es un poco demasiado pronto. Creo que necesitamos mejores plataformas para llegar all. Pero, qu tiene de bueno es que lo que realmente queda por hacer UML un lenguaje ejecutable es realmente muy poco. Pero cuanto antes te lo hacen un lenguaje ejecutable, tiene que ser apoyado en las plataformas. As que es demasiado pronto para hacerlo hoy porque me gustara ver a Microsoft e IBM estn de acuerdo en algo as. Pero si lo hicieron para que pudiramos tener una lengua ejecutable, lo bueno con UML es que en realidad se puede aadir que se aplicar, por lo que sera capaz de soportar muchos programas y estilos diferentes, por lo que podra tener perfiles de UML y diferente variantes de la misma y se puede escoger y elegir. Pero es demasiado pronto; necesitamos mejores plataformas que lo que tenemos hoy. As que estoy deseando que llegue cuando tenemos mejores plataformas.

13. Entonces, qu piensa usted acerca de la MDA?

MDA se basa en algo bsicamente hemos estado oyendo desde hace muchos aos , el desarrollo basado en modelos . Tengo un pequeo problema con llamarlo arquitectura basada en modelos , porque no es slo acerca de los arquitectos sino de todo lo que hacemos . Esa es una vieja idea , quiero decir que todos creemos que es bueno , creo que todos se pondrn de pie y decir que el desarrollo dirigido por modelos es bueno porque lo hacemos, lo hemos hecho en muchas disciplinas diferentes , no slo en el software . Se empieza por los dibujos , y se mueve de dibujos para otro tipo de dibujos , etc . Lo interesante de cmo OMG ha presentado , es que pasar de diferentes tipos de modelos y tienes transformaciones de estos modelos, y se pueden definir reglas para hacer estas transformaciones. Creo firmemente que podemos hacer eso . En realidad hemos adoptado parte de lo que ya, por lo que crea un modelo de anlisis , que es bsicamente un modelo en el que en realidad no importa ninguna otra cosa que no sea el problema , especificamos un problema de una manera formal y que en realidad hacemos ejecutable , lo hacemos utilizando slo Java, Java normal , y este modelo es entonces el comienzo para hacer un diseo , as que agregamos cosas como la persistencia o temas transversales , como se habla de ello en el mundo de aspecto, le sumamos la seguridad , aadimos todo tipo de monitoreo, y aadimos la distribucin y lo hacemos como los aspectos , por lo que no cambia realmente el ncleo , esta especificacin original implementado en Java , pero lo agregamos en forma de aspectos . Y eso hace que sea muy fcil . Es muy fcil para los clientes a hacer ; mantenemos el ncleo del problema agradable y comprensible y aadimos el material especfico. Yo creo en l y creo en ella porque creo que he visto que podemos hacerlo y que no son realmente todo el camino como OMG originalmente lo describi, pero si lo tomamos de una manera ms modesta que lo puedo hacer una parte hoy y podemos , por supuesto, ser capaz de hacer ms y ms en el futuro . Todos los grandes fabricantes estn haciendo, algn tipo de arquitectura moderna , un desarrollo moderno . Creo que la crtica contra esto viene de el mismo campamento que critica UML.
14. Qu es lo que ves sobre AOP es que va a ser tan comn como OOP?

En primer lugar hay una gran diferencia en lo que significa la adopcin de AOP y la programacin orientada a objetos . En realidad no me gusta hablar de ella como una tcnica de programacin , yo lo veo como una prctica de desarrollo de software, pero la gran diferencia es que usted realmente no necesita pensar de manera muy diferente que no es el nuevo cambio de paradigma. Usted puede pensar en trminos de objetos y la adicin de los aspectos a los objetos es slo un refinamiento de la tecnologa. En lugar de tratar con los objetos que participan en diferentes casos de uso o implementan muchas caractersticas diferentes , en realidad se mire estas cosas en el objeto, por lo que un caso de uso puede golpear varios objetos diferentes y puede seguir estos separadas unas de otras . Y a componer ellos a travs del mecanismo de aspecto. Esto no es una idea nueva , aspecto orientacin , ha habido soluciones similares a este problema sobre temas transversales y separacin de intereses , a 20 aos pasan . Mi primer artculo habla de un lenguaje muy similar a como lo hace cuando se habla de los aspectos orientacin fue escrito en 1986 y estoy bastante seguro de que esto se convertira en una tecnologa muy importante , pero cuando , esto depende de los proveedores. Estoy muy preocupado por la forma en la comunidad de programadores , la comunidad orientada a aspectos tratados , se trata de tecnologa demasiado, ya que el bajo nivel y tambin quiero mover esta tecnologa upstream ahora la gente habla de aspectos tan tempranas aspectos se estn trasladando a todas las disciplinas y lo hacen en las condiciones sobre la programacin , sobre los ejecutores , mientras que tiene que ser una tecnologa que soporta todo el ciclo de vida de desarrollo de software, desde los requisitos hasta el fondo de los ejecutables y cdigos comprobables.
15. Algunas palabras finales?

Las ltimas palabras seran mis palabras finales estndar. Realmente creo que hay una gran cantidad de tecnologa interesante. Los ltimos 30 a 35 aos que he estado trabajando con el software han sido muy emocionante, que se han movido muy lentamente, los componentes ya estaban all en 1970, los casos de uso y muchas de las tcnicas, UML estaba all, pero se ha movido lentamente . Pero nunca hemos estado tan lejos como estamos hoy, cuando se trata de las mejores prcticas y la adopcin de las mejores prcticas. Creo que los 30 aos que he estado trabajando con el software han sido muy emocionante, pero los prximos 35 aos ser an ms emocionante. Pero, dnde nos estamos moviendo con todo esto es hacer el mundo

ms humano. Hoy estamos muy centrados en la mquina y yo queremos pasar de un mundo centrado en la mquina a un mundo ms humano centrado.