Universidad de Guayaquil Osito
Universidad de Guayaquil Osito
Universidad de Guayaquil Osito
TEMA:
AUTOR:
CIUDAD:
GUAYAQUIL
FECHA:
15/10/2018
Resumen
2
ÍNDICE GENERAL
Resumen.................................................................................................................................2
1. ANTECEDENTES.....................................................................................................4
2. OBJETIVO GENERAL............................................................................................5
2.1. Objetivo general..................................................................................................5
2.2. Objetivo especifico..............................................................................................5
3. MARCO TEÓRICO..................................................................................................5
4. ANÁLISIS CRITICO..............................................................................................10
5. CONCLUSIONES Y RECOMENDACIONES.....................................................13
6. BIBLIOGRAFÍA.........................................................................................................14
3
1. ANTECEDENTES
El Lenguaje de modelado unificado (UML) apareció por primera vez en la
década de 1990 como un esfuerzo por seleccionar los mejores elementos de los muchos
sistemas de modelado propuestos en ese momento y combinarlos en una única notación
coherente. Desde entonces se ha convertido en el estándar de la industria para el
modelado y diseño de software, así como el modelado de otros procesos en el mundo
científico y empresarial. Enterprise Architect admite el último estándar UML, según lo
define OMG. Les brinda acceso a los 14 tipos de diagramas, las tecnologías MDA y un
generador de documentación integral, para ayudarlo a comunicarse y compartir sus
modelos de manera más efectiva.
2. OBJETIVO GENERAL
2.1. Objetivo general
4
2.2. Objetivo especifico
3. MARCO TEÓRICO
5
Proceso de negocio: incluye una colección de tareas que producen un
servicio específico para los clientes y se visualiza con un diagrama de
flujo como una secuencia de actividades.
3.3. Componentes lógicos y reutilizables de software
Los diagramas UML se pueden dividir en dos categorías. El primer tipo incluye
seis tipos de diagramas que representan información estructural. El segundo incluye los
siete restantes que representan tipos generales de comportamiento. Los diagramas de
estructura se utilizan para documentar la arquitectura de los sistemas de software y están
involucrados en el sistema que se está modelando.
Los sistemas de negocios tienen muchos conceptos que nunca son destinado o
adecuado para ejecutar en un programa, como el personal de trabajo en el negocio,
fabricando producción, equipo, reglas y objetivos que impulsan el negocio. Los
procesos UML fueron diseñado inicialmente para describir aspectos de un sistema de
software. Debido a esto, UML necesitaba ser extendido con el fin de identificar y
visualizar con mayor claridad los importantes conceptos de procesos, metas, recursos y
reglas de un sistema de negocio. Para abordar este problema, se han creado creado un
7
conjunto de extensiones basadas en los elementos de modelo existentes de UML
[ CITATION Her16 \l 2058 ].
Una entrada utiliza recursos para generar información. Cabe destacar que la
recopilación de la información no se utiliza en los procesos, sino más bien se junta con
8
ellos para ejecutar la actividad. En la diagramación, el conector determina que la
información no se elimina en la fase de procesamiento.
En el caso de los objetivos, estos deben ser bien definidos por parte del
programador. Determinar los objetivos es la parte más crítica del modelamiento en
UML, pues es aquí donde se determina las necesidades principales del negocio. Una
vez que este todo definido se unen las piezas y se diagrama el modelado del negocio.
9
4. ANÁLISIS CRITICO
Lo que hace que UML sea idóneo y adecuado para el desarrollo de software es
su flexibilidad. Puede personalizar sus elementos de modelado e interacciones en un
diagrama UML específicamente para adaptarse al dominio o las tecnologías que está
utilizando [ CITATION Pat121 \l 2058 ].
UML es un lenguaje rico y extenso que se puede usar para modelar no solo la
ingeniería de software orientada a objetos, sino también la estructura y el
comportamiento de las aplicaciones, y los procesos de negocios. Los reproductores de
software han acordado que no podemos eliminar la documentación de la arquitectura.
Es importante. Ayuda a evaluar el rendimiento, la seguridad, el seguimiento y
proporciona pautas importantes para la asignación en operación.
10
Abundancia de herramientas UML
Las herramientas UML son una de las razones más importantes por las que
UML se usa tanto. Las herramientas UML van desde el software gratuito de código
abierto hasta los que cuestan millones de dólares. Estas herramientas cubren mucho
territorio más allá de dibujar diagramas. Pueden generar código a partir del diseño,
aplicar patrones de diseño, requisitos de mina, código de ingeniería inversa y realizar
análisis de impacto y complejidad.
Por otra parte, Hernández (2013), define que el argumento más fuerte contra
UML es que realmente no necesita un diagrama UML para comunicar sus diseños.
Puede tener el mismo impacto y efecto con los diagramas informales de caja y línea
creados en PowerPoint, Visio o una pizarra. Como la codificación es un lenguaje formal
en sí mismo, muchos desarrolladores no prefieren la complejidad y la formalidad en el
nivel arquitectónico, lo que desalienta el uso de UML y se ha convertido en una de sus
desventajas.
11
Un término acuñado por George Fairbanks, "diseño indiferente a la arquitectura"
es una situación en la que UML se considera innecesario. En su esencia, un diseño de
arquitectura indiferente se refiere a una arquitectura de software que es simple y básica,
y no necesita ningún diagrama complejo para representar o explicar el diseño. Si las
empresas ponen más énfasis en la codificación formal, y existe una cultura de
documentación de diseño mínima, UML se considera innecesario [ CITATION Enr13 \l
2058 ].
12
BPMN tiene una semántica simple, pero poderosa. Los modelos de
proceso pueden ser creados por personal de negocios.
Pueden ser aumentados o enriquecidos, por personal comercial o técnico
más experimentado.
El modelado BPMN de eventos y el manejo de excepciones son aspectos
clave que posicionan a BPMN como líder en notaciones de modelado
[ CITATION Mar17 \l 2058 ].
5. CONCLUSIONES Y RECOMENDACIONES
El sistema UML también posee una mejor comunicación entre cada uno de los
procesos. Razón por la cual generalmente su elección es superior a las de un sistema
BPMN. Sin embargo, sus complejidades a la hora de realizar el desarrollo de los
procesos hacen que los usuarios menos expertos opten por utilizar un sistema BPMN.
13
6. BIBLIOGRAFÍA
14