Ingeniería de software asistida por computadora

Ir a: navegación, búsqueda de
Ejemplo de una herramienta CASE.

Ingeniería de software asistida por computadora (CASO) es el dominio de herramientas de software utilizado para diseñar e implementar aplicaciones. Herramientas CASE son similares a y fueron inspirados en parte por Diseño asistido por computadora Herramientas (CAD) para diseño de productos de hardware. Herramientas CASE se utilizan para desarrollar software de alta calidad, libre de defectos y mantenible.[1] A menudo se asocia con metodologías para el desarrollo de software caso sistemas de información junto con automatizado de herramientas que pueden utilizarse en la proceso de desarrollo de software.[2]

Contenido

  • 1 Historia
  • 2 CASO software
    • 2.1 Herramientas
    • 2.2 Bancos de trabajo
    • 2.3 Entornos
  • 3 CASO los principales factores de riesgo
  • 4 Véase también
  • 5 Referencias

Historia

El proyecto de diseño de sistemas de información y optimización de sistema (ISDOS), comenzado en 1968 en la Universidad de Michigan, inició un gran interés en el concepto de la utilización de sistemas informáticos para ayudar a los analistas en el difícil proceso de análisis de requerimientos y desarrollo de sistemas. Varios papeles por Daniel Teichroew despidieron a toda una generación de entusiastas con el potencial de desarrollo de sistemas automatizados. Su lenguaje de la declaración de problema / herramienta problema declaración Analyzer (PSL/PSA) fue una herramienta CASE aunque lo precedió el término.[3]

Otro subproceso principal surgió como una extensión lógica de la Diccionario de datos de un base de datos. Ampliando la gama de metadatos sostenido, los atributos de una aplicación podrían celebrados dentro de un diccionario y utilizarse en tiempo de ejecución. Este diccionario"activo" se convirtió en el precursor de los más modernos Ingeniería basado en modelos capacidad. Sin embargo, el diccionario activo no proporcionó una representación gráfica de cualquiera de los metadatos. Fue la vinculación del concepto de un diccionario con metadatos de los analistas, como derivados de la utilización de un conjunto integrado de técnicas, junto con la representación gráfica de los datos que dieron origen a las versiones anteriores del caso.[4]

El término fue acuñado originalmente por la empresa de software Nastec Corporation de Southfield, Michigan en 1982, con su originales gráficos y texto editor integrado GraphiText, que también fue el primer sistema basado en microprocesador utilizar hipervínculos para cotejar las cadenas de texto en documentos — un precursor temprano de enlace de la página web de hoy. Producto de sucesor de GraphiText, DesignAid, fue la primera herramienta lógica y semánticamente evaluar los diagramas de diseño de software y sistema y construir un diccionario de datos basados en microprocesadores.

Bajo la dirección de Albert F. Case, Jr. Vicepresidente de gestión de productos y consultoría y Vaughn Frick, director de gestión de producto, la suite de productos de DesignAid se amplió para apoyar el análisis de una amplia gama de metodologías de análisis y diseño estructuradas, los de incluidos Ed Yourdon y Tom DeMarco, Chris Gane & Trish Sarson, Ward-Mellor SA/SD (tiempo real) y Warnier-Orr (datos).[5]

El siguiente participante en el mercado fue Excelerator de índice Technology en Cambridge, Massachusetts. Mientras que DesignAid funcionó en tecnologías convergentes y más tarde Burroughs Ngen microordenadores conectados en red, índice lanzó Excelerator en el IBM PC / AT plataforma. Mientras, en el momento del lanzamiento y desde hace varios años, la plataforma IBM no apoyó las redes o una base de datos centralizada como lo hizo la tecnologías convergentes o Burroughs máquinas, el encanto de IBM era fuerte y Excelerator vino a la prominencia. Caliente en los talones de Excelerator fueron una serie de ofertas de empresas como Knowledgeware (James Martin, Fran Tarkenton y Don Addington) de Texas Instrument IEF y Andersen Consulting Fundación toolset (diseño/1, instalación/1, FCP).

Herramientas CASE estaban en su apogeo en la década de 1990.[6] En el momento IBM había propuesto AD/ciclo, que era una alianza de proveedores de software de IBM de centrar Repositorio de software usando IBM DB2 en mainframe y OS/2:

Las herramientas de desarrollo de aplicación pueden ser de varias fuentes: de IBM, de proveedores y de los propios clientes. IBM ha entrado en relaciones con Bachman información sistemas, índice Technology Corporation y en el cual se comercializarán productos seleccionados de estos proveedores a través de un programa de marketing complementario de IBM para ofrecer las ofrendas que le ayudará a lograr una cobertura completa el ciclo de vida Knowledgeware, Inc.. [7]

Con la caída de la unidad central, AD/ciclo y el caso herramientas se extinguió, abriendo el mercado de las principales herramientas CASE de hoy. Muchos de los líderes del mercado caso de principios de los noventa terminaron siendo adquirido por Computer Associates, incluyendo IEW, IEF, ADW, Cayena y Learmonth & Burchett Management Systems (LBMS). La otra tendencia que condujo a la evolución de herramientas CASE fue el surgimiento de métodos orientados a objetos y herramientas. La mayoría de los proveedores de herramientas diversas había añadido algún apoyo para herramientas y métodos orientados a objetos. Además nuevos productos que fueron diseñados surgieron desde el fondo hasta ayuda el enfoque orientado a objetos. Andersen desarrolló su proyecto águila como una alternativa a la Fundación. Varios de los líderes en desarrollo orientado a objetos cada uno desarrollaron su propia metodología y caso sistema de herramienta: Jacobsen, Rumbaugh, Booch, etc.. Eventualmente, estos conjuntos de diversas herramientas y métodos se consolidaron mediante normas lideradas por el Object Management Group (OMG). El OMG Lenguaje de modelado unificado de (UML) es actualmente ampliamente aceptado como el estándar para la industria de modelado orientado a objetos.

CASO software

Alfonso Fuggetta clasificados caso software en 3 categorías:[8]

  1. Herramientas apoyar tareas específicas en la ciclo de vida de software.
  2. Bancos de trabajo se combinan dos o más herramientas enfocadas en una parte específica del software-ciclo de vida.
  3. Entornos combinar dos o más herramientas o bancos de trabajo y soporte del ciclo de vida completo software.

Herramientas

Herramientas CASE apoya tareas específicas en el ciclo de vida de desarrollo de software. Se pueden dividir en las siguientes categorías:

  1. Negocios y el modelado de análisis. Herramientas de modelado gráfico. Por ejemplo, modelado E/R, modelado de objetos, etc.
  2. Desarrollo. Fases de diseño y construcción del ciclo de vida. Entornos de depuración. Por ejemplo, GNU Debugger.
  3. Verificación y validación. Analizar el código y las especificaciones para corrección, rendimiento, etc..
  4. Gestión de la configuración. Control el check-in y check-out de archivos y objetos del repositorio. Por ejemplo, SCCS, CMS.
  5. Medición y métricas. Analizar código de complejidad, modularidad (por ejemplo, no "de"), rendimiento, etc..
  6. Gestión de proyectos. Gestión de planes de proyectos, asignaciones de tareas, programación.

Otra forma común de distinguir Herramientas CASE es la distinción entre mayúsculas y minúsculas. MAYÚSCULAS herramientas apoyo empresarial y análisis de modelización. Apoyan lenguajes diagramáticas tradicionales tales como Diagramas ER, Diagrama de flujo de datos, Cartas de estructura, Árboles de decisión, Tablas de decisión, etc.. Herramientas minúsculas apoyar actividades de desarrollo, tales como diseño físico, depuración, construcción, pruebas, integración del componente, mantenimiento e ingeniería inversa. Todas las demás actividades abarcan todo el ciclo de vida y aplicarán igualmente a mayúsculas y minúsculas.[9]

Bancos de trabajo

Bancos de trabajo integran dos o más herramientas CASE y apoyan las actividades de proceso de software específicas. Por lo tanto logran:

  • una interfaz homogénea y coherente (integración de presentación).
  • integración de herramientas y herramienta cadenas (integración de datos y control).

Un banco de trabajo de ejemplo es de Microsoft Visual Basic entorno de programación. Incorpora varias herramientas de desarrollo: una GUI builder, editor de código inteligente, depurador, etcétera. CASO los productos más comerciales tendieron a ser esos bancos que integran dos o más herramientas. Bancos de trabajo también se pueden clasificar de la misma manera como herramientas; centrándose en análisis, desarrollo, verificación, etc. así como estar centrado en mayúsculas, minúsculas o procesos como la gestión de la configuración que abarcan todo el ciclo de vida completo.

Entornos

Un ambiente es una colección de herramientas CASE o mesas de trabajo que intenta apoyar el proceso de software completo. Esto contrasta con las herramientas que se centran en una tarea específica o una parte específica del ciclo de vida. CASOS ambientes se clasifican por Fuggetta como sigue:[8]

  1. Kits de herramientas. Colecciones libremente acopladas de herramientas. Estos suelen construcción sobre sistema operativo bancos como banco de trabajo del programador Unix o establecer la VAX VMS. Normalmente realizan integración a través de tuberías o algún otro mecanismo básico para compartir datos y pasar el control. La fuerza de la integración es también uno de los inconvenientes. Simple paso de parámetros mediante tecnologías como shell scripting no puede proporcionar el tipo de integración sofisticada que una base de datos del repositorio común.
  2. Cuarta generación. Estos ambientes son también conocidos como pie de 4GL para entornos de lenguaje de cuarta generación debido al hecho de que los ambientes tempranos fueron diseñados alrededor de determinados lenguajes como Visual Basic. Eran los ambientes primeros para proporcionar una integración profunda de múltiples herramientas. Normalmente estos ambientes se centraron en tipos específicos de aplicaciones. Por ejemplo, interfaz de usuario impulsada por aplicaciones que hizo transacciones atómicas estándar a una base de datos relacional. Los ejemplos son Informix 4GL y el enfoque.
  3. Centrada en el lenguaje. Entornos basados en una sola lengua a menudo orientada a objetos, tales como el medio ambiente Symbolics Lisp géneros o VisualWorks Smalltalk de Parcplace. En estos ambientes todos los recursos del sistema operativo eran objetos en el lenguaje orientado a objetos. Esto brinda oportunidades potente gráficas y depuración, pero el código desarrollado se limita principalmente a la lengua específica. Por esta razón, estos ambientes fueron principalmente un nicho dentro de caso. Su uso era principalmente para prototipos y proyectos i+d. Fue una idea de núcleo común para estos entornos el Model-view-controller interfaz de usuario que facilita mantener múltiples presentaciones del mismo diseño coherente con el modelo subyacente. La arquitectura MVC fue adoptada por los otros tipos de entornos de caso, así como muchas de las aplicaciones que se construyeron con ellos.
  4. Integrado. Estos ambientes son un ejemplo de lo que la mayoría es gente tiende a pensar de primera cuando piensan en caso. Ambientes tales como AD/ciclo IBM, Fundación de Andersen Consulting, el ICL CADES sistema y cohesión DEC. Trate de estos entornos cubrir el ciclo de vida completo de análisis para el mantenimiento y proporciona un repositorio de base de datos integrada para almacenar todos los artefactos del proceso de software. El repositorio de software integrado fue la característica definitoria de este tipo de herramientas. Proporcionaron múltiples modelos de diseño diferentes, así como apoyo para el código en idiomas heterogéneos. Uno de los objetivos principales de estos tipos de ambientes fue "Ingeniería de ida y vuelta": ser capaz de realizar cambios en el nivel de diseño y tener esos auotmatically se refleja en el código y viceversa. Estos ambientes también fueron típicamente asociados con una metodología particular para el desarrollo de software. Por ejemplo, la suite de la caja de cimentación de Andersen fue ligada a la metodología de Andersen método/1.
  5. Centrada en el proceso. Este es el tipo más ambicioso de la integración. Trate de estos ambientes no sólo formalmente especificar los objetos de análisis y diseño del proceso de software, pero el proceso real de sí mismo y de utilizar ese proceso formal para controlar y guiar los proyectos de software. Los ejemplos son Oriente, empresa II, sabio proceso, proceso de Weaver y Arcadia. Estos ambientes eran por definición vinculada a alguna metodología desde el propio proceso de software es parte del medio ambiente y puede controlar muchos aspectos de la invocación de la herramienta.

En la práctica, la distinción entre bastidores y ambientes era flexible. Por ejemplo, Visual Basic era un banco de trabajo programación pero también fue considerado un entorno 4GL por muchos. Las características que distinguía a los bancos de trabajo de ambientes eran integración profunda a través de un repositorio compartido o lenguaje común y una especie de metodología (entornos integrados y centrada en el proceso) o especificidad de dominio (4GL).[8]

