República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación Superior

Universidad Politécnica Territorial Agroindustrial del Táchira

Sede Rubio – Municipio Junín

Unidad 3: Proceso de Desarrollo de Software

Autor:

Mariño Miguel

C.I:27.270.027

PNF: Informática

Sección: II

Junio de 2021

1
 Índice

Fundamentos del enfoque orientado a objetos ................. .................. .......... 4

Características. ................. ................. .......... ................. .................. .......... .... 5

Desarrollo de Componentes. ................. ................. .......... ................. ............ 6

Tipos Características de Componentes. ................. ................. .......... ......... . 7

Estándares en el proceso de desarrollo de software. ................. ................. 8

Documentación y Artefactos. ................. ................. .......... .............. ........... 10

Metodologías empleadas: Proceso Unificado de Desarrollo (UP del inglés Unified

Process). ................. ................. .......... .................. ................. .......... 11

Fases de desarrollo. ................. ................. ............... ............... ............... ..... 12

Disciplinas. ................. ................. .......... ................. ................. ................. .... 13

Introducción a los procesos ágiles de desarrollo. ................. ................. ...... 15

Elementos para interpretar el modelado de software (Lenguaje Unificado de

Modelado).

Tipos de diagramas. ................. ................. .......... ................. ................. ........ 16

Símbolos y notación de los diagramas. ................. ................. .............. ....... . 22

Uso de Herramientas CASE en el modelado ................. ................. ........... .. 24

Conclusión ................. ................. .......... ................. ................. .......... ........... 25

2
 Introducción

En el diseño y desarrollo de proyectos de software, se aplican diferentes métodos y

técnicas para su implementación, la informática aporta diversas herramientas y
procedimientos sobre los que se apoya la ingeniería de software. Todo analista de
sistemas, ingeniero de sistemas o especialista en TI debe contemplar siempre la
mejora de la calidad de los productos de software, aumentando la productividad y el
trabajo de los ingenieros del software, facilitando el control del proceso de
desarrollo de software y suministrando a los desarrolladores las bases para construir
un software de alta calidad en una forma eficiente, garantizando siempre la
producción y el mantenimiento de los productos de software desarrollados, en el
plazo establecido y dentro del costo estimado.

3
 Proceso de Desarrollo de Software

Fundamentos del enfoque orientado a objetos

El contexto del Enfoque Orientado a Objetos (EOO) un objeto es una entidad que
encapsula datos (atributos) y acciones o funciones que los manejan (métodos).
También para el EOO un objeto se define como una instancia o particularización de
una clase.

El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base

de todo desarrollo orientado a objetos. Estos principios son: la Abstracción, el
Encapsulamiento, la Modularidad y la Herencia.

Abstracción: Denota las características esenciales de un objeto, donde se capturan

sus comportamientos.Cada objeto en el sistema sirve como modelo de un "agente"
abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse"
con otros objetos en el sistema sin revelar cómo se implementan estas
características. Los procesos, las funciones o los métodos pueden también ser
abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar
una abstracción.El proceso de abstracción permite seleccionar las características
relevantes dentro de un conjunto e identificar comportamientos comunes para
definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el
proceso de análisis y diseño orientado a objetos, ya que mediante ella podemos
llegar a armar un conjunto de clases que permitan modelar la realidad o el problema
que se quiere atacar.

Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse

pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite
aumentar la cohesión de los componentes del sistema. Algunos autores confunden
este concepto con el principio de ocultación, principalmente porque se suelen
emplear conjuntamente.

Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una

aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe
ser tan independiente como sea posible de la aplicación en sí y de las restantes
partes. Estos módulos se pueden compilar por separado, pero tienen conexiones
con otros módulos. Al igual que la encapsulación, los lenguajes soportan la
Modularidad de diversas formas.

4
Herencia: Las clases no están aisladas, sino que se relacionan entre sí, formando una
jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento
de todas las clases a las que pertenecen. La herencia organiza y facilita el
polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados
como tipos especializados de objetos preexistentes. Estos pueden compartir (y
extender) su comportamiento sin tener que volver a implementarlo. Esto suele
hacerse habitualmente agrupando los objetos en clases y estas en árboles o
enrejados que reflejan un comportamiento común. Cuando un objeto hereda de
más de una clase se dice que hay herencia múltiple.

Otros elementos a destacar (aunque no fundamentales) en el EOO son:

Polimorfismo, Enlace dinámico (o binding), Concurrencia y Persistencia.

EL Paradigma Orientado a Objetos es una disciplina de ingeniería de desarrollo y

modelado de software que permite construir más fácilmente sistemas complejos a
partir de componentes individuales.

Objetos + Mensajes = Programa

El proceso Orientado a Objetos se mueve a través de una espiral evolutiva que

comienza con la comunicación con el usuario. Es en esta parte donde se define el
dominio del problema y se identifican las clases básicas del problema. La
planificación y el análisis de riesgos establecen una base para el plan de proyecto
OO.

Características

a) Objeto: Los datos están cuantificados en entidades discretas y distinguibles

llamadas objetos.

b) Clase: Significa que los objetos con la misma estructura de datos (atributos) y
comportamiento (operaciones) se agrupa para formar una clase.

c) Atributo: Describen la clase o el objeto de alguna manera

d) Mensajes: Medio por el cual interactúan los objetos

e) Polimorfismo: Significa que una misma operación puede comportarse de modos

distintos en distintas clases.

5
f) Herencia: Compartir atributos y operaciones entre clases tomando como base una
relación jerárquica.

Desarrollo de Componentes

Es una unidad autocontenida que encapsula el estado y el comportamiento de

varios clasificadores. También se podría decir que es un tipo clasificador con la
diferencia de que no tiene características propias, pero contiene las clases que
definen las características.

Un componente proporciona una vista encapsulada de la funcionalidad definida por

las clases contenidas. Un componente es una parte física del sistema. Cada
componente tiene un nombre, el cual puede ser un nombre simple o un nombre de
ruta.

Las organizaciones almacenan grandes cantidades de datos, por eso, debe tenerse
en cuenta donde almacenarlos y como recuperarlos cuando se los necesita. Cuando
un sistema se desarrolla en forma apropiada, se puede recuperar en forma rápida la
información.

Los diseños de sistemas ayudan a disminuir los costos, ya que toma ventaja de las
capacidades de cálculo automático y de recuperación de datos que están incluidos
en procedimientos de programas en computadora. Muchas tareas son realizadas por
programas de cómputo, lo cual deja un número muy reducido de éstas para su
ejecución manual, disminuyendo al personal. Mediante una Fábrica de Software se
buscan:

 Proyectos que sigan los mismos estándares.

 Métricas de productividad.

 Búsqueda de mejora continua del servicio.

 Ganar confiabilidad de los clientes.

 Establecer proyectos de referencia.

 Establecer reconocimiento del servicio en el mercado.

 Mantenerse actualizado en tecnología.

6
  Convivencia necesaria entre las diversas tecnologías.

Tipos de componentes y caraterísticas

Componentes de despliegue o distribución (Deployment): Estos componentes se

usan para formar un sistema ejecutable. Un ejemplo de tal componente es la librería
de enlace dinámico y los archivos ejecutables. Otros ejemplos son los componentes
COM+, Enterprise Java Beans, componentes CORBA y objetos de base de datos.

Componentes de Producto de Trabajo: Estos componentes son parte del proceso de

desarrollo que es esencial para el sistema. Algunos ejemplos de componentes de
producto de trabajo son los archivos fuente, archivos de datos y tablas. Ellos son los
archivos fuente y archivos de datos que se usan para crear los componentes de
distribución como AgenteAnalizado.Java y AnalizadorDatos.txt.

Componentes de Ejecución: Estos componentes son el resultado de un sistema que

se está ejecutando. Cuando un DLL es instanciado como un componente COM+, es
un ejemplo de un componente de ejecución.

Características

 La característica fundamental de un componente es la habilidad de definir

interfaces.

 Es una unidad ejecutable que puede ser implantada independientemente.

 Puede ser sujeto de composición por terceras partes, es decir, una compañía
o un desarrollador puede llegar y tomar el componente y agregarlo a lo que
esté haciendo, o sea haría una composición de componentes.

 Un componente no tiene estado.

 Se puede tomar a los componentes de software como una analogía a los

componentes electrónicos

Estándares en el proceso de desarrollo de software

7
NORMAS ISO/IEC: Estándar para los procesos de ciclo de vida del software de la
organización, este estándar se concibió para aquellos interesados en adquisición de
software, así como desarrolladores y proveedores. El estándar indica una serie de
procesos desde la recopilación de requisitos hasta la culminación del software.

El estándar comprende 17 procesos lo cuales son agrupados en tres categorías:

1. Principales

1.1. Adquisiciones

1.2. Suministro

1.3. Desarrollo

1.4. Operación

1.5. Mantenimiento

2. De apoyo

2.1. Documentación

2.2. Gestión de la configuración

2.3. Aseguramiento de la calidad

2.4. Verificación

2.5. Validación

2.6. Revisión conjunto

2.7. Auditoría

2.8. Solución de problemas

3. De organización

3.1. Gestión

3.2. Mejora

3.3. Infraestructura

8
 3.4. Resursos humano

Este estándar agrupa las actividades que se pueden llevar a cabo durante el ciclo de
vida del software en cinco procesos principales, ocho procesos de apoyo y cuatro
procesos organizativos

Norma ISO/IEC 9126

La norma ISO/IEC 9126 de 1991, es la norma para evaluar los productos de software,
esta norma nos indica las características de la calidad y los lineamientos para su uso,
las características de calidad y sus métricas asociadas, pueden ser útiles tanto como
para evaluar el producto como para definir los requerimientos de la calidad y otros
usos. Esta norma definida por un marco conceptual basado en los factores tales
como Calidad del Proceso, Calidad del Producto del Software y Calidad en Uso;
según el marco conceptual, la calidad del producto, a su vez, contribuye a mejorar la
calidad en uso.

Estándar ISO/IEC 14598

El estándar ISO/IEC 14598 es actualmente usado como base metodológica para la

evaluación del producto software. En sus diferentes etapas, establece un marco de
trabajo para evaluar la calidad de los productos de software proporcionando,
además, métricas y requisitos para los procesos de evaluación de los mismos.

Norma ISO/IEC 25000 (SquaRE)

ISO 25000:2005 (SQuaRE -Software Quality Requirements and Evaluation) es una

nueva serie de normas que se basa en ISO 9126 y en ISO 14598 (Evaluación del
software). Uno de los principales objetivos de la serie SQuaRE es la coordinación y
armonización del contenido de ISO 9126 y de ISO 15939:2002 (Measurement
Information Model).

Documentación y Artefactos

La documentación no es más que la debilidad más frecuente en productos e

instalaciones informáticos. Cabe mencionar que los actores que intervienen en el
ciclo de vida del software desempeñan diversos roles. Arquitectos, diseñadores,
analistas, programadores, implementadores, administradores o auditores son
quienes explicitan distintos aspectos de los productos y procesos.

9
Un artefacto es una pieza de información que es producida o utilizada por procesos.
Los artefactos son los elementos son los elementos tangibles de un proyecto,
elementos que el proyecto produce o usa mientras se trabaja en busca del producto
final. Éstos, pueden tomar varias formas y formatos, como por ejemplo:

 Un documento, tal como la visión o la lista de riesgos.

 Un modelo, por ejemplo un diagrama de casos de uso o el modelo de

diseño.

 Un elemento dentro de un modelo, tal como una clase, un caso de uso o un

subsistema.

 Ejecutables, por ejemplo el ejecutable del prototipo.

 Código fuente.

Las actividades tienen artefactos como entrada y salida. Los roles usan artefactos
para ejecutar actividades y producen artefactos durante la ejecución de sus
actividades. Los artefactos son la responsabilidad sencilla del rol, creando
responsabilidades fáciles de identificar y entender, promoviendo la idea de que cada
pieza de información producida en un proceso de desarrollo requiere un conjunto
apropiado de habilidades. Aunque un rol puede ser el propietario de un artefacto,
otros roles pueden hacer uso de éste, incluso podrían actualizar el artefacto si el rol
que va a hacerlo, tiene permiso para hacerlo.

Metodologías empleadas: Proceso Unificado de Desarrollo (UP del inglés Unified

Process)

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo

extensible que puede ser adaptado a organizaciones o proyectos específicos. De la
misma forma, el Proceso Unificado de Rational, también es un marco de trabajo
extensible, por lo que muchas veces resulta imposible decir si un refinamiento
particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho
motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

10
El nombre Proceso Unificado se usa para describir el proceso genérico que incluye
aquellos elementos que son comunes a la mayoría de los refinamientos existentes.

Características

 Iterativo e Incremental: El Proceso Unificado es un marco de desarrollo

iterativo e incremental compuesto de cuatro fases denominadas Inicio,
Elaboración, Construcción y Transición. Cada una de estas fases es a su vez
dividida en una serie de iteraciones (la de inicio puede incluir varias
iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado
un incremento del producto desarrollado que añade o mejora las
funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que
recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de
requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones
suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro
de cada una de ellas varía a lo largo del proyecto.

 Dirigido por los casos de uso: En el Proceso Unificado los casos de uso se
utilizan para capturar los requisitos funcionales y para definir los contenidos
de las iteraciones. La idea es que cada iteración tome un conjunto de casos
de uso o escenarios y desarrolle todo el camino a través de las distintas
disciplinas: diseño, implementación, prueba, etc. El proceso dirigido por
casos de uso es el rup. Nota: en UP se está Dirigido por requisitos y riesgos
de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema.

 Centrado en la arquitectura: El Proceso Unificado asume que no existe un

modelo único que cubra todos los aspectos del sistema. Por dicho motivo
existen múltiples modelos y vistas que definen la arquitectura de software
de un sistema. La analogía con la construcción es clara, cuando construyes
un edificio existen diversos planos que incluyen los distintos servicios del
mismo: electricidad, fontanería, etc.

 Enfocado en los riesgos: El Proceso Unificado requiere que el equipo del

proyecto se centre en identificar los riesgos críticos en una etapa temprana
del ciclo de vida. Los resultados de cada iteración, en especial los de la fase
de Elaboración deben ser seleccionados en un orden que asegure que los
riesgos principales son considerados primero.

11
Fases de Desarrollo

1). Fase de Inicio:

Es la fase más pequeña del proyecto e, idealmente, debe realizarse también en un

periodo de tiempo pequeño (una única iteración).

El hecho de llevar a cabo una fase de inicio muy larga indica que se esta realizando
una especificación previa excesiva, lo que responde más a un modelo en cascada.

2). Fase de Elaboración:

Durante esta fase se capturan la mayoría de los requisitos del sistema.

Los objetivos principales de esta fase serán la identificación de riesgos y establecer y

validar la arquitectura del sistema.

Base de Arquitectura Ejecutable:

La arquitectura se valida a través de la implementación de una Base de

Arquitectura Ejecutable: se trata de una implementación parcial del sistema que
incluye los componentes principales del mismo.

Al final de la fase de elaboración la base de arquitectura ejecutable debe demostrar

que soporta los aspectos clave de la funcionalidad del sistema y que muestra la
conducta adecuada en términos de rendimiento, escalabilidad y coste.

3). Fase de construcción.

Es la fase más larga de proyecto.

El sistema es construido en base a lo especificado en la fase de elaboración.

Las características del sistema se implementan en una serie de iteraciones cortas y

limitadas en el tiempo.

El resultado de cada iteración es una versión ejecutable de software.

El hito de capacidad operativa inicial marca el final de la fase.

Fase de transición.

12
En esta fase el sistema es desplegado para los usuarios finales.

La retroalimentación recibida permite incorporar refinamientos al sistema en las

sucesivas iteraciones.

Esta iteración también cubre el entrenamiento de los usuarios para la utilización del
sistema.

Disciplinas

a). Modelado del negocio

El objetivo es establecer un canal de comunicación entre los ingenieros del negocio y

los ingenieros del software.

Los ingenieros del software deben conocer la estructura y dinámica de la

organización objetivo (el cliente), los problemas actuales y sus posibles mejoras.

Se plasma en la identificación del modelo del dominio en el que se visualizan los

aspectos básicos del dominio de aplicación.

b). Requisitos

El objetivo es describir que es lo que tiene que hacer el sistema y poner a los
desarrolladores y al cliente de acuerdo en esta descripción.

c). Análisis y diseño

Describe como el software será realizado en la fase de implementación.

Se plasma en un modelo de diseño que consiste en una serie de clases (agrupadas

en paquetes y subsistemas) con interfaces bien definidos.

También contiene descripciones de cómo los objetos colaboran para realizar las
acciones incluidas en los casos de uso.

d). Implementación

Se implementan las clases y objetos en términos de componentes (ficheros fuentes,

binarios, ejecutables, entre otros).

13
e). Prueba

Se comprueba que el funcionamiento es correcto analizando diversos aspectos: los

objetos como unidades, la integración entre objetos, la implementación de todos los
requisitos, entre otros

f). Despliegue

Se crea la versión externa del producto, se empaqueta, se distribuye y se instala en

el lugar de trabajo. También se da asistencia y ayuda a los usuarios.

Introducción a los procesos ágiles de desarrollo.

El Agile UP (AUP) es una versión simplificada de Rational Unified Process (RUP). Este
describe un enfoque simple y fácil de entender para el desarrollo de software
usando técnicas y conceptos que aún se mantienen vigentes en RUP.

Los enfoques aplican técnicas ágiles incluidas en el Desarrollo Dirigido por Pruebas
(TDD), Desarrollo Dirigido por Modelado Ágil (AMDD), administración de cambios
ágil, y refactorización de bases de datos para mejorar la productividad.

La naturaleza serial en Agile UP es capturada en cuatro fases:

1. Iniciación: El objetivo es identificar el alcance inicial del proyecto, una

arquitectura potencial de su sistema, y obtener la financiación inicial del
proyecto y la aceptación del involucrado.

2. Elaboración: El objetivo es mejorar la arquitectura del sistema.

3. Construcción: El objetivo es construir software funcional en una base regular

e incremental, la cual cumpla con las necesidades de prioridad más alta de
los involucrados de su proyecto.

4. Transición: El objetivo es validar y desplegar su sistema en su ambiente de

producción.

14
Elementos para interpretar el modelado de software (Lenguaje Unificado de
Modelado).

El lenguaje de modelado unificado (UML) es un estándar para la representación

visual de objetos, estados y procesos dentro de un sistema. Por un lado, el lenguaje
de modelado puede servir de modelo para un proyecto y garantizar así una
arquitectura de información estructurada; por el otro, ayuda a los desarrolladores a
presentar la descripción del sistema de una manera que sea comprensible para
quienes están fuera del campo. UML se utiliza principalmente en el desarrollo de
software orientado a objetos. Al ampliar el estándar en la versión 2.0, también es
adecuado para visualizar procesos empresariales.

Antes de que UML se introdujera en el desarrollo de software, el campo de la

programación orientada a objetos (OOP) había crecido. Este estilo de programación
se basa en el concepto de que todo es un objeto: los bloques de construcción de un
programa son objetos que interactúan entre sí, los mensajes que se envían de un
lado a otro entre los componentes también constan de objetos. Cada objeto
individual es un ejemplo de su clase superior. La clase misma también actúa como
un objeto y también determina el comportamiento de las instancias de objetos que
contiene. Los objetos consisten en datos y código. El objeto organiza los datos en
campos, también llamados atributos. El código determina su procedimiento o
método.

El Lenguaje Unificado de Modelado es referido por algunos como la lingua franca

entre los lenguajes de modelado. Como se mencionó al principio, el UML visualiza
los estados y las interacciones entre objetos dentro de un sistema. Su extensa
popularidad se debe probablemente a la fuerte influencia que ejercen los miembros
del OMG (IBM, Microsoft y HP entre otros). La semántica estructurada hace el resto.
Los diagramas UML se utilizan para representar los siguientes componentes del
sistema:

Objetos individuales (elementos básicos)

 Clases (combina elementos con las mismas propiedades)

 Relaciones entre objetos (jerarquía y comportamiento/comunicación entre

objetos)

 Actividad (combinación compleja de acciones/módulos de comportamiento)

15
  Interacciones entre objetos e interfaces

Tipos de diagramas

1). Diagramas de estructura

Los diagramas de estructura representan los elementos individuales de un sistema.

Por lo tanto, son especialmente adecuados para la representación de la arquitectura
de software. La representación estática no representa un cambio, sino estados y
dependencias en un momento determinado. Los elementos individuales u objetos
están relacionados entre sí. Por ejemplo, un objeto pertenece a una clase. Otros
componentes son nodos de ordenador o artefactos –un artefacto representa un
resultado, por ejemplo, un archivo de script terminado.

 Diagrama de clases: si los objetos tienen un comportamiento común o la

misma estructura, pueden clasificarse (asignarse a una clase). La clase es, por
tanto, un elemento simplificador (abstracción) para la representación visual.
Las clases y los objetos están conectados entre sí mediante interfaces. El
diagrama de clase muestra todos estos componentes y sus interrelaciones.
Una clase representa el diagrama con un rectángulo. Contiene el nombre de
la clase en negrita, como se muestra a continuación.

 Diagrama de objetos: el diagrama de objetos tiene una estructura similar a la

del diagrama de clases. Cuando el nombre aparece en el diagrama de clase
(ver Persona arriba), el diagrama de objeto especifica el nombre de la
instancia junto con el nombre del clasificador/categoría. De acuerdo con el
pliego de condiciones, se subraya lo siguiente (por ejemplo: Helga:Persona)

 Diagrama de componentes: un componente es un módulo que está aislado

del sistema externo e interactúa con otros componentes mediante interfaces
definidas. Es un subformulario de la clase. Por lo tanto, las características
estructurales, como las operaciones y los atributos, definen el componente
con mayor precisión. El componente contiene varios componentes. Estos
pueden ser de nuevo componentes, pero también clases, subsistemas o
partes. Hay dos opciones de visualización diferentes para el modelado: Black
Box o caja negra(el contenido está oculto) y White Box o caja blanca (el
contenido es visible).

16
  Diagrama de estructura compositiva: los objetos pertenecen a clases. Estos,
a su vez, también pueden clasificarse. Estas metaclases se denominan
clasificadores en UML. El diagrama de estructura de la composición
representa las partes y conectores de un clasificador. Las partes son siempre
parte del todo, incluso si no son necesarias para completar el clasificador. Los
conectores son las conexiones entre las partes. Las características o servicios
que requieren componentes externos al clasificador envían las piezas a
través de una interfaz.

 Diagrama de paquete: un paquete agrupa elementos como interfaces o

clases en un espacio de nombres. Los paquetes (packages) también pueden
fusionarse con otros paquetes (fusión de paquetes), importarlos
(importación de paquetes) o contener otros paquetes (subpaquetes). Los
paquetes estructuran el contenido del diagrama jerárquicamente como en
un diagrama de árbol. El diagrama de paquete se utiliza, por ejemplo, en el
metamodelo de UML 2. En los sistemas de software representa las subáreas
de forma modular. Según la especificación, un paquete consta de una
cabecera y un área de contenido

Paquete con clase A y B y una interfaz

En la cabecera el paquete de palabras clave describe el elemento, "paquete" es el

nombre. En el área de contenido, el paquete incluye una interfaz y dos clases.

 Diagrama de distribución: el diagrama de distribución modela la distribución

física de los artefactos en nodos. Los nodos pueden ser hardware (device
nodes), que puede proporcionar memoria, o software (execution
environment nodes), que proporciona un entorno para ejecutar procesos. Se
representan como cuboides tridimensionales. Los artefactos se dibujan como
rectángulos conteniendo el nombre del archivo. Para distinguirlo de una
clase, añade el estereotipo <<artefact>>. El diagrama es adecuado para
visualizar dependencias entre nodos y artefactos, las llamadas relaciones de
distribución.

 Gráfica de perfil: los diagramas de perfil se utilizan a nivel de metamodelo.

Se utilizan para asignar un estereotipo a las clases o un perfil a los paquetes.
En el metanivel tienes la posibilidad de adaptar el modelo para otra
plataforma o dominio. Por ejemplo, si restringes la semántica UML dentro de
un perfil, transfieres las especificaciones a las clases subordinadas.

17
2). Diagramas de comportamiento

Los diagramas de comportamiento cubren las especificaciones restantes bajo UML.

A diferencia de los diagramas estructurales, no son estáticos, sino que representan
procesos y situaciones dinámicas. Los diagramas de comportamiento también
incluyen los diagramas de interacción.

 Diagrama de casos de uso: el diagrama de casos de uso muestra el

comportamiento que se esperará de un sistema más adelante. Este modelo
no solo es adecuado para sistemas de software, sino también, por ejemplo,
para procesos esperados en las relaciones comerciales. El caso de uso
involucra a un actor (humano o sistema) con un objetivo. El diagrama
normalmente tiene como nombre el objetivo. Los diferentes casos de uso
dentro del sistema cumplen el objetivo del actor.

 Diagrama de actividades: las actividades consisten en una red de acciones

que se relacionan entre sí mediante flujos de datos y de control. Mientras
que el Diagrama de casos de uso muestra los requisitos del sistema, el
Diagrama de actividades muestra cómo funcionan estos casos de uso. En
este tipo de diagrama, por ejemplo, el token juega un papel importante: en
los procesos paralelos, es un marcador para el cual se priorizan los procesos
y, por lo tanto, se reciben los recursos (por ejemplo, la memoria de trabajo).

 Diagrama de máquina de estados: una máquina de estados, también

llamada autómata finito, representa un conjunto finito de estados en un
sistema. Si se cumple una condición definida en el sistema (se detona un
desencadenante), se produce una situación correspondiente. Esto puede
incluir actividades o interacciones.

2.1). Diagramas de interacción

Los diagramas de interacción son un subtipo de los diagramas de comportamiento.

Por lo tanto, también representan situaciones dinámicas. En particular, son
adecuados para modelar el comportamiento en el que los elementos intercambian
información. Los diagramas definen el papel de los objetos implicados. También
nombran y priorizan los mensajes que se envían de un lado a otro entre los objetos.
Los diagramas de interacción también muestran cómo estos mensajes afectan a los
elementos del comportamiento. Por ejemplo, puede iniciar o detener actividades.

18
  Diagramas de secuencia: como diagrama de interacción, el diagrama de
secuencia representa el intercambio de mensajes entre objetos. El tipo de
diagrama UML modela estos objetos como las llamadas líneas de vida. En
este sentido, es similar a otros diagramas de comportamiento como el
diagrama de actividad. Sin embargo, a diferencia de estos, el diagrama de
secuencia no se utiliza para obtener una visión general del comportamiento
de un sistema, sino para presentar un posible comportamiento entre muchos
otros en detalle. Prescribe una cronología. Una línea discontinua representa
el curso del tiempo.

 Diagrama de comunicación: al igual que el diagrama de secuencia, el

diagrama de comunicación modela una transferencia de mensajes. Sin
embargo, este diagrama UML no utiliza líneas discontinuas para la secuencia
de tiempo, sino que numera las secuencias con números y letras. Estos
llamados términos de secuencia se encuentran encima de una flecha con la
punta apuntando hacia el receptor. Los números representan el orden en
que se envían los mensajes, las letras representan el nivel jerárquico.

 Diagrama de tiempos: el diagrama de tiempos permite mostrar el

comportamiento de los sistemas en detalle en función de la secuenciación
temporal. Los sistemas en tiempo real, por ejemplo, tienen que manejar
ciertos procesos dentro de un cierto período de tiempo. UML 2.0 modela el
diagrama de temporización como un diagrama bidimensional con un eje x y
un eje y para representar mejor el plano temporal. Con este subformulario
del diagrama de secuencia, los estados de los objetos se encuentran en el eje
y y las secuencias de tiempo asignadas a ellos se ejecutan a lo largo del eje y.

 Diagrama de interacción: el nuevo diagrama de interacción añadido a UML

2.0 ayuda a mostrar un sistema muy complejo primero en un esquema
aproximado, si un diagrama de interacción normal se vuelve demasiado
confuso. Un diagrama de secuencia, por ejemplo, es adecuado para la
visualización detallada. El diagrama UML es similar al diagrama de actividad
con nodos. Representa los flujos de control entre interacciones.

Categoría

1). Estructura

 Diagrama de clases: Visualizar clases

19
  Diagrama de objetos: Estado del sistema en un momento dado

 Diagrama de componentes: Estructurar componentes y mostrar relaciones

 Diagrama de estructura compositiva: Divide los componentes o clases en sus

componentes y aclara sus relaciones.

 Diagrama de paquete: Agrupa las clases en paquetes, muestra la jerarquía y

la estructura de los paquetes.

 Diagrama de distribución: Distribución de componentes a los nodos

informáticos

 Gráfica de perfil: Ilustra contextos de uso a través de estereotipos,

condiciones límite, etc.

2). Comportamiento

 Diagrama de casos de uso: Representa varias aplicaciones

 Diagrama de actividades: Describe el comportamiento de diferentes

procesos (paralelos) en un sistema.

 Diagrama de máquina de estados: Documenta cómo un objeto es movido de

un estado a otro por un evento.

2.1). Comportamiento interacción

 Diagrama secuencial: Secuencia temporal de las interacciones entre objetos

 Diagrama de comunicación: Distribución de roles de los objetos dentro de

