Fundamentos de Ingería de Bu

Software Maribel Zahuantitla Salas

INICIO
U1 Fundamentos Ingenieria de Software >

1.1 Conceptos Basicos

Ingenierí

• Es la profesión en la que el conocimiento de las ciencias naturales y matemáticas

obtenidos con el estudio, la práctica y la experiencia se aplica con juicio para
desarrollar formas de utilizar de modo económico, los materiales y fuerzas de la
naturaleza para beneficio de la humanidad

Software

• Es el conjunto de todos los programas que existen dentro de una

computadora.
• Es el producto del desarrollo que realizan los ingenieros de software resultado de
requerimientos de información.

La Ingeniería de Software

• Es una disciplina de la Ingeniería que comprende todos los aspectos de la

producción del software desde las etapas iníciales de la especificación del sistema
hasta el mantenimiento de éste después de que se libera.
La Ingeniería de Software incluye:

• Personas (quién lo hace)

· Proceso (la manera en que se hace)

· Proyecto (la realización)

· Producto (la aplicación de artefactos)

Vídeo de YouTube
 Funte de información
http://unudad1conceptos.blogspot.mx/2013/02/unidad-1-fundamentos-de-
ingenieria-de.html

Subpáginas (1): 1.2 El papel evolutivo del Software

Comentarios
No tienes permiso para añadir comentarios.

INICIO
U1 Fundamentos Ingenieria de Software >

1.4 Clasificacion de la Tecnologia en el desarrollo de

software (Tecnologia Estructurada y Orientada a
Objetos)
Tecnologías de desarrollo estructurado
Las tecnologías de desarrollo estructurado son las más
convencionales de las empleadas hoy día. Han surgido de la
evolución de las ideas de programación estructurada (hace
más de veinticinco años) hacia las fases iniciales del ciclo de
vida. En su formulación actual, las notaciones empleadas en
las primeras fases del ciclo de vida (especificación de
requisitos de usuario y sistema) suelen estar constituidas por
lenguajes gráficos que permiten: identificar el sistema y el
entorno; representar el flujo de información entre los
elementos; y, describir los datos y las actividades del sistema.
La idea base de esta tecnología es que es posible estructurar
el modelo de un sistema de software en base a funciones que
procesan información que reciben de otras funciones (o del
exterior) y dirigen la información procesada a otros módulos
funcionales (o al exterior). El enfoque seguido, por tanto, es
el de pensar en las funciones del sistema necesarias
(extraídas de los requisitos del sistema) y luego en los datos
que requieren.
Orientado a Objetos

Los métodos de descomposición orientada a objetos

constituyenla tendencia más influyente observada en la
ingeniería de sistemas de software en los últimos años. Con
 ellos nos referimos a un conjunto de métodos (aún en fase de
desarrollo o evolución) que permiten al analista y diseñador
concebir su sistema identificando clases de objetos,
operaciones permitidas y relaciones entre ellos como base
para la estructura del sistema a diseñar.
En ellas, un objeto es un conjunto de datos y funciones de
manipulación de los mismos encapsulados en una unidad
que es posible tratar como un todo (crear, copiar, destruir,
etc.). Un objeto posee unas operaciones visibles a otros
objetos aunque éstos no conocen cómo están
implementadas. El diseñador reconoce inicialmente clases
de objetos de las que se derivan los objetos concretos que
utilizará en el diseño.
Un objeto puede construirse jerárquicamente empleando, a
su vez, a otros objetos más simples. Una clase implica una
generalización del concepto de objeto (identificando
similitudes entre objetos similares) y constituye la base a
partir de las cuales se construye el sistema.
Existen varias tecnologías orientadas a objetos que, aunque
similares en su potencia expresiva, ofrecen algunas
diferencias que las hacen más adecuadas para algún tipo
concreto de sistemas.
Podemos mencionar como una de las más representativas
a OMT.
OMT está soportada por muchas herramientas CASE
comerciales.
Corresponde a una notación gráfica que permite representar
las clases de objetos, sus relaciones y la creación de
ejemplares de los mismos. Aunque básicamente empleada
para la fase de análisis de requisitos del sistema puede
también emplearse para las primeras fases del diseño.
URL
http://ithuejutlajhh.blogspot.mx/2013/02/fundamentos-de-
ingenieria-de-software.html

Comentarios
No tienes permiso para añadir comentarios.

Iniciar sesión|Actividad reciente del sitio|Notificar uso inadecuado|Imprimir página|Con la tecnología

de Google Sites
 Fundamentos de Ingería de Bu

Software Maribel Zahuantitla Salas

INICIO
U1 Fundamentos Ingenieria de Software >

1.5 Definicion e historia de las herramientas CASE

Se puede definir a las Herramientas CASE como un conjunto de
programas y ayudas que dan asistencia.
a los analistas, ingenieros de software y desarrolladores, durante todos
los pasos del Ciclo de Vida de desarrollo de un Software. Como es
sabido, los estados en el Ciclo de Vida de desarrollo de un Software son:
Investigación Preliminar, Análisis, Diseño, Implementación e Instalación.
CASE: Conjunto de métodos, utilidades y técnicas que facilitan la
automatización del ciclo de vida del desarrollo de sistemas de
información, completamente o en alguna de sus fases.

La realización de un nuevo software requiere que las tareas sean

organizadas y completadas en forma correcta y eficiente. Las
Herramientas CASE fueron desarrolladas para automatizar esos
procesos y facilitar las tareas de coordinación de los eventos que
necesitan ser mejorados en el ciclo de desarrollo de software.

La mejor razón para la creación de estas herramientas fue el incremento

en la velocidad de desarrollo de los sistemas. Por esto, las compañías
pudieron desarrollar sistemas sin encarar el problema de tener cambios
en las necesidades del negocio, antes de finalizar el proceso de
desarrollo.

También permite a las compañías competir más efectivamente usando

estos sistemas desarrollados nuevamente para compararlos con sus
necesidades de negocio actuales. En un mercado altamente competitivo,
esto puede hacer la diferencia entre el éxito y el fracaso. Las
herramientas CASE también permiten a los analistas tener más tiempo
para el análisis y diseño y minimizar el tiempo para codificar y probar.
La introducción de CASE integradas está comenzando a tener un
impacto significativo en los negocios y sistemas de información de las
organizaciones.

Con un CASE integrado, las organizaciones pueden desarrollar

rápidamente sistemas de mejor calidad para soportar procesos críticos
del negocio y asistir en el desarrollo y promoción intensiva de la
información de productos y servicios. Estas herramientas pueden proveer
 muchos beneficios en todas las etapas del proceso de desarrollo de
software, algunas de ellas son:

 Verificar el uso de todos los elementos en el sistema diseñado.

 Automatizar el dibujo de diagramas.

 Ayudar en la documentación del sistema.

 Ayudar en la creación de relaciones en la Base de Datos.

 Generar estructuras de código.

La principal ventaja de la utilización de una herramienta CASE, es la

mejora de la calidad de los desarrollos realizados y, en segundo término,
el aumento de la productividad. Para conseguir estos dos objetivos es
conveniente contar con una organización y una metodología de trabajo,
además de la propia herramienta.
Vídeo de YouTube

URLde informacaión

http://ithuejutlajhh.blogspot.mx/2013/02/fundamentos-de-ingenieria-de-
software.html

http://www.youtube.com/watch?v=k5UzKfCBiIk

Comentarios
No tienes permiso para añadir comentarios.

Iniciar sesión|Actividad reciente del sitio|Notificar uso inadecuado|Imprimir página|Con la tecnología

de Google Sites

Fundamentos de Ingería de Software Bu

Maribel Zahuantitla Salas

INICIO
U1 Fundamentos Ingenieria de Software >
1.6 Clasificacion de las herramientas CASE
No existe una única clasificación de herramientas CASE y, en ocasiones, es difícil
incluirlas en una clase determinada. Podrían clasificarse atendiendo a:

 Las plataformas que soportan.

 Las fases del ciclo de vida del desarrollo de sistemas que cubren.

 La arquitectura de las aplicaciones que producen.

 Su funcionalidad.

Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se
pueden agrupar de la forma siguiente:
1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado):
abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Sonllamadas
también CASE workbench.
2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) ofront-end,
orientadas a la automatización y soporte de las actividades desarrolladas durante las
primeras fases del desarrollo: análisis y diseño.
3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) oback-end,
dirigidas a las últimas fases del desarrollo: construcción e implantación.

4. Juegos de herramientas o Tools-Case, son el tipo más simple de herramientas

CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se
encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento.

Vídeo de YouTube

Subpáginas (1): Portafolio de Evidencias Unidad 1

Comentarios
Iniciar sesión|Actividad reciente del sitio|Notificar uso inadecuado|Imprimir página|Con la tecnología
de Google Sites
 ¿Qué es y para qué sirve
UML? Versiones de UML
(Lenguaje Unificado de
Modelado). Tipos de
diagramas UML.
Escrito por César Krall
Resumen: UML ó Lenguaje Unificado de Modelado es un estándar para la representación de
procesos o esquemas de software (programas informáticos).

Codificación aprenderaprogramar.com: DV00205D

DEFINICIÓN Y CONCEPTO DE UML

UML son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de Modelado”. Se trata de un
estándar que se ha adoptado a nivel internacional por numerosos organismos y empresas para crear
esquemas, diagramas y documentación relativa a los desarrollos de software (programas informáticos).

¿QUÉ ES Y PARA QUÉ SIRVE UML?

El término “lenguaje” ha generado bastante confusión respecto a lo que es UML. En realidad el término
lenguaje quizás no es el más apropiado, ya que no es un lenguaje propiamente dicho, sino una serie de
normas y estándares gráficos respecto a cómo se deben representar los esquemas relativos al software.
Mucha gente piensa por confusión que UML es un lenguaje de programación y esta idea es errónea: UML
no es un lenguaje de programación. Como decimos, UML son una serie de normas y estándares que dicen
cómo se debe representar algo.

UML es una herramienta propia de personas que tienen conocimientos relativamente avanzados de
programación y es frecuentemente usada por analistas funcionales (aquellos que definen qué debe hacer
un programa sin entrar a escribir el código) y analistas-programadores (aquellos que dado un problema, lo
estudian y escriben el código informático para resolverlo en un lenguaje como Java, C#, Python o
cualquier otro). Por tanto si estás dando tus primeros pasos en programación, te recomendaríamos que te
olvides de UML hasta que tengas unos conocimientos mínimos como uso de condicionales, bucles, y
conocimiento de la programación orientada a objetos. Esto es solo una recomendación, en realidad
prácticamente cualquier persona puede usar UML, incluso podría usarse para realizar esquemas o
documentación de procesos que no tengan que ver con la informática.

Hemos dicho que UML es un estándar. Vamos a aclarar primero qué es un estándar. Supongamos que
vamos a definir un estándar llamado “LMAPR” o lenguaje de modelado de aprenderaprogramar.com.
Ahora definimos dentro de nuestro estándar estas normas:

Un animal debe representarse con su nombre escrito enteramente en minúsculas enmarcado dentro de un
rectángulo doble. Encima del nombre debe etiquetarse el tipo de animal así: <<Tipo de Animal>>. Por
ejemplo, <<Gato>>.

Si un animal envía un mensaje a otro animal deben conectarse los dos animales con una línea punteada
terminada en flecha encima de la cual debe figurar el texto msg(“Contenido del mensaje”).

Ahora supongamos que tenemos dos gatos, uno de los cuales le dice al otro “Caza un ratón y tráemelo
aquí por favor”. Veamos formas de representar esto:

Esta es una forma de representación. Sin embargo, no se adapta al estándar que hemos definido por
varios motivos: no indica <<Gato>> encima de los nombres de los animales, no escribe los nombres en
minúsculas, no representa los animales con un rectángulo, etc.

Veamos la representación que sí se adaptaría al estándar definido:

Con este ejemplo sencillo hemos tratado de hacer explícito qué es y para qué sirve UML: un conjunto de
normas que nos dicen cómo hay que representar esquemas de software. En el caso del software orientado
a objetos, en vez de gatos tendremos clases u objetos instanciados, y dispondremos de numerosos tipos
de esquemas y diagramas para representar distintas cosas. Un esquema que cumple las normas UML
podría tener este aspecto:

O también este otro:

¿Por qué si ambos esquemas cumplen con UML tienen un aspecto tan distinto? Porque UML define normas
para construir muchos tipos de esquemas, no esquemas de un solo tipo.

¿Quién usa UML? UML lo suelen usar las empresas o medianos o grandes equipos de desarrollo software
con el objetivo de planificar y documentar cómo se construyen los programas informáticos complejos. Los
usuarios individuales o pequeños equipos de desarrollo de 2 ó 3 personas no suelen usar herramientas
UML. UML es un término que se relaciona mucho con “Ingeniería del software”. Al igual que un proyecto
de edificio requiere la participación de un arquitecto y unos plantos, un proyecto software requiere la
participación de ingenieros informáticos y una planificación y documentación.

¿CUÁLES SON LAS VERSIONES DE UML?

Los antecedentes de UML se sitúan en la década de los 90 con distintos estándares para modelado de
software, no obstante podemos hablar de dos grandes versiones:

UML 1.X (comprende UML 1.1, 1.2, 1.3, 1.4, 1.5): desde finales de los 90 se empezó a trabajar con el
estándar UML. En los años sucesivos fueron apareciendo nuevas versiones que introducían mejoras o
ampliaban a las anteriores.

UML 2.X (comprende UML 2.1 hasta UML 2.5, 2.6, etc.): en torno a 2005 se difundió una nueva versión de
UML a la que podemos denominar UML 2.X. Comprenden varias revisiones.

UML 3.X: evolución que se espera para UML 2.X.

Hay que tener en cuenta que UML es un conjunto muy amplio de normas. Prácticamente nadie las conoce
todas. Según la empresa o universidad, institución o centro de trabajo se usan determinados programas
para crear diagramas y se conocen ciertas partes de UML, pero no el conjunto de UML.

¿Qué versión usar? Para generar diagramas UML se usan programas informáticos. Usa un programa
actualizado pero no te preocupes en exceso por qué versión de UML usar, lo importante es que en tu
grupo de trabajo o personas a las que se les vaya a enviar documentación sobre un proyecto software
sepan interpretar lo que se les envía. A nivel profesional no se le presta demasiada atención a que se
cumpla estrictamente con las normas de una determinada versión de UML, sino a que los esquemas estén
bien construidos y razonados.

TIPOS DE DIAGRAMAS EN UML

Usando UML se pueden construir numerosos tipos de diagramas. Vamos a citar algunos:

Diagramas de casos de uso: representan a los actores y casos de uso (procesos principales) que
intervienen en un desarrollo de software.

Diagramas de clases:para UML una clase es una entidad, no una clase software. Un diagrama de clases
UML puede ser un diagrama del dominio o representación de conceptos que intervienen en un problema,
o también un diagrama de clases software. El sentido de un diagrama UML se lo da la persona que lo
construye.

Diagramas de secuencia:suelen usarse para representar objetos software y el intercambio de mensajes

entre ellos, representando la aparición de nuevos objetos de izquierda a derecha.
Diagramas de colaboración:suelen usarse para representar objetos o clases y la forma en que se
transmiten mensajes y colaboran entre ellos para cumplir un objetivo.

Diagramas de estados:suelen usarse para representar cómo evoluciona un sistema (cómo va

cambiando de estado) a medida que se producen determinados eventos.

Otros diagramas:diagramas de actividad, diagramas de paquetes, diagramas de arquitectura software,

etc.

HERRAMIENTAS O PROGRAMAS PARA TRABAJAR CON UML

Hay muchísimos programas que permiten trabajar con UML, aunque aprender a usarlos requiere tiempo.

Astah community: herramienta sencilla, adecuada para aprender. Se puede descargar una versión
gratuita en http://astah.net/editions/community. Astah (antes conocido como Jude) también tiene una
versión profesional.

Rational Rose: conjunto de herramientas IBM usado por muchas empresas.

Lucidchart: herramienta que permite crear muchos tipos de diagramas, entre ellos UML. Puede probarse
visitando https://www.lucidchart.com/pages/es/ejemplos/diagrama-UML

Microsoft Visio: herramienta de Microsoft que permite la creación de muchos tipos de diagramas, entre
ellos diagramas UML.

Otros: Erwin, Oracle Designer, EasyCASE, Power Designer, etc. son herramientas que incorporan muchas
utilidades, entre ellas UML.

CRÍTICAS A UML

UML recibe numerosas críticas por parte de los miembros de la comunidad de desarrolladores software,
entre ellas el ser demasiado extenso, carecer de significados precisos para los elementos representados,
dificultad para representar algunos tipos de sistemas software o elementos, etc.

A pesar de ello y de no ser “perfecto”, es un estándar de amplio uso hoy día y una herramienta
fundamental en desarrollos software de gran envergadura.

Para hacer un comentario o consulta utiliza los foros aprenderaprogramar.com, abiertos a cualquier
persona independientemente de su nivel de conocimiento.

Descargar archivo:

DV00205D que es uml versiones uml para que sirve lenguaje unificado [] 77
 modelado.pdf kB

DIVULGACIÓN
 Lenguajes y entornos
 Tendencias en programación
 Empresas y emprendedores
 Herramientas informáticas
 Servicios web gratutitos
 De todo un poco
Donar o colaborar
Este sitio se mantiene abierto gracias al apoyo de muchas personas. Si crees que merece la pena apoyar
económicamente este sitio web puedes realizar una donación o colaborar. Contacta con nosotros.

¿Puedo yo aprender?
Seas o no del área informática, si quieres aprender a programar te ofrecemos una solución guiada y
personalizada: realizar un curso tutorizado on-line. Con este tipo de curso, podrás aprender a programar
de forma ágil y amena.

Acceder a detalles y precios de los cursos tutorizados on-line

Participa!!! Entra en los foros aprenderaprogramar.com.

Cómo obtener claves o

contraseñas de redes wifi
(cracking "a por naranjas")
¿Es segura una red
inalámbrica?
Alex Rodríguez

Resumen: Conectarse a redes wifi existentes en tu entorno (por ejemplo, la de tu vecino).

¿Es posible? ¿Cómo se hace y qué dificultad y problemas tiene hacerlo?

Codificación aprenderaprogramar.com: DV00107D

LAS REDES WIFI

A partir del año 2000 se consolidó y fue en aumento el uso de una tecnología basada en la conexión a
internet sin cables: las denominadas redes wifi. Wifi hace alusión al estándar adoptado a nivel
internacional, que se incorpora a todos los ordenadores, tablets, teléfonos de última generación, etc.

Descargar archivo:

DV00107D obtener claves wifi craking seguridad redes inalambricas.pdf [ ] 107 kB

Leer más...

Seguridad informática: ¿Qué es el hacking y

quiénes son los hackers? ¿Están seguros
nuestros datos?
César Krall

Resumen: En clave de humor: aspectos claves de la seguridad informática. Normas básicas

de seguridad, qué es el hacking, troyanos bancarios y otras lindezas.

Codificación aprenderaprogramar.com: DV00102A

LEYES PARA COMPRENDER LA SEGURIDAD INFORMÁTICA

1. Todo es mentira.

2. Las cosas funcionan de casualidad.

3. El mundo es un gran trapicheo.

4. En una empresa toda persona va ascendiendo hasta que llega a su máximo nivel de incompetencia
(Principio de Dilbert).

Descargar archivo:

DV00102A Seguridad informatica hacking hackers datos y dilbert.pdf [ ] 34 kB

Leer más...
 Grandes empresas: hacia la industrialización del
software. Radarc, la apuesta de Icinetic por la
productividad.
Mario R. Rancel

Resumen: Este artículo explica cómo las grandes empresas están tendiendo a producir
software (programas o aplicaciones) de una forma industrial.

Codificación aprenderaprogramar.com: DV00101A

¿QUÉ SIGNIFICA INDUSTRIALIZACIÓN DEL SOFTWARE Y FÁBRICA DE SOFTWARE?

Las grandes multinacionales como las españolas Indra y Coritel entre otras, están tendiendo a agrupar sus
oficinas y centros productivos en un mismo emplazamiento, dando lugar a que se creen grandes centros
de producción de software que se están denominando “fábricas de software”. Estos centros distan
bastante de lo que puede ser una fábrica convencional (de automóviles por ejemplo), pero en cierta
medida se basan en conceptos semejantes, entre los que destacan la producción en cadena y la
automatización.

Descargar archivo:

DV00101A Grandes empresas tendencia industrializacion software radarc.pdf [ ] 31 kB

Leer más...

Minería de datos (data mining). ¿Qué es? ¿Para

qué sirve? (1ª parte) (DV00105A)
César Krall

Resumen: cuestiones básicas sobre la minería de datos (data mining). ¿Qué es? ¿Para qué
sirve?. Campos de aplicación y metodología habitual en trabajos de minería de datos.

Codificación aprenderaprogramar.com: DV00105A

MINERÍA DE DATOS: ¿QUÉ ES? ¿PARA QUÉ SIRVE?

Hay diferentes definiciones para minería de datos. Una muy simple sería decir que es el estudio y
tratamiento de datos masivos para extraer conclusiones e información relevante de ellos.

Vamos a tratar de explicar para qué sirve la minería de datos dando ejemplos de en qué situaciones se
aplica.
Descargar archivo:

DV00105A Mineria de datos data mining ques es para que sirve 1.pdf [ ] 29 kB

Leer más...

Calidad del software. Métricas y fiabilidad de

aplicaciones (1ª parte) (DV00103A)
César Krall

Resumen: Este artículo explica cuestiones básicas sobre la calidad del software y sobre qué
son las métricas y otras cuestiones relacionadas.

Codificación aprenderaprogramar.com: DV00103A

CALIDAD DEL SOFTWARE

El software es un producto como cualquier otro, y por tanto podemos hablar de software de buena calidad
y software de mala calidad. La calidad del software comprende distintos aspectos como estética (que sea
agradable a la vista), funcionalidad (que sea fácil de usar), eficiencia (que ejecute con rapidez y precisión
los procesos), etc.

Descargar archivo:

DV00103A Calidad del software metricas cmmi y fiabilidad de aplicaciones.pdf [ ] 57 kB

Leer más...

Minería de datos (2ª parte). Modelos, técnicas,

herramientas. (DV00106A)
César Krall

Resumen: cuestiones básicas sobre la minería de datos (data mining), desde varios puntos
de vista (utilidad empresarial, campo para emprendedores y campo de investigación). ¿Qué
es? ¿Para qué sirve?. Modelos, técnicas y herramientas de uso habitual en trabajos de
minería de datos.

Codificación aprenderaprogramar.com: DV00106A

 ¿QUÉ ES UN MODELO DE MINERÍA DE DATOS?

La minería de datos se aplica a todo tipo de datos imaginable: desde datos numéricos a imágenes de
satélite, mamografías, música, archivos de ordenador, imágenes, etc. Podemos decir que “cualquier cosa”
constituye un dato. Por tanto la minería de datos tiene infinitas aplicaciones: comerciales, marketing,
industria, internet, agricultura, etc.

Descargar archivo:

DV00106A Mineria de datos data mining modelos tecnicas herramientas 2.pdf [ ] 55 kB

Leer más...

Calidad del software (2ª parte) Métricas,

repositorios y planes de proyecto (DV00104A)
César Krall

Resumen: Este artículo explica cuestiones básicas sobre la calidad del software y sobre qué
son las métricas y otras cuestiones relacionadas.

Codificación aprenderaprogramar.com: DV00104A

CONTINUACIÓN: CALIDAD DEL SOFTWARE ¿POR QUÉ DEDICAR RECURSOS A LA CALIDAD?

Un error común es pensar que si un proyecto de software con una persona se desarrolla en 12 meses, con
dos personas se desarrollará en 6 meses o con tres personas en 4 meses. Esto no es así por muchos
motivos, entre otros porque hay fases como las pruebas y el diseño que no pueden solaparse.

Descargar archivo:

DV00104A Metricas repositorios planes proyecto calidad del software 2.pdf [ ] 36 kB

Leer más...
DIVULGACIÓN
 Lenguajes y entornos
¿Qué es UML? ¿Qué diagramas componen UML?
El Lenguaje Unificado de Modelado o UML (“Unified Modeling Language”) es
un lenguaje estandarizado de modelado. Está especialmente desarrollado para
ayudar a todos los intervinientes en el desarrollo y modelado de un sistema o
un producto software a describir, diseñar, especificar, visualizar, construir y
documentar todos los artefactos que lo componen, sirviéndose de varios tipos
de diagramas.

Estos diagramas contenidos en UML son la forma más común y más utilizada
de modelado de software. Modelar consiste en hacer un diseño previo de una
aplicación antes de proceder a su desarrollo e implementación. De forma
similar que un arquitecto dibuja planos sobre la casa que va a construir, un
analista de software (u otros perfiles) crea distintos diagramas UML que sirven
de base para la posterior construcción/mantenimiento del sistema. El modelado
es la principal forma de visualizar el diseño de una aplicación con la finalidad
de compararla con los requisitos antes de que el equipo de desarrollo comience
a codificar

El modelado es vital en todo tipo de proyectos, pero cobra especialmente

importancia a medida que el proyecto crece de tamaño. Para que una
aplicación funcione correctamente, debe ser diseñada para permitir
laescalabilidad, la seguridad y la ejecución. Utilizando diagramas UML se
consigue visualizar y verificar los diseños de sus sistemas de software antes de
que la implementación del código haga que los cambios sean difíciles y
demasiado costosos.

Estos diagramas de UML son representaciones gráficas que muestran de

forma parcial un sistema de información, bien esté siendo desarrollado o ya lo
haya sido. Suelen estar acompañados de documentación que les sirve de
apoyo, adoptando esta múltiples formas. Además, UML no excluye la
posibilidad de mezclar diagramas, algo que, de hecho, suele ser bastante
común.

Como principal desventaja ampliamente mencionada de UML podemos

nombrar el hecho de que se trata de un lenguaje muy amplio, haciendo, en
ocasiones, complicado utilizar todas las posibilidades que ofrece. No obstante,
los analistas tienden a utilizar los diagramas de forma sencilla, consiguiendo
que sean entendidos fácilmente por cualquier persona que accedan a ellos.

[Si estás comenzando en UML te recomiendo que visites nuestra entrada 3

libros para aprender UML desde 0 en Español]
 Contenido [Ocultar]
 1 ¿Por qué UML?
 2 Tipos de diagramas UML
o 2.1 Diagramas estructurales
o 2.2 Diagramas de comportamiento
 3 ¿Qué versiones existen de UML?
 4 Breve historia de UML
 5 Recursos y utilidades
 6 Producto disponible en Amazon.es
¿Por qué UML?

Los modelos o diagramas de UML nos ayudan a trabajar a un mayor nivel de

abstracción. Permite modelar cualquier tipo de aplicación corriendo en
cualquier combinación de hardware y software, sistema operativo, lenguaje de
programación y red, es decir, UML es independiente de la plataforma hardware
sobre la que actua el software. Su flexibilidad permite modelar cualquier tipo de
aplicación e, incluso, otros tipos de proyecto que no son puramente software.

UML ofrece ese modelado utilizando diagramas y se denomina lenguaje por ser
una forma común de expresarse por todos los analistas, desarrolladores y
usuarios. Está desarrollado para ayudar a todos estos (y más) perfiles a
especificar, visualizar, construir y documentar todos los componentes de un
proyecto. A pesar de que cada diagrama UML en particular aporta su visión
particular al modelado, el lenguaje en su conjunto tiene algunas características
que interesa resaltar:

 Es muy sencillo. Pese a que si es usado de forma completa puede llegar a

complicarse, lo normal es que se simplifique.

 Es capaz de modelar todo tipo de sistemas.

 Es un lenguaje universal, haciendo que todos los miembros del equipo se

relacionen a través de sus diagramas sean del ámbito que sean.

 Es fácilmente extensible. Tiene mecanismos sencillos para especializar los

conceptos fundamentales.

 Es visual y, por lo tanto, intuitivo.

 Es independiente del desarrollo, del lenguaje y de la plataforma.

 Bien ejecutado aporta un conjunto considerable de buenas prácticas.

 No está completo. Utilizando los distintos diagramas no podemos estar

seguros de comprender con totalidad el sistema que va a desarrollarse. Los
diagramas, para facilitar su comprensión pueden (y suelen) omitir información,
pueden tener partes que se entienden de distintas maneras o, incluso, pueden
tener conceptos que no pueden ser representados por ningún diagrama.
Este pequeño sitio web está dedicado a mostrar información sobre todos los
tipos de diagramas que existen en UML de forma online, incluyendo teoría y
ejemplos sobre los mismos. Si estás buscando las mejores herramientas para
construir diagramas UML en línea te recomiendo que accedas a nuestra lista
de mejores herramientas para construir diagramas UML online.

Tipos de diagramas UML

A día de hoy, en la versión 2.5.1 de UML, existen dos clasificaciones de

diagramas: Los diagramas estructurales y los diagramas de
comportamiento. Todos los diagramas UML están contenidos en esta
clasificación.

Clasificación de los diagramas UML

Pulsa en cualquier diagrama de los que se presentan a continuación para ver

más información.

Diagramas estructurales

Los diagramas estructurales muestran la estructura estática del sistema y sus

partes en diferentes niveles de abstracción. Existen un total de siete tipos de
diagramas de estructura:
Diagrama de clases

Muestra la estructura del sistema, subsistema o componente utilizando clases

con sus características, restricciones y relaciones: asociaciones,
generalizaciones, dependencias, etc.

Diagrama de componentes

Muestra componentes y dependencias entre ellos. Este tipo de diagramas se

utiliza para el desarrollo basado en componentes (CDB), para describir
sistemas con arquitectura orientada a servicios (SOA).

Diagrama de despliegue

Muestra la arquitectura del sistema como despliegue (distribución) de

artefactos de software.

Diagrama de objetos

Un gráfico de instancias, incluyendo objetos y valores de datos. Un diagrama

de objeto estático es una instancia de un diagrama de clase; muestra una
instantánea del estado detallado de un sistema en un punto en el tiempo.

Diagrama de paquetes

Muestra los paquetes y las relaciones entre los paquetes.

Diagrama de perfiles

Diagrama UML auxiliar que permite definir estereotipos personalizados, valores

etiquetados y restricciones como un mecanismo de extensión ligero al estándar
UML. Los perfiles permiten adaptar el metamodelo UML para diferentes
plataformas o dominios.

Diagrama de estructura compuesta

Muestra la estructura interna (incluidas las partes y los conectores) de un

clasificador estructurado.

Diagramas de comportamiento

A diferencia de los diagramas estructurales, muestran como se comporta un

sistema de información de forma dinámica. Es decir, describe los cambios que
sufre un sistema a través del tiempo cuando está en ejecución. Hay un total de
siete diagramas de comportamiento, clasificados de la siguiente forma:
Diagrama de actividades

Muestra la secuencia y las condiciones para coordinar los comportamientos de

nivel inferior, en lugar de los clasificadores que poseen esos comportamientos.
Estos son comúnmente llamados modelos de flujo de control y flujo de objetos.

Diagrama de casos de uso

Describe un conjunto de acciones (casos de uso) que algunos sistemas o

sistemas (sujetos) deben o pueden realizar en colaboración con uno o más
usuarios externos del sistema (actores) para proporcionar algunos resultados
observables y valiosos a los actores u otros interesados del sistema(s).

Diagrama de máquina de estados

Se utiliza para modelar el comportamiento discreto a través de transiciones de

estados finitos. Además de expresar el comportamiento de una parte del
sistema, las máquinas de estado también se pueden usar para expresar el
protocolo de uso de parte de un sistema.

Diagramas de interacción.

Es un subconjunto de los diagramas de comportamiento. Comprende los

siguientes diagramas:

Diagrama de secuencia

Es el tipo más común de diagramas de interacción y se centra en el

intercambio de mensajes entre líneas de vida (objetos).

Diagrama de comunicación

Se enfoca en la interacción entre líneas de vida donde la arquitectura de la

estructura interna y cómo esto se corresponde con el paso del mensaje es
fundamental. La secuencia de mensajes se da a través de una numeración.

Diagrama de tiempos

Se centran en las condiciones que cambian dentro y entre las líneas de vida a
lo largo de un eje de tiempo lineal.

Diagrama global de interacciones

Los diagramas global de interacciones brindan una descripción general del flujo
de control donde los nodos del flujo son interacciones o usos de interacción.
¿Qué versiones existen de UML?

La versión actual de UML es la 2.5.1 y fue publicada en Junio de 2015. UML es

gestionada y actualizada por la OMG (Object Manabement Group).

Los creadores originales de UML son 3: Jim Rumbaugh, Grady Booch e Ivar
Jacobson.

Esta es la lista de versiones que han sido publicadas:

 1.1 – Noviembre de 1997

 1.3 – Marzo de 2000

 1.4 – Septiembre de 2001

 1.5 – Marzo de 2003

 1.4.2 – Enero de 2005

 2.0 – Octubre de 2005

 2.1 – Abril de 2006

 2.1.1 – Febrero de 2007

 2.1.2 – Noviembre de 2007

 2.2 – Febrero de 2009

 2.3 – Mayo de 2010

 2.4.1 – Agosto de 2011

 2.5 – Junio de 2015

 2.5.1 – Diciembre de 2017 (Última versión)

Breve historia de UML

Desde hace unos años, las tecnología de la información y comunicación ya han

producido una enorme variedad de métodos y notaciones para llevar a cabo el
modelado. Existen métodos y anotaciones para el diseño, la estructura, el
procesamiento y el almacenamiento de información. De la misma manera
también podemos encontrar métodos para la planificación, modelado,
implementación, ensamblaje, prueba, documentación, ajuste, etc. de los
sistemas. Entre los conceptos que se utilizan existen algunos relativamente
fundamentales y, debido a eso, se expanden más allá del ámbito en el que
fueron creados en un principio.
Desde la concepción de la tecnología de la información hasta finales de 1970,
los desarrolladores de software se tomaron el desarrollo del software como un
arte. Pero estos sistemas fueron poco a poco haciendose más complejos y por
esta razón el mantenimiento y el desarrollo exigía otro tipo de visión, más allá
del previamente descrito. Este hecho dio lugar a la ya famosa crisis del
software.

Esta crisis lleva al enfoque de ingeniería (ingeniería de software) y la

programación estructurada. Se desarrollaron métodos para la estructuración de
sistemas y para los procesos de diseño, desarrollo y mantenimiento. Los
enfoques orientados a procesos, por ejemplo, el método de salida de
procesamiento de entrada de jerarquía, enfatizaron la funcionalidad de los
sistemas. Con este método, el sistema total se divide en componentes más
pequeños a través de la descomposición funcional.

La crisis del software

Al mismo tiempo, se desarrollaron enfoques orientados a la estructura de

datos, como el método de Jackson, en el que la estructura del programa se
deriva de la visualización gráfica de las estructuras de datos.

En todos estos métodos y notaciones, dividimos el sistema en dos partes: una

sección de datos y una sección de procedimientos. Esto es claramente
reconocible en lenguajes de programación más antiguos, como COBOL. Los
diagramas de flujo de datos, los diagramas de estructura, los
diagramas HIPO y los diagramas de Jackson se utilizan para ilustrar el rango
de funciones. Naturalmente, estos primeros métodos enfatizaron el desarrollo
de nuevos sistemas.

En la década de 1980, el análisis estructural clásico se desarrolló aún más. Los

desarrolladores generaron diagramas de relaciones de entidades para el
modelado de datos y redes de Petri para el modelado de procesos.

A medida que los sistemas se volvieron más complejos, ya no se podría

diseñar cada sistema “desde cero”. Las propiedades, como la mantenibilidad y
la reutilización, se hicieron cada vez más importantes. Se desarrollaron
lenguajes de programación orientados a objetos, y con ellos, los primeros
lenguajes de modelado orientados a objetos surgieron en los años 70 y 80. En
la década de 1990, las primeras publicaciones sobre análisis orientado a
objetos y diseño orientado a objetos se pusieron a disposición del público. A
mediados de la década de 1990, ya existían más de 50 métodos orientados a
objetos, así como muchos formatos de diseño. Un lenguaje de
modelado unificado parecía indispensable.

A principios de la década de 1990, los métodos orientados a objetos de Grady

Booch y James Rumbaugh se utilizaron ampliamente. En octubre de 1994,
Rational Software Corporation (parte de IBM desde febrero de 2003) comenzó
la creación de un lenguaje de modelado unificado. Primero, acordaron una
estandarización de la notación (lenguaje), ya que esto parecía menos
elaborado que la estandarización de los métodos. Al hacerlo, integraron
el Método Booch de Grady Booch, la Técnica de modelado de objetos ( OMT )
de James Rumbaugh y la Ingeniería de software orientada a objetos ( OOSE ),
de Ivar Jacobsen, con elementos de otros métodos y publicaron esta nueva
notación bajo el nombre UML, versión 0.9 .

El objetivo no era formular una notación completamente nueva, sino adaptar,

expandir y simplificar los tipos de diagramas existentes y aceptados de varios
métodos orientados a objetos, como los diagramas de clase, los diagramas de
casos de uso de Jacobson o los diagramas de gráficos de estado de Harel. Los
medios de representación que se utilizaron en los métodos estructurados se
aplicaron a UML. Por lo tanto, los diagramas de actividad de UML están, por
ejemplo, influenciados por la composición de los diagramas de flujo de datos y
las redes de Petri.

Lo que es sobresaliente y nuevo en UML no es su contenido, sino su

estandarización a un solo lenguaje unificado con un significado definido
formalmente.

Compañías conocidas, como IBM, Oracle, Microsoft, Digital, Hewlett-Packard y

Unisys se incluyeron en el desarrollo posterior de UML. En 1997, la versión 1.1
de UML fue enviada y aprobada por la OMG . La versión 1.2 de UML, con
adaptaciones editoriales, se lanzó en 1998, seguida de la versión 1.3 un año
después, y la versión 1.5 de UML en marzo de 2003. Los desarrolladores ya
habían estado trabajando en la versión 2.0 de UML desde el año 2000, y se
aprobó como una Especificación final adoptada por OMG en junio de 2003.
Cuando este libro se imprimió en junio de 2005, la etapa final de adopción por
parte de OMG como una especificación disponible aún no se había
completado.