Ingeniería del Software I



Documentos relacionados
MODELADO DEL DOMINIO (MODELO CONCEPTUAL)

2.4 Modelado conceptual

UNIDAD Nº 4. Construcción de un Modelo Conceptual

El Modelo Conceptual

Unidad II. Metodología para resolver problemas aplicando la POO. Parte 3 Análisis del Problema Modelo del Dominio

M III ABSTRACCIÓN Y CLASIFICACIÓN

Capítulo VI. Diagramas de Entidad Relación

Diagrama de Clases. Diagrama de Clases

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

Metodología Orientada a Objetos Clave Maestría en Sistemas Computacionales

Patrones de software y refactorización de código

CLASE 6: MODELO CONCEPTUAL/ MODELO DE DOMINIO. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette Carolina Martínez


3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

Unidad 1. Fundamentos en Gestión de Riesgos

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

Modelo Entidad-Relación

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

Capítulos 2 y 5: Modelación con UML y Modelo Objeto

Elementos requeridos para crearlos (ejemplo: el compilador)

FICHEROS Y BASES DE DATOS (E44) 3º INGENIERÍA EN INFORMÁTICA. Tema 9. Reglas de Integridad

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

DIAGRAMA DE CLASES EN UML

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas.

DIRECTRIZ DE ICC/ESOMAR SOBRE MANTENIMIENTO DE LAS DISTINCIONES ENTRE LA INVESTIGACIÓN DE MERCADO Y EL MARKETING DIRECTO

2.2 Política y objetivos de prevención de riesgos laborales de una organización

Análisis de Sistemas. M.Sc. Lic. Aidee Vargas C. C. octubre 2007

INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones

Capitulo III. Diseño del Sistema.

TEMA 8: DIAGRAMA DE CLASE EN UML

Módulo 7: Los activos de Seguridad de la Información

FORMAS DE ORGANIZAR LA INFORMACIÓN. Esquema circular (algorítmico)

Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech

Notación UML para modelado Orientado a Objetos

Gestión de Requisitos ULPGC

Figure 7-1: Phase A: Architecture Vision

Fundamentos del diseño 3ª edición (2002)

FICHEROS Y BASES DE DATOS (E44) 3º INGENIERÍA EN INFORMÁTICA. Tema 8. Elementos Básicos

PROCEDIMIENTO ESPECÍFICO. Código G Edición 0

Diagramas de clases de UML

Unidad 5. Modelo de objetos del dominio del problema. Trimestre 10-I. Universidad Autonomía Metropolitana. Unidad 5

Introducción. Metadatos

INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS

Ventajas del software del SIGOB para las instituciones

BPMN Business Process Modeling Notation

Formularios. Formularios Diapositiva 1

Ingeniería de Software I

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos:

GUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000

Introducción. Componentes de un SI. Sistema de Información:

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Por dónde empiezo a documentar? Ing. Fedra E. González

Registro (record): es la unidad básica de acceso y manipulación de la base de datos.

Informe final de evaluación del seguimiento de la implantación de títulos oficiales

CAPITULO V PLANIFICACIÓN Y GESTIÓN DEL PROYECTO

FAQ de Cuestiones Técnicas Modelo de monitorización

Gestión de la Configuración

Figure 9-1: Phase C: Information Systems Architectures

Programación Avanzada. Análisis Modelado del Dominio

PROCEDIMIENTO ELABORACIÓN DE DOCUMENTOS

Cuándo se pueden utilizar estos sistemas?

UML, ejemplo sencillo sobre Modelado de un Proyecto

LiLa Portal Guía para profesores

DCU Diagramas de casos de uso

COMUNICADO Nro /11/2010. Ref.: Tarjetas de crédito. Tasas y costos promedio de las tarjetas de crédito a agosto de Tarjetas de Crédito

COMUNICADO Nro /07/2008. Ref.: Costos promedio de paquetes de productos. Paquetes de productos 1

Aspectos a considerar en la adopción por primera vez en la transición a las NIIF para PYMES

DE VIDA PARA EL DESARROLLO DE SISTEMAS

Bolsa POLÍTICA DE EJECUCIÓN DE ÓRDENES BANESTO BOLSA

PERFIL DEL PUESTO POR COMPETENCIAS Sepa cómo construirlo y evitar bajos desempeños posteriores

Patrones de Diseño Orientados a Objetos 2 Parte

AUTORA: SUSANA REYES BENÍTEZ DNI: C LA IMPORTANCIA DE LOS RECUROS HUMANOS. Introducción:

Diagramas de Clases ~ 1 ~ Ing. Fabián Silva Alvarado

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007

Adelacu Ltda. Fono Graballo+ Agosto de Graballo+ - Descripción funcional - 1 -

GUÍA METODOLÓGICA PARA LA FORMACIÓN CON E-LEARNING DIRIGIDA A COLECTIVOS SIN ALTA CUALIFICACIÓN CAPÍTULO 4. Dirección Técnica:

Las Relaciones Públicas en el Marketing social

Implementando un ERP La Gestión del Cambio

Introducción al UML. Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación

Calidad Escuela de Ingeniería de Sistemas y Computación Desarrol o de Software II Agosto Diciembre 2007

e-commerce, es hacer comercio utilizando la red. Es el acto de comprar y vender en y por medio de la red.

UNIVERSIDAD NACIONAL DE TRUJILLO ESCUELA DE INFORMATICA BASE DE DATOS

Un primer acercamiento a la CMDB.

SIIGO Pyme. Informes de Saldos y Movimientos de Inventarios. Cartilla I

Configuración de Software

Diseño orientado a los objetos

Base de Datos. Profesor: José Miguel Rubio L. P. UNIVERSIDAD CATÓLICA DE VALPARAÍSO FACULTAD DE INGENIERÍA ESCUELA DE ING.

Cómo definir un Catálogo de Servicios de TI

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases

INGENIERÍA DEL SOFTWARE I. Univ. Cantabria Fac. de Ciencias. Especificación de Requisitos. Práctica 2

El objetivo principal del presente curso es proporcionar a sus alumnos los conocimientos y las herramientas básicas para la gestión de proyectos.

Gestión de proyectos

comunidades de práctica

IAP TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO)

Hacer Realidad BPM en su Organización ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

DISEÑO DE FUNCIONES (TRATAMIENTOS)

Indicadores del Sector Público. marzo de 2011

Transcripción:

- 1 - Ingeniería del Software I Introducción al Modelo Conceptual 2do. Cuatrimestre 2005 INTRODUCCIÓN... 2 CLASES CONCEPTUALES... 3 ESTRATEGIAS PARA IDENTIFICAR CLASES CONCEPTUALES... 3 Utilizar lista de categorías de clases conceptuales... 3 Identificar frases nominales (sustantivos o frases)... 4 ASOCIACIONES... 5 ESTRATEGIAS PARA IDENTIFICAR ASOCIACIONES... 5 MULTIPLICIDAD... 6 ROLES... 7 ATRIBUTOS... 8 CLASES DE ASOCIACIÓN... 9 HERENCIA... 10 LIMITACIONES... 12 NOTACIÓN... 13

- 2 - Introducción Un modelo conceptual tiene como objetivo identificar y explicar los conceptos significativos en un dominio de problema, identificando los atributos y las asociaciones existentes entre ellos. Puede ser visto, también como una representación de las cosas, entidades, ideas, conceptos u objetos del mundo real o dominio de interés. Es importante diferenciar que dichas entidades u objetos no son componentes de software. También podría ser considerado como un diccionario visual de abstracciones, conceptos, vocabulario e información del dominio de problema. No es absolutamente correcto o incorrecto, su intención en ser útil sirviendo como una herramienta de comunicación. Aclaraciones: Modelo conceptual, modelo de objetos del dominio y modelo de los objetos de análisis son distintos nombres que suelen usarse indistintamente para referirse a este modelo. Clase conceptual, concepto, o entidad también suelen usarse indistintamente.

- 3 - Clases conceptuales El proceso de desarrollo de software debe incluir en sus primeras etapas la construcción del modelo conceptual. Dicha tarea suele encararse como parte del análisis de requerimientos: la identificación de requerimientos debe acompañarse con la identificación de las entidades o conceptos involucrados en los mismos. De igual manera, la identificación de entidades puede contribuir con la identificación de requerimientos. Estrategias para identificar clases conceptuales - Utilizar lista de categorías de entidades. - Identificar frases nominales (sustantivos o frases). Utilizar lista de categorías de clases conceptuales Categoría Objetos tangibles o físicos Especificaciones, diseños o descripciones de las cosas Lugares Transacciones Líneas de la transacción Roles de la gente Contenedores de otras cosas Contenidos Otros sistemas informáticos o electromecánicos externos al sistema Conceptos abstractos Organizaciones Hechos Procesos (normalmente no se representan como conceptos, pero podría ocurrir) Reglas y políticas Catálogos Registros de finanzas, trabajo, contratos, cuestiones legales Instrumentos y servicios financieros Manuales, documentos, artículos de referencia, libros Ejemplo Casa, Avión PlanoDeLaCasa, EspecificaciónDelProducto, DescripciónDelVuelo Tiendo, Aula Venta, Pago, Reserva, Tranferencia LíneaDeVenta Cajero, Piloto, Jefe Aula, Ciolectivo, Lata, Mochila Pasajero, Artículo, ÚtilEscolar SistemaDeAutorización, ControlDeTra ficoaéreo Amor, Celos, Ansia, Acrofobia DepartamentoDeVentas, CompañiaAérea Reunión, Vuelo, Aterrizaje, Venta, Pago VentaDeUnProducto, ReservaDeUnAsiento (no confundir con trasacciones) PolíticaDeReintegro, PolíticaDeCancelación CatálogoDeProductos Recibo, Remito, Factura, ContratoDeEmpleo, Expediente LíneaDeCrédito, Stock ManualDeReparaciones, ListaDeCambios

- 4 - Relaciones Amistad, Parentesco (podría estar en conceptos abstractos pero es bueno destacarlo ya que las relaciones no suelen ser consideradas al modelar) Identificar frases nominales (sustantivos o frases) Se intenta identificar sustantivos o frases nominales en el vocabulario y descripciones del dominio del problema. Esta técnica práctica no puede ser aplicada mecánicamente sino que hay que usar el sentido común y capturar las abstracciones adecuadas puesto que el lenguaje natural es ambiguo y los conceptos relevantes no siempre se encuentran de manera explícita. Por ejemplo, si se quisiera modelar distintos torneos de fútbol, algunas entidades involucradas serían:

- 5 - Asociaciones Una asociación es una relación entre dos conceptos que indica alguna conexión significativa entre ellos. Las asociaciones útiles a determinar, suelen incluir el conocimiento de una relación que ha de preservarse por algún tiempo: puede tratarse de milisegundos o de años (según el contexto). Por ejemplo, cómo reflejar que un equipo está compuesto por jugadores, qué uno de ellos es el capitán, qué los equipos juegan partidos o que los torneos tienen varios partidos programados? Los nombres de las asociaciones deben ser lo más claros posibles, y deben permitir leer y entender fácilmente las relaciones entre conceptos. Por lo general, se asume un orden en la lectura: de izquierda a derecha y de arriba hacia abajo. No obstante, es posible indicar explícitamente algún otro orden. Estrategias para identificar asociaciones La siguiente lista de preguntas puede resultar útil para identificar asociaciones entre distintas clases conceptuales. A es una parte física o lógica de B A está lógica o físicamente contenido en B A es una descripción de B A es un elemento de línea (o renglón) en una transacción o reporte B A se conoce/introduce/registra/presenta/captura en B A es miembro de B A es una unidad organizacional de B

- 6 - A usa o dirige a B A se comunica con B A se relaciona con una transacción B A es una transacción relacionada con otra transacción B A es propiedad de B Multiplicidad La multiplicidad define cuántas instancias de un tipo A pueden asociarse a una instancia del tipo B en determinado momento. Las expresiones de multiplicidad son las siguientes: - 1 Exactamente uno - 0..1 Cero o uno - 0..* Cero o muchos - 1..* Al menos uno: uno o muchos Por ejemplo, continuando con el ejemplo: cómo modelar los siguientes aspectos? Un jugador puede jugar en sólo un equipo o en ninguno (si es que está libre). Todo equipo tiene un capitán. Los partidos los juegan dos equipos: uno será local y otro visitante. Todos los equipos tienen asegurados al menos un partido como visitante y al menos un partido como local. Cualquier torneo tiene al menos un partido programado. Todo partido se realiza en el contexto de un único torneo.

- 7 - Roles Dada una asociación entre dos entidades, decimos que cada entidad representa un rol en dicha asociación. Muchas veces, según el punto de vista de cada entidad, es posible nombrar a la asociación de manera diferente. Por ejemplo, así como un jugador juega en un equipo, también podríamos decir que un equipo está conformado por varios jugadores. En estos casos resulta útil darle un nombre a cada rol.

- 8 - Atributos Las entidades suelen poseer características propias que en sí mismas no constituyen otros conceptos, en estos casos decimos que son atributos. Los posibles valores que un atributo podrá poseer en algún momento, pertenecen a un dominio en particular. Por ejemplo, un jugador tiene un nombre y una fecha de nacimiento. El dominio del atributo no debe pensarse como el tipo de datos del mismo. Cuando se elabora el modelo conceptual no se está diseñando ni programando, simplemente se está creando una abstracción, un modelo como parte de la especificación de un problema.

- 9 - Clases de Asociación Algunas veces se quiere modelar información que no es propia de una entidad sino que sólo tiene sentido en el marco de una asociación entre varias entidades. Por ejemplo, los jugadores de fútbol se incorporan a sus equipos firmando un contrato en el cual se aclara que número de camiseta usará y cuanto cuál será su sueldo. Desde algún punto de vista, dicho contrato provee más información a la asociación existente entre un jugador y su equipo, por eso es que puede modelarse como una clase de asociación.

- 10 - Herencia Existe una asociación entre entidades que merece un tratamiento a parte: la relación de es un. Muchas veces una entidad, además de representar algo en particular, es al mismo tiempo algo más general. Por ejemplo, existen vehículos aéreos y vehículos terrestres. En ambos casos, más allá de ser terrestres o aéreos, son vehículos. A su vez existen vehículos aéreos que son helicópteros y otros que son aviones. También es posible modelar este tipo de situaciones. En todos los casos, depende de la interpretación que se esté haciendo, es posible obtener distintas jerarquías. Por ejemplo, desde el punto de vista de quién o como se use, un vehículo aéreo puede ser comercial o militar. Ahora bien, según de cómo sea estructuralmente, puede ser un helicóptero o un avión.

- 11 - Estos diagramas se deben interpretar de la siguiente manera: un avión posee todos los atributos de un vehículo aéreo, y además puede poseer atributos propios. Por otro lado, cualquier asociación que termine en la clase Vehículo Aéreo, también pertenecerá a cualquier helicóptero, avión, vehículo aéreo comercial o vehículo aéreo militar. Sin embargo, una avocación que involucre a la clase avión, no tendrá nada que ver con el resto de los vehículos aéreos.

- 12 - Limitaciones Dado un problema es posible confeccionar muchos modelos conceptuales, no necesariamente consistentes entre sí. La elaboración del modelo conceptual es una tarea que requiere una interpretación de la realidad, y en dicha interpretación juega un rol importante la subjetividad de quien realiza la tarea. Analizando el siguiente diagrama: Pueden desprenderse las siguientes preguntas: Qué garantías hay de que el jugador capitán de un equipo, juegue en ese equipo? Qué garantías hay de que un equipo no juegue el mismo partido como visitante y local a la vez? Qué garantías hay de que en un equipo todos los jugadores tengan un número de camiseta distinto? Qué garantías hay de que no haya dos equipos con el mismo color de camiseta? En todos los casos, la respuesta es ninguna. El modelo conceptual es una técnica que permite modelar algunos aspectos relacionados con las entidades y sus relaciones, pero no todos. En estos casos, será útil utilizar otras técnicas (por ejemplo OCL) con el fin de cubrir los aspectos ambiguos o no especificados.

- 13 - Notación Pueden utilizarse distintas notaciones para representar un modelo conceptual. En la cátedra utilizaremos el Diagrama de Clases de UML para tal fin. La notación del diagrama de clases puede utilizarse durante distintas etapas del proceso de software para representar distintas cosas: por ejemplo, en una primera etapa lo utilizaremos para confeccionar el modelo conceptual y más adelante, lo utilizaremos para confeccionar el diseño detallado, en el cual se diseñan las clases (componentes de software) que finalmente se implementarán. En ambos casos, las diferencias son más semánticas que sintácticas. Por tal motivo, para remarcar aún más la diferencia, utilizaremos el siguiente estereotipo al notar las clases conceptuales. La sintaxis provista por el diagrama de clases, también permite distinguir distintos tipos de asociaciones, como la composición y agregación.