Sistemas de Información II. Diseño de Sistemas Orientado a Objetos
|
|
- Juan Carlos Aranda Flores
- hace 6 años
- Vistas:
Transcripción
1 Diseño de Sistemas Orientado a Objetos
2 Análisis de Sistemas Orientado a Objeto El Proceso Unificado Concepción Elaboración Construcción Transición Modelado del Negocio Requerimientos Análisis y Diseño Implementación Prueba Implantación Admón. del Proyecto Iteraciones IT #1 IT # 2 IT # 3 IT # 4 IT # 5 IT # 6 IT # 7 IT # 8
3 Objetivos Introducción Contenido Flujo de Trabajo de Diseño Modelo de Diseño en RUP El Diseño en el Proceso Unificado RUP
4 Objetivos Sistemas de Información II Introducir la descripción general del modelado estático (estructura) y dinámico (comportamiento) internos de un sistema entrando en detalles estructurales (clases, atributos y relaciones entre clases) y de comportamiento (operaciones, estados y actividades). Continuar con el estudio del Proceso Unificado en el flujo de trabajo de análisis y diseño. Presentar el modelo de diseño del Proceso Unificado.
5 Introducción En el flujo de requisitos se construye un modelo que representa el comportamiento observable o externo del sistema que se quiere obtener En los flujos de análisis, diseño e implementación, se representa la estructura y el comportamiento internos del sistema a realizar En los tres flujos se trabaja a diferentes niveles de abstracción, desde el más elevado en el análisis, hasta el más bajo en la implementación
6 Flujo de Trabajo de Diseño
7 Flujo de Trabajo de Diseño La técnica de modelado consiste en identificar, a través de las especificaciones de las clases de análisis las clases de diseño correspondientes Para cada clase de análisis se puede derivar una o más clases de diseño: Clase de control clase activa (>= 1) Clase de entidad clase de entidad (>= 1) Clase de interfaz clase de interfaz (>= 1)
8 Flujo de Trabajo de Diseño Clase de control: Se deriva al menos una clase activa, que representa un proceso o un hilo de proceso (thread) <<trace>> Gestor de cuentas Gestor de cuentas <<trace>> Gestor clientes Gestor clientes
9 Flujo de Trabajo de Diseño Clase de entidad: Se deriva al menos una clase de entidad, que guarda la información de una entidad u objeto del sistema, y se puede ligar a una clase activa para su gestión <<trace>> Facturas Facturas <<trace>> itemsfactura <<trace>> Clientes Clientes
10 Flujo de Trabajo de Diseño Clase de interfaz: Se deriva al menos una clase de interfaz y se puede ligar a una clase activa para su gestión y conexión con otros tipos de clases interfazdatos Cliente <<t race>> <<trace>> interfazproductos InterfazFacturar <<trac e>> int erfazpago
11 Flujo de Trabajo de Diseño El proceso de conversión del Modelo de Análisis (MA) al Modelo de Diseño (MD), la estrategia adoptada es mixta: Top-Down Level-to-Level Estrategia Top-Down: Se parte del Diagrama de Clases de Análisis de Contexto (DCAX, MA nivel 0) Inicialmente, cada uno de los paquetes / subsistemas en el DCAX puede corresponder a un subsistema en el Diagrama de Clases de Diseño de Contexto (DCDX, MD nivel 0) Sistemas de Información II
12 Flujo de Trabajo de Diseño: Estrategia Top-Down
13 Flujo de Trabajo de Diseño Estrategia Level-to-Level: Se trabaja con los diagramas de clases de Análisis de niveles inferiores (nivel 1, 2,...) Inicialmente, cada uno de los paquetes/subsistemas en el DCAX puede corresponder a un subsistema en el Diagrama de Clases de Diseño de Contexto (DCDX, MD nivel 0) Se puede tomar como guía la estructura de los DCA de niveles 1, 2,...y se aplican las transformaciones consiguientes, con las debidas precauciones.
14 Flujo de Trabajo de Diseño: Estrategia Level-to-Level
15 Flujo de Trabajo de Diseño El Modelo de Diseño consta igualmente de dos vistas: Vista de Diseño Estática: Descripción de la estructura del sistema a modelar con decisiones de implementación. Compuesta fundamentalmente por clases que se pueden agrupar en: Agrupaciones lógicas de clases o subsistemas, y que se pueden representar por los elementos de UML denominados paquetes Diagramas de clases de diseño (DCD) con la estructura de niveles ya conocida. Sistemas de Información II
16 Flujo de Trabajo de Diseño Vista de Diseño Dinámica: Descripción del comportamiento del sistema a modelar con decisiones de implementación. Compuesta fundamentalmente por diagramas UML: Diagrama de Interacción/ Secuencia de sucesos Diagrama de Interacción/ Colaboración Diagrama de Estados Diagrama de Actividades
17 Flujo de Trabajo de Diseño
18 EL Diseño en el proceso Unificado Visión General Artefactos Modelo de diseño. Clases de diseño. Realización en diseño de los casos de uso. Subsistemas en diseño. Interfaz. Modelado de Despliegue Descripción de la Arquitectura Actividades Diseño de los casos de uso. Diseño de las clases. Diseño de subsistemas. Diseño de la arquitectura
19 EL Diseño en el proceso Unificado: Visión General
20 EL Diseño en el proceso Unificado: Visión General Abordar requisitos no funcionales y restricciones en relación a: Lenguajes de programación, reutilización de componentes, sistemas operativos, tecnologías de: distribución, concurrencia, bases de datos, interfaces de usuario, gestión de transacciones, etc. Descomponer el modelo de análisis en subsistemas que puedan desarrollarse en paralelo. Definir la interfaz de cada subsistema. Derivar una representación arquitectónica del sistema
21 EL Diseño en el proceso Unificado: Visión General Acercar el modelo de análisis al modelo de implementación Los milagros más comunes de la ingeniería del software son las transiciones desde el análisis hasta el diseño y desde el diseño al código (Richard Due).
22 EL Diseño en el proceso Unificado: Visión General Modelado de Análisis Modelo conceptual Pueden obtenerse varios diseños Menos formal Menos caro de desarrollar Puede eliminarse Modelado de Diseño Modelo físico Específico a una implementación Mas formal Más caro (5 veces más) Debe mantenerse todo el cv
23 EL Diseño en el proceso Unificado: Visión General
24 EL Diseño en el proceso Unificado Visión General Artefactos Modelo de diseño. Clases de diseño. Realización en diseño de los casos de uso. Subsistemas en diseño. Interfaz. Modelado de Despliegue Descripción de la Arquitectura Actividades Diseño de los casos de uso. Diseño de las clases. Diseño de subsistemas. Diseño de la arquitectura
25 Artefactos: Modelo de Diseño Casos de uso en el dominio de la solución Cómo soportar requisitos funcionales/no funcionales y otras restricciones en el entorno de implementación Entrada fundamental para actividades de implementación
26 Artefactos: Clases de Diseño Una clase de diseño es una abstracción de una clase de implementación Las operaciones atributos, tipos, visibilidad (public, protected, private...), se pueden especificar con la sintaxis del lenguaje elegido Las relaciones entre clases de diseño se traducen de manera directa al lenguaje: generalización: herencia asociaciones, agregaciones: atributos Se pueden postergar algunos requisitos a implementación (por ejemplo: manera de nombrar los CAL/Notación atributos, Modelo del Negocio operaciones,...)
27 Artefactos: Clases de Diseño Realizan interfaces. Una clase de diseño puede ser activa (los objetos de la clase tienen su propio flujo de control y se ejecutan concurrentemente con otros objetos activos). Depende de la tecnología de concurrencia utilizada por el lenguaje de implementación.
28 Artefactos: Realización en diseño de los casos de uso Es una colaboración que describe cómo se realiza en diseño un caso de uso en términos de clases de diseño y sus interacciones
29 Artefactos: Realización en diseño de los casos de uso La realización en diseño de un caso de uso, incluye: Diagramas de clases de Diseño: clases participantes Diagramas de interacción: escenarios del caso de uso Descripción textual del flujo de eventos
30 Artefactos: Realización en diseño de los casos de uso Modelo de Análisis factura Vendedor (from Use Case View) interfacefacura gestorfactura producto
31 Artefactos: Realización en diseño de los casos de uso Modelo de Diseño cliente interfacepago 1 +posee 0..n +pertenece Vendedor (f rom Use Case Vie w) int erfacefactura gestorfactura fact ura 0..n +contiene interfaceproducto 1..n +esta contenida itemsfactura +produce 1 inventario producto +se asocia 1
32 Artefactos: Subsistemas de Diseño Para organizar los artefactos de diseño: clases de diseño, realización de casos de uso, interfaces y otros subsistemas. Fuertemente cohesionados y débilmente acoplados
33 Artefactos: Interfaz Los interfaces se utilizan para especificar las operaciones de las clases y los subsistemas de diseño Especifica una colección de operaciones públicas, tipos y parámetros necesarios para acceder y usar las capacidades de una clase de diseño o un subsistema Las clases de diseño soportan las operaciones de su interfaz mediante métodos. Los subsistemas de diseño soportan las operaciones de su interfaz mediante las clases de diseño (o subsistemas) que contiene
34 Artefactos: Interfaz La mayoría de las interfaces entre subsistemas se consideran relevantes para la arquitectura debido a que definen las interacciones permitidas entre los subsistemas
35 Actividades: Diseño de la Arquitectura
36 Artefactos: Artefactos. Modelo Modelo de Despliegue de Despliegue Es un modelo de objetos que describe la distribución física del sistema en términos de cómo se distribuye la funcionalidad entre los nodos de cómputo Correspondencia entre la arquitectura software y la arquitectura del sistema Cada nodo representa un recurso de cómputo, normalmente un procesador o un dispositivo hardware similar Los nodos poseen relaciones que representan medios de comunicación que hay entre ellos, tales como una Intranet o Internet. El modelo de despliegue puede describir diferentes configuraciones de red
37 Artefactos: Modelo de Despliegue La funcionalidad de un nodo viene representada por los componentes que se ejecutan en él. El modelo de despliegue representa un mapeo claro entre la arquitectura software y la hardware. Un diagrama de distribución muestra la ubicación de los componentes en nodos, de tal forma que se obtenga una vista de distribución del sistema Los procesadores y dispositivos son estereotipos comunes de Nodo. Los nodos se conectan en el diagrama a través de una línea, que refleje la ruta de comunicación entre ellos Los elementos esenciales de un diagrama de distribución son los nodos y las conexiones 10 Modelo Físico = Modelo de Diseño + Modelo de Despliegue
38 Artefactos: Descripción de la Arquitectura (Vista Modelo de Diseño) Contiene una vista de la arquitectura del modelo de diseño que muestra sus artefactos relevantes para la arquitectura. Suele considerarse significativos para la arquitectura los siguientes artefactos del modelo de diseño: La descomposición del modelo de diseño en subsistemas, sus interfaces y las dependencias entre ellos. Esta descomposición es muy significativa, debido a que los subsistemas y sus interfaces constituyen la estructura fundamental del sistemas. Clases de diseño fundamentales con una traza a las clases de análisis significativas y clases activas
39 Artefactos: Descripción de la Arquitectura (Vista Modelo de Diseño) Realizaciones de caso de uso diseño que describan una funcionalidad importante y crítica y que deban desarrollarse pronto en el ciclo de vida Artefactos: Descripción de la Arquitectura (Vista Modelo de Despliegue) Contiene una vista de la arquitectura del modelo de despliegue que muestra los artefactos relevantes para la arquitectura
40 Artefactos: Descripción de la Arquitectura Contiene una vista de la arquitectura del modelo de despliegue que muestra los artefactos relevantes para la arquitectura
41 Artefactos: Descripción de la Arquitectura Dimensiones de la arquitectura del software: Perspectivas diferentes para inversionistas diferentes: Usuario final, cliente, administrador de proyecto Ingeniero de sistema, desarrollador, arquitecto, evaluador Las perspectivas múltiples requieren múltiples vistas: Los diagramas de clases no muestran el mapeo del sistema al hardware Los diagramas de bloques de hardware no describen que partes del sistema son obtenidas de software comercial
42 Artefactos: Descripción de la Arquitectura Para describir completamente una arquitectura, se necesitan cuatro vistas: Una Vista Lógica que proporciona una imagen estática de las principales clases y sus relaciones Una Vista de Componentes que muestra como está el código organizado en paquetes y librerías, así como el software comercial Una Vista de Procesos que muestra procesos y tareas Una Vista de Distribución que muestra los procesadores, dispositivos y ligas en el ambiente operacional Finalmente, una Vista de Casos de Uso que explica como trabajan juntas las otras cuatro vistas
43 Artefactos: Descripción de la Arquitectura El Modelo 4+1 Vistas Vista Logica Vista de Componentes Funcionalidad Administración, reuso y portabilidad del Software Usuarios finales Vista de Casos de Uso Ingenieros de software Entendimiento de Utilidad Vista de Procesos Desempeño, Disponibilidad, Tolerancia de fallas Vista de Distribución Desempeño, Disponibilidad Tolerancia a fallas, Escalabilidad Entrega e Instalación Integradores de Sistema Ingenieros de Sistema
44 Artefactos: Descripción de la Arquitectura Las 4+1 Vistas del Modelo UML Vista Lógica Diagramas de Clases, Diagramas de Secuencias Vista de Componente Diagramas de Componentes Vista de Caso de Uso Diagramas de Casos de Uso, Diagramas de Secuencias Vista de proceso Vista de Despliegue Diagramas de Procesos Diagramas de Distribución
45 EL Diseño en el proceso Unificado Visión General Artefactos Modelo de diseño. Clases de diseño. Realización en diseño de los casos de uso. Subsistemas en diseño. Interfaz. Modelado de Despliegue Descripción de la Arquitectura Actividades Diseño de los casos de uso. Diseño de las clases. Diseño de subsistemas. Diseño de la arquitectura
46 Actividades: Diseño de Casos de Uso Identificar las clases de diseño y/o subsistemas necesarios para la realización del caso de uso. Distribuir el comportamiento del caso de uso entre las clases y/o subsistemas de diseño
47 Actividades: Diseño de Casos de Uso Identificar las clases de diseño Derivar las clases de diseño de las correspondientes clases de análisis que participan en el caso de uso. Estudiar los requisitos especiales del caso de uso: realizarlos con los mecanismos genéricos de diseño o con clases de diseño. Asignar responsabilidades a las clases identificadas. Realizar un diagrama de clases que muestre las clases de diseño que intervienen en la realización del caso de uso y las relaciones entre ellas.
48 Actividades: Diseño de Casos de Uso Describir interacciones entre objetos de diseño Utilizar diagramas de secuencia objetos, instancias de actores, enlaces Crear un diagramas de secuencia Comenzar estudiando la realización en análisis del casos de uso Sobre los diagramas de secuencia: el caso de uso comienza cuando una instancia de un actor envía un mensaje a un objeto interfaz. cada clase de diseño identificada debería tener al menos un objeto participando en el diagrama de secuencia.
49 Actividades: Diseño de Casos de Uso Describir interacciones entre objetos de diseño En este flujo de trabajo gestionar excepciones y errores (entradas incorrectas, situaciones anormales, etc.)
50 EL Diseño en el proceso Unificado Visión General Artefactos Modelo de diseño. Clases de diseño. Realización en diseño de los casos de uso. Subsistemas en diseño. Interfaz. Modelado de Despliegue Descripción de la Arquitectura Actividades Diseño de los casos de uso. Diseño de las clases. Diseño de subsistemas. Diseño de la arquitectura
51 Actividades: Diseño de Clases Identificar las responsabilidades de las clases de diseño (papeles en los casos de uso) Identificar: operaciones atributos relaciones en las que participa estados (diagramas de estados) métodos que soportan sus operaciones Requisitos nuevos
52 Actividades: Diseño de Clases Identificar operaciones En el lenguaje de implementación Mirar responsabilidades que tiene en los casos de uso Identificar atributos Describirlos en el lenguaje de programación Considerar los atributos de las clases de análisis de las que se derivan
53 Actividades: Diseño de Clases Identificar asociaciones y agregaciones Las interacciones en los diagramas de secuencia precisan de asociaciones entre las clases que interactúan. Minimizar el número de relaciones entre clases (disminuir el acoplamiento). Refinar multiplicidad, papeles, etc. Refinar la navegabilidad (dirección) de las asociaciones en base a los diagramas de secuencia. Identificar generalizaciones-especializaciones.
54 Actividades: Diseño de Clases Describir métodos Algoritmos para implementar alguna operación (lenguaje natural). Esqueletos de métodos generado por la herramienta. En general, esto se suele hacer en implementación. Describir estados Algunos objetos reaccionan en función de su estado actual. Utilizar diagramas de transición de estados.
55 Diagrama de clase de Diseño
56 Diagrama de clase de Diseño
57 EL Diseño en el proceso Unificado Visión General Artefactos Modelo de diseño. Clases de diseño. Realización en diseño de los casos de uso. Subsistemas en diseño. Interfaz. Modelado de Despliegue Descripción de la Arquitectura Actividades Diseño de los casos de uso. Diseño de las clases. Diseño de subsistemas. Diseño de la arquitectura
58 Actividades: Diseño de los Subsistemas Intentar que los subsistemas de diseño estén débilmente acoplados. Intentar que las clases dentro de los subsistemas tengan una alta cohesión. Describir las dependencias entre los subsistemas. Determinar qué clases de unos subsistemas interactúan con qué otras clases de otros subsistemas.
59 Actividades: Diseño de los Subsistemas Asegurarse que el subsistema soporta sus interfaces. Objetivos: Subsistemas independientes Garantizar corrección de interfaces Garantizar la realización de dichas interfaces
60 EL Diseño en el proceso Unificado Visión General Artefactos Modelo de diseño. Clases de diseño. Realización en diseño de los casos de uso. Subsistemas en diseño. Interfaz. Modelado de Despliegue Descripción de la Arquitectura Actividades Diseño de los casos de uso. Diseño de las clases. Diseño de subsistemas. Diseño de la arquitectura
61 Actividades: Diseño de la Arquitectura El objetivo es esbozar los modelos de diseño y despliegue y su arquitectura mediante la identificación de los siguientes elementos: Los nodos y sus configuraciones de red Los subsistemas y sus interfaces Las clases de diseño significativas para la arquitectura Los mecanismos de diseño genéricos que tratan requisitos comunes
62 Actividades: Diseño de la Arquitectura Identificación de Nodos y Configuraciones de Red Las configuraciones de red suelen tener una gran influencia sobre la arquitectura del software, incluyendo las clases activas que se necesitan y la distribución de la funcionalidad entre los nodos de red Las configuraciones de red habituales utilizan un patrón de tres capas: Capa de los clientes (interacción con el usuario) Capa de lógica de negocio o de aplicación Capa de funcionalidad de base de datos (acceso a datos) El patrón cliente / servidor simple es un caso especial del patrón de las tres capas, en el cual la capa de CAL/Notación aplicación Modelo del Negociose ubica en una de las otras capas
63 Actividades: Actividades. Diseño de Diseño la Arquitectura de la Arquitectura Aspectos a destacar [Jacobson et al., 1999] Qué nodos se necesitan y cuál debe ser su capacidad en términos de potencia de procesamiento y tamaño de memoria? Qué tipo de conexiones debe haber entre los nodos y qué protocolos de comunicaciones deben utilizarse? Qué características deben tener las conexiones y los protocolos de comunicaciones, en aspectos tales como ancho de banda, disponibilidad y calidad? Es necesario tener alguna capacidad de proceso redundante, modos de fallo, migración de procesos, mantenimiento de copias de seguridad de los datos, CAL/Notación o Modelo aspectos del Negocio similares?
64 3.2.4 Actividades. Diseño de la Arquitectura Actividades: Diseño de la Arquitectura Ejemplo: Configuración de red para el Sistema Interbank Cliente del Comprador <<intranet (TCP/IP)>> Servidor del Comprador <<internet (TCP/IP)>> Servidor del Vendedor <<internet (TCP/IP)>> Cliente del Vendedor <<internet (TCP/IP)>> <<internet (TCP/IP)>> Servidor del Banco
65 Actividades: Actividades. Diseño de Diseño la Arquitectura de la Arquitectura Identificación de Subsistema y sus Interfaces Identificación de Subsistema y sus Interfaces Los subsistemas son un medio para organizar el modelo de diseño en piezas manejables. No todos los subsistemas se desarrollan internamente en el proyecto en curso Los subsistemas se organizan siguiendo un patrón de capas [Buchmann et al., 1996; Shaw y Garlan, 1996] Este patrón facilita la organización jerárquica de los subsistemas en capas Sigue la máxima de que los subsistemas de una capa sólo pueden referenciar subsistemas de un nivel igual o inferior La comunicación entre los subsistemas de diferentes capas se lleva a cabo mediante un conjunto de interfaces bien definidas
66 3.2.4 Actividades. Diseño de la Arquitectura Actividades: Diseño de la Arquitectura Identificación de subsistemas de aplicación Se identifican los subsistemas de las capas de la aplicación (dos capas superiores) Si se hizo una división adecuada en paquetes durante el análisis, se pueden utilizar éstos tanto como sea posible, e identificar los correspondientes subsistemas dentro del modelo de diseño. Se pueden refinar estos subsistemas para tratar temas relativos al diseño. La descomposición inicial de los subsistemas del análisis se refina cuando [Jacobson et al., 1999] Una parte de un paquete del análisis se corresponde con un subsistema por sí mismo. Esa parte puede ser compartida y utilizada por otros subsistemas
67 3.2.4 Actividades. Diseño de la Arquitectura Actividades: Diseño de la Arquitectura Algunas partes de un paquete de análisis se realizan mediante productos software reutilizados. Estas funcionalidades pueden asignarse a capas intermedias o subsistemas de software del sistema Los paquetes del análisis no representan una división adecuada del trabajo. Los paquetes del análisis no representan la incorporación de un sistema heredado. Se puede encapsular un sistema heredado, o parte de él, mediante un subsistema de diseño independiente. Los paquetes del análisis no están preparados para una distribución directa sobre los nodos
68 3.2.4 Actividades. Diseño de la Arquitectura Actividades: Diseño de la Arquitectura Patrón de capas propuesto en [Jacobson et al., 1999]
69 Actividades: Diseño de la Arquitectura Ejemplo: Identificación de subsistemas de diseño a partir de paquetes de análisis Modelo de Análisis <<Paquete de Analisis>> Gestion de Facturas del Comprador <<Paquete de Analisis>> Gestion de Cuentas Modelo de Diseño <<subsystem>> Gestion de facturas del comprador <<subsystem>> Gestion de cuentas
70 Actividades: Diseño de la Arquitectura Identificación de los subsistemas de servicios a partir de paquetes de servicios existentes <<Paquete de Analisis>> Ges tion de Cuentas <<Paquete de Servicio>> Cuentas <<Paquete de Servicio>> Riesgos <<subsystem>> Gestion de cuentas <<subsistemz de Servicio>> cuentas <<Subsistema de servicio>> riesgos
71 Actividades: Diseño de la Arquitectura Durante el diseño se puede identificar subsistemas de diseño de servicios para proporcionar un servicio general que puedan utilizar diferentes realizaciones de casos de uso <<subsystem>> Gestion de facturas del comprador Capa especifica de la aplicación <<subsistema de servicio>> Gestion de Planificacion de pagos <<subsys tem >> Gestion de cuentas Capa general de la aplicación
72 Actividades: Diseño de la Arquitectura Identificación de subsistemas intermedios y de software del sistema Estos subsistemas constituyen los cimientos de un sistema. Toda la funcionalidad descansa sobre software como sistemas operativos, sistemas de gestión de bases de datos, software de comunicaciones, tecnologías de distribución de objetos, bibliotecas de componentes para el diseño de interfaces gráficas de usuario y tecnologías de gestión transacciones [Jacobson et al., 1997] La selección e integración de productos software que se compran o se construyen son dos de los objetivos fundamentales durante las fases de inicio y CAL/Notación elaboración Modelo del Negocio
73 Actividades: Diseño de la Arquitectura Definición de las dependencias Deberían definirse dependencias entre subsistemas si sus contenidos tienen relación entre sí La dirección de la dependencia debería ser la misma que la dirección de la navegabilidad de la relación. Si se utilizan interfaces entre subsistemas, las dependencias deberían ir hacia las interfaces, no hacia los subsistemas
74 Actividades: Diseño de la Arquitectura Dependencias y Capas
75 Actividades: Diseño de la Arquitectura Identificación de Interfaces entre Subsistemas Las interfaces proporcionadas por un subsistema definen operaciones que son accesibles desde afuera del subsistema. Estas interfaces las proporcionan o bien clases de diseño u otros subsistemas dentro del subsistema. Para definir inicialmente las interfaces, antes de conocer los contenidos de los subsistemas, debemos considerar hacia donde apunta las dependencias entre subsistemas. Cuando un subsistemas tiene una dependencia que apunta hacia el, es probable que CAL/Notación deba Modelo proporcionar del Negocio una interface.
76 Actividades: Diseño de la Arquitectura Interfaces en las dos capas superiores <<subsystem>> Gestion de facturas del comprador Recepcion Factura Capa especifica de la aplicación SolicitudPago <<subsistema de servicio>> Gestion de Planificacion de pagos Transferencia <<subsystem>> Gestion de cuentas Capa general de la aplicación
77 Actividades: Diseño de la Arquitectura
78 Actividades: Diseño de la Arquitectura Ejemplo: Diagrama de Distribución para el Sistema de Inscripción Este diagrama muestra dos nodos y los dispositivos con los que se comunica el Sistema de Inscripción Sistema de Inscripción Base de Datos Dormitorios <<device>> Edificio Principal <<device>> Biblioteca <<device>>
TEMA 4. PROCESO UNIFICADO
TEMA 4. PROCESO UNIFICADO Diseño El objetivo final del diseño es producir un Modelo Lógico del sistema a implementar. Diferencia entre Análisis y Diseño del Proceso Unificado Modelo de Análisis Modelo
Más detallesINGENIERÍA DEL SOFTWARE I Práctica 5 Modelado de Diseño
INGENIERÍA DEL SOFTWARE I Práctica 5 Modelado de Diseño Univ. Cantabria Fac. de Ciencias Patricia López Introducción al Diseño Modelamos la estructura software del sistema (incluida la arquitectura) para
Más detallesElementos Diagramas de Clases Clase:
Diagramas de Clases Un diagrama de clases o estructura estática muestra el conjunto de clases y objeto importantes que forman parte de un sistema, junto con las relaciones existentes entre clases y objetos.
Más detalles1. Asignar Responsabilidades a componentes de software es la habilidad más importante del AOO. Porque:
Análisis y Diseño O.O. Preguntas del diseño : Cómo podrían asignarse responsabilidades a las clases de los objetos? Cómo podrían interactuar los objetos? Qué deberían hacer las clases? Patrones : Ciertas
Más detallesDIAGRAMAS UML ANDRÉS ESTEBAN MARTÍNEZ HUTA CICLO DE VIDA DEL SOFTWARE GLORIA CECILIA RÍOS MUÑOZ
DIAGRAMAS UML ANDRÉS ESTEBAN MARTÍNEZ HUTA CICLO DE VIDA DEL SOFTWARE 10 GLORIA CECILIA RÍOS MUÑOZ INSTITUCIÓN EDUCATIVA GABRIEL GARCÍA MÁRQUEZ MEDELLÍN 2013 DIAGRAMAS Un diagrama es una representación
Más detallesDiagramas De Casos De Uso
Estáticos Diagramas De Casos De Uso Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario.. Por lo tanto los casos de uso determinan los requisitos
Más detallesDiseño arquitectónico 1ª edición (2002)
Unidades temáticas de Ingeniería del Software Diseño arquitectónico 1ª edición (2002) Facultad de Informática objetivo Los sistemas grandes se descomponen en subsistemas que suministran un conjunto relacionado
Más detallesLenguaje de Modelamiento Unificado.
Lenguaje de Modelamiento Unificado. Pontificia Universidad Javeriana What can you Model with UML? 1. Structure Diagrams include: The Class Diagram Object Diagram Component Diagram Composite Structure Diagram
Más detallesContenido. 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo
Tutorial Contenido 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo 1. El proceso Fases soportadas por UML Análisis de requisitos de usuario Análisis de requisitos de software Diseño de la plataforma
Más detalles1. Preparar al estudiante para desarrollar aplicaciones de software utilizando un enfoque orientado a objetos.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA ESCUELA DE CIENCIAS NOMBRE DEL CURSO: Computación y Programación 2 CODIGO: 771 CREDITOS: 5 ESCUELA: Ciencias y Sistemas AREA A LA QUE PERTENECE:
Más detallesIngeniería a de Software CC51A
Ingeniería a de Software CC51A Clase Auxiliar Auxiliar: Andrés s Neyem Oficina 418 de Doctorado aneyem@dcc.uchile.cl 19 de Marzo de 2007 Aspectos Generales Grupo CC51A Diseño Cliente Requisitos Usuario
Más detallesLos diagramas de clases y de objetos sirven para modelar diversos aspectos estructurales o estáticos de un sistema: Modelado - Vocabulario del Sistema
Modelado Los diagramas de clases y de objetos sirven para modelar diversos aspectos estructurales o estáticos de un sistema: Vocabulario del Sistema Distribución de Responsabilidades Semántica de una Clase
Más detallesUML Unifield Modeling Languaje
UML Unifield Modeling Languaje 1 Modelo: Representación abstracta de una especificación, un diseño o un sistema. Generalmente, basada en una visión particular y compuesta por uno o más diagramas. Lenguaje
Más detallesProf. Mariano Mancuso. Sistemas de información y control diagrama de clases
Prof. Mariano Mancuso Sistemas de información y control diagrama de clases UML Qué son los modelos? Para qué sirven los modelos? Cuáles son los modelos de UML? Se usan todos...? Qué son los modelos? Un
Más detallesCristian Blanco
UNIDAD DIDÁCTICA 8. ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS. DIAGRAMAS DE COMPORTAMIENTO En el siguiente enlace tienes una descripción y algunos ejemplos de todos los diagramas UML.: http://jms32.eresmas.net/tacticos/uml/umlindex.html
Más detallesGuía del Curso Analista Programador Java: Business Apps Expert
Guía del Curso Analista Programador Java: Business Apps Expert Modalidad de realización del curso: Número de Horas: Titulación: Online 600 Horas Diploma acreditativo con las horas del curso OBJETIVOS UML
Más detallesProceso Unificado (Iterativo e incremental)
Proceso Unificado (Iterativo e incremental) Proceso Unificado de Desarrollo de Software, I. Jacobson, J. Rumbaugh y G. Booch, Addison-Wesley, 1999 Fases y Flujos de trabajo de los ciclos de vida. Disciplinas
Más detallesDiplomado Programación orientada a objetos con C++ 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 detallesUML (Lenguaje de Modelado Unificado) y Diagramas de Casos de Uso
UML (Lenguaje de Modelado Unificado) y Diagramas de Casos de Uso Los sistemas orientados a objetos describen las entidades como objetos. Los objetos son parte de un concepto general denominado clases.
Más detallesCapacitación adquirida por el alumno al finalizar este modulo
Curso de UML y UP Analiza, modela y diseña sistemas orientado a objetos con UML. Aprende cuándo y cómo utilizar todos los diagramas que forman parte de UML en forma práctica utilizando el Enterprise Architect
Más detallesDIAGRAMAS DE UML. Prof. Wenceslao Chávez Bedoya
DIAGRAMAS DE UML Prof. Wenceslao Chávez Bedoya 1 DIAGRAMAS DEL UML La finalidad de los diagramas es presentar diversas perspectivas de un sistema a las cuales se les conoce como modelo. Muestran diferentes
Más detallesSistemas de Información II Requerimientos. Análisis de Requisitos
Requerimientos El Proceso Unificado Concepción Elaboración Construcción Transición Modelado del Negocio Requerimientos Análisis y Diseño Implementación Prueba Implantación Admón. del Proyecto Iteraciones
Más detallesUML: INTRODUCCIÓN, ORIENTACIÓN a Objetos
1Diseño y Modelado UML UML: INTRODUCCIÓN, ORIENTACIÓN a Objetos - Por qué es necesario el UML - La concepción del UML - Diagramas del UML - Diagrama de clases - Diagrama de objetos - Diagrama de casos
Más detallesDISEÑO DEL SISTEMA DE INFORMACION (DSI)
DISEÑO DEL SISTEMA DE INFORMACION (DSI) El objetivo del proceso de Diseño del Sistema de Información (DSI) es la definición de la arquitectura del y del entrono tecnológico que le va a dar soporte, junto
Más detallesCapítulo 16. Diagrama de Clases UML
Capítulo 16. Diagrama de Clases UML Florentino TORRES M. CINVESTAV-Tamaulipas 15 de Oct del 2012 Florentino TORRES M. (CINVESTAV) 15 de Oct del 2012 1 / 70 1 Capítulo 16. Diagrama de Clases UML Aplicando
Más detallesDesarrollo Orientado a Objetos en Métrica v. 3
Desarrollo Orientado a Objetos en Métrica v. 3 Carlos Rossi Jiménez c 2003 Carlos Rossi Jiménez. Universidad de Málaga p.1/45 Estructura del curso 1. Estructura de Métrica v. 3 2. Técnicas orientadas a
Más detallesTEMA 4. PROCESO UNIFICADO
TEMA 4. PROCESO UNIFICADO Definición El Proceso Unificado de Desarrollo Software es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura
Más detallesTÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN ÁREA SISTEMAS INFORMÁTICOS.
TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN ÁREA SISTEMAS INFORMÁTICOS. HOJA DE ASIGNATURA CON DESGLOSE DE UNIDADES TEMÁTICAS 1. Nombre de la asignatura Ingeniería de
Más detallesDescripción del Curso
Curso Práctico de Modelado de Negocios BPMN con UML Descripción del Curso Durante este curso aprenderás de forma práctica el estándar BPMN (Business Process Management Notation) y las extensiones de UML
Más detallesTEMA 9: DIAGRAMA DE OBJETOS, SECUENCIA Y DESPLIEGUE EN UML
TEMA 9: DIAGRAMA DE OBJETOS, SECUENCIA Y DESPLIEGUE EN UML Diagramas en UML El bloque de construcción básico de UML es un Diagrama Introducción a UML 2 1 Diagrama de Objetos en UML Se utilizan para visualizar,
Más detallesCIDE, SA. RIF: J NIT: MODELO FUNCIONAL
MODELO FUNCIONAL SIGA C O NTE NlD O Introducción Aspectos Conceptuales Definición de modelo Requisitos de un Modelo Funcional Modelando la Funcionalidad del Sistema: Diagrama de Casos de Uso Definición
Más detallesDiagramas de interacción
Tema 6: Diagramas de Interacción Diagramas de interacción Los diagramas de interacción son diagramas que describen cómo grupos de objetos colaboran para conseguir algún fin. Estos diagramas muestran objetos,
Más detallesPROTOCOLO IP. Vicente Sánchez Patón. I.E.S Gregorio Prieto. Tema 1 SRI
PROTOCOLO IP Tema 1 SRI Vicente Sánchez Patón I.E.S Gregorio Prieto Cada dispositivo de una red debe definirse en forma exclusiva. En la capa de red, es necesario identificar los paquetes de la transmisión
Más detallesCapítulo III: MARCO METODOLÓGICO
Capítulo III: MARCO METODOLÓGICO Tipo de Investigación El presente trabajo de investigación, tuvo como propósito el desarrollo de una aplicación experimental que permitió evaluar la operatividad y funcionalidad
Más detallesModelado Básico con Casos de Uso. Diseño de Software Avanzado Departamento de Informática
Modelado Básico con Casos de Uso El Modelo de Casos de Uso La técnica de los casos de uso (inventada por Ivar Jacobson): Objetivo: identificar la funcionalidad de un sistema (requisitos funcionales). Método:
Más detallesLenguajes de marcado para presentación de Páginas web.
CENTRO COLABORADOR FORMACIÓN & CONSULTING ATENEO S.L.U.. Nº 40 30009 DESARROLLO de APLICACIONES con TECNOLOGÍAS WEB R.D. 1531/2011 de 31 de octubre Nivel de Cualificación 3 590 horas UNIDADES de COMPETENCIA
Más detallesM. C. Felipe Santiago Espinosa
M. C. Felipe Santiago Espinosa Junio de 2008 Un sistema empotrado es un procesador, con sus elementos externos que desarrolla una función especifica de manera autónoma. Un sistema empotrado es un sistema
Más detallesIFCD0210 Desarrollo de Aplicaciones con Tecnologías Web
IFCD0210 Desarrollo de Aplicaciones con Tecnologías Web Cualificaciones Profesionales y Certificados de Profesionalidad Ficha Técnica Categoría Informática y Comunicaciones Referencia Precio Horas 9777-1302
Más detallesTema: Herramientas UML, Análisis y diseño UML
Programación II. Guía No.3 1 Facultad: Ingeniería Escuela: Computación Asignatura: Programación II Tema: Herramientas UML, Análisis y diseño UML Objetivos Conocer una herramienta de modelado para la solución
Más detallesDIAGRAMAS DE UML DIAGRAMAS DE CASO DE USO
DIAGRAMAS DE UML DIAGRAMAS DE CASO DE USO Un diagrama de casos de uso es una especie de diagrama de comportamiento. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras
Más detallesTema: Herramientas UML, Análisis y diseño UML
Programación II. Guía 2 1 Facultad: Ingeniería Escuela: Computación Asignatura: Programación II Tema: Herramientas UML, Análisis y diseño UML Objetivo Conocer una herramienta de modelado para la solución
Más detallesRESUMEN DE LAS DIAPOSITIVAS DE BASE DE DATOS 1
RESUMEN DE LAS DIAPOSITIVAS DE BASE DE DATOS 1 ANTES QUE NADA DEFINIR QUE ES UNA BASE DE DATOS: Una base de datos es una colección estructurada de datos, Un sistema de base de datos es una colección de
Más detallesANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CON UML
ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CON UML ( Parte IV ) Ing. Luis Zuloaga Rotta Los Diagramas de Actividades Un diagrama de actividades es una variante de los diagramas de estadostransiciones, organizado
Más detallesDiseño Organizacional
Diseño Organizacional DISEÑO ORGANIZACIONAL 1 Lectura No. 7 Nombre: Estructura y Diseño Organizacional Introducción En esta sesión presentaremos los conceptos que definen la estructura y el diseño organizacional.
Más detallesCapítulo 2.- Marco Teórico
Capítulo 2.- Marco Teórico Describiremos brevemente el Lenguaje de Modelaje Unificado(UML) y el Proceso Unificado. El Lenguaje de Modelaje Unificado (UML) El Lenguaje de Modelaje Unificado tiene un amplio
Más detallesINGENIERÍA DEL SOFTWARE
INGENIERÍA DEL SOFTWARE Sesión No. 11 INGENIERÍA DEL SOFTWARE 1 Nombre: Estereotipos y valores etiquetados de los paquetes Contextualización Los estereotipos dentro de los medios de programación son más
Más detallesSistemas de información Administrativa II
Sistemas de información Administrativa II UNIDAD 1 MSI. José Luis Llamas Cárdenas Ciclo de Vida Proceso de todo sistema de información Sistemas de Información El sistema informativo esta comprendido por
Más detallesCentro Asociado Palma de Mallorca Tutor: Antonio Rivero Cuesta
Capítulo 6 UML Centro Asociado Palma de Mallorca Tutor: Antonio Rivero Cuesta 1 6 UML Lenguaje Unificado de Modelado 6.1 Introducción. El UML es un lenguaje universal de modelado de sistemas que se emplea
Más detallesBASES DE DATOS TEMA 2 MODELOS DE DATOS
SES DE DTOS TEM 2 MODELOS DE DTOS Un modelo de datos es una serie de conceptos que puede utilizarse para describir un conjunto de datos y las operaciones para manipularlos. Hay dos tipos de modelos de
Más detallesEl proceso de diseño. Análisis de tareas
El proceso de diseño Diseño Iteración: Prototipado y Evaluación Técnicas de prototipado Técnicas de evaluación Definir tareas: Análisis de tareas: HTA: Análisis jerárquico de tareas : Diagramas de secuencias
Más detallesIngeniería del Software I
- 1 - Ingeniería del Software I 2do. Cuatrimestre 2005 INTRODUCCIÓN... 2 SEMÁNTICA... 2 NOTACIÓN... 3 ESTADO ACCIÓN... 3 Transiciones Simples... 3 Estados Acción Compuestos... 3 Estados Acción Iniciales
Más detallesAplicaciones de Microsoft Dynamics CRM 4.0
8980B Aplicaciones de Microsoft Dynamics CRM 4.0 Fabricante: Microsoft Grupo: Dynamics Subgrupo: Microsoft Dynamics CRM 4.0 Formación: Presencial Horas: 15 Introducción Este curso con instructor de tres
Más detallesPrograma de actualización profesional ACTI.NET Desarrollo de aplicaciones locales y web con tecnología VB.NET
Programa de actualización profesional ACTI.NET Desarrollo de aplicaciones locales y web con tecnología VB.NET OBJETIVOS: Conocer de las bondades del paradigma de orientación a objetos en.net y su lenguaje
Más detallesCARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES SYLLABUS DE INGENERIA DE SOFTWARE I
Facultad de Ingeniería en Ciencias Aplicadas pag. 1 CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES SYLLABUS DE INGENERIA DE SOFTWARE I 1. Misión: (de la carrera) La Carrera de Ingeniería en Sistemas
Más detallesREDES DE DATOS Modelo OSI. Angélica Flórez Abril, MSc.
REDES DE DATOS Modelo OSI Angélica Flórez Abril, MSc. Jerarquía de protocolos Organización en capas o niveles. El número de capas y sus funciones difieren de red a red. Cada capa ofrece servicios a las
Más detalles4. DIAGRAMAS DE INTERACCIÓN INTRODUCCIÓN DIAGRAMAS DE SECUENCIA Objetos Mensajes
4. DIAGRAMAS DE INTERACCIÓN...37 4.1. INTRODUCCIÓN... 37 4.2. DIAGRAMAS DE SECUENCIA... 37 4.2.1. Objetos...37 4.2.2. Mensajes...38 4.2.3. Creación y destrucción de un objeto...39 4.3. DIAGRAMAS DE COLABORACIÓN...
Más detallesPrograma de actualización profesional ACTI.NET Desarrollo de aplicaciones locales y web con tecnología VB.NET 2010
Programa de actualización profesional ACTI.NET Desarrollo de aplicaciones locales y web con tecnología VB.NET 2010 OBJETIVOS: Conocer de las bondades del paradigma de orientación a objetos en.net y su
Más detallesEl Lenguaje Unificado de Modelado (UML)
El Lenguaje Unificado de Modelado (UML) Enrique Hernández Orallo(ehernandez@disca.upv.es) Cualquier rama de ingeniería o arquitectura ha encontrado útil desde hace mucho tiempo la representación de los
Más detallesDIAGRAMAS DE ACTIVIDAD SESION 9. Cap. 9 Kendall & Kendall Cap 5 Jacobson
DIAGRAMAS DE ACTIVIDAD Cap. 9 Kendall & Kendall Cap 5 Jacobson SESION 9 Ana Mercedes Cáceres mercycaceres@gmail.com Instructora: Carmen Morales Año 2006. OBJETIVOS Representar gráficamente los problemas
Más detallesRequerimientos de Software
Requerimientos de Software Ingeniería de Requerimientos Se define como el proceso de establecer los servicios que el consumidor requiere de un sistema y las restricciones sobre las cuales de funcionar
Más detallesDe Desempeño De Conocimiento SABERES ESENCIALES CONTENIDOS RUTA FORMATIVA Saber Conocer Nociones, Proposiciones, Conceptos Categorías
Facultad Programa Académico Nombre Del Curso Administración e Ingenierias Ingenieria De Sistemas ANÁLISIS DE SISTEMAS Problema? Competencia específica Criterios de Desempeño Saber conocer Saber Ser Saber
Más detallesExamen de Ingeniería del Software / 3º de Informática de Gestión 7 de febrero de 2007
Apellidos: Nombre: Nota: El alumno da su autorización para publicar sus notas tanto en los tablones de la asignatura como en la Web. En caso contrario, recuadre la opción NO. SERÁ NECESARIO OBTENER AL
Más detallesAnálisis y Diseño de Sistemas
Análisis y Diseño de Sistemas Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Clase 6 Modelo de Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar] 1er. CUATRIMESTRE 2006
Más detallesPlanificaciones Análisis de la Información. Docente responsable: GONZALEZ NORBERTO DANIEL. 1 de 6
Planificaciones 7509 - Análisis de la Información Docente responsable: GONZALEZ NORBERTO DANIEL 1 de 6 OBJETIVOS Introducir al alumno en los conceptos fundamentales del desarrollo de sistemas de información
Más detallesDiseño Basado en Componentes. UML aplicado al diseño basado en componentes. Tabla de contenidos. Introducción a UML. Definición e historia
Tabla de contenidos Diseño Basado en Componentes UML aplicado al diseño basado en componentes Introducción a UML Paquetes en UML Implementación de interfaces Diagramas de componentes Diagramas de despliegue
Más detallesSistema electrónico digital (binario) que procesa datos siguiendo unas instrucciones almacenadas en su memoria
1.2. Jerarquía de niveles de un computador Qué es un computador? Sistema electrónico digital (binario) que procesa datos siguiendo unas instrucciones almacenadas en su memoria Es un sistema tan complejo
Más detallesGuía del Curso Técnico en Mantenimiento de CRM: Recursos Empresariales y de Gestión de Relaciones con Clientes
Guía del Curso Técnico en Mantenimiento de CRM: Recursos Empresariales y de Gestión de Relaciones con Clientes Modalidad de realización del curso: Número de Horas: Titulación: Online 160 Horas Diploma
Más detallesTecnológico Nacional de México INSTITUTO TECNOLÓGICO DE SALINA CRUZ
Tecnológico Nacional de México INSTITUTO TECNOLÓGICO DE SALINA CRUZ UNIDAD 2: ENRUTAMIENTO ESTÁTICO Y DINÁMICO ACTIVIDAD: TRABAJO DE INVESTIGACIÓN 1 MATERIA: REDES DE COMPUTADORAS DOCENTE: SUSANA MÓNICA
Más detallesUNIÓN INTERNACIONAL DE TELECOMUNICACIONES RED DIGITAL DE SERVICIOS INTEGRADOS (RDSI) ESTRUCTURA GENERALES
UNIÓN INTERNACIONAL DE TELECOMUNICACIONES UIT-T I.130 SECTOR DE NORMALIZACIÓN DE LAS TELECOMUNICACIONES DE LA UIT RED DIGITAL DE SERVICIOS INTEGRADOS (RDSI) ESTRUCTURA GENERALES MÉTODO DE CARACTERIZACIÓN
Más detallesINDICE Prologo Capitulo 1. Algoritmos y programas Capitulo 2. La resolución de los problemas con computadoras y las herramientas de programación
INDICE Prologo XI Capitulo 1. Algoritmos y programas 1.1. Configuraciones de una computadora 1 1.2. Lenguajes de programación 2 1.3. Resolución de problemas 1.3.1. Fase de resolución del problema 3 1.3.1.1.
Más detallesSistemas Distribuidos: Migración de Procesos
Sistemas Distribuidos: Migración de Procesos Yudith Cardinale Universidad Central de Venezuela Facultad de Ciencias Postgrado en Computación Octubre 2013 Febrero 2014 Objetivos Entender la importancia
Más detallesMETODOLOGÍAS ÁGILES. Proceso Unificado Ágil (AUP) Ingeniería del Software II Análisis de Sistemas
METODOLOGÍAS ÁGILES Proceso Unificado Ágil (AUP) Docentes: Titular: Ing. Ivaniszyn Selva Nieves Rambo, Alice Sueldo, Roberto Integrantes: Osuna, Jessica Marianela Rougoski, Santiago José Ingeniería del
Más detallesINGENIERÍA EN TECNOLOGÍAS DE LA INFORMACIÓN
INGENIERÍA EN TECNOLOGÍAS DE LA INFORMACIÓN HOJA DE ASIGNATURA CON DESGLOSE DE UNIDADES TEMÁTICAS 1. Nombre de la asignatura Modelado de Procesos de Negocios 2. Competencias Dirigir proyectos de tecnologías
Más detalles1.4.1 Inicio de la computadora por primera vez Hay problemas Causas, síntomas y soluciones a posibles averías...
Índice INTRODUCCIÓN...11 CAPÍTULO 1. EXPLOTACIÓN DE SISTEMAS MICROINFORMÁTICOS...13 1.1 La arquitectura de los ordenadores...14 1.1.1 La máquina de Turing...14 1.1.2 La arquitectura Harvard...15 1.1.3
Más detallesSISTEMAS OPERATIVOS MONOPUESTO 1. CONTENIDOS MÍNIMOS PARA LA EVALUACIÓN POSITIVA
1ª evaluación DEPARTAMENTO MATERIA CURSO INFORMATICA SISTEMAS OPERATIVOS MONOPUESTO 1º S.M.R 1. CONTENIDOS MÍNIMOS PARA LA EVALUACIÓN POSITIVA Caracterización de sistemas operativos: Utilización de sistemas
Más detallesDiseño. Diseño. Interacción. Aspectos comunes en interacción. Diagramas de Interacción. Curso de Arquitecturas de Software
Curso de Arquitecturas de Software Programación Orientada a Objetos Diagramas de Interacción Diseño En la fase de diseño se hace refinamiento estructural, se modifica y completa el diagrama de clases del
Más detallesCurso Microsoft SharePoint Server 2010 Designing and Developing Applications (10232)
Curso Microsoft SharePoint Server 2010 Designing and Developing Applications (10232) Programa de Estudio Curso Microsoft SharePoint Server 2010 Designing and Developing Applications (10232) Aprende a diseñar
Más detallesAnálisis y Diseño de Sistemas
Análisis y Diseño de Sistemas Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Clase 10 Modelo Dinámico Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar] 1er. CUATRIMESTRE
Más detallesGestion y Modelación de Datos Introducción
Gestion y Modelación de Datos Introducción Julio de 2011 Contenido Gestión y Modelación de Datos Descripción del Curso Bases de Datos Definición - Funcionalidades Modelos de Datos DDLs, DMLs Descripción
Más detallesINFORMÁTICA Y COMUNICACIONES
GRADO MEDIO Técnico en Sistemas Microinformáticos y Redes GRADO SUPERIOR Técnico Superior en Administración de Sistemas Informáticos en Red Técnico Superior en Desarrollo de Aplicaciones Multiplataforma
Más detallesde Procesos de Negocio 4. Productos de la ingeniería del software 5. Procesos de la ingeniería del software
1. Características del software 2. Problemas de Introducción la al Modelado industria del software 3. La necesidad de una ingeniería del software de Procesos de 4. Productos de la ingeniería del software
Más detallesProtocolos y funcionalidad de la capa de Aplicación
Protocolos y funcionalidad de la capa de Aplicación Aspectos básicos de networking: Capítulo 3 1 Objetivos Definir la capa de aplicación como el origen y el destino de los datos para la comunicación a
Más detallesCasos de Uso. Introducción. Actores
Casos de Uso Introducción Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Representan las funciones que un sistema puede ejecutar. Por tanto
Más detallesTEMA 5. Otras arquitecturas distribuidas III. Otros entornos de objetos distribuidos
TEMA 5. Otras arquitecturas distribuidas III. Otros entornos de objetos distribuidos III. Otros entornos de objetos distribuidos 1. Problemas de CORBA 2. Java Enterprise Edition 1. EJB 2. Servidor de aplicaciones
Más detallesARQUITECTURAS PARA PROCESAMIENTO PARALELO
1 de 6 27/11/11 13:08 ARQUITECTURAS PARA PROCESAMIENTO PARALELO Facultad de Ingeniería de Sistemas Información para el Proyecto REYCYT RESUMEN Se presenta información general relativa a las diferentes
Más detallesBASES DE DATOS TEMA 1 PERSPECTIVA DEL ÁREA DE BASES DE DATOS
BASES DE DATOS TEMA 1 PERSPECTIVA DEL ÁREA DE BASES DE DATOS 1.3 Desarrolladores y usuarios finales Siendo entonces una DB una colección de datos almacenados en una computadora (discos, tambores u otro
Más detallesUNIVERSIDAD AUTÓNOMA DE CHIAPAS LICENCIATURA EN SISTEMAS COMPUTACIONALES
UNIVERSIDAD AUTÓNOMA DE CHIAPAS LICENCIATURA EN SISTEMAS COMPUTACIONALES Área de formación: Disciplinaria Unidad académica: Programación Orientada a Objetos Ubicación: Cuarto Semestre Clave: 2087 Horas
Más detallesSoluciones de administración de clientes e impresión móvil
Soluciones de administración de clientes e impresión móvil Guía del usuario Copyright 2007 Hewlett-Packard Development Company, L.P. Windows es una marca comercial registrada de Microsoft Corporation en
Más detallesFICHA PÚBLICA DEL PROYECTO
NUMERO DE PROYECTO: 218824 EMPRESA BENEFICIADA: MICROCALLI DEL GOLFO S.A DE C.V TÍTULO DEL PROYECTO: LÍNEA DE PRODUCTOS DE SOFTWARE PARA DOMÓTICA OBJETIVO DEL PROYECTO: Incorporar el paradigma de LPS como
Más detallesT3-Análisis y Diseño del Sistema Software
UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA T3-Análisis y Diseño del Sistema Software Gómez Carretero, Ana Isabel Oliver Donoso, Eulalio Rivas García, Bibiano Rivero Alberca, Elena
Más detallesINTERFACES INTELIGENTES. ING. MA. MARGARITA LABASTIDA ROLDÁN E mail:
INTERFACES INTELIGENTES ING. MA. MARGARITA LABASTIDA ROLDÁN E mail: magielr@gmail.com GENERALIDADES DE LAS INTERFACES INTERFAZ DE USUARIO: Es el dispositivo por medio del cual un usuario realiza la comunicación
Más detallesComunicación de Datos I Profesora: Anaylen López Sección IC631 MODELO OSI
Comunicación de Datos I Profesora: Anaylen López Sección IC631 MODELO OSI Arquitectura de Redes Definición Formal: Se define una arquitectura de red como un conjunto de niveles y protocolos que dan una
Más detallesIntroducción a la Orientación a Objetos
Introducción a la Orientación a Objetos Breve historia de la OO 1960s. Simula incorpora características propias de la OO. 1970s. Smalltalk. Lenguaje totalmente OO. 1990s. Boom de la OO. 2000-Hoy. Época
Más detallesUNIDAD 1: CONCEPTOS BA SICOS DE BASE DE DATOS
UNIDAD 1: CONCEPTOS BA SICOS DE BASE DE DATOS [Escriba el subtítulo del documento] Qué es un gestor de base de datos? Un gestor de base de datos o sistema de gestión de base de datos (SGBD o DBMS) es un
Más detallesBUENAS PRACTICAS EN DESARROLLO DE SOFTWARE APUNTES DE UNA EXPERIENCIA
BUENAS PRACTICAS EN DESARROLLO DE SOFTWARE APUNTES DE UNA EXPERIENCIA Contenido Una metodología para el desarrollo de software debe ser un instrumento que permita gestionar un proceso dado, existen hoy
Más detallesHERENCIA Y TIPOS. Articulo. Video Audio Altavoces. Amplificador
HERENCIA Y TIPOS. Las clases con propiedades y funciones comunes se agrupan en una superclase. Las clases que se derivan de una superclase son las subclases. Las clases se organizan como jerarquía de clases.
Más detallesSEMESTRE: CREDITOS: 3 Horas Presénciales: 3 Horas de Acompañamiento: 1 Total Horas Semanales 4 CODIGO: Sistemas de Información
NÚCLEO DE CONTENIDO: Ingeniería Aplicada NÚCLEO DE CONOCIMIENTO: Sistemas de Información NUCLEO TEMÁTICO: Ingeniería de Software-I SEMESTRE: VI CREDITOS: 3 Horas Presénciales: 3 Horas de Acompañamiento:
Más detallesMS_ Enabling and Managing Office 365.
Enabling and Managing Office 365 www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, CDMX. Tel/Fax: 52785560 Por favor no imprimas este documento si no es necesario.
Más detalles20483 Programación en C#
20483B 20483 Programación en C# Fabricante: Microsoft Grupo: Desarrollo Subgrupo: Microsoft Visual Studio 2012 Formación: Presencial Horas: 25 Introducción Este curso enseña a los desarrolladores las habilidades
Más detallesCurso Taller de Arquitectura de Software usando UML
Curso Taller de Arquitectura de Software usando UML Presentación: Este curso comprende las técnicas necesarias para el modelamiento de sistemas a través de los diagramas definidos por UML (Unified Modelling
Más detalles