Vous êtes sur la page 1sur 46

ORTIZ CRUZ PABLO ANLISIS Y DISEO DE SISTEMAS SAETI TURNO VESPERTINO FECHA DE INGRESO (PERIODO) MAYO 2010

Anlisis y Diseo de Sistemas. UNIDAD I: MTODOS TRADICIONALES DEL ANLISIS DE SISTEMAS ........................... ......................................................... 3 1.1 CONCEPTOS GENERAL ES. ............................................................................ ................................................................................ .......... 3 1.1.1 SISTEMAS. .................................................... ................................................................................ ........................................... 3 1.1.2 SISTEMAS DE INFORMACIN........ ................................................................................ ............................................................. 3 1.1.3 ANLISIS. ... ................................................................................ ................................................................................ ............. 3 1.1.4 DISEO....................................................... ................................................................................ ............................................. 6 1.1.5 ANALISTA DE SISTEMAS....... ................................................................................ .................................................................... 9 1.1.6 PROG RAMADOR. ....................................................................... ................................................................................ ............. 10 1.1.7 ADMINISTRADOR DE BASES DE DATOS. ......................... ................................................................................ ......................... 11 1.2. CICLO DE VIDA CLSICO ........................... ................................................................................ ........................................................ 11 1.2.1 INVESTIGACIN PRE LIMINAR. ....................................................................... ......................................................................... 12 1.2. 2 DETERMINACIN DE REQUERIMIENTOS. ............................................... ................................................................................ .. 12 1.2.3 DISEO DEL SISTEMA. ................................................... ................................................................................ ........................ 12 1.2.4 DESARROLLO DEL SOFTWARE. ...................... ................................................................................ ......................................... 12 1.2.5 PRUEBA DEL SISTEMA. .......... ................................................................................ ................................................................. 13 1.2.6 IMPLAN TACIN Y EVOLUCIN.................................................................. .............................................................................. 1 3 1.2.7 MANTENIMIENTO............................................................ ................................................................................ ....................... 15 1.3 ANLISIS ESTRUCTURADO. ............................. ................................................................................ .................................................... 16 1.3.1 ELEMENTOS DEL ANLISI S ESTRUCTURADO. ................................................................ .......................................................... 17 1.4 TCNICAS PARA ENC ONTRAR HECHOS. ................................................................. .............................................................................. 1 7 1.4.1 ENTREVISTAS. ............................................................ ................................................................................ ........................... 17 1.4.2 CUESTIONARIOS............................... ................................................................................ ...................................................... 17 1.4.3 REVISIN DE LOS REG ISTROS. ........................................................................ ........................................................................ 18 1.4.4 OBSERVACIN. .................................................................... ................................................................................ .................. 18 UNIDAD II: DISEO DE SISTEMAS ............................... ................................................................................ ...................................... 20 2.1 HERRAMIENTAS PARA DOCUMENTAR CONCEP TO DE DECISIN. .................................................................. ......................................... 20 2.1.1 ACCIONES. ....................

................................................................................ ........................................................................ 20 2.1.2 RBOLES DE DECISIN. .............................................................. ................................................................................ ........... 20 2.1.3 TABLAS DE DECISIN. .......................................... ................................................................................ ................................. 21 2.2 ELEMENTOS DEL DISEO...................... ................................................................................ ............................................................... 22 2.2.1 FLUJO DE DATOS. ........................................................................ ................................................................................ .......... 22 2.2.2 ALMACENES DE DATOS........................................... ................................................................................ ............................... 23 2.2.3 PROCESOS. .............................. ................................................................................ .............................................................. 24 2.2.4 PROCEDIMI ENTOS. ......................................................................... ................................................................................ ........ 24 2.2.5 FUNCIONES DEL PERSONAL. ....................................... ................................................................................ ............................ 24 UNIDAD III: MODELADO DE SISTEMAS ORIENTADO A OBJE TOS............................................................................. .............. 25 3.1 CONCEPTOS. ................................................ ................................................................................ ....................................................... 25 3.1.1 MODELADO. ...... ................................................................................ ................................................................................ .... 26 3.1.2 MODELADO DE OBJETOS. .............................................. ................................................................................ ......................... 26 3.1.3 MODELO DINMICO. ............................... ................................................................................ .............................................. 27 3.1.4 MODELO FUNCIONAL......... ................................................................................ .................................................................... 27 3.2 DESCR IPCIN DE MODELOS DE OBJETOS. .................................................... ................................................................................ ........ 27 3.2.1 SIMBOLOGA. ..................................................... ................................................................................ .................................... 28 3.2.2 IDENTIFICACIN DE OBJETOS Y CLASES. . ................................................................................ ................................................ 29 3.2.3 OPERACIN, MTODOS, ASOCIAC IONES Y MULTIPLICIDAD. ......................................................... .......................................... 30 3.2.4 ATRIBUTO DE ENLACE CLASIFICAC IN Y AGREGACIN. .................................................................. ....................................... 31 3.3 DESCRIPCIN DEL MODELO DINMICO. ..... ................................................................................ ......................................................... 34 3.3.1 SIMBOLOGA. .... ................................................................................ ................................................................................ ..... 34 3.3.2 SUCESOS Y ESTADOS. ............................................... ................................................................................ ............................. 35 3.3.3 ESCENARIOS. .............................. ................................................................................ ........................................................... 36 3.3.4 DIAGRAMAS DE ESTADO. ....................................................................... ................................................................................ 36 3.3.5 CONDICIONES Y OPERACIONES.............................................. ................................................................................ ................. 37 3.3.6 FUNDAMENTOS DE ESTADO................................. ................................................................................

................................... 37 3.4 DESCRIPCIN DEL MODELO FUNCIONAL........ ................................................................................ ...................................................... 37 3.4.1 SIMBOLOGA. ....... ................................................................................ ................................................................................ .. 37 3.4.2 DIAGRAMA DE HOJA DE DATOS. .......................................... ................................................................................ .................. 38 3.4.3 FLUJO DE DATOS, ACTORES Y ALMACN DE DATOS. ........... ................................................................................ ................... 38 3.4.4 FLUJO DE CONTROL. .................................. ................................................................................ ............................................ 38 BIBLIOGRAFIA .................... ................................................................................ ................................................................................ .... 39 2

Pablo Ortiz Cruz UNIDAD I: MTODOS TRADICIONALES SISTEMAS 1.1 CONCEPTOS GENERALES. 1.1.1 SISTEMAS. DEL ANLISIS DE Todas las organizaciones son sistemas que actan e recibiendo entradas y produciendo salidas. Los ados por otros sistemas ms pequeos denominados r fines especficos. Sin embargo, los propsitos ntienen el control. 1.1.2 SISTEMAS DE INFORMACIN. Conjunto u ordenacin de elementos organizados para llevar a cabo algn mtodos, proce dimiento o control mediante el proceso de informacin. ELEMENTOS DE UN SISTEMA DE INFORMACION SOFWARE. Los programas de computadoras, as estructuras de datos y la documentacin asociada, que sirve para realizar el mtodo lgico. HARWARE: Los dispos itivos electrnicos que proporcionan la capacidad de computacin y que proporcionan las funciones del mundo exterior. GENTE: Los individuos que son usuarios y opera dores del software y del hardware. BASES DE DATOS: Una coleccin grande y organiza da de informacin a la que se accede mediante el software y que es una parte integ ral del funcionamiento del sistema. DOCUMENTACION: Los manuales, los impresos de scriptiva que explica el uso y / o la operacin. y otra informacin PROCESAMIENTOS: Los pasos que definen el uso especifico de cada elemento del sis tema o el contexto procedimental en que reside el sistema. CONTROL: Los sistemas trabajan mejor cuando operan dentro de niveles de control tolerables de rendimi ento por ejemplo: el sistema de control de un calentador de agua. 1.1.3 ANLISIS. Anlisis Es el proceso de clasificacin e interpretacin de hechos, diagnostico de pro blemas y empleo de la informacin para recomendar mejoras al sistemas. Conceptos y Anlisis: Es un conjunto o disposicin de procedimientos o programas relacionados d e manera que juntos forman una sola unidad. Un conjunto de hechos, principios y reglas clasificadas y dispuestas de manera ordenada mostrando un plan lgico en la unin de las partes. Un mtodo, plan o procedimiento de clasificacin para hacer algo . Tambin es un conjunto o arreglo de elementos para realizar un objetivo predefin ido en el procesamiento de la Informacin. Esto se lleva a cabo teniendo en cuenta ciertos principios: 3 recprocamente con su medio ambient sistemas, que pueden estar form subsistemas, funcionan para alcanza o metas se alcanzan slo cuando se ma

Anlisis y Diseo de Sistemas. Debe presentarse y entenderse el dominio de la informacin de un problema. Defina las funciones que debe realizar el Software. del software modelos a que consecue ncias representan de la Represente el comportamiento acontecimientos externos. Divida en forma jerrquica los informacin, funciones y comportamiento. El proceso debe partir desde la informacin esencial hasta el detalle de la Implem entacin. La funcin del Anlisis puede ser dar soporte a las actividades de un negoci o, o desarrollar un producto que pueda venderse para generar beneficios. Para co nseguir este objetivo, un Sistema basado en computadoras hace uso de seis (6) el ementos fundamentales: Software, que son Programas de computadora, con estructur as de datos y su documentacin que hacen efectiva la logstica metodologa o controles de requerimientos del Programa. Hardware, dispositivos electrnicos y electromecni cos, que proporcionan capacidad de clculos y funciones rpidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que proporcionan una funcin externa dentro de los Sistemas. Personal, son los operadores o usuari os directos de las herramientas del Sistema. Base de Datos, una gran coleccin de informaciones organizadas y enlazadas al Sistema a las que se accede por medio d el Software. Documentacin, Manuales, formularios, y otra informacin descriptiva qu e detalla o da instrucciones sobre el empleo y operacin del Programa. Procedimien tos, o pasos que definen el uso especifico de cada uno de los elementos o compon entes del Sistema y las reglas de su manejo y mantenimiento. Un Anlisis de Sistem a se lleva a cabo teniendo en cuenta los siguientes objetivos en mente: Identifi que las necesidades del Cliente. Evale que conceptos tiene el cliente del sistema para establecer su viabilidad. Realice un Anlisis Tcnico y econmico. Asigne funcio nes al Hardware, Software, personal, base de datos, y otros elementos del Sistem a. Establezca las restricciones de presupuestos y planificacin temporal. Cree una definicin del sistema que forme el fundamento de todo el trabajo de Ingeniera. 4

Pablo Ortiz Cruz

Para lograr estos objetivos se requiere tener un gran conocimiento y dominio del Hardware y el Software, as como de la Ingeniera humana (Manejo y Administracin de personal), y administracin de base de datos. Objetivos del Anlisis. Identificacin d e Necesidades. Es el primer paso del anlisis del sistema, en este proceso en Anal ista se rene con el cliente y/o usuario (un representante institucional, departam ental o cliente particular), e identifican las metas globales, se analizan las p erspectivas del cliente, sus necesidades y requerimientos, sobre la planificacin temporal y presupuestal, lneas de mercadeo y otros puntos que puedan ayudar a la identificacin y desarrollo del proyecto. Algunos autores suelen llamar a esta par te Anlisis de Requisitos y lo dividen en cinco partes: Reconocimiento del prob a. Evaluacin y Sntesis. Modelado. Especificacin. Revisin Antes de su reunin con el analista, el cliente prepara un documento conceptual de l proyecto, aunque es recomendable que este se elabore durante la comunicacin Cli ente analista, ya que de hacerlo el cliente solo de todas maneras tendra que ser modificado, durante la identificacin de las necesidades. Estudio de Viabilidad. M uchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recu rsos y el tiempo no son realistas para su materializacin sin tener prdidas econmica s y frustracin profesional. La viabilidad y el anlisis de riesgos estn relacionados de muchas maneras, si el riesgo del proyecto es alto, la viabilidad de producir software de calidad se reduce, sin embargo se deben tomar en cuenta cuatro reas principales de inters: 1. Viabilidad econmica. Una evaluacin de los costos de desar rollo, comparados con los ingresos netos o beneficios obtenidos del producto o S istema desarrollado. 2. Viabilidad Tcnica. Un estudio de funciones, rendimiento y restricciones que puedan afectar la realizacin de un sistema aceptable. 3. Viabi lidad Legal. o Es determinar cualquier posibilidad de infraccin, violacin responsa bilidad legal en que se podra incurrir al desarrollar el Sistema. Alternativas. Una evaluacin de los enfoques alternativos del desarrollo del produ cto o Sistema. 5

Anlisis y Diseo de Sistemas. El estudio de la viabilidad puede documentarse como un informe aparte para la al ta gerencia. Anlisis Econmico y Tcnico. El anlisis econmico incluye lo que llamamos, el anlisis de costos beneficios, significa una valoracin de la inversin econmica com parado con los beneficios que se obtendrn en la comercializacin y utilidad del pro ducto o sistema. Muchas veces en el desarrollo de Sistemas de Computacin estos so n intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a l a caractersticas del Sistema. El anlisis de costos beneficios es una fase muy impo rtante de ella depende la posibilidad de desarrollo del Proyecto. En el Anlisis Tc nico, el Analista evala los principios tcnicos del Sistema y al mismo tiempo recog e informacin adicional sobre el rendimiento, fiabilidad, caractersticas de manteni miento y productividad. Los resultados obtenidos del anlisis tcnico son la base pa ra determinar sobre si continuar o abandonar el proyecto, si hay riesgos de que no funcione, no tenga el rendimiento deseado, o si las piezas no encajan perfect amente unas con otras. 1.1.4 DISEO. Especifica las caractersticas del producto terminado. Conceptos y principios: El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y principios con el propsito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretacin y realizacin fsica. La etapa del Diseo del Sistema encierra cuatro etapas: 1. El diseo de los datos. Trasforma el modelo de dominio de la informacin, creado durante el anlisis, en las estructuras de dat os necesarios para implementar el Software. 2. El Diseo Arquitectnico. entre cada uno de los elementos estructurales del Define la relacin programa. 3. El Diseo de la Interfaz. Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con el y con los operadores y usuarios que lo emplean. 4. El Diseo de proc edimientos. Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseo del Software se puede definir en una sola palabra Calida d, dentro del diseo es donde se fomenta la calidad del Proyecto. El Diseo es la nic a manera de materializar con precisin los requerimientos del cliente. 6

Pablo Ortiz Cruz El Diseo del Software es un proceso y un modelado a la vez. El proceso de Diseo es un conjunto de pasos repetitivos que permiten al diseador describir todos los as pectos del Sistema a construir. A lo largo del diseo se evala la calidad del desar rollo del proyecto con un conjunto de revisiones tcnicas: El diseo debe implementa r todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumula r todos los requisitos implcitos que desea el cliente. Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen el Sof tware. El Diseo debe proporcionar una completa idea de lo que es el Software, enf ocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementacin. Para evaluar la calidad de una presentacin del diseo, se debe n establecer criterios tcnicos para un buen diseo como son: Un diseo debe presentar una organizacin jerrquica que haga un uso inteligente del control entre los compo nentes del software. El diseo debe ser modular, es decir, se debe hacer una parti cin lgica del Software en elementos que realicen funciones y subfunciones especfica s. Un diseo debe contener abstracciones de datos y procedimientos. que presenten caractersticas complejidad de de las Debe producir mdulos funcionamiento independi ente. Debe conducir a interfaces que reduzcan la conexiones entre los mdulos y el entor no exterior. Debe producir un diseo usando un mtodo que pudiera repetirse segn la informacin obte nida durante el anlisis de requisitos de Software. Estos criterios no se consigue n por casualidad. El proceso de Diseo del Software exige buena calidad a travs de la aplicacin de principios fundamentales de Diseo, Metodologa sistemtica y una revis in exhaustiva. Cuando se va a disear un Sistema de Computadoras se debe tener pres ente que el proceso de un diseo incluye, concebir y planear algo en la mente, as c omo hacer un dibujo o modelo o croquis. Diseo de la Salida. En este caso salida s e refiere a los resultados e informaciones generadas por el Sistema, Para la may ora de los usuarios la salida es la nica razn para el desarrollo de un Sistema y la base de evaluacin de su utilidad. Sin embargo cuando se realiza un sistema, como analistas deben realizar lo siguiente: Determine que informacin presentar. Decid ir si la informacin ser presentada en forma visual, verbal o impresora y seleccion ar el medio de salida. 7

Anlisis y Diseo de Sistemas. Disponga la presentacin de la informacin en un formato aceptable. Decida cmo distri buir la salida entre los posibles destinatarios. Diseo de Archivos. Incluye decisiones con respecto a la naturaleza y contenido de l propio archivo, como si se fuera a emplear para guardar detalles de las transa cciones, datos histricos, o informacin de referencia. Entre las decisiones que se toman durante el diseo de archivos, se encuentran las siguientes: Los datos que d eben incluirse en el formato de registros contenidos en el archivo. La longitud de cada registro, con base en las caractersticas de los datos que contenga. La se cuencia a disposicin de los registros dentro del archivo (La estructura de almace namiento que puede ser secuencial, indexada o relativa). No todos los sistemas r equieren del diseo de todos los archivos, ya que la mayora de ellos pueden utiliza r los del viejo Sistema y solo tenga que enlazarse el nuevo Sistema al Archivo m aestro donde se encuentran los registros. Diseo de Interacciones con la Base de D atos. La mayora de los sistemas de informacin ya sean implantado en sistemas de cmp utos grandes o pequeos, utilizan una base de datos que pueden abarcar varias apli caciones, por esta razn estos sistemas utilizan u administrador de base de datos, en este caso el diseador no construye la base de datos sino que consulta a su ad ministrador para ponerse de acuerdo en el uso de esta en el sistema. Herramienta s para el Diseo de Sistemas. Apoyan el proceso de formular las caractersticas que el sistema debe tener para satisfacer los requerimientos detectados durante las actividades del anlisis: Herramientas de especificacin. Apoyan el proceso de formu lar las caractersticas que debe tener una aplicacin, tales como entradas, Salidas, procesamiento y especificaciones de control. Muchas incluyen herramientas para crear especificaciones de datos. Herramientas para presentacin. Se utilizan para describir la posicin de datos, mensajes y encabezados sobre las pantallas de las terminales, reportes y otros medios de entrada y salida. Herramientas para el de sarrollo de Sistemas. Estas herramientas nos ayudan como analistas a trasladar d iseos en aplicaciones funcionales. Herramientas para Ingeniera de Software. 8

Pablo Ortiz Cruz Apoyan el Proceso de formular diseos de Software, incluyendo procedimientos y con troles, as como la documentacin correspondiente. Generadores de cdigos. Producen el cdigo fuente y las aplicaciones a partir de especificaciones funcionales bien ar ticuladas. Herramientas para pruebas. Apoyan la fase de la evaluacin de un Sistem a o de partes del mismo contra las especificaciones. Incluyen facilidades para e xaminar la correcta operacin del Sistema as como el grado de perfeccin alcanzado en comparacin con las expectativas. La revolucin del procesamiento de datos de maner a computarizada, junto con las prcticas de Diseo sofisticadas estn cambiando de for ma dramtica la manera en que se trasladan las especificaciones de Diseo d Sistemas de Informacin funcionales. 1.1.5 ANALISTA DE SISTEMAS. Disear y desarrollar sistemas de informacin, recomendar mejoras para el mismo, des arrollar las especificaciones de diseo y planificar el software y hardware necesa rio para implantar el diseo. Realizar el proceso de clasificacin e interpretacin de hechos, diagnstico de problemas y empleo de la informacin para desarrollar el dis eo del sistema. FUNCIONES PROPIAS DEL PUESTO Estudiar el mercado informtico en ref erencia a nuevos productos, tendencias y servicios del mbito informtico. Probar y comparar nuevos equipos informticos del mercado. Estudiar las necesidades informti cas de los diferentes departamentos de la empresa a nivel de equipos tcnicos, mtod os y procedimientos informticos. Elaborar parte del anlisis funcional, en el que d efine la estructura del nuevo sistema informtico (equipos tcnicos, mtodos y procedi mientos). Planificar la implantacin y puesta en marcha del sistema a nivel de rec ursos humanos y elementos de hardware. Realizar presupuestos referentes a la ins talacin de nuevos equipos y elaborar el informe de justificacin tcnica y econmica. E laborar planes de seguridad de la informacin y de los equipos. las pruebas a real izar y para a detectar los las Estudiar y establecer anomalas del sistema. Asesor ar interesados. a sus colaboradores informticos servicios Coordinar, controlar y verificar la instalacin e implantacin del nuevo sistema 9

