1.

Conceptos de Ingeniería del Software (IS) (6Cap1)

 Ingeniería: Conjunto de conocimientos orientados a la invención y utilización de

técnicas para el aprovechamiento de recursos naturales o para la actividad
industrial.
 Tecnología: Conjunto de teorías y técnicas que permiten el aprovechamiento
practico del conocimiento científico.
 Software: Conjunto de instrucciones que cuando se ejecutan proporcionan las
características, función y desempeño buscados, también podrían ser
estructuras de datos que permiten que los programas manipulen en forma
adecuada la información.

1.1 La Ingeniería del Software:

Concepto: Según la IEEE en 1993, es la aplicación de un enfoque sistemático,

disciplinado y cuantificable al desarrollo, operación y mantenimiento del software. Ofrece
métodos o técnicas para desarrollar y mantener software de calidad que resuelven problemas
de todo tipo, y trata áreas muy diversas de la informática y de las ciencias computacionales.
Objetivos:
 Especificar, documentar, visualizar el proyecto antes de escribir una línea de
código.
 Servir de enlace entre quien tiene la idea y quien la lleva a cabo.
 Articular soluciones en base a la comprensión de problemas (Captura de
requerimientos).
 Permitir la exploración de alternativas de solución.
 Mejorar la calidad de los productos de software.
 Aumentar la productividad del proceso.
 Definir una disciplina que garantice la producción y mantenimiento del software
desarrollado.

1.2 Complejidad del Software (5Cap1)

La complejidad del software esta relacionada directamente con el tamaño de los

sistemas de este. Cuando mas grandes los sistemas, mayor es su complejidad. Se pueden
hablar de 2 factores principales que causan esta complejidad:

 Complejidad del problema: Tiene que ver con la funcionalidad que el sistema
debe brindar. Cuando mayor sea el numero de requerimientos, mayor será el
tamaño del sistema, creando sistemas mas difíciles de comprender y
desarrollar.
 Complejidad de la solución: Tiene que ver con el disenho del sistema, el cual
debe satisfacer la funcionalidad del problema. Cuando la complejidad del
problema es grande y difícil de reducir, es muy importante reducir la otra fuente
de complejidad, el de la solución o sea, el software.

1.3 Costos (Directo, Indirecto, Ocultos), Complejidad

Costo Directo: para adquirir el software, el cual incluye el software empacado, se puede
adquirir en un negocio de computación o por internet. Y el software a la medida, requiere un
desarrollo especializado y adaptado a las necesidades particulares de una empresa.
Costo Indirecto: para utilizar el software incluye aspectos como la capacitación, instalación,
soporte técnico, así como otros costos que por lo general se pueden conocer de antemano.

Costo oculto: ocasionado principalmente por las fallas del software. A diferencia de los costos
directos e indirectos, los cuales son previsibles, los costos ocultos por definición son difíciles de
prever. Vale la pena destacar que el tema de costos ocultos afecta principalmente a los
sistemas conocidos como de misión critica (aquellos sistemas críticos para la operación
correcta de una empresa).

1.4 Proceso de Software (5Cap3)

Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan cuando va a

crearse algún producto del trabajo. Una actividad busca lograr un objetivo amplio (por ejemplo,
comunicación con los participantes) y se desarrolla sin importar el dominio de la aplicación,
tamaño del proyecto, complejidad del esfuerzo o grado de rigor con el que se usará la
ingeniería de software.

1.5 Modelo de Proceso, Modelos Clásicos (Cascada, Incremental, Evolutivo, Espiral),

Modelos contemporáneos

Modelo de Proceso: Un modelo de proceso de software define como solucionar la

problemática del desarrollo de sistemas de software. Para desarrollar el software se requiere
resolver ciertas fases de su proceso, las cuales se conocen en su conjunto como el ciclo de
vida del desarrollo de software. Un modelo de procesos debe considerar una variedad de
aspectos. Ej: conjuntos de personas, estructuras organizacionales, reglas, políticas,
actividades, componentes de softwares, metodologías y herramientas utilizadas.

Modelos Clásicos:

Cascada: El modelo de la cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque
sistemático y secuencial para el desarrollo del software, que comienza con la especificación de
los requerimientos por parte del cliente y avanza a través de planeación, modelado,
construcción y despliegue, para concluir con el apoyo del software terminado.

Entre los problemas que en ocasiones surgen al aplicar el modelo de la cascada se encuentran
los siguientes:

Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo. Aunque el
modelo lineal acepta repeticiones, lo hace en forma indirecta. Como resultado, los cambios
generan confusión conforme el equipo del proyecto avanza.

A menudo, es difícil para el cliente enunciar en forma explícita todos los requerimientos. El
modelo de la cascada necesita que se haga y tiene dificultades para aceptar la incertidumbre
natural que existe al principio de muchos proyectos.
El cliente debe tener paciencia. No se dispondrá de una versión funcional del (de los)
programa(s) hasta que el proyecto esté muy avanzado. Un error grande sería desastroso si se
detectara hasta revisar el programa en funcionamiento.

Incremental: Cuando se utiliza un modelo incremental, es frecuente que el primer incremento

sea el producto fundamental. Es decir, se abordan los requerimientos básicos, pero no se
proporcionan muchas características suplementarias (algunas conocidas y otras no). El modelo
incremental aplica secuencias lineales en forma escalonada a medida que avanza el calendario
de actividades. Cada secuencia lineal produce “incrementos” de software susceptibles de
entregarse de manera parecida a los incrementos producidos en un flujo de proceso evolutivo.
Ej: un software para procesar textos que se elabore con el paradigma incremental quizá
entregue en el primer incremento las funciones básicas de administración de archivos, edición y
producción del documento; en el segundo dará herramientas más sofisticadas de edición y
producción de documentos; en el tercero habrá separación de palabras y revisión de la
ortografía; y en el cuarto se proporcionará la capacidad para dar formato avanzado a las
páginas.

Evolutivo: Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que
permiten desarrollar versiones cada vez más completas del software. Para ello se suele hacer
prototipos. El paradigma de hacer prototipos comienza con comunicación. Usted se reúne con
otros participantes para definir los objetivos generales del software, identifica cualesquiera
requerimientos que conozca y detecta las áreas en las que es imprescindible una mayor
definición.

El ideal es que el prototipo sirva como mecanismo para identificar los requerimientos del
software. Si va a construirse un prototipo, pueden utilizarse fragmentos de programas
existentes o aplicar herramientas (por ejemplo, generadores de reportes y administradores de
ventanas) que permitan generar rápidamente programas que funcionen.

Espiral: El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por

el riesgo, que se usa para guiar la ingeniería concurrente con participantes múltiples de
sistemas intensivos en software. Tiene dos características distintivas principales. La primera es
el enfoque cíclico para el crecimiento incremental del grado de definición de un sistema y su
implementación, mientras que disminuye su grado de riesgo. La otra es un conjunto de puntos
de referencia de anclaje puntual para asegurar el compromiso del participante con soluciones
factibles y mutuamente satisfactorias.

Modelos Contemporáneos: El modelo de desarrollo concurrente, en ocasiones llamado

ingeniería concurrente, permite que un equipo de software represente elementos iterativos y
concurrentes de cualquiera de los modelos de proceso descritos en este capítulo. Ej: la
actividad de modelado definida para el modelo espiral se logra por medio de invocar una o más
de las siguientes acciones de software: hacer prototipos, análisis y diseño.
El modelado concurrente es aplicable a todos los tipos de desarrollo de software y proporciona
un panorama apropiado del estado actual del proyecto. En lugar de confinar las actividades,
acciones y tareas de la ingeniería de software a una secuencia de eventos, define una red del
proceso.

1.6 Por qué modelar? (2Cap1) (4Cap2)

Un modelo se expresa en un medio adecuado para el trabajo. Ej: Los modelos de construcción
pueden dibujarse en papel, las figuras 3D son construidas con cartón y papel cartón, o las
ecuaciones de elementos finitos en un computador. Un modelo de construcción de un edificio
muestra la apariencia del edificio, pero también puede usarse para hacer ingeniería y cálculo
de coste.

- Objetivos del Análisis de Sistemas

Identificar las necesidades o requerimientos del cliente

Evaluar la vialidad del sistema

Realizar análisis técnico

Realizar análisis económico

Asignar funciones:

Al software

Al hardware

A las personas

A la base de datos (Software)

A otros elementos del sistema

Establecer restricciones (costo y tiempo)

Crear una definición del sistema que sea la base para yodo el trabajo posterior de ingeniería

- Niveles de complejidad de los proyectos

- Qué es un modelo?. Importancia de Modelar

Un modelo es una representación de algo en el mismo u otro medio. El modelo capta los
aspectos importantes de lo que estamos modelando, desde cierto punto de vista y simplifica u
omite el resto. Un modelo de un sistema software está construido en un lenguaje de modelado,
como UML. La importancia de modelar es el modelo pretende ser más fácil de usar para ciertos
propósitos que el sistema final.
- Para qué sirven los modelos?

Para capturar, enumerar los requisitos y el dominio del problema

Para pensar en el diseño de un sistema

Para capturar decisiones del diseño a partir de los requisitos

Para generar Productos aprovechables para el trabajo

Para organizar, encontrar, filtrar, examinar y corregir información

Para explorar económicamente múltiples soluciones

Para comprender sistemas complejos

- Principios del Modelado

La elección de que modelos crear tiene una profunda influencia sobre cómo se plantea un
problema y la solución

Todo modelo puede ser expresado a diferentes niveles de precisión

Los modelos están ligados a la realidad

Un único modelo no es suficiente. Cualquier sistema no trivial se aborda a través de un

pequeño conjunto de modelos casi interdependientes

- Niveles del Modelado

Guías al proceso de pensamiento: Los modelos de alto nivel construidos al principio de un

proyecto, sirven para enfocar el proceso del pensamiento de los participantes y destacar
determinadas opciones. Capturan requisitos y representan un punto de partida hacia un diseño
del sistema.

Especificaciones abstractas de la estructura esencial de un sistema: El propósito de los

modelos abstractos es conseguir que los aspectos de alto nivel estén correctos, antes de
abordar los de los detalles más localizados. Estos modelos se piensan para evolucionar en los
modelos finales mediante un proceso cuidadoso que garantice que el sistema final implementa
correctamente el objetivo de los modelos anteriores.

Especificaciones completas de un sistema final: Un modelo de implementación incluye

suficiente información para construir el sistema. Debe incluir la semántica lógica del sistema y
los algoritmos, la estructura de datos y los mecanismos que aseguran funcionamiento
apropiado.
Ejemplos de sistema típicos o posibles: Los ejemplos de las estructuras de datos típicas,
pueden ayudar a las personas a intentar entender una situación complicada. Se deben utilizar
con un cierto cuidado.

Descripciones completas o parciales de sistemas: Un modelo puede ser una descripción

completa de un solo sistema. Se organiza como un conjunto de unidades distintas, discretas de
las cuales se puede almacenar y manipular por separado, como parte de la descripción
completa.

2. Revisión de Conceptos Básicos de Orientación a Objetos (1Cap19) (4CapEnciclopedia)

(5Cap2)

La POO define una estructura de más alto nivel llamada "objeto" que ofrece dos ventajas sobre
la programación tradicional:

 Permitir al programador que organice su programa de acuerdo con abstracciones de

más alto nivel, siendo más cercanas a los pensamientos de la gente. Es decir, los
objetos son las unidades de representación de las aplicaciones. Ej: Cuentas de banco,
reserva de vuelos, etc.

 Los datos globales desaparecen junto con las funciones (interna) de los objetos. Por lo
tanto, cualquier cambio en la estructura de los datos solo debería de afectar a las
funciones definida en ese mimo objeto y no en los demás.

2.1 Abstracción, Herencia, Polimorfismo, Encapsulamiento

Polimorfismo: Se definen múltiples funciones con nombres e interfaces similares en distintas

clases. Las funciones son implementadas de manera diferente en las clases. El polimorfismo es
útil para extender la funcionalidad del sistema al definir nuevas clases aun desconocida al
momento de especificarlo.

Encapsulación: Es el mecanismo básico de la POO para ocultar los detalles internos del
objeto de los demás objetos. Permite distinguir entre la interface del objeto, es decir, los
aspectos del objeto conocido externamente, y su implementación, es decir, sus aspectos
conocidos internamente.

Abstracción: Consiste en elevar el nivel de las representaciones necesarias para un sistema

de software, de manera que se reduzcan en términos de datos y funciones. En la POO,
representa un sistema mediante objetos, omitiendo los detalles correspondientes a datos y
funciones.
Herencia: es un concepto de la POO. El cual es un mecanismo que permite derivar una clase a
otra clase. En otras palabras, tendremos unas clases que serán hijos, y otras clases que serán
padres.

Las clases hijas pueden utilizar tanto sus métodos y propiedades como de la clase padre,
siempre que su modificador de acceso lo permita.

2.2 Clases y Objetos, Atributos, Mensajes, (Operaciones, Métodos, Servicios)

 Clases: Describe un grupo de objetos con estructura y comportamiento común. Una

clase es como un molde en el cual se crean múltiples objetos. Ej: Universidad,
Persona, Compañía, etc.

 Objetos: Son las entidades básicas del modelo de objeto. Los objetos son más que
simples cosas que se pueden arrojar. Son sustantivos, es decir, cualquier cosa que
incorpore una estructura y un comportamiento o acción. Ej: Pelota, Libro, Elefante,
Mesa (concreto), viaje (abstracto).

 Atributos: Define la estructura de una clase y de sus correspondientes objetos. El

atributo define el valor de un dato para todos los objetos perteneciente a una clase.
Deben ser únicos. Ej: Nombre, edad, peso - clase Persona.

 Mensajes: Son llamados a métodos de un objeto en particular, Por convenio, el objeto

que envía la petición se denomina emisor y el objeto que recibe la petición se
denomina receptor. Como todo objeto necesita de unos atributos, es por eso que el
envío de estos soporta todas las interacciones que se realicen en dicho objeto. Para
poder enviar y recibir mensajes, los objetos no forman parte del mismo proceso, ni de
una máquina. Ej: Jugar(), Programar(), Llevar().

 Operaciones: Son funciones o transformaciones que se aplican a todos los objetos de

una clase particular. Puede ser una acción ejecutada por el objeto o sobre objeto.
Deben ser únicas dentro una misma clase. No se debe utilizar el mismo nombre que
tengan un significado totalmente diferente. Ej: Arrojar, atrapar, inflar, patear - clase
pelota. Abrir, cerrar, ocultar - clase ventana.

 Métodos: Se utiliza para distinguir la operación como un concepto de alto nivel de la

propia implementación de la operación, algo correspondiente a un concepto de más
bajo nivel. Ej: Imprimir - clase Archivo. Se puede implementar con diferentes métodos.
Imprimir - clase Dispositivo, el cual manda el archivo a la impresora.
3. El Lenguaje Unificado de Modelado (UML)

Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y

documentar artefactos de un sistema de software. Captura decisiones y conocimiento sobre los
sistemas que se deben construir. Se usa para entender, diseñar, hojear, configurar, mantener y
controlar la información sobre tales sistemas. El UML capta información sobre la estructura
estática y el comportamiento dinámico de un sistema.

Ejemplos de utilización: Sistemas de información de todo tipo, Aplicaciones WEB, Sistemas de

Tiempo Real, Relacionados con Medicina - Electrónica - etc., Procesos de Negocios.

3.1 Una Herramienta para Visualizar, Especificar, Construir y Documentar.

VISUALIZAR

No siempre es fácil explicar ciertos aspectos de un sistema en forma escrita. Antes de

construir debemos tener un bosquejo de lo que vamos a hacer.

UML permite modelar proyectos con un lenguaje Estándar. UML permite comunicarse
con otros actores sobre temas relativos a un proyecto.

ESPECIFICAR

Permite construir modelos precisos, que no sean ambiguos, pero si completos,

mostrando el proyecto desde diferentes ópticas.

UML cubre todas las decisiones de análisis, diseño e implementación para desarrollar,
implementar o desplegar sistemas.

CONSTRUIR

NO es lenguaje de programación. Sus modelos pueden relacionarse o corresponderse

con códigos de programas.

Existen muchas herramientas y lenguajes que lo soportan.

Esta correspondencia permite "Ingeniería de Ida y Vuelta":

- Ingeniería Directa, Generar código a partir del UML

- Ingeniería Inversa, Generar modelos de UML a partir de una implementación.

 DOCUMENTAR

Una organización de Sistemas(TI) produce muchos artefactos.

UML cubre la documentación de:

- Arquitectura del Sistema con todos sus detalles

- Requisitos y Pruebas

- Planificación del Proyecto

- Gestión de Versiones

3.2 Situación de Partida, Historia, Inconvenientes, Perspectivas (2Cap2)

Los métodos de desarrollo para los lenguajes de programación tradicionales, como Cobol y
Fortran, emergieron en los años 70 y se volvieron ampliamente difundidos en los 80. Entre ellos
se encontraba el diseño el Análisis estructurado y el diseño estructurado (Yourdon-79) y sus
variantes como Diseño estructurado de tiempo real (Ward-85).

Estos métodos fueron desarrollados por: Constantine, DeMarco, Mellor, Ward, Yourdon, etc.

Estos métodos alcanzaron cierta penetración en el área de los grandes sistemas, como
proyectos contratados por el gobierno para los campos aeroespacial y de defensa. En los
cuales se necesitaba de realizar un proceso de desarrollo organizado y que contenga una
amplia documentación del diseño e implementación del sistema. Los resultados no siempre
eran buenos pero los métodos incluían buenas ideas que fueron usadas eficientemente en
algunos casos para la construcción de grandes sistemas.

El primer lenguaje que es reconocido como orientado a objetos es Simula 67 (desarrollado en

1967). Este lenguaje no tuvo un significativo seguimiento, pero influyó en los lenguajes
orientados a objetos que se fueron desarrollando posteriormente.

Primeros métodos de desarrollo orientado a objetos:

- Shlaer/Mellor -> [Shlaer-88]

- Coad/Yourdon -> [Coad-91]

- "Libros" de Booch -> [Booch-91]

Primeros libros de diseño de lenguajes de programación:

- Goldberg/Robson -> [Golderg-83]

- Cox -> [Cox-86]

- Meyer -> [Meyer-88]

La combinación de estos, iniciaron el campo de la metodología orientado a objetos. La primera

fase se completó al final de 1990. El libro de Objectory [Jacobson-92] fue publicado ligeramente
después, basado en publicaciones anteriores. Este libro tomo un acercamiento un poco
diferente con su enfoque sobre los casos de uso y el proceso de desarrollo.

Durante los siguientes 5 años, fueron lanzados más libros de metodologías orientada a objetos,
donde se añadían nuevos conceptos útiles, pero por lo general había gran similitud entre los
conceptos propuestos por los diferentes actores. Surgió un núcleo de conceptos comunes,
junto con una gran variedad de conceptos aceptados por uno o dos autores, pero no utilizados
ampliamente, esto creaba discrepancias entre los métodos que hacían que la comparación
detallada sea algo capciosa.

ESFUERZO DE UNIFICACION

Un ejemplo destacable de unificación de los conceptos entre métodos fue Fusion por Coleman
y sus colegas [Coleman-94] el cual incluyó conceptos de OMT, Booch y CRC.

El primer intento exitoso de combinar y reemplazar los métodos existentes llegó con la union de
Rumbaugh y Booch en Rational Software Corporation en 1994. Luego se une

Jacobson y juntos forman un trabajo llamado Lenguaje Unificado de Modelado (UML). Esta
unión de los 3 autores más grandes de estas metodologías, incentivo a los demás
metodólogos.

En 1996, el Object Management Group (OMG) publico una petición de propuestas para un
enfoque estándar sobre el modelado orientado a objetos a los autores del UML (Brooch,
Jacobson y Rumbaugh). Todas las propuestas se unieron a la propuesta final de UML que fue
sometida gracias a la consideración del OMG en septiembre de 1997. El producto final fue una
colaboración entre varias personas.

ESTANDARIZACION

UML fue adoptado unánimemente por los miembros de OMG como estándar en noviembre de
1997. Muchos proveedores de herramientas anunciaron apoyos o planes para ofrecer UML y
muchos metodólogos anunciaron que usarían la notación UML en sus trabajos futuros. Creían
la estandarización apoyaría tanto la expansión del uso del modelado orientado a objetos entre
los desarrolladores como la aparición de un robusto mercado de herramientas de formación y
utilización, haciendo que los usuarios ni los proveedores tengan que pensar en que
metodologías usar y mantener.

3.3 El modelo conceptual del UML (2Cap2)

3.4 Bloques Básicos de Construcción, Reglas, Mecanismos Comunes (2Cap2)

MODELO CONCEPTUAL DEL UML

Los bloques básicos de Construcción son: Elementos, Relaciones, Diagramas. También se

encuentran las Reglas y Mecanismos Comunes.

Los Elementos y las Relaciones colaboran con los Diagramas. Mientras que las Reglas y
Mecanismos Comunes afectan a dichos Diagramas.

- Elementos: Son abstracciones de los modelos. Se dividen en: Estructurales,

Comportamiento, Agrupación y Anotación.
  Estructurales

Son partes estáticas del modelo. Representan cosas que pueden ser conceptuales o
materiales.

- Casos de Uso: Produce un resultado observable. Se utiliza para estructurar los

aspectos de comportamiento en un modelo. Es realizado por una colaboración de
Objetos. Describe de una secuencia de acciones que el sistema lleva a cabo.

- Componente: Es una parte física y reemplazable de un sistema. Está conformado por

interfaces y proporciona implementación de la misma. Un componente representa un
empaquetamiento físico de Clases, Interfaces y Colaboraciones.

- Nodo: Elemento físico que existe en tiempo de ejecución. Representa un recurso

computacional que suele disponer de memoria y capacidad de almacenamiento.

 Comportamiento

Constituye la parte dinámica de los modelos UML. Son como los verbos del modelo y
representan el comportamiento en el tiempo y en el espacio.

- Interacción: Comprende un conjunto de mensajes intercambiados entre objetos, para

un contexto definido y para lograr un propósito especifico. Involucra elementos como:
mensajes, secuencia de acciones y objetos.

- Maquina de Estado: Especifica la secuencia de estados por las que pasa un objeto o
una interacción. Puede especificar el comportamiento de una Clase individual o una
Colaboración de Clases. Involucra elementos como: estados, transiciones, eventos y
actividades.

 Agrupación

Es la parte organizativa de los modelos, son como cajas en las que se descomponen los
modelos.

- Paquete: Se usa para organizar elementos en grupos. Agrupa elementos estructurales,

comportamiento y de agrupación. No existe en tiempo de ejecución, es solo conceptual.

 Anotación

Sirve para hacer aclaraciones al modelo y se aplica a cualquier elemento.

- Nota: Es un símbolo dentro del cual se muestran restricciones y comentarios sobre un

elemento o colección de estos.

Relaciones: Permiten ligar a los elementos entre sí. Se dividen en: Dependencia, Asociación,
Generalización, Realización.

 Dependencia
 Es la relación de uso entre dos elementos, uno independiente y otro dependiente. Si
existe un cambio en el elemento independiente, puede afectar a la semántica del
elemento dependiente.

 Asociación

Relación estructural que describe un conjunto de enlaces. Especifica que los objetos de
una clase están relacionados con los elementos de la otra clase.

 Generalización

Los objetos del elemento especializado (hijo) pueden sustituir a los objetos del elemento
general (padre)

 Realización

Relación semántica entre clasificadores. Donde un clasificador especifica un contrato que

otro clasificador garantiza que cumplirá. Se utiliza para implementar una interfaz y para
indicar la colaboración de objetos que realizan a un caso de uso.

- Diagramas: Son las representaciones graficas de una colección de elementos de modelado,

a menudo se dibujan como un grafo con nodos conectados por arcos.

Se dividen en: Casos de Uso, Clases, Objetos, Secuencia, Colaboración, Estados,

Componentes, Despliegue.

- Reglas: El UML tiene reglas que especifican como debe ser un modelo bien formado. Se
dividen en: Nombres, Alcance, Visibilidad, Integridad.

 Nombres

Como llamar a los elementos, relaciones y diagramas, generalmente es una cadena

de texto

 Alcance

El contexto que da un significado especifico a un artefacto

- Mecanismos Comunes: Se dividen en: Especificaciones, Adornos, Divisiones comunes,

Extensibilidad, Estereotipos.

 Especificaciones

Proporcionan la explicación textual de la sintaxis y semántica de un bloque básico de

construcción. Se usa para enunciar los detalles del sistema. La notación grafica se usa
para visualizar.

 Adornos
 Todos los elementos del UML comienzan con un símbolo básico. Ej: Publico (+) ;
Privado (-) ; Protegido (#)

 Divisiones Comunes

Se crean divisiones para una mejor visualización del problema observado. Ejemplos:
Clase - Objetos

 Extensibilidad

UML es abierto, es posible extender el lenguaje de manera controlada, bajo reglas

claras. Mecanismos: Estereotipos, Valores etiquetados, Restricciones.

 Estereotipos

Extiende el vocabulario del UML. Permite crear nuevos tipos de bloques de construcción
que deriven de los existentes, pero que sean bienes específicos a un problema.

Valores Etiquetados

Permite agregar nueva información a la especificación de un elemento.

Restricciones

Permite agregar nuevas reglas para los bloques de construcción

3.5 Una visión Global de los Diagramas UML