SlideShare una empresa de Scribd logo
Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
Contenidos de la Unidad 1 Introducción al Diseño f) Ingeniería del Software Asistida por Computadora. Clasificación de CASE    Sommerville. Sección 4.5   C. Proceso de Diseño Pressman. Cap. 13.2 Introducción.   I. Fases del diseño. Pressman. Sección 13.1 Sommerville. Sección 4.3.2 II. Diseño y calidad del software Pressman. 13.2.1 III. Principios y conceptos del diseño. Pressman.  Sección 13.3 y 13.4 IV. Documentación del Diseño. Pressman, Sección 13.8 V. Análisis y Diseño Orientado a Objetos Sommerville, Cap.14 Larman, 2ª. Ed., Cap. 1.4 Pressman, Cap.21 y 22 VI. Modelos de dominio, Casos de Uso. (revisión) Larman, 1ª. Ed.,Cap. 9/11 Larman, 2a. Ed. Cap. 9/11 VII. Del Análisis al Diseño Larma n, 1ª. Ed. Cap. 15 Larman, 2ª. Ed. Cap. 14
MODELO CONCEPTUAL O DE DOMINIO Craig Larman (Caps. 9/12) Ingeniería en Sistemas de Información DISEÑO DE SISTEMAS Una vez concluida la fase de planeación y elaboración  y que los casos de uso fueron identificados, clasificados y programados. Se presenta entonces una transición muy importante: comienza la fase de construcción, donde se cumplen los ciclos del desarrollo iterativo.
DISEÑO DE SISTEMAS Un  Modelo Conceptual  nos brinda los conceptos significativos para el dominio del problema. El lenguaje UML ofrece la notación en diagramas de estructuras estáticas para graficar los modelos conceptuales Es el “artefacto” más importante que se crea durante la etapa del AOO Modelo Conceptual   => representa cosas del mundo real, no componentes del software Actividades y dependencias Crear un Modelo Conceptual para los Casos de Uso no puede hacerse si no se cuenta con los Casos y con Documentos que permitan identificar los Conceptos (Objetos). La creación no siempre es lineal, puede formularse en paralelo con el desarrollo de los Casos.
DISEÑO DE SISTEMAS Modelo Conceptual El paso esencial en el enfoque orientado a  objetos  es  descomponer el problema en conceptos u objetos individuales : las cosas que sabemos Modelo Conceptual => representación de conceptos en un dominio del problema En UML lo ilustramos con un conjunto de  diagramas de estructura estática  donde  no se define ninguna operación Un modelo conceptual puede mostrar: Conceptos Asociaciones entre conceptos Atributos de conceptos  MODELO CONCEPTUAL
DISEÑO DE SISTEMAS Modelo Conceptual ¿Qué representa? Un modelo conceptual nos permite descomponer el dominio del problema en unidades comprensibles (conceptos), éste contribuye a esclarecer la terminología o nomenclatura del dominio. ¿Qué NO representa? Un modelo conceptual NO ES una descripción del diseño del software, como una clase en C++, una ventana, una base de datos, etc. Class alumno{ int Cod; char *Apellido; . . .
DISEÑO DE SISTEMAS Modelo Conceptual En términos informales el concepto es una idea, cosa u objeto. En un lenguaje más formal, podemos considerarlo a partir de su simbolo, intensión y extensión.   Símbolo : palabras o imágenes que representan un concepto Intensión : la definición del concepto Extensión : el conjunto de ejemplos a que se aplica el concepto. CONCEPTOS Un modelo conceptual muestra conceptos del mundo real venta fecha hora conceptos del mundo, no una clase de software
DISEÑO DE SISTEMAS Modelo Conceptual Venta-1 Venta-3 Venta-2 venta fecha hora Símbolo del Concepto Intensión del Concepto “ Una venta representa el evento de una transacción de compra. Tiene fecha y hora.” Extensión del Concepto
DISEÑO DE SISTEMAS Modelo Conceptual Estrategias para identificar los conceptos   La meta es crear un modelo conceptual de conceptos interesantes o significativos del dominio en cuestión. Es mejor exagerar y especificar un modelo conceptual con muchos conceptos refinados que no especificarlo cabalmente. No piense que un modelo conceptual es más adecuado si tiene menos conceptos. Es frecuente omitir coceptos durante la fase inicial de identificación y descubrirlos más tarde, lo importante es incorporarlos. No excluya conceptos simplemente porque los requerimientos no indiquen una necesidad.
Dos estrategias para identificar los conceptos: 1. Obtención de conceptos a partir de una lista de categorías de conceptos. 2. Obtención de conceptos a partir de la identificación de frases nominales. DISEÑO DE SISTEMAS Modelo Conceptual 1. La creación de un modelo conceptual comienza preparando una lista de conceptos idóneos.
2. Consiste en identificar las frases nominales en las descripciones textuales del dominio de un problema y considerarlas conceptos o atributos idóneos. DISEÑO DE SISTEMAS Modelo Conceptual Este método hay que utilizarlo con mucha prudencia; no es posible encontrar siempre mecánicamente correspondencias entre sustantivo y concepto, y además las palabras del lenguaje natural son ambiguas.     Acción del actor Respuesta del sistema 1. Este caso de uso comienza cuando el  Socio  llega a la  caja  con  videos  para  alquilar .   2. El  empleado  ingresa el  Nº de socio .     3. Visualiza el nombre del Socio. 5. Incorpora el  título  del video a la  transacción .   4. El empleado registra el  código de video . 6. ....
DISEÑO DE SISTEMAS Modelo Conceptual Cómo construir un modelo conceptual 1. Liste los conceptos idóneos usando la Lista de categorías de conceptos y la identificación de la frase nominal relacionada con los requerimientos en cuestión. 2. Dibújelos en un modelo conceptual. 3. Incorpore las asociaciones necesarias para registrar las relaciones para las cuales debe reservar un espacio en la memoria. 4. Agregue los atributos necesarios para cumplir con las necesidades de información.
DISEÑO DE SISTEMAS Modelo Conceptual La asignación de nombres y el modelado de las cosas: el cartógrafo La estrategia del cartógrafo se aplica a los mapas y a los modelos conceptuales:       Utilice los nombres existentes en el territorio.       Excluya las características irrelevantes.       No agregue cosas que no existen. El modelo conceptual es una especie de mapa de conceptos o cosas de un dominio. Este enfoque pone de relieve el papel analítico de un modelo conceptual y sugiere lo siguiente:        
DISEÑO DE SISTEMAS Modelo Conceptual  Los cartógrafos se sirven de nombres del territorio – no cambian los nombres de las ciudades en sus mapas. En un modelo conceptual significa  utilizar el vocabulario del dominio cuando se asignan nombres a los conceptos y a los atributos .      Un cartógrafo elimina cosas en el mapa en caso de que no las juzgue pertinentes para su propósito. De modo análogo, un modelo conceptual puede excluir en el dominio del problema los conceptos que no se relacionen con los requerimientos. Por ejemplo, podemos omitir  BolsadePapel  (del modelo conceptual) por no tener una función importante u obvia.      Un cartógrafo no muestra cosas que no existen. En forma parecida, el modelo conceptual ha de excluir las cosas que  no  se encuentren en el dominio del problema en cuestión.
DISEÑO DE SISTEMAS Modelo Conceptual Un Error Frecuente al identificar Conceptos   Tal vez el error más frecuente cuando se crea un modelo conceptual es el de representar algo como atributo, cuando debió haber sido un concepto. Una regla práctica para no caer en él es:  Si en el mundo real no consideramos algún concepto X como número o texto, probablemente X sea un concepto y no un atributo.   Por ejemplo, el caso del dominio de las reservaciones en líneas aéreas. ¿Debería “ Destino”  ser un atributo de “ Vuelo”  o ser un concepto aparte llamado “ Aeropuerto” ?
DISEÑO DE SISTEMAS Modelo Conceptual En el mundo real, un aeropuerto de destino no se considera número ni texto: es una cosa masiva que ocupa espacio. Por tanto,  Aeropuerto  debería ser un  concepto . En caso de duda, convierta el atributo en un concepto independiente. Vuelo Destino Vuelo Aeropuerto Nombre ¿o ...?
DISEÑO DE SISTEMAS Modelo Conceptual Especificación o descripción de conceptos   Necesidad de las especificaciones. La descripción o especificación de objetos se relaciona con aquella cosa que describen. En un modelo conceptual, se acostumbra a estipular que una  Especificación X describe una X.   Por ejemplo:   una  EspecificaciondeProducto  no representa un  Elemento,  sino una descripción  acerca  de ellos.   La necesidad de especificar los conceptos es frecuente en los dominios de ventas, productos y elaboración, a donde se requiere una  descripción  de lo manufacturado que se distingue de la cosa manufacturada.
DISEÑO DE SISTEMAS Modelo Conceptual Especificaciones de otras cosas. El signo “*” indica multiplicidad de “muchos”. Indica que una “ EspecificaciondeProducto”  puede describir muchos  Productos . Producto descripcion precio numero de serie CUP EspecificaciondeProducto descripcion precio CUP Producto numero de serie 1 * Describe Mal Bien
DISEÑO DE SISTEMAS Modelo Conceptual ¿Cuando se requiere especificar los conceptos?   Incorpore una especificación o descripción de conceptos cuando:   L a eliminación de las instancias de las cosas que se describen da por resultado una pérdida de información que debe conservarse. Reduce información redundante o duplicada.
DISEÑO DE SISTEMAS Modelo Conceptual AGREGACIÓN DE LAS ASOCIACIONES Asociaciones:   La asociación es una relación entre dos conceptos que indica alguna conexión significativa e interesante entre ellos.   1 Caja Venta Registra asociación *
DISEÑO DE SISTEMAS Modelo Conceptual Criterios de las asociaciones útiles   Las asociaciones “significativas” o “interesantes” son las que deben preservarse durante algún tiempo (milisegundos o años). En otras palabras, cuando entre los objetos hay que tener algún recuerdo sobre una relación; por ejemplo, se debe recordar cuáles instancias de  VentasLineadeProducto  están asociadas a la instancia  Venta , porque de lo contrario no sería posible reconstruir la venta, imprimir el recibo ni calcular el total de la venta.
DISEÑO DE SISTEMAS Modelo Conceptual Examine la conveniencia de incluir las siguientes asociaciones en un modelo conceptual:          L as asociaciones en que el conocimiento de la relación ha de ser preservado  durante algún tiempo (asociaciones que “deben conocerse”).          Las asociaciones provenientes de la  Lista de asociaciones comunes . De lo contrario, no es necesario recordar una relación entre una  Venta  Actual y un  Gerente , pues los requerimientos no indican que haga falta ese tipo de relación. Tal vez no sea incorrecto mostrar esta relación, pero no es útil dentro del contexto de nuestros requerimientos.
DISEÑO DE SISTEMAS Modelo Conceptual Notación de las asociaciones en UML   Una asociación se representa como una línea entre los conceptos con el nombre de la asociación. Esta es intrínsecamente bidireccional, o sea es posible un nexo lógico entre los objetos de un tipo y los del otro. Este vínculo es  totalmente abstracto ;  no  es una afirmación sobre las conexiones entre las entidades del software.   1 Caja Venta Registra asociación * -flecha de dirección de la lectura -sin otro significado  -a menudo se excluye multiplicidad
DISEÑO DE SISTEMAS Modelo Conceptual Los extremos de una asociación pueden contener una expresión de multiplicidad que indique la relación numérica entre las instancias de los conceptos. Una flecha opcional de la dirección de lectura ( o  “flecha de la dirección del nombre” ) indica la dirección en que debe leerse el nombre de la asociación; no denota la dirección de visibilidad o de navegación. En su ausencia, la asociación se lee de izquierda a derecha o de arriba hacia abajo.  La flecha de dirección de la lectura no tiene un valor semántico; tan solo es una ayuda para leer el diagrama.
DISEÑO DE SISTEMAS Modelo Conceptual Identificación de las asociaciones: Lista de asociaciones comunes   Comience a agregar las asociaciones utilizando la lista anexa. Contiene categorías comunes que normalmente vale la pena incluir. Los ejemplos tomados de los dominios de la Tienda y de la reservación de las líneas aéreas.   Categoría Ejemplos A es una parte física de B Caja – TPDV Ala – Avion  A es una parte lógica de B VentasLineadeProducto – Venta TramodeVuelo – RutadeVuelo A está físicamente contenido en B TPDV – Tienda, Producto – Estante Pasajero – Avion A está contenido lógicamente en B DescripciondeProducto – Catalogo Vuelo – Programa de Vuelo ... ...
DISEÑO DE SISTEMAS Modelo Conceptual Asociaciones de alta prioridad   Son aquellas  que siempre conviene incluir en un modelo   conceptual:           A es una  parte física o lógica  de B.           A está  física o lógicamente contenido  en B.           A está  registrado en  B.
DISEÑO DE SISTEMAS Modelo Conceptual ¿Qué grado de detalle deberían tener las asociaciones?   Las asociaciones son importantes, pero una falla habitual al crear modelos conceptuales es el excesivo tiempo que, durante la investigación, se dedica al intento de descubrirlas. Es indispensable convencerse de lo siguiente: Es mucho más importante identificar los  conceptos  que las asociaciones. El tiempo consagrado a la creación del modelo conceptual debería destinarse a identificar los conceptos, no las asociaciones.
DISEÑO DE SISTEMAS Modelo Conceptual Directrices de las asociaciones   Concentrarse en las asociaciones en que el conocimiento de la relación ha de preservarse durante algún tiempo (asociaciones que “es necesario conocer”).  Es más importante identificar los  conceptos  que las asociaciones.  Muchas asociaciones tienden a confundir el modelo conceptual en vez de aclararlo. A veces se requiere mucho tiempo para descubrirlas, y los beneficios son escasos.  No incluir las asociaciones redundantes ni las derivables.
DISEÑO DE SISTEMAS Modelo Conceptual Multiplicidad   La multiplicidad  define cuántas instancias de un tipo A pueden asociarse a una instancia de tipo B en determinado momento. Por ejemplo, una instancia individual de una  Tienda  puede asociarse a “muchas” instancias de  Producto .   1 Tienda Producto Almacena * multiplicidad
DISEÑO DE SISTEMAS Modelo Conceptual Asignación de nombres a las asociaciones Los nombres de las asociaciones comienzan con una mayúscula. Una frase nominal debe construirse con guiones. 1 Caja Venta Registra 1..* Tienda Pago 1 Pagada-por 1 1..* 1 Contiene
DISEÑO DE SISTEMAS Modelo Conceptual Asociaciones múltiples entre dos tipos   Dos tipos pueden tener varias asociaciones entre ellos; esto sucede con frecuencia. No hay un ejemplo sobresaliente en nuestro sistema TPDV, pero en el dominio de la línea aérea encontramos uno en las relaciones entre  Vuelo  y  Aeropuerto . Las asociaciones volar – hacia y volar – de son relaciones netamente diferentes que han de mostrarse por separado.   Vuelo Aeropuerto 0..1 * Vuela-a * 1 Vuela-de
DISEÑO DE SISTEMAS Modelo Conceptual Atributos => Valor Lógico de un dato de un objeto.   Clave para su inclusión en un Modelo Conceptual:   Aquellos en que los requerimientos (Casos de Uso) indican o conllevan la  necesidad de recordar información . (El concepto “Venta” requiere, por ejemplo, los atributos de: fecha y hora) AGREGACIÓN DE LOS ATRIBUTOS
DISEÑO DE SISTEMAS Modelo Conceptual Notación de los atributos en UML   Los atributos se muestran en la segunda sección de la sección de los Conceptos. Indicar su tipo es opcional. Venta Fecha Hora Atributos
DISEÑO DE SISTEMAS Modelo Conceptual Conserve simples los atributos   Los tipos más simples de atributos son los que, en la práctica, suelen considerarse los tipos primitivos de datos. Por lo general el tipo de un atributo no debería ser un  concepto complejo  del dominio (al revés que los “conceptos”).   En un modelo conceptual es preferible que los atributos sean atributos simples o valores puros de datos.   Entre los tipos comunes de atributos simples más frecuentes se cuentan: Booleano, Fecha, Número, Cadena, Hora, Dirección, Color, Geometría, Número telefónico, DNI, CUP, Código Postal, ISBN, Nombre y Apellido, etc.
DISEÑO DE SISTEMAS Modelo Conceptual Cajero nombre CAJAactual Atributos Mal Cajero nombre Caja numero Usa 1 1 Bien
DISEÑO DE SISTEMAS Modelo Conceptual Relacione conceptos con una asociación, no con un atributo   Vuelo destino Aeropuerto 1 1 Vuela-a Vuelo Mal Bien Destino es un concepto complejo
DISEÑO DE SISTEMAS Modelo Conceptual Ningún atributo debe incluirse como clave foránea   Los atributos no se usan para relacionar conceptos distintos en el Modelo Conceptual. La violación más frecuente de esta regla consiste en agregar un tipo de atributo de clave foránea, lo cual suele hacerse con los diseños de bases de datos relacionales, a fin de asociar dos entidades. Cajero nombre NumeroTPDVactual Un atributo “simple”, pero que se  usa como clave extraña para relacionarlo con otro objeto Mal Cajero nombre TPDV numero Usa 1 1 Bien
DISEÑO DE SISTEMAS Modelo Conceptual Glosario   El glosario o diccionario modelo incluye y define todos los términos que requieren explicación para mejorar la comunicación y aminorar el riesgo de malos entendidos. El glosario se crea originalmente durante la fase de planeación y Elaboración conforme vayan generándose los términos; después va perfeccionándose continuamente en cada ciclo de desarrollo al aparecer nuevos vocablos.   En cuanto al formato del glosario no existe uno oficial. Durante nuestro diseño adoptaremos el siguiente:
DISEÑO DE SISTEMAS Modelo Conceptual Término Categoría Comentarios Comprar Productos Caso de Uso Descripción del proceso de un cliente que compra productos en una tienda. Producto Tipo/Concepto Un producto que la Tienda tiene disponible para la venta. Pago.monto:  Dinero Atributo El monto que el cliente abona para cancelar una Venta. ... ... ...

Más contenido relacionado

La actualidad más candente

Diagramas UML: Componentes y despliegue
Diagramas UML: Componentes y despliegueDiagramas UML: Componentes y despliegue
Diagramas UML: Componentes y despliegue
joshell
 
control de concurrencia
control de concurrenciacontrol de concurrencia
control de concurrencia
Jose Guadalupe Couoh Dzul
 
Uml lenguaje unificado de modelado
Uml lenguaje unificado de modeladoUml lenguaje unificado de modelado
Uml lenguaje unificado de modelado
Marvin Zumbado
 
Diagrama de dominio armando
Diagrama de dominio armandoDiagrama de dominio armando
Diagrama de dominio armando
Negrita Ruiz Bruno
 
Fundamentos de POO
Fundamentos de POOFundamentos de POO
Fundamentos de POO
gueritamala
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
Andrés Felipe Montoya Ríos
 
2. El proceso del software
2. El proceso del software2. El proceso del software
2. El proceso del software
Luis Fernandez Vizcarra
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
Nedoww Haw
 
Diagrama de Componentes
Diagrama de ComponentesDiagrama de Componentes
Diagrama de Componentes
Universidad Técnica del Norte
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientos
nenyta08
 
Modelamiento software
Modelamiento softwareModelamiento software
Modelamiento software
Cristhian J. Oscco Huangal
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de software
Yaskelly Yedra
 
Metodologia orientada a objeto
Metodologia orientada a objetoMetodologia orientada a objeto
Metodologia orientada a objeto
Luis Eduardo Aponte
 
Ingenieria requerimientos
Ingenieria requerimientosIngenieria requerimientos
Ingenieria requerimientos
Giovanny Guillen
 
Diagrama de interaccion(secuencia y colaboracion)
Diagrama de interaccion(secuencia y colaboracion)Diagrama de interaccion(secuencia y colaboracion)
Diagrama de interaccion(secuencia y colaboracion)
marianela0393
 
Diagramas estados
Diagramas estadosDiagramas estados
Diagramas estados
loco8888
 
Requerimientos no funcionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos no funcionales
Angel Minga
 
Vistas Arquitectonicas Ingenieria de Software
Vistas Arquitectonicas Ingenieria de SoftwareVistas Arquitectonicas Ingenieria de Software
Vistas Arquitectonicas Ingenieria de Software
Roberth Loaiza
 
Ieee 830
Ieee 830Ieee 830
Ieee 830
ALEX MERINO
 
03 Modelo Relacional
03 Modelo Relacional03 Modelo Relacional
03 Modelo Relacional
Kudos S.A.S
 

La actualidad más candente (20)

Diagramas UML: Componentes y despliegue
Diagramas UML: Componentes y despliegueDiagramas UML: Componentes y despliegue
Diagramas UML: Componentes y despliegue
 
control de concurrencia
control de concurrenciacontrol de concurrencia
control de concurrencia
 
Uml lenguaje unificado de modelado
Uml lenguaje unificado de modeladoUml lenguaje unificado de modelado
Uml lenguaje unificado de modelado
 
Diagrama de dominio armando
Diagrama de dominio armandoDiagrama de dominio armando
Diagrama de dominio armando
 
Fundamentos de POO
Fundamentos de POOFundamentos de POO
Fundamentos de POO
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
 
2. El proceso del software
2. El proceso del software2. El proceso del software
2. El proceso del software
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
 
Diagrama de Componentes
Diagrama de ComponentesDiagrama de Componentes
Diagrama de Componentes
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientos
 
Modelamiento software
Modelamiento softwareModelamiento software
Modelamiento software
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de software
 
Metodologia orientada a objeto
Metodologia orientada a objetoMetodologia orientada a objeto
Metodologia orientada a objeto
 
Ingenieria requerimientos
Ingenieria requerimientosIngenieria requerimientos
Ingenieria requerimientos
 
Diagrama de interaccion(secuencia y colaboracion)
Diagrama de interaccion(secuencia y colaboracion)Diagrama de interaccion(secuencia y colaboracion)
Diagrama de interaccion(secuencia y colaboracion)
 
Diagramas estados
Diagramas estadosDiagramas estados
Diagramas estados
 
Requerimientos no funcionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos no funcionales
 
Vistas Arquitectonicas Ingenieria de Software
Vistas Arquitectonicas Ingenieria de SoftwareVistas Arquitectonicas Ingenieria de Software
Vistas Arquitectonicas Ingenieria de Software
 
Ieee 830
Ieee 830Ieee 830
Ieee 830
 
03 Modelo Relacional
03 Modelo Relacional03 Modelo Relacional
03 Modelo Relacional
 

Destacado

Unidad 5 Mad Modelado Analisis Modelo Conceptual
Unidad 5 Mad Modelado Analisis   Modelo ConceptualUnidad 5 Mad Modelado Analisis   Modelo Conceptual
Unidad 5 Mad Modelado Analisis Modelo Conceptual
Sergio Sanchez
 
Domain Modeling
Domain ModelingDomain Modeling
Domain Modeling
Harsh Jegadeesan
 
Aula diagrama de classes
Aula diagrama de classesAula diagrama de classes
Aula diagrama de classes
Márcia Rodrigues
 
Modelos de dominio
Modelos de dominioModelos de dominio
Modelos de dominio
Juan Pablo Bustos Thames
 
Analise sistemas 03
Analise sistemas 03Analise sistemas 03
Analise sistemas 03
Caroline Raquel Rodrigues
 
Modelo del dominio
Modelo del dominioModelo del dominio
Modelo del dominio
SCMU AQP
 
Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1
Adriano Tavares
 
Arquitetura de Software Visão Geral
Arquitetura de Software Visão GeralArquitetura de Software Visão Geral
Arquitetura de Software Visão Geral
sergiocrespo
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
Conecta - Grupo ACP
 
Modelos de Datos y Modelado Conceptual
Modelos de Datos y Modelado ConceptualModelos de Datos y Modelado Conceptual
Modelos de Datos y Modelado Conceptual
Anabel
 
Modelo conceptual de la base de datos
Modelo conceptual de la base de datosModelo conceptual de la base de datos
Modelo conceptual de la base de datos
Ruth Hidalgo Tene
 
Modelo conceptual de uml
Modelo conceptual de umlModelo conceptual de uml
Modelo conceptual de uml
Sergio Girado
 
Modelo Conceptual
Modelo ConceptualModelo Conceptual
Modelo Conceptual
Alex Gonzaga
 
Modelo dominio y secuencia
Modelo dominio y secuenciaModelo dominio y secuencia
Modelo dominio y secuencia
brayanfp
 

Destacado (14)

Unidad 5 Mad Modelado Analisis Modelo Conceptual
Unidad 5 Mad Modelado Analisis   Modelo ConceptualUnidad 5 Mad Modelado Analisis   Modelo Conceptual
Unidad 5 Mad Modelado Analisis Modelo Conceptual
 
Domain Modeling
Domain ModelingDomain Modeling
Domain Modeling
 
Aula diagrama de classes
Aula diagrama de classesAula diagrama de classes
Aula diagrama de classes
 
Modelos de dominio
Modelos de dominioModelos de dominio
Modelos de dominio
 
Analise sistemas 03
Analise sistemas 03Analise sistemas 03
Analise sistemas 03
 
Modelo del dominio
Modelo del dominioModelo del dominio
Modelo del dominio
 
Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1
 
Arquitetura de Software Visão Geral
Arquitetura de Software Visão GeralArquitetura de Software Visão Geral
Arquitetura de Software Visão Geral
 
Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
Modelos de Datos y Modelado Conceptual
Modelos de Datos y Modelado ConceptualModelos de Datos y Modelado Conceptual
Modelos de Datos y Modelado Conceptual
 
Modelo conceptual de la base de datos
Modelo conceptual de la base de datosModelo conceptual de la base de datos
Modelo conceptual de la base de datos
 
Modelo conceptual de uml
Modelo conceptual de umlModelo conceptual de uml
Modelo conceptual de uml
 
Modelo Conceptual
Modelo ConceptualModelo Conceptual
Modelo Conceptual
 
Modelo dominio y secuencia
Modelo dominio y secuenciaModelo dominio y secuencia
Modelo dominio y secuencia
 

Similar a Modelos de dominio

Clase 29
Clase 29Clase 29
Clase 29
victdiazm
 
Uso de-patrones-de-arquitectura-capitulo-4
Uso de-patrones-de-arquitectura-capitulo-4Uso de-patrones-de-arquitectura-capitulo-4
Uso de-patrones-de-arquitectura-capitulo-4
Ozzy Bull
 
Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
Nii Caytuiro
 
Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
Nii Caytuiro
 
Diagramas de clases
Diagramas de clasesDiagramas de clases
Diagramas de clases
Juan Pablo Bustos Thames
 
6.modelado de los requerimientos escenarios y clases
6.modelado de los requerimientos  escenarios y clases6.modelado de los requerimientos  escenarios y clases
6.modelado de los requerimientos escenarios y clases
Ramiro Estigarribia Canese
 
Diseño de patrones
Diseño de patronesDiseño de patrones
Diseño de patrones
Edwin Roman Castrillon
 
ComputacionParaTodos / SocioTecnologico
ComputacionParaTodos / SocioTecnologicoComputacionParaTodos / SocioTecnologico
ComputacionParaTodos / SocioTecnologico
andres hurtado
 
Poa Borrador
Poa BorradorPoa Borrador
Poa Borrador
AmistadLealtad
 
Patrones GRASP de tipo de bajo acoplamiento
Patrones GRASP de  tipo de bajo acoplamientoPatrones GRASP de  tipo de bajo acoplamiento
Patrones GRASP de tipo de bajo acoplamiento
Fernando Alfonso Casas De la Torre
 
METODOS Y MODELOS POO
METODOS Y MODELOS POOMETODOS Y MODELOS POO
METODOS Y MODELOS POO
johnny herrera
 
Semana13-AOO.ppt
Semana13-AOO.pptSemana13-AOO.ppt
Semana13-AOO.ppt
antonyfloresgutierre
 
Patrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. graspPatrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. grasp
Juan Pablo Bustos Thames
 
Analisis de requerimiento
Analisis de requerimientoAnalisis de requerimiento
Analisis de requerimiento
turlahackers
 
7.modelado de los requerimientos escenarios y clases
7.modelado de los requerimientos  escenarios y clases7.modelado de los requerimientos  escenarios y clases
7.modelado de los requerimientos escenarios y clases
Ramiro Estigarribia Canese
 
Introducción poo
Introducción pooIntroducción poo
Introducción poo
g_torrealba
 
Consejos para escribir buenos casos de uso
Consejos para escribir buenos casos de usoConsejos para escribir buenos casos de uso
Consejos para escribir buenos casos de uso
kaolong
 
Uml
UmlUml
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso RealesUnidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Sergio Sanchez
 
3 analisis y diseño resumen
3  analisis  y diseño resumen3  analisis  y diseño resumen
3 analisis y diseño resumen
felixzenon
 

Similar a Modelos de dominio (20)

Clase 29
Clase 29Clase 29
Clase 29
 
Uso de-patrones-de-arquitectura-capitulo-4
Uso de-patrones-de-arquitectura-capitulo-4Uso de-patrones-de-arquitectura-capitulo-4
Uso de-patrones-de-arquitectura-capitulo-4
 
Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
 
Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
 
Diagramas de clases
Diagramas de clasesDiagramas de clases
Diagramas de clases
 
6.modelado de los requerimientos escenarios y clases
6.modelado de los requerimientos  escenarios y clases6.modelado de los requerimientos  escenarios y clases
6.modelado de los requerimientos escenarios y clases
 
Diseño de patrones
Diseño de patronesDiseño de patrones
Diseño de patrones
 
ComputacionParaTodos / SocioTecnologico
ComputacionParaTodos / SocioTecnologicoComputacionParaTodos / SocioTecnologico
ComputacionParaTodos / SocioTecnologico
 
Poa Borrador
Poa BorradorPoa Borrador
Poa Borrador
 
Patrones GRASP de tipo de bajo acoplamiento
Patrones GRASP de  tipo de bajo acoplamientoPatrones GRASP de  tipo de bajo acoplamiento
Patrones GRASP de tipo de bajo acoplamiento
 
METODOS Y MODELOS POO
METODOS Y MODELOS POOMETODOS Y MODELOS POO
METODOS Y MODELOS POO
 
Semana13-AOO.ppt
Semana13-AOO.pptSemana13-AOO.ppt
Semana13-AOO.ppt
 
Patrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. graspPatrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. grasp
 
Analisis de requerimiento
Analisis de requerimientoAnalisis de requerimiento
Analisis de requerimiento
 
7.modelado de los requerimientos escenarios y clases
7.modelado de los requerimientos  escenarios y clases7.modelado de los requerimientos  escenarios y clases
7.modelado de los requerimientos escenarios y clases
 
Introducción poo
Introducción pooIntroducción poo
Introducción poo
 
Consejos para escribir buenos casos de uso
Consejos para escribir buenos casos de usoConsejos para escribir buenos casos de uso
Consejos para escribir buenos casos de uso
 
Uml
UmlUml
Uml
 
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso RealesUnidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
 
3 analisis y diseño resumen
3  analisis  y diseño resumen3  analisis  y diseño resumen
3 analisis y diseño resumen
 

Más de Juan Pablo Bustos Thames

Pruebas del Software
Pruebas del SoftwarePruebas del Software
Pruebas del Software
Juan Pablo Bustos Thames
 
Verificación y Validación del Diseño
Verificación y Validación del DiseñoVerificación y Validación del Diseño
Verificación y Validación del Diseño
Juan Pablo Bustos Thames
 
Diseño a Nivel de Componentes
Diseño a Nivel de ComponentesDiseño a Nivel de Componentes
Diseño a Nivel de Componentes
Juan Pablo Bustos Thames
 
El Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
El Proceso de Diseño de Interfaz del Usuario por Ian SommervilleEl Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
El Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
Juan Pablo Bustos Thames
 
El Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger PressmanEl Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger Pressman
Juan Pablo Bustos Thames
 
Reglas de Oro
Reglas de OroReglas de Oro
Diseño de interfaces
Diseño de interfacesDiseño de interfaces
Diseño de interfaces
Juan Pablo Bustos Thames
 
Modelos de dominio específicos
Modelos de dominio específicosModelos de dominio específicos
Modelos de dominio específicos
Juan Pablo Bustos Thames
 
Arquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidos
Juan Pablo Bustos Thames
 
Descomposición modular y estilos de control
Descomposición modular y estilos de controlDescomposición modular y estilos de control
Descomposición modular y estilos de control
Juan Pablo Bustos Thames
 
Diseño arquitectónico
Diseño arquitectónicoDiseño arquitectónico
Diseño arquitectónico
Juan Pablo Bustos Thames
 
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Juan Pablo Bustos Thames
 
Soluciones con objetos y patrones. visibilidad
Soluciones con objetos y patrones. visibilidadSoluciones con objetos y patrones. visibilidad
Soluciones con objetos y patrones. visibilidad
Juan Pablo Bustos Thames
 
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Juan Pablo Bustos Thames
 
Del análisis al diseño. diagramas de secuencia y contratos
Del análisis al diseño. diagramas de secuencia y contratosDel análisis al diseño. diagramas de secuencia y contratos
Del análisis al diseño. diagramas de secuencia y contratos
Juan Pablo Bustos Thames
 
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoPrimeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
Juan Pablo Bustos Thames
 
Análisis y diseño orientado a objetos
Análisis y diseño orientado a objetosAnálisis y diseño orientado a objetos
Análisis y diseño orientado a objetos
Juan Pablo Bustos Thames
 
Documentación del diseño
Documentación del diseñoDocumentación del diseño
Documentación del diseño
Juan Pablo Bustos Thames
 
Conceptos de diseño
Conceptos de diseñoConceptos de diseño
Conceptos de diseño
Juan Pablo Bustos Thames
 
Proceso de diseño
Proceso de diseñoProceso de diseño
Proceso de diseño
Juan Pablo Bustos Thames
 

Más de Juan Pablo Bustos Thames (20)

Pruebas del Software
Pruebas del SoftwarePruebas del Software
Pruebas del Software
 
Verificación y Validación del Diseño
Verificación y Validación del DiseñoVerificación y Validación del Diseño
Verificación y Validación del Diseño
 
Diseño a Nivel de Componentes
Diseño a Nivel de ComponentesDiseño a Nivel de Componentes
Diseño a Nivel de Componentes
 
El Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
El Proceso de Diseño de Interfaz del Usuario por Ian SommervilleEl Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
El Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
 
El Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger PressmanEl Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger Pressman
 
Reglas de Oro
Reglas de OroReglas de Oro
Reglas de Oro
 
Diseño de interfaces
Diseño de interfacesDiseño de interfaces
Diseño de interfaces
 
Modelos de dominio específicos
Modelos de dominio específicosModelos de dominio específicos
Modelos de dominio específicos
 
Arquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidos
 
Descomposición modular y estilos de control
Descomposición modular y estilos de controlDescomposición modular y estilos de control
Descomposición modular y estilos de control
 
Diseño arquitectónico
Diseño arquitectónicoDiseño arquitectónico
Diseño arquitectónico
 
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
 
Soluciones con objetos y patrones. visibilidad
Soluciones con objetos y patrones. visibilidadSoluciones con objetos y patrones. visibilidad
Soluciones con objetos y patrones. visibilidad
 
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
 
Del análisis al diseño. diagramas de secuencia y contratos
Del análisis al diseño. diagramas de secuencia y contratosDel análisis al diseño. diagramas de secuencia y contratos
Del análisis al diseño. diagramas de secuencia y contratos
 
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoPrimeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
 
Análisis y diseño orientado a objetos
Análisis y diseño orientado a objetosAnálisis y diseño orientado a objetos
Análisis y diseño orientado a objetos
 
Documentación del diseño
Documentación del diseñoDocumentación del diseño
Documentación del diseño
 
Conceptos de diseño
Conceptos de diseñoConceptos de diseño
Conceptos de diseño
 
Proceso de diseño
Proceso de diseñoProceso de diseño
Proceso de diseño
 

Modelos de dominio

  • 1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
  • 2. Contenidos de la Unidad 1 Introducción al Diseño f) Ingeniería del Software Asistida por Computadora. Clasificación de CASE   Sommerville. Sección 4.5   C. Proceso de Diseño Pressman. Cap. 13.2 Introducción.   I. Fases del diseño. Pressman. Sección 13.1 Sommerville. Sección 4.3.2 II. Diseño y calidad del software Pressman. 13.2.1 III. Principios y conceptos del diseño. Pressman. Sección 13.3 y 13.4 IV. Documentación del Diseño. Pressman, Sección 13.8 V. Análisis y Diseño Orientado a Objetos Sommerville, Cap.14 Larman, 2ª. Ed., Cap. 1.4 Pressman, Cap.21 y 22 VI. Modelos de dominio, Casos de Uso. (revisión) Larman, 1ª. Ed.,Cap. 9/11 Larman, 2a. Ed. Cap. 9/11 VII. Del Análisis al Diseño Larma n, 1ª. Ed. Cap. 15 Larman, 2ª. Ed. Cap. 14
  • 3. MODELO CONCEPTUAL O DE DOMINIO Craig Larman (Caps. 9/12) Ingeniería en Sistemas de Información DISEÑO DE SISTEMAS Una vez concluida la fase de planeación y elaboración y que los casos de uso fueron identificados, clasificados y programados. Se presenta entonces una transición muy importante: comienza la fase de construcción, donde se cumplen los ciclos del desarrollo iterativo.
  • 4. DISEÑO DE SISTEMAS Un Modelo Conceptual nos brinda los conceptos significativos para el dominio del problema. El lenguaje UML ofrece la notación en diagramas de estructuras estáticas para graficar los modelos conceptuales Es el “artefacto” más importante que se crea durante la etapa del AOO Modelo Conceptual => representa cosas del mundo real, no componentes del software Actividades y dependencias Crear un Modelo Conceptual para los Casos de Uso no puede hacerse si no se cuenta con los Casos y con Documentos que permitan identificar los Conceptos (Objetos). La creación no siempre es lineal, puede formularse en paralelo con el desarrollo de los Casos.
  • 5. DISEÑO DE SISTEMAS Modelo Conceptual El paso esencial en el enfoque orientado a objetos es descomponer el problema en conceptos u objetos individuales : las cosas que sabemos Modelo Conceptual => representación de conceptos en un dominio del problema En UML lo ilustramos con un conjunto de diagramas de estructura estática donde no se define ninguna operación Un modelo conceptual puede mostrar: Conceptos Asociaciones entre conceptos Atributos de conceptos MODELO CONCEPTUAL
  • 6. DISEÑO DE SISTEMAS Modelo Conceptual ¿Qué representa? Un modelo conceptual nos permite descomponer el dominio del problema en unidades comprensibles (conceptos), éste contribuye a esclarecer la terminología o nomenclatura del dominio. ¿Qué NO representa? Un modelo conceptual NO ES una descripción del diseño del software, como una clase en C++, una ventana, una base de datos, etc. Class alumno{ int Cod; char *Apellido; . . .
  • 7. DISEÑO DE SISTEMAS Modelo Conceptual En términos informales el concepto es una idea, cosa u objeto. En un lenguaje más formal, podemos considerarlo a partir de su simbolo, intensión y extensión. Símbolo : palabras o imágenes que representan un concepto Intensión : la definición del concepto Extensión : el conjunto de ejemplos a que se aplica el concepto. CONCEPTOS Un modelo conceptual muestra conceptos del mundo real venta fecha hora conceptos del mundo, no una clase de software
  • 8. DISEÑO DE SISTEMAS Modelo Conceptual Venta-1 Venta-3 Venta-2 venta fecha hora Símbolo del Concepto Intensión del Concepto “ Una venta representa el evento de una transacción de compra. Tiene fecha y hora.” Extensión del Concepto
  • 9. DISEÑO DE SISTEMAS Modelo Conceptual Estrategias para identificar los conceptos La meta es crear un modelo conceptual de conceptos interesantes o significativos del dominio en cuestión. Es mejor exagerar y especificar un modelo conceptual con muchos conceptos refinados que no especificarlo cabalmente. No piense que un modelo conceptual es más adecuado si tiene menos conceptos. Es frecuente omitir coceptos durante la fase inicial de identificación y descubrirlos más tarde, lo importante es incorporarlos. No excluya conceptos simplemente porque los requerimientos no indiquen una necesidad.
  • 10. Dos estrategias para identificar los conceptos: 1. Obtención de conceptos a partir de una lista de categorías de conceptos. 2. Obtención de conceptos a partir de la identificación de frases nominales. DISEÑO DE SISTEMAS Modelo Conceptual 1. La creación de un modelo conceptual comienza preparando una lista de conceptos idóneos.
  • 11. 2. Consiste en identificar las frases nominales en las descripciones textuales del dominio de un problema y considerarlas conceptos o atributos idóneos. DISEÑO DE SISTEMAS Modelo Conceptual Este método hay que utilizarlo con mucha prudencia; no es posible encontrar siempre mecánicamente correspondencias entre sustantivo y concepto, y además las palabras del lenguaje natural son ambiguas.     Acción del actor Respuesta del sistema 1. Este caso de uso comienza cuando el Socio llega a la caja con videos para alquilar .   2. El empleado ingresa el Nº de socio .     3. Visualiza el nombre del Socio. 5. Incorpora el título del video a la transacción .   4. El empleado registra el código de video . 6. ....
  • 12. DISEÑO DE SISTEMAS Modelo Conceptual Cómo construir un modelo conceptual 1. Liste los conceptos idóneos usando la Lista de categorías de conceptos y la identificación de la frase nominal relacionada con los requerimientos en cuestión. 2. Dibújelos en un modelo conceptual. 3. Incorpore las asociaciones necesarias para registrar las relaciones para las cuales debe reservar un espacio en la memoria. 4. Agregue los atributos necesarios para cumplir con las necesidades de información.
  • 13. DISEÑO DE SISTEMAS Modelo Conceptual La asignación de nombres y el modelado de las cosas: el cartógrafo La estrategia del cartógrafo se aplica a los mapas y a los modelos conceptuales:       Utilice los nombres existentes en el territorio.      Excluya las características irrelevantes.      No agregue cosas que no existen. El modelo conceptual es una especie de mapa de conceptos o cosas de un dominio. Este enfoque pone de relieve el papel analítico de un modelo conceptual y sugiere lo siguiente:        
  • 14. DISEÑO DE SISTEMAS Modelo Conceptual  Los cartógrafos se sirven de nombres del territorio – no cambian los nombres de las ciudades en sus mapas. En un modelo conceptual significa utilizar el vocabulario del dominio cuando se asignan nombres a los conceptos y a los atributos .    Un cartógrafo elimina cosas en el mapa en caso de que no las juzgue pertinentes para su propósito. De modo análogo, un modelo conceptual puede excluir en el dominio del problema los conceptos que no se relacionen con los requerimientos. Por ejemplo, podemos omitir BolsadePapel (del modelo conceptual) por no tener una función importante u obvia.     Un cartógrafo no muestra cosas que no existen. En forma parecida, el modelo conceptual ha de excluir las cosas que no se encuentren en el dominio del problema en cuestión.
  • 15. DISEÑO DE SISTEMAS Modelo Conceptual Un Error Frecuente al identificar Conceptos Tal vez el error más frecuente cuando se crea un modelo conceptual es el de representar algo como atributo, cuando debió haber sido un concepto. Una regla práctica para no caer en él es:  Si en el mundo real no consideramos algún concepto X como número o texto, probablemente X sea un concepto y no un atributo.   Por ejemplo, el caso del dominio de las reservaciones en líneas aéreas. ¿Debería “ Destino” ser un atributo de “ Vuelo” o ser un concepto aparte llamado “ Aeropuerto” ?
  • 16. DISEÑO DE SISTEMAS Modelo Conceptual En el mundo real, un aeropuerto de destino no se considera número ni texto: es una cosa masiva que ocupa espacio. Por tanto, Aeropuerto debería ser un concepto . En caso de duda, convierta el atributo en un concepto independiente. Vuelo Destino Vuelo Aeropuerto Nombre ¿o ...?
  • 17. DISEÑO DE SISTEMAS Modelo Conceptual Especificación o descripción de conceptos Necesidad de las especificaciones. La descripción o especificación de objetos se relaciona con aquella cosa que describen. En un modelo conceptual, se acostumbra a estipular que una Especificación X describe una X. Por ejemplo: una EspecificaciondeProducto no representa un Elemento, sino una descripción acerca de ellos. La necesidad de especificar los conceptos es frecuente en los dominios de ventas, productos y elaboración, a donde se requiere una descripción de lo manufacturado que se distingue de la cosa manufacturada.
  • 18. DISEÑO DE SISTEMAS Modelo Conceptual Especificaciones de otras cosas. El signo “*” indica multiplicidad de “muchos”. Indica que una “ EspecificaciondeProducto” puede describir muchos Productos . Producto descripcion precio numero de serie CUP EspecificaciondeProducto descripcion precio CUP Producto numero de serie 1 * Describe Mal Bien
  • 19. DISEÑO DE SISTEMAS Modelo Conceptual ¿Cuando se requiere especificar los conceptos? Incorpore una especificación o descripción de conceptos cuando: L a eliminación de las instancias de las cosas que se describen da por resultado una pérdida de información que debe conservarse. Reduce información redundante o duplicada.
  • 20. DISEÑO DE SISTEMAS Modelo Conceptual AGREGACIÓN DE LAS ASOCIACIONES Asociaciones:   La asociación es una relación entre dos conceptos que indica alguna conexión significativa e interesante entre ellos. 1 Caja Venta Registra asociación *
  • 21. DISEÑO DE SISTEMAS Modelo Conceptual Criterios de las asociaciones útiles Las asociaciones “significativas” o “interesantes” son las que deben preservarse durante algún tiempo (milisegundos o años). En otras palabras, cuando entre los objetos hay que tener algún recuerdo sobre una relación; por ejemplo, se debe recordar cuáles instancias de VentasLineadeProducto están asociadas a la instancia Venta , porque de lo contrario no sería posible reconstruir la venta, imprimir el recibo ni calcular el total de la venta.
  • 22. DISEÑO DE SISTEMAS Modelo Conceptual Examine la conveniencia de incluir las siguientes asociaciones en un modelo conceptual:         L as asociaciones en que el conocimiento de la relación ha de ser preservado durante algún tiempo (asociaciones que “deben conocerse”).          Las asociaciones provenientes de la Lista de asociaciones comunes . De lo contrario, no es necesario recordar una relación entre una Venta Actual y un Gerente , pues los requerimientos no indican que haga falta ese tipo de relación. Tal vez no sea incorrecto mostrar esta relación, pero no es útil dentro del contexto de nuestros requerimientos.
  • 23. DISEÑO DE SISTEMAS Modelo Conceptual Notación de las asociaciones en UML Una asociación se representa como una línea entre los conceptos con el nombre de la asociación. Esta es intrínsecamente bidireccional, o sea es posible un nexo lógico entre los objetos de un tipo y los del otro. Este vínculo es totalmente abstracto ; no es una afirmación sobre las conexiones entre las entidades del software. 1 Caja Venta Registra asociación * -flecha de dirección de la lectura -sin otro significado -a menudo se excluye multiplicidad
  • 24. DISEÑO DE SISTEMAS Modelo Conceptual Los extremos de una asociación pueden contener una expresión de multiplicidad que indique la relación numérica entre las instancias de los conceptos. Una flecha opcional de la dirección de lectura ( o “flecha de la dirección del nombre” ) indica la dirección en que debe leerse el nombre de la asociación; no denota la dirección de visibilidad o de navegación. En su ausencia, la asociación se lee de izquierda a derecha o de arriba hacia abajo. La flecha de dirección de la lectura no tiene un valor semántico; tan solo es una ayuda para leer el diagrama.
  • 25. DISEÑO DE SISTEMAS Modelo Conceptual Identificación de las asociaciones: Lista de asociaciones comunes Comience a agregar las asociaciones utilizando la lista anexa. Contiene categorías comunes que normalmente vale la pena incluir. Los ejemplos tomados de los dominios de la Tienda y de la reservación de las líneas aéreas. Categoría Ejemplos A es una parte física de B Caja – TPDV Ala – Avion A es una parte lógica de B VentasLineadeProducto – Venta TramodeVuelo – RutadeVuelo A está físicamente contenido en B TPDV – Tienda, Producto – Estante Pasajero – Avion A está contenido lógicamente en B DescripciondeProducto – Catalogo Vuelo – Programa de Vuelo ... ...
  • 26. DISEÑO DE SISTEMAS Modelo Conceptual Asociaciones de alta prioridad Son aquellas que siempre conviene incluir en un modelo conceptual:          A es una parte física o lógica de B.          A está física o lógicamente contenido en B.          A está registrado en B.
  • 27. DISEÑO DE SISTEMAS Modelo Conceptual ¿Qué grado de detalle deberían tener las asociaciones? Las asociaciones son importantes, pero una falla habitual al crear modelos conceptuales es el excesivo tiempo que, durante la investigación, se dedica al intento de descubrirlas. Es indispensable convencerse de lo siguiente: Es mucho más importante identificar los conceptos que las asociaciones. El tiempo consagrado a la creación del modelo conceptual debería destinarse a identificar los conceptos, no las asociaciones.
  • 28. DISEÑO DE SISTEMAS Modelo Conceptual Directrices de las asociaciones Concentrarse en las asociaciones en que el conocimiento de la relación ha de preservarse durante algún tiempo (asociaciones que “es necesario conocer”).  Es más importante identificar los conceptos que las asociaciones.  Muchas asociaciones tienden a confundir el modelo conceptual en vez de aclararlo. A veces se requiere mucho tiempo para descubrirlas, y los beneficios son escasos.  No incluir las asociaciones redundantes ni las derivables.
  • 29. DISEÑO DE SISTEMAS Modelo Conceptual Multiplicidad La multiplicidad define cuántas instancias de un tipo A pueden asociarse a una instancia de tipo B en determinado momento. Por ejemplo, una instancia individual de una Tienda puede asociarse a “muchas” instancias de Producto . 1 Tienda Producto Almacena * multiplicidad
  • 30. DISEÑO DE SISTEMAS Modelo Conceptual Asignación de nombres a las asociaciones Los nombres de las asociaciones comienzan con una mayúscula. Una frase nominal debe construirse con guiones. 1 Caja Venta Registra 1..* Tienda Pago 1 Pagada-por 1 1..* 1 Contiene
  • 31. DISEÑO DE SISTEMAS Modelo Conceptual Asociaciones múltiples entre dos tipos Dos tipos pueden tener varias asociaciones entre ellos; esto sucede con frecuencia. No hay un ejemplo sobresaliente en nuestro sistema TPDV, pero en el dominio de la línea aérea encontramos uno en las relaciones entre Vuelo y Aeropuerto . Las asociaciones volar – hacia y volar – de son relaciones netamente diferentes que han de mostrarse por separado. Vuelo Aeropuerto 0..1 * Vuela-a * 1 Vuela-de
  • 32. DISEÑO DE SISTEMAS Modelo Conceptual Atributos => Valor Lógico de un dato de un objeto. Clave para su inclusión en un Modelo Conceptual:   Aquellos en que los requerimientos (Casos de Uso) indican o conllevan la necesidad de recordar información . (El concepto “Venta” requiere, por ejemplo, los atributos de: fecha y hora) AGREGACIÓN DE LOS ATRIBUTOS
  • 33. DISEÑO DE SISTEMAS Modelo Conceptual Notación de los atributos en UML Los atributos se muestran en la segunda sección de la sección de los Conceptos. Indicar su tipo es opcional. Venta Fecha Hora Atributos
  • 34. DISEÑO DE SISTEMAS Modelo Conceptual Conserve simples los atributos Los tipos más simples de atributos son los que, en la práctica, suelen considerarse los tipos primitivos de datos. Por lo general el tipo de un atributo no debería ser un concepto complejo del dominio (al revés que los “conceptos”). En un modelo conceptual es preferible que los atributos sean atributos simples o valores puros de datos.   Entre los tipos comunes de atributos simples más frecuentes se cuentan: Booleano, Fecha, Número, Cadena, Hora, Dirección, Color, Geometría, Número telefónico, DNI, CUP, Código Postal, ISBN, Nombre y Apellido, etc.
  • 35. DISEÑO DE SISTEMAS Modelo Conceptual Cajero nombre CAJAactual Atributos Mal Cajero nombre Caja numero Usa 1 1 Bien
  • 36. DISEÑO DE SISTEMAS Modelo Conceptual Relacione conceptos con una asociación, no con un atributo Vuelo destino Aeropuerto 1 1 Vuela-a Vuelo Mal Bien Destino es un concepto complejo
  • 37. DISEÑO DE SISTEMAS Modelo Conceptual Ningún atributo debe incluirse como clave foránea Los atributos no se usan para relacionar conceptos distintos en el Modelo Conceptual. La violación más frecuente de esta regla consiste en agregar un tipo de atributo de clave foránea, lo cual suele hacerse con los diseños de bases de datos relacionales, a fin de asociar dos entidades. Cajero nombre NumeroTPDVactual Un atributo “simple”, pero que se usa como clave extraña para relacionarlo con otro objeto Mal Cajero nombre TPDV numero Usa 1 1 Bien
  • 38. DISEÑO DE SISTEMAS Modelo Conceptual Glosario El glosario o diccionario modelo incluye y define todos los términos que requieren explicación para mejorar la comunicación y aminorar el riesgo de malos entendidos. El glosario se crea originalmente durante la fase de planeación y Elaboración conforme vayan generándose los términos; después va perfeccionándose continuamente en cada ciclo de desarrollo al aparecer nuevos vocablos. En cuanto al formato del glosario no existe uno oficial. Durante nuestro diseño adoptaremos el siguiente:
  • 39. DISEÑO DE SISTEMAS Modelo Conceptual Término Categoría Comentarios Comprar Productos Caso de Uso Descripción del proceso de un cliente que compra productos en una tienda. Producto Tipo/Concepto Un producto que la Tienda tiene disponible para la venta. Pago.monto: Dinero Atributo El monto que el cliente abona para cancelar una Venta. ... ... ...