Edición de «Apunte de Modelo Conceptual (Ingeniería I)»

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

== Elementos ==
==== Clases ====
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.
* 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 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.

==== Asociaciones ====

Las asociaciones entre clases marcan relaciones entre ellas.

* 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 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.
* 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).
* 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 ==
OCL, es un lenguaje para definir restricciones, responsabilidades y atributos derivados en base a un modelo conceptual.

== Checklist ==
Lista de errores comunes a chequear en un problema de modelo conceptual.

* No confundir el nombre de una clase con su rol. En el ejemplo de los hoteles, la ciudad donde se encuentra es de clase ciudad, pero cumple el rol de sede.
* 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 <<Enum>> sobre el nombre de las clases enumeradas.
* 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.
* Recordar que la idea del modelo conceptual es ser explicativo.
* Poner "'''/'''" en los atributos y responsabilidades derivadas.
* De encontrarse con un ciclo, por ejemplo, Paciente - Hospital - Cama (con las tres asociaciones posibles), casi siempre es necesario usar OCL para asegurar que para un paciente que esta en una cama y en un hospital, esa cama pertenezca a ese hospital.
* No restringir algo con OCL que se podría haber modelado con el diagrama (por ejemplo poner multiplicidad * y restringir con OCL a que sean 2).
* La herencia de clases es útil cuando las clases más específicas se relacionan de maneras distintas con alguna otra clase. Si ambas se relacionan igual con una clase A no poner la misma relación hacia las dos clases específicas sinó una sola relación hacia la clase general.
* No poner una clase "Bizarra" '''sólo''' para facilitarnos una restricción en OCL que de otra manera hubiera sido muy complicada.

[[Category:Apuntes]]