Formas de utilizar UML en el desarrollo de software.

UML es para modelado. Los propios autores de UML definen a su descendencia de la siguiente manera.

lenguaje UML es un lenguaje de modelado gráfico de propósito general para especificar, visualizar, diseñar y documentar todos los artefactos creados durante el desarrollo de sistemas de software.

Estamos totalmente de acuerdo con esta definición, y no solo aprobamos la elección de las palabras clave, sino que damos gran importancia al orden en que se enumeran.

1.2.1. Especificación

Por lo general, al menos dos actores están involucrados en el proceso de desarrollo de la aplicación: cliente(una persona específica o grupo de personas u organización) y desarrollador(podría ser un programador solitario, un equipo de proyecto temporal o toda una organización especializada en el desarrollo de software). Debido al hecho de que hay dos personajes, mucho depende del grado de comprensión mutua.

Uno de los pasos clave en el desarrollo de una aplicación es determinar qué requisitos debe cumplir la aplicación que se está desarrollando. Como resultado de esta etapa, aparece un documento formal o informal (artefacto), que recibe diferentes nombres y significa aproximadamente lo mismo: planteamiento del problema, requisitos, términos de referencia, especificaciones externas, etc.

Similares en propósito, pero quizás diferentes en forma y contenido, los artefactos también aparecen en otras etapas de desarrollo, especialmente si muchos actores están incluidos en el desarrollo. También se utilizan varios nombres para ellos: especificaciones funcionales, arquitectura de aplicaciones, etc. A todos estos artefactos los llamaremos especificaciones.

Especificación es una descripción declarativa de cómo funciona o funciona algo.

Deben tenerse en cuenta tres interpretaciones de las especificaciones.

• El que significa el actor que es la fuente de la especificación (por ejemplo, el cliente).
• Lo que se entiende por el actor que es el consumidor de la especificación (por ejemplo, el desarrollador).
• Aquello que está objetivamente condicionado por la naturaleza del objeto especificado.

Estas tres interpretaciones de las especificaciones pueden no coincidir y, desafortunadamente, como muestra la práctica, muy a menudo no coinciden, y de manera significativa. El cliente puede desconocer sus necesidades objetivas, o malinterpretarlas, o ser engañado sobre la naturaleza de su situación, tratando de tratar los síntomas en lugar de la causa de su enfermedad comercial con una aplicación de oficina personalizada. Es posible que el desarrollador no comprenda el área temática del cliente e interprete la redacción de la especificación de una manera completamente incorrecta. Si el desarrollador está involucrado en la formulación de las especificaciones, el abuso de la terminología técnica puede desorientar completamente al cliente.

Propósito principal UML- proporcionar, por un lado, más bien formal, Por otro lado, lo suficientemente cómodo, y, por la tercera parte, bastante versátil, en cierta medida reducen el riesgo de discrepancias en la interpretación de las especificaciones.

1.2.2. Visualización

Hay un dicho famoso que dice que es mejor ver una vez que escuchar cien veces. Agregaremos: más aún, lea el recuento mil veces. Las características de la percepción humana son tales que el texto con imágenes se percibe más fácilmente que el texto simple. Y las imágenes con texto (esto se llama "cómics") son aún más fáciles. Los modelos UML se pueden representar en forma de imágenes, y estas imágenes son claras, intuitivas, casi inequívocamente interpretadas y fáciles de componer. De hecho, el desarrollo y detalle de esta tesis constituye la mayor parte del contenido del resto del libro. No nos adelantaremos y simplemente daremos un ejemplo sin ninguna explicación.

¿Hay algo que no esté claro?

Por lo tanto, el segundo propósito más importante de UML es servir como un medio adecuado de comunicación entre las personas. Por supuesto, la visualización de los modelos UML solo importa si los humanos los van a componer o comprender; este propósito de UML no tiene nada que ver con las computadoras.

La representación gráfica de un modelo UML no es idéntica al modelo en sí. Este punto importante a menudo se pasa por alto cuando se introduce UML por primera vez.

1.2.3. Diseño

En el original, este propósito de UML se define con la palabra construcción, que expresamos con el término cuidadoso "diseño". El punto es que UML está destinado no solo a describir modelos de aplicaciones abstractos, sino también a manipular directamente los artefactos que componen estas aplicaciones, incluido el código del programa. En otras palabras, uno de los propósitos de UML es, por ejemplo, crear modelos para los cuales sea posible generación automática de código(o fragmentos de código) de las respectivas aplicaciones. Además, la naturaleza de los modelos UML es tal que también es posible el proceso inverso: construir automáticamente un modelo a partir del código de una aplicación terminada.

En inglés, la construcción automática de un modelo basado en el código de una aplicación terminada se denomina ingeniería inversa y generalmente se traduce al ruso como "ingeniería inversa". Categóricamente no nos gusta esta traducción: ¿qué tipo de diseño es este y por qué es todo lo contrario? Existe una buena alternativa: "análisis de ingeniería de programas", pero aún no ha recibido distribución.

Lo dicho en el párrafo anterior requiere reservas "hasta cierto punto", "hasta cierto punto" literalmente después de cada afirmación. Lo más molesto es que por el momento no es posible indicar con precisión el "grado" y la "medida". La razón no es que nadie se haya molestado en hacerlo, sino que es una tarea muy difícil, pero no desesperada. Las herramientas que admiten UML mejoran constantemente, por lo que en el futuro, el tercer propósito de UML puede destacarse.

Para algunos desarrolladores que están cansados ​​​​de la depuración interminable, puede parecer que vale la pena aprender UML y todos los problemas de programación se resolverán. Desafortunadamente, esto no es así.

1.2.4. Documentación

Los modelos UML son artefactos que se pueden almacenar y utilizar tanto en forma de documentos electrónicos como en forma de copia impresa. Se ha hecho mucho en las versiones recientes de UML para adaptarse mejor a este propósito. En particular, se especifica la representación de modelos UML en forma de documentos XMI, lo que proporciona una interoperabilidad práctica a la hora de trabajar con modelos. En otras palabras, los modelos UML no son cosas en sí mismas que solo pueda admirar: son documentos que se pueden usar de varias maneras, desde imprimir imágenes hasta generar automáticamente descripciones de texto legibles por humanos.

XMI (XML Metadata Interchange) es un formato de datos externo basado en el lenguaje XML (esquema y un conjunto de reglas para el uso de etiquetas) diseñado para serializar modelos e intercambiarlos.

Explique la última oración del párrafo anterior. El estándar requiere que en la representación interna del modelo, cada elemento de modelado tenga un lugar donde se pueda almacenar una descripción textual informal de este elemento. La mayoría de las herramientas cumplen con este requisito: literalmente, para cada línea o figura del diagrama, puede ingresar texto que explique el significado y el propósito de esta línea o figura en particular. Además, muchas herramientas pueden ensamblar documentos de texto completos, bastante significativos y bien formateados a partir de estas descripciones de texto, que se pueden usar exactamente como descripciones de texto familiares del sistema que se está modelando. Desafortunadamente, esta maravillosa oportunidad en la práctica se usa menos de lo que merece. El hecho es que así como a los programadores no les gusta y son demasiado perezosos para escribir comentarios significativos en el código del programa, a los arquitectos no les gusta y son demasiado perezosos para escribir explicaciones textuales para sus diagramas.

1.2.5. Lo que UML NO es

No debes pensar que UML es una panacea para todos los niños ∇ Programando enfermedades. Para una comprensión clara del propósito y alcance de UML, es útil comparar UML con otros fenómenos relacionados.

∇ Las tecnologías de la información tienen al menos medio siglo de antigüedad; todavía es la infancia de un nuevo campo de la actividad humana.

Primeramente, UML no es un lenguaje de programación(aunque no se desaconseja la generación de código, consulte la sección 1.2.3). No es que UML sea un lenguaje gráfico, pero la gran mayoría de los lenguajes de programación prácticos son lenguajes basados ​​en texto. Mucho más importante es que los modelos UML no están definidos semántica operativa, es decir, no se define la forma en que se ejecutan los modelos en la computadora. Esto se hace de manera bastante deliberada, de lo contrario, UML dependería de algún modelo de computabilidad, el nivel de abstracción de sus conceptos tendría que reducirse significativamente y no cumpliría su propósito principal: servir como un medio para especificar aplicaciones y otros sistemas en cualquier nivel de abstracción y en diversas áreas temáticas.

En segundo lugar, UML no es una especificación de herramienta(aunque las herramientas están implícitas y disponibles, como Magic Draw, Rational Rose Enterprise, Visual Paradigm, Enterprise Architect, etc.). El lenguaje en sí mismo no impone de ninguna manera cómo debe ser apoyado por herramientas. La solución de todos los problemas relacionados con la implementación de UML en una computadora está completamente a merced de los desarrolladores de herramientas.

En tercer lugar, UML no es un modelo para el proceso de desarrollo de aplicaciones(aunque se necesita un modelo de proceso de desarrollo y hay muchos modelos diferentes propuestos por diferentes autores). Por supuesto, los autores de UML tienen su propio modelo de proceso: Rational Unified Process (RUP), que no pudieron evitar tener en cuenta al desarrollar el lenguaje, pero, sin embargo, hicieron todo lo posible para eliminar la influencia directa de RUP. en UML y hacer que UML se pueda utilizar en cualquier modelo de proceso o incluso sin él.

Los autores de este libro también tienen sus propias opiniones sobre la relación entre UML y el modelo de proceso de desarrollo de software (ver Sección 5.2), que no pueden sino afectar la descripción de la pragmática del lenguaje, pero dondequiera que se note tal influencia, se deben hacer las reservas apropiadas. son hechos.

1.2.6. Maneras de usar el UML

De lo anterior, se puede ver que UML está diseñado para resolver varios problemas, respectivamente, se puede usar y usar en la práctica de diferentes maneras. A continuación, enumeramos las diversas formas en que se puede utilizar UML.

dibujo de imagen. Las herramientas de gráficos UML pueden y deben usarse sin tener en cuenta todo lo demás. Incluso dibujar diagramas con un lápiz sobre papel le permite agilizar sus pensamientos y capturar por sí mismo información esencial sobre la aplicación u otro sistema que se está modelando.

Intercambio de información. La comunidad de personas que usan y entienden UML está creciendo rápidamente. Si usa UML, los demás lo entenderán y los entenderá "de un vistazo".

Especificación de sistemas. Esta es la forma más importante de utilizar UML. Y aunque UML no es un medio de especificación absolutamente adecuado en todos los casos, esperamos que a medida que se desarrolle el lenguaje, habrá cada vez menos excepciones en las que UML no sea aplicable.

Reutilización de soluciones arquitectónicas. La reutilización de soluciones desarrolladas previamente es la clave para aumentar la eficiencia. Nuestra opinión sobre este asunto se presenta en la Sección 5.2. Desafortunadamente, hasta ahora los modelos UML se han reutilizado de forma muy limitada.

El caso de uso "dibujar diagramas" se refiere a dibujar diagramas UML con el fin de pensar, compartir ideas entre personas, documentar y similares. El resultado que es significativo para el usuario Usuario en este caso es la imagen de los propios gráficos. En términos generales, en este caso de uso del lenguaje, no se necesita realmente una herramienta de apoyo. A veces, dibujar diagramas a mano con un rotulador y luego fotografiarlos con una cámara digital puede ser más práctico.

El caso de uso de modelado implica la creación y modificación de un modelo de sistema en términos de los elementos de modelado proporcionados por el metamodelo UML. Un resultado significativo en este caso es un artefacto legible por máquina con una descripción del modelo. Para abreviar, simplemente nos referiremos a tal artefacto como modelo, nos referiremos a la actividad de producir el modelo como modelado y nos referiremos al sujeto del modelado como el arquitecto.

El desarrollo de casos de uso ("Desarrollo de aplicaciones") implica un detallado modelado, implementación y prueba de la aplicación en términos de UML. El resultado significativo para el usuario desarrollador en este caso es una aplicación funcional que se puede compilar en un lenguaje compatible con un sistema de programación en particular o que el entorno de tiempo de ejecución de la herramienta puede interpretar de inmediato. Este caso de uso es el más difícil de implementar.

Las herramientas modernas soportan estos casos de uso lejos de ser iguales. Todas las herramientas son capaces (bien o mal) de visualizar todo tipo de diagramas UML, algunas herramientas le permiten construir un modelo que permite un uso posterior, pero solo unas pocas herramientas pueden generar código ejecutable, y luego, de ninguna manera, no para todos los diagramas. Hay muchas razones prácticas y organizativas por las que los casos de uso anteriores son desiguales y tienen diversos grados de compatibilidad con las herramientas modernas. Consideraremos algunas de estas razones en capítulos posteriores.

Actualmente, Rational Software es el líder indiscutible en el campo del análisis y diseño orientado a objetos de sistemas de información con arquitectura de componentes. La metodología desarrollada por esta empresa, basada en el uso de un lenguaje de modelado unificado (UML - Unified Modeling Language es adoptado actualmente por OMG como estándar), se apoya en toda una gama de herramientas de modelado visual, desarrollo colaborativo (los principales lenguajes de programación ​​C ++, Java, Visual Basic, SmallTalk, etc., así como entornos de desarrollo populares: MS Visual Studio, Delphi, PowerBuilder), pruebas y documentación automatizadas, que cubren el ciclo de vida de la creación de sistemas de software.

Además de Rational Rose, un producto de Rational Software, las herramientas de modelado visual populares que admiten los estándares UML incluyen Paradigm Plus (un producto de software de PLATINUM Technology), SELECT (Software SELECT), Oracle Designer (Oracle), Together Control Center (Borland) , AllFusion Component Modeler (Computer Associates) y Microsoft Visual Modeler (Rational Software y Microsoft Corporation).

Rosa racional. Una popular herramienta de modelado visual para sistemas de información orientados a objetos de Rational Software Cogr. El funcionamiento del producto se basa en el lenguaje de modelado universal UML (Universal Modeling Language). Gracias a su lenguaje de modelado único, Rational Rose es capaz de resolver casi cualquier problema en el diseño de sistemas de información: desde el análisis de procesos de negocio hasta la generación de código en un lenguaje de programación específico. Solo Rose le permite desarrollar modelos de alto y bajo nivel, implementando así un diseño abstracto o un diseño lógico.

Rational Rose admite ingeniería directa e inversa en lenguajes: ADA, Java, C, C++, Basic. Soporta tecnologías COM, DDL, XML. Le permite generar esquemas Oracle y SQL.

Rational Rose tiene una API abierta que le permite crear sus propios módulos para lenguajes de programación específicos.

Seleccione Yourdon. Este sistema fue desarrollado por Select Software Tools Ltd. (Inglaterra). Select Yourdon admite las fases de análisis de requisitos y diseño del sistema de software, cubriendo todo el período de desarrollo inicial hasta la codificación del módulo. Se admiten los siguientes tipos de métodos estructurales (diagramas):

• diagramas de entidad-relación;
• diagramas de flujo de datos y control basados ​​en la notación de Yourdon/Ward & Mellor y Hatley;
• diagramas de transición de estado;
• especificaciones de mini procesos;
• diagramas estructurales de Constantino;
• Diagramas estructurales de Jackson.

Los tres primeros tipos de diagramas y especificaciones de miniprocesos se pueden utilizar para analizar y formular requisitos de software, los dos últimos, para diseñar la arquitectura de software y sus módulos individuales. La base de datos del proyecto se concentra en el llamado Diccionario de Datos. El sistema admite tanto el trabajo de un solo usuario como el trabajo en red de un equipo de desarrolladores.

Diseñador de Oracle. El kit de herramientas Oracle Designer ofrece una solución integrada para desarrollar sistemas de aplicaciones empresariales para aplicaciones Web y cliente/servidor. Oracle Designer participa en cada fase del ciclo de vida del desarrollo de software, desde el modelado de procesos comerciales hasta la implementación. El uso de un único repositorio permite utilizar cualquiera de sus componentes para el rápido desarrollo de aplicaciones distribuidas escalables y multiplataforma.

La tarea de Oracle Designer es recopilar datos sobre las necesidades de los usuarios y automatizar la construcción de aplicaciones gráficas flexibles. Oracle Designer se usa no solo para crear aplicaciones, sino también para realizar un seguimiento de los cambios que inevitablemente ocurren durante la operación del sistema.

Los modelos gráficos de definición de proyectos integrados con el repositorio multiusuario facilitan mucho el trabajo con Oracle Designer. Las herramientas se construyen sobre la base de metodologías generalmente aceptadas que cubren todo el ciclo de vida del desarrollo. Esto proporciona flexibilidad y un enfoque abierto para el desarrollo de software al usar solo aquellas partes del producto que se requieren para una tarea determinada. El proceso de desarrollo es compatible con RAD, JAD, diseño de información, cascada, enfoques iterativos y específicos de la empresa.

Modelador visual de Microsoft. Microsoft Visual Modeler (MSVM), una herramienta de modelado visual desarrollada por Rational Software en asociación con Microsoft Corporation, proporciona modelado basado en UML para diseñar aplicaciones basadas en componentes. Los modelos creados con MSVM pueden generar automáticamente código objeto para proyectos implementados en los entornos de desarrollo de Visual Basic 6.0 y Visual C++.

Microsoft Visual Modeler es compatible con la arquitectura de aplicaciones de Internet distribuidas de Windows (Windows DNA), que permite a los desarrolladores empresariales crear aplicaciones comerciales escalables de varios niveles que se pueden instalar en cualquier red.

La última versión de Microsoft Visual Modeler ofrece un nivel de integración sin precedentes entre el modelado visual y el entorno de desarrollo de Visual Studio, que incluye características actualizadas tanto para desarrolladores de Visual Basic como para soporte de desarrollo de Visual C++.

Windows DNA, Visual Studio y Microsoft Visual Modeler (MSVM) brindan la combinación correcta de infraestructura y herramientas de diseño para crear la próxima generación de aplicaciones basadas en componentes de n niveles.

MSVM facilita la creación de aplicaciones comerciales complejas y en capas basadas en el ADN de Windows al permitir que los desarrolladores visualicen la organización de sus aplicaciones de forma gráfica.

Las nuevas funciones de Microsoft Visual Modeler incluyen la integración con el sistema de control de versiones Microsoft Visual SourceSafe; integración con Microsoft Visual Manager (VCM) y soporte mejorado de Microsoft Repository para el desarrollo de Visual Basic. Las extensiones de Visual Modeler para respaldar el desarrollo del equipo incluyen la capacidad de publicar modelos en un repositorio a través de VCM; los modelos se pueden ver y compartir entre los miembros del equipo de diseño. Los componentes se pueden importar desde el repositorio a través de VCM utilizando la técnica de arrastrar y soltar. Del mismo modo, los componentes de la interfaz COM se pueden importar desde el Explorador de Windows.

Microsoft Visual Modeler, la herramienta más fácil de aprender de la familia Rational Rose, la herramienta de modelado visual líder en el mundo, comparte una base de código común y ofrece un conjunto escalable, integrado y totalmente interoperable de soluciones de modelado visual para programadores que utilizan Visual Basic y/o o Visual C++. Visual Modeler admite el lenguaje de modelado unificado (UML), diseñado de tal manera que incluso los desarrolladores sin experiencia en modelado visual pueden dominarlo fácilmente y crear modelos con éxito.

Familia de productos AllFusion. Component Modeler es el componente base de AllFusion Modeling Suite de Computer Associates. La suite también incluye: Process Modeler (anteriormente BPwin), que combina procesos comerciales, flujo de datos y modelado de flujo de trabajo en una herramienta fácil de usar; ERwin Data Modeler (anteriormente ERwin) para el modelado de bases de datos y Data Model Validator (anteriormente ERwin Examiner) para mejorar la consistencia y la calidad de los modelos de datos. Component Modeler y ERwin Data Modeler trabajan juntos para permitir que los desarrolladores y analistas de bases de datos transformen la información en bases de datos relacionales en una forma adecuada para su uso por aplicaciones orientadas a objetos. Los modelos de procesos de negocios de Process Modeler se pueden sincronizar con los modelos de datos de ERwin Data Modeler para proporcionar un soporte óptimo para los procesos de negocios de una organización.

La familia AllFusion consta de herramientas para la gestión de procesos y proyectos, modelado y desarrollo, publicación de conocimientos y visualización. La familia de software AllFusion mejora la capacidad de automatizar los procesos del ciclo de vida de las aplicaciones de misión crítica para satisfacer las necesidades de un mundo de comercio electrónico cada vez más complejo y cambiante.

La mayoría de los métodos existentes de análisis y diseño orientados a objetos (OOAD) incluyen tanto un lenguaje de modelado como una descripción del proceso de modelado. lenguaje de modelado es una notación (principalmente gráfica) que utiliza el método para describir proyectos.

Notación es una colección de objetos gráficos que se utilizan en modelos; es la sintaxis de un lenguaje de modelado. Por ejemplo, la notación de diagrama de clases define cómo se representan elementos y conceptos como clase, asociación y multiplicidad.

Proceso es una descripción de los pasos a seguir en el desarrollo del proyecto.

Lenguaje unificado de modelado UML(Unified Modeling Language) es el sucesor de la generación de métodos OOAP que surgieron a finales de los 80 y principios de los 90.

lenguaje UML es un lenguaje de modelado visual de propósito general diseñado para la especificación, visualización, diseño y documentación de componentes de software, procesos comerciales y otros sistemas. El lenguaje UML es una herramienta de modelado simple y poderosa que se puede usar de manera efectiva para construir modelos conceptuales, lógicos y gráficos de sistemas complejos para varios propósitos.

El uso constructivo del lenguaje UML se basa en la comprensión de los principios generales del modelado de sistemas complejos y las características del proceso de diseño orientado a objetos (POO) en particular. La elección de los medios expresivos para construir modelos de sistemas complejos predetermina las tareas que pueden resolverse utilizando estos modelos. Al mismo tiempo, uno de los principios básicos para la construcción de modelos de sistemas complejos es el principio de abstracción, que prescribe incluir en el modelo solo aquellos aspectos del sistema diseñado que están directamente relacionados con el desempeño de las funciones del sistema o su función prevista. propósito. En este caso, se omiten todos los detalles menores para no complicar demasiado el proceso de análisis y estudio del modelo resultante.

Otro principio para construir modelos de sistemas complejos es principio multimodelo. Este principio es la afirmación de que ningún modelo único puede describir adecuadamente los diversos aspectos de un sistema complejo. Aplicado a la metodología OOP, esto significa que un modelo bastante completo de un sistema complejo permite una serie de vistas interrelacionadas (vistas), cada una de las cuales refleja adecuadamente algún aspecto del comportamiento o estructura del sistema. A su vez, las representaciones más generales de un sistema complejo se consideran representaciones estáticas y dinámicas, las cuales, a su vez, pueden subdividirse en otras representaciones más particulares.) El fenómeno de un sistema complejo radica precisamente en que ninguna de sus únicas representaciones es suficiente para expresar adecuadamente todas las características del sistema simulado.

Otro principio del análisis de sistemas aplicado es el principio de construcción jerárquica de modelos de sistemas complejos. Este principio prescribe considerar el proceso de construcción de un modelo en diferentes niveles de abstracción o detalle en el marco de representaciones fijas. En este caso, el modelo inicial o inicial de un sistema complejo tiene la representación más general (metarrepresentación). Tal modelo se construye en la etapa de diseño inicial y puede no contener muchos detalles y aspectos del sistema que se está modelando.

La creación del UML en realidad comenzó a finales de 1994, cuando grado b uy y james rambo comenzó a trabajar en la combinación de los métodos Booch y OMT (técnica de modelado de objetos) bajo los auspicios de Rational Software. A fines de 1995, crearon la primera especificación de método unificado, a la que llamaron Método unificado, versión 0.8. Luego, en 1995, se les unió el creador del método OOSE (Ingeniería de Software Orientada a Objetos) ivar jacobson. De este modo, UML es una union y unificacion directa Métodos de Booch, Rambo y Jacobson , pero les agrega nuevas características.

Los principales objetivos en el desarrollo de UML fueron los siguientes:

– proporcionar a los usuarios un lenguaje de modelado visual expresivo listo para usar que les permita desarrollar y compartir modelos significativos;

– proporcionar mecanismos de extensibilidad y especialización para ampliar los conceptos básicos;

– garantizar la independencia de lenguajes de programación y procesos de desarrollo específicos;

– proporcionar una base formal para comprender este lenguaje de modelado (el lenguaje debe ser preciso y comprensible, sin formalismos innecesarios);

– estimular el crecimiento del mercado de herramientas orientadas a objetos;

– Integrar las mejores prácticas.

lenguaje UML está en proceso de estandarización conducida por OMG (Object Management Group), una organización de estándares en el campo de los métodos y tecnologías orientados a objetos, ahora se acepta como un lenguaje de modelado estándar y ha recibido un amplio apoyo en la industria del software.

lenguaje UML adoptado por casi todas las principales empresas de software (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase, etc.). Además, casi todos los fabricantes mundiales de herramientas CASE, además de Rational Software (Rational Rose), admiten UML en sus productos (Paradigm Plus 3.6, System Architec, Microsoft Visual Modeler for Visual Basic, Delphi, PowerBuilder, etc.). Puede encontrar una descripción completa de UML en http://www.omg.urg, http://www.rational.com y http://uml.shl.com. La descripción de UML en ruso está contenida en el libro de M. Fowler y K. Scott, en la presentación adicional, la terminología del idioma corresponde a esta traducción.

Los creadores de UML lo presentan como un lenguaje para definir, representar, diseñar y documentar sistemas de software, organizativos, económicos, técnicos, etc.

UML contiene un conjunto estándar de diagramas y notaciones de varios tipos.

Diagrama en UML- Esta es una representación gráfica de un conjunto de elementos, generalmente representado como un gráfico conectado con vértices (entidades) y bordes (relaciones). Los diagramas se dibujan para visualizar un sistema desde diferentes perspectivas.

Diagrama- en cierto sentido, una de las proyecciones del sistema. Por regla general, excepto en los casos más triviales, los diagramas dan una visión condensada de los elementos que componen el sistema. El mismo elemento puede estar presente en todos los diagramas, o solo en unos pocos (la opción más común), o no estar presente en ninguno (muy raro).

En teoría, los diagramas pueden contener cualquier combinación de entidades y relaciones. En la práctica, sin embargo, se utiliza un número relativamente pequeño de combinaciones típicas, correspondientes a los cinco tipos más comunes que componen la arquitectura de un sistema de software.

El UML distingue lo siguiente tipos de gráficos:

– diagramas de casos de uso(diagramas de casos de uso) - para modelar los procesos comerciales de la organización (requisitos del sistema);

– diagramas de clase(diagramas de clases) - para modelar la estructura estática de las clases del sistema y las relaciones entre ellas. Dichos diagramas muestran clases, interfaces, objetos y colaboraciones, así como sus relaciones. Al modelar sistemas orientados a objetos, este tipo de diagrama se usa con más frecuencia. Los diagramas de clases corresponden a la vista estática del sistema desde el punto de vista del diseño;

– diagramas de comportamiento del sistema(diagramas de comportamiento);

– diagramas de interacción(diagramas de interacción) - para modelar el proceso de intercambio de mensajes entre objetos. Hay dos tipos de diagramas de interacción: diagramas de secuencia(diagramas de secuencia) y diagramas cooperativos(diagramas de colaboración). Los diagramas de interacción representan relaciones entre objetos; muestra, en particular, los mensajes que los objetos pueden intercambiar. Los diagramas de interacción se refieren a la vista dinámica de un sistema. Al mismo tiempo, los diagramas de secuencia reflejan el orden temporal de los mensajes y los diagramas de cooperación reflejan la organización estructural de los objetos que intercambian mensajes. Estos diagramas son isomorfos, es decir, se pueden transformar entre sí;

– diagramas de estado(diagramas de gráficos de estado): para modelar el comportamiento de los objetos del sistema durante la transición de un estado a otro. Representan un autómata que incluye estados, transiciones, eventos y tipos de acciones. Los diagramas de estado se refieren a la vista dinámica de un sistema; son especialmente importantes cuando se modela el comportamiento de una interfaz, clase o colaboración. Se enfocan en el comportamiento de un objeto dependiendo de la secuencia de eventos, lo cual es muy útil para modelar sistemas reactivos;

– diagramas de actividades(diagramas de actividad) - para modelar el comportamiento del sistema en el marco de varios casos de uso o actividades de modelado. Este es un caso especial de un diagrama de estado; representa las transiciones del flujo de control de una actividad a otra dentro del sistema. Los diagramas de actividad se refieren a la vista dinámica del sistema; son muy importantes para modelar su funcionamiento y reflejan el flujo de control entre objetos;

– diagramas de implementación: diagramas de componentes(diagramas de componentes) - para modelar la jerarquía de componentes (subsistemas) del sistema; diagramas de colocación(diagramas de implementación) - para modelar la arquitectura física del sistema. El diagrama de componentes muestra la organización de un conjunto de componentes y las dependencias que existen entre ellos. Los diagramas de componentes se refieren a la vista estática de un sistema desde el punto de vista de la implementación. Pueden estar relacionados con los diagramas de clases, ya que un componente generalmente se asigna a una o más clases, interfaces o colaboraciones.Una breve historia de UML

Los lenguajes de modelado orientados a objetos aparecieron en el período comprendido entre mediados de los 70 y finales de los 80, cuando los investigadores, ante la necesidad de tener en cuenta las nuevas características de los lenguajes de programación orientados a objetos y los requerimientos de aplicaciones cada vez más complejas. , se vieron obligados a desarrollar varios enfoques alternativos para el análisis y el diseño.

De 1989 a 1994, el número de diferentes métodos orientados a objetos aumentó de diez a más de cincuenta. Sin embargo, muchos usuarios tuvieron dificultades para elegir un lenguaje de modelado que se adaptara completamente a sus necesidades, lo que provocó la llamada "guerra de métodos". A raíz de estas guerras surgió una nueva generación de métodos, entre los que los lenguajes adquirieron especial importancia. Booch, creado Grady Boochem (Grady Booch) OOSE(Ingeniería de Software Orientada a Objetos), desarrollado por ivar jacobson (Ivar Jacobson) y HTA(Técnica de modelado de objetos), escrito por james rambo (James Rumbaugh). Además, se deben mencionar los idiomas. Fusión, Schlaer-Mellora(Shlaer-Mellor) y Coada Yordona(Coad Yourdon). Cada uno de estos métodos puede considerarse bastante completo y completo, aunque cada uno de ellos no solo tiene fortalezas, sino también debilidades.

Las posibilidades expresivas del método Booch son especialmente importantes en las etapas de diseño y construcción del modelo. OOSE es muy adecuado para el análisis y la formulación de requisitos, así como para el diseño de alto nivel. OMT-2 demostró ser particularmente útil para el análisis y desarrollo de sistemas de información orientados al procesamiento de grandes cantidades de datos.

Una masa crítica de nuevas ideas comenzó a formarse a mediados de la década de 1990, cuando Grady Butch(Corporación de Software Racional), ivar jacobson(Objetivo) y james rambo(General Electric) intentaron combinar sus métodos, que ya han recibido reconocimiento mundial como los más prometedores en esta área. Como los principales autores de lenguas Booch, OOSE y OMT, los socios intentaron crear una nueva, lenguaje de modelado unificado y se guiaron por tres consideraciones.

Primero, los tres métodos, independientemente del deseo de los desarrolladores, ya se han desarrollado en la dirección opuesta. Fue prudente continuar esta evolución juntos, en lugar de por separado, lo que ayudaría a eliminar las diferencias no deseadas y, como resultado, los inconvenientes para los usuarios en el futuro.

En segundo lugar, mediante la unificación de métodos, sería más fácil brindar estabilidad al mercado de herramientas de modelado orientado a objetos, lo que haría posible basar todos los proyectos en un único lenguaje maduro y permitiría a los fabricantes de herramientas centrarse en actividades más productivas.

Finalmente, era de esperar que tal cooperación mejorara los tres métodos y proporcionara soluciones a problemas para los cuales cualquiera de ellos, tomado aisladamente, no era muy adecuado.

– modelar sistemas completos, desde el concepto hasta el artefacto ejecutable, utilizando métodos orientados a objetos;

– resolver el problema de la escalabilidad, que es inherente a los sistemas complejos diseñados para realizar tareas críticas;

- crear un lenguaje de modelado que pueda ser utilizado no solo por personas, sino también por computadoras.

Inventar un lenguaje para el análisis y diseño orientado a objetos no es muy diferente de desarrollar un lenguaje de programación. primeramente, se requería limitar la tarea. ¿Debe el lenguaje incluir la capacidad de especificar requisitos? ¿Debe el lenguaje permitir la programación visual? en segundo lugar, era necesario encontrar un equilibrio entre la fuerza expresiva y la sencillez. Un lenguaje demasiado simple limitaría la gama de tareas resueltas con él, y demasiado complejo podría abrumar a un desarrollador inexperto. Además, al combinar los métodos existentes, era necesario tener en cuenta la disponibilidad de productos ya desarrollados con su ayuda. Hacer demasiados cambios podría alienar a los usuarios existentes y, al resistirse al desarrollo del lenguaje, los autores perderían la capacidad de atraer nuevos usuarios y hacer que el lenguaje sea más simple y fácil de usar. Al crear UML, los desarrolladores intentaron encontrar la mejor solución a estos problemas.

Oficialmente, la creación de UML comenzó en octubre de 1994. cuando Rumbaugh se mudó a Rational Software, donde trabajaba Butch. El objetivo original era combinar los métodos Booch y OMT. Primer intento versión 0.8 del Método Unificado(Método Unificado), como se llamaba entonces, apareció en octubre de 1995 . Casi al mismo tiempo, Jacobson se pasó a Rational y el proyecto UML se amplió para incluir OOSE. Como resultado de los esfuerzos conjuntos en junio de 1996 salió UML versión 0.9. A lo largo del año, los creadores han recopilado comentarios de las principales empresas de ingeniería de software. Durante este tiempo, quedó claro que la mayoría de estas empresas consideraban UML como un lenguaje de importancia estratégica para sus negocios. Como resultado, se fundó un consorcio de UML, que incluía organizaciones dispuestas a contribuir con recursos para trabajar hacia una definición completa de UML.

Versión de idioma 1.0 apareció como resultado de los esfuerzos conjuntos de Digital Equipment Corporation, Hewlett Packard, I-Logix, Intellicprp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments y Unisys. UML 1.0 resultó ser un lenguaje bien definido, expresivo y poderoso aplicable a una amplia variedad de tareas. En enero de 1997, se presentó al Object Management Group (OMG) para un concurso para crear un lenguaje de modelado estándar.

Entre enero y junio de 1997, el consorcio UML se expandió para incluir prácticamente a todas las empresas que respondieron a la convocatoria de OMG, a saber, Andersen Consulting, Ericsson, ObjecTime Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software y Taskon. Para formalizar las especificaciones de UML y coordinar con otros grupos de estándares, se formó Semantic Group bajo el liderazgo de Cris Kobryn de MCI Systemhouse y Ed Eykholt de Rational. Una versión revisada del UML (1.1) se presentó nuevamente al OMG en julio de 1997. En septiembre, la versión fue aprobada en las reuniones del Grupo de Análisis y Diseño y el Comité de Arquitectura de OMG, y el 14 de noviembre de 1997, fue adoptada como estándar en una reunión general de todos los miembros de OMG.

El OMG Revision Task Force (RTF), dirigido por Chris Kobrin, llevó a cabo más trabajos sobre el desarrollo de UML. V junio de 1998 Se lanzó UML 1.2 y otoño de 1998– UML 1.3.

lenguaje de modelado UML

UML(Unified Modeling Language) es un lenguaje de descripción gráfica para el modelado de objetos en el campo del desarrollo de software. Utiliza notación gráfica para crear un modelo de sistema. Este lenguaje fue creado para definir, visualizar, diseñar y documentar sistemas de software, y también se utiliza para modelar procesos de negocios, diseño de sistemas.

Descripción del lenguaje de modelado unificado UML

Una breve historia de UML (Creadores: Grady Butch, ivar jacobson y james rambo)

Modelo conceptual de UML (el modelo conceptual incluye: los principales bloques de construcción del lenguaje; las reglas para su combinación; algunos mecanismos comunes a todo el lenguaje)

Tipos de diagramas para modelar:

Diagramas de casos de uso (describen el propósito funcional del sistema o lo que debe hacer el sistema)

Diagramas de clases (utilizados para representar la estructura estática de un modelo de sistema en la terminología de las clases de programación orientada a objetos; tales diagramas pueden reflejar varias relaciones entre entidades individuales del área temática, como objetos y subsistemas, así como describir su estructura interna y tipos de relaciones)

Diagramas de interacción (describen la interacción entre objetos en el sistema y se dividen en dos tipos principales de diagramas: diagramas de secuencia y diagramas cooperativos)

Diagramas de estado (utilizados para describir todos los estados posibles de una instancia de una determinada clase y las posibles secuencias de sus transiciones de un estado a otro, es decir, modela todos los cambios en el estado de un objeto como su reacción a influencias externas)

Diagramas de actividad (utilizados para modelar el proceso de realización de operaciones)

Diagramas de implementación (sirven para representar los componentes del sistema y hacer referencia a su modelo físico)

Diagramas de componentes (describe las características de la representación física del sistema y permite determinar la arquitectura del sistema que se está desarrollando estableciendo dependencias entre los componentes del software, que pueden ser código fuente y código ejecutable)

Diagramas de ubicación (reflejan las relaciones físicas entre los componentes de software y hardware del sistema, y ​​también se utilizan para representar las rutas de movimiento de los objetos en un sistema distribuido)

Anotación: El tema de este curso es El UML - Lenguaje Unificado de Modelado. En la lección anterior, hablamos sobre qué es UML, sobre su historia, propósito, formas de usar el lenguaje, la estructura de su definición, terminología y notación. Se ha señalado que un modelo UML es un conjunto de diagramas. En esta lección, consideraremos tales preguntas: por qué necesitamos varios tipos de diagramas; tipos de diagramas; OOP y diagramación de secuencias

Antes de pasar a la discusión del material principal de esta lección, hablemos sobre por qué construir diagramas. El desarrollo de un modelo de cualquier sistema (no solo software) siempre precede a su creación o actualización. Esto es necesario al menos para imaginar más claramente el problema que se está resolviendo. Los modelos reflexivos son muy importantes tanto para la interacción dentro del equipo de desarrollo como para el entendimiento mutuo con el cliente. Después de todo, le permite asegurarse de que el proyecto sea "arquitectónicamente coherente" antes de implementarlo en el código.

Construimos modelos de sistemas complejos porque no podemos describirlos completamente, "échales un vistazo". Por lo tanto, seleccionamos solo las propiedades del sistema que son esenciales para una tarea en particular y construimos su modelo que refleja estas propiedades. El método de análisis orientado a objetos permite describir sistemas complejos reales de la forma más adecuada. Pero a medida que los sistemas se vuelven más complejos, existe la necesidad de una buena tecnología de simulación. Como dijimos en la lección anterior, un sistema unificado se usa como una tecnología "estándar". lenguaje de modelado(Lenguaje de modelado unificado, UML), que es un lenguaje gráfico para la especificación, visualización, diseño y documentación de sistemas. Usando UML, puede desarrollar un modelo detallado del sistema que se está creando, reflejando no solo su concepto, sino también características de implementación específicas. Dentro del marco del modelo UML, todas las representaciones sobre el sistema se fijan en forma de construcciones gráficas especiales llamadas diagramas.

Nota. No consideraremos todos, sino solo algunos de los tipos de gráficos. Por ejemplo, el diagrama de componentes no se cubre en esta lección, que es solo una breve descripción general de los tipos de diagramas. La cantidad de tipos de gráficos para un modelo de aplicación en particular no está limitada de ninguna manera. Para aplicaciones simples, no hay necesidad de construir diagramas de todo tipo sin excepción. Algunos de ellos pueden simplemente faltar, y este hecho no se considerará un error. Es importante comprender que la disponibilidad de diagramas de cierto tipo depende de los detalles de un proyecto en particular. Puede encontrar información sobre otros tipos de diagramas (que no se analizan aquí) en el estándar UML.

Por qué necesita varios tipos de gráficos

Primero, definamos la terminología. En el prefacio de esta lección, usamos repetidamente los conceptos de sistema, modelo y diagrama. El autor está seguro de que cada uno de nosotros comprende intuitivamente el significado de estos conceptos, pero para que quede completamente claro, volvamos a mirar el glosario y leamos lo siguiente:

Sistema- un conjunto de subsistemas controlados interconectados unidos por un objetivo común de funcionamiento.

Sí, no muy informativo. ¿Qué es un subsistema entonces? Para aclarar la situación, volvamos a los clásicos:

sistema Llamamos a un conjunto de subsistemas organizados para lograr un objetivo específico y descritos utilizando un conjunto de modelos, posiblemente desde diferentes puntos de vista.

Bueno, no hay nada que puedas hacer, tienes que buscar la definición de un subsistema. También dice allí que subsistema es un conjunto de elementos, algunos de los cuales especifican el comportamiento de otros elementos. Ian Sommerville explica el concepto de esta manera:

Subsistema es un sistema cuyo funcionamiento no depende de los servicios de otros subsistemas. El sistema de software está estructurado como un conjunto de subsistemas relativamente independientes. También se definen las interacciones entre los subsistemas.

Tampoco muy claro, pero mejor. Hablando en lenguaje "humano", el sistema se representa como un conjunto de entidades más simples que son relativamente autosuficientes. Esto se puede comparar con cómo, en el proceso de desarrollo de un programa, construimos una interfaz gráfica a partir de "cubos" estándar: componentes visuales, o cómo el texto del programa también se divide en módulos que contienen subrutinas que se combinan de acuerdo con un funcional. y se pueden reutilizar en los siguientes programas.

Comprender el concepto de sistema. Durante el proceso de diseño, el sistema se considera desde diferentes puntos de vista con la ayuda de modelos, cuyas diversas representaciones aparecen en forma de diagramas. Una vez más, el lector puede tener preguntas sobre el significado de los conceptos modelos y diagramas. Creemos que una definición hermosa, pero no muy clara modelos como abstracción de un sistema semánticamente cerrado Es poco probable que se aclare la situación, así que intentemos explicarlo "con nuestras propias palabras".

Modelo- este es un cierto objeto (material o no) que muestra solo las características más significativas del sistema para esta tarea. Los modelos son diferentes: tangibles e intangibles, artificiales y naturales, decorativos y matemáticos...

Demos algunos ejemplos. Los autos de juguete de plástico que todos conocemos, que jugamos con tanta emoción en la infancia, no son más que material artificial decorativo modelo de coche real. Por supuesto, en tal "automóvil" no hay motor, no llenamos su tanque con gasolina, la caja de cambios no funciona en él (además, está ausente en absoluto), pero como modelo, este juguete cumple plenamente su funciones: le da al niño una idea sobre el automóvil, porque muestra sus rasgos característicos son la presencia de cuatro ruedas, una carrocería, puertas, ventanas, la capacidad de conducir, etc.

En la investigación médica, las pruebas con animales a menudo preceden a los ensayos clínicos de medicamentos en humanos. En este caso, el animal actúa como materiales naturales modelos humanos.

La ecuación que se muestra arriba también es un modelo, pero este es un modelo matemático y describe el movimiento de un punto material bajo la acción de la gravedad.

Solo queda decir qué es un diagrama. Diagrama es una representación gráfica de un conjunto de elementos. Por lo general, se representa como un gráfico con vértices (entidades) y bordes (relaciones). Hay muchos ejemplos de diagramas. Este es un diagrama de bloques familiar para todos nosotros desde la escuela, y diagramas de instalación para varios equipos que podemos ver en los manuales de usuario, y un árbol de archivos y directorios en un disco, que podemos ver ejecutando el comando de árbol en el consola de Windows, y mucho, mucho más otros. En la vida cotidiana, los diagramas nos rodean por todos lados, porque una imagen es más fácil de percibir para nosotros que un texto...

Pero volvamos al diseño de software (y no solo). En esta industria desde usando diagramas, puede visualizar el sistema desde diferentes puntos de vista. Uno de los diagramas, por ejemplo, puede describir la interacción del usuario con el sistema, el otro, el cambio en los estados del sistema durante su funcionamiento, el tercero, la interacción entre los elementos del sistema, etc. Un complejo El sistema puede y debe representarse como un conjunto de pequeños y casi independientes modelos - diagramas, y ninguno de ellos es suficiente para describir el sistema y obtener una imagen completa del mismo, ya que cada uno de ellos se enfoca en algún aspecto particular del funcionamiento del sistema. sistema y expresa un diferente nivel de abstracción. En otras palabras, cada modelo corresponde a un punto de vista específico y particular sobre el sistema que se está diseñando.

A pesar de que en el párrafo anterior fuimos muy flojos con el concepto de modelo, debe entenderse que en el contexto de las definiciones anteriores ningún diagrama es un modelo. Los diagramas son solo un medio para visualizar el modelo, y los dos deben distinguirse. Solo un conjunto de diagramas constituye un modelo de sistema y lo describe más completamente, pero ningún diagrama sacado de contexto.

Tipos de gráficos

UML 1.5 definido doce tipos de gráficos dividido en tres grupos:

• cuatro tipos de diagramas representan la estructura estática de la aplicación;
• cinco representan los aspectos de comportamiento del sistema;
• tres representan los aspectos físicos del funcionamiento del sistema (diagramas de implementación).

La versión actual de UML 2.1 no ha realizado demasiados cambios. Los diagramas han cambiado ligeramente en apariencia (han aparecido marcos y otras mejoras visuales), la notación ha mejorado ligeramente, algunos diagramas han recibido nuevos nombres.

Sin embargo, el número exacto diagramas canónicos no tiene ninguna importancia para nosotros, ya que no los consideraremos todos, sino solo algunos, debido a que la cantidad de tipos de diagramas para un modelo particular de una aplicación particular no es estrictamente fija. Para aplicaciones simples, no es necesario construir todos los diagramas sin excepción. Por ejemplo, para una aplicación local, no es necesario crear un diagrama de implementación. Es importante comprender que la lista de diagramas depende de los detalles del proyecto que se está desarrollando y la determina el propio desarrollador. Si el lector curioso aún desea conocer todos los diagramas UML, lo referiremos al estándar UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Recordemos que el propósito de este curso no es describir absolutamente todas las posibilidades de UML, sino solo introducir este lenguaje, para dar una idea inicial de esta tecnología.

Por lo tanto, veremos brevemente tipos de gráficos como:

• use el diagrama del caso;
• diagrama de clase;
• diagrama de objetos;
• diagrama de secuencia;
• diagrama de interacción;
• diagrama de estado;
• diagrama de actividad;
• diagrama de despliegue.

Hablaremos sobre algunos de estos diagramas con más detalle en las próximas lecciones. Por ahora, no nos centraremos en los detalles, sino que nos fijamos el objetivo de enseñar al lector a distinguir al menos visualmente entre los tipos de diagramas, para dar una idea inicial del propósito de los principales tipos de diagramas. Vamos a empezar.

Use el diagrama del caso

Todos los sistemas (incluido el software) están diseñados teniendo en cuenta el hecho de que en el curso de su trabajo serán utilizados por personas y/o interactuarán con otros sistemas. Las entidades con las que el sistema interactúa en el curso de su trabajo se denominan actores, y cada actor espera que el sistema se comporte de una manera predecible y estrictamente definida. Intentemos dar una definición más rigurosa de un ector. Para hacer esto, usamos un maravilloso vocabulario visual para UML. Mentor Zicom:

Héctor (actor)- este es un conjunto de roles lógicamente relacionados realizados al interactuar con precedentes o entidades (sistema, subsistema o clase). Un actor puede ser una persona u otro sistema, subsistema o clase que represente algo fuera de la entidad.

Gráficamente, el vector se representa como " hombrecito", similares a los que dibujábamos en la infancia, representando a miembros de nuestra familia, o símbolo de clase con estereotipo correspondiente, como se muestra en la imagen. Ambas formas de presentación tienen el mismo significado y se pueden utilizar en diagramas. La forma "estereotipada" se usa más a menudo para representar a los actores del sistema o en los casos en que el actor tiene propiedades que deben mostrarse (Figura 2.1).

El lector atento puede inmediatamente hacerse la pregunta: ¿Por qué es Héctor y no un actor?? Estamos de acuerdo, la palabra "ektor" corta un poco la oreja de una persona rusa. La razón por la que decimos esto es simple: el ector se forma a partir de la palabra acción, lo que significa en la traducción acción. La traducción literal de la palabra "ektor" - actor- demasiado largo e incómodo de usar. Por lo tanto, lo seguiremos diciendo.

El mismo lector atento pudo notar que la palabra "precedente" brilló en la definición del ector. ¿Qué es? Esta pregunta nos interesará aún más si recordamos que ahora estamos hablando de use el diagrama del caso. Entonces,

Precedente (caso de uso)- descripción de un aspecto particular del comportamiento del sistema desde el punto de vista del usuario (Butch).

La definición es bastante comprensible y exhaustiva, pero se puede refinar aún más utilizando el mismo Mentor Zicom"om:

caso de uso- descripción del conjunto de eventos sucesivos (incluidas las variantes) realizados por el sistema, que conducen al resultado observado por el actor. Un caso de uso representa el comportamiento de una entidad al describir la interacción entre los actores y el sistema. Un precedente no muestra "cómo" se logra un determinado resultado, sino sólo "qué" es.

Los precedentes se indican de una manera muy simple: en forma de elipse, dentro de la cual se indica su nombre. Los casos de uso y los actores están conectados con líneas.. A menudo, en un extremo de la línea se representa el arroz. 2.3

Si te enfrentas a la tarea de describir el trabajo de una organización, tienes entre manos una enorme cantidad de información desordenada. Está perdido y no sabe de qué lado abordar todo esto, le aconsejo la siguiente secuencia de acciones:

2. Determine qué tipo de modelo de proceso comercial necesita construir y seleccione una lista de metodologías que se pueden usar en el modelado (utilice la guía a continuación);

3. Compare las metodologías y notaciones de modelado para su tipo de modelo y elija la metodología que más le convenga:

• Metodologías para modelar procesos comerciales y flujos de datos de alto nivel;
• Metodologías para modelar flujos de trabajo;
• Metodologías para el modelado de la estructura de la información.

4. Construya el modelo.

Guía de Notaciones y Metodologías

Para no confundirse con todo tipo de metodologías y notaciones que se utilizan para construir los modelos de organización más comunes (modelos de gestión - procesos de negocio en el nivel superior, modelos de flujo de trabajo y modelo de información - estructura de información), ofrezco una guía y sus detallando más.

Metodologías clásicas

A pesar de su diferencia, principalmente relacionada con el nombre de los diagramas y los tipos de objetos utilizados, las metodologías modernas para describir procesos de negocios son casi idénticas y representan cambios menores a los estándares clásicos.