Densy yuli

11
“A ño de la consolidación delM ar de G rau” Instituto D e Educación Superior Tecnológico Privado Curso Ingenieria De Software I T em a Diagrama De Clases integrantes Densy de la Cruz Lucero Yuliana Arrieta Flores Elvis Acuña Reyes Ciclo V T urno noche Especialidad Computacion e Informatica D ocente marco aurelio porro chulli 2016

Transcript of Densy yuli

Page 1: Densy yuli

“Año de la consolidación del Mar de Grau”

Instituto De Educación Superior Tecnológico Privado

Curso Ingenieria De Software I

Tema Diagrama De Clases

integrantes Densy de la Cruz Lucero

Yuliana Arrieta Flores

Elvis Acuña Reyes

Ciclo V

Turno noche

Especialidad Computacion e Informatica

Docente marco aurelio porro chulli

2016

Page 2: Densy yuli

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.

Page 3: Densy yuli

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.

Page 4: Densy yuli

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.

Page 5: Densy yuli

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

Page 6: Densy yuli

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.

Page 7: Densy yuli

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

Page 8: Densy yuli

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.

Page 9: Densy yuli

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

Page 10: Densy yuli

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).

Page 11: Densy yuli

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