Curso Modelamiento Procesos ESUN-OTA

1. 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.

2. 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.

3. 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.

4. 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.

5. 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

6. 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

7. 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%

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

9. CURSO DE MODELAMIENTO EN DISEÑO DE PROCESOS http://modelamientouta.blogspot.com 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?

10. 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

11. 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. 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: Otros ejemplos de ecuaciones para predecir Explicación y ejemplos de analogías

13. 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.

14. 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

15. 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

16. LA ANALOGIA ELECTRO HIDRAULICA

18. 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

19. 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)

20. 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

21. 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?

22. 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

23. 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

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

25. 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

26. 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.

27. 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

28. 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

29. 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

30. 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.

31. CONCEPTOS BASICOS DE INGENIERIA DE SISTEMAS Tomás Bradanovic P.

32. 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.

34. 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.

35. 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

36. 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.

38. 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.

39. 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

40. 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

41. 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.

42. 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

43. 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.

44. 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

45. 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"

46. 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).

47. INTRODUCCION A LOS SISTEMAS DE ARCHIVOS Y BASES DE DATOS Tomás Bradanovic P.

48. 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

49. 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.

51. 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: 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 765544 CODORNICES 324 DIEGO 3 345566 ACACIAS 222 JUAN 2 223344 LOA 123 PEDRO 1 TELEFONO DIRECCION NOMBRE NRO

52. 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

53. 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í: 765544 CODORNICES 324 DIEGO 345566 ACACIAS 222 JUAN 223344 LOA 123 PEDRO 3

54. 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

55. 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).

57. 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

58. 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

59. 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 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

60. 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

61. 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

62. 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:

63. 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

64. 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.

65. 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.

66. 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

67. -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" El DBMS es el que aisla y relaciona la capa superior con los datos físicos, tiene tres subcomponentes:

68. 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.

69. 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.

70. 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.

71. 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.

72. 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.

73. 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.

74. INTRODUCCION A LOS MODELOS ENTIDAD-RELACION Tomás Bradanovic P.

75. 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

76. 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

77. Empleado: Artículo: Nombre Descripción Puesto Costo Salario Clave R.F.C. Símbolo Representa Un ejemplo simple http :// sistemas.itlp.edu.mx / tutoriales /basedat1/tema1_4. htm

78. 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

79. ENTIDADES 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 http :// caos.cl / jms /

80. 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 http :// caos.cl / jms /

81. José Miguel Santibañes, Sistemas de Información http :// caos.cl / jms / 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)

82. 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 http :// caos.cl / jms /

83. 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 IDENTIFICANDO Y MODELANDO RELACIONES Siga la secuencia de pasos que se indican, para extraer las relaciones de notas de entrevistas. José Miguel Santibañes, Sistemas de Información http :// caos.cl / jms /

84. ATRIBUTOS 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 http :// caos.cl / jms /

85. 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 http :// caos.cl / jms /

87. 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 http :// caos.cl / jms /

89. PRIMERA FORMA NORMAL 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 La relación entre el identificador de la entidad y sus atributos debe ser 1:1 en esa dirección José Miguel Santibañes, Sistemas de Información http :// caos.cl / jms /

90. 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 http :// caos.cl / jms /

91. 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 http :// caos.cl / jms /

92. INTRODUCCION A LA ORIENTACION A OBJETOS Tomás Bradanovic

96. 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 Aspiradoras Tostadoras Superclase Subclase Las Supercalses pueden ser Subclases de otras

97. 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.

98. Envío de mensajes : los objetos se comunican entre sí enviándose mensajes a través de interfaces. Interfase Interfase Encendido() agregarRopa() 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

99. 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()

100. 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

101. 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

102. 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

103. 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.

104. 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”

105. 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

106. 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

107. 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

108. 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

109. 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

110. 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

111. 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:indows y sus sub carpetas, pero además tienen sus propias .dll y .ocx según necesiten.

112. 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

113. 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.

114. INTRODUCCION AL MODELO DE NEGOCIOS SAP Tomás Bradanovic P.

115. 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.

116. 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. http://help.sap.com/ http :// www.sap.com / http :// www.sapfans.com / http://www.sap.com/chile/ 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

117. 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

118. 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)

119. 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

126. 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

136. 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

137. UML UNIFIED MODELLING LANGUAGE Tomás Bradanovic P.

138. 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