Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos

Save this PDF as:
 WORD  PNG  TXT  JPG

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos"

Transcripción

1 3.3 EL MÉTODO DE BOOCH Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura de todos los detalles de un sistema de software complejo es necesario vistas múltiples. La Figura # 44 muestra los diferentes modelos que se han considerado relevantes, en el desarrollo de un proyecto orientado a objetos. Modelo Dinámico Modelo Estático Modelo Lógico Modelo Físico Estructura de clases Estructura de Objetos Arquitectura de módulos Arquitectura de procesos Figura # 44 Modelos del desarrollo Orientado.. El hecho de que esta notación sea detallada no significa que se deben utilizar todos sus aspectos en la totalidad de las ocasiones, de hecho, un subconjunto de ella es suficiente para expresar la semántica de un gran porcentaje de problemas de análisis y diseño. La notación utilizada es independiente del lenguaje seleccionado, es necesario tener en cuenta que algunos elementos de la notación no tienen equivalencia en determinados lenguajes de programación, por lo que se deben evitar para la implementación Modelos y vistas. Son necesarias dos dimensiones para especificar la estructura y comportamiento de un sistema orientado a objetos: Dimensión uno: Física / Lógica. Dimensión dos: Estática / Dinámica. Para cada dimensión se definen una serie de diagramas que denotan una vista de los modelos del sistema, éstos reflejan "toda la verdad" sobre sus clases, relaciones y otras entidades, y cada diagrama representa una proyección de estos modelos. En el estado estable, todos estos diagramas deben ser consistentes con el modelo y también consistentes entre ellos mismos. Modelos lógicos contra modelos físicos. Modelo lógico: Describe la existencia y significado de las abstracciones principales y los mecanismos que forman el espacio del problema o para definir la arquitectura del sistema. Modelo físico: Describe la composición concreta en cuanto a hardware y software del contexto o implantación del sistema. 62

2 Modelos estáticos contra modelos dinámicos. Modelos estáticos: Están formados por los diagramas de: Diagramas de clases: Muestra la existencia de clases y sus relaciones, en la visión lógica de un sistema, utilizados en la etapa de análisis. Diagramas de objetos: Muestran la existencia de objetos y sus relaciones en la etapa de diseño lógico de un sistema. Diagramas de módulos: Muestran la asignación de clases y objetos a módulos en el diseño físico de un sistema. Diagramas de procesos: Muestran la asignación de procesos a procesadores en el diseño físico de un sistema. Modelos dinámicos: La semántica dinámica de un problema se expresa mediante los siguientes diagramas: Diagrama de transición de estados: Muestra el comportamiento de cada instancia de una clase, los eventos que provocan una transición de un estado a otro y las acciones que resultan de este cambio de estado, por lo que, cada clase puede contar con este tipo de diagrama. Diagramas de interacción: Muestra el orden temporal en que se suceden los mensajes en un conjunto de objetos que representan un escenario. Están en el mismo contexto que los diagramas de objetos Representación gráfica. Diagramas de Clases Un diagrama de clases es utilizado para mostrar la existencia de clases y sus relaciones en la visión lógica de un sistema. Los dos elementos esenciales de un diagrama de clases son: las clases y sus relaciones básicas. Clases: La figura # 45 muestra el icono que se utiliza para representar una clase en un diagrama de clases. En ciertos diagramas de clases, es útil exponer algunos de los atributos y operaciones asociados con una clase: Nombre Atributos Operaciones( ) a) Icono de una clase Figura # 45 Atributos: denotan una parte de un objeto agregado, durante el diseño expresan una propiedad singular de la clase.! A Nombre del atributo solamente.! :C Clase del atributo solamente.! A:C Nombre y clase del atributo. 63

3 Operaciones: denotan algún servicio proporcionado por la clase, se distinguen de los atributos añadiendo paréntesis.! N() Nombre de la operación solamente.! R N(Argumento) Clase de retorno de la operación, nombre y parámetros formales (si los hay). Relaciones de clase: representan una colaboración con otras clases de diversas maneras. Las conexiones esenciales entre clases incluyen las siguientes relaciones: Asociación Herencia Posesión Uso Figura # 46 Iconos de relaciones Asociación: conecta dos clases y denota una conexión semántica, se etiquetan con expresiones sustantivas, denotando la naturaleza de la relación. Herencia: denota una relación de generalización / especialización (una relación <<es un>>), y aparece como una asociación con una cabeza de flecha. La flecha apunta a la superclase, y el extremo opuesto de la asociación designa la subclase. La subclase hereda la estructura y comportamiento de su superclase. Las relaciones de herencia no pueden llevar indicaciones de cardinalidad. Posesión: denota una relación todo / parte (relación <<tiene un>> o agregación), aparece como una asociación con un círculo relleno en el extremo que señala al agregado, la clase que esta en el otro extremo denota la parte cuyas instancias están contenidas por el objeto agregado. Utilización: denota una relación cliente / servidor y aparece como una asociación con una circunferencia en el extremo que denota al cliente. En esta relación de alguna forma el cliente depende del servidor para que éste le proporcione determinados servicios. Pildora Come Pacman 50 Come Fruta La multiplicidad o cardinalidad: se aplica el adorno de la cardinalidad al extremo de destino de una asociación y denota el número de enlaces entre cada instancia de la clase origen y las instancias de la clase destino. Exactamente uno. N Número ilimitado. Figura # 47 Diagrama de clases 64

4 0..N Cero o más...n Uno o más. 0.. Cero o uno Rango específico...3, 7 Rango específico o número exacto. Tipos de clases: A F Abstracta Amiga S V Estática Virtual Figura # 48 Abstracta: es aquella clase la cual no puede tener instancias. Para representarla se señala el icono de clase con la letra (A), situada en el interior de un triangulo, en cualquier punto del interior del icono de clase. Estática: la designación de un objeto o función miembro de una clase (S). Virtual: la designación de una clase base compartida en una trama de herencias con forma de rombo(v). Amiga: la designación de una clase que concede a otra derechos de acceso a sus partes no publicas (F). Pacman Posición : entero Come Laberinto 4 F 4 F Fantasma n Come 4 Pildora_m Pildora A S n Pildora_N n Figura # 49 Ejemplo de Propiedades 65

5 Diagramas de Objetos. Un diagrama de objetos se utiliza para mostrar la existencia de objetos y sus relaciones en el diseño lógico de un sistema. Los dos elementos esenciales de un diagrama de objetos son los objetos y sus relaciones. Objetos: La Figura # 50 muestra el icono que se usa para representar un objeto en un diagrama de objetos. Al igual que en el diagrama de clases, también se pueden especificar algunos atributos del objeto. Nombre Atributo Figura # 50 Icono de objeto. Relaciones entre objetos: los objetos interaccionan a través de sus enlaces con otros objetos, representados por el icono de la Figura # 5, un enlace es una instancia de una asociación, al igual que un objeto es una instancia de una clase. Mensaje(parámetros) Objeto/valor Rol [Llave] Restricción Figura # 5 Relaciones entre objeto. Mensaje: la existencia de una asociación entre dos clases denota por tanto una vía de comunicación entre instancias de clases, por la que un objeto puede enviar mensajes a otro. Un objeto también puede enviarse un mensaje a sí mismo. Cualquier objeto que invoque la operación se conoce como cliente, cualquier objeto que suministre la operación se conoce como proveedor o servidor. Un enlace se puede adornar mediante una serie de mensajes. Cada mensaje consta de tres elementos. D Un símbolo de sincronización que denota la dirección de la invocación. M Una invocación de operación o despacho de evento. S Opcionalmente, un número de secuencia. La dirección del mensaje se indica mediante una línea dirigida que apunta al objeto servidor. La invocación de una operación es el tipo de mensaje más común. La sintaxis es la siguiente: N() Solamente el nombre de la operación. R N(argumentos) Objeto de retorno, nombre y argumentos actuales de la operación. 66

6 Papeles, claves y restricciones: denotan el propósito o carácter de la relación que asocia una clase con otra. Es útil declarar este papel en el enlace correspondiente entre dos objetos, ya que ayuda a explicar porque un objeto opera sobre otro. Flujo de datos: los datos pueden fluir en la misma dirección que un mensaje o en dirección contraria. El mostrar explícitamente la dirección del flujo de datos ayuda a explicar la semántica de un escenario particular. Sincronización (para objetos activos). Objetos activos: son aquellos que incorporan su propio hilo de control. Simple: simple paso de mensajes secuencial. Sincronización: Espera hasta que el servidor acepta el mensaje. Contratiempo: Abandona el mensaje si el servidor no puede proporcionar el servicio de manera inmediata. Fuera de tiempo: Es igual al anterior, solo que en este caso se espera una cierta cantidad de tiempo Visibilidad. (valor / referencia negro/blanco) Sincronización: El servidor pone en la cola el mensaje y el cliente continua sin esperar respuesta. Figura # 52 Sincronización. G Global: El objeto proveedor es global al cliente. P Parámetro: El objeto proveedor es parametro de alguna operación del cliente. F Campo: El objeto servidor es una parte del cliente. L Local: Objeto declarado de forma local en el ámbito del diagrama. Figura # 53 Visibilidad 67

7 Pildora Posicion : entero = 50 Valor : entero = 5 Numero : entero = Pacman Come Posicion : entero = 2 Puntos : entero = 200 Vida : entero = 3 Velocidad : entero = 20 Come Fruta Posicion : entero = 00 Valor : entero = 5 Figura # 54 Diagrama de objetos. Diagramas de transición de estados. Un diagrama de transición de estados se utiliza para mostrar el espacio de estados de una clase determinada, los eventos que provocan una transición de un estado a otro y las acciones que resultan de ese cambio de estado. Puede representar una vista del modelo dinámico de una sola clase o de un sistema completo. Debido a que durante el análisis se utilizan para indicar el comportamiento dinámico del sistema. Estados: el estado de un objeto representa los resultados acumulados de su comportamiento. Todo estado debe de tener un nombre y este debe ser único dentro de la clase que lo contiene. Es también útil exponer las acciones asociadas a un estado. Transiciones entre estados: se le conoce como cambio de estado, un evento es algún suceso que puede causar un cambio en el estado de un objeto. Cada transición de estados conecta a dos estados, un estado puede tener una transición hacia si mismo. Acción: denota típicamente la invocación de un método, el disparo de otro evento, o el inicio o parada de una actividad. Evento: puede ser un nombre simbólico, una clase o el nombre de alguna operación. Un evento puede proporcionar operaciones que pueden recibir tales nombres y efectuar la acción adecuada. Transiciones de estado condicionales: en esta tipo de transición, esta será disparada automáticamente solo en el caso de que la expresión se evalué como cierta. El orden de evaluación en transición de estado condicionales es importante. En todo diagrama de transición de estados debe haber exactamente un estado de partida por defecto, que se designa escribiendo una transición sin etiqueta al estado desde un icono especial, que aparece como un circulo relleno. Es menos frecuente describir un estado de parada. 68

8 nombre acciones evento / acción a) icono de estado b) icono de transición de estado. Figura # 55 [ Fantasma come pacman ] / Pacman termina inicio entry: Camina Activo do: Come Pildora, Camina En Borde do: Espera Come Pildora_M do: Come Fantasma, incrementa velocidad Figura # 56 Diagrama de transición de estados. El diagrama de estados inicia cuando el Pacman camina, entra en un estado activo que tiene dos estados opcionales a donde puede irse. Si se topa en un borde entra en estado de espera y la otra opción es de comer Píldora-M en este estado puede comer fantasma e incrementar velocidad. El estado activo termina cuando un fantasma se come al Pacman. Diagramas de interacción. Es otra manera de representar el diagrama de objetos, tomando la mayoría de sus elementos esenciales de los diagramas de objeto. Con este tipo de diagramas es más fácil leer el paso de mensajes en orden relativo. 69

9 : Jugador : Pacman : Fruta : Pildora Mover Camina_ Camina_Fruta(Posicion) Come_ Decrementa(n Come_ El diagrama de interacción esta compuesto de 3 bloques y un actor que es el jugador. Inicia con el mensaje mover que va del actor hacia la clase Pacman. Después la clase Pacman se envía un mensaje a el mismo que es el de caminar. Seguido de la clase Fruta donde su auto-mensaje es de camina_fruta. Después tanto Píldora como Fruta le envía un mensaje a Pacman de come, es decir estas pueden ser comibles por el Pacman. Diagramas de módulos. Figura # 57 Diagrama de interacción. Se utiliza un diagrama de módulos para mostrar la asignación de clases y objetos a módulos en el diseño físico de un sistema. Un solo diagrama de módulos representa una vista de la estructura de módulos de un sistema. Los dos elementos esenciales de un diagrama de módulos son los módulos y sus dependencias. Programa principal :Denota un archivo que contiene la raíz del programa. c) Programa Principal Figura # 58 70

10 Especificación y cuerpo: Denotan archivos que contienen la declaración y la definición de las entidades. a) Especificación en "C" archivo.h b) Cuerpo en "C" archivo.cpp Figura # 59 Subsistema: Los subsistemas sirven para modularizar el modelo físico de un sistema. Un subsistema es un agregado que contiene otros módulos y otros subsistemas. Cada modulo engloba la declaración o definición de clases, objetos y otros detalles del lenguaje. nombre Sistema del Pacman Definición de Pacman Definición de Pildora Definición de Fruta d) Subsistema. Figura # 60 Definición de Campo Campo Sistema del Pacman Figura # 6 Diagrama de módulos 7

11 Dependencias: la única relación que puede darse entre dos módulos es una dependencia de compilación, representada por una línea dirigida que apunta al modulo respecto al cual existe la dependencia. Las flechas denotan dependencias, la flecha sale del el icono dependiente. Diagrama de procesos. Se usa un diagrama de procesos para mostrar la asignación de procesos a procesadores en el diseño físico de un sistema. Un solo diagrama de procesos presenta una vista de la estructura de procesos de un sistema. Elementos del diagrama Procesadores. Elemento de hardware capaz de ejecutar programas. Dispositivos. Elemento de hardware incapaz de ejecutar un programa. Conexiones. Son líneas no dirigida para indicar conexiones entre procesadores y/o dispositivos. nombre nombre a) icono de proceso b) icono de dispositivo c) icono de conexión Figura # 62 Diagrama de Procesos. Estación de Juego del Usuario JoyStick Figura # 63 Diagrama de procesos, Representa el sistema del Pacman El proceso. El proceso de diseño orientado a objetos no puede describirse mediante reglas, aunque esta bastante bien definido como para brindar un proceso predecible y repetible para una organización de software madura. Un proyecto de software bien hecho es aquel en el que el software entregado satisface y posiblemente excede las expectativas del cliente. Se ha desarrollado de forma económica, 72

12 entregado en tiempo, y es flexible al cambio y al crecimiento. En los proyectos que han tenido éxito se ha visto que existen los siguientes aspectos:! La existencia de una fuerte visión arquitectónica. Un sistema con una buena arquitectura es aquel que cuenta con integridad conceptual, y las siguientes propiedades:! Esta construido en capas de abstracción bien definida.! Existe una separación entre la interfaz y la implementación de cada capa.! La arquitectura es simple.! La aplicación de un ciclo de vida bien dirigido, iterativo e incremental.! Es iterativo ya que conduce al refinamiento sucesivo de una arquitectura orientada a objetos.! Es incremental ya que en cada pasada por el ciclo; análisis / diseño / evolución conduce a un refinamiento gradual de las decisiones estratégicas y tácticas, convergiendo hacia los requerimientos reales y habitualmente no expresados por el usuario final. El micro-proceso de desarrollo. Esta dirigido por la corriente de escenarios y productos arquitectónicos, resultantes del macroproceso y refinamientos sucesivos. El micro-proceso sigue las siguientes actividades: Identifica clases y objetos a un nivel dado de abstracción: Se identifican clases y tipos de objetos para delimitar el problema y tener bien establecido el dominio del mismo. A raíz de realizar esta etapa se crea un diccionario de datos donde se documentan dichos elementos, el cual servirá para tener una visión global del sistema. Identifica la semántica de estas clases y objetos: Se identifica que van a hacer y que representa cada clase de datos, por lo cual surge un refinamiento del diccionario de datos debido a que cada descripción de clase contendrá los atributos y responsabilidades de dichas clases. Identifica las relaciones entre estas clases y objetos: Se identifican las colaboraciones de cada clase u objeto, para establecer las asociaciones y se lleva a cabo mediante la descripción de las responsabilidades de cada abstracción. En esta etapa se especifican las asociaciones y mediante la separación de responsabilidades se lleva a cabo un refinamiento de las mismas, además esta etapa tiene como consecuencia otro refinamiento al diccionario de datos. Especifica la interfaz y luego la implementación de estas clases y objetos: En esta etapa se verifican las abstracciones existentes ya que se identifican la forma en que una abstracción responde al llamado de otra, lo cual lleva a definir métodos y mensajes transmitidos entre las abstracciones. En la figura # 64 se muestra el micro-proceso de desarrollo. 73

13 Refinamiento del diccionario Identificar clases y objetos. Diccionario de datos (clases y objetos). Especificar interfaces e implementación de clases y objetos. Identificar semántica de clases y objetos. Diccionario de datos (responsabilidades y accesibilidad entre ellos) Identificar relaciones entre clases y objetos. Diccionario de datos (clases y objetos responsabilidades) Figura # 64 Microproceso de desarrollo. El micro-proceso se ve como un proceso de refinamiento dentro de las etapas del macro-proceso Para cada una de las etapas se desarrollan los siguientes puntos: Propósito. Productos. Actividades. Hitos y medidas. El macro-proceso de desarrollo. En el marco de referencia para el control del micro-proceso, se dicta una serie de actividades cuantificables que permiten al equipo de desarrollo tasar el riego de forma significativa y realizar correcciones iniciales al micro-proceso de forma de centrar mejor las actividades de análisis y diseño del equipo. El macro-proceso realiza las siguientes actividades:! Conceptualización: En esta etapa se establecen los requisitos esenciales para el sistema.! Análisis: Se lleva a cabo un análisis en el dominio del problema para poder llegar a describir el problema basándose en el comportamiento del sistema.! Diseño: Crear una arquitectura para la implementación.! Evolución: En esta etapa se puede llegar a aumentar y cambiar la implantación mediante refinamientos sucesivos.! Mantenimiento: Gestionar la evolución post-venta o post-entrega. Para cada una de las etapas se desarrollan los siguientes puntos: Propósito. Productos. Actividades. Hitos y medidas. 74

14 Gráficamente el macro-proceso se puede representar como en la figura # 65. Establecer requisitos básicos (conceptualización) Desarrollar un modelo del comportamiento deseado (análisis) Crear una arquitectura (diseño) Gestionar la evolución después de la entrega (mantenimiento) Transformar la implementación (evolución) Figura # 65 Macro-proceso de desarrollo. Booch propone este proceso de desarrollo pensando en que el macro-proceso es aquel proceso donde las etapas de desarrollo abarcan un período grande, donde un equipo de desarrolladores se vera implicado, mientras que define al micro-proceso como una actividad diaria que se debe de realizar según lo que se va descubriendo o desarrollando durante el macro-proceso. Mediante esta conceptualización durante las primeras etapas del macro-proceso en especial en el análisis es donde se estudia el comportamiento del sistema, se entra en el proceso del microproceso donde se describen que clases y objetos intervendrán, y mientras se avanza en el macroproceso cuando se tengan establecidos los escenarios en el micro-proceso se podrá llevar acabo una narración de sucesos que ayudará a identificar las responsabilidades de cada abstracción. Mediante el ejemplo anterior se percibe que durante una etapa dentro del macro-proceso se pueden tener varias iteraciones del micro-proceso, lo cual tendrá el propósito de refinar el sistema agregando o eliminando abstracciones que se presenten en el sistema. No importa lo sofisticado que sea el método de desarrollo, y lo bien fundamentado que estén sus bases teóricas, no es posible ignorar los aspectos prácticos de diseño de sistemas para el mundo real. Esto implica que es necesario considerar buenas prácticas de gestión por lo que se refiere a temas como; administración de personal, gestión de versiones y control de calidad. 75

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

Diagramas de Clase en UML 1.1

Diagramas de Clase en UML 1.1 Diagramas de Clase en UML. Francisco José García Peñalvo Licenciado en Informática. Profesor del Área de Lenguajes y Sistemas Informáticos de la Universidad de Burgos. fgarcia@.ubu.es Carlos Pardo Aguilar

Más detalles

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

Introducción al UML. Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación Introducción al UML Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación Contenido Qué es UML?. Diagramas Utilizados en UML. Ejemplos. Qué es UML UML es un Lenguaje de Modelado

Más detalles

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

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los

Más detalles

Tema 5. Diseño detallado.

Tema 5. Diseño detallado. Ingeniería del Software II 2011 Tema 5. Diseño detallado. Diseño del Software. Los requisitos y el análisis orientado a objetos se centran en aprender a hacer lo correcto: Entender los objetos de nuestro

Más detalles

El proceso unificado en pocas palabras

El proceso unificado en pocas palabras El Proceso Unificado de Desarrollo de Software Ivar Jacobson Grady Booch James Rumbaugh Addison Wesley Resumen Capítulo 1. El proceso unificado: dirigido por casos de uso, centrado en la arquitectura,

Más detalles

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

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos: Tutorial de UML Introducción: El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende

Más detalles

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño El proceso de diseño para una base de datos consta básicamente de 7 pasos, los cuáles se describen en la siguiente imagen.

Más detalles

La importancia del desarrollo para el buen diseño del software

La importancia del desarrollo para el buen diseño del software La importancia del desarrollo para el buen diseño del software RESUMEN N L González Morales. 1 En este ensayo se examinan los temas vistos en clase que son Desarrollo de Orientado a Objetos y Arquitectura

Más detalles

UML. Lenguaje de Modelado Unificado

UML. Lenguaje de Modelado Unificado Lenguaje de Modelado Unificado Concepto de Reseña Histórica Características Estándares que conforman Modelo Relacional con Ventajas Críticas Concepto de (Unified( Modeling language) Es un lenguaje usado

Más detalles

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

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

PUD: Proceso de Desarrollo Unificado

PUD: Proceso de Desarrollo Unificado PUD: Proceso de Desarrollo Unificado 1 1998 Genealogía del PUD Rational Unified Process 5.0 1997 Rational Objectory Process 4.1 UML 1996 Rational Objectory Process 4.0 1995 Método Ericsson Rational Approach

Más detalles

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

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos 65 CAPITULO 3 DISEÑO 3.1. DISEÑO El diseño del software es el proceso que permite traducir los requisitos analizados de un sistema en una representación del software. 66 Diseño procedural Diseño de la

Más detalles

ISO 19103. Lenguaje de Esquema Conceptual

ISO 19103. Lenguaje de Esquema Conceptual ISO 19103 Lenguaje de Esquema Conceptual La ISO 19103 establece normas y guías para la adopción y uso de un Lenguaje de Esquema Conceptual (CSL) para desarrollar modelos o esquemas de información geográfica,

Más detalles

DIAGRAMA DE CLASES EN UML

DIAGRAMA DE CLASES EN UML DIAGRAMA DE CLASES EN UML Mg. Juan José Flores Cueto jflores@usmp.edu.pe Ing. Carmen Bertolotti Zuñiga cbertolotti@usmp.edu.pe INTRODUCCIÓN UML (Unified Modeling Language) es un lenguaje que permite modelar,

Más detalles

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

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

El modelo de casos de uso. Ingeniería de la Programación

El modelo de casos de uso. Ingeniería de la Programación El modelo de casos de uso Ingeniería de la Programación Prácticas cas 1 Contenidos Introducción RF y RNF Introducción al modelo de RF de UML. Actores y Casos de Uso Modelo de casos de uso Diagrama de contexto

Más detalles

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos I. INTRODUCCIÓN El reciente aumento de aplicaciones en donde se utiliza la computadora ha sido posible debido a un hardware de bajo costo, por lo cual la demanda de software ha crecido de forma exponencial.

Más detalles

Diagramas de clases de UML

Diagramas de clases de UML Qué es UML? UML ( Unified Modeling Language ) es un lenguaje visual para crear modelos de sistemas. Diagramas de clases de UML Franco Guidi Polanco Escuela de Ingeniería Industrial Pontificia Universidad

Más detalles

Tema 1 Introducción a la Ingeniería de Software

Tema 1 Introducción a la Ingeniería de Software Tema 1 Introducción a la Ingeniería de Software Curso Ingeniería de Software UMCA Profesor Luis Gmo. Zúñiga Mendoza 1. Software En la actualidad todo país depende de complejos sistemas informáticos. Podemos

Más detalles

UML. UML significa Lenguaje Unificado de Modelado UML combina lo mejor de:

UML. UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: UML UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: Conceptos de modelado de datos (diagramas entidad-relación) Modelado de negocios (flujos de trabajo) Modelado de objetos Modelado

Más detalles

TEMA 7: DIAGRAMAS EN UML

TEMA 7: DIAGRAMAS EN UML TEMA 7: DIAGRAMAS EN UML Diagramas en UML El bloque de construcción básico de UML es un Diagrama Introducción a UML 2 1 Modelo de Casos de Uso (MCU) Todos los casos de uso constituyen el MCU que describe

Más detalles

PROCESO UNIFICADO CAPTURA DE REQUISITOS

PROCESO UNIFICADO CAPTURA DE REQUISITOS PROCESO UNIFICADO CAPTURA DE REQUISITOS El proceso unificado de desarrollo, Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999 The unified software development process, Ivar Jacobson,

Más detalles

2. Conceptos básicos Abstracción La abstracción como un proceso mental natural La abstracción en el desarrollo de software

2. Conceptos básicos Abstracción La abstracción como un proceso mental natural La abstracción en el desarrollo de software 2. Conceptos básicos Hoy en día las aplicaciones son demasiado voluminosas y complejas para ser manejadas por una sola persona. Las aplicaciones de software son complejas porque modelan la complejidad

Más detalles

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

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

Notación UML para modelado Orientado a Objetos

Notación UML para modelado Orientado a Objetos 1 Notación UML para modelado Orientado a Objetos 2 Notación UML para modelado Orientado a Objetos Índice 1.1. Qué es UML?.. 3 1.2. Por qué interesa UML en la asignatura de Programación Orientada a Objetos?3

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

Modelos de Desarrollo de Programas

Modelos de Desarrollo de Programas Modelos de Desarrollo Orientados a Objetos Adriana Castro Bonenfant Curso 2009/2010 Índice 1. Ciclo de vida del software 3 1.1. Introducción.................................... 3 1.2. Objetivos.....................................

Más detalles

Análisis de Requerimientos

Análisis de Requerimientos Análisis de Requerimientos Ing. Luis Zuloaga Rotta Situación de la Industria de Software Mas del 30% de todos los proyectos de software son cancelados antes de su finalización. Mas del 70% de los proyectos

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Introducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO)

Introducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO) Diseño Orientado a Objetos. Metodología enfocada a la solución de problemas complejos. Complejidad del software. Problemas difíciles de precisar. Definición de requerimientos vago y cambio en el desarrollo

Más detalles

13019 Diseño de bases de datos

13019 Diseño de bases de datos 13019 Diseño de bases de datos Diseño de requisitos mediante casos de uso Wladimiro Díaz Wladimiro.Diaz@uv.es Universitat de València 13019 Diseño de bases de datos p. 1 Introducción En literatura, un

Más detalles

Unidad 9. Implementación. M.C. Martín Olguín

Unidad 9. Implementación. M.C. Martín Olguín Unidad 9 Implementación M.C. Martín Olguín Implementación Es la traducción directa del diseño en un lenguaje de programación. Es decir, en la implementación se construyen los componentes: Archivos de código

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

Programación Avanzada. Análisis Modelado del Dominio

Programación Avanzada. Análisis Modelado del Dominio Programación Avanzada Análisis Modelado del Dominio Contenido Introducción Modelo de Dominio Conceptos Asociaciones Atributos Generalizaciones Otros elementos Restricciones Programación Avanzada Análisis:

Más detalles

Modelado de objetos con UML

Modelado de objetos con UML Modelado de objetos con UML José Vicente Núñez Zuleta (jose@eud.com, josevnz@yahoo.com) Líder de desarrollo para El Diario El Universal División de Nuevos Medios Puntos a tratar Qué es UML? Tipos de diagramas.

Más detalles

INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones

INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones Univ. Cantabria Fac. de Ciencias Patricia López Modelo de Casos de Uso vs Modelo de Análisis Modelo de Casos de Uso Modelo de Análisis Descrito con el

Más detalles

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV 746 Miércoles 5 octubre 2005 Suplemento del BOE núm. 238 CE2.1 Identificar los distintos sistemas de archivo utilizables en un dispositivo de almacenamiento dado para optimizar los procesos de registro

Más detalles

Técnicas de desarrollo de aplicaciones en Métrica V3

Técnicas de desarrollo de aplicaciones en Métrica V3 Índice de contenido Técnicas de desarrollo de aplicaciones en Métrica V3 Técnicas de desarrollo de aplicaciones en Métrica V3...1 Licencia...1 Introducción...1 Técnicas de desarrollo...1 Análisis coste-beneficio...2

Más detalles

ESTÁNDAR DIAGRAMA DE SECUENCIA

ESTÁNDAR DIAGRAMA DE SECUENCIA ESTÁNDAR DIAGRAMA DE SECUENCIA Un diagrama de secuencia muestra las interacciones entre objetos ordenadas en secuencia temporal. Muestra los objetos que se encuentran en el escenario y la secuencia de

Más detalles

3 - PROCESOS DE LA DIRECCIÓN DE PROYECTOS

3 - PROCESOS DE LA DIRECCIÓN DE PROYECTOS PROCESOS DE LA DIRECCIÓN DE PROYECTOS La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir con los requisitos del

Más detalles

3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1.

3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1. 3. DIAGRAMAS DE CLASES...19 3.1. INTRODUCCIÓN... 19 3.2. DIAGRAMAS DE CLASES... 19 3.2.1. Perspectivas...20 3.2.2. Clases...20 3.2.2.1. Compartimento del nombre...21 3.2.2.2. Compartimento de la lista

Más detalles

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

Análisis de Sistemas. M.Sc. Lic. Aidee Vargas C. C. octubre 2007 Análisis de Sistemas M.Sc. Lic. Aidee Vargas C. C. octubre 2007 Metodologías de Desarrollo de Software Las metodologías existentes se dividen en dos grandes grupos: Metodologías estructuradas Metodologías

Más detalles

INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS

INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS AUTORÍA JOSEFA PÉREZ DOMÍNGUEZ TEMÁTICA NUEVAS TECNOLOGIAS ETAPA CICLOS FORMATIVOS DE GRADO SUPERIOR DE INFORMÁTICA Resumen En esta publicación se

Más detalles

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles

Conceptos de redes. LAN (Local Area Network) WAN (Wide Area Network)

Conceptos de redes. LAN (Local Area Network) WAN (Wide Area Network) Conceptos de redes. Una red de ordenadores permite conectar a los mismos con la finalidad de compartir recursos e información. Hablando en términos de networking, lo importante es que todos los dispositivos

Más detalles

Capítulo 4. Prueba de Adaptabilidad

Capítulo 4. Prueba de Adaptabilidad Capítulo 4 Prueba de Adaptabilidad Capítulo 4. Prueba de Adaptabilidad Como se mencionó en el capítulo 2 actualmente no es válido que el software únicamente funcione bien y resuelva el problema que le

Más detalles

CAPITULO V. HERRAMIENTA CASE (Rational Rose, C++)

CAPITULO V. HERRAMIENTA CASE (Rational Rose, C++) CAPITULO V HERRAMIENTA CASE (Rational Rose, C++) 5.1 HERRAMIENTA CASE La documentación del UML ha propiciado el desarrollo de herramientas CASE, las cuales cubren el ciclo de vida del software y además

Más detalles

CAPITULO 2. Como se definió en el plan del presente proyecto, este será desarrollado bajo

CAPITULO 2. Como se definió en el plan del presente proyecto, este será desarrollado bajo 1 CAPITULO 2 ANÁLISIS DEL SISTEMA 1. Introducción Como se definió en el plan del presente proyecto, este será desarrollado bajo la metodología orientada a objetos. El objetivo del análisis será marcar

Más detalles

2.4 Modelado conceptual

2.4 Modelado conceptual 2.4 Modelado conceptual 2.4. Búsqueda de conceptos Un modelo conceptual muestra clases conceptuales significativas en un dominio del problema; es el artefacto más importante que se crea durante el análisis

Más detalles

ANÁLISIS DE REQUISITOS

ANÁLISIS DE REQUISITOS ANÁLISIS DE REQUISITOS 3.1.- INTRODUCCIÓN AL ANALISIS DE REQUISITOS Como se dijo en capítulos anteriores, el término análisis aplicado a sistemas significa descomponer el sistema en sus componentes para

Más detalles

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

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

Más detalles

M III ABSTRACCIÓN Y CLASIFICACIÓN

M III ABSTRACCIÓN Y CLASIFICACIÓN M III ABSTRACCIÓN Y CLASIFICACIÓN COMPLEJIDAD Y ABSTRACCIÓN La abstracción en el desarrollo del programario En todo el proceso de abstracción siempre hay una parte de la situación o del problema que se

Más detalles

6.6 DISEÑO. [Proceso]

6.6 DISEÑO. [Proceso] 6.6 DISEÑO. [Proceso] Durante un Ciclo de Desarrollo iterativo es posible pasar a la Fase de Diseño una vez completada la documentación de la fase de Análisis. Durante esta etapa se desarrolla una solución

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Weitzenfeld: Capítulo 4 1

Weitzenfeld: Capítulo 4 1 Weitzenfeld: Capítulo 4 Parte II Modelado y Programación Orientada a Objetos En esta segunda parte se describirá la programación orientada a objetos desde dos perspectivas distintas. La primera es el modelado

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

Más detalles

GLOSARIO DE TÉRMINOS

GLOSARIO DE TÉRMINOS MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO Ejercicio Guiado de Análisis y Diseño Orientado a Objetos Ejemplo: CAJERO AUTOMÁTICO El siguiente ejercicio muestra las diferentes actividades que se realizan dentro del desarrollo de un producto software

Más detalles

Patrones de Diseño Orientados a Objetos 2 Parte

Patrones de Diseño Orientados a Objetos 2 Parte Patrones de Diseño Orientados a Objetos 2 Parte Patrón Observador Observer (Patrón de Comportamiento) Patrón Observador Observer Observador (en inglés: Observer) es un patrón de diseño que define una dependencia

Más detalles

FUNDAMENTOS DE LA TEORÍA DE SISTEMA

FUNDAMENTOS DE LA TEORÍA DE SISTEMA FUNDAMENTOS DE LA TEORÍA DE SISTEMA AL TERMINAR LA CLASE UD PODRÁ RESPONDER Qué es un sistema? Cómo pueden ser definidos los sistemas? Cuáles son los parámetros de un sistema? Cuáles son las característica

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

Metodologías para generación de Sistemas Orientados a Objetos

Metodologías para generación de Sistemas Orientados a Objetos Metodologías para generación de Sistemas Orientados a Objetos Análisis y Diseño (Tecnologías) Orientado a Objetos Dr. Leopoldo Altamirano Robles 22 septiembre, 2003 Alicia Morales Reyes Alma Rosa Rugerio

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

Unidad II: Administración de Procesos y del procesador

Unidad II: Administración de Procesos y del procesador Unidad II: Administración de Procesos y del procesador 2.1 Concepto de proceso Un proceso no es más que un programa en ejecución, e incluye los valores actuales del contador de programa, los registros

Más detalles

UML, ejemplo sencillo sobre Modelado de un Proyecto

UML, ejemplo sencillo sobre Modelado de un Proyecto UML, ejemplo sencillo sobre Modelado de un Proyecto Normal &DOLILFDU 0L3DQRUDPD 626 (VFULEHSDUD1RVRWURV Por Armando Canchala Contenido Introducción Objetivo Requerimientos Casos de Uso Subcasos de Uso

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Pilares de la Orientación a Objetos

Pilares de la Orientación a Objetos Pilares de la Orientación a Objetos Pilares de la Orientación a Objetos Abstracción Relaciones Herencia Encapsulamiento Abstracción La Abstracción es la propiedad que permite seleccionar las características

Más detalles

Guía del Curso Analista Programador PHP Javascript

Guía del Curso Analista Programador PHP Javascript Guía del Curso Analista Programador PHP Javascript Modalidad de realización del curso: Número de Horas: Titulación: Online 180 Horas Diploma acreditativo con las horas del curso OBJETIVOS UML usa técnicas

Más detalles

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

Más detalles

TEMA 1. Introducción

TEMA 1. Introducción TEMA 1 Introducción Contenidos: Visión estructurada de los sistemas de transmisión de datos. Arquitectura de protocolos. 1 Modelo simplificado de comunicaciones Fuente Transmisor Sistema de transmisión

Más detalles

DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN

DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN MODULO I: Análisis y Diseño de Sistemas El alumno se familiarizará y describirá los conceptos y aspectos fundamentales del Análisis y Diseño Orientado a Objetos

Más detalles

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0 Centro Ideoinformática Universidad de las Ciencias Informáticas Carretera a San Antonio Km 2 ½. Torrens. Boyeros. Ciudad de La Habana. Cuba Teléfono: + 53 (7)

Más detalles

NORMA ISO 19109 Resumen

NORMA ISO 19109 Resumen NORMA ISO 19109 Resumen Julio de 2009 1 RESUMEN DE NORMA ISO 19109 INFORMACIÓN GEOGRÁFICA REGLAS PARA EL ESQUEMA DE APLICACIÓN El objetivo de esta Norma Internacional es proporcionar los principios para

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS ANÁLISIS Y DISEÑO DE SISTEMAS Clase XVIII: Modelo Dinámico Diagramas de Actividades Primer Cuatrimestre 2013 Diagrama de Actividades (DA) Un grafo o diagrama de actividad (DA) es un tipo especial de máquina

Más detalles

Anexo I MÓDULOS PROFESIONALES. 1. Evalúa sistemas informáticos identificando sus componentes y características.

Anexo I MÓDULOS PROFESIONALES. 1. Evalúa sistemas informáticos identificando sus componentes y características. Página I / Anexo I Núm. 135 BOLETÍN OFICIAL DE LA RIOJA Viernes, 21 de octubre de 2011 Módulo Profesional: Sistemas informáticos. Código: 0483 Equivalencia en créditos ECTS: 10 Curso: 1º Duración: 170

Más detalles

Modelo Entidad-Relación

Modelo Entidad-Relación Modelo Entidad-Relación El modelo de datos de entidad-relación (ER) se basa en una percepción de un mundo real que consiste en un conjunto de objetos básicos llamados entidades y de relaciones entre estos

Más detalles

MODULO DE PROGRAMACION JAVA Nivel Básico-Intermedio

MODULO DE PROGRAMACION JAVA Nivel Básico-Intermedio MODULO DE PROGRAMACION JAVA Nivel Básico-Intermedio Objetivo general: Introducir al participante en los conceptos y herramientas más importantes del lenguaje javo para la programación de objetos. Duración

Más detalles

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

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

Instructivo para la elaboración de un Manual Técnico

Instructivo para la elaboración de un Manual Técnico Instructivo para la elaboración de un Manual Técnico Autora: Ing. Alena González Reyes. (agonzalez@ceis.cujae.edu.cu) Ciudad de la Habana, Cuba Marzo, 2010 Índice 1. Introducción... 3 2. Confección...

Más detalles

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software Principio de Diseño Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002 Introducción al Diseño de Software Qué es el diseño? Representación ingenieril

Más detalles

Guía de Diccionarios de Datos

Guía de Diccionarios de Datos Soluciones abiertas para un mundo cambiante Guía de Diccionarios de Datos www.moose-software.com www.visualdataflex.es Soluciones abiertas para un mundo cambiante Versiones documento Versión Revisado por

Más detalles

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

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

Módulo Profesional 01: Bases de datos (código: 0484).

Módulo Profesional 01: Bases de datos (código: 0484). Módulo Profesional 01: Bases de datos (código: 0484). Actividades de enseñanza-aprendizaje que permiten alcanzar los objetivos del módulo. Interpretar diseños lógicos de bases de datos. Realizar el diseño

Más detalles

8 Conjunto de protocolos TCP/IP y direccionamiento IP

8 Conjunto de protocolos TCP/IP y direccionamiento IP 8 Conjunto de protocolos TCP/IP y direccionamiento IP 8.1 Introducción a TCP/IP 8.1.1 Historia de TCP/IP El Departamento de Defensa de EE.UU. (DoD) creó el modelo de referencia TCP/IP porque necesitaba

Más detalles

Fundamentos del diseño de software

Fundamentos del diseño de software Fundamentos del diseño de software El diseño es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniería. Definición de diseño según Taylor Proceso de aplicar distintas técnicas

Más detalles

Guía del Curso. IFCD0112 Programación con Lenguajes Orientados a Objetos y Bases de Datos. Relacionales

Guía del Curso. IFCD0112 Programación con Lenguajes Orientados a Objetos y Bases de Datos. Relacionales Guía del Curso IFCD0112 Programación con Lenguajes Orientados a Objetos y Bases de Datos Relacionales Modalidad de realización del curso: Número de Horas: Titulación: Distancia 710 Horas Diploma acreditativo

Más detalles

FORMACIÓN Principios de la programación orientada a objetos

FORMACIÓN Principios de la programación orientada a objetos FORMACIÓN Principios de la programación orientada a objetos En un mercado laboral en constante evolución, la formación continua de los profesionales debe ser una de sus prioridades. En Galejobs somos conscientes

Más detalles

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas Departamento de Informática PROGRAMACIÓN DIDÁCTICA Curso 11-12 1 CONSEJERÍA DE EDUCACIÓN I.E.S. NERVIÓN Departamento de Informática CICLO FORMATIVO: TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA.

Más detalles

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

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles