CAPITULO 9

Modelos de Ingeniería de Software y Métodos

INTRODUCCION: Modelos y métodos de ingeniería de software Estructura al de ingeniería de software con El objetivo de hacer que la actividad sistemática, Repetible, y en definitiva más éxito - orientado. El uso de modelos ofrece una aproximación a un problema La resolución, una anotación, y los procedimientos para el modelo La construcción y el análisis. Métodos proporcionan una Acercarse a la especificación sistemática, diseño, Construcción, el ensayo y la verificación del producto final, Software y productos de trabajo asociados.

Modelos y métodos de ingeniería de software variar ampliamente en su alcance, desde hacer frente a un único la fase del

ciclo de vida del software a la cobertura de la completa ciclo de vida del software. El énfasis en este área de conocimiento

( KA ) está en la ingeniería de software modelos y métodos que abarcan múltiples de vida del software fases del ciclo , ya

que los métodos específicos para la vida sola fases del ciclo estén cubiertos por otra Kas .

DISTRIBUCIÓN DE TEMAS PARA MODELOS DE INGENIERÍA DE SOFTWARE Y MÉTODOS

Este capítulo sobre modelos de ingeniería de software y métodos se divide en cuatro áreas temáticas principales:

Modelado: se analiza la práctica general de modelado y presenta los temas en el modelado principios; propiedades

y expresión de modelos; la sintaxis de modelado, la semántica y pragmática; y condiciones previas, condiciones

posteriores e invariantes. Tipos de modelos: Los modelos discuten brevemente Y la agregación de sub modelos y proporciona Algunas características generales de los tipos de modelo Encontrado comúnmente en la ingeniería de software Práctica.

Análisis de modelos: presenta algunas de las Las técnicas de análisis comunes utilizados en el modelado para verificar la integridad, la consistencia, exactitud, trazabilidad, y la interacción.

Métodos de software de ingeniería: presenta un breve resumen de software de uso común métodos de ingeniería. Las guías de discusión el lector a través de un resumen de heurística métodos, métodos formales, la creación de prototipos, y métodos ágiles.

SIGLAS

3GL Idioma de 3ª Generación

BNF

Backus-Naur Form

FDD

Desarrollo impulsado por la función

IDE Desarrollo integrado Ambiente

PBI Producto de reserva pedidos y artículos

RAD

Desarrollo rápido de aplicaciones

UML

Lenguaje de Modelado Unificado

XP

Programación extrema

El desglose de los temas para el Software Modelos y Métodos de ingeniería se muestra KA en la Figura 9.1 .

1. Modelado: Modelado de software se está convirtiendo en un omnipresente Técnica para ayudar a los ingenieros de software a entender al ingeniero, y comunicar los aspectos del software Para apropiarse de las partes interesadas. Las partes interesadas son aquellas personas o partes que tienen un indicadas o de interés implícita en el software por ejemplo, usuario, comprador, proveedor, el arquitecto, la autoridad de certificación, Evaluador, desarrollador, ingeniero de software, y Quizás otros). Si bien hay muchos lenguajes de modelado,notaciones , técnicas y herramientas en la literatura y en la práctica , no están unificando conceptos generales que se aplican en alguna forma a todos ellos. Las secciones siguientes proporcionan antecedentes sobre estos conceptos generales.

Ingeniería de

software y métodos

MODELADO

TIPOS DE

MODELOS

ANALISIS DE MODELO

METODOS DE

INGENIERIA DE SOFTWARE

Principios de

modelado

Propiedades y

expresión de los

modelos

Sematicas sintaxis

y la pragmática

Precondiciones

pos condiciones

e invariantes

Modelado de

información

Modelado del

Comportamiento

Modelado de la

estructura

Análisis de integridad

el análisis

Análisis de Consistencia

El Análisis De La Corrección

Trazabilidad

Análisis de la interacción

Métodos

heurísticos

Métodos Formales

Métodos De

Prototipos

Métodos ágiles

1.1. Principios de modelización [1*, c2s2, c5s1, c5s2] [2*, c2s2] [3*, c5s0] Modelado proporciona al ingeniero de software con Un enfoque organizado y sistemático para la representación Aspectos significativos del software bajo Estudiar, facilitando la toma de decisiones sobre el software O elementos de la misma, y la comunicación de los Decisiones importantes a otros en la parte interesada Las comunidades. Hay tres principios generales Orientar dichas actividades de modelado:

Modelar los Fundamentos: buenos modelos no lo hacen por lo general representan cada aspecto o característica del software bajo todas las condiciones posibles. Modelado típicamente involucra el desarrollo de solamente aquellos aspectos o características del software que necesita respuestas específicas, abstraerse de cualquier información no esencial. Este enfoque mantiene los modelos manejable y útil.

Proporcionar Perspectiva: el modelado ofrece Puntos de vista del software en estudio utilizando Un conjunto definido de reglas para la expresión del Modelo dentro de cada vista. Esta perspectiva driven Enfoque proporciona a dimensional dad El modelo (por ejemplo, una vista estructural, Punto de vista del comportamiento, vista temporal, de organización Punto de vista, y otros puntos de vista según el caso) La organización de la información en vistas enfoques Los esfuerzos de modelado de software en concreto. Preocupaciones pertinentes a la vista mediante la Notación adecuadas, vocabulario, métodos, Y herramientas.

Habilitar una comunicación eficaz : el modelad Emplea el dominio de aplicación del vocabulario Del software, un

lenguaje de modelado Expresión semántica (en otras palabras, significado Dentro del contexto). Cuando se utiliza rigurosamente y sistemáticamente , los resultados de este modelado en Un enfoque de informes que facilita la efecto la comunicación de información de software de Interesados en el proyecto.

Un modelo es una abstracción o simplificación de un componente de software. A consecuencia de la utilización abstracción es que hay una única abstracción completamente describe un componente de software. Más bien, el modelo del software se representa como una la agregación de las abstracciones , que , cuando se toma juntos, describir sólo aspectos específicos , perspectivas , o sólo los puntos de vista que se necesitan para tomar decisiones informadas y

responder a la razones para crear el modelo en el primer lugar . Esta simplificación conduce a un conjunto de supuestos sobre el contexto dentro del cual el modelo es Colocado que también deben ser capturados en el modelo. Entonces, cuando reutilizando el modelo, estos supuestos pueden ser validados primero en establecer la relevancia del modelo reutilizado dentro de su nuevo uso y el contexto.

1.2. Propiedades y Expresión de Modelos [1*, c5s2, c5s3] [3*, c4s1.1p7, c4s6p3, c5s0p3]

Propiedades de los modelos son aquellas características distintivas de un modelo en particular utilizado para caracterizar su integridad, consistencia y corrección dentro de la notación de modelado elegido y utillaje usado. Propiedades de los modelos incluyen los siguientes:

Integridad: el grado en que todos Se han implementado los requisitos y comprobada dentro del modelo.

Consistencia: el grado en que el modelo no contiene requisitos conflictivos, afirmaciones, restricciones, funciones, o componente descripciones.

Corrección: el grado en que el modelo satisface sus requerimientos y especificaciones de diseño y está libre de defectos

Los modelos se construyen para representar el mundo real objetos y sus comportamientos de respuesta específica preguntas acerca de cómo se espera que el software para operar. Interrogar a los modelos, ya sea a través de la exploración, la simulación, o una revisión a mayo exponer las áreas de incertidumbre en el modelo y el software al que se refiere el modelo. Estas incertidumbres y preguntas sin respuesta con respecto los requisitos, el diseño y / o implementación a continuación, puede ser manejado apropiadamente El elemento de expresión primaria de un modelo es una entidad. Una entidad puede representar artefactos concretos (Por ejemplo, procesadores, sensores, o robots) o artefactos abstractos (por ejemplo, módulos de software o protocolos de comunicación) . entidades del modelo de están conectadas a otras entidades que utilizan las relaciones (En otras palabras, las líneas o los operadores de texto sobre las entidades de destino) . Expresión de las entidades del modelo se puede conseguir usando textual o gráfica Lenguajes de modelado; tanto lenguaje de modelado tipos de entidades se conectan a través de un lenguaje específico modelo construcciones. El significado de una entidad puede ser representado por su forma, atributos de texto, o ambos. Generalmente, la información textual se adhiere a estructura sintáctica específica del idioma. la precisión de significados relacionados con el modelado de contexto , estructura, o el comportamiento usando estas entidades y relaciones depende de la lenguaje de modelado se utiliza, el rigor de diseño aplica a la modelización esfuerzo, siendo construido el punto de vista específico , y la entidad a la que el elemento de anotación específica puede estar unido . Múltiples vistas del modelo puede ser necesaria para capturar la semántica necesaria del software.

Al utilizar modelos soportados con la automatización, modelos pueden comprobarse la integridad de y consistencia. La utilidad de estos controles depende en gran medida del nivel de semántica y sintáctica el rigor aplicado al esfuerzo de modelado, además al soporte de la herramienta explícita. La corrección es típicamente comprobado a través de la simulación y / o revisión.

1.3. Sintaxis, la semántica y la pragmática: [2* c2s2.2.2p6] [3*, c5s0]

Los modelos pueden ser sorprendentemente engañosos. El hecho que un modelo es una abstracción con la información que falta puede conducir a uno en una falsa sensación de completo Descripción del software de un solo modelo. Un modelo completo.

Guía 9-4 SWEBOK® V3.0

En relación con el esfuerzo de modelado) puede ser una unión De varios subámoselos y cualquier función especial Modelos. El examen y la toma de decisiones relativa a un modelo único dentro de esta colección de Submodelos pueden ser problemáticos. La comprensión de los significados precisos de modelado Construcciones también puede ser difícil. Modelado Idiomas se definen por sintáctico y semántico Reglas. Para lenguajes textuales, se define la sintaxis Utilizando una gramática notación que define idioma válido Construcciones (por ejemplo, Backus –Naur Form (BNF). Para lenguajes gráficos, la sintaxis es Definido usando modelos gráficos llamados metamodelos . Al igual que con el BNF, metamodelos definen la validez Construcciones sintácticas de un modelado gráfico Idioma; el metamodelo define cómo estas construcciones Puede estar compuesto para producir modelos válidos . La semántica de lenguajes de modelado especifican el es decir, pegadas a las entidades y las relaciones Capturado dentro del modelo. Por ejemplo, un simple Diagrama de dos cajas conectadas por una línea está abierto a una variedad de interpretaciones. Sabiendo que el Diagrama en el que se coloca y se conectan las cajas es un diagrama de objeto o un diagrama de actividad Puede ayudar en la interpretación de este modelo. En la práctica, por lo general hay un buen Comprensión de la semántica de un determinado Modelo de software debido al lenguaje de modelado Seleccionado, la forma en que el lenguaje de modelado se utiliza para Expresar las entidades y las relaciones dentro de ese modelo ,la experiencia base del modelador (s ), y el Contexto en el que el modelado ha sido Llevado a cabo y representado. El significado se comunica a través del modelo incluso en presencia De información incompleta a través de la abstracción; la pragmática se explica cómo se materializa significado en el modelo y su contexto y comunicada Eficazmente a otros ingenieros de software.

Todavía hay casos, sin embargo, en que la precaución se necesita con respecto a la modelización y la semántica. Por ejemplo, las piezas importadas de modelo otro modelo o de la biblioteca deben ser examinados para supuestos semánticos que los conflictos en el nuevo entorno de modelado; esto puede no ser obvia. El modelo debe ser revisado para documentada supuestos. Mientras que la sintaxis puede ser modelado idéntica, el modelo puede significar algo muy diferente en el nuevo entorno, que es un diferente contexto. Además, considere que a medida que el software madura y se realizan cambios, la discordia semántica puede ser introducido, lo que conduce a errores. Con muchas Ingenieros de software que trabajan en una parte del modelo más Tiempo, junto con las actualizaciones de la herramienta y quizás nueva Requisitos, existen oportunidades para que las porciones Del modelo para representar algo diferente a partir del modelo inicial y la intención del autor originalContexto.

1.4. Condiciones previas, pos condiciones, y la Invariantes: [2*, c4s4] [4*, c10s4p2, c10s5p2p4]

Al modelar las funciones o métodos, el software ingeniero suele comenzar con un conjunto de suposiciones sobre el estado del software anteriores de, durante, y después de la función o método ejecuta. Estos supuestos son esenciales para el correcto funcionamiento de la función o método y son agrupados, para su discusión, como un conjunto de

condiciones previas, pos condiciones, e invariantes.

• Condiciones previas: un conjunto de condiciones que deben ser satisfecha antes de la ejecución de la función o método. Si estas condiciones no se sostienen antes de la ejecución de la función o método, la función o método pueden producir errónea resultados. • Pos condiciones: un conjunto de condiciones que es Garantizada para ser verdad después de la función o Método ha ejecutado con éxito. Típicamente, Las condiciones posteriores representan cómo el Estado Del software ha cambiado, cómo los parámetros Pasado a la función o método han Cambiado, cómo los valores de datos han cambiado, o Cómo el valor de retorno se ha visto afectado

Invariantes: un conjunto de condiciones dentro de la entorno operativo que persisten (en Es decir, no cambian) antes y después ejecución de la función o método. Estas invariantes son pertinentes y necesarias para el software y el correcto funcionamiento de la función o método.

2. Tipos de Modelos

Un modelo típico consiste en una agregación de sub modelos Cada sub-modelo es una descripción parcial y se crea para un propósito específico; puede estar compuesto de uno o más diagramas. Los colección de sub modelos puede emplear múltiples

Modelado de idiomas o un solo lenguaje de modelado. El Unified Modeling Lenguaje (UML) reconoce una rica colección de diagramas de modelado. El uso de estos diagramas, junto con el construcciones de lenguaje de modelado, da lugar a tres tipos de modelos generales de uso común: información modelos, modelos de comportamiento, y los modelos de estructura (Ver sección 1.1).

2.1 . Modelado de información

[1*, c7s2.2] [3*, c8s1]

Modelos de información de proporcionar un hilo de datos e información. Un modelo de información es una representación abstracta que identifica y define un conjunto de conceptos, propiedades, relaciones y restricciones en entidades de datos La semántica o conceptual modelo de información se utiliza a menudo para proporcionar algunos formalismo y el contexto para que el software sea modelado como se ve desde la perspectiva problema, sin preocuparse de cómo este modelo es en realidad asignada a la aplicación del software. El modelo de información semántica o conceptual es una abstracción y, como tal, incluye sólo los conceptos, propiedades, relaciones y restricciones necesarias para conceptualizar el punto de vista del mundo real de la información. Transformaciones posteriores de el modelo de información semántica o conceptual conducir a la elaboración de la lógica y física modelos de datos como se aplica en el software

2.2 . Modelado del comportamiento [1*, c7s2.1, c7s2.3, c7s2.4] [2*, c9s2] [3*, c5s4] Modelos de comportamiento identifican y definen las funciones del software que se está modelando. Conductual modelos generalmente toman tres formas básicas:Máquinas de estado, modelos de flujo de control de flujo de datos, y modelos. Las máquinas de estado proporcionan un modelo del software como una colección de estados definidos, eventos y transiciones. Las transiciones de software de un estado a otro por medio de un vigilado o sin vigilancia evento desencadenante que se produce en el entorno de modelado. Los modelos de flujo de control representan cómo una secuencia de acontecimientos provoca procesos para ser activado o desactivado.

Comportamiento de flujo de datos se tipifica como una secuencia de pasos donde los datos mueven a través de procesos hacia almacenes de datos o sumideros de datos.

2.3 . Modelado estructura [1*, c7s2.5, c7s3.1, c7s3.2] [3*, c5s3] [4*, c4] Modelos de estructura ilustran la física o lógica Composición de software de sus diversos componentes partes. Modelado Estructura establece la límite definido entre el ser software Aplicado o modelado y el medio ambiente en el que ha de operar. Algún estructural común Construcciones utilizadas en el modelado de la estructura son Composición , descomposición, la generalización y Especialización de entidades; identificación de relevantes Las relaciones entre las entidades y cordialidad; y la definición de proceso o interfaces funcionales . Diagramas de estructura proporcionada por el UML Para el modelado de la estructura incluyen la clase, componente, De objetos, de implementación y de embalaje diagramas.

3. Análisis de Modelos El desarrollo de modelos proporciona el software diseñar una oportunidad de estudiar , razonar sobre , y comprender la estructura, la función operativa de uso y montaje consideraciones asociadas con software. Análisis de construida Se necesitan modelos para asegurar que estos modelos son completa, coherente , y lo suficientemente correcta para servir su propósito destinado a las partes interesadas . Las secciones siguientes describen brevemente la Las técnicas de análisis utilizan generalmente con el software modelos para asegurar que el ingeniero de software y otras partes interesadas ganancia apropiada valor del desarrollo y uso de modelos .

3.1 . Para completar el análisis [3*, c4s1.1p7, c4s6] [5*, p8–11]

Con el fin de tener un software que cumple plenamente las necesidades de las partes interesadas, la integridad es fundamental, desde el proceso de obtención requisitos para la implementación de código. Integridad es el grado en el cual todos los requisitos especificados se han aplicado y verificado. Los modelos pueden ser revisados para exhaustividad por una herramienta de modelado que utiliza técnicas como el análisis estructural y de espacio de estado El análisis de accesibilidad (que asegurar que todos los caminos en los modelos de estado son alcanzados por un conjunto de correcta insumos); modelos también pueden comprobarse la integridad de manualmente mediante inspecciones u otras revisiones técnicas (véase la calidad KA Software). Errores

9-6 SWEBOK® Guide V3.0A Avisos generados por estas herramientas de análisis y Demostrado en una inspección o revisión indicar probables Las

acciones correctivas necesarias para garantizar la integridad De los modelos.

3.2 . La consistencia para analizar [3*, c4s1.1p7, c4s6] [5*, p8–11] La consistencia es el grado en que contienen modelos No hay requisitos conflictivos, afirmaciones, las limitaciones, funciones o descripciones de componentes. Típicamente, la comprobación de consistencia se logra con la herramienta de modelado utilizando un análisis automatizado función; modelos también se pueden examinar la consistencia manualmente mediante inspecciones u otras revisiones técnicas (véase la calidad KA Software) . Como con integridad, errores y avisos generados por estas herramientas de análisis y demostrado en una inspección o opinión indican la necesidad de una acción correctiva.

3.3 . El análisis de la corrección [5*, p8–11] La corrección es el grado en el que un modelo satisface sus requisitos de software y software especificaciones de diseño , está libre de defectos , y en última instancia satisface las necesidades de los interesados. analizando para la corrección incluye verificar corrección sintáctica del modelo ( es decir , el uso correcto de la gramática lenguaje de modelado y construcciones ) y la verificación de la corrección semántica del modelo ( que es decir, el uso del lenguaje de modelado construye representar correctamente el significado de lo que es que está siendo modelado ) . Para analizar un modelo para sintáctica y la corrección semántica , uno lo analiza , ya sea de forma automática ( por ejemplo, usando el modelado herramienta para comprobar la corrección sintáctica modelo) o manualmente (mediante inspecciones u otras revisiones técnicas ) -searching por posibles defectos y a continuación, la eliminación o la reparación de los defectos confirmados antes de que el software está liberado para su uso .

3.4 . trazabilidad [3*, c4s7.1, c4s7.2] El desarrollo de software normalmente implica el uso , Creación y modificación de muchos productos de trabajo tales como los documentos de planificación , las especificaciones del proceso Requisitos de software , diagramas, diseños y pseudo-código, escrito a mano y la herramienta generada Código, casos de prueba manuales y automatizados e informes,y los archivos y datos. Estos productos pueden ser de trabajo. Relacionadas a través de diferentes relaciones de dependencia (Por ejemplo, utiliza, implementos y pruebas). A medida que el software se está desarrollando, gestionar, mantener, o Extendido, hay una necesidad de asignar y controlar estos Relaciones de trazabilidad para demostrar software Requisitos de compatibilidad con el software Modelo (ver Requisitos de rastreo en el Software

Requisitos KA) y los muchos productos de trabajo. El uso de trazabilidad suele mejorar la gestión de los productos de trabajo de software y procesos de software Calidad; sino que también proporciona garantías a las partes interesadas que se han cumplido todos los requisitos. La trazabilidad permite el análisis del cambio una vez que el software está desarrollado y puesto en libertad, puesto que las relaciones a productos de software de trabajo pueden ser fácilmente atravesados para evaluar el impacto del cambio. Las herramientas de modelado típicamente Proporcionar algunos medios automatizados o manuales para especificar y gestionar los enlaces de trazabilidad entre los requisitos, Diseño, código y / o entidades de prueba como pueden ser Representado en los modelos de software y otros trabajos Productos. (Para obtener más información sobre la trazabilidad, Ver el software de configuración de administración KA).

3.5 . Análisis de Interacción [2*, c10, c11] [3*, c29s1.1, c29s5] [4*, c5] Interacción análisis se centra en las comunicaciones o las relaciones entre las entidades de control de flujo utilizado para realizar una tarea o función específica dentro del modelo de software. Este análisis examina el comportamiento dinámico de las interacciones entre las diferentes partes del modelo de software, incluyendo otras capas de software ( como la operación sistema , middleware y aplicaciones ) . Eso también puede ser importante para algunas aplicaciones de software para examinar las interacciones entre el ordenador aplicación de software y la interfaz de usuario software. Algunos entornos de modelado de software proporcionar instalaciones de simulación para estudiar los aspectos de la el comportamiento dinámico de software modelado. Stepping a través de la simulación proporciona un análisis opción para el ingeniero de software para revisar el el diseño de interacción y verificar que los diferentes partes de la obra de software juntos para proporcionar la funciones previstas. Modelos de Ingeniería de Software y Métodos 9-7

4. Métodos de Ingeniería de Software Métodos de ingeniería de software proporcionan un segmento organizadoy el enfoque sistemático para el desarrollo de software para un equipo de destino . Hay numerosos métodos entre los que elegir , y es importante para el ingeniero de software para elegir una adecuada método o métodos para el desarrollo de software tarea en cuestión; esta elección puede tener un efecto dramático en el éxito del proyecto de software. El uso de estos métodos de ingeniería de software , junto con la gente del conjunto de habilidades y las herramientas adecuadas permiten el software ingenieros para visualizar los detalles del software y, finalmente, transformar la representación en una conjunto de trabajo de código y datos . Se discuten los métodos de ingeniería de software seleccionados abajo. Las áreas temáticas se organizan en discusiones de los métodos heurísticos , Métodos formales, Métodos de creación de prototipos , y los métodos ágiles .

4.1 . Los métodos heurísticos [1*, c13, c15, c16] [3*, c2s2.2, c5s4.1, c7s1,]

Los métodos heurísticos son aquellos basados en la experiencia métodos de ingeniería de software que han sido y son bastante ampliamente practicado en la industria del software . Esta área temática contiene tres amplia discusión Categorías : análisis y diseño estructurado métodos , los métodos de modelado de datos , y orientado a objetos análisis y diseño de métodos .

Análisis estructurado y Métodos Diseño :El modelo de software es desarrollado principalmentedesde un punto de vista funcional o conductual ,a partir de una visión de alto nivel del software( Incluyendo elementos de datos y de control ) y luego en descomposición o del refinado progresivamentelos componentes del modelo a través de cada vez diseños detallados . El diseño detallado finalmente converge a detalles muy específicoso las especificaciones del software que debe sercodificado (con la mano , se genera automáticamente , oambos) , construido , probado y

verificado . • Los métodos de modelado de datos: El modelo de datos es construida a partir del punto de vista de los datos o la

información utilizada . Las tablas de datos y relaciones definir los modelos de datos . Este modelado de datos método se utiliza principalmente para definir y los requisitos de análisis de datos de soporte

4.2 . Métodos formales [1*, c18] [3*, c27] [5*, p8–24]

Los métodos formales son los métodos de ingeniería de software se utiliza para especificar, desarrollar y verificar el software mediante la aplicación de un matemáticamente rigurosa notación y lenguaje basado. A través del uso de un lenguaje de especificación, el modelo de software se puede comprobar la consistencia (en otras palabras, falta de ambigüedad), integridad y corrección de forma sistemática y automatizada o semi - automatizada Moda. Este tema está relacionado con el análisis formal la sección de los Requisitos de software KA. Esta sección se ocupa de los lenguajes de especificación, refinamiento de programas y derivación, la verificación formal, y la inferencia lógica.

• Especificación Idiomas: Especificación Lenguajes proporcionan la base matemática Por un método formal; lenguajes de especificación Son formales, equipo de alto nivel Idiomas (en otras palabras, no es un clásico Lenguaje de programación de 3ª Generación (3GL) Idioma utilizado durante el software Especificación, análisis de requerimientos, y / o etapas de diseño para describir entrada específica /Comportamiento de salida. Lenguajes de especificación son Idiomas no directamente ejecutables son: 9-8 SWEBOK® Guide V3.0

Normalmente compuesto por una notación y sintaxis, semántica para el uso de la notación, y un conjunto de relaciones permitidas para los objetos

• Perfeccionamiento del programa y Derivación: Programa refinamiento es el proceso de crear una nivel más bajo (o más detallada) especificación utilizando una serie de transformaciones. Es a través de transformaciones sucesivas que el

software ingeniero deriva una representación ejecutable de un programa. Las especificaciones pueden ser refinadas, añadiendo detalles hasta que el modelo se puede formular en un lenguaje de programación 3GL o en una parte ejecutable de la especificación elegida idioma. Esta especificación es el refinamiento hecha posible mediante la definición de las especificaciones con las propiedades semánticas precisas; las especificaciones deberán contener no sólo las relaciones entre entidades, sino también los significados de tiempo de ejecución exactos de esas relaciones y operaciones.

• Verificación Formal: El chequeo de modelo es un método de verificación formal; por lo general implica la realización de una exploración de espacio de estado o el análisis de accesibilidad para demostrar que el diseño de software representado tiene o preserva determinados del modelo de interés. Un ejemplo de verificación de modelos es una El análisis que verifica el comportamiento del programa correcta bajo posible entrelazado de evento o llegadas de mensajes. El uso de la verificación formal requiere un modelo rigurosamente especificado del software y su entorno operativo; este modelo a menudo toma la forma de una máquina de estados finitos u otra define formalmente autómata.

• La inferencia lógica : La inferencia lógica es una método de diseño de software que involucra especificando las condiciones previas y condiciones posteriores alrededor de cada bloque importante del diseño, y el uso de la lógica matemática - desarrollo la prueba de que esas condiciones previas y condiciones posteriores debe mantener en todas las entradas . Esta proporciona una manera para que el ingeniero de software predecir el comportamiento del software sin tener para ejecutar el software. Algunos integrado Entornos de desarrollo (IDE) incluyen formas de representar estas pruebas junto con el diseño o código.

4.3 . Métodos de creación de prototipos [1*, c12s2] [3*, c2s3.1] [6*, c7s3p5]

Creación de prototipos de software es una actividad que generalmente Crea versiones incompletas o mínimamente funcionales De una aplicación de software, por lo general para tratar Nuevas características, solicitando retroalimentación Sobre los requisitos de software o más interfaces de usuario, La exploración de los requisitos de software, software

Diseño, implementación o opciones, y / o ganar Alguna otra información útil en el software. Los Ingeniero de software selecciona un método de creación de prototipos de Entender los aspectos o componentes menos comprendidos Del software primero; este enfoque es en A diferencia de otros métodos de ingeniería de software Que por lo general comienzan con el desarrollo de la mayor parte Entendido porciones primera. Típicamente, el prototipo Producto no se convierta en la versión final del software Producto sin extensa re trabajo desarrollo o refactorización. En esta sección se discute la creación de prototipos estilos, objetivos, y técnicas de evaluación en breve.

• Estilo de prototipos: Esto se refiere a los diversos enfoques para desarrollar prototipos. Prototipos puede ser

desarrollado como código de usar y tirar o productos de papel, como una evolución de un trabajo diseño, o como una especificación ejecutable. Los diferentes procesos del ciclo de vida de prototipos son normalmente utilizados para cada estilo. El estilo elegido se basa en el tipo de resultados del proyecto necesidades, la calidad de los resultados es necesario, y la urgencia de los resultados. • Prototipos Objetivo: El objetivo del prototipo La actividad es el producto específico que Servido por el esfuerzo de creación de prototipos . Ejemplos De creación de prototipos objetivos incluyen unos requisitos Especificación, un elemento de diseño arquitectónico O componente, un algoritmo, o una human machine Interfaz de usuario.

• Técnicas de evaluación de prototipos : Un prototipo puede ser usado o evaluado en varios de maneras por

el ingeniero de software o otros interesados en el proyecto , impulsado principalmente por las razones subyacentes que llevaron al prototipo el desarrollo en el primer lugar. Prototipos puede ser evaluado o probado contra el software implementado real o contra un objetivo conjunto de requisitos (por ejemplo, una requisitos prototipo) ; el prototipo puede También servirá como modelo para un futuro software esfuerzo de desarrollo (por ejemplo, como en un usuario especificación de interfaz ). Software Engineering Models and Methods 9-9

4.4. Los métodos ágiles [3*, c3] [6*, c7s3p7] [7*, c6, App. A] Los métodos ágiles nacieron en la década de 1990 de laLa necesidad de reducir la gran sobrecarga aparente asociada Con el peso pesado, métodos basados en el plan utilizado En proyectos de desarrollo de software a gran escala. Los métodos ágiles son considerados métodos ligeros En que se caracterizan por corto, iterativo Los ciclos de desarrollo, equipos de auto-organización, Diseños más simples, refactorización de código, basado en pruebas El desarrollo, la participación de los clientes frecuentes, y Un énfasis en la creación de un trabajo demostrable Producto con cada ciclo de desarrollo. Muchos métodos ágiles están disponibles en la literatura; Algunos de los enfoques más populares, Que se analizan aquí en breve, incluirá rápido Desarrollo de aplicaciones (RAD), Extreme Programming (XP ) , Scrum , y característica – Driven Desarrollo ( FDD ) .

• RAD: Rapid métodos de desarrollo de software se utilizan principalmente en grandes volúmenes de datos, sistemas

de negocio desarrollo de aplicaciones. El RAD método está habilitado con la base de datos de propósito especial herramientas de desarrollo de software utilizado por los ingenieros desarrollar rápidamente, probar e implementar aplicaciones de negocios nuevos o modificados.

• XP: Este método utiliza historias o escenarios Para los requisitos, desarrolla pruebas primeras, tiene La implicación

del cliente directamente en el equipo (Por lo general la definición de las pruebas de aceptación) , usos La programación en parejas, y prevé continua Refactorización de código y la integración. Cuentos Se descomponen en tareas, priorizado, estimado, Desarrollado, y probado. Cada incremento De software ha sido probado con automatizado y pruebas manuales; un incremento puede ser Lanzan con frecuencia, por ejemplo, cada par de Semanas más o menos.

• Scrum: Este enfoque es más ágil proyecto gestión del medio ambiente que los otros. Los scrum maestro gestiona las

actividades dentro de el incremento de proyectos; cada incremento es llama una carrera corta y dura no más de 30 días.

Un artículo Pila de Producto (PBI) es la lista desarrollados a partir de la cual se identifican las tareas, definido y priorizado, y estimado. Un trabajo versión del software ha sido probado y lanzado en cada incremento. Scrum diaria reuniones aseguran trabajo se administra con el plan.

• FDD: Este es un modelo impulsado, corto, iterativo Enfoque de desarrollo de software utilizando Un proceso de cinco

fases: (1 ) el desarrollo de un producto Modelo para alcance la amplitud del dominio, (2) Crear la lista de necesidades o características, (3) la construcción El plan de desarrollo de funciones, (4) el desarrollo Diseños para funciones de iteración específica, y ( 5 ) de código, prueba, y luego integrar las funciones . FDD es similar a un software incremental Enfoque de desarrollo; también es similar a XP, con la excepción de que se le asigna la propiedad del código A individuos más que el equipo. FDD Hace hincapié en un enfoque arquitectónico global Al software, que promueve la construcción de la Función de forma correcta la primera vez en lugar de Haciendo hincapié en la refactorización continúa. Hay muchas más variaciones de los métodos ágiles En la literatura y en la práctica. Tenga en cuenta que Siempre habrá un lugar para el peso pesado, Métodos de ingeniería de software basados en plan, así Como lugares donde brillan los métodos ágiles. Existen Nuevos métodos derivados de combinaciones de ágil Y los métodos basados en el plan donde los practicantes están La definición de nuevos métodos que equilibran las características Necesaria tanto en el peso pesado y ligero Los métodos basados principalmente en que prevalece la organización Necesidades del negocio. Estas necesidades del negocio, Como suelen representado por algunos de los proyectos Las partes interesadas, debe y no conducir en la elección Utilizando un método de ingeniería de software a través Otro, o en la construcción de un nuevo método de la Mejores características de una combinación de la ingeniería de Métodos software.

9-10 SWEBOK® Guide V3.0 MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Budgen 2003

[1*]

Mellor y Balcer 2002 [2*]

Sommerville 2011 [3*]

Page-Jones 1999 [4*]

Wing 1990

[5*]

Brookshear 2008

[6*]

Boehm and Turner 2003

[7*]

1.Modelado

1.1Modelado principios

c2s2, c5s1, c5s2

c2s2 c5s0

1.2 propiedades y expresión de modelos

c5s2, c5s3

c4s1.1p7, c4s6p3, c5s0p3

1.3 Sintaxis, Semántica y Pragmática

C2s2.2.2 p6

c5s0

1.4 condiciones previas , Post condiciones , y invariantes

c4s4

c10s4p2, c10s5 p2p4

2. Types of Models 2.1 Información Modelado

c7s2.2

c8s1

2.2conductual Modelado

c7s2.1, c7s2.3, c7s2.4

c9s2 c5s4

2.3 . Estructura

7s2.5, c7s3.1,c7s3.2

c5s3 c4

Modelado

3. Análisis de Modelos

3.1 El análisis completo

c4s1.1p7, c4s6

pp8–11

3.2 El análisis de Consistencia

c4s1.1p7, c4s6

pp8–11

3.3 . El análisis de Exactitud

pp8–11

3.4 . trazabilidad

c4s7.1, c4s7.2

3.5

Interacción

Análisis

c10, c11

c29s1.1, c29s5

c5

Budgen 2003 [1*]

Mellor and Balcer 2002 [2*]

Sommerville 2011 [3*]

Page-Jones 1999 [4*]

Wing 1990 [5*]

Brookshear 2008 [6*]

Boehm and Turner 2003 [7*]

4. Software

Métodos de

ingeniería

4.1 . Heurístico métodos

c13, c15, c16

c2s2.2, c7s1, c5s4.1

4.2 . Métodos formales

c18

c27

pp8–24

4.3 . prototipo

métodos

C12s2

c2s3.1

c7s3p5

4.4 . Los métodos ágiles

c3

c7s3p7 c6, app. A

9-12 SWEBOK® Guide V3.0

Referencias

[ 1 * ] D. Budgen , Diseño de software, 2ª ed . , Addison-Wesley , 2003 .

[ 2 *] S.J. Mellor y M. J. Balcer , Ejecutable UML : La Base para Model- Driven Arquitectura, 1ª ed . , Addison- Wesley , 2002 .

[ 3 * ] I. Sommerville , Ingeniería de Software , 9 ed . , Addison- Wesley , 2011.

[ 4 * ] M. Página - Jones , Fundamentales Objetos de Diseño en UML , 1ª ed . , Addison-Wesley , 1999

[ 5 * ] J. M. Wing, " Introducción de un especificador de Métodos formales , "Computer , vol. 23 , no. 9 , 1990 , pp . 8 , 10-23

[ 6 *] J.G. Brookshear , Ciencias de la Computación : Un Descripción general , 10ª ed . , Addison- Wesley , 2008

[ 7 * ] B. Boehm y R. Turner , Agilidad Equilibrio y Disciplina : Una Guía de los Perplejos , Addison-Wesley , 2003 ..