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.
Otros ejemplos de ecuaciones para predecir
Probablemente el estudio de los fenómenos ondulatorios dió mucho impulso a
la Teoría General de Sistemas: fenómenos completamente distintos como las
ondas en el agua al caer una piedra, el movimiento del péndulo de un reloj, un
sonido propagándose por el aire, las ondas e luz o de radio obececen todas a
ecuaciones del tipo y=K*sen(x+algo), o sea fenómenos muy disintos compartían el
mismo modelo matemático. También se observaron en física muchas analogías
entre fenómenos muy distintos que podían representarse con un mismo modelo,
por ejemplo la analogía entre un sistema hidráulico y uno eléctrico. Todas estas
analogías y similitudes llevaron a formular en los años 30 la Teoría General de
Sistemas basada en ciertos conceptos básicos:
Explicación y ejemplos de analogías
1. Los sistemas tienen características comunes a todos
2. Por lo anterior la TGS es integral, abarca todo lo que existe: sistemas
físicos, químicos, biológicos, sociales, económicos, etc. uno se puede
aproximar a cualquier fenómeno usando un enfoque de sistemas, que
es una forma de aproximarse a la realidad
3. Un sistema se puede modelar como una caja negra, que
tiene entradas, las procesa, entrega salidas y a veces
se realimenta. El concepto de caja negra es algo que estudiamos desde
afuera, sin importarnos como funciona internamente, solo nos interesa
saber que pasa con las entradas (estímulos) y con las salidas
(respuestas) del sistema.
Realimentación
SISTEMA
Entradas
Salidas
Ejemplos de cajas negras con sus entradas y salidas
Cuando se trata de conocer lo que pasa dentro de la caja negra estudiando
como se modifican las salidas en función de las entradas eso se
llama Ingeniería Reversa
Ejemplos de ingeniería reversa
Un computador es un ejemplo clásico de caja negra: lo alimentamos con
información y obtenemos respuestas sin tener idea del detalle de los
millones de operaciones intenas involucradas ni como funcionan. Cuando
usamos el computador lo hacemos con el enfoque sistémico, es decir de
caja negra.
Supongamos que necesito traducir un párrafo en inglés, voy al computador
y entro al traductor en línea Babelfish, ingreso el párrafo (o sea alimento la
caja negra con una entrada), cliqueo los botones adecuados y obtengo mi
traducción.(o sea mi salida) ¿es necesario saber en detalle como opera el
computador o como funciona el algoritmo traductor?, claro que no, para eso
es el sistema de caja negra, los procesos de detalle lo hacen otros y
nosotros no tenemos para que saber como funcionan: sería muy ineficiente
si todos tuvieramos que aprender en detalle como funciona cada cosa. El
concepto de caja negra es muy importante, volveremos sobre él a menudo.
4. Los sistemas pueden ser reales, que existen independientemente de
nosotros y los podemos descubrir o no, ejemplos de sistemas reales son el
clima, la economía, los organismos, etc. todo lo que tiene independencia de
nosotros. También existen los sistemas ideales que solo existen en el
intelecto, por ejemplo la lógica, las matemáticas, etc. Finalmente existen
los modelos que son abstracciones de la realidad. Los modelos son el tipo
de sistema que estudiaremos en este curso.
5. Un modelo es una abstracción de la realidad, una representación
simplificada, exprimida de algo real a la que le hemos sacado todo lo
irrelevante y le hemos dejado solo lo que más nos importa. Lo que es
"relevante" o "irrelevante" es completamente relativo a lo que nos interesa
obtener de nuestro modelo. En un muñeco lo relevante será que tenga un
parecido físico con lo real, en el modelo de un puente lo relevante será que
las características de resistencia, flexibilidad, etc sean parecidas, en el
modelo de un negocio lo relevante puede ser las cantidades de dinero y como
se comportan bajo distintas condiciones.
Ejemplos de sistemas reales, ideales, modelos
6. Los sistemas tienen a su vez subsistemas y también son parte de
sistemas mayores. Por ejemplo el sistema de contabilidad de una
empresa tiene distintos subsistemas (cuentas por cobrar, caja, activos,
pasivos, etc.) pero también es parte de otros sistemas mayores (las
finanzas de la empresa, las finanzas de la ciudad, del país, etc.). Por eso
en la TGS es importante definir el ámbito de acción, o sea las fronteras
dentro de las cuales estudiaremos un sistema.
Ejemplos de subsistemas y supra-sistemas
La TGS tiene dos campos de actividad: Investigar el isomorfismo de
conceptos, leyes y modelos en varios campos y facilitar las transferencias
entre aquellos. promoción y desarrollo de modelos teóricos en campos que
carecen de ellos y reducir la duplicación de los esfuerzos teóricos,.
promoviendo la unidad de la ciencia a través de principios conceptuales y
metodológicos unificadores.
Ejemplos de isomorfismo
LA ANALOGIA ELECTRO HIDRAULICA
MODELAMIENTO
Competencia que un ingeniero debe poseer: captar una cierta problemática y
poder representarla en algún modelo usando, por ejemplo el lenguaje de
modelación UML o un gráfico entidad relación.
El proceso de abstracción es una constante en el desarrollo de actividades
que involucran el modelamiento. Este proceso es difícil de enseñar en
términos tradicionales, es más bien una capacidad que los estudiantes ya
traen y que es necesario orientar y potenciar para poder desarrollar las
competencias específicas que posibilitarán un desempeño exitoso en el
ámbito del modelamiento de sistemas y bases de datos.
La asignatura Modelamiento de Datos es una asignatura donde los
estudiantes se enfrentan al problema de modelar sistemas administrativos,
procesos, problemas de control, etc.
Ejemplos de abstracción
Que es La Teoría General de Sistemas
Como la Teoría de Conjuntos, la Teoría General de sistemas pretende hacer
una abstracción que represente una gran cantidad de cosas distintas. El
concepto de "sistema" es muy general, algunas definiciones de lo que es un
sistema son:
"una cantidad de elementos y relaciones" (Klaus)
"una parte de la realidad, observable y que se puede describir" (Muller)
“algo que posee elementos, estructura, vecindad, recibe y envia magnitudes
concretas a su vecindad" (Semard)
Casi cualquier cosa la podemos considerar un "sistema" que además suele
tener partes o subsistemas: por ejemplo una industria es un sistema, uno de
sus talleres es un sistema parcial de los cuales los operarios de torno serían
otro subsistema. También la industria podría ser subsistema de un parque
industrial, etc.
Ejemplos de sistemas con sus elementos y relaciones
(Ej. Ctas. Corrientes, Inventarios)
En la teoría de Sistemas distinguimos a un sujeto que observa y objetos que
son estudiados. El sujeto estudia, interpreta y crea conocimientos, pero los
objetos suelen tener muchas facetas de estudio y es imposible (además de
inútil) estudiar su "realidad total" así se crea un sistema, que es "un análogo
de un objeto real". Es decir el objeto y el sistema son dos cosas distintas,: el
sistema es una imagen del objeto real que sirve para simplificar su estudio.
De aquí deducimos que para un mismo objeto pueden existir diferentes
sistemas (abstracciones) que lo representen según que es lo que nos interesa
estudiar.
La clave de la Teoría de Sistemas consiste en que, si bien todos los
sistemas pueden ser distintos, existen estructuras y relaciones que son
comunes a muchos de ellos: por ejemplo el movimiento del agua en un río y
el comportamiento de una multitud de personas a la salida de un estadio son
de una naturaleza material absolutamente distinta, pero se pueden
establecer analogías entre ambos fenómenos. En la naturaleza existe una
gran cantidad de sistemas análogos y si hacemos abstracción de la realidad
material, vemos que muchos sistemas absolutamente distintos se pueden
caracterizar por un mismo conjunto de relaciones.
Ejemplos de distintos modelos para un mismo fenómeno
Ej.-Una ciudad puede tener un modelo vial y otro de
seguridad ciudadana
Sistema Elemental (o Elemento Activo)
Un sistema elemental tiene a lo menos una magnitud de entrada y una de
salida. Veamos un ejemplo práctico, si queremos estudiar el movimiento
de la carga que maneja un puerto puedo definir un sistema sencillo que
considere la carga que entra al puerto y la que sale de él. Así el complejo
sistema llamado "puerto" lo hemos reducido, por abstracción a una "caja
negra" a la cual le podemos medir (digamos, en toneladas) la carga que
entra para embarque y la carga que se desembarca de los buques. Con
este sencillo modelo podemos estudiar, por ejemplo, en que épocas del
año hay atochamientos, cuando hay más capacidad ociosa.
Nuestro modelo de puerto es un elemento activo que posee una vecindad
(los barcos y la ciudad) a la que le entrega determinadas magnitudes
(toneladas de carga), la vecindad también le entrega a nuestro puerto
magnitudes por lo que ambos interactúan constantemente.
¿Qué otra utilidad podría tener el modelo elemental de puerto?
A nuestro modelo podemos complicarlo agregando otras variables para hacer
más exacto nuestro estudio: por ejemplo la cantidad de trabajadores, la
capacidad de las bodegas y la disponibilidad de camiones para transportar la
carga. Todas esas magnitudes influirán finalmente en la cantidad de carga que
en realidad se mueve y también existirán otras magnitudes externas, como los
días con marejada que obligan a mantener el puerto cerrado, etc. Así vemos
como el comportamiento de nuestro sistema está influenciado por si mismo y por
el exterior.
Lo importante de este ejemplo es como hemos hecho abstracción de muchas
cosas (como el paisaje, la forma de las instalaciones físicas, etc.) para
concentrarnos solo en algunas pocas características que nos interesan: hemos
creado un modelo que nos será más útil, por ejemplo, que una fotografía o una
película. Teniendo nuestro modelo podemos "jugar" con las variables para
estudiar que pasaría, si establecemos las relaciones que nos interesan en forma
matemática (por ejemplo una función que indique cuanto aumenta la capacidad
de movimiento en relación a la capacidad de las bodegas) podemos calcular
teóricamente y de antemano si es conveniente o no construir nuevas bodegas.
Ventajas y desventajas de agregar muchas variables
Clasificación de los Sistemas
Grado de Abstracción
Abstractos
Reales
Ejemplos
Transformación en el tiempo
Estáticos
Dinámicos
Ejemplos
Complejidad
Simples
Complejos
Muy complejos
Ejemplos
Certeza del comportamiento
Determinados
Estocásticos (al azar)
Ejemplos
Linealidad
Lineales
No lineales
Ejemplos
Armonía
Abiertos
Cerrados
Ejemplos
Estabilidad
Estables
Inestables
Mixtos
Ejemplos
Funciones o Relaciones de un Sistema
Cuando hacemos un modelo lo que tratamos es establecer cuales son las
relaciones entre las magnitudes de entrada y las de salida. Así, en un modelo
abstracto podemos tener varias entradas, varias salidas y una función de
sistema que describe matemáticamente como se relacionan las salidas con las
entradas, o sea
S=T(E)
Donde S es el conjunto de las magnitudes de salida, E el conjunto de
magnitudes de entrada y T la función que las relaciona.
Siguiendo nuestro ejemplo práctico, podríamos establecer (por observación)
que al aumentar la cantidad de camiones nuestro puerto aumentará su
capacidad de movimiento de carga en un factor de x veces, etc.
También existen relaciones de retroalimentación, donde las magnitudes de
salida influyen en las de entrada (por ejemplo si los embarques aumentan
mucho, entrarán mas empresas de camiones a trabajar al puerto y viceversa)
Explicitar las funciones de entrada y salida
Teoría de los Modelos
Un modelo fundamentalmente es algo que obtenemos después de un
proceso de abstracción, es decir tomamos un sistema real y hacemos
una imágen de el, más simple y más clara que el original.. Al construir
un modelo tratamos de captar lo que es esencial en el sistema, lo que
a nosotros nos interesa estudiar y lo que pensamos que nos servirá
para ese estudio. Todo lo demás lo desechamos.
Un modelo facilita la comprensión de un sistema complejo,
representando lo que es significativo para nuestro estudio, es una
imitación de la realidad. Así, tenemos el objeto real, el sujeto que lo
estudia y el modelo, que tiene relaciones de analogía o similitud con el
objeto real y permite al sujeto obtener conclusiones relativas al
sistema.
Clasificación de los Modelos
Modelos de Afirmación
Describen al sistema usando palabras, se usan en los sistemas más
complejos donde no es factible determinar relaciones matemáticas. Estos
modelos son muy debilmente predictivos y se limitan a hacer una descripción
verbal y cualitativa del sistema. Sin embargo son muy usados en sistemas
administrativos Ejemplo
Modelos Físicos
Son objetos materiales usados para demostración y, en menor medida para
experimentación cuantitativa. Ejemplo
Modelos Gráficos
Son modelos ideales que usan medios de expresión gráfica, Ejemplo
Modelos Formales
Son los modelos abstractos, matemáticos ampliamente usados en la
investigación científica. Consideran los parámetros variables escenciales de
un fenómeno y sus relaciones descritas en forma de ecuaciones matemática
Ejemplo
Como Modelar
Ordenar las opiniones: para modelar se debe primero que nada observar el
sistema y recoger información relevante, luego se determina sobre qué base
será construído el modelo según las relaciones de analogía que se observen.
También en esta etapa se determinará a que objetivo será construido el modelo
Elaborar los elementos esenciales y sus acoplamientos el modelo se va
conformando de acuerdo a las relaciones de analogía encontradas
Experimentar con modelos: se trata de buscar modelos alternativos o variantes
del configurado originalmente para ver si se puede perfeccionar la similitud con
el comportamiento relevante del modelo real
Decidir la solución óptima: de todos los modelos experimentados se escoge al
que represente al sistema de la mejor manera para nuestros propósitos
Prueba del modelo: se deben diseñar y ejecutar pruebas que confronten la
capacidad predictiva del modelo con respuestas conocidas del sistema, de
manera de detectar si hay omisiones o errores relevantes
Ejemplo: modelar un curso
Tres Técnicas Fundamentales
* El método de conclusiones por analogías
* 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"
NOTA IMPORTANTE: Para sistemas pequeños muchos de los problemas
mencionados no existen y por ello algunos de los criterios desarrollados por la
Ingeniería de Software no se aplican.
Los productos de software (que en adelante llamaremos
Sistemas) pueden ser de dos clases
Genéricos (por ejemplo Word, Excel, etc.)
A la medida (por ejemplo el software del control de las
fronteras)
Los sistemas, además de el conjunto de archivos con
ejecutables compilados y bibliotecas usualmente tienen los
siguientes componentes adicionales
• Documentación de los requerimientos (casos de uso)
• Documentación de los diseños (especificaciones de
diseño)
• Código fuente
• Planes de prueba (casos de prueba)
• Manual de operación y ayuda (manual de usuario)
• Instrucciones de instalación
• Procedimientos de mantenimiento (planes de respaldo,
protocolos de reporte de error, planes de contingencia, etc.)
Como se desarrolla un sistema
Planificación y estimaciones: en esta etapa se planifican las actividades, se asignan los
tiempos, los requerimientos de recursos humanos, físicos y se estima el presupuesto de
cada etapa así como el presupuesto total del proyecto
Análisis de los requisitos: aquí se descompone el problema que se pretende modelar en
sus detalles, determinando que es lo que se requiere que haga el sistema
Diseño: en esta etapa se crea el modelo y el diseño lógico con todas las entradas, salidas y
procesos que debe ejecutar el sistema
Codificación: el diseño creado en la etapa anterior se materializa escribiendo en lenguaje
de programación las instrucciones para llevar a cabo cada una de los módulos según las
especificaciones del diseño lógico
Prueba: la etapa de prueba es simultánea a la de codificación a nivel de detalle pero
también posterior, cuando se ensamblan los módulos. Finalmente cuando se entrega todo el
sistema para producción comienza una tercera fase de la etapa de prueba que es para todo
el sistema bajo condiciones reales.
Mantenimiento: en esta etapa se agregan nuevos módulos, se modifican o se quitan según
vayan cambiando los requerimientos del sistema, se ejecutan programas de respaldo de
datos y sistema, etc.
Concepto de Calidad de Software
La calidad de un software tiene que ver con la percepción subjetiva acerca de su
desempeño, robustez, prestaciones, etc. y se percibe en dos niveles:
Nivel Externo, es como perciben el software los usuarios del sistema
Nivel Interno, es como perciben el software los profesionales de la computación
En el nivel externo, la percepción de calidad suele variar mucho según las
expectativas de los usuarios algunas de estas son objetivas como:
Corrección: cuando el sistema ejecuta sin errores todas sus funciones, tal como han
sido especificadas en el diseño.
Robustez: cuando el sistema no se cae en condiciones excepcionales o anormales
Modificabilidad: la capacidad para adaptarse al cambio en sus especificaciones
Compatibilidad: capacidad para acoplarse y trabajar en conjunto con otros sistemas
Ergonomía: capacidad para hacer las tareas con la mayor facilidad para el operador,
evitando la duplicación de entrada de datos, el paso innecesario por varias etapas
para hacer una tarea, etc.
Integridad: capacidad para protegerse contra accesos no autorizados, robo de
información, modificación maliciosa, etc.
Facilidad de uso: aprendizaje sencillo, operación sencilla, reportes de calidad
Sin embargo existen otros criterios de percepción de calidad por parte de los usuarios que,
sin ser tan objetivos, son los que causan los mayores conflictos:
Disconformidad con el diseño del sistema: pese a que el diseño se construye en base a
encuestas y estudio de las necesidades de los usuarios, este no es siempre 100%
funcional a sus intereses porque existen muchos otros criterios que el diseño debe
considerar, por ejemplo al mejorar la seguridad y los controles normalmente se perjudica la
ergonomía, los jefes pueden haber introducido requisitos adicionales al sistema para
prestaciones y trabajos que antes no se efectuaban, el sistema puede ser menos robusto
ante el ingreso equivocado de datos, etc. En general los usuarios siempre comparan el
nuevo sistema con el antiguo y distintos usuarios tienen distintas prioridades, por lo que no
existe un sistema que pueda dejar a todos conformes por igual, los operadores desearan
hacer lo mismo con menos trabajo, los clientes desearán tener prestaciones adicionales,
los jefes más control y seguridad, etc. todos esos requerimientos están frecuentemente en
conflicto por lo que no es raro que la percepción de calidad difiera para los diferentes
usuarios.
Aversión al cambio: operadores y usuario están acostumbrados al sistema antiguo y se
molestan al tener que cambiar sus métodos de operación y aprender otros nuevos.
Falsos errores de sistema: producidos por errores de operación durante la curva de
aprendizaje, durante el período de prueba en explotación suelen producirse fuertes
tensiones y recriminaciones mutuas entre operadores y el equipo de desarrollo por esta
causa
En el nivel interno algunos de los principales factores de calidad son:
Seguridad: es la capacidad de protección del sistema ante ataques
intencionados o negligencias para mantener la integridad y confidencialidad
de los datos
Robustez: es la capacidad de continuar funcionando correctamente en
circunstancias adversas tales como flujos anormalmente grandes, errores de
operación, etc.
Modularidad: que es la capacidad de cada componente del programa de
funcionar de manera independiente, posibilitando el reemplazo, reutilización,
etc. sin tener que afectar al sistema completo
Legibilidad: el código debe estar escrito de manera clara y tan auto
documentado como sea posible en cada uno de sus módulos de manera que
cualquiera lo pueda entender, mantener, reparar, etc.
Ciclo de vida del software
El ciclo de vida son las etapas por las que pasa un sistema desde su
concepción hasta su explotación en régimen. Existen varios modelos de los
cuales revisaremos tres:
Clasico
El ciclo de vida clásico consiste en el desarrollo secuencial en una serie de
pasos, cada paso genera las entradas y la documentación para el siguiente:
Entrevistas
Especificaciones de casos de uso
Diseño lógico
Diseño Físico
Casos de Prueba
Documentación
Producción
Este ciclo de vida todavía se ocupa para el desarrollo de sistemas pequeños
por su simplicidad, pero en la mayoría de los sistemas se usa una variante
llamada
Ciclo Clásico en Cascada
En este caso también se recoge información, se hacen especificaciones de
diseño, se hace un diseño lógico y finalmente se codifica, la diferencia es
que el flujo no es secuencial sino que las correcciones afectan no solo a la
etapa inmediatamente anterior sino a todas las etapas. Al crecer los
sistemas aparecen una serie de inconvenientes en el desarrollo en
cascada, como:
* Es difícil imaginar de antemano los requerimientos de las etapas que
siguen
* Muchos problemas no siguen un flujo secuencial
* Los errores se detectan solo cuando se pone a prueba todo el sistema
Ciclo de vida por prototipado
Los prototipos son versiones iniciales de un producto o un módulo, que
permiten que el cliente y el futuro operador vean como se va a comportar,
den sus impresiones y críticas, ayudan a establecer las necesidades reales
del cliente quien muchas veces no las tiene claras al momento de ser
entrevistado.
EL DISEÑO EN CASCADA
La ingeniería de sistemas se preocupa del análisis y modelamiento del sistema que se
pretende construir. El trabajo consiste a grandes rasgos en entender el problema, fijar las
prioridades y especificarlas en un modelo lógico que normalmente se concreta como un
listado exhaustivo de especificaciones sobre estructuras de datos, que es lo que el
programa debe hacer, las entradas, procesos y salidas..
El trabajo de la ingeniería de sistemas tiene que ver con la organización, las necesidades y
expectativas de los clientes, la idea es definir y ordenar las prioridades en una capa lógica
abstracta, antes de enredarse con los detalles técnicos de la codificación y es por eso que
se le da gran importancia al trabajo de encuestas en esta etapa, de manera de tener claras
las prioridades y expectativas.
Luego viene el trabajo de ingeniería de software que consiste en codificar las
especificaciones entregadas y convertirlas en un programa que funcione. El trabajo en una
primera instancia consiste en construir prototipos de las interfases de usuario, es decir un
programa "de mentira" para determinar las mejores interfases hombre-máquina y, una vez
elegido esto dedicarse a codificar y optimizar los procesos que el sistema debe realizar,
todo esto apegado a las especificaciones entregadas por el diseño lógico. La construcción
de prototipos semi funcionales es de gran ayuda al momento de probar el comportamiento
real de las ideas del diseño.
Esta es la teoría. La construcción de un programa debe ser un proceso en cascada donde
el diseño ideal debe preceder a la codificación. En el desarrollo de programas
computacionales según se nos ha enseñado, existen dos etapas claramente definidas: el
diseño lógico y el diseño físico. En la realidad sin embargo, esta separación ha sido fuente
de diversos problemas
POR QUE SE DISEÑA EN CASCADA
Esta separación entre diseño lógico y el diseño físico es consecuencia de los
problemas de crecimiento de tamaño y complejidad en los sistemas. En un principio
ambas etapas estaban estrechamente relacionadas, y lo siguen estando en el caso de
los sistemas pequeños donde trabaja solo un programador o un pequeño grupo de
personas.
Pero al hacer sistemas más complejos y dividir las tareas entre un equipo de
programadores era necesario fijar prioridades y criterios de diseño de antemano, de
manera que todos trabajen bajo normas claras y criterios comunes. Esto evita el
problema de desviarse de los grandes objetivos por percepciones o necesidades
particulares de alguno de sus subsistemas. También divide el trabajo en una parte
creativa y normativa (diseño lógico) y otra mecanizada y sujeta a normas (diseño
físico).
El diseño en cascada ha formado una verdadera cultura que separa a analistas y
programadores. Harry Boehm de la Universidad de California del Sur cuenta su
experiencia al respecto: "Cuando tratamos de introducir el uso de prototipos en
proyectos con alta interacción de usuarios en TRW, los ingenieros de software,
resistiéndose al cambio, golpeaban la mesa y gritaban, "¡No pueden hacer
esto! ¡hacer prototipos es codificar sin haber pasado la revisión crítica del diseño,
esto esta absolutamente prohibido por las políticas corporativas!" , tomó años
deshacer las muchas formas en que el modelo de cascada se había infiltrado en
varios aspectos de nuestra cultura corporativa tales como el marketing, preparación
de propuestas, estimación de costos, contratos, contabilidad y gerenciamiento"
Y CUAL ES EL PROBLEMA?
Hay un viejo cuento de un ingeniero de sistemas que decía haber diseñado finalmente
un software que podía rivalizar con el cerebro humano. Al pedírsele que lo demostrara
entregó una larga lista con las especificaciones comunes de un computador a las que
había agregado las especificaciones de "imaginación", "conciencia de si mismo",
"lenguaje sofisticado" etc. "Bueno", dijo a modo de explicación "allí tienen el diseño,
ahora solo es cosa de los programadores y los ingenieros de hardware implementarla.
Lo principal ya esta hecho.
Bueno, ese es uno de los mayores problemas de trabajar en abstracto
desentendiéndose de los problemas prosaicos tales como la codificación, los recursos
disponibles, costos y el rendimiento. Los ingenieros de sistema vienen normalmente de
las áreas de la ingeniería industrial o de la administración (ingeniería comercial en
Chile), no son fuertes en programación y a menudo ven con cierto desprecio la labor del
programador, considerándola mecánica y poco creativa.
No es raro que los diseños lógicos, al desentenderse de los detalles del mundo real
tales como las limitaciones de hardware o la complicación excesiva en el código
terminen en una serie de especificaciones y requisitos que no es factible de implementar
con éxito. Esos son los conocidos "desastres informáticos" o sistemas que llevan mucho
tiempo, esfuerzo y dinero en desarrollarse y que nunca llegan a funcionar del todo bien
(muchos simplemente jamás funcionan).
INTRODUCCION A LOS SISTEMAS DE ARCHIVOS Y
BASES DE DATOS
Tomás Bradanovic P.
Introducción a Los Archivos y Bases de Datos
Los computadores, desde su inicio se han convertido en la herramienta para
modelar por excelencia porque tienen dos potentes características para esta
tarea: pueden almacenar información de manera persistente y pueden
ejecutar procedimientos automatizados (cálculos, búsqueda, selección, etc.).
Las primeras aplicaciones hacían una diferencia clara entre datos y procesos,
los datos eran información estática, guardada en algún lugar que se podía
manipular (procesar) por medio de programas, entonces los datos se
guardaban en archivos que podían ser de tamaño más o menos fijo (como un
archivo con los datos de cuenta para un programa de cuentas corrientes) y
otros de tamaño variable (como los archivos de movimiento que crecen en el
tiempo), en este esquema tenemos:
Archivo de datos
Archivo de datos ----------- Programa
Archivo de datos
En este esquema, que todavía se usa en sistemas pequeños, el programa es
fundamental y actúa sobre los datos, recuperándolos, buscando o
modificando y luego los muestra arreglados de cierta forma.
Volviendo al ejemplo de cuentas corrientes podemos tener un módulo de
programas -por ejemplo- para listar el analítico de una cuenta (la cartola)
este módulo pediría la identificación de la cuenta (clave de búsqueda) y se
iría al archivo de nombres de cuentas, para recuperar el nombre del titular,
su RUT, su límite de crédito, etc. Esos son los datos a desplegar en el
encabezado de la cartola.
Luego el programa recorrería secuencialmente el archivo de movimientos,
que tiene los registros de todas las cuentas almacenados en secuencia,
seleccionando solo los registros que corresponden a la cuenta solicitada y
los desplegaría como líneas de la cartola, del más antiguo al más nuevo.
Operaciones con Archivos
Almacenar datos en una tabla
Esta es la forma mas usada por ser sencilla e intuitiva, es lo que
usan las bases de datos "relacionales" y los archivos planos de
tipo "random" o aleatorio. Consiste en definir campos, nombres y
largos, con lo que describimos una grilla cuyas "lineas"
corresponden a "registros" y las "columnas" a "campos". Los que
conocen las bases de datos o las hojas de cálculo conocen bien
esta idea, por
ejemplo:
NRO
NOMBRE
DIRECCION
TELEFONO
1
PEDRO
LOA 123
223344
2
JUAN
ACACIAS 222
345566
3
DIEGO
CODORNICES 324
765544
También existieron en su época las bases de datos
jerárquicas pero nunca tuvieron tanto éxito como las
relacionales. El hecho es que estamos acostumbrados a
almacenar datos en tablas
Archivos planos vs. Archivos con formato
Los datos se pueden guardar en un soporte magnético (discos duros), en
cinta, en CD, DVD, etc. En la actualidad el soporte magnético es el más
usado porque da la mejor relación entre capacidad de almacenamiento vs
tiempo de recuperación de los datos.
Los datos se graban en archivos, que tienen un nombre y agrupan un
conjunto de datos según cierto orden o estructura. Existen dos formas
distintas de guardar datos: los archivos planos o texto claro, que usan solo
los caracteres del conjunto ASCII normal y guardan los datos tal cual si los
escribiesemos en un block de notas.
La otra forma es en un archivo con formato, que usa caracteres especiales
o bien algún sistema de encriptación u ocultamiento de la información para
que los datos solo se puedan ver usando el programa específico por quien
tiene los permisos. En un archivo de texto plano cualquiera puede ver los
datos simplemente usando el notepad o algún editor de textos básico
Ejemplos de archivo con formato y de texto plano
Los Archivos Random
Son una manera sencilla de guardar los datos en un archivo plano usando Visual
Basic.
Necesitamos guardar en algún lado la cantidad de registros almacenados, para
saber en que posicion se guardará el registro siguiente (en el ejemplo mostrado
hay 3 registros). Esto podria hacerse en otro pequeño archivo con un solo
registro o, por ejemplo, en la primera posicion del mismo archivo, el que quedaría
físicamente así:
3
PEDRO
LOA 123
223344
JUAN
ACACIAS 222
345566
DIEGO
CODORNICES 324
765544
Nótese que eliminamos el campo correspondiente al "número", éste no
necesitamos grabarlo pues está implícito en la posición física donde va grabado
el registro.Luego necesitamos grabar los datos "alineados" es decir todos los
campos deben tener el mismo largo. Supongamos que definimos de antemano
que el campo "nombre" debe tener 30 caracteres, el campo "direccion" 40
caracteres y el campo "teléfono" 20 caracteres ¿como los alineamos?
Simplemente agregándole espacios en blanco. Por ejemplo si entramos el valor
"PEDRO" en el campo de nombre (5 caracteres) tendremos que agregarle 25
espacios en blanco, a "JUAN" (4 caracteres) le agregamos 26 espacios, etc. No
es necesario hacer una rutina para agregar espacios pues esto se hace
fácilmente en Visual Basic con:
Type Registro_de_agenda
Nombre as string * 35
Direccion as string * 40
Telefono as string * 20
End Type
Global Agenda as Registro_de_agenda
Este código se guarda en un módulo .Bas donde van las declaraciones, valores
de inicialización y variables globales o públicas, etc. Las instrucciones
Type....End Type convierten los valores que entramos en esas variables en largo
fijo y la declaración Global (o Dim, Public o Private, según nos convenga) sirve
para crear variables "con apellido" llamadas "tipos de datos definidos por el
usuario", así de ahora en adelante las variables se llamarán:
Agenda.Nombre
Agenda.Direccion
Agenda.Telefono
Esta es una notación muy conveniente y emparentada con la notación de
objetos: es decir el objeto "Agenda" tendría las propiedades "nombre",
"dirección" y "telefono" Luego, para crear un archivo del tipo "random" nos falta
usar solo tres instruciones más "Open" (abre un archivo), "Put" (graba un
registro), "get" (lee un registro) y "Close" (cierra el archivo).
Para "iniializar" un archivo con 1000 registros en blanco por ejemplo, abrimos
una Form, le colocamos un botón con el Caption "Inicializar (Borrar todo)" y le
programamos el evento click con:
Sub Inicializar()
Open "Archivo_de_Agenda" for Random as 1
For z=1 to 1000
Agenda.Nombre=""
Agenda.Direccion=""
Agenda.Telefono=""
Put 1, z, Agenda
Next z
Close
End Sub
¿Se podría usar el archivo sin inicializarlo? si, el único inconveniente sería al
leer registros vacíos aparecería "basura" es decir cualquier información que
haya en el buffer en ese momento
Sub LeerRegistro()
Open "Archivo_de_Agenda" for Random as 1
Get 1, z, Agenda
Nombre=Agenda.Nombre
Direccion=Agenda.Direccion
Telefono=Agenda.Telefono
Close
End Sub
Sub agregar()
Open "Archivo_de_Agenda" For Random As 1
rem
rem leer el indice, incrementar y grabarlo
rem
Get 1, 1, Agenda
ultimo = Val(Agenda.nombre)
If Val(ultimo) = 0 Then ultimo = 1 rem si esta
vacio lo pone en 1
Puntero = ultimo + 1
Agenda.Nombre = Puntero
Put 1, 1, Agenda
rem
rem puntero almacena donde debe grabarse el
nuevo registro
rem
Agenda.Nombre = Text1.Text
Agenda.Direccion = Text2.Text
Agenda.Telefono = Text3.Text
Put 1, Puntero, Agenda
Close
End sub
Sub listar()
Open archivo For Random As 1
rem leer el indice
Get 1, 1, Agenda
ultimo = Val(Agenda.Nombre)
rem listar
For z%=2 to indice
Get 1, z%, agenda
List1.AddItem Agenda.Nombre
Next z
Close
End Sub
Existen dos problemas que a menudo están relacionados al usar archivos
random, son los de buscar (y encontrar) rápidamente un registro y presentar el
archivo ordenado según algún criterio. En ambos casos se usa uno o
más archivos auxiliares de índice, que almacenan la ubicación física de los
registros en distintos órdenes según se requiera.
Para recuperar un registro dentro de un archivo hay dos formas posibles:
1.- hacer una búsqueda secuencial desde el primer registro, uno por uno,
chequeando si es el valor buscado, esto se usa cuando hay que ubicar –por
ejemplo- a una persona por el nombre o parte de él
2.- recuperar directamente por medio de un código que dirija al número de orden
en que el registro está ubicado (por ejemplo para eso se usan los códigos de
barras o los códigos numéricos)
Programar estos índices y usar métodos de ordenación y búsqueda más
sofisticados son procedimientos complicados, y es una de las razones que
originaron y popularizaron el uso de motores de base de datos que automatizan
estas dos tareas. En la programación convencional sin usar bases de datos, se
usan normalmente el método ISAM (Indexed Sequencias Access Mode) y el
algoritmo Quick Sort.
En bases de datos se usa el SQL (structured query language) para estos fines
Los Archivos secuenciales
En los archivos secuenciales los datos no se almacenan en campos de largo fijo
sino como una secuencia continua de datos con algún caracter delimitador que
los separa, el ejemplo anterior –delimitado por comas- quedaría asi:
Pedro,Loa123,223344,Juan,Acacias 222,345566,Diego,Codornices
324,245512… etc.
Un archivo secuencial es como una tira de salchichas donde los datos solo
pueden ir agregandose al final y se debe leer y escribir la secuencia completa
cada vez. Son por lo general complicados de actualizar, ordenar y bastante
lentos, pero tienen algunos usos interesantes como por ejemplo grabar archivos
de texto completos y particularmente archivos del tipo .ini, muy usados en
Windows para ingresar settings
Para usar archivos secuenciales en almacenamiento de datos el procedimiento
es trabajar con toda la sarta de salchichas almacenada en un array en memoria.
Esto limita bastante el tamaño y el rendimiento de estos archivos. Me parece
que las hojas de cálculo usan una estrategia similar y por eso son tán limitadas
en cuanto al manejo de hojas grandes. Para leer un archivo secuencial de texto
en una lista List1, usamos:
Para leer un archivo secuencial en Vbasic usamos
Sub leerarchivo()
Dim Lineatemporal As String
List1.Clear
Open "Archivo_de_Datos" For Input as 1
While not EOF(1)
Line Input 1, Lineatemporal
List1.Additem Lineatemporal
Wend
Close 1
End Sub
Y para escribir (agregar al final) usamos:
Sub escribearchivo()
Open "Archivo_de_Datos" for Append Shared As 1
Print 1, "dato a grabar"
Close 1
End Sub
Este es un ejemplo típico de como trabajan los sistemas procedurales, o sea
donde lo más importante es el proceso. Estos sistemas fueron los primeros en
desarrollarse y tienen muchos inconvenientes a medida que el volumen de datos
crece demasiado (los procesos de búsqueda y recuperación se hacen muy
lentos).
Otro problema es cuando los procesos se complican demasiado, los programas
crecen mucho y llegan a ser imposibles de comprender, excepto por el propio
programador que los hizo. Otro problema de estos sistemas es que el diseño
depende mucho de como están almacenados físicamente los datos (en que
formato), los datos se guardaban en formatos propietarios e incompatibles con
otros programas.
Bases de Datos
Lo anterior se llamaba el problema de la dependencia físico-lógica. "Poco a poco,
el centro de gravedad de la informática, que estaba situado en el proceso, se
desplazo hacia la estructuración de los datos, siendo actualmente los aspectos
relacionados con este tema un eje fundamental alrededor del cual gira una gran
parte del conjunto de problemas con los que se enfrenta todo diseñador de un
sistema de información”.
Se cambia, por tanto, de sistemas orientados hacia el proceso a sistemas
orientados hacia los datos, donde estos adquieren el protagonismo, pasando
desde el plano más bien oscuro y difuso en el que estaban situados a ocupar un
lugar privilegiado en el interés de todo informático.
Surge así, a finales de los sesenta y principios de los setenta, la primera
generación de productos de bases de datos en red (basados en lo que
posteriormente se conocería por modelos jerárquicos y Codasyl), entre los que
destacaron por su impacto el IMS de IBM y el IOMS de Cullinet. Estos productos,
si bien resultaban bastante eficientes, presentaban lenguajes procedimentales,
que obligaban al programador a navegar (registro a registro) por la base de
datos, y que no disponían de la suficiente independencia físico/lógica, lo que
conllevaba una escasa flexibilidad" (Mario Piattini Velthuis).
La base de datos relacional se inventa en 1970, básicamente consiste en un
conjunto de reglas (un modelo) teóricas que independizan las operaciones sobre
los datos de la forma en que estos están almacenados físicamente para ello una
base de datos relacional tiene tres componentes: -Un motor de base de datos
DBMS, que es el conjunto de programas que maneja la creacción y acceso a los
datos físicos, distintos motores de bases de datos deben llevar al mismo modelo
en la capa superior
El DBMS es el que aisla y relaciona la capa superior con los datos físicos, tiene
tres subcomponentes:
-Un lenguaje de definición de datos DDL para definir y documentar las
estructuras de datos
-Un lenguaje de manipulación de datos DML para hacer procesos con los datos
-Un lenguaje de consultas SQL para hacer consultas y obtener vistas de los
datos
La base de datos relacional es la más usada por su sencillez y porque coincide
con nuestra idea intuitiva de como se deben almacenar los datos, relacional, en
palabras simples significa "organizadas como una tabla, en filas y columnas"
pero también existen otras dos formas de organización: jerárquica y en red. La
organización jerárquica sigue el modelo de un organigrama, un arbol geneológico,
etc. con un nodo "raíz" del cual se van descolgando subnodos, la clave de una
organización jerárquica es que cada hijo solo puede tener un padre, o sea solo una
dependencia hacia arriba como muestra la figura:
La tecnología XML, de gran importancia por su potente aplicabilidad en
sistemas de Internet usa un esquema jerárquico para organizar los
datos.
La organización en red es escencialmente igual que la jerárquica pero con el
agregado que los hijos pueden tener varios padres, en estas bases de datos
se usa un registro conector para indicar con quienes está conectado el dato.
Son muy poco usadas por su complejidad.
El Diseño en Tres Capas
Las bases relacionales normalmente se usan en conjunto con la arquitectura en
tres capas (3 Layer Architecture) que consiste en estandarizar y aislar las
operaciones en capas:
1. Capa Física, es el nivel real donde están almacenados los datos (por ejemplo
el disco duro) como se almacenan, en registros, como se indexan, etc. Este
nivel tiene asociada una representación de los datos en registros y campos,
denominada esquema físico. Es un nivel restringido a muy pocas personas.
2. Capa Conceptual, corresponde a una visión de la base de datos, es la
organización lógica de los datos sin importar donde están físicamente
almacenados.
3. Capa de Visión, los usuarios solo tienen acceso a pequeñas porciones de la
capa conceptual (vistas o subconjuntos), rara vez al conjunto total. Por ejemplo
un cajero debe tener su visión restringida a lo que necesita usar y no a ver los
sueldos de sus superiores, la capa conceptual define y divide estas parcelas
para los usuarios.
Ventajas de las bases de datos
1. Independizan los datos de los procesos, si se cambia de programa no es
necesario cambiar los datos y viceversa, porque son bases estandarizadas,
bajando así los costos de mantenimiento.
2. Coherencia, reducen la redundancia (usando la normalización) y se evitan
las inconsistencias (que un mismo dato tenga dos valores distintos al mismo
tiempo)
3. Los datos son más disponibles, ni las plicaciones ni los usuarios son
"dueños" de los datos por tecnología, solo por diseño, los datos pueden ser
usados por distintas aplicaciones y distintos usuarios. Los datos pueden
usarse aunque no haya ningún programa, usando solo el SQL.
4. Procedimientos normalizados, iguales para todos los casos, no hay
procedimientos excepcionales, los accesos y operaciones permitidas están
claramente definidos.
5. El acceso concurrente es mucho más sencillo, por ejemplo varios usuarios
pueden acceder simultáneamente a una misma base de datos e incluso a un
mismo registro, las bases de datos tienen mecanismos incorporados para
evitar inconsistencias a diferencia de los archivos tradicionales.
Desventajas de las Bases de datos
1. Requieren de muchos programas e instalaciones para funcionar:
bibiotecas, APIS, módulos, etc. lo que dificulta la portabilidad, no es sencillo
portar ni migrar una base de datos. La migración entre sistemas legados a un
nuevo sistema es uno de los procesos más críticos y complicados, aunque
hay muchas utilidades para esto.
2. Aunque estándares dentro de su ámbito, el esquema de almacenamiento
físico es propietario y muy oculto, cuando una base de datos se corrompe es
muy difícil recuperar los datos que han quedado intactos, porque su acceso
físico está muy encapsulado.
3. Vulnerabilidad, las bases de datos tienden a ser monolíticas y por lo mismo
muy vulnerables, hay que tener mucho cuidado con las políticas de respaldo.
Algunas marcas de base DBMS:
- MySql, tiene licencia GPL (gratis) basada en un servidor, es
muy rápida pero su rendimiento decae cuando almacena
demasiados datos
-PostgreSqul y Oracle, son de los más poderosos, para grandes
volúmenes de datos
-Access, es el DBMS "casero" de Microsoft almacena los datos
en archivos con extensión mdb, viene con la licencia de los
productos de Office
-Microsoft SQL Server, es la DBMS profesional de Microsoft su
licencia se vende aparte y funciona con los lenguajes .Net como
Visual Basic, etc.
INTRODUCCION A LOS MODELOS
ENTIDAD-RELACION
Tomás Bradanovic P.
Modelos Entidad-Relación
Los programas procedurales que trabajan con archivos Se diseñan
pensando en resolver un problema mediante un flujo, o secuencia de
operaciones que se efectúan sobre uno o más archivos de datos. Los
archivos de datos normalmente se diseñan en base a los informes que
debe entregar el sistema. Esto funciona bien para los sistemas pequeños
o sencillos.
En sistemas más complejos donde no existe uno sino decenas o cientos
de archivos relacionados el diseño de la estructura de los datos se
complica mucho pues aparecen problemas de redundancia,
inconsistencias y pérdida de información. Las bases de datos no son
estáticas y a medida que el sistema va creciendo se van requiriendo
nuevos informes, cálculos y análisis, si no existe un modelo de datos bien
especificado pueden ocurrir problemas catastróficos
Un modelo de datos es una colección de herramientas conceptuales para
describir y organizar los datos, existen principalmente dos niveles
Modelos lógicos basados en objetos
Modelos lógicos basados en registros
Los modelos basados en objetos están en lo que llamamos la “capa de visión”
o sea como vemos los datos en el mundo real, existen varios modelos, los
principales son los de estructuras de datos y modelos entidad/relación
Los modelos entidad/relación están muy influenciados por las matemáticas,
especialmente la teoría de conjuntos, define Entidades que son cosas que
existen y tienen características que las distinguen, por ejemplo la entidad auto
se puede distinguir por su marca, modelo, motor, etc. Estas características se
llaman atributos y las entidades interactúan mediante relaciones.
Los modelos son representaciones gráficas similares a los diagramas de flujo,
aunque con una metodología completamente distinta
Un ejemplo simple
Empleado:
Nombre
Puesto
Salario
R.F.C.
Símbolo
Artículo:
Descripción
Costo
Clave
Representa
http://sistemas.itlp.edu.mx/tutoriales/basedat1/tema1_4.htm
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)
R equerim ientos de Inform ación del N egocio
E strategia
Capa Visión
M odelam iento C onceptual
de D atos
M odelo Entidad - R elación,
D efinición de Entidades
A nálisis
D iseño
Capa Diseño
D iseño de la B ase de D atos
D efinición de Tablas
Indices, vistas, C luster,y
D efiniciones de espacio
C ontrucción de
la B ase de D atos
C onstrucción
B ase de D atos O peracional
Capa Física
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 semitangibles (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/
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.
P A R T IC IP A N T E
CU RSO
in scrito
to m a d o p o r
CHEQUE
p ara
EM PLEA D O
el recep to r
de
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)
EM PLEA D O
(T R A B A JA D O R )
D EPA RTA M EN TO
A U T O M O V IL
FA CTU RA
José Miguel Santibañes, Sistemas de Información http://caos.cl/jms/
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)
obligatorio
uno
opcional
m uchos
(pata de gallo )
José Miguel Santibañes, Sistemas de Información http://caos.cl/jms/
IDENTIFICANDO Y MODELANDO RELACIONES
Siga la secuencia de pasos que se indican, para extraer las
relaciones de notas de entrevistas.
DETERMINE LA EXISTENCIA DE UNA RELACION
Cuando hay dos sustantivos juntos que son entidades, las palabras de entre
medio son a menudo relaciones
NOMBRE LA RELACION
¿Cómo está relacionada una ENTIDAD A con una ENTIDAD B?
DETERMINE LA OPCIONALIDAD DE LA RELACION
¿Debe una ENTIDAD A ser {nombre de relación} de una ENTIDAD B?
¿Siempre?
DETERMINE LA CARDINALIDAD DE LA RELACION
¿Podría una ENTIDAD A ser nombre de relación de más de una ENTIDAD
B?
¿Podría una ENTIDAD B ser nombre de relación de más de una ENTIDAD
A?
VALIDE LA RELACION
Re – examine el Modelo E – R y valide la relación.
Lea la Relación en Voz Alta
José Miguel Santibañes, Sistemas de Información http://caos.cl/jms/
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
CU RSO
PERSONA
có d ig o
n o m b re
sex o
p eso
d u ració n
v alo r
EM PLEADO
n ú m ero id en tificació n
n ú m ero en p lan illa d e su eld o
n o m b re
ap ellid o
fech a d e n acim ien to
situ ació n em p leo
José Miguel Santibañes, Sistemas de Información http://caos.cl/jms/
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
C L IE N T E
incorrecto
id
fecha contactado
CONTACTO
fecha contactado
lugar
resultado
C L IE N T E
para
sujeto
de
id
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/
OPCIONALIDAD DE ATRIBUTOS
PERSONA
*
*
o
*
o
có d ig o
n o m b re
títu lo
sex o
p eso
Atributos obligatorios *
Atributos opcionales o
IDENTIFICANDO Y MODELANDO ATRIBUTOS
Siga la secuencia de pasos que se indican, para extraer los atributos desde
notas de entrevistas.
1.Atributos son a menudo sustantivos seguido de otro sustantivo.
“El nombre de un Proyecto...”
Condiciones también referencias atributos
“...Entonces el Proyecto es completado...”
1.Pregunte al usuario
¿Qué información necesita Ud. Conocer o tener acerca de la entidad x?
¿Qué información le gustaría a Ud. Desplegar o imprimir acerca de la entidad
x?
José Miguel Santibañes, Sistemas de Información http://caos.cl/jms/
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/
NORMALIZACION
La normalización es una técnica para desarrollar y evaluar modelos de datos.
La normalización fue originalmente un invento del Dr. Codd, un investigador de la
IBM, y ha sido refinada y extendida por varios otros científicos de bases de datos
desde su introducción en 1972.
Regla de Normalización
Descripción
Primera Forma Normal (1NF)
La relación entre el identificador de
la entidad y sus atributos debe ser
1:1 en esa dirección.
Segunda Forma Normal (2 FN)
Un atributo debe ser dependiente
del identificador completo de la
entidad
Tercera Forma Normal (3 FN)
La relación entre cualesquiera dos
atributos que no son identificador
de la entidad, excepto atributos no
duplicados, no debe ser de uno a
uno en ninguna dirección.
La 3FN es la regla apropiada para eliminar la redundancia en el diseño de base de datos
José Miguel Santibañes, Sistemas de Información http://caos.cl/jms/
PRIMERA FORMA NORMAL
La relación entre el identificador de la entidad y sus atributos debe ser 1:1
en esa dirección
Ejemplo
¿Cumple la entidad CLIENTE con 1NF? Si no, ¿Cómo podría ser convertido a 1NF?
CLIEN TE
# identificador
* fecha contacto
El atributo fecha contacto tiene múltiples
valores, por lo tanto la entidad CLIENTE no
está en 1Nf.
CONTACTO
C L IE N T E
para
# fecha contacto
o localización
o resultado
sujeto
de
# identificador
Si un atributo tiene múltiples valores, cree una entidad adicional y
relaciónela con la entidad original con una relación M:1
José Miguel Santibañes, Sistemas de Información http://caos.cl/jms/
SEGUNDA FORMA NORMAL
Un atributo debe ser dependiente del identificador único de su entidad.
CUENTA
#
*
*
*
n ú m e ro
sa ld o
fe c h a d e a p e rtu ra
d ire c c ió n d e l b a n c o
a d m in istra d o
por
BANCO
e je c u tiv o
de
# n ú m e ro
* n o m b re
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/
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
ORDEN
#
*
*
*
*
id
fecha de orden
id de cliente
nom bre del cliente
estado
C L IE N T E
encargado
de
ORDEN
* id
* fecha de orden
para
* id
* nom bre
* estado
José Miguel Santibañes, Sistemas de Información http://caos.cl/jms/
INTRODUCCION A LA ORIENTACION A OBJETOS
Tomás Bradanovic
La orientación a objetos es la teoría principal para el desarrollo de software
en sistemas grandes, algunas de sus ventajas son:
- Ayuda al desarrollo por componentes
- Desarrollo modular
- Permite crear objetos reutilizables
La orientación a objetos es un modelo, un paradigma que se usa para
muchas cosas, desde los modelos lógicos hasta los lenguajes de
programación orientados a objetos, este modelo se basa en ciertos
principios fundamentales.
Un objeto es cualquier cosa concreta o virtual, el mundo se compone de
objetos y específicamente en el software creamos objetos que imitan o
representan a otros objetos reales
Un objeto es la instancia de una clase (por ejemplo una persona es una
instancia de la clase “seres humanos”), las clases son objetos de otras
clases mayores
Los objetos tienen características que pueden ser
-Atributos (o propiedades)
-Acciones
-Una clase, además de agrupar a los objetos de una cierta categoría, sirve
como “molde” para fabricar nuevos objetos. Esta es una característica
importante al escribir software: las clases sirven para crear nuevas
instancias
El modelo se puede
hacer más exacto
agregando más
atributos y acciones
relevantes
Para que un objeto cumpla con los requisitos del paradigma debe tener las
siguientes características:
1. Abstracción
2. Herencia
3. Polimorfismo
4. Encapsulamiento
Además debe tener las capacidades para
1. Enviar mensajes
2. Asociarse
3. Agregarse
Abstracción: quitar todas las propiedades de un objeto dejando solo las
que son necesarias. Las propiedades relevantes dependen del problema
ejemplo lavadora
Herencia: las clases heredan sus propiedades hacia abajo, por eso una
clase es una plantilla que sirve para crear nuevos objetos, esto evita repetir
las propiedades, basta con que sea una subclase para que las propiedaes
sean heredadas por defecto ejemplo electrodomésticos – lavadora
Superclase
Las Supercalses
pueden ser
Subclases de otras
Aspiradoras
Tostadoras
Subclase
Polimorfismo: una operación puede tener el mismo nombre en diferentes
clases, en cada clase puede operar de manera distinta, por ejemplo la
operación abrir(). Cada clase debe “saber” como funcionan sus operaciones,
ejemplo: abrir un archivo, abrir una ventana, abrir un acceso a base de datos
son operaciones distintas que llevan el mismo nombre, ´la clase donde están
define como opera.
Encapsulamiento: consiste en ocultar el funcionamiento interno de sus
operaciones, el objeto muestra una funcionalidad pero no da acceso al
prodedimiento detallado, el encapsulamiento permite la integridad y la
interoperabilidad entre objetos, ejemplo a una función
abrirBaseDatos(nombre,#registro) solo tenemos acceso a sus parámetros,
pero no a su funcionamiento interno. El encapsulamiento también se llama
ocultamiento.
El mundo real está lleno de ejemplos de encapsulamiento, usamos autos,
teléfonos, vemos televisión, etc. sin saber en detalle como funcionan, solo nos
interesa conocer sus funcionalidades.
Envío de mensajes: los objetos se comunican entre sí enviándose
mensajes a través de interfaces.
Interfase
Encendido()
Interfase
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
Asociaciones: dos objetos se pueden asociar entre si mediante una
relación, la asociación se materializa a través de mensajes, pero se
diferencia en que la asociación se refiere más bien a la naturaleza de los
mensajes. Las asociaciones tienen direción –pueden ser en una sola
dirección o en dos direcciones o vías- también dos objetos pueden asociarse
en más de una forma, ejemplo Pedro y Juan pueden ser colegas de trabajo,
pero también amigos o compañeros de equipo de fútbol, etc.
Un solo objeto o clase se puede asociar con otros varios, esto se llama
multiplicidad o diversificación, es decir pueden haber asociaciones uno a uno,
uno a muchos, o muchos a uno.
Agregación: consiste en la asociación de varios objetos que funcionan para
un fin común, ejemplo, en un programa de inventario puede haber un objeto
leerRegistro(), grabarRegistro(), listarInventario(), etc. todos trabajan
asociados. La composición agrupa a todos los componentes que son vitales
para que la agregación funcione, por ejemplo un sistema de inventario no
puede funcionar sin un objeto leerRegistro()
Orientación a objetos=objetos+clasificación+herencia+comunicación
Abstracciones de datos (atributos) y procedimientos=modularidad
Ocultamiento de la información (encapsulamiento) minimiza el impacto de
los cambios, ejemplo, compartimientos estancos en los barcos
Los métodos (operaciones) manipulan los atributos, que son limitados
(cohesión interna). La clase forma una “muralla” alrededor de los métodos,
que solo son accesibles por las “puertas” de sus parámetros a través de
mensajes. Esto produce un bajo acoplamiento con los demás componentes
del sistema.
Las clases se organizan en jerarquías, como muestra la figura
Ejemplo de uso del polimorfismo
Supongamos que tenemos un objeto que debe recibir datos y hacer uno de
los siguientes gráficos: barra, torta, líneas o nube de puntos, por el método
tradicional debería programarse algo como:
case of tipo_grafico:
if tipo_grafico=grafico_barra then DibujarBarras(datos);
if tipo_grafico=grafico_torta then DibujarTorta(datos);
if tipo_grafico=grafico_linea then DibujarLinea(datos);
if tipo_grafico=grafico_nube then DibujarNube(datos);
End case
Si definimos una clase Grafico y cuatro subclases para cada tipo,
podríamos reemplazar todo esto por una sola línea
tipo_grafico dibujar
Donde la operación dibujar será distinta para cada tipo_grafico
Objetos y componentes
Como dijimos la Teoría de Orientación a Objetos es un paradigma, muy bien
estructurado con bases matemáticas en la Teoría de Conjuntos, por esto tiene
definiciones y requisitos estrictos que definen cuales enfoques on orientados a
objeto y cuales no (deben cumplir con los requisitos de abstracción, herencia,
polimorfismo, encapsulación, etc.)
Existe un desarrollo teóricamente más relajado que toma muchas de las
definiciones y métodos de la orientación a objetos aunque no cumple
estrictamente con todos los requisitos, es el desarrollo modular de
componentes.
Por ejemplo los lenguajes de programación C++, C#, Visua Basic.net son
orientados a objetos, mientras el Visual Basic.6 o el Visual Basic Para
Aplicaciones son lenguajes orientados a componentes, que no cumplen con
algunos de los requisitos de la Teoría de Objetos
Visual Basic 6 no implementa de manera nativa la herencia ni el polimorfismo,
aunque se pueden simular ambos requisitos, la crítica fundamental es que VB
6 no restringe y permite crear objetos que violen estos dos requisitos. Se
puede decir que VB6 es un lenguaje orientado a eventos que usa objetos y
muchos de los conceptos de la Teoría de Objetos
Como el Visual Basic 6 y VBA son los lenguajes más usados para
desarrollar aplicaciones comerciales a nivel de micro y mini
aplicaciones (inventarios, cuentas corrientes, etc.) los usaremos como
ejemplos para mostrar como se aplica la orientación a objetos en el
desarrollo de software
Clases y objetos
Las palabras "clase" y "objeto" se utilizan con tanta frecuencia en la
programación orientada a objetos que es fácil confundir los términos.
En general, una class es una representación abstracta de algo,
mientras que un objeto es un ejemplo utilizable de lo que representa la
clase. La única excepción a esta regla la constituyen los miembros de
clases compartidas, que pueden utilizarse en instancias de una clase y
en variables de objeto declaradas como tipo de la clase.
Campos, propiedades, métodos y eventos
Las clases se componen de campos, propiedades, métodos y eventos.
Los campos y propiedades representan información que contiene un
objeto. Los campos se parecen a las variables en que se pueden leer y
establecer directamente.
Por ejemplo, si tiene un objeto denominado “Auto", podría almacenar su
color en un campo denominado "Color".
Las propiedades se recuperan y establecen como los campos, pero se
implementan mediante los procedimientos Get propiedad
y Set propiedad, que proporcionan más control sobre la forma en que
los valores se establecen o se devuelven. Ejemplos:
Get Auto.Color
Set Auto.Color=“Rojo”
Los métodos representan acciones que un objeto puede realizar. Por
ejemplo, un objeto “Auto" podría tener los métodos “encenderMotor",
“conducir" y “apagarMotor". Los métodos se definen agregando
procedimientos, ya sean rutinas o funciones Sub, a la clase. Ejemplo
Sub encenderMotor(), Sub conducir(40)
Los eventos son notificaciones que un objeto recibe de, o transmite a,
otros objetos o aplicaciones. Los eventos permiten a los objetos
realizar acciones siempre que se produce un acontecimiento
específico. Un ejemplo de evento para la clase “Auto" sería un evento
"Check_Engine". Como Microsoft Windows es un sistema controlado
por eventos, éstos pueden proceder de otros objetos, aplicaciones o
entradas de usuario realizadas al hacer clic con el mouse (ratón) o al
presionar teclas. Ejemplo
Sub BotonComando1_Click()
Se usa para escribir lo que debe ocurrir cuando se haga un click con
el mouse en el objeto BotonComando1
Ejemplo: si insertamos un
Userform y un
CommandButton1, luego
hacemos click al Userform1
En la parte inferior izquierda
aparece la ventana con todas
las propiedades del objeto
Userform1
Backcolor, Bordercolor,
Borderstyle, Caption, etc.
Estas propiedades las
podemos cambiar en esa
ventana o bien dentro de otro
objeto Sub por medio de un
mensaje
Ejemplo de cambio de
propiedades de Userform1
Si ahora hacemos click sobre
el CommandButtom1, la
ventana de propiedades
cambia y aparecen las
propiedades asociadas a ese
objeto
Ejemplo de cambio de
propiedades de
CommandButtom1
Aún cuando VB6 no es un lenguaje orientado estrictamente a objetos,
nos permite ver de manera clara algunas de las ventajas de la Teoría
de Orientación a Objetos.
Por ejemplo vemos como hay al menos dos objetos (son muchísimos
más como veremos más adelante) predefinidos, de uso general, uno
de ellos es la UserForm, que es una ventana a la que le podemos
alterar sus propiedades así como su comportamiento, el otro es un
CommandButtom que también tiene propiedades y operaciones,
veamos por ejemplo el CommandButtom1 que ocurre cuando hacemos
doble click en él
En este caso aparece a la derecha
Private Sub CommandButtom1_Click()
End sub
Aquí escribimos el procedimiento que hara el objeto
CommandButtom al recibir un click del mouse
En el extremo derecho aparece una serie de “eventos” que pueden
ser programados para el botón CommandButtom, por ejemplo
Dblclick, Enter, Error, Exit, Keydown, Keypress, Keyup, etc.
O sea tenemos una Clase, que también es un Objeto, el cual tiene
propiedades y hace distintas operaciones de acuerdo a los mensajes
que se le envían a través de los eventos
Ejemplo de programación de CommandButtom1
Ya vimos como el VB6 nos permite usar algunos objetos
predeterminados, bien sea usando “Insert” en el menú, o bien
arrastrándolos desde una caja de herramientas, pero ¿de donde vienen
estos objetos? ¿podemos crear objetos nuevos, que sirvan para alguna
aplicación particular nuestra?. Si hacemos click en “Herramientas”,
“Controles Adicionales”, aparece un larga lista de objetos, muchos que
no son de Microsoft
Los que están chequeados son
los que ya aparecen en la caja
de herramientas, los que no
están chequeados son los que
podemos agregar
La idea de programar con componentes es una extensión de las
subrutinas de propósito general, por ejemplo, imaginemos que hay que
programar varios sistemas diferentes pero todos ellos necesitarán usar
ventanas, botones de control, desplegar listas, etc. entonces en lugar
de programar para cada aplicación desde cero todas las ventanas,
botones y listas lo que se hace es una “library” (biblioteca) con objetos
genéricos –o clases- por ejemplo en mi biblioteca incluyo un objeto
llamado Ventana que tendrá propiedades variables (color, tamaño,
ubicación en la pantalla, etc.) y también tendrá métodos (acciones,
operaciones), como por ejemplo aparecer, desaparecer, cambiar de
color, etc.
También uno mismo puede programar algún componente especial que
necesite (por ejemplo un objeto genérico que lea los registros de un
archivo), estos componentes se encapsulan con la extensión .ocx
Por ejemplo todos los programas que funcionan en Windows
aprovechan los cientos de bibliotecas de funciones genéricas .dll que
están en C:\Windows y sus sub carpetas, pero además tienen sus
propias .dll y .ocx según necesiten.
Así muchos programas diferentes pueden llamar a estas bibliotecas
por medio de mensajes, diciendo que objeto quieren usar, cuales
deben ser sus propiedades y que operación desean que haga, los
diferentes programas serán mucho más sencillos pues no necesitan
repetir todo lo que requieren desde cero, basta con que llamen a la
biblioteca correspondiente.
Estas bibliotecas son los archivos con extensión .dll y otras que
acompañan a la mayoría de los programas
Tenemos entonces las .dll, .ocx y similares que nos evitan tener que
reescribir código repetidamente desde cero para cada aplicación.
Como estas bibliotecas y componentes están encapsulados, no
tenemos acceso a sus procedimientos internos, sino que funcionan
como una caja negra que permite solo cierto tipo de entradas y salidas
Es como un televisor que podemos usar, pero nunca lo desarmamos,
para encender, apagar, cambiar el canal, volumen, etc.tenemos una
forma de enviarle “mensajes” sin que sea necesario modificar los
circuitos, esa es la idea de la encapsulación.
INTRODUCCION AL MODELO DE NEGOCIOS SAP
Tomás Bradanovic P.
Tradicionalmente la organización era vista como un conjunto de funciones
áreas que trabajaban por separado en pos de un objetivo. La especialización
del trabajo fue tergiversada hasta un punto en el que se crearon "islas de
poder" dentro de las empresas. Así, existían las comarcas de Contabilidad,
Tesorería, Operaciones, etc., con sus correspondientes pugnas por ejercer el
control y obtener poder unas sobre otras.
De esta misma forma, la tecnología de la información en su afán por apoyar
el negocio, ideó los sistemas de información. Sistemas segmentados por
funciones, dedicados a sólo una parte del todo.
El advenimiento de las bases de datos intentó resolver el problema, pero lo
complicó aún más. En lugar de centralizar toda la data en un solo repositorio
de información, se crearon múltiples bases de datos, al menos una por
sistema, complicándose más cuando hay una gran diversidad de plataformas.
El nuevo pensamiento gerencial orienta la organización hacia los procesos y la
optimización de los mismos, basado en un enfoque holístico de la empresa.
Cuando se formulan procesos se eliminan las "parcelas de poder", y se
administran eficientemente los recursos de la misma. La tecnología de la
información generó un concepto a la par de estas ideas: sistemas integrados.
Sistemas basados en una única Base de Datos, garantizando información
consistente e integrada, donde se persigue eliminar la redundancia de tareas y la
duplicidad de información. Sistemas que permiten adoptar las mejores prácticas
de negocios y mejorar la competitividad y rentabilidad. SAP es uno de estos
sistemas integrados.
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
SAP R/3
Es un sistema integrado, todo en uno compuesto de módulos agrupados en
tres áreas: logística, contabilidad y recursos humanos todos los módulos
están conectados así es que el cambio en un módulo se refleja
automáticamente en todos los demás. Los módulos se pueden adaptar a las
necesidades específicas de cada empresa variando sus parámetros.
SAP tiene un sistema de permisos donde distintos usuarios solo tienen
acceso a ciertos módulos y funciones según su perfil
Procesos de Negocios
Un proceso de negocio es una cadena de actividades que sumadas
producen algo de valor para el cliente, interno o externo. Recordemos la
Cadena del Valor de Porter
Esta es una cadena de valor agregado, donde los componentes
individuales van agregando valor dentro de un proceso para obtener el
resultado final.
Las tareas deben integrarse, las decisiones se deben tomar localmente, se
debe redistribuir la división del trabajo y minimizar las interfases (etapas
que no agregan valor)
Para optimizar el proceso de negocio debe buscarse que este sea uniforme,
sin cuellos de botella ni interrupciones, como por ejemplo los retrasos
producidos por el transporte innecesario de mercaderías, eliminando
procesos duplicados y sobre todo las descoordinaciones por falta de
información.
Los sistemas y tecnologías de información representan un rol clave no solo
para el control, sino también para la coordinación y la toma de decisiones
estratégicas.
Los sistemas de procesamiento de datos normalmente se construyen sobre
diseños y un paradigma heredado, como una forma de hacer más eficiente lo
mismo que ya se estaba haciendo en forma manual, por ejemplo un sistema
de inventarios puede pasar desde un kardex de tarjetas a un sistema
computacional, pero el control y el modelo total del negocio permanecen sin
cambios. Mejoran eficiencia local, pero no necesariamente la eficiencia
corportaiva
SAP tiene dos características interesantes:
1.Es integrado, es decir abarca todas las necesidades de procesamiento de
información de la empresa y no una necesidad específica
2.Es estandar, no es un sistema creado a medida de las necesidades de la
empresa, esto presenta la desventaja de que obliga a adaptar los procesos al
sistema y la ventaja que no se replican procedimientos globalmente
ineficientes, no se heredan los errores
Un análisis de los procesos de negocios permite cuestionar los
procedimientos tradicionales y –eventualmente- cambiarlos. En SAP esto se
lograría mediante la adaptación de los procedimientos a los estándares del
sistema.
Implementación Orientada a SAP
1. Mapear la compañía en una jerarquía de negocios, de acuerdo a la
estructura SAP
2. Identificar donde encajan los procesos SAP e incluirlos en el mapa
3. Dividir las tareas en alguna de estas categorías
1. Automáticas (las que se realizarán con SAP)
2. Manuales (las que realizarán los usuarios sin SAP)
3. Transacciones (las que realizarán los usuarios usando SAP
4. Definir el alcance de cada tarea: frecuencia y uso de recursos
SAP es una implementación comercial de un modelo teórico llamado ERP
Enterpise Resourcing Planning que propone concentrar todo el planeamiento
de recursos de la empresa en un solo sistema de información, a diferencia de
los diferentes sistemas tradicionales (contabilidad, inventario, sueldos, etc.)
SAP fue desarrollado originalmente en Alemania y ha tenido mucho éxito en
grandes empresas en todo el mundo, universidades y escuelas de negocios
han hecho alianzas estratégicas para formar personal e investigar mejoras de
la implementación
La idea clave de los ERP es imponer un paradigma de organización al que las
empresas deben adaptarse en líneas generales, a nivel de detalle es el SAP
que se adapta a los requerimientos de la empresa mediante el ajuste de sus
parámetros.
“Todo en uno” un solo gran sistema de información que contiene todo en una
sola base de datos, cada evento inicia una transacción, todo ocurre en tiempo
real y no en base a información histórica como en los sistemas tradicionales
Módulos de aplicación SAP
•FI Contabilidad financiera, registra y genera todos los libros contables
•CO Control, controla el flujo de costos y ganancias, es un intrumento para la
toma de decisiones estratégicas que se actualiza automáticamente cuando
ocurre cualquier transacción
•AM Manejo de activos, controla el Activo Fijo, compra y venta de activos,
depreciación, etc.
•PS Sistema de proyectos, permite la planificación, control y monitoreo de
proyectos de largo plazo
•WF Flujo de trabajo, conecta los módulos SAP con otras aplicaciones,
herramientas y servicios
•IS Soluciones industriales, combina los módulos SAP con aplicaciones
específicas según la industria
•HR Recursos humanos, sistema completo para apoyar la planificación y control
del personal
•PM Plan de mantenimiento, planifica y controla las operaciones de
mantenimiento
•MM Manejo de los materiales, soporta todas las operaciones relcionadas con
los inventarios
•QM Manejo de calidad, Control de calidad y sistema de planeamiento de las
inspecciones
•PP Planeamiento de la producción, facturación de material, ruteo, centros de
trabajo, planeamiento de ventas y operaciones, requerimiento de materiales,
costeo, etc.
•SD Ventas y distribución, entrega, facturación, soporte pre y post venta, etc.
Características a nivel de sistema de SAP
Customizing– es como se configura el sistema para adaptarlo a las
necesidades específicas de la empresa, los informes requeridos –internos y
externos- y los procesos de negocio
Organizational Elements
Financial-client es una unidad legal y organizacional del nivel más alto en SAP
company es una entidad legal independiente dentro de un cliente
business areas se usan para producir informes de pérdidas y
ganancias así como hojas de balance para cada línea de marketing
Materials Management
Purchasing units
Plants
Sales and Distribution
Sales Organization
Distribution channel
Division
Master Data son los registros que permanecen en la base de datos por un
período extendido de tiempo, por ejemplo:
Customer Master
Vendor Master
Material master
Account Master
Esta estructura elimina los datos redundantes y es compartida por todos los
módulos SAP. Es un aspecto crítico de la robustez del sistema
Employee Self Service—los empleados tienen acceso a sus propios
registros en el módulo de Recursos Humanos HR a través de Internet.
Classification consiste en asignar un objeto a una clase. Cada clase tiene
sus características estándar.
Matchcodes son herramientas de consulta usadas para encontrar
información específica por medio de métodos de búsqueda.
Security es administrada por objetos, perfiles y autorizaciones. Los
usuarios son solo autorizados a ver o cambiar las partes del sistema
requeridas por las responsabilidades de su trabajo.
Office
Workplace
Telephone Integration
Appointment Calendar
Room Reservations
Start Workflow
Business Documents
Logistics
Materials Management
Sales/distribution
Logistics Execution
Production
Production-process
Plant Maintenance
Customer Service
Quality Management
Logis. controlling
Project Management
Environment Health & Safety
Central Functions
Accounting
Financial Accounting
Treasury
Controlling
Enterprise Control
Investmt Mgt.
Project management
Real Estate
Human Resources
Managers Desktop
Personnel admin.
Time management
Payroll
Training and Event Management
Organizational Management
Travel
Information system
Information Systems
Executive Information Systems
Logistics
Accounting
Human Resources
Project System
Ad Hoc Reports
General Report System
Tools
ABAP/4 Workbench
Accelerated SAP
Administration
ALE
Business Communication
Business Documents
Business Framework
Business Workflow
CCMS
Web Development
SAPScript
Hypertext
Find
En Resumen
SAP es un sistema Integrado, “todo en uno”
Su mayor utilidad es en las empresas muy grandes ¿Por qué?
Obliga a la organización a adaptar sus procesos al sistema
Requiere de personal altamente entrenado -ingenieros certificados SAPOrdena los sistemas de información
Elimina las redundancias
Es más seguro y más robusto
Su implementación es muy cara
UML UNIFIED MODELLING LANGUAGE
Tomás Bradanovic P.
UML ayuda a capturar la idea de un Sistema Real para comunicarla a los
que deben desarrollar su implementación en un software. Esto se hace
mediante la representación gráfica del sistema usando símbolos
estandarizados sencillos de entender.
Por Sistema Real entenderemos cualquier proceso más o menos complejo
de control dentro de una empresa, por Sistema entenderemos el conjunto de
software y hardware destinado a controlar el Sistema Real.
Tenemos un Sistema Real y debemos llegar a un Sistema Computacional.
Antes de empezar a codificar es necesario hacer un plan, un modelo y un
diseño (lo que se conoce como diseño lógico) UML sirve para que el modelo
pueda ser explicado claramente y sin ambiguedades a los que tendrán que
implementar el Sistema Computacional
UML es esencialmente una herramienta de comunicación
Existen distintas estrategias para implementar un sistema:
•Si es pequeño y simple se puede codificar de inmediato, esa era la forma en
que se implementaban antiguamente todos los sistemas
•Si es complicado, grande o debe cumplir con requisitos de calidad de
software, existen dos alternativas:
•La forma tradicional es hacer un diseño lógico con las especificaciones
detalladas que el software debe cumplir, un modelo basado en diagramas
entidad/relación o UML servirá para comunicar este diseño lógico a
quienes deben hacer el diseño físico (codificación)
•Otra forma consiste en ir construyendo prototipos y luego componentes
en el marco de un diseño lógico menos detallado y más flexible, esto
permite que los usuarios y los programadores vayan modificando el diseño
en la medida que aparezcan problemas, los componentes deben cumplir
con todos los requisitos del diseño orientado a objeto y luego de un
proceso de prueba y error se va completando el diseño lógico de modo
paralelo al diseño físico
Al estudiar UML lo haremos suponiendo el enfoque original del diseño en
cascada, es decir la especificación completa de un modelo antes de
empezar a codificar
UML no solo sirve para explicar el modelo a los programadores, sino
también al cliente, para que tenga claro como va a funcionar antes de que
empiece la implementación física
Metáfora de un arquitecto diseñando un edificio complejo
UML produce gráficos orientados a objetos, se diseñó entre 1994 y 1998, es
un estándar bien aceptado para el diseño de sistemas complejos
Un modelo UML describe lo que hará el sistema, pero no dice como
implementarlo
UML permite hacer distintos tipos de diagramas como veremos a
continuación:
Diagramas de clases, consiste en agrupar objetos que tienen
características y acciones en común, un ejemplo que ya vimos es la
clase “LavadoraIndustrial”
Diagramas de objetos, un objeto es una instancia de una clase, o sea
una entidad con valores específicos de atributos y acciones, por ejemplo,
mi lavadora, marca Westinhouse, modelo EW3400, serie etr33345222,
capacidad 20 kgs. agregarRopa(si), agregarDetergente(si), sacarRopa
(no), su diagrama sería
Diagrama de Casos de Uso: un caso de uso describe las acciones de un
sistema desde el punto de vista del usuario. En este ejemplo el “mono” es
el “actor” o sea quien usa el sistema (puede ser una persona u otro
sistema) y la elipse es el caso de uso
Diagrama de estados: muestra como cambia el estado de un objeto en
el tiempo
Diagrama de secuencias, muestra las secuencias de operaciones de un
sistema. Para el ejemplo de la lavadora podríamos tener como objetos una
manguera de agua, un tambor, un sistema de drenaje. Luego de
agregarRopa, agregarDetergente y Activar, la secuencia puede ser:
1. La manguera llena el tambor con agua
2. Tambor inactivo por 5 minutos
3. La manguera corta el paso de agua
4. Tambor gira 15 minutos
5. Sale el agua por el drenaje
6. Comienza a entrar agua nuevamente
7. Tambor sigue girando
8. Se corta el agua
9. Sale por el drenaje
10. Tambor gira incrementando velocidad por 5 minutos
11. Tambor se detien, fin del proceso
Diagrama de actividades: las actividades ocurren en un caso de uso o
en el comportamiento de un objeto, los 11 pasos del ejemplo anterior se
pueden representar en un diagrama de actividades, por ejemplo para las
actividades 4 a la 6
Diagrama de colaboraciones: cuando los elementos trabajan en
conjunto se puede diagramar la forma en que colaboran, por ejemplo:
Diagrama de componentes: como vimos en clases pasadas, los
componentes son cajas negras de software, diseñadas según el modelo
orientado a objetos a las que se puede tener acceso a través de mensajes,
el símbolo UML para los componentes es:
Diagrama de distribución: permite mostrar como se distribuyen
físicamente los distintos equipos o componentes de hardware
Paquetes: se usan cuando se quieren organizar los elementos de un
diagrama en un mismo grupo, por ejemplo para agrupar varias clases
relacionadas
Estereotipos: se usan cuando combinamos algunos elementos del UML
para crear otro nuevo, por ejemplo podemos crear el estereotipo (o
cliché) llamado <<Interfaz>> como una clase especial que hace ciertas
operaciones pero no tiene atributos
Ejemplo de un caso de uso real
CA01 Registro de Contribuyente
•Historial de Revisiones:
Fecha
/
/
Versión
1.0
Descripción
Autor
Caso de uso para ser revisado con
los usuarios del sistema – Módulo
de Catastro Urbano.
Firmas:
CA01 Registro de Contribuyente
Descripción
El actor digitador, después de registrarse en el sistema mediante el usuario y la contraseña puede
invocar el caso de uso registro de contribuyente, en el cual podrá registrar nuevos contribuyentes
llenando las pestañas correspondientes, también podrá Modificar, Inactivar, Imprimir o Exportar a
Excel los datos de un contribuyente seleccionado.
Flujo de Eventos
Flujo Básico
El digitador ingresara un nuevo contribuyente pulsando el botón Nuevo.
El sistema activa las pestañas en las cuales el digitador se prestara a llenar los datos que han sido
recabado y llenados en las fichas impresas.
Una vez llenado los datos se procede a guardar la información dando clic en el botón Guardar.
El sistema pide una confirmación del proceso guardar.
El sistema vuelve a la interfaz inicial de registro de contribuyente.
Flujos Alternativos
En el punto 1
El digitador puede realizar otras acciones como ser: Buscar o Salir del modulo.
En caso de realizar una búsqueda y seleccionar algún registro encontrado podrá realizar lo siguiente:
Modificar, Inactivar, Imprimir, Exportar a Excel o Salir del modulo.
En el punto 2
A partir de este punto hasta el punto 3, el digitador podrá cancelar el registro del contribuyente dando
clic en el botón Deshacer.
El digitador en este punto deberá de escoger si registra a una persona natural o una persona jurídica.
En el punto 4
El digitador podrá negar la confirmación de guardado, regresando al punto 3 con todos los datos
ingresados hasta ese momento.
Precondiciones
El Digitador ha realizado correctamente su ingreso en el sistema mediante el nombre de usuario y la
contraseña.
El contribuyente no debe de estar registrado.
Poscondiciones
En caso de haber llenado la ficha registro de contribuyente parcialmente, el digitador podría aumentar la
información con la opción Modificar.
También podrá Modificar la información en caso se este actualizando los datos del contribuyente.
Por cualquier motivo que se modifique, el sistema le pedirá que digite una observación donde puede
escribir el motivo por el cual se realizo la modificación.
El digitador deberá cerrar el modulo correctamente usando el botón cerrar para no tener posteriormente
ningún inconveniente.
•Historial de Aprobaciones:
Fecha
/
Versión
/
1.0
Descripción
Se aprueba en
presente caso de uso.
Autor
% el
Observaciones:
Firmas:
Ejemplo real de un caso de prueba
CP01 - REGISTRO DE CONTRIBUYENTE, PERSONA NATURAL
Información de la versión
Proyecto:
Número Interno de
Versión:
Documentos
Relacionados:
Proyecto Modernización de la Infraestructura de Software, Hardware y comunicaciones en los
sistemas de Información de la MPT.
2.0
Registro de Contribuyente – Persona Natural
Probar que se puede registrar un nuevo contribuyente como persona natural.
Propósito:
Pre-requisitos:
El contribuyente no debe de estar registrado.
Datos de Prueba
Procederemos a llenar los campos necesarios:
Identificación del contribuyente:
Tipo de contribuyente: 1, persona natural
Nombres: Miguel Eduardo
Apellido paterno: Aguilar
Apellido materno: Medina
Estado civil: 01, soltero
Profesión: 11711, ingeniero, sistemas informáticos
Sexo: masculino
Homonimia: No
Fecha de Nacimiento: 15/04/1977
(Gestión de Cobranza-Trabajo interno)
Calif. Contributiva: 003, pequeño contribuyente
Calif. SocioEconómica: 003, nivel C
Calif. Deudora: 003, pequeño deudor
Domicilio Fiscal:
Tipo de Vía: 99, no especificado
Vía: 99999999, no especificado
Hab. Urbana: 230101326, asoc. De Viv. Villa magisterial
Numero:
Numero adicional:
Nombre de la edificación:
Tipo edific.: 02, casa / chalet
Tipo interior: 02, casa / chalet
Num. Interior:
Nombre:
Manzana: B
Lote: 6
Sub lote:
Dirección adicional:
Documentos:
Tipo de documento: 02, DNI
Número de documento: 30857012
Contactos: (para uso de personas jurídicas)
Nombre del contacto:
Email:
Cargo:
Teléfonos:
Gestores:
(Gestión de Cobranza-Trabajo interno)
Código gestor: 99999999, no especificado
Fecha inicio:
Fecha fin:
Observación:
Teléfonos - EMail:
Teléfono(s)
Tipo de teléfono: 05, celular 1
Numero: 9689952
E-Mail (s)
Dirección: [email protected]
Observaciones:
Observación: nuevo contribuyente
Pasos:
Entrar al sistema SIGTMv2
Entrar a registro de contribuyente: Registro/Contribuyente
Dar clic en la opción nuevo
Llenar los campos de identificación del contribuyente
Llenar domicilio fiscal
Ingresar documento de identidad del contribuyente
Registrar algún contacto del contribuyente (para uso de personas jurídicas)
Registrar los gestores si los hubiere (Ficha de uso interno)
Registrar teléfonos y correo electrónico del contribuyente
Ingresar alguna observación (obligatorio)
Dar clic en guardar
Confirmar la opción de guardado
Salir del formulario “Datos del Contribuyente”
Salir del sistema SIGTMv2
Pantallas usadas durante el llenado de información del registro del contribuyente
Notas:
UML: Unified Modelling Language Parte 2
Tomás Bradanovic
Que son las clases
Como vimos una clase es algo que engloba a objetos con carcterísticas
comúnes, en UML se escribe su nombre con la primera letra en mayúsculas y
su símbolo es un rectángulo
Un paquete también puede hacer la funcionalidad de una clase
Si, por ejemplo, la clase LavadoraIndustrial es parte del paquete
Electrodomésticos se puede “rutear” de esta manera:
Electrodomesticos:: LavadoraIndustrial
Como vimos una clase puede tener varios atributos (propiedades,
características) o ninguno, los nombres de atributo siempre empiezan con
minúscula. Cada uno de los atributos tiene un valor específico. El nombre de
la clase puede ir ruteado y subrayado
Además existen las operaciones que puede tener una clase u objeto, las
operaciones llevan paréntesis donde se colocan los parámetros
No siempre se
detallan los
atributos y las
operaciones o a
veces se ponen
solo algunos o
ninguno
Si son demasiados los atributos y operaciones, o si se necesita quitar o
agregar algunos, lo que se hace es crear un esterotipo, con categorías a
las que se pueden agregar o quitar elementos
Restricciones: los
atributos u
operaciones
pueden estar
sujetos a alguna
restricción, esta
se indica al lado
del símbolo entre
paréntesis
También se pueden incluir notas
aclaratorias con el símbolo que se
muestra
En las entrevistas con los usuarios para armar un modelo, lo primero que se
debe definir son las clases. En la entrevista aparecen sustantivos, algunos
son clases y otros son atributos, también aparecen verbos, esas son
operaciones. Ejercicio:
“En nuestra empresa compramos y vendemos mercadería, mantenemos stock
en bodega, para comprar y pagar los gastos de operación usamos una cuenta
corriente y además como dueño uso una segunda cuenta para las finanzas
personales, la contabilidad legal la lleva un contador externo pero necesito
también llevar una contabilidad operativa que me entregue un estado mensual
consolidado de resultados. Tenemos la casa central y tres sucursales. Mis
problemas de stock son controlar el robo de mercaderías y conocer la rotación
de los artículos porque cada mes tengo que hacer los pedidos de compras,
necesito saber cuales son los artículos que más se venden y cuales los que
dan mayor utilidad, necesito tener algún índice de rotación y utilidad para
rankear mis mercaderías.
Deseo implementar en cada sucursal un sistema de punto de venta en el
mesón, que en el momento de hacer la venta me descargue inmediatamente
el inventario y me haga un informe de caja diario, este informe debe
acumularse para el informe mensual consolidado”
Formule preguntas adicionales y proponga clases, objetos, atributos y
operaciones para el modelo
Las Relaciones: construir las clases y objetos es el primer paso, ahora hay
que determinar como estas clases se relacionan entre sí
Asociaciones: se trata de relaciones de participación en cualquier sentido.
Ejemplos:
Supongamos que
definimos una
superclase llamada
SistemaIntegrado, en
la que participan dos
clases: Inventarios y
CuentasCorrientes
3000
1
Un Vínculo es una instancia (caso particular) de una asociación, por
ejemplo para nuestro ejemplo anterior. En las instancias se subraya el
nombre del vínculo
500
1
Multiplicidad: la asociación no tiene por que ser 1 a 1, en el ejemplo anterior
sería 500 a 1 como se indica, si hubiesen 3000 distintas clases de mercadería
en el bojeto Inventario, su asociación con la clase SistemaIntegrado sería 3000
a 1. Multiplicidad es la cantidad de objetos de una clase que se relacionan con
un objeto de la clase asociada
Agregaciones: ocurren cuando una clase se compone de otras clases, las
agregaciones se indican con un rombo en la línea que relaciona a las clases,
por ejemplo:
Composiciones: es una clase especial de
agregación, con las subclases que
componen una clase (sin una de ellas la
clase no funciona) el símbolo es un rombo
relleno
Diagramas de Contexto: presentan un detalle de las subclases
Por ejemplo si tenemos un diagrama
de Composición de clases como este
Podemos mostrar un diagrama de
contexto que muestra donde está
situado dentro del sistema
Interfaz es el conjunto de
operaciones que realiza una clase,
se grafica con una línea punteada
terminada en flecha sin rellenar
Visibilidad: los atributos y operaciones de una clase pueden tener tres
niveles de visibilidad:
•Publicos, cuando se extienden a todas las demás clases, se indica con +
•Protegidos, cuando se extienden solo a las clases que se heredan, se
indica con #
•Privados, cuando solo se pueden usar dentro de la clase, se indica con -
Ejercicio: hacer las agregaciones detalladas de clases
•de un sistema de inventario
•de un sistema de cuentas corrientes
•de un sistema de información integrado que haga los reportes mensuales
BPMN
BUSINESS PRECESS MODELLING
NOTATION
Tomás Bradanovic P.
BPMN: Business Process Modeling Notation
Hasta ahora vimos principalmente el modelamiento de los datos, ahora
pasaremos a ver el modelamiento de los procesos de negocio.
Vemos como se vuelve a la diferenciación original entre datos y
procesos.
BPMN es una notación gráfica estándar diseñada para crear modelos
que todos los participantes en un proceso de negocio puedan entender:
usuarios, analistas, clientes, gerentes, etc.
La idea es que usando una cantidad limitada de símbolos podamos crear
modelos entendibles que nos ayuden a optimizar –y eventualmente a
optimizar- los procesos
BPMN ha sido desarrollado para cubrir la brecha entre el diseño y la
implementación de un sistema. Fue formado por la Business Process
Management Initiative con el Object Management Group
Elementos del BPMN: Eventos
Evento de inicio
Evento intermedio
Evento final
A los eventos específicos se les puede agregar un icono que
muestren su significado
Un evento intermedio tipo “mensaje”, por ejemplo, puede tener
dos instancias: enviando o recibiendo. Los eventos que envían
se anotan con un icono relleno, mientras que los que reciben con
un núcleo claro
En la figura se pueden ver distintas clases de eventos
BPMN: Eventos de partida
http://diveintobpm.org/index.jsp
Disparador
Descripción
Ninguno
No se especifica el tipo de evento, también se
usa cuando un sub proceso disparado por el
proceso padre
Mensaje
Llegada/envío de un mensaje y se dispara un
proceso
Timer
Para procesos que parten en un día/hora
específica
Condicional
Es cuando un proceso parte con una condición
tal como “si se producen diferencias de
inventario teórico y físico”
Señal
Una señal no es un mensaje con un destino
fijo, sino que puede activar muchos procesos
distintos
Múltiple
Muchos eventos distintos pueden activar el
proceso, basta con que uno de ellos se
cumpla para que el proceso se dispare
Símbolo
BPMN: Eventos intermedios
http://diveintobpm.org/index.jsp
Disparador
Descripción
Ninguno
No se muestra el tipo de evento
Mensaje
El proceso queda en espera hasta que llegue el mensaje (recepción) o se usa
para enviar mensajes (envío), también se usa para desviar excepciones (*)
Timer
Dispara el proceso en un día/hora determinados, también se usa para desviar
excepciones
Error
Se dispara cuando se produce un determinado error. Solo se puede poner en
el extremo de una actividad
Cancelar
Se puede poner solo en el extremo de un sub proceso. Se dispara cuando
recibe un evento “Cancelar”
Compensación
Activa eventos que compensan alguna acción, puede afectar a una actividad
si esta se especifica o a todas las suceptibles de ser compensadas
Condicional
Es el evento que se dispara cuando una condición tiene valor “True”
Link
Conecta dos secciones de un proceso, se puede usar –por ejemplo- para
crear loops. Puede tener múltiples fuentes pero solo un destino
Señal
Envía y recibe señales que se comunican a lo largo de todo un flujo a quien
pueda interesar
Múltiple
Es cuando un evento tiene múltiples disparadores, ya sea para recepción
como para envío
Símbolo
(*) Excepción, es cuando se produce un evento excepcional o inesperado, típicamente un error o algo
no previsto
BPMN: Gateways (compuertas)
http://diveintobpm.org/index.jsp
Las gateways son puntos de decisión para canalizar el flujo
Exclusive Data-Based: una o varias salidas son posibles pero solo una
condición dirigirá el flujo
Exclusive Event-Based: igual que el caso anterior pero escogerá la
primera condición que le llegue (race)
Inclusive: evalúa dos o más condiciones, el flujo puede salir por una o más
ramas en paralelo
Complex: sirve para combinaciones de las otras gateways, se escribe en
un detalle aparte su comportamiento en cada caso particular
Paralel: sincroniza los flujos que salen de manera paralela
http://diveintobpm.org/index.jsp
BPMN: Swimlanes y Pools
Pools (piscinas) y swimlanes (pistas) se usan para
organizar dentro de un bloque actividades afines y
mostrar la colaboración entre ellas.
Típicamente se usan para organizar un subproceso,
una unidad de negocios específica, etc.
http://diveintobpm.org/index.jsp
Proceso intermedio básico: Races
http://diveintobpm.org/index.jsp
BPMN: Interrupciones
http://diveintobpm.org/index.jsp
Flujos condicionales
En este ejemplo los flujos son
dirigidos según el resultado de la
condición asociada (por ej
verdadero/falso, cumple/no cumple)
Flujos arbitrarios
State based
Aquí los flujos se dirigen según si se
ha recibido un mensaje, se ha
cumplido una condición o ha pasado
cierto tiempo
http://diveintobpm.org/index.jsp
Ejercicios…
(ej. Taller mecánico, tienda ventas detalle, inst. educativo, etc.)
Prototipos en Visual Basic Para Aplicaciones (OOBasic)
Tomás Bradanovic
Modelado con Prototipos
A diferencia de los sistemas anteriores en que hay una separación estricta entre
diseño lógico (modelo conceptual) y la implementación física (codificación) el
modelo por prototipos es una técnica evolutiva, donde luego de las entrevistas,
se bosqueja un diseño lógico y se codifican interfases gráficas de usuario
(como cada usuario verá el sistema) se ensayan estas interfases y por medio
de prueba y error se van modificando. Una vez llegado a acuerdo se consolida
esta parte dentro del diseño lógico.
En los sstemas pequeños el prototipeado puede reemplazar al modelamiento
lógico, en los sistemas medianos agrandes lo complementa. Se conoce como
una técnica de diseño evolutivo, al contrario del diseño en cascada que separa
de manera tajante las etapas.
En cascada se va de lo másgrande a lo más pequeño, en prototipos de lo
pequeño a lo grande.
En programas comerciales lo que más se usa es una combinación de Sistema
Administrador de Base de Datos y alguna versión de Visua Basic para las
interfases de usuario, a continuación veremos algunos ejemplos para codificar
prototipos simples en VBA (u OOB para software libre)
Discusión: Ventajas y problemas del modelado por prototipos
Prototipo de Agenda
Private Sub CommandButton1_Click()
indice = Hoja1.Cells(1, 1)
If indice = "" Then
indice = 1
Hoja1.Cells(1, 1) = indice
End If
indice = indice + 1
Hoja1.Cells(1, 1) = indice
Hoja1.Cells(indice, 1) = TextBox1.Text
Hoja1.Cells(indice, 2) = TextBox2.Text
Hoja1.Cells(indice, 3) = TextBox3.Text
Hoja1.Cells(indice, 4) = TextBox4.Text
TextBox1.Text = ""
TextBox2.Text = ""
TextBox3.Text = ""
TextBox4.Text = ""
TextBox1.SetFocus
End Sub
Prototipo de Inventario: Rebajar las Ventas
Prototipo de Inventario: Ingresar Nuevo Artículo
Prototipo de Inventario
Prototipo de Inventario
Prototipo de Inventario
Prototipo de Inventario
Prototipo Cuentas Corrientes: Mostrar Saldos
Prototipo Cuentas Corrientes: Ingresar Movimiento
Prototipo Cuentas Corrientes: Ingresar Nuevas Cuentas
Prototipo Cuentas Corrientes: Listar Cartola
Prototipo de Cuentas Corrientes: Ingresar Movimiento
Prototipo de Cuentas Corrientes
Activar UserForm Muestra Saldo
Activar UserForm Ingresa
Movimientos
Botón Ingresar Movimiento
Prototipo de Cuentas Corrientes
Mostrar Cartola
Descargar

Document