Ingeniería de Sistemas – Diseño de Aplicaciones web

DISEÑO DE
APLICACIONES WEB

Por: Ing. Edwin Calle Terrazas

 REQUISITOS FUNCIONALES
La captura de requisitos es el primer paso para cumplir con el
desarrollo de un Sistema de información, el cual conlleva al desarrollo
de un sistema de gestión.

Cada requerimiento tiene una descripción breve que refleja lo que el

sistema brinda a los usuarios.

En la siguiente tabla se identificarán los requisitos funcionales que se

estructuran más adelante mediante los casos de uso, tomando como
caso de estudio: Sistema de información web para gestionar Ordenes de
Servicio de reparación de computadoras
 REQUISITOS FUNCIONALES
Nº Requerimientos
R1 Registrar Clientes
R2 Registrar Empleado
R3 Registrar Orden de Servicio Registra la orden de servicio que los clientes solicitan.
R4 Registrar Equipo
Registrar Reparación de
R5
Servicios
R6 Registrar Accesorios
R7 Registrar Trabajo
R8 Registrar Compras
R9 Registrar Proveedores
R10 Registrar Usuarios
R11 Registrar Privilegios
Descripción
Registra los datos de los clientes que solicitan los servicios de
reparación de equipos
Registra los datos de los empleados que trabajan en la empresa.
Registra los datos equipos que se van a reparar
Registra la reparación del servicio, trabajos realizados, técnicos y
accesorios utilizados en la reparación.
Registra los accesorios que se utilizan en la reparación de los
equipos.
Registra los trabajos que se realizan en los servicios de reparación
Registra las compras realizadas para luego enviarlas a almacén,
registro de accesorios.
Registra los datos de los proveedores
Registra a los usuarios responsables del Sistema.
Registra los Privilegios de los usuarios.
 DIAGRAMA DE CASOS DE USO

Un caso de uso es una descripción de las acciones de un sistema

desde el punto de vista del usuario. Es una herramienta valiosa
dado que es una técnica de aciertos y errores para obtener los
requerimientos del sistema, justamente desde el punto de vista del
usuario.

Los diagramas de caso de uso modelan la funcionalidad del sistema

usando actores y casos de uso. Los casos de uso son servicios o
funciones provistas por el sistema para sus usuarios.
 DIAGRAMA DE CASOS DE USO

<<include>>
Gestionar Empleado Gestionar Usuarios

Gestionar Cliente

Recepcionista
<<include>>

Técnico
<<include>> <<include>>

Gesitionar Orden Servicio

<<include>>
Administrador
<<include>> Gestionar ReparaciónServicio

Gestionar Proveedor Gestionar Equipo

<<include>>
<<include>>

<<include>> Gestionar Accesorios Gestionar Privilegios

<<include>>

Gestionar Compra
Gestionar Trabajo

Almacenero
 DIAGRAMA DE PAQUETES
El objetivo de estos diagramas es obtener una visión más clara del
sistema de información orientado a objetos, organizándolo en
subsistemas, agrupando los elementos del análisis, diseño o
construcción y detallando las relaciones de dependencia entre ellos.
El mecanismo de agrupación se denomina Paquete.

Estos diagramas contienen dos tipos de elementos:

• Paquetes: Un paquete es una agrupación de elementos, bien sea
casos de uso, clases o componentes. Los paquetes pueden contener a
su vez otros paquetes anidados que en última instancia contendrán
alguno de los elementos anteriores.
• Dependencias entre paquetes: Existe una dependencia cuando un
elemento de un paquete requiere de otro que pertenece a un paquete
distinto. Es importante resaltar que las dependencias no son
transitivas.
 DIAGRAMA DE PAQUETES

SISTEMA SERVITEC

SubSistema Administracion SubSistema Servicios

SubSistema Compras
 DIAGRAMA DE PAQUETES

SUBSISTEMA ADMINISTRACION

Realizar Backup

Gestionar Bitacora Restaurar Backup

<<include>>

Administrador
Gestionar Privilegios
Gestionar Usuarios

<<include>>
<<include>>

Gestionar Asignar Privilegios

 DIAGRAMA DE PAQUETES

SUBSISTEMA SERVICIOS

Gestionar Cliente

Gestionar Equipo

<<include>> <<include>> Recepcionista Técnico

Gestionar Orden Servicio

<<include>> Gestionar Reparacion Servicio

<<include>>
<<include>> <<include>>

Gestionar Empleado
Gestionar Trabajo
 DIAGRAMA DE COLABORACIÓN
Un diagrama de comunicación, es una forma de representar interacciones entre
objetos, alterna al diagrama de secuencia.
En el diagrama de comunicación, los objetos se muestran con conectores de
asociación entre ellos. Los mensajes se agregan a las asociaciones y se muestran
con flechas cortas apuntando en la dirección del flujo de mensaje. La secuencia
de los mensajes se muestra a través de un esquema enumerado.
3 : GuardarCliente()
1 : Guardar() 2 : GuardarCliente() 7 : ObtenerDatosCliente()
4 : Buscar() 11 : ModificarCliente() 12 : ModificarCliente()
10 : Modificar() 14 : EliminarCliente() 15 : EliminarCliente()
13 : Eliminar()

clsCliente tblCliente
: Recepcionista frmCliente

5 : BuscarCli()
6 : BuscarCliente()

9 : ObtCodCliente()
8 : MostrarDatosCliente()

frmBuscarCliente
 DIAGRAMA DE COLABORACIÓN
1 : Guardar() 3 : GuardarEmpleado()
2 : GuardarEmpleado()
4 : Buscar() 7 : ObtenerDatosEmpleado()
10 : Modificar() 11 : ModificarEmpleado()
12 : ModificarEmpleado()
13 : Eliminar() 14 : EliminarEmpleado() 15 : EliminarEmpleado()

: Recepcionista clsEmpleado tblEmpleado

frmEmpleado

5 : BuscarEmp()

6 : BuscarEmpleado()

9 : ObtCodEmpleado()
8 : MostrarDatosEmpleado()

frmBuscarEmpleado

1 : Guardar() 2 : GuardarDatosEquipo() 3 : GuardarEquipo()

4 : Modificar() 5 : ModicarDatosEquipo() 6 : ModificarEquipo()
7 : Eliminar() 8 : EliminarDatosEquipo() 9 : EliminarEquipo()

: Recepcionista clsEquipo tblEquipo

frmEquipo
 DIAGRAMA DE COLABORACIÓN

3 : BuscarCliente() 4 : ObtenterDatosCliente()

5 : MostrarDatosCliente()
frmBuscarCliente clsCliente tblCliente

2 : BuscarCli() 8 : BuscarEmpleado() 9 : ObtenerDatosEmpleado()

10 : MostrarDatosEmpleado()
frmBuscarEmpleado clsEmpleado tblEmpleado

6 : ObtCodCliente() 7 : BuscarEmp()

11 : ObtCodEmpleado()

1 : Guardar() 17 : GuardarOrdenServicio() 18 : GuardarOrdenServicio()

: Recepcionista tblOrdenServicio
frmOrdenServicio clsOrdenServicio

12 : DatosEquipo()

13 : GuardarEquipo() 14 : GuardarEquipo()

clsEquipo tblEquipo
frmEquipo
15 : GuardarEquipoOrdenServ()

16 : GuardarEquipoOrdenServ()

clsEquipoOrdenServ tblEquipoOrdenServ
 DISEÑO DE BASE DE DATOS
El diseño de base de datos es un proceso fundamental a la hora de modelar
nuestros conjuntos de datos y definir las operaciones que queremos realizar
sobre ellos. Los datos son el activo mas importante de nuestra organización
y una base de datos bien diseñada influye de forma directa en la eficiencia
que obtendremos a la hora de almacenar, recuperar y analizar nuestros
datos.
Como cada proceso, el diseño de base de datos está compuestos por distintas
etapas secuenciales. Ellas son las siguientes:
RECOPILACIÓN Y ANÁLISIS DE REQUISITOS: Esta primera fase
consiste en un paso previo obligatorio, para asegurarnos de que nuestra base
de datos cumplirá con nuestros objetivos. Para ello, deberemos analizar
distintos factores, entre los cuales:
• Los datos que necesitamos almacenar y de dónde provienen.
• La información que los datos describen.
• Los usuarios de la base de datos y sus necesidades a la hora de acceder a
los datos.
 DISEÑO DE BASE DE DATOS
DISEÑO CONCEPTUAL: En esta fase se representan una descripción a alto
nivel del contenido de la base de datos, independientemente del sistema de
gestión de base de datos que se utilizará a continuación. Se definen en un
dibujo las clases, sus atributos y las relaciones entre ellas.
ELECCIÓN DE UN SISTEMA DE GESTIÓN DE BASE DE DATOS
(SGBD): Es en esta fase donde elegiremos el (SGBD) concreto que mejor se
adapta a nuestro proyecto, como ser: Oracle, MySQL, MS-SQLServer.
DISEÑO LÓGICO: En esta fase, se traduce el modelo conceptual obtenido
anteriormente a un esquema lógico, que describe la estructura de la base de
datos. Se trata de la fase en la cual se diseñan las tablas propiamente dichas,
con sus llaves, columnas y relaciones.
DISEÑO FÍSICO: En esta fase se definen las estructuras de almacenamiento
de la base de datos de forma física. Es cuando se escribe el código (por
ejemplo, SQL) para concretar el diseño en el motor de base de datos que
hemos escogido.
IMPLEMENTACIÓN: Finalmente, se crea y se compila el esquema de la
base de datos, se generan los ficheros y las aplicaciones que implementan las
transacciones.
 DIAGRAMA DE CLASES: DISEÑO DE BD
class Class Mo...

Trabaj o
Equipo
- id_trabajo
- nombre - id_equipo
- costo - serie
- descripcion
0..* - tipo_equipo

1..*
DetalleReparacion

- precio

1..* Empleado
1..*
- id_empleado
ReparacionServ icio OrdenServ icio - nombre
- paterno
- id_reparacion - id_servicio
- materno
- fechaEntrega - fecha 1..*
0..1 1 1 - telefono
- glosa - importe
- sueldo
- montoTotal - observacion
- tipo
0..* 1..* - fechaIngreso
- estado

1 1
ReparacionAccesorio
Cliente
- cantidad
- id_cliente
- nombre
1..* - paterno
- materno 1..*
Accesorio - telefono Prov eedor
Compra
- id_accesorio - id_proveedor
- nombre - id_compra - nombre
- nroSerie 1..* 1..* - fecha 1..* 1 - paterno
- precio - glosa - materno
- stock - telefono
DetalleCompra

- cantidad
- costo

Diseño conceptual, representado a través de Diagrama de clases de UML

 DIAGRAMA DE DESPLIEGUE
El diagrama de despliegue especifica el hardware físico sobre el que el Sistema de
software se ejecutará y también especifica como el software se despliega en ese
hardware. Dicho diagrama mapea la arquitectura de software creada en diseño con
una arquitectura física de Sistema que los ejecuta.
deployment Deployment Mo...

«device» «device»
PC-1 Recepcion PC-2 Tecnico

TCP-IP

TCP-IP TCP-IP
«device»
Impresora

TCP-IP

«device,PC Linux»
SERVIDOR WEB
«device»
PC-3 Gerente TCP-IP
general BD
«executionEnvironment»
MYSQL
APACHE
DIAGRAMA DE DESPLIEGUE: Otro ejemplo
 DIAGRAMA DE NAVEGACIÓN

• Muestran una estructura de los contenidos que van

aparecer en el Sitio Web.
• Permite conocer el orden que van llevar la página web
• Presentar los enlaces y poder comprobar la
accesibilidad que tienen estos

Dicho modelo permite representar la navegación a

páginas relacionadas a través de asociaciones o enlaces
hipertextuales. Dichas asociaciones se etiquetan, pueden
tener asociados atributos y pueden ser unidireccionales o
bidimensionales.
 ESTEREOTIPOS

La notación WAE (Web Application Extension), es una notación

propuesta que consiste en un conjunto de estereotipos que
extienden la notación UML original, a fin de apoyar la
representación gráfica de la estructura de navegación y de las
relaciones de construcción de páginas dinámicas de una
aplicación Web. Estos estereotipos principales son los siguientes:
NOMBRE ESTEREOTIPO DESCRIPCIÓN

Representa una página web que

Server Page tiene scripts que son ejecutados por
el Servidor.

Es una página web formateada en

Client Page HTML
 ESTEREOTIPOS

NOMBRE ESTEREOTIPO DESCRIPCIÓN

Es una colección de datos de

Form entrada que forma parte de una
Client Page.

Es la combinación del Server Page

Web Page y Client Page.

Es un contenedor de múltiples
Frame Set páginas web.

Son compartimientos de una

Target ventana en el browser, donde las
páginas web son desplegadas.
 ESTEREOTIPOS

Los scripts de las páginas de servidor (Server page) representan

los métodos de esta clase. Las páginas del cliente (Client page)
tienen métodos que se ejecutan solamente del lado del cliente,
como por ejemplo: java applets y controles activeX.

Un formulario (form) es una colección de campos de entrada:

textbox, textarea, checkbox, radiobutton y select list.
Cuando un formulario es llenado, se envía al servidor usando una
operación submit solicitada por el usuario típicamente al hacer
click en un botón.
 RELACIONES

Representa un apuntador desde una “Client Page” a

<<Link>> “Client Page” o “Server Page”. Corresponde
directamente con una etiqueta <a> (ancla de HTML)
Esta relación siempre se da entre una “Form” y una
<<Submit>> “Server Page”, por su puesto la Server Page procesa los
datos que la “Form” le envía (submit)
Sirve para identificar cuales “Server Page” son
<<Build>> responsables de la creación de una “Client Page”. Un
“Server Page” puede crear varias “Client Page”, pero
una “Client Page” solo puede ser creada por una sola
“Server Page”. Esta relación siempre es unidireccional
Esta es también una relaciona unidireccional, que indica
<<Redirect>> que una página web redirige hacia otra. En caso que la
página origen sea “Client Page” esta asociación
corresponderá con la “META” etiqueta y valor Http
equivalente de “Refresh”
RELACIONES
RELACIONES
RELACIONES
 RELACIONES

Si un vínculo (hiper link) incluye parámetros, éstos son

modelados como atributos del link (fuera) fuera de la
asociación. Por ejemplo:
 RELACIONES

Dado que una página podría tener varios formularios (forms), es

posible que desde esta página se acceda a diferentes páginas.
Los formularios se modelan con el estereotipo <<form>>. Las
páginas clientes contiene formularios.
EJEMPLO: DIAGRAMA DE NAVEGACIÓN
EJEMPLO: DIAGRAMA DE NAVEGACIÓN