Está en la página 1de 15

Sistema de Seguridad

Software Architecture Document Fecha: 02/Octubre/2017

Sistema de Seguridad
Documento de Arquitectura de Software

1. Introduccin

Propsito: Este documento proporciona una descripcin de la arquitectura global


del sistema, utilizando diferentes vistas arquitectnicas para representar los
diferentes aspectos del sistema. Est pensada para capturar y transmitir las
decisiones importantes en la arquitectura que se han realizado en el sistema.

Alcance: Este documento de arquitectura de software se aplica al Sistema de


Seguridad que ser desarrollado como producto final para la materia de Ingeniera
de Software II.

2. Representacin Arquitectnica1
Se consultaron las siguientes arquitecturas:

Arquitectura monoltica

Es la arquitectura de los primeros sistemas operativos constituidos


fundamentalmente por un solo programa compuesto de un conjunto de rutinas
entrelazadas de tal forma que cada una puede llamar a cualquier otra

Las caractersticas fundamentales de este tipo de arquitectura son:

Construccin del programa final a base de mdulos compilados


separadamente que se unen a travs del ligador.

Buena definicin de parmetros de enlace entre las distintas rutinas


existentes, que puede provocar mucho acoplamiento.

Carecen de protecciones y privilegios al entrar a rutinas que manejan


diferentes aspectos de los recursos de la computadora, como memoria,
disco, etc.

Generalmente estn hechos a medida, por lo que son eficientes y rpidos


en su ejecucin y gestin, pero por lo mismo carecen de flexibilidad para
soportar diferentes ambientes de trabajo o tipos de aplicaciones.

1 https://prezi.com/2uraxobilh0t/tipos-de-arquitecturas-de-software/

Confidential <Company Name>, 2017 Page 1 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

Ventajas:

Muy eficiente ya que se producen pocos cambios de contexto.

Inconvenientes:

Difcil de depurar, un error en una funcin se puede manifestar en otra


distinta.

Difcil de ampliar.

Arquitectura CLIENTE-SERVIDOR

Donde el software reparte su carga de cmputo en dos partes independientes, los


proveedores de los recursos o servicios (servidores) y los demandantes (clientes),
pero sin reparto claro de funciones.

Ventajas

Centralizacin del control


Escalabilidad
Fcil mantenimiento
Tecnologas maduras y robustas

Arquitectura 3 CAPAS
La programacin por capas es una arquitectura cliente-servidor en el que el
objetivo primordial es la separacin de la lgica de negocios de la lgica de diseo;
un ejemplo bsico de esto consiste en separar la capa de datos de la capa de
presentacin al usuario.

Ventajas

Simplifica la comprensin y la organizacin del desarrollo de sistemas


complejos
Reduce las dependencias de forma que las capas mas bajas no son
conscientes de ningn detalle de las superiores
Esta separacin aade una enorme flexibilidad al diseo de la aplicacin.

Confidential <Company Name>, 2017 Page 2 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

Capa de presentacin

Presenta el sistema al usuario.


Captura y comunica la informacin al usuario.
GUI (Interfaz Grfica del Usuario).
Entendible, amigable y usable.

Capa de negocio

En donde residen las funciones que se ejecutan.


Se reciben las peticiones del usuario.
Se procesa la informacin.
Se envan las respuestas tras el proceso.

Capa de datos

En donde residen los datos.


Encargada de gestionar los datos:
Definir y almacenar
Consultar
Manipular
Controlar
3. Objetivos arquitectnicos y limitaciones

Objetivo general:
Implementar un sistema de informacin web que permita a otros sistemas o
aplicaciones configurar y gestionar el nivel de acceso a sus formularios, pginas
u objetos que la componen y, a travs de mdulos asignar roles y permisos de
creacin, lectura, edicin y eliminado a los usuarios finales que accedern a la
aplicacin.

Objetivos especficos

1. Definir los mdulos que compondrn la aplicacin web y la interfaz para


que los usuarios puedan interactuar con el sistema.
2. Desarrollar la interfaz para agregar empresas, aplicaciones, formularios o
mdulos y/o controles
3. Implementar la interfaz para la creacin de roles con la asignacin de
permisos de acceso a los controles de una aplicacin.
4. Definir una interfaz para visualizar, crear, editar y/o eliminar los usuarios

Confidential <Company Name>, 2017 Page 3 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

finales de la aplicacin del cliente.


5. Implementar un servicio web que reciba las credenciales de acceso de un
usuario y retorne la informacin de permisos y acceso que tiene ese usuario
dentro de la aplicacin del cliente.

Funcin principal del sistema de informacin a construir es la servir como


validador del usuario final de las aplicaciones o sistemas web que sean agregados
al sistema y gestionar, almacenar, comunicar y retornan los permisos que de esa
aplicacin o sistema web tiene el usuario final que intenta acceder.

Lo primordial a tener en cuenta en la aplicacin es la privacidad y la seguridad de


la informacin que se enva sobre un usuario en los intentos de acceso a las
aplicaciones o sistemas clientes. Esto significa que lo primero que se debe
establecer dentro del sistema es un usuario para una empresa con el cual podr
registrar una entrada que represente su software, ya sea una aplicacin o un sitio
web y agregar los formularios, mdulos, controles y/u objetos que componen dicho
software. La siguiente informacin a registrar pueden ser los roles de acceso a
cada uno de esos componentes. Posteriormente agregar los usuarios que
accedern al software de la empresa y asignar el rol que le garantice el acceso a
lo establecido por el usuario administrador. Estos usuarios tendrn un nombre de
usuario y una contrasea para realizar una autenticacin y validacin en nuestro
sistema de Seguridad y as, retornar el nivel y permisos que tiene sobre los objetos
o controles en el software de la empresa. Se establecer un Servicio Web con
tecnologa REST para que cada software pueda determinar esa informacin
usando los datos de autenticacin de un usuario. En la respuesta organizada de
tipo JSON se incluirn los permisos que el usuario tiene sobre la aplicacin.

4. Vista de casos de uso

Los casos de uso en este sistema se enumeran a continuacin.

1. El usuario que crea los formularios, los mdulos y la seguridad de cada


uno.
2. Conexin de una aplicacin a los servicios web para obtener los permisos
de un usuario sobre los formularios.
3. Un usuario administrador que crea a la empresa para que pueda ingresar
sus formularios.

Registro de usuarios en la plataforma

Confidential <Company Name>, 2017 Page 4 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

Informacin de Catalogacin
Proyecto Sistema de seguridad
Autor Jessica Paola Galindo Mahecha
Versin 1.0 Estado de Desarrollo En borrador
Definicin del Caso de Uso
Cdigo CU_001
Nombre Registro de usuarios en la plataforma
Objetivo Agregar al sistema los usuarios que usaran la plataforma
Descripcin El administrador registrar a un usuario en la plataforma y le asignar el rol y
permisos correspondiente
Actores A: Administrador, S: Sistema
Condiciones - El usuario no debe estar registrado en el sistema
Necesarias - Se debe tener toda la informacin necesaria y correspondiente al usuario para el
registro
Escenario 1. A: Ingresar al sistema e ir la seccin de administracin de usuarios del sistema
Principal 2. S: Presentar una interface donde se soliciten los datos para el registro de un
usuario: Nombre completo, Tipo de documento de identidad, Documento de
identidad, correo electrnico, profesin, cargo, perfil, permisos, estado dentro del
sistema (activo, inactivo, etc.).
3. A: Diligenciar los campos completos con la informacin correspondiente al usuario
y guardar
4. S: Validar que no exista ese usuario en el sistema para continuar
5. S: Informar el registro como usuario en el sistema
Escenario
Alternativo
Condicin de Un nuevo usuario registrado en el sistema con su respectivo perfil

Confidential <Company Name>, 2017 Page 5 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

xito

Creacin de formularios, mdulos y seguridad

Informacin de Catalogacin
Proyecto Sistema de seguridad
Autor Jessica Paola Galindo Mahecha
Versin 1.0 Estado de Desarrollo En borrador
Definicin del Caso de Uso
Cdigo CU_002
Nombre Creacin de formularios, mdulos y seguridad
Objetivo Crear los formularios, mdulos y la seguridad que usara la plataforma en cada uno de
los usuarios y gestiones que se realizaran
Descripcin El administrador crea los formularios, los mdulos y administrara la seguridad de cada
uno de los usuarios que accedern a la plataforma
Actores A: Administrador, S: Sistema

Confidential <Company Name>, 2017 Page 6 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

Condiciones - El formulario, modulo y seguridad no deben estar creadas en la plataforma


Necesarias - Se debe tener con claridad para que se desea cada formulario y cada mdulo que
se creen dentro de la plataforma
Escenario 1. A: Ingresar al sistema e ir la seccin de creacin de formularios o mdulos
Principal 2. S: Presentar una interface donde se soliciten los datos para el registro de un
empleado: Nombre completo, Tipo de documento de identidad, Documento de
identidad, correo electrnico, profesin, cargo, perfil, permisos, rea, horario,
estado dentro del sistema (activo, inactivo, etc.).
3. A: Crear el formulario con los campos que se requieran dependiendo para que vaya
a usarse el formulario o modulo
4. A: Administrar la seguridad que usara cada uno de los usuarios, dependiente el rol
y el permiso que se asigne
5. S: Validar que no exista ningn formulario o modulo con los mismos campos
6. S: Validar que el usuario ya se encuentre creado para asignar la seguridad
respectiva
7. S: Informar el registro como formulario o modulo creado
8. S: Informar el registro de seguridad asignada
Escenario
Alternativo
Condicin de Un nuevo formulario, modulo o seguridad ha sido registrado y creado correctamente
xito

Aplicacin tiene conexin a un servidor web

Informacin de Catalogacin
Proyecto Sistema de seguridad

Confidential <Company Name>, 2017 Page 7 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

Autor Jessica Paola Galindo Mahecha


Versin 1.0 Estado de Desarrollo En borrador
Definicin del Caso de Uso
Cdigo CU_003
Nombre Aplicacin tiene conexin a un servidor web
Objetivo La plataforma o aplicacin se conectar a un web service, el cual permitir a un
usuario administrador dar permisos sobre cada uno de los formularios o mdulos
creados
Descripcin La plataforma se conectar automticamente a un web service en donde esta
administrar los permisos del usuario que se le brindar un rol de seguridad para
administrar todos los formularios y mdulos
Actores A: Aplicacin
Condiciones - Tener claridad de los permisos de seguridad que se brindaran frente a cada uno
Necesarias de los formularios y modulos
Escenario 1. A: Asignar permisos a un usuario para que administre la aplicacin frente a
Principal formularios y mdulos

Escenario
Alternativo
Condicin de Permisos asignados correctamente
xito

5. Vista Lgica
Desde el punto de vista lgico, el sistema de seguridad se compone de 5
paquetes principales:

Presentacin: contiene las clases para cada una de los formularios que
utilizarn los actores para comunicarse e interactuar con el sistema.

Aplicacin: contiene clases con la funcionalidad de procesamiento dentro del


sistema. Las clases de control existen para apoyar la insercin de formularios y
los permisos que pueden ser asignados a estos mismos y sus respectivos
controles dentro de una aplicacin, gestionar los usuarios de la aplicacin,
gestin de perfiles de acceso y proporcionar retroalimentacin sobre el uso de la
misma.

Dominio: Contiene paquetes para compatibilizar las aplicaciones, los


formularios, los controles y el acceso a estos.

Persistencia: Contiene clases para persistir objetos especficos dentro del


sistema. Con estas, se registran en la base de datos el listado de controles de
todos los formularios que una aplicacin puede tener y mostrar a sus usuarios.
Tambin se hace persistencia de los usuarios y el nivel de acceso de cada uno a

Confidential <Company Name>, 2017 Page 8 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

los controles de los formularios a travs de la creacin de perfiles.

Servicios: Contiene clases que proporcionan servicios a nivel del sistema de


clases para fines de consulta desde las aplicaciones que requieren conocer el
nivel de acceso y los permisos de un usuario especfico dentro de su aplicacin.

5.1 Visin general


Las principales clases del Sistema estarn diseadas para interactuar con los
principales objetos y registrar su persistencia en la base de datos.
Jerrquicamente el nivel ms alto de agrupamiento est dado a nivel de
aplicacin, el siguiente nivel es por formulario el cual agrupa varios controles
que a su vez tendrn establecidos permisos de acceso. Los usuarios sern
agregados para que puedan acceder a una aplicacin en el momento que
intenten ingresar a la misma mediante un usuario y una contrasea. Los
mtodos de las clases responsables de esta labor se exponen a continuacin:

Confidential <Company Name>, 2017 Page 9 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

6. Process View
Veremos cmo ser el proceso que debe realizar el usuario, en este proceso
vemos plasmado al igual que en los casos de uso los pasos que debe ejecutar el
usuario para ejecutar determinadas acciones.

Confidential <Company Name>, 2017 Page 10 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

7. Vista de Despliegue

8. Implementation View

Confidential <Company Name>, 2017 Page 11 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

8.1 Informacin General

8.2 Capas
Dentro de la capa 1 tenemos la distribucin que se presume tiene el espacio web
que usaremos para almacenar el servicio web, as como tambin la aplicacin que
se ejecutara dentro del mismo servidor de almacenamiento.
Dentro de la segunda capa veremos la aplicacin como tal que ser la interfaz
que vemos al momento de tener la intencin de brindar seguridad a una
aplicacin.
La capa tres ser en el punto del cliente que es donde se ver y finalmente se
har uso de las capacidades de la aplicacin
9. Tamao y rendimiento
Para la aplicacin de seguridad se recomienda el uso de una infraestructura
simple, ya que la cantidad de usuarios conectados y con sesin permanente
segn lo calculado no son altos.

Se calculo la concurrencia haciendo uso de una frmula de promedio la cual es:


Co: Cu/Ta
Donde
Co = Concurrencia
Cu= Cantidad de Usuarios
Ta = Tiempo de Acceso

Para esto se tom un promedio de 50 usuarios concurrentes, para dar un tiempo


estimado se calcul que el usuario este aproximadamente 30 minutos, la
conexin se evidenciara de la siguiente forma.

Confidential <Company Name>, 2017 Page 12 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

- Un servidor en promedio soporta 2000 usuarios de concurrencia, pero debido a que


tenemos un servidor apache este recibir un mximo de 200 usuarios
- Todas las conexiones tendrn un protocolo TCP/IP, el formato de repuesta ser de
HTTP y HTTPS esto ser lo que genera respuesta.

10. Calidad
- La interfaz de usuario ser compatible con todos los navegadores, esto establecido
como uno de los requerimientos, adicionalmente como un estndar de calidad.
- Cada mdulo desarrollado cumplir con las buenas prcticas establecidas por
Microsoft
- La aplicacin funcionara de forma dinmica segn lo establecido por requerimientos
adicionalmente esto permitir un mejor y ms amplio manejo por parte de los
usuarios.
11. Patrones

En el desarrollo de la aplicacin web se planea usar los siguientes patrones para


solucionar los problemas comunes en los casos que se especifica a continuacin:
Abstract Factory (crear los objetos y pasarlos a travs del servicio web)
Este patrn se puede aplicar cuando:

Un sistema debe ser independiente de como sus objetos son creados.


Un sistema debe ser 'configurado' con una cierta familia de productos.
Se necesita reforzar la nocin de dependencia mutua entre ciertos objetos.

Estructura del Patrn Abstract Factory

Confidential <Company Name>, 2017 Page 13 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

Singleton (Para conectarse a la base de datos usando una sola instancia)

El patrn Singleton se usa cuando:

Debe haber exactamente una nica instancia de una clase y los clientes deben poder
acceder desde un punto de acceso fiable.
La instancia debera ser extensible mediante subclases y los clientes deberan poder
usar una instancia sin modificar su cdigo.

Estructura

Confidential <Company Name>, 2017 Page 14 of 15


Sistema de Seguridad
Software Architecture Document Fecha: 02/Octubre/2017

La clase Singleton define la operacin instance() que permite a los clientes acceder a la
nica instancia de la clase. Los clientes slo pueden acceder a esa instancia a travs de
esa operacin2

Bridge (Para entregar la informacin a las aplicaciones que usen el sistema)


Estructura:

La estructura de un Bridge se puede clasificar en dos partes: la parte abstracta y la


implementacin de la interfaz por las diferentes clases del grupo de objetos, de modos
que la relacin se hace mediante una agregacin de la interfaz por parte de la clase
abstracta, de esta forma se relaciona la primera parte y la segunda, donde sus
comportamientos son independientes.3

2 . https://instintobinario.com/patrones-de-diseno-patron-singleton/
3 http://patronestructuralesyalgomas.blogspot.com.co/2009/05/patron-bridge.html

Confidential <Company Name>, 2017 Page 15 of 15

También podría gustarte