Qu es una metodologa? por Edward V.

Berard La Agencia de objetos ltimamente, ha habido una serie de preguntas a lo largo de las lneas de: Qu mtodos (metodologas) estn siendo utilizados para esfuerzos de desarrollo orientado a objetos? Son los enfoques orientados a objetos de ingeniera de software sustancialmente diferente de la ms tradicional (por ejemplo, descomposicin) enfoques funcionales? Cmo se define "el mtodo / metodologa de eleccin?"

He pasado los ltimos doce aos investigando, enseanza, consultora en, y el uso de metodologas de ingeniera de software. Por ms que el ltimos siete aos, mi inters principal ha sido en el rea de ingeniera del software orientado a objetos. Por alguna razn, me siento obligado a hacer frente a las cuestiones que han aparecido en los ltimos tiempos en comp. objeto (;-)). OBSERVACIONES GENERALES Aunque el xito o el fracaso de muchos esfuerzos de ingeniera pueden ser atribuidos a la "suerte", "destino" o "destino", la ingeniera, por lo general, no se basa en estos elementos. Probablemente la idea ms importante detrs de la ingeniera es que uno puede sistemticamente y predecible llegar en soluciones pragmticas y rentables y oportunas a las del mundo real problemas. Suerte de hecho puede jugar un papel en la mayora de los esfuerzos de ingeniera, pero la mayora de los ingenieros les gustara pensar que tienen una cantidad significativa de control sobre el resultado de un esfuerzo de ingeniera. Las tcnicas de ingeniera ms valiosas son aquellas que: Se puede describir cuantitativamente , as como cualitativamente, Puede ser utilizado en varias ocasiones, cada vez que se obtengan resultados parecidos. Se puede ensear a los dems dentro de un plazo razonable. Puede ser aplicado por otros con un nivel razonable de xito. Lograr de manera significativa y consistente, mejores resultados que o bien otras tcnicas o un enfoque ad hoc. Son aplicables en un porcentaje relativamente alto de los casos.

Los ingenieros no son verdaderos magos. Si un buen ingeniero descubre lo que es al parecer, una mejor manera de hacer las cosas, l o ella tratan de decir otros acerca de su mtodo. Magos debe, por la naturaleza misma de sus negocios, a mantener sus tcnicas y llenas de misterio. Un buen ingeniero no es un "gur", un "asistente", o un "chamn". Un buen ingeniero puede ser

"talentoso", "dotado " o " intuitivo", pero en cualquier caso, un buen ingeniero puede comunicarse de manera simple y eficaz a los dems las tcnicas que l o ella utiliza para lograr una alta tasa de xito. Ingeniera difiere de la ciencia. Ingeniera utiliza la ciencia, matemticas, disciplinas de ingeniera (por ejemplo, anlisis de errores, gestin de la configuracin, la evaluacin de riesgos, y la reutilizacin) y excelentes habilidades de comunicacin para el desarrollo pragmtico y rentable, y soluciones oportunas a los problemas del mundo real. Un cientfico no es a menudo un ingeniero, sin embargo, un ingeniero debe tener una base slida en ciencia. LOS INICIOS DE METODOLOGAS DE INGENIERA DE SOFTWARE En 1962, Edsger Dijkstra hizo la observacin de que un pedazo de fuente cdigo era una serie de declaraciones esencialmente matemticos. Por lo tanto, se supuesto, uno debe ser capaz de tomar un programa arbitrario y "demostrar sea matemticamente correcta o incorrecta. " Sus intentos en este, sin embargo, no cumplieron con mucho xito. En 1965, Dijkstra y otros, eran conscientes de uno de los principales obstculos, es decir, el ahora infame declaracin "Ir a" (ms especficamente, un salto incondicional). ( Ver [ Dijkstra , 1965 ] , [ Knuth , 1974 ] , y [ Yourdon , 1975 ] . ) En 1968, Dijkstra estaba tan convencido de que el salto incondicional fue el problema, que public su muy citado (y satirizado) "Ir a Declaracin Considerado artculo Nocivo " ( [ Dijkstra , 1968a ] ) . Dijkstra preocupaciones, sin embargo, no se limitaron a "Ir a" declaraciones. Ms adelante en 1968, public los resultados de sus esfuerzos (con xito) en el desarrollo de un sistema operativo ([ Dijkstra , 1968b ] ) . Este trabajo es "debe leer ", y describe un enfoque de " capas de abstraccin ", que es muy usada hoy en da, que rara vez pensamos en l como siempre no estar cerca. En " Programacin Estructurada " ( [ Dijkstra , 1969 ] ) , Dijkstra no slo acu el trmino " programacin estructurada ", pero tambin hizo hincapi en la importancia de la prevencin de errores , en contraposicin a error cura. En este artculo, se plantea la pregunta: "La pregunta principal fue si era concebible para aumentar nuestra capacidad de programacin en un orden de magnitud y lo tcnicas (mental, organizativas o mecnicos) pueden ser aplicado en el proceso de composicin de programa para producir este aumentar. Esta pregunta an hoy nos ocupa, por ejemplo, ver [Brooks, 1987]. Para 1966, Bohm (con diresis sobre la ' o') y Jacopini tuvieron su artculo traducido al Ingls y publicado en las Comunicaciones de la ACM ( [ Bohm y Jacopini , 1966 ] ) . En 1967, el trmino "software ingeniera fue seleccionado "por una (ahora famoso) 1968 conferencia de la OTAN, cuyo

objetivo era, entre otras cosas, para ayudar a determinar exactamente lo que ingeniera de software " era y lo que implicaba. 1971 vio " Programa de Desarrollo de paso a paso de refinamiento " de Niklaus Wirth ( [ Wirth , 1,971 ] ) . Refinamiento paso a paso sistematiz el trabajo anterior de Dijkstra y Bohm y Jacopini . David L. Parnas public su artculo sobre " la ocultacin de informacin " ([ Parnas , 1972 ] ) el prximo ao . El diciembre 1973 cuestin de la Datamation se dedic al tema de la estructura de programacin, y contena un nmero de ejemplos de la exitosa aplicacin de la tcnica. Fue tambin durante la dcada de 1960 que las personas se dieron cuenta de que estructurada de programacin (en gran medida, " codificacin estructurada ), no era suficiente. Halan D. Mills enfoc sus esfuerzos en " la optimizacin de la programador " en el clsico " proyecto superprogrammer . "Los resultados de este trabajo se introduce en el proyecto de "New York Times" cita a menudo ( [ Baker y Mills, 1973 ] ) . Es importante comprender que estos grandes proyectos, y otros (por ejemplo, el esfuerzo Skylab), demostraron no slo programacin estructurada, pero tambin conceptos como el " jefe de equipo de programadores ", y las primeras versiones de " diseo estructurado . Larry Constantine (empleado de IBM durante los aos 1960 y 1970) se pregunt si haba algunos mecanismos confiables tanto para evitar malos diseos desde el principio, y el reconocimiento de las reas con problemas potenciales antes de que el software llegara a la etapa de produccin. Con Wayne Stevens y Glen Myers, desarroll " diseo compuesto ", que pas a llamarse ms tarde a " diseo estructurado. " (Ver [Stevens et al, 1974].) LA DCADA DE 1970 - Metodologas TODAS PARTES Por la dcada de 1970 a mediados y finales de la serie de la ingeniera de software metodologas en general, y el nmero de desarrollo de software metodologas, en particular, explotaron. Algunos ejemplos incluyen: Mtodos de descomposicin funcional , por ejemplo, estructurados Diseo y anlisis estructurado ( [ DeMarco , 1978 ] ) Data-Driven/Data-Structured enfoques , por ejemplo, [ Warnier , 1974 ] y [ Jackson, 1975 ] Enfoques formales (matemticas) , por ejemplo , el desarrollo de Viena Mtodo (VDM ) . Ver [Jones, 1980].

Probablemente el ms comnmente mencionado (no lo mismo que "usado") metodologas de software eran los llamados enfoques estructurados. Tom McCabe incluso introdujo lo que llam " la prueba estructurada. "

LA DCADA DE 1980 - Un vistazo ms cercano A comienzos de la dcada de 1980 haba tantas metodologas disposicin que acaba de hacer su seguimiento fue un esfuerzo de tiempo completo. No tiene habido un buen nmero de "encuestas metodologa" publicados, entre ellos: [ Birrell y Ould , 1985 ] [ Et blanco al, 1983 ] [ Doi, 1981 ] [ Freeman y Wasserman , 1982 ]

El Departamento de esfuerzo " Methodman " del de Defensa de EE.UU. trat de investigar 48 metodologas diferentes, y, al final, inform brevemente en 24 de ellos. La dcada de 1980 tambin fue la dcada que vio el aumento de la importancia de: Prototipos acerca. Vase, por ejemplo, [ Boehm , 1986 ] . Problemas en tiempo real. Vase, por ejemplo, [Ward y Mellor, 1985]. Computer Aided Software Engineering (CASE), para automatizar todo estas ideas "maravillosas. METODOLOGAS orientada a objetos Incluso si usted no hace caso de las races ms antiguas de software orientado a objetos ingeniera (es decir, los primeros trabajos en Inteligencia Artificial ( AI) ) , todava se puede decir que las tcnicas orientadas a objetos han existido desde A finales de 1960 (la mayora de la gente cita la obra de Dahl y Nygaard en Simula ) . Sin embargo, hasta la dcada de 1980, gran parte del trabajo en arena orientada a objetos se centr en " orientada a programacin objetos. " Mientras que, por un lado, una buena dosis de " programacin orientada a objetos " es realmente " codificacin orientada a objetos, " tenemos que ser honestos y sealar la siguiente: Metodologas son muy importantes si usted tiene muchos " pequeos " pasos para llevar a cabo, y muchos "pequeos" elementos con los que tratar. Objetos (y clases) son tpicamente en niveles ms altos de abstraccin que son "meros datos y funciones. " Por lo tanto, (semi -) metodologas rigurosas no son tan necesaria "pequeo" , orientado a objetos no crtica , aplicaciones , ya que sera en aplicaciones similares desarrollado utilizando herramientas y enfoques ms tradicionales. A pesar de que el foco de muchos debates orientados a objetos y los papeles tienden a ser altamente especfico del lenguaje de programacin , muchos de los conceptos tratados (por ejemplo , la herencia , los datos la abstraccin , la delegacin, la reutilizacin y la reflexin) tienen implicaciones que van mucho ms all de los bajos niveles de abstraccin y programas sencillos.

Hasta que la bastante reciente (en la dcada de 1980) explosiva inters en las cosas orientado a objetos, orientada a objetos enfoques rara vez se utilizan para grandes o crtica aplicaciones. (Ntese que he dicho no "eran nunca utilizado . ) Por lo tanto, la necesidad / demanda de bien formulado metodologas orientadas a objetos fue muy bajo hasta hace muy recientemente.

Las cosas son diferentes ahora. La demanda de enfoques orientados a objetos es asombrosa. Las "promesas " de la tecnologa orientada a objetos estn siendo escuchado en lugares donde las metodologas son la norma. Adems, es perfectamente normal que alguien diga: "Yo quiero hacer orientado a objetos ingeniera de software. Cmo lo hago , y lo ms importante , cmo s que lo he hecho bien?" ACERCAMIENTO DE METODOLOGAS orientada a objetos Imagina un "campo de juego " con el software orientado a objetos bien definidos de ingeniera en el medio. Vemos dos equipos se acercan a la media, desde dos direcciones diferentes: Uno de los equipos es la " multitud de programacin orientado a objetos ", es decir, usuarios de programacin idiomas / sistemas tales como Smalltalk, C + +, Eiffel, CLOS, y el Yo. Los jugadores en este equipo, a pesar de sus diferencias internas, tienen muy pocos problemas la identificacin de objetos y clases. Sin embargo, cuando se le pregunt sobre enfoques bien definidos a cosas como " orientado a objetos diseo ", que tienden o bien decir cosas como " Yo s cmo hacerlo, pero no estoy seguro de que puedo decirle, "o" eh? El otro equipo se parece mucho a Anbal cruzando la Alpes. Ellos traen una gran cantidad de "equipaje " intil con ellos. Lo has adivinado, son la " multitud estructurada ", y su "bagaje intil " se compone de cosas como de flujo de datos diagramas, diagramas de estructura, diagramas entidad relacin, y bases de datos relacionales. Cuando se le pregunt por qu quieren utilizar estos elementos para la ingeniera de software orientado a objetos, que respondemos con respuestas como: "Sabemos cmo utilizar estos, y nosotros no saben cmo resolver los problemas sin ellos. "o" Hey, hombre! Nos hundimos un montn de dinero en herramientas CASE que apoyar estas cosas, y lo que tenemos que utilizar " em.

Debera ser obvio para un observador casual, que lo que estos dos equipos necesitan hacer es cooperar. Desafortunadamente, hay muy poco de eso pasando.

METODOLOGAS Orientada a Objetos - Qu est disponible? Desde mi punto de vista, los que estn en busca de bien definido, " probadas metodologas orientadas a objetos tienen tres opciones: 1. Los inicios de metodologas orientadas a objetos dentro de la comunidad de programacin orientada a objetos. (Vase, por ejemplo, algunos de los trabajos presentados durante el " software ingeniera " sesiones en el ms reciente OOPSLA.) Estos encontrado ms como "tiles sugerencias" que lo hacen metodologas. Parecen ser pesado en acoplamiento objeto, y ms bien cobarde cuando se trata de cualquiera de "tiempo real " o " desarrollo orientado a objetos en el grande" ( OODIL ) . 2. Las ofrendas de la " multitud estructurado recin convertidos - . " Usted puede obtener la impresin de que estas personas utilizan orientada a objetos la terminologa de una manera muy extraa, y a veces de forma inadecuada. Esto puede, a su vez, har cuestionar la idoneidad del material. 3. La ltima opcin es buscar a las personas que han estado trabajando con metodologas orientadas a objetos para un nmero de aos, por ejemplo, la gente como Grady Booch. Estas personas se renen dos criterios. En primer lugar, han estado trabajando con La tecnologa orientada a objetos para un nmero de aos. En segundo lugar, que han sido acercan desde una metodologa punto de vista, no es un punto de vista programtico. En cualquier caso, existen metodologas orientadas a objetos probados. Por desgracia, son pocos y distantes entre s. Este mensaje ya es demasiado largo. Son las 3:30 de la maana. Estoy superar. Si quieres que te presente un breve debate sobre orientacin a objetos diseo o anlisis de requisitos orientado a objetos, que me haga saber. Gracias por escuchar.