Analisis y diseño de sistemas

ORTIZ CRUZ PABLO

A N Á L I S I S Y D I S E Ñ O D E S I S T E M A S

SAETI

T U R N O V E S P E R T I N O

FECHA DE INGRESO (PERIODO) MAYO 2010

Análisis y Diseño de Sistemas.

UNIDAD I: MÉTODOS TRADICIONALES DEL ANÁLISIS DE SISTEMAS ............................................................ .................................................................................... ........................ 3

1.1 CONCEPTOS GENERALES . ........................................................ ...................................................................................... ............................................................ ............................................................. .................................................. ................... 3 1.1.1 SISTEMAS. ............................................................ .......................................................................................... ............................................................ ............................................................. ....................................................... ........................ 3 1.1.2 SISTEMAS DE INFORMACIÓN ........................................................... ........................................................................................ ............................................................ ............................................................ .............................. 3 1.1.3 ANÁLISIS. ........................................................ ...................................................................................... ............................................................ ............................................................. ............................................................ ............................. 3 1.1.4 DISEÑO............................................................ ......................................................................................... ............................................................ ............................................................. ............................................................ ............................. 6 1.1.5 ANALISTA DE SISTEMAS............................................................ .......................................................................................... ............................................................ .............................................................. ................................... ... 9 1.1.6 PROGRAMADOR . ........................................................ ...................................................................................... ............................................................ ............................................................ ................................................ .................. 10 1.1.7 ADMINISTRADOR DE BASES DE DATOS. ......................................................... ....................................................................................... ............................................................ ........................................... ............. 11 1.2. CICLO DE VIDA CLÁSICO ............................................................ .......................................................................................... ............................................................ ............................................................ ........................................... ............. 11 1.2.1 INVESTIGACIÓN PRELIMINAR. ........................................................ ...................................................................................... ............................................................ .......................................................... ............................ 12 1.2.2 DETERMINACIÓN DE REQUERIMIENTOS . ......................................................... ...................................................................................... ........................................................... ........................................... ............. 12 1.2.3 DISEÑO DEL SISTEMA. ......................................................... ....................................................................................... ............................................................ ............................................................ ...................................... ........ 12 1.2.4 DESARROLLO DEL SOFTWARE. ............................................................ .......................................................................................... ............................................................ ..................................................... ....................... 12 1.2.5 PRUEBA DEL SISTEMA. ......................................................... ....................................................................................... ............................................................ ............................................................ ...................................... ........ 13 1.2.6 IMPLANTACIÓN Y EVOLUCIÓN ............................................................. .......................................................................................... ............................................................ ..................................................... ....................... 13 1.2.7 MANTENIMIENTO ............................................................ ......................................................................................... ............................................................ ............................................................ ........................................... ............. 15 1.3 ANÁLISIS ESTRUCTURADO . .......................................................... ........................................................................................ ............................................................ ............................................................ ........................................... ............. 16 1.3.1 ELEMENTOS DEL ANÁLISIS ESTRUCTURADO ........................................................... ....................................................................................... .......................................................... ................................... ...... 17 1.4 TÉCNICAS PARA ENCONTRAR HECHOS. ............................................................ .......................................................................................... ............................................................ ..................................................... .......................1 7 1.4.1 ENTREVISTAS . ........................................................... ......................................................................................... ............................................................ ............................................................. ................................................ ................. 17 1.4.2 CUESTIONARIOS ......................................................... ....................................................................................... ............................................................ ............................................................ ................................................ .................. 17 1.4.3 REVISIÓN DE LOS REGISTROS. ........................................................ ...................................................................................... ............................................................ .......................................................... ............................ 18 1.4.4 OBSERVACIÓN . .......................................................... ........................................................................................ ............................................................ ............................................................. ................................................ ................. 18 UNIDAD II: DISEÑO DE SISTEMAS ................................................... ................................................................................. ............................................................. ............................................................ ..................................... ........ 20

2.1 HERRAMIENTAS PARA DOCUMENTAR CONCEPTO DE DECISIÓN. .......................................................... ....................................................................................... ................................................. .................... 20 2.1.1 ACCIONES. ........................................................... ......................................................................................... ............................................................ ............................................................. ..................................................... ...................... 20 2.1.2 ÁRBOLES DE DECISIÓN. ............................................................ .......................................................................................... ............................................................ ............................................................ ................................. ... 20 2.1.3 TABLAS DE DECISIÓN. ......................................................... ....................................................................................... ............................................................ ............................................................ ...................................... ........ 21 2.2 ELEMENTOS DEL DISEÑO......................................................... ....................................................................................... ............................................................ ............................................................ ................................................ .................. 22 2.2.1 FLUJO DE DATOS. ........................................................... ......................................................................................... ............................................................ ............................................................ ........................................... ............. 22 2.2.2 ALMACENES DE DATOS............................................................. .......................................................................................... ............................................................ ............................................................ ................................. ... 23 2.2.3 PROCESOS . ........................................................... ......................................................................................... ............................................................ ............................................................. ..................................................... ...................... 24 2.2.4 PROCEDIMIENTOS . .......................................................... ........................................................................................ ............................................................ ............................................................ ........................................... ............. 24 2.2.5 FUNCIONES DEL PERSONAL. ........................................................... ......................................................................................... ............................................................ .......................................................... ............................ 24 UNIDAD III: MODELADO DE SISTEMAS ORIENTADO A OBJETOS...................... OBJET OS................................................... ......................................................... ........................................ ............ 25

3.1 CONCEPTOS . ............................................................ .......................................................................................... ............................................................ ............................................................ ........................................................... ................................. .... 25 3.1.1 MODELADO . ......................................................... ....................................................................................... ............................................................ ............................................................. ..................................................... ...................... 26 3.1.2 MODELADO DE OBJETOS. .......................................................... ........................................................................................ ............................................................ ............................................................ ................................. ... 26 3.1.3 MODELO DINÁMICO. ........................................................... ......................................................................................... ............................................................ ............................................................ ...................................... ........ 27 3.1.4 MODELO FUNCIONAL ........................................................... ........................................................................................ ............................................................ ............................................................ ...................................... ........ 27 3.2 DESCRIPCIÓN DE MODELOS DE OBJETOS. ......................................................... ....................................................................................... ............................................................ ..................................................... ....................... 27 3.2.1 SIMBOLOGÍA......................................................... ...................................................................................... ............................................................ ............................................................. ..................................................... ...................... 28 3.2.2 IDENTIFICACIÓN DE OBJETOS Y CLASES. ........................................................ ...................................................................................... ............................................................ ........................................... ............. 29 3.2.3 OPERACIÓN , MÉTODOS, ASOCIACIONES Y MULTIPLICIDAD. ....................................................... .................................................................................... ............................................ ...............30 3.2.4 ATRIBUTO DE ENLACE CLASIFICACIÓN Y AGREGACIÓN......................................................... ..................................................................................... ................................................. .................... 31 3.3 DESCRIPCIÓN DEL MODELO DINÁMICO. ........................................................... ......................................................................................... ............................................................ ..................................................... .......................3 4 3.3.1 SIMBOLOGÍA......................................................... ...................................................................................... ............................................................ ............................................................. ..................................................... ...................... 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 DESCRIPCIÓN DEL MODELO FUNCIONAL ........................................................... ......................................................................................... ............................................................ ..................................................... ....................... 37 3.4.1 SIMBOLOGÍA......................................................... ...................................................................................... ............................................................ ............................................................. ..................................................... ...................... 37 3.4.2 DIAGRAMA DE HOJA DE DATOS. ......................................................... ....................................................................................... ............................................................ ..................................................... ....................... 38 3.4.3 FLUJO DE DATOS, ACTORES Y ALMACÉN DE DATOS. ........................................................ ..................................................................................... ...................................................... ......................... 38 3.4.4 FLUJO DE CONTROL. ............................................................ .......................................................................................... ............................................................ ............................................................ ...................................... ........ 38 BIBLIOGRAFIA .......................................................... ....................................................................................... ........................................................... ........................................................... .......................................................... ...................................... ......... 39

2


UNIDAD I: MÉTODOS TRADICIONALES DEL ANÁLISIS DE SISTEMAS ............................................................ .................................................................................... ........................ 3

1.1 CONCEPTOS GENERALES . ........................................................ ...................................................................................... ............................................................ ............................................................. .................................................. ................... 3 1.1.1 SISTEMAS. ............................................................ .......................................................................................... ............................................................ ............................................................. ....................................................... ........................ 3 1.1.2 SISTEMAS DE INFORMACIÓN ........................................................... ........................................................................................ ............................................................ ............................................................ .............................. 3 1.1.3 ANÁLISIS. ........................................................ ...................................................................................... ............................................................ ............................................................. ............................................................ ............................. 3 1.1.4 DISEÑO............................................................ ......................................................................................... ............................................................ ............................................................. ............................................................ ............................. 6 1.1.5 ANALISTA DE SISTEMAS............................................................ .......................................................................................... ............................................................ .............................................................. ................................... ... 9 1.1.6 PROGRAMADOR . ........................................................ ...................................................................................... ............................................................ ............................................................ ................................................ .................. 10 1.1.7 ADMINISTRADOR DE BASES DE DATOS. ......................................................... ....................................................................................... ............................................................ ........................................... ............. 11 1.2. CICLO DE VIDA CLÁSICO ............................................................ .......................................................................................... ............................................................ ............................................................ ........................................... ............. 11 1.2.1 INVESTIGACIÓN PRELIMINAR. ........................................................ ...................................................................................... ............................................................ .......................................................... ............................ 12 1.2.2 DETERMINACIÓN DE REQUERIMIENTOS . ......................................................... ...................................................................................... ........................................................... ........................................... ............. 12 1.2.3 DISEÑO DEL SISTEMA. ......................................................... ....................................................................................... ............................................................ ............................................................ ...................................... ........ 12 1.2.4 DESARROLLO DEL SOFTWARE. ............................................................ .......................................................................................... ............................................................ ..................................................... ....................... 12 1.2.5 PRUEBA DEL SISTEMA. ......................................................... ....................................................................................... ............................................................ ............................................................ ...................................... ........ 13 1.2.6 IMPLANTACIÓN Y EVOLUCIÓN ............................................................. .......................................................................................... ............................................................ ..................................................... ....................... 13 1.2.7 MANTENIMIENTO ............................................................ ......................................................................................... ............................................................ ............................................................ ........................................... ............. 15 1.3 ANÁLISIS ESTRUCTURADO . .......................................................... ........................................................................................ ............................................................ ............................................................ ........................................... ............. 16 1.3.1 ELEMENTOS DEL ANÁLISIS ESTRUCTURADO ........................................................... ....................................................................................... .......................................................... ................................... ...... 17 1.4 TÉCNICAS PARA ENCONTRAR HECHOS. ............................................................ .......................................................................................... ............................................................ ..................................................... .......................1 7 1.4.1 ENTREVISTAS . ........................................................... ......................................................................................... ............................................................ ............................................................. ................................................ ................. 17 1.4.2 CUESTIONARIOS ......................................................... ....................................................................................... ............................................................ ............................................................ ................................................ .................. 17 1.4.3 REVISIÓN DE LOS REGISTROS. ........................................................ ...................................................................................... ............................................................ .......................................................... ............................ 18 1.4.4 OBSERVACIÓN . .......................................................... ........................................................................................ ............................................................ ............................................................. ................................................ ................. 18 UNIDAD II: DISEÑO DE SISTEMAS ................................................... ................................................................................. ............................................................. ............................................................ ..................................... ........ 20