Anlisis y Diseo de Sistemas. Disear y desarrollar la configuracin del sistema informtico (de gestin, industrial). Redactar protocolos de aplicaciones, normativas y procedimientos. Negociar con proveedores/as de equipos y software informtico. Puede realizar presentaciones de proyectos. HERRAMIENTAS Las herramientas o materiales de trabajo necesarios para el desarro llo de su actividad son los siguientes: Equipos y maquinaria: ordenadores, monit ores, teclado, ratn, disquetera, cableado y conexiones para red, impresoras, impr esoras lser, modem, sistemas de alimentacin, software de base (sistema operativo: Ms-Dos, Windows, Macintosh, Linux) y software requerido para cada tipo de red, s oftware de ofimtica, etc. Manuales de explotacin, normativa tcnica, manuales de pro gramacin (C, C++, Visual Basic, Delphi, Java, Cobol, Pascal, Oracle, HTML, etc.). 1.1.6 PROGRAMADOR. Un programador es un individuo que ejerce la programacin, es decir, que escribe p rogramas de computadora u ordenador. Los programadores tambin reciben el nombre d e desarrolladores de software. En la mayora de los profesional reconocida. pases, programador es tambin una categora El programador se encarga de la implementacin de prototipos mediante un lenguaje de programacin que pueda entender la computadora. Inicialmente, la profesin se for maliz desde el enfoque Tayloriano de la especializacin de funciones en la empresa. As, el proceso de produccin de software se concibe como un conjunto de tareas alt amente especializadas donde est claramente definido el papel de cada categora prof esional: El analista tiene como cometido analizar un problema y describirlo con el propsito de ser solucionado mediante un sistema de informacin. El programador c uya nica funcin consista en trasladar las especificaciones del analista en cdigo eje cutable por la computadora. Dichas especificaciones se recogen en un documento d enominado cuaderno de carga, medio de comunicacin entre ambos. Obsrvese que esto s e consideraba un trabajo mecnico y de baja cualificacin. Hoy da se reconoce que est e enfoque no es vlido para organizar tareas de tipo intelectual, como es la produ ccin de software. De manera que la profesin de programador ha ido evolucionando. L as dificultades de comunicacin entre analistas y programadores (un mero documento no basta para describir lo que se quiere hacer) dio origen a una categora profes ional intermedia, denominada analista-programador. La concepcin original del prog ramador ha desaparecido siendo sustituida por esta: la de un profesional mucho ms formado y con unas funciones menos "mecnicas". La profesin de analista tambin ha e volucionado, surgiendo el concepto diseador (de software). Esto se debe a los ava nces de la ingeniera del 10

Pablo Ortiz Cruz software donde se reconoce que el anlisis es una actividad distinta del diseo. El anlisis describe el problema (el qu hacer) mientras que el diseo describe la solucin (el cmo hacerlo). En la mayora de pases industrializados esto ha dado lugar a la c ategora profesional del diseador o arquitecto del software. 1.1.7 ADMINISTRADOR DE BASES DE DATOS. El administrador de base de datos (DBA) es la persona responsable de los aspecto s ambientales de una base de datos. En general esto incluye: Recuperabilidad - C rear y probar Respaldos Integridad - Verificar o ayudar a la verificacin en la in tegridad de datos Seguridad - Definir y/o implementar controles de acceso a los datos Disponibilidad - Asegurarse del mayor tiempo de encendido Asegurarse del mx imo desempeo incluso con las e Desempeo limitaciones Desarrollo y soporte a pruebas - Ayudar a los ingenieros a utilizar eficientemen te la base de datos. programadores El diseo lgico y fsico de las bases de datos a pesar de no ser obligaciones de un a dministrador de bases de datos, es a veces parte del trabajo. Esas funciones por lo general estn asignadas a los analistas de bases de datos a los diseadores de b ases de datos. Los deberes de un administrador de bases de datos dependen de la descripcin del puesto, corporacin y polticas de Tecnologas de Informacin (TI). Por lo general se incluye recuperacin de desastres (respaldos y pruebas de respaldos), anlisis de rendimiento y optimizacin, y algo de asistencia en el diseo de la base d e datos. 1.2. CICLO DE VIDA CLSICO El ciclo de vida de un sistema de informacin est ligado al ciclo de vida del siste ma de base de datos sobre el que se apoya. Al ciclo de vida de los sistemas de i nformacin tambin se le denomina ciclo de vida de desarrollo del software. Las etap as tpicas del ciclo de vida de desarrollo del software son: planificacin, recolecc in y anlisis de los requisitos, diseo (incluyendo el diseo de la base de datos), cre acin de prototipos, implementacin, prueba, conversin y mantenimiento. Este ciclo de vida hace nfasis en la identificacin de las funciones que realiza la empresa y en el desarrollo de las aplicaciones que lleven a cabo estas funciones. Se dice qu e el ciclo de vida sigue un enfoque orientado a funciones, ya que los sistemas s e ven desde el punto de vista de las funciones que llevan a cabo. Las etapas del ciclo de vida son: 1).- Planificacin del proyecto o Investigacin Preliminar. 2).Definicin del sistema. 11

Anlisis y Diseo de Sistemas. 3).- Recoleccin y anlisis de los requisitos. 4).- Diseo de la aplicacin o del sistem a. 5).- Implementacin y evaluacin del sistema. 6).- Prueba de sistemas. 7).- Mante nimiento. 1.2.1 INVESTIGACIN PRELIMINAR. La solicitud para recibir ayuda de un sistema de informacin puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la peticin de una persona. Planteamiento del Problema Identificar los componente s, explicando las relaciones entre ellos. Ubicar el problema dentro de un marco conceptual. Analizar el problema desglosando en sus unidades ms simples. simplifi cando, eliminando la informacin redundante. investigar estudios anlogos consultand o la literatura existente. el problema DE plantear investigarlo. en una forma ms variable para poder 1.2.2 DETERMINACIN REQUERIMIENTOS. Determinacin de los requerimientos del sistema: El aspecto fundamental del anlisis de sistemas es comprender todas las facetas importantes de la parte de la empre sa que se encuentra bajo estudio. Cada actividad realizada siempre es parte de u n entorno mayor. El trabajo comienza estableciendo los requisitos de todos aquel los elementos importantes del sistema. Asignando grupos con estos requisitos par a integrar el sistema de cmputo. Es esencial cuando el SW debe interrelacionarse con otros elementos SW, HW, personas, base de datos, etc. 1.2.3 DISEO DEL SISTEMA. Diseo del sistema: El diseo de un sistema de informacin produce los detalles que es tablecen la forma en la que el sistema cumplir con los requerimientos identificad os durante la fase de anlisis. Los especialistas en sistemas se refieren, con fre cuencia, a esta etapa como diseo lgico en contraste con la del desarrollo del soft ware, a la que denominan diseo fsico 1.2.4 DESARROLLO DEL

SOFTWARE. Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseados a la medida del sol icitante. La eleccin depende del costo de cada alternativa, 12

Pablo Ortiz Cruz del tiempo disponible para escribir el software y de la disponibilidad de los pr ogramadores 1.2.5 PRUEBA DEL SISTEMA. Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de maner a experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Dependiendo del tamao de la Empresa que usara el Sistema y e l riesgo asociado a su uso, puede hacerse la eleccin de comenzar la operacin del S istema solo en un rea de la Empresa (como una Prueba piloto), que puede llevarse a cabo en un Departamento o con una o dos personas. Cuando se implanta un nuevo sistema lo aconsejable es que el viejo y el nuevo funcionen de manera simultnea o paralela con la finalidad de comparar los resultados que ambos ofrecen en su op eracin, adems dar tiempo al personal para su entrenamiento y adaptacin al nuevo Sis tema. Durante el Proceso de Implantacin y Prueba se deben implementar todas las e strategias posibles para garantizar que en el uso inicial del Sistema este se en cuentre libre de problemas lo cual se puede descubrir durante este proceso y lev ar a cabo las correcciones de lugar para su buen funcionamiento. Desdichadamente la evaluacin de Sistemas no siempre recibe la atencin que merece, sin embargo cua ndo se lleva a cabo de manera adecuada proporciona muchas informaciones que pued en ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicacione s futuras. 1.2.6 IMPLANTACIN Y EVOLUCIN. La implantacin es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesari os para utilizarla. Una vez instaladas, las aplicaciones se emplean durante much os aos y la evaluacin ocurre a lo largo de cualquiera de las siguientes dimensione s: Evaluacin operacional, Impacto organizacional, Opinin de los administradores, D esempeo del desarrollo. Es la ltima fase del desarrollo de Sistemas. Es el proceso instalar equipos o Software nuevo, como resultado de un anlisis y diseo previo co mo resultado de la sustitucin o mejoramiento de la forma de llevar a cabo un proc eso automatizado. Al Implantar un Sistema de Informacin lo primero que debemos ha cer es asegurarnos que el Sistema sea operacional o sea que funcione de acuerdo a los requerimientos del anlisis y permitir que los usuarios puedan operarlo. Exi sten varios enfoques de Implementacin: Es darle responsabilidad a los grupos. Uso de diferentes estrategias para el entrenamiento de los usuarios. El Analista de Sistemas necesita ponderar la situacin y proponer un plan de conve rsin que sea adecuado para la organizacin. 13

Anlisis y Diseo de Sistemas. El Analista necesita formular medidas de desempeo con las cuales evaluar a los Us uarios. Debe Convertir fsicamente el sistema de informacin antiguo, al nuevo modif icado. En la preparacin de la Implantacin, aunque el Sistema este bien diseado y de sarrollado correctamente su xito depender de su implantacin y ejecucin por lo que es importante capacitar al usuario con respecto a su uso y mantenimiento. Capacita cin de Usuarios del Sistema: Es ensear a los usuarios que se relacionan u operan e n un proceso de implantacin. La Responsabilidad de esta capacitacin de los Usuario s primarios y secundarios es del Analista, desde el personal de captura de datos hasta aquellos que toman las decisiones sin usar una Computadora. No se debe in cluir a personas de diferentes niveles de habilidad e intereses de trabajo; debi do a que si en una Empresa existen trabajadores inexpertos no se pueden incluir en la misma seccin de los expertos ya que ambos grupos quedaran perdidos. "Es com o querer conducir dos Barcos con diferentes destinos con un mismo Mapa de rutas o con el mismo timn". Aun y cuando la Empresa puede contratar los Servicios de In structores externos, el analista es la persona que puede ofrecer la mejor capaci tacin debido a que conoce el personal y al Sistema mejor que cualquier otro. A la falta o imposibilidad del analista la organizacin puede contratar otros servicio s de capacitacin como son: Vendedores: Son aquellos que proporcionan fuera de la Empresa de uno o dos das. capacitacin gratuita Instructor pagado externamente: Son aquellos que pueden ensear todo acerca de las computadoras pero para algunos usuarios esta no es una capacitacin necesaria. In structores en casa: Estn familiarizados con el personal y pueden adecuar los mate riales a sus necesidades, pero le faltara experiencia en Sistemas de Informacin qu e es realmente la necesidad del usuario. Objetivos de la Capacitacin: Es lograr q ue los usuarios tengan el Dominio necesario de las cosas bsicas acerca de las maq uinarias y procesos que se emplean para su operacin de manera eficiente y segura. La Evaluacin del Sistema: Se lleva a cabo para identificar puntos dbiles y fuerte s del Sistema implantado. La evaluacin ocurre a lo largo de cualquiera de las sig uientes cuatro dimensiones: Evaluacin operacional: 14

Pablo Ortiz Cruz Es el Momento en que se evala la manera en que funciona el Sistema, esto incluye su facilidad de uso, Tiempo de respuesta ante una necesidad o proceso, como se a decuan los formatos en que se presenta la Informacin, contabilidad global y su ni vel de Utilidad. Impacto Organizacional: Identifica y mide los beneficios operac ionales para la Empresa en reas tales como, Finanzas (Costos, Ingresos y Ganancia s), eficiencia en el desempeo laboral e impacto competitivo, Impacto, rapidez y o rganizacin en el flujo de Informacin interna y externa. Desempeo del Desarrollo. Es la evaluacin del Proceso de desarrollo adecuado tomando en cuentas ciertos crite rios como, Tiempo y esfuerzo en el desarrollo concuerden con presupuesto y estnda res y otros criterios de Administracin de Proyectos. Adems se incluyen la valoracin de los mtodos y herramientas utilizados durante el desarrollo del Sistema. 1.2.7 MANTENIMIENTO. Con posterioridad a la fase de implementacin de los sistemas, se impone la fase d e mantenimiento. El mantenimiento de sistemas es el mantenimiento continuo despus del inicio del funcionamiento. Cuando se elaboran planes para la estrategia de informacin, las organizaciones no pueden dejar de considerar que el mantenimiento de sistemas es la fase ms prolongada y costosa del ciclo de vida de los sistemas . Las implicaciones del volumen de trabajo para mantenimiento para los planes de estrategia de informacin en una organizacin es un tema que merece atencin especial . La estructura de organizacin necesita flexibilidad para apoyar el mantenimiento de los sistemas existentes concurrentemente con la ejecucin de nuevas tecnologas. Es importante considerar la evaluacin y el monitoreo de un sistema en trminos del mantenimiento necesario y, en consecuencia, reducir o contener los costos implci tos. El mantenimiento de sistemas puede clasificarse en cuatro grupos, cada uno de los cuales repercute en el plan estratgico de informacin institucional de difer entes maneras: Mantenimiento correctivo. Independientemente de cun bien diseado, d esarrollado y probado est un sistema o aplicacin, ocurrirn errores inevitablemente. Este tipo de mantenimiento se relaciona con la solucin o la correccin de problema s del sistema. Atae generalmente a problemas no identificados durante la fase de ejecucin. Un ejemplo de mantenimiento correctivo es la falta de una caracterstica requerida por el usuario, o su funcionamiento defectuoso. Mantenimiento para fin es especficos. Este tipo de mantenimiento se refiere a la creacin de caractersticas nuevas o a la adaptacin de las existentes segn lo requieren los cambios en la org anizacin o los usuarios, por ejemplo, los cambios en el cdigo tributario o los reg lamento internos de la organizacin. Mantenimiento para mejoras. Se trata de la ex tensin o el mejoramiento del desempeo del sistema, ya sea mediante el agregado de nuevas 15

Anlisis y Diseo de Sistemas. caractersticas, o el cambio de las existentes. Un ejemplo de este tipo de manteni miento es la conversin de los sistemas de texto a GUI (interfaz grfica de usuarios ). Mantenimiento preventivo. Este tipo de mantenimiento es probablemente uno de los ms eficaces en funcin de los costos, ya que si se realiza de manera oportuna y adecuada, puede evitar serios problemas en el sistema. Un ejemplo de este mante nimiento fue la correccin del problema del ao 2000. 1.3 ANLISIS ESTRUCTURADO. Un sistema de informacin realiza cuatro actividades bsicas: entrada, almacenamient o, procesamiento y salida de informacin. Entrada de Informacin: Es el proceso medi ante el cual el Sistema de Informacin toma los datos que requiere para procesar l a informacin. Las entradas pueden ser manuales o automticas. Las manuales son aque llas que se proporcionan en forma directa por el usuario, mientras que las automt icas son datos o informacin que provienen o son tomados de otros sistemas o mdulos . Esto ltimo se denomina interfaces automticas. Almacenamiento de informacin: El al macenamiento es una de las actividades o capacidades ms importantes que tiene una computadora, ya que a travs de esta propiedad el sistema puede recordar la infor macin guardada en la seccin o proceso anterior. Esta informacin suele ser almacenad a en estructuras de informacin denominadas archivos. La unidad tpica de almacenami ento son los discos magnticos o discos duros, los discos flexibles o diskettes y los discos compactos (CD-ROM). Procesamiento de Informacin: Es la capacidad del S istema de Informacin para efectuar clculos de acuerdo con una secuencia de operaci ones preestablecida. Estos clculos pueden efectuarse con datos introducidos recie ntemente en el sistema o bien con datos que estn almacenados. Esta caracterstica d e los sistemas permite la transformacin de datos fuente en informacin que puede se r utilizada para la toma de decisiones, lo que hace posible, entre otras cosas, que un tomador de decisiones genere una proyeccin financiera a partir de los dato s que contiene un estado de resultados o un balance general de un ao base. Salida de Informacin: La salida es la capacidad de un Sistema de Informacin para sacar l a informacin procesada o bien datos de entrada al exterior. Las unidades tpicas de salida son las impresoras, terminales, diskettes, cintas magnticas, la voz, los graficadores y los plotters, entre otros. Es importante aclarar que la salida de un Sistema de Informacin puede constituir la entrada a otro Sistema de Informacin o mdulo. En este caso, tambin existe una interface automtica de salida. Por ejempl o, el Sistema de Control de Clientes tiene una interface automtica de salida con el Sistema de Contabilidad, ya que genera las plizas contables de los movimientos procesales de los clientes. 16

Pablo Ortiz Cruz 1.3.1 ELEMENTOS DEL ANLISIS ESTRUCTURADO. Entradas: Elementos que requiere el sistema para funcionar Proceso: Manipular, t rabajar con la entrada para obtener un resultado (tcnicas, formulas, mtodos etc.) Salidas: Resultado, la satisfaccin de la necesidad Frontera: El lmite del sistema Integracin: Es la unin de los elementos del sistema y se define en base a: objetiv os, metas y funciones Comunicacin: Que informacin o datos comunican, hacia donde y por qu medio. se comunican, a quien se 1.4 TCNICAS PARA ENCONTRAR HECHOS. reunir y Los analistas pueden emplear varios mtodos para obtener, determinar los requerimi entos del sistema. Entre estos tenemos: 1.4.1 ENTREVISTAS. Es una conversacin dirigida con el propsito especfico que utiliza un formato de pre guntas y respuestas. Se espera de la entrevista, obtener opiniones de los entrev istados acerca de la situacin actual del sistema, los objetivos organizacionales, comentarios personales y procedimientos. Pasos para planificar la entrevista Leer los antecedentes. - Establecer los objetivos de la entrevista. - Decidir a quin entrevistar. - Preparar al entrevistado. - Decidir el tipo estructurada). de preguntas y la estructura ( estructurada o no 1.4.2 CUESTIONARIOS. Es una tcnica de recopilacin de informacin que permite a travs del empleo de formato s estandarizados reunir informacin para estudiar las actitudes, comportamientos y caractersticas de muchas personas. Los cuestionarios pueden ser de manera rpida, los cuales deben cumplir unas directrices: - Determinar que fines se persigue co n al elaboracin del cuestionario. - Los tipos de preguntas que utiliza un cuestio nario son : abierta y cerrada. - Elegir el lenguaje del cuestionario, implica ut ilizar el lenguaje que emplean los encuestados. la redaccin debe ser sencilla. Us o de escalas en los cuestionarios Los analistas de sistemas emplean dos formas d e escalas de medicin - Escalas nominales: Se emplean para clasificar cosas Que ti po de software emplea mas? 17

Anlisis y Diseo de Sistemas. 1= Un procesador de texto 2= Una hoja de calculo 3= Una base de datos 4= Un prog rama de correo electrnico - Escalas de Intervalos: Poseen la caracterstica de que los intervalos entre cada uno de los nmeros son iguales. Que tan til es el apoyo q ue ofrece el grupo de soporte tcnico? No tiene utilidad alguna Es sumamente til 1 2 3 4 5 Diseo de los cuestionarios: - Dejar bastante espacio en blanco - Facilita r a los encuestados que marquen con claridad sus respuestas - Mantener un estilo consistente. - Mantener lineamientos: primero colocar preguntas mas agrupar los elementos de contenido similar, incorporar preguntas menos polmicas. importantes , primero las 1.4.3 REVISIN DE LOS REGISTROS. Varios tipos de reportes y de registros pueden proporcionar al analista informac in valiosa con respecto a las organizaciones y a sus operaciones. Al revisar los registros, el analista examina la informacin asentada en ellos relacionada con el sistema y los usuarios. La revisin puede efectuarse el comienzo del estudio, com o introduccin o despus, esto sirve para comparar las operaciones actuales, por lo tanto los registros pueden indicar que est sucediendo. Los registros incluyen man uales de polticas, reglamentos y procedimientos estndares de operacin utilizados po r la mayor parte de las organizaciones como guas. Los registros no indican la for ma en la que se desarrollan las actividades, donde se encuentra todo el poder en la toma de decisiones, o como se realizan todas las tareas. 1.4.4 OBSERVACIN. Por medio de la observacin el analista obtiene informacin de primera mano sobre la forma en que se efectan las actividades. este mtodo es til cuando el analista nece sita observar: - La forma en que se manejan los documentos y se llevan a cabo lo s procesos. - Si se siguen los pasos especificados. El mtodo de la observacin cump le unos requisitos - Sirve a un objetivo, previamente establecido - Es planifica da sistemticamente - Es controlada previamente 18

Pablo Ortiz Cruz - Est sujeta a comprobaciones de fiabilidad y validez Etapas de la Observacin: - S e plantea un objetivo - Recogida de datos: definir las variables a observar, cos to en tiempo y gasto econmico, decidir el muestreo de datos. - Anlisis e interpret acin de los datos recogidos - Elaborar conclusiones o incluso replanteamientos Comunicacin de los resultados: Informe sobre si los hallazgos son o no relevantes . 19

Anlisis y Diseo de Sistemas. UNIDAD II: DISEO 2.1 HERRAMIENTAS PARA DE SISTEMAS DE DOCUMENTAR CONCEPTO DECISIN. Apoyan el proceso de formular las caractersticas que el sistema debe tener para s atisfacer los requerimientos detectados durante las actividades del anlisis: 2.1.1 ACCIONES. Herramientas de especificacin. Apoyan el proceso de formular las caractersticas qu e debe tener una aplicacin, tales como entradas, Salidas, procesamiento y especif icaciones de control. Muchas incluyen herramientas para crear especificaciones d e datos. Herramientas para presentacin. Se utilizan para describir la posicin de d atos, mensajes y encabezados sobre las pantallas de las terminales, reportes y o tros medios de entrada y salida. Herramientas para el desarrollo de Sistemas. Es tas herramientas nos ayudan como analistas a trasladar diseos en aplicaciones fun cionales. Herramientas para Ingeniera de Software. Apoyan el Proceso de formular diseos de Software, incluyendo procedimientos y controles, as como la documentacin correspondiente. Generadores de cdigos. Producen el cdigo fuente y las aplicacione s a partir de especificaciones funcionales bien articuladas. Herramientas para p ruebas. Apoyan la fase de la evaluacin de un Sistema o de partes del mismo contra las especificaciones. Incluyen facilidades para examinar la correcta operacin de l Sistema as como el grado de perfeccin alcanzado en comparacin con las expectativa s. La revolucin del procesamiento de datos de manera computarizada, junto con las prcticas de Diseo sofisticadas est cambiando de forma dramtica la manera en que se trasladan las especificaciones de Diseo de Sistemas de Informacin funcionales. 2.1.2 RBOLES DE DECISIN. Cuando un proceso de decisin estructurada se integra con ramificaciones complejas , entonces se hace uso de los rboles de decisiones. Los rboles de decisiones se di bujan sobre un plano horizontal, con la raz del rbol al lado izquierdo del papel y las ramas hacia la derecha. Esto permite al analista describir las condiciones de acciones sobre las ramas. Cuando se dibujan los rboles de decisiones es til dis tinguir entre las condiciones y las acciones. Para este propsito, el uso de un no do cuadrado 20

Pablo Ortiz Cruz indica una accin y un crculo representa una condicin, tal y como se representa en l a figura 5.4.1. El uso de esta notacin hace ms accesible el rbol de decisiones s uno piensa que un crculo significa IF (SI), mientras que cuadrado significa THEN (EN TONCES). El rbol de decisiones tiene tres ventajas principales sobre la tabla de decisiones: Primera, es que toma las ventajas de la estructura consecutiva de la s ramas del rbol de decisiones, de tal forma que se identifican de manera inmedia ta el orden de verificacin de las condiciones y las acciones que se deben llevar a cabo. Segundo, las condiciones y acciones del rbol de decisiones se encuentran en ciertas ramas pero no en otras, a diferencia de las tablas de decisiones, don de todas forman parte de la misma tabla. Tercero, al compararse con las tablas l os rboles de decisiones se entienden con ms facilidad en una organizacin y son apro piados como un mtodo de comunicacin. 2.1.3 TABLAS DE DECISIN. Una tabla de decisiones es una tabla de renglones y columnas que contiene cuatro cuadrantes. El cuadrante superior izquierdo contiene la condicin, el cuadrante s uperior derecho opciones a la condicin. La mitad inferior de la tabla contiene la s acciones que se van a tomar (en el extremo izquierdo) y las reglas para ejecut ar las acciones (en el derecho). Cuando una tabla de decisiones se utiliza para determinar las acciones que se llevaron a cabo, la lgica sigue el sentido del rel oj, comenzando en el extremo superior izquierdo. TABLA DE DECISIONES Condiciones y acciones Reglas Condiciones Alternativas de la condicin Acciones Registro de l as acciones Para construir tablas de decisin, el analista necesita definir el tam ao mximo de la tabla, eliminar cualquier situacin imposible, inconsistencia o redun dancia y simplificar la tabla mejor posible. Los siguientes pasos proveen al ana lista de un mtodo sistemtico para el desarrollo de tablas de decisiones: Determine el nmero de condiciones que pudieran afectar la decisin. Combine renglones que se sobrepongan. El nmero de condiciones ser igual al nmero de renglones presentes en la mitad superior de la tabla de decisiones. Determine el nmero de acciones posib les que puedan realizarse. Este ser igual al nmero de renglones de la parte inferi or de la tabla de decisiones. 21

Anlisis y Diseo de Sistemas. Determine el nmero de opciones para cada condicin. En la forma ms sencilla, habr dos alternativas (S o N) para cada condicin. En una tabla de tipo extendida, puede l legar a haber muchas opciones para cada condicin. 2.2 ELEMENTOS DEL DISEO. Al disear un sistema informtico, se tienen en cuenta los cinco elementos fundament ales que componen el hardware: la unidad aritmtico-lgica, la unidad de control, la memoria, la entrada y la salida. La unidad aritmticolgica realiza operaciones ari tmticas y compara valores numricos. La unidad de control dirige el funcionamiento de la computadora recibiendo instrucciones del usuario y transformndolas en seales elctricas que puedan ser comprendidas por los circuitos del ordenador. La combin acin de la unidad aritmtico-lgica y la unidad de control se denomina unidad central de procesamiento, o CPU (siglas en ingls). La memoria almacena instrucciones y d atos. Las secciones de entrada y salida permiten respectivamente que la computad ora reciba y enve datos. Se necesitan arquitecturas diferentes de hardware debido a las necesidades especializadas de los distintos sistemas y usuarios. Por ejem plo, un usuario puede necesitar que su sistema muestre grficos de forma extremada mente rpida, mientras que otro tal vez necesite buscar eficazmente en una base de datos o tener un consumo bajo de energa, como en el caso de ordenadores personal es porttiles. Adems del diseo del hardware, se debe considerar los sistemas operati vos que harn funcionar el sistema. El software, como los lenguajes de programacin y los sistemas operativos, hace que los detalles de la arquitectura del hardware resulten invisibles para el usuario. Por ejemplo, diferentes computadoras que e mpleen el lenguaje de programacin C o el sistema operativo UNIX pueden parecer ig uales desde el punto de vista del usuario aunque la arquitectura de hardware sea diferente. 2.2.1 FLUJO DE DATOS. Un diagrama de flujo de datos (DFD por sus siglas en espaol e ingls) es una repres entacin grfica del "flujo" de datos a travs de un sistema de informacin. Un diagrama de flujo de datos tambin se puede utilizar para la visualizacin de procesamiento de datos (diseo estructurado). Es una prctica comn para un diseador dibujar un conte xto a nivel de DFD que primero muestra la interaccin entre el sistema y las entid ades externas. Este contexto a nivel de DFD se "explot" para mostrar ms detalles d el sistema que se est modelando. Los diagramas de flujo de datos fueron inventado s por Larry Constantine, el desarrollador original del diseo estructurado, basado en el modelo de computacin de Martin y Estrin: "flujo grfico de datos" . Los diag ramas de flujo de datos (DFD) son una de las tres perspectivas esenciales de Anli sis de Sistemas Estructurados y Diseo por Mtodo SSADM. El patrocinador de un proye cto y los usuarios finales tendrn que ser informados y consultados en todas las e tapas de una evolucin del sistema. Con un diagrama de flujo de datos, los usuario s van a poder visualizar la forma en que el sistema funcione, lo que el sistema va a lograr, y cmo el sistema se pondr en prctica. El antiguo sistema de diagramas de flujo de datos puede ser 22

Pablo O Ortiz Cruz elaborado y se compar con el nuevo siste ma de diagramas de flujo para establecer diferencias y mejoras a aplicar p ara desarrollar un sistema ms eficiente. Los d iagramas de flujo de d atos pueden ser usados para proporcionar al usuario final una idea fsica de cmo resultarn los datos a ltima instancia, y cmo tienen un efecto sobre la estructura de todo el sistema. La manera en que cualquier s istema es d esarrollado puede determinarse a travs de un diagrama de flu jo de datos. El desa rrollo de un DFD ayuda en la identificacin de los datos de la transaccin en el mod elo de datos. 2.2.2 ALMACENES DE DATOS. La integracin de los datos y de los sist emas surge como un resultado directo de la centralizacin del departame nto de sistemas bajo una sola estructura administr ativa. Las nuevas tecnologas relacionadas c on base de datos, sistemas administra dores de bases de datos y le nguajes de cuarta generacin, hicieron posible la int egracin. En esta etapa surge la primera hoja electr nica de clculo comercial y los usuarios inician haciendo sus propias aplicaciones. Esta herramienta ayud mucho a que los usuarios hicieran su pro pio trabajo y no tuvieran que esperar a que su s propuestas de sistemas fueran cumplidas. El costo del equipo y del software di sminuy por lo cual estuvo al alcance de ms usuarios. En forma paralela a los camb ios tecnolgic os, cambi el rol del usuario y del departamento de Sistemas de Infor maci n. El departamento de sistemas evolucion hacia una estructura descentra lizad a, permitiendo al usuario utilizar herramientas para el desarrollo de sistemas. Los usuarios y el departamento de sistema i niciaron el desarrollo de nuevos sis temas, reemplazando los sistemas a ntiguos, en beneficio de la organizacin. El de partamento de Sistemas de Informacin reconoce que la informacin es un recurso muy valioso que debe estar acces ible para todos los usuarios. 23

Anlisis y Diseo de Sistemas. Para poder cumplir con lo anterior resulta necesario administrar los datos en fo rma apropiada, es decir, almacenarlos y mantenerlos en forma adecuada para que l os usuarios puedan utilizar y compartir este recurso. El usuario de la informacin adquiere la responsabilidad de la integridad de la misma y debe manejar niveles de acceso diferentes. 2.2.3 PROCESOS. Actividades para aceptar, manejar y suministrar Pueden ser manuales o basadas en computadora. datos e informacin. 2.2.4 PROCEDIMIENTOS. Mtodos y rutinas para utilizar el sistema de informacin y lograr con ello los resu ltados esperados. 2.2.5 FUNCIONES DEL PERSONAL. Las responsabilidades de todas las personas que tienen que ver con el nuevo sist ema incluyendo los usuarios, operadores de computadora y personal de apoyo. Abar ca todo el espectro de componentes del sistema, incluso desde la entrada de dato s hasta la distribucin de salidas o resultados. A menudo, las funciones del perso nal se establecen en forma de procedimiento. 24

Pablo Ortiz Cruz UNIDAD III: MODELADO DE SISTEMAS ORIENTADO OBJETOS 3.1 CONCEPTOS. A Hay varios conceptos que son propios de la orientacin a objetos y otros inherente s a la tecnologa. Aunque no todos son exclusivos de los sistemas orientados a obj etos estn bien apoyados por el paradigma. Orientado a Objetos: significa que el s oftware se organiza como una coleccin de objetos discretos que contienen tanto es tructuras de datos como comportamiento. Identidad: Los datos estn cuantificados e n entidades discretas y distinguibles denominadas objetos. Cada objeto posee su propia identidad inherente. Pueden ser ejemplos de objetos, un prrafo de un docum ento, la reina blanca del juego de ajedrez, una silla. En otras palabras: dos ob jetos sern distintos aun cuando los valores de todos sus atributos (tales como el nombre y el tamao) sean idnticos. Por ejemplo en un conjunto de 6 sillas de un mi smo juego los valores de los atributos son los mismos y cada una de las sillas t iene su propia identidad. Identificacin: en el mundo real los objetos se limitan a existir, pero dentro de un entorno de computacin cada objeto posee una identifi cacin mediante la cual se puede hacer alusin a l de modo exclusivo. La identificacin se puede implementar de distintas maneras que pueden ser como una direccin, un nd ice de una matriz, o un valor exclusivo de un atributo. Clasificacin: significa q ue los objetos con la misma estructura de datos (atributos) y comportamiento (op eraciones) se aglutinan para formar una clase. Son ejemplos de clases: prrafo, pi eza de ajedrez. Clase: Es una abstraccin que describe propiedades importantes par a una aplicacin y que ignora el resto. La seleccin de clases es arbitraria y depen de de la aplicacin. Una clase contienen el molde (estructura, esquema) a partir d el cual se crean los objetos que pertenecen a ella y el cdigo que debe ejecutarse cada vez que un objeto de la clase recibe un mensaje. Una clase contiene la des cripcin de las caractersticas comunes de todos los objetos que pertenecen a ella: la especificacin del comportamiento, la definicin de la estructura interna y la im plementacin de los mtodos. Instancia: se dice que cada objeto es una instancia de su clase. Toda clase describe un conjunto posiblemente finito de objetos individ uales. Toda instancia de la clase posee su propio valor para cada uno de los atr ibutos pero comparte los nombres de los atributos y las operaciones con las dems instancias de la clase. Todo objeto contiene una referencia implcita a su propia clase; sabe la clase de cosa que es. Los objetos contienen los valores de los atribu tos (que lo distinguen de otros objetos) y una identidad. 25

Anlisis y Diseo de Sistemas. 3.1.1 MODELADO. El Modelado y Diseo Orientado problemas a resolver empleando como base conceptos del mundo combina las estructuras de datos nica. a Objetos se funda en pensar ace rca de modelos que se han organizado tomando real. La unidad bsica es el objeto q ue con los comportamientos en una entidad La Metodologa OMT se extiende desde el anlisis hasta la implementacin pasando por e l diseo. En primer lugar, se construye un modelo de anlisis para abstraer los aspe ctos esenciales del dominio de la aplicacin sin tener en cuenta la implementacin e ventual. En este modelo se toman decisiones importantes que despus se completan p ara optimizar la implementacin en segundo lugar. Los objetos del dominio de la ap licacin constituyen el marco de trabajo del modelo de diseo, pero se implementan e n trminos de objetos del dominio de la computadora. Por ltimo, el modelo de diseo s e implementa en algn lenguaje de programacin, base de datos o hardware. 3.1.2 MODELADO DE OBJETOS. Un modelo es una abstraccin de algo, cuyo objetivo es comprenderlo antes de const ruirlo. Dado que los modelos omiten los detalles no esenciales es ms sencillo man ipularlos que manipular la entidad original. La abstraccin permite enfrentarse a la complejidad. Los ingenieros, artistas y artesanos han estado construyendo mod elos durante miles de aos para probar los diseos antes de ejecutarlos. El desarrol lo de sistemas hardware y software no es una excepcin. Para construir sistemas co mplejos, el desarrollador debe abstraer distintas vistas del sistema, construir modelos utilizando notaciones precisas, verificar que los modelos satisfacen los requisitos del sistema y aadir, gradualmente, detalles para transformar los mode los en una implementacin. Los modelos tienen varios objetivos: Probar una entidad fsica antes de construirla Comunicacin con el cliente Visualizacin del conjunto Re duccin de la complejidad La abstraccin es el examen selectivo de ciertos aspectos de un problema. Su finalidad es aislar aquellos aspectos que sean importantes pa ra algn objetivo y suprimir los aspectos que no lo sean. La abstraccin siempre deb e de hacerse con algn objetivo prefijado, porque el propsito determina lo que es y no es importante. Es posible efectuar muchas abstracciones diferentes de la mis ma cosa, dependiendo del propsito para el cual se hagan esas abstracciones. Todas las abstracciones son incompletas e imprecisas. La realidad es una red sin cost uras. Todo lo que digamos acerca de ella, cualquier descripcin, ser una versin redu cida. Todas las palabras y lenguajes humanos son abstracciones, descripciones in completas del mundo real. Esto no elimina su utilidad. El propsito de una abstrac cin es limitar al universo para que podamos hacer cosas. Al construir modelos, po r tanto, no debe uno buscar la verdad absoluta, sino su adecuacin para algn propsit o. No existe un 26

Pablo Ortiz Cruz nico modelo correcto de una situacin, solo existen modelos adecuados o inadecuados. Un buen modelo captura los aspectos cruciales del problema y omite los dems. La met odologa OMT emplea tres clases de modelos para describir el sistema: el Modelo de Objetos que describe los objetos del sistema y sus relaciones; el Modelo Dinmico que describe las interacciones existentes entre objetos del sistema; y el Model o Funcional que describe las transformaciones de datos del sistema. Todos los mo delos son aplicables en la totalidad de las fases del desarrollo y van adquirien do detalles de implementacin a medida que progresa el desarrollo. 3.1.3 MODELO DINMICO. Describe los aspectos de comportamiento (de control) de un sistema que cambian c on el tiempo. El modelo dinmico se utiliza para especificar e implementar los asp ectos del control del sistema. Los modelos dinmicos contienen diagramas de estado s. Un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos son transiciones entre estados causadas por sucesos o eventos. Se especifican en est e modelo la temporizacin y secuencia de operaciones (sucesos que marcan los cambi os, secuencias de sucesos, estados que definen el contexto para los sucesos), y la organizacin de sucesos y de estados. El modelo dinmico captura el control, aque l aspecto de un sistema que describe las secuencias de operaciones que se produc en sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en la que estn implementadas. Las acciones de los diagramas de estado se corresponden con funciones procedentes del modelo funcional; los sucesos de un diagrama de estado pasan a ser operaciones que se aplican a objetos dentro del m odelo de objetos. 3.1.4 MODELO FUNCIONAL. Describe las transformaciones (de funcin), de valores de datos que ocurren dentro del sistema, captura lo que hace el sistema, independientemente de cuando se ha ga o de la forma en que se haga. El modelo funcional contiene diagramas de flujo de datos. Un diagrama de flujo de datos es un grafo cuyos nodos son procesos y cuyos arcos son flujos de datos, se muestra las dependencias entre los valores y el clculo de valores de salida a partir de los de entrada y de funciones, sin co nsiderar cuando se ejecutan las funciones, ni siquiera si llegan a ejecutarse. L as funciones se invocan como acciones en el modelo dinmico y se muestran como ope raciones que afectan a objetos en el modelo de objetos. 3.2 DESCRIPCIN DE MODELOS DE OBJETOS. Una descripcin completa del sistema requiere los tres modelos. Un procedimiento tp ico de software contiene estos tres aspectos: utiliza estructuras de datos (mode lo de objetos), secuencia las operaciones en el tiempo (modelo dinmico) y transfo rma valores (modelo funcional). Cada modelo referencia a entidades de los otros modelos, los tres modelos estn relacionados entre si. Las interconexiones entre l os distintos modelos 27

Anlisis y Diseo de Sistemas.

son limitadas y explcitas. Los buenos diseos aslan los distintos aspectos del siste ma y limitan el acoplamiento entre ellos. El ms importante es el modelo de objeto s porque es necesario para describir qu est cambiando o transformndose, antes de descr bir cundo y cmo cambia. El enfoque orientado a objetos se centra primordialmente en ficar objetos procedentes del dominio de la aplicacin ajustndoles despus los proced imientos. Soporta mejor las evoluciones de los requisitos porque est basado en el entorno subyacente del dominio de la aplicacin en s, ms que en los requisitos func ionales adhoc de un nico problema. 3.2.1 SIMBOLOGA. PAQUETES: Permiten dividir un modelo, reagrupar y encapsular elementos de modela do y se representa con una carpeta con nombre. los Grficamente un paquete viene representado como se indica en la Figura: Cualquier sistema grande se debe dividir en unidades ms pequeas, de modo que las p ersonas puedan trabajar con una cantidad de informacin limitada, a la vez y de mo do que los equipos de trabajo no interfieran con el trabajo de los otros. Los pa quetes ofrecen un mecanismo general para la organizacin de los modelos/subsistema s agrupando elementos de modelado. Cada paquete corresponde a un submodelo (subs istema) del modelo (sistema). Los paquetes son unidades de organizacin jerrquica d e uso general de los modelos de UML. Pueden ser utilizados para el almacenamient o, el control de acceso, la gestin de la configuracin y la construccin de bibliotec as que contengan fragmentos reutilizables del modelo. CASOS DE USO: Un Caso de U so es representado por una elipse y es una descripcin de la secuencia de interacc iones que se producen entre un actor y el sistema, cuando el actor usa el sistem a para llevar a cabo una tarea especfica. Representan la funcionalidad del sistem a y los requisitos del sistema desde la perspectiva del usuario. Los objetivos d e los casos de uso son los siguientes: Capturar los requisitos funcionales del s istema y expresarlos desde el punto de vista del usuario. Guiar todo el proceso de desarrollo del sistema de informacin. Los casos de uso proporcionan, por tanto , un modo claro y preciso de comunicacin entre cliente y desarrollador. Desde el punto de vista del cliente proporcionan una visin de caja negra del sistema, esto e s, cmo aparece el sistema desde el exterior sin necesidad de entrar en los detall es de su construccin. Para los desarrolladores, suponen el punto de partida y el eje sobre el que se apoya todo el desarrollo del sistema en sus procesos de anlis is y diseo. ACTORES: Un actor es una entidad externa al sistema que realiza algn t ipo de interaccin con el mismo. Se representa mediante una figura humana dibujada con palotes. 28

Pablo Ortiz Cruz Esta representacin sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.). Si se habla de usuarios, un actor e s el papel que puede llevar a cabo en cuanto a su forma de interactuar con el si stema, es decir, un nico actor puede representar a muchos usuarios diferentes y d e la misma forma, un usuario puede actuar como actores diferentes. RELACIONES: L as relaciones pueden tener lugar entre actores y casos de uso o entre casos de u so. La relacin entre un actor y un caso de uso es una relacin de comunicacin, que i ndica que un actor interviene en el caso de uso. Normalmente, el actor aporta in formacin para la realizacin de un caso de uso o recibe informacin como resultado de la realizacin del mismo, por ello, esta relacin puede ser unidireccional o bidire ccional, aunque generalmente se muestra como bidireccional, ya que no es necesar io especificar en detalle estas relaciones. La relacin entre casos de uso es una relacin unidireccional. Esta relacin puede presentar uno de los dos siguientes tip os: usa y extiende. 3.2.2 IDENTIFICACIN DE OBJETOS Y CLASES. OBJETOS: Es la representacin de una entidad sea real o conceptual. Un objeto pued e representar algo concreto (una persona, un auto, una computadora, etc.), o un concepto (un proceso qumico, una transaccin bancaria, una orden de compra, etc.). Un objeto tiene tres caractersticas: a. Estado: Representado por una coleccin de p ropiedades o atributos, por ejemplo el objeto Curso puede estar en uno de dos es tados: Abierto o Cerrado. b. Conducta: Representa todo lo que el objeto puede hacer (Operaciones), por ejemplo un curso disponible podra tener las operaciones: Agreg arEstudiante() y EliminarEstudiante() c. Identidad: Representa la unicidad de un objeto con respecto a otros objetos, por ejemplo: Matemtica 001- Seccin 1 y Matemt ica 001 Seccin 2 son dos objetos del Sistema de Registro Curso. Aunque ambos curs os estn disponibles, cada uno tiene una nica identidad. En uml, los objetos son re presentados con rectngulos y el nombre del objeto es subrayado. CLASES: es una de scripcin de un grupo de objetos la cual consta de: propiedades comunes (los atrib utos), conductas comunes(los funcionamientos), relaciones comunes y semntica comn. As una clase es una plantilla para crear objetos. Cada objeto es una instancia d e alguna clase u objeto. Por ejemplo, la clase Curso Disponible puede definirse co n las siguientes caractersticas: a. Atributos: ubicacin, horas disponibles. b. .Op eraciones: recuperar ubicacin, recuperar horas al da, agregar estudiante. As: Matemt ica 001 Seccin 1 y Matemtica 001 Seccin 2 son objetos pertenecientes a la clase Curs o Disponible. Cada objeto debera tener valores para sus atributos y acceso a las o peraciones especificadas en la clase Curso Disponible. 29

A Anlisis y Dise de Sistema eo as. En UML, las clases se representan con rect ngulos divididos en tres partes. 3.2.3 OPERACIN, MTODOS, ASOCIACION ES Y MULTIPLICIDAD. Las operaciones son los procesos que u na clase sabe llevar a cabo. Evidentement e, corresponden a los mtodos sobre una clase. En el nivel de especificacin, las op eraciones corresponde n a los mtodos pblicos sobre un tipo. En general, no se mues tran aquellas operaciones que simplemente manipulan atributos, ya que por lo comn , se pueden inferir. Sin embargo, tal vez sea necesario indicar si un atributo d ado es de slo lectura o est inmutable congelado (esto es, que su valor nunca cambi a). En el modelo de implementacin, se podran mostrar tamb in las operaciones privad as y protegidas. La sintaxis del UML completa para las operaciones es visibilida d nombre (lista-de-parmetros) : ex presin- tipo-de-dato-a-regresar {cadena-de-prop iedades} . donde visibilidad es + (public), # (protected), o- ( private) nombre es una cadena de caracteres (string ) lista-de-parmetros contiene argumentos (opcion ales) cuya sintaxis, es la misma que la de los atributos expresin-tipo-de-dato-a-r egresar dependiente del lenguaje es una especificacin opcional cadena-de-propiedades indica valores de propiedad que se aplican a la operacin dad a Un ejemplo de operacin sera: + ItimaCa ntidadDe (valorTipoFenmeno) : Cantidad Dent ro de los modelos conceptuales, las o peraciones no deben tratar de especificar la interfaz de una clase. En lug ar de el lo, debern indicar las principales resp onsabilidades de dicha cla se, usando tal vez un par de palabras que sinteticen una responsabilidad de CRC. Con frecuencia encuentro til hacer la distincin entre aquellas operaciones que cambian el estado de una c lase y aq uellas que no lo h acen. Una consulta es una operacin que obtiene un valor de una clase sin que camb ie el estado observable de tal clase. El estado observable de un objeto es el es tado que se puede determinar a parti r de sus consultas asociadas. Considrese un objeto de Cuenta que calcu la su balance a partir de una lista de entradas. Para mejorar el desemp eo, Cuenta puede poner en un campo cach el resultado del clculo del b alance, para consultas futuras. Por tanto, si el cach est vaco, la primera ve z que se llama a la operacin "balance", pondr el resultado en el campo cach. La ope racin "balance" 30

Pablo Ortiz Cruz cambia as el estado real del objeto Cuenta, pero no su estado observable, pues to das las consultas devuelven el mismo valor, est o no lleno el campo cach. Las oper aciones que s cambian el estado observable de un objeto se llaman modificadores. Considero til tener perfectamente clara la diferencia entre consultas y modificad ores. Las consultas se pueden ejecutar en cualquier orden, pero la secuencia de los modificadores es ms importante. Yo tengo como poltica evitar que los modificad ores devuelvan valores, con el fin de mantenerlos separados. Otros trminos que al gunas veces se presentan son: mtodos de obtencin y mtodos de establecimiento. El mto do de obtencin (getting) es un mtodo que devuelve el valor de un campo (sin hacer nada ms). El mtodo de establecimiento (setting) pone un valor en un campo (y nada ms). Desde afuera, el cliente no debe poder saber si una consulta es un mtodo de o btencin ni si un modificador es un mtodo de establecimiento. El conocimiento sobre los mtodos de obtencin y establecimiento est contenido completamente dentro de la clase. Otra distincin es la que se da entre operacin y mtodo. Una operacin es algo q ue se invoca sobre un objeto (la llamada de procedimiento), mientras que un mtodo es el cuerpo del procedimiento. Los dos son diferentes cuando se tiene polimorf ismo. Si se tiene un supertipo con tres subtipos, cada uno de los cuales suplant a la operacin "foo" del supertipo, entonces lo que hay es una operacin y cuatro mto dos que la implementan. Es muy comn que operacin y mtodo se empleen indistintamente , pero hay veces en que es necesario precisar la diferencia. En algunas ocasione s, la gente distingue entre una y otro mediante los trminos llamada a un mtodo, o declaracin de mtodo (en lugar de operacin), y cuerpo del mtodo. Los lenguajes tienen sus propias convenciones para los nombres. En C ++, las operaciones se llaman f unciones miembro; En Smalltalk, operaciones de mtodos. C ++ tambin emplea el trmino miembros de una clase para denominar las operaciones y mtodos de una clase. Son los medios para establecer relaciones entre objetos y clases, un enlace es una c onexin fsica o conceptual entre instancias de objetos, matemticamente se define com o un ente ordenado de instancias de objetos, un enlace es una instancia de una a sociacin, esta describe un grupo de enlaces con estructura y semntica comunes, las asociaciones describen un conjunto de enlaces potenciales, del mismo modo que l as clases describen un conjunto de objetos potenciales, y suelen implementarse e n los lenguajes de programacin como punteros que van de un objeto a otro. La nota cin para las asociaciones es una lnea entre clases, y los enlaces es una lnea entre objetos, el nombre de la asociacin se pone en cursiva. Limita el nmero de objetos relacionados, los diagramas de objetos lo indican mediante smbolos al final de l a lnea de asociacin, subestimar la multiplicidad puede evitar la flexibilidad de u na aplicacin, una subestimacin de la misma impone gastos adicionales extraordinari os. 3.2.4 ATRIBUTO DE ENLACE CLASIFICACIN 31 Y AGREGACIN.

Anlisis y Diseo de Sistemas. Un atributo de un enlace es una propiedad de los enlaces de una asociacin. Todo a tributo de enlace tiene un valor para cada enlace. Rol Es un nombre que identifi ca en forma nica un extremo de la asociacin, el uso de nombres de rol proporciona una forma de recorrer las asociaciones desde un objeto de un extremo sin mencion ar explcitamente la asociacin, los roles pueden aparecer como sustantivos en la de scripcin del problema. Clasificacin Normalmente los objetos del lado muchosen una asociacin no tienen un orden explcito y se pueden considerar como un conjunto, la clasificacin es una parte inherente de la asociacin, si es un conjunto ordenado de objetos se escribe ordenado o clasificado al lado del smbolo de multiplicidad. C ualificacin Una asociacin cualificada relaciona dos clases de objetos y una cualif icada, este es un atributo especial que reduce la multiplicidad efectiva de una asociacin, las asociaciones 1 a N o N a M pueden ser cualificadas, las cuales tam bin se pueden considerar como una forma de asociacin ternaria. Agrupacin Es una for ma fuerte de asociacin, los componentes de algo se asocian a un objeto que repres enta el ensamblaje completo. La agrupacin es una forma especial de asociacin, no u n conceptoindependiente, si dos objetos estn acoplados mediante una relacin todo p arte se trata de una agrupacin, si los dos objetos suelen considerarse independie ntes entonces se trata de una asociacin; entre las pruebas distintivas se incluye : 1.Utilizara Ud. la frase "parte de". 2.Hay algunas operaciones (del todo) que s e aplican automticamente a las partes. 3.Hay algunos valores de atributos (del to do), que se propagan del todo a todas las partes o a algunas de ellas. 4.Existe una asimetra intrnseca de la asociacin de tal modo que una clase de objeto sea subc lase de otra. Arbol de agrupacin Es una notacin taquigrfica que resulta mucho ms sen cilla de dibujar que muchas lneas que contienen los componentes para formar un en samblado. Agregados recursivos Una agregacin puede ser fija, variable o recursiva , los agregadosfijos tienen una estructura fija que ser el nmero y tipo de las par tes componentes que estn predeterminadas, los agregados variablestienen un nmero f inito de niveles, pero el nmero de partes puede variar, los agregados recursivos contienen directa o indirectamente una instancia de esa misma clase de agregado, el nmero de niveles es ilimitado, la forma habitual de un agregado recursivo es una superclase y dos subclases en las 32

Pablo Ortiz Cruz cuales una es un nodo intermedio del agregado y otra es un nodo terminal del agr egado Generalizacin y herencia Son potentes abstracciones para compartir similitu des entre clases al mismo tiempoque se mantienen sus diferencias, la generalizac in es la relacin entre una clase y una o ms reuniones de esa misma clase que conect a a la superclase con sus subclases, la leyenda a la par del tringulo son discrim inadores que indica que propiedad del objeto est siendo abstrado por una relacin de generalizacin en particular. La herencia ha llegado a ser un sinnimo de reutiliza cin del cdigodentro de la programacin orientada a objeto, frecuentemente hay un cdig o que est disponible de trabajos anteriores ( biblioteca), la aplicacin ms importan te es la simplificacin conceptual que proviene de reducir el nmero de caracterstica s independientes dentro del sistema. La generalizacin y especializacin son dos pun tos de vistas distintos, la primera proviene del hecho de que la superclase gene raliza a la subclase y la segunda hace alusin al hecho de que la subclase especia liza a la superclase, una subclase puede anular una caracterstica de una supercla se definiendo una caracterstica del mismo nombre, se hace para obtener un mejor r endimiento. Herencia mltiple Permite que una clase tenga ms de una superclase y qu e herede caractersticas de todas ellas, esto permite mezclar informacinprocedente de dos o ms fuentes, una clase con ms de una superclase se denomina clase unin. Mdul o Es una construccin lgica para agrupar clases, asociaciones y generalizaciones, s us lmites son ligeramente arbitrarios y son materia opinable, el nombre del mdulo debe especificarse en la parte superior de la hoja, los mdulos nos permiten desco mponer al modelo en segmentos manejables. Hojas Una hoja es el mecanismo para de scomponer un modelo de objetos grande, en un conjunto de pginas; por lo general n o pondremos ms de un mdulo por folio, una hoja es una notacin c moda, no una estruct ura lgica. Clases abstractas Es una clase que no tiene instancias directas, en ca mbio una clase concreta puede unir instancias discretas, una clase concreta pued e formar subclases abstractas. Metadatos Son datos que describen datos, por ejem plo: La definicin de clases, los mdulos, los planos, etc. Claves candidatas 33

A Anlisis y Dise de Sistema eo as. Es un conjunto mnimo de atributos que definen de manera unvoca un objeto. Una clas e puede tener ms de una c lave candidata, cada una de las cuales tendr distintas c ombinaciones y nm ero de atributos. La etiqueta de un objeto es siempre una cla v e candidata de una clase, para las asociaciones son claves candidatas una o ms co mbinaciones de objetos relacionados. 3.3 DESCRIPCIN Modelo Dinmico DEL MODELO DINMICO . Los aspectos del sistema que estn relacion ados con los tiempos y con los cambios constituyen lo modelos dinmicos, los conceptos ms importantes del modelado dinmico son: Los recursos (e stmulos externos) y los estados (valores de los objetos). E scenario: Es una secuencia de sucesos que se producen durante una ejecucin comple ta de un sistema, el ambi ente puede incluir a todos los sucesos o solo a aquell os que afecten a algunos objetos del sistema, el paso siguiente a la escritura d e un escenario con siste en identificar a los objetos emisores y receptores de c ada suceso. Los objetos que intercambian sucesos se pueden mostrar en un ambient e m ejorado llamado diagrama de segmentos de trazos de sucesos. Actividad: Es un a operacin cuya realizacin requiere un cierto tiempo, toda actividad esta asociada a un esta do; entre las actividades se encuentran las operaciones continuas, un estado puede controlar una actividad continua, la cual persiste hasta q ue se p roduce un suceso que le da fin, produciendo una transicin que sale de ese estado Accin: Es una operacin instantnea que va asociada a un suceso, las acciones tambin p ueden representar operaciones internas de control, tales como dar un valor a un atributo o generar o tros sucesos, estas acciones son mecanismos para estructura r el control dent ro de una implementacin. 3.3.1 SIMBOLOGA. El modelo dinmico del sistema que represe nta los aspectos temporales, de comport amiento y de control de un sistema ( de gran ayuda cuando Se tienen sistemas en tiempo real o sistemas orien tados a eventos, en donde la realizacin de una afect a el comportamient o global del sistema). Describe las interacciones entre los o bjetos en el sis tema. Es usado para especificar e implementar los aspectos de c ontrol del si stema. C onsiste en un diagrama 34

Pablo O Ortiz Cruz de estados que es un grafo cuyos transiciones causadas por eventos. nodos son estados y los arcos son El modelo funcional del sistema, que represe nta los aspectos de transformacin lo s datos y de funcin de un sistema. Consiste en un grafo cuyos nodos son procesos y arcos son flujos de datos, dicho grafo es llamado diagrama de flujo de datos. La figura 5.3 m uestra los smbolos usados por este modelo. Los modelos no son independientes entre s, mas bien, el objetivo de la metodologa es mantener una relacin entre ellos de tal forma que sean una estructura que perm ita avanzar consistente mente y que si una cambia sea fcil el cambiar la siguient e. As el modelo de objetos describe estructuras de datos que los modelos dinmico y funcional utilizan. Las operaciones en el modelo de objetos corresponden a eve ntos en el modelo dinmico y funciones en el modelo funcional. El modelo dinmico de scribe la estructura de control de los objetos mostrando decision es que depende n de los valores de los objetos en un instante dado. El modelo funcional describ e funciones in vocadas por operaciones en el modelo de objetos y acciones en el modelo dinmico. Las funciones operan sobre valores de datos especificados por el m odelo de objetos. 3.3.2 SUCESOS Y ESTADOS. Sucesos y enlaces Estados: Son los valores de los atributos y d e los enlaces ma ntenidos por un objeto, un diagrama de estado es una redd e estados y recursos, el modelo 35

Anlisis y Diseo de Sistemas. dinmico consta de mltiples diagramas de estado, cada uno de ellos para cada clase que contenga un comportamiento dinmico importante y muestre la actividad del sist ema. Suceso: Es algo que transcurre durante un perodo de tiempo (ej. "el vuelo 34 1 sale a Crdoba"); dos sucesos que no tienen relacin causal son concurrentes, no t ienen efecto entre s, un suceso es una transmisin de informacin de direccin nica entr e un objeto y otro. Todo suceso se agrupa en clases a los que se les da un nombr e para una comodidad de estructura (jerrquica) y de comportamiento, todo suceso a porta informacin de un objeto a otro, los valores de los datos aportados son sus atributos. 3.3.3 ESCENARIOS. Es una secuencia de sucesos que se producen durante una ejecucin completa de un s istema, el ambiente puede incluir a todos los sucesos o solo a aquellos que afec ten a algunos objetos del sistema, el paso siguiente a la escritura de un escena rio consiste en identificar a los objetos emisores y receptores de cada suceso. Los objetos que intercambian sucesos se pueden mostrar en un ambiente mejorado l lamado diagrama de segmentos de trazos de sucesos. Actividad: Es una operacin cuy a realizacin requiere un cierto tiempo, toda actividad esta asociada a un estado; entre las actividades se encuentran las operaciones continuas, un estado puede controlar una actividad continua, la cual persiste hasta que se produce un suces o que le da fin, produciendo una transicin que sale de ese estado Accin: Es una op eracin instantnea que va asociada a un suceso, las acciones tambin pueden represent ar operaciones internas de control, tales como dar un valor a un atributo o gene rar otros sucesos, estas acciones son mecanismos para estructurar el control den tro de una implementacin. 3.3.4 DIAGRAMAS DE ESTADO. Los sucesos se pueden representar como operaciones en el modelo de objeto. Un so lo objeto puede tener distintos estados a lo largo del tiempo, pero no puede ten er distintas clases. Las diferencias inherentes entre objetos son modelados corr ectamente como clases distintas, mientras que las diferencias temporales son mod elados correctamente como distintos estados entre los miembros de una misma clas e. Algunos consejos: 1. Solo hay que construir diagramas de estados para las cla ses que tengan un comportamiento dinmico. 2. Para comenzar la construccin utilizar escenarios como ayuda. 3. 4. del diagrama de estado hay que Solo hay que considerar los atributos relevantes Solo hay que dejar que la aplic acin distinga acciones y actividades. 5. Cuando un estado tiene mltiples transiciones entrantes y todas hacen que se pr oduzca una misma accin, hay que poner las acciones dentro 36

Pablo Ortiz Cruz de cuadros de estados, anteponiendo el suceso de entrada en lugar en arcos de transicin (lo mismo para los sucesos de salida). 6. e los diagramas de estado de las subclases sean independientes de de estados de sus superclases, estas deberan concentrarse en los ivos de esas subclases. 3.3.5 CONDICIONES Y OPERACIONES. Una operacin es una funcin o transformacin que puede ser aplicada por los objetos d e una clase, todos los objetos de una clase comparten las mismas operaciones y u na misma operacin puede aplicarse a clases distintas, cada operacin es polimrfica, es decir que una misma operacin adopta distintas formas en distintas clases. 3.3.6 FUNDAMENTOS DE ESTADO. Son los valores de los atributos y de los enlaces mantenidos por un objeto, un d iagrama de estado es una red de estados y recursos, el modelo dinmico consta de ml tiples diagramas de estado, cada uno de ellos para cada clase que contenga un co mportamiento dinmico importante y muestre la actividad del sistema. 3.4 DESCRIPCIN DEL MODELO FUNCIONAL. Describe las transformaciones (de funcin), de valores de datos que ocurren dentro del sistema, captura lo que hace el sistema, independientemente de cuando se ha ga o de la forma en que se haga. El modelo funcional contiene diagramas de flujo de datos. Un diagrama de flujo de datos es un grafo cuyos nodos son procesos y cuyos arcos son flujos de datos, se muestra las dependencias entre los valores y el clculo de valores de salida a partir de los de entrada y de funciones, sin co nsiderar cuando se ejecutan las funciones, ni siquiera si llegan a ejecutarse. L as funciones se invocan como acciones en el modelo dinmico y se muestran como ope raciones que afectan a objetos en el modelo de objetos. 3.4.1 SIMBOLOGA. Muestra la forma en la que se derivan los valores producidos en un clculo a parti r de los valores introducidos, sin tener en cuenta el orden en que se calculan, consta de mltiples DFD que muestran el flujo de valores desde las entradas extern as a travs de las operaciones y almacenes hasta las salidas externas, las DB suel en tener un modelo funcional no importante. DFD: Muestra las relaciones funciona les entre los valores calculados por un sistema incluyendo los valores introduci dos, los obtenidos y los almacenes internos de datos. Un DFD contiene procesos q ue transforman datos, flujos de datos, objetos actores que producen y consumen d atos y almacenes de datos que los almacenan en forma pasiva. Procesos: Transform a valores de datos, los de bajo nivel son funciones puras sin efectos laterales, un grfico completo e un flujo de datos es un proceso de alto nivel y pueden tene r efectos laterales como almacenes de datos de objetos externos. Flujo de datos: Conecta la salida de un objeto o proceso con la entrada de otro objeto o proces de enumerarlas Intente hacer qu los diagramas atributos exclus

o, se dibuja como flechas entre el productor y el 37

Anlisis y Diseo de Sistemas. consumidor (de valores descripcin de los datos. de datos). La flecha esta rotulada con una Grficamente: dos lneas paralelas y un nombre. Flujo de control: Un diagrama de flu jo de control muestra todas las posibles vas de computacin para los valores, no mu estra cuales son las vas que se ejecutan ni en qu orden, se muestran con una lnea d iscontinua que va de un proceso que produce un valor hasta el que se est controla ndo. 3.4.2 DIAGRAMA DE HOJA DE DATOS. Una hoja es el mecanismo para descomponer un modelo de objetos grande, en un con junto de pginas; por lo general no pondremos ms de un mdulo por folio, una hoja es una notacin cmoda, no una estructura lgica. 3.4.3 FLUJO DE DATOS, ACTORES Y ALMACN DE DATOS. Actores: Es un objeto activo que controla el grfico de flujo de datos produciendo o consumiendo valores, estn asociados a las entradas y a las salidas del grfico d e flujo de datos, se denominan tambin terminador. Almacn de datos: Es un objeto pa sivo dentro de un DFD, a diferencia de los actores no genera ninguna operacin por s mismo, sino que almacena y accede a datos.

3.4.4 FLUJO DE CONTROL. Flujo de control: Un diagrama de flujo de control muestra todas las posibles vas de computacin para los valores, no muestra cuales son las vas que se ejecutan ni e n qu orden, se muestran con una lnea discontinua que va de un proceso que produce un valor hasta el que se est controlando. 38

Pablo Ortiz Cruz BIBLIOGRAFIA Anlisis y diseo de sistemas E. KENDALL, KENNETH y E. KENDALL, JULIE Sexta edicin PE ARSON EDUCACIN Mxico, 2005. Anlisis y diseo de sistemas de informacin James A. Senn S egunda edicin Mc Graw-Hill. Mxico. 1991 39

Vous aimerez peut-être aussi