CASO los principales factores de riesgo

Algunos de los factores de riesgo más importantes para las organizaciones adoptando tecnología caso incluyen:

  • Normalización inadecuada. Las organizaciones generalmente tienen que adaptar y adoptar metodologías y herramientas para sus requerimientos específicos. Hacerlo puede requerir un esfuerzo significativo para integrar tecnologías divergentes tanto como métodos divergentes. Por ejemplo, antes de la adopción del estándar UML el diagrama convenciones y métodos para el diseño de modelos orientados a objetos eran muy diferentes entre los seguidores de Jacobsen, Booch, Rumbaugh, etc..
  • Expectativas poco realistas. Los autores del caso tecnología--especialmente los proveedores de conjuntos de herramientas costosas--a menudo bombo las expectativas que el nuevo enfoque será una bala de plata que resuelve todos los problemas de comercialización. En realidad no hay tal tecnología puede hacer eso y si organizaciones abordar caso con expectativas poco realistas inevitablemente estarán decepcionados.
  • Inadecuada capacitación. Como con cualquier nueva tecnología, caso requiere tiempo para entrenar a la gente sobre cómo utilizar las herramientas y a ponerse al día con ellos. CASOS proyectos pueden fallar si los practicantes son no dado suficiente tiempo para el entrenamiento o si es el primer proyecto de tratado con la nueva tecnología altamente misión crítica y plagado de riesgos.
  • Control de procesos inadecuados. CASO proporciona nuevas capacidades significativas a utilizar nuevos tipos de herramientas de formas innovadoras. Sin la orientación del proceso adecuado y controles estas nuevas capacidades pueden causar significativos nuevos problemas también.[10]

Véase también

  • Modelado de datos
  • Modelado específico de dominio
  • GForge Advanced Server
  • LibreSource
  • Ingeniería de método
  • Arquitectura basada en el modelo
  • Lenguaje de modelado
  • Desarrollo rápido de aplicaciones

Referencias

  1. ^ Kuhn, D.L (1989). "Selección y efectivamente usando una computadora ayudó a herramienta de ingeniería de software". Simposio Anual de Westinghouse computadora; 6 – 7 Nov de 1989; Pittsburgh, PA (Estados Unidos); Proyecto DOE.
  2. ^ Loucopoulos P. y V. Karakostas (1995). Software Engineerinuality requisitos del sistema que se pueden realizar con eficacia.
  3. ^ Teichroew, Daniel; Hershey, Ernest Allen (1976). "PSL/PSA una técnica asistida por ordenador para documentación estructurado y análisis de sistemas de procesamiento de información". Procedimiento CISE 76 actas de la segunda Conferencia Internacional sobre ingeniería de Software (IEEE Computer Society Press).
  4. ^ Coronel, Carlos; Morris, Steven (04 de febrero de 2014). Sistemas de base de datos: Diseño, implementación y administración. Cengage Learning. PP. 695-700. ISBN1285196147. 25 de noviembre 2014.
  5. ^ Caso, Albert (otoño 1985). "Ingeniería de software asistida por ordenador (CASE): tecnología para mejorar la productividad del desarrollo de software". ACM SIGMIS base de datos 17 (1): 35-43.
  6. ^ Yourdon, Ed (23 de julio de 2001). "Pueden crecer proyectos XP?". Computerworld. 25 de noviembre 2014.
  7. ^ "Estrategia AD/ciclo y arquitectura", IBM Systems Journal, Vol. 29, NO 2, 1990; p. 172.
  8. ^ a b c Alfonso Fuggetta (diciembre de 1993). "Una clasificación de tecnología CASE". Computadora 26 (12): 25-38. Doi:10.1109/2.247645. 2009-03-14.
  9. ^ Ingeniería del software: Herramientas, principios y técnicas por Sangeeta Sabharwal, Umesh publicaciones
  10. ^ Ingeniería de Software asistida por ordenador. En: FFIEC IT examen manual InfoBase. Obtenido 03 de marzo de 2012.

Otras Páginas

Obtenido de"https://en.copro.org/w/index.php?title=Computer-aided_software_engineering&oldid=635777661"