Modelamiento en Diseño de Procesos: Introducción

Modelamiento en Diseño de Procesos: Introducción
La asignatura de Modelamiento en Diseño de Procesos trata el problema de analizar procesos complicados en la empresa y construir modelos que los describan y sirvan de base a los diseños lógicos de soluciones computacionales. El objetivo es desarrollar en el alumno las capacidades prácticas para enfrentar el problema de modelamiento, conocer las herramientas teóricas y prácticas así como conceptos fundamentales de la Ingeniería de sistemas para el desarrollo de software de calidad. Se enfatizará la diferencia entre el diseño y modelamiento de sistemas pequeños y grandes, las diferencias metodológicas y cuando aplicar cada una. Se revisarán conceptos generales de modelamiento y Teoría General de Sistemas con su historia, potencialidades y limitaciones. Se estudiarán en extenso los problemas teóricos y prácticos asociados al modelamiento de procesos y datos, las tendencias y problemas de las distintas metodologías para el almacenamiento, recuperación y proceso de los datos.

Que se espera de los alumnos de este curso:
Contenidos: nociones de Teoría de Sistemas, modelamiento, diseño lógico de software para pequeñas y grandes empresas Habilidades: capacidad de exponer ideas, hacer preguntas, discutir, leer y resumir, seguir con atención temas tediosos, responsabilidad, buscar soluciones En las calificaciones tendrán más peso las habilidades y destrezas que los contenidos, por eso tanta ponderación a la participación en clases y casos Aparte de los controles de lectura no se les pedirá memorizar nada, todas las demás notas serán colocadas en clase. La ventaja es que no hay tareas para la casa, la desventaja que no hay segunda oportunidad.

Se enseñarán técnicas para desarrollar prototipos basados en la programación de aplicaciones de uso común en ofimática, el taller de desarrollo de prototipos será parte importante en el desarrollo del curso. Las notas serán de dos casos donde se evaluará la participación. dos controles de lectura y una nota general por participación en clases. Se entiende por participación cada pregunta, opinión, ejemplo, comentario, etc. del alumno, que será registrado y evaluado en una escala de 1 a 3, el alumno con mayor puntaje tendrá la nota 7 y a partir de allí se construirá la escala, si un alumno no participa o no asiste a clases tiene nota 1. Condiciones -Asistencia 80%, en cada clase se deberán firmar la planilla de asistencia, los alumnos que al final del curso no tengan el 80% de asistencia requerida serán reprobados sin que esta decisión sea apelable ante el profesor, solo se puede pedir reconsideración al Jefe de Carrera. Lo mismo se aplica para las pruebas.

Si un alumno no asiste a algún caso o control de lectura tendrá nota 1 a menos que justifique de acuerdo a reglamento, en ese caso su nota se reemplazará por un control de lectura que será XML for Dummies para recuperar controles de lectura Ingeniería de Negocios, Oscar Barros (1ra parte), para recuperar una nota de caso Se estudiará como primer caso la supervisión de un proyecto grande, ya implementado, en el cual los alumnos tendrán que analizar, detectar problemas, proponer soluciones y establecer procedimientos de control de su desarrollo. Para este caso existirá una sesión de Presentación y otra de Análisis y Desarrollo, Los requisitos de la exposición y el análisis pueden verse AQUI Se estudiará como segundo caso el modelamiento y diseño de un sistema para pequeña empresa, en el cual los alumnos tendrán que desarrollar desde cero partiendo por las entrevistas, casos de uso, manual de procedimientos, diseño lógico, documentación y análisis del diseño físico. Este será evaluado como segundo caso.

Planificación de las sesiones
1 Introducción al curso, presentación de los contenidos, evaluación, etc. 2 Fundamentos de la Teoría General de Sistemas 3 Fundamentos de la Teoría General de Sistemas 4 Conceptos básicos de la Ingeniería de Sistemas 5 Caso Gobierno Local de Santa. Exposición 6 Caso Gobierno Local de Santa. Desarrollo y análisis 7 Introducción a los archivos y bases de datos 1 8 Introducción a los archivos y bases de datos 2 9 Control de lectura 1: Graphical Entity Relationship Models 10 Modelos Entidad-Relación 11 Introducción a la orientación a objetos 1 12 Introducción a la orientación a objetos 2 13 Control de lectura 2: ERP Systems tutorial page 14 Introducción al modelo de negocios SAP 15 Unified Modelling Language 1

16 Unified Modelling Language 2 17 Unified Modelling Language 3 18 Unified Modelling Language 4 19 Fundamentos del BPMN 20 Herramientas computacionales: Bizagui, Visio 21 Trabajo Bizagui aplicado al caso GLS 22 Herramientas computacionales: VBA, OOBaSIC 1 23 Herramientas computacionales: VBA, OOBaSIC 2 24 Herramientas computacionales: VBA, OOBaSIC 3 25 Herramientas computacionales: VBA, OOBaSIC 4 26 Caso Bar Delirios, exposición 27 Caso Bar Delirios, desarrollo 28 Caso Bar Delirios diseño

Controles de lectura opcionales (para notas recuperativas)
XML for Dummies Ingeniería de Negocios, Oscar Barros (1ra parte) Nota por participación en clase Se registrará en cada clase la participación de los alumnos, que serán evaluadas por cantidad y calidad en una planilla. Estas participaciones se promediarán y será una de las notas de evaluación total del curso con un peso de 25%. La evaluación total se compondrá de la siguiente forma: Controles de lectura Se tomarán dos controles de lectura sobre textos cortos en idioma inglés referidos al modelamiento, ambas notas formarán un 25% de la evaluación total Evaluación Caso Gobierno Local Santa 25% Controles de lectura 25% Caso Bar Delirios 25% Participación en clases 25%

FUNDAMENTOS DE LA TEORIA GENERAL DE SISTEMAS
Tomás Bradanovic P.

CURSO DE MODELAMIENTO EN DISEÑO DE PROCESOS http://modelamientouta
TEORIA TGS, Modelamiento de datos, Gestión de datos, Bases de Datos, diseño en capas, modelos entidad-relación, UML, orientación a objetos, modelos conceptuales, modelos evolutivos, modelos en cascada, análisis y diseño PRACTICA Casos, Diseño de entrevistas, modelado por prototipos, uso VBA para crear prototipos, mejora de procesos, microaplicaciones, persistencia, implementación ¿Alguna idea previa respecto de que se trata el curso?

Fundamentos de la Teoría General de Sistemas Historia Galileo, Dos Nuevos Sistemas, el problema del colapso, por ejemplo de una viga soportada en sus extremos ¿que largo puede tener sin que se caiga bajo su propio peso?. Los modelos físicos (maquetas) pese a ser exactamente proporcionales no servían para predecir problemas de resistencia y colapsos, por ejemplo el problema de hacer un barco grande o un edificio de varios piso sin saber si va a resistir o no. Galileo desarrolló modelos matemáticos para describir la mecánica y la resistencia de materiales. Las matemáticas eran muy primitivas: geometría, lógica, aritmética básica, así es que los modelos resultaron complicadísimos, sin embargo muchas de sus demostraciones siguen siendo fundamentos de la mecánica clásica. Otros ejemplos de modelos físicos Explicación de por qué no siempre funcionan

La idea de los modelos seguramente ha existido desde siempre: un muñeco es un modelo de ser humano, un calendario es un modelo de los movimientos del sol, en el folklore existe la idea de hacer miniaturas de las cosas para representarlas e influenciar sobre ellas (ekekos, alasitas). Las matemáticas aplicadas son el lenguaje de la ciencia y la herramienta más poderosa para modelar, una ecuación puede ser un modelo de algo real (por ejemplo la trayectoria de una bala de cañón está descrita casi exactamente por la ecuación de la parábola o las ondas de sonido por una ecuación tipo y=K*sen(x+algo), los modelos matemáticos son los más poderosos y exactos para problemas más o menos simples. Otros ejemplos de ecuaciones para predecir Probablemente el estudio de los fenómenos ondulatorios dió mucho impulso a la Teoría General de Sistemas: fenómenos completamente distintos como las ondas en el agua al caer una piedra, el movimiento del péndulo de un reloj, un sonido propagándose por el aire, las ondas e luz o de radio obececen todas a ecuaciones del tipo y=K*sen(x+algo), o sea fenómenos muy disintos compartían el mismo modelo matemático. También se observaron en física muchas analogías entre fenómenos muy distintos que podían representarse con un mismo modelo, por ejemplo la analogía entre un sistema hidráulico y uno eléctrico. Todas estas analogías y similitudes llevaron a formular en los años 30 la Teoría General de Sistemas basada en ciertos conceptos básicos: Explicación y ejemplos de analogías

Los sistemas tienen características comunes a todos 2
Los sistemas tienen características comunes a todos 2. Por lo anterior la TGS es integral, abarca todo lo que existe: sistemas físicos, químicos, biológicos, sociales, económicos, etc. uno se puede aproximar a cualquier fenómeno usando un enfoque de sistemas, que es una forma de aproximarse a la realidad 3. Un sistema se puede modelar como una caja negra, que tiene entradas, las procesa, entrega salidas y a veces se realimenta. El concepto de caja negra es algo que estudiamos desde afuera, sin importarnos como funciona internamente, solo nos interesa saber que pasa con las entradas (estímulos) y con las salidas (respuestas) del sistema. Realimentación SISTEMA Entradas Salidas Ejemplos de cajas negras con sus entradas y salidas

Cuando se trata de conocer lo que pasa dentro de la caja negra estudiando como se modifican las salidas en función de las entradas eso se llama Ingeniería Reversa Ejemplos de ingeniería reversa Un computador es un ejemplo clásico de caja negra: lo alimentamos con información y obtenemos respuestas sin tener idea del detalle de los millones de operaciones intenas involucradas ni como funcionan. Cuando usamos el computador lo hacemos con el enfoque sistémico, es decir de caja negra. Supongamos que necesito traducir un párrafo en inglés, voy al computador y entro al traductor en línea Babelfish, ingreso el párrafo (o sea alimento la caja negra con una entrada), cliqueo los botones adecuados y obtengo mi traducción.(o sea mi salida) ¿es necesario saber en detalle como opera el computador o como funciona el algoritmo traductor?, claro que no, para eso es el sistema de caja negra, los procesos de detalle lo hacen otros y nosotros no tenemos para que saber como funcionan: sería muy ineficiente si todos tuvieramos que aprender en detalle como funciona cada cosa. El concepto de caja negra es muy importante, volveremos sobre él a menudo.

4. Los sistemas pueden ser reales, que existen independientemente de nosotros y los podemos descubrir o no, ejemplos de sistemas reales son el clima, la economía, los organismos, etc. todo lo que tiene independencia de nosotros. También existen los sistemas ideales que solo existen en el intelecto, por ejemplo la lógica, las matemáticas, etc. Finalmente existen los modelos que son abstracciones de la realidad. Los modelos son el tipo de sistema que estudiaremos en este curso. 5. Un modelo es una abstracción de la realidad, una representación simplificada, exprimida de algo real a la que le hemos sacado todo lo irrelevante y le hemos dejado solo lo que más nos importa. Lo que es "relevante" o "irrelevante" es completamente relativo a lo que nos interesa obtener de nuestro modelo. En un muñeco lo relevante será que tenga un parecido físico con lo real, en el modelo de un puente lo relevante será que las características de resistencia, flexibilidad, etc sean parecidas, en el modelo de un negocio lo relevante puede ser las cantidades de dinero y como se comportan bajo distintas condiciones. Ejemplos de sistemas reales, ideales, modelos

6. Los sistemas tienen a su vez subsistemas y también son parte de sistemas mayores. Por ejemplo el sistema de contabilidad de una empresa tiene distintos subsistemas (cuentas por cobrar, caja, activos, pasivos, etc.) pero también es parte de otros sistemas mayores (las finanzas de la empresa, las finanzas de la ciudad, del país, etc.). Por eso en la TGS es importante definir el ámbito de acción, o sea las fronteras dentro de las cuales estudiaremos un sistema. Ejemplos de subsistemas y supra-sistemas La TGS tiene dos campos de actividad: Investigar el isomorfismo de conceptos, leyes y modelos en varios campos y facilitar las transferencias entre aquellos. promoción y desarrollo de modelos teóricos en campos que carecen de ellos y reducir la duplicación de los esfuerzos teóricos,. promoviendo la unidad de la ciencia a través de principios conceptuales y metodológicos unificadores. Ejemplos de isomorfismo

LA ANALOGIA ELECTRO HIDRAULICA

MODELAMIENTO Competencia que un ingeniero debe poseer: captar una cierta problemática y poder representarla en algún modelo usando, por ejemplo el lenguaje de modelación UML o un gráfico entidad relación. El proceso de abstracción es una constante en el desarrollo de actividades que involucran el modelamiento. Este proceso es difícil de enseñar en términos tradicionales, es más bien una capacidad que los estudiantes ya traen y que es necesario orientar y potenciar para poder desarrollar las competencias específicas que posibilitarán un desempeño exitoso en el ámbito del modelamiento de sistemas y bases de datos. La asignatura Modelamiento de Datos es una asignatura donde los estudiantes se enfrentan al problema de modelar sistemas administrativos, procesos, problemas de control, etc. Ejemplos de abstracción

Que es La Teoría General de Sistemas Como la Teoría de Conjuntos, la Teoría General de sistemas pretende hacer una abstracción que represente una gran cantidad de cosas distintas. El concepto de "sistema" es muy general, algunas definiciones de lo que es un sistema son: "una cantidad de elementos y relaciones" (Klaus) "una parte de la realidad, observable y que se puede describir" (Muller) “algo que posee elementos, estructura, vecindad, recibe y envia magnitudes concretas a su vecindad" (Semard) Casi cualquier cosa la podemos considerar un "sistema" que además suele tener partes o subsistemas: por ejemplo una industria es un sistema, uno de sus talleres es un sistema parcial de los cuales los operarios de torno serían otro subsistema. También la industria podría ser subsistema de un parque industrial, etc. Ejemplos de sistemas con sus elementos y relaciones (Ej. Ctas. Corrientes, Inventarios)

En la teoría de Sistemas distinguimos a un sujeto que observa y objetos que son estudiados. El sujeto estudia, interpreta y crea conocimientos, pero los objetos suelen tener muchas facetas de estudio y es imposible (además de inútil) estudiar su "realidad total" así se crea un sistema, que es "un análogo de un objeto real". Es decir el objeto y el sistema son dos cosas distintas,: el sistema es una imagen del objeto real que sirve para simplificar su estudio. De aquí deducimos que para un mismo objeto pueden existir diferentes sistemas (abstracciones) que lo representen según que es lo que nos interesa estudiar. La clave de la Teoría de Sistemas consiste en que, si bien todos los sistemas pueden ser distintos, existen estructuras y relaciones que son comunes a muchos de ellos: por ejemplo el movimiento del agua en un río y el comportamiento de una multitud de personas a la salida de un estadio son de una naturaleza material absolutamente distinta, pero se pueden establecer analogías entre ambos fenómenos. En la naturaleza existe una gran cantidad de sistemas análogos y si hacemos abstracción de la realidad material, vemos que muchos sistemas absolutamente distintos se pueden caracterizar por un mismo conjunto de relaciones. Ejemplos de distintos modelos para un mismo fenómeno Ej.-Una ciudad puede tener un modelo vial y otro de seguridad ciudadana

Sistema Elemental (o Elemento Activo) Un sistema elemental tiene a lo menos una magnitud de entrada y una de salida. Veamos un ejemplo práctico, si queremos estudiar el movimiento de la carga que maneja un puerto puedo definir un sistema sencillo que considere la carga que entra al puerto y la que sale de él. Así el complejo sistema llamado "puerto" lo hemos reducido, por abstracción a una "caja negra" a la cual le podemos medir (digamos, en toneladas) la carga que entra para embarque y la carga que se desembarca de los buques. Con este sencillo modelo podemos estudiar, por ejemplo, en que épocas del año hay atochamientos, cuando hay más capacidad ociosa. Nuestro modelo de puerto es un elemento activo que posee una vecindad (los barcos y la ciudad) a la que le entrega determinadas magnitudes (toneladas de carga), la vecindad también le entrega a nuestro puerto magnitudes por lo que ambos interactúan constantemente. ¿Qué otra utilidad podría tener el modelo elemental de puerto?

A nuestro modelo podemos complicarlo agregando otras variables para hacer más exacto nuestro estudio: por ejemplo la cantidad de trabajadores, la capacidad de las bodegas y la disponibilidad de camiones para transportar la carga. Todas esas magnitudes influirán finalmente en la cantidad de carga que en realidad se mueve y también existirán otras magnitudes externas, como los días con marejada que obligan a mantener el puerto cerrado, etc. Así vemos como el comportamiento de nuestro sistema está influenciado por si mismo y por el exterior. Lo importante de este ejemplo es como hemos hecho abstracción de muchas cosas (como el paisaje, la forma de las instalaciones físicas, etc.) para concentrarnos solo en algunas pocas características que nos interesan: hemos creado un modelo que nos será más útil, por ejemplo, que una fotografía o una película. Teniendo nuestro modelo podemos "jugar" con las variables para estudiar que pasaría, si establecemos las relaciones que nos interesan en forma matemática (por ejemplo una función que indique cuanto aumenta la capacidad de movimiento en relación a la capacidad de las bodegas) podemos calcular teóricamente y de antemano si es conveniente o no construir nuevas bodegas. Ventajas y desventajas de agregar muchas variables

Clasificación de los Sistemas Grado de Abstracción Abstractos Reales Ejemplos
Transformación en el tiempo Estáticos Dinámicos Ejemplos Complejidad Simples Complejos Muy complejos Ejemplos

Certeza del comportamiento Determinados Estocásticos (al azar) Ejemplos Linealidad Lineales No lineales Ejemplos Armonía Abiertos Cerrados Ejemplos Estabilidad Estables Inestables Mixtos Ejemplos

Funciones o Relaciones de un Sistema
Cuando hacemos un modelo lo que tratamos es establecer cuales son las relaciones entre las magnitudes de entrada y las de salida. Así, en un modelo abstracto podemos tener varias entradas, varias salidas y una función de sistema que describe matemáticamente como se relacionan las salidas con las entradas, o sea S=T(E) Donde S es el conjunto de las magnitudes de salida, E el conjunto de magnitudes de entrada y T la función que las relaciona. Siguiendo nuestro ejemplo práctico, podríamos establecer (por observación) que al aumentar la cantidad de camiones nuestro puerto aumentará su capacidad de movimiento de carga en un factor de x veces, etc. También existen relaciones de retroalimentación, donde las magnitudes de salida influyen en las de entrada (por ejemplo si los embarques aumentan mucho, entrarán mas empresas de camiones a trabajar al puerto y viceversa) Explicitar las funciones de entrada y salida

Teoría de los Modelos Un modelo fundamentalmente es algo que obtenemos después de un proceso de abstracción, es decir tomamos un sistema real y hacemos una imágen de el, más simple y más clara que el original.. Al construir un modelo tratamos de captar lo que es esencial en el sistema, lo que a nosotros nos interesa estudiar y lo que pensamos que nos servirá para ese estudio. Todo lo demás lo desechamos. Un modelo facilita la comprensión de un sistema complejo, representando lo que es significativo para nuestro estudio, es una imitación de la realidad. Así, tenemos el objeto real, el sujeto que lo estudia y el modelo, que tiene relaciones de analogía o similitud con el objeto real y permite al sujeto obtener conclusiones relativas al sistema.

Clasificación de los Modelos Modelos de Afirmación Describen al sistema usando palabras, se usan en los sistemas más complejos donde no es factible determinar relaciones matemáticas. Estos modelos son muy debilmente predictivos y se limitan a hacer una descripción verbal y cualitativa del sistema. Sin embargo son muy usados en sistemas administrativos Ejemplo Modelos Físicos Son objetos materiales usados para demostración y, en menor medida para experimentación cuantitativa. Ejemplo Modelos Gráficos Son modelos ideales que usan medios de expresión gráfica, Ejemplo Modelos Formales Son los modelos abstractos, matemáticos ampliamente usados en la investigación científica. Consideran los parámetros variables escenciales de un fenómeno y sus relaciones descritas en forma de ecuaciones matemática Ejemplo

Como Modelar Ordenar las opiniones: para modelar se debe primero que nada observar el sistema y recoger información relevante, luego se determina sobre qué base será construído el modelo según las relaciones de analogía que se observen. También en esta etapa se determinará a que objetivo será construido el modelo Elaborar los elementos esenciales y sus acoplamientos el modelo se va conformando de acuerdo a las relaciones de analogía encontradas Experimentar con modelos: se trata de buscar modelos alternativos o variantes del configurado originalmente para ver si se puede perfeccionar la similitud con el comportamiento relevante del modelo real Decidir la solución óptima: de todos los modelos experimentados se escoge al que represente al sistema de la mejor manera para nuestros propósitos Prueba del modelo: se deben diseñar y ejecutar pruebas que confronten la capacidad predictiva del modelo con respuestas conocidas del sistema, de manera de detectar si hay omisiones o errores relevantes Ejemplo: modelar un curso

Tres Técnicas Fundamentales. El método de conclusiones por analogías
Tres Técnicas Fundamentales * El método de conclusiones por analogías * El método de la caja negra * El método de las aproximaciones sucesivas Para obtener conclusiones por analogías consiste en buscar fenómenos semejantes cuya solución sea conocida, comparar sistemas distintos buscando semejanzas o analogías, en su comportamiento, su estructura o su materialidad Ejemplo Para sistemas muy complejos un buen método es el de la caja negra, que consiste en un sistema al que solo podemos influenciar alimentándolo y observando sus reacciones. Así podemos definir un comportamiento "macro" sin entrar a los detalles internos del sistema. El método de la caja negra es muy usado en el modelamiento de sistemas Ejemplo El método de las aproximaciones sucesivas consiste en definir un resultado óptimo y tratar de obtenerlo ingresando magnitudes al azar al sistema, por medio de la prueba y error nos acercaremos al óptimo esperado lo que permitirá encontrar la relación buscada sobre el comportamiento del sistema. Ejemplo

En la Práctica se usan etapas de diseño lógico de los sistemas complicados. Los analistas de sistema son por lo general gente del área de la ingeniería industrial o de la administración ya que, a diferencia de los ingenieros de software el diseño lógico está más cerca de la administración que de la parte relacionada con algoritmos y lenguajes. El trabajo de un analista consiste en estudiar los requerimientos del sistema que se desea diseñar así como los flujos de la información y, en base a eso, entregar su producto que es el diseño lógico, que consiste en diagramas y una lista detallada con las especificaciones que debe cumplir el sistema, una guía de criterios de diseño y procedimientos para que la gente de software se encargue de implementar. En los sistemas pequeños el trabajo de diseño lógico y físico son llevados a cabo por una misma persona y a menudo el proceso de diseño lógico es informal y no deja especificaciones escritas. Sin embargo es recomendable para cualquier diseño, por simple que sea dejar escrita una lista de especificaciones del diseño lógico ya que esta formalización ayudará bastante a quienes tomen posteriormente las tareas de mantención del sistema, esta lista también constituye una salvaguarda contra cambios abruptos de diseño pedidos por el cliente una vez que el sistema está implementado.

CONCEPTOS BASICOS DE INGENIERIA DE SISTEMAS

La ingeniería de software surge frente a la crisis del software detectada a fines de los años 60 cuando los programas comenzaron a crecer en tamaño y complejidad. En un comienzo la programación completa para resolver un problema era hecha por una sola persona o un pequeño grupo de dos o tres personas que se repartían tareas, los primeros programas eran todos listas de instrucciones que se ejecutaban en una secuencia estricta por ejemplo Inicio del programa Aparece un menú de opciones Si se escoge la opción 1 se ejecuta el procedimiento 1 (secuencia de instrucciones del procedimiento 1) Si se escoge la opción 2 se ejecuta el procedimiento 2 (secuencia de instrucciones del procedimiento 2) etc.. Vuelta al menú al terminar alguno de los procedimientos Fin del programa Estos se conocían como lenguajes de programación procedurales , es decir que consistían en listas secuenciales de procedimientos. En sus niveles más bajos todos los sistemas son procedurales.

Los lenguajes procedurales aún se usan, todo lenguaje de bajo nivel (o sea los que interactúan directamente con la máquina) son procedurales y cuando programamos sistemas pequeños se puede usar el método procedural sin problema. Como los lenguajes procedurales son escencialmente listas de instrucciones son los que se usan en modo de consola (opuesto al modo gráfico o de ventanas). Al complicarse cada vez más los programas y aumentar de manera monstruosa la cantidad de instrucciones (hoy no es raro encontrar programas con millones de líneas de instrucciones), se hizo necesario el desarrollo en colaboración, los programas pasaron a llamarse sistemas y se hacían de manera modular por equipos de jefe de proyecto, analistas, programadores, documentadores, etc.

Otra consecuencia de estos cambios fue la necesidad de desarrollar los sistemas en módulos porque era imposible que una sola persona pudiese entender o controlar un sistema en su totalidad, esta modularidad desarrolló el concepto de cajas negras y aislación en capas donde cada módulo era una cápsula cerrada de código a la que se le conocían sus entradas y salidas, pero los detalles internos quedaban restringidos y ocultos para quienes trabajaban en los demás módulos, así las cápsulas o módulos de código se podían ensamblar como piezas de un Lego y también podían reusarse para otros programas.. Los sistemas dejaron de ser un solo archivo monstruosamente grande para convertirse en un ejecutable principal muy grande que llamaba a las funciones de otros ejecutables relacionados llamados bibliotecas. Por ejemplo en Windows estas bibliotecas son los archivos con extensión dll, ocx y otras. Por eso los programas modernos y complejos (especialmente en Windows) tienen normalmente una API (Aplication Programmers Interface) que permite agregar procedimientos accediendo a las rutinas de bajo nivel sin violar la estructura de capas. Ejemplos de API: Facebook, Twitter, Windows, etc. Las APIs son como “ventanas” que permiten enviar mensajes a algunas capas de bajo nivel de los programas, permitiendo que desarrolladores independientes les agreguen nuevas funciones o aplicaciones

Hasta fines de los sesentas la programación de computadores era una especie de arte donde personas muy dotadas (los programadores) veían un problema, diseñaban un modelo abstracto de solución, diseñaban los procedimientos lógicos y finalmente codificaban todos estos procedimientos. Sin embargo al crecer la complejidad de los programas ya nadie era capáz de manejar un diseño por si solo y la programación "artística" colapsó por múltiples razones: Al trabajar en equipo no todos los programadores son igualmente hábiles, esto creaba enormes cuellos de botella en la producción de un sistema. Como la codificación dependía mucho de la habilidad del programador, lo normal era que el único que entendía el código era quien lo había programado, o sea los programadores se convertían en indispensables e irremplazables. Al no existir procedimientos estrictos de desarrollo el código resultaba enredado, lleno de errores que se iban parchando en el camino y quedaban sin documentar, el desarrollo se demoraba, etc. Para corregir esta situación surgió la Ingeniería de Software con el objetivo de "la producción sistemática y el mantenimiento de productos de software, su desarrollo y modificación en el tiempo previsto y dentro de los costos estimados" NOTA IMPORTANTE: Para sistemas pequeños muchos de los problemas mencionados no existen y por ello algunos de los criterios desarrollados por la Ingeniería de Software no se aplican.

Los productos de software (que en adelante llamaremos Sistemas) pueden ser de dos clases
Genéricos (por ejemplo Word, Excel, etc.) A la medida (por ejemplo el software del control de las fronteras) Los sistemas, además de el conjunto de archivos con ejecutables compilados y bibliotecas usualmente tienen los siguientes componentes adicionales Documentación de los requerimientos (casos de uso) Documentación de los diseños (especificaciones de diseño) Código fuente Planes de prueba (casos de prueba) Manual de operación y ayuda (manual de usuario) Instrucciones de instalación Procedimientos de mantenimiento (planes de respaldo, protocolos de reporte de error, planes de contingencia, etc.)

Como se desarrolla un sistema
Planificación y estimaciones: en esta etapa se planifican las actividades, se asignan los tiempos, los requerimientos de recursos humanos, físicos y se estima el presupuesto de cada etapa así como el presupuesto total del proyecto Análisis de los requisitos: aquí se descompone el problema que se pretende modelar en sus detalles, determinando que es lo que se requiere que haga el sistema Diseño: en esta etapa se crea el modelo y el diseño lógico con todas las entradas, salidas y procesos que debe ejecutar el sistema Codificación: el diseño creado en la etapa anterior se materializa escribiendo en lenguaje de programación las instrucciones para llevar a cabo cada una de los módulos según las especificaciones del diseño lógico Prueba: la etapa de prueba es simultánea a la de codificación a nivel de detalle pero también posterior, cuando se ensamblan los módulos. Finalmente cuando se entrega todo el sistema para producción comienza una tercera fase de la etapa de prueba que es para todo el sistema bajo condiciones reales. Mantenimiento: en esta etapa se agregan nuevos módulos, se modifican o se quitan según vayan cambiando los requerimientos del sistema, se ejecutan programas de respaldo de datos y sistema, etc.

Concepto de Calidad de Software
La calidad de un software tiene que ver con la percepción subjetiva acerca de su desempeño, robustez, prestaciones, etc. y se percibe en dos niveles: Nivel Externo, es como perciben el software los usuarios del sistema Nivel Interno, es como perciben el software los profesionales de la computación En el nivel externo, la percepción de calidad suele variar mucho según las expectativas de los usuarios algunas de estas son objetivas como: Corrección: cuando el sistema ejecuta sin errores todas sus funciones, tal como han sido especificadas en el diseño. Robustez: cuando el sistema no se cae en condiciones excepcionales o anormales Modificabilidad: la capacidad para adaptarse al cambio en sus especificaciones Compatibilidad: capacidad para acoplarse y trabajar en conjunto con otros sistemas Ergonomía: capacidad para hacer las tareas con la mayor facilidad para el operador, evitando la duplicación de entrada de datos, el paso innecesario por varias etapas para hacer una tarea, etc. Integridad: capacidad para protegerse contra accesos no autorizados, robo de información, modificación maliciosa, etc. Facilidad de uso: aprendizaje sencillo, operación sencilla, reportes de calidad

Sin embargo existen otros criterios de percepción de calidad por parte de los usuarios que, sin ser tan objetivos, son los que causan los mayores conflictos: Disconformidad con el diseño del sistema: pese a que el diseño se construye en base a encuestas y estudio de las necesidades de los usuarios, este no es siempre 100% funcional a sus intereses porque existen muchos otros criterios que el diseño debe considerar, por ejemplo al mejorar la seguridad y los controles normalmente se perjudica la ergonomía, los jefes pueden haber introducido requisitos adicionales al sistema para prestaciones y trabajos que antes no se efectuaban, el sistema puede ser menos robusto ante el ingreso equivocado de datos, etc. En general los usuarios siempre comparan el nuevo sistema con el antiguo y distintos usuarios tienen distintas prioridades, por lo que no existe un sistema que pueda dejar a todos conformes por igual, los operadores desearan hacer lo mismo con menos trabajo, los clientes desearán tener prestaciones adicionales, los jefes más control y seguridad, etc. todos esos requerimientos están frecuentemente en conflicto por lo que no es raro que la percepción de calidad difiera para los diferentes usuarios. Aversión al cambio: operadores y usuario están acostumbrados al sistema antiguo y se molestan al tener que cambiar sus métodos de operación y aprender otros nuevos. Falsos errores de sistema: producidos por errores de operación durante la curva de aprendizaje, durante el período de prueba en explotación suelen producirse fuertes tensiones y recriminaciones mutuas entre operadores y el equipo de desarrollo por esta causa

En el nivel interno algunos de los principales factores de calidad son:
Seguridad: es la capacidad de protección del sistema ante ataques intencionados o negligencias para mantener la integridad y confidencialidad de los datos Robustez: es la capacidad de continuar funcionando correctamente en circunstancias adversas tales como flujos anormalmente grandes, errores de operación, etc. Modularidad: que es la capacidad de cada componente del programa de funcionar de manera independiente, posibilitando el reemplazo, reutilización, etc. sin tener que afectar al sistema completo Legibilidad: el código debe estar escrito de manera clara y tan auto documentado como sea posible en cada uno de sus módulos de manera que cualquiera lo pueda entender, mantener, reparar, etc.

Ciclo de vida del software
El ciclo de vida son las etapas por las que pasa un sistema desde su concepción hasta su explotación en régimen. Existen varios modelos de los cuales revisaremos tres: Clasico El ciclo de vida clásico consiste en el desarrollo secuencial en una serie de pasos, cada paso genera las entradas y la documentación para el siguiente: Entrevistas Especificaciones de casos de uso Diseño lógico Diseño Físico Casos de Prueba Documentación Producción Este ciclo de vida todavía se ocupa para el desarrollo de sistemas pequeños por su simplicidad, pero en la mayoría de los sistemas se usa una variante llamada

Ciclo Clásico en Cascada
En este caso también se recoge información, se hacen especificaciones de diseño, se hace un diseño lógico y finalmente se codifica, la diferencia es que el flujo no es secuencial sino que las correcciones afectan no solo a la etapa inmediatamente anterior sino a todas las etapas. Al crecer los sistemas aparecen una serie de inconvenientes en el desarrollo en cascada, como: * Es difícil imaginar de antemano los requerimientos de las etapas que siguen * Muchos problemas no siguen un flujo secuencial * Los errores se detectan solo cuando se pone a prueba todo el sistema Ciclo de vida por prototipado Los prototipos son versiones iniciales de un producto o un módulo, que permiten que el cliente y el futuro operador vean como se va a comportar, den sus impresiones y críticas, ayudan a establecer las necesidades reales del cliente quien muchas veces no las tiene claras al momento de ser entrevistado.

EL DISEÑO EN CASCADA La ingeniería de sistemas se preocupa del análisis y modelamiento del sistema que se pretende construir. El trabajo consiste a grandes rasgos en entender el problema, fijar las prioridades y especificarlas en un modelo lógico que normalmente se concreta como un listado exhaustivo de especificaciones sobre estructuras de datos, que es lo que el programa debe hacer, las entradas, procesos y salidas.. El trabajo de la ingeniería de sistemas tiene que ver con la organización, las necesidades y expectativas de los clientes, la idea es definir y ordenar las prioridades en una capa lógica abstracta, antes de enredarse con los detalles técnicos de la codificación y es por eso que se le da gran importancia al trabajo de encuestas en esta etapa, de manera de tener claras las prioridades y expectativas. Luego viene el trabajo de ingeniería de software que consiste en codificar las especificaciones entregadas y convertirlas en un programa que funcione. El trabajo en una primera instancia consiste en construir prototipos de las interfases de usuario, es decir un programa "de mentira" para determinar las mejores interfases hombre-máquina y, una vez elegido esto dedicarse a codificar y optimizar los procesos que el sistema debe realizar, todo esto apegado a las especificaciones entregadas por el diseño lógico. La construcción de prototipos semi funcionales es de gran ayuda al momento de probar el comportamiento real de las ideas del diseño. Esta es la teoría. La construcción de un programa debe ser un proceso en cascada donde el diseño ideal debe preceder a la codificación. En el desarrollo de programas computacionales según se nos ha enseñado, existen dos etapas claramente definidas: el diseño lógico y el diseño físico. En la realidad sin embargo, esta separación ha sido fuente de diversos problemas

POR QUE SE DISEÑA EN CASCADA
Esta separación entre diseño lógico y el diseño físico es consecuencia de los problemas de crecimiento de tamaño y complejidad en los sistemas. En un principio ambas etapas estaban estrechamente relacionadas, y lo siguen estando en el caso de los sistemas pequeños donde trabaja solo un programador o un pequeño grupo de personas. Pero al hacer sistemas más complejos y dividir las tareas entre un equipo de programadores era necesario fijar prioridades y criterios de diseño de antemano, de manera que todos trabajen bajo normas claras y criterios comunes. Esto evita el problema de desviarse de los grandes objetivos por percepciones o necesidades particulares de alguno de sus subsistemas. También divide el trabajo en una parte creativa y normativa (diseño lógico) y otra mecanizada y sujeta a normas (diseño físico). El diseño en cascada ha formado una verdadera cultura que separa a analistas y programadores. Harry Boehm de la Universidad de California del Sur cuenta su experiencia al respecto: "Cuando tratamos de introducir el uso de prototipos en proyectos con alta interacción de usuarios en TRW, los ingenieros de software, resistiéndose al cambio, golpeaban la mesa y gritaban, "¡No pueden hacer esto! ¡hacer prototipos es codificar sin haber pasado la revisión crítica del diseño, esto esta absolutamente prohibido por las políticas corporativas!" , tomó años deshacer las muchas formas en que el modelo de cascada se había infiltrado en varios aspectos de nuestra cultura corporativa tales como el marketing, preparación de propuestas, estimación de costos, contratos, contabilidad y gerenciamiento"

Y CUAL ES EL PROBLEMA? Hay un viejo cuento de un ingeniero de sistemas que decía haber diseñado finalmente un software que podía rivalizar con el cerebro humano. Al pedírsele que lo demostrara entregó una larga lista con las especificaciones comunes de un computador a las que había agregado las especificaciones de "imaginación", "conciencia de si mismo", "lenguaje sofisticado" etc. "Bueno", dijo a modo de explicación "allí tienen el diseño, ahora solo es cosa de los programadores y los ingenieros de hardware implementarla. Lo principal ya esta hecho. Bueno, ese es uno de los mayores problemas de trabajar en abstracto desentendiéndose de los problemas prosaicos tales como la codificación, los recursos disponibles, costos y el rendimiento. Los ingenieros de sistema vienen normalmente de las áreas de la ingeniería industrial o de la administración (ingeniería comercial en Chile), no son fuertes en programación y a menudo ven con cierto desprecio la labor del programador, considerándola mecánica y poco creativa. No es raro que los diseños lógicos, al desentenderse de los detalles del mundo real tales como las limitaciones de hardware o la complicación excesiva en el código terminen en una serie de especificaciones y requisitos que no es factible de implementar con éxito. Esos son los conocidos "desastres informáticos" o sistemas que llevan mucho tiempo, esfuerzo y dinero en desarrollarse y que nunca llegan a funcionar del todo bien (muchos simplemente jamás funcionan).

INTRODUCCION A LOS SISTEMAS DE ARCHIVOS Y BASES DE DATOS

Introducción a Los Archivos y Bases de Datos
Los computadores, desde su inicio se han convertido en la herramienta para modelar por excelencia porque tienen dos potentes características para esta tarea: pueden almacenar información de manera persistente y pueden ejecutar procedimientos automatizados (cálculos, búsqueda, selección, etc.). Las primeras aplicaciones hacían una diferencia clara entre datos y procesos, los datos eran información estática, guardada en algún lugar que se podía manipular (procesar) por medio de programas, entonces los datos se guardaban en archivos que podían ser de tamaño más o menos fijo (como un archivo con los datos de cuenta para un programa de cuentas corrientes) y otros de tamaño variable (como los archivos de movimiento que crecen en el tiempo), en este esquema tenemos: Archivo de datos Archivo de datos Programa Archivo de datos

En este esquema, que todavía se usa en sistemas pequeños, el programa es fundamental y actúa sobre los datos, recuperándolos, buscando o modificando y luego los muestra arreglados de cierta forma. Volviendo al ejemplo de cuentas corrientes podemos tener un módulo de programas -por ejemplo- para listar el analítico de una cuenta (la cartola) este módulo pediría la identificación de la cuenta (clave de búsqueda) y se iría al archivo de nombres de cuentas, para recuperar el nombre del titular, su RUT, su límite de crédito, etc. Esos son los datos a desplegar en el encabezado de la cartola. Luego el programa recorrería secuencialmente el archivo de movimientos, que tiene los registros de todas las cuentas almacenados en secuencia, seleccionando solo los registros que corresponden a la cuenta solicitada y los desplegaría como líneas de la cartola, del más antiguo al más nuevo.

Operaciones con Archivos Almacenar datos en una tabla Esta es la forma mas usada por ser sencilla e intuitiva, es lo que usan las bases de datos "relacionales" y los archivos planos de tipo "random" o aleatorio. Consiste en definir campos, nombres y largos, con lo que describimos una grilla cuyas "lineas" corresponden a "registros" y las "columnas" a "campos". Los que conocen las bases de datos o las hojas de cálculo conocen bien esta idea, por ejemplo: NRO NOMBRE DIRECCION TELEFONO 1 PEDRO LOA 123 223344 2 JUAN ACACIAS 222 345566 3 DIEGO CODORNICES 324 765544 También existieron en su época las bases de datos jerárquicas pero nunca tuvieron tanto éxito como las relacionales. El hecho es que estamos acostumbrados a almacenar datos en tablas

Archivos planos vs. Archivos con formato
Los datos se pueden guardar en un soporte magnético (discos duros), en cinta, en CD, DVD, etc. En la actualidad el soporte magnético es el más usado porque da la mejor relación entre capacidad de almacenamiento vs tiempo de recuperación de los datos. Los datos se graban en archivos, que tienen un nombre y agrupan un conjunto de datos según cierto orden o estructura. Existen dos formas distintas de guardar datos: los archivos planos o texto claro, que usan solo los caracteres del conjunto ASCII normal y guardan los datos tal cual si los escribiesemos en un block de notas. La otra forma es en un archivo con formato, que usa caracteres especiales o bien algún sistema de encriptación u ocultamiento de la información para que los datos solo se puedan ver usando el programa específico por quien tiene los permisos. En un archivo de texto plano cualquiera puede ver los datos simplemente usando el notepad o algún editor de textos básico Ejemplos de archivo con formato y de texto plano

Los Archivos Random Son una manera sencilla de guardar los datos en un archivo plano usando Visual Basic. Necesitamos guardar en algún lado la cantidad de registros almacenados, para saber en que posicion se guardará el registro siguiente (en el ejemplo mostrado hay 3 registros). Esto podria hacerse en otro pequeño archivo con un solo registro o, por ejemplo, en la primera posicion del mismo archivo, el que quedaría físicamente así: 3 PEDRO LOA 123 223344 JUAN ACACIAS 222 345566 DIEGO CODORNICES 324 765544

Nótese que eliminamos el campo correspondiente al "número", éste no necesitamos grabarlo pues está implícito en la posición física donde va grabado el registro.Luego necesitamos grabar los datos "alineados" es decir todos los campos deben tener el mismo largo. Supongamos que definimos de antemano que el campo "nombre" debe tener 30 caracteres, el campo "direccion" 40 caracteres y el campo "teléfono" 20 caracteres ¿como los alineamos? Simplemente agregándole espacios en blanco. Por ejemplo si entramos el valor "PEDRO" en el campo de nombre (5 caracteres) tendremos que agregarle 25 espacios en blanco, a "JUAN" (4 caracteres) le agregamos 26 espacios, etc. No es necesario hacer una rutina para agregar espacios pues esto se hace fácilmente en Visual Basic con: Type Registro_de_agenda Nombre as string * 35 Direccion as string * 40 Telefono as string * 20 End Type Global Agenda as Registro_de_agenda

Este código se guarda en un módulo
Este código se guarda en un módulo .Bas donde van las declaraciones, valores de inicialización y variables globales o públicas, etc. Las instrucciones Type....End Type convierten los valores que entramos en esas variables en largo fijo y la declaración Global (o Dim, Public o Private, según nos convenga) sirve para crear variables "con apellido" llamadas "tipos de datos definidos por el usuario", así de ahora en adelante las variables se llamarán: Agenda.Nombre Agenda.Direccion Agenda.Telefono Esta es una notación muy conveniente y emparentada con la notación de objetos: es decir el objeto "Agenda" tendría las propiedades "nombre", "dirección" y "telefono" Luego, para crear un archivo del tipo "random" nos falta usar solo tres instruciones más "Open" (abre un archivo), "Put" (graba un registro), "get" (lee un registro) y "Close" (cierra el archivo).

Para "iniializar" un archivo con 1000 registros en blanco por ejemplo, abrimos una Form, le colocamos un botón con el Caption "Inicializar (Borrar todo)" y le programamos el evento click con: Sub Inicializar() Open "Archivo_de_Agenda" for Random as 1 For z=1 to 1000 Agenda.Nombre="" Agenda.Direccion="" Agenda.Telefono="" Put 1, z, Agenda Next z Close End Sub ¿Se podría usar el archivo sin inicializarlo? si, el único inconveniente sería al leer registros vacíos aparecería "basura" es decir cualquier información que haya en el buffer en ese momento

Sub LeerRegistro() Open "Archivo_de_Agenda" for Random as 1 Get 1, z, Agenda Nombre=Agenda.Nombre Direccion=Agenda.Direccion Telefono=Agenda.Telefono Close End Sub

Sub agregar() Open "Archivo_de_Agenda" For Random As 1 rem rem leer el indice, incrementar y grabarlo rem Get 1, 1, Agenda ultimo = Val(Agenda.nombre) If Val(ultimo) = 0 Then ultimo = 1 rem si esta vacio lo pone en 1 Puntero = ultimo + 1 Agenda.Nombre = Puntero Put 1, 1, Agenda rem puntero almacena donde debe grabarse el nuevo registro rem Agenda.Nombre = Text1.Text Agenda.Direccion = Text2.Text Agenda.Telefono = Text3.Text Put 1, Puntero, Agenda Close End sub

Sub listar() Open archivo For Random As 1 rem leer el indice Get 1, 1, Agenda ultimo = Val(Agenda.Nombre) rem listar For z%=2 to indice Get 1, z%, agenda List1.AddItem Agenda.Nombre Next z Close End Sub

Existen dos problemas que a menudo están relacionados al usar archivos random, son los de buscar (y encontrar) rápidamente un registro y presentar el archivo ordenado según algún criterio. En ambos casos se usa uno o más archivos auxiliares de índice, que almacenan la ubicación física de los registros en distintos órdenes según se requiera. Para recuperar un registro dentro de un archivo hay dos formas posibles: 1.- hacer una búsqueda secuencial desde el primer registro, uno por uno, chequeando si es el valor buscado, esto se usa cuando hay que ubicar –por ejemplo- a una persona por el nombre o parte de él 2.- recuperar directamente por medio de un código que dirija al número de orden en que el registro está ubicado (por ejemplo para eso se usan los códigos de barras o los códigos numéricos) Programar estos índices y usar métodos de ordenación y búsqueda más sofisticados son procedimientos complicados, y es una de las razones que originaron y popularizaron el uso de motores de base de datos que automatizan estas dos tareas. En la programación convencional sin usar bases de datos, se usan normalmente el método ISAM (Indexed Sequencias Access Mode) y el algoritmo Quick Sort. En bases de datos se usa el SQL (structured query language) para estos fines

Los Archivos secuenciales
En los archivos secuenciales los datos no se almacenan en campos de largo fijo sino como una secuencia continua de datos con algún caracter delimitador que los separa, el ejemplo anterior –delimitado por comas- quedaría asi: Pedro,Loa123,223344,Juan,Acacias 222,345566,Diego,Codornices 324,245512… etc. Un archivo secuencial es como una tira de salchichas donde los datos solo pueden ir agregandose al final y se debe leer y escribir la secuencia completa cada vez. Son por lo general complicados de actualizar, ordenar y bastante lentos, pero tienen algunos usos interesantes como por ejemplo grabar archivos de texto completos y particularmente archivos del tipo .ini, muy usados en Windows para ingresar settings Para usar archivos secuenciales en almacenamiento de datos el procedimiento es trabajar con toda la sarta de salchichas almacenada en un array en memoria. Esto limita bastante el tamaño y el rendimiento de estos archivos. Me parece que las hojas de cálculo usan una estrategia similar y por eso son tán limitadas en cuanto al manejo de hojas grandes. Para leer un archivo secuencial de texto en una lista List1, usamos:

Para leer un archivo secuencial en Vbasic usamos
Sub leerarchivo() Dim Lineatemporal As String List1.Clear Open "Archivo_de_Datos" For Input as 1 While not EOF(1) Line Input 1, Lineatemporal List1.Additem Lineatemporal Wend Close 1 End Sub Y para escribir (agregar al final) usamos: Sub escribearchivo() Open "Archivo_de_Datos" for Append Shared As 1 Print 1, "dato a grabar" Close 1 End Sub

Este es un ejemplo típico de como trabajan los sistemas procedurales, o sea donde lo más importante es el proceso. Estos sistemas fueron los primeros en desarrollarse y tienen muchos inconvenientes a medida que el volumen de datos crece demasiado (los procesos de búsqueda y recuperación se hacen muy lentos). Otro problema es cuando los procesos se complican demasiado, los programas crecen mucho y llegan a ser imposibles de comprender, excepto por el propio programador que los hizo. Otro problema de estos sistemas es que el diseño depende mucho de como están almacenados físicamente los datos (en que formato), los datos se guardaban en formatos propietarios e incompatibles con otros programas.

Bases de Datos Lo anterior se llamaba el problema de la dependencia físico-lógica. "Poco a poco, el centro de gravedad de la informática, que estaba situado en el proceso, se desplazo hacia la estructuración de los datos, siendo actualmente los aspectos relacionados con este tema un eje fundamental alrededor del cual gira una gran parte del conjunto de problemas con los que se enfrenta todo diseñador de un sistema de información”. Se cambia, por tanto, de sistemas orientados hacia el proceso a sistemas orientados hacia los datos, donde estos adquieren el protagonismo, pasando desde el plano más bien oscuro y difuso en el que estaban situados a ocupar un lugar privilegiado en el interés de todo informático.

Surge así, a finales de los sesenta y principios de los setenta, la primera generación de productos de bases de datos en red (basados en lo que posteriormente se conocería por modelos jerárquicos y Codasyl), entre los que destacaron por su impacto el IMS de IBM y el IOMS de Cullinet. Estos productos, si bien resultaban bastante eficientes, presentaban lenguajes procedimentales, que obligaban al programador a navegar (registro a registro) por la base de datos, y que no disponían de la suficiente independencia físico/lógica, lo que conllevaba una escasa flexibilidad" (Mario Piattini Velthuis). La base de datos relacional se inventa en 1970, básicamente consiste en un conjunto de reglas (un modelo) teóricas que independizan las operaciones sobre los datos de la forma en que estos están almacenados físicamente para ello una base de datos relacional tiene tres componentes: -Un motor de base de datos DBMS, que es el conjunto de programas que maneja la creacción y acceso a los datos físicos, distintos motores de bases de datos deben llevar al mismo modelo en la capa superior

El DBMS es el que aisla y relaciona la capa superior con los datos físicos, tiene tres subcomponentes: -Un lenguaje de definición de datos DDL para definir y documentar las estructuras de datos -Un lenguaje de manipulación de datos DML para hacer procesos con los datos -Un lenguaje de consultas SQL para hacer consultas y obtener vistas de los datos La base de datos relacional es la más usada por su sencillez y porque coincide con nuestra idea intuitiva de como se deben almacenar los datos, relacional, en palabras simples significa "organizadas como una tabla, en filas y columnas"

pero también existen otras dos formas de organización: jerárquica y en red. La organización jerárquica sigue el modelo de un organigrama, un arbol geneológico, etc. con un nodo "raíz" del cual se van descolgando subnodos, la clave de una organización jerárquica es que cada hijo solo puede tener un padre, o sea solo una dependencia hacia arriba como muestra la figura: La tecnología XML, de gran importancia por su potente aplicabilidad en sistemas de Internet usa un esquema jerárquico para organizar los datos.

La organización en red es escencialmente igual que la jerárquica pero con el agregado que los hijos pueden tener varios padres, en estas bases de datos se usa un registro conector para indicar con quienes está conectado el dato. Son muy poco usadas por su complejidad.

El Diseño en Tres Capas Las bases relacionales normalmente se usan en conjunto con la arquitectura en tres capas (3 Layer Architecture) que consiste en estandarizar y aislar las operaciones en capas: 1. Capa Física, es el nivel real donde están almacenados los datos (por ejemplo el disco duro) como se almacenan, en registros, como se indexan, etc. Este nivel tiene asociada una representación de los datos en registros y campos, denominada esquema físico. Es un nivel restringido a muy pocas personas. 2. Capa Conceptual, corresponde a una visión de la base de datos, es la organización lógica de los datos sin importar donde están físicamente almacenados. 3. Capa de Visión, los usuarios solo tienen acceso a pequeñas porciones de la capa conceptual (vistas o subconjuntos), rara vez al conjunto total. Por ejemplo un cajero debe tener su visión restringida a lo que necesita usar y no a ver los sueldos de sus superiores, la capa conceptual define y divide estas parcelas para los usuarios.

Ventajas de las bases de datos 1
Ventajas de las bases de datos 1. Independizan los datos de los procesos, si se cambia de programa no es necesario cambiar los datos y viceversa, porque son bases estandarizadas, bajando así los costos de mantenimiento. 2. Coherencia, reducen la redundancia (usando la normalización) y se evitan las inconsistencias (que un mismo dato tenga dos valores distintos al mismo tiempo) 3. Los datos son más disponibles, ni las plicaciones ni los usuarios son "dueños" de los datos por tecnología, solo por diseño, los datos pueden ser usados por distintas aplicaciones y distintos usuarios. Los datos pueden usarse aunque no haya ningún programa, usando solo el SQL. 4. Procedimientos normalizados, iguales para todos los casos, no hay procedimientos excepcionales, los accesos y operaciones permitidas están claramente definidos. 5. El acceso concurrente es mucho más sencillo, por ejemplo varios usuarios pueden acceder simultáneamente a una misma base de datos e incluso a un mismo registro, las bases de datos tienen mecanismos incorporados para evitar inconsistencias a diferencia de los archivos tradicionales.

Desventajas de las Bases de datos 1
Desventajas de las Bases de datos 1. Requieren de muchos programas e instalaciones para funcionar: bibiotecas, APIS, módulos, etc. lo que dificulta la portabilidad, no es sencillo portar ni migrar una base de datos. La migración entre sistemas legados a un nuevo sistema es uno de los procesos más críticos y complicados, aunque hay muchas utilidades para esto. 2. Aunque estándares dentro de su ámbito, el esquema de almacenamiento físico es propietario y muy oculto, cuando una base de datos se corrompe es muy difícil recuperar los datos que han quedado intactos, porque su acceso físico está muy encapsulado. 3. Vulnerabilidad, las bases de datos tienden a ser monolíticas y por lo mismo muy vulnerables, hay que tener mucho cuidado con las políticas de respaldo.

Algunas marcas de base DBMS: - MySql, tiene licencia GPL (gratis) basada en un servidor, es muy rápida pero su rendimiento decae cuando almacena demasiados datos -PostgreSqul y Oracle, son de los más poderosos, para grandes volúmenes de datos -Access, es el DBMS "casero" de Microsoft almacena los datos en archivos con extensión mdb, viene con la licencia de los productos de Office -Microsoft SQL Server, es la DBMS profesional de Microsoft su licencia se vende aparte y funciona con los lenguajes .Net como Visual Basic, etc.

INTRODUCCION A LOS MODELOS ENTIDAD-RELACION

Modelos Entidad-Relación
Los programas procedurales que trabajan con archivos Se diseñan pensando en resolver un problema mediante un flujo, o secuencia de operaciones que se efectúan sobre uno o más archivos de datos. Los archivos de datos normalmente se diseñan en base a los informes que debe entregar el sistema. Esto funciona bien para los sistemas pequeños o sencillos. En sistemas más complejos donde no existe uno sino decenas o cientos de archivos relacionados el diseño de la estructura de los datos se complica mucho pues aparecen problemas de redundancia, inconsistencias y pérdida de información. Las bases de datos no son estáticas y a medida que el sistema va creciendo se van requiriendo nuevos informes, cálculos y análisis, si no existe un modelo de datos bien especificado pueden ocurrir problemas catastróficos

Un modelo de datos es una colección de herramientas conceptuales para describir y organizar los datos, existen principalmente dos niveles Modelos lógicos basados en objetos Modelos lógicos basados en registros Los modelos basados en objetos están en lo que llamamos la “capa de visión” o sea como vemos los datos en el mundo real, existen varios modelos, los principales son los de estructuras de datos y modelos entidad/relación Los modelos entidad/relación están muy influenciados por las matemáticas, especialmente la teoría de conjuntos, define Entidades que son cosas que existen y tienen características que las distinguen, por ejemplo la entidad auto se puede distinguir por su marca, modelo, motor, etc. Estas características se llaman atributos y las entidades interactúan mediante relaciones. Los modelos son representaciones gráficas similares a los diagramas de flujo, aunque con una metodología completamente distinta

Nombre Descripción Puesto Costo Salario Clave R.F.C.
Un ejemplo simple Empleado: Artículo: Nombre Descripción Puesto Costo Salario Clave R.F.C. Símbolo Representa

La construcción de una base de datos parte con el modelamiento conceptual (a nivel de objetos) sigue con el diseño (a nivel de registros) y termina con la construcción física (codificación) Capa Visión Capa Diseño Capa Física

Las entidades son sustantivos.
Una entidad es una persona, lugar o cosa, de interés para los usuarios, acerca de la cual el sistema debe mantener, conocer y mostrar información. Las entidades son sustantivos. Las entidades están dentro del alcance del sistema. Las entidades existen por sí mismas, por lo tanto no dependen ni están subordinadas a otras. Las entidades pueden ser tangibles (tales como edificios o empleados), intangibles (como departamentos o cuentas) o semi- tangibles (pedidos o facturas). Cada entidad debe tener múltiples ocurrencias o instancias cantidad de elementos. Si una entidad no puede ser identificada de manera única, podría no ser entidad. José Miguel Santibañes, Sistemas de Información

ASOCIACIONES Una asociación es una relación entre dos o más entidades (u otras asociaciones), de interés para el grupo de usuarios, acerca de la cual el sistema debe mantener, correlacionar y mostrar información. Las asociaciones ocurren de tres formas: uno a uno (1:1), uno a muchos (1:M) y muchos a muchos (M:M) Discusión Las asociaciones ocurren típicamente entre una entidad y otra (clientes y pedidos, por ejemplo, o pedidos y presupuestos), pero pueden involucrar cualquier número de entidades e interrelaciones. José Miguel Santibañes, Sistemas de Información

SIMBOLOGIA PARA DIAGRAMAR ENTIDADES
Caja de contornos suaves con cualquier dimensión. Nombre de entidad singular y único. Nombre de entidad en mayúscula. Sinónimo opcional (entre paréntesis) José Miguel Santibañes, Sistemas de Información

SIMBOLOGIA PARA DIAGRAMAR ASOCIACIONES Una línea entre dos entidades
Nombres de relaciones en minúscula Opcionalidad Opcionalidad (puede ser o estar) Obligatorio (debe ser o estar) José Miguel Santibañes, Sistemas de Información

IDENTIFICANDO Y MODELANDO RELACIONES
Siga la secuencia de pasos que se indican, para extraer las relaciones de notas de entrevistas. DETERMINE LA EXISTENCIA DE UNA RELACION Cuando hay dos sustantivos juntos que son entidades, las palabras de entre medio son a menudo relaciones NOMBRE LA RELACION ¿Cómo está relacionada una ENTIDAD A con una ENTIDAD B? DETERMINE LA OPCIONALIDAD DE LA RELACION ¿Debe una ENTIDAD A ser {nombre de relación} de una ENTIDAD B? ¿Siempre? DETERMINE LA CARDINALIDAD DE LA RELACION ¿Podría una ENTIDAD A ser nombre de relación de más de una ENTIDAD B? ¿Podría una ENTIDAD B ser nombre de relación de más de una ENTIDAD A? VALIDE LA RELACION Re – examine el Modelo E – R y valide la relación. Lea la Relación en Voz Alta José Miguel Santibañes, Sistemas de Información

¿Cuáles son algunos atributos de la entidad EMPLEADO?
Un atributo es una característica o cualidad de una entidad o de una asociación, de interés para el grupo de usuarios, acerca de la cual el sistema debe mantener y mostrar información. Ejemplo ¿Cuáles son algunos atributos de la entidad EMPLEADO? Los nombres de atributos son singulares y se muestran en minúscula José Miguel Santibañes, Sistemas de Información

Verifique que cada atributo tenga un valor único para cada instancia de entidad. Un atributo de múltiples valores o grupo repetitivo no es un atributo válido incorrecto correcto ATRIBUTOS DERIVADOS Los atributos derivados, son atributos cuyos valores se pueden determinar o calcular de otros datos en el modelo. Por ejemplo el valor total en inventario (costo por cantidad) José Miguel Santibañes, Sistemas de Información

OPCIONALIDAD DE ATRIBUTOS
Atributos obligatorios * Atributos opcionales o IDENTIFICANDO Y MODELANDO ATRIBUTOS Siga la secuencia de pasos que se indican, para extraer los atributos desde notas de entrevistas. Atributos son a menudo sustantivos seguido de otro sustantivo. “El nombre de un Proyecto...” Condiciones también referencias atributos “...Entonces el Proyecto es completado...” Pregunte al usuario ¿Qué información necesita Ud. Conocer o tener acerca de la entidad x? ¿Qué información le gustaría a Ud. Desplegar o imprimir acerca de la entidad x? José Miguel Santibañes, Sistemas de Información

Criterios para definir Identificadores
Un Identificador Unico (UID) es cualquier combinación de atributos y/o relaciones que sirven para identificar en forma única una ocurrencia de una entidad. Cada ocurrencia de una entidad debe ser identificable de manera única. Simbología Represente gráficamente un identificador, anteponiendo el símbolo # al nombre del o los atributos que lo componen. Criterios para definir Identificadores El valor del identificador no puede ser nulo. No puede contener valores duplicados. Debe permanecer invariante en el tiempo (no contener información). De longitud pequeña. Preferentemente de tipo numérico. Familiar para los usuarios. José Miguel Santibañes, Sistemas de Información

NORMALIZACION La normalización es una técnica para desarrollar y evaluar modelos de datos. La normalización fue originalmente un invento del Dr. Codd, un investigador de la IBM, y ha sido refinada y extendida por varios otros científicos de bases de datos desde su introducción en 1972. Regla de Normalización Descripción Primera Forma Normal (1NF) La relación entre el identificador de la entidad y sus atributos debe ser 1:1 en esa dirección. Segunda Forma Normal (2 FN) Un atributo debe ser dependiente del identificador completo de la entidad Tercera Forma Normal (3 FN) La relación entre cualesquiera dos atributos que no son identificador de la entidad, excepto atributos no duplicados, no debe ser de uno a uno en ninguna dirección. La 3FN es la regla apropiada para eliminar la redundancia en el diseño de base de datos José Miguel Santibañes, Sistemas de Información

PRIMERA FORMA NORMAL La relación entre el identificador de la entidad y sus atributos debe ser 1:1 en esa dirección Ejemplo ¿Cumple la entidad CLIENTE con 1NF? Si no, ¿Cómo podría ser convertido a 1NF? El atributo fecha contacto tiene múltiples valores, por lo tanto la entidad CLIENTE no está en 1Nf. Si un atributo tiene múltiples valores, cree una entidad adicional y relaciónela con la entidad original con una relación M:1 José Miguel Santibañes, Sistemas de Información

SEGUNDA FORMA NORMAL Un atributo debe ser dependiente del identificador único de su entidad. Cada instancia de un BANCO y número de cuenta determinan valores específicos de saldo y fecha de apertura para cada cuenta. El atributo dirección del banco está mal colocado. Depende del BANCO, pero no de un número de cuenta. No debería ser un atributo de CUENTA. Si un atributo no depende de todo el UID de su entidad, está mal colocado y debe ser removido José Miguel Santibañes, Sistemas de Información

TERCERA FORMA NORMAL La relación entre cualesquiera dos atributos que no son identificador de la entidad, excepto atributos no duplicados, no debe ser de uno a uno en ninguna dirección. Ejemplo: ¿Depende cualquiera de los atributos no- UID de otro atributo no –UID? Los atributos nombre de cliente y estado dependen del id del cliente. Cree otra entidad llamada CLIENTE con un UID de id del cliente y coloque los atributos respectivos José Miguel Santibañes, Sistemas de Información

INTRODUCCION A LA ORIENTACION A OBJETOS
Tomás Bradanovic

La orientación a objetos es la teoría principal para el desarrollo de software en sistemas grandes, algunas de sus ventajas son: Ayuda al desarrollo por componentes Desarrollo modular Permite crear objetos reutilizables La orientación a objetos es un modelo, un paradigma que se usa para muchas cosas, desde los modelos lógicos hasta los lenguajes de programación orientados a objetos, este modelo se basa en ciertos principios fundamentales. Un objeto es cualquier cosa concreta o virtual, el mundo se compone de objetos y específicamente en el software creamos objetos que imitan o representan a otros objetos reales Un objeto es la instancia de una clase (por ejemplo una persona es una instancia de la clase “seres humanos”), las clases son objetos de otras clases mayores

Los objetos tienen características que pueden ser
Atributos (o propiedades) Acciones Una clase, además de agrupar a los objetos de una cierta categoría, sirve como “molde” para fabricar nuevos objetos. Esta es una característica importante al escribir software: las clases sirven para crear nuevas instancias El modelo se puede hacer más exacto agregando más atributos y acciones relevantes

Para que un objeto cumpla con los requisitos del paradigma debe tener las siguientes características: Abstracción Herencia Polimorfismo Encapsulamiento Además debe tener las capacidades para Enviar mensajes Asociarse Agregarse

Las Supercalses pueden ser Subclases de otras
Abstracción: quitar todas las propiedades de un objeto dejando solo las que son necesarias. Las propiedades relevantes dependen del problema ejemplo lavadora Herencia: las clases heredan sus propiedades hacia abajo, por eso una clase es una plantilla que sirve para crear nuevos objetos, esto evita repetir las propiedades, basta con que sea una subclase para que las propiedaes sean heredadas por defecto ejemplo electrodomésticos – lavadora Superclase Las Supercalses pueden ser Subclases de otras Aspiradoras Tostadoras Subclase

Polimorfismo: una operación puede tener el mismo nombre en diferentes clases, en cada clase puede operar de manera distinta, por ejemplo la operación abrir(). Cada clase debe “saber” como funcionan sus operaciones, ejemplo: abrir un archivo, abrir una ventana, abrir un acceso a base de datos son operaciones distintas que llevan el mismo nombre, ´la clase donde están define como opera. Encapsulamiento: consiste en ocultar el funcionamiento interno de sus operaciones, el objeto muestra una funcionalidad pero no da acceso al prodedimiento detallado, el encapsulamiento permite la integridad y la interoperabilidad entre objetos, ejemplo a una función abrirBaseDatos(nombre,#registro) solo tenemos acceso a sus parámetros, pero no a su funcionamiento interno. El encapsulamiento también se llama ocultamiento. El mundo real está lleno de ejemplos de encapsulamiento, usamos autos, teléfonos, vemos televisión, etc. sin saber en detalle como funcionan, solo nos interesa conocer sus funcionalidades.

Envío de mensajes: los objetos se comunican entre sí enviándose mensajes a través de interfaces.
Interfase Interfase agregarRopa() Encendido() Ejemplo, al usar un control remoto estamos enviando un mensaje al televisor para que cambie de canal, este mensaje lleva un parametro (el número de canal al que queremos cambiar) y es nuestra forma de comunicar al objeto persona con el objeto televisor

Asociaciones: dos objetos se pueden asociar entre si mediante una relación, la asociación se materializa a través de mensajes, pero se diferencia en que la asociación se refiere más bien a la naturaleza de los mensajes. Las asociaciones tienen direción –pueden ser en una sola dirección o en dos direcciones o vías- también dos objetos pueden asociarse en más de una forma, ejemplo Pedro y Juan pueden ser colegas de trabajo, pero también amigos o compañeros de equipo de fútbol, etc. Un solo objeto o clase se puede asociar con otros varios, esto se llama multiplicidad o diversificación, es decir pueden haber asociaciones uno a uno, uno a muchos, o muchos a uno. Agregación: consiste en la asociación de varios objetos que funcionan para un fin común, ejemplo, en un programa de inventario puede haber un objeto leerRegistro(), grabarRegistro(), listarInventario(), etc. todos trabajan asociados. La composición agrupa a todos los componentes que son vitales para que la agregación funcione, por ejemplo un sistema de inventario no puede funcionar sin un objeto leerRegistro()

Orientación a objetos=objetos+clasificación+herencia+comunicación
Abstracciones de datos (atributos) y procedimientos=modularidad Ocultamiento de la información (encapsulamiento) minimiza el impacto de los cambios, ejemplo, compartimientos estancos en los barcos Los métodos (operaciones) manipulan los atributos, que son limitados (cohesión interna). La clase forma una “muralla” alrededor de los métodos, que solo son accesibles por las “puertas” de sus parámetros a través de mensajes. Esto produce un bajo acoplamiento con los demás componentes del sistema. Las clases se organizan en jerarquías, como muestra la figura

Ejemplo de uso del polimorfismo
Supongamos que tenemos un objeto que debe recibir datos y hacer uno de los siguientes gráficos: barra, torta, líneas o nube de puntos, por el método tradicional debería programarse algo como: case of tipo_grafico: if tipo_grafico=grafico_barra then DibujarBarras(datos); if tipo_grafico=grafico_torta then DibujarTorta(datos); if tipo_grafico=grafico_linea then DibujarLinea(datos); if tipo_grafico=grafico_nube then DibujarNube(datos); End case Si definimos una clase Grafico y cuatro subclases para cada tipo, podríamos reemplazar todo esto por una sola línea tipo_grafico dibujar Donde la operación dibujar será distinta para cada tipo_grafico

Objetos y componentes Como dijimos la Teoría de Orientación a Objetos es un paradigma, muy bien estructurado con bases matemáticas en la Teoría de Conjuntos, por esto tiene definiciones y requisitos estrictos que definen cuales enfoques on orientados a objeto y cuales no (deben cumplir con los requisitos de abstracción, herencia, polimorfismo, encapsulación, etc.) Existe un desarrollo teóricamente más relajado que toma muchas de las definiciones y métodos de la orientación a objetos aunque no cumple estrictamente con todos los requisitos, es el desarrollo modular de componentes. Por ejemplo los lenguajes de programación C++, C#, Visua Basic.net son orientados a objetos, mientras el Visual Basic.6 o el Visual Basic Para Aplicaciones son lenguajes orientados a componentes, que no cumplen con algunos de los requisitos de la Teoría de Objetos Visual Basic 6 no implementa de manera nativa la herencia ni el polimorfismo, aunque se pueden simular ambos requisitos, la crítica fundamental es que VB 6 no restringe y permite crear objetos que violen estos dos requisitos. Se puede decir que VB6 es un lenguaje orientado a eventos que usa objetos y muchos de los conceptos de la Teoría de Objetos

Como el Visual Basic 6 y VBA son los lenguajes más usados para desarrollar aplicaciones comerciales a nivel de micro y mini aplicaciones (inventarios, cuentas corrientes, etc.) los usaremos como ejemplos para mostrar como se aplica la orientación a objetos en el desarrollo de software Clases y objetos Las palabras "clase" y "objeto" se utilizan con tanta frecuencia en la programación orientada a objetos que es fácil confundir los términos. En general, una class es una representación abstracta de algo, mientras que un objeto es un ejemplo utilizable de lo que representa la clase. La única excepción a esta regla la constituyen los miembros de clases compartidas, que pueden utilizarse en instancias de una clase y en variables de objeto declaradas como tipo de la clase.

Campos, propiedades, métodos y eventos
Las clases se componen de campos, propiedades, métodos y eventos. Los campos y propiedades representan información que contiene un objeto. Los campos se parecen a las variables en que se pueden leer y establecer directamente. Por ejemplo, si tiene un objeto denominado “Auto", podría almacenar su color en un campo denominado "Color". Las propiedades se recuperan y establecen como los campos, pero se implementan mediante los procedimientos Get propiedad y Set propiedad, que proporcionan más control sobre la forma en que los valores se establecen o se devuelven. Ejemplos: Get Auto.Color Set Auto.Color=“Rojo”

Los métodos representan acciones que un objeto puede realizar
Los métodos representan acciones que un objeto puede realizar. Por ejemplo, un objeto “Auto" podría tener los métodos “encenderMotor", “conducir" y “apagarMotor". Los métodos se definen agregando procedimientos, ya sean rutinas o funciones Sub, a la clase. Ejemplo Sub encenderMotor(), Sub conducir(40) Los eventos son notificaciones que un objeto recibe de, o transmite a, otros objetos o aplicaciones. Los eventos permiten a los objetos realizar acciones siempre que se produce un acontecimiento específico. Un ejemplo de evento para la clase “Auto" sería un evento "Check_Engine". Como Microsoft Windows es un sistema controlado por eventos, éstos pueden proceder de otros objetos, aplicaciones o entradas de usuario realizadas al hacer clic con el mouse (ratón) o al presionar teclas. Ejemplo Sub BotonComando1_Click() Se usa para escribir lo que debe ocurrir cuando se haga un click con el mouse en el objeto BotonComando1

Ejemplo: si insertamos un Userform y un CommandButton1, luego hacemos click al Userform1
En la parte inferior izquierda aparece la ventana con todas las propiedades del objeto Userform1 Backcolor, Bordercolor, Borderstyle, Caption, etc. Estas propiedades las podemos cambiar en esa ventana o bien dentro de otro objeto Sub por medio de un mensaje Ejemplo de cambio de propiedades de Userform1

Si ahora hacemos click sobre el CommandButtom1, la ventana de propiedades cambia y aparecen las propiedades asociadas a ese objeto Ejemplo de cambio de propiedades de CommandButtom1

Aún cuando VB6 no es un lenguaje orientado estrictamente a objetos, nos permite ver de manera clara algunas de las ventajas de la Teoría de Orientación a Objetos. Por ejemplo vemos como hay al menos dos objetos (son muchísimos más como veremos más adelante) predefinidos, de uso general, uno de ellos es la UserForm, que es una ventana a la que le podemos alterar sus propiedades así como su comportamiento, el otro es un CommandButtom que también tiene propiedades y operaciones, veamos por ejemplo el CommandButtom1 que ocurre cuando hacemos doble click en él

En este caso aparece a la derecha
Private Sub CommandButtom1_Click() End sub Aquí escribimos el procedimiento que hara el objeto CommandButtom al recibir un click del mouse En el extremo derecho aparece una serie de “eventos” que pueden ser programados para el botón CommandButtom, por ejemplo Dblclick, Enter, Error, Exit, Keydown, Keypress, Keyup, etc. O sea tenemos una Clase, que también es un Objeto, el cual tiene propiedades y hace distintas operaciones de acuerdo a los mensajes que se le envían a través de los eventos Ejemplo de programación de CommandButtom1

Ya vimos como el VB6 nos permite usar algunos objetos predeterminados, bien sea usando “Insert” en el menú, o bien arrastrándolos desde una caja de herramientas, pero ¿de donde vienen estos objetos? ¿podemos crear objetos nuevos, que sirvan para alguna aplicación particular nuestra?. Si hacemos click en “Herramientas”, “Controles Adicionales”, aparece un larga lista de objetos, muchos que no son de Microsoft Los que están chequeados son los que ya aparecen en la caja de herramientas, los que no están chequeados son los que podemos agregar

La idea de programar con componentes es una extensión de las subrutinas de propósito general, por ejemplo, imaginemos que hay que programar varios sistemas diferentes pero todos ellos necesitarán usar ventanas, botones de control, desplegar listas, etc. entonces en lugar de programar para cada aplicación desde cero todas las ventanas, botones y listas lo que se hace es una “library” (biblioteca) con objetos genéricos –o clases- por ejemplo en mi biblioteca incluyo un objeto llamado Ventana que tendrá propiedades variables (color, tamaño, ubicación en la pantalla, etc.) y también tendrá métodos (acciones, operaciones), como por ejemplo aparecer, desaparecer, cambiar de color, etc. También uno mismo puede programar algún componente especial que necesite (por ejemplo un objeto genérico que lea los registros de un archivo), estos componentes se encapsulan con la extensión .ocx Por ejemplo todos los programas que funcionan en Windows aprovechan los cientos de bibliotecas de funciones genéricas .dll que están en C:\Windows y sus sub carpetas, pero además tienen sus propias .dll y .ocx según necesiten.

Así muchos programas diferentes pueden llamar a estas bibliotecas por medio de mensajes, diciendo que objeto quieren usar, cuales deben ser sus propiedades y que operación desean que haga, los diferentes programas serán mucho más sencillos pues no necesitan repetir todo lo que requieren desde cero, basta con que llamen a la biblioteca correspondiente. Estas bibliotecas son los archivos con extensión .dll y otras que acompañan a la mayoría de los programas

Tenemos entonces las. dll,
Tenemos entonces las .dll, .ocx y similares que nos evitan tener que reescribir código repetidamente desde cero para cada aplicación. Como estas bibliotecas y componentes están encapsulados, no tenemos acceso a sus procedimientos internos, sino que funcionan como una caja negra que permite solo cierto tipo de entradas y salidas Es como un televisor que podemos usar, pero nunca lo desarmamos, para encender, apagar, cambiar el canal, volumen, etc.tenemos una forma de enviarle “mensajes” sin que sea necesario modificar los circuitos, esa es la idea de la encapsulación.

INTRODUCCION AL MODELO DE NEGOCIOS SAP

Tradicionalmente la organización era vista como un conjunto de funciones áreas que trabajaban por separado en pos de un objetivo. La especialización del trabajo fue tergiversada hasta un punto en el que se crearon "islas de poder" dentro de las empresas. Así, existían las comarcas de Contabilidad, Tesorería, Operaciones, etc., con sus correspondientes pugnas por ejercer el control y obtener poder unas sobre otras. De esta misma forma, la tecnología de la información en su afán por apoyar el negocio, ideó los sistemas de información. Sistemas segmentados por funciones, dedicados a sólo una parte del todo. El advenimiento de las bases de datos intentó resolver el problema, pero lo complicó aún más. En lugar de centralizar toda la data en un solo repositorio de información, se crearon múltiples bases de datos, al menos una por sistema, complicándose más cuando hay una gran diversidad de plataformas.

El nuevo pensamiento gerencial orienta la organización hacia los procesos y la optimización de los mismos, basado en un enfoque holístico de la empresa. Cuando se formulan procesos se eliminan las "parcelas de poder", y se administran eficientemente los recursos de la misma. La tecnología de la información generó un concepto a la par de estas ideas: sistemas integrados. Sistemas basados en una única Base de Datos, garantizando información consistente e integrada, donde se persigue eliminar la redundancia de tareas y la duplicidad de información. Sistemas que permiten adoptar las mejores prácticas de negocios y mejorar la competitividad y rentabilidad. SAP es uno de estos sistemas integrados. SAP tiene 2 versiones principales SAP Bussiness All-In-One Para empresas con más de 250 empleados SAP Business One Para empresas con menos de 250 empleados

SAP R/3 Es un sistema integrado, todo en uno compuesto de módulos agrupados en tres áreas: logística, contabilidad y recursos humanos todos los módulos están conectados así es que el cambio en un módulo se refleja automáticamente en todos los demás. Los módulos se pueden adaptar a las necesidades específicas de cada empresa variando sus parámetros. SAP tiene un sistema de permisos donde distintos usuarios solo tienen acceso a ciertos módulos y funciones según su perfil

Procesos de Negocios Un proceso de negocio es una cadena de actividades que sumadas producen algo de valor para el cliente, interno o externo. Recordemos la Cadena del Valor de Porter Esta es una cadena de valor agregado, donde los componentes individuales van agregando valor dentro de un proceso para obtener el resultado final. Las tareas deben integrarse, las decisiones se deben tomar localmente, se debe redistribuir la división del trabajo y minimizar las interfases (etapas que no agregan valor)

Para optimizar el proceso de negocio debe buscarse que este sea uniforme, sin cuellos de botella ni interrupciones, como por ejemplo los retrasos producidos por el transporte innecesario de mercaderías, eliminando procesos duplicados y sobre todo las descoordinaciones por falta de información. Los sistemas y tecnologías de información representan un rol clave no solo para el control, sino también para la coordinación y la toma de decisiones estratégicas. Los sistemas de procesamiento de datos normalmente se construyen sobre diseños y un paradigma heredado, como una forma de hacer más eficiente lo mismo que ya se estaba haciendo en forma manual, por ejemplo un sistema de inventarios puede pasar desde un kardex de tarjetas a un sistema computacional, pero el control y el modelo total del negocio permanecen sin cambios. Mejoran eficiencia local, pero no necesariamente la eficiencia corportaiva

SAP tiene dos características interesantes:
Es integrado, es decir abarca todas las necesidades de procesamiento de información de la empresa y no una necesidad específica Es estandar, no es un sistema creado a medida de las necesidades de la empresa, esto presenta la desventaja de que obliga a adaptar los procesos al sistema y la ventaja que no se replican procedimientos globalmente ineficientes, no se heredan los errores Un análisis de los procesos de negocios permite cuestionar los procedimientos tradicionales y –eventualmente- cambiarlos. En SAP esto se lograría mediante la adaptación de los procedimientos a los estándares del sistema.

Implementación Orientada a SAP
Mapear la compañía en una jerarquía de negocios, de acuerdo a la estructura SAP Identificar donde encajan los procesos SAP e incluirlos en el mapa Dividir las tareas en alguna de estas categorías Automáticas (las que se realizarán con SAP) Manuales (las que realizarán los usuarios sin SAP) Transacciones (las que realizarán los usuarios usando SAP Definir el alcance de cada tarea: frecuencia y uso de recursos

SAP es una implementación comercial de un modelo teórico llamado ERP Enterpise Resourcing Planning que propone concentrar todo el planeamiento de recursos de la empresa en un solo sistema de información, a diferencia de los diferentes sistemas tradicionales (contabilidad, inventario, sueldos, etc.) SAP fue desarrollado originalmente en Alemania y ha tenido mucho éxito en grandes empresas en todo el mundo, universidades y escuelas de negocios han hecho alianzas estratégicas para formar personal e investigar mejoras de la implementación

La idea clave de los ERP es imponer un paradigma de organización al que las empresas deben adaptarse en líneas generales, a nivel de detalle es el SAP que se adapta a los requerimientos de la empresa mediante el ajuste de sus parámetros. “Todo en uno” un solo gran sistema de información que contiene todo en una sola base de datos, cada evento inicia una transacción, todo ocurre en tiempo real y no en base a información histórica como en los sistemas tradicionales Módulos de aplicación SAP FI Contabilidad financiera, registra y genera todos los libros contables CO Control, controla el flujo de costos y ganancias, es un intrumento para la toma de decisiones estratégicas que se actualiza automáticamente cuando ocurre cualquier transacción AM Manejo de activos, controla el Activo Fijo, compra y venta de activos, depreciación, etc. PS Sistema de proyectos, permite la planificación, control y monitoreo de proyectos de largo plazo WF Flujo de trabajo, conecta los módulos SAP con otras aplicaciones, herramientas y servicios

IS Soluciones industriales, combina los módulos SAP con aplicaciones específicas según la industria
HR Recursos humanos, sistema completo para apoyar la planificación y control del personal PM Plan de mantenimiento, planifica y controla las operaciones de mantenimiento MM Manejo de los materiales, soporta todas las operaciones relcionadas con los inventarios QM Manejo de calidad, Control de calidad y sistema de planeamiento de las inspecciones PP Planeamiento de la producción, facturación de material, ruteo, centros de trabajo, planeamiento de ventas y operaciones, requerimiento de materiales, costeo, etc. SD Ventas y distribución, entrega, facturación, soporte pre y post venta, etc.

Características a nivel de sistema de SAP
Customizing– es como se configura el sistema para adaptarlo a las necesidades específicas de la empresa, los informes requeridos –internos y externos- y los procesos de negocio Organizational Elements Financial-- client es una unidad legal y organizacional del nivel más alto en SAP company es una entidad legal independiente dentro de un cliente business areas se usan para producir informes de pérdidas y ganancias así como hojas de balance para cada línea de marketing Materials Management Purchasing units Plants Sales and Distribution Sales Organization Distribution channel Division

Master Data son los registros que permanecen en la base de datos por un período extendido de tiempo, por ejemplo: Customer Master Vendor Master Material master Account Master Esta estructura elimina los datos redundantes y es compartida por todos los módulos SAP. Es un aspecto crítico de la robustez del sistema Employee Self Service—los empleados tienen acceso a sus propios registros en el módulo de Recursos Humanos HR a través de Internet. Classification consiste en asignar un objeto a una clase. Cada clase tiene sus características estándar. Matchcodes son herramientas de consulta usadas para encontrar información específica por medio de métodos de búsqueda. Security es administrada por objetos, perfiles y autorizaciones. Los usuarios son solo autorizados a ver o cambiar las partes del sistema requeridas por las responsabilidades de su trabajo.

Office Workplace Telephone Integration Appointment Calendar Room Reservations Start Workflow Business Documents Logistics Materials Management Sales/distribution Logistics Execution Production Production-process Plant Maintenance Customer Service Quality Management Logis. controlling Project Management Environment Health & Safety Central Functions

Accounting Financial Accounting Treasury Controlling Enterprise Control Investmt Mgt. Project management Real Estate Human Resources Managers Desktop Personnel admin. Time management Payroll Training and Event Management Organizational Management Travel Information system

Information Systems Executive Information Systems Logistics Accounting Human Resources Project System Ad Hoc Reports General Report System Tools ABAP/4 Workbench Accelerated SAP Administration ALE Business Communication Business Documents Business Framework Business Workflow CCMS Web Development SAPScript Hypertext Find

En Resumen SAP es un sistema Integrado, “todo en uno” Su mayor utilidad es en las empresas muy grandes ¿Por qué? Obliga a la organización a adaptar sus procesos al sistema Requiere de personal altamente entrenado -ingenieros certificados SAP- Ordena los sistemas de información Elimina las redundancias Es más seguro y más robusto Su implementación es muy cara

UML UNIFIED MODELLING LANGUAGE

UML ayuda a capturar la idea de un Sistema Real para comunicarla a los que deben desarrollar su implementación en un software. Esto se hace mediante la representación gráfica del sistema usando símbolos estandarizados sencillos de entender. Por Sistema Real entenderemos cualquier proceso más o menos complejo de control dentro de una empresa, por Sistema entenderemos el conjunto de software y hardware destinado a controlar el Sistema Real. Tenemos un Sistema Real y debemos llegar a un Sistema Computacional. Antes de empezar a codificar es necesario hacer un plan, un modelo y un diseño (lo que se conoce como diseño lógico) UML sirve para que el modelo pueda ser explicado claramente y sin ambiguedades a los que tendrán que implementar el Sistema Computacional UML es esencialmente una herramienta de comunicación

Existen distintas estrategias para implementar un sistema:
Si es pequeño y simple se puede codificar de inmediato, esa era la forma en que se implementaban antiguamente todos los sistemas Si es complicado, grande o debe cumplir con requisitos de calidad de software, existen dos alternativas: La forma tradicional es hacer un diseño lógico con las especificaciones detalladas que el software debe cumplir, un modelo basado en diagramas entidad/relación o UML servirá para comunicar este diseño lógico a quienes deben hacer el diseño físico (codificación) Otra forma consiste en ir construyendo prototipos y luego componentes en el marco de un diseño lógico menos detallado y más flexible, esto permite que los usuarios y los programadores vayan modificando el diseño en la medida que aparezcan problemas, los componentes deben cumplir con todos los requisitos del diseño orientado a objeto y luego de un proceso de prueba y error se va completando el diseño lógico de modo paralelo al diseño físico

Al estudiar UML lo haremos suponiendo el enfoque original del diseño en cascada, es decir la especificación completa de un modelo antes de empezar a codificar UML no solo sirve para explicar el modelo a los programadores, sino también al cliente, para que tenga claro como va a funcionar antes de que empiece la implementación física Metáfora de un arquitecto diseñando un edificio complejo UML produce gráficos orientados a objetos, se diseñó entre 1994 y 1998, es un estándar bien aceptado para el diseño de sistemas complejos Un modelo UML describe lo que hará el sistema, pero no dice como implementarlo UML permite hacer distintos tipos de diagramas como veremos a continuación:

Diagramas de clases, consiste en agrupar objetos que tienen características y acciones en común, un ejemplo que ya vimos es la clase “LavadoraIndustrial” Diagramas de objetos, un objeto es una instancia de una clase, o sea una entidad con valores específicos de atributos y acciones, por ejemplo, mi lavadora, marca Westinhouse, modelo EW3400, serie etr , capacidad 20 kgs. agregarRopa(si), agregarDetergente(si), sacarRopa (no), su diagrama sería

Diagrama de Casos de Uso: un caso de uso describe las acciones de un sistema desde el punto de vista del usuario. En este ejemplo el “mono” es el “actor” o sea quien usa el sistema (puede ser una persona u otro sistema) y la elipse es el caso de uso Diagrama de estados: muestra como cambia el estado de un objeto en el tiempo

Diagrama de secuencias, muestra las secuencias de operaciones de un sistema. Para el ejemplo de la lavadora podríamos tener como objetos una manguera de agua, un tambor, un sistema de drenaje. Luego de agregarRopa, agregarDetergente y Activar, la secuencia puede ser: La manguera llena el tambor con agua Tambor inactivo por 5 minutos La manguera corta el paso de agua Tambor gira 15 minutos Sale el agua por el drenaje Comienza a entrar agua nuevamente Tambor sigue girando Se corta el agua Sale por el drenaje Tambor gira incrementando velocidad por 5 minutos Tambor se detien, fin del proceso

Diagrama de actividades: las actividades ocurren en un caso de uso o en el comportamiento de un objeto, los 11 pasos del ejemplo anterior se pueden representar en un diagrama de actividades, por ejemplo para las actividades 4 a la 6 Diagrama de colaboraciones: cuando los elementos trabajan en conjunto se puede diagramar la forma en que colaboran, por ejemplo:

Diagrama de componentes: como vimos en clases pasadas, los componentes son cajas negras de software, diseñadas según el modelo orientado a objetos a las que se puede tener acceso a través de mensajes, el símbolo UML para los componentes es: Diagrama de distribución: permite mostrar como se distribuyen físicamente los distintos equipos o componentes de hardware

Paquetes: se usan cuando se quieren organizar los elementos de un diagrama en un mismo grupo, por ejemplo para agrupar varias clases relacionadas Estereotipos: se usan cuando combinamos algunos elementos del UML para crear otro nuevo, por ejemplo podemos crear el estereotipo (o cliché) llamado <<Interfaz>> como una clase especial que hace ciertas operaciones pero no tiene atributos

Ejemplo de un caso de uso real
CA01 Registro de Contribuyente Historial de Revisiones: Fecha Versión Descripción Autor / / 1.0 Caso de uso para ser revisado con los usuarios del sistema – Módulo de Catastro Urbano. Firmas: CA01 Registro de Contribuyente Descripción El actor digitador, después de registrarse en el sistema mediante el usuario y la contraseña puede invocar el caso de uso registro de contribuyente, en el cual podrá registrar nuevos contribuyentes llenando las pestañas correspondientes, también podrá Modificar, Inactivar, Imprimir o Exportar a Excel los datos de un contribuyente seleccionado. Flujo de Eventos Flujo Básico El digitador ingresara un nuevo contribuyente pulsando el botón Nuevo. El sistema activa las pestañas en las cuales el digitador se prestara a llenar los datos que han sido recabado y llenados en las fichas impresas. Una vez llenado los datos se procede a guardar la información dando clic en el botón Guardar. El sistema pide una confirmación del proceso guardar. El sistema vuelve a la interfaz inicial de registro de contribuyente.

Flujos Alternativos En el punto 1 El digitador puede realizar otras acciones como ser: Buscar o Salir del modulo. En caso de realizar una búsqueda y seleccionar algún registro encontrado podrá realizar lo siguiente: Modificar, Inactivar, Imprimir, Exportar a Excel o Salir del modulo. En el punto 2 A partir de este punto hasta el punto 3, el digitador podrá cancelar el registro del contribuyente dando clic en el botón Deshacer. El digitador en este punto deberá de escoger si registra a una persona natural o una persona jurídica. En el punto 4 El digitador podrá negar la confirmación de guardado, regresando al punto 3 con todos los datos ingresados hasta ese momento. Precondiciones El Digitador ha realizado correctamente su ingreso en el sistema mediante el nombre de usuario y la contraseña. El contribuyente no debe de estar registrado. Poscondiciones En caso de haber llenado la ficha registro de contribuyente parcialmente, el digitador podría aumentar la información con la opción Modificar. También podrá Modificar la información en caso se este actualizando los datos del contribuyente. Por cualquier motivo que se modifique, el sistema le pedirá que digite una observación donde puede escribir el motivo por el cual se realizo la modificación. El digitador deberá cerrar el modulo correctamente usando el botón cerrar para no tener posteriormente ningún inconveniente.

Ejemplo real de un caso de prueba
Historial de Aprobaciones: Fecha Versión Descripción Autor / / 1.0 Se aprueba en % el presente caso de uso. Observaciones: Firmas: Ejemplo real de un caso de prueba CP01 - REGISTRO DE CONTRIBUYENTE, PERSONA NATURAL Información de la versión Proyecto: Proyecto Modernización de la Infraestructura de Software, Hardware y comunicaciones en los sistemas de Información de la MPT. Número Interno de Versión: 2.0 Documentos Relacionados:

Datos de Prueba Registro de Contribuyente – Persona Natural Propósito:
Probar que se puede registrar un nuevo contribuyente como persona natural. Pre-requisitos: El contribuyente no debe de estar registrado. Datos de Prueba Procederemos a llenar los campos necesarios: Identificación del contribuyente: Tipo de contribuyente: 1, persona natural Nombres: Miguel Eduardo Apellido paterno: Aguilar Apellido materno: Medina Estado civil: 01, soltero Profesión: 11711, ingeniero, sistemas informáticos Sexo: masculino Homonimia: No Fecha de Nacimiento: 15/04/1977 (Gestión de Cobranza-Trabajo interno) Calif. Contributiva: 003, pequeño contribuyente Calif. SocioEconómica: 003, nivel C Calif. Deudora: 003, pequeño deudor Domicilio Fiscal: Tipo de Vía: 99, no especificado Vía: , no especificado Hab. Urbana: , asoc. De Viv. Villa magisterial Numero: Numero adicional: Nombre de la edificación: Tipo edific.: 02, casa / chalet

Tipo interior: 02, casa / chalet
Num. Interior: Nombre: Manzana: B Lote: 6 Sub lote: Dirección adicional: Documentos: Tipo de documento: 02, DNI Número de documento: Contactos: (para uso de personas jurídicas) Nombre del contacto: Cargo: Teléfonos: Gestores: (Gestión de Cobranza-Trabajo interno) Código gestor: , no especificado Fecha inicio: Fecha fin: Observación: Teléfonos - Teléfono(s) Tipo de teléfono: 05, celular 1 Numero: (s) Dirección: Observaciones: Observación: nuevo contribuyente

Pasos: Entrar al sistema SIGTMv2 Entrar a registro de contribuyente: Registro/Contribuyente Dar clic en la opción nuevo Llenar los campos de identificación del contribuyente Llenar domicilio fiscal Ingresar documento de identidad del contribuyente Registrar algún contacto del contribuyente (para uso de personas jurídicas) Registrar los gestores si los hubiere (Ficha de uso interno) Registrar teléfonos y correo electrónico del contribuyente Ingresar alguna observación (obligatorio) Dar clic en guardar Confirmar la opción de guardado Salir del formulario “Datos del Contribuyente” Salir del sistema SIGTMv2 Pantallas usadas durante el llenado de información del registro del contribuyente

Notas:

UML: Unified Modelling Language Parte 2
Tomás Bradanovic

Que son las clases Como vimos una clase es algo que engloba a objetos con carcterísticas comúnes, en UML se escribe su nombre con la primera letra en mayúsculas y su símbolo es un rectángulo Un paquete también puede hacer la funcionalidad de una clase Si, por ejemplo, la clase LavadoraIndustrial es parte del paquete Electrodomésticos se puede “rutear” de esta manera: Electrodomesticos:: LavadoraIndustrial

Como vimos una clase puede tener varios atributos (propiedades, características) o ninguno, los nombres de atributo siempre empiezan con minúscula. Cada uno de los atributos tiene un valor específico. El nombre de la clase puede ir ruteado y subrayado Además existen las operaciones que puede tener una clase u objeto, las operaciones llevan paréntesis donde se colocan los parámetros No siempre se detallan los atributos y las operaciones o a veces se ponen solo algunos o ninguno

Si son demasiados los atributos y operaciones, o si se necesita quitar o agregar algunos, lo que se hace es crear un esterotipo, con categorías a las que se pueden agregar o quitar elementos Restricciones: los atributos u operaciones pueden estar sujetos a alguna restricción, esta se indica al lado del símbolo entre paréntesis También se pueden incluir notas aclaratorias con el símbolo que se muestra

En las entrevistas con los usuarios para armar un modelo, lo primero que se debe definir son las clases. En la entrevista aparecen sustantivos, algunos son clases y otros son atributos, también aparecen verbos, esas son operaciones. Ejercicio: “En nuestra empresa compramos y vendemos mercadería, mantenemos stock en bodega, para comprar y pagar los gastos de operación usamos una cuenta corriente y además como dueño uso una segunda cuenta para las finanzas personales, la contabilidad legal la lleva un contador externo pero necesito también llevar una contabilidad operativa que me entregue un estado mensual consolidado de resultados. Tenemos la casa central y tres sucursales. Mis problemas de stock son controlar el robo de mercaderías y conocer la rotación de los artículos porque cada mes tengo que hacer los pedidos de compras, necesito saber cuales son los artículos que más se venden y cuales los que dan mayor utilidad, necesito tener algún índice de rotación y utilidad para rankear mis mercaderías. Deseo implementar en cada sucursal un sistema de punto de venta en el mesón, que en el momento de hacer la venta me descargue inmediatamente el inventario y me haga un informe de caja diario, este informe debe acumularse para el informe mensual consolidado” Formule preguntas adicionales y proponga clases, objetos, atributos y operaciones para el modelo

Las Relaciones: construir las clases y objetos es el primer paso, ahora hay que determinar como estas clases se relacionan entre sí Asociaciones: se trata de relaciones de participación en cualquier sentido. Ejemplos:

Supongamos que definimos una superclase llamada SistemaIntegrado, en la que participan dos clases: Inventarios y CuentasCorrientes

Un Vínculo es una instancia (caso particular) de una asociación, por ejemplo para nuestro ejemplo anterior. En las instancias se subraya el nombre del vínculo Multiplicidad: la asociación no tiene por que ser 1 a 1, en el ejemplo anterior sería 500 a 1 como se indica, si hubiesen 3000 distintas clases de mercadería en el bojeto Inventario, su asociación con la clase SistemaIntegrado sería 3000 a 1. Multiplicidad es la cantidad de objetos de una clase que se relacionan con un objeto de la clase asociada

Agregaciones: ocurren cuando una clase se compone de otras clases, las agregaciones se indican con un rombo en la línea que relaciona a las clases, por ejemplo: Composiciones: es una clase especial de agregación, con las subclases que componen una clase (sin una de ellas la clase no funciona) el símbolo es un rombo relleno

Diagramas de Contexto: presentan un detalle de las subclases
Por ejemplo si tenemos un diagrama de Composición de clases como este Podemos mostrar un diagrama de contexto que muestra donde está situado dentro del sistema

Interfaz es el conjunto de operaciones que realiza una clase, se grafica con una línea punteada terminada en flecha sin rellenar Visibilidad: los atributos y operaciones de una clase pueden tener tres niveles de visibilidad: Publicos, cuando se extienden a todas las demás clases, se indica con + Protegidos, cuando se extienden solo a las clases que se heredan, se indica con # Privados, cuando solo se pueden usar dentro de la clase, se indica con -

Ejercicio: hacer las agregaciones detalladas de clases
de un sistema de inventario de un sistema de cuentas corrientes de un sistema de información integrado que haga los reportes mensuales

BUSINESS PRECESS MODELLING NOTATION
BPMN BUSINESS PRECESS MODELLING NOTATION Tomás Bradanovic P.

BPMN: Business Process Modeling Notation
Hasta ahora vimos principalmente el modelamiento de los datos, ahora pasaremos a ver el modelamiento de los procesos de negocio. Vemos como se vuelve a la diferenciación original entre datos y procesos. BPMN es una notación gráfica estándar diseñada para crear modelos que todos los participantes en un proceso de negocio puedan entender: usuarios, analistas, clientes, gerentes, etc. La idea es que usando una cantidad limitada de símbolos podamos crear modelos entendibles que nos ayuden a optimizar –y eventualmente a optimizar- los procesos BPMN ha sido desarrollado para cubrir la brecha entre el diseño y la implementación de un sistema. Fue formado por la Business Process Management Initiative con el Object Management Group

Elementos del BPMN: Eventos
Evento de inicio Evento intermedio Evento final A los eventos específicos se les puede agregar un icono que muestren su significado Un evento intermedio tipo “mensaje”, por ejemplo, puede tener dos instancias: enviando o recibiendo. Los eventos que envían se anotan con un icono relleno, mientras que los que reciben con un núcleo claro En la figura se pueden ver distintas clases de eventos

BPMN: Eventos de partida
Disparador Descripción Símbolo Ninguno No se especifica el tipo de evento, también se usa cuando un sub proceso disparado por el proceso padre Mensaje Llegada/envío de un mensaje y se dispara un proceso Timer Para procesos que parten en un día/hora específica Condicional Es cuando un proceso parte con una condición tal como “si se producen diferencias de inventario teórico y físico” Señal Una señal no es un mensaje con un destino fijo, sino que puede activar muchos procesos distintos Múltiple Muchos eventos distintos pueden activar el proceso, basta con que uno de ellos se cumpla para que el proceso se dispare

BPMN: Eventos intermedios
Disparador Descripción Símbolo Ninguno No se muestra el tipo de evento Mensaje El proceso queda en espera hasta que llegue el mensaje (recepción) o se usa para enviar mensajes (envío), también se usa para desviar excepciones (*) Timer Dispara el proceso en un día/hora determinados, también se usa para desviar excepciones Error Se dispara cuando se produce un determinado error. Solo se puede poner en el extremo de una actividad Cancelar Se puede poner solo en el extremo de un sub proceso. Se dispara cuando recibe un evento “Cancelar” Compensación Activa eventos que compensan alguna acción, puede afectar a una actividad si esta se especifica o a todas las suceptibles de ser compensadas Condicional Es el evento que se dispara cuando una condición tiene valor “True” Link Conecta dos secciones de un proceso, se puede usar –por ejemplo- para crear loops. Puede tener múltiples fuentes pero solo un destino Señal Envía y recibe señales que se comunican a lo largo de todo un flujo a quien pueda interesar Múltiple Es cuando un evento tiene múltiples disparadores, ya sea para recepción como para envío (*) Excepción, es cuando se produce un evento excepcional o inesperado, típicamente un error o algo no previsto

BPMN: Gateways (compuertas)
Las gateways son puntos de decisión para canalizar el flujo Exclusive Data-Based: una o varias salidas son posibles pero solo una condición dirigirá el flujo Exclusive Event-Based: igual que el caso anterior pero escogerá la primera condición que le llegue (race) Inclusive: evalúa dos o más condiciones, el flujo puede salir por una o más ramas en paralelo Complex: sirve para combinaciones de las otras gateways, se escribe en un detalle aparte su comportamiento en cada caso particular Paralel: sincroniza los flujos que salen de manera paralela

BPMN: Swimlanes y Pools
BPMN: Swimlanes y Pools Pools (piscinas) y swimlanes (pistas) se usan para organizar dentro de un bloque actividades afines y mostrar la colaboración entre ellas. Típicamente se usan para organizar un subproceso, una unidad de negocios específica, etc.

Proceso intermedio básico: Races

BPMN: Interrupciones

Flujos condicionales Flujos arbitrarios Ejercicios…
En este ejemplo los flujos son dirigidos según el resultado de la condición asociada (por ej verdadero/falso, cumple/no cumple) State based Aquí los flujos se dirigen según si se ha recibido un mensaje, se ha cumplido una condición o ha pasado cierto tiempo Flujos arbitrarios Ejercicios… (ej. Taller mecánico, tienda ventas detalle, inst. educativo, etc.)

Prototipos en Visual Basic Para Aplicaciones (OOBasic)
Tomás Bradanovic

Modelado con Prototipos
A diferencia de los sistemas anteriores en que hay una separación estricta entre diseño lógico (modelo conceptual) y la implementación física (codificación) el modelo por prototipos es una técnica evolutiva, donde luego de las entrevistas, se bosqueja un diseño lógico y se codifican interfases gráficas de usuario (como cada usuario verá el sistema) se ensayan estas interfases y por medio de prueba y error se van modificando. Una vez llegado a acuerdo se consolida esta parte dentro del diseño lógico. En los sstemas pequeños el prototipeado puede reemplazar al modelamiento lógico, en los sistemas medianos agrandes lo complementa. Se conoce como una técnica de diseño evolutivo, al contrario del diseño en cascada que separa de manera tajante las etapas. En cascada se va de lo másgrande a lo más pequeño, en prototipos de lo pequeño a lo grande. En programas comerciales lo que más se usa es una combinación de Sistema Administrador de Base de Datos y alguna versión de Visua Basic para las interfases de usuario, a continuación veremos algunos ejemplos para codificar prototipos simples en VBA (u OOB para software libre) Discusión: Ventajas y problemas del modelado por prototipos

Prototipo de Agenda

Private Sub CommandButton1_Click()
indice = Hoja1.Cells(1, 1) If indice = "" Then indice = 1 Hoja1.Cells(1, 1) = indice End If indice = indice + 1 Hoja1.Cells(1, 1) = indice Hoja1.Cells(indice, 1) = TextBox1.Text Hoja1.Cells(indice, 2) = TextBox2.Text Hoja1.Cells(indice, 3) = TextBox3.Text Hoja1.Cells(indice, 4) = TextBox4.Text TextBox1.Text = "" TextBox2.Text = "" TextBox3.Text = "" TextBox4.Text = "" TextBox1.SetFocus End Sub

Prototipo de Inventario: Rebajar las Ventas

Prototipo de Inventario: Ingresar Nuevo Artículo

Prototipo de Inventario

Prototipo Cuentas Corrientes: Mostrar Saldos

Prototipo Cuentas Corrientes: Ingresar Movimiento

Prototipo Cuentas Corrientes: Ingresar Nuevas Cuentas

Prototipo Cuentas Corrientes: Listar Cartola

Prototipo de Cuentas Corrientes: Ingresar Movimiento

Prototipo de Cuentas Corrientes
Activar UserForm Muestra Saldo Activar UserForm Ingresa Movimientos

Botón Ingresar Movimiento

Prototipo de Cuentas Corrientes
Mostrar Cartola

Modelamiento en Diseño de Procesos: Introducción

Presentaciones similares

Presentación del tema: "Modelamiento en Diseño de Procesos: Introducción"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Modelamiento en Diseño de Procesos: Introducción

Presentaciones similares

Presentación del tema: "Modelamiento en Diseño de Procesos: Introducción"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback