GUÍA DE ESTUDIO MODULAR TÉCNICA DE ANÁLISIS DE DISEÑO …

INSTITUTO TECNOLÓGICO SUPERIOR “DAVID AUSUBEL”

SEMIPRESENCIAL

VICERRECTORADO ACADÉMICO

GUÍA DE ESTUDIO MODULAR

TÉCNICA DE ANÁLISIS DE

DISEÑO DE SOFTWARE

CUARTO NIVEL

TECNOLOGÍA EN:

INFORMÁTICA MENCIÓN: ANÁLISIS DE

SISTEMAS

AUTOR: ING. MARCO MOLINA ÁLVAREZ

Corrección: Comisión de Redacción

Aprobado: Vicerrectorado Académico

Edición: Instituto Superior Tecnológico “David Ausubel”

PERÍODO: Octubre 2015 – abril 2016

QUITO - ECUADOR


SEMIPRESENCIAL


PARA USTED APRECIADO ESTUDIANTE

NO OLVIDE QUE EL ESFUERZO Y LA PERSEVERANCIA MÁS EL ESTUDIAR

Y TRABAJAR ENGRANDECE AL SER HUMANO. Y USTED DEPENDE EL

ENGRANDECERSE

El Instituto Tecnológico Superior “David Ausubel”, da la bienvenida a este

su módulo de Técnicas de Análisis de Diseño de Software y espera que el

desarrollo del mismo aporte para su vida profesional.


SEMIPRESENCIAL


NOTA:

EN ESTE TEXTO GUIA SE ENCUENTRAN DESARROLLADOS LOS TEMAS QUE

CORRESPONDEN A ESTE MÓDULO, Y LAS TAREAS QUE USTED DEBE DESARROLLAR; Y

CON LA AYUDA DEL TUTOR USTED LLEGARÁ A DOMINAR EL CONOCIMIENTO.

1. EL ESTUDIANTE TIENE LAS OPORTUNIDADES QUE SEAN NECESARIAS PARA

ACLARAR LOS TEMAS QUE NO COMPRENDA MEDIANTE LA EXPLICACIÓN DEL

TUTOR YA SEA DE MANERA PRESENCIAL O MEDIANTE EL CORREO ELECTRONICO.

2. LAS TAREAS SERAN ENVIADAS POR EL TUTOR, DE ACUERDO A LAS FECHAS DEL

CALENDARIO Y DE ACUERDO AL DESARROLLO DEL MÓDULO.

3. ES OBLIGACION DEL ESTUDIANTE ASISTIR A CADA UNA DE LAS TUTORÍAS

PRESENCIALES PROGRAMADAS EN EL CALENDARIO DE ACTIVIDADES.

4. TODO TRABAJO DEL ESTUDIANTE SERÁ EVALUADO CUANTITATIVAMENTE.

5. AL FINAL EL TUTOR EVALUARA EL MÓDULO EN SU TOTALIDAD.

6. DE REQUERIR CUALQUIER INFORMACION DIRIGIRSE AL CORREO DE LA

DIRECCION ACADEMICA Y SERA ATENDIDO INMEDIATAMENTE EN SU CONSULTA.

Docente: Geovanny Paucar [email protected]

[email protected]

Gracias por su confianza.

mailto:[email protected]

mailto:[email protected]


SEMIPRESENCIAL


1. PERFIL DE INFORMÁTICA MENCIÓN ANÁLISIS DE SISTEMAS

a) OBJETIVO DE FORMACIÓN INTEGRAL DEL PROFESIONAL

Demostrar en el desempeño profesional de la informática un comportamiento ético que se

evidencie en el interés por la investigación e innovación tecnológica, con responsabilidad social,

espíritu empresarial y compromiso con el desarrollo sostenido y sustentable del país.

b) PERFIL DEL TECNÓLOGO EN INFORMÁTICA

Es un profesional capaz de usar herramientas y técnicas para recolectar datos, analizar,

diseñar, desarrollar e implementar nuevos sistemas que permitan automatizar los

procedimientos de las empresas con fundamentos científicos, tecnológicos, humanísticos

y de gestión, demostrando sólidos valores ético-morales.

c) COMPETENCIAS PRINCIPALES POR DESARROLLAR

Conducir el ciclo de vida de un sistema de información que permita automatizar el

manejo de los datos mediante un sistema de computadora, utilizando para ello las

diferentes herramientas informáticas existentes en el medio actual.

Fundamentar cambios en la estructura organizacional, procedimientos, políticas y

funciones de una entidad que permitan optimizar el flujo de datos e información,

aumentando con ello la productividad y competitividad y disminuyendo los costos

operativos.

Administrar las acciones para realizar un correcto análisis, diseño, desarrollo y

documentación de los sistemas informáticos de un centro de cómputo, que cubran

las expectativas de la institución y del medio en que se desenvuelve.

Evaluar y seleccionar hardware y software, fundamentado en cuadros

comparativos técnicos que permitan satisfacer los requerimientos de las empresas

y organizaciones en general.

Analizar de manera independiente e imparcial las bondades o defectos de un

sistema de información, mediante la valoración de todos los procesos que

intervienen, tomando en cuenta las necesidades y el presupuesto económico.

Apoyar la toma de decisiones de la gerencia utilizando métodos matemáticos,

estadísticos, modelos de transporte y de investigación de operaciones.


SEMIPRESENCIAL


SISTEMATIZACIÓN DE LAS COMPETENCIAS POR NIVELES

d) NIVEL COMPETENCIA PRINCIPAL

Instalar, operar y administrar programas utilitarios conociendo todos los principios

de la informática.

Programar en lenguajes de tercera generación aplicando técnicas especializadas y

con pleno conocimiento de sistemas matemáticos y contables

Conocer las acciones requeridas hacia la automatización de las empresas

mediante el análisis, diseño, desarrollo, documentación e implementación de los

sistemas.

Diseñar y administrar Bases de datos, dominando la programación en

herramientas de cuarta generación y la programación orientada a objetos.

Participar en el diseño de sistemas informáticos interactuando con plataformas de

internet y con pleno conocimiento de la administración de las redes y sus sistemas

operativos.

Administrar las actividades de un departamento de cómputo con la aplicación de

herramientas informáticas y gerenciales incluyendo la creación de su propia

microempresa.

e) ESCENARIOS DE ACTUACIÓN

El Tecnólogo en Informática podrá desempeñarse en todo tipo de empresa pública o

Privada donde se requiera tratar de una manera especial a los datos y la información que

Se generan dentro de la entidad, sea por procesos o por transacciones:

·Instituciones Bancarias

Entidades Financieras

Empresas Comerciales

Empresas del estado

Entes de servicio a la comunidad

Instituciones de capacitación a nivel profesional, universitario o intermedio


SEMIPRESENCIAL


Empresas de Asesoría Informática

f) OCUPACIONES PROFESIONALES

El Tecnólogo en Informática podrá desempeñarse como:

Gerente de Sistemas

Programador de computadoras

Director de grupos de trabajo

Administrador de Centros de Cómputo

Asistente de gerencia

Administrador de Bases de Datos

Instructor de personal en el área informática

Asesor organizacional de las empresas

Asesor en el área informática


SEMIPRESENCIAL


DESCRIPCIÓN DE LA MATERIA

En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver

los problemas.

La Ingeniería de Software es un enfoque sistemático del desarrollo, operación,

mantenimiento y retiro del software. Se considera que la Ingeniería de software es la rama

de la Ingeniería que aplica os principios de la ciencia de la computación y la matemática

para lograr soluciones costo-efectivas a los problemas de desarrollo de software.

Un sistema debe estar basado en un ciclo de vida del software que comprende cuatro

grandes fases estudiadas en el contenido.

Se estudiará las fases del análisis con sus respectivas actividades poniendo énfasis en la

metodología orientada a objetos.

OBJETIVO GENERAL

Conocer las actividades a realizar dentro de las fases de análisis y conceptos básicos de

diseño en el desarrollo de software.

GENERALIDADES

CONCEPTOS Metodología Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software. Tarea Actividades elementales en que se dividen los procesos. Procedimiento Definición de la forma de ejecutar la tarea. Técnica Herramienta utilizada para aplicar un procedimiento. Se pueden utilizar una o varias. Herramienta Para realizar una técnica, podemos apoyarnos en las herramientas software que automatizan su aplicación. Producto Resultado de cada etapa


SEMIPRESENCIAL


CONTENIDO

CAPITULO I

1. HISTORIA DEL SOFTWARE

1.1 LA IMPORTANCIA DEL SOFTWARE

1.1.1 EL SOFTWARE

1.1.2 CARACTERISTICAS DEL SOFTWARE

1.1.3 COMPONENTES DEL S0FWARE

1.1.4 APLICACIONES DEL SOFTWARE

1.1.4.1 SOFTWARE DE SISTEMAS

1.1.4.2 SOFTWARE DE TIEMPO REAL

1.1.4.3 SOFTWARE DE GESTIÓN

1.1.4.4 SOFTWARE EMPOTRADO

1.1.4.5 SOFTWARE DE INTELIGENCIA ARTIFICIAL

1.2 MITOS

1.3 PARADIGMAS DE LA INGENIERIA DE SOFTWARE

1.4 INGENIERIA DE SOFTWARE

CAPITULO II

2. CICLOS DE VIDA

2.1 EL CICLO DE VIDA CLÁSICO SEGÚN PROGER

2.2 PLANIFICACIÓN DEL SISTEMA

2.3 MODELO DEL COSTO DE UN PROYECTO

2.3.1 MODELO DE PROTOTIPO PARA EL CICLO DE VIDA

2.4 FACTORES DE CALIDAD

2.5 MEDICIÓN DE SOFTWARE

2.6 INGENIERÍA DE SOFTWARE

CAPITULO III

3. INGENIERIA DE SOFTWARE

3.1 SISTEMAS BASADOS EN COMPUTADORAS

3.2 LA JERARQUUÍA DE LA INGENIERIA DE SISTEMAS DE COMPUTADORAS

3.3 MODELO DE SISTEMAS

3.4 INGENIERIA DE INFORMACIÓN

3.5 INGENIERIA DE PRODUCTOS

3.6 PLANIFICACIÓN DE LA ESTRATEGÍA DE LA INFORMACIÓN

3.6.1 MODELADO DE LA EMPRESA

3.6.2 MODELADO DE DATOS A NIVEL DE NEGOCIO

3.6.3 ANALISIS DEL AREA DE NEGOCIO

3.6.4 MODELADO DEL PROCESO


SEMIPRESENCIAL


3.6.5 MODELADO DE FLUJO DE INFORMACIÓN

3.6.6 INGENIERÍA DE PRODUCTOS

CAPITULO IV

4. IDENTIFICADORES DE NECESIDADES

4.1 ESTUDIO DE LA VARIABLE

4.1.1 ANÁLISIS ECONÓMICO

4.1.2 ANÁLISIS TECNICO

4.2 MODELADO DE LA ARQUITECTURA DEL SISTEMA

4.3 MODELADO Y SIMULACIÓN DEL SISTEMA

4.4 ESPECIFICACIÓN DEL SISTEMA

4.5 TECNICAS ORIENTADAS A OBJETOS

4.6 CARACTERÍSTICAS

CAPITULO V

5. METODOLOGÍAS DE DESARRROLLO DE SOFTWAR

5.1 METODOLOGÍA Vs CICLO DE VIDA

5.1.1 GENERACIÓN DE METODOLOGÍA

5.1.2 DESARROLLO CONVENCIONAL

5.1.3 DESARROLLO ESTRUCTURADO

5.1.4 DESARROLLO ORIENTADO A OBJETOS

5.2 METODOLOGÍAS ORIENTADAS A OBJETOS

5.2.1 CLASIFICACIÓN DE LAS METODOLOGÍAS

5.2.2 METODOLOGÍAS ESTRUCTURADAS

5.2.3 METODOLOGÍA YOURDON/CONSTANTE

5.2.4 METODOLOGÍA ORIENTADA A DATOS JERÁRQUICOS / NO JERÁRQUICOS

5.3 CICLO DE VIDA DEL SISTEMA ORIENTADO A OBJETOS

5.3.1 ESTUDIO PREMILINAR

5.3.2 ANÁLISIS ORIENTADOS A OBJETOS

5.3.3 DISEÑO ORIENTADOS A OBJETOS

5.3.4 CONTRUCCIÓN ORIENTADA A OBJETOS

5.3.5 IMPLEMENTACIÓN

5.4 OBJETO

5.4.1 CLASIFICACIÓN DEL OBJETO

5.4.2 ANÁLISIS ORIENTADO A OBJETOS

5.4.3 OBJETIVO DEL ANÁLISIS

5.4.4 ANÁLISIS DE OBJETOS

5.5 EJERCICIOS


SEMIPRESENCIAL


DESARROLLO DEL CONTENIDO

CAPITULO I 1. HISTORIA DEL SOFTWARE

Durante las tres primeras décadas de la Informática, el principal desafío era el desarrollo del hardware de las computadoras, de forma que se redujera el costo de procesamiento y almacenamiento de datos. La necesidad de enfoques sistemáticos para el desarrollo y mantenimiento de productos de software se patentizó en la década de 1960. En ésta década aparecieron las computadoras de la tercera generación y se desarrollaron técnicas de programación como la multiprogramación y el tiempo compartido. Y mientras las computadoras estaban haciéndose más complejas, resultó obvio que la demanda por los productos de software creció en mayor cantidad que la capacidad de producir y mantener dicho software. Estas nuevas capacidades aportaron la tecnología necesaria para el establecimiento de sistemas computacionales interactivos, de multiusuario, en línea y en tiempo real; surgiendo nuevas aplicaciones para la computación, como las reservaciones aéreas, bancos de información médica, etc. Fue hasta el año 1968 que se convocó una reunión en Garmisch, Alemania Oriental estimulándose el interés hacia los aspectos técnicos y administrativos utilizados en el desarrollo y mantenimiento de software, y fue entonces donde se utilizó el término "Ingeniería de Software". A lo largo de la década de los ochenta, los avances en microelectrónica han dado como resultado una mayor potencia de cálculo a la vez que una reducción de costo. Hoy el problema es diferente. El principal desafío es mejorar la calidad y reducir el costo. 1.1 LA IMPORTANCIA DEL SOFTWARE Durante las tres primeras décadas de la informática, el principal desafío era el desarrollo del hardware de computadoras, de forma que se redujera el costo del procesamiento y almacenamiento de datos. A lo largo de las décadas de los ochenta, los avances en microelectrónica han dado como resultado una mayor potencia de cálculo a la vez que una reducción del costo. Hoy, el problema es diferente. El principal desafío es mejorar la calidad (y reducir el costo) de las soluciones basadas en computadoras – soluciones que se implementan con el software. La potencia de las grandes computadoras de la era de los ochenta esta hoy disponible en una computadora personal. Las enormes capacidades de procesamiento y el almacenamiento de hardware moderno representan una gran potencia de cálculo. El software es el mecanismo que nos facilita utilizar y explotar este potencial. 1.1.1 EL SOFTWARE


SEMIPRESENCIAL


Hace veinte años menos del 1 por 100 de la gente podría describir de forma inteligente lo que significaba el “software de computadora”. Hoy, la mayoría de los profesionales y muchas personas en general creen que entienden el software. Una descripción del software de un libro de texto puede tener la siguiente forma: “Instrucciones (programas de computadora) que cuando se ejecutan proporcionan la función y el comportamiento deseado”. “Estructuras de datos que facilitan a los programas manipular los datos adecuadamente la información”. “Documentos que describen la operación y el uso de los programas”. 1.1.2 CARACTERÍSTICAS DEL SOFTWARE Para poder comprender lo que el software (y consecuentemente la ingeniería del software), es importante examinar las características del software que lo diferencian de otras cosas que los hombres pueden construir. Cuando se construye hardware, el proceso creativo humano (análisis, diseño, construcción y prueba) se traduce finalmente de una forma física. Si construimos una nueva computadora, nuestro boceto inicial, diagramas formales de diseño y prototipo de prueba, evolucionan hacia un producto físico (pastillas de VLSI, tarjetas de circuitos impresos, fuentes de potencia, entre otros). El software es un elemento del sistema que es lógico, en lugar de físico. Por tanto, el software tiene unas características distintas a las del hardware: El software se desarrolla, no se fabrica en un sentido clásico. Aunque existen algunas similitudes entre le desarrollo del software y la construcción del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante un buen diseño, pero la fase de construcción del hardware puede introducir problemas de calidad que no existen en el software. Ambas actividades dependen de las personas, pero la relación entre la gente dedicada y el trabajo realizado es completamente diferente para el software. Ambas actividades requieren la construcción de un producto, pero los métodos son diferentes. Los costos del software se encuentran en la ingeniería. Esto significa que los proyectos no se pueden gestionar como si fueran proyectos de fabricación y esto es bien importante para el manejo de los sistemas de información. El software no se “estropea”. El software no es susceptible a los males del entorno que hacen que el hardware se estropee. Los defectos no detectados harán que falle el programa durante las primeras etapas de su vida. Sin embargo, una vez que se corrigen, suponiendo que no introducen nuevos errores, el software no se estropea !Pero se deteriora! Durante su vida, el software


SEMIPRESENCIAL


sufre cambios (mantenimiento). Conforme se hacen los cambios, es bastante probable que se introduzcan nuevos defectos. Lentamente, el nivel mínimo de fallos comienza a crecer; el software se va deteriorando debido a los cambios. Este aspecto de mantenimiento del software, es de suma importancia para el buen manejo de los sistemas de información que fluyen dentro de una empresa. La mayoría del software se construye a medida, en vez de ensamblar componentes existentes. Se puede comprar software ya desarrollado, pero solo con una unidad completa, no como componentes que pueden reensamblarse en nuevos programas. 1.1.3 COMPONENTES DEL SOFTWARE El software de computadora es información que existe en dos formas básicas: componentes no ejecutables en la maquina y componentes ejecutable en las maquinas. Los componentes de software se crean mediante una serie de traducciones que hacen corresponder los requisitos del cliente con un código ejecutable en la maquina. Se traduce un modelo (prototipo) de requisitos a un diseño. Se traduce el diseño del software a una forma en un lenguaje que especifica las estructuras de datos, los atributos procedí mentales y los requisitos que atañen al software. La forma en lenguaje es procesada por un traductor que la convierte en instrucciones ejecutables a la maquina. La habilidad de poder volver a usarse es una característica importante para un componente de software de alta calidad. Es decir, el componente debe diseñarse e implementarse para que pueda volver a usarse en muchos programas diferentes. Los componentes de software se construyen mediante un lenguaje de programación que tiene un vocabulario limitado, una gramática definida explícitamente y reglas bien formadas de sintaxis y semántica. Estos atributos son esenciales para la traducción por la maquina. Las clases de lenguaje que se utilizan actualmente son lenguajes de maquina, los lenguajes de alto nivel y los lenguajes no procedí mentales. Los lenguajes maquina son una representación sim del conjunto de instrucciones de la CPU. Los lenguajes de alto nivel permiten al programador y al programa independizarse de la maquina. Cuando se utiliza un traductor sofisticado, el vocabulario, la gramática, la sintaxis y la semántica de un lenguaje de alto nivel pueden ser mucho más sofisticados que los lenguajes maquinan. Los lenguajes de programación modernos (lenguajes que soportan directamente las prácticas modernas para el diseño procide mental y datos) tales como Pascal, C y Ada se utilizan ampliamente. Los lenguajes orientados a los objetos como c+++, Object Pascal, Eiffel y otros, están ganando cada vez más seguidores entusiastas.


SEMIPRESENCIAL


Los lenguajes especializados (diseñados para ámbitos de aplicación específicos), como APL, LIPS, OPS5 y lenguajes descriptivos para redes neutrales artificiales, están teniendo cada vez mayor aceptación conforme las nuevas aplicaciones pasan de los laboratorios a la práctica. 1.1.4 APLICACIONES DEL SOFTWARE El software puede aplicarse en cualquier situación en la que se haya definido previamente un conjunto especifico de pasos procedí mentales(es decir un algoritmo). Para determinar la naturaleza de una aplicación de software, hay dos factores importantes que se deben considerar: El contenido y el determinismo de la información. El contenido se refiere al significado y a la forma de la información de entrada y de salida. Por ejemplo, muchas aplicaciones bancarias usan unos datos de entrada muy estructurados (una base de datos) y producen informes con Determinados formatos. El software que controla una maquina automática (por ejemplo, un control numérico) actúa sobre elementos de datos discretos con una estructura limitada y produce ordenes concretas para la maquina de rápida sucesión. El determinismo de la información se refiere a la predecibilidad del orden y del tiempo de llegada de los datos. Un programa de ingeniería acepta datos que están en un orden predefinido, ejecuta el algoritmo sin interrupción y produce los datos resultantes en un informe o formatos grafico. Algunas veces es difícil establecer categorías genéricas para las aplicaciones del software que sean significativas. Conforme aumenta la complejidad del software, es más difícil establecer compartimientos nítidamente separados. Las siguientes áreas del software indican la amplitud de las posibilidades de aplicación. 1.1.4.1 SOFTWARE DE SISTEMAS. Es software de sistemas es un conjunto de programas que han sido escritos para servir a otros programas. Algunos programas de sistemas (p. Ej.: compiladores, editores y utilidades de gestión de archivos) procesan estructuras de información complejas pero determinadas. En cualquier caso, el área del software de sistemas se caracteriza por una fuerte interacción del hardware de la computadora; una gran utilización por múltiples usuarios; una operación concurrente que requiere una planificación, una compartición de recursos y una sofisticada gestión de procesos; unas estructuras de datos complejos y múltiples interfaces externas. 1.1.4.2 SOFTWARE DE TIEMPO REAL. El software que mide/analiza/controla sucesos del mundo real conforme ocurren, se denominan de tiempo real. Entre los elementos del software de tiempo real se incluyen: un componente de adquisición de datos que recolecta y da formato a ala información


SEMIPRESENCIAL


recibida del entorno externo, un componente de análisis que transforma la información según lo requiera la aplicación, un componente de control / salida que responda al entorno externo y un componente de monitorización que coordina todos los demás componentes, de forma que puede mantenerse la respuesta en tiempo real. 1.1.4.3 SOFTWARE DE GESTIÓN. El procesamiento de información comercial constituye la mayor delas áreas de aplicación del software. Los “sistemas discretos” (por ejemplo: Nominas, cuentas de haberes/debitos, inventarios etc. que proporcionan información básica a la organización) han evolucionado hacia el software de sistemas de información de gestión (SIG), que accede a una o más bases de datos grandes que contienen información comercial. Las aplicaciones en esta área reestructuran los datos existentes en orden a facilitarlas operaciones comerciales o gestionar las tomas de decisiones. Además de las tareas convencionales de procesamientos de datos, las aplicaciones de software de gestión también realizan cálculo interactivo (por ejemplo: el procesamiento de transacciones en puntos de ventas). 1.1.4.4 SOFTWARE EMPOTRADO El software empotrado reside en memoria de solo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo. El software empotrado puede ejecutar funciones muy limitadas y curiosas (por ejemplo: el control de las teclas de un horno de microonda) o suministrar una función significativa y con capacidad de control (por ejemplo: Funciones digitales en un automóvil, tales como control de gasolina, indicaciones en el salpicadero, sistemas de frenado, etc.). 1.1.4.5 SOFTWARE DE INTELIGENCIA ARTIFICIAL. El software de inteligencia artificial hace uso de algoritmos no numéricos para resolver problemas complejos para los que no es adecuado él cálculo o el análisis directo. Actualmente, el área más activa de la IA es la de los sistemas experto, también llamados sistemas basados en el conocimiento. 1.2 MITOS Muchas de las causas de la crisis del software se pueden encontrar en una mitología que surge durante los primeros años del desarrollo del software. Hoy la mayoría de los profesionales competentes consideran a los mitos como actitudes erróneas que han causado serios problemas, siendo éstos hábitos difíciles de modificar. Examinemos algunos de ellos: Mitos de Gestión Mitos del Cliente Mitos de los Desarrolladores


SEMIPRESENCIAL


Mitos de Gestión Mito. Tenemos ya un libro que está lleno de estándares y procedimientos para construir software. ¿No le proporciona ya a mi gente todo lo que necesita saber? Realidad. Está muy bien que el libro exista, pero ¿Se usa? ¿Conocen los trabajadores su existencia? ¿Refleja las prácticas modernas de desarrollo de software? ¿Es completo? En muchos casos, la respuesta a todas estas preguntas es "no"?. Mito. Nuestra gente dispone de las herramientas de desarrollo de software más avanzadas; después de todo, les compramos las computadoras más nuevas. Realidad. Se necesita mucho más que el último modelo de computadora grande (o de PC) para hacer desarrollo de software de gran calidad. Las herramientas de ingeniería del software asistida por computadora (CASE), aunque no se usen la mayoría, son más importantes que el hardware para conseguir buena calidad y productividad. Mito. Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido. Realidad. El desarrollo de software no es un proceso mecánico como la fabricación. Brooks dice: "Añadir gente a un proyecto de software retrasado lo retrasa aún más". Ya que cuando se añaden nuevas personas, la necesidad de aprender y comunicarse con el equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo productivo. Puede añadirse gente, pero de una manera planificada y bien coordinada. Mitos del Cliente Mito. Una declaración general de los objetivos es suficiente para comenzar a escribir los programas. (Podemos detallar más adelante). Realidad. Una mala definición inicial es la causa principal del trabajo baldío en software. Es esencial una descripción formal y detallada del ámbito de la información, funciones, rendimiento, etc. Y todas éstas características sólo se pueden determinar después de una exhaustiva comunicación entre cliente y analista. Mito. Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible.


SEMIPRESENCIAL


Realidad. Es verdad que los requisitos del software cambian pero el impacto del cambio varía según el momento en que se introduzca. Entre más temprano se realicen mejor. Mitos de los Desarrolladores. Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado. Realidad. Alguien dijo una vez: "Cuando más pronto se comience a escribir código, más se tardará en terminarlo". Datos industriales indican que entre el 50 y el 70 por ciento de todo el esfuerzo dedicado a un programa se realizará después de que se le haya entregado al cliente por primera vez. Mito. Hasta que no tengo el programa “ejecutándose” realmente no tengo forma de comprobar su calidad. Realidad. Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar la calidad del software (Revisión de técnica formal). La revisión del Software es un "filtro de calidad" que se ha comprobado que es más efectivo que la prueba, para encontrar ciertas clases de defectos en el software. Mito. Lo único que se entrega al terminar el programa funcionando. Realidad. Un programa que funciona es sólo una parte de una configuración del software que incluye todos los elementos tales como el Análisis, Diseño, Documentación del sistema, etc. 1.3 PARADIGMAS DE LA INGENIERIA DE SOFTWARE El mal que ha afectado el desarrollo del software no va a desaparecer de la noche a la mañana. No existe un único enfoque mejor para solucionar el mal del software. Sin embargo mediante la combinación de métodos completos para todas las fases del desarrollo del software, mejores herramientas para automatizar estos métodos, bloques de construcción más potentes para la implementación del software, mejores técnicas para la garantía de calidad del software y una filosofía predominante para la coordinación, control y gestión, podemos conseguir una disciplina para el desarrollo del software.

1.4 INGENIERIA DE SOFTWARE


SEMIPRESENCIAL


Una de las primeras definiciones de ingeniería del software fue la propuesta por Fritz Bauer en la primera conferencia importante [NAU 69] dedicada al tema: El establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que sea fiable y funcione de manera eficiente sobre máquinas reales. Aunque se han propuesto muchas más definiciones generales, todas refuerzan la importancia de una disciplina de ingeniería para el desarrollo del software. La ingeniería del software surge de la ingeniería de sistemas y de hardware. Abarca un conjunto de tres elementos clave – métodos, herramientas y procedimientos- que facilitan a las personas a controlar el proceso del desarrollo del software. Los métodos de la ingeniería del software indican cómo construir técnicamente el software. Los métodos abarcan un amplio espectro de tareas que incluyen: planificación y estimación de proyectos, análisis de los requisitos del sistema y del software, diseño de estructuras de datos, arquitectura de programas y procedimientos algorítmicos, codificación, prueba y mantenimiento. Los métodos de la ingeniería del software introducen frecuentemente una notación especial orientada a un lenguaje o gráfica y un conjunto de criterios para la calidad del software. Las herramientas de la ingeniería del software suministran un soporte automático o semiautomático para los métodos. Hoy existen herramientas para soportar cada uno de los métodos mencionados anteriormente. Cuando se integran las herramientas de forma que la información creada por una herramienta pueda ser usada por otra, se establece un sistema para el soporte del desarrollo del software llamado Ingeniería de Software asistido por una Computadora (CASE). CASE combina software, hardware y bases de datos sobre ingeniería de software (una estructura de datos que contenga la información relevante sobre el análisis, diseño, codificación y prueba) para crear un entorno de ingeniería del software (por ejemplo [BRE88]) análogo al diseño/ingeniería asistido por computadora, CAD/CAE (de las siglas en inglés) para el hardware. Los procedimientos de la ingeniería del software son el pegamento que junta los métodos y las herramientas y facilita un desarrollo racional y oportuno del software de la computadora. Los procedimientos definen la secuencia en la que se aplican los métodos, las entregas (documentos, informes, formas) que se requieren los controles que ayudan a asegurar la calidad y coordinar los cambios y las directrices que ayudan a los gestores del software a evaluar el progreso. La ingeniería del software está compuesta por una serie de pasos que abarcan los métodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniería de software. La elección de un paradigma para la ingeniería del software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos y herramientas a usar y los controles y entregas requeridos. Tres Son los diferentes tipos de paradigmas que se han tratado ampliamente.


SEMIPRESENCIAL


CAPITULO II 2. CICLOS DE VIDA

Es esencial definir previamente los requisitos de todos los elementos del sistema, así como un modelo de vida para cada uno de los proyectos de programación, puesto que permite clasificar y controlar las diferentes actividades necesarias para el desarrollo y mantenimiento del producto.

Modelo de Fases de Ciclo de Vida

Modelo del Costo de un Proyecto

Modelo de Prototipo para el Ciclo de Vida

Modelo de fases del ciclo de vida (Cascada) 2.1 EL CICLO DE VIDA CLÁSICO SEGÚN ROGER S. PRESSMAN. Este modelo divide el ciclo de vida del producto de programación en una serie de actividades sucesivas; cada fase requiere información de entrada, procesos y resultados, bien definidos.

Planificación del Sistema

Análisis

Diseño

Codificación

Prueba

Mantenimiento En ocasiones se denomina de cascada porque los productos pasan de un nivel a otro con suavidad. Este es el ciclo de vida clásico y más antiguo, usado en el desarrollo de productos de software. Sin embargo, con el paso de unos cuantos años, se han producido críticas, incluso por seguidores activos, que cuestionan su aplicabilidad a todas las situaciones. 2.2 PLANIFICACIÓN DEL SISTEMA: Es la etapa en la que se determina si el proyecto es o no factible de realizar y se determinan tiempos y costos aproximados, estableciendo así la ruta crítica de cada actividad. Esto es porque la falta de planeación de un sistema es la causa principal de retrasos en programación, incremento de costos, poca calidad, y altos costos de mantenimiento en los desarrollos de productos de software. Con frecuencia se dice que es imposible realizar una planeación inicial, porque la información precisa sobre las metas del proyecto, necesidades del cliente y restricciones del producto no se conocen al comenzar el proyecto de desarrollo, sin embargo, uno de los principales propósitos de esta fase es aclarar los objetivos, problemas o necesidades y restricciones. La dificultad de la planeación no debe desalentar tan importante actividad.


SEMIPRESENCIAL


ANÁLISIS Es indispensable comprender perfectamente los requisitos del software, para que éste no fracase. Esta etapa puede parecer una tarea relativamente sencilla, pero las apariencias engañan. Abundan los casos en que se puede llegar a malas interpretaciones o falta de información. Existe una frase que se utiliza al momento de hacer el análisis, y es la siguiente: "Sé que crees que comprendes lo que piensas que he dicho, pero no estoy seguro de que lo que creíste oír sea lo que yo quise decir..."

DISEÑO El diseño del software es realmente un proceso multipaso que se enfoca sobre cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes de que comience la codificación. Al igual que los requisitos, el diseño se documenta y forma parte de la configuración del software.

CODIFICACIÓN El diseño debe traducirse en una forma legible para la máquina. Si el diseño se realiza de una manera detallada, la codificación puede realizarse mecánicamente.

PRUEBA Una vez que se ha generado el código, comienza la prueba del programa. La prueba se centra en la lógica interna del software, asegurando que todas las sentencias se han probado, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.

MANTENIMIENTO Es indudable que el software una vez entregado al cliente sufrirá cambios (posible excepción es el software empotrado). Los cambios ocurrirán debido a que se hayan encontrado errores, a que el software deba adaptarse a posibles cambios. El desarrollo de productos de software bajo éste ciclo de vida tiene los siguientes problemas: 1.- Los proyectos reales raramente siguen el flujo secuencial que propone el modelo. 2.- Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. Este ciclo lo requiere y tiene dificultades en entender posibles problemas que pudieran existir.


SEMIPRESENCIAL


3.- El cliente debe tener paciencia. Hasta llegar a las etapas finales del desarrollo del proyecto. A pesar de sus inconvenientes, este ciclo de vida sigue siendo el modelo clásico más ampliamente usado por los ingenieros del software. 2.3 MODELO DEL COSTO DE UN PROYECTO Otro punto de vista para el ciclo de vida de desarrollo de un producto de programación es la consideración del costo de la realización de las distintas actividades del proyecto. El costo de un proyecto es la suma de los costos incurridos en cada fase, y éstos, a su vez, incluyen los costos de la realización de los procesos y preparación de los documentos de esa fase, más los costos de verificación de la consistencia de estos productos con los de las fases previas. Es sumamente importante hacer hincapié en que es prácticamente 100 veces más costoso hacer un cambio a los requisitos durante la prueba del sistema, que hacerlo durante su definición. 2.3.1 MODELO DE PROTOTIPO PARA EL CICLO DE VIDA Un prototipo es una representación o modelo del producto de programación que, a diferencia de un modelo de simulación, incorpora componentes del producto real. Por lo regular, un prototipo tiene un funcionamiento limitado en cuanto a capacidades, confiabilidad o eficiencia. Hay varias razones para desarrollar un prototipo; una de ellas es ilustrar los formatos de datos de entrada, mensajes, informes y diálogos al cliente, este es un mecanismo adecuado para explicar opciones de procesamiento y tener un mejor entendimiento de las necesidades de él. Una vez realizado el sistema prototipo, la pregunta que surgiría sería la siguiente: ¿Qué debemos hacer con el prototipo cuando ya ha servido para el propósito establecido? Brooks nos da una respuesta: "En la mayoría de los proyectos, el primer sistema construido apenas es utilizable". Puede ser demasiado lento, demasiado grande, difícil de usar o las tres cosas. No hay más alternativa que comenzar de nuevo y construir una versión rediseñada que resuelva los problemas que se presenten... Cuando se utiliza un nuevo concepto de sistema o de tecnología, hay que construir un sistema para desecharlo, porque incluso la mejor planificación no puede asegurar que vaya a ser bueno la primera vez. Por tanto, la cuestión no es si hay que construir un sistema piloto y tirarlo. Se tirará. La única cuestión es si planificar de antemano la construcción de algo que se va a desechar, o prometer entregar el desecho a los clientes. Al igual que el ciclo de vida clásico, la construcción de prototipos puede ser problemática por las siguientes razones:


SEMIPRESENCIAL


1.- El cliente ve funcionando lo que parece ser una primera versión del software, ignorando que, por las prisas en hacer que funcione, no hemos considerado los aspectos de calidad o de mantenimiento del software a largo plazo. Cuando se le informa de que el producto debe ser reconstruido, el cliente se vuelve loco y solicita que se apliquen “cuantas mejoras” sean necesarias para hacer del prototipo un producto final que funcione. Y el desarrollador del producto cede demasiado a menudo. 2.- El técnico de desarrollo, frecuentemente, impone ciertos compromisos de implementación con el fin de obtener un prototipo que funciones rápidamente. Puede que utilice un sistema operativo inapropiado, o un lenguaje de programación equívoco o simplemente porque ya está disponible y es conocido, puede que implemente ineficientemente un algoritmo, sencillamente para demostrar su capacidad. La clave está en definir al comienzo las reglas del juego; esto, es, el cliente y el técnico deben estar de acuerdo en que el prototipo se construya para servir sólo como un mecanismo de definición de los requisitos. 2.4 FACTORES DE CALIDAD El grado de formalidad y la cantidad de tiempo asignada varía de acuerdo con el tamaño y complejidad del producto que se desarrollará. Existe una gran diferencia entre escribir un programa pequeño de uso personal y el desarrollar para una empresa, ya que esto requiere el desarrollo y mantenimiento de productos de alta calidad y habilidades técnicas y gerenciales comparables con otras ramas de la ingeniería. Capacidad Individual El desarrollo de productos de software es laborioso por lo que la capacidad de cada individuo influye mucho en la calidad de desarrollo. Existen dos aspectos en la capacidad: la competencia global del individuo y su familiaridad con el área particular de aplicación Por mencionar algunos ejemplos: programadores que se muestran competentes en el procesamiento de datos, suelen no serlo en áreas científicas, y de igual forma, un buen programador científico no es, forzosamente, un buen programador de sistemas. Comunicación en grupo Aunque la programación se considera una actividad individual y privada de modo que muchos programadores tienen poco contacto social y prefieren trabajar en forma aislada. Con el incremento del tamaño de un producto, disminuye la productividad debido al aumento en complejidad de las interacciones entre los diversos componentes del sistema, y a causa del incremento de comunicación necesario entre programadores, gerentes y clientes. Complejidad del Producto Existen tres tipos de complejidad en un producto generalmente aceptados: programas de aplicación, programas de apoyo y programas de sistema operativo. Los programas de aplicación tienen el más alto nivel de productividad mientras que los programas de sistemas operativos tienen el menor, medido en términos de líneas de código por día de programador. El esfuerzo requerido para desarrollar y mantener un producto de programación es una función no lineal del tamaño del producto y su complejidad. Un producto del doble de tamaño o doblemente difícil que otro producto, usando cualquier


SEMIPRESENCIAL


métrica diferente del esfuerzo, puede requerir diez o tal vez 100 veces más esfuerzo para obtener el producto. Notaciones apropiadas Las notaciones apropiadas son vehículos de comunicación entre el personal asignado al proyecto y planean la posibilidad de usar una herramienta automatizada de programación para manejar las notaciones verificando su uso correcto. Esto puede beneficiar un proyecto en particular, pero se obtendrán más beneficios cuando se adopte, en todas las organizaciones e industrias, un conjunto pequeño de notaciones bien definidas para los proyectos de programación. Enfoques Sistemáticos Es indispensable al momento de desarrollar software, el utilizar herramientas de diseño tales como modelos de desarrollo. Pudiéndose utilizar de cascada, costo, Versiones sucesivas, y más. Dependiendo del sistema. En este documento se describen varios enfoques sistemáticos de desarrollo y mantenimiento pero, como la ingeniería del software se encuentra en su infancia, muchos de los procedimientos propuestos tendrán todavía que madurar. Control de Cambios La flexibilidad de un programa es un gran beneficio y a su vez una gran fuente de dificultad en la ingeniería de software. Las notaciones y procedimientos que permitan seguir la secuencia y determinar el impacto de un posible cambio son necesarios para hacer visible el costo verdadero de una modificación aparentemente pequeña al código fuente; estos cambios de manuales, requisitos y planes de prueba. Por otro lado, el uso de notaciones y técnicas apropiadas hace que se puedan realizar cambios controlados, sin menoscabo de la calidad del producto. Nivel Tecnológico Incluye aspectos como selección del lenguaje, ambiente computacional, prácticas de programación y herramientas de programación disponibles. Entre más tecnología de hardware y software se tenga mejor será la calidad y productividad. Nivel de Confiabilidad Todo producto de programación debe poseer un nivel elemental de confiabilidad; sin embargo, la alta confiabilidad sólo se consigue con gran cuidado en el análisis, diseño, instrumentación, pruebas y mantenimiento del software. Captación del problema Muchas veces, es el cliente quien no entiende realmente la naturaleza del problema, además de no entender las capacidades y limitaciones de la computación. Para poder resolver esta situación, se necesita realizar entrevistas con el cliente, la observación de la tarea manual, el desarrollo de prototipos, una versión preliminar del manual del usuario, entre otros. Tiempo Disponible


SEMIPRESENCIAL


La mayoría de las veces las empresas desean tener los sistemas para ayer. Aunque pareciera que un proyecto de programación que requiere de un esfuerzo de seis meses-programador pueda ser completado por un programador en seis meses o seis programadores en un mes, los proyectos de programación son sensibles no sólo al total de esfuerzo requerido, sino también al número de personas comprendidas. El uso de seis programadores durante un mes probablemente sea menos eficiente que usar sólo uno durante seis meses, y esto se debe a que la curva de aprendizaje para el grupo de seis programadores afectará notablemente al proyecto. Especialización requerida. No es necesario que todos los ingenieros poseen todas las habilidades necesarias, pero los miembros del equipo de programación sí deberán poseerlas, ya que se requiere de una gama de habilidades y especialidades; por ejemplo: la obtención de la información de los clientes con el fin de determinar sus necesidades requiere de la habilidad de comunicarse, de tener tacto y diplomacia, así como de un buen conocimiento del área de aplicación. Facilidades y recursos. Es muy motivante para un programador contar con un buen ambiente de trabajo, así como un buen acceso a una buena máquina y un lugar silencioso donde laborar. Casi todos los programadores se motivan con los recursos con que cuentan, por lo tanto son muy sensibles y están sujetos a frustración si cuentan con recursos pobres o inadecuados. Los gerentes de un proyecto de programación deben de ser eficaces en el manejo de los factores de motivación y frustración, si desean mantener la calidad de sus productos, la productividad de sus programadores y la satisfacción del trabajo. Entrenamiento adecuado La programación de un producto es sólo un aspecto de la ingeniería de programación sin embargo, ésta es la única fase del desarrollo y mantenimiento de un producto que se enseña en muchas escuelas. Hasta el momento, la mayoría de los programadores se han educado como ingenieros en computación, ingenieros electrónicos, contadores, matemáticos, más no como ingenieros en productos de programación. Las universidades han formado tradicionalmente licenciado en computación y las industrias buscan, también por tradición, ingenieros de programación. Habilidades gerenciales Los proyectos de programación son, por lo común, supervisados por gerentes que tienen poco conocimiento, si acaso lo tienen, acerca de la ingeniería de programación Por otro lado, la costumbre de promover a puestos administrativos de un proyecto de programación a individuos técnicamente competentes, con poca inclinación gerencial y sin entrenamiento administrativo, también suele producir resultado negativos. Metas apropiadas La meta principal de la ingeniería de software es el desarrollo de productos de programación que cumplan con los requisitos del uso deseado; idealmente, todo producto


SEMIPRESENCIAL


de programación debe proporcionar niveles óptimos de generalidad, eficiencia y confiabilidad 2.5 MEDICION DEL SOFTWARE Hay varias razones por las que hay que medir el software:

.Para indicar la calidad del Producto

Para evaluar la productividad de la gente que desarrolla el producto

.Para evaluar los beneficios

Para establecer una línea de base para la estimación

Para ayudar a justificar el uso de nuevas herramientas o de formación adicional 2.6 INGENIERÍA DE SOFTWARE No es una ciencia sino un conjunto de técnicas. Una de las primeras definiciones de ingeniería del software fue la propuesta por Fritz Bauer en la primera conferencia importante [NAU 69] dedicada al tema: “El establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que sea fiable y funcione de manera eficiente sobre máquinas reales”. Aunque se han propuesto muchas más definiciones generales, todas refuerzan la importancia de una disciplina de ingeniería para el desarrollo del software. La ingeniería del software surge de la ingeniería de sistemas y de hardware. Abarca un conjunto de tres elementos clave – métodos, herramientas y procedimientos- que facilitan a las personas a controlar el proceso del desarrollo del software. Los métodos de la ingeniería del software indican cómo construir técnicamente el software. Los métodos abarcan un amplio espectro de tareas que incluyen: planificación y estimación de proyectos, análisis de los requisitos del sistema y del software, diseño de estructuras de datos, arquitectura de programas y procedimientos algorítmicos, codificación, prueba y mantenimiento. Las herramientas de la ingeniería del software suministran un soporte automático o semiautomático para los métodos. Hoy existen herramientas para soportar cada uno de los métodos mencionados anteriormente. Cuando se integran las herramientas de forma que la información creada por una herramienta pueda ser usada por otra, se establece un sistema para el soporte del desarrollo del software, llamado Ingeniería de Software asistido por una Computadora (CASE). Los procedimientos de la ingeniería del software son el pegamento que junta los métodos y las herramientas y facilita un desarrollo racional y oportuno del software de la computadora. Los procedimientos definen la secuencia en la que se aplican los métodos, las entregas (documentos, informes, formas, etc.) que se requieren, los controles que


SEMIPRESENCIAL


ayudan a asegurar la calidad y coordinar los cambios y las directrices que ayudan a los gestores del software a evaluar el progreso. En este caso nos enfocaremos a la Ingeniería de Sistemas que es lo que más se apega a lo del curso de Análisis de Sistemas.

CAPITULO III

3. INGENIERIA DE SISTEMAS La Ingeniería de Software ocurre como consecuencia de un proceso denominado Ingeniería de Sistemas de Computadora. En lugar de concentrarse únicamente en el software, la Ingeniería de Sistemas de Computadora se concentra en una variedad de elementos, analizando, diseñando y organizando esos elementos en un sistema que puede ser un producto, un servicio o una tecnología para la transformación de información o control de información. El proceso de Ingeniería de Software es denominado Ingeniería de Información cuando el contexto del trabajo de Ingeniería se enfoca en una empresa. Cuando hay que construir un producto el proceso se denomina Ingeniería de Producto. Aunque cada una se aplica en un dominio de aplicaciones diferentes, ambas trabajan para asignar un papel al software de la computadora y establecer los enlaces que unen al software con otros elementos de un sistema basado en computadoras. 3.1 SISTEMAS BASADOS EN COMPUTADORAS Un Sistema basado en computadora se define como un conjunto o arreglo de elementos que están organizados para alcanzar un objetivo predefinido procesando información. Para conseguir este objetivo el sistema hace uso de varios elementos: Software: Se refiere a programas de computadora, estructuras de datos y su documentación. Hardware: Son dispositivos electrónicos que proporcionan capacidad de calculo y dispositivos electromecánicos que proporcionan una función externa. Personas: Se refiere al usuario o operador del hardware y software. Bases de Datos: Una gran colección de información.


SEMIPRESENCIAL


Documentación: Manuales, formularios y otra información descriptiva que retrata el empleo y operación del sistema. Procedimientos: Pasos que definen el empleo especifico de cada elemento del sistema. Los elementos se combinan de varias maneras para transformar la información. 3.2 LA JERARQUIA DE LA INGENIERÍA DE SISTEMAS DE COMPUTADORAS La Ingeniería de Sistemas de Computadora comprende una colección de métodos para navegar de arriba abajo y de abajo a arriba dentro de su jerarquía. El proceso empieza con lo que se conoce normalmente como Vista Global, esto se refiere a examinar el dominio entero del negocio o producto para asegurarse de que se puede establecer el contexto de negocio o tecnológico apropiado. La visión global se refina para enfocarse totalmente en un dominio de interés específico para analizar la necesidad de elementos del sistema. Finalmente se inicia el análisis, diseño y construcción del elemento deseado. En la parte alta de la jerarquía se establece un contexto muy amplio y en la parte baja se llevan a cabo actividades técnicas mas detalladas, realizadas por la disciplina de ingeniería correspondiente. La visión global retrata una clara definición de la funcionalidad general que permitirá al ingeniero entender el dominio y finalmente el sistema o producto del contexto apropiado. 3.3 MODELADO DEL SISTEMA La ingeniería de Sistemas de Computadora es un proceso de modelado por lo que es necesario crear modelos que definan los procesos que satisfagan las necesidades de la visión bajo consideración, representa en el comportamiento de los procesos y los supuestos en que se basa el comportamiento, definen explícitamente las entradas de información y representa en todas las uniones que permitan entender mejor la visión. Para construir el modelo hay que tener ciertas restricciones:

Supuestos que reducen el número de permutaciones y variaciones posibles.

Simplificaciones que permitan crear el modelo a tiempo

Limitaciones que ayuden a delimitar el sistema

Restricciones que guían la manera de crear el modelo y el enfoque que se toma al implementar el modelo.

Preferencia que indican la arquitectura preferida para toda la información, funciones y tecnología.

El modelo de sistema resultante puede reclamar una exclusión completamente automática, semiautomática o un enfoque manual. Es posible caracterizar modelos de


SEMIPRESENCIAL


cada tipo que sirven como soluciones alternativas para el problema que tenemos entre manos. En esencia el trabajo se limita a modificar simplemente la influencia relativa de los diferentes elementos del sistema para crear modelos de cada tipo. 3.5 INGENIERÍA DE INFORMACIÓN La meta de la Ingeniería de Información es definir arquitecturas que permitan a las empresas emplear la información eficazmente y crear un plan global para ampliar dichas arquitecturas. Se deben analizar y diseñar 3 arquitecturas diferentes dentro del contexto de objetivos y metas del negocio:

Arquitectura de Datos: Proporciona una estructura para las necesidades de información de un negocio o una función de negocio. Los componentes de la arquitectura son los objetos de datos que emplea la empresa. Estos fluyen entre las funciones de negocio

Arquitectura de Aplicación: Comprende aquellos elementos de un sistema que transforman objetos dentro de la arquitectura de datos por algún propósito del negocio.

Infraestructura de Tecnología: Proporciona el fundamento de las arquitecturas de datos y de aplicaciones. La infraestructura comprende del hardware y software empleados para dar soporte a las aplicaciones y datos. Esto incluye computadoras y redes de computadoras, enlaces de telecomunicaciones, tecnologías de almacenamiento y la arquitectura diseñada para implementar estas tecnologías.

Para modelar las arquitecturas de sistema definidas anteriormente, se define una jerarquía de actividades de ingeniería de la información. La visión global se consigue a través del Planificación de la Estrategia Información (PEI). PEI ve al negocio como una entidad y aísla los dominios del negocio importantes para la totalidad de la empresa. Además define los objetos de datos visibles a nivel de empresa, sus relaciones y como fluyen entre los dominios del negocio. La vista de dominio del negocio se trata con una actividad II denominada Análisis del Área de Negocio (AAN). El AAN se ocupa de identificar en detalle la información y los requisitos de la funciones de áreas de negocio seleccionadas identificadas durante el PEI. Se ocupa solo de especificar que se requiere en un área de negocio. Una vez que se ha aislado un sistema de información para un desarrollo posterior, la II hace una transición a la ingeniería del software. Invocando un paso del Diseño de Sistema de Negocio (DSN), se modelan los requisitos básicos de un sistema de información específico y estos requisitos se traducen en arquitectura de datos, arquitectura de aplicación, e infraestructura tecnológica. El paso final de la II(Construcción e Integración) se concentra en los detalles de implementación. La arquitectura e infraestructura se implementan construyendo una base de datos apropiada y estructuras


SEMIPRESENCIAL


internas de datos, mediante la construcción de aplicaciones que están constituidas por programas. Cada uno de estos componentes del sistema debe integrarse para formar una aplicación o sistema de infamación completo. INGENIERÍA DE PRODUCTOS La meta de la Ingeniería de Productos es traducir el deseo de un cliente, de un conjunto de capacidades definidas, en un producto operativo. Para conseguir esta meta, la ingeniería de producto debe crear una arquitectura y una infraestructura. La arquitectura comprende 4 tipos de componentes de sistema distintos: software, hardware, datos y personas. Se establece una infraestructura de soporte e incluye tecnología requerida para unir componentes y la información que se emplea para dar soporte a los componentes. Los requisitos generales del producto se obtienen del cliente. Estos requisitos comprenden necesidades de información y control, funcionalidad del producto y comportamiento, rendimiento general del producto, diseño, restricciones de la interfaz y otras necesidades especiales. Luego de determinar los requisitos es necesario asignar funcionalidad y comportamiento a cada uno de los 4 componentes mencionados anteriormente. Una vez realizada la asignación comienza la Ingeniería de Componentes. La Ingeniería de componentes es un conjunto de actividades concurrentes que se dirigen separadamente a cada uno de los componentes de sistema. La visión de elemento para la ingeniería de productos es la disciplina de ingeniería aplicada a la asignación de componentes. Para la ingeniería de Software, esto significa actividades de modelado del análisis y diseño y actividades de construcción e integración que comprenden generación de código, pruebas y actividades de soporte. 3.6 PLANIFICACIÓN DE LA ESTRATEGIA DE LA INFORMACIÓN El primer paso de la ingeniería de información es la Planificación de la Estrategia de Información (PEI). Los objetivos generales del PEI son:

Definir los objetivos y metas estratégicos del negocio

Aislar los factores de éxito críticos

Analizar el impacto de la tecnología y automatización en las metas y objetivos

Analizar la información existente para determinar su papel en la consecución de las metas y objetivos. Con esto se pretende evaluar el desempeño del sistema actual.

3.6.1 MODELADO DE LA EMPRESA


SEMIPRESENCIAL


El modelado de la empresa crea una visión a tres dimensiones de un negocio. La primera dimensión se ocupa de la estructura de la organización y de las funciones que se realizan dentro de las áreas de negocio definidas en el organigrama. La segunda dimensión descompone la función de negocio para aislar los procesos que hacen que ocurra dicha función. Finalmente, la tercera dimensión relaciona los objetivos, metas y FCE con la organización y sus funciones. Además el modelado de la empresa crea un modelo de datos a nivel de negocio que define objetos de datos y sus relaciones con otros elementos del modelo de empresa. 3.6.2 MODELADO DE DATOS A NIVEL DE NEGOCIO El modelado de datos a nivel de negocio es una actividad de modelado de empresa que se concentra en objetos de datos o entidades necesarias para alcanzar las funciones de negocios como soporte corporativo, ventas y marketting, Ingeniería y fabricación.. Un objeto de información contiene un conjunto de atributos que define algún aspecto, cualidad, característica o descriptor de la información que describe. Una vez que se definen las entidades se determina las relaciones entre ellas. 3.6.3 ANALISIS DEL AREA DE NEGOCIO Para modelar las complicadas y sutiles maneras en que se relacionan los diferentes aspectos de la información de la empresa, el ingeniero de la información debe describir cómo se usan y transforman los objetos de datos dentro de cada área de negocios. Para esto se emplean varios modelos diferentes: Modelos de datos Modelos de flujos de proceso Diagramas de descomposición de procesos Una variedad de matrices de referencias cruzadas 3.6.4 MODELADO DEL PROCESO El trabajo realizado dentro de un área de negocio comprende un conjunto de funciones de negocio que se refinan más en los procesos de negocio. Por ejemplo el proceso de ventas: Función de Ventas:

n el cliente

Considerar cuestiones y detalles

Aceptar la orden de ventas

Comprobar la disponibilidad del pedido

Preparar la orden de envío

Confirmar con el cliente el pedido , los precios y la fecha de envío

Transmitir la orden de envío al depto. de distribución

Hacer un seguimiento al cliente


SEMIPRESENCIAL


Con esta información se puede perfectamente desarrollar un diagrama de flujo de proceso. 3.6.5 MODELADO DEL FLUJO DE INFORMACIÓN El modelo de flujo de proceso está integrado con el modelo de datos para proporcionar una indicación de cómo fluye la información a través del área de negocio. Se muestran los objetos de datos de entrada y salida para cada proceso, proporcionando una indicación de cómo el proceso transforma la información. Una vez que se ha creado un conjunto de modelos de flujo de proceso, el ingeniero de información examina cómo se puede rediseñar el proceso existente y donde se podrían modificar o sustituir los sistemas o aplicaciones de información actuales por otras tecnologías de la información eficaces. EL modelo de proceso revisado se emplea como base para la especificación de software nuevo o revisado para dar soporte a la función de negocio. 3.6.6 INGENIERIA DE PRODUCTOS La ingeniería de productos (o Ingeniería de sistemas de computadora) es una actividad de resolución de problemas. Se localiza, analiza y asigna la información, función y comportamiento del producto deseado a componentes individuales de ingeniería. Análisis de Sistema El análisis del sistema se lleva a cabo con los siguientes objetivos en mente:

Identificar la necesidad del cliente;

Evaluar el concepto del sistema para establecer la viabilidad

Realizar un análisis técnico y económico

Asignar funciones al hardware, software, personal, bases de datos y otros elementos del sistema

Establecer las restricciones de presupuesto y planificación temporal

Crear una definición de sistema que forme el fundamento de todo el trabajo de ingeniería .Se requiere un gran dominio del hardware y software para conseguir con éxito los objetivos mencionados anteriormente.


SEMIPRESENCIAL


CAPITULO IV

4. IDENTIFICACION DE NECESIDADES El primer paso del proceso de análisis del sistema afecta a la identificación de la necesidad. El analista se reúne con el cliente y el usuario final. La intención es entender los objetivos del producto y definir las metas necesarias para alcanzar esos objetivos. Una vez que se han identificado las metas globales, el analista pasa a la evaluación de la información suplementaria: ¿Existe la tecnología para construir el sistema ?¿Qué recursos especiales de desarrollo y fabricación serán necesarios ?¿Qué límites se han puesto al presupuesto y a la planificación temporal? Si el nuevo es un producto a desarrollar para venderlo a muchos clientes, se plantean además las siguientes cuestiones: ¿Cuál es el mercado potencial del producto ?¿Cómo es comparativamente este producto con los de la competencia ?¿Qué posición ocupa este producto en la línea general de producción de la compañía? Esta información es reunida por el analista en base a las reuniones y entrevistas con el cliente, la comunicación cliente – analista originará modificaciones a esta información. 4.1 ESTUDIO DE VIABILIDAD Todos los proyectos son posibles si se tiene finitos recursos y tiempo. Desgraciadamente, el desarrollo de un sistema o producto basado en computadora es muy probable que esté plagado de escasees de recursos y de fechas de entrega difíciles (no realistas). Es necesario y prudente evaluar la viabilidad de un proyecto cuanto antes. Se pueden evitar meses o años de esfuerzo, miles o millones y un bochorno profesional si se reconoce un sistema mal concebido en la pronta fase de definición. La viabilidad y el análisis de riesgo están relacionados de muchas maneras. Si el riesgo del proyecto es alto, la viabilidad de producir software de calidad se reduce. Durante la ingeniería de producto, sin embargo, concentramos nuestra atención en cuatro áreas principales de interés: Viabilidad económica, Una evaluación del costo de desarrollo sopesado con los ingresos netos o beneficios obtenidos del sistema o producto desarrollado Viabilidad técnica, un estudio de función, rendimiento y restricciones que pueden afectar a la consecución de un sistema aceptable. Viabilidad legal, Determinar infracción, violación o responsabilidad legal que se podría incurrir durante el desarrollo del sistema. Alternativas, Una evaluación de los enfoques alternativos al desarrollo del sistema o producto.


SEMIPRESENCIAL


No es necesario un estudio de viabilidad para sistemas en que la justificación económica es obvia, el riesgo técnico es bajo, se esperan pocos problemas legales y no existe ninguna alternativa razonable. 4.1.1 ANÁLISIS ECONÓMICO Entre la información más importante contenida en un estudio de viabilidad está el análisis costo/ beneficio: una valoración de la justificación económica para un proyecto de sistema basado en computadora. El análisis costo/beneficio determina los costos para el desarrollo del proyecto y los relaciona contra los beneficios tangibles. El análisis costo/beneficio es complicado por criterios que varían con las características del sistema a desarrollar, el tamaño relativo del proyecto y los beneficios esperados de la inversión como parte del plan estratégico de la compañía. El analista puede estimar cada costo y usar después el desarrollo y los costos sucesivos para determinar la recuperación de lo invertido, un punto de beneficio cero y un período de rentabilidad. Solo invirtiendo tiempo para evaluar la viabilidad reducimos las posibilidades de una grave situación embarazosa en etapas posteriores del proyecto de un sistema. 4.1.2 ANÁLISIS TÉCNICO Durante el análisis técnico, el analista evalúa los principios técnicos del sistema al mismo tiempo que se recoge información adicional sobre el rendimiento, fiabilidad, características de mantenimiento y productividad. En algunos casos, esta frase del análisis del sistema también incluye una cierta cantidad de investigación y diseño. El análisis técnico empieza con una valoración de la viabilidad técnica del sistema propuesto. ¿Qué tecnologías se requieren para lograr el funcionamiento y rendimiento del sistema ?¿Qué nuevos materiales, métodos o procesos se necesitan y cuál es su riesgo de desarrollo ?¿Cómo afectarán estos aspectos tecnológicos a los costos? Las herramientas disponibles para un análisis técnico se obtienen de técnicas de optimización y modelos matemáticos, probabilidades y estadísticas, teoría de colas y de control, por nombrar unas pocas. Es importante resaltar, sin embargo, que no siempre es posible una evaluación analítica. El modelado es un mecanismo eficaz para el análisis técnico de sistemas basados en computadora. Los resultados obtenidos del análisis técnico forman la base para otra decisión de continuar/abandonar sobre el sistema. Si el riesgo es grave , si los modelos indican que no se puede conseguir la función o rendimiento deseados , si las piezas no encajan perfectamente unas con otras , Hay que buscar un nuevo planteamiento.... 4.2 MODELADO DE LA ARQUITECTURA DEL SISTEMA


SEMIPRESENCIAL


Todos los sistemas basados en computadora pueden modelarse como la transformación empleando una arquitectura del tipo entrada-proceso-salida. Últimamente se han incluido dos características adicionales del sistema: proceso de interfaz de usuario y proceso del mantenimiento y autocomprobación. Mediante la representación de entrada-proceso-salida, proceso de la interfaz de usuario y de autocomprobación un ingeniero de sistemas puede crear un modelo de componentes de sistema que establezca el fundamento para análisis de requisitos posteriores y etapas de diseño en cada una de las disciplinas de ingeniería. Las dos herramientas que se usan en este proceso son: el diagrama de contexto de la arquitectura y el diagrama de flujo de arquitectura. El diagrama de contexto establece el límite de información entre el sistema que se esta implementando y el entorno en que va a operar. Y por otro lado esta el de flujo que es el flujo de información a través de las regiones y se usa para guiar al ingeniero de sistemas. 4.3 MODELADO Y SIMULACION DEL SISTEMA Muchos sistemas basados en computadora interaccionan con el mundo real de forma reactiva. Es decir, los acontecimientos del mundo real son vigilados por el hardware y el software que componen el sistema y basándose en esos eventos, el sistema aplica su control sobre las máquinas, procesos e incluso las personas que motivan los acontecimientos. Hoy en día se utilizan herramientas CASE en el modelado y simulación de sistemas para ayudar a eliminar sorpresas cuando se construyen sistemas reactivos basados en computadora. Estas herramientas se aplican durante el proceso de ingeniería del sistema, mientras se están especificando las necesidades del hardware, software, bases de datos y de personas. 4.4 ESPECIFICACION DEL SISTEMA La especificación del sistema es un documento que sirve como fundamento para la ingeniería hardware, software, bases de datos y humana. Describe la función y el rendimiento de un sistema basado en computadora y las restricciones que gobernarán su desarrollo. La especificación delimita cada elemento del sistema asignado. Por ejemplo: proporciona al ingeniero del software una indicación del papel del software dentro del contexto del sistema en su totalidad y los distintos subsistemas. Especificando además lo que se introduce y se saca del sistema. 4.5 TÉCNICAS ORIENTADAS A OBJETOS

Principio de la Ingeniería de Software


SEMIPRESENCIAL


“la gran ingeniería es una ingeniería SENCILLA” Actualidad y tendencia del desarrollo de software Toda metodología debe realizar una representación más natural y real.

METODOLOGÍA

EVOLUCIÓN (Generaciones)

ESTRUCTURAL ORIENTADA A OBJETOS

OMT UML ANÁLISIS Y DISEÑO

ORIENTADO A OBJETOS

DIAGRAMA DE COMPONENTES Y DE

DISTRIBUCIÓN

OBJETO

PROGRAMACIÓN

POR COMPONENTES

Y POR OBJETOS

REDES Y

COMUNICACIONES

DISTRIBUIDAS


SEMIPRESENCIAL


Primera Generación

Data de los 50’ Primera generación de Hardware (Tubos al vacío) Programación por cable

Segunda Generación

Data de los 60’ Transistores Aparecen los lenguajes de programación (FORTRAN - BASIC) Inicia el desarrollo de software Surge la crisis del software Se define el Ciclo de Vida del Software

CLÁSICO Tercera Generación

Data de los 70’ y 80’ Tercera y Cuarta Generación del Hardware (Circuitos Integrados y

Microprocesador) Apogeo de los lenguajes de programación Alto desarrollo del software comercial y genérico Se profundiza la crisis del software Aparece la técnica estructurada moderna de YOURDON Se incorporan técnicas de administración para: El control de proyectos de planificación Manejo de grupos de trabajo

Cuarta Generación

Data de los finales de los 80’ y desde los 90’ en adelante Quinta Generación del Hardware (Computadoras Inteligentes) Desarrollo de la técnicas orientadas a objetos

o OMT

CASCADA

PROTOTIPO

ESPIRAL


SEMIPRESENCIAL


o UML o Desarrollo de áreas específicas como:

Visual Electrónica Inteligencia artificial Simulación

ALCANCE Todo se representa como un objeto.

Metodologías

Análisis Orientado a Objetos o Análisis de objetos

Diagramas orientados a objetos

De casos de uso

De clases

De secuencia Diseño Orientado a Objetos

Diagramas orientados a objetos

De actividades

INGENIERIA DE SISTEMAS

INGENIERIA DE REDES

INGENIERIA MANUFACTURA Y

PRODUCCIÓN

INGENIERIA DE

CONOCIMIENTO

OBJETO


SEMIPRESENCIAL


De componentes

De distribución Herramientas CASE

o Racional Rose o Power Designer

4.6 CARACTERÍSTICAS Tiene una representación natural y real porque un objeto se le considera natural y real. Posee mayor complejidad. Posee mayor reusabilidad. Aplicación total de la GUI

Define estructuras más estables para la reutilización.

OBJETO

FÍSICO LÓGICO

EVENTO CLIC


SEMIPRESENCIAL


CAPITULO V

5. METODOLOGÍAS DE DESARROLLO DE SOFTWARE 5.1 METODOLOGÍA vs. CICLO DE VIDA Una metodología puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo de vida indica qué es lo que hay que obtener a lo largo del desarrollo del proyecto pero no cómo hacerlo. La metodología indica cómo hay que obtener los distintos productos parciales y finales 5.1.1 GENERACIONES DE METODOLOGÍA

Desarrollo Convencional (Sin Metodología).

Desarrollo Estructurado.

Desarrollo Orientado a Objetos. 5.1.2 DESARROLLO CONVENCIONAL

Los resultados finales son impredecibles

No hay forma de controlar lo que está sucediendo

Los cambios organizativos afectan negativamente al proceso de desarrollo EJEMPLO DE PROGRAMACIÓN CONVENCIONAL 10 CLS 20 A=10 30 INPUT B 40 IF B=A THEN GOTO 50 ELSE GOTO 70 50 PRINT “A Y B SON IGUALES” 60 GOTO 100 70 IF A>B THEN GOTO 80 ELSE GOTO 90 80 B= B + 1; GOTO 40 90 B= B - 1; GOTO 40 100 END 5.1.3 DESARROLLO ESTRUCTURADO

Programación estructurada

Diseño estructurado

Análisis estructurado Especificaciones funcionales:

Gráficas

Particionadas

Mínimamente redundantes


SEMIPRESENCIAL


EJEMPLO DE PROGRAMACIÓN ESTRUCTURADA PROGRAMA NUMEROS IGUALES BEGIN CLEARSCREEN; A :=10 ; INPUT B; REPEAT IF B=A THEN PRINT “A Y B SON IGUALES” ELSE REDUCEDIFERENCIA(A, B); UNTIL B=A; END; PROCEDURE REDUCEDIFENCIA(A, B); BEGIN IF A>B THEN B:= B+1 ELSE B:= B - 1 END RELACION HISTORICA DE LAS PRINCIPALES METODOLOGIAS

5.1.4 DESARROLLO ORIENTADO A OBJETOS La esencia del desarrollo orientado a objetos es la identificación y organización de conceptos del dominio de la aplicación y no tanto de su representación final en un lenguaje de programación.


SEMIPRESENCIAL


5.2 METODOLOGÍAS ORIENTADAS A OBJETOS

Se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo orientado al objeto.

Aparece una nueva forma de concebir los lenguajes de programación y su uso al incorporarse bibliotecas de clases y otros componentes reutilizables.

Hay un alto grado de iteración y solapamiento, lo que lleva a una forma de trabajo muy dinámica.

Son interactivas e incrementales.

Fácil de dividir el sistema en varios subsistemas independientes.

Existencia de reglas predefinidas

Cobertura total del ciclo de desarrollo

Verificaciones intermedias

Planificación y control

Comunicación efectiva

Utilización sobre un abanico amplio de proyectos

Fácil formación

Herramientas CASE

Actividades que mejoren el proceso de desarrollo

Soporte al mantenimiento

Soporte de la reutilización de software 5.2.1 CLASIFICACIÓN DE LAS METODOLOGÍAS

Estructuradas o Orientadas a Procesos o Orientadas a datos

Jerárquicas No Jerárquicas Mixtas

Orientadas a Objetos

Para Sistemas de Tiempo Real 5.2.2 METODOLOGÍAS ESTRUCTURADAS

Orientada a Procesos o Diagramas de Flujo de Datos o Diccionario de Datos o Especificaciones de procesos


SEMIPRESENCIAL


5.2.3 METODOLOGÍA DE YOURDON/CONSTANTINE

Realizar los DFD del sistema

Realizar el diagrama de estructuras

Evaluar el diseño

Preparar el diseño para la implantación METODOLOGIAS ORIENTADAS A DATOS JERARQUICOS La estructura de control del programa debe ser jerárquica y se debe derivar de la estructura de datos del programa El proceso de diseño consiste en definir primero las estructuras de los datos de entrada y salida, mezclarlas todas en una estructura jerárquica de programa y después ordenar detalladamente la lógica procedimental para que se ajuste a esta estructura. El diseño lógico debe preceder y estar separado del diseño físico. 5.2.4 METODOLOGIAS ORIENTADAS A DATOS NO JERARQUICOS METODOLOGÍA INGENIERÍA DE LA INFORMACIÓN Planificación: construir una arquitectura de la Información y una estrategia que soporte los objetivos de la organización Análisis: comprender las áreas del negocio y determinar los requisitos del sistema


SEMIPRESENCIAL


Diseño: establecer el comportamiento del sistema deseado por el usuario y que sea alcanzable por la tecnología Construcción: construir sistemas que cumplan los tres niveles anteriores METODOLOGIAS PARA SISTEMAS DE TIEMPO REAL

Manejo de interrupciones

Comunicación y sincronización entre tareas

Gestión de procesos concurrentes

Respuesta oportuna ante eventos externos

Datos continuos o discretos

Se está produciendo una evolución de las metodologías orientadas a objetos para desarrollos de sistemas de tiempo real

PRINCIPALES METODOLOGIAS DE DESARROLLO METODOLOGIA MERISE Fases de la Metodología:

Estudio Preliminar

Estudio Detallado

Implementación

Realización y puesta en marcha

METODOLOGIA METRICA FASE 0: Plan de Sistemas de Información FASE 1: Análisis de Sistemas FASE 2: Diseño de Sistemas


SEMIPRESENCIAL


FASE 3: Construcción de Sistemas FASE 4: Implantación de Sistemas 5.3 CICLO DE VIDA DEL SISTEMA ORIENTADO A OBJETOS Es el contenido de actividades secuenciales y organizadas para garantizar el éxito del proceso. Tipos:

Clásico

Cascada

Prototipo

Espiral

Cuarta Generación

Desarrollo rápido de aplicaciones

Combinado Fases: Actividades 5.3.1 ESTUDIO PELIMINAR Conocimiento general de la empresa y del proyecto o sistema. Actividades:

Recolección de información

ESTUDIO

PRELIMINAR

ANÁLISIS

ORIENTADO

A OBJETOS

DISEÑO

ORIENTADO

A OBJETOS

CONSTRUCCIÓN

ORIENTADO

A OBJETOS

IMPLEMENTACIÓN


SEMIPRESENCIAL


Determinar la información empresarial

Identificación y definición del proyecto (módulos)

Fijación de objetivos

Verificar la viabilidad 5.3.2 ANÁLISIS ORIENTADO A OBJETOS Conocimiento detallado del sistema. ¿Qué hace el sistema? Actividades:

Investigación detallada

Descripción detallada del sistema (sistema actual SA)

Estudio de requerimientos

Definición del sistema propuesto (SP)

Identificación y definición de objetos

Diagramas del análisis orientado a objetos

Modularidad (diagrama de paquetes DP)

Funcionalidad de objetos (diagrama de casos de uso DCU, diagrama de clases DC)

Análisis de datos orientado a objetos (MOR)

Comportamiento de objetos (diagrama de secuencias DS, diagrama de colaboración DCol)

EVALUACIÓN ECONÓMICA (DE TODO EL PROYECTO)

Documentación

Planificación 5.3.3 DISEÑO ORIENTADO A OBJETOS Proceso para generar las especificaciones técnicas del diseño para la construcción. ¿Cómo automatizar el sistema? Actividades:

Definir el ámbito del software

Selección de plataforma

Sistema operativo

Administrador de base de datos

Lenguaje de programación

CASE orientado a objetos

Especificar modularidad y abstracción del software


SEMIPRESENCIAL


Generación de diagramas técnicos:

Diseño de servicios (diagrama de estados DE, diagrama de actividades DA)

Diseño de datos orientados a objetos (Modelo físico de datos MFD)

Diseño de implementación e interfaz (diagrama de componentes DCom, diagrama de distribución DD)

Diseñar la administración del software

Documentación

Planificación 5.3.44CONSTRUCCION ORIENTADA A OBJETOS Generar el software. Actividades:

Generación y pruebas a la base de datos

Verificación y consistencia de interfaz

Estandarización

Consistencia

Con los programas

Con los datos especiales

Codificación de módulos primarios

Realizar pruebas

Programar módulos transaccionales

Realizar pruebas

Generar módulos complementarios o Usuarios o Ayuda o Ejecutables

Integración del software

Pruebas

Generar el manual de usuario

Documentación

Planificación 5.3.5 IMPLEMENTACIÓN Pasar a productividad el software con garantía de rendimiento. Actividades:

Verificar el rendimiento óptimo del centro de cómputo

Instalación y configuración

Capacitación de usuarios

Pruebas reales con usuarios


SEMIPRESENCIAL


Verificación de rendimiento con técnicos

Garantizar el software

Obtener la aprobación


SEMIPRESENCIAL


Secuencia de los Diagramas


SEMIPRESENCIAL


1.3.4 Estimación del esfuerzo Desarrollo 10-40% Mantenimiento 90-60% Características: Se asume un dominio metodológico Desconocimiento del sistema, por lo que se da mayor tiempo al análisis. 5.4 OBJETO Entidad real y abstracta con una estructura propia que le diferencia de otros. Representación

Clase:

Categoría

Generación

Pocas propiedades

Pocos atributos

Pocos servicios

Baja aplicación Objeto:

ANÁLISIS 40%

DISEÑO 20%

CONSTRUCCIÓN 40%


SEMIPRESENCIAL


Instancia

Especificación

Varias propiedades

Varios atributos

Varios servicios

Constante aplicación 5.4.1 CLASIFICACIÓN DE LOS OBJETOS: Físicos Ocupa un lugar en el espacio Lógico Hace referencia a ideas o definiciones Evento Transacción Documento Papeles normalizados Estructura De compras o lugar de trabajo Estructura de un objeto Atributos Son los datos. Definen estructuras de datos para los modelos de datos. Servicios Son las actividades que modifican al objeto. Características de los objetos Encapsulamiento Ocultamiento de información Integra: Atributos Servicios Herencia Mecanismo para definir las propiedades de un objeto en base a existentes mediante estructura jerárquica de nivel superior a descendientes.


SEMIPRESENCIAL


Tipos:

Simple

Compuesta

Polimorfismo 5.4.2 ANÁLISIS ORIENTADO A OBJETOS 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: 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 metodologí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.


SEMIPRESENCIAL


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 por 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 específico de cada uno de los elementos o componentes del Sistema y las reglas de su manejo y mantenimiento. Un Análisis de Sistema se lleva a cabo teniendo en cuenta los siguientes 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 presupuestos y planificación temporal. Cree una definición del sistema que forme el fundamento de todo el trabajo de Ingeniería. 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. 5.4.3 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 requerimientos, 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 lo dividen en cinco partes:


SEMIPRESENCIAL


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 cliente solo de todas maneras tendría que ser modificado, durante la identificación de las necesidades. MODELADO DE LA ARQUITECTURA DEL SISTEMA. Cuando queremos dar a entender mejor lo que vamos a construir en el caso de edificios, Herramientas, Aviones, Maquinas, se crea un modelo idéntico, pero en menor escala (mas pequeño). Sin embargo cuando aquello que construiremos es un Software, nuestro modelo debe tomar una forma diferente, deben representar todas las funciones y subfunciones de un Sistema. Los modelos se concentran en lo que debe hacer el sistema no en como lo hace, estos modelos pueden incluir notación gráfica, información y comportamiento del Sistema. Todos los Sistemas basados en computadoras pueden modelarse como transformación de la información empleando una arquitectura del tipo entrada y salida. ESPECIFICACIONES DEL SISTEMA. Es un Documento que sirve como fundamento para la Ingeniería Hardware, software, Base de datos, e ingeniería Humana. Describe la función y rendimiento de un Sistema basado en computadoras y las dificultades que estarán presente durante su desarrollo. Las Especificaciones de los requisitos del software se producen en la terminación de la tarea del análisis. 5.4.4 ANÁLISIS DE OBJETOS La abstracción es el nivel de detalle. Desde el punto de vista del objeto: Se le conoce como FACTORIZACION, que consiste en eliminar las diferencias entre objetos, identificando las propiedades comunes para formar una jerarquia de datos.


SEMIPRESENCIAL


Ejemplo: PERSONA

CLIENTE común PROVEEDOR Dirección Nombre Teléfono Servicios: Nivel de abstracción: Servicios Actividades tareas EJERC ESTRUCTURA ENTRE OBJETOS Es la generalización o parte de… Define una estructura jerárquica de clasificación de lo general a lo específico. Se identifica la herencia que existe.

Código

Fecha ingreso

Fecha nacimiento

.

.

RUC

e-mail

fax

.

.

MAYOR DETALLE


SEMIPRESENCIAL


Representación con UML:

TRANSPORTE

MARÍTIMO TERRESTRE AÉREO URBANO INTERPROVINCIAL SELECTIVO POPULAR

AGREGACIÓN O PARTE DE… Define una estructura jerárquica de formación o composición de las partes al todo. Identifica CARDINALIDAD.

H

E

R

E

N

C

I

A


SEMIPRESENCIAL


Representación UML:

PC

DISPOSITIVOS CPU

ENTRADA SALIDA CASE MAINBOARD ALMACENAMIENTO AT ATX TIPOS DE AGRAGACIÓN: Por referencia Por valor COMUNICACIÓN ENTRE DATOS Consiste en ejecutar un servicio del objeto receptor mediante el mensaje del objeto emisor. Ejemplo.: CATEGORÍA PRODUCTO IngresarNuevaCategoria ingresarNuevoProducto


SEMIPRESENCIAL


Objeto emisor objeto receptor IngresarNuevoProducto Relaciones:

Estructura entre datos

Generalización

Agrupación

Estructura de almacenamiento o 1-1 o 1-n o N-n

Mensaje DIAGRAMAS TÉCNICOS ORIENTADOS A OBJETOS MOLULARIDAD DIAGRAMA DE PAQUETES (DP) Representa la modularidad del proyecto o del sistema.

ELEMENTO REPRESENTACIÓN DESCRIPCIÓN

PAQUETE

Sistema Subsistema Módulos Puede ser un área organizacional Sistemas externos que se tienen comunicación Contenido de detalle técnico

COMUNICACIÓN

-----------------

RELACIÓN ENTRE PAQUETES

FUNCIONALIDAD DIAGRAMA DE CASOS DE USO (DCU) Representa los casos de uso o ACTIVIDADES O FUNCIONALIDAD del sistema.

ELEMENTO REPRESENTACIÓN DESCRIPCIÓN


SEMIPRESENCIAL


Representa el entorno que influye y ejecuta la funcionalidad del sistema o módulo. 5.5 EJERCICIO PROPUESTO: El departamento de obras públicas de una gran ciudad ha decidido realizar un sistema basado en computadora de seguimiento y reparación de baches (SSRB). A medida que se informa sobre cada bache, se le asigna un número de identificación y se guarda con la calle en la que se encuentra, su tamaño (en escala de 1 a 10), su posición (en el medio, o a un lado, entre otros), su distrito (determinado a partir de la calle) y una prioridad de reparación.(Determinada a partir de su tamaño). A cada bache se asocian datos de petición de obra, incluyendo la ubicación y el tamaño, la brigada de reparación identificada por un número, la cantidad de trabajadores de la brigada, el equipamiento asignado, las horas de reparación, el estado del bache (obra en curso, reparado, reparación temporal, no reparado), la cantidad de material de relleno usado y el coste de la reparación (calculado con las horas dedicadas, el número de trabajadores, el material y el equipamiento utilizado). Finalmente, se crea un archivo de daños para mantener la información sobre los daños reportados debidos a la existencia del bache, incluyendo el nombre del ciudadano, su dilección, su teléfono, el tipo daño y el coste del subsanamiento del daño. El sistema SSRB es un sistema interactivo. Utilice el análisis estructurado para modelizar el SSRB.

ACTOR

Agente Referencia a una persona o grupo de personas Área organizacional o punto de trabajo

CASO DE USO

Es una actividad

RELACIÓN

Es una comunicación y la ejecución del caso de uso. Identifica secuencia de casos de uso


SEMIPRESENCIAL


DIAGRAMA DE CLASES (DC) Primer diagrama sin módulos. DIAGRAMA DE INTERFAZ EJERCICIO PROPUETO: El súper-comisariato está ampliando su sistema y desea también integrarlo al sistema actual que controla el inventario de bodega. Se requiere que el sistema controle todo el mundo transaccional como fecha, origen o destino y las diferentes valoraciones, aquí se realizan compras, ventas, consumos, transferencias y devoluciones, las devoluciones únicamente en compras y ventas, además, se requiere controlar los parámetros de funcionalidad del sistema como el IVA y los porcentajes para realizar las diferentes cotizaciones de acuerdo a la ocasión y al destino. El destino principalmente es nuestro cliente, el cual puede ser un empleado, administrador e incluso el mismo usuario del sistema. El usuario del sistema se configura por globalidad que es un administrador y por especialidad que manejará módulos específicos del sistema. Como requerimientos de amigabilidad del software se requiere que la interfaz sea para acceso, configuración o manipulación, cada una de ellas compuesta por ventanas, menús y controles, cabe indicar que existen varios tipos de controles. ANÁLISIS DE DATOS ORIENTADO A OBJETOS MODELOS DE DATOS Un modelo de datos es una serie de conceptos que puede utilizarse para describir un conjunto de datos y las operaciones para manipularlos. Hay dos tipos de modelos de datos: los modelos conceptuales y los modelos lógicos. Los modelos conceptuales se utilizan para representar la realidad a un alto nivel de abstracción. Mediante los modelos conceptuales se puede construir una descripción de la realidad fácil de entender. En los modelos lógicos, las descripciones de los datos tienen una correspondencia sencilla con la estructura física de la base de datos. En el diseño de bases de datos se usan primero los modelos conceptuales para lograr una descripción de alto nivel de la realidad, y luego se transforma el esquema conceptual en un esquema lógico. El motivo de realizar estas dos etapas es la dificultad de abstraer la estructura de una base de datos que presente cierta complejidad. Un esquema es un conjunto de representaciones lingüísticas o gráficas que describen la estructura de los datos de interés. Los modelos conceptuales deben ser buenas herramientas para representar la realidad, por lo que deben poseer las siguientes cualidades: Expresividad: deben tener suficientes conceptos para expresar perfectamente la realidad. Simplicidad: deben ser simples para que los esquemas sean fáciles de entender.


SEMIPRESENCIAL


Minimalidad: cada concepto debe tener un significado distinto. Formalidad: todos los conceptos deben tener una interpretación única, precisa y bien definida. En general, un modelo no es capaz de expresar todas las propiedades de una realidad determinada, por lo que hay que añadir aserciones que complementen el esquema. EL MODELO E-R El modelo E-R es el modelo conceptual más utilizado para el diseño conceptual de bases de datos. Fue introducido por Peter Chen en 1976. El modelo E-R está formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones gráficas y lingüísticas. Originalmente, el modelo E-R sólo incluía los conceptos de entidad, relación y atributo. Más tarde, se añadieron otros conceptos, como los atributos compuestos y las jerarquías de generalización, en lo que se ha denominado modelo entidad-relación extendido. ENTIDAD Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona, concepto abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes, empresas, oficios, diseños de productos, conciertos, excursiones, etc. Las entidades se representan gráficamente mediante rectángulos y su nombre aparece en la parte superior. Un nombre de entidad sólo puede aparecer una vez en el esquema conceptual. EMPLEADOS

Hay dos tipos de entidades: fuertes y débiles. Una entidad débil es una entidad cuya existencia depende de la existencia de otra entidad. Una entidad fuerte es una entidad que existe pos sí sola y no depende de la existencia de otras. RELACIÓN (INTERRELACIÓN)

# CI * Nombre * Apellido * Dirección º Teléfono * Cargo º Jefe


SEMIPRESENCIAL


Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene dos extremos, cada uno de ellos con un nombre que describe su función. Las relaciones se representan gráficamente mediante líneas continuas o entrecortadas, dependiendo de la opcionalidad de las mismas. R1 R2

Las entidades que están involucradas en una determinada relación se denominan entidades participantes. El número de participantes en una relación es lo que se denomina grado de la relación. Por lo tanto, una relación en la que participan dos entidades es una relación binaria; si son tres las entidades participantes, la relación es ternaria; entre otros. Una relación recursiva es una relación donde la misma entidad participa más de una vez en la relación con distintos papeles. El nombre de estos papeles es importante para determinar la función de cada participación. La cardinalidad con la que una entidad participa en una relación especifica el número mínimo y el número máximo de correspondencias en las que puede tomar parte cada ocurrencia de dicha entidad. La participación de una entidad en una relación es obligatoria (total) si la existencia de cada una de sus ocurrencias requiere la existencia de, al menos, una ocurrencia de la otra entidad participante. Si no, la participación es opcional (parcial). Las reglas que definen la cardinalidad de las relaciones son las reglas de negocio. A veces, surgen problemas cuando se está diseñado un esquema conceptual. Estos problemas, denominados trampas, suelen producirse a causa de una mala interpretación en el significado de alguna relación, por lo que es importante comprobar que el esquema conceptual carece de dichas trampas. En general, para encontrar las trampas, hay que asegurarse de que se entiende completamente el significado de cada relación. Si no se entienden las relaciones, se puede crear un esquema que no represente fielmente la realidad. Una de las trampas que pueden encontrarse ocurre cuando el esquema representa una relación entre entidades, pero el camino entre algunas de sus ocurrencias es ambiguo. El

Dueño de

Perteneciente a

Relación 1:N

Obligatorio - Opcional


SEMIPRESENCIAL


modo de resolverla es reestructurando el esquema para representar la asociación entre las entidades correctamente. Otra de las trampas sucede cuando un esquema sugiere la existencia de una relación entre entidades, pero el camino entre una y otra no existe para algunas de sus instancias. En este caso, se produce una pérdida de información que se puede subsanar introduciendo la relación que sugería el esquema y que no estaba representada. ATRIBUTO Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los atributos representan las propiedades básicas de las entidades y de las relaciones. Toda la información extensiva es portada por los atributos. Gráficamente, se representan mediante nombres escritos al interior de los rectángulos que representan a las entidades. Cada atributo tiene un conjunto de valores asociados denominado dominio. El dominio define todos los valores posibles que puede tomar un atributo. Puede haber varios atributos definidos sobre un mismo dominio. Por su opcionalidad, los atributos se dividen en obligatorios y opcionales. Los obligatorios son aquellos que deben tener un valor válido en cada instancia de la entidad y de ninguna manera puede ser nulo. Por otro lado, los atributos opcionales pueden como no pueden tener un valor válido en cada instancia de una entidad. Los atributos también pueden clasificarse en monovalentes o polivalentes. Un atributo monovalente es aquel que tiene un solo valor para cada ocurrencia de la entidad o relación a la que pertenece. Un atributo polivalente es aquel que tiene varios valores para cada ocurrencia de la entidad o relación a la que pertenece. A estos atributos también se les denomina multivaluados, y pueden tener un número máximo y un número mínimo de valores. La cardinalidad de un atributo indica el número mínimo y el número máximo de valores que puede tomar para cada ocurrencia de la entidad o relación a la que pertenece. El valor por omisión es 1. . CLAVES Una clave de una entidad es un atributo o conjunto de atributos que , de alguna manera, identifica cada ocurrencia de esa entidad. Las claves, dentro del modelo Entidad – Relación, se clasifican en los siguientes tipos:

Superclaves

Claves Candidatas

Clave Primaria

Claves Alternas


SEMIPRESENCIAL


Toda entidad tiene al menos una clave primaria y puede tener varias claves alternas. Las claves primarias se representan gráficamente con un signo de numeral junto al nombre del mismo. JERARQUÍA DE GENERALIZACIÓN Una entidad E es una generalización de un grupo de entidades E1, E2,…., En. Si cada ocurrencia de cada una de esas entidades es también una ocurrencia de E. Cada jerarquía es total o parcial, y exclusiva o superpuesta: Es total si cada instancia de la entidad genérica corresponde al menos a una instancia de las subentidades. Es parcial si existe alguna instancia de la entidad genérica que no corresponde con ninguna ocurrencia de ninguna subentidad. Una jerarquía es exclusiva si cada instancia de la entidad genérica corresponde, como mucho, con una instancia de una sola de las subentidades. Es superpuesta si existe alguna instancia de la entidad genérica que corresponda a instancias de dos o más subentidades diferentes. DISEÑO LÓGICO DE BASES DE DATOS El objetivo del diseño lógico es convertir los esquemas conceptuales locales en un esquema lógico global que se ajuste al modelo de DBMS sobre el que se vaya a implementar el sistema. Mientras que el objetivo fundamental del diseño conceptual es la compleción y expresividad de los esquemas conceptuales locales, el objetivo del diseño lógico es obtener una representación que use, del modo más eficiente posible, los recursos que el modelo de DBMS posee para estructurar los datos y para modelar las restricciones Los modelos de bases de datos más extendidos son el modelo relacional, el modelo de red y el modelo jerárquico. El modelo orientado a objetos es también muy popular, pero no existe un modelo estándar orientado a objetos. El modelo relacional (y los modelos previos) carecen de ciertos rasgos de abstracción que se usan en los modelos conceptuales. Por lo tanto, un primer paso en la fase del diseño lógico consistirá en la conversión de esos mecanismos de representación de alto nivel en términos de las estructuras de bajo nivel disponibles en el modelo relacional. METODOLOGÍA DE DISEÑO LÓGICO EN EL MODELO RELACIONAL


SEMIPRESENCIAL


La metodología que se va a seguir para el diseño lógico en el modelo relacional consta de dos fases, cada una de ellas compuesta por varios pasos que se detallan a continuación.

Construir y validar los esquemas lógicos locales para cada vista de usuario.

Convertir los esquemas conceptuales locales en esquemas lógicos locales.

Derivar un conjunto de relaciones (tablas) para cada esquema lógico local.

Validar cada esquema mediante la normalización.

Validar cada esquema frente a las transacciones del usuario.

Dibujar el diagrama entidad-relación.

Definir las restricciones de integridad.

Revisar cada esquema lógico local con el usuario correspondiente.

Construir y validar el esquema lógico global.

Mezclar los esquemas lógicos locales en un esquema lógico global.

Validar el esquema lógico global.

Estudiar el crecimiento futuro.

Dibujar el diagrama entidad-relación final.

Revisar el esquema lógico global con los usuarios. En la primera fase, se construyen los esquemas lógicos locales para cada vista de usuario y se validan. En esta fase se refinan los esquemas conceptuales creados durante el diseño conceptual, eliminando las estructuras de datos que no se pueden implementar de manera directa sobre el modelo que soporta el DBMS, en el caso que nos ocupa, el modelo relacional. Una vez hecho esto, se obtiene un primer esquema lógico que se valida mediante la normalización y frente a las transacciones que el sistema debe llevar a cabo, tal y como se refleja en las especificaciones de requisitos de usuario. El esquema lógico ya validado se puede utilizar como base para el desarrollo de prototipos. Una vez finalizada esta fase, se dispone de un esquema lógico para cada vista de usuario que es correcto, comprensible y sin ambigüedad. Convertir los esquemas conceptuales locales en esquemas lógicos locales En este paso, se eliminan de cada esquema conceptual las estructuras de datos que los sistemas relacionales no modelan directamente: Eliminar las relaciones de muchos a muchos, sustituyendo cada una de ellas por una nueva entidad intermedia y dos relaciones de uno a muchos de esta nueva entidad con las entidades originales. La nueva entidad será débil, ya que sus ocurrencias dependen de la existencia de ocurrencias en las entidades originales. Eliminar las relaciones entre tres o más entidades, sustituyendo cada una de ellas por una nueva entidad (débil) intermedia que se relaciona con cada una de las entidades originales. La cardinalidad de estas nuevas relaciones binarias dependerá de su significado.


SEMIPRESENCIAL


Eliminar las relaciones recursivas, sustituyendo cada una de ellas por una nueva entidad (débil) y dos relaciones binarias de esta nueva entidad con la entidad original. La cardinalidad de estas relaciones dependerá de su significado. Eliminar las relaciones con atributos, sustituyendo cada una de ellas por una nueva entidad (débil) y las relaciones binarias correspondientes de esta nueva entidad con las entidades originales. La cardinalidad de estas relaciones dependerá del tipo de la relación original y de su significado. Eliminar los atributos multivaluados, sustituyendo cada uno de ellos por una nueva entidad (débil) y una relación binaria de uno a muchos con la entidad original. Revisar las relaciones de uno a uno, ya que es posible que se hayan identificado dos entidades que representen el mismo objeto (sinónimos). Si así fuera, ambas entidades deben integrarse en una sola. Eliminar las relaciones redundantes. Una relación es redundante cuando se puede obtener la misma información que ella aporta mediante otras relaciones. El hecho de que haya dos caminos diferentes entre dos entidades no implica que uno de los caminos corresponda a una relación redundante, eso dependerá del significado de cada relación. Una vez finalizado este paso es más correcto referirse a los esquemas conceptuales locales refinados como esquemas lógicos locales, ya que se adaptan al modelo de base de datos que soporta el DBMS escogido. DERIVAR UN CONJUNTO DE RELACIONES (TABLAS) PARA CADA ESQUEMA LÓGICO LOCAL En este paso, se obtiene un conjunto de relaciones (tablas) para cada uno de los esquemas lógicos locales en donde se representen las entidades y relaciones entre entidades, que se describen en cada una de las vistas que los usuarios tienen de la empresa. Cada relación de la base de datos tendrá un nombre, y el nombre de sus atributos aparecerá, a continuación, entre paréntesis. El atributo o atributos que forman la clave primaria se subrayan. Las claves ajenas, mecanismo que se utiliza para representar las relaciones entre entidades en el modelo relacional, se especifican aparte indicando la relación (tabla) a la que hacen referencia. A continuación, se describe cómo las relaciones (tablas) del modelo relacional representan las entidades y relaciones que pueden aparecer en los esquemas lógicos. Entidades fuertes. Crear una relación para cada entidad fuerte que incluya todos sus atributos simples. De los atributos compuestos incluir sólo sus componentes.


SEMIPRESENCIAL


Cada uno de los identificadores de la entidad será una clave candidata. De entre las claves candidatas hay que escoger la clave primaria; el resto serán claves alternativas. Para escoger la clave primaria entre las claves candidatas se pueden seguir estas indicaciones:

Escoger la clave candidata que tenga menos atributos.

Escoger la clave candidata cuyos valores no tengan probabilidad de cambiar en el futuro.

Escoger la clave candidata cuyos valores no tengan probabilidad de perder la unicidad en el futuro.

Escoger la clave candidata con el mínimo número de caracteres (si es de tipo texto).

Escoger la clave candidata más fácil de utilizar desde el punto de vista de los usuarios.

ENTIDADES DÉBILES Crear una relación para cada entidad débil incluyendo todos sus atributos simples. Añadir una clave ajena a la entidad de la que depende. Para ello, se incluye la clave primaria de la relación que representa a la entidad padre en la nueva relación creada para la entidad débil. A continuación, determinar la clave primaria de la nueva relación. Relaciones binarias de uno a uno. Para cada relación binaria se incluyen los atributos de la clave primaria de la entidad padre en la relación (tabla) que representa a la entidad hijo, para actuar como una clave ajena. La entidad hijo es la que participa de forma total (obligatoria) en la relación, mientras que la entidad padre es la que participa de forma parcial (opcional). Si las dos entidades participan de forma total o parcial en la relación, la elección de padre e hijo es arbitraria. Además, en caso de que ambas entidades participen de forma total en la relación, se tiene la opción de integrar las dos entidades en una sola relación (tabla). Esto se suele hacer si una de las entidades no participa en ninguna otra relación. Relaciones binarias de uno a muchos. Como en las relaciones de uno a uno, se incluyen los atributos de la clave primaria de la entidad padre en la relación (tabla) que representa a la entidad hijo, para actuar como una clave ajena. Pero ahora, la entidad padre es la de ``la parte del muchos'' (cada padre tiene muchos hijos), mientras que la entidad hijo es la de ``la parte del uno'' (cada hijo tiene un solo padre). Jerarquías de generalización. En las jerarquías, se denomina entidad padre a la entidad genérica y entidades hijo a las subentidades. Hay tres opciones distintas para representar las jerarquías. La elección de la más adecuada se hará en función de su tipo (total/parcial, exclusiva/superpuesta).


SEMIPRESENCIAL


Crear una relación por cada entidad. Las relaciones de las entidades hijo heredan como clave primaria la de la entidad padre. Por lo tanto, la clave primaria de las entidades hijo es también una clave ajena al padre. Esta opción sirve para cualquier tipo de jerarquía, total o parcial y exclusiva o superpuesta. Crear una relación por cada entidad hijo, heredando los atributos de la entidad padre. Esta opción sólo sirve para jerarquías totales y exclusivas. Integrar todas las entidades en una relación, incluyendo en ella los atributos de la entidad padre, los atributos de todos los hijos y un atributo discriminativo para indicar el caso al cual pertenece la entidad en consideración. Esta opción sirve para cualquier tipo de jerarquía. Si la jerarquía es superpuesta, el atributo discriminativo será multievaluado. Una vez obtenidas las relaciones con sus atributos, claves primarias y claves ajenas, sólo queda actualizar el diccionario de datos con los nuevos atributos que se hayan identificado en este paso. VALIDAR CADA ESQUEMA MEDIANTE LA NORMALIZACIÓN La normalización se utiliza para mejorar el esquema lógico, de modo que satisfaga ciertas restricciones que eviten la duplicidad de datos. La normalización garantiza que el esquema resultante se encuentra más próximo al modelo de la empresa, que es consistente y que tiene la mínima redundancia y la máxima estabilidad. La normalización es un proceso que permite decidir a qué entidad pertenece cada atributo. Uno de los conceptos básicos del modelo relacional es que los atributos se agrupan en relaciones (tablas) porque están relacionados a nivel lógico. En la mayoría de las ocasiones, una base de datos normalizada no proporciona la máxima eficiencia, sin embargo, el objetivo ahora es conseguir una base de datos normalizada por las siguientes razones: Un esquema normalizado organiza los datos de acuerdo a sus dependencias funcionales, es decir, de acuerdo a sus relaciones lógicas. El esquema lógico no tiene porqué ser el esquema final. Debe representar lo que el diseñador entiende sobre la naturaleza y el significado de los datos de la empresa. Si se establecen unos objetivos en cuanto a prestaciones, el diseño físico cambiará el esquema lógico de modo adecuado. Una posibilidad es que algunas relaciones normalizadas se desnormalicen. Pero la desnormalización no implica que se haya malgastado tiempo normalizando, ya que mediante este proceso el diseñador aprende más sobre el significado de los datos. De hecho, la normalización obliga a entender completamente cada uno de los atributos que se han de representar en la base de datos.


SEMIPRESENCIAL


Un esquema normalizado es robusto y carece de redundancias, por lo que está libre de ciertas anomalías que éstas pueden provocar cuando se actualiza la base de datos. Los equipos informáticos de hoy en día son mucho más potentes, por lo que en ocasiones es más razonable implementar bases de datos fáciles de manejar (las normalizadas), a costa de un tiempo adicional de proceso. La normalización produce bases de datos con esquemas flexibles que pueden extenderse con facilidad. El objetivo de este paso es obtener un conjunto de relaciones que se encuentren en la forma normal de Boyce-Codd. Para ello, hay que pasar por la primera, segunda y tercera formas normales. El proceso de normalización se describe más adelante en este texto. DIBUJAR EL DIAGRAMA ENTIDAD-RELACIÓN En este momento, se puede dibujar el diagrama entidad-relación final para cada vista de usuario que recoja la representación lógica de los datos desde su punto de vista. Este diagrama habrá sido validado mediante la normalización y frente a las transacciones de los usuarios. DEFINIR LAS RESTRICCIONES DE INTEGRIDAD Las restricciones de integridad son reglas que se quieren imponer para proteger la base de datos, de modo que no pueda llegar a un estado inconsistente. Hay cinco tipos de restricciones de integridad. Datos requeridos. Algunos atributos deben contener valores en todo momento, es decir, no admiten nulos. Restricciones de dominios. Todos los atributos tienen un dominio asociado, que es el conjunto los valores que cada atributo puede tomar. Integridad de entidad. La clave primaria de una entidad no puede ser nula, por lo tanto, las claves primarias de las relaciones no admiten nulos. Integridad referencial. Una clave extranjera enlaza cada tupla de la relación hijo con la tupla de la relación padre que tiene el mismo valor en su clave primaria. La integridad referencial dice que si una clave ajena tiene un valor (si es no nula), ese valor debe ser uno de los valores de la clave primaria a la que referencia. Hay varios aspectos a tener en cuenta sobre las claves ajenas para lograr que se cumpla la integridad referencial.


SEMIPRESENCIAL


¿Admite nulos la clave ajena? Cada clave ajena expresa una relación. Si la participación de la entidad hijo en la relación es total, entonces la clave ajena no admite nulos; si es parcial, la clave ajena debe aceptar nulos. ¿Qué hacer cuando se quiere borrar una ocurrencia de la entidad padre que tiene algún hijo? O lo que es lo mismo, ¿qué hacer cuando se quiere borrar una tupla que está siendo referenciada por otra tupla a través de una clave ajena? Hay varias respuestas posibles: Restringir: no se pueden borrar tuplas que están siendo referenciadas por otras tuplas. Propagar: se borra la tupla deseada y se propaga el borrado a todas las tuplas que le hacen referencia. Anular: se borra la tupla deseada y todas las referencias que tenía se ponen, automáticamente, a nulo (esta respuesta sólo es válida si la clave ajena acepta nulos). Valor por defecto: se borra la tupla deseada y todas las referencias toman, automáticamente, el valor por defecto (esta respuesta sólo es válida si se ha especificado un valor por defecto para la clave ajena). No comprobar: se borra la tupla deseada y no se hace nada para garantizar que se sigue cumpliendo la integridad referencial. ¿Qué hacer cuando se quiere modificar la clave primaria de una tupla que está siendo referenciada por otra tupla a través de una clave ajena? Las respuestas posibles son las mismas que en el caso anterior. Cuando se escoge propagar, se actualiza la clave primaria en la tupla deseada y se propaga el cambio a los valores de clave ajena que le hacían referencia. Reglas de negocio. Cualquier operación que se realice sobre los datos debe cumplir las restricciones que impone el funcionamiento de la empresa. Todas las restricciones de integridad establecidas en este paso se deben reflejar en el diccionario de datos para que puedan ser tenidas en cuenta durante la fase del diseño físico. Revisar cada esquema lógico local con el usuario correspondiente Para garantizar que cada esquema lógico local es una fiel representación de la vista del usuario lo que se debe hacer es comprobar con él que lo reflejado en el esquema y en la documentación es correcto y está completo. Relación entre el esquema lógico y los diagramas de flujo de datos El esquema lógico refleja la estructura de los datos a almacenar que maneja la empresa. Un diagrama de flujo de datos muestra cómo se mueven los datos en la empresa y los almacenes en donde se guardan. Si se han utilizado diagramas de flujo de datos para


SEMIPRESENCIAL


modelar las especificaciones de requisitos de usuario, se pueden utilizar para comprobar la consistencia y completitud del esquema lógico desarrollado. Para ello: Cada almacén de datos debe corresponder con una o varias entidades completas. Los atributos en los flujos de datos deben corresponder a alguna entidad. Los esquemas lógicos locales obtenidos hasta este momento se integrarán en un solo esquema lógico global en la siguiente fase para modelar los datos de toda la empresa. NORMALIZACIÓN La normalización es una técnica para diseñar la estructura lógica de los datos de un sistema de información en el modelo relacional, desarrollada por E. F. Codd en 1972. Es una estrategia de diseño de abajo a arriba: se parte de los atributos y éstos se van agrupando en relaciones (tablas) según su afinidad. Aquí no se utilizará la normalización como una técnica de diseño de bases de datos, sino como una etapa posterior a la correspondencia entre el esquema conceptual y el esquema lógico, que elimine las dependencias entre atributos no deseadas. Las ventajas de la normalización son las siguientes:

Evita anomalías en inserciones, modificaciones y borrados.

Mejora la independencia de datos.

No establece restricciones artificiales en la estructura de los datos. Uno de los conceptos fundamentales en la normalización es el de dependencia funcional. Una dependencia funcional es una relación entre atributos de una misma relación (tabla). Si x e y son atributos de la relación R, se dice que x es funcionalmente dependiente de y (se denota por x → y) si cada valor de x tiene asociado un solo valor de y (x e y pueden constar de uno o varios atributos). A x se le denomina determinante, ya que x determina el valor de y. Se dice que el atributo y es completamente dependiente de x si depende funcionalmente de x y no depende de ningún subconjunto de x. La dependencia funcional es una noción semántica. Si hay o no dependencias funcionales entre atributos no lo determina una serie abstracta de reglas, sino, más bien, los modelos mentales del usuario y las reglas de negocio de la organización o empresa para la que se desarrolla el sistema de información. Cada dependencia funcional es una clase especial de regla de integridad y representa una relación de uno a muchos. En el proceso de normalización se debe ir comprobando que cada relación (tabla) cumple una serie de reglas que se basan en la clave primaria y las dependencias funcionales. Cada regla que se cumple aumenta el grado de normalización. Si una regla no se cumple, la relación se debe descomponer en varias relaciones que sí la cumplan.


SEMIPRESENCIAL


La normalización se lleva a cabo en una serie pasos. Cada paso corresponde a una forma normal que tiene unas propiedades. Conforme se va avanzando en la normalización, las relaciones tienen un formato más estricto (más fuerte) y, por lo tanto, son menos vulnerables a las anomalías de actualización. El modelo relacional sólo requiere un conjunto de relaciones en primera forma normal. Las restantes formas normales son opcionales. Sin embargo, para evitar las anomalías de actualización, es recomendable llegar al menos a la tercera forma normal. PRIMERA FORMA NORMAL (1FN) Una relación está en primera forma normal si, y sólo si, todos los dominios de la misma contienen valores atómicos, es decir, no hay grupos repetitivos. Si se ve la relación gráficamente como una tabla, estará en 1FN si tiene un solo valor en la intersección de cada fila con cada columna. Si una relación no está en 1FN, hay que eliminar de ella los grupos repetitivos. Un grupo repetitivo será el atributo o grupo de atributos que tiene múltiples valores para cada tupla de la relación. Hay dos formas de eliminar los grupos repetitivos. En la primera, se repiten los atributos con un solo valor para cada valor del grupo repetitivo. De este modo, se introducen redundancias ya que se duplican valores, pero estas redundancias se eliminarán después mediante las restantes formas normales. La segunda forma de eliminar los grupos repetitivos consiste en poner cada uno de ellos en una relación aparte, heredando la clave primaria de la relación en la que se encontraban. Un conjunto de relaciones se encuentra en 1FN si ninguna de ellas tiene grupos repetitivos. SEGUNDA FORMA NORMAL (2FN) Una relación está en segunda forma normal si, y sólo si, está en 1FN y, además, cada atributo que no está en la clave primaria es completamente dependiente de la clave primaria. La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. Las relaciones que no están en 2FN pueden sufrir anomalías cuando se realizan actualizaciones. Para pasar una relación en 1FN a 2FN hay que eliminar las dependencias parciales de la clave primaria. Para ello, se eliminan los atributos que son funcionalmente dependientes y se ponen en una nueva relación con una copia de su determinante (los atributos de la clave primaria de los que dependen).


SEMIPRESENCIAL


TERCERA FORMA NORMAL (3FN) Una relación está en tercera forma normal si, y sólo si, está en 2FN y, además, cada atributo que no está en la clave primaria no depende transitivamente de la clave primaria. La dependencia x →y es transitiva si existen las dependencias, x →z ; z →y siendo x, y, z atributos o conjuntos de atributos de una misma relación. Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en 1FN, todavía pueden sufrir anomalías frente a las actualizaciones. Para pasar una relación de 2FN a 3FN hay que eliminar las dependencias transitivas. Para ello, se eliminan los atributos que dependen transitivamente y se ponen en una nueva relación con una copia de su determinante (el atributo o atributos no clave de los que dependen). FORMA NORMAL DE BOYCE-CODD (BCNF) Una relación está en la forma normal de Boyce-Codd si, y sólo si, todo determinante es una clave candidata. La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la clave primaria. Pero este tipo de dependencias todavía pueden existir sobre otras claves candidatas, si éstas existen. La BCNF es más fuerte que la 3FN, por lo tanto, toda relación en BCNF está en 3FN. La violación de la BCNF es poco frecuente ya que se da bajo ciertas condiciones que raramente se presentan. Se debe comprobar si una relación viola la BCNF si tiene dos o más claves candidatas compuestas que tienen al menos un atributo en común. COMPORTAMIENTO DE OBJETOS DIAGRAMA SECUENCIAL (DS) En éste diagrama se identifican los escenarios. El escenario representa el conjunto secuencial de servicios, definiendo la interacción entre objetos. INTERACCIÓN: Acción Reacción Elementos:


SEMIPRESENCIAL


DISEÑO ORIENTADO A OBJETOS INTRODUCCIÓN Conceptos y principios: El Diseño de Sistemas se define el proceso de aplicar ciertas técnicas 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: 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 implementar el Software. DISEÑO ARQUITECTÓNICO. Define la relación entre cada uno de los elementos estructurales del programa. 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. EL DISEÑO DE PROCEDIMIENTOS. Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseño del Software se puede definir en una sola palabra Calidad, dentro del diseño es


SEMIPRESENCIAL


donde se fomenta la calidad del Proyecto. El Diseño es la única manera de materializar con precisión los requerimientos del cliente. 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 al 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ícitos 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 Software, 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 subfunciones especificas.

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.


SEMIPRESENCIAL


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 mente, 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 generadas 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 de salida. Disponga la presentación de la información en un formato aceptable. Decida como 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 las 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 pueden 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.


SEMIPRESENCIAL


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 del 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 encabezados 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 diseñ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 especificaciones 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 practicas 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. MODELOS DE DISEÑO ORIENTADO A OBJETOS


SEMIPRESENCIAL


DISEÑO DE SERVICIOS DIAGRAMA DE LOS ESTADOS (DE) DIAGRAMA DE ACTIVIDADES O PROCESOS (DA)

GUÍA DE ESTUDIO MODULAR TÉCNICA DE ANÁLISIS DE DISEÑO …

Documents

Transcript of GUÍA DE ESTUDIO MODULAR TÉCNICA DE ANÁLISIS DE DISEÑO …