Edición de «Apunte de Modelo Conceptual (Ingeniería I)»
De Cuba-Wiki
Puedes deshacer la edición. Antes de deshacer la edición, comprueba la siguiente comparación para verificar que realmente es lo que quieres hacer, y entonces publica los cambios para así efectuar la reversión.
| Revisión actual | Tu texto | ||
| Línea 1: | Línea 1: | ||
<div style="border: 1px solid #CECEFF; padding: 5px; background-color: #EEEEFF; margin: 0px 0px 15px 0px;">[[Image:Back.png|14px|]] [[Ingeniería de Software I|Volver a la página de la materia]]</div> | |||
El modelo conceptual busca capturar las clases que comprenden nuestro modelo y sus interacciones. No confundir con el diagrama de diseño, en esta instancia las clases son conceptuales y no se corresponden necesariamente con las que se implementarán. | El modelo conceptual busca capturar las clases que comprenden nuestro modelo y sus interacciones. No confundir con el diagrama de diseño, en esta instancia las clases son conceptuales y no se corresponden necesariamente con las que se implementarán. | ||
== Elementos == | == Elementos == | ||
==== Clases ==== | ==== Clases ==== | ||
Los objetos están conformados por Clases, las cuales se componen de un nombre, atributos y responsabilidades. | Los objetos están conformados por Clases, las cuales se componen de un nombre, atributos y responsabilidades. | ||
* El nombre de la clase en el modelo, que no debe confundirse con su rol. | * El nombre de la clase en el modelo, que no debe confundirse con su rol. | ||
* Los atributos se notan de la forma nombre:Dominio, donde el dominio es el conjunto de valores que puedan tomar. Si se busca utilizar OCL, entonces conviene utilizar un Tipo de dato en lugar de un Dominio, ya que OCL solo puede predicar sobre Tipos. | * Los atributos se notan de la forma nombre:Dominio, donde el dominio es el conjunto de valores que puedan tomar. Si se busca utilizar OCL, entonces conviene utilizar un Tipo de dato en lugar de un Dominio, ya que OCL solo puede predicar sobre Tipos. | ||
* Los atributos también pueden corresponder a un tipo enumerado, el cual se nota como una clase aparte con el encabezado <<Enum>>, el nombre del enum, y los distintos valores posibles a tomar. | * Los atributos también pueden corresponder a un tipo enumerado, el cual se nota como una clase aparte con el encabezado <<Enum>>, el nombre del enum, y los distintos valores posibles a tomar. | ||
* Los atributos derivados son atributos que se calculan a partir de los valores de otros. Por ejemplo, TiempoTranscurrido puede ser un atributo derivado de Inicio y Fin. Se marca con una '''/''' delante y se define usando OCL. | * Los atributos derivados son atributos que se calculan a partir de los valores de otros. Por ejemplo, TiempoTranscurrido puede ser un atributo derivado de Inicio y Fin. Se marca con una '''/''' delante y se define usando OCL. | ||
* Las responsabilidades son los métodos de la clase. Si no modifican el estado interno de la instancia, se denominan queries. Se notan como Nombre(Param1:Tipo1,...):Tipo. Tanto el resultado como los parámetros son opcionales. En el caso de las queries, se las marca con una '''/''' adelante. | * Las responsabilidades son los métodos de la clase. Si no modifican el estado interno de la instancia, se denominan queries. Se notan como Nombre(Param1:Tipo1,...):Tipo. Tanto el resultado como los parámetros son opcionales. En el caso de las queries, se las marca con una '''/''' adelante. | ||
| Línea 18: | Línea 24: | ||
* Las asociaciones pueden tener, opcionalmente un nombre. | * Las asociaciones pueden tener, opcionalmente un nombre. | ||
* Cada clase de la asociación tiene un determinado rol respecto de la otra. Dicho rol se dice es un pseudoatributo de la otra clase. | * Cada clase de la asociación tiene un determinado rol respecto de la otra. Dicho rol se dice es un pseudoatributo de la otra clase. | ||
* Cada clase tiene una determinada cardinalidad en la asociación. | * Cada clase tiene una determinada cardinalidad en la asociación. | ||
* Una instancia de una asociación se define como el par de instancias que une. Notar que dos instancias particulares de objetos pueden estar asociadas una única vez; por ejemplo, un producto en una factura, o un hotel en una ciudad. Si no se busca modelar esto, se agrega una clase intermedia. | * Una instancia de una asociación se define como el par de instancias que une. Notar que dos instancias particulares de objetos pueden estar asociadas una única vez; por ejemplo, un producto en una factura, o un hotel en una ciudad. Si no se busca modelar esto, se agrega una clase intermedia. | ||
* Si se quieren agregar atributos a la asociación, se puede definir una clase de asociación que los contenga. Tiene las mismas características que una asociación común, es decir, es única para dos instancias en particular. | * Si se quieren agregar atributos a la asociación, se puede definir una clase de asociación que los contenga. Tiene las mismas características que una asociación común, es decir, es única para dos instancias en particular. | ||
* Además de las asociaciones comunes, pueden definirse composiciones y agregaciones (también llamadas composiciones débiles). La composición indica que un determinado objeto está compuesto por una seria de instancias del otro, y que este último no puede existir sin el primero. Por ejemplo, la relación entre hotel y habitaciones puede definirse como una composición. La cardinalidad del lado del compuesto es siempre 1. Se nota con un rombo lleno (pintado) del lado del compuesto (en el ejemplo, el compuesto es el hotel). | * Además de las asociaciones comunes, pueden definirse composiciones y agregaciones (también llamadas composiciones débiles). La composición indica que un determinado objeto está compuesto por una seria de instancias del otro, y que este último no puede existir sin el primero. Por ejemplo, la relación entre hotel y habitaciones puede definirse como una composición. La cardinalidad del lado del compuesto es siempre 1. Se nota con un rombo lleno (pintado) del lado del compuesto (en el ejemplo, el compuesto es el hotel). | ||
* La agregación es una composición débil. Es un concepto bastante subjetivo, la idea sería la misma que la | |||
* La agregación es una composición débil. Es un concepto bastante subjetivo, la idea sería la misma que la agregación, con la diferencia de que el objeto que compone puede vivir independientemente del compuesto. | |||
== Object Constraint Language == | == Object Constraint Language == | ||
OCL, es un lenguaje para definir restricciones, responsabilidades y atributos derivados en base a un modelo conceptual. | OCL, es un lenguaje para definir restricciones, responsabilidades y atributos derivados en base a un modelo conceptual. | ||
== Checklist == | == Checklist == | ||
Lista de errores comunes a chequear en un problema de modelo conceptual. | Lista de errores comunes a chequear en un problema de modelo conceptual. | ||
| Línea 34: | Línea 50: | ||
* No utilizar clases de asociación cuando la asociación puede darse muchas veces entre los objetos. En el ejemplo de los trenes, un mismo ''tren'' puede realizar muchos ''viajes'' sobre un mismo ''recorrido''. Para estos casos, en lugar de una clase de asociacion, se coloca una clase intermedia que representa cada instancia de asociación. La multiplicidad del lado de la clase intermedia es generalmente 1, ya que cada instancia se corresponde a una única instancia de los objetos que une. | * No utilizar clases de asociación cuando la asociación puede darse muchas veces entre los objetos. En el ejemplo de los trenes, un mismo ''tren'' puede realizar muchos ''viajes'' sobre un mismo ''recorrido''. Para estos casos, en lugar de una clase de asociacion, se coloca una clase intermedia que representa cada instancia de asociación. La multiplicidad del lado de la clase intermedia es generalmente 1, ya que cada instancia se corresponde a una única instancia de los objetos que une. | ||
* Escribir <<CC>> sobre el nombre de cada clase para indicar que se trata de una clase conceptual. | * Escribir <<CC>> sobre el nombre de cada clase para indicar que se trata de una clase conceptual. | ||
* Atención al ubicar los atributos en una determinada clase, puede que pertenezcan a una asociación más que a la clase en sí, depende lo que se desee modelar. Por ejemplo, en la relación Producto - Factura, un atributo de cantidad en Producto puede indicar el stock que queda del mismo, mientras que el mismo atributo en la asociación indica cuántos items del Producto se vendieron en la Factura. | * Atención al ubicar los atributos en una determinada clase, puede que pertenezcan a una asociación más que a la clase en sí, depende lo que se desee modelar. Por ejemplo, en la relación Producto - Factura, un atributo de cantidad en Producto puede indicar el stock que queda del mismo, mientras que el mismo atributo en la asociación indica cuántos items del Producto se vendieron en la Factura. | ||
* No incluir en el diagrama clases que pertenecen a la implementación, y no al modelo conceptual. | * No incluir en el diagrama clases que pertenecen a la implementación, y no al modelo conceptual. | ||
* Recordar que la idea del modelo conceptual es ser explicativo. | * Recordar que la idea del modelo conceptual es ser explicativo. | ||
* Poner "'''/'''" en los atributos y responsabilidades derivadas. | * Poner "'''/'''" en los atributos y responsabilidades derivadas. | ||
[[Category:Apuntes]] | [[Category:Apuntes]] | ||