2.1 HERRAMIENTAS PARA DOCUMENTAR CONCEPTO DE DECISIÓN. .......................................................... ....................................................................................... ................................................. .................... 20 2.1.1 ACCIONES. ........................................................... ......................................................................................... ............................................................ ............................................................. ..................................................... ...................... 20 2.1.2 ÁRBOLES DE DECISIÓN. ............................................................ .......................................................................................... ............................................................ ............................................................ ................................. ... 20 2.1.3 TABLAS DE DECISIÓN. ......................................................... ....................................................................................... ............................................................ ............................................................ ...................................... ........ 21 2.2 ELEMENTOS DEL DISEÑO......................................................... ....................................................................................... ............................................................ ............................................................ ................................................ .................. 22 2.2.1 FLUJO DE DATOS. ........................................................... ......................................................................................... ............................................................ ............................................................ ........................................... ............. 22 2.2.2 ALMACENES DE DATOS............................................................. .......................................................................................... ............................................................ ............................................................ ................................. ... 23 2.2.3 PROCESOS . ........................................................... ......................................................................................... ............................................................ ............................................................. ..................................................... ...................... 24 2.2.4 PROCEDIMIENTOS . .......................................................... ........................................................................................ ............................................................ ............................................................ ........................................... ............. 24 2.2.5 FUNCIONES DEL PERSONAL. ........................................................... ......................................................................................... ............................................................ .......................................................... ............................ 24 UNIDAD III: MODELADO DE SISTEMAS ORIENTADO A OBJETOS...................... OBJET OS................................................... ......................................................... ........................................ ............ 25

3.1 CONCEPTOS . ............................................................ .......................................................................................... ............................................................ ............................................................ ........................................................... ................................. .... 25 3.1.1 MODELADO . ......................................................... ....................................................................................... ............................................................ ............................................................. ..................................................... ...................... 26 3.1.2 MODELADO DE OBJETOS. .......................................................... ........................................................................................ ............................................................ ............................................................ ................................. ... 26 3.1.3 MODELO DINÁMICO. ........................................................... ......................................................................................... ............................................................ ............................................................ ...................................... ........ 27 3.1.4 MODELO FUNCIONAL ........................................................... ........................................................................................ ............................................................ ............................................................ ...................................... ........ 27 3.2 DESCRIPCIÓN DE MODELOS DE OBJETOS. ......................................................... ....................................................................................... ............................................................ ..................................................... ....................... 27 3.2.1 SIMBOLOGÍA......................................................... ...................................................................................... ............................................................ ............................................................. ..................................................... ...................... 28 3.2.2 IDENTIFICACIÓN DE OBJETOS Y CLASES. ........................................................ ...................................................................................... ............................................................ ........................................... ............. 29 3.2.3 OPERACIÓN , MÉTODOS, ASOCIACIONES Y MULTIPLICIDAD. ....................................................... .................................................................................... ............................................ ...............30 3.2.4 ATRIBUTO DE ENLACE CLASIFICACIÓN Y AGREGACIÓN......................................................... ..................................................................................... ................................................. .................... 31 3.3 DESCRIPCIÓN DEL MODELO DINÁMICO. ........................................................... ......................................................................................... ............................................................ ..................................................... .......................3 4 3.3.1 SIMBOLOGÍA......................................................... ...................................................................................... ............................................................ ............................................................. ..................................................... ...................... 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 DESCRIPCIÓN DEL MODELO FUNCIONAL ........................................................... ......................................................................................... ............................................................ ..................................................... ....................... 37 3.4.1 SIMBOLOGÍA......................................................... ...................................................................................... ............................................................ ............................................................. ..................................................... ...................... 37 3.4.2 DIAGRAMA DE HOJA DE DATOS. ......................................................... ....................................................................................... ............................................................ ..................................................... ....................... 38 3.4.3 FLUJO DE DATOS, ACTORES Y ALMACÉN DE DATOS. ........................................................ ..................................................................................... ...................................................... ......................... 38 3.4.4 FLUJO DE CONTROL. ............................................................ .......................................................................................... ............................................................ ............................................................ ...................................... ........ 38 BIBLIOGRAFIA .......................................................... ....................................................................................... ........................................................... ........................................................... .......................................................... ...................................... ......... 39

2

Pablo Ortiz Cruz

UNIDAD I: MÉTODOS TRADICIONALES SISTEMAS

DEL

A N Á L I S I S

DE

1.1 CONCEPTOS GENERALES. 1.1.1 SISTEMAS. Todas las organizaciones son sistemas que actúan recíprocamente con s u medio ambiente recibiendo entradas y produciendo salidas. Los sistemas, que pueden estar formados por otros sistemas más pequeños denominados subsistemas, funcionan para alcanzar fines específicos. Sin embargo, los propósitos o metas se alcanzan sólo cuando se mantienen el control.

1.1.2 SISTEMAS

DE

INFORMACIÓN.

Conjunto u ordenación de elementos organizados para llevar a cabo algún métodos, procedimiento o control mediante el proceso de información. ELEMENTOS DE UN SISTEMA DE INFORMACION SOFWARE. Los programas de computadoras, as estructuras de datos y la documentación asociada, que sirve para realizar el método lógico. HARWARE: Los dispositivos electrónicos que proporcionan la capacidad de computación y que proporcionan las funciones del mundo exterior. GENTE: Los individuos que son usuarios y operadores del software y del hardware. BASES DE DATOS: Una colección grande y organizada de información a la que se accede mediante el software y que es una parte integral del funcionamiento del sistema. DOCUMENTACION: Los manuales, los impresos y otra información descriptiva que exp lica el uso y / o la operación. PROCESAMIENTOS: Los pasos que definen el uso especifico de cada elemento del sistema o el contexto procedimental en que reside el sistema. CONTROL: Los sistemas trabajan mejor cuando operan dentro de niveles de control tolerables de rendimiento por ejemplo: el sistema de control de un calentador de agua.

1 . 1 . 3 A N Á L I S I S . Análisis Es el proceso de clasificación e interpre tación de hechos, diagnostico de problemas y empleo de la información para recomendar mejoras al sistemas. Conceptos y Análisis: Es un conjunto o disposición de procedimientos o programas relacionados de manera que juntos forman una sola unidad. Un conjunto de hechos, principios y reglas clasificadas y dispuestas de manera ordenada mostrando un plan lógico en la unión de las partes. Un método, plan o procedimiento de clasificación para hacer algo. También es un conjunto o arreglo de elementos para realizar un objetivo predefinido en el procesamiento de la Información. Esto se lleva a cabo teniendo en cuenta ciertos principios: 3


• Debe presentarse y entenderse el dominio de la información de un problema. • Defina las funciones que debe realizar el Software. • Represente el comportamiento del software a consecuencias de acontecimientos externos. • Divida en forma jerárquica los modelos que representan la información, funciones y comportamiento. El proceso debe partir desde la información esencial hasta el detalle de la Implementación. La función del Análisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir este objetivo, un Sistema basado en computadoras hace uso de seis (6) elementos fundamentales: • Software, que son Programas de computadora, con estructuras de datos y su documentación que hacen efectiva la logística metodol ogía o controles de requerimientos del Programa. • Hardware, dispositivos electrónicos y electromecánicos, que proporcionan capacidad de cálculos y funciones rápidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que proporcionan una función externa dentro de los Sistemas. • Personal, son los operadores o usuarios directos de las herramientas del Sistema. • Base de Datos, una gran colección de informaciones organizadas y enlazadas al Sistema a las que se accede p or medio del Software. • Documentación, Manuales, formularios, y otra información descriptiva que detalla o da instrucciones sobre el empleo y operación del Programa. • Procedimientos, o pasos que definen el uso especifico de cada uno de los elementos o componentes del Sistema y las reglas de s u manejo y mantenimiento. Un Análisis de Sistema se lleva a cabo teniendo en cuenta los siguien tes objetivos en mente: • Identifique las necesidades del Cliente. • Evalúe que conceptos tiene el cliente del sistema para establecer su viabilidad. • Realice un Análisis Técnico y económico. • Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos del Sistema. • Establezca las restricciones de presupuesto s y planificación temporal. • Cree una definición del sistema que forme el fundamento de todo el trabajo de Ingeniería.

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 Ingeniería humana (Manejo y Administración de personal), y administración de base de datos. Objetivos del Análisis. Identificación de Necesidades. Es el primer paso del análisis del sistema, en este proceso en Analista se reúne con el cliente y/o usuario (un representante institucional, departamental o cliente particular), e identifican las metas globales , se analizan las perspectivas del cliente, sus necesidades y requerimi entos, sobre la planificación temporal y presupuestal, líneas de mercadeo y otros puntos que puedan ayudar a la identificación y desarrollo del proyecto. Algunos autores suelen llamar a esta parte ¨ Análisis de Requisitos ¨ y l o dividen en cinco partes: • Reconocimiento del problema. • Evaluación y Síntesis. • Modelado. • Especificación. • Revisión Antes de su reunión con el analista, el cliente prepara un documento conceptual del proyecto, aunque es recomendable que este se elabore durante la comunicación Cliente – analista, ya que de hacerlo el c liente solo de todas maneras tendría que ser modificado, durante la identificación de las necesidades. Estudio de Viabilidad. Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el tiempo no son realistas para su materialización sin tener pérdidas económicas y frustración profesional. La viabilidad y el análisi s de riesgos están 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 interés: 1. Viabilidad económica. Una evaluación de los costos de desarrollo, comparados con los in gresos netos o beneficios obtenidos del producto o Sistema desarrollado. 2. Viabilidad Técnica. Un estudio de funciones, rendimiento y restricciones que puedan afectar la realización de un sistema aceptable. 3. Viabilidad Legal. Es determinar cualquier posibilidad de infracción, violación o responsabilidad legal en que s e podría incurrir al desarrollar el Sistema. Alternativas. Una evaluación de los enfoques alternativos del desarrollo del producto o Sistema. 5


El estudio de la viabilidad puede documentarse como un informe a parte para la alta gerencia. Análisis Económico y Técnico. El análisis económico incluye lo que llamamos, el análisis de costos – beneficios, significa una valoración de la inversión económica comparad o con los beneficios que se obtendrán en la comercialización y utilidad del producto o sistema. Muchas veces en el desarrollo de Sistemas de Computación estos son intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la características del Sistema. El análisis de costos – beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del Proyecto. En el Análisis Técnico, el Analista evalúa los principios técnicos del Sistema y al mismo tiempo recoge información a dicional sobre el rendimiento, fiabilidad, características de mantenimiento y productividad. Los resultados obtenidos del análisis técnico son la base para determina r 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 perfectamente unas con otras.

1.1.4 DISEÑO. Especifica las características del producto terminado. Conceptos y principios: El Diseño de Sistemas se define el proceso de aplicar ciertas téc nicas y principios con el propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretación y realización física. La etapa del Diseño del Sistema encierra cuatro etapas: 1. El diseño de los datos. Trasforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarios para i mplementar el Software. 2. El Diseño Arquitectónico. Define la relación entre cada uno de los elementos estructurales del programa. 3. El Diseño 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 Diseño de procedimientos. Transforma elementos estructurales de la arquitectura del programa. L a importancia del Diseño del Software se puede definir en una sola palabra Calidad, dentro del diseño es donde se fomenta la calidad del Proyecto. El Diseño es la única manera de materializar con precisión los requerimientos del cliente. 6

Pablo Ortiz Cruz

El Diseño del Software es un proceso y un modelado a la vez. El proceso de Diseño es un conjunto de pasos repetitivos que permiten a l diseñador describir todos los aspectos del Sistema a construir. A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones técnicas: El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acumular todos los requisitos implíc itos que desea el cliente. Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el Software. El Diseño debe proporcionar una completa idea de lo que es el Softw are, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementación. Para evaluar la calidad de una presentación del diseño, se deben establecer criterios técnicos para un buen diseño como son: • Un diseño debe presentar una organización jerárquica que haga un uso inteligente del control entre los componentes del software. • El diseño debe ser modular, es decir, se debe hacer una partición lógica del Software en elementos que realicen funciones y subfu nciones específicas. • Un diseño debe contener abstracciones de datos y procedimientos. • Debe producir módulos que presenten características de funcionamiento independiente. • Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y el entorno exterior. • Debe producir un diseño usando un método que pudiera repetirse según la información obtenida durante el análisis de requisitos de Software. Estos criterios no se consiguen por casualidad. El proceso de Diseño del Software exige buena calidad a través de la aplicación de principios fundamentales de Diseño, Metodología sistemática y una revisión exhaustiva. Cuando se va a diseñar un Sistema de Computadoras se debe tener presente que el proceso de un diseño incluye, concebir y planear algo en la men te, así como hacer un dibujo o modelo o croquis. Diseño de la Salida. En este caso salida se refiere a los resultados e informaciones genera das por el Sistema, Para la mayoría de los usuarios la salida es la única razón para el desarrollo de un Sistema y la base de evaluación de su utilidad. Sin embargo cuando se realiza un sistema, como analistas deben realizar lo siguiente: • Determine que información presentar. Decidir si la información será presentada en forma visual, verbal o impresora y seleccionar el medio d e salida. 7


• Disponga la presentación de la información en un formato aceptable. • Decida cómo distribuir la salida entre los posibles destinatarios. Diseño de Archivos. Incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a emplear para guardar detalles de las transacciones, datos históricos, o información de referencia. Entre las decisiones que se toman durante el diseño de archivos, se encuentran la s siguientes: • Los datos que deben incluirse en el formato de registros contenidos en el archivo. • La longitud de cada registro, con base en las características de los datos que contenga. • La secuencia a disposición de los registros dentro del archivo (La estructura de almacenamiento que puede ser secuencial, indexada o relativa). No todos los sistemas requieren del diseño de todos los archivos, ya que la mayoría de ellos pueden utilizar los del viejo Sistema y solo tenga que enlazarse el nuevo Sistema al Archivo maestro donde se encuentran los registros. Diseño de Interacciones con la Base de Datos. La mayoría de los sistemas de información ya sean implantado en sistemas de cómputos grandes o pequeños, utilizan una base de datos que pue den abarcar varias aplicaciones, por esta razón estos sistemas utilizan u administrador de base de datos, en este caso el diseñador no construye la base de datos sino que consulta a su administrador para ponerse de acuerdo en el uso de esta en el sistema. Herramientas para el Diseño de Sistemas. Apoyan el proceso de formular las características que el sistema debe tener para satisfacer los requerimientos detectados durante las actividades de l análisis: Herramientas de especificación. Apoyan el proceso de formular las características que debe tener una aplicación, tales como entradas, Salidas, procesamiento y especificaciones de control. Muchas incluyen herramientas para crear especificaciones de datos. Herramientas para presentación. Se utilizan para describir la posición de datos, mensajes y enc abezados sobre las pantallas de las terminales, reportes y otros medios de entrada y salida. Herramientas para el desarrollo de Sistemas. Estas herramientas nos ayudan como analistas a trasladar dis eños en aplicaciones funcionales. Herramientas para Ingeniería de Software. 8

Pablo Ortiz Cruz

Apoyan el Proceso de formular diseños de Software, incluyendo procedimientos y controles, así como la documentación correspondiente. Generadores de códigos. Producen el código fuente y las aplicaciones a partir de especifica ciones funcionales bien articuladas. Herramientas para pruebas. Apoyan la fase de la evaluación de un Sistema o de partes del mismo contra las especificaciones. Incluyen facilidades para examinar la correcta operación del Sistema así como el grado de perfección alcanzado en comparación con las expectativas. La revolución del procesamiento de datos de manera computarizada, junto con las prácticas de Diseño sofisticadas están cambiando de forma dramática la manera en que se trasladan las especificaciones de Diseño d Sistemas de Información funcionales.

1 . 1 . 5 A N A L I S T A

DE

SISTEMAS.

Diseñar y desarrollar sistemas de información, recomendar mejoras para el mismo, desarrollar las especificaciones de diseño y planificar el software y hardware necesario para implantar el diseño. Realizar el proceso de clasificación e interpretación de hechos, diagnóstico de problemas y empleo de la información para desarrollar el dise ño del sistema. FUNCIONES PROPIAS DEL PUESTO • Estudiar el mercado informático en referencia a nuevos productos, tendencias y servicios del ámbito informático. • Probar y comparar nuevos equipos informáticos del mercado. • Estudiar las necesidades informáticas de los diferentes departamentos de la empresa a nivel de equipos técnicos, métodos y procedimientos informáticos. • Elaborar parte del análisis funcional, en el que define la estructura del nuevo sistema informático (equipos técnicos, métodos y procedimientos). • Planificar la implantación y puesta en marcha del sistema a nivel de recursos humanos y elementos de hardware. • Realizar presupuestos referentes a la instalación de nuevos equipos y elaborar el informe de justificación técnica y económica. • Elaborar planes de seguridad de la información y de los equipos. • Estudiar y establecer las pruebas a realizar para detectar las anomalías del sistema. • Asesorar a sus colaboradores informáticos y a los servicios interesados. • Coordinar, controlar y verificar la instalación e implantación del nuevo sistema 9


• Diseñar y desarrollar la configuración del sistema informático (de gestión, industrial). • Redactar protocolos de aplicaciones, normativas y procedimientos. • Negociar con proveedores/ as de equipos y software informático. • Puede realizar presentaciones de proyectos. HERRAMIENTAS Las herramientas o materiales de trabajo necesarios para el desarrollo de su actividad son los siguientes: Equipos y maquinaria: ordenadores, monitores, teclado, ratón, disquetera, cableado y conexiones para red, impresoras, impresoras láser, modem, sistemas de alimentación, software de base (sistema operativo: Ms-Dos, Windows, Macintosh, Linux) y software requerido para cada tipo de r ed, software de ofimática, etc. Manuales de explotación, normativa té cnica, manuales de programación (C, C++, Visual Basic, Delphi, Java, Cobol, Pascal, Oracle, HTML, etc.).

1 . 1 . 6 P R O G R A M A D O R. Un programador es un individuo que ejerce la programación, es decir, que escribe programas de computadora u ordenador. Los programadores también reciben el nombre de desarrolladores de software. En la mayoría de los países, programador es también una categoría profesional reconocida. El programador se encarga de la implementación de prototipos mediante un lenguaje de programación que pueda entender la computadora. Inicialmente, la profesión se formalizó desde el enfoque Tayloriano de la especialización de funciones en la empresa. Así, el proceso de producción de software se concibe como un conjunto de tareas altamente especializada s donde está claramente definido el papel de cada categoría profesional: • El analista tiene como cometido analizar un problema y describirlo con el propósito de ser solucionado mediante un sistema de información. • El programador cuya única función consistía en trasladar las especificaciones del analista en código ejecutable por la computadora. Dichas especificaciones se recogen en un documento denominado cuaderno de carga, medio de comunicación entre ambos. Obsérvese que esto se consideraba un trabajo mecánico y de baja cualificación. Hoy día se reconoce que este enfoque no es válido para organizar tareas de tipo intelectual, como es la producción de software. De maner a que la profesión de programador ha ido evolucionando. Las dificultades de comunicación entre analistas y programadores (un mero documento no basta para describir lo que se quiere hacer) dio origen a una categoría profesio nal intermedia, denominada analista-programador. La concepción original del programador ha desaparecido siendo sustituida por esta : la de un profesional mucho más formado y con unas funciones menos "mecánicas". La profesión de analista también ha evolucionado, surgiendo el conce pto diseñador (de software). Esto se debe a los avances de la ingeniería del 10

Pablo Ortiz Cruz

software donde se reconoce que el análisis es una actividad distint a del diseño. El análisis describe el problema (el qué hacer) mientras que el diseño describe la solución (el cómo hacerlo). En la mayoría de países industrializados esto ha dado lugar a la categoría profesional del diseñador o arquitecto del software.

1 . 1 . 7 A D M I N I S T R A D O R

DE

BASES

DE

DATOS.

El administrador de base de datos (DBA) es la persona responsable de los aspectos ambientales de una base de datos. En general esto incluye: • Recuperabilidad - Crear y probar Respaldos • Integridad - Verificar o ayudar a la verificación en la integridad de datos • Seguridad - Definir y/o implementar controles de acceso a los datos • Disponibilidad - Asegurarse del mayor tiempo de encendido • Desempeño - Asegurarse del máximo desempeño incluso con las limitaciones • Desarrollo y soporte a pruebas - Ayudar a los programadores e ingenieros a utilizar eficientemente la base de datos. El diseño lógico y físico de las base s de datos a pesar de no s er obligaciones de un administrador de bases de datos, es a veces parte del trabajo. Esa s funciones por lo general están asignadas a los analistas de bases de datos ó a los diseñadores de bases de datos. Los deberes de un administrador de bases de datos dependen de la descripción del puesto, corporación y políticas de Tecnologías de Información (TI). Por lo general se incluye recuperación d e desastres (respaldos y pruebas de respaldos), análisis de rendimiento y optimización, y algo de asistencia en el diseño de la base de datos.

1.2. CICLO

DE

V I D A C L Á S I C O

El ciclo de vida de un sistema de información está ligado al ciclo de vida del sistema de base de datos sobre el que se apoya. Al ciclo de vida de los sistemas de información también se le denomina ciclo de vida de desarrollo del software. Las etapas típicas del ciclo de vida de desarrollo del software son: planificación, recolección y análisis de los requisitos, diseño (incluyendo el diseño de la base de datos), creación de prototipos, implementación, prueba, conversión y mantenimiento. Este ciclo de vida hace énfasis en la identificación de las funcio nes que realiza la empresa y en el desarrollo de las aplicaciones que lleven a cabo estas funciones. Se dice que el ciclo de vida sigue un enfoque orientado a funciones, ya que los sistemas se ven desde el punto de vista de las funciones que llevan a cabo. Las etapas del ciclo de vida son: 1).- Planificación del proyecto o Investigación Preliminar. 2).- Definición del sistema. 11


3).4).5).6).7).-

Recolección y análisis de los requisitos. Diseño de la aplicación o del siste ma. Implementación y evaluación del sistema. Prueba de sistemas. Mantenimiento.

1.2.1 INVESTIGACIÓN PRELIMINAR. La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona. Planteamiento del Problema • Identificar los componentes, explicando las relaciones entre ellos. • Ubicar el problema dentro de un marco conceptual. • Analizar el problema desglosando en sus unidades más simples. • simplificando, eliminando la información redundante. • investigar estudios análogos consultando la literatura existente. • plantear el problema en una forma más variable para poder investigarlo.

1.2.2 DETERMINACIÓN

DE

R E Q U E R I M I E N T O S.

Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. • Cada actividad realizada siempre es parte de un entorno mayor. • El trabajo comienza estableciendo los requisitos de todos aquellos elementos importantes del sistema. • Asignando grupos con estos requisitos para integrar el sistema de cómputo. • Es esencial cuando el SW debe interrelacionarse con otros elementos SW, HW, personas, base de datos, etc.

1.2.3 DISEÑO

DEL

S I S T E M A .

Diseño del sistema: El diseño de un sistema de información produc e los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico

1.2.4 DESARROLLO

DEL

SOFTWARE.

Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, 12

Pablo Ortiz Cruz

del tiempo disponible para escribir el software y de la disponibilidad de los programadores

1.2.5 PRUEBA

DEL

S I S T E M A .

Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera 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 tamaño de la Empresa que usara el Sistema y el rie sgo asociado a su uso, puede hacerse la elección de comenzar la operación del Sistema 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 s e implanta un nuevo sistema lo aconsejable es que el viejo y el nuevo funcionen de manera simultánea o paralela con la finalidad de comparar los resultados que ambos ofrecen en su operación, además dar tiempo al personal para su entrenamiento y adaptación al nuevo Sistema. Durante el Proceso de Implantación y Prueba se deben implementar todas las estrategias posibles para garantizar que en el uso inicial del Siste ma este se encuentre libre de problemas lo cual se puede descubrir d urante este proceso y levar a cabo las correcciones de lugar para su buen funcionamiento. Desdichadamente la evaluación de Sistemas no siempre recibe la atención que merece, sin embargo cuando se lleva a cabo de mane ra adecuada proporciona muchas informaciones que pueden ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones futuras.

1.2.6 IMPLANTACIÓN

Y

EVOLUCIÓN.

La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años y la evaluación ocurre a lo largo de cualquiera de las siguientes dimensione s: Evaluación operacional, Impacto organizacional, O pinión de los administradores, Desempeño del desarrollo. Es la última fase del desarrollo de Sistemas. Es el proceso instalar equipos o Software nuevo, como resultado de un análisis y diseño p revio como resultado de la sustitución o mejoramiento de la forma de llevar a cabo un proceso automatizado. Al Implantar un Sistema de Información lo primero que debemos hacer es asegurarnos que el Sistema sea operacional o sea que funcione de acuerdo a los requerimientos del análisis y permitir que los usuarios puedan operarlo. Existen varios enfoques de Implementación: • Es darle responsabilidad a los grupos. • Uso de diferentes estrategias para el entrenamiento de los usuarios. • El Analista de Sistemas necesita ponderar la situación y proponer un plan de conversión que sea adecuado para la organización. 13


• El Analista necesita formular medidas de desempeño con las cuales evaluar a los Usuarios. • Debe Convertir físicamente el sistema de información antiguo, al nuevo modificado. En la preparación de la Implantación, aunque el Sistema este bien diseñado y desarrollado correctamente su éxito dependerá de su implantación y ejecución por lo que es importante capacitar al usuario con respecto a su uso y mantenimiento. Capacitación de Usuarios del Sistema: Es enseñar a los usuarios que se relacionan u operan en un pr oceso de implantación. La Responsabilidad de esta capacitación de los Usuarios primarios y secundarios es del Analista, desde el personal de captura de datos h asta aquellos que toman las decisiones sin usar una Computadora. No se debe incluir a personas de diferentes niveles de habilidad e intereses de trabajo; debido a que si en una Empresa existen trabajadores inexpertos no se pueden incluir en la misma sección de los expertos ya qu e ambos grupos quedaran perdidos. "Es como querer conducir dos Barcos con diferentes destinos con un mismo Mapa de rutas o con el mismo timón". Aun y cuando la Empresa puede contratar los Servicios de Instructores externos, el analista es la persona que puede ofrecer la mejor capacitación debido a que conoce el personal y al Sistema mejor que cualquier otro. A la falta o imposibilidad del analista la organización puede contratar otros servicios de capacitación como son: • Vendedores : Son aquellos que proporcionan capacitación gratuita fuera de la Empresa de uno o dos días. • Instructor pagado externamente: Son aquellos que pueden enseñar todo acerca de las computadoras pero para algunos usuarios esta no es una capacitación necesaria. • Instructores en casa: Están familiarizados con el personal y pueden adecuar los materiales a sus necesidades, pero le faltaría experiencia en Sistemas de Información que es realmente la necesidad del usuario. Objetivos de la Capacitación: Es lograr que los usuarios tengan el Dominio necesario de las cosas básicas acerca de las maquinarias y procesos que se emplean para su operación de manera eficiente y segura. La Evaluación del Sistema: Se lleva a cabo para identificar puntos débiles y fuertes del Sistema implantado. La evaluación ocurre a lo largo de cualquiera de las siguientes cuatro dimensiones: Evaluación operacional:

14

Pablo Ortiz Cruz

Es el Momento en que se evalúa la manera en que funciona el Sistema, esto incluye su facilidad de uso, Tiempo de respuesta ante una ne cesidad o proceso, como se adecuan los formatos en que se presenta la Información, contabilidad global y su nivel de Utilidad. Impacto Organizacional: Identifica y mide los beneficios operacionales para la Empresa en áreas tales como, Finanzas (Costos, Ingresos y Ganancias), eficien cia en el desempeño laboral e impacto competitivo, Impacto, rapidez y organización en el flujo de Información interna y externa. Desempeño del Desarrollo. Es la evaluación del Proceso de desarrollo adecuado tomando en cuen tas ciertos criterios como, Tiempo y esfuerzo en el desarrollo concuerden c on presupuesto y estándares y otros criterios de Administración de Proyectos. Además se incluyen la valoración de los métodos y herramientas utilizados durante el desarrollo del Sistema.

1 . 2. 7 MA N T EN I M I E NT O. Con posterioridad a la fase de implementación de los sistemas, se impone la fase de mantenimiento. El mantenimiento de sistemas es el mantenimiento continuo después de l inicio del funcionamiento. Cuando se elaboran planes para la estrategia de información, las organizaciones no pueden dejar de considerar que el mantenimient o de sistemas es la fase más prolongada y costosa del ciclo de vida de los sistemas. Las implicaciones del volumen de trabajo para mantenimie nto para los planes de estrategia de información en una organización es un tema que merece atención especial. La estructura de organización necesita flexibilidad para apoyar el mantenimiento de los sistemas existentes concurrentemente con la ejecución de nuevas tecnologías. Es importante considerar la evaluación y el monitoreo de un sistema en términos del mantenimiento necesario y, en consecuencia, reducir o contener los costos implícitos. El mantenimiento de sistemas puede clasificarse en cuatro grupos, cada uno de los cuales repercute en el pl an estratégico de información institucional de diferentes maneras: Mantenimiento correctivo. Independientemente de cuán bien di señado, desarrollado y probado está un sistema o aplicación, ocurrirán errores inevitablemente. Este tipo de mantenimiento se relaciona con la solución o la corrección de problemas del sistema. Atañe generalmente a problemas no identificados durante la fase de ejecución. Un ejemplo de mantenimien to correctivo es la falta de una característica requerida por el usuario, o su funcionamiento defectuoso. Mantenimiento para fines específicos. Este tipo de mantenimiento se refiere a la creación de características nuevas o a la adaptación de las existentes según lo requieren los cambios en la organización o los usuarios, por ejemplo, los cambios en el código tributario o los reglamento interno s de la organización. Mantenimiento para mejoras. Se trata de la extensión o el mejoramiento del desempeño del sistema, ya sea mediante el agregado de nuevas 15


características, o el cambio de las existentes. Un ejemplo de este tip o de mantenimiento es la conversión de los sistemas de texto a GUI (inte rfaz gráfica de usuarios). Mantenimiento preventivo. Este tipo de mantenimiento es probablemente uno de los más eficaces en función de los costos, ya que si se r ealiza de manera oportuna y adecuada, puede evitar serios problemas en el sistema. Un ejemplo de este mantenimiento fue la corrección del problema del año 2000.

1 . 3 A N Á L I S I S E S T R U C T U R A D O . Un sistema de información realiza cuatro actividades básicas: e ntrada, almacenamiento, procesamiento y salida de información. Entrada de Información: Es el proceso mediante el cual el S istema de Información toma los datos que requiere para procesar la información. Las entradas pueden ser manuales o automáticas. Las manuales son aquellas que se proporcionan en forma directa por el usuario, mientras que las automáticas son datos o información que provienen o son tomados de otros sistemas o módulos. Esto último se denomina interfaces automáticas. Almacenamiento de información: El almacenamiento es una de las actividades o capacidades más importantes que tiene una computadora, ya que a través de esta propiedad el sistema puede recordar la informa ción guardada en la sección o proceso anterior. Esta información suele ser almacenada en estructuras de información denominadas arch ivos. La unidad típica de almacenamiento son los discos magnéticos o discos duros, los discos flexibles o diskettes y los discos compactos (CD-ROM). Procesamiento de Información: Es la capacidad del Sistema de Información para efectuar cálculos de acuerdo con una secuencia de operaciones preestablecida. Estos cálculos pueden efectuarse con datos introd ucidos recientemente en el sistema o bien con datos que están almacenados. Esta característica de los sistemas permite la transformación de datos fuente en información que puede ser utilizada para la toma de decisiones, lo que hace posible, entre otras cosas, que un tomador de decisiones genere una proyección financiera a partir de los datos que contiene un estado de resultados o un balance general de un año base. Salida de Información: La salida es la capacidad de un Sistema de Información para sacar la información procesada o bien datos de entrada al exterior. Las unidades típicas de salida son las impresoras, term inales, diskettes, cintas magnéticas, la voz, los graficadores y los plotters, e ntre otros. Es importante aclarar que la salida de un Sistema de Informac ión puede constituir la entrada a otro Sistema de Información o módulo. En este caso, también existe una interface automática de salida. Por ejemplo, el Sistema de Control de Clientes tiene una interface automática de salida con el Sistema de Contabilidad, ya que genera las pólizas contables de los movimientos procesales de los clientes.

16

Pablo Ortiz Cruz

1.3.1 ELEMENTOS

DEL

A N Á L I S I S E S T R U C T U R A D O .

Entradas: Elementos que requiere el sistema para funcionar Proceso: Manipular, trabajar con la entrada para obtener un r esultado (técnicas, formulas, métodos etc.) Salidas: Resultado, la satisfacción de la necesidad Frontera: El límite del sistema Integración: Es la unión de los elementos del sistema y se define en base a: objetivos, metas y funciones Comunicación: Que información o datos se comunican, a quien se comunican, hacia donde y por qué medio.

1.4 TÉCNICAS

PARA ENCONTRAR

HECHOS.

Los analistas pueden emplear varios métodos para obtener, reunir y determinar los requerimientos del sistema. Entre estos tenemos:

1 . 4 . 1 EN T R E V I S T A S. Es una conversación dirigida con el propósito específico que u tiliza un formato de preguntas y respuestas. Se espera de la entrevista, obtener opiniones de los entrevistados acerca de la situación 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 quién entrevistar. - Preparar al entrevistado. - Decidir el tipo de preguntas y la estructura ( estructurada o no estructurada).

1 . 4 . 2 C U E S T I O N A R I O S. Es una técnica de recopilación de información que permite a trav és del empleo de formatos estandarizados reunir información para estudiar las actitudes, comportamientos y características de muchas persona s. Los cuestionarios pueden ser de manera rápida, los cuales deben cumplir unas directrices: - Determinar que fines se persigue con al elaboración del cuestionario. - Los tipos de preguntas que utiliza un cuestionario son : abierta y cerrada. - Elegir el lenguaje del cuestionario, implica utilizar el lenguaje que emplean los encuestados. la redacción debe ser sencilla. Uso de escalas en los cuestionarios Los analistas de sistemas emplean dos formas de escalas de medición - Escalas nominales: Se emplean para clasificar cosas ¿ Que tipo de software emplea mas? 17


1= Un procesador de texto 2= Una hoja de calculo 3= Una base de datos 4= Un programa de correo electrónico - Escalas de Intervalos: Poseen la característica de que los intervalos entre cada uno de los números son iguales. ¿ Que tan útil es el apoyo que ofrece el grupo de soporte técnico? No tiene utilidad alguna Es sumamente útil 1 2 3 4 5 Diseño de los cuestionarios: - Dejar bastante espacio en blanco - Facilitar a los encuestados que marquen con claridad sus respuestas - Mantener un estilo consistente. - Mantener lineamientos: primero colocar preguntas mas imp ortantes, agrupar los elementos de contenido similar, incorporar primero las preguntas menos polémicas.

1.4.3 REVISIÓN

DE LOS

REGISTROS.

Varios tipos de reportes y de registros pueden proporcionar al analista información valiosa con respecto a las organizaciones y a sus operaciones. Al revisar los registros, el analista examina la información asentad a en ellos relacionada con el sistema y los usuarios. La revisión puede efectuarse el comienzo del estudio, como introducción o después, esto sirve para comparar las operaciones actuales, por lo tanto los registros puede n indicar que está sucediendo. Los registros incluyen manuales de políticas, reglamentos y procedimientos estándares de operación utilizados por la mayor parte de las organizaciones como guías. Los registros no indican la forma 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 O B S E R V A C I Ó N. Por medio de la observación el analista obtiene información de primera mano sobre la forma en que se efectúan las actividades. este método es útil cuando el analista necesita observar: - La forma en que se manejan los documentos y se lleva n a cabo los procesos. - Si se siguen los pasos especificados. El método de la observación cumple unos requisitos - Sirve a un objetivo, previamente establecido - Es planificada sistemáticamente - Es controlada previamente 18

Pablo Ortiz Cruz

- Está sujeta a comprobaciones de fiabilidad y validez Etapas de la Observación: - Se plantea un objetivo - Recogida de datos: definir las variables a observar, costo en tiempo y gasto económico, decidir el muestreo de datos. - Análisis e interpretación de los datos recogidos - Elaborar conclusiones o incluso replanteamientos - Comunicación de los resultados: Informe sobre si los hallazgos son o no relevantes.

19


UNIDAD II: DISEÑO 2.1 HERRAMIENTAS

PARA D OCUMENTAR

DE

SISTEMAS

CONCEPTO

DE

DECISIÓN.

Apoyan el proceso de formular las características que el sistema debe tener para satisfacer los requerimientos detectados durante las actividades de l análisis:

2 . 1 . 1 A C C I O N E S . Herramientas de especificación. Apoyan el proceso de formular las características que debe tener una aplicación, tales como entradas, Salidas, procesamiento y especificaciones de control. Muchas incluyen herramientas para crear especificaciones de datos. Herramientas para presentación. Se utilizan para describir la posición de datos, mensajes y enc abezados sobre las pantallas de las terminales, reportes y otros medios de entrada y salida. Herramientas para el desarrollo de Sistemas. Estas herramientas nos ayudan como analistas a trasladar dis eños en aplicaciones funcionales. Herramientas para Ingeniería de Software. Apoyan el Proceso de formular diseños de Software, incluyendo procedimientos y controles, así como la documentación correspondiente. Generadores de códigos. Producen el código fuente y las aplicaciones a partir de especifica ciones funcionales bien articuladas. Herramientas para pruebas. Apoyan la fase de la evaluación de un Sistema o de partes del mismo contra las especificaciones. Incluyen facilidades para examinar la correcta operación del Sistema así como el grado de perfección alcanzado en comparación con las expectativas. La revolución del procesamiento de datos de manera computarizada, junto con las prácticas de Diseño sofisticadas está cambiando de forma dramática la manera en que se trasladan las especificaciones de Diseño de Sistemas de Información funcionales.

2 . 1 . 2 Á R B O L E S

DE

DECISIÓN.

Cuando un proceso de decisión estructurada se integra con ramificaciones complejas, entonces se hace uso de los árboles de decisiones. Los árboles de decisiones se dibujan sobre un plano horizontal, con la raíz del ár bol al lado izquierdo del papel y las ramas hacia la derecha. Esto p ermite al analista describir las condiciones de acciones sobre las ramas. Cuando se dibujan los árboles de decisiones es útil distinguir e ntre las condiciones y las acciones. Para este propósito, el uso de un nodo cuadrado 20

Pablo Ortiz Cruz

indica una acción y un círculo representa una condición, tal y como se representa en la figura 5.4.1. El uso de esta notación hace más accesible el árbol de decisiones sí uno piensa que un círculo significa IF (SI), mientras que cuadrado significa THEN (ENTONCES). El árbol de decisiones tiene tres ventajas principales sobre la tabla de decisiones: Primera, es que toma las ventajas de la estructura consecutiv a de las ramas del árbol de decisiones, de tal forma que se identifican de man era inmediata el orden de verificación 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, donde todas forman parte de la misma tabla. Tercero, al compararse con las tablas los árboles de decisiones se entienden con más facilidad en una organización y son apropiados como un método de comunicación.

2.1.3 TABLAS

DE

DECISIÓN.

Una tabla de decisiones es una tabla de renglones y columnas que contiene cuatro cuadrantes. El cuadrante superior izquierdo contiene la condición, el cuadrante superior derecho opciones a la condición. La mitad inferior de la tabla contiene las acciones que se van a tomar (en el extremo izquierdo) y las reglas para ejecutar las acciones (en el derecho). Cuando una tabla de decisiones se utiliza para determinar las acciones que se llevaron a cabo, la lógica sigue el sentido del reloj, comenzando en el extremo superior izquierdo. TABLA DE DECISIONES Condiciones y acciones Reglas Condiciones Alternativas de la condición Acciones Registro de las acciones Para construir tablas de decisión, el analista necesita definir el tamaño máximo de la tabla, eliminar cualquier situación imposible, inconsistencia o redundancia y simplificar la tabla mejor posible. Los siguientes pasos proveen al analista de un método sistemático para el desarrollo de tablas d e d e c i s i o ne s : Determine el número de condiciones que pudieran afectar la decisión. Combine renglones que se sobrepongan. El número de condiciones será igual al número de renglones presentes en la mitad superior de la tabla de decisiones. Determine el número de acciones posibles que puedan realizarse. Este será igual al número de renglones de la parte inferior de la tabla de decisiones . 21


Determine el número de opciones para cada condición. En la forma más sencilla, habrá dos alternativas (S o N) para cada condición. En una tabla de tipo extendida, puede llegar a haber muchas opcion es para cada condición.

2.2 ELEMENTOS

DEL

DISEÑO.

Al diseñar un sistema informático, se tienen en cuenta los cinco elementos fundamentales que componen el hardware: la unidad aritmético-lógica, la unidad de control, la memoria, la entrada y la salida. La unidad aritmét icológica realiza operaciones aritméticas y compara valores numéricos . La unidad de control dirige el funcionamiento de la computadora recibien do instrucciones del usuario y transformándolas en señales eléctric as que puedan ser comprendidas por los circuitos del ordenador. La combinación de la unidad aritmético-lógica y la unidad de control se denomina unidad central de procesamiento, o CPU (siglas en inglés). La memoria almacena instrucciones y datos. Las secciones de entrada y salida permiten respectivamente que la computadora reciba y envíe datos. Se necesitan arquitecturas diferentes de hardware debido a las necesidades especializadas de los distintos sistemas y usuarios. Por ejemplo, un usuario puede necesitar que su sistema muestre gráficos de forma extremadamente rápida, mientras que otro tal vez necesite buscar eficazmente en una base de datos o tener un consumo bajo de energía, como en el caso de ordenadores personales portátiles. Además del diseño del hardware, se debe considerar los sistemas operativos que harán funcionar el si stema. El software, como los lenguajes de programación y los sistemas operat ivos, hace que los detalles de la arquitectura del hardware resulten invisib les para el usuario. Por ejemplo, diferentes computadoras que em pleen el lenguaje de programación C o el sistema operativo UNIX pueden parece r iguales 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 español e inglés) es una representación gráfica del "flujo" de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es u na práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas. Este contexto a nivel de DFD se "explotó" para mostrar más detalles del sistema que se está modelando. Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador original del diseño estructurado, basado en el modelo de computación de Martin y Estrin: "flujo gráfico de datos" . Los diagramas de flujo de datos (DFD) son una de las tres perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador de un proyecto y los usuarios finales tendrán que ser informados y consultados en todas las etapas de una evolución del sistema. Con un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que el s istema funcione, lo que el sistema va a lograr, y cómo el sistema se pondrá en práctica. El antiguo sistema de diagramas de flujo de datos puede ser 22

Pablo

rtiz Cruz

elaborad y se c mparó con el nu evo siste ma de d iagramas de fluj para establecer difere cias y mejoras a aplicar ara des rrollar n sistema más eficiente. Los d agramas de flujo de d atos pu den ser usados para roporcionar al u uario fi al una i dea físic de cóm resultarán los datos a última i stancia, y cómo tienen un efecto sobre l estructura de todo el sistema. La ma era en que cu lquier istema es desa rollado puede determinarse a través de n diagrama de fl jo de da tos. El d esarrollo de un DFD ayuda en la identificación de los dato de la t ansacción en el odelo de datos.

2 . 2 . 2 A L M A C E N E

DE

D

TOS.

a integración de los da tos y de los sistemas surge com un res ultado directo e la centralización del departam nto de sistemas bajo una sola estructura admin strativa. as nuevas tecnologías relacio adas c on base de d tos, sistemas administradores de base de da os y le nguajes de cuar ta gener ación, hicieron posible l integración. En esta tapa su usuarios inician mucho a que los esperar que sus

ge la primera hoja electr ónica de cálculo omercia y los aciendo sus prop as aplic ciones. sta herramienta ayudó usuario hicieran su pr pio trab ajo y n tuvieran que propues as de sistemas fu eran cu plidas.

El costo del equi o y del software disminu ó por lo cual es uvo al alcance de más usuarios. En form paralela a los cambios tecnológi del depa tamento de Siste as de I formaci evolucio ó hacia una est uctura escentr utilizar erramie tas par el desarrollo de os usuarios y el departa sistemas, reemplazando organiza ión.

os, cam ió el ro del usuario y n. El de partame to de sis temas lizada, permitie do al u suario sistemas.

ento de sistema niciaron el desarrollo de uevos los sistemas a ntiguos, en be eficio de la

El depar amento e Siste as de Informació n recono e que la información es un recur o muy v lioso qu debe estar acces ible par todos los usuari s.

23


Para poder cumplir con lo anterior resulta necesario administrar los datos en forma apropiada, es decir, almacenarlos y mantenerl os en forma adecuada para que los usuarios puedan utilizar y compartir este recurso. El usuario de la información 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 datos e información. Pueden ser manuales o basadas en computadora.

2 . 2 . 4 P R O C E D I M I E N T O S. Métodos y rutinas para utilizar el sistema de información y lograr con ello los resultados esperados.

2.2.5 FUNCIONES

DEL

PERSONAL.

Las responsabilidades de todas las personas que tienen que ver con el nuevo sistema incluyendo los usuarios, operadores de com putadora y personal de apoyo. Abarca todo el espectro de componentes del s istema, incluso desde la entrada de datos hasta la distribución de salidas o resultados. A menudo, las funciones del personal se establecen en forma de procedimiento.

24

Pablo Ortiz Cruz

UNIDAD III: MODELADO DE SISTEMAS ORIENTADO OBJETOS

A

3 . 1 C O N C E P T O S. Hay varios conceptos que son propios de la orientación a objetos y otros inherentes a la tecnología. Aunque no todos son exclusivos de los sistemas orientados a objetos están bien apoyados por el paradigma. Orientado a Objetos: significa que el software se organi za como una colección de objetos discretos que contienen tanto estructuras d e datos como comportamiento. Identidad: Los datos están cuantificados en entidades discretas y distinguibles denominadas objetos. Cada objeto posee su propia identidad inherente. Pueden ser ejemplos de objetos, un párrafo de un documento, la reina blanca del juego de ajedrez, una silla. En otras palabras: dos objetos serán distintos aun cuando los valores de todos sus atributos (tales como el nombre y el tamaño) sean idénticos. Por ejemplo en un conjunto de 6 sillas de un mismo juego los valores de los atributos so n los mismos y cada una de las sillas tiene su propia identidad. Identificación: en el mundo real los objetos se limitan a existir, pero dentro de un entorno de computación cada objeto posee una identificación mediante la cual se puede hacer alusión a él de modo exclusivo. La identificación se puede implementar de distintas maneras que pueden ser como una dirección, un índice de una matriz, o un valor exclusivo d e un atributo. Clasificación: significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se aglutinan para formar una clase. Son ejemplos de clases: párrafo, pieza de ajedrez. Clase: Es una abstracción que describe propiedades importantes para una aplicación y que ignora el resto. La selección de clases es arbitraria y depende de la aplicación. Una clase contienen el molde (estructura, esquema) a partir del cual se crean los objetos que pertenecen a ella y el código que debe ejecutarse cada vez que un objeto de la clase re cibe un mensaje. Una clase contiene la descripción de las características comunes de todos los objetos que pertenecen a ella: la especificación del comportamiento, la definición de la estructura interna y la implementación de los métodos. Instancia: se dice que cada objeto es una instancia de su clase. Toda clase describe un conjunto posiblemente finito de objetos individuale s. Toda instancia de la clase posee su propio valor para cada uno de los atributo s pero comparte los nombres de los atributos y las operaciones con las demás instancias de la clase. Todo objeto contiene una referencia implícita a su propia clase; ‘‘sabe la clase de cosa que es’’. Los objetos contienen los valores de los atributos (que lo distinguen de otros objetos) y una identidad.

25


3.1.1 MODELADO. El Modelado y Diseño Orientado a Objetos se funda en pensar acerca de problemas a resolver empleando modelos que se han organizado tomando como base conceptos del mundo real. La unidad básica es el ob jeto que combina las estructuras de datos con los comportamientos en una entidad única. La Metodología OMT se extiende desde el análisis hasta la implementación pasando por el diseño. En primer lugar, se construye un modelo de análisis para abstraer los aspectos esenciales del dominio de la aplicación sin tener en cuenta la implementación eventual. En este modelo se toman decisiones importantes que después se completan para optimizar la implementación en segundo lugar. Los objetos del dominio de la aplicación cons tituyen el marco de trabajo del modelo de diseño, pero se implementan en términos de objetos del dominio de la computadora. Por último, el modelo de diseño se implementa en algún lenguaje de programación, base de datos o hardware.

3.1.2 MODELADO

DE

OBJETOS.

Un modelo es una abstracción de algo, cuyo objetivo es comprenderlo antes de construirlo. Dado que los modelos omiten los detalles no esenciales es más sencillo manipularlos que manipular la entidad original. La abstracción permite enfrentarse a la complejidad. Los ingenieros, artistas y artesanos han estado construyendo modelos durante miles de años para probar los diseños antes de ejecutarlos. El desarrollo de sistemas hardware y software no es una excepción. Para construir sistemas co mplejos, el desarrollador debe abstraer distintas vistas del sistema, construir modelos utilizando notaciones precisas, verificar que los modelos satisfa cen los requisitos del sistema y añadir, gradualmente, detalles para transformar los modelos en una implementación. Los modelos tienen varios objetivos: • Probar una entidad física antes de construirla • Comunicación con el cliente • Visualización del conjunto • Reducción de la complejidad La abstracción es el examen selectivo de ciertos aspectos de un problema. Su finalidad es aislar aquellos aspectos que sean importantes para algú n objetivo y suprimir los aspectos que no lo sean. La abstracción siempre debe de hacerse con algún objetivo prefijado, porque el propósito determina lo que es y no es importante. Es posible efectuar muchas abst racciones diferentes de la misma cosa, dependiendo del propósito para el cual se hagan esas abstracciones. Todas las abstracciones son incompletas e imprecisas. La realidad es una red sin costuras. Todo lo que digamos acerca de ella, cualquier descripción, será una versión reducida. Todas las palabras y lenguajes humanos son abstracciones, descripciones incompletas del mundo real. Esto no elimina su utilidad. El propósito de una abstracción es limitar al universo para que podamos hacer cosas. Al construir modelos, por tanto, no debe uno buscar la verdad absoluta, sino su adecuación para algún propósito. No exist e un 26

Pablo Ortiz Cruz

único modelo ‘‘correcto’’ de una situación, solo existen modelos adecuados o inadecuados. Un buen modelo captura los aspectos cruciales del problema y omite los demás. La metodología 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 Dinámico que describe las interacciones existen tes entre objetos del sistema; y el Modelo Funcional que describe las transformaciones de datos del sistema. Todos los modelos son aplicables en la totalidad de las fases del desarrollo y van adquiriendo detalles de implementación a medida que progresa el desarrollo.

3.1.3 MODELO DINÁMICO. Describe los aspectos de comportamiento (de control) de un sistema que cambian con el tiempo. El modelo dinámico se utiliza para especific ar e implementar los aspectos del control del sistema. Los modelos dinámico s contienen diagramas de estados. 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 este modelo la temporización y secuencia de operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados que definen el contexto para los sucesos), y la organización de suceso s y de estados. El modelo dinámico captura el control, aquel aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en la que estén 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 modelo de objetos.

3.1.4 MODELO FUNCIONAL. Describe las transformaciones (de función), de valores de datos que ocurren dentro del sistema, captura lo que hace el sistema, independientemente de cuando se haga 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 cálculo de valores de salida a partir de los de entrada y de funciones, sin considerar cuando se ejecutan las funciones, ni siquiera si llegan a ejecutarse. Las funciones se invocan como acciones en el modelo dinámico y se muestran como operaciones que afectan a objetos en el modelo de objetos.

3.2 DESCRIPCIÓN

DE

MODELOS

DE

OBJETOS.

Una descripción completa del sistema requiere los tres modelos. Un procedimiento típico de software contiene estos tres aspectos: • utiliza estructuras de datos (modelo de objetos), • secuencia las operaciones en el tiempo (modelo dinámico) y • transforma valores (modelo funcional). Cada modelo referencia a entidades de los otros modelos, los tres modelos están relacionados entre si. Las interconexiones entre los distintos modelos 27


son limitadas y explícitas. Los buenos diseños aíslan los distintos aspectos del sistema y limitan el acoplamiento entre ellos. El más importante es el modelo de objetos porque es necesario para describir ‘‘qué’’ está cambiando o transformándose, antes de describir ‘‘cuándo’’ y ‘‘cómo’’ cambia. El enfoque orientado a obje tos se centra primordialmente en identificar objetos procedentes del domini o de la aplicación ajustándoles después los procedimientos. Soporta me jor las evoluciones de los requisitos porque está basado en el entorno subyacente del dominio de la aplicación en sí, más que en los requ isitos funcionales adhoc de un único problema.

3 . 2 . 1 S I M B O L O G Í A . PAQUETES: Permiten dividir un modelo, reagrupar y encapsular los elementos de modelado y se representa con una carpeta con nombre. Gráficamente un paquete viene representado como se indica en la Figura:

 Cualquier sistema grande se debe dividir en unidades más pequeñas, de modo que las personas puedan trabajar con una cantidad de informació n limitada, a la vez y de modo que los equipos de trabajo no inte rfieran con el trabajo de los otros. Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado. Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema). Los paquetes son unidades de organización jerárquica de uso general de los modelos de UML. Pueden ser utilizados para el almacenamiento, el control de acceso, la gestión de la configuración y la construcción de bibli otecas que contengan fragmentos reutilizables del modelo. CASOS DE USO: Un Caso de Uso es representado por una elipse y es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una t area específica. Representan la funcionalidad del sistema y los requisitos del sistema desde la perspectiva del usuario. Los objetivos de los casos d e uso son los siguientes: • Capturar los requisitos funcionales del sistema y expresarlos desde el punto de vista del usuario. • Guiar todo el proceso de desarrol lo del sistema de información. Los casos de uso proporcionan, por tanto, un modo claro y preciso de comunicación entre cliente y desarrollador. Desde el punto de vista del cliente proporcionan una visión de “caja negra” del sistema, esto es, cómo aparece el sistema desde el exterior sin necesidad de entrar en los detalles de su construcción. 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 análisis y diseño. ACTORES: Un actor es una entidad externa al sistema que realiza algún tipo de interacción con el mismo. Se representa mediante una figura humana dibujada con palotes.  28

Pablo Ortiz Cruz

Esta representación sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.). Si se habla de usuarios, un actor es el papel que puede llevar a cabo en cuanto a su forma de interactuar con el sistema, es decir, un único a ctor puede representar a muchos usuarios diferentes y de la misma forma, un usuario puede actuar como actores diferentes. RELACIONES: Las relaciones pueden tener lugar entre actores y casos de uso o entre casos de uso. La relación entre un actor y un caso de uso es una relación de comunicación, que indica que un actor interviene en el caso de uso. Normalmente, el actor aporta información para la realización de un caso de uso o recibe información como resultado de la re alización del mismo, por ello, esta relación puede ser unidireccional o bid ireccional, aunque generalmente se muestra como bidireccional, ya que no es necesario especificar en detalle estas relaciones. La relación entre casos de uso es una relación unidireccional. Esta relación puede presentar uno de los dos siguientes tipos: “usa” y “extiende”.

3.2.2 IDENTIFICACIÓN

DE

OBJETOS

Y CLASES.

OBJETOS: Es la representación de una entidad sea real o conceptual. Un objeto puede representar algo concreto (una persona, un auto, una computadora, etc.), o un concepto (un proceso químico, una tra nsacción bancaria, una orden de compra, etc.). Un objeto tiene tres características: a. Estado: Representado por una colección de propiedades o atributos, por ejemplo el objeto Curso puede estar en uno de dos estados: “Abierto” o “Cerrado”. b. Conducta: Representa todo lo que el objeto puede hacer (Operaciones), por ejemplo un curso disponible podría tener las operaciones: AgregarEstudiante() y EliminarEstudiante() c. Identidad: Representa la unicidad de un objeto con respecto a otros objetos, por ejemplo: Matemática 001- Sección 1 y Matemática 001 Sección 2 son dos objetos del Sistema de Registro Curso. Aunque ambos cursos están disponibles, cada uno tiene una única identidad. En uml, los objetos son representados con rectángulos y el no mbre del objeto es subrayado. CLASES: es una descripción de un grupo de objetos la cual consta de: propiedades comunes (los atributos), conductas comunes(los funcionamientos), relaciones comunes y semántica común. Así una clase es una plantilla para crear objetos. Cada objeto es una instancia de al guna clase u objeto. Por ejemplo, la clase “Curso Disponible” puede definirse con las siguientes características: a. Atributos: ubicación, horas disponibles. b. .Operaciones: recuperar ubicación, recuperar horas al día, agregar estudiante. Así: Matemática 001 – Sección 1 y Matemática 001 – Sección 2 son objetos pertenecientes a la clase “Curso Disponible”. Cada objeto debería tener valores para sus atributos y acceso a las operaciones especificadas en la clase “Curso Disponible”. 29

nálisis y Dis ño de Sistemas.

En UML, las clas s se representan con rect ngulos d ivididos en tres partes.

3.2.3 OPERACIÓ , MÉTO

OS,

A S O C I A C I O N E S

Y

MU LTIPLICIDAD.

as ope aciones son los procesos que u na clas sabe levar a cabo. Evidentemente, c rrespon en a los métodos sobre u a clase. En el ni vel de especific ción, las operac ones corresponde n a los métodos públicos sobre un tipo. En general, no se muestr n aquell as opera iones q e simplemente manipul n atributos, ya que por lo común, se puede n inferir . Sin embargo, tal vez sea necesario indicar si un atribut dado e de sólo lectura o está nmutable congel do (esto es, que su valor nunca c mbia). En el modelo de mpleme tación, se podrí n mostrar también las operacio es priv das y rotegid s. a sinta is del U

L comp eta para las oper aciones e s

isibilid d nombre (lista-de-parám tros) : e xpresión-tipo-de- ato-a-regresar {cadena- e-propiedades} . donde •visibili ad es +

public), # (protected), o- ( private)

•nombre es una c dena de caracteres (strin ) •lista-de-parámetros cont ene arg mentos misma q e la de los atributos •expresi n-tipo-de-dato-a-regresar dependiente del l nguaje

es

opcionales) cuya sintaxis, es la una

es pecificación

•cadena-de-propi dades i dica valores de propied d que s operació dada n ejem lo de operación sería: + Cantidad

opcional

aplica

a la

ItimaCa ntidadDe (valorT poFenómeno) :

Dentro de los m delos conceptuales, las peraciones no d ben tra ar de especific r la interfaz de una clase. En lu gar de e lo, debe án indic ar las rincipales responsabilid des de dicha cl se, usa do tal ez un ar de alabras que sinteticen un a responsabilida de CRC. Con frecuencia encuentro útil hacer la dist nción entre aquellas operacio es que cambian el estado de una c lase y a uellas q e no lo hacen. na consulta es una operación que obtien un valor de un clase s n que ambie e estado observable de tal clase. E estado observab e de un objeto es el est do que se puede etermin r a part r de sus consultas asocia as. Considérese un objeto de Cuenta que calc ula su b alance a partir e una ista de entradas. Para mejorar e desemp eño, Cue nta pue e poner en un ampo c ché el resultado del cálc lo del b alance, ara consultas futuras. Por tant , si el c ché está vacío, la primera vez que se llama a la ope ración "balance", pondrá el resu tado en el camp caché. La oper ción "balance" 30

Pablo Ortiz Cruz

cambia así el estado real del objeto Cuenta, pero no su estado observable, pues todas las consultas devuelven el mismo valor, esté o no lleno el campo caché. Las operaciones que sí cambian el estado observable de un objeto se llaman modificadores. Considero útil tener perfectamente clara la diferencia entre consulta s y modificadores. Las consultas se pueden ejecutar en cualquier orden, pero la secuencia de los modificadores es más importante. Yo tengo como política evitar que los modificadores devuelvan valores, con el fin de mantenerlo s separados. Otros términos que algunas veces se presentan son: métodos de obtención y métodos de establecimiento. El método de obtención (getting) es un método que devuelve el valor de un campo (sin hacer nada más). El m étodo de establecimiento (setting) pone un valor en un campo (y nada más). Desde afuera, el cliente no debe poder saber si una consulta es un método de obtención ni si un modificador es un método de e stablecimiento. El conocimiento sobre los métodos de obtención y establecimiento está contenido completamente dentro de la clase. Otra distinción es la que se da entre operación y método. Una operación es algo que se invoca sobre un objeto (la llamada de procedimiento), mientras que un método es el cuerpo del procedimiento. Los dos so n diferentes cuando se tiene polimorfismo. Si se tiene un supertipo con tres subti pos, cada uno de los cuales suplanta la operación "foo" del supertipo, entonces lo que hay es una operación y cuatro métodos que la implementan. Es muy común que operación y método se empleen indistintamente, per o hay veces en que es necesario precisar la diferencia. En algunas ocasiones, la gente distingue entre una y otro mediante los términos llamada a un método, o declaración de método (en lugar de operación), y cuerpo del método. Los lenguajes tienen sus propias convenciones para los nombres. En C ++, las operaciones se llaman funciones miembro; En Smalltalk, operaciones de métodos. C ++ también emplea el término miembros de una clas e para denominar las operaciones y métodos de una clase. Son los medios para establecer relaciones entre objetos y clases, un enlace es una conexión física o conceptual entre instancias de objetos, matemáticamente se define como un ente ordenado de instancias de objetos, un enlace es una instancia de una asociación, esta describe un grup o de enlaces con estructura y semántica comunes, las asociaciones describen un conjunto de enlaces potenciales, del mismo modo que las clases describe n un conjunto de objetos potenciales, y suelen implementarse en los lenguajes de programación como punteros que van de un objeto a otro. La notac ión para las asociaciones es una línea entre clases, y los enlaces es una lín ea entre objetos, el nombre de la asociación se pone en cursiva. Limita el número de objetos relacionados, los diagramas de objetos lo indican mediante símbolos al final de la línea de asociación, subestimar la multiplicidad puede evitar la flexibilidad de una aplicación, una subestimación de la misma impone gastos adicionales extraordinarios.

3 . 2 . 4 A T R I B U T O

DE

ENLACE CLASIFICACIÓN 31

Y

A G R E G A C I Ó N .


Un atributo de un enlace es una propiedad de los enlaces de una asociación. Todo atributo de enlace tiene un valor para cada enlace. Rol Es un nombre que identifica en forma única un extremo de la asociación, el uso de nombres de rol proporciona una forma de recorrer las asociaciones desde un objeto de un extremo sin mencionar explícitamente la asociación, los roles pueden aparecer como sustantivos en la descripción del problema. Clasificación Normalmente los objetos del lado muchosen una asociación no tienen un orden explícito y se pueden considerar como un conjunto, la clasificación es una parte inherente de la asociación, si es un conjunto ordenado de objetos se escribe ordenado o clasificado al lado del símbolo de multiplicidad. Cualificación Una asociación cualificada relaciona dos clases de objetos y una cualificada, este es un atributo especial que reduce l a multiplicidad efectiva de una asociación, las asociaciones 1 a N o N a M pueden ser cualificadas, las cuales también se pueden considerar como una forma d e asociación ternaria. Agrupación Es una forma fuerte de asociación, los componentes de algo se asocian a un objeto que representa el ensamblaje completo. La agrupación es una forma especial de asociación, no un conceptoindependiente, si dos objetos est án acoplados mediante una relación todo – parte se trata de una agrupación, si los dos objetos suelen considerarse independientes entonces se trata de una asociación; entre las pruebas distintivas se incluye: 1.Utilizaría Ud. la frase "parte – de". 2.Hay algunas operaciones (del todo) que se aplican automáticamente a las partes. 3.Hay algunos valores de atributos (del todo), que se propagan del todo a todas las partes o a algunas de ellas. 4.Existe una asimetría intrínseca de la asociación de tal modo q ue una clase de objeto sea subclase de otra. Arbol de agrupación Es una notación taquigráfica que resulta mucho más sencilla de dibujar que muchas líneas que contienen los componentes para formar un ensamblado. Agregados recursivos Una agregación puede ser fija, variable o recursiva, los ag regadosfijos tienen una estructura fija que será el número y tipo de las partes componentes que están predeterminadas, los agregados variablestienen un número finito de niveles, pero el número de partes puede variar, los agregados recursivos contienen directa o indirectamente una instancia de esa misma clase de agregado, el número de niveles es ilimitado, la for ma 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 agregado Generalización y herencia Son potentes abstracciones para compartir similitudes entre clases al mismo tiempoque se mantienen sus diferencias, la generalización es la relación entre una clase y una o más reuniones de esa misma clas e que conecta a la superclase con sus subclases, la leyenda a la par del triángulo son discriminadores que indica que propiedad del objeto está siendo abstraído por una relación de generalización en particular. La herencia ha llegado a ser un sinónimo de reutilización del códigodentro de la programación orientada a objeto, frecuentemente hay un código que está disponible de trabajos anteriores ( biblioteca), la a plicación más importante es la simplificación conceptual que proviene de reducir el número de características independientes dentro del sistema. La generalización y especialización son dos puntos de vistas distintos, la primera proviene del hecho de que la superclase generaliza a la subclase y la segunda hace alusión al hecho de que la subclase especializa a la superclase, una subclase puede anular una característica de una superclase definiendo una característica del mismo nombre, se hace para obtener un mejor rendimiento. Herencia múltiple Permite que una clase tenga más de una superclase y que herede características de todas ellas, esto permite mezclar informaciónprocedente de dos o más fuentes, una clase con más de una superclase se de nomina clase unión. Módulo Es una construcción lógica para agrupar clases, asociaciones y generalizaciones, sus límites son ligeramente arbitrarios y son materia opinable, el nombre del módulo de be especificarse en la parte superior d e la hoja, los módulos nos permiten descomponer al modelo e n segmentos manejables. Hojas Una hoja es el mecanismo para descomponer un modelo de objetos grande, en un conjunto de páginas; por lo general no pondremos más de un módulo por folio, una hoja es una notación có moda, no una estructura lógica. Clases abstractas Es una clase que no tiene instancias directas, en cambio una clase concreta puede unir instancias discretas, una clase concreta puede formar subclases abstractas. Metadatos Son datos que describen datos, por ejemplo: La definición de clase s, los módulos, los planos, etc. Claves candidatas 33

nálisis y Dis ño de Sistemas.

Es un c njunto ínimo e atributos que definen de manera unívoca un objeto. Una clase puede tener más de una c lave candidata, cada una de las uales tendrá dis intas co binacio es y nú ero de a tributos. a etiqu ta de un objeto es siempre una cl ve candidata de na clase, para as asociaciones son clave s candid tas una o más c mbinaci nes de o bjetos relacion dos.

3.3 DES

RIPCIÓ

DEL

M

DELO

D

NÁMICO .

odelo Dinámico os aspectos del ambios constitu del modelado din (valores de los ob

sistema que está relacionados con los tie mpos y con los en lo m delos dinámicos, los con eptos m s importantes mico so : Los re ursos (e stímulos externos) y los estados etos).

Escenari : Es u a secuencia de sucesos que se produce ejecución comple a de un sistema, el amb iente pu ede incl sucesos o solo a aquellos ue afect n a alg nos obje tos del s siguiente a la escritura de un esce ario con siste en identific emisores y receptores de cada suceso. Los o bjetos q e interc se pueden mostrar en un ambiente m ejorado llamado segmentos de trazos de su esos.

durante una ir a todos los stema, el paso r a los o bjetos mbian sucesos diagra a de

ctivida : Es una operación cuya realiza ión req iere un cierto t empo, toda actividad sta aso iada a un est do; ent re las ctividades se encuentran las peraciones continuas, u n estado puede controlar una activida continua, la cual persiste hasta ue se pr oduce u suceso que le da fin, p oducien o una tr nsición que sale de ese es tado cción: s una peración instantánea qu va aso iada a un suces o, las acciones también pueden r epresentar opera iones in ternas d control, tales omo dar un valo a un at ibuto o enerar tros sucesos, est s acciones son mecanis os para estructu ar el co trol den ro de un a implementación.

3.3.1 SI

B O L O G Í A .

El modelo dinámico del si tema que repres nta los aspectos tempora es, de omportamiento y de control de un sistema (de gran ayuda cuando Se tienen sistemas en tie po real o siste as orie tados a eventos, en do de la realización de un a afecta el comp rtamiento global del sistema). Describe as interacciones entre los objetos en el sis tema. Es usado para espe ificar e implementar los aspecto de cont rol del si stema. C onsiste e n un dia grama 34

Pablo

de estados que es un grafo cuyos transiciones caus das por eventos.

nodos

son

estados

y

los

rtiz Cruz

arcos

son

El mod lo funcional d l siste a, que repres nta los aspectos de transfor ación los datos de función de u n sistema. Consiste en un grafo uyos no os son procesos arcos s n flujos de datos, dicho g afo es ll amado diagram de flujo de datos. La figura 5.3 uestra os símbolos usados por este modelo.

os mod los no on inde endient s entre sí, mas bien, el objetivo de la metodología es m ntener una relac ón entre ellos de tal forma que se n una estructura que permita avanzar consistent mente y que si na cambia sea fácil el cambiar la siguiente. Así e l modelo de objet os descr be estructuras de datos que los odelos inámico y funcio nal utili an. Las operacio es en el modelo de ob etos corresponden a eve ntos en el modelo diná ico y funcione en el modelo funcional. El modelo dinámico describe la estr ctura de contr l de los objetos ostrand decisio es que ependen de los valores de los ob etos en n instante dado. El mode o funcio nal desc ribe fun iones i vocadas por ope raciones en el modelo de objetos y accio es en el modelo dinámic . Las funciones peran sobre valores de atos esp cificado por el odelo de objetos.

3.3.2 SUCESOS Sucesos

Y

ESTADOS.

enlaces

Estados: Son los alores d los atributos y e los enl aces ma tenidos objeto, un diagrama de estado es una redd e estado s y recu sos, el 35

or un odelo


dinámico consta de múltiples diagramas de estado, cada uno de ellos para cada clase que contenga un comportamiento dinámico importante y muestre la actividad del sistema. Suceso: Es algo que transcurre durante un período de tiempo (ej. "el vuelo 341 sale a Córdoba"); dos sucesos que no tienen relac ión causal son concurrentes, no tienen efecto entre sí, un suceso es una transmisión de información de dirección única entre un objeto y otro. Todo suceso se agrupa en clases a los que se les da un nombre par a una comodidad de estructura (jerárquica) y de comportamiento, todo suceso aporta información de un objeto a otro, los valores de los datos aportado s son sus atributos.

3 . 3 . 3 E S C E N A R I O S. Es una secuencia de sucesos que se producen durante una ejecución completa de un sistema, el ambiente puede incluir a todos los sucesos o solo a aquellos que afecten a algunos objetos del sistema, el paso siguiente a la escritura de un escenario consiste en identificar a los objetos emisor es y receptores de cada suceso. Los objetos que intercambian sucesos se pueden mostrar en un ambiente mejorado llamado diagrama de segmentos de trazos de sucesos. Actividad: Es una operación cuya realización requiere un cierto t iempo, toda actividad esta asociada a un estado; entre las actividades se encuentran las operaciones continuas, un estado puede cont rolar una actividad continua, la cual persiste hasta que se produce un suceso que le da fin, produciendo una transición que sale de ese estado Acción: Es una operación instantánea que va asociada a un suc eso, las acciones también pueden representar operaciones internas de control, tales como dar un valor a un atributo o generar otros sucesos, estas acciones son mecanismos para estructurar el control dentro de una implementación.

3.3.4 DIAGRAMAS

DE

ESTADO.

Los sucesos se pueden representar como operaciones en el modelo de objeto. Un solo objeto puede tener distintos estados a lo largo del tiempo, pero no puede tener distintas clases. Las diferencias inherentes entre objetos so n modelados correctamente como clases distintas, mie ntras que las diferencias temporales son modelados correctamente como distintos estados entre los miembros de una misma clase. Algunos consejos: 1. Solo hay que construir diagramas de estados para las clases que tengan un comportamiento dinámico. 2. Para comenzar la construcción del diagrama de estado hay que utilizar escenarios como ayuda. 3. Solo hay que considerar los atributos relevantes 4. Solo hay que dejar que la aplicación distinga acciones y actividades. 5. Cuando un estado tiene múltiples transiciones entrantes y todas hacen que se produzca una misma acción, hay que poner las acciones dentro 36

Pablo Ortiz Cruz

de cuadros de estados, anteponiendo el suceso de entrada en lugar de enumerarlas en arcos de transición (lo mismo para los sucesos de salida). 6. Intente hacer que los diagramas de estado de las subclases sean independientes de los diagramas de estados de sus supercla ses, estas deberían concentrarse en los atributos exclusivos de esas subclases.

3.3.5 CONDICIONES

Y

OPERACIONES.

Una operación es una función o transformación que puede ser aplicada por los objetos de una clase, todos los objetos de una clase comparten las mismas operaciones y una misma operación puede aplicarse a clases distintas, cada operación es polimórfica, es decir que una misma operación 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 diagrama de estado es una red de estados y recursos, el modelo dinámico consta de múltiples diagramas de estado, cada uno de ellos para cada clase que contenga un comportamiento dinámico importante y muestre la actividad del sistema.

3.4 DESCRIPCIÓN

DEL

MODELO FUNCIONAL.

Describe las transformaciones (de función), de valores de datos que ocurren dentro del sistema, captura lo que hace el sistema, independientemente de cuando se haga 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 cálculo de valores de salida a partir de los de entrada y de funciones, sin considerar cuando se ejecutan las funciones, ni siquiera si llegan a ejecutarse. Las funciones se invocan como acciones en el modelo dinámico y se muestran como operaciones que afectan a objetos en el modelo de objetos.

3 . 4 . 1 S I M B O L O G Í A . Muestra la forma en la que se derivan los valores producidos en un cálculo a partir de los valores introducidos, sin tener en cuenta el orden en que se calculan, consta de múltiples DFD que muestran el flujo de valores desde las entradas externas a través de las operaciones y almacenes hasta las salidas externas, las DB suelen tener un modelo funcional no importante. DFD: Muestra las relaciones funcionales entre los valores calculados por un sistema incluyendo los valores introducidos, los obtenidos y los almacenes internos de datos. Un DFD contiene procesos que transforman datos, flujos de datos, objetos actores que producen y consumen datos y almacenes de datos que los almacenan en forma pasiva. Procesos: Transforma valores de datos, los de bajo nivel son funciones puras sin efectos laterales, un gráfico completo e un flujo de datos es un proceso de alto nivel y pueden tener efectos laterales como almacenes de datos de objetos externos. Flujo de datos: Conecta la salida de un objeto o proceso con la entrada d e otro objeto o proceso, se dibuja como flechas entre el productor y el 37


consumidor (de valores de datos). La flecha esta rotulada con una descripción de los datos. Gráficamente: dos líneas paralelas y un nombre. Flujo de control: Un diagrama de flujo de control muestra todas las posibles vías de computación para los valores, no muestra cuales son las vías que se ejecutan ni en qué orden, se muestran con una línea discontinua que va de un proceso que produce un valor hasta el que se está controlando.

3.4.2 DIAGRAMA

DE

HOJA

DE

DATOS.

Una hoja es el mecanismo para descomponer un modelo de objetos grande, en un conjunto de páginas; por lo general no pondremos más de un módulo por folio, una hoja es una notación cómoda, no una estructura lógica.

3.4.3 FLUJO

DE

D A T O S , A C T O R E S

Y

A L M A C É N

DE

DATOS.

Actores: Es un objeto activo que controla el gráfico de flujo de datos produciendo o consumiendo valores, están asociados a las entradas y a las salidas del gráfico de flujo de datos, se denominan también terminador. Almacén de datos: Es un objeto pasivo dentro de un DFD, a diferencia de los actores no genera ninguna operación 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 vías de computación para los valores, no muestra cuales son las vías que se ejecutan ni en qué orden, se muestran con una línea discontinua que va de un proceso que produce un valor hasta el que se está controlando.

38

Analisis y diseño de sistemas

Recommend Documents