Son los diagramas más comunes en el modelado de sistemas orientados a objetos.

1. “Añ o de la con solidación del Mar de Gr au ”
Instituto De Educación Superior
Tecnológico Privado
Curso Ingenieria De Software I
Tema Diagrama De Clases
integrantes Densy de la Cruz Lucero
Ciclo V
Turno noche
Especialidad Computacion e Informatica
Docente marco aurelio porro chulli
2016

2. DEFINICION
Son los diagramas más comunes en el modelado de sistemas orientados a
objetos.
Un diagrama de clase muestra un conjunto de clases, interfaces, y colaboraciones
y sus relaciones entre ellos.
Los diagramas de clase se usan en el diseño del modelo estático para ver un
sistema. Para las demás partes, este modelado involucra el vocabulario del
sistema, el modelado de colaboraciones, o modelado de esquemas. Los
diagramas de clase son también la base para un par de diagramas relacionados:
Diagramas de Componente y Diagramas de Instalación (Deployment).
Los diagramas de clase son importantes no solo para la visualización,
especificación y documentación del modelo estructural, pero también para la
construcción de sistemas ejecutables. Ingeniería hacia adelante e ingeniería
inversa.
La construcción de software tiene muchas características similares, excepto, que
la calidad (Fluidez) de software, uno tiene la habilidad de definir la construcción de
bloques básicos para ir detallando (scratch).
Términos y Conceptos.
Un diagrama de clases muestra un conjunto de clases, interfaces, y
colaboraciones y sus relaciones. Gráficamente un diagrama de clase es una
colección de vértices y arcos.
Propiedades comunes: Un diagramas de clase es justo un tipo especial de
diagrama y comparte propiedades comunes al igual que todos los otros diagramas
-un nombre y un contenido gráfico son una proyección dentro de un modelo.

3. Contenido.
Un diagrama de clases comúnmente con tiene lo siguiente:
 Clases
 Interfaces
 Colaboraciones
 Dependencia
 Generalización
 Relaciones de asociación
Los otros diagramas de clase pueden contener notas y restricciones. Los
diagramas de clase pueden también contener paquetes o subsistemas ambos de
los cuales son usados para agrupar elementos de su modelo. Algunas veces se
quieren instancias de lugar en el diagrama de clases, como también
especialmente cuando se quiere visualizar el tipo de una instancia (posibilidad
dinámica).
Usos comunes:
- Modelado del diseño estático de un sistema. Esta vista en primer lugar soporta
los requerimientos funcionales de un sistema - el servicio del sistema debería de
proveer este a los usuarios finales.
Para el modelo de diseño estático de la vista de un sistema, típicamente se usan
diagramas de clases en alguna de estas tres alternativas:
1. Modelo del vocabulario de un sistema. El modelo del vocabulario de un
sistema involucra tomar decisiones acerca de las cuales son parte del
sistema y cuales quedan fuera del ambiente. Los diagramas de clase
especifican estas abstracciones y sus responsabilidades.
2. Modelado simple de colaboraciones. Una colaboración es una sociedad de
clases, interfaces, y otros elementos, estos trabajan juntos para proveer
igual comportamiento de colaboración, esto es más grande que la suma de
todos los elementos. Por ejemplo, cuando se está modelando la semántica
de una transacción en un sistema distribuido, no se puede fijar la vista en
una simple clase, para entender cuál irá. Esta semántica es llevada fuera
por un conjunto de clases que trabajan juntas. Los diagramas de clases se
usan para visualizar y especificar este conjunto de clases y sus relaciones.
3. Modelo lógico del esquema de la base de datos.

4. Modelado de Colaboraciones Simples.
Las clases no están solas, cada trabajo en colaboración con otros genera
semántica igual de grandiosa que cada una de manera individual. Por lo tanto, en
agregación a la captura del vocabulario del sistema, también es necesario poner la
atención en la visualización, especificación, construcción y documentación de
varios caminos esto junto al vocabulario de trabajo. Se usa el diagrama de clases
para representar tales colaboraciones.
Cuando se crea un diagrama de clases se modela una parte de los elementos y el
conjunto de relaciones de vistas del diseño del sistema. Por esta razón, cada
diagrama de clase debería centrarse en una colaboración en un tiempo.
Para Modelar una colaboración.
 Identificar el mecanismo a modelar. Un mecanismo representa igual
funciones o comportamiento de las partes del sistema, son modelados esto
como resultado de la interacción de una sociedad de clases, interfaces, y
otros elementos.
 Para cada mecanismo identifica las clases, interfaces y otras
colaboraciones que participan en esta colaboración. Identifica las relaciones
entre esos objetos también.
 Escenarios de uso para dirigirse a esos elementos. A lo largo del camino se
descubren partes del modelo que fueron omitidas y partes que fueron
planeadas semánticamente erróneas.
 Asegura la propagación de estos elementos con el contenido de ellos. Para
clases empezar trayendo un buen balance de responsabilidades. Entonces,
sobre el tiempo, vuelve esto entre atributos concretos y operaciones.
Modelado lógico del esquema de la base de datos.
Muchos de los sistemas a modelar tienen objetos persistentes, con lo cual por
medio de ellos pueden ser almacenados en una base de datos para recuperarse
más tarde. Muy frecuentemente se usa una base de datos Relacional, una base
de datos orientada a objetos, o un híbrido BD relacional/objetos para almacenar lo
persistente. El UML soporta también el modelo lógico del esquema de la base de
dato, como también la base de datos física.
En UML los diagramas de clase son un super conjunto de los diagramas E-R
(Entidad-Relación), comúnmente las herramientas de modelado para el diseño
lógico de la base de datos.

5. Para modelar un esquema.
 Identificar las clases en el modelo cuyos estados sean los más
trascendentes en el tiempo de vida de sus aplicaciones.
 Crear un diagrama de clases y marcar aquellas que sean persistentes.
 Expandir los detalles estructurales de esas clases, en general, estas
especificaciones de detalles de sus atributos y centrarse en las
asociaciones y en sus cardinalidades eso estructura esas clases.
 Observar para el modelo común ese complicado diseño físico de la base de
datos, tal como asociaciones cíclicas, asociaciones uno-a-uno, uno-a-
muchos y asociaciones muchos-a-muchos. Donde necesariamente se crea
una abstracción intermedia para simplificar la estructura lógica.
 Considerar también el comportamiento de esas clases para expandir
operaciones, esto es importante para el acceso a datos y la integridad de
los datos. En general, se provee la mejor separación concerniente, reglas
de negocios concernientes con la manipulación de conjuntos de objetos que
deberían ser encapsulados en una capa acerca de esas clases
persistentes.
 Donde posiblemente, el uso de herramientas ayudan a transformar el
diseño lógico a diseño físico.
Ingeniería hacia adelante e ingeniería inversa.
El modelado es importante, pero hay que recordar que el principal producto del
desarrollo en equipo es el software, no los diagramas. Las razones de crear
modelos es predecir el tiempo de liberación del software que satisfaga las metas
de los usuarios y del negocio. Por esta razón, es importante que ese modelo que
se crea y la implementación tengan un mapeo de uno a otro y también un camino
este minimizado o uniforme eliminado los costos de manejar el modelo y la
implementación en sincronía con otro diferente.
Para usos similares de UML, los modelos que se crean nunca deberían mapearse
al código. Por ejemplo, si tu estas modelando el proceso de un negocio usando
diagramas de actividad, muchas de las actividades del modelo involucran gente,
no computadoras. En otros casos, se quiere modelar sistemas cuyas partes son,
del nivel de abstracción, justo una pieza de hardware.(en otro nivel de abstracción,
es bueno que el hardware contenga empotrado el cálculo y el software).
En más casos, la creación de modelos puede mapear al código. En UML no se
especifica un mapeo particular a algún lenguaje de programación orientada a
objetos, pero UML fue diseñado con tal mapeo en mente. Este es especialmente
cierto para los diagramas de clase, con lo cual el contenido tiene un mapeo claro
con todas las industrias fuertes de lenguajes orientados a objetos, tales como
Java, C++, Smalltalk, Eiffel, Ada, Object-Pascal, y Forte. El UML fue diseñado

6. Ingeniería hacia adelante.
Es el proceso de transformar un modelo en código a un mapeo en un lenguaje de
implementación. La ingeniería hacia adelante resulta en una pérdida de
información, porque el modelo escrito UML es semánticamente más rico que
cualquier lenguaje de programación orientado a objetos. De hecho esta es una
mayor razón por lo que es necesario modelar en adición al código.
Características estructurales tales como colaboraciones, y características de
comportamiento tales como interacciones pueden ser visualizadas claramente en
UML, pero no son tan claras para una línea de código.
Un Diagrama de clases para la ingeniería hacia adelante:
 Identificar las reglas para el mapeo al lenguaje de implementación o
lenguaje de preferencia. Esto es algo que se quiere hacer para un proyecto
o para la organización como un todo.
 Dependiendo de la semántica del lenguaje elegido, se tienen muchas
restricciones para usar las características del UML. Por ejemplo, el UML
permite al modelo herencia múltiple pero Smalltalk permite solo herencia
simple. Se puede prohibir a los desarrolladores para el modelado usar la
herencia múltiple (con esto se hace al modelo dependiente del lenguaje) o
desarrollar un lenguaje que transforma estas ricas características en un
lenguaje de implementación (con lo cual se hace un mapeo más complejo).
 Usar valores de marca para especificar ligas con el lenguaje. Esto se puede
hacer en el lenguaje individual de clases si se necesita un control preciso.
Se puede hacer en un nivel alto tal como con colaboraciones o paquetes.
 Usar herramientas para la ingeniería hacia adelante para los modelos.
Ingeniería inversa.
Es el proceso de transformar código en un modelo a un mapeo de la
especificación del lenguaje de implementación. La ingeniería inversa es resultado
de la abundancia de información, algo de lo cual está en un nivel bajo de detalle
que se necesita para construir modelos útiles. En algún momento la ingeniería
inversa es incompleta. Esto trae pérdida de información de los modelos de la
ingeniería hacia adelante al código, y también cuando no se puede recrear
completamente un modelo de código a menos que las herramientas dosifiquen
información en la fuente de comentarios semánticamente más allá del lenguaje de
implementación.

7. Un Diagrama de clases para la ingeniería inversa:
 Identifica las reglas de mapeo del lenguaje de implementación o lenguaje
preferido. Esto es lo que algunas veces quieres para tu proyecto o la
organización como un todo.
Propiedad Predeterminado Descripción
Valor
predeterminado
(vacío) El valor del atributo cuando se crean
instancias del clasificador.
Is Read Only False Si es true, el valor del atributo no se puede
cambiar.
Estático False Si es true, las instancias de este tipo
comparten el mismo valor para este
atributo.
Si es true, el nombre del atributo aparece
subrayado en el diagrama.
Name (un nombre
nuevo)
Debe ser único en el clasificador propietario.
Tipo (ninguno) Un tipo primitivo, como Entero, o un tipo que
se define en el modelo.Si escribe un
nombre para un nuevo tipo en esta
propiedad, se agregará un tipo a la
sección Tipos sin especificar del Explorador
de modelos UML.
Visibilidad Público Los valores permitidos y los caracteres que
aparecen en la firma son los siguientes:
+ Público: es visible globalmente
- Privado: no es visible fuera del tipo
propietario
# Protegido: es visible para los tipos
derivados del propietario
~ Paquete: es visible para otros tipos del
mismo paquete

8. Atributos y operaciones
Un atributo (4) es un valor con nombre
que todas las instancias de un tipo
pueden tener. Cuando se obtiene
acceso a un atributo, no se modifica el
estado de la instancia.
Una operación (5) es un método o
función que las instancias del tipo
pueden realizar. Puede devolver un
valor. Si su propiedadisQuery es true,
no se puede modificar el estado de la
instancia.
Para agregar un atributo u operación a
un tipo, abra el menú contextual del tipo, elija Agregar y, a continuación,
elija Atributo u Operación.
Para ver sus propiedades, abra el menú contextual del atributo u operación, y
elija Propiedades. Las propiedades aparecen en la ventana Propiedades.
Para ver las propiedades de los parámetros de una operación, en la
propiedad Paramentes, elija [...].Aparece un nuevo cuadro de diálogo
Propiedades.
Tipos de atributos y operaciones
Los tipos de atributo u operación y los tipos de parámetro pueden ser uno de los
que se detallan a continuación:
(ninguno): un tipo puede dejarse sin especificar en la firma omitiendo el signo de
dos puntos anterior (:).
Uno de los tipos primitivos estándar: Booleano, Entero, Cadena.
Un tipo que esté definido en el modelo.
Un valor parame trizado de un tipo de plantilla, con el formato
Plantilla<Parámetro>.Vea Tipos de plantilla.
También puede escribir el nombre de un tipo que aún no haya definido en el
modelo. El nombre aparecerá en Tipos sin especificar en el Explorador de
modelos UML.

9. Propiedades
En la tabla siguiente se describen las propiedades de un atributo en una clase o
interfaz en un diagrama de clases UML.
Para ver las propiedades de un atributo, haga clic con el botón derecho en el
atributo en la clase o interfaz del diagrama y después haga clic
en Propiedades.Las propiedades aparecen en la ventana Propiedades.
Para ver las propiedades de un atributo, haga clic en él con el botón derecho y
luego haga clic en Propiedades.
Opciones de visualización personalizadas
Si su proyecto generará código fuente en lenguajes de programación .NET (C# o
Visual Basic), sus clases pueden contener propiedades .NET a las que se pueden
llamar desde fuera, mediante atributos, pero que se implementan de manera
interna como métodos.
Para organizar mejor las clases .NET, UModel ofrece la opción de mostrar las
propiedades y métodos .NET en compartimientos separados dentro de la clase.
Esta vista es una opción de configuración opcional y se puede seleccionar en la
ventana "Estilos". Independientemente de si decide mostrar las propiedades .NET
en compartimientos separados o usa un solo compartimiento, el código generado
a partir de la clase será el mismo.
Tipos de datos
Los tipos de datos son elementos de un programa en java que representan un
conjunto de valores que se le pueden asignar a una variable en ejemplo el tipo de
dato “char” representa la basta secuencia de caracteres UNICODE. Dentro de esta
práctica desarrollaremos un programa que utilice todos los tipos de datos que
utilice el lenguaje java. Para esta práctica hacemos uso del entorno de desarrollo
de BlueJ ya que es el entorno con el que hemos estado trabajando dentro del
laboratorio. Lo primero que hacemos en esta práctica haremos uso de los tipos de
datos básicos los cuales son:
CHAR – BYTE – SHORT – INT – LONG – FLOAT - DOUBLE - BOOLEAN
Estos tipos de datos como ya se mencionó en la introducción se denominan como
valores que puede tener un variable.
Estos tipos de datos se dividen en 4:*Enteros (Byte, Short, Int, Long)
*Caracteres (char,string)
*Números de coma flotante. (Float, Double)
*Lógicos (boolean)
Operadores

10. Resumen
Son los diagramas más comunes en el modelado de sistemas orientados
a objetos.
Un diagrama de clase muestra un conjunto de clases, interfaces, y
colaboraciones y sus relaciones entre ellos.
Los diagramas de clase se usan en el diseño del modelo estático para
ver un sistema. Para las demás partes, este modelado involucra el
vocabulario del sistema, el modelado de colaboraciones, o modelado de
esquemas. Los diagramas de clase son también la base para un par de
diagramas relacionados: Diagramas de Componente y Diagramas de
Instalación (Deployment).
Los diagramas de clase son importantes no solo para la visualización,
especificación y documentación del modelo estructural, pero también
para la construcción de sistemas ejecutables. Ingeniería hacia adelante e
ingeniería inversa.
La construcción de software tiene muchas características similares,
excepto, que la calidad (Fluidez) de software, uno tiene la habilidad de
definir la construcción de bloques básicos para ir detallando (scratch).

11. Summary
Are the most common diagrams in modeling object-oriented systems.
A class diagram shows a set of classes, interfaces, and collaborations
and their relationships with each other.
Class diagrams are used in designing the static model for a system. For
the other parties, this involves modeling the vocabulary of the system,
modeling collaborations, or modeling schemes. Class diagrams are also
the basis for a couple of related diagrams: component diagrams and
diagrams Installation (Deployment).
Class diagrams are important not only for visualization, specification and
documentation of the structural model, but also to construct executable
systems. Forward engineering and reverse engineering.
Building software has many similar features, except that the quality
(smoothness) software, you have the ability to define the basic building
blocks to go detailing (scratch).
Conclusión
Como ingenieros de software el diagrama de clase permite ampliar las
oportunidades, para que las personas involucradas en el proyecto
aprendan de una mejor manera de aplicación
Linkografía
http://www.mcc.unam.mx/~cursos/Objetos/Cap8/cap8.html
http://elnazgul666.blogspot.pe/2012/10/tipo-de-datos-y-operadores.html
http://egdamar877.blogspot.pe/2009/05/expocicion.html