Plantilla Diseo del Sistema

Apreciado aprendiz, debe diligenciar este informe con el fin de determinar el

Informe Final de Diseo de Arquitectura Tecnolgica que utilizara el sistema de
informacin.
Recuerde: Para realizar este informe usted debe recopilar las evidencias
realizadas durante toda la fase de Diseo tratadas en las guas de aprendizaje
correspondientes.
Esta plantilla corresponde con la Descripcin del Diseo del Software y se basa
en el estndar empleado para desarrollar esta documentacin de forma
normalizada como lo es el IEEE Std. 1016-1998, que identifica prcticas
recomendadas para describir los diseos de software. Especifica la informacin
que debe contener, y recomienda cmo organizarla.

1. Introduccin
1.1. Propsito del sistema.
Este software se basara en el estndar IEEE 1016 para representar el diseo
del software que ser usado para registrar la informacin del diseo y para que
las partes interesadas lo conozcan
Este estndar puede ser utilizado para cuando se necesite alguna revisin.
Actualizacin o reconstruccin del software.
El Propsito de este artefacto podr ser usado para modelar y representar los
mdulos, clases y procesos detalladamente tomando en cuenta el punto de
vista del programador, ingeniero de diseo y el las partes interesadas as como
los requerimientos previos
Lenguaje de programacin

1.2. Objetivos del diseo

Servir como documento de referencia para el diseo del software, conocer
los aspectos bsicos del software
Orientar el cumplimiento de los requisitos tcnicos estipulados por la clnica
LA CAMPIA

1.3. Definiciones, acrnimos y abreviaturas

La clase admin principal cuanta con 4 atributos idAdminP, nombre, apellido,
direccin, telfono, los cuales servirn para guardar datos del adminr.
Tambin tiene un mtodo para los administradores secundarios IdadminS que
servir para inicializar los datos esos administradores al momento de registrar
o necesitar alguna informacion.
El mtodo actualizar servir para cambiar cualquier dato de los
administradores.
Finalmente el mtodo eliminar servir para borrar todos los datos de un
administrador en especifico.

La clase paciente contendr 1 atributo: idPaciente que ser de tipo entero y 4

de tipo String (nombre, apellido, cedula, carnet de salud direccin, telfono.)
Tiene un constructor paciente que se encargara de inicializar los datos del
paciente al crear una instancia.
El mtodo actualizar, permitir hacer un cambio en los datos del paciente,
excepto el idPaciente.
El mtodo eliminar, eliminara a un Paciente de la base de datos.

1.4. Referencias
EEE830, IEEE 802.15.1
AP1-AA3-Ev1-Lista de requerimientos funcionales y no funcionales del Proyecto.
AP3-AA3-Ev1-Informe de Anlisis del Sistema de Informacin

2. Representacin de la arquitectura.
2.1 Metas y restricciones de la Arquitectura
Clasificacin
Usabilidad

Requerimientos
Descripcin
Se enfoca a las
RNF-04 - La cdula Del paciente que se
caractersticas de
muestre en el sistema debe permitir
esttica y consistencia enconsultas de la forma ms fcil e
las interfaces grficas
intuitiva posible.

RNF-05 - La resolucin mnima para una

Clasificacin

Descripcin

Requerimientos
buena visualizacin del sistema ser de
800x600 pxeles.

RNF-18 - El sistema debe permitir ser

usado intuitivamente por cualquier
usuario

Confiabilidad

Rendimiento

Soporte

RNF-19 - En caso de error del usuario el

sistema
informar
claramente
el
mensaje del error y una solucin
entendible.
RNF-20 - El sistema estar disponible
solo los das de atencin en la clinica

Se enfoca con las

caractersticas como
disponibilidad (el tiempo
disponible del sistema),
exactitud de los clculos
del sistema, y las
habilidades del sistema
para recuperarse durante
fallos.
Se enfoca con las
RNF-17 El sistema debe demorarse no
caractersticas como
ms de 1 segundo en registrar un
tiempo de respuesta,
paciente.
tiempo de iniciacin y
trmino.
Se concentra en las
RNF-03 - El sistema mostrar su interfaz
caractersticas como
en los idiomas espaol e ingls.
pruebas, adaptabilidad,
mantenimiento,
configuracin,
RNF-16 - El sistema debe trabajar sobre
Instalacin, escalabilidad,cualquier navegador con soporte para el
y localizacin.
protocolo http versin 1.1

Consideraciones d
e diseo

Especifica las opciones

del diseo para el
sistema.

RNF-01 Todos los mdulos del sistema

sern desarrollados con base en la
tecnologa J2EE y el uso del Framework
Struts versin 1.3.8 con Tiles e iBatis
versin 2.1.6.

RNF-02 El sistema considera una

arquitectura lgica de tres capas: Datos,

Clasificacin

Descripcin

Requerimientos
Negocio y Presentacin.

RNF-14 - La base de datos ser MySQL

en su versin 5. Esta ser centralizada y
provista por el Usuario.

Requerimientos de
implementacin

Especifica la codificacin RNF-01 Todos los mdulos del sistema

o construccin del
sern desarrollados con base en la
sistema, pueden ser
tecnologa J2EE y el uso del Framework
estndares,
Struts versin 1.3.8 con Tiles e iBatis
implementaciones,
versin 2.1.6.
lenguajes y lmites de los
recursos.

RNF-13 - Estndar de codificacin

MEDESOFT 1.1
Requerimiento
Especificaciones fsicas RNF-15 - El sistema debe trabajar sobre
fsicos
impuestas por el
cualquier computador que cuente con
hardware usado para
estos requerimientos mnimos: con
mantener el sistema.
procesador Pentium III o superior, 500
Mb de memoria RAM y disco duro de 20
Gb de almacenamiento.
Aspectos Generales Especifica los
RNF-10 - A cada usuario se le asignar
requerimientos de
un login y una clave del sistema, los
seguridad que deben
cuales le permitirn el ingreso de
tener el sistema y sus
acuerdo un perfil determinado.
caractersticas generales.

RNF-11 - Permitir que el usuario pueda

cambiar la contrasea de acuerdo a las
polticas de seguridad de la
organizacin.

RNF-09 - La encriptacin del canal de

transmisin ser mediante el protocolo
SSL. Este ser provisto y configurado
por el Usuario.

2.2 Reutilizacin
Un framework da soporte a los desarrolladores en la creacin de
soluciones a problemas dentro de un dominio concreto. Las aplicaciones
se construyen extendiendo el framework base con funcionalidad propia

de la aplicacin a desarrollar. Definen las interacciones clave entre las

clases del dominio.
Las clases abstractas son los elementos
fundamentales para la construccin de framework. Un framework es
incompleto por definicin.
Qu aporta un framework?:
Infraestructura y gua arquitectnica.
Calidad, mantenibilidad y reusabilidad.
Ofrecen mecanismos para la correcta extensin.
El uso de masivo de clases abstractas e interfaces reduce el
acoplamiento entre clases

3. Vista lgica
se pueden identifcar dos grandes componentes en el sistema: Communication
y Simulator. El primero, tienen como responsabilidad manejar todo lo necesario
para llevar a cabo la comunicacin del sistema con los agentes que
eventualmente se conecten al sistema. Esto significa que es su responsabilidad
mantener toda la informacin necesaria referente a los agentes externos y el
envo y recepcin de informacin. El otro componente, denominado Simulator
es el responsable de modelar la simulacin que se desea crear y gestionar su
evolucin. A continuacin se puede ver un diagrama que incluye ambos
componentes

3.1 Identificacin de Subsistemas

Con el fin de organizar y facilitar el diseo, se realiza una divisin del

sistema de informacin en subsistemas de diseo. Estos pueden ser
subsistemas especficos y subsistemas de soporte, con la finalidad de
independizar, en la medida de lo posible, las funcionalidades a cubrir
por el sistema de informacin de la infraestructura que le da soporte.
Los subsistemas especficos contemplan las funcionalidades propias
del sistema de informacin, mientras que los de soporte cubren
servicios comunes, proporcionando un acceso transparente a los
distintos recursos. Tomando como referencia el modelo de
subsistemas realizado en el anlisis y la arquitectura definida en el
punto.

3.2 Estructuracin por capas.

Una vez que se han determinado los subsistemas, agruparlos mediante una
estructuracin por capas, donde cada una determina un nivel de abstraccin.
Determinar el nmero de capas a implementar, acorde con el sistema
Nombrar cada capa y definir su funcionalidad
Asignar los subsistemas / paquetes /clases que corresponden con cada capa
Se pueden utilizar diagramas de paquetes

3.3 Diagrama de Clases del diseo

4. Vista del proceso

Describe la descomposicin del sistema en procesos, se debe representar la informacin
solicitada utilizando diagramas de secuencia para tres de los casos de uso ms
representativos del negocio.

4.1 Diagramas de secuencia

Se debe representar la informacin solicitada utilizando diagramas de secuencia
especficos del proyecto (diagramas de interaccin de objetos), preferiblemente
utilizando la notacin UML. Donde sea posible, los diagramas explican el proceso de
interaccin requerido por los casos de uso principales.

5. Vista de datos
Describe el modelo de datos del sistema que se va a desarrollar. Se realiza la
identificacin a travs de diagramas relacionales que presenten el modelo de base de
datos a implementar y su descripcin usando el diccionario de datos.

5.1 Modelo de datos

Se presenta el modelo relacional de la base de datos a travs de un diagrama, donde

se identifican las tablas, campos y relaciones entre tablas que fueron definidas para
almacenar los datos del sistema de informacin.

5.2 Diccionario de datos

Se puede construir el formato especfico que detalle para cada una de las tablas los
campos, tipos de datos y restricciones o elementos de integridad a ser incorporados.
Tambin se pueden utilizar los generados por herramientas CASE.

6. Vista de Interaccin
Se deben presentar las distintas interacciones con las que contar la aplicacin, para
lo cual se presenta las interfaces de usuario.

6.1 Interfaces de Usuario.

Lista y describe las interfaces de usuario de la aplicacin, especificarlas por caso de
uso.

6.2 Mapa de Navegacin

Presenta la estructura global de navegacin de la aplicacin.

7. Vista de seguridad
Describir los distintos elementos y sistemas de seguridad con los que cuenta el
software.
Sistema de Acceso
Se debe definir de forma clara el acceso al sistema: nivel de seguridad de acceso,
empleo de las claves de acceso. Incluir la segmentacin de procesos, perfiles y roles
y los mecanismos de autenticacin a implementar en el sistema
Cifrado de datos
Existe informacin en la base de datos que debe ser cifrada o encriptada. Si es as
que algoritmos de encripcin se utilizaran.

8. Vista de Implementacin
Describe la estructura general del modelo de implementacin y la descomposicin del
sistema.

8.1 Herramientas de Desarrollo e implementacin

Describe las herramientas tecnolgicas que se deben utilizar para el desarrollo del
sistema, incluye: IDE, Lenguaje de Programacin, base de datos, framework, etc.
Adems el software que se requiere para su ejecucin y puesta en marcha: servidor
de aplicaciones/web, Sistema de base de datos, Librerias, plugins, etc.

8.2 Paquetes/Componentes
Describir el modo principal de comunicacin entre los procesos del sistema operativo.
Incluir diagramas de componentes.

8.3 Despliegue
Describir la configuracin de la plataforma fsica (procesador/almacenamiento) en la
que el software va a ser desplegado. Si el sistema se va a desplegar en varios sitios,
proporcionar una vista de despliegue para cada sitio diferente. Como mnimo, para
cada configuracin, se deben indicar los nodos fsicos (ej.: ordenadores, CPUs,
memorias) que ejecutan el software y sus interconexiones (ej.: bus, topologa LAN,
punto a punto, WAN).
Incluir un mapeo entre los procesos de la vista de proceso y los nodos fsicos. La
notacin preferida es UML para la vista de despliegue.

8.4 Vista de Administracin

Describe las distintas opciones de la administracin del software.