Proceso de desarrollo de software unificado. Proceso de desarrollo unificado y programación extrema

De acuerdo con GOST 34.601-90 “AS. Etapas de creación" establece las siguientes etapas de creación de un AIS, las cuales, a su vez, se pueden dividir en etapas:

· formación de requisitos para AIS;

· desarrollo del concepto AIS;

· tarea técnica;

· diseño preliminar;

· proyecto técnico;

· documentación de trabajo;

· puesta en marcha.

Cada etapa tiene su propio conjunto de documentación de diseño e implementación de módulos técnicos y de software del sistema. La práctica demuestra que el proceso de creación de un sistema es iterativo e incremental. Los autores de UML enfatizan esto al definir el concepto. proceso unificado de desarrollo de software e información. Aunque en la primera etapa se forma un conjunto de requisitos para el AS en su conjunto, en realidad siempre está incompleto al principio y se aclara en etapas posteriores. tengo que hacer iteraciones, es decir, repetir pasos y etapas individuales, ya sea en su totalidad o en parte. Además, un sistema real es multifuncional y complejo, por lo que se suele dividir en subsistemas y conjuntos separados de tareas, distinguiendo subsistemas y tareas de la primera etapa, la segunda, etc. El sistema se está creando. incrementalmente, a través de incrementos graduales de funcionalidad con la sustitución de soluciones de diseño preliminares por otras más desarrolladas que satisfagan mejor las necesidades del usuario. Esto reduce los riesgos financieros y ahorra tiempo y consumo de recursos en las etapas finales de la creación.

Cuando se utiliza la metodología UML para crear software AIS y soporte de información, se propone construir un conjunto de modelos interconectados que reflejen las propiedades estáticas y dinámicas del sistema futuro:

· modelo de caso de uso;

· modelo de análisis;

· modelo de diseño;

· modelo de implementación;

· modelo de implementación;

· modelo de prueba.

Modelo de caso de uso incluye diagramas de casos de uso y escenarios correspondientes, describe los requisitos funcionales del sistema y su comportamiento al interactuar con los usuarios.

Modelo de análisis incluye diagramas de clases genéricos para implementar casos de uso de nivel lógico, diagramas de secuencia asociados y/o diagramas de colaboración, y es un bosquejo de cómo se implementarán los casos de uso de nivel lógico.

Modelo de diseño es una representación detallada de la implementación física del modelo de análisis e incluye diagramas de paquete (subsistema), diagramas de clases detallados, diagramas de secuencia y/o diagramas de cooperación, diagramas de estado, diagramas de actividad de diversos grados de detalle.

Modelo de implementación Incluye diagramas de implementación preliminares que definen todas las configuraciones de red en las que se puede ejecutar el sistema. Los diagramas de implementación indican los nodos de red, los tipos de conexión y la distribución de clases de sistemas activos entre los nodos.

Modelo de implementación Describe cómo se implementan las clases de diseño como componentes. En consecuencia, incluye diagramas de componentes, seguimientos de clases (implementación), diagramas de implementación detallados y una descripción de la arquitectura del sistema.

Modelo de prueba Contiene un conjunto de casos de prueba, procedimientos de prueba y descripciones de componentes de prueba. Especifica métodos para probar componentes ejecutables del sistema.

Comparemos los procesos de construcción de modelos con las etapas estandarizadas de creación de un AS. El modelo de casos de uso se construye en la etapa de formación de requisitos para el AS; el modelo de análisis se encuentra en la etapa de desarrollo del concepto AS. En la etapa de especificaciones técnicas y diseño preliminar, se construye un modelo de diseño. Se perfecciona en la etapa de diseño técnico y se complementa con un modelo de implementación. En la etapa de documentación de trabajo, se crean modelos de implementación y prueba. Finalmente, en la fase de puesta en marcha, el modelo de prueba se perfecciona y se convierte en un modelo de referencia durante el funcionamiento, destinado a comprobaciones periódicas del correcto funcionamiento y diagnóstico del sistema.

1.5 Componentes del lenguaje UML

Lenguaje unificado de modelado UML(Lenguaje de modelado unificado) es un lenguaje de modelado visual que se utiliza para especificar, visualizar, configurar y documentar sistemas complejos (incluido el software) utilizando tecnología orientada a objetos.

Al crear un AS en la metodología UML, se utilizan los principios de análisis de sistemas estructurales conocidos de las metodologías Hein/Sarson y SADT:

· desarrollo de arriba hacia abajo, etapa por etapa;

· técnica de diagramación;

· jerarquía de descripciones;

· formalización estricta de la descripción de las soluciones de diseño;

· desarrollo inicial del proyecto a nivel lógico sin detalles de implementación técnica;

· modelado conceptual en términos del área temática para que el cliente comprenda el diseño del sistema;

· soporte tecnológico con herramientas (sistemas CASE).

Se puede estudiar un modelo de un sistema complejo en UML para obtener características estimadas de la eficiencia de los procesos en el sistema.

Los modelos para la implementación, implementación y prueba de software AS y soporte de información en UML se pueden utilizar como un proyecto de aplicación con la posterior generación automatizada de código de aplicación en uno de los entornos de programación seleccionados.

Un modelo bastante completo de un sistema complejo debería reflejar dos aspectos:

-estático(estructural) – composición, estructura de los componentes y sus relaciones;

-dinámica(comportamental) – descripción de la lógica de los procesos que ocurren en el sistema o que se implementarán.

El método principal para representar modelos adoptados en UML son los diagramas provistos de información textual, incluidas expresiones en el lenguaje de restricciones incorporado OCL, así como en los lenguajes de programación y consulta de información utilizados para implementar el sistema.

El principio básico del modelado: un sistema se modela como un grupo de objetos discretos que interactúan entre sí de tal manera que satisfagan los requisitos del usuario.

Un modelo estático especifica la estructura, los tipos de objetos y las relaciones entre objetos. El modelo dinámico determina el comportamiento de los objetos a lo largo del tiempo (la historia de los objetos) y su interacción.

Básicamente, UML es un lenguaje de modelado discreto, es decir, contiene el concepto de eventos discretos y cambios de estado. Los procesos continuos se modelan aproximadamente mediante discretización.

El modelo tiene dos aspectos: información semántica (semántica) y representación visual (notación).

La composición completa de las representaciones de modelos en el lenguaje UML se proporciona en la Tabla 1.

Tabla 1 – Representación de modelos de sistemas en UML.

El modelo conceptual más común de un sistema es el diagrama de casos de uso; es el punto de partida para construir otros diagramas.

Todos los diagramas del lenguaje son gráficos de un tipo especial, que contienen vértices (figuras geométricas) conectados por aristas (arcos). Normalmente la escala de la imagen y la ubicación de los vértices no son particularmente importantes, sin embargo, en el diagrama de secuencia se introduce el eje del tiempo y allí es significativo.

Las conexiones se indican mediante varias líneas en el plano, el texto está escrito dentro de las figuras y se pueden representar algunos símbolos gráficos cerca de los vértices y las conexiones. Las extensiones UML permiten diagramas espaciales.

El lenguaje tiene 4 tipos de estructuras gráficas:

· iconos (pictogramas);

· símbolos gráficos en un avión;

· caminos (líneas);

· líneas de texto.

1.6 Nivel conceptual. Modelo de caso de uso

En general, el proceso de diseño orientado a objetos ocurre de acuerdo con los principios básicos del análisis de sistemas estructurales: diseño de arriba hacia abajo con la construcción de una jerarquía de diagramas que nos mueven gradualmente de un nivel a otro: conceptual – lógico – físico (implementación)

Se considera que el diagrama de nivel superior es el propuesto por A. Jacobson en OOSE use el diagrama del caso sistemas en su conjunto. Esta es la representación conceptual inicial del sistema y se construye con el objetivo de:

· determinar los límites generales y el contexto del área temática modelada;

· formular requisitos generales para el comportamiento funcional y la interfaz del sistema;

· preparar la documentación inicial para la interacción entre desarrolladores y clientes - usuarios del sistema.

Punto de vista del modelo: usuario externo del sistema. Un diagrama de casos de uso incluye actores, casos de uso y asociaciones.

actante(actor, entidad externa, actor): una descripción abstracta de una clase de fuentes/receptores de mensajes que interactúan directamente con un sistema, subsistema o clase. esta es la descripción roles jugado por el usuario (persona u otro sistema, subsistema, clase) durante la interacción con el sistema. Esencialmente, se trata de una generalización de solicitudes de información similares al sistema que requieren un cierto servicio(servicios).

Un actante no necesariamente tiene que identificarse con un individuo o dispositivo específico, aunque esto a veces es posible en principio si solo cumple una función. En la mayoría de los casos, físicamente, se trata de diferentes personas y dispositivos que acceden al sistema para recibir el mismo servicio. En el nivel más alto, por ejemplo, los actantes pueden ser un operador, un administrador del sistema, un administrador de bases de datos, un usuario normal o algún tipo de dispositivo.

Todos los actantes posibles agotan todas las formas posibles de interacción del usuario con el sistema (subsistema, clase). Al implementar un sistema, los actantes se encarnan en personas y objetos físicos. Una persona u objeto físico, según el modo de interacción, puede representar varios actantes (diferentes roles). Por ejemplo, una misma persona puede ser operador y administrador de base de datos, vendedor y comprador, etc.

En muchos AS no hay otros actantes excepto personas. Sin embargo, los actantes pueden ser un sistema externo, un dispositivo de E/S o un temporizador (comúnmente encontrado en sistemas integrados en tiempo real). Entre los actantes del caso de uso destaca uno actante principal(actor principal), que inicia el trabajo con el sistema. El resto son secundarios, también participan en el caso de uso, recibiendo resultados e ingresando algunos datos intermedios.

En los niveles lógico y físico, los actantes están representados por clases y objetos que son instancias de clases. Es posible construir una jerarquía de actantes con herencia de todos los roles y relaciones, atributos y operaciones que tiene el actante ancestro. Siempre se puede utilizar una instancia de un actante hijo en el lugar del sistema donde se declara el uso del actante ancestro (principio de sustitución).

Un actante se puede representar en diagramas de dos formas:

3. Símbolo de clase (rectángulo) con indicación interna del estereotipo.

4. Más estándar: "hombre" con una inscripción (símbolo de una persona)

El actante está fuera del sistema y su estructura interna no está determinada. Es la fuente/receptor de mensajes.

Cliente

Caso de uso(precedente, caso de uso): una descripción abstracta de la clase de servicio (funciones de servicio) proporcionada al actante en respuesta a sus solicitudes.

El servicio puede ser proporcionado por el sistema en su conjunto, un subsistema o una clase. Por tanto, un caso de uso significa modelar alguna parte de la funcionalidad o comportamiento de un sistema. Un caso de uso tiene un nombre y significa una determinada secuencia de acciones visibles para una fuente/receptor externo (actante). La forma interna de implementar la opción está oculta y revelada en niveles inferiores de detalle. diagrama de cooperación. Como cualquier clase, un caso de uso tiene atributos y operaciones, cuya implementación se expone en la capa física.

El caso de uso incluye toda la secuencia de mensajes que el actante comienza y termina con el sistema (subsistema, clase). Por lo tanto, cualquier instancia de implementación de un caso de uso siempre tiene un comienzo en el tiempo y un final cuando ningún actante envía mensajes para esta opción. Esto también incluye mensajes de error, opciones para realizar la función de mantenimiento con varias configuraciones (alternativas).

Una instancia de caso de uso es la ejecución de un caso de uso que comienza después de recibir por primera vez un mensaje de una instancia de actante. En respuesta a un mensaje determinado, el caso de uso realiza una secuencia específica de acciones, como enviar un mensaje a otras instancias del actante (no solo al autor). A su vez, estos actantes envían mensajes a esta instancia de caso de uso y la interacción continúa hasta que no se reciben más mensajes de este tipo. Esto marca el final del caso de uso.

Se muestra la relación entre el actante y el caso de uso. asociación.

El diagrama representa el caso de uso de dos maneras:

1) una elipse, dentro se coloca un nombre

2) un rectángulo, como cualquier clase

Cliente

Sensor

Entre actantes y casos de uso, la asociación es el único tipo de conexión. Además, tiene semántica. comunicación de conmutación Por lo tanto, la transmisión de mensajes, es decir, el paso de mensajes, no suele marcarse ya que el contexto queda claro a partir de la notación de actantes y casos de uso. Pero puedes marcarlo y también indicar la multiplicidad de la conexión:

Cliente bancario

Multiplicidad(multiplicidad) caracteriza el número de instancias específicas de una clase que participan en una conexión determinada (un cliente puede emitir un número ilimitado de préstamos).

En general asociación Es una relación entre dos o más componentes del modelo. Dado que en la mayoría de los casos los componentes son algunas clases de objetos, una instancia de asociación es simplemente una lista ordenada de referencias a instancias específicas, quizás equipadas con atributos (propiedades) de asociación.

El nombre de la asociación, si existe, debe ser único. Se forma según el significado de las relaciones entre las clases que participan en la asociación. Por ejemplo, "Empleado trabaja en Gerente de departamento completa Computadora”, etc.

Las asociaciones son en sí mismas clases ( clase de asociación, clase de asociación), tiene propiedades tanto de clase como de asociación. Las instancias de esta clase son conexiones que no solo tienen enlaces a objetos, sino también valores de atributos (propiedades).

Los miembros de la asociación se llaman sus polos. Todos los polos son roles de las clases involucradas en la conexión, son distintos y pueden enumerarse en alguna lista ordenada. En la mayoría de los casos, las asociaciones son binarias (dos roles en una asociación con cierta semántica), pero también puede haber norte -ario. Una misma clase puede actuar en diferentes roles, es decir, estar simultáneamente en dos polos de la asociación.

La multiplicidad de conexiones se indica en los polos.

Las conexiones pueden aparecer y desaparecer durante el funcionamiento del sistema; las restricciones y los predicados correspondientes se pueden especificar en los polos de la asociación.

A veces la conexión cambia sólo en uno de los polos. Si un enlace tiene atributos, estos se pueden cambiar mediante operaciones; sin embargo, los enlaces a los participantes del enlace no cambian.

Una asociación se representa como una línea continua que conecta los límites de 2 clases si la asociación norte-ario, luego se dibuja un rombo (un signo de agregación):

		Muchas asociaciones - agregación
	asociación binaria

Los casos de uso no intercambian mensajes entre sí y solo pueden ser en relaciones (conexiones) extensiones(extender) inclusión(incluir) y generalizaciones(generalización).

EN con respecto a la expansión caso de uso: el cliente introduce una secuencia adicional de acciones, comenzando desde algún punto de la secuencia principal, y puede haber varias "inserciones" de este tipo. Todos estos puntos se llaman puntos de expansión.

Rational Unified Process (RUP) es una de las mejores metodologías de desarrollo de software, creada por Rational Software. Basado en la experiencia de muchos proyectos de software exitosos, el Proceso Unificado le permite crear sistemas de software complejos basados ​​en métodos de desarrollo industrial. Uno de los principales pilares en los que se basa RUP es el proceso de creación de modelos utilizando el Lenguaje Unificado de Modelado (UML). Este artículo trata sobre el uso de diagramas UML en el flujo de trabajo de desarrollo de sistemas de software utilizando la metodología Rational Software.

No es ningún secreto que la creación de software es un proceso complejo, que, por un lado, tiene mucho en común con la creatividad, y por otro, aunque es un negocio muy rentable, también es un negocio costoso. La feroz competencia en el mercado obliga a los desarrolladores a buscar métodos de trabajo más eficientes. Formas de crear sistemas de software en un tiempo aún más rápido, a menor costo y con mejor calidad. La complejidad de los programas aumenta constantemente. Hasta hace poco, los productos de software podían ser creados en un tiempo previsible por individuos o, por ejemplo, en el departamento de TI de una empresa automatizada.

Hoy en día, a las personas que crean programas de rodillas les queda el área de pequeñas utilidades y varios módulos de extensión para productos de software "pesados". El futuro pertenece al enfoque industrial de la creación de software. En 1913, Henry Ford inauguró la primera línea de montaje de automóviles y, en los años 90, se empezó a utilizar una línea de montaje similar en el campo de las tecnologías de la información. El desarrollo de equipos requiere un enfoque completamente diferente y una metodología diferente, que tarde o temprano hubo que crear.

Rational Software Corporation (http://www.rational.com) ha publicado una base de conocimientos estructurada llamada Rational Unified Process (RUP), que es un conjunto de recomendaciones integrales para crear casi cualquier producto de software. Habiendo absorbido la experiencia de los mejores desarrollos, RUP detalla cuándo, quién y qué se debe hacer en el proyecto para terminar con un sistema de software a tiempo, con una determinada funcionalidad y dentro del presupuesto asignado.

El proceso unificado puede considerarse como la suma de las diversas actividades de la empresa de desarrollo necesarias para traducir los requisitos del cliente en un sistema de software. Un sistema que proporcionaría “resultados significativos” a los usuarios y haría exactamente lo que esperan del sistema. Por lo tanto, el proceso está controlado por casos de uso del sistema o, de lo contrario, por precedentes.

Para implementar los requisitos del cliente a tiempo, el Proceso Unificado se divide en fases que constan de iteraciones, por lo que el proceso también se denomina iterativo e incremental. Cada iteración pasa por un ciclo de trabajo básico y lleva a los desarrolladores al objetivo final: crear un sistema de software. Durante las iteraciones, se crean artefactos intermedios que son necesarios para la finalización exitosa del proyecto y una versión del sistema de software que implementa un cierto conjunto de funciones, que aumenta de una iteración a otra. Las fases y principales flujos de trabajo del proceso se muestran en la Fig. 1, allí también se dan los costes laborales aproximados del trabajo por fase.

arroz. 1 fases de RUP y flujos de trabajo

Cabe señalar que en la Fig. 1 muestra sólo el trabajo principal del Proceso Unificado. Por ejemplo, las actividades de gestión de actividades no se muestran aquí para evitar saturar el diagrama.

Todo el desarrollo de software se considera en RUP como un proceso de creación de artefactos. Cualquier resultado del proyecto, ya sean textos fuente, módulos de objetos, documentos transferidos al usuario, modelos, son subclases de todos los artefactos del proyecto. Cada miembro del equipo del proyecto crea sus propios artefactos y es responsable de ellos. El programador crea el programa, el gerente crea el plan del proyecto y el analista crea el modelo del sistema. RUP le permite determinar cuándo, quién y qué artefacto debe crearse, modificarse o utilizarse.

Una de las clases más interesantes de artefactos de proyecto son los modelos, que permiten a los desarrolladores definir, visualizar, construir y documentar artefactos del sistema de software. Cada modelo es una visión autónoma del sistema que se está desarrollando y está destinado a delinear problemas y proponer soluciones. La autosuficiencia de modelos significa que un analista o desarrollador puede obtener toda la información que necesita de un modelo específico sin recurrir a otras fuentes.

Los modelos permiten considerar el sistema futuro, sus objetos y su interacción incluso antes de invertir importantes fondos en su desarrollo; permiten verlo a través de los ojos de los futuros usuarios desde el exterior y de los desarrolladores desde el interior, incluso antes de la primera línea de origen. Se crea el código. La mayoría de los modelos están representados por diagramas UML; puede leer más sobre UML, por ejemplo, en.

El Lenguaje Unificado de Modelado apareció a finales de los 80 y principios de los 90, principalmente gracias a los esfuerzos de los "tres amigos" Gradi Bucha, Jim Rambo e Ivar Jacobson. Ahora ha sido adoptado por el consorcio OMG como un lenguaje de modelado estándar que proporciona a los desarrolladores una notación clara que permite mostrar los modelos en elementos gráficos que generalmente son aceptados y comprendidos por todos en el proyecto.

Sin embargo, no debemos olvidar que el lenguaje de modelado proporciona solo una notación: una herramienta para describir y modelar un sistema, y ​​un proceso unificado determina la metodología para usar esta herramienta, así como otras herramientas de soporte metodológico de Rational. UML se puede utilizar sin una metodología específica porque es independiente del proceso y, sin importar qué opción de proceso se utilice, se pueden utilizar diagramas para documentar las decisiones tomadas durante el desarrollo y mostrar los modelos creados.

Un sistema de software se crea para resolver problemas específicos de los usuarios y no para que los programadores prueben nuevas tecnologías y adquieran experiencia para el director del proyecto. En general, al usuario no le importa si utiliza un enfoque orientado a objetos, UML, RUP o crea un sistema utilizando el método XP (programación extrema) en el proceso de desarrollo. El uso de ciertos métodos, tecnologías y la creación de la estructura interna óptima del proyecto permanece en la conciencia de los desarrolladores, quienes toman decisiones basadas en experiencias previas y sus propias preferencias. Sin embargo, el usuario no le perdonará que ignore sus requisitos. Incluso si un sistema de software se desarrolla diez veces utilizando métodos y tecnologías de última generación, si el usuario no obtiene lo que se llama un "resultado significativo", su proyecto de software fracasará estrepitosamente.

De esto se deduce que la aplicación irreflexiva de UML, simplemente porque está de moda, no solo no conducirá al éxito del desarrollo, sino que también puede causar insatisfacción entre los empleados que necesitan estudiar una gran cantidad de literatura adicional y los gerentes de proyectos cuando resulta que Los costos laborales en el proyecto aumentan y los rendimientos no aumentan. Debe comprender claramente lo que desea obtener al implementar esta tecnología y seguir este objetivo. El uso de UML ahorra recursos de desarrollo porque le permite tener una idea del sistema más rápido que cuando se crean diseños y prototipos, gastando incomparablemente menos recursos.

Los diagramas facilitan la comunicación entre los miembros del proyecto y, lo que es especialmente valioso, involucran a los usuarios finales del sistema en el proceso. El modelado permite reducir los riesgos del proyecto, ya que siempre es más fácil para los programadores hacer algo claro y comprensible que llegar a un resultado incierto. Crear diagramas es similar a crear un proyecto en construcción: puede prescindir de él, por ejemplo, al construir un cobertizo en una cabaña de verano, pero cuanto más grande es el edificio (en nuestro caso, un producto de software), más difícil es que hacer y más incierto será el resultado final.

Una vez impartí un seminario sobre RUP en una empresa de software que había tenido bastante éxito en el mercado durante diez años, pero que no utilizaba ningún modelado en su flujo de trabajo, sino que se basaba en prototipos. En la sala se reunieron una veintena de programadores jóvenes y experimentados, que escucharon atentamente todo lo que les conté sobre RUP y UML. Y uno de ellos, mirando el tablero cubierto de diagramas de ejemplo, comentó: "Todo esto es interesante y probablemente bueno para otros proyectos", dijo, "pero hemos estado trabajando durante bastante tiempo sin todo esto, ya que estamos Aún así nos las arreglamos sin UML, probablemente simplemente no lo necesitemos”.

Esta pregunta me hizo pensar que el cambio en los procesos de negocio que inevitablemente debe ocurrir en una empresa de desarrollo de software al implementar RUP y UML puede ser tan difícil como implementar un sistema de información en una empresa industrial, cualquier implementación es una ruptura de estereotipos. Dado que las calificaciones de los empleados de una empresa de desarrollo de software son bastante altas, es más difícil para esas personas abandonar sus puntos de vista que para los "simples mortales", y las dificultades y el rechazo que surgen pueden compararse con la transición de lo procedimental a lo objetual. pensamiento orientado.

1.Definición de requisitos

Un proceso unificado es un proceso impulsado por casos de uso que reflejan escenarios de interacción del usuario. De hecho, es la visión que tienen los usuarios del sistema de software desde fuera. Así, una de las etapas más importantes del desarrollo, según RUP, será la etapa de determinación de requisitos, que consiste en recoger todos los deseos posibles para el funcionamiento del sistema que sólo pueden venir a la mente de usuarios y analistas. Posteriormente, será necesario sistematizar y estructurar estos datos, pero en esta etapa, a través de entrevistas con los usuarios y el estudio de documentos, los analistas deben recopilar la mayor cantidad posible de requisitos para el futuro sistema, lo cual no es tan simple como parece a primera vista. Los usuarios a menudo no tienen idea de lo que deberían obtener al final. Para facilitar este proceso, los analistas utilizan diagramas de casos de uso (Fig. 2)

Fig 2. Ejemplo de un diagrama de casos de uso

El diagrama es un reflejo de los actores (actantes) que interactúan con el sistema y la reacción de los objetos de software a sus acciones. Los actantes pueden ser tanto usuarios como agentes externos que necesitan transmitir o recibir información. El ícono de caso de uso refleja la respuesta del sistema a la entrada externa y muestra lo que se debe hacer para el actante.

Para detallar un caso de uso específico, se utiliza un diagrama de actividades, cuyo ejemplo se muestra en la Figura 3.

arroz. 3 Ejemplo de diagrama de actividades

La simplicidad del diagrama de casos de uso permite a los analistas comunicarse fácilmente con los clientes durante el proceso de definición de requisitos, identificando las restricciones impuestas al sistema y a la implementación de requisitos individuales, como el tiempo de respuesta del sistema, que luego caen en la sección de no funcionales. requisitos.

También se puede utilizar un diagrama de casos de uso para crear escenarios de prueba, ya que todas las interacciones entre los usuarios y el sistema ya se han definido.

Para determinar correctamente los requisitos, los desarrolladores deben comprender el contexto (parte del área temática) en el que funcionará el futuro sistema. Para ello se crea un modelo de dominio y un modelo de negocio, que son diferentes enfoques ante un mismo tema. A menudo se crea una cosa: un modelo de dominio o un modelo de negocio.

La diferencia entre estos modelos es que el modelo de dominio describe los conceptos importantes con los que funcionará el sistema y sus conexiones entre sí. Mientras que un modelo de negocio describe los procesos de negocio (existentes o futuros) que el sistema debería soportar. Por tanto, además de definir los objetos de negocio que intervienen en el proceso, este modelo define a los trabajadores, sus responsabilidades y las acciones que deben realizar.

Para crear un modelo de dominio, se utiliza un diagrama de clases normal (Figura 6), pero claramente no es suficiente para crear un modelo de negocio. En este caso, se utiliza un diagrama de casos de uso utilizando iconos adicionales que reflejan la esencia de los procesos comerciales: estos son actantes comerciales, casos de uso comerciales, entidades comerciales y gestión comercial. Este modelo está mucho más cerca del siguiente modelo creado en el proceso de desarrollo: el modelo de análisis.

2.Análisis

Luego de determinar los requisitos y el contexto en el que operará el sistema, llega el momento de analizar los datos obtenidos. Durante el proceso de análisis, se crea un modelo analítico que guía a los desarrolladores hacia la arquitectura del futuro sistema. Un modelo analítico es una vista de un sistema desde adentro, a diferencia de un modelo de casos de uso, que muestra cómo se verá el sistema desde afuera.

Este modelo permite comprender cómo se debe diseñar el sistema, qué clases debe tener y cómo deben interactuar entre sí. Su objetivo principal es determinar la dirección de implementación de la funcionalidad identificada en la etapa de recopilación de requisitos y esbozar la arquitectura del sistema.

A diferencia del modelo de diseño que se crea posteriormente, el modelo de análisis es más un modelo conceptual y solo acerca a los desarrolladores a las clases de implementación. Este modelo no debe tener posibles contradicciones que puedan ocurrir en el modelo precedente.

Para mostrar el modelo de análisis usando UML, se usa un diagrama de clases con estereotipos (patrones de comportamiento) "clase límite", "entidad", "control" y diagramas de colaboración para detallar (Figura 4). El estereotipo de "clase límite" representa una clase que interactúa con actantes externos, el estereotipo de "entidad" representa clases que son almacenes de datos y el estereotipo de "control" representa clases que gestionan consultas a entidades.

Figura 4. Ejemplo de diagrama de colaboración

La numeración de los mensajes muestra su orden, pero el propósito del diagrama no es considerar el orden de los mensajes intercambiados, sino mostrar claramente las relaciones de las clases entre sí.

Si nos centramos en el orden de interacción, entonces otra representación sería un diagrama de secuencia (Sequence), que se muestra en la Figura 5. Este diagrama le permite observar el intercambio de mensajes a lo largo del tiempo, mostrando visualmente la secuencia del proceso. Cuando se utiliza una herramienta de creación de modelos como Rational Rose, estos dos tipos de diagramas se pueden crear automáticamente entre sí (puede leer más sobre Rational Rose, por ejemplo, en).

Arroz. 5 Ejemplo de diagrama de secuencia

La decisión de cuál de los dos diagramas crear primero depende de las preferencias de cada desarrollador. Dado que estos diagramas son una representación del mismo proceso, ambos le permiten reflejar la interacción entre objetos.

3.Diseño

La siguiente etapa en el proceso de creación de un sistema es el diseño, durante el cual se crea un modelo de diseño basado en los modelos creados anteriormente. Este modelo refleja la implementación física del sistema y describe el producto creado a nivel de clase y componente. A diferencia del modelo de análisis, el modelo de diseño tiene una clara dependencia de las condiciones de implementación, los lenguajes de programación y los componentes utilizados. Para una comprensión más precisa de la arquitectura del sistema, este modelo debe estar lo más formalizado posible y mantenerse actualizado durante todo el ciclo de vida de desarrollo del sistema.

Para crear un modelo de diseño, se utiliza un conjunto completo de diagramas UML: diagramas de clases (Fig. 5), diagramas de cooperación, diagramas de interacción, diagramas de actividad.

Fig 6. Ejemplo de un diagrama de clases

Además, este flujo de trabajo puede crear un modelo de implementación que se implementa en función de un diagrama de implementación. Este es el tipo de diagrama más simple diseñado para modelar la distribución de dispositivos en una red. Para la visualización sólo se utilizan dos opciones para los iconos del procesador y del dispositivo, junto con las conexiones entre ellos.

4.Implementación

La tarea principal del proceso de implementación es crear un sistema en forma de componentes: códigos fuente de programas, scripts, archivos binarios, módulos ejecutables, etc. En esta etapa, se crea un modelo de implementación que describe cómo se implementan los elementos del modelo de diseño y qué clases se incluirán en componentes específicos. Este modelo describe la forma de organizar estos componentes de acuerdo con los mecanismos de estructuración y modularización adoptados en el entorno de programación seleccionado y está representado por un diagrama de componentes (Fig. 7).

arroz. 7 Ejemplo de diagrama de componentes

5.Pruebas

Durante el proceso de prueba, se verifican los resultados de la implementación. Para este proceso, se crea un modelo de prueba, que consta de casos de prueba, procedimientos de prueba y componentes de prueba, pero no tiene una representación en diagrama UML, por lo que no nos detendremos en ello.

6. Conclusión

Aquí sólo se consideraron los principales procesos de la metodología Racional. RUP es bastante extenso y contiene recomendaciones para ejecutar varios proyectos de software, desde la creación de programas por un grupo de desarrolladores de varias personas hasta proyectos de software distribuidos que unen a miles de personas en diferentes continentes. Sin embargo, a pesar de sus enormes diferencias, los métodos para utilizar modelos creados con UML serán los mismos. Los diagramas UML, creados en varias etapas de desarrollo, son inseparables del resto de los artefactos de un proyecto de software y, a menudo, son el vínculo entre procesos RUP individuales.

La decisión de utilizar diagramas específicos depende del proceso de desarrollo establecido en la empresa, que aunque se denomina unificado, no es algo congelado. Rational no sólo ofrece mejorarlo y refinarlo, sino que también proporciona herramientas especiales para realizar cambios en la base de datos RUP.

Pero en cualquier caso, el uso de UML junto con un proceso unificado permitirá obtener un resultado predecible, cumplir con el presupuesto asignado, aumentar el impacto de los participantes del proyecto y la calidad del producto de software creado.

Krátchen. F. Introducción Proceso racional unificado . Ed. 2º - M.: Williams Publishing House, 2002. - 240 págs.: ill.

Jacobson A., Buch G., Rambo J. Proceso unificado de desarrollo de software - San Petersburgo: Peter, 2002. - 496 págs.: ill.

Fowler M., Scott K. UML en pocas palabras. Aplicación de un lenguaje estándar de modelado de objetos: Transl. De inglés – M.:Mir, 1999. – 191 p., enfermo.

Arroyo. E. Programación extrema. – San Petersburgo: Peter, 2002. – 224 p.: ill.

TrofimovS. Tecnologías CASE: Trabajo práctico en Rational Rose.
Ed. 2do - M.: Binom-Press, 2002 - 288 p.

Unified Process utiliza activamente el lenguaje de modelado unificado ( UML). en el nucleo UML Se encuentra un modelo que permite al equipo de desarrollo comprender de forma simplificada la variedad de procesos complejos necesarios para el desarrollo de software. Varios modelos utilizados en Proceso unificado, le permiten visualizar el sistema, describir su estructura y comportamiento, y documentar las decisiones tomadas durante el proceso de desarrollo.

Historia de origen

Los orígenes del marco se encuentran en el trabajo de un empleado. Ericson Ivar Jacobson, publicado a finales de los años 1960. Jacobson y sus colegas modelaron enormes sistemas de telecomunicaciones utilizando capas de "bloques" (lo que más tarde se conoció como "componentes"): las capas inferiores sirvieron de base para los subsistemas de las capas superiores. El equipo construyó los bloques inferiores considerando "casos de tráfico" que podrían sucederles a los usuarios del sistema. Fueron estos "incidentes" los que se convirtieron en el prototipo de casos de uso, que luego se incluyeron en UML. El trabajo de Jacobson también inspiró la creación de diagramas utilizados en UML, incluidos diagramas de actividad y secuencia .

En 1987, Jacobson fundó su propia empresa. Objetoria AB y junto con sus socios pasaron varios años desarrollando un proyecto y producto llamado Objetoria. En 1995, Jacobson publicó el libro “ Ingeniería de software orientada a objetos”, que describe un proceso de desarrollo impulsado por los requisitos del cliente que se traducen en el producto final a través de casos de uso. El lanzamiento del libro coincidió con la primera publicación de la versión online del kernel. Proceso unificado.

En 1995 la empresa Objetoria AB absorbido por la corporación Racional. Con la ayuda de un número significativamente mayor de colegas, Jacobson comienza a ampliar el proceso. Objetoria, complementándolo con herramientas para la gestión y desarrollo de proyectos. Junto con Grady Booch y James Rumbaugh, quienes trabajaron en Racional Anteriormente, Jacobson se convirtió en miembro del grupo de “tres amigos”, quienes lideraron el trabajo para crear un proceso llamado Proceso de objeción racional (ROP), así como la distribución Proceso unificado, que se convirtió en la base de Lenguaje de modelado unificado.

En el proceso de trabajar en ROP Y UML, corporación Racional Continuaciones de fusiones y adquisiciones de empresas involucradas en la creación de herramientas de desarrollo de software. Estas herramientas proporcionaron capacidades para la gestión de requisitos ("RequisitePro"), pruebas generales ("SQA"), pruebas de rendimiento, gestión de configuración y gestión de cambios. En 1998 Racional cambia el nombre del producto a RUP, cuyo núcleo conceptual sigue siendo Proceso unificado.

Características

Proceso unificado Residencia en casos de uso, describiendo uno o más actores que interactúan con el sistema y obtienen resultados que son valiosos para los participantes en el proceso. Son los casos de uso los que son la principal fuerza impulsora que impulsa todo el proceso de desarrollo, comenzando con la recopilación y discusión de los requisitos y terminando con el análisis, el diseño y la implementación. Los casos de uso se describen en un lenguaje sencillo y comprensible, para que sean comprensibles para un lector externo.

De acuerdo a Proceso unificado, en el centro del proceso de desarrollo se encuentra arquitectura- la organización fundamental de todo el sistema. Puede incluir elementos estáticos y dinámicos, su interacción y permite resolver problemas de eficiencia del producto, extensibilidad, capacidad de reutilización de elementos y ayudar a superar limitaciones económicas y técnicas. El equipo del proyecto comienza a trabajar en la descripción de la arquitectura lo antes posible y la amplía y mejora constantemente durante el proceso de desarrollo. La arquitectura se considera un aspecto importante. Proceso unificado por una serie de razones, cuya clave es la capacidad de ver la imagen completa de lo que está sucediendo, la aplicación correcta de los esfuerzos de los desarrolladores, la facilitación de oportunidades para reutilizar componentes, el desarrollo de sistemas y la selección correcta de casos de uso.

El tercer principio fundamental Proceso unificado es el uso enfoque iterativo e incremental. Las iteraciones son proyectos en miniatura que le permiten lanzar una versión más nueva del sistema. El resultado de la iteración, los cambios realizados en el sistema, se denomina incremento. En particular, el enfoque iterativo le permite mejorar constantemente la arquitectura del sistema, manejar cambios constantes en los requisitos y ajustar de manera flexible el plan de todo el proyecto. El compromiso con el principio de integración continua le permite identificar posibles problemas en una etapa temprana. Además, la iteración ayuda a minimizar los riesgos asociados con las limitaciones técnicas, la arquitectura y los requisitos cambiantes.

Fases de desarrollo

Tamaño relativo de las fases de desarrollo de un proyecto típico

Cada ciclo de desarrollo, según Proceso unificado, consta de cuatro fases, que representan el período de tiempo entre hitos importantes del proyecto, lo que permite a los gerentes tomar decisiones importantes con respecto a la continuación del proceso de desarrollo, el alcance del trabajo, el presupuesto y el cronograma.

Variedades de flujo de trabajo

Adentro Proceso unificado En cada fase de desarrollo, existen cinco tipos de procesos de trabajo: requisitos, análisis, diseño, implementación y pruebas.

Cada proceso es un conjunto de actividades realizadas por diferentes miembros del equipo del proyecto. Por lo tanto, el objetivo de los procesos de recopilación de requisitos es crear un modelo de casos de uso que permita identificar los requisitos funcionales básicos para el sistema. Los procesos de análisis y el modelo correspondiente permiten a los desarrolladores estructurar los requisitos funcionales; El proceso de diseño describe la implementación física de los casos de uso y es una abstracción para el siguiente modelo. El proceso y el modelo de implementación describen cómo los elementos de diseño se relacionan con los componentes de software, incluido el código fuente, las bibliotecas dinámicas, etc. El último modelo, que describe las pruebas, explica qué pruebas del sistema y pruebas unitarias deben realizarse y cómo debe realizarlas el equipo de desarrollo.

Iteraciones e incrementos

Cada una de las fases descritas en el Proceso Unificado consta de iteraciones, que son subproyectos en miniatura de duración limitada. Normalmente, cada iteración incluye los cinco elementos del flujo de trabajo en distintos grados. El resultado de la iteración es incremento, una versión que contiene mejoras respecto a la versión anterior del producto.

Proceso racional unificado(RUP) es un marco tecnológico de desarrollo de software desarrollado y comercializado por Rational Software. Incorpora las mejores prácticas globales en el desarrollo de software y proporciona un enfoque disciplinario para asignar y gestionar tareas y responsabilidades dentro de una organización de desarrollo de software. Al aplicar este proceso, los equipos de desarrollo de software podrán crear software de alta calidad que satisfaga las necesidades de sus usuarios finales y hacerlo dentro de un cronograma y presupuesto predecibles.

RUP guía a los profesionales del software para que apliquen eficazmente las mejores prácticas actuales, como desarrollo iterativo, solicitud enfoque centrado en la arquitectura, casos de uso, reducción de riesgos en todas las etapas del proceso y verificación continua del programa.

El Proceso Unificado Racional se basa en varios principios fundamentales, recopilados de muchos proyectos exitosos:

· Empiece a atacar los principales riesgos antes y conduzca de forma continua, o ellos mismos pasarán a la ofensiva contra usted.

· Garantizar que se cumplan los requisitos del cliente.

· Concéntrese en el programa que se está ejecutando.

· Adaptarse al cambio desde el inicio del proyecto.

· Establecer una arquitectura ejecutable tempranamente.

· Construir un sistema a partir de componentes.

·Trabajar juntos como un equipo.

· Hacer de la calidad una forma de vida, no una ocurrencia tardía.

Usos de RUP enfoque iterativo Cada iteración realiza un poco de trabajo, análisis, diseño, implementación y prueba de requisitos. Cada iteración se basa en los resultados de iteraciones anteriores y produce un programa ejecutable que se acerca un paso más al producto final.

RUP proporciona enfoque estructurado para el desarrollo iterativo, dividiendo el proyecto en cuatro fases: Inicio, Diseño, Construcción e Implementación. Cada fase va acompañada de un llamado hito, un punto de control del proceso, en el que se verifica el logro de los objetivos de la siguiente fase y se toma una decisión sobre la transición (o no) a la siguiente fase. Por lo tanto, cada una de las cuatro fases de RUP tiene un hito y un conjunto de objetivos claramente definidos. Estos objetivos se utilizan para determinar qué tareas realizar y qué artefactos crear. Cada fase se centra estrictamente en lo que sólo es necesario para lograr los objetivos comerciales de la fase.

Todos los elementos del proceso - roles, tareas, artefactos y relacionado conceptos, guías y plantillas agrupados en contenedores lógicos llamados Disciplinas(Disciplinas). Sólo hay nueve disciplinas en el producto RUP estándar. Estos incluyen: modelado de negocios, gestión de requisitos, gestión de proyectos, gestión de cambios y medio ambiente.

Cada flujo de trabajo de proceso: recopilación de requisitos, análisis, diseño, implementación y prueba define un conjunto de artefactos y actividades asociados. Recuerde que un artefacto es un documento, informe, elemento ejecutable, etc. Artefacto pueden producirse, procesarse o consumirse.

Modelo- el tipo de artefacto más importante. Se proporcionan nueve modelos que juntos cubren todas las soluciones para visualización, especificación, diseño y documentación de sistemas de software:

· modelo de negocio. Define la abstracción de la organización para la cual se crea el sistema;

· modelo de dominio. Corrige el entorno contextual del sistema;

· Caso de uso del modelo. Define los requisitos funcionales del sistema.

· modelo de análisis. Interpreta los requisitos del sistema en términos del modelo de diseño;

· modelo de diseño. Define el vocabulario de dominio del problema y su solución;

· modelo de colocación. Define la topología de hardware en la que se ejecuta el sistema;

· modelo de implementación. Define las piezas que se utilizan para ensamblar e implementar un sistema físico;

· modelo de prueba. Define casos de prueba para probar el sistema;

· modelo de proceso. Define paralelismo en el sistema y mecanismos de sincronización.

Artefactos técnicos se dividen en cuatro conjuntos principales:

· conjunto de requisitos. Describe Qué el sistema debería funcionar;

· conjunto de diseño.

· conjunto de implementaciones. Describe el ensamblaje de los componentes de software desarrollados;

· conjunto de colocación. Proporciona toda la información sobre la configuración suministrada.

Conjunto de requisitos puede incluir un modelo de caso de uso, un modelo de requisitos no funcionales, un modelo de dominio, un modelo de análisis y otras formas de expresar las necesidades del usuario.

Conjunto de diseño puede incluir un modelo de diseño, un modelo de prueba y otras formas de expresar la esencia del sistema.

Conjunto de implementaciones agrupa todos los datos sobre los elementos de software que componen el sistema (código de programa, archivos de configuración, archivos de datos, componentes de software, información del ensamblaje del sistema).

Conjunto de ubicación agrupa toda la información sobre embalaje, envío, instalación y puesta en marcha del sistema.

Cada proceso tecnológico va acompañado riesgo. Al desarrollar un producto de software, un resultado insatisfactorio (UN) puede ser: exceso del presupuesto, baja confiabilidad, funcionamiento incorrecto, etc. El impacto del riesgo se calcula utilizando la expresión

Indicador de Riesgo = Probabilidad (LP) * Pérdida (LP).

Gestión de riesgos incluye seis acciones:

1. Identificación de riesgos: identificar elementos de riesgo en el proyecto.

2. Análisis de riesgos: evaluación de la probabilidad y magnitud de la pérdida para cada elemento de riesgo.

3. Clasificación de riesgos: ordenar los elementos de riesgo según el grado de su influencia.

4. Planificación de la gestión de riesgos: preparación para afrontar cada elemento de riesgo.

5. Resolución de riesgos – eliminación o resolución de elementos de riesgo.

6. Monitoreo de riesgos: rastrear la dinámica de los elementos de riesgo y tomar acciones correctivas.

Las tres primeras acciones pertenecen a la etapa de evaluación de riesgos, las tres últimas acciones a la etapa de control de riesgos.

Hay tres categorías de fuentes de riesgo: riesgo de proyecto, riesgo técnico y riesgo comercial. Después de identificar los elementos de riesgo, se debe cuantificar su impacto en el proyecto de software y resolver las dudas sobre posibles pérdidas. Estas cuestiones se abordan durante el paso del análisis de riesgos. Y finalmente, en el plan general del proyecto de software se integra un plan para gestionar cada elemento de riesgo, es decir, un conjunto de funciones para gestionar cada elemento de riesgo.