Analisis y Diseño de Sistemas

ORTIZ CRUZ PABLO
ANÁLISIS Y DISEÑO DE SISTEMAS
SAETI
TURNO VESPERTINO
FECHA DE INGRESO (PERIODO)
MAYO 2010
Análisis y Diseño de Sistemas.
UNIDAD I: MÉTODOS TRADICIONALES DEL ANÁLISIS DE SISTEMAS .................................................................................... 3
1.1 CONCEPTOS GENERALES. ...................................................................................................................................................................... 3
1.1.1 SISTEMAS. ............................................................................................................................................................................... 3
1.1.2 SISTEMAS DE INFORMACIÓN..................................................................................................................................................... 3
1.1.3 ANÁLISIS. ................................................................................................................................................................................ 3
1.1.4 DISEÑO.................................................................................................................................................................................... 6
1.1.5 ANALISTA DE SISTEMAS........................................................................................................................................................... 9
1.1.6 PROGRAMADOR. .................................................................................................................................................................... 10
1.1.7 ADMINISTRADOR DE BASES DE DATOS. .................................................................................................................................. 11
1.2. CICLO DE VIDA CLÁSICO ................................................................................................................................................................... 11
1.2.1 INVESTIGACIÓN PRELIMINAR. ................................................................................................................................................ 12
1.2.2 DETERMINACIÓN DE REQUERIMIENTOS. ................................................................................................................................. 12
1.2.3 DISEÑO DEL SISTEMA. ........................................................................................................................................................... 12
1.2.4 DESARROLLO DEL SOFTWARE. ............................................................................................................................................... 12
1.2.5 PRUEBA DEL SISTEMA. ........................................................................................................................................................... 13
1.2.6 IMPLANTACIÓN Y EVOLUCIÓN................................................................................................................................................ 13
1.2.7 MANTENIMIENTO................................................................................................................................................................... 15
1.3 ANÁLISIS ESTRUCTURADO. ................................................................................................................................................................. 16
1.3.1 ELEMENTOS DEL ANÁLISIS ESTRUCTURADO. .......................................................................................................................... 17
1.4 TÉCNICAS PARA ENCONTRAR HECHOS. ............................................................................................................................................... 17
1.4.1 ENTREVISTAS. ....................................................................................................................................................................... 17
1.4.2 CUESTIONARIOS..................................................................................................................................................................... 17
1.4.3 REVISIÓN DE LOS REGISTROS. ................................................................................................................................................ 18
1.4.4 OBSERVACIÓN. ...................................................................................................................................................................... 18
UNIDAD II: DISEÑO DE SISTEMAS ..................................................................................................................................................... 20
2.1 HERRAMIENTAS PARA DOCUMENTAR CONCEPTO DE DECISIÓN. ........................................................................................................... 20
2.1.1 ACCIONES. ............................................................................................................................................................................ 20
2.1.2 ÁRBOLES DE DECISIÓN. ......................................................................................................................................................... 20
2.1.3 TABLAS DE DECISIÓN. ........................................................................................................................................................... 21
2.2 ELEMENTOS DEL DISEÑO..................................................................................................................................................................... 22
2.2.1 FLUJO DE DATOS. .................................................................................................................................................................. 22
2.2.2 ALMACENES DE DATOS.......................................................................................................................................................... 23
2.2.3 PROCESOS. ............................................................................................................................................................................ 24
2.2.4 PROCEDIMIENTOS. ................................................................................................................................................................. 24
2.2.5 FUNCIONES DEL PERSONAL. ................................................................................................................................................... 24
UNIDAD III: MODELADO DE SISTEMAS ORIENTADO A OBJETOS........................................................................................... 25
3.1 CONCEPTOS. ....................................................................................................................................................................................... 25
3.1.1 MODELADO. .......................................................................................................................................................................... 26
3.1.2 MODELADO DE OBJETOS. ....................................................................................................................................................... 26
3.1.3 MODELO DINÁMICO. ............................................................................................................................................................. 27
3.1.4 MODELO FUNCIONAL............................................................................................................................................................. 27
3.2 DESCRIPCIÓN DE MODELOS DE OBJETOS. ............................................................................................................................................ 27
3.2.1 SIMBOLOGÍA. ......................................................................................................................................................................... 28
3.2.2 IDENTIFICACIÓN DE OBJETOS Y CLASES. ................................................................................................................................. 29
3.2.3 OPERACIÓN, MÉTODOS, ASOCIACIONES Y MULTIPLICIDAD. ................................................................................................... 30
3.2.4 ATRIBUTO DE ENLACE CLASIFICACIÓN Y AGREGACIÓN. ......................................................................................................... 31
3.3 DESCRIPCIÓN DEL MODELO DINÁMICO. .............................................................................................................................................. 34
3.3.1 SIMBOLOGÍA. ......................................................................................................................................................................... 34
3.3.2 SUCESOS Y ESTADOS. ............................................................................................................................................................ 35
3.3.3 ESCENARIOS. ......................................................................................................................................................................... 36
3.3.4 DIAGRAMAS DE ESTADO. ....................................................................................................................................................... 36
3.3.5 CONDICIONES Y OPERACIONES............................................................................................................................................... 37
3.3.6 FUNDAMENTOS DE ESTADO.................................................................................................................................................... 37
3.4 DESCRIPCIÓN DEL MODELO FUNCIONAL.............................................................................................................................................. 37
3.4.1 SIMBOLOGÍA. ......................................................................................................................................................................... 37
3.4.2 DIAGRAMA DE HOJA DE DATOS. ............................................................................................................................................ 38
3.4.3 FLUJO DE DATOS, ACTORES Y ALMACÉN DE DATOS. .............................................................................................................. 38
3.4.4 FLUJO DE CONTROL. .............................................................................................................................................................. 38
BIBLIOGRAFIA ........................................................................................................................................................................................ 39
2
Pablo Ortiz Cruz
UNIDAD I: MÉTODOS TRADICIONALES DEL ANÁLISIS DE

SISTEMAS
1.1 CONCEPTOS GENERALES.

1.1.1 SISTEMAS.
Todas las organizaciones son sistemas que actúan recíprocamente con su
medio ambiente recibiendo entradas y produciendo salidas. Los sistemas,
que pueden estar formados por otros sistemas más pequeños denominados
subsistemas, funcionan para alcanzar fines específicos. Sin embargo, los
propósitos o metas se alcanzan sólo cuando se mantienen el control.
1.1.2 SISTEMAS DE INFORMACIÓN.
Conjunto u ordenación de elementos organizados para llevar a cabo algún
métodos, procedimiento o control mediante el proceso de información.
ELEMENTOS DE UN SISTEMA DE INFORMACION
SOFWARE. Los programas de computadoras, as estructuras de datos y la
documentación asociada, que sirve para realizar el método lógico.
HARWARE: Los dispositivos electrónicos que proporcionan la capacidad de
computación y que proporcionan las funciones del mundo exterior.
GENTE: Los individuos que son usuarios y operadores del software y del
hardware.
BASES DE DATOS: Una colección grande y organizada de información a la
que se accede mediante el software y que es una parte integral del
funcionamiento del sistema.
DOCUMENTACION: Los manuales, los impresos y otra información
descriptiva que explica el uso y / o la operación.
PROCESAMIENTOS: Los pasos que definen el uso especifico de cada
elemento del sistema o el contexto procedimental en que reside el sistema.
CONTROL: Los sistemas trabajan mejor cuando operan dentro de niveles de
control tolerables de rendimiento por ejemplo: el sistema de control de un
calentador de agua.
1.1.3 ANÁLISIS.
Análisis Es el proceso de clasificación e interpretación de hechos,
diagnostico de problemas y empleo de la información para recomendar
mejoras al sistemas.
Conceptos y Análisis:
Es un conjunto o disposición de procedimientos o programas relacionados de
manera que juntos forman una sola unidad. Un conjunto de hechos,
principios y reglas clasificadas y dispuestas de manera ordenada mostrando
un plan lógico en la unión de las partes. Un método, plan o procedimiento
de clasificación para hacer algo. También es un conjunto o arreglo de
elementos para realizar un objetivo predefinido en el procesamiento de la
Información. Esto se lleva a cabo teniendo en cuenta ciertos principios:
3
• Debe presentarse y entenderse el dominio de la información de un

problema.
• Defina las funciones que debe realizar el Software.
• Represente el comportamiento del software a consecuencias de
acontecimientos externos.
• Divida en forma jerárquica los modelos que representan la
información, funciones y comportamiento.
El proceso debe partir desde la información esencial hasta el detalle de la
Implementación.
La función del Análisis puede ser dar soporte a las actividades de un
negocio, o desarrollar un producto que pueda venderse para generar
beneficios. Para conseguir este objetivo, un Sistema basado en
computadoras hace uso de seis (6) elementos fundamentales:
• Software, que son Programas de computadora, con estructuras de
datos y su documentación que hacen efectiva la logística 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.
• 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 especifico 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.
4
Pablo Ortiz Cruz
Para lograr estos objetivos se requiere tener un gran conocimiento y

dominio del Hardware y el Software, así como de la Ingeniería humana
(Manejo y Administración de personal), y administración de base de datos.
Objetivos del Análisis.
Identificación de Necesidades.
Es el primer paso del análisis del sistema, en este proceso en Analista se
reúne con el cliente y/o usuario (un representante institucional,
departamental o cliente particular), e identifican las metas globales, se
analizan las perspectivas del cliente, sus necesidades y 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:
• 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.
Estudio de Viabilidad.
Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas
los recursos y el tiempo no son realistas para su materialización sin tener
pérdidas económicas y frustración profesional. La viabilidad y el análisis
de riesgos están relacionados de muchas maneras, si el riesgo del proyecto
es alto, la viabilidad de producir software de calidad se reduce, sin
embargo se deben tomar en cuenta cuatro áreas principales de interés:
1. Viabilidad económica.
Una evaluación de los costos de desarrollo, comparados con los ingresos
netos o beneficios obtenidos del producto o Sistema desarrollado.
2. Viabilidad Técnica.
Un estudio de funciones, rendimiento y restricciones que puedan afectar la
realización de un sistema aceptable.
3. Viabilidad Legal.
Es determinar cualquier posibilidad de infracción, violación o
responsabilidad legal en que se podría incurrir al desarrollar el Sistema.
Alternativas. Una evaluación de los enfoques alternativos del desarrollo del
producto o Sistema.
5
El estudio de la viabilidad puede documentarse como un informe aparte

para la alta gerencia.
Análisis Económico y Técnico.
El análisis económico incluye lo que llamamos, el análisis de costos –
beneficios, significa una valoración de la inversión económica comparado
con los beneficios que se obtendrán en la comercialización y utilidad del
producto o sistema.
Muchas veces en el desarrollo de Sistemas de Computación estos son
intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a
la características del Sistema. El análisis de costos – beneficios es una fase
muy importante de ella depende la posibilidad de desarrollo del Proyecto.
En el Análisis Técnico, el Analista evalúa los principios técnicos del
Sistema y al mismo tiempo recoge información adicional sobre el
rendimiento, fiabilidad, características de mantenimiento y productividad.
Los resultados obtenidos del análisis técnico son la base para determinar
sobre si continuar o abandonar el proyecto, si hay riesgos de que no
funcione, no tenga el rendimiento deseado, o si las piezas no encajan
perfectamente unas con otras.
1.1.4 DISEÑO.
Especifica las características del producto terminado.
Conceptos y principios:
El Diseño de Sistemas se define el proceso de aplicar ciertas té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:
1. El diseño de los datos.
Trasforma el modelo de dominio de la información, creado durante el
análisis, en las estructuras de datos necesarios para implementar el
Software.
2. El Diseño Arquitectónico.
Define la relación entre cada uno de los elementos estructurales del
programa.
3. El Diseño de la Interfaz.
Describe como se comunica el Software consigo mismo, con los sistemas que
operan junto con el y con los operadores y usuarios que lo emplean.
4. El Diseño de procedimientos.
Transforma elementos estructurales de la arquitectura del programa. La
importancia del Diseño del Software se puede definir en una sola palabra
Calidad, dentro del diseño es donde se fomenta la calidad del Proyecto. El
Diseño es la única manera de materializar con precisión los requerimientos
del cliente.
6
Pablo Ortiz Cruz
El Diseño del Software es un proceso y un modelado a la vez. El proceso de

Diseño es un conjunto de pasos repetitivos que permiten 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
específicas.
• Un diseño debe contener abstracciones de datos y procedimientos.
• Debe producir módulos que presenten características de
funcionamiento independiente.
• Debe conducir a interfaces que reduzcan la complejidad de las
conexiones entre los módulos y el entorno exterior.
• Debe producir un diseño usando un método que pudiera repetirse
según la información obtenida durante el análisis de requisitos de
Software.
Estos criterios no se consiguen por casualidad. El proceso de Diseño del
Software exige buena calidad a través de la aplicación de principios
fundamentales de Diseño, Metodología sistemática y una revisión
exhaustiva.
Cuando se va a diseñar un Sistema de Computadoras se debe tener presente
que el proceso de un diseño incluye, concebir y planear algo en la 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.
7
• Disponga la presentación de la información en un formato aceptable.

• Decida cómo distribuir la salida entre los posibles destinatarios.
Diseño de Archivos.
Incluye decisiones con respecto a la naturaleza y contenido del propio
archivo, como si se fuera a emplear para guardar detalles de las
transacciones, datos históricos, o información de referencia. Entre las
decisiones que se toman durante el diseño de archivos, se encuentran 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.
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.
8
Pablo Ortiz Cruz
Apoyan el Proceso de formular diseños de Software, incluyendo

procedimientos y controles, así como la documentación correspondiente.
Generadores de códigos.
Producen el código fuente y las aplicaciones a partir de 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 prácticas de Diseño sofisticadas están cambiando de forma
dramática la manera en que se trasladan las especificaciones de Diseño d
Sistemas de Información funcionales.
1.1.5 ANALISTA DE SISTEMAS.
Diseñar y desarrollar sistemas de información, recomendar mejoras para el
mismo, desarrollar las especificaciones de diseño y planificar el software y
hardware necesario para implantar el diseño.
Realizar el proceso de clasificación e interpretación de hechos, diagnóstico
de problemas y empleo de la información para desarrollar el diseño del
sistema.
FUNCIONES PROPIAS DEL PUESTO
• Estudiar el mercado informático en referencia a nuevos productos,
tendencias y servicios del ámbito informático.
• Probar y comparar nuevos equipos informáticos del mercado.
• Estudiar las necesidades informáticas de los diferentes departamentos
de la empresa a nivel de equipos técnicos, métodos y procedimientos
informáticos.
• Elaborar parte del análisis funcional, en el que define la estructura
del nuevo sistema informático (equipos técnicos, métodos y procedimientos).
• Planificar la implantación y puesta en marcha del sistema a nivel de
recursos humanos y elementos de hardware.
• Realizar presupuestos referentes a la instalación de nuevos equipos y
elaborar el informe de justificación técnica y económica.
• Elaborar planes de seguridad de la información y de los equipos.
• Estudiar y establecer las pruebas a realizar para detectar las
anomalías del sistema.
• Asesorar a sus colaboradores informáticos y a los servicios
interesados.
• Coordinar, controlar y verificar la instalación e implantación del
nuevo sistema
9
• Diseñar y desarrollar la configuración del sistema informático (de

gestión, industrial).
• Redactar protocolos de aplicaciones, normativas y procedimientos.
• Negociar con proveedores/as de equipos y software informático.
• Puede realizar presentaciones de proyectos.
HERRAMIENTAS
Las herramientas o materiales de trabajo necesarios para el desarrollo de
su actividad son los siguientes:
Equipos y maquinaria: ordenadores, monitores, teclado, ratón, disquetera,
cableado y conexiones para red, impresoras, impresoras láser, modem,
sistemas de alimentación, software de base (sistema operativo: Ms-Dos,
Windows, Macintosh, Linux) y software requerido para cada tipo de red,
software de ofimática, etc. Manuales de explotación, normativa técnica,
manuales de programación (C, C++, Visual Basic, Delphi, Java, Cobol,
Pascal, Oracle, HTML, etc.).
1.1.6 PROGRAMADOR.
Un programador es un individuo que ejerce la programación, es decir, que
escribe programas de computadora u ordenador. Los programadores también
reciben el nombre de desarrolladores de software.
En la mayoría de los países, programador es también una categoría
profesional reconocida.
El programador se encarga de la implementación de prototipos mediante un
lenguaje de programación que pueda entender la computadora.
Inicialmente, la profesión se formalizó desde el enfoque Tayloriano de la
especialización de funciones en la empresa. Así, el proceso de producción de
software se concibe como un conjunto de tareas altamente especializadas
donde está claramente definido el papel de cada categoría profesional:
• El analista tiene como cometido analizar un problema y describirlo
con el propósito de ser solucionado mediante un sistema de información.
• El programador cuya única función consistía en trasladar las
especificaciones del analista en código ejecutable por la computadora.
Dichas especificaciones se recogen en un documento denominado cuaderno
de carga, medio de comunicación entre ambos. Obsérvese que esto se
consideraba un trabajo mecánico y de baja cualificación.
Hoy día se reconoce que este enfoque no es válido para organizar tareas de
tipo intelectual, como es la producción de software. De manera que la
profesión de programador ha ido evolucionando. Las dificultades de
comunicación entre analistas y programadores (un mero documento no basta
para describir lo que se quiere hacer) dio origen a una categoría profesional
intermedia, denominada analista-programador. La concepción original del
programador ha desaparecido siendo sustituida por esta: la de un
profesional mucho más formado y con unas funciones menos "mecánicas".
La profesión de analista también ha evolucionado, surgiendo el concepto
diseñador (de software). Esto se debe a los avances de la ingeniería del
10
Pablo Ortiz Cruz
software donde se reconoce que el análisis es una actividad distinta del

diseño. El análisis describe el problema (el qué hacer) mientras que el
diseño describe la solución (el cómo hacerlo). En la mayoría de países
industrializados esto ha dado lugar a la categoría profesional del diseñador
o arquitecto del software.
1.1.7 ADMINISTRADOR DE BASES DE DATOS.
El administrador de base de datos (DBA) es la persona responsable de los
aspectos ambientales de una base de datos. En general esto incluye:
• Recuperabilidad - Crear y probar Respaldos
• Integridad - Verificar o ayudar a la verificación en la integridad de
datos
• Seguridad - Definir y/o implementar controles de acceso a los datos
• Disponibilidad - Asegurarse del mayor tiempo de encendido
• Desempeño - Asegurarse del máximo desempeño incluso con las
limitaciones
• Desarrollo y soporte a pruebas - Ayudar a los programadores e
ingenieros a utilizar eficientemente la base de datos.
El diseño lógico y físico de las bases de datos a pesar de no ser obligaciones
de un administrador de bases de datos, es a veces parte del trabajo. Esas
funciones por lo general están asignadas a los analistas de bases de datos ó
a los diseñadores de bases de datos.
Los deberes de un administrador de bases de datos dependen de la
descripción del puesto, corporación y políticas de Tecnologías de
Información (TI). Por lo general se incluye recuperación de desastres
(respaldos y pruebas de respaldos), análisis de rendimiento y optimización,
y algo de asistencia en el diseño de la base de datos.
1.2. CICLO DE VIDA CLÁSICO
El ciclo de vida de un sistema de información está ligado al ciclo de vida
del sistema de base de datos sobre el que se apoya. Al ciclo de vida de los
sistemas de información también se le denomina ciclo de vida de desarrollo
del software.
Las etapas típicas del ciclo de vida de desarrollo del software son:
planificación, recolección y análisis de los requisitos, diseño (incluyendo el
diseño de la base de datos), creación de prototipos, implementación, prueba,
conversión y mantenimiento.
Este ciclo de vida hace énfasis en la identificación de las funciones que
realiza la empresa y en el desarrollo de las aplicaciones que lleven a cabo
estas funciones. Se dice que el ciclo de vida sigue un enfoque orientado a
funciones, ya que los sistemas se ven desde el punto de vista de las
funciones que llevan a cabo.
Las etapas del ciclo de vida son:
1).- Planificación del proyecto o Investigación Preliminar.
2).- Definición del sistema.
11
3).- Recolección y análisis de los requisitos.

4).- Diseño de la aplicación o del sistema.
5).- Implementación y evaluación del sistema.
6).- Prueba de sistemas.
7).- Mantenimiento.
1.2.1 INVESTIGACIÓN PRELIMINAR.
La solicitud para recibir ayuda de un sistema de información puede
originarse por varias razones: sin importar cuales sean estas, el proceso se
inicia siempre con la petición de una persona.
Planteamiento del Problema
• Identificar los componentes, explicando las relaciones entre ellos.
• Ubicar el problema dentro de un marco conceptual.
• Analizar el problema desglosando en sus unidades más simples.
• simplificando, eliminando la información redundante.
• investigar estudios análogos consultando la literatura existente.
• plantear el problema en una forma más variable para poder
investigarlo.
1.2.2 DETERMINACIÓN DE REQUERIMIENTOS.
Determinación de los requerimientos del sistema: El aspecto fundamental
del análisis de sistemas es comprender todas las facetas importantes de la
parte de la empresa que se encuentra bajo estudio.
• Cada actividad realizada siempre es parte de un entorno mayor.
• El trabajo comienza estableciendo los requisitos de todos aquellos
elementos importantes del sistema.
• Asignando grupos con estos requisitos para integrar el sistema de
cómputo.
• Es esencial cuando el SW debe interrelacionarse con otros elementos
SW, HW, personas, base de datos, etc.
1.2.3 DISEÑO DEL SISTEMA.
Diseño del sistema: El diseño de un sistema de información produce los
detalles que establecen la forma en la que el sistema cumplirá con los
requerimientos identificados durante la fase de análisis. Los especialistas
en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en
contraste con la del desarrollo del software, a la que denominan diseño
físico
1.2.4 DESARROLLO DEL SOFTWARE.
Desarrollo del software: Los encargados de desarrollar software pueden
instalar software comprobando a terceros o escribir programas diseñados a
la medida del solicitante. La elección depende del costo de cada alternativa,
12
Pablo Ortiz Cruz
del tiempo disponible para escribir el software y de la disponibilidad de los

programadores
1.2.5 PRUEBA DEL SISTEMA.
Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de
manera experimental para asegurarse de que el software no tenga fallas, es
decir, que funciona de acuerdo con las especificaciones y en la forma en que
los usuarios esperan que lo haga.
Dependiendo del tamaño de la Empresa que usara el Sistema y el riesgo
asociado a su uso, puede hacerse la elección de comenzar la operación del
Sistema solo en un área de la Empresa (como una Prueba piloto), que puede
llevarse a cabo en un Departamento o con una o dos personas. Cuando se
implanta un nuevo sistema lo aconsejable es que el viejo y el nuevo
funcionen de manera simultánea o paralela con la finalidad de comparar los
resultados que ambos ofrecen en su operación, además dar tiempo al
personal para su entrenamiento y adaptación al nuevo Sistema.
Durante el Proceso de Implantación y Prueba se deben implementar todas
las estrategias posibles para garantizar que en el uso inicial del Sistema
este se encuentre libre de problemas lo cual se puede descubrir durante
este proceso y levar a cabo las correcciones de lugar para su buen
funcionamiento.
Desdichadamente la evaluación de Sistemas no siempre recibe la atención
que merece, sin embargo cuando se lleva a cabo de manera adecuada
proporciona muchas informaciones que pueden ayudar a mejorar la
efectividad de los esfuerzos de desarrollo de aplicaciones futuras.
1.2.6 IMPLANTACIÓN Y EVOLUCIÓN.
La implantación es el proceso de verificar e instalar nuevo equipo, entrenar
a los usuarios, instalar la aplicación y construir todos los archivos de datos
necesarios para utilizarla.
Una vez instaladas, las aplicaciones se emplean durante muchos años y la
evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:
Evaluación operacional, Impacto organizacional, Opinión de los
administradores, Desempeño del desarrollo.
Es la última fase del desarrollo de Sistemas. Es el proceso instalar equipos
o Software nuevo, como resultado de un análisis y diseño previo como
resultado de la sustitución o mejoramiento de la forma de llevar a cabo un
proceso automatizado.
Al Implantar un Sistema de Información lo primero que debemos hacer es
asegurarnos que el Sistema sea operacional o sea que funcione de acuerdo a
los requerimientos del análisis y permitir que los usuarios puedan operarlo.
Existen varios enfoques de Implementación:
• Es darle responsabilidad a los grupos.
• Uso de diferentes estrategias para el entrenamiento de los usuarios.
• El Analista de Sistemas necesita ponderar la situación y proponer un
plan de conversión que sea adecuado para la organización.
13
• El Analista necesita formular medidas de desempeño con las cuales

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

incluye su facilidad de uso, Tiempo de respuesta ante una necesidad o
proceso, como se adecuan los formatos en que se presenta la Información,
contabilidad global y su nivel de Utilidad. Impacto Organizacional:
Identifica y mide los beneficios operacionales para la Empresa en áreas
tales como, Finanzas (Costos, Ingresos y Ganancias), eficiencia en el
desempeño laboral e impacto competitivo, Impacto, rapidez y organización
en el flujo de Información interna y externa.
Desempeño del Desarrollo.
Es la evaluación del Proceso de desarrollo adecuado tomando en cuentas
ciertos criterios como, Tiempo y esfuerzo en el desarrollo concuerden con
presupuesto y estándares y otros criterios de Administración de Proyectos.
Además se incluyen la valoración de los métodos y herramientas utilizados
durante el desarrollo del Sistema.
1.2.7 MANTENIMIENTO.
Con posterioridad a la fase de implementación de los sistemas, se impone la
fase de mantenimiento.
El mantenimiento de sistemas es el mantenimiento continuo después del
inicio del funcionamiento.
Cuando se elaboran planes para la estrategia de información, las
organizaciones no pueden dejar de considerar que el mantenimiento de
sistemas es la fase más prolongada y costosa del ciclo de vida de los
sistemas. Las implicaciones del volumen de trabajo para mantenimiento
para los planes de estrategia de información en una organización es un
tema que merece atención especial. La estructura de organización necesita
flexibilidad para apoyar el mantenimiento de los sistemas existentes
concurrentemente con la ejecución de nuevas tecnologías.
Es importante considerar la evaluación y el monitoreo de un sistema en
términos del mantenimiento necesario y, en consecuencia, reducir o
contener los costos implícitos. El mantenimiento de sistemas puede
clasificarse en cuatro grupos, cada uno de los cuales repercute en el plan
estratégico de información institucional de diferentes maneras:
Mantenimiento correctivo. Independientemente de cuán bien diseñado,
desarrollado y probado está un sistema o aplicación, ocurrirán errores
inevitablemente. Este tipo de mantenimiento se relaciona con la solución o
la corrección de problemas del sistema. Atañe generalmente a problemas no
identificados durante la fase de ejecución. Un ejemplo de mantenimiento
correctivo es la falta de una característica requerida por el usuario, o su
funcionamiento defectuoso.
Mantenimiento para fines específicos. Este tipo de mantenimiento se
refiere a la creación de características nuevas o a la adaptación de las
existentes según lo requieren los cambios en la organización o los usuarios,
por ejemplo, los cambios en el código tributario o los reglamento internos
de la organización.
Mantenimiento para mejoras. Se trata de la extensión o el mejoramiento del
desempeño del sistema, ya sea mediante el agregado de nuevas
15
características, o el cambio de las existentes. Un ejemplo de este tipo de

mantenimiento es la conversión de los sistemas de texto a GUI (interfaz
gráfica de usuarios).
Mantenimiento preventivo. Este tipo de mantenimiento es probablemente
uno de los más eficaces en función de los costos, ya que si se realiza de
manera oportuna y adecuada, puede evitar serios problemas en el sistema.
Un ejemplo de este mantenimiento fue la corrección del problema del año
2000.
1.3 ANÁLISIS ESTRUCTURADO.
Un sistema de información realiza cuatro actividades básicas: entrada,
almacenamiento, procesamiento y salida de información.
Entrada de Información: Es el proceso mediante el cual el Sistema de
Información toma los datos que requiere para procesar la información. Las
entradas pueden ser manuales o automáticas. Las manuales son aquellas
que se proporcionan en forma directa por el usuario, mientras que las
automáticas son datos o información que provienen o son tomados de otros
sistemas o módulos. Esto último se denomina interfaces automáticas.
Almacenamiento de información: El almacenamiento es una de las
actividades o capacidades más importantes que tiene una computadora, ya
que a través de esta propiedad el sistema puede recordar la información
guardada en la sección o proceso anterior. Esta información suele ser
almacenada en estructuras de información denominadas archivos. La
unidad típica de almacenamiento son los discos magnéticos o discos duros,
los discos flexibles o diskettes y los discos compactos (CD-ROM).
Procesamiento de Información: Es la capacidad del Sistema de Información
para efectuar cálculos de acuerdo con una secuencia de operaciones
preestablecida. Estos cálculos pueden efectuarse con datos introducidos
recientemente en el sistema o bien con datos que están almacenados. Esta
característica de los sistemas permite la transformación de datos fuente en
información que puede ser utilizada para la toma de decisiones, lo que hace
posible, entre otras cosas, que un tomador de decisiones genere una
proyección financiera a partir de los datos que contiene un estado de
resultados o un balance general de un año base.
Salida de Información: La salida es la capacidad de un Sistema de
Información para sacar la información procesada o bien datos de entrada al
exterior. Las unidades típicas de salida son las impresoras, terminales,
diskettes, cintas magnéticas, la voz, los graficadores y los plotters, entre
otros. Es importante aclarar que la salida de un Sistema de Información
puede constituir la entrada a otro Sistema de Información o módulo. En
este caso, también existe una interface automática de salida. Por ejemplo,
el Sistema de Control de Clientes tiene una interface automática de salida
con el Sistema de Contabilidad, ya que genera las pólizas contables de los
movimientos procesales de los clientes.
16
Pablo Ortiz Cruz
1.3.1 ELEMENTOS DEL ANÁLISIS ESTRUCTURADO.

Entradas: Elementos que requiere el sistema para funcionar
Proceso: Manipular, trabajar con la entrada para obtener un resultado
(técnicas, formulas, métodos etc.)
Salidas: Resultado, la satisfacción de la necesidad
Frontera: El límite del sistema
Integración: Es la unión de los elementos del sistema y se define en base a:
objetivos, metas y funciones
Comunicación: Que información o datos se comunican, a quien se
comunican, hacia donde y por qué medio.
1.4 TÉCNICAS PARA ENCONTRAR HECHOS.
Los analistas pueden emplear varios métodos para obtener, reunir y
determinar los requerimientos del sistema. Entre estos tenemos:
1.4.1 ENTREVISTAS.
Es una conversación dirigida con el propósito específico que utiliza un
formato de preguntas y respuestas. Se espera de la entrevista, obtener
opiniones de los entrevistados acerca de la situación actual del sistema, los
objetivos organizacionales, comentarios personales y procedimientos.
Pasos para planificar la entrevista
- Leer los antecedentes.
- Establecer los objetivos de la entrevista.
- Decidir a quién entrevistar.
- Preparar al entrevistado.
- Decidir el tipo de preguntas y la estructura ( estructurada o no
estructurada).
1.4.2 CUESTIONARIOS.
Es una técnica de recopilación de información que permite a través del
empleo de formatos estandarizados reunir información para estudiar las
actitudes, comportamientos y características de muchas personas. Los
cuestionarios pueden ser de manera rápida, los cuales deben cumplir unas
directrices:
- Determinar que fines se persigue con al elaboración del cuestionario.
- Los tipos de preguntas que utiliza un cuestionario son : abierta y cerrada.
- Elegir el lenguaje del cuestionario, implica utilizar el lenguaje que
emplean los encuestados. la redacción debe ser sencilla.
Uso de escalas en los cuestionarios
Los analistas de sistemas emplean dos formas de escalas de medición
- Escalas nominales: Se emplean para clasificar cosas
¿ Que tipo de software emplea mas?
17
1= Un procesador de texto
2= Una hoja de calculo
3= Una base de datos
4= Un programa de correo electrónico
- Escalas de Intervalos: Poseen la característica de que los intervalos entre
cada uno de los números son iguales.
¿ Que tan útil es el apoyo que ofrece el grupo de soporte técnico?
No tiene utilidad alguna Es sumamente útil
1 2 3 4 5
Diseño de los cuestionarios:
- Dejar bastante espacio en blanco
- Facilitar a los encuestados que marquen con claridad sus respuestas
- Mantener un estilo consistente.
- Mantener lineamientos: primero colocar preguntas mas importantes,
agrupar los elementos de contenido similar, incorporar primero las
preguntas menos polémicas.
1.4.3 REVISIÓN DE LOS REGISTROS.
Varios tipos de reportes y de registros pueden proporcionar al analista
información valiosa con respecto a las organizaciones y a sus operaciones.
Al revisar los registros, el analista examina la información asentada en
ellos relacionada con el sistema y los usuarios. La revisión puede
efectuarse el comienzo del estudio, como introducción o después, esto sirve
para comparar las operaciones actuales, por lo tanto los registros pueden
indicar que está sucediendo.
Los registros incluyen manuales de políticas, reglamentos y procedimientos
estándares de operación utilizados por la mayor parte de las organizaciones
como guías. Los registros no indican la forma en la que se desarrollan las
actividades, donde se encuentra todo el poder en la toma de decisiones, o
como se realizan todas las tareas.
1.4.4 OBSERVACIÓN.
Por medio de la observación el analista obtiene información de primera
mano sobre la forma en que se efectúan las actividades. este método es útil
cuando el analista necesita observar:
- La forma en que se manejan los documentos y se llevan a cabo los
procesos.
- Si se siguen los pasos especificados.
El método de la observación cumple unos requisitos
- Sirve a un objetivo, previamente establecido
- Es planificada sistemáticamente
- Es controlada previamente
18
Pablo Ortiz Cruz
- Está sujeta a comprobaciones de fiabilidad y validez

Etapas de la Observación:
- Se plantea un objetivo
- Recogida de datos: definir las variables a observar, costo en tiempo y
gasto económico, decidir el muestreo de datos.
- Análisis e interpretación de los datos recogidos
- Elaborar conclusiones o incluso replanteamientos
- Comunicación de los resultados: Informe sobre si los hallazgos son o no
relevantes.
19
UNIDAD II: DISEÑO DE SISTEMAS
2.1 HERRAMIENTAS PARA DOCUMENTAR CONCEPTO DE DECISIÓN.

Apoyan el proceso de formular las características que el sistema debe tener
para satisfacer los requerimientos detectados durante las actividades del
análisis:
2.1.1 ACCIONES.
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 prácticas de Diseño sofisticadas está cambiando de forma dramática
la manera en que se trasladan las especificaciones de Diseño de Sistemas
de Información funcionales.
2.1.2 ÁRBOLES DE DECISIÓN.
Cuando un proceso de decisión estructurada se integra con ramificaciones
complejas, entonces se hace uso de los árboles de decisiones. Los árboles de
decisiones se dibujan sobre un plano horizontal, con la raíz del árbol al
lado izquierdo del papel y las ramas hacia la derecha. Esto permite al
analista describir las condiciones de acciones sobre las ramas.
Cuando se dibujan los árboles de decisiones es útil distinguir entre las
condiciones y las acciones. Para este propósito, el uso de un nodo cuadrado
20
Pablo Ortiz Cruz
indica una acción y un círculo representa una condición, tal y como se

representa en la figura 5.4.1. El uso de esta notación hace más accesible el
árbol de decisiones sí uno piensa que un círculo significa IF (SI), mientras
que cuadrado significa THEN (ENTONCES).
El árbol de decisiones tiene tres ventajas principales sobre la tabla de
decisiones:
Primera, es que toma las ventajas de la estructura consecutiva de las
ramas del árbol de decisiones, de tal forma que se identifican de manera
inmediata el orden de verificación de las condiciones y las acciones que se
deben llevar a cabo.
Segundo, las condiciones y acciones del árbol de decisiones se encuentran
en ciertas ramas pero no en otras, a diferencia de las tablas de decisiones,
donde todas forman parte de la misma tabla.
Tercero, al compararse con las tablas los árboles de decisiones se entienden
con más facilidad en una organización y son apropiados como un método de
comunicación.
2.1.3 TABLAS DE DECISIÓN.
Una tabla de decisiones es una tabla de renglones y columnas que contiene
cuatro cuadrantes. El cuadrante superior izquierdo contiene la condición, el
cuadrante superior derecho opciones a la condición. La mitad inferior de la
tabla contiene las acciones que se van a tomar (en el extremo izquierdo) y
las reglas para ejecutar las acciones (en el derecho). Cuando una tabla de
decisiones se utiliza para determinar las acciones que se llevaron a cabo, la
lógica sigue el sentido del reloj, comenzando en el extremo superior
izquierdo.
TABLA DE DECISIONES
Condiciones y acciones
Reglas
Condiciones
Alternativas de la condición
Acciones
Registro de las acciones
Para construir tablas de decisión, el analista necesita definir el tamaño
máximo de la tabla, eliminar cualquier situación imposible, inconsistencia
o redundancia y simplificar la tabla mejor posible. Los siguientes pasos
proveen al analista de un método sistemático para el desarrollo de tablas
de decisiones:
Determine el número de condiciones que pudieran afectar la decisión.
Combine renglones que se sobrepongan. El número de condiciones será igual
al número de renglones presentes en la mitad superior de la tabla de
decisiones.
Determine el número de acciones posibles que puedan realizarse. Este será
igual al número de renglones de la parte inferior de la tabla de decisiones.
21
Determine el número de opciones para cada condición. En la forma más

sencilla, habrá dos alternativas (S o N) para cada condición. En una tabla
de tipo extendida, puede llegar a haber muchas opciones para cada
condición.
2.2 ELEMENTOS DEL DISEÑO.
Al diseñar un sistema informático, se tienen en cuenta los cinco elementos
fundamentales que componen el hardware: la unidad aritmético-lógica, la
unidad de control, la memoria, la entrada y la salida. La unidad aritmético-
lógica realiza operaciones aritméticas y compara valores numéricos. La
unidad de control dirige el funcionamiento de la computadora recibiendo
instrucciones del usuario y transformándolas en señales eléctricas que
puedan ser comprendidas por los circuitos del ordenador. La combinación de
la unidad aritmético-lógica y la unidad de control se denomina unidad
central de procesamiento, o CPU (siglas en inglés). La memoria almacena
instrucciones y datos. Las secciones de entrada y salida permiten
respectivamente que la computadora reciba y envíe datos.
Se necesitan arquitecturas diferentes de hardware debido a las necesidades
especializadas de los distintos sistemas y usuarios. Por ejemplo, un usuario
puede necesitar que su sistema muestre gráficos de forma extremadamente
rápida, mientras que otro tal vez necesite buscar eficazmente en una base
de datos o tener un consumo bajo de energía, como en el caso de
ordenadores personales portátiles. Además del diseño del hardware, se debe
considerar los sistemas operativos que harán funcionar el sistema. El
software, como los lenguajes de programación y los sistemas operativos,
hace que los detalles de la arquitectura del hardware resulten invisibles
para el usuario. Por ejemplo, diferentes computadoras que empleen el
lenguaje de programación C o el sistema operativo UNIX pueden parecer
iguales desde el punto de vista del usuario aunque la arquitectura de
hardware sea diferente.
2.2.1 FLUJO DE DATOS.
Un diagrama de flujo de datos (DFD por sus siglas en español e inglés) es
una representación gráfica del "flujo" de datos a través de un sistema de
información. Un diagrama de flujo de datos también se puede utilizar para
la visualización de procesamiento de datos (diseño estructurado). Es una
práctica común para un diseñador dibujar un contexto a nivel de DFD que
primero muestra la interacción entre el sistema y las entidades externas.
Este contexto a nivel de DFD se "explotó" para mostrar más detalles del
sistema que se está modelando.
Los diagramas de flujo de datos fueron inventados por Larry Constantine,
el desarrollador original del diseño estructurado, basado en el modelo de
computación de Martin y Estrin: "flujo gráfico de datos" . Los diagramas de
flujo de datos (DFD) son una de las tres perspectivas esenciales de Análisis
de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador de
un proyecto y los usuarios finales tendrán que ser informados y consultados
en todas las etapas de una evolución del sistema. Con un diagrama de flujo
de datos, los usuarios van a poder visualizar la forma en que el sistema
funcione, lo que el sistema va a lograr, y cómo el sistema se pondrá en
práctica. El antiguo sistema de diagramas de flujo de datos puede ser
22
Pablo O
Ortiz Cruz
elaborado y se comparó con el nuevo siste ma de diagramas de flujo para

establecer diferencias y mejoras a aplicar p ara desarrollar un sistema más
eficiente. Los diagramas de flujo de d atos pueden ser usados para
proporcionar al usuario final una idea física de cómo resultarán los datos a
última instancia, y cómo tienen un efecto sobre la estructura de todo el
sistema. La manera en que cualquier s istema es desarrollado puede
determinarse a través de un diagrama de flu jo de datos. El desarrollo de un
DFD ayuda en la identificación de los datos de la transacción en el modelo
de datos.
2.2.2 ALMACENES DE DATOS.

La integración de los datos y de los sist emas surge como un resultado
directo de la centralización del departame nto de sistemas bajo una sola
estructura administrativa.
Las nuevas tecnologías relacionadas c on base de datos, sistemas
administradores de bases de datos y le nguajes de cuarta generación,
hicieron posible la integración.
En esta etapa surge la primera hoja electr ónica de cálculo comercial y los
usuarios inician haciendo sus propias aplicaciones. Esta herramienta ayudó
mucho a que los usuarios hicieran su pro pio trabajo y no tuvieran que
esperar a que sus propuestas de sistemas fueran cumplidas.
El costo del equipo y del software disminuy ó por lo cual estuvo al alcance
de más usuarios.
En forma paralela a los cambios tecnológic os, cambió el rol del usuario y
del departamento de Sistemas de Informació n. El departamento de sistemas
evolucionó hacia una estructura descentra lizada, permitiendo al usuario
utilizar herramientas para el desarrollo de sistemas.
Los usuarios y el departamento de sistema i niciaron el desarrollo de nuevos
sistemas, reemplazando los sistemas a ntiguos, en beneficio de la
organización.
El departamento de Sistemas de Información reconoce que la información es
un recurso muy valioso que debe estar acces ible para todos los usuarios.
23
Para poder cumplir con lo anterior resulta necesario administrar los datos
en forma apropiada, es decir, almacenarlos y mantenerlos en forma
adecuada para que los usuarios puedan utilizar y compartir este recurso.
El usuario de la información adquiere la responsabilidad de la integridad
de la misma y debe manejar niveles de acceso diferentes.
2.2.3 PROCESOS.
Actividades para aceptar, manejar y suministrar datos e información.
Pueden ser manuales o basadas en computadora.
2.2.4 PROCEDIMIENTOS.
Métodos y rutinas para utilizar el sistema de información y lograr con ello
los resultados esperados.
2.2.5 FUNCIONES DEL PERSONAL.
Las responsabilidades de todas las personas que tienen que ver con el
nuevo sistema incluyendo los usuarios, operadores de computadora y
personal de apoyo. Abarca todo el espectro de componentes del sistema,
incluso desde la entrada de datos hasta la distribución de salidas o
resultados. A menudo, las funciones del personal se establecen en forma de
procedimiento.
24
Pablo Ortiz Cruz
UNIDAD III: MODELADO DE SISTEMAS ORIENTADO A

OBJETOS
3.1 CONCEPTOS.
Hay varios conceptos que son propios de la orientación a objetos y otros
inherentes a la tecnología. Aunque no todos son exclusivos de los sistemas
orientados a objetos están bien apoyados por el paradigma.
Orientado a Objetos: significa que el software se organiza como una
colección de objetos discretos que contienen tanto estructuras de datos
como comportamiento.
Identidad: Los datos están cuantificados en entidades discretas y
distinguibles denominadas objetos. Cada objeto posee su propia identidad
inherente. Pueden ser ejemplos de objetos, un párrafo de un documento, la
reina blanca del juego de ajedrez, una silla. En otras palabras: dos objetos
serán distintos aun cuando los valores de todos sus atributos (tales como el
nombre y el tamaño) sean idénticos. Por ejemplo en un conjunto de 6 sillas
de un mismo juego los valores de los atributos son los mismos y cada una de
las sillas tiene su propia identidad.
Identificación: en el mundo real los objetos se limitan a existir, pero dentro
de un entorno de computación cada objeto posee una identificación
mediante la cual se puede hacer alusión a él de modo exclusivo. La
identificación se puede implementar de distintas maneras que pueden ser
como una dirección, un índice de una matriz, o un valor exclusivo de un
atributo.
Clasificación: significa que los objetos con la misma estructura de datos
(atributos) y comportamiento (operaciones) se aglutinan para formar una
clase. Son ejemplos de clases: párrafo, pieza de ajedrez.
Clase: Es una abstracción que describe propiedades importantes para una
aplicación y que ignora el resto. La selección de clases es arbitraria y
depende de la aplicación. Una clase contienen el molde (estructura,
esquema) a partir del cual se crean los objetos que pertenecen a ella y el
código que debe ejecutarse cada vez que un objeto de la clase recibe un
mensaje. Una clase contiene la descripción de las características comunes
de todos los objetos que pertenecen a ella: la especificación del
comportamiento, la definición de la estructura interna y la implementación
de los métodos.
Instancia: se dice que cada objeto es una instancia de su clase. Toda clase
describe un conjunto posiblemente finito de objetos individuales. Toda
instancia de la clase posee su propio valor para cada uno de los atributos
pero comparte los nombres de los atributos y las operaciones con las demás
instancias de la clase. Todo objeto contiene una referencia implícita a su
propia clase; ‘‘sabe la clase de cosa que es’’. Los objetos contienen los
valores de los atributos (que lo distinguen de otros objetos) y una
identidad.
25
3.1.1 MODELADO.
El Modelado y Diseño Orientado a Objetos se funda en pensar acerca de
problemas a resolver empleando modelos que se han organizado tomando
como base conceptos del mundo real. La unidad básica es el objeto que
combina las estructuras de datos con los comportamientos en una entidad
única.
La Metodología OMT se extiende desde el análisis hasta la implementación
pasando por el diseño. En primer lugar, se construye un modelo de análisis
para abstraer los aspectos esenciales del dominio de la aplicación sin tener
en cuenta la implementación eventual. En este modelo se toman decisiones
importantes que después se completan para optimizar la implementación en
segundo lugar. Los objetos del dominio de la aplicación constituyen el
marco de trabajo del modelo de diseño, pero se implementan en términos de
objetos del dominio de la computadora. Por último, el modelo de diseño se
implementa en algún lenguaje de programación, base de datos o hardware.
3.1.2 MODELADO DE OBJETOS.
Un modelo es una abstracción de algo, cuyo objetivo es comprenderlo antes
de construirlo. Dado que los modelos omiten los detalles no esenciales es
más sencillo manipularlos que manipular la entidad original. La
abstracción permite enfrentarse a la complejidad. Los ingenieros, artistas y
artesanos han estado construyendo modelos durante miles de años para
probar los diseños antes de ejecutarlos. El desarrollo de sistemas hardware
y software no es una excepción. Para construir sistemas complejos, el
desarrollador debe abstraer distintas vistas del sistema, construir modelos
utilizando notaciones precisas, verificar que los modelos satisfacen los
requisitos del sistema y añadir, gradualmente, detalles para transformar
los modelos en una implementación.
Los modelos tienen varios objetivos:
• Probar una entidad física antes de construirla
• Comunicación con el cliente
• Visualización del conjunto
• Reducción de la complejidad
La abstracción es el examen selectivo de ciertos aspectos de un problema.
Su finalidad es aislar aquellos aspectos que sean importantes para algún
objetivo y suprimir los aspectos que no lo sean. La abstracción siempre
debe de hacerse con algún objetivo prefijado, porque el propósito determina
lo que es y no es importante. Es posible efectuar muchas abstracciones
diferentes de la misma cosa, dependiendo del propósito para el cual se
hagan esas abstracciones.
Todas las abstracciones son incompletas e imprecisas. La realidad es una
red sin costuras. Todo lo que digamos acerca de ella, cualquier descripción,
será una versión reducida. Todas las palabras y lenguajes humanos son
abstracciones, descripciones incompletas del mundo real. Esto no elimina
su utilidad. El propósito de una abstracción es limitar al universo para que
podamos hacer cosas. Al construir modelos, por tanto, no debe uno buscar la
verdad absoluta, sino su adecuación para algún propósito. No existe un
26
Pablo Ortiz Cruz
único modelo ‘‘correcto’’ de una situación, solo existen modelos adecuados o

inadecuados. Un buen modelo captura los aspectos cruciales del problema y
omite los demás.
La metodología OMT emplea tres clases de modelos para describir el
sistema: el Modelo de Objetos que describe los objetos del sistema y sus
relaciones; el Modelo Dinámico que describe las interacciones existentes
entre objetos del sistema; y el Modelo Funcional que describe las
transformaciones de datos del sistema. Todos los modelos son aplicables en
la totalidad de las fases del desarrollo y van adquiriendo detalles de
implementación a medida que progresa el desarrollo.
3.1.3 MODELO DINÁMICO.
Describe los aspectos de comportamiento (de control) de un sistema que
cambian con el tiempo. El modelo dinámico se utiliza para especificar e
implementar los aspectos del control del sistema. Los modelos dinámicos
contienen diagramas de estados. Un diagrama de estados es un grafo cuyos
nodos son estados y cuyos arcos son transiciones entre estados causadas por
sucesos o eventos.
Se especifican en este modelo la temporización y secuencia de operaciones
(sucesos que marcan los cambios, secuencias de sucesos, estados que
definen el contexto para los sucesos), y la organización de sucesos y de
estados. El modelo dinámico captura el control, aquel aspecto de un sistema
que describe las secuencias de operaciones que se producen sin tener en
cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en
la que estén implementadas. Las acciones de los diagramas de estado se
corresponden con funciones procedentes del modelo funcional; los sucesos
de un diagrama de estado pasan a ser operaciones que se aplican a objetos
dentro del modelo de objetos.
3.1.4 MODELO FUNCIONAL.
Describe las transformaciones (de función), de valores de datos que ocurren
dentro del sistema, captura lo que hace el sistema, independientemente de
cuando se haga o de la forma en que se haga. El modelo funcional contiene
diagramas de flujo de datos. Un diagrama de flujo de datos es un grafo
cuyos nodos son procesos y cuyos arcos son flujos de datos, se muestra las
dependencias entre los valores y el cálculo de valores de salida a partir de
los de entrada y de funciones, sin considerar cuando se ejecutan las
funciones, ni siquiera si llegan a ejecutarse.
Las funciones se invocan como acciones en el modelo dinámico y se
muestran como operaciones que afectan a objetos en el modelo de objetos.
3.2 DESCRIPCIÓN DE MODELOS DE OBJETOS.
Una descripción completa del sistema requiere los tres modelos. Un
procedimiento típico de software contiene estos tres aspectos: • utiliza
estructuras de datos (modelo de objetos), • secuencia las operaciones en el
tiempo (modelo dinámico) y • transforma valores (modelo funcional).
Cada modelo referencia a entidades de los otros modelos, los tres modelos
están relacionados entre si. Las interconexiones entre los distintos modelos
27
son limitadas y explícitas. Los buenos diseños aíslan los distintos aspectos
del sistema y limitan el acoplamiento entre ellos.
El más importante es el modelo de objetos porque es necesario para
describir ‘‘qué’’ está cambiando o transformándose, antes de describir
‘‘cuándo’’ y ‘‘cómo’’ cambia. El enfoque orientado a objetos se centra
primordialmente en identificar objetos procedentes del dominio de la
aplicación ajustándoles después los procedimientos. Soporta mejor las
evoluciones de los requisitos porque está basado en el entorno subyacente
del dominio de la aplicación en sí, más que en los requisitos funcionales ad-
hoc de un único problema.
3.2.1 SIMBOLOGÍA.
PAQUETES: Permiten dividir un modelo, reagrupar y encapsular los
elementos de modelado y se representa con una carpeta con nombre.
Gráficamente un paquete viene representado como se indica en la Figura:

Cualquier sistema grande se debe dividir en unidades más pequeñas, de
modo que las personas puedan trabajar con una cantidad de información
limitada, a la vez y de modo que los equipos de trabajo no interfieran con el
trabajo de los otros.
Los paquetes ofrecen un mecanismo general para la organización de los
modelos/subsistemas agrupando elementos de modelado. Cada paquete
corresponde a un submodelo (subsistema) del modelo (sistema). Los
paquetes son unidades de organización jerárquica de uso general de los
modelos de UML. Pueden ser utilizados para el almacenamiento, el control
de acceso, la gestión de la configuración y la construcción de bibliotecas
que contengan fragmentos reutilizables del modelo.
CASOS DE USO: Un Caso de Uso es representado por una elipse y es una
descripción de la secuencia de interacciones que se producen entre un actor
y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea
específica.
Representan la funcionalidad del sistema y los requisitos del sistema desde

la perspectiva del usuario. Los objetivos de los casos de uso son los
siguientes: • Capturar los requisitos funcionales del sistema y expresarlos
desde el punto de vista del usuario. • Guiar todo el proceso de desarrollo
del sistema de información. Los casos de uso proporcionan, por tanto, un
modo claro y preciso de comunicación entre cliente y desarrollador. Desde
el punto de vista del cliente proporcionan una visión de “caja negra” del
sistema, esto es, cómo aparece el sistema desde el exterior sin necesidad de
entrar en los detalles de su construcción. Para los desarrolladores, suponen
el punto de partida y el eje sobre el que se apoya todo el desarrollo del
sistema en sus procesos de análisis y diseño.
ACTORES: Un actor es una entidad externa al sistema que realiza algún
tipo de interacción con el mismo. Se representa mediante una figura
humana dibujada con palotes. 
28
Pablo Ortiz Cruz
Esta representación sirve tanto para actores que son personas como para
otro tipo de actores (otros sistemas, sensores, etc.).
Si se habla de usuarios, un actor es el papel que puede llevar a cabo en
cuanto a su forma de interactuar con el sistema, es decir, un único actor
puede representar a muchos usuarios diferentes y de la misma forma, un
usuario puede actuar como actores diferentes.
RELACIONES: Las relaciones pueden tener lugar entre actores y casos de
uso o entre casos de uso. La relación entre un actor y un caso de uso es una
relación de comunicación, que indica que un actor interviene en el caso de
uso. Normalmente, el actor aporta información para la realización de un
caso de uso o recibe información como resultado de la realización del
mismo, por ello, esta relación puede ser unidireccional o bidireccional,
aunque generalmente se muestra como bidireccional, ya que no es necesario
especificar en detalle estas relaciones.
La relación entre casos de uso es una relación unidireccional. Esta relación
puede presentar uno de los dos siguientes tipos: “usa” y “extiende”.
3.2.2 IDENTIFICACIÓN DE OBJETOS Y CLASES.
OBJETOS: Es la representación de una entidad sea real o conceptual. Un

objeto puede representar algo concreto (una persona, un auto, una
computadora, etc.), o un concepto (un proceso químico, una transacción
bancaria, una orden de compra, etc.). Un objeto tiene tres características:
a. Estado: Representado por una colección de propiedades o atributos,
por ejemplo el objeto Curso puede estar en uno de dos estados: “Abierto” o
“Cerrado”.
b. Conducta: Representa todo lo que el objeto puede hacer (Operaciones),
por ejemplo un curso disponible podría tener las operaciones:
AgregarEstudiante() y EliminarEstudiante()
c. Identidad: Representa la unicidad de un objeto con respecto a otros
objetos, por ejemplo: Matemática 001- Sección 1 y Matemática 001 Sección 2
son dos objetos del Sistema de Registro Curso. Aunque ambos cursos están
disponibles, cada uno tiene una única identidad.
En uml, los objetos son representados con rectángulos y el nombre del
objeto es subrayado.
CLASES: es una descripción de un grupo de objetos la cual consta de:
propiedades comunes (los atributos), conductas comunes(los
funcionamientos), relaciones comunes y semántica común. Así una clase es
una plantilla para crear objetos. Cada objeto es una instancia de alguna
clase u objeto. Por ejemplo, la clase “Curso Disponible” puede definirse con
las siguientes características:
a. Atributos: ubicación, horas disponibles.
b. .Operaciones: recuperar ubicación, recuperar horas al día, agregar
estudiante. Así: Matemática 001 – Sección 1 y Matemática 001 – Sección 2
son objetos pertenecientes a la clase “Curso Disponible”. Cada objeto
debería tener valores para sus atributos y acceso a las operaciones
especificadas en la clase “Curso Disponible”.
29
A
Análisis y Diseeño de Sistema
as.
En UML, las clases se representan con rectá ngulos divididos en tres partes.
3.2.3 OPERACIÓN, MÉTODOS, ASOCIACION ES Y MULTIPLICIDAD.

Las operaciones son los procesos que u na clase sabe llevar a cabo.
Evidentemente, corresponden a los métodos sobre una clase. En el nivel de
especificación, las operaciones corresponde n a los métodos públicos sobre
un tipo. En general, no se muestran aquellas operaciones que simplemente
manipulan atributos, ya que por lo común, se pueden inferir. Sin embargo,
tal vez sea necesario indicar si un atributo dado es de sólo lectura o está
inmutable congelado (esto es, que su valor nunca cambia). En el modelo de
implementación, se podrían mostrar tamb ién las operaciones privadas y
protegidas.
La sintaxis del UML completa para las operaciones es
visibilidad nombre (lista-de-parámetros) : ex presión- tipo-de-dato-a-regresar
{cadena-de-propiedades} .
donde
•visibilidad es + (public), # (protected), o- ( private)
•nombre es una cadena de caracteres (string )
•lista-de-parámetros contiene argumentos (opcionales) cuya sintaxis, es la
misma que la de los atributos
•expresión-tipo-de-dato-a-regresar es una especificación opcional
dependiente del lenguaje
•cadena-de-propiedades indica valores de propiedad que se aplican a la
operación dada
Un ejemplo de operación sería: + úItimaCa ntidadDe (valorTipoFenómeno) :
Cantidad
Dentro de los modelos conceptuales, las o peraciones no deben tratar de
especificar la interfaz de una clase. En lug ar de el lo, deberán indicar las
principales responsabilidades de dicha cla se, usando tal vez un par de
palabras que sinteticen una responsabilidad de CRC.
Con frecuencia encuentro útil hacer la distinción entre aquellas
operaciones que cambian el estado de una c lase y aq uellas que no lo hacen.
Una consulta es una operación que obtiene un valor de una clase sin que
cambie el estado observable de tal clase. El estado observable de un objeto
es el estado que se puede determinar a parti r de sus consultas asociadas.
Considérese un objeto de Cuenta que calcu la su balance a partir de una
lista de entradas. Para mejorar el desemp eño, Cuenta puede poner en un
campo caché el resultado del cálculo del b alance, para consultas futuras.
Por tanto, si el caché está vacío, la primera vez que se llama a la operación
"balance", pondrá el resultado en el campo caché. La operación "balance"
30
Pablo Ortiz Cruz
cambia así el estado real del objeto Cuenta, pero no su estado observable,
pues todas las consultas devuelven el mismo valor, esté o no lleno el campo
caché. Las operaciones que sí cambian el estado observable de un objeto se
llaman modificadores.
Considero útil tener perfectamente clara la diferencia entre consultas y
modificadores. Las consultas se pueden ejecutar en cualquier orden, pero la
secuencia de los modificadores es más importante. Yo tengo como política
evitar que los modificadores devuelvan valores, con el fin de mantenerlos
separados.
Otros términos que algunas veces se presentan son: métodos de obtención y
métodos de establecimiento. El método de obtención (getting) es un método
que devuelve el valor de un campo (sin hacer nada más). El método de
establecimiento (setting) pone un valor en un campo (y nada más). Desde
afuera, el cliente no debe poder saber si una consulta es un método de
obtención ni si un modificador es un método de establecimiento. El
conocimiento sobre los métodos de obtención y establecimiento está
contenido completamente dentro de la clase.
Otra distinción es la que se da entre operación y método. Una operación es
algo que se invoca sobre un objeto (la llamada de procedimiento), mientras
que un método es el cuerpo del procedimiento. Los dos son diferentes
cuando se tiene polimorfismo. Si se tiene un supertipo con tres subtipos,
cada uno de los cuales suplanta la operación "foo" del supertipo, entonces lo
que hay es una operación y cuatro métodos que la implementan.
Es muy común que operación y método se empleen indistintamente, pero
hay veces en que es necesario precisar la diferencia. En algunas ocasiones,
la gente distingue entre una y otro mediante los términos llamada a un
método, o declaración de método (en lugar de operación), y cuerpo del
método.
Los lenguajes tienen sus propias convenciones para los nombres. En C ++,
las operaciones se llaman funciones miembro; En Smalltalk, operaciones de
métodos. C ++ también emplea el término miembros de una clase para
denominar las operaciones y métodos de una clase.
Son los medios para establecer relaciones entre objetos y clases, un enlace
es una conexión física o conceptual entre instancias de objetos,
matemáticamente se define como un ente ordenado de instancias de objetos,
un enlace es una instancia de una asociación, esta describe un grupo de
enlaces con estructura y semántica comunes, las asociaciones describen un
conjunto de enlaces potenciales, del mismo modo que las clases describen
un conjunto de objetos potenciales, y suelen implementarse en los lenguajes
de programación como punteros que van de un objeto a otro. La notación
para las asociaciones es una línea entre clases, y los enlaces es una línea
entre objetos, el nombre de la asociación se pone en cursiva.
Limita el número de objetos relacionados, los diagramas de objetos lo
indican mediante símbolos al final de la línea de asociación, subestimar la
multiplicidad puede evitar la flexibilidad de una aplicación, una
subestimación de la misma impone gastos adicionales extraordinarios.
3.2.4 ATRIBUTO DE ENLACE CLASIFICACIÓN Y AGREGACIÓN.
31
Un atributo de un enlace es una propiedad de los enlaces de una asociación.

Todo atributo de enlace tiene un valor para cada enlace.
Rol
Es un nombre que identifica en forma única un extremo de la asociación, el
uso de nombres de rol proporciona una forma de recorrer las asociaciones
desde un objeto de un extremo sin mencionar explícitamente la asociación,
los roles pueden aparecer como sustantivos en la descripción del problema.
Clasificación
Normalmente los objetos del lado muchosen una asociación no tienen un
orden explícito y se pueden considerar como un conjunto, la clasificación es
una parte inherente de la asociación, si es un conjunto ordenado de objetos
se escribe ordenado o clasificado al lado del símbolo de multiplicidad.
Cualificación
Una asociación cualificada relaciona dos clases de objetos y una
cualificada, este es un atributo especial que reduce la multiplicidad
efectiva de una asociación, las asociaciones 1 a N o N a M pueden ser
cualificadas, las cuales también se pueden considerar como una forma de
asociación ternaria.
Agrupación
Es una forma fuerte de asociación, los componentes de algo se asocian a un
objeto que representa el ensamblaje completo. La agrupación es una forma
especial de asociación, no un conceptoindependiente, si dos objetos están
acoplados mediante una relación todo – parte se trata de una agrupación, si
los dos objetos suelen considerarse independientes entonces se trata de una
asociación; entre las pruebas distintivas se incluye:
1.Utilizaría Ud. la frase "parte – de".
2.Hay algunas operaciones (del todo) que se aplican automáticamente a las
partes.
3.Hay algunos valores de atributos (del todo), que se propagan del todo a
todas las partes o a algunas de ellas.
4.Existe una asimetría intrínseca de la asociación de tal modo que una
clase de objeto sea subclase de otra.
Arbol de agrupación
Es una notación taquigráfica que resulta mucho más sencilla de dibujar que
muchas líneas que contienen los componentes para formar un ensamblado.
Agregados recursivos
Una agregación puede ser fija, variable o recursiva, los agregadosfijos
tienen una estructura fija que será el número y tipo de las partes
componentes que están predeterminadas, los agregados variablestienen un
número finito de niveles, pero el número de partes puede variar, los
agregados recursivos contienen directa o indirectamente una instancia de
esa misma clase de agregado, el número de niveles es ilimitado, la forma
habitual de un agregado recursivo es una superclase y dos subclases en las
32
Pablo Ortiz Cruz
cuales una es un nodo intermedio del agregado y otra es un nodo terminal

del agregado
Generalización y herencia
Son potentes abstracciones para compartir similitudes entre clases al
mismo tiempoque se mantienen sus diferencias, la generalización es la
relación entre una clase y una o más reuniones de esa misma clase que
conecta a la superclase con sus subclases, la leyenda a la par del triángulo
son discriminadores que indica que propiedad del objeto está siendo
abstraído por una relación de generalización en particular.
La herencia ha llegado a ser un sinónimo de reutilización del códigodentro
de la programación orientada a objeto, frecuentemente hay un código que
está disponible de trabajos anteriores ( biblioteca), la aplicación más
importante es la simplificación conceptual que proviene de reducir el
número de características independientes dentro del sistema.
La generalización y especialización son dos puntos de vistas distintos, la
primera proviene del hecho de que la superclase generaliza a la subclase y
la segunda hace alusión al hecho de que la subclase especializa a la
superclase, una subclase puede anular una característica de una superclase
definiendo una característica del mismo nombre, se hace para obtener un
mejor rendimiento.
Herencia múltiple
Permite que una clase tenga más de una superclase y que herede
características de todas ellas, esto permite mezclar informaciónprocedente
de dos o más fuentes, una clase con más de una superclase se denomina
clase unión.
Módulo
Es una construcción lógica para agrupar clases, asociaciones y
generalizaciones, sus límites son ligeramente arbitrarios y son materia
opinable, el nombre del módulo debe especificarse en la parte superior de la
hoja, los módulos nos permiten descomponer al modelo en segmentos
manejables.
Hojas
Una hoja es el mecanismo para descomponer un modelo de objetos grande,
en un conjunto de páginas; por lo general no pondremos más de un módulo
por folio, una hoja es una notación có moda, no una estructura lógica.
Clases abstractas
Es una clase que no tiene instancias directas, en cambio una clase concreta
puede unir instancias discretas, una clase concreta puede formar subclases
abstractas.
Metadatos
Son datos que describen datos, por ejemplo: La definición de clases, los
módulos, los planos, etc.
Claves candidatas
33
A
Análisis y Diseeño de Sistema
as.
Es un conjunto mínimo de atributos que definen de manera unívoca un

objeto. Una clase puede tener más de una c lave candidata, cada una de las
cuales tendrá distintas combinaciones y núm ero de atributos.
La etiqueta de un objeto es siempre una cla ve candidata de una clase, para
las asociaciones son claves candidatas una o más co mbinaciones de objetos
relacionados.
3.3 DESCRIPCIÓN DEL MODELO DINÁMICO .
Modelo Dinámico
Los aspectos del sistema que están relacion ados con los tiempos y con los
cambios constituyen lo modelos dinámicos, los conceptos más importantes
del modelado dinámico son: Los recursos (e stímulos externos) y los estados
(valores de los objetos).
Escenario: Es una secuencia de sucesos que se producen durante una
ejecución completa de un sistema, el ambi ente puede incluir a todos los
sucesos o solo a aquellos que afecten a algunos objetos del sistema, el paso
siguiente a la escritura de un escenario con siste en identificar a los objetos
emisores y receptores de cada suceso. Los objetos que intercambian sucesos
se pueden mostrar en un ambiente m ejorado llamado diagrama de
segmentos de trazos de sucesos.
Actividad: Es una operación cuya realización requiere un cierto tiempo,
toda actividad esta asociada a un esta do; entre las actividades se
encuentran las operaciones continuas, un estado puede controlar una
actividad continua, la cual persiste hasta q ue se produce un suceso que le
da fin, produciendo una transición que sale de ese estado
Acción: Es una operación instantánea que va asociada a un suceso, las
acciones también pueden representar operaciones internas de control, tales
como dar un valor a un atributo o generar o tros sucesos, estas acciones son
mecanismos para estructurar el control dent ro de una implementación.
3.3.1 SIMBOLOGÍA.
El modelo dinámico del sistema que represe nta los aspectos temporales, de
comportamiento y de control de un sistema ( de gran ayuda cuando Se tienen
sistemas en tiempo real o sistemas orien tados a eventos, en donde la
realización de una afecta el comportamient o global del sistema). Describe
las interacciones entre los objetos en el sis tema. Es usado para especificar
e implementar los aspectos de control del si stema. C onsiste en un diagrama
34
Pablo O
Ortiz Cruz
de estados que es un grafo cuyos nodos son estados y los arcos son
transiciones causadas por eventos.
El modelo funcional del sistema, que represe nta los aspectos de

transformación los datos y de función de un sistema. Consiste en un grafo
cuyos nodos son procesos y arcos son flujos de datos, dicho grafo es llamado
diagrama de flujo de datos. La figura 5.3 m uestra los símbolos usados por
este modelo.
Los modelos no son independientes entre sí, mas bien, el objetivo de la

metodología es mantener una relación entre ellos de tal forma que sean una
estructura que permita avanzar consistente mente y que si una cambia sea
fácil el cambiar la siguiente. Así el modelo de objetos describe estructuras
de datos que los modelos dinámico y funcional utilizan. Las operaciones en
el modelo de objetos corresponden a eve ntos en el modelo dinámico y
funciones en el modelo funcional. El modelo dinámico describe la estructura
de control de los objetos mostrando decision es que dependen de los valores
de los objetos en un instante dado.
El modelo funcional describe funciones in vocadas por operaciones en el
modelo de objetos y acciones en el modelo dinámico. Las funciones operan
sobre valores de datos especificados por el m odelo de objetos.
3.3.2 SUCESOS Y ESTADOS.
Sucesos y enlaces
Estados: Son los valores de los atributos y d e los enlaces mantenidos por un
objeto, un diagrama de estado es una redd e estados y recursos, el modelo
35
dinámico consta de múltiples diagramas de estado, cada uno de ellos para

cada clase que contenga un comportamiento dinámico importante y muestre
la actividad del sistema.
Suceso: Es algo que transcurre durante un período de tiempo (ej. "el vuelo
341 sale a Córdoba"); dos sucesos que no tienen relación causal son
concurrentes, no tienen efecto entre sí, un suceso es una transmisión de
información de dirección única entre un objeto y otro.
Todo suceso se agrupa en clases a los que se les da un nombre para una
comodidad de estructura (jerárquica) y de comportamiento, todo suceso
aporta información de un objeto a otro, los valores de los datos aportados
son sus atributos.
3.3.3 ESCENARIOS.
Es una secuencia de sucesos que se producen durante una ejecución
completa de un sistema, el ambiente puede incluir a todos los sucesos o solo
a aquellos que afecten a algunos objetos del sistema, el paso siguiente a la
escritura de un escenario consiste en identificar a los objetos emisores y
receptores de cada suceso. Los objetos que intercambian sucesos se pueden
mostrar en un ambiente mejorado llamado diagrama de segmentos de trazos
de sucesos.
Actividad: Es una operación cuya realización requiere un cierto tiempo,
toda actividad esta asociada a un estado; entre las actividades se
encuentran las operaciones continuas, un estado puede controlar una
actividad continua, la cual persiste hasta que se produce un suceso que le
da fin, produciendo una transición que sale de ese estado
Acción: Es una operación instantánea que va asociada a un suceso, las
acciones también pueden representar operaciones internas de control, tales
como dar un valor a un atributo o generar otros sucesos, estas acciones son
mecanismos para estructurar el control dentro de una implementación.
3.3.4 DIAGRAMAS DE ESTADO.
Los sucesos se pueden representar como operaciones en el modelo de objeto.
Un solo objeto puede tener distintos estados a lo largo del tiempo, pero no
puede tener distintas clases. Las diferencias inherentes entre objetos son
modelados correctamente como clases distintas, mientras que las
diferencias temporales son modelados correctamente como distintos estados
entre los miembros de una misma clase.
Algunos consejos:
1. Solo hay que construir diagramas de estados para las clases que
tengan un comportamiento dinámico.
2. Para comenzar la construcción del diagrama de estado hay que
utilizar escenarios como ayuda.
3. Solo hay que considerar los atributos relevantes
4. Solo hay que dejar que la aplicación distinga acciones y actividades.
5. Cuando un estado tiene múltiples transiciones entrantes y todas
hacen que se produzca una misma acción, hay que poner las acciones dentro
36
Pablo Ortiz Cruz
de cuadros de estados, anteponiendo el suceso de entrada en lugar de

enumerarlas en arcos de transición (lo mismo para los sucesos de salida).
6. Intente hacer que los diagramas de estado de las subclases sean
independientes de los diagramas de estados de sus superclases, estas
deberían concentrarse en los atributos exclusivos de esas subclases.
3.3.5 CONDICIONES Y OPERACIONES.
Una operación es una función o transformación que puede ser aplicada por
los objetos de una clase, todos los objetos de una clase comparten las
mismas operaciones y una misma operación puede aplicarse a clases
distintas, cada operación es polimórfica, es decir que una misma operación
adopta distintas formas en distintas clases.
3.3.6 FUNDAMENTOS DE ESTADO.
Son los valores de los atributos y de los enlaces mantenidos por un objeto,
un diagrama de estado es una red de estados y recursos, el modelo dinámico
consta de múltiples diagramas de estado, cada uno de ellos para cada clase
que contenga un comportamiento dinámico importante y muestre la
actividad del sistema.
3.4 DESCRIPCIÓN DEL MODELO FUNCIONAL.
Describe las transformaciones (de función), de valores de datos que ocurren
dentro del sistema, captura lo que hace el sistema, independientemente de
cuando se haga o de la forma en que se haga. El modelo funcional contiene
diagramas de flujo de datos. Un diagrama de flujo de datos es un grafo
cuyos nodos son procesos y cuyos arcos son flujos de datos, se muestra las
dependencias entre los valores y el cálculo de valores de salida a partir de
los de entrada y de funciones, sin considerar cuando se ejecutan las
funciones, ni siquiera si llegan a ejecutarse.
Las funciones se invocan como acciones en el modelo dinámico y se
muestran como operaciones que afectan a objetos en el modelo de objetos.
3.4.1 SIMBOLOGÍA.
Muestra la forma en la que se derivan los valores producidos en un cálculo
a partir de los valores introducidos, sin tener en cuenta el orden en que se
calculan, consta de múltiples DFD que muestran el flujo de valores desde
las entradas externas a través de las operaciones y almacenes hasta las
salidas externas, las DB suelen tener un modelo funcional no importante.
DFD: Muestra las relaciones funcionales entre los valores calculados por un
sistema incluyendo los valores introducidos, los obtenidos y los almacenes
internos de datos. Un DFD contiene procesos que transforman datos, flujos
de datos, objetos actores que producen y consumen datos y almacenes de
datos que los almacenan en forma pasiva.
Procesos: Transforma valores de datos, los de bajo nivel son funciones
puras sin efectos laterales, un gráfico completo e un flujo de datos es un
proceso de alto nivel y pueden tener efectos laterales como almacenes de
datos de objetos externos.
Flujo de datos: Conecta la salida de un objeto o proceso con la entrada de
otro objeto o proceso, se dibuja como flechas entre el productor y el
37
consumidor (de valores de datos). La flecha esta rotulada con una

descripción de los datos.
Gráficamente: dos líneas paralelas y un nombre.
Flujo de control: Un diagrama de flujo de control muestra todas las posibles
vías de computación para los valores, no muestra cuales son las vías que se
ejecutan ni en qué orden, se muestran con una línea discontinua que va de
un proceso que produce un valor hasta el que se está controlando.
3.4.2 DIAGRAMA DE HOJA DE DATOS.
Una hoja es el mecanismo para descomponer un modelo de objetos grande,
en un conjunto de páginas; por lo general no pondremos más de un módulo
por folio, una hoja es una notación cómoda, no una estructura lógica.
3.4.3 FLUJO DE DATOS, ACTORES Y ALMACÉN DE DATOS.
Actores: Es un objeto activo que controla el gráfico de flujo de datos
produciendo o consumiendo valores, están asociados a las entradas y a las
salidas del gráfico de flujo de datos, se denominan también terminador.
Almacén de datos: Es un objeto pasivo dentro de un DFD, a diferencia de
los actores no genera ninguna operación por sí mismo, sino que almacena y
accede a datos.
3.4.4 FLUJO DE CONTROL.
Flujo de control: Un diagrama de flujo de control muestra todas las posibles
vías de computación para los valores, no muestra cuales son las vías que se
ejecutan ni en qué orden, se muestran con una línea discontinua que va de
un proceso que produce un valor hasta el que se está controlando.
38
Pablo Ortiz Cruz
BIBLIOGRAFIA
Análisis y diseño de sistemas

E. KENDALL, KENNETH y E. KENDALL, JULIE
Sexta edición
PEARSON EDUCACIÓN
México, 2005.
Análisis y diseño de sistemas de información

James A. Senn
Segunda edición
Mc Graw-Hill.
México. 1991
39

Analisis y Diseño de Sistemas

Cargado por

Copyright:

Formatos disponibles

Analisis y Diseño de Sistemas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Analisis y Diseño de Sistemas

Cargado por

Copyright:

Formatos disponibles

ORTIZ CRUZ PABLO

ANÁLISIS Y DISEÑO DE SISTEMAS

FECHA DE INGRESO (PERIODO)

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

1.1 CONCEPTOS GENERALES.

• Debe presentarse y entenderse el dominio de la información de un

Para lograr estos objetivos se requiere tener un gran conocimiento y

El estudio de la viabilidad puede documentarse como un informe aparte

El Diseño del Software es un proceso y un modelado a la vez. El proceso de

• Disponga la presentación de la información en un formato aceptable.

Apoyan el Proceso de formular diseños de Software, incluyendo

• Diseñar y desarrollar la configuración del sistema informático (de

software donde se reconoce que el análisis es una actividad distinta del

3).- Recolección y análisis de los requisitos.

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

• El Analista necesita formular medidas de desempeño con las cuales

Es el Momento en que se evalúa la manera en que funciona el Sistema, esto

características, o el cambio de las existentes. Un ejemplo de este tipo de

1.3.1 ELEMENTOS DEL ANÁLISIS ESTRUCTURADO.

- Está sujeta a comprobaciones de fiabilidad y validez

UNIDAD II: DISEÑO DE SISTEMAS

2.1 HERRAMIENTAS PARA DOCUMENTAR CONCEPTO DE DECISIÓN.

indica una acción y un círculo representa una condición, tal y como se

Determine el número de opciones para cada condición. En la forma más

elaborado y se comparó con el nuevo siste ma de diagramas de flujo para

2.2.2 ALMACENES DE DATOS.

UNIDAD III: MODELADO DE SISTEMAS ORIENTADO A

único modelo ‘‘correcto’’ de una situación, solo existen modelos adecuados o

Representan la funcionalidad del sistema y los requisitos del sistema desde

OBJETOS: Es la representación de una entidad sea real o conceptual. Un

3.2.3 OPERACIÓN, MÉTODOS, ASOCIACION ES Y MULTIPLICIDAD.

Un atributo de un enlace es una propiedad de los enlaces de una asociación.

cuales una es un nodo intermedio del agregado y otra es un nodo terminal

Es un conjunto mínimo de atributos que definen de manera unívoca un

El modelo funcional del sistema, que represe nta los aspectos de

Los modelos no son independientes entre sí, mas bien, el objetivo de la

dinámico consta de múltiples diagramas de estado, cada uno de ellos para

de cuadros de estados, anteponiendo el suceso de entrada en lugar de

consumidor (de valores de datos). La flecha esta rotulada con una

Análisis y diseño de sistemas

Análisis y diseño de sistemas de información

También podría gustarte

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.