Caso de Uso Reserva de habitaciones y servicio / Resuelto por Felipe Ocampo
Nombre caso de uso
|
Iniciar sesión como
usuario.
|
|
Actor /es
|
Administrador o recepcionista.
|
|
Propósito
|
Permitir
al administrador o al recepcionista ingresar al sistema.
|
|
Visión General
|
El administrador o el recepcionista deben
ingresar su nombre de usuario y
contraseña para acceder al sistema.
|
|
Pre condiciones
|
Ingresar su nombre de usuario y contraseña
|
|
Post condiciones
|
Que lo ingresado exista dentro de la base
de datos del sistema
|
|
Incluye
|
||
Extiende
|
||
Hereda de
|
||
Curso Típico de Eventos: Acción del Actor / Respuesta del Sistema
|
||
1
|
Este caso de uso comienza cuando el
administrador o recepcionista desea iniciar sesión de trabajo.
|
|
2
|
El sistema despliega un módulo para
ingresar el nombre de usuario y la contraseña, para iniciar sesión.
|
|
3
|
El administrador o recepcionista ingresa
su nombre de usuario y contraseña.|
|
|
4
|
El sistema verifica que el nombre de
usuario y la contraseña, sean válidos
|
|
5
|
El sistema muestra el entorno de trabajo
correspondiente al usuario iniciado
|
|
Cursos alternativos
|
||
Línea n1
|
Si en el nombre de usuario y la contraseña
existe algo ingresado que no sea válido, entonces, el sistema muestra un
mensaje de información del caso y vuelve a colocar todo de nuevo.
|
|
Línea n2
|
Si el nombre de usuario y contraseña
ingresada no existen, el sistema muestra mensaje de información del caso y se
debe volver a ingresar todo
nuevamente.
|
|
Nombre caso de uso
|
Iniciar sesión de pasajeros.
|
|
Actor /es
|
Pasajero.
|
|
Propósito
|
Permitir
al pasajero ingresar al sistema.
|
|
Visión General
|
El pasajero debe ingresar su correo
electrónico y contraseña para entrar al sistema.
|
|
Pre condiciones
|
Ingresar su nombre de correo electrónico y
contraseña.
|
|
Post condiciones
|
Que los datos ingresados existan dentro de
la base de datos del sistema.
|
|
Incluye
|
||
Extiende
|
||
Hereda de
|
||
Curso Típico de Eventos: Acción del Actor / Respuesta del Sistema
|
||
1
|
Este caso de uso comienza cuando el
pasajero desea iniciar sesión
|
|
2
|
El sistema despliega un módulo para
ingresar el correo electrónico y la contraseña, para iniciar sesión.
|
|
3
|
El pasajero ingresa su correo electrónico
y contraseña.
|
|
4
|
El sistema verifica que el correo
electrónico y la contraseña, sean válidos.
|
|
5
|
El sistema muestra el entorno
correspondiente al pasajero iniciado.
|
|
Cursos alternativos
|
||
Línea n1
|
Si en el nombre de usuario y la contraseña
existe algo ingresado que no sea válido, entonces, el sistema muestra un
mensaje de información del caso y vuelve a colocar todo de nuevo.
|
|
Línea n2
|
Si el nombre de usuario y contraseña
ingresada no existen, el sistema muestra mensaje de información del caso y se
debe volver a ingresar todo
nuevamente.
|
|
Nombre caso de uso
|
Solicitar un servicio.
|
|
Actor /es
|
Pasajero.
|
|
Propósito
|
Solicitar
un servicio del hotel.
|
|
Visión General
|
El pasajero solicita al recepcionista o
administrador un servicio ofrecido por ellos.
|
|
Pre condiciones
|
Que el servicio esté disponible.
|
|
Post condiciones
|
Pagar por el servicio pedido.
|
|
Incluye
|
||
Extiende
|
||
Hereda de
|
||
Curso Típico de Eventos: Acción del Actor / Respuesta del Sistema
|
||
1
|
Este caso de uso comienza cuando el
Pasajero solicita un servicio al recepcionista o administrador.
|
|
2
|
Se ofrecen una serie de servicios.
|
|
3
|
El pasajero elige un servicio.
|
|
4
|
El administrador cobra por el servicio.
|
|
Cursos alternativos
|
||
Línea n1
|
El servicio elegido no
se encuentra disponible,entonces elige otro que se este disponible o no
solicita ningún servicio.
|
|
Línea n2
|
El servicio ofrecido
supera el monto disponible que el pasajero puede abonar, elige uno acorde a
su presupuesto o no elige ninguno.
|
|
Caso de Uso Municipio / Resuelto por Silvia Belizán
Ejemplo: Ficha de descripción de requisitos
Resumen Diagrama de Clase
UML está organizado en una serie de diagramas que tienen objetivos definidos, con sintaxis y semántica determinada, que representan/ modelan distintas vistas de un sistema.
El Diagrama de Clases tiene como objetivo describir las clases del dominio y sus relaciones. Permite modelar la estructura del sistema desde un punto de vista estático, modelando las clases desde distintos enfoques de acuerdo a la etapa del proyecto.
Esta compuesto por clases, relaciones entre clases y opcionalmente los paquetes que agrupan a las clases.
El Diagrama de Objetos tiene como objetivo describir los objetos del dominio y sus relaciones. Permite representar al sistema en un momento determinado del tiempo, es proporcional a obtener una fotografía o snapshot del sistema en un momento determinado.
Esta compuesto por objetos y relaciones de enlace. También es posible pensarlo como una instancia de un Diagrama de Clases.
Ambos diagramas son estructurales porque reflejan relaciones estáticas de una estructura.
El Diagrama de Clases (Class Diagram)
El diagrama de clases es un diagrama que permite modelar la estructura del sistema desde un punto de vista estático, modelando las clases desde distintos enfoques de acuerdo a la etapa del proyecto. Describe tipos de jerarquías, relaciones y abstracciones.
Objetivo
“..Describir las clases del dominio y sus relaciones..”
Elementos
Clase
Una clase representa a una agrupación de cosas, es una plantilla para armar un objeto. Las clases son detectadas – en la mayoría de los casos - como sustantivos en singular.
Ejemplos de una clase puede ser la clase Auto, que es una clase representante de todos los autos posibles (autos de carrera, autos urbanos, cualquier marca, patente, color, etc.) Otro ejemplo puede ser la clase Animal, representando a todos los animales posibles (mamíferos, herbívoros u otros, cualquier cantidad de patas, color, etc.)
Las clases están formadas por atributos y métodos, y por convención, la primera letra debe estar en mayúscula.
Que son los atributos
Los atributos son características que posee una clase, y determinan el estado que posteriormente tendrá un objeto En el caso de la clase Auto, atributos pueden ser color, marca, modelo, cantidad de puertas y velocidad. Por convención, la primera letra debe estar en minúscula.
Que son los métodos
Los métodos son las responsabilidades (o comportamiento) que realiza una clase. Generalmente los métodos son verbos. Por convención, la primera letra debe estar en minúscula.
Representación grafica de una clase
Las clases abstractas
Las clases abstractas son clases que representan un concepto abstracto, de carácter muy general. Por ejemplo una institución, que tiene los atributos dirección y superficie, pero no es posible determinar que tipo de institución es.
Es una clase que no se puede instanciar, es decir que no se puede crear un objeto a partir de ésta clase. Se utiliza como base para otras clases en la relación de generalización, pero no tiene sentido por sí sola.
Las clases que no son abstractas se denominan concretas. Por convención, la primera letra debe estar en mayúscula, y la palabra en negrita e itálica.
Representación gráfica de una clase abstracta
Interfaz
A diferencia de la clase, la interfaz define únicamente un comportamiento, es decir un conjunto de métodos que no poseen implementación. Estos métodos deberán ser implementados por las clases que decidan implementar la interfaz. Representa un “contrato” que una clase debe respetar en caso de implementar la interfaz.
Por ejemplo, se puede crear un interfaz denominada Volador, que tiene los métodos despegar, aterrizar y volar.
Por convención, para definir el nombre de una interfaz se aplican las mismas reglas que para una clase.
Relaciones
Generalización
La relación de generalización se produce entre dos clases. La clase superior es una generalización de la clase inferior, como así también la clase inferior es una particularización de la clase superior.
A la clase superior se la denomina superclase, y a la clase inferior se la denomina subclase. La subclase deberá respetar la relación “es un” o “is a”, que representa a la relación de generalización.
Al construir varios relaciones de este tipo entre clases, se genera la jerarquía de clases (o árbol de clases). En términos de un lenguaje de programación, es posible entenderla como herencia.
Por ejemplo, la clase MedioDeTransporte puede ser una superclase, y algunas de sus subclases pueden ser Auto, Avión y Tren.
Asociación
La relación de asociación representa una asociación entre dos clases, donde una clase “es socia” de otra o tienen algún tipo de relación. Es común describir con un nombre definido por el usuario la relación entre ambas.
Por ejemplo, la clase Cuidador tiene una relación con la clase Perro, donde Cuidador “cuida” al Perro. Es posible determinar la multiplicidad de los extremos de la relación, en el caso anterior un cuidador cuida de uno a muchos perros.
Existen dos relaciones denominadas Composición y Agregación que son casos particulares de la relación de Asociación.
Composición
La relación de composición se puede describir como “está compuesta por”, ya que una clase determina la existencia de la otra.
Si Clase1 está compuesta por Clase2 entonces Clase1 determina la existencia de Clase2.
Clase2 no podrá existir por si sola si no existe Clase1, es decir que Clase1 controla el tiempo de vida de Clase2.
Si la Clase1 es eliminada, también será eliminada Clase2, es decir que si se elimina el “todo” (Clase1), también serán eliminadas sus partes (Clase2).
UML denomina a la relación como “strong has-a relationship”, representando un fuerte sentido de pertenencia del “todo” hacia la “parte”.
Por ejemplo, un Auto está compuesta por un Carburador, con lo cual el Carburador no tiene sentido por si solo si no existe el Auto. Dicho Carburador puede utilizarse únicamente para ese Auto, y no para otros, es decir que el mismo Carburador no puede utilizarse al mismo tiempo en más de un Auto.
Otro ejemplo muy ilustrativo puede ser la relación entre una Tabla y una Columna, donde la Columna es construida si la Tabla es construida, y la Columna es eliminada si la Tabla es eliminada.
Agregación
La relación de agregación se puede describir como “tiene como partes a”. A diferencia de la composición, si Clase1 tiene como partes a Clase2, Clase1 no determina la existencia de Clase2. Clase2 puede existir aún cuando Clase1 no exista, es decir tiene sentido por si sola. Clase1 no controla el tiempo de vida de Clase2. Si la Clase1 es eliminada, puede no ser eliminada Clase2, es decir que si se elimina el “todo” (Clase1), no necesariamente serán eliminadas sus partes (Clase2).
UML denomina a la relación como “weak has-a relationship”, representando un débil sentido de pertenencia del “todo” hacia la “parte”.
Implementación o Realización
La relación de implementación se produce entre una clase y una interfaz. La clase que implementa la interfaz tiene la obligación de implementar todos los métodos que forman parte de esa interfaz.
Por ejemplo, un Avión para “saber volar” deberá implementar un interfaz denominada Volador, que incluye los métodos despegar, aterrizar y volar.
Esta relación también se denomina realización.
Clases Estereotipadas
El estereotipo representa la construcción de un nuevo elemento de UML que extiende a partir de uno ya existente, en el caso de las clases representa a una categoría o un tipo nuevo de clases. Representa una funcionalidad determinada, identificada por su nombre.
El Proceso Unificado de Desarrollo (presentado mas adelante) utiliza tres estereotipos de clases que se han estandarizado en el mercado, estos son Boundary, Control y Entity.
El estereotipo Boundary
El estereotipo Boundary se utiliza para representar clases que se encuentran en el limite (bound) del sistema. Estas clases representan a la interfaz de usuario dentro de un sistema, generalmente implementadas como ventanas. Se utilizan para capturar la interacción entre el usuario y el sistema a nivel de pantalla.
Estas clases dentro de una arquitectura multicapa generalmente pertenecen a la
Capa de Presentación (PL o Presentation Layer). En el patrón de diseño M-V-C representa a la vista.
El estereotipo Control
El estereotipo Control se utiliza para representar clases que se encargan de controlar los procesos de negocios, son clases que llevan a cabo las reglas de negocios, realizando la coordinación entre las clases del tipo Boundary y las clases del tipo Entity. Se encargan de la organización y planificación de actividades.
El estereotipo Entity
El estereotipo Entity se utiliza para almacenar o persistir información propia del sistema.
Representación gráfica
Aplicación
Modelo de Análisis o Modelo Conceptual
Uno de los posibles usos del diagrama de clases es la construcción del denominado Modelo Conceptual.
El modelo conceptual es uno o varios diagramas de clase construidos por un Analista Funcional que esta basado en la detección de clases (junto con sus atributos y posibles métodos) y sus relaciones pero desde un punto de vista funcional, es decir dentro de la de la etapa de Análisis.
No se definen características propias de un lenguaje de programación, sino que se intenta reflejar la realidad.
Adicionalmente, es posible utilizar una CRC Card (Class Responsability and Collaboration) para detallar el nombre de la clase, descripción, atributos y responsabilidades.
Modelo de Diseño
El modelo de diseño es el conjunto de diagramas de clases (puede ser uno solo) que se utiliza como base para realizar la codificación de la aplicación. El encargado de construirlo es el Diseñador, y debe definir todo lo que sea necesario para que el desarrollador pueda codificar sin problemas. Toma como uno de los documentos de entrada el correspondiente al Modelo de Análisis, y se definen nuevas clases (en general las detectadas en Análisis se mantienen) que tiene un perfil netamente de diseño y resuelven cuestiones técnicas y ya no de negocios.
A partir del Modelo de Diseño se genera el código fuente de manera automática que será tomado como base por los desarrolladores. De esta manera el programador no toma decisiones ni de Análisis ni de Diseño, lo cual queda restringido a programar en el código recibido.
El modelo tiende a evolucionar en la fase de construcción a través de feed-backs que realizan los desarrolladores.
Diseño de Base de Datos
El modelo de datos o diseño de una base de datos también es posible realizarlo a través de un diagrama de clases. En este caso las clases representan las tablas y los atributos representan los campos.
Para esto es necesario utilizar estereotipos (ver Sección Conceptos Generales), determinando el estereotipo <<table>> para las tablas, el estereotipo
<<column>> para los campos, y otros estereotipos posibles como <<PK>> para las claves primarias y <<FK>> para las claves foráneas, entre otros.
Ejemplo
Diagrama de Objetos (Object Diagram)
El Diagrama de Objetos permite representar el sistema en un momento determinado del tiempo, es similar a obtener una fotografía o snapshot del sistema en un momento determinado, y visualizar los objetos junto con sus relaciones.
Se suele utilizar como punto de partida para la construcción del Diagrama de Comunicación o Colaboración.
Objetivo
“..describir los objetos del dominio y sus relaciones..”
Elementos
Objeto
El objeto representa una cosa en particular, es una instancia de una clase. Nace de utilizar una clase como plantilla y llenar sus atributos con valores. Los objetos dentro del diagrama dependen de algún tipo de clase, y pueden estar estereotipados para una mejor comprensión.
Por convención, la primera letra debe estar en minúscula y la palabra subrayada. Es común agregar luego del nombre del objeto el nombre de la clase a la cual pertenece el objeto.
Relaciones
Vínculo
Se utiliza para establecer algún tipo de relación entre los objetos, no denota un tipo de relación en particular sino simplemente un vinculo que no tiene dirección.
Vínculo Direccional
Aplicación
Fotografía del sistema
Este diagrama es el menos utilizado de todos los diagramas ya que no representa relevancia sobre ninguna vista posible del sistema. Su uso mas frecuente es la posibilidad de visualizar el sistema en un determinado momento, estudiando que objetos están instanciados y la relación entre los mismos.
Ejemplo
UML está organizado en una serie de diagramas que tienen objetivos definidos, con sintaxis y semántica determinada, que representan/ modelan distintas vistas de un sistema.
El Diagrama de Clases tiene como objetivo describir las clases del dominio y sus relaciones. Permite modelar la estructura del sistema desde un punto de vista estático, modelando las clases desde distintos enfoques de acuerdo a la etapa del proyecto.
Esta compuesto por clases, relaciones entre clases y opcionalmente los paquetes que agrupan a las clases.
El Diagrama de Objetos tiene como objetivo describir los objetos del dominio y sus relaciones. Permite representar al sistema en un momento determinado del tiempo, es proporcional a obtener una fotografía o snapshot del sistema en un momento determinado.
Esta compuesto por objetos y relaciones de enlace. También es posible pensarlo como una instancia de un Diagrama de Clases.
Ambos diagramas son estructurales porque reflejan relaciones estáticas de una estructura.
El Diagrama de Clases (Class Diagram)
El diagrama de clases es un diagrama que permite modelar la estructura del sistema desde un punto de vista estático, modelando las clases desde distintos enfoques de acuerdo a la etapa del proyecto. Describe tipos de jerarquías, relaciones y abstracciones.
Objetivo
“..Describir las clases del dominio y sus relaciones..”
Elementos
Clase
Una clase representa a una agrupación de cosas, es una plantilla para armar un objeto. Las clases son detectadas – en la mayoría de los casos - como sustantivos en singular.
Ejemplos de una clase puede ser la clase Auto, que es una clase representante de todos los autos posibles (autos de carrera, autos urbanos, cualquier marca, patente, color, etc.) Otro ejemplo puede ser la clase Animal, representando a todos los animales posibles (mamíferos, herbívoros u otros, cualquier cantidad de patas, color, etc.)
Las clases están formadas por atributos y métodos, y por convención, la primera letra debe estar en mayúscula.
Que son los atributos
Los atributos son características que posee una clase, y determinan el estado que posteriormente tendrá un objeto En el caso de la clase Auto, atributos pueden ser color, marca, modelo, cantidad de puertas y velocidad. Por convención, la primera letra debe estar en minúscula.
Que son los métodos
Los métodos son las responsabilidades (o comportamiento) que realiza una clase. Generalmente los métodos son verbos. Por convención, la primera letra debe estar en minúscula.
Representación grafica de una clase
Las clases abstractas
Las clases abstractas son clases que representan un concepto abstracto, de carácter muy general. Por ejemplo una institución, que tiene los atributos dirección y superficie, pero no es posible determinar que tipo de institución es.
Es una clase que no se puede instanciar, es decir que no se puede crear un objeto a partir de ésta clase. Se utiliza como base para otras clases en la relación de generalización, pero no tiene sentido por sí sola.
Las clases que no son abstractas se denominan concretas. Por convención, la primera letra debe estar en mayúscula, y la palabra en negrita e itálica.
Representación gráfica de una clase abstracta
Interfaz
A diferencia de la clase, la interfaz define únicamente un comportamiento, es decir un conjunto de métodos que no poseen implementación. Estos métodos deberán ser implementados por las clases que decidan implementar la interfaz. Representa un “contrato” que una clase debe respetar en caso de implementar la interfaz.
Por ejemplo, se puede crear un interfaz denominada Volador, que tiene los métodos despegar, aterrizar y volar.
Por convención, para definir el nombre de una interfaz se aplican las mismas reglas que para una clase.
Relaciones
Generalización
La relación de generalización se produce entre dos clases. La clase superior es una generalización de la clase inferior, como así también la clase inferior es una particularización de la clase superior.
A la clase superior se la denomina superclase, y a la clase inferior se la denomina subclase. La subclase deberá respetar la relación “es un” o “is a”, que representa a la relación de generalización.
Al construir varios relaciones de este tipo entre clases, se genera la jerarquía de clases (o árbol de clases). En términos de un lenguaje de programación, es posible entenderla como herencia.
Por ejemplo, la clase MedioDeTransporte puede ser una superclase, y algunas de sus subclases pueden ser Auto, Avión y Tren.
Asociación
La relación de asociación representa una asociación entre dos clases, donde una clase “es socia” de otra o tienen algún tipo de relación. Es común describir con un nombre definido por el usuario la relación entre ambas.
Por ejemplo, la clase Cuidador tiene una relación con la clase Perro, donde Cuidador “cuida” al Perro. Es posible determinar la multiplicidad de los extremos de la relación, en el caso anterior un cuidador cuida de uno a muchos perros.
Existen dos relaciones denominadas Composición y Agregación que son casos particulares de la relación de Asociación.
Composición
La relación de composición se puede describir como “está compuesta por”, ya que una clase determina la existencia de la otra.
Si Clase1 está compuesta por Clase2 entonces Clase1 determina la existencia de Clase2.
Clase2 no podrá existir por si sola si no existe Clase1, es decir que Clase1 controla el tiempo de vida de Clase2.
Si la Clase1 es eliminada, también será eliminada Clase2, es decir que si se elimina el “todo” (Clase1), también serán eliminadas sus partes (Clase2).
UML denomina a la relación como “strong has-a relationship”, representando un fuerte sentido de pertenencia del “todo” hacia la “parte”.
Por ejemplo, un Auto está compuesta por un Carburador, con lo cual el Carburador no tiene sentido por si solo si no existe el Auto. Dicho Carburador puede utilizarse únicamente para ese Auto, y no para otros, es decir que el mismo Carburador no puede utilizarse al mismo tiempo en más de un Auto.
Otro ejemplo muy ilustrativo puede ser la relación entre una Tabla y una Columna, donde la Columna es construida si la Tabla es construida, y la Columna es eliminada si la Tabla es eliminada.
Agregación
La relación de agregación se puede describir como “tiene como partes a”. A diferencia de la composición, si Clase1 tiene como partes a Clase2, Clase1 no determina la existencia de Clase2. Clase2 puede existir aún cuando Clase1 no exista, es decir tiene sentido por si sola. Clase1 no controla el tiempo de vida de Clase2. Si la Clase1 es eliminada, puede no ser eliminada Clase2, es decir que si se elimina el “todo” (Clase1), no necesariamente serán eliminadas sus partes (Clase2).
UML denomina a la relación como “weak has-a relationship”, representando un débil sentido de pertenencia del “todo” hacia la “parte”.
Por ejemplo, una OrdenDeCompra tiene como partes a uno o muchos Producto(s), pero si el Producto no forma parte de ninguna OrdenDeCompra, sigue teniendo sentido por si mismo. Si la OrdenDeCompra es eliminada, el Producto no será eliminado.
Implementación o Realización
La relación de implementación se produce entre una clase y una interfaz. La clase que implementa la interfaz tiene la obligación de implementar todos los métodos que forman parte de esa interfaz.
Por ejemplo, un Avión para “saber volar” deberá implementar un interfaz denominada Volador, que incluye los métodos despegar, aterrizar y volar.
Esta relación también se denomina realización.
Clases Estereotipadas
El estereotipo representa la construcción de un nuevo elemento de UML que extiende a partir de uno ya existente, en el caso de las clases representa a una categoría o un tipo nuevo de clases. Representa una funcionalidad determinada, identificada por su nombre.
El Proceso Unificado de Desarrollo (presentado mas adelante) utiliza tres estereotipos de clases que se han estandarizado en el mercado, estos son Boundary, Control y Entity.
El estereotipo Boundary
El estereotipo Boundary se utiliza para representar clases que se encuentran en el limite (bound) del sistema. Estas clases representan a la interfaz de usuario dentro de un sistema, generalmente implementadas como ventanas. Se utilizan para capturar la interacción entre el usuario y el sistema a nivel de pantalla.
Estas clases dentro de una arquitectura multicapa generalmente pertenecen a la
Capa de Presentación (PL o Presentation Layer). En el patrón de diseño M-V-C representa a la vista.
El estereotipo Control
El estereotipo Control se utiliza para representar clases que se encargan de controlar los procesos de negocios, son clases que llevan a cabo las reglas de negocios, realizando la coordinación entre las clases del tipo Boundary y las clases del tipo Entity. Se encargan de la organización y planificación de actividades.
El estereotipo Entity
El estereotipo Entity se utiliza para almacenar o persistir información propia del sistema.
Representación gráfica
Aplicación
Modelo de Análisis o Modelo Conceptual
Uno de los posibles usos del diagrama de clases es la construcción del denominado Modelo Conceptual.
El modelo conceptual es uno o varios diagramas de clase construidos por un Analista Funcional que esta basado en la detección de clases (junto con sus atributos y posibles métodos) y sus relaciones pero desde un punto de vista funcional, es decir dentro de la de la etapa de Análisis.
No se definen características propias de un lenguaje de programación, sino que se intenta reflejar la realidad.
Adicionalmente, es posible utilizar una CRC Card (Class Responsability and Collaboration) para detallar el nombre de la clase, descripción, atributos y responsabilidades.
Modelo de Diseño
El modelo de diseño es el conjunto de diagramas de clases (puede ser uno solo) que se utiliza como base para realizar la codificación de la aplicación. El encargado de construirlo es el Diseñador, y debe definir todo lo que sea necesario para que el desarrollador pueda codificar sin problemas. Toma como uno de los documentos de entrada el correspondiente al Modelo de Análisis, y se definen nuevas clases (en general las detectadas en Análisis se mantienen) que tiene un perfil netamente de diseño y resuelven cuestiones técnicas y ya no de negocios.
A partir del Modelo de Diseño se genera el código fuente de manera automática que será tomado como base por los desarrolladores. De esta manera el programador no toma decisiones ni de Análisis ni de Diseño, lo cual queda restringido a programar en el código recibido.
El modelo tiende a evolucionar en la fase de construcción a través de feed-backs que realizan los desarrolladores.
Diseño de Base de Datos
El modelo de datos o diseño de una base de datos también es posible realizarlo a través de un diagrama de clases. En este caso las clases representan las tablas y los atributos representan los campos.
Para esto es necesario utilizar estereotipos (ver Sección Conceptos Generales), determinando el estereotipo <<table>> para las tablas, el estereotipo
<<column>> para los campos, y otros estereotipos posibles como <<PK>> para las claves primarias y <<FK>> para las claves foráneas, entre otros.
Ejemplo
Diagrama de Objetos (Object Diagram)
El Diagrama de Objetos permite representar el sistema en un momento determinado del tiempo, es similar a obtener una fotografía o snapshot del sistema en un momento determinado, y visualizar los objetos junto con sus relaciones.
Se suele utilizar como punto de partida para la construcción del Diagrama de Comunicación o Colaboración.
Objetivo
“..describir los objetos del dominio y sus relaciones..”
Elementos
Objeto
El objeto representa una cosa en particular, es una instancia de una clase. Nace de utilizar una clase como plantilla y llenar sus atributos con valores. Los objetos dentro del diagrama dependen de algún tipo de clase, y pueden estar estereotipados para una mejor comprensión.
Por convención, la primera letra debe estar en minúscula y la palabra subrayada. Es común agregar luego del nombre del objeto el nombre de la clase a la cual pertenece el objeto.
Relaciones
Vínculo
Se utiliza para establecer algún tipo de relación entre los objetos, no denota un tipo de relación en particular sino simplemente un vinculo que no tiene dirección.
Vínculo Direccional
Se utiliza de la misma forma que el vínculo, pero tiene como valor agregado que permite entender mejor la relación, determinar la navegabilidad de la misma.
Aplicación
Fotografía del sistema
Este diagrama es el menos utilizado de todos los diagramas ya que no representa relevancia sobre ninguna vista posible del sistema. Su uso mas frecuente es la posibilidad de visualizar el sistema en un determinado momento, estudiando que objetos están instanciados y la relación entre los mismos.
Ejemplo
