IFM-0435 SISTEMAS DE INFORMACION II

UNIDAD I

DISEO CONCEPTUAL
El diseo conceptual se considera como un

anlisis de actividades y consiste en la solucin de

negocios para el usuario y se expresa con los casos
de uso. El diseo lgico es la solucin del equipo de
proyecto del negocio y consiste de las siguientes
tareas:
Identificar los usuarios y sus roles
Obtener datos de los usuarios
Evaluar la informacin
Documentar los escenarios de uso
Validar con los usuarios
Validar contra la arquitectura de la empresa

DISEO CONCEPTUAL
Una forma de obtener estos
requerimientos es construir una matriz
usuarios-actividades de negocios, realizar
entrevistas, encuestas y/o visitas a los
usuarios, de tal manera que se obtenga
quin, qu, cundo, dnde y por qu de la
solucin.

DISEO LGICO
El diseo lgico traduce los escenarios de uso

creados en el diseo conceptual en un conjunto de

objetos de negocio y sus servicios. El diseo lgico se
convierte en parte en la especificacin funcional que
se usa en el diseo fsico. El diseo lgico es
independiente de la tecnologa. El diseo lgico
refina, organiza y detalla la solucin de negocios y
define formalmente las reglas y polticas especficas
de negocios.
El diseo lgico es el proceso de construir un
esquema de la informacin que utiliza la empresa,
basndose en un modelo de base de datos especfico,
independiente del SGBD concreto que se vaya a
utilizar y de cualquier otra consideracin fsica.

ETAPAS Y TAREAS DEL DISEO LOGICO

DETALLADO (disea el exterior y
documentarlo)

1.- Generar alternativas de solucin (mnimo

2) Se puede generar alternativas:
a) Agregando una funcin
b) Eliminando una funcin o fundindola
c) Modificando fuertemente el interior
Se evalan tcnica, econmica y
operacionalmente las alternativas
generadas. (bienes de capital; costo beneficio) y se elige una.

ETAPAS Y TAREAS
2.- Documentar la alternativa elegida Se debe documentar

cada funcin del exterior, en formulario que contendr:

- Nombre de la funcin
- Situacin
- Objetivo; lo que pretende hacer
- Informacin de entrada; y de donde proviene; detallada
- Informacin de salida; y a donde va; detallada
- Archivos internos que usa: fichero, memoria, krdex,....
- Recursos utilizados. Secretaria, mquinas, telfono
fax,....
- Procedimiento general (describir la manera en que ella
se realizar)
- Observaciones

ETAPAS Y TAREAS
3.-Documentar los procedimientos administrativos

Formularios usados; con su diseo. Se debe indicar

todos
los formularios a usar, los que usa ahora, y los que
usar:
- Flujograma de formularios; tabla de doble entrada
origen - destino de los formularios original y copias
que se tiene contemplado utilizar.
- Sistemas de codificacin usados. Los cdigos que se
utilizar, estn ya en uso o a ser usados ahora.

ETAPAS Y TAREAS
4.-Requerimientos al interior.

Se debe especificar
aqu lo que se quiere que el computador acepte como
informacin de entrada a l y que proveniente del
exterior del sistema o medio ambiente, y lo que se
quiere que el computador genere como informacin de
salida para alimentar las funciones contempladas en el
diseo del SI:
Descripcin de la informacin de Entrada, con el
origen, cantidad, periodicidad, tipo.
Descripcin de la informacin de Salida. Se hace por
medio del:
- Diseo de los formularios de salida (listados que se
espera)
- Diseo de las pantallas de consultas (men, formatos
de respuestas)

EL DISEO LGICO GLOBAL

Objetivo:

Establecer las alternativas de diseo en

relacin a la situacin actual, y elegir la

"mejor" de ellas a travs de un proceso de
evaluacin. El resultado final es un conjunto de
funciones a ser realizadas por el sistema, junto
con la especificacin de la manera en que ellas
se llevarn a cabo, los flujos de informacin
que los conectarn y el rol del computador.
Modelos : Se usa dos tipos de modelos para
visualizar el sistema.

1.- Aqu el sistema se concibe como una "malla"

o red de funciones interactuando a travs de

informacin que reciben de entradas de las
funciones relacionadas, y generan salidas hacia
ellas, y que adems regulan el funcionamiento de
la malla de los procesos del sistema.

2 Visualizar el sistema como una particin

jerrquica de cada uno de los elementos que lo

componen en la forma: Entrada -- Funcin -Salida. Los elementos son los que estn en el
modelo descrito en la malla de funciones. Es un
diagrama del tipo rbol.

DISEO FISICO

El diseo fsico traduce el diseo lgico en una

solucin implementable y costo-efectiva o

econmica.
El componente es la unidad de construccin
elemental del diseo fsico. Las caractersticas de
un componente son:
Se define segn cmo interacta con otros
Encapsula sus funciones y sus datos
Es reusable a travs de las aplicaciones
Puede verse como una caja negra
Puede contener otros componentes

Acoplamiento y Cohesin

ACOPLAMIENTO:
Mide el grado de independencia entre los mdulo. Un

buen diseo debe minimizar el acoplamiento (aumentar

la independencia.) por las sig. Razones:
1 Cuanto menos conexiones existan entre 2 mdulos,
menos oportunidad hay de que aparezca el efecto RIPPLE
(1 defecto de 1 mdulo aparece afectando a otro).
2 Se desea poder cambiar un modulo sin que afecte a
otro.
3 Mientras se mantiene un mdulo, no debemos
preocuparnos de otro, mxima sencillez.

COHESIN:
Mide el grado de integracin de los elementos

de un mdulo, para organizar todos los

elementos de forma que los que estn ms
relacionados a la hora de realizar una tarea
pertenezcan al mismo mdulo y los elementos
relacionados entre s en mdulos separados.

Cuanto ms vinculados estn los elementos

de un mdulo, ms fuerte es su cohesin, lo

que lleva a un mejor acoplamiento y a un
mejor sistema (el SW es fcil de mantener y
los mdulos fciles de usar).
A medida que aumenta el nmero de
mdulos, el coste por interfaz crece y el
esfuerzo para desarrollar cada mdulo
decrece.

Iceberg de la usabilidad
Qu es la Arquitectura del Software y

que relacin tiene con la usabilidad.

Tener en cuenta la usabilidad en el
momento del diseo de la arquitectura
de un sistema interactivo nos puede
ahorrar muchos problemas.

Se podra decir que, en el diseo de un

sistema, hay tres aspectos a tener en cuenta:

la presentacin de la informacin
la funcionalidad de la aplicacin
la Arquitectura del Software
Cuntas veces hemos tenido que correr a

realizar cambios profundos en la funcionalidad

de una aplicacin despus de haber detectado
problemas de usabilidad?

Arquitectura de software y
usabilidad
El usuario pueda visualizar el progreso de sus

peticiones, que pueda deshacer acciones (undo), que

pueda disponer de un entono multilinge, que pueda
cancelar una operacin que lleva mucho tiempo en
espera, que pueda reutilizar informacin que ha
introducido anteriormente, y muchas otras cosas.
Si analizamos estos escenarios de interaccin,
veremos que la causa de que no se puedan
implementar es que no se tuvo en cuenta al usuario
al inicio del diseo del sistema, es decir, en la
Arquitectura del Software.

Arquitectura de software
Arquitectura del Software es el diseo de ms alto nivel
de la estructura de un sistema, programa o aplicacin y
tiene la responsabilidad de:
Definir los mdulos principales
Definir las responsabilidades que tendr cada uno de
estos mdulos
Definir la interaccin que existir entre dichos mdulos:
Control y flujo de datos
Secuenciacin de la informacin
Protocolos de interaccin y comunicacin
Ubicacin en el hardware

La definicin oficial de Arquitectura del

Software es la IEEE Std 1471-2000 que reza

as: La Arquitectura del Software es la
organizacin fundamental de un sistema
formada por sus componentes, las relaciones
entre ellos y el contexto en el que se
implantarn, y los principios que orientan su
diseo y evolucin

Uno de los modelos ms conocidos es el 4+1 de Philippe

Kruchten, vinculado al Rational Unified Process (RUP), que

define cuatro vistas diferentes:
Vista lgica: describe el modelo de objetos.
Vista de proceso: muestra la concurrencia y sincrona de los

procesos.
Vista fsica: muestra la ubicacin del software en el hardware.
Vista de desarrollo: describe la organizacin del entorno de
desarrollo.
Existe una quinta vista que consiste en una seleccin de casos
de uso o de escenarios que los arquitectos pueden elaborar a
partir de las cuatro vistas anteriores

Heursticas de diseo
Las heursticas de diseo son un conjunto de

recomendaciones que ayudan a mejorar la

estructura del sistema, optimizando la
modularidad. La aplicacin de estas
recomendaciones depende en gran medida
del diseo especfico, as como de las
caractersticas del equipo fsico donde se
desarrolla el sistema.

1).- Tamao del mdulo

El desarrollo del sistema de una estructura modular

define la funcionalidad propia de cada mdulo. Sin

embargo, es recomendable revisar independientemente
cada mdulo a efectos de optimizar su tamao en
nmero de sentencias, para facilitar el desarrollo
tcnico del programa y su posterior mantenimiento.
En general, podemos resumir diferentes versiones

sobre el tamao ptimo de un mdulo definiendo que,

el coste en el desarrollo y mantenimiento de un sistema
ser ptimo, cuando su estructura est compuesta por
mdulos con un tamao comprendido entre 10 y 100
sentencias.

Tamao del mdulo

Un mdulo demasiado grande a menudo puede deberse a:
a) Dos o ms funciones han sido combinadas (frecuentemente con
cohesin lgica) en un mismo mdulo.

2).- mbito de control

Se llama mbito de control de un mdulo a

todos los mdulos llamados por l y a los

llamados por stos, es decir, a todos los
mdulos que hay por debajo de l, en esa rama
del diagrama de descomposicin funcional.
Un mdulo que llama a muchos otros puede ser
difcil de entender, y en el otro extremo, si los
mdulos forman una larga secuencia lineal, es
posible que pueda suprimirse alguno de ellos.
Debe evitarse ambos extremos:

Ambito de control alto:

Normalmente se produce cuando no se tienen en cuenta los

niveles intermedios. El estudio de los grupos de mdulos

subordinados que permitan combinar sus funciones en una
sola, puede solucionar el problema.
Resistencia por parte del diseador a delegar
responsabilidades en mdulos subordinados.

Solucin: debe considerarse la posibilidad de agruparse

varios subordinados en una funcin combinada. El principio de

cohesin debe guiar este proceso para evitar mdulos de baja
cohesin.

mbito de control bajo:

Para optimizar una estructura de este tipo se deben

revisar las posibilidades de descomponer las

funciones en subfunciones con entidad propia, para
formar nuevos mdulos, o por el contrario, comprimir
mdulos subordinados en el mdulo de nivel
superior. esto es vlido si se puede dar a los nuevos
mdulos un sentido dentro de la estructura del
problema.

mbito de control
correcto