Ivar Jacobson en UML, MDA, y el futuro de las metodologías

1. Ivar tú eres una leyenda, tú has estado trabajando en cosas durante tantos años,

¿qué vas a hacer hoy?

Hoy mi objetivo sigue siendo en la mejora de las mejores prácticas de desarrollo de software. Y

estoy trabajando en lo que yo llamaría proceso de desarrollo de software de última generación,

y también estoy trabajando con orientación aspecto de desarrollo de software que sería

probablemente dos de las cosas más importantes. Tengo una serie de cosas de menor

importancia que los que trabajo.

2. ¿Cuáles 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 artículos sobre cosas como un rotundo " sí" a los procesos ágiles. Pero también a la próxima gran cosa, que es el título 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 más importante que la documentación , por lo que no es el punto . La verdadera diferencia es que cuando se habla de los métodos de algunos realmente clasifican a sí mismos como los métodos ágiles y otros no hagan eso , pero en realidad hay todo un espectro , hay procesos básicos unificados que he estado trabajando durante tantos años y ágiles versiones de procesos unificados . Y en realidad no creo que debe haber algo más que las versiones ágiles de procesos unificados para ser franco . Y lo mismo con los métodos ágiles , algunos métodos ágiles son más como tradicional en proceso también. Y eso es todo el espectro. Pero si hablamos de la diferencia fundamental real entre los diferentes métodos de hoy damos los métodos á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 están 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 métodos ágiles que se basan principalmente en el conocimiento tácito . ¿No es un mundo maravilloso ser capaz de confiar en el conocimiento tácito ? Lo que usted tiene en la cabeza es útil . El otro enfoque se basó en el conocimiento explícito , sobre todo , no sólo porque no hay nadie que sólo pueden confiar en el conocimiento explícito y el conocimiento explícito 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 cómo 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 métodos ágiles buenas ideas, como primera prueba de diseño y cosas por el estilo , o el desarrollo basado en pruebas , que toman prestado de nosotros como historias de usuario y otras ideas también. Y así es como debe ser. La diferencia fundamental es exactamente eso : si confiar en el conocimiento tácito o de confiar en el conocimiento explícito

.

3. ¿Cuál es la diferencia fundamental entre el conocimiento tácito y explícito? Un método que se basa en el conocimiento tácito , ¿cómo te enseñó eso? ¿Cómo sabes lo que es , ya que sólo está en la cabeza de la gente? ¿Cómo , si pones a un equipo que todos vienen con el conocimiento tácito , ¿cómo 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 , ¿cómo es posible crecer ese conocimiento? ¿Cómo 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 métodos que se basan en el conocimiento tácito . 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 montón 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 fácil. 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 tamaño no ser ágil. Y como he dicho durante muchos años nunca he creído que un proceso unificado o proceso unificado racional como tal, sería 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 años, cuando yo creía que un máximo del 10-15% de la población jamás adoptarlo (y eso no suena bien ¿no?) , Pero sabía 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 explícito , hay un futuro . Si no se basó en el conocimiento explícito , pero el conocimiento tácito no puedo ver cómo puede evolucionar eso. ¿Cuáles serán los métodos ágiles verá en diez años? Quiero decir , ¿cómo hacer crecer estos métodos por lo que realmente se mueven para producir un software mejor , más rápido y con mayor calidad y con más diversión ?

4. Usted dijo que un proceso como el unificado nunca puede ser adoptado por más de

10% de la población desarrollador. ¿Por qué? La razón es que la inversión que se necesita para aprender un proceso unificado como lo es hoy , es un poco , los equipos pequeños altos , pequeñas campañas se encuentran demasiado caro para invertir en ese tipo de formación, y las herramientas y así sucesivamente. Así que no lo hacen . Las empresas más 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 más grandes pueden hacerlo, pero los equipos más pequeños 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 métodos á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 algún tiempo . Si vas a entrenar, porque el entrenamiento en el mismo, se necesita tiempo para ir a través 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. ¿Cuál será el proceso de próxima generación? Creo firmemente que el proceso de próxima generación será lo que yo llamo un proceso inteligente e inteligente es básicamente ágil + + + , que significa que tiene las propiedades de la agilidad , pero en realidad también ayudará a utilizar el conocimiento. Imaginemos que , de alguna manera mágica , podríamos enseñar a la gente y aprender de personas para enseñar proceso unificado , para aplicar proceso unificado , para su control , etc Podríamos enseñarles a hacer eso. Y sólo la parte del proceso unificado que realmente necesita y sólo cuando lo necesite justo en el InContext derecho cuando necesita que significa pequeños fragmentos de conocimiento , procedentes cuando lo necesita y no antes. Imagínese que usted puede conseguir esto, ¿ entonces importa el tamaño de un proceso? ¿Importa si un proceso es de 50.000 páginas, 100.000 páginas, un millón de páginas 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 tamaño, cuanto más grande mejor , no como solemos decir ahora hoy en día con los métodos á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 tecnología para hacer que eso significa agentes inteligentes o tecnología similar. Los agentes inteligentes son como en cualquier papel que usted juega , usted no sólo tener un programador de par , la pareja es en realidad el agente , usted tiene un par analista , diseñador 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 , básicamente, un mentor virtual esperando por ti, para estar listo para ayudarle en cualquier momento . Y hay evidencia científica de que una pareja de un mentor humana combinada con un mentor virtual es mucho más eficaz que sólo mentores humanos , entrenadores humanos. Hay un montón de evidencia científica , 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 / reproducción algún 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 más , sino que tiene, está impulsada no sólo por el código de procedimiento , pero en realidad por las reglas . Estas reglas han formulado explícitamente objetivos. Por ejemplo , el objetivo podría ser la producción de un componente, éste no debe ser sólo un componente, pero es un buen componente. Y luego están las reglas de cómo 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 años , 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 monolíticos y usados y son difíciles 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 también, y algunas técnicas para hacer eso .

7. ¿Puede describir lo que esto podría ser como en un proyecto? Usted tiene, digamos,

un proyecto de 30 hombres están construyendo un sitio de comercio electrónico en

línea, dónde los agentes encajan, ¿cuál podría ser similar en el tiempo?

Los agentes están 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 después de que el agente conocerá que es una buena utilización de los casos es. Y hemos programado esta agentes para hacer lo que creemos que son buenas formas de hacer los casos de uso. Podría ser, si usted piensa que una buena manera de hacer un buen uso de los casos es hacer una historia de usuario, una versión muy ligera de casos de uso, usted puede hacer eso. Si es una buena manera de escribir un caso de uso más preciso con condición previa, post-condición y definir todas las cosas diferentes que luego se convertirán en los casos de prueba, entonces se hace eso. Porque, básicamente, casos de uso son los casos de prueba, por lo que es un montón de reglas de cómo hacer buenos casos de prueba. Así que tendrás que para básicamente todos los papeles que desempeñamos en el desarrollo de software siguiendo luego las mejores prácticas de lo que creemos que es bueno las mejores prácticas.

8. ¿Qué pasa con la programación en parejas, sin duda la interacción humana es más

eficiente que la interacción hombre-máquina? Hay pruebas científicas de que en algunos casos los seres humanos en realidad no lo hacen tan buen trabajo, sólo , pero en realidad si se trabaja con algunos mentores virtuales en lugar de mentores humanos se obtiene un resultado mucho más productivo. Les puedo decir por experiencia propia que si utiliza los entrenadores para ayudar a la gente a adoptar cualquier tipo de metodología, 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 cómo 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 día y noche para trabajar. En cambio, los mentores humanos están haciendo cosas más avanzadas , como la " gestión del cambio " , ¿cómo cambiar la organización, ¿cómo hacer que la gente y adoptar los principios de desarrollo de software y así sucesivamente. Eso es mucho más cualificado , que es nuestra propia experiencia. Así que cuando entramos y trabajamos con un equipo, en vez tenemos menos mentores humanos en una organización y en su lugar todo el mundo tiene un mentor

virtual, y se obtiene un mejor resultado y es mucho más rentable para la empresa. La otra cosa es que, si nos fijamos en él , existen resultados científicos , creo que en la Universidad de Penn State , que, efectivamente, han medido y estudiado lo que sucede en un sistema de control de mando , ¿cómo reaccionan los usuarios cuando se encuentran en una situación de lucha , y el resultado fue que los seres humanos , cuando están en una situación normal , sin estrés, trabajan muy bien juntos , no es un problema real, pero en cuanto se meten en situaciones de estrés , 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 programación en parejas , si eso es transmitir el conocimiento de un experto a un chico nuevo menos expertos , es básicamente una forma muy cara de hacerlo, porque podemos hablar de boca en boca, en la que si usted tiene un experto que debería 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 también es muy aburrido con este tipo de enseñar 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 excluiría a tener algún tipo de apoyo en cuanto a la programación en parejas pero es probablemente más 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 también 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 mayoría 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 sabía mucho acerca de la gestión del proyecto , que era jefe de proyecto , pero yo no sabía mucho acerca de las reglas para hacer eso , así que nunca pensé en pasar un montón de energía en la formalización de la materia proceso aburrido , lo que todos los desarrolladores piensan que es aburrido y el odio. Me concentré sólo en una cosa, que yo realmente quería hacer : ¿cómo hacer cosas buenas , buenas , buenas interfaces de componentes , buenas operaciones, cualesquiera que sean buenos atributos , buen código , 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 gestión 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 estás 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 más impulsado por los administradores? En realidad no, yo no hago eso . Creo que es una percepción y que un proceso unificado , básicamente, 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 gestión 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 técnica está impulsado por los expertos, los técnicos , por lo que no veo ninguna diferencia con la programación extrema en ese sentido . Hay una percepción de que ahora vamos yo dije eso. Una de las cosas que no he visto en muchos años, pero estamos de vuelta en la actualidad , es que hay tanta religión acerca de la metodología , y durante los primeros años 90 , cuando tuvimos todos estos diferentes métodos sobre cómo hacer desarrollo orientado a objetos de software, usted sabe que había un Grady Booch , Rumbaugh , yo tenía mi libro , había diez de nosotros , que ha silenciado por completo desde hace muchos años , 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 están realmente basados en hechos. Trato de permanecer fuera de estas discusiones y centrarse en la discusión de lo que realmente creo que puedo medir o tener pruebas para .

11. Así que apelaría 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 años 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 montón de adopción. Básicamente, cada metodología en ese momento dio su propia notación y de hecho trabajó duro con ellos para asegurarse de que podían usar UML para sustituir a nuestra propia notación y nuestro propio idioma. En ese campamento había otro competidor que era muy grave y que era STL , STL es el predecesor de UML que se convirtió en el estándar 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 , básicamente , que se convirtió en un estándar. Lo que hicimos , sabíamos que hemos desarrollado un nuevo tipo de lenguaje, porque normalmente estas lenguas se desarrollan sin tener una semántica detallados subyacentes; razón 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. Podrían haber muchas otras semánticas subyacentes y usted no quiere que eso se reflejará en el lenguaje de modelado . Pero UML ganó ese voto también, 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 ¿cuál es la crítica contra UML ? ¿De dónde 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 semántica formal de los lenguajes formales . Bueno, yo lo he hecho a mí mismo también, hice mi doctorado en lenguaje formal de la semántica formal , y cuando lo hicimos la STL solíamos semántica formal que en realidad utilizó método de desarrollo de Viena para especificar tanto la sintaxis , la sintaxis abstracta , la sintaxis concreta , la semántica estática, la semántica dinámica 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 semántica matemáticos formales . Pero tuvimos sintaxis abstracta , tuvimos semántica estática de una manera formal. Ahora sigues y te ves en la programación. ¿Cuántos lenguajes de programación por ahí alguna vez han tenido una semántica formal ? Muy pocos de ellos . Creo que estas lenguas no son realmente utilizadas. ¿Tiene C + + tiene una semántica formal ? De ninguna manera! Ni siquiera C tiene . A lo mejor tiene . JAVA ? ¿Hay semántica formal con Java? De ninguna manera! Así que hemos todavía la gente utilice estas lenguas con éxito. Así que la crítica principal a UML es que no es lo suficientemente precisa. Bueno esa es una crítica que viene de la gente que nunca he usado ese lenguaje de modelado . Entonces la crítica proviene de los proveedores , que en realidad quieren desarrollar su propio lenguaje de modelado . Eso es muy natural también. Tiene que ver con su interés en que los clientes bloqueados en su solución y no tanto sobre la lengua . Si hay un problema con el idioma , podían arreglarlo. Ahora hay una crítica relevante , y ese es el tamaño de UML. UML 2.0 ha llegado a ser muy grande , se ha vuelto pesado , es muy difícil 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 adopción de las cosas, que no resuelven otros problemas pero ayudan a que adopte, que le ayudan a aprender , que le ayudarán a aplicar tecnologías.

12. UML parece estar convirtiéndose en un lenguaje de programación. ¿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 gustaría ver a Microsoft e IBM están de acuerdo en algo así. Pero si lo hicieron para que pudiéramos tener una lengua ejecutable, lo bueno con UML es que en realidad se puede añadir que se aplicará, por lo que sería capaz de soportar muchos programas y estilos diferentes, por lo que podría 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 básicamente hemos estado oyendo desde hace muchos años , el desarrollo basado en modelos . Tengo un pequeño problema con llamarlo arquitectura basada en modelos , porque no es sólo 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 pondrán de pie y decir que el desarrollo dirigido por modelos es bueno porque lo hacemos, lo hemos hecho en muchas disciplinas diferentes , no sólo en el software . Se empieza por los dibujos , y se mueve de dibujos para otro tipo de dibujos , etc . Lo interesante de cómo 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 análisis , que es básicamente 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 sólo Java, Java normal , y este modelo es entonces el comienzo para hacer un diseño , así que agregamos cosas como la persistencia o temas transversales , como se habla de ello en el mundo de aspecto, le sumamos la seguridad , añadimos todo tipo de monitoreo, y añadimos la distribución y lo hacemos como los aspectos , por lo que no cambia realmente el núcleo , esta especificación original implementado en Java , pero lo agregamos en forma de aspectos . Y eso hace que sea muy fácil . Es muy fácil para los clientes a hacer ; mantenemos el núcleo del problema agradable y comprensible y añadimos el material específico. 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 más modesta que lo puedo hacer una parte hoy y podemos , por supuesto, ser capaz de hacer más y más en el futuro . Todos los grandes fabricantes están haciendo, algún tipo de arquitectura moderna , un desarrollo moderno . Creo que la crítica contra esto viene de el mismo campamento que critica UML.

14. ¿Qué es lo que ves sobre AOP es que va a ser tan común como OOP? En primer lugar hay una gran diferencia en lo que significa la adopción de AOP y la programación orientada a objetos . En realidad no me gusta hablar de ella como una técnica de programación , yo lo veo como una práctica 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 términos de objetos y la adición de los aspectos a los objetos es sólo un refinamiento de la tecnología. En lugar de tratar con los objetos que participan en diferentes casos de uso o implementan muchas características 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 través del mecanismo de aspecto. Esto no es una idea nueva , aspecto orientación , ha habido soluciones similares a este problema sobre temas transversales y separación de intereses , a 20 años pasan . Mi primer artículo habla de un lenguaje muy similar a como lo hace cuando se habla de los aspectos orientación fue escrito en 1986 y estoy bastante seguro de que esto se convertiría en una tecnología 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 tecnología demasiado, ya que el bajo nivel y también quiero mover esta tecnología upstream ahora la gente habla de aspectos tan tempranas aspectos se están trasladando a todas las disciplinas y lo hacen en las condiciones sobre la programación , sobre los ejecutores , mientras que tiene que ser una tecnología que soporta todo el ciclo de vida de desarrollo de software, desde los requisitos hasta el fondo de los ejecutables y códigos comprobables.

15. Algunas palabras finales? Las últimas palabras serían mis palabras finales estándar. Realmente creo que hay una gran

cantidad de tecnología interesante. Los últimos 30 a 35 años 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 técnicas, UML estaba allí, pero se ha

movido lentamente . Pero nunca hemos estado tan lejos como estamos hoy, cuando se trata de

las mejores prácticas y la adopción de las mejores prácticas. Creo que los 30 años que he

estado trabajando con el software han sido muy emocionante, pero los próximos 35 años será

aún más emocionante. Pero, ¿dónde nos estamos moviendo con todo esto es hacer el mundo

más humano. Hoy estamos muy centrados en la máquina y yo queremos pasar de un mundo

centrado en la máquina a un mundo más humano centrado.