Modelamiento en Diseño de Procesos: Introducción



Descargar 149,4 Kb.
Página1/5
Fecha de conversión03.04.2017
Tamaño149,4 Kb.
  1   2   3   4   5
  • 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.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?
  • 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.
  • 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
  • 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.
  • SISTEMA
  • Entradas
  • Salidas
  • Realimentación
  • 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     * 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
  • Tomás Bradanovic P.
  • 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"
  1   2   3   4   5


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal