República Bolivariana De Venezuela

Ministerio del poder popular para la defensa

Universidad Nacional Experimental de las fuerzas armadas unefa

Sección:06S2603D1 ING.SISTEMAS

TALLER PRÁCTICO

DISEÑO DE PROGRAMAS Y DISEÑO ORIENTADO A OBJETOS.

PROFESORA: Alumno:

Lingzay Acosta. Victor

Solorzano

Ci:29716623

FECHA 11/12/2020
 Unidad 6

DISEÑO DE PROGRAMAS:

Diseñar un programa supone describir objetivos, seleccionar y

secuenciar contenidos y actividades así como especificar la
metodología y forma de evaluación incluyendo adecuación al
currículum, al aula y a los contextos educativos para los cuales se
diseña.. Supone, en definitiva, trasladar la filosofía del currículo a
un plan detallado de enseñanza que variará en función del
paradigma del que el programa sea reflejo.

El modo concreto en que el diseñador aplica la prioridad, selección,

subdivisión y secuenciación de objetivos y contenidos, así como la
selección de la metodología y el sistema de evaluación, refleja
puntos de vista sobre la lengua, sobre la forma de usarla y sobre su
concepción de la enseñanza y aprendizaje de una lengua. En este
sentido, cabe afirmar que diseñar un programa de lengua puede
entenderse como una expresión de un determinado paradigma
científico, en tanto que representación concreta de conocimientos
y capacidades. La representación de la lengua de un diseñador de
programas diferirá, por ejemplo, de la de un lingüista descriptivo,
debido precisamente a los requisitos pedagógicos de dicha
representación.
Diseño modular:

La modularidad es, en programación modular y más

específicamente en programación orientada a objetos, 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 que se puedan compilar por separado, pero que

tienen conexiones con otros módulos. Al igual que la
encapsulación, los lenguajes soportan la Modularidad de diversas
formas. La modularidad debe seguir los conceptos de acoplamiento
y cohesión.

EJEMPLO:
DESCOMPOSICION MODULAR:

Descomposición Modular o Modularización es el proceso de

descomposición de un sistema en un conjunto de elementos con un
índice bajo acoplamiento (independientes) y alto índice de
cohesión (con significado propio).

Consiste en descomponer el problema a resolver en módulos o

tareas más simples. Cada tarea representa una actividad completa
y se codifica de manera independiente. Facilita el diseño
descendente del problema, centrándonos cada vez en la resolución
de subproblemas de magnitud inferior.

A la resolución de cada uno de estos subproblemas de complejidad

inferior se denomina refinamiento por pasos. Los módulos pueden
ser planificados, codificados, comprobados y depurados
independientemente, y a continuación se combinan uno a uno con
otros módulos.

El diseño modular propone dividir el sistema en partes

diferenciadas y definir sus interfaces.

EJEMPLO:
Diseño asistido por herramientas case:

Herramientas CASE (Computer Aided Software Engineering,

Ingeniería de Software Asistida por Computadoras). Son diversas
Aplicaciones informáticas destinadas a aumentar la productividad
en el Desarrollo de software reduciendo el coste de las mismas en
términos de tiempo y de dinero. Estas herramientas nos pueden
ayudar en todos los aspectos del ciclo de vida de desarrollo del
software en tareas como el diseño de proyectos, cálculo de costes,
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.

Es un sistema de software que intenta proporcionar ayuda

automatizada a las actividades del proceso de desarrollo de
software. Los sistemas CASE a menudo se utilizan como apoyo al
método. La primera herramienta CASE como hoy la conocemos fue
Excelerator en 1984, era para PC. Actualmente la oferta de
herramientas CASE es muy amplia y tenemos por ejemplo el
EASYCASE o WINPROJECT .

Componentes de una herramienta CASE

De una forma esquemática podemos decir que una herramienta

CASE se compone de los siguientes elementos:

• Repositorio (diccionario) donde se almacenan los elementos

definidos o creados por la herramienta, y cuya gestión se realiza
mediante el apoyo de un Sistema de Gestión de Base de Datos
(SGBD) o de un sistema de gestión de ficheros.

• Metamodelo (no siempre visible), que constituye el marco para la

definición de las técnicas y metodologías soportadas por la
herramienta.

• Carga o descarga de datos, son facilidades que permiten cargar el

repertorio de la herramienta CASE con datos provenientes de otros
sistemas, o bien generar a partir de la propia herramienta
esquemas de base de datos, programas, etc. que pueden, a su vez,
alimentar otros sistemas. Este elemento proporciona así un medio
de comunicación con otras herramientas.

• Comprobación de errores, facilidades que permiten llevar a cabo

un análisis de la exactitud, integridad y consistencia de los
esquemas generados por la herramienta.

• Interfaz de usuario, que constará de editores de texto y

herramientas de diseño gráfico que permitan, mediante la
utilización de un sistema de ventanas, iconos y menús, con la ayuda
del ratón, definir los diagramas, matrices, etc. que incluyen las
distintas metodologías.

Estructura general de una herramienta CASE

La estructura CASE se basa en la siguiente terminología :

Estructura1.jpeg

• CASE de alto nivel son aquellas herramientas que automatizan o

apoyan las fases finales o superiores del ciclo de vida del desarrollo
de sistemas como la planificación de sistemas, el análisis de
sistemas y el diseño de sistemas.

• CASE de bajo nivel son aquellas herramientas que automatizan o

apoyan las fases finales o inferiores del ciclo de vida como el diseño
detallado de sistemas, la implantación de sistemas y el soporte de
sistemas.

• CASE cruzado de ciclo de vida se aplica a aquellas herramientas

que apoyan actividades que tienen lugar a lo largo de todo el ciclo
de vida, se incluyen actividades como la gestión de proyectos y la
estimación.

Clasificación

Aunque no es fácil y no existe una forma única de clasificarlas, las

herramientas CASE se pueden clasificar teniendo en cuenta los
siguientes parámetros:
1. Las plataformas que soportan.

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

3. La arquitectura de las aplicaciones que producen.

4. Su funcionalidad.

La clasificación basada en las fases del ciclo de desarrollo cubre:

Upper CASE (U-CASE), herramientas que ayudan en las fases de

planificación, análisis de requisitos y estrategia del desarrollo,
usando, entre otros diagramas UML.

Middle CASE (M-CASE), herramientas para automatizar tareas en el

análisis y diseño de la aplicación.

Lower CASE (L-CASE), herramientas que semi-automatizan la

generación de código, crean programas de detección de errores,
soportan la depuración de programas y pruebas. Además
automatizan la documentación completa de la aplicación. Aquí
pueden incluirse las herramientas de Desarrollo rápido de
aplicaciones.

Existen otros nombres que se le dan a este tipo de herramientas, y

que no es una clasificación excluyente entre sí, ni con la anterior:
Integrated CASE (I-CASE), herramientas que engloban todo el
proceso de desarrollo software, desde análisis hasta
implementación.

MetaCASE, herramientas que permiten la definición de nuestra

propia técnica de modelado, los elementos permitidos del
metamodelo generado se guardan en un repositorio y pueden ser
usados por otros analistas, es decir, es como si definiéramos
nuestro propio UML, con nuestros elementos, restricciones y
relaciones posibles.

CAST (Computer-Aided Software Testing), herramientas de soporte

a la prueba de software.

IPSE (Integrated Programming Support Environment), herramientas

que soportan todo el ciclo de vida, incluyen componentes para la
gestión de proyectos y gestión de la configuración.

Por funcionalidad podríamos diferenciar algunas como:

Herramientas de generación semiautomática de código.

Editores UML.

Herramientas de Refactorización de código.

Herramientas de mantenimiento como los sistemas de control de

versiones.

Ejemplos de Herramientas Case más utilizadas.

ERwin
PLATINUM ERwin es una herramienta de diseño de base de datos.
Brinda productividad en diseño, generación, y mantenimiento de
aplicaciones. Desde un modelo lógico de los requerimientos de
información, hasta el modelo físico perfeccionado para las
características específicas de la base de datos diseñada, ERwin
permite visualizar la estructura, los elementos importantes, y
optimizar el diseño de la base de datos. Genera automáticamente
las tablas y miles de líneas de stored procedure y triggers para los
principales tipos de base de datos.

EasyCASE

EasyCASE Profesional, el centro de productos para procesos,

modelamiento de datos y eventos, e Ingeniería de Base de Datos,
es un producto para la generación de esquemas de base de datos e
ingeniería reversa, trabaja para proveer una solución comprensible
para el diseño, consistencia y documentación del sistema en
conjunto.

Oracle Designer

Oracle Designer es un juego de herramientas para guardar las

definiciones que necesita el usuario y automatizar la construcción
rápida de aplicaciones cliente/servidor flexibles y gráficas.
Integrado con Oracle Developer, Oracle Designer provee una
solución para desarrollar sistemas empresariales cliente/servidor
de segunda generación.
PowerDesigner

Poerdesigner.jpeg

PowerDesigner es una suite de aplicaciones de Powersoft para la

construcción, diseño y modelado de datos a través de diversas

aplicaciones. Es la herramienta para el análisis, diseño inteligente y

construcción sólida de una base de datos y un desarrollo orientado
a modelos de datos a nivel físico y conceptual, que dan a los
desarrolladores de aplicaciones Cliente/Servidor la más firme base
para aplicaciones de alto rendimiento.

System Architect

System Architect posee un repositorio único que integra todas las

herramientas, y metodologías usadas. En la elaboración de los
diagramas, el System Architect conecta directamente al diccionario
de datos, los elementos asociados, comentarios,reglas de
validaciones, normalización, etc. Posee control automático de
diagramas y datos, normalizaciones y balanceo entre diagramas
"Padre e Hijo", además de balanceo horizontal, que trabaja
integrado con el diccionario de datos, asegurando la compatibilidad
entre el Modelo de Datos y el Modelo Funcional.

SNAP
SNAP es un CASE para el desarrollo de aplicaciones en Sistemas
AS/400 de IBM. Proporciona el ambiente integral de trabajo,
brindando la posibilidad de construir sistemas de inmejorable
calidad, adheridos a los estándares S.A.A de IBM., totalmente
documentados y ajustados a los requerimientos específicos de la
organización, en una fracción del tiempo y coste del que se
invertiría, si se utilizaran herramientas tradicionales.

Generadores Automaticos:

En computación, un generador es una rutina especial que se puede

usar para controlar el comportamiento de un iterador en un bucle.
Un generador es muy similar a una función que devuelve un vector,
en el que un generador tiene los parámetros que se pueden llamar,
y genera una secuencia de valores.

En lugar de construir un vector que contenga todos los valores y

devolverlos de una vez, un generador proporciona un valor a la vez,
lo que requiere menos memoria y, por lo tanto, permite que quien
lo llama comience a procesar los primeros valores inmediatamente.
En resumen, un generador se asemeja a una función pero se
comporta como un iterador.

Los generadores pueden implementarse en construcciones de

control de flujo más expresivas, como la continuación de objetos de
primera clase o como co-funciones.
Los generadores aparecen por primera vez en 1975 en el lenguaje
[[CLU]; y están disponibles en Python, C #, JavaScript, [Ruby] y en
otros idiomas. En CLU y C#, los generadores se llaman iteradores y
en Ruby enumeradores.

UNIDAD 7

Diseño orientado a objetos:

El diseño orientado a objetos (DOO) es una fase de la metodología

orientada a objetos para el desarrollo de software.

Su uso induce a desarrolladores y programadores a pensar en

términos de objetos y responsabilidades, en vez de procedimientos,
cuando planifican el código.

Un objeto agrupa datos encapsulados y procedimientos para

representar una entidad. La "interfaz del objeto", esto es, las
responsabilidades del objeto, también se definen en esta etapa.

Un programa orientado a objetos se caracteriza por la interacción

de esos objetos.
El diseño orientado a objetos es la disciplina que define los objetos
y sus interacciones para resolver un problema de negocio que fue
identificado y documentado durante el análisis orientado a objetos
(AOO).

Ejemplo:

Diseño de componentes de dominio de problema:

El componente del dominio del problema (PDC) es el conjunto

básico de objetos funcionales que llega de la etapa de análisis. Tales
objetos directamente resuelven el problema que se pretende ser
resuelto por el sistema que se está construyendo, lo que quiere
decir que el diseño del PDC se termina en su mayor parte en la
etapa de análisis, completándose ahora con la ejecución de tres
actividades, las cuales son:

Diseño de reuso: Se pueden añadir en esta etapa nuevas clases

para reusar objetos que serán útiles más adelante. Es el caso de los
paquetes comerciales de clase generalizada como las que
contienen las organizaciones de programadores OO con
experiencia, ellos por lo general poseen una biblioteca de clases
desarrollada para los objetos. Estas bibliotecas y paquetes pueden
contener clases que tienen atributos y servicios para objetos
similares a los requeridos en el diseño del sistema a desarrollarse.
Estas clases reusables pueden ser añadidas al diseño como clases
bases en una estructura Gen-Spec.

Estructura de Implementación: Debido a la implementación en un

lenguaje de programación en particular podría ser necesario que
en el diseño se agreguen estructuras que pueden ser de agregación,
o Gen-Spec, este último para permitir que varias clases de objetos
compartan un protocolo o estructura de datos. Estas estructuras
usan el concepto de herencia para hacer más fácil el enfoque de
programación.

Acomodo al lenguaje: En esta sección podemos corregir (si es

necesario) el diseño para que las estructuras puedan ser
construidas en el lenguaje de programación seleccionado, debido a
que estos lenguajes pueden tener diferentes patrones de herencia.
Algunos lenguajes, por ejemplo, incluyen herencia múltiple (C++),
otros solamente incluyen herencia simple (Java) y todavía otros que
posiblemente no incluyen herencia. En los casos más restrictivos,
los patrones de herencia del diseño deben ser modificados para
permitir las capacidades del lenguaje de programación.
En la figura anterior se observa que el objeto Tren hereda de Listas
y Celdas (clases propias de la biblioteca de C++), pero al no tener C+
+ forma de manejar dos estructuras Gen-Spec con Listas se tuvo
que crear una segundo estructura llamada ListaCarrros y
conectarlos uno a uno con el objeto Tren.

Diseño del Componente de Interfaz Humana:

En esta actividad creamos los menús, reportes y pantallas

interactivas que usarán las personas para trabajar con el sistema.
Por lo general, se puede obtener ayuda en gran forma en clases de
bibliotecas para el diseño de clases de Interfaz. Esta es un área
donde la reusabilidad de las clases Orientado a Objetos ha probado
ser muy efectiva. Las clases de bibliotecas generalmente
proporcionan generalizaciones de menús, ventanas, control de tipo
de letra, y utilerías de cortar y pegar.

Los prototipos son muy útiles durante el diseño de Interfaz para

hacer más fácil la manera en que trabajarán las clases de biblioteca
con los objetos del Dominio.

Por lo general, con la información obtenida en las entrevistas y

casos de uso podemos recopilar información acerca de los perfiles
de usuarios involucrados en el sistema y diseñar una interfaz
correspondiente a su perfil. Con base a estos y otros perfiles,
podemos seleccionar una interfaz.

Diseño de Componentes de administración de tareas y Datos:

Ambos componentes están estrechamente relacionados con la

tecnología de implementación. El manejo de tareas esta muy
determinado por la configuración de hardware de computación, y
el manejo de datos esta muy determinado por el software de
sistema disponible cuando el sistema este de hecho en ejecución.

El componente de manejo de tareas es más importante cuando el

sistema está ejecutándose en varios procesadores o computadoras.
Una “tarea”es un conjunto de servicios relacionados que deben
ejecutarse juntos (tal ves en el mismo procesador). Las tareas son
activadas por el tiempo transcurrido o por un evento. Los objetos
del manejo de tarea obedecen a activadores de tareas, asignación
de procesadores y prioridades

cuando son llamados los servicios.

Un ejemplo de componente de tareas es como se muestra a

continuación, en él, el tema del componente de manejo de tareas
se añade al paquete de diagrama de capas existente. Este
componente es implementado luego creando objetos Tarea
conforme son necesarios por el sistema.

El componente de Manejo de Datos comprende, por lo general,

clases y objetos necesarios para almacenar y recuperar a los otros
objetos del sistema. El Componente Manejo de Datos varia
considerablemente dependiendo de si la tecnología de tiempo de
ejecución subyacente es una base de datos orientada a objetos,
una base de datos relacional o un sistema de archivos “plano”
ordinario. En un ambiente de Base de Datos relacional o de archivo
plano el componente de manejo de datos debe proporcionar
servicios de almacenamiento al sistema.

Hay tres formas diferentes para diseñar el Diagrama de Manejo de

Datos:

1. Construir servicios de almacenamiento en cada Clase y Objetos

en el diseño: Esto involucra, por lo general, una cantidad
considerable de programación de diseño adicional.

2. Crear una Clase y Objeto, ServidorObjeto, que proporcione todos

los servicios de Base de Datos: Involucra un complejo objeto que
sepa cómo guardar o recuperar todos los objetos del sistema.
Cualquier petición de almacenamiento se hace por medio de
mensajes a este único objeto cuyo diseño podría ser como el que se
muestra a continuación.
3. Crear una clase Almacenable: Es una combinación de los dos
enfoques anteriores. Cada objeto del sistema que deba ser
guardado o recuperado es conectado luego a una estructura Gen-
Spec con la clase almacenable. La figura a continuación es un
ejemplo de ésta.

Enfoque alternativo y notación para su implantación:

Implantación del enfoque de sistemas Introducción El enfoque de

sistemas es un diseño metodológico que se presenta como mentor
para la solución de problemas, principalmente aquellos que nacen
en la administración de un sistema, al existir una discrepancia entre
lo que se tiene y lo que se desea, su problemática, sus
componentes y su solución. Son las actividades que determinan un
objetivo general y la justificación de cada uno de los subsistemas.

Conceptos orientados a objetos:

Los conceptos Orientados a Objetos (POO) es un paradigma de

programación, es decir, un modelo o un estilo de programación que
nos da unas guías sobre cómo trabajar con él. Se basa en el
concepto de clases y objetos. Este tipo de programación se utiliza
para estructurar un programa de software en piezas simples y
reutilizables de planos de código (clases) para crear instancias
individuales de objetos.

A lo largo de la historia, han ido apareciendo diferentes paradigmas

de programación. Lenguajes secuenciales como COBOL o
procedimentales como Basic o C, se centraban más en la lógica que
en los datos. Otros más modernos como Java, C# y Python, utilizan
paradigmas para definir los programas, siendo la Programación
Orientada a Objetos la más popular.

Con el paradigma de Programación Orientado a Objetos lo que

buscamos es dejar de centrarnos en la lógica pura de los
programas, para empezar a pensar en objetos, lo que constituye la
base de este paradigma. Esto nos ayuda muchísimo en sistemas
grandes, ya que en vez de pensar en funciones, pensamos en las
relaciones o interacciones de los diferentes componentes del
sistema.

Un programador diseña un programa de software organizando

piezas de información y comportamientos relacionados en una
plantilla llamada clase. Luego, se crean objetos individuales a partir
de la plantilla de clase. Todo el programa de software se ejecuta
haciendo que varios objetos interactúen entre sí para crear un
programa más grande.
Diagrama de UML:

Qué es UML?

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un

lenguaje de modelado visual común y semántica y sintácticamente
rico para la arquitectura, el diseño y la implementación de sistemas
de software complejos, tanto en estructura como en
comportamiento. UML tiene aplicaciones más allá del desarrollo de
software, p. ej., en el flujo de procesos en la fabricación.

Es comparable a los planos usados en otros campos y consiste en

diferentes tipos de diagramas. En general, los diagramas UML
describen los límites, la estructura y el comportamiento del sistema
y los objetos que contiene.

UML no es un lenguaje de programación, pero existen

herramientas que se pueden usar para generar código en diversos
lenguajes usando los diagramas UML. UML guarda una relación
directa con el análisis y el diseño orientados a objetos.
Ejemplo:
 Modelo de casos de uso:

En el Lenguaje de Modelado Unificado, un diagrama de casos de

uso es una forma de diagrama de comportamiento UML mejorado.
El Lenguaje de Modelado Unificado (UML), define una notación
gráfica para representar casos de uso llamada modelo de casos de
uso. UML no define estándares para que el formato escrito describa
los casos de uso, y así mucha gente no entiende que esta notación
gráfica define la naturaleza de un caso de uso; sin embargo una
notación gráfica puede solo dar una vista general simple de un caso
de uso o un conjunto de casos de uso. Los diagramas de casos de
uso son a menudo confundidos con los casos de uso. Mientras los
dos conceptos están relacionados, los casos de uso son mucho más
detallados que los diagramas de casos de uso. En los conceptos se
debe detallar más de un caso de uso para poder identificar qué es
lo que hace un caso de uso.

Las tres relaciones principales entre los casos de uso son

soportadas por el estándar UML, el cual describe notación gráfica
para esas relaciones. Veamos una revisión de ellas a continuación:

Inclusión (include)

Es una forma de interacción o creación, un caso de uso dado puede

"incluir" otro caso de uso. El primer caso de uso a menudo depende
del resultado del caso de uso incluido. Esto es útil para extraer
comportamientos verdaderamente comunes desde múltiples casos
de uso a una descripción individual(si el actor realiza el caso de uso
base tendrá que realizar también el caso de uso incluido), desde el
caso de uso. El estándar de Lenguaje de Modelado Unificado de
OMG define una notación gráfica para realizar diagramas de casos
de uso, pero no el formato para describir casos de uso. Mucha
gente sufre la equivocación pensando que un caso de uso es una
notación gráfica (o es su descripción). Mientras la notación gráfica y
las descripciones son importantes, ellos forman parte de la
documentación de un caso de uso --un propósito para el que el
actor puede usar el sistema. La notación es de una flecha de punta
abierta con línea discontinua desde el caso de uso que lo incluye
hasta el caso de uso incluido, con la etiqueta "«include»". Este uso
se asemeja a una expansión de una macro, donde el
comportamiento del caso incluido es colocado dentro del
comportamiento del caso de uso base. No hay parámetros o
valores de retorno

Extensión (extend)

Es otra forma de interacción, un caso de uso dado (la extensión)

puede extender a otro. Esta relación indica que el comportamiento
del caso de la extensión se utiliza en casos de uso, un caso de uso a
otro caso siempre debe tener extensión o inclusión. El caso de uso
extensión puede ser insertado en el caso de uso extendido bajo
ciertas condiciones. La notación, es una flecha de punta abierta con
línea discontinua, desde el caso de uso extensión al caso de uso
extendido, con la etiqueta «extend». Esto puede ser útil para lidiar
con casos especiales, o para acomodar nuevos requisitos durante el
mantenimiento del sistema y su extensión.

"La extensión, es el conjunto de objetos a los que se aplica un

concepto. Los objetos de la extensión son los ejemplos o instancias
de los conceptos."

documentan el comportamiento de un sistema desde el punto de

vista de un usuario

En otras palabras será utilizado cuando un caso de uso sea similar a

otro pero con ciertas variaciones, un ejemplo claro es que se
necesite comprar azúcar y podemos seleccionar de entre azúcar
rubia, blanca o su unidad de medida bolsa, kilo, etc.

Generalización

"Entonces la Generalización es la actividad de identificar elementos

en común entre conceptos y definir las relaciones de una
superclase (concepto general) y subclase (concepto especializado).
Es una manera de construir clasificaciones taxonómicas entre
conceptos que entonces se representan en jerarquías de clases. Las
subclases conceptuales son conformes con las superclases
conceptuales en cuanto a la intención y extensión."

En la tercera forma de relaciones entre casos de uso, existe una

relación generalización/especialización. Un caso de uso dado puede
estar en una forma especializada de un caso de uso existente. La
notación es una línea sólida terminada en un triángulo dibujado
desde el caso de uso especializado al caso de uso general. Esto se
asemeja al concepto orientado a objetos de sub-clases, en la
práctica puede ser útil factorizar comportamientos comunes,
restricciones al caso de uso general, describirlos una vez, y
enfrentarse a los detalles excepcionales en los casos de uso
especializados. UML.

DIAGRAMAS Y PAQUETES Y OTROS ARTEFACTOS UML:

Artefacto UML
En el Lenguaje Unificado de Modelado (UML), un artefacto es la
especificación de un componente físico de información que es
usado o producido por un proceso de desarrollo de software, o por
el desarrollo y operación de un sistema.

Ejemplos de artefactos incluyen modelo de archivos, archivos

fuentes, scripts, archivos binarios ejecutables, una tabla en una
base de datos, un development deliverable, o un documento de
procesamiento de texto, como un mensaje de correo electrónico.

En UML 2.0, los artefactos son las entidades físicas que son
desplegadas en Nodos, Dispositivos y Ambientes de Ejecución.
Otros elementos de UML, tales como las clases y los componentes,
son primero manifestados como artefactos, y las instancias de
dichos artefactos son luego desplegados. Los artefactos pueden
también estar compuestos por otros artefactos.

Diagramas: