ODMG (Object Data Management Group)
Ejemplos de uso de Bases de Datos Orientadas a Objetos en la Industria
La siguiente presentación muestra 5 ejemplos de uso de Bases de Datos Orientadas a Objetos en la Industria.
Las 13 Características de un SGBDOO
Las características de un Sistema Gestor de Bases de Datos Orientado a Objetos son:
1.-Debe soportar objetos complejos. Debe ser posible construir objetos complejos aplicando constructores a objetos básicos.
2.-Identidad del objeto. Todos los objetos deben tener un identificador, el cual es independiente de los valores de sus atributos.
3.-Encapsulamiento. Los programadores solo tienen acceso a la interfaz de los métodos, y los datos e implementación de estos métodos están en los objetos.
4.-Tipos o clases. El esquema de una base orientada a objetos contiene un conjunto de clases o tipos.
5.-Tipos o clases deben ser capaces de heredar de sus super-tipos o superclases los atributos y los métodos.
6.-La sobrecarga debe ser soportada, los métodos deben poder aplicarse a diferentes tipos.
7.-El DML debe ser completo. El DML en los sistemas gestores de bases de datos orientados a objetos debe ser un lenguaje de programación de propósito general.
8.-El conjunto de tipos de datos debe ser extensible. No habrá distinción entre los tipos definidos por el usuario y los tipos definidos por el sistema,
9.-Persistencia de datos. Los datos deben mantenerse después de que la aplicación que los creó haya finalizado, el usuario no tiene que hacer copia explícitamente.
10.-El SGBD debe ser capaz de manejar bases de datos grandes.
11.-El SGDB debe soportar la concurrencia. Debe disponer del mecanismo para el control de la concurrencia.
12.-Recuperaci¢n. El sistema gestor debe de proveer mecanismos de recuperación de la información en caso de fallo de sistema.
13.-El SGDB debe proveer de manera fácil de hacer consultas.
First PC – Manual de usuario
El siguiente manual muestra los puntos más importantes relacionados con la configuración del sitio e información necesaria para poder registrarse en en sitio y por tanto, comprar y realiar pedidos.
Listo! First PC en línea
First PC es un sistema online dedicado principalmente a la venta de equipo de cómputo.
El hosting elegido fue de zobyhost.com, a razón de que brindan un excelente servicio de hospedaje, manejo de bases de datos en MySQL y ejecución de código PHP.
Visitar página principal de First PC.
Ejemplo Manual Técnico – “First PC”
En el siguiente manual técnico se especifican los diagramas generales (ER, Relacional), Diccionario de datos, Variables, Librerías Flujograma y Restricciones, entre otros, del proyecto “FirstPC”, un sistema online de venta de equipo de cómputo mediante programación en php y conexión a base de datos en MySQL:
Creación del Manual Técnico
La creación de un manual técnico compone el desarrollo de los siguientes puntos:
1. Historia
2. Introducción
3. ERS (especificación de requerimientos del software)
4. Diagrama general (m .entidad-relación, diagrama de contexto)
5. Diccionario de datos.
6. Diagrama relacional
7. Definición de variables de ambiente y librerías.
8. Programas especiales y de ambiente
9. Flujo grama de información proceso actividad
10. Restricciones o límites de la programación.
Las especificaciones de la creación del Manual Técnico se encuentran en el siguiente documento:
Ejemplo ERS – Proyecto “First PC”
El siguiente documento muestra la Especificación de Requerimientos de Software de un sistema destinado a la venta de equipo de cómputo mediante una pagina Web en php con conexión en MySQL.
¿Que es un ERS?
¿Por qué y para qué documentar los requerimientos de software?
El desarrollo de un software a medida cuesta mucho dinero y tiempo. Estadísticamente el 80% de los softwares a medida fracasan por causa de fallas en la planificación, en muchos casos porque:
- cumplen los requerimientos a medias, o
- no funcionan correctamente, o
- son demasiado caros de mantener y actualizar, o
- se vuelven obsoletos antes de lo esperado
- etc
Para evitar todos estos problemas es necesario comenzar con la definición de requerimientos:
- Para definir cláramente lo que necesitas sin ambigüedades, evitando omisiones importantes (en la etapa de planificación), que luego son difíciles de abordar (en la etapa de desarrollo)
- Para pedir presupuestos a programadores o empresas de desarrollo de software, al mismo tiempo y evaluar diferentes propuestas
- Para conocer la complejidad, dimensión y alcances del sistema web a desarrollar
- Para poder establecer prioridades funcionales y un plan de escalabilidad
- Para no arriesgar recursos y dinero en vano
- Para exigir estándares de calidad de Software
Cualidades o características esperables en la expresión de requerimientos de software (SRS)
Los requerimientos bien formulados deben satisfacer varias características. Si no lo hacen, deben ser reformulados hasta hacerlo.
- Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
- No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.
- Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos importantes
- Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos debe ser consistente también.
- Completo: Los requerimientos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.
- Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.
- Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.
Estas características suelen ser subjetivas, es decir, no pueden ser calculadas de forma automática por ningún sistema. Por ello, se tiende a medir otras métricas o indicadores que sí que pueden ser calculados de forma automática y que, de algún modo, pueden sustituir o mapear con esta lista de características.
“Preferiría hacerlo yo mismo”
Actividad de Consultoría 4.1
“Preferiría hacerlo yo mismo”
En el siguiente documento se encuentra un ejemplo de consultoría y análisis de la problemática que se intenta resolver al momento de analizar y dseñar un sistema, en este caso, Yumtime Food.
Diagramas Entidad-Relación
En el siguiente video se muestran tres diferentes tipos de creación de diagramas entidad relación.
- Modelo Híbrido
- Diagrama ER (común)
- Diagrama ERE (extendido)
Bases de Datos
Las bases de datos no son tan solo una colección de archivos. Mas bien, una base de datos es una fuerte central de datos destinados a compartirse entre muchos usuarios para diversidad de aplicaciones.
Objetivos de efectividad de la base de datos
- Asegurar que los datos se puedan compartir entre los usuarios para una diversidad de aplicaciones.
- Mantener datos que sean exactos y consistentes.
- Asegurar que todos los datos requeridos por las aplicaciones actuales y futuras se podrán acceder con facilidad.
- Permitir a la base de datos evolucionar conforme aumentan las necesidades de los usuarios.
- Permitir a los usuarios construir su vista personal de los datos, sin preocuparse por la forma en que los datos se encuentran almacenados físicamente.
Ejemplo Entidad-Relación
La Ley de FITT
Esta ley es la más básica y conocida entre las leyes de interfaces de usuario.
“Cuanto más grande y más cercano al puntero del ratón esté un objeto, más sencillo es hacer clic sobre él”
Esto es sentido común, pero es ignorado dentro del diseño de Interfaces de Usuario.
Interfaces Innecesarias
Cuando un usuario está trabajando sobre una aplicación, normalmente está concentrado en su trabajo. Suponga el caso de que “una aplicación modernista” facilita automáticamente al usuario la notificación puntual de cada hora mediante un mensaje gráfico o animación. El usuario tiende a distraerse y perder la concentración; llevando esto como consecuencia que el usuario recapitule lo que estaba haciendo.
Utilización de la potencia computacional
1. Utiliza su potencia para ayudar al usuario
2. Hace distinción fácil entre los elementos similares
3. Recuerda las opciones de la aplicación
Libro: Análisis y Diseño [Kendall]
Aqui les dejo el link del libro de “Analisis y diseño de sistemas” de kendall & kendall
Además un resumen del capítulo:
“Diseño de interfaces de usuario”
La fase de estudio preliminar y todo el ciclo de vida de un sistema, comienza con la detección de un problema que incluye al sistema de información actual, o a la necesidad de un sistema de información donde no existía ninguno antes.
La fase termina con la decisión del comité directivo de sistemas (o de un gerente de sistemas de información si es que no se tiene comité) de comenzar o no una investigación de sistemas. Si la decisión es comenzar una investigación, comienza la fase de análisis. El propósito de esta fase es determinar exactamente lo que debe realizar un sistema.
El primer paso es la planeación de proyectos; después sigue una investigación del sistema o un estudio del sistema actual para conocer sus estado, fuerzas y debilidades. El siguiente paso es el análisis del sistema. La información acerca del sistema actual se estudia en detalle, y se entrevista a los usuarios, se toman medidas, se desarrollan pronósticos de necesidades futuras y se toman todos los demás pasos necesarios para determinar lo que el nuevo sistema debe realizar.
Diseño de interfaces de usuario
Antes de implementar los formularios y los informes ahí que diseñar su aspecto para ello es necesario tener en cuenta las siguientes recomendaciones:
1.- Utilizar títulos que sean significativos, y que identifiquen sin ambigüedad el propósito del informe o del formulario
2.- dar instrucciones breves y fáciles de comprender
3.- agrupar y secuenciar los campos de forma lógica
4.- hacer que el formulario sea atractivo a la vista
5.- Utilizar nombres familiares para etiquetar los campos
6.- utilizar terminologías y términos consistentes
7.- hacer un uso razonable y consistente de los colores
8.- dejar un espacio visible para los datos de entrada y delimitarlos
9.- permitir un uso sencio y adecuado del cursor
10.- permitir la dirección carácter a carácter y de campos completos
11.- dar mensajes de error para los valores ilegales
12.- marcar los campos que sean opcionales o en si defecto requisito
13.- dar mensajes a nivel de campo para indicar su significado
14.- dar una señal que indique cuando el informe o formulario está completo
El usuario no está autorizando tu aplicación
La cuestión más básica a considerar en el diseño de interfaces de usuarios es que el usuario no quiere utilizar tu aplicación, quieren haces su trabajo de la forma más rápida y sencilla posible, y la aplicación no es más que otra herramienta para ayudarles a lograrlo
Arquitectura vs Diseño + Ejemplos
Tarea: Arquitectura vs Diseño + Ejemplos
En el siguiente documento se presentan las tres principales áreas que diferencían la arquitectura y el diseño:
- Nivel de abstracción
- Entregables
- Áreas de enfoque
Incluyendo como ejemplos dos potnetes motores de diseño de proyectos de desarrollo en programación orientada a objetos 3d:
- Unity 3d engine 2.6.1
- Unreal Engine 3.0 (Aug 2010)
Arquitectura de Software
La arquitectura de software se basa en los siguientes espectos:
-Uso de componentes.
-La relación entre ellos.
-El ambiente en el que van a trabajar.
También se contemplan los principios o reglas que normarán su diseño y evolución
Una definición de parte de ingeniería de software seria la siguiente:
-Una arquitectura de software es la estructura de ·estructuras” de un sistema, la cual abarca componentes de software, propiedades externas visibles a estos componentes y sus relaciones. (Es lo más alto que se puede tomar en cuenta en el diseño)
¿Por qué es importante la arquitectura?
-R1: Porque las representaciones de la arquitectura de software facilitan la comunicación entre todas las partes interesadas, en el desarrollo de un sistema basado en computadora.
-R2: Destaca decisiones tempranas de diseño que tendrían un profundo impacto en todo el trabajo de ingeniería
-R3: Porque constituye un modelo relativamente pequeño e intelectualmente comprensible de cómo está estructurado el sistema y de cómo trabajan junto con los componentes.
Aplicaciones monolíticas
Son aquellas que conocemos como “aplicaciones de estación”, en otras palabras, interfaces gráficas de usuario –GUI’s-
Son servicios de presentación, negocios y persistencia de datos, en la misma máquina. No hay concurrencia de usuarios.
Arquitectura Cliente-Servidor
Una de sus características es que cuenta con clientes bastantes pesados, aunque esto no es un estándar, dependiendo del lenguaje.
Existen conexiones dedicadas a Bases de Datos mediante esta arquitectura.
Generalmente los protocolos de comunicación son pesados.
Existe ejecución remota de SQL´s.
Existe alta administración y el rendimiento es bajo.
El tráfico en la red puede estar saturado o ser muy alto
Arquitectura Cliente-Servidor Mejorada
Se aplica la lógica de negocios en Bases de Datos.
Existen clientes pesados, aunque tampoco es un estándar.
Las conexiones a las bases de datos se convierten en conexiones dedicadas.
El rendimiento en este tipo de arquitectura es mucho mejor.
Existe una alta administración, baja escalabilidad flexibilidad y portabilidad.
Arquitectura de tres niveles
Reutilización de la lógica de negocios para diferentes clientes o sistemas, son aplicables en este enfoque, se mejora la escalabilidad y la flexibilidad de las aplicaciones
Existe una completa independencia de la base de datos.
Arquitectura vs Diseño
Compone un conjunto de decisiones estratégicas de diseño, lineamientos, reglas y patrones que restringen el diseño y la implementación de un software.
Tercer semana – Diseño Estructurado
Diseño estructuradose refiere a la elección de los componentes, así como la comunicación entre los mismos, para solucionar un problema especificado.
Una vez que se han establecido los requerimientos del software , el diseño del software es la primera de tres actividades técnicas: diseño, codificación, y prueba. Cada actividad transforma la información de forma que finalmente se obtiene un software para computadora válido.
En la figura se muestra el flujo de información durante la fase de desarrollo. Los requisitos del sistema, establecidos mediante los modelos de información, funcional y de comportamiento, alimentan el proceso del diseño. Mediante alguna metodología (en nuestro caso, estructurada basada en el flujo de información) se realiza el diseño estructural, procedimental, y de datos.
- El diseño de datos transforma el modelo del campo de información, creado durante el análisis, en las estructuras de datos que se van a requerir para implementar el software.
- El diseño estructural define las relaciones entre los principales elementos estructurales del programa. El objetivo principal del diseño estructural es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos.
- El diseño procedimental transforma los elementos estructurales en una descripción procedimental del software
Diseño Orientado Al flujo de Datos
En la siguiente presentación se muestra la metodología común del diseño orientado al flujo de datos, dentro del desarrollo de sistemas de información.
Contenido:
- Diseño arquitectónico
- –Determinación del flujo de datos (primera revisión)
- –Diseño arquitectónico en el cliente
- ——Descomposición de primer nivel
- ——Descomposición de segundo nivel
- –Diseño arquitectónico en el servidor
- ——Descomposición de primer nivel
- ——Descomposición de segundo nivel
- Postproceso de diseño
- –Descripción de módulos en el cliente
- ——Limitaciones en el modelo del cliente
- –Descripción de módulos en el servidor
- ——-Limitaciones en el modelo del servidor
- Diseño de la interfaz
- –Notas previas
- –Consideraciones sobre el diseño de la interfaz hombre-máquina
Cuadro Sinóptico – Diseño de sistemas
En el siguiente cuadro sinóptico se muestra la metodología y puntos clave del diseño de los tipos de sistema más comunes dentro del ámbito del desarrollo:
Sistemas de escritorio:
Consiste en la elección de arquitectura, (ya sea Micronúcleo. Multihilos. Multiproceso Simétrico. Sistemas Operativos Distribuidos. Diseño Orientado a Objetos.Visión de requisitos). Administrando la Capa de Abstracción de Hardware (HAL), el Ejecutor del SO Administrador de Objetos, procesos y Memoria, entre otros.
Sistemas para la Web:
La Perspectiva de Aplicación, como la Descripción de las aplicaciones existentes y los recursos para definir el flujo de la cadena, incluyendo los recursos de programación, implementado en un lenguaje de definición del flujo.
Sistemas para dispositivos móviles:
Denota al individuo y las interacciones del equipo de desarrollo , junto con los procesos y las herramientas.
Tiene que haber una interacción constante entre el cliente y el equipo de desarrollo, buena respuesta ante el cambio (más importante que el seguimiento de un plan) y la planificación no debe ser estricta sino flexible y abierta.
Clic en la imagen para ver el cuadro sinóptico:
Fuente:
http://www.adamwesterski.com/wp-content/files/docsCursos/Agile_doc_TemasAnv.pdf
http://www.essi.upc.edu/~gomariz/index_archivos/IntroduccionSD-EnricMartinez.pdf
http://www.monografias.com/trabajos26/arquitectura-windows/arquitectura-windows.shtml
Ensayo – Diseño Físico y Lógico – U1
El siguiente ensayo complementa la información referida a la unidad 1 de Sistemas de Información 2, que explica las diferentes etapas del desarrollo de sistemas de información, como lo son el análisis, diseño, implementación, pruebas y validación.
Ensayo – Diseño Físico y logico
Segunda semana del curso
DISEÑO DE SISTEMAS
El Diseño de Sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en función de aquella configuración que tenga más posibilidades de satisfacer los objetivos planteados tanto desde el punto de vista funcional como del no funcional (lo que antes hemos denominado constricciones). El proceso de diseño de un sistema complejo se suele realizar de forma descendente:
* Diseño de alto nivel (o descomposición del sistema a diseñar en subsistemas menos complejos)
* Diseño e implementación de cada uno de los subsistemas:
- Especificación consistente y completa del subsistema de acuerdo con los objetivos establecidos en el análisis
- Desarrollo según la especificación
- Prueba
* Integración de todos los subsistemas
* Validación del diseño
DESARROLLO DE SOFTWARE
Cuando se va desarrollar un software intervienen muchas personas como lo es el cliente quien es el que tiene el problema en su empresa y desea que sea solucionado, para esto existe el analista de sistema quien es el encargado de hacerle llegar todos los requerimientos y necesidades que tiene el cliente a los programadores quienes son las personas encargadas de realizar lo que es la codificación y diseño del sistema para después probarlo y lo instalan al cliente.
PRUEBAS DEL SISTEMA
Consiste en la aplicación de un programa con la intención de descubrir un error técnica experimental para la búsqueda de errores en los programas, sencillamente es donde al sistema se pone a prueba lo dice para así poder saber cuáles son los posibles errores que se están generando del sistema y con ello mejorarlo para eliminar todos los errores que se puedan presentar, puesto que un programa con menor índice de errores llega a tener un cierto grado de calidad.
IMPLEMENTACION
La implementación de un sistema de software consiste en la puesta en funcionamiento masiva de la aplicación en el lugar donde se encuentra el usuario final. Una puesta en funcionamiento exitosa en los sitios pilotos no significa que automáticamente la puesta en funcionamiento general sea exitosa.
Coherencia de software (cohesión)
La cohesión tiene que ver con la forma en la que agrupamos unidades de software en una unidad mayor. Por ejemplo, la forma en la que agrupamos funciones en una librería, o la forma en la que agrupamos métodos en una clase, o la forma en la que agrupamos clases en una librería, etc.
Se suele decir que cuanto más cohesionados estén los elementos agrupados, mejor. El criterio por el cual se agrupan es la cohesión.
Veremos los distintos tipos de cohesión, de la que se considera mayor cohesión a la que se considera menor.
Nuevamente, los nombres no son demasiado importantes, basta saber que a la hora de decidir por qué criterio agrupar, unos suelen dar mejores resultados que otros desde el punto de vista de la modularidad.
La cohesión no tiene tanto impacto sobre la modularidad como el acoplamiento. Es decir, un gran acoplamiento puede ser muy malo a la hora de corregir errores, integrar partes, hacer mantenimientos… Sin embargo, una cohesión baja puede ser incómoda, pero no suele plantear grandes problemas. Aunque esto, no es motivo para descuidarla.
1) Cohesión funcional. Se produce cuando agrupamos unidades de software teniendo en cuenta que todas ellas contribuyen a realizar un mismo fin. Es decir, cuando todas las unidades agrupadas, trabajando juntas consiguen un objetivo. En general, es el criterio de agrupación más deseable. Además, entre este tipo de unidades suele haber un acoplamiento relativamente alto, así que mejor que estén juntas.
2) Cohesión secuencial. Cuando agrupamos unidades que cumplen que los resultados que produce una son los que utiliza otra para continuar trabajando. Es decir, los datos de salida de una sirven de entrada para otras. Es una forma de agrupar muy relacionada con el problema que se está tratando de resolver.
3) Cohesión de datos. Cuando todas las unidades agrupadas trabajan sobre el mismo conjunto de datos.
4) Cohesión lógica. Cuando todas las unidades agrupadas realizan trabajo en una misma categoría lógica, pero no necesariamente tienen relación unas con otras. Por ejemplo, librerías de funciones matemáticas… se agrupan simplemente porque realizan cálculos matemáticos, pero no necesariamente tienen relación unos con otros.
5) Cohesión temporal. Este criterio empieza a ser algo peor. Significa que agrupamos una serie de unidades simplemente porque tienen que ejecutarse más o menos en el mismo periodo de tiempo, pero sin que tengan una relación mayor entre ellas… es decir, sin que contribuyan al mismo fin (funcional), sin que se pasen datos en secuencia (secuencial) y sin que ni tan siquiera trabajen sobre los mismos datos (de datos) ni caen dentro de una misma categoría (lógica). Simplemente, tienen que ejecutarse cerca unas de otras.
6) Cohesión casual. Pues cualquier criterio que no caiga dentro de los anteriores se considera ya puramente casual. Mejor evitarla a toda costa.
En resumen, mantener el acoplamiento lo más bajo posible y la cohesión lo más alta posible suele ser el objetivo de todo arquitecto, diseñador o programador. Tener unos buenos criterios para agrupar unidades de software (alta cohesión), y mantener esas unidades lo más independientes posible (bajo acoplamiento) garantiza la modularidad, facilitando la reutilización del software y gran parte de las tareas del desarrollo del sofware.
fuente:
http://latecladeescape.com/w0/ingenieria-del-software/acoplamiento-y-cohesion.html
Ejemplos de acoplamiento de software
Acoplamiento de software se refiere a el nivel de dependencia entre las unidades de software de un sistema informático, es decir, el grado en que una unidad puede funcionar sin recurrir a otras; dos funciones son absolutamente independientes entre sí (el nivel más bajo de acoplamiento) cuando una puede hacer su trabajo completamente sin recurrir a la otra. En este caso se dice que ambas están desacopladas.
EJEMPLO 1 – SAMBA (from WINDOWS to UNIX)
Samba es una implementación libre del protocolo de archivos compartidos de Microsoft Windows (antiguamente llamado SMB, renombrado recientemente a CIFS) para sistemas de tipo UNIX. De esta forma, es posible que ordenadores con GNU/Linux, Mac OS X o Unix en general se vean como servidores o actúen como clientes en redes de Windows. Samba también permite validar usuarios haciendo de Controlador Principal de Dominio (PDC), como miembro de dominio e incluso como un dominio Active Directory para redes basadas en Windows; aparte de ser capaz de servir colas de impresión, directorios compartidos y autentificar con su propio archivo de usuarios.
Entre los sistemas tipo Unix en los que se puede ejecutar Samba, están las distribuciones GNU/Linux, Solaris y las diferentes variantes BSD entre las que podemos encontrar el Mac OS X Server de Apple.
EJEMPLO 2 – WINE (from UNIX to WINDOWS)
Wine acrónimo recursivo en inglés para “Wine Is Not an Emulator”, es una reimplementación de la API de Win16 y Win32 para sistemas operativos basados en Unix. Permite la ejecución de programas para MS-DOS, Windows 3.11, 95, 98, ME, NT, 2000 y XP.
Wine provee de:
- Un conjunto de herramientas de desarrollo para portar código fuente de aplicaciones Windows a Unix.
- Un cargador de programas, el cual permite que muchas aplicaciones para Windows 2.0/3.x/9X/ME/NT/2000/XP/Vista y Win 7 se ejecuten sin modificarse en varios sistemas operativos similares a Linux como GNU/Linux, BSD, Solaris y Mac OS X
fuente:
http://es.wikipedia.org/wiki/Acoplamiento_inform%C3%A1tico
http://www.winehq.org/
http://es.wikipedia.org/wiki/WINE
http://es.wikipedia.org/wiki/Samba_%28programa%29
