• Diagrama de componentes 
• Diagrama de objetos
• Diagrama de despliegue
• Diagrama de paquetes
• Diagrama de casos de uso 
Si se observa alrededor en una habitación, existen un conjunto de objetos físicos que pueden ser fácilmente identificados, clasificados y definidos (en términos de atributos y operaciones). Pero cuando se “observa” el espacio de un problema en una aplicación de software, los objetos pueden ser más difíciles de identificar. Se puede empezar a identificar objetos examinando el planteamiento del problema o realizando un “análisis sintáctico gramatical” en la narrativa del sistema que se va a construir. Los objetos se determinan subrayando cada nombre o cláusula nominal e introduciéndola en una tabla simple. Los sinónimos deben destacarse. Si se requiere del objeto que implemente una solución, entonces éste formará parte del espacio de solución; en caso de que el objeto se necesite solamente para describir una solución, éste forma parte del espacio del problema. Los objetos se manifiestan de alguna de las formas siguientes: • Entidades Externas que producen o consumen información a usar por un sistema computacional. Por ejemplo: otros sistemas, dispositivos, personas. • Cosas que son parte del dominio de información del problema. Por ejemplo: informes, presentaciones, cartas, señales. • Ocurrencias o Sucesos que ocurren dentro del contexto de una operación del sistema. Por ejemplo: una transferencia de propiedad o la terminación de una serie de movimientos en un robot. • Papeles o Roles desempeñados por personas que interactúan con el sistema. Por ejemplo: director, ingeniero, vendedor. • Unidades Organizacionales que son relevantes en una aplicación. Por ejemplo: división, grupo, equipo. • Lugares que establecen el contexto del problema y la función general del sistema. Por ejemplo: planta de producción o muelle de carga. • Estructuras que definen una clase de objetos o, en casos extremos, clases relacionadas de objetos. Por ejemplo: sensores, vehículos de cuatro ruedas o computadoras. La clasificación mostrada es una de las muchas que se han propuesto en la literatura. También es importante destacar qué no son los objetos. En general, un objeto nunca debe tener un “nombre procedimental imperativo”. Coud y Yourdon sugieren seis características de selección a usar cada vez que un analista considera si incluye o no un objeto potencial en el modelo de análisis: o Información retenida el objeto potencial será de utilidad durante el análisis solamente si la información acerca de él debe recordarse para que el sistema funciones. o Servicios necesarios el objeto potencial debe poseer un conjunto de operaciones identificables que pueden cambiar de alguna manera el valor de sus atributos. o Atributos múltiples durante el análisis de requisitos, se debe centrar la atención en la información principal (un objeto con un solo atributo puede, en efecto, ser útil durante el diseño, pero seguramente será mejor presentado como un atributo de otro objeto durante la actividad de análisis). o Atributos comunes puede definirse un conjunto de atributos para el objeto potencial, los cuales son aplicables a todas las ocurrencias del objeto. o Operaciones comunes puede definirse un conjunto de operaciones para el objeto potencial, las cuales son aplicables a todas las ocurrencias del objeto. o Requisitos esenciales entidades externas que aparecen en el espacio del problema y producen o consumen información esencial para la producción de cualquier solución para el sistema, serán casi siempre definidas como objetos en el modelo de requisitos. Para ser considerado un objeto válido a incluir en el modelo de requisitos, un objeto potencial debe satisfacer todas (o casi todas) las características anteriores. La decisión de incluir objetos potenciales en el modelo de análisis es algo subjetivo, y una evaluación posterior puede llegar a descartar un objeto o reincluirlo. Sin embargo, el primer paso del Análisis Orientado a Objetos debe ser la definición de objetos, y la consiguiente toma de decisiones (incluso subjetivas).
Enfocado a nuestro problema
Los objetos que nosotros detectamos están clasificado dentro de las siguientes clases:
Mediante el UML es posible indicar el tipo de dato que almacenara cada atributo.
Los atributos de los objetos que detectamos en nuestra problemática son:
El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones.
Cada clase se representa en un rectángulo con tres compartimientos:
Los atributos de una clase no deberían ser manipulables directamente por el resto de objetos. Por esta razón se crearon niveles de visibilidad para los elementos que son:
(-) Privado : es el más fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminología C++) .
(#) Los atributos/operaciones protegidos están visibles para las clases friends y para las clases derivadas de la original.
(+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación).
Relaciones entre clases:
Los enlaces entre objetos pueden representarse entre las respectivas clases y sus formas de relación son:
Asociación y Agregación (vista como un caso particular de asociación)
Generalización/Especialización.
Las relaciones de Agregación y Generalización forman jerarquías de clases.
Asociación:
La asociación expresa una conexión bidireccional entre objetos. Una asociación es una abstracción de la relación existente en los enlaces entre los objetos. Puede determinarse por la especificación de multiplicidad (mínima...máxima)
Agregación:
La agregación representa una relación parte_de entre objetos. En UML se proporciona una escasa caracterización de la agregación. Esta relación puede ser caracterizada con precisión determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes.
Una agregación se podría caracterizar según:Puede el objeto parte comunicarse directamente con objetos externos al objeto agregado? No => inclusiva Si => no inclusiva Puede cambiar La composición del objeto agregado? Si => dinámica No => estática
Diagrama de Clases y Diagramas de Objetos pertenecen a dos vistas complementarias del modelo. Un Diagrama de Clases muestra la abstracción de una parte del dominio. Un Diagrama de Objetos representa una situación concreta del dominio. Las clases abstractas no son instanciadas.
Generalización:
Permite gestionar la complejidad mediante un ordenamiento taxonómico de clases, se obtiene usando los mecanismos de abstracción de Generalización y/o Especialización. La Generalización consiste en factorizar las propiedades comunes de un conjunto de clases en una clase más general. Los nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivada. Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre están disponibles en sus clases hijas. La Generalización y Especialización son equivalentes en cuanto al resultado: la jerarquía y herencia establecidas. Generalización y Especialización no son operaciones reflexivas ni simétricas pero sí transitivas. La especialización es una técnica muy eficaz para la extensión y reutilización.
La noción de clase está próxima a la de conjunto. Dada una clase, podemos ver el conjunto relativo a las instancias que posee o bien relativo a las propiedades de la clase. Generalización y especialización expresan relaciones de inclusión entre conjuntos.
Enfocado a nuestro problema.
Por ejemplo en nuestro caso, tenemos identificadas las clases de Personal, Nota, Productos y Proveedores, pero de la clase Nota se desprenden dos subclases que son Tarjeta de crédito y Efectivo. Por lo que esta están agregadas con el diagrama de clase Nota, mientras que esta última está relacionada con el diagrama de clase Personal y con el diagrama de clase Productos, ambas asociasiones son del tipo uno a muchos. El diagrama de clase Productos está ligado con el de Proveedores, tambien con una asociación uno a muchos.