una interacción

 Diagrama de tiempos: Limitación de tiempo para los acontecimientos que

conducen a un cambio de estado

 Diagrama de interacción: Secuencias y actividades interactivas

Símbolos y notación de los diagramas

20
Un diagrama es una representación gráfica de una colección de elementos de
modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vértices
(otros elementos del modelo). Un diagrama no es un elemento semántico, un
diagrama muestra representaciones de elementos semánticos del modelo, pero su
significado no se ve afectado por la forma en que son representados. Un diagrama
está contenido dentro de un paquete.

La mayoría de los diagramas de UML y algunos símbolos complejos son grafos que
contienen formas conectadas por rutas. La información está sobre todo en la
topología, no en el tamaño o la colocación de los símbolos (hay algunas excepciones
como el diagrama de secuencia con un eje métrico de tiempo). Hay tres clases
importantes de relaciones visuales: conexión (generalmente de líneas a formas de
dos dimensiones), contención (de símbolos por formas cerradas de dos
dimensiones), y adhesión visual (un símbolo que está "cerca" de otro en un
diagrama). Estas relaciones geométricas se reasignan a conexiones entre nodos en
un gráfico en la forma analizada de la notación.

La notación de UML está pensada para ser dibujada en superficies bidimensionales.

Algunas formas bidimensionales son proyecciones de formas tridimensionales tales
como cubos, pero todavía se representan como íconos en una superficie
bidimensional.

Hay cuatro clases de construcciones gráficas que se usan en la notación de UML :

íconos, símbolos bidimensionales, rutas y cadenas.

Un icono es una figura gráfica con un tamaño y forma fijos. No se amplía para
contener a su contenido. Los iconos pueden aparecer dentro de símbolos de área,
como terminadores en las rutas o como símbolos independientes que puedan o no
conectar con las rutas.

Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden

ampliarse para permitir otras cosas tales como listas de cadenas o de otros
símbolos. Muchos de ellos están divididos en compartimientos similares o de tipos
diferentes. Las rutas se conectan con los símbolos, el arrastrar o suprimir uno de
ellos afecta a su contenido y las rutas conectadas.

21
Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus
puntos finales. Conceptualmente una ruta es una sola entidad topológica, aunque
sus segmentos se pueden manipular gráficamente. un segmento no debería existir
separado de su ruta. Las rutas siempre van conectadas en ambos extremos.

Las cadenas presentan varias clases de información en una forma "no analizada",
UML asume que cada uso de una cadena en la notación tiene una sintaxis por la cual
pueda ser analizada la información del modelo subyacente. Las cadenas pueden
existir como el contenido de un compartimiento, como elementos en las listas, como
etiquetas unidas a los símbolos o a las rutas, o como elementos independientes en
un diagrama.

Uso de Herramientas CASE en el modelado

Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de

Software Asistida por Computadora) son diversas aplicaciones informáticas o
programas informáticos destinadas a aumentar el balance en el desarrollo de
software reduciendo el costo de las mismas en términos de tiempo y de dinero.

Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de
desarrollo del software en tareas como el proceso de realizar un diseño del
proyecto, cálculo de costos, implementación de parte del código automáticamente
con el diseño dado, compilación automática, documentación o detección de errores
entre otras.

22
Objetivos

 Mejorar la productividad del software.

 Aumentar la calidad del software.

 Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas

informáticos.

 Mejorar la planificación de un proyecto.

 Aumentar la biblioteca de conocimiento informático de una empresa

ayudando a la búsqueda de soluciones para los requisitos.

 Automatizar el desarrollo del software, la documentación, la generación de

código, las pruebas de errores y la gestión del proyecto.

 Ayuda a la reutilización del software, portabilidad y estandarización de la

documentación.

 Gestión global en todas las fases de desarrollo de software con una misma
herramienta.

 Facilitar el uso de las distintas metodologías propias de la ingeniería del

software.

Conclusión

En conclusión gracias a los importantes estándares como el proceso de software

personal es de gran ayuda para los ingenieros involucrados en el proyecto ya que les
permite mejorar la forma en que trabajan y controlar los tiempos mediante
formatos de tiempo para cada una de las actividades y que el software desarrollado
sea de calidad. Por último la aplicación de una norma o estándar los podemos
aplicar en nuestros proyectos de acuerdo a la necesidades de dicho proyecto.

23
24