capítulo 2: diseÑo de sistemas

Capítulo 2:DISEÑO DE SISTEMAS.

Ing. Alejandra Colina V.

Septiembre, 2019

Conceptos y Principios.

Importancia de un buen diseño.Diseño de Los Datos.

Diseño Arquitectónico. Diseño de la Interfaz.

Diseño de los Procedimientos

ANALISIS DE SISTEMA

Sistema Contexto Teórico Modelos de DatosFases Preliminar Metodologías

Tradicionales

Ágiles

Lineal

Prototipo

DFD

Estructurada

D. Clases

Casos de Usos

Analista Usuario

Téc. de Recop.

Entrevista

Iden. Problema

Deter. Requerim

Análisis Costo-Ben

Los pasos son:

Ciclo de Vida

Análisis

Diseño

Objetivos

Sistema Experto

Información critica

SIE

SDE

Corporativa

Cto. elementos

Transaccionales

Necesidades

Entorno remoto

Interna Administrativo

Del Análisis al Diseño de Sistemas

¿Qué documento

surge en el

análisis?

¿Qué se hace

en el análisis?

¿Cómo es el

paso al Diseño

de Sistema?

Conceptos

• Significado:

• Proceso por el que se genera una solución a un

problema

• Descripción de la solución

DISEÑO

Diseño 1

Diseño 2

Diseño n

...

Requerimientos

Restricciones

Distintos

Diseños

(Alternativas)

permiten

cumplir con los

requerimiento,

pero cada uno

ofrece

prestaciones

específicas

• Proceso de planificar, reemplazar o complementar un sistema organizacional

existente.

• Consiste en aplicar ciertas técnicas y principios con el propósito de definir

un dispositivo, un proceso o un sistema, con suficientes detalles para

permitir su interpretación y realización física

• Se requiere comprender, el viejo sistema y determinar la mejor forma en que

se pueden utilizar recursos tecnológicos para incorporar eficiencia.

Conceptos

DISEÑO

• Se trata de describir los datos calculados o almacenados

que se introducirán seleccionando la estructura de los

archivos y los dispositivos de almacenamiento ya sean

digital o físicos (papel).

Conceptos

DISEÑO

• Los procedimientos deben demostrar cómo se

procesarán los datos y sus salidas, en pocas palabras el

diseño de sistemas es una combinación de actividades y

procedimientos para lograr aquellos objetivos

organizacionales

Conceptos

DISEÑO

• El diseño de sistemas es un proceso creativo en el que el

analista repite a través de varias actividades o

procedimientos de trabajo, uno a la vez, investigando

mentalmente a través del proceso completo.

Conceptos

DISEÑO

• El analista debe tener en cuenta dos puntos importantes:

1. Resuelva un problema a la vez. No se confunda al

querer resolver muchos problemas a la vez.

2. Su nuevo sistema debe concordar con los objetivos y

metas generales del área bajo estudio y la empresa en

sí.

Conceptos

DISEÑO

• Los puntos a seguir cuando se diseña un nuevo sistema

son:

1. Examine todos los datos posibles.

2. Concéntrese y piense en forma creativa.

3. Proporcione diferentes entradas, salidas, operaciones,

controles y técnicas de procedimiento.

4. Primero evalúe los procedimientos más importantes.

5. Examine las diversas alternativas.

Conceptos

DISEÑO

• El diseño de un sistema de información se define como

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.

Conceptos

DISEÑO

• 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.

Conceptos

DISEÑO

Planeación:

❖ Definición de Objetivos. Se determinan las metas y el plazo

esperado para su obtención.

❖ Formulación de Estrategias. Se establece la metodología a

seguir, seleccionando las técnicas más adecuadas.

❖ Determinación de Recursos. Se identifican los recursos

humanos, técnicos y materiales que se necesitarán.

❖ Elaboración del Plan de Trabajo. En función a la prioridad, tiempo

y recursos disponibles se formula el programa de actividades.

Conceptos

Actividades Del Diseño De Un Sistema De Información:

Diseño de Salidas:

❖ Interpretación de Requerimientos. Con base a las

especificaciones resultantes de la “Definición de Productos de

Información” hecha en el análisis, se determina la forma de

presentación más adecuada, de contenido

❖ Diseño Físico. Las especificaciones del reporte son plasmadas

en un “Lay - Out” que es una hoja cuadriculada, en donde se

precisa el número de renglón y columna en donde se imprimirá la

información.

Conceptos


Definición de la Base de Datos:

❖ Descripción Completa de Datos. Se determina con exactitud el conjunto de

datos a manejar con sus características físicas de: tipo, longitud y código de

equivalencia.

❖ Elaboración de Estructuras de Datos. Se tipifican los datos con base a su

naturaleza y fuente de actualización y uso en la generación de salidas.

❖ Establecimiento del Modelo de Datos. Se conciben los grupos lógicos de

datos (archivos), sus relaciones y formas de acceso (mediante claves),

estableciendo un modelo lógico de base de datos.

❖ Definición del Tipo Organización. Acceso y formato de los archivos,

identificando sus campos, llaves y orden de almacenamiento.

Conceptos


Diseño de Entradas:

Interpretación de Requerimientos. Con base a las

especificaciones hechas en la definición de insumos por el

análisis y la definición de la base de datos, se establecen

los medios (documentos, parámetros, etc.) que alimentarán

y actualizarán los archivos que integran al sistema,

determinado el contenido (datos, cifras de control, etc.) y

medio adecuados.

Conceptos


Definición de Procesos:

❖ Establecimiento de la Arquitectura del Sistema. Se definen los

principales procesos que harán el sistema y sus interrelaciones mediante

las entradas y salidas que manejan.

❖ Descripción de Procesos. Para cada proceso definido en la

arquitectura del sistema, se determina: su objetivo (captura, validación,

actualización, clasificación, selección, cálculo, comparación, impresión,

explotación, respaldo, etc.), resultados a producir (reportes, archivos,

desplegados, etc.) y descripción del procedimiento que realiza (lectura

de archivos, selección de registros especiales, etc.).

Conceptos


Control:

❖ Presentación del Sistema. El resultado de las actividades anteriores

es plasmado en un documento que describe los principales elementos

del sistema de información.

❖ Revisión de la Propuesta. Se evalúan los formatos de salidas

conforme a las necesidades planteadas, se valida el contenido de las

entradas y los archivos que se manejan, repasando los procesos que se

pretenden realizar.

❖ Modificaciones a la Propuesta. Se adaptan aquellas diferencias y

errores encontrados en el diseño del sistema propuesto.

Conceptos


Guías para un Diseño de Calidad

. . .Hay una diferencia entre hacer que

un software trabaje, y hacerlo que

trabaje correctamente. . .

1. Un buen diseño debe tener una arquitectura que:

• Creado utilizando estilos o patrones “reconocidos”

• Conformado por componentes

• Implementado de una manera evolutiva

2. Un buen diseño es modular, es decir, puede partirse de manera lógicaen elementos o subsistemas.

3. Un buen diseño contiene representaciones diferenciales de datos,arquitectura, interfaces y componentes.

4. Un buen diseño debe conducir a estructuras de datos que sonapropiadas para las clases a implementarse, y que resultan de patronesreconocidos.

21


4. Un buen diseño con componentes y características funcionales independientes.

5. Un buen diseño debe conducir a interfaces que reducen la complejidad de las conexiones entre componentes y el medio externo.

7. Un buen diseño debe llevarse a cabo utilizando métodosrepetibles y que es conducida por la información obtenida en elanálisis.

8. Un buen diseño debe representarse usando una notación quees efectiva en la manera que comunica el significado deldiseño.

22


Atributos de Calidad en el Diseño

• Funcionalidad

• Usabilidad

• Confiabilidad

• Desempeño

• Sustentabilidad

…qué importancia tiene??

Diseño de los Datos.

▪ Trasforma el modelo de dominio de la información, en las estructuras

de datos necesarios para implementar el software.

▪ Crea el modelo de datos e información, representado en un nivel de

abstracción alto, y se va refinando progresivamente.

▪ Traduce en bases de datos, para formar los “warehouses” que permitirán

el manejo de sistemas administradores de conocimiento de la empresa.

Diseño Arquitectónico.

▪ El modelo de arquitectura se obtiene principalmente de tres fuentes:

• Información acerca del dominio de aplicación del software a

construirse

• Elementos del modelo de análisis: diagramas de flujo o clases

generadas en el análisis sus relaciones y colaboraciones

• Disponibilidad de patrones de arquitectura

▪ Define la relación entre cada uno de los elementos estructurales del

programa.


Los subsistemas que componen un sistema deben intercambiarinformación con el fin de que puedan trabajar de forma conjunta y efectiva.

Existen dos formas:

▪ Todos los datos compartidos se ubican en una base de datos centralque pueda ser accedida por todos los subsistemas.

▪ Cada subsistema tiene su propia base de datos. Los datos seintercambian con otros subsistemas pasando mensajes entre ellos.

Estructura del sistema – Modelo de Depósito


Ventajas✓ Eficiente para compartir grandes cantidades de datos.✓ Los subsistemas están acordes al modelo de depósito de datos.✓ Las actividades de respaldo, seguridad, control de acceso y recuperaciónde errores están centralizadas. Son responsabilidad del deposito.

DesventajasSi se genera un gran volumen de información, será difícil evolucionar si se

ha acordado un modelo de datos. Traducir esto en un nuevo modelo serácostoso, puede ser difícil, e incluso imposible.

El modelo de depósito fuerza a los subsistema a las mismas políticas deseguridad.

Estructura del sistema – Modelo de Depósito


Es un modelo de sistemas distribuidos que muestra como los datos y elprocesamiento se distribuyen a lo largo de varios procesadores.

Componentes:

Servidor 1

Servicio 1

Servidor 2

Servicio 2

Servidor 3

Servicio 3

RED

Clientes Clientes Clientes Clientes

Ofrecen Servicios

Llaman a los servicios ofrecidos

Permite a los clientes acceder a los servicios

Estructura del sistema – Modelo Cliente - Servidor


Los clientes necesitan conocer los nombres de los servidores y losservicios que suministran. En cambio, los servidores no requieren conocerla identidad de los clientes o cuantos clientes existen.

La ventaja, es su arquitectura distribuida. Ya que, es fácil agregar omodificar un nuevo servidor sin afectar a otras partes del sistema.

Desventajas, necesitan seguridad más elaborada, administración delsistema y desarrollo de aplicaciones.

Estructura del sistema – Modelo Cliente - Servidor


▪ Modela la interacción entre los subsistemas.

▪ Organiza el sistema en una serie de capas, cada una de las cuales suministraun conjunto de servicio.

▪ Un modelo bien conocido para este enfoque es el modelo de referenciaISO/OSI.

Subsistema 5

Subsistema 1

Subsistema 2

Subsistema 3

Subsistema 4

Estructura del sistema – Modelo de Capas


▪ Este modelo es una arquitectura cambiable y portable. Cuando se cambiao elimina una capa, solo se verán afectadas sus capas adyacentes.

▪ Una desventaja del enfoque, es que estructurar los sistemas de está formaes difícil.

▪ El desempeño también puede ser un problema debido a los múltiplesniveles de interpretación de ordenes que algunas veces se requieren.

Estructura del sistema – Modelo de Capas


Los modelos para estructurar un sistema se refieren a la manera en que unsistema se descompone en subsistemas.

El diseñador debe organizar los subsistemas acorde a un modelo de control quecomplemente el modelo estructural que se utiliza.

Se identifican dos enfoques:

➢Control Centralizado: un subsistema tiene completa responsabilidad paracontrolar, iniciar, y detener a otros subsistemas. Puede entregar el control,pero se lo deben devolver.

➢Control basado en eventos: cada subsistema puede responder a eventosgenerados en el exterior.

Modelos de Control

Sergio Sánchez Rios

Un subsistema se designa como controlador del sistema y tiene la

responsabilidad de administrar la ejecución de otros subsistemas.

Existen dos enfoques:

Modelo de llamada - retorno: éste es el modelo familiar de subrutinas

descendentes, donde el control se inicia en la parte superior de una jerarquía

y por medio de llamadas a las subrutinas pasa a los niveles inferiores del

árbol.Programa Principal

Rutina 1 Rutina 2 Rutina 3

Rutina 1.2Rutina 1.1 Rutina 3.1 Rutina 3.2

Aplicable solo a sistemas secuenciales

Modelos de Control – Control Centralizado


Modelo del administrador: se aplica a los modelos concurrentes. Un

componente del sistema se designa como un sistema administrador y controla

el inicio, detención y la coordinación de otros procesos del sistema.

Controlador delSistema

Proceso 1 Proceso 2

Proceso 3 Proceso 4

Modelos de Control – Control Centralizado


Los modelos de control dirigidos por eventos se rigen por eventos generados

en el exterior.

Existen varios sistemas dirigidos por eventos que se pueden desarrollar. Ej.:

las hojas de calculo, en la que el valor cambiante de las celdas provoca que

otras celdas se modifiquen.

Modelo de Transmisión: en estos modelos, un evento se transmite, en

principio a todos los subsistemas. Cualquier subsistema que pueda manejar

ese evento responde a él.

Modelos de Control – Dirigido por Eventos


La ventaja de este modelo, es su evolución relativamente sencilla. Un nuevo

subsistema que maneje clases particulares de eventos, se puede integrar

registrando sus eventos en el controlador de eventos.

La desventaja es que los subsistemas no saben si los eventos se

manejarán, ni cuando lo harán.

Controlador de eventos y mensajes

Subsistema1

Subsistema2

Subsistema3

Modelos de Control – Dirigido por Eventos


Estos se utilizan exclusivamente en sistema de tiempo real, donde las

interrupciones externas son detectadas por un controlador de interrupciones.

Después éstos se pasan a algún componente para su procesamiento.

Controlador1

Controlador2

Controlador3

Controlador4

Proceso1

Proceso2

Proceso3

Proceso4

INTERRUPCIONES

Vector de interrupciones

Modelos de Control – Dirigido por Interrupciones


Se consideran dos modelos que son de utilidad cuando se descompone un

subsistema en módulos:

▪ Modelo orientado a objetos: el sistema se descompone en un

conjunto de objetos que se comunican entre ellos. Son objetos con

estado privado y con operaciones definidas sobre ese estado.

▪ Modelo de flujo de datos: el sistema se descompone en módulos

funcionales que afectan entradas de datos y las transforman, de

alguna manera, en datos de salida. Son transformaciones funcionales.

Descomposición modular


El modelo orientado a objetos de una arquitectura de sistema, estructura el

sistema en un conjunto de objetos débilmente acoplados con interfaces bien

definidas.

Los objetos llaman a los servicios ofrecidos por otros objetos.

Una descomposición orientada a objetos, comprende clases de objetos, sus

atributos y operaciones.Cliente

Cliente#NombreDirecciónPeriodo de crédito

Recibo

Factura#FechaMontoCliente#

Pago

Factura#FechaMontoCliente#

Factura

Factura#FechaMontocliente

Emitir()enviarRecordatorio()aceptarPago()enviarRecibo()

Descomposición modular – Modelo de Objetos


Las ventajas de este modelo son bien conocidas, puesto que los objetos

están débilmente acoplados, la implementación de objetos se puede

modificar sin afectar a otros objetos.

Además, los objeto se pueden reutilizar.

La desventaja, es que los objetos para utilizar los servicios deben hacer

referencia explicita al nombre y la interfaz de otros objetos.

Descomposición modular – Modelo de Objetos


En un modelo de flujo de datos, las transformaciones funcionales

procesan sus entradas y producen sus salidas .

Los datos fluyen de un lugar a otro y se transforman durante este

movimiento.

Leer facturasemitidas

IdentificarPagos

Emitir Recibos

Hallar pagosretrasados

Emitir RecordatorioDe pago

Facturas Pagos

Recordatorios

Recibos

Descomposición modular – Modelo de Flujo de datos


Ventajas:

✓ Permite la reutilización de transformaciones.

✓ Es intuitivo.

✓ Permite que el sistema evolucione al agregar nuevas transformaciones.

✓ Sencilla de implementar, ya sea como un sistema concurrente o

secuencial.

Desventajas:

Cada transformación debe estar acorde con las transformaciones que

se comunica, en el formato de los datos a ser procesado.

Descomposición modular – Modelo de Flujo de datos


• Describe cómo se comunica el software consigo mismo, con los sistemasque operan junto con él y con los operadores y usuarios que lo emplean.

• Como la información fluye entrando y saliendo del sistema, y se comunican através de los componentes definidos como parte de la arquitectura.

• Los elementos importantes en el diseño de interfaces:

✓ Interfaz con el usuario

✓ Interfaces externas con otros sistemas, dispositivos, redes u otrosproductores o consumidores de información

✓ Interfaces internas entre los diferentes componentes de diseño

Diseño de la Interfaz

Diseño de interfaces externas

• Requiere información definitiva sobre la entidad a la cual la información se

manda o recibe.

• Debe incluir pruebas de errores y características de seguridad


Diseño de interfaces internas

▪ Está fuertemente relacionado con el diseño a nivel componentes (diseñodetallado)

▪ En algunos casos, una interface se diseña de igual manera que una clase.

▪ Según la OMG “una interfaz es un especificador de operacionesexternamente visibles (publicas) de una clase, componente u otro clasificador(incluyendo subsistemas) sin la especificación de una estructura interna”

▪ Una interfaz es un conjunto de operaciones que describe alguna parte delcomportamiento de un sistema y las operaciones necesarias para accesaresas operaciones


▪ 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.

▪ Permite materializar con precisión los requerimientos del cliente.

▪ Es un proceso y un modelado a la vez.

Diseño de la Procedimientos

capítulo 2: diseÑo de sistemas

Documents