SQL Server

PROCEDIMIENTOS ALMACENADOS

 

Los procedimientos almacenados (PA) son módulos o rutinas que encapsulan código para su reutilización.

Los PA son similares a los procedimientos de otros lenguajes de programación.

– Aceptan parámetros de entrada.

– Devuelven varios valores.

– Contienen instrucciones de programación que realizan operaciones en la base de datos, incluidas las llamadas a otros procedimientos.

– Devuelven un valor de estado a un lote o a un procedimiento que realiza una llamada para indicar si la operación se ha realizado correctamente o se han producido errores.

– Devuelve los motivos de los errores.

Ventajas de usar procedimientos almacenados.

– Se registran en el servidor.

– Pueden incluir atributos de seguridad, se pueden asociar certificados.

– Mejoran la seguridad de la aplicación. Inyección de código SQL.

– Permite una programación Modular.

– Mejora el mantenimiento y acceso a la base de datos de manera uniforme.

– Reduce el tráfico de red.

Tipos de procedimientos almacenados

– Procedimientos almacenados definidos por el usuario.

o Transact-SQL. Un procedimiento almacenado Transact-SQL es una colección guardada de instrucciones Transact-SQL que puede tomar y devolver los parámetros proporcionados por el usuario.

o CLR. Un procedimiento almacenado CLR es una referencia a un método Common Language Runtime (CLR) de Microsoft .NET Framework que puede aceptar y devolver parámetros suministrados por el usuario.

– Procedimientos almacenados extendidos.

o Se eliminarán en futuras versiones.

o Los procedimientos almacenados extendidos le permiten crear sus propias rutinas externas en un lenguaje de programación como pueda ser C.

o Se programan con la API Procedimiento almacenado extendido de SQL Server.

– Procedimientos almacenados del sistema.

o Muchas de las actividades administrativas en SQL Server se realizan mediante un tipo especial de procedimiento conocido como procedimiento almacenado del sistema.

o Los procedimientos almacenados del sistema aparecen de forma lógica en el esquema sys de cada base de datos definida por el usuario y el sistema.

Reglas para diseñar procedimientos almacenados.

o La propia definición de CREATE PROCEDURE puede incluir cualquier número y tipo de instrucciones SQL.

o Puede crear otros objetos de base de datos dentro de un procedimiento almacenado.

o Puede hacer referencia a tablas temporales.

o Si crea una tabla temporal local dentro de un procedimiento almacenado, ésta existirá únicamente para los fines del procedimiento y desaparecerá cuando éste finalice.

o Si ejecuta un procedimiento almacenado que llama a otro procedimiento almacenado, este último puede tener acceso a todos los objetos creados por el primero, incluidas las tablas temporales.

o El número máximo de parámetros en un procedimiento almacenado es de 2100.

o El número máximo de variables locales en un procedimiento almacenado está limitado únicamente por la memoria disponible.

o En función de la memoria disponible, el tamaño máximo de un procedimiento almacenado es de 128 megabytes (MB).

Crear procedimientos almacenados.

Operadores Básicos

– Create Procedure. Crear un procedimiento almacenado

– Alter Procedure. Modifica un procedimiento almacenado

– Output. Define un parámetro como “de salida”

– Set. Permite asignar un valor a un parámetro o variable.

– Declare. Permite declarar variables que serán utilizadas en el cuerpo del procedimiento almacenado

– Begin Tran. Inicia una transacción, esta instrucción puede llevar un nombre

– Commit tran. Finaliza y confirma una transacción

– If Else. Permite realizar decisiones en el cuerpo del procedimiento almacenado

– Begin. Inicia un conjunto de sentencias sql

– End. Finaliza el conjunto de sentencias sql.

– If @@Error <> 0. si no es igual a 0 significa que se ha producido un error, al momento de de insertar, actualizar o eliminar.

– Rollback Transaction. Elimina las operaciones que se han realizado en una transacción. Esta instrucción tiene que estar antes del comm tran.

– @@Identity. Devuelve el último valor insertado de un campo autoincrementable.

Ejemplos.

Crear un procedimiento almacenado para insertar un Empleado.

CREATE PROCEDURE dbo.Actividades_I_Empleado

@ApellidoPaterno Varchar(35),

@ApellidoMaterno Varchar(35),

@Nombre1 Varchar(35),

@Nombre2 Varchar(35)

AS

Insert into Empleado (ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

values (@ApellidoPaterno, @ApellidoMaterno, @Nombre1, @Nombre2)

ALTER PROCEDURE [dbo].[Actividades_I_Empleado]

@ApellidoPaterno Varchar(35),

@ApellidoMaterno Varchar(35),

@Nombre1 Varchar(35),

@Nombre2 Varchar(35)

AS

Begin

Insert into Empleado (ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

values (@ApellidoPaterno, @ApellidoMaterno, @Nombre1, @Nombre2)

Select @@IDENTITY

End

La sentencia ALTER PROCUDURE, permite modificar el procedimiento almacenado.

Crear un procedimiento almacenado para insertar una actividad.

CREATE PROCEDURE I_ActividadDiaria

@CodigoTopico int,

@FechaInicio datetime,

@FechaFinalizacion datetime,

@Estado char(1),

@Id_Empleado int

AS

begin

insert into ActividadDiaria(CodigoTopico, FechaInicio, FechaFinalizacion, Estado, Id_Empleado)

Values (@CodigoTopico, @FechaInicio, @FechaFinalizacion, @Estado, @Id_Empleado)

end

Crear un procedimiento almacenado que seleccione a todos los empleados de un grupo.

CREATE PROCEDURE S_EmpleadosDeUnGrupo

@NombreGrupo varchar(50)

AS

begin

Select a.ApellidoPaterno, a.ApellidoMaterno, a.Nombre1, a.Nombre2

From Empleado a inner join GrupoEmpleado b on a.Id_Empleado=b.Id_empleado

inner join Grupo c on b.CodigoGrupo=c.CodigoGrupo

Where c.NombreGrupo=@NombreGrupo

end

Crear un procedimiento almacenado que permita insertar una cuenta de empleado.

CREATE PROCEDURE I_CuentaEmpleado

@CuentaEmpleado varchar(20),

@Id_Empleado int

AS

begin

Insert into CuentaEmpleado (CuentaEmpleado, Id_empleado)

Values (@CuentaEmpleado, @Id_Empleado)

end

Crear un procedimiento para insertar a un empleado y asignar un grupo.

CREATE PROCEDURE I_EmpleadoAsignarGrupo

@ApellidoPaterno varchar(35),

@ApellidoMaterno varchar(35),

@Nombre1 varchar(35),

@Nombre2 varchar(35),

@NombreGrupo varchar(50)

AS

begin tran

DECLARE @Id_Empleado int

DECLARE @CodigoGrupo int

INSERT INTO Empleado(ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

VALUES(@ApellidoPaterno, @ApellidoMaterno, @Nombre1, @Nombre2)

SET @Id_Empleado = @@IDENTITY

SELECT @CodigoGrupo=CodigoGrupo FROM Grupo WHERE NombreGrupo=@NombreGrupo

if @CodigoGrupo>0

begin

INSERT INTO GrupoEmpleado(CodigoGrupo, Id_Empleado)

VALUES(@CodigoGrupo, @Id_Empleado)

print N’Se Inserto’

end

else

print N’ocurrio un error’

if @@error<>0

ROLLBACK TRANSACTION

Commit

Crear un procedimiento almacenado que replique a una tabla auxiliar los datos siguientes. CodigoActividad, NombreCompletoEmpleado, NombreTopico, Estado.

create procedure G_BolcarDatos

as

begin tran

CREATE TABLE Auxiliar

(

CodigoActividad int,

NombreEmpleado varchar(105),

NombreTopico varchar(35),

Estado char(1)

)

Insert into Auxiliar SELECT ActividadDiaria.CodigoActividad,

Empleado.ApellidoPaterno+’ ‘+Empleado.ApellidoMaterno+’ ‘+Empleado.Nombre1+’ ‘+Empleado.Nombre2,

Topico.NombreTopico as Nombre,

ActividadDiaria.Estado

FROM ActividadDiaria INNER JOIN

Empleado ON ActividadDiaria.Id_Empleado = Empleado.Id_Empleado INNER JOIN

Topico ON ActividadDiaria.CodigoTopico = Topico.CodigoTopico

if @@error<>0

ROLLBACK TRANSACTION

commit

Crear un procedimiento almacenado que valide a un empleado.

Create Procedure G_ValidarEmpleado

@CuentaEmpleado varchar(20),

@Id_Empleado int,

@Valido Char(1) OUTPUT

as

BEGIN

declare @CuentaEmp varchar(20)

declare @Id_Emp int

Select @CuentaEmp = CuentaEmpleado, @Id_Emp = Id_Empleado

From CuentaEmpleado

Where CuentaEmpleado=@CuentaEmpleado and Id_Empleado=@Id_Empleado

if @CuentaEmp=@CuentaEmpleado

SET @Valido=’S’

else

SET @Valido=’N’

END

SQL Server

Parte 1: Consultas a la Base de Datos Actividades

Script de la creación de la Base de datos

CREATE TABLE [Topico](

[CodigoTopico] [int] IDENTITY(1,1) NOT NULL,

[NombreTopico] [varchar](50) NULL,

[Descripcion] [varchar](150) NULL,

CONSTRAINT [PK_Topico] PRIMARY KEY CLUSTERED

(

[CodigoTopico] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

CREATE TABLE [GruposTopico](

[CodigoGrupo] [int] NULL,

[CodigoTopico] [int] NULL

) ON [PRIMARY]

GO

CREATE TABLE [GrupoEmpleado](

[CodigoGrupo] [int] NULL,

[Id_Empleado] [int] NULL

) ON [PRIMARY]

GO

CREATE TABLE [Grupo](

[CodigoGrupo] [int] IDENTITY(1,1) NOT NULL,

[NombreGrupo] [varchar](50) NULL,

[Descripcion] [varchar](150) NULL,

CONSTRAINT [PK_Grupo] PRIMARY KEY CLUSTERED

(

[CodigoGrupo] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

CREATE TABLE [Empleado](

[Id_Empleado] [int] IDENTITY(1,1) NOT NULL,

[ApellidoPaterno] [varchar](35) NULL,

[ApellidoMaterno] [varchar](35) NULL,

[Nombre1] [varchar](35) NULL,

[Nombre2] [varchar](35) NULL,

CONSTRAINT [PK_Empleado] PRIMARY KEY CLUSTERED

(

[Id_Empleado] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

CREATE TABLE [DetalleActividadDiaria](

[CodigoActividad] [int] NULL,

[Detalle] [varchar](300) NULL

) ON [PRIMARY]

GO

CREATE TABLE [CuentaEmpleado](

[CuentaEmpleado] [varchar](20) NULL,

[Id_Empleado] [int] NULL

) ON [PRIMARY]

GO

CREATE TABLE [ActividadDiaria](

[CodigoActividad] [int] IDENTITY(1,1) NOT NULL,

[CodigoTopico] [int] NULL,

[FechaInicio] [datetime] NULL,

[FechaFinalizacion] [datetime] NULL,

[Estado] [char](1) NULL,

[Id_Empleado] [int] NULL,

CONSTRAINT [PK_ActividadDiaria] PRIMARY KEY CLUSTERED

(

[CodigoActividad] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

SCRIPT DE INSERCION DE DATOS.

EMPLEADOS

insert into Empleado (ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

values (‘Arancibia’,’Miranda’,’Juan’,’Jose’)

insert into Empleado (ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

values (‘Toro’,’Carmona’,’Pedro’,’Eduardo’)

insert into Empleado (ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

values (‘Torrejón’,’Camargo’,’Isa’,’Rosa’)

insert into Empleado (ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

values (‘Sotomayor’,’Quiroga’,’Yulesqui’,»)

insert into Empleado (ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

values (‘Zurita’,’Miranda’,’Gonsalo’,’Pedro’)

insert into Empleado (ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

values (‘Barea’,’Vedia’,’Jose’,’Carlos’)

insert into Empleado (ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

values (‘Bejarano’,’Saavedra’,’Alejandro’,’Yolei’)

insert into Empleado (ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

values (‘Ceballos’,’Duran’,’Alejandra’,’Trina’)

insert into Empleado (ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

values (‘Enriquez’,’Barrero’,’Marcel’,’Juan’)

insert into Empleado (ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

values (‘Flores’,’Zambrana’,’Carmelo’,»)

TOPICOS

INSERT INTO Topico (NombreTopico, Descripcion)

VALUES(‘Reparación de PC’,’Reparación de los compomentes internos de una computadora’)

INSERT INTO Topico (NombreTopico, Descripcion)

VALUES(‘Reparacion de Impresara’,’Reparación de los componentes internos de una impresora’)

INSERT INTO Topico (NombreTopico, Descripcion)

VALUES(‘Limpieza de Impresora’,’Trabajo de limpiesa y lubricacion de los componentes de una impresora’)

INSERT INTO Topico (NombreTopico, Descripcion)

VALUES(‘Intalación Red de Datos’,’Extendido y configuración de una red de datos categoria 5e’)

INSERT INTO Topico (NombreTopico, Descripcion)

VALUES(‘Desarrollo de Aplicaciones Web’,’Desarrollo de aplicaciones Web en ASP.NET con C#’)

ACTIVIDADES

INSERT INTO ActividadDiaria(CodigoTopico, FechaInicio, FechaFinalizacion, Estado, Id_Empleado)

VALUES (1, Convert(datetime, ’13/10/2009 17:01:32.100′, 103),

Convert(datetime, ’13/10/2009 17:01:32.100′, 103), ‘I’, 1)

INSERT INTO ActividadDiaria(CodigoTopico, FechaInicio, FechaFinalizacion, Estado, Id_Empleado)

VALUES (2, Convert(datetime, ’14/10/2009 17:01:32.100′, 103),

Convert(datetime, ’15/10/2009 17:01:32.100′, 103), ‘F’, 2)

INSERT INTO ActividadDiaria(CodigoTopico, FechaInicio, FechaFinalizacion, Estado, Id_Empleado)

VALUES (3, Convert(datetime, ’13/10/2009 17:01:32.100′, 103),

Convert(datetime, ’13/10/2009 17:01:32.100′, 103), ‘I’, 1)

INSERT INTO ActividadDiaria(CodigoTopico, FechaInicio, FechaFinalizacion, Estado, Id_Empleado)

VALUES (4, Convert(datetime, ’13/10/2009 17:01:32.100′, 103),

Convert(datetime, ’16/10/2009 17:01:32.100′, 103), ‘F’, 2)

INSERT INTO ActividadDiaria(CodigoTopico, FechaInicio, FechaFinalizacion, Estado, Id_Empleado)

VALUES (5, Convert(datetime, ’15/10/2009 17:01:32.100′, 103),

Convert(datetime, ’15/10/2009 17:01:32.100′, 103), ‘I’, 3)

INSERT INTO ActividadDiaria(CodigoTopico, FechaInicio, FechaFinalizacion, Estado, Id_Empleado)

VALUES (1, Convert(datetime, ’16/10/2009 17:01:32.100′, 103),

Convert(datetime, ’13/10/2009 17:01:32.100′, 103), ‘I’, 4)

INSERT INTO ActividadDiaria(CodigoTopico, FechaInicio, FechaFinalizacion, Estado, Id_Empleado)

VALUES (2, Convert(datetime, ’13/10/2009 17:01:32.100′, 103),

Convert(datetime, ’17/10/2009 17:01:32.100′, 103), ‘F’, 5)

INSERT INTO ActividadDiaria(CodigoTopico, FechaInicio, FechaFinalizacion, Estado, Id_Empleado)

VALUES (3, Convert(datetime, ’15/10/2009 17:01:32.100′, 103),

Convert(datetime, ’15/10/2009 17:01:32.100′, 103), ‘I’, 6)

INSERT INTO ActividadDiaria(CodigoTopico, FechaInicio, FechaFinalizacion, Estado, Id_Empleado)

VALUES (3, Convert(datetime, ’13/10/2009 17:01:32.100′, 103),

Convert(datetime, ’19/10/2009 17:01:32.100′, 103), ‘F’, 1)

INSERT INTO ActividadDiaria(CodigoTopico, FechaInicio, FechaFinalizacion, Estado, Id_Empleado)

VALUES (5, Convert(datetime, ’15/10/2009 17:01:32.100′, 103),

Convert(datetime, ’15/10/2009 17:01:32.100′, 103), ‘I’, 7)

DETALLE DE ACTIDIDAD DIARIA

Insert into DetalleActividadDiaria (CodigoActividad, Detalle)

Values (2, ‘Se ha cambiado el cabezal a que el anteriore estaa muy gastado’)

Insert into DetalleActividadDiaria (CodigoActividad, Detalle)

Values (4, ‘Se ha instalado un número de 120 puntos de red los cuales cumplen la categoria 6e’)

Insert into DetalleActividadDiaria (CodigoActividad, Detalle)

Values (7, ‘Se ha realizado una limpeza completa ya que uno de los compoentes de rodamiento estaba muy mal lubricado’)

Insert into DetalleActividadDiaria (CodigoActividad, Detalle)

Values (9, ‘Se una limpeza superficial no se realizó limpeza de los componentes internos’)

GRUPOS

Insert into Grupo (NombreGrupo, Descripcion)

Values (‘Grupo 1’, ‘Atención al Cliente’)

Insert into Grupo (NombreGrupo, Descripcion)

Values (‘Grupo 2’, ‘Experto’)

Insert into Grupo (NombreGrupo, Descripcion)

Values (‘Grupo 3’, ‘Técnico especialista’)

Insert into Grupo (NombreGrupo, Descripcion)

Values (‘Grupo 4’, ‘Limpieza’)

GRUPO EMPLEADO

Insert into GrupoEmpleado (CodigoGrupo, Id_Empleado)

Values (1, 1)

Insert into GrupoEmpleado (CodigoGrupo, Id_Empleado)

Values (1, 2)

Insert into GrupoEmpleado (CodigoGrupo, Id_Empleado)

Values (1, 3)

Insert into GrupoEmpleado (CodigoGrupo, Id_Empleado)

Values (2, 4)

Insert into GrupoEmpleado (CodigoGrupo, Id_Empleado)

Values (2, 5)

Insert into GrupoEmpleado (CodigoGrupo, Id_Empleado)

Values (3, 6)

Insert into GrupoEmpleado (CodigoGrupo, Id_Empleado)

Values (3, 7)

Insert into GrupoEmpleado (CodigoGrupo, Id_Empleado)

Values (4, 8)

Insert into GrupoEmpleado (CodigoGrupo, Id_Empleado)

Values (2, 9)

Insert into GrupoEmpleado (CodigoGrupo, Id_Empleado)

Values (4, 10)

CONSULTAS A LA BASE DE DATOS

Todos los empleados que tienen una o más actividades terminadas.

Select a.ApellidoPaterno, a.ApellidoMaterno, a.Nombre1, a.Nombre2, b.Estado as ‘Estado_Actividad’, b.CodigoActividad

from Empleado a inner join ActividadDiaria b on a.Id_Empleado =b.Id_Empleado

Where Estado=’F’

Todos los empleados que tienen una actividad

Select a.ApellidoPaterno, a.ApellidoMaterno, a.Nombre1, a.Nombre2, b.Estado as ‘Estado_Actividad’, b.CodigoActividad

from Empleado a inner join ActividadDiaria b on a.Id_Empleado =b.Id_Empleado

Los que no tienen actividades

Select a.ApellidoPaterno, a.ApellidoMaterno, a.Nombre1, a.Nombre2, b.Estado as ‘Estado_Actividad’, b.CodigoActividad

from Empleado a left join ActividadDiaria b on a.Id_Empleado =b.Id_Empleado

where Estado is null

Esta consulta se ejecuta correctamente en el SQL Server 2008

Los que tienen más de una actividad ordenados por el Numero de actividades

Select COUNT(a.Id_Empleado) as Numero_Actividades, a.ApellidoPaterno, a.ApellidoMaterno, a.Nombre1, a.Nombre2

from Empleado a inner join ActividadDiaria b on a.Id_Empleado =b.Id_Empleado

group by a.ApellidoPaterno, a.ApellidoMaterno, a.Nombre1, a.Nombre2

having COUNT(a.Id_Empleado)>1

Order by Numero_Actividades desc

Todos los empleados que tienen actividades finalizadas menores a una fecha, además mostrar el nombre del tópico de la actividad

Select a.Id_Empleado, b.Estado as ‘Estado_Actividad’, b.CodigoActividad, c.NombreTopico, b.FechaInicio, b.FechaFinalizacion

from Empleado a inner join ActividadDiaria b on a.Id_Empleado =b.Id_Empleado

inner join Topico c on b.CodigoTopico=c.CodigoTopico

where Estado=’F’ and b.FechaFinalizacion<Convert(datetime, ’17/10/2009 23:59:59.100′,103)

Todos los empleados que tienen actividades finalizadas en un rango de fecha, además mostrar el nombre del tópico de la actividad.

Select a.Id_Empleado, b.Estado as ‘Estado_Actividad’, b.CodigoActividad, c.NombreTopico, b.FechaInicio, b.FechaFinalizacion

from Empleado a inner join ActividadDiaria b on a.Id_Empleado =b.Id_Empleado

inner join Topico c on b.CodigoTopico=c.CodigoTopico

where Estado=’F’ and b.FechaFinalizacion>=Convert(datetime, ’13/10/2009 00:00:00.100′,103)

and b.FechaFinalizacion<=Convert(datetime, ’15/10/2009 23:59:59.100′,103)

Buscar a un Empleado por el Id_Empleado

Select Id_Empleado, ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2

From Empleado

Where Id_Empleado=1

Buscar a un Tópico por el NombreTópico utilizando LIKE

Select CodigoTopico, NombreTopico, Descripcion

From Topico

Where NombreTopico LIKE ‘%reparaci%’

Mostrar el detalle de las actividades finalizadas

Select a.CodigoActividad, b.Detalle, a.Estado

From ActividadDiaria a inner join DetalleActividadDiaria b on a.CodigoActividad=b.CodigoActividad

Where a.Estado=’F’

Mostrar el detalle de las actividades finalizadas y el nombre del Empleado

Select a.CodigoActividad, b.Detalle, a.Estado, c.Nombre1+’ ‘+c.Nombre2+’ ‘+c.ApellidoPaterno+’ ‘+c.ApellidoMaterno as Nombre_Completo

From ActividadDiaria a inner join DetalleActividadDiaria b on a.CodigoActividad=b.CodigoActividad

inner join Empleado c on a.Id_Empleado=c.Id_Empleado

Where a.Estado=’F’

Todos los empleados de un grupo

Select a.ApellidoPaterno, a.ApellidoMaterno, a.Nombre1, a.Nombre2, b.CodigoGrupo

From Empleado a inner join GrupoEmpleado b on a.Id_Empleado=b.Id_Empleado

Select a.ApellidoPaterno, a.ApellidoMaterno, a.Nombre1, a.Nombre2, b.CodigoGrupo, c.NombreGrupo

From Empleado a inner join GrupoEmpleado b on a.Id_Empleado=b.Id_Empleado

inner join Grupo c on b.CodigoGrupo=c.CodigoGrupo

Select a.ApellidoPaterno, a.ApellidoMaterno, a.Nombre1, a.Nombre2, b.CodigoGrupo, c.NombreGrupo

From Empleado a inner join GrupoEmpleado b on a.Id_Empleado=b.Id_Empleado

inner join Grupo c on b.CodigoGrupo=c.CodigoGrupo

Where c.NombreGrupo=’Grupo 3′

Grupo al que pertenece el empleado

Select a.CodigoGrupo, a.NombreGrupo, a.Descripcion, c.ApellidoPaterno, c.Nombre1

From Grupo a inner join GrupoEmpleado b on a.CodigoGrupo=b.CodigoGrupo

inner join Empleado c on b.Id_Empleado=c.Id_Empleado

Where c.ApellidoPaterno LIKE ‘%Be%’ and c.Nombre1 LIKE ‘%Al%’

Todas las actividades más el detalle de un empleado

Select a.CodigoActividad, d.NombreTopico, a.Estado, a.FechaInicio, a.FechaFinalizacion, b.Detalle

From ActividadDiaria a inner join DetalleActividadDiaria b on a.CodigoActividad=b.CodigoActividad

inner join Empleado c on a.Id_Empleado=c.Id_Empleado

inner join Topico d on a.CodigoTopico=d.CodigoTopico

Select a.CodigoActividad, d.NombreTopico, a.Estado, a.FechaInicio, a.FechaFinalizacion, b.Detalle, c.Id_Empleado

From ActividadDiaria a inner join DetalleActividadDiaria b on a.CodigoActividad=b.CodigoActividad

inner join Empleado c on a.Id_Empleado=c.Id_Empleado

inner join Topico d on a.CodigoTopico=d.CodigoTopico

Where c.Id_Empleado=1

Todas las actividades de un empleado

Actividades de un grupo en una fecha

Todas las actividades de un empleado

SQL Server

Crear una Base de Datos.

Para crear una base se utiliza la siguiente sintaxis:

CREATE DATABASE BDI_Actividades

El Nombre de la base de datos puede contener 128 caracteres. Si no se especifica un nombre de archivos de datos, el nombre de la base de datos seran los nombres estos archivos (Archivos de datos y de registro).

Crear una Tabla.

Para crear una tabla se utiliza la siguiente sintaxis.

CREATE TABLE ActividadDiaria

(

CodigoActividad int identity(1,1) not null,

CodigoTopico int null,

FechaInicio datetime null,

FechaFinalizacion datetime null,

Estado char(1) null,

Id_Empleado int null

)

El nombre de la tabla puede contener 128 caracteres si no es una tabla temporal.

Identity. Crea una columna de identidad en una tabla. Esta propiedad se usa con las instrucciones CREATE TABLE y ALTER TABLE de Transact-SQL. IDENTITY(seek, increment)

CREATE TABLE Empleado(

Id_Empleado int IDENTITY(1,1) NOT NULL ,

ApellidoPaterno varchar(35) NULL,

ApellidoMaterno varchar(35),

Nombre1 Varchar(35),

Nombre2 varchar(35),

CONSTRAINT PK_Empleado PRIMARY KEY CLUSTERED

(

Id_Empleado ASC

) ON [PRIMARY]

)

Insertar datos a una tabla.

Para agregar una fila (registro) a una tabla se debe seguir la siguiente sintaxis:

INSERT INTO Empleado(ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2)

VALUES

(‘Poppe’, ‘Maldonado’, ‘Carlos’, ‘Eduardo’)

INSERT INTO ActividadDiaria(CodigoTopico, FechaInicio, FechaFinalizacion, Estado, Id_Empleado)

VALUES (1, Convert(datetime, ’12/10/2009 17:01:32.100′, 101), GETDATE(), ‘F’, 1)

Mostrar los datos de una tabla.

Para obtener un conjunto de registros de una determinada tabla se debe seguir la siguiente sintaxis:

SELECT Id_Empleado, ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2

FROM Empleado

Consultas con la sentencia WHERE

SELECT ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2

FROM Empleado

WHERE ApellidoPaterno=’Arancibia’ and Nombre1=’Sergio’

SELECT ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2

FROM Empleado

WHERE ApellidoPaterno not in (‘Arancibia’)

SELECT ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2

FROM Empleado

WHERE ApellidoPaterno <>’Arancibia’

Consultas con la instrucción TOP

SELECT top(1) ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2

FROM Empleado

WHERE ApellidoPaterno <>’Arancibia’

Consultas con la sentencia LIKE

SELECT ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2

FROM Empleado

WHERE ApellidoPaterno like ‘%a%’

Busca a todos los empleados que en su apellido paterno existe una letra “a”.

SELECT ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2

FROM Empleado

WHERE ApellidoPaterno like ‘_rancibia’

Busca a todos los empleados que su apellido paterno termine en “rancibia”.

Consultas con la sentencia DISTINCT

SELECT DISTINCT ApellidoPaterno

FROM Empleado

Consultas con la sentencia ORDER BY

SELECT ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2

FROM Empleado

ORDER BY ApellidoPaterno

SELECT ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2

FROM Empleado

ORDER BY ApellidoPaterno asc

SELECT ApellidoPaterno, ApellidoMaterno, Nombre1, Nombre2

FROM Empleado

ORDER BY ApellidoPaterno desc

Modificar datos de un registro.

UPDATE Empleado

SET ApellidoMaterno=’Otro Apellido’

WHERE Id_Empleado=2

UPDATE Empleado

SET ApellidoMaterno=’Otro Apellido’, Nombre2=’Segundo Nombre’

WHERE Id_Empleado=2

Eliminar un registro de una tabla.

DELETE Empleado

WHERE ApellidoPaterno=’Arancibia’

Base de Datos Ejemplo

DetalleActividadDiaria CodigoActividad à int Detalle –-> varchar(300)	CuentaEmpleado CuentaEmpleado –-> varchar(20) Id_Empleado –-> int	ActividadDiaria CodigoActividad –-> int CodigoTopico –-> int FechaInicio –-> datetime FechaFinalizacion –-> datetime Estato –-> char(1) Id_Empleado –-> int
Empleado Id_Empleado –-> int ApellidoPaterno –-> varchar(35) ApellidoMaterno –-> varchar(35) Nombre1 –-> varchar(35) Nombre2 –-> varchar(35)	Topico CodigoTopico –-> int NombreTopico –-> varchar(50) Descripcion –-> varchar(150)	GrupoEmpleado CodigoGrupo –-> int Id_Empleado –-> int
GruposTopico CodigoTopico –-> int CodigoGrupo –-> int	Grupo CodigoGrupo –-> int NombreGrupo –-> varchar(50) Descripcion –-> varchar(150)

Introducción al SQL Server

Objetivo.

Obtener una vista general del gestor de base de datos Microsoft SQL Server.

Introducción.

SQL server está diseñado para trabajar con grandes cantidades de información y la capacidad de cumplir con los requisitos de los procesos de información para aplicaciones comerciales y sitios Web.

SQL Server es un sistema administrador para Bases de Datos relacionales basadas en la arquitectura Cliente / Servidor (RDBMS) que usa Transact-SQL para mandar peticiones entre un cliente y el SQL Server.

Arquitectura cliente / servidor.

Se basa en un conjunto de nodos que realizan la función clientes y de otros que realizan la función de servidores. La lógica del negocio está distribuida entre clientes y el servidor. Los clientes llaman a los servicios. Es un modelo de sistemas distribuido que muestra como los datos y el procesamiento se distribuyen a lo largo de varios procesadores. Está compuesto por:

– Conjunto de Servidores independientes. Ofrecen servicios a otros subsistemas. Servidor de la BD, servidor de las reglas del negocio

– Conjunto de clientes. Llaman a los servicios de los servidores. Por lo general son subsistemas. Existen varias ocurrencias de un programa cliente. Concurrencia.

– Red de Datos. Permite a los clientes acceder a estos servicios.

La arquitectura cliente/servidor se clasifica en:

– Cliente Delgado. Todas las consultas y la lógica del negocio están en el servidor de datos.

– Cliente Grueso. Todas las consultas y la lógica del negocio están en el cliente.

– Cliente/Servidor Distribuido. Servidores que están conectados que a la vez hacen de cliente y servidor.

SQL Server usa la arquitectura Cliente / Servidor para separar la carga de trabajo en tareas que corran en computadoras tipo Servidor y tareas que corran en computadoras tipo Cliente:

– El Cliente es responsable de la parte lógica y de presentar la información al usuario. Generalmente, el cliente corre en una o más computadoras.

– SQL Server administra Bases de Datos y distribuye los recursos disponibles del servidor (tales como memoria, operaciones de disco, entre otros) entre las múltiples peticiones.

Historia de SQL-Server.

Historia de SQL Server
Versión	Año	Nombre de la versión	Code Name
1.0 (OS/2)	1989	SQL Server 1.0	–
4.21 (NT)	1993	SQL Server 4.21	–
6.0	1995	SQL Server 6.0	SQL95
6.5	1996	SQL Server 6.5	Hydra
7.0	1998	SQL Server 7.0	Sphinx
	1999	SQL Server Herramientas OLAP	Platón
8.0	2000	SQL Server 2000	Shiloh
8.0	2003	SQL Server 2000 para 64 bits	Liberty
9.0	2005	SQL Server 2005	Yukon
10.0	2008	SQL Server 2008	katmai

La base de código, para MS SQL Server (antes a la versión 7.0) se originó en Sybase SQL Server y fue el inicio de Microsoft para el mercado a nivel de empresa de base de datos, compitiendo contra Oracle, IBM y Sybase en sí mismo. Microsoft, Sybase y Ashton-Tate originalmente se unieron para crear y la primera versión denominada SQL Server 1.0 para OS/2 (alrededor de 1989) que era esencialmente similar a Sybase SQL Server 3.0 en UNIX en el mercado. Microsoft SQL Server 4.2 se lanzó alrededor de 1992 (disponible con Microsoft OS/2 versión 1.3). Al mismo tiempo con Windows NT 3.1, fue liberado Microsoft SQL Server 4.21 para Windows NT. Microsoft SQL Server v6.0 fue la primera versión diseñada para NT.

En el momento en que Windows NT fue liberado, Sybase y Microsoft dividen caminos y cada uno persigue sus propios planes de diseño y comercialización. Microsoft  negoció derechos exclusivos a todas las versiones de SQL Server escrito para sistemas operativos Microsoft. Más tarde, Sybase cambió el nombre de su producto a Adaptive Server Enterprise para evitar confusiones con Microsoft SQL Server. Hasta 1994, Microsoft SQL Server llevó tres avisos de copyright de Sybase como una indicación de su origen.

SQL Server 7.0 fue una reescritura del código heredado de Sybase. Luego llegó SQL Server 2000, que fue la primera edición a iniciarse en una variante para la arquitectura IA-64.

En los ocho años desde la versión anterior de la actual de Microsoft  SQL Server (SQL Server 2000), se han dado avances en varios sistemas complementarios que se empaquetan con SQL Server 2005, las herramientas IDE de cliente y rendimiento. Estas incluyen: una herramienta ETL (SQL Server Integration Services o SSIS ), un servidor de informes, un servidor OLAP y minería de datos ( Analysis Services ) y varias tecnologías de mensajería, específicamente Service Broker y servicios de notificación.

SQL Server 2005 (con nombre de código Yukon), publicado en octubre de 2005, es el sucesor de SQL Server 2000. Se incluyeron la compatibilidad nativa para administrar los datos XML, además de datos relacionales. Para este propósito, define un tipo de datos XML que podría utilizarse como un tipo de datos en columnas de la base de datos o como literales en consultas. SQL Server 2005 también permite a un servidor de base de datos estar disponible sobre servicios web mediante paquetes TDS encapsulados dentro de las solicitudes SOAP (protocolo). Cuando se tiene acceso a los datos sobre los servicios web, los resultados se devuelven como XML.
Para datos relacionales, T-SQL ha sido ampliado con control de las características y apoyo para consultas recursivas de errores. SQL Server 2005 también se ha mejorado con nuevos algoritmos de indexación y mejores sistemas de recuperación de error. Las particiones en las tablas e índices admiten de forma nativa, por lo que escalado una base de datos en un clúster es más fácil. CLR de SQL se introdujo con SQL Server 2005 para dejarlo a integrar con el .NET Framework.

La versión actual de SQL Server, SQL Server 2008, (denominada «Katmai»,) fue liberado el 6 de agosto de 2008, y pretende hacer gestión de datos, autónomos de organizar y mantener, para proporcionar un tiempo de inactividad en cero. SQL Server 2008 incluirá también apoyo a datos estructurados y semiestructurados, incluyendo los formatos de medios de comunicación digital de imágenes, audio, vídeo y otros datos multimedia.

Otros nuevos tipos de datos que se incluyen son los de fecha y el de hora separados, así como datos espaciales
La funcionalidad de búsqueda de texto ha sido integrada con el motor de base de datos, que simplifica la gestión y mejora el rendimiento.

SQL Server incluye características de compresión, también incluye el Gobernador de recursos que permite reservar los recursos para ciertos usuarios o los flujos de trabajo. También incluye capacidades para cifrado transparente de datos, así como la compresión de las copias de seguridad. SQL Server 2008 apoya el marco de la entidad de ADO.NET y la definición de herramientas, replicación y datos de informes se construirá en el modelo entity framework. La versión de SQL Server Management Studio incluida con SQL Server 2008 admite IntelliSense para las consultas SQL contra un motor de base de datos SQL Server 2008. SQL Server 2008 también disponer las bases de datos a través de los proveedores de Windows PowerShell y funcionalidad de gestión disponible como cmdlets, para que el servidor y todas las instancias que se está ejecutando pueden administrarse desde Windows PowerShell.

Sistema administrador para bases de datos relacionales (rdbms):

El RDBMS es responsable de:

– Mantener las relaciones entre la información y la Base de Datos.

– Asegurarse de que la información es almacenada correctamente, es decir, que las reglas que definen las relaciones ente los datos no sean violadas.

– Recuperar toda la información en un punto conocido en caso de que el sistema falle.

Transact – SQL:

Transact-SQL es el lenguaje que se utiliza para administrar instancias del SQL Server Database Engine (Motor de base de datos de SQL Server), para crear y administrar objetos de base de datos, y para insertar, recuperar, modificar y eliminar datos. Transact-SQL es una extensión del lenguaje definido en los estándares de SQL publicados por International Standards Organization (ISO) y American National Standards Institute (ANSI).

Componentes de SQL Server.

SQL Server Database Engine. SQL Server Database Engine (Motor de base de datos de SQL Server) incluye Database Engine (Motor de base de datos), el servicio principal para almacenar, procesar y proteger datos; también incluye replicación, búsqueda de texto completo y herramientas para administrar datos XML y relacionales.

Analysis Services. Analysis Services incluye las herramientas para crear y administrar aplicaciones de procesamiento analítico en línea (OLAP) y de minería de datos.

Reporting Services. Reporting Services incluye componentes de servidor y de cliente para crear, administrar e implementar informes tabulares, matriciales, gráficos y de forma libre. Reporting Services también es una plataforma extensible que puede utilizarse para desarrollar aplicaciones de informes.

Integration Services. Integration Services es un conjunto de herramientas gráficas y objetos programables para mover, copiar y transformar datos.

Motor de Base de Datos.

Para implementar una aplicación con el motor de base de datos se debe tomar en cuenta las siguientes tareas que se puede realizar con este:

– Diseñar y crear una base de datos que contenga las tablas relacionales o los documentos XML que el sistema necesita.

– Implementar sistemas para obtener acceso y cambiar los datos almacenados en la base de datos, lo que incluye implementar los sitios Web o las aplicaciones que funcionan con los datos, así como crear procedimientos que utilicen las herramientas y utilidades de SQL Server para trabajar con los datos.

– Aplicar los sistemas implementados en la organización o en los clientes.

– Proporcionar soporte técnico administrativo diario para optimizar el rendimiento de la base de datos.

Procesamiento de instrucciones SQL.

Una instrucción SELECT no es de procedimiento, no expone los pasos exactos que el servidor de la base de datos debe utilizar para recuperar los datos solicitados. Esto significa que el servidor de la base de datos debe analizar la instrucción para determinar la manera más eficaz de extraer los datos solicitados. Este proceso se denomina optimizar la instrucción SELECT. El componente que lo lleva a cabo se denomina optimizador de consultas. La entrada al optimizador consta de la consulta, el esquema de la base de datos (definiciones de tabla e índice) y las estadísticas de base de datos. La salida del optimizador es un plan de ejecución de la consulta, en ocasiones denominado plan de la consulta o simplemente plan.

Una instrucción SELECT define únicamente los siguientes elementos:

– El formato del conjunto de resultados.

– Las tablas que contienen los datos de origen.

– Cómo se relacionan lógicamente las tablas para la instrucción SELECT.

– Las condiciones que deben cumplir las filas de las tablas de origen para satisfacer los requisitos de la instrucción SELECT.

Un plan de ejecución de consulta es una definición de los siguientes elementos:

– La secuencia en la que se tiene acceso a las tablas de origen.
Normalmente, hay muchas secuencias diferentes en las que el servidor de la base de datos puede tener acceso a las tablas base para generar el conjunto de resultados. Por ejemplo, si la instrucción SELECT hace referencia a tres tablas, el servidor de la base de datos podría tener acceso primero a TablaA, utilizar datos de TablaA para extraer las filas que coincidan con las de TablaB y, finalmente, utilizar datos de TablaB para extraer datos de TablaC. Las demás secuencias en las que el servidor de base de datos podría tener acceso a las tablas son:
TablaC, TablaB, TablaA
TablaB, TablaA, TablaC
TablaB, TablaC, TablaA
TablaC, TablaA, TablaB

– Los métodos que se utilizan para extraer los datos de cada tabla.
Por lo general, hay métodos diferentes para tener acceso a los datos de cada tabla. Si solo se necesitan unas cuantas filas con valores de clave específicos, el servidor de la base de datos puede utilizar un índice. Si se necesitan todas las filas de una tabla, el servidor de la base de datos puede omitir los índices y realizar un recorrido de la tabla. Si se necesitan todas las filas de la tabla, pero hay un índice cuyas columnas de clave están ordenadas con ORDER BY, realizar un recorrido del índice en lugar de un recorrido de la tabla puede evitar otra ordenación del conjunto de resultados. Si la tabla es muy pequeña, el recorrido de la misma puede ser el método más eficaz para la mayoría de los accesos a la tabla.

El proceso de selección de un plan de ejecución entre varios planes posibles se conoce como optimización. El optimizador de consultas es uno de los componentes más importantes de un sistema de base de datos SQL. Mientras que parte de la carga de trabajo se debe al análisis de la consulta y selección de un plan por parte del optimizador de consultas, esta carga suele reducirse cuando dicho optimizador elige un plan de ejecución eficaz. Por ejemplo, se pueden dar a dos constructoras planos idénticos para una casa. Si una de las constructoras tarda unos días más en planear cómo construirá la casa y la otra comienza a construir inmediatamente sin planear, la que ha planeado su proyecto probablemente terminará antes.

El optimizador de consultas de SQL Server es un optimizador basado en el costo. Cada plan de ejecución posible tiene asociado un costo en términos de la cantidad de recursos del equipo que se utilizan. El optimizador de consultas debe analizar los planes posibles y elegir el de menor costo estimado. Algunas instrucciones SELECT complejas tienen miles de planes de ejecución posibles. En estos casos, el optimizador de consultas no analiza todas las combinaciones posibles. En lugar de esto, utiliza algoritmos complejos para encontrar un plan de ejecución que tenga un costo razonablemente cercano al mínimo posible.

El optimizador de consultas de SQL Server elige, además del plan de ejecución con el costo de recursos mínimo, el plan que devuelve resultados al usuario con un costo razonable de recursos y con la mayor brevedad posible. Por ejemplo, el procesamiento de una consulta en paralelo suele utilizar más recursos que el procesamiento en serie, pero completa la consulta más rápidamente. El optimizador de SQL Server utilizará un plan de ejecución en paralelo para devolver resultados si esto no afecta negativamente a la carga del servidor.

El optimizador confía en las estadísticas de distribución cuando calcula los costos de recursos de métodos diferentes para extraer información de una tabla o un índice. Las estadísticas de distribución se mantienen para las columnas y los índices. Indican la posibilidad de seleccionar los valores de un índice o de una columna determinados. Por ejemplo, en una tabla que representa automóviles, muchos automóviles tienen el mismo fabricante, pero cada uno dispone de un único número de identificación de vehículo (NIV). Un índice del NIV es más selectivo que un índice del fabricante. Si las estadísticas de los índices no están actualizadas, puede que el optimizador de consultas no realice la mejor elección para el estado actual de la tabla.

El optimizador de consultas es importante porque permite que el servidor de la base de datos se ajuste dinámicamente a las condiciones cambiantes de la base de datos, sin necesitar la entrada de un programador o de un administrador de base de datos. Esto permite a los programadores centrarse en la descripción del resultado final de la consulta. Pueden estar seguros de que el optimizador de consultas creará un plan de ejecución eficaz para el estado de la base de datos cada vez que se ejecuta la instrucción.

Procesar una instrucción Select.

Los pasos básicos que SQL Server utiliza para procesar una única instrucción SELECT incluyen lo siguiente:

1. El analizador examina la instrucción SELECT y la divide en unidades lógicas como palabras clave, expresiones, operadores e identificadores.
2. Se genera un árbol de la consulta, a veces denominado árbol de secuencia, que describe los pasos lógicos que se requieren para transformar los datos de origen en el formato que necesita el conjunto de resultados.
3. El optimizador de consultas analiza diferentes formas de acceso a las tablas de origen. A continuación, selecciona la serie de pasos que devuelve los resultados de la forma más rápida utilizando el menor número posible de recursos. El árbol de la consulta se actualiza para registrar esta serie exacta de pasos. La versión final y optimizada del árbol de la consulta se denomina plan de ejecución.
4. El motor relacional comienza a ejecutar el plan de ejecución. A medida que se procesan los pasos que necesitan datos de las tablas base, el motor relacional solicita al motor de almacenamiento que pase los datos de los conjuntos de filas solicitados desde el motor relacional.
5. El motor relacional procesa los datos que devuelve el motor de almacenamiento en el formato definido para el conjunto de resultados y devuelve el conjunto de resultados al cliente.

Base de Datos Ejemplo

Sentencias SQL básicas

Tipos de datos.

– Bit. Tipo de datos entero que puede aceptar valores de 1 y 0.

– Char. Datos de carácter de longitud fija.

– Date. Define una fecha. AAAA-MM-DD.

– Datetime. Define una fecha que combina con una hora del día con fracciones de segundos en un reloj de 24 horas.

– Decimal (p,s). Tipo de dato numérico que tiene precisión y escala fija. p à el número máximo de dígitos decimales que se puede almacenar. sà el número máximo de decimales que se pueden almacenar a la derecha del separador de decimal. 0<=s<=p.

– Image. En futuras versiones será eliminado. Datos binarios de longitud variable desde 0 a 2147483647.

– Int. Tipo de dato numérico exacto que utilizan datos enteros. -2147483648 a 2147483647. 4bytes

– Money. Tipos de datos que representan valores monetarios o de moneda.

– Nchar (n). Datos de carácter de longitud fija. N deb estar comprendido entre 1 y 4000. El tamaño de almacenamiento en bytes es dos veces el número de caracteres especificado.

– Ntext. En futuras versiones será eliminado. Datos de longitud variable con una longitud máxima 2^30

– Numeric(p,s). Tipo de dato numérico que tiene precisión y escala fija. p à el número máximo de dígitos decimales que se puede almacenar. sà el número máximo de decimales que se pueden almacenar a la derecha del separador de decimal. 0<=s<=p.

– Nvarchar(n). Datos de carácter de longitud variable. N puede ser un valor comprendido entre 1 y 4000. El tamaño de almacenamiento en bytes es dos veces el número de caracteres especificado.

– Real. Tipos de datos numéricos y aproximados que se utilizan con datos numéricos de coma flotante. Sinónimo ISO es float(24). De -3,40E+38 a 3,40E+38.

– Tinyint. Tipo de dato numérico exacto que utilizan datos enteros. De 0 a 255. 1byte

– Smallint. Tipo de dato numérico exactos que utilizan datos enteros. De -32768 a 32767. 2bytes

– Text. En futuras versiones será eliminado. Datos de longitud variable de la página de códigos del servidor y con una longitud máxima de 2147483647 caracteres.

– Time. Define una hora de un día. La hora no distingue la zona horaria y está basada en el reloj de 24 horas. Hh:mm:ss.nnnnnnn. 5bytes

– Varchar(n). Datos de caracteres. N puede ser un valor entre 1 y 8000. Los sinónimos ISO son char varying o character varying. Se utiliza este tipo de datos cuando los tamaños de las entradas de datos columnas varíen de forma considerable.

– Uniqueidentifier. 6F9619FF-8B86-D011-B42D-00C04FC964FF. La replicación de mezcla y transaccional con suscripciones de actualización utiliza columnas uniqueidentifier para garantizar que las filas se identifican de forma exclusiva en varias copias de la tabla. 16bytes

CREATE TABLE.

– Crear un nueva tabla.

CREATE TABLE ActividadDiaria

(

CodigoActividad int identity(1,1) not null,

CodigoTopico int null,

FechaInicio datetime null,

FechaFinalizacion datetime null,

Estado char(1) null,

Id_Empleado int null

)

Modelo Relacional

Objetivo.

Estudiar la Forma Normal de Boyce-Codd.

Dependencia Funcional Completa.

– El atributo Y es funcionalmente dependiente y completamente del atributo X, si es funcionalmente dependiente de X y no es funcionalmente dependiente de algún subconjunto de X.

Definición de la Forma Normal de Boyce-Codd.

– La definición de la 3FN puede resultar inadecuada en el caso de una relación donde ocurre lo siguiente:

o La relación tiene varias llaves candidatas donde esas llaves candidatas son compuestas y esas llaves candidatas se solapan (o sea, tienen al menos un atributo común).

– Una relación R está en FNBC si y solo si cada determinante es una superllave (candidata o primaria)

– Obsérvese que se habla en términos de llaves candidatas y no solo de la llave primaria, ya que una llave es un caso especial de superllave y la llave puede ser candidata o primaria.

– La definición de FNBC es conceptualmente más simple pero más fuerte. Una relación que está en FNBC está también en 1FN, 2FN y 3FN.

– Ejemplo: Sea la relación EAP(Estudio, Asignatura, Profesor). Donde una tupla significa que un estudiante E recibe la asignatura A por el Profesor P y en la cual se cumple:

o Para cada Asignatura, cada estudiante tiene un solo profesor.

o Cada profesor imparte solo una asignatura.

o Cada asignatura es impartida por varios profesores.

O sea, AEà P y PàA

Solución AE(Asignatura, Estudio) y PA(Profesor, Asignatura)

Modelo Relacional

Objetivo.

Estudiar la 1ra, 2da y 3ra Forma Normal.

Representación

– Un esquema relacional se representará mediante un grafo, conocido como grafo relacional.

– Las llaves primarias deben a parecer subrayadas

– Las llaves foráneas deben estar en negrillas y referencian a la relación en la que son llave primaria con una flecha

Transformación de entidades, atributos y dominios de un diagrama Entidad – Relación.

– Cada Entidad del esquema E/R dará lugar a una relación cuya llave primaria es el identificador principal de la entidad. (Nota: Se recomienda crear una llave primaria que sea generada por el gestor de base de datos o el programador)

– Cada Atributo de una entidad se transforma en un atributo de la relación, aunque se debe tomar en cuenta los distintos tipos de restricciones.

– Cardinalidad N:M.

o La cardinalidad N:M dan como resultado una nueva relación cuyas clave primaria será la concatenación de los identificadores de las entidades que se enlazan a través de esta.

– Cardinalidad 1:N.

o Da lugar a una propagación de la llave primaria de una relación a otra.

o La propagación de la llave primaria debe ser desde la entidad que se encuentra en el lado 1 a la entidad que se encuentra en el lado n.

– Cardinalidad 1:1:

o Da lugar a una propagación de la llave primaria de una relación a otra, pero debe realizarse un estudio de dominio para decidir cómo será la propagación.

– Generalizaciones.

o Se creará una relación por cada entidad participante en la jerarquía, una relación para el supertipo y otra para cada uno de los subtipos, de tal forma que el supertipo propague su identificador principal (llave primaria) a cada uno de los subtipos.

– Especialización.

o Las llaves primarias de cada una de las entidades que conforman la especialización deben propagarse a través de la entidad con la cual tiene una relación. La propagación debe cumplir con la cardinalidad.

Ejercicios: Convierta los siguientes diagramas entidad – relación a un modelo relacional.

Pasos para la normalización.

1. Cálculos de las dependencias funcionales.

2. Cálculo de las claves candidatas de la relación, de los atributos principales y de los no principales.

3. Cálculo de la forma normal en la que se encuentra la relación.

4. Aplicar los métodos de síntesis o análisis para obtener la forma normal deseada.

Cálculo de las dependencias funcionales.

– Solo es para los atributos.

– Entre los atributos de una relación puede existir dependencias de varios tipo

– Las dependencias son propiedades inherentes al contenido semántico de los datos, formando parte de las restricciones de usuario del modelo relacional.

– Dependencia funcional.

o Definición. Sea el esquema de relación R, y X y Y dos subconjuntos denominados descriptores. Y depende funcionalmente de X (X implica o determina a Y) si para cada valor de X solamente existe un único valor posible de Y. Ejemplo: Automóviles, las características del vehículo dependen funcionalmente de la Placa o del número de registro. Dada una placa se determina las características del vehículo.

o Notación: XàY. por el ejemplo anterior PlacaàModelo, Color, Número de Puertas

o Cuando dos o más atributos se implican funcionalmente mutuamente se dice que son equivalentes. Ejemplo: Nombre_Profesor ß à Carnet_Identidad.

o Reflexividad. A partir de cualquier atributo o conjunto de atributos siempre puede deducirse él mismo. Dependencia trivial: x -> x.

o Aumentativadad. Si x à y entonces x+z à y. Así se puede aumentar trivialmente el antecedente de una dependencia. Ejemplo: si con el Carnet_Identidad se determina el Nombre de una persona, entonces con el Carnet_Identidad más la Dirección también se determina el nombre.

o Proyectitividad. Si x à y+z entonces x à y. Ejemplo: si a partir del Carnet_Identidad es posible deducir el nombre y la dirección de una persona, entonces con el Carnet_Identidad es posible determinar el nombre.

o Aditividad. Si x à y y z à w entonces x+z à y+w. Ejemplo: si con el Carnet_Identidad se determina el nombre y con la dirección el teléfono de una persona, entonces con el Carnet_Identidad y la dirección podrá determinarse el nombre y el teléfono.

o Transitividad. Si xày e yàz entonces xàz. Ejemplo: si con el Carnet_Identidad
puede determinarse el código de la provincia de residencia de una persona y con éste código puede determinarse el nombre de la provincia, entonces con el Carnet_Identidad puede determinarse el nombre de la provincia. Éste es el mecanismo básico de funcionamiento del enlace entre tablas a partir de claves ajenas

Primera Forma Normal.

– Definición: Una relación está en 1FN si cumple la propiedad de que sus dominios no tienen elementos que, a su vez, sean conjuntos. Una relación está en 1FN si no incluye ningún grupo repetitivo (Un grupo repetitivo es un atributo que contiene un conjunto de valores y no un único valor).

– Definición: Se dice que una relación se encuentra en 1FN cuando cada atributo solo toma un valor del dominio simple subyacente. Es decir que no existen grupos repetitivos.

– La primera forma normal es una restricción inherente al modelo relacional, por lo que su cumplimiento es obligatorio para toda relación.

La primera tabla no se encuentra en la 1FN, sin embargo la segunda tabla sí cumple con la restricción y por tanto se trata de una relación.

Segunda Forma Normal.

– Definición: Una relación R se dice que está en 2FN si está en 1FN y si, solo si, los atributos no llaves (ni primarias, ni candidatas) de R, si los hubiese, son funcional y completamente dependientes de la llave primaria R

– Por ejemplo: En el esquema de relación R({A,B,C,D}, {A,BàC; AàD}, donde la llave candidata es el conjunto {A,B}, y por lo tanto los atributos principales son A y B y los no principales C y D, el atributo no principal D, depende de A, pero no de una llave. Por lo tanto, el esquema no se encuentra en 2FN. Sin embargo los esquemas R1({A,B,C,}, {A,BàC}) Y R2({A,D}, {AàD}) se encuentran en 2FN.

Procedimiento para hallar llaves candidatas de una relación.

Supongamos que se quiere encontrar las llaves candidatas de una relación R(A,B,C,D,E) con las siguientes dependencias funcionales:

A B

BC D

AB E

Para comenzar, se parte de que no existen más llaves que dependencias funcionales, pues el concepto de llave incluye la existencia de dependencia funcional. Se analiza, por tanto, cada una de las DF presentes en la relación, añadiendo los atributos que sean imprescindibles en la parte izquierda para lograr determinar a todos los atributos de la relación. El conjunto de atributos así formado debe ser mínimo.

Luego se analiza cada uno de esos conjuntos mínimos, de forma que, si alguno es un superconjunto de otro, ya no es llave, sino superllave. Pueden resultar varias llaves candidatas.

En el ejemplo:

1. AB ACA B E C D AC es llave

2. BCD BCAB C D A E BCA es superllave

3. ABE ABCA B E C D ABC es superllave

La única llave es AC. No hay ninguna otra llave candidata, pues en las otras DF se obtiene el mismo conjunto ABC y este conjunto contiene a AC.

Tercera Forma Normal.

– Una relación R está en 3FN si está en 2FN y si, y sólo si, los atributos no llaves son independientes de cualquier otro atributo no llave primaria.

– Esto es lo mismo que decir que se deben eliminar las dependencias transitivas de atributos no llaves respecto a la llave primaria, estando ya la relación en 2FN.

Ejemplo. En el esquema de relación R({A,B,C}, {AàB; BàC}), la llave candidata de la relación es el atributo A, y los atributos no principales B y C. Como el atributo C depende transitivamente de la clave A, la relación no se encuentra en 3FN, aunque en sí en 2FN, ya que C depende transitivamente de la llave. Sin embargo, las relaciones R1({A,B},{AàB}) y R2({B,C},{BàC}), sí se encuentra en 3FN.

DETERMINACIÓN DE LOS REQUISITOS NO FUNCIONALES DE LA APLICACIÓN

DESARROLLO DE APLICACIONES WEB EN MICROSOFT C# .NET MODELADAS EN UML.

Se debe definir los requisitos no funcionales del software a desarrollar. Implica la determinación de los atributos no funcionales asociadas a las facilidades, funcionalidades y de características generales del software como controles necesarios para garantizar la confiabilidad del sistema, seguridad propuesta, requisitos de la calidad, interfaces con otros sistemas de procesamiento manual o automatizado, ambiente de software y hardware.

Para la definición de los requisitos no funcionales se utilizará la clasificación de la Norma ISO-9126 (2000), el modelo de calidad que clasifica los atributos de la calidad del software en seis características, que son además divididas en sub-características. El efecto combinado de las características de calidad de software para el usuario se define como la calidad en el uso. Las características definidas son aplicables a todo tipo de software. La ISO 9126 permite especificar y evaluar la calidad del producto de software desde las perspectivas diferentes, asociados con la adquisición, regulación, desarrollo, uso, evaluación, apoyo, mantenimiento, aseguramiento de la calidad y auditoría del software. El modelo de calidad definido puede usarse para:

• Validar la integridad de la definición de los requisitos;
• Identificar los requisitos no funcionales del software (Este punto es el que interesa para este documento);
• Identificar los objetivos del diseño del software;
• Identificar los objetivos de prueba del software;
• Identificar el criterio de aceptación de usuario para un producto de software completo.

Las seis características son:

• Funcionalidad. La capacidad del software para proporcionar funciones que satisfacen las necesidades declaradas e implícitas cuando el software se usa bajo las condiciones especificadas. Esta característica está relacionada con lo que hace el software para satisfacer las necesidades.
  • La Idoneidad. La capacidad del software para mantener un conjunto apropiado de funciones para las tareas especificadas y los objetivos del usuario.
  • La Precisión. La capacidad del software para proporcionar efectos o resultados correctos o convenidos en cálculos y resultados.
  • La Interoperabilidad. La capacidad del software para actuar recíprocamente con uno o más sistemas especificados. La interoperabilidad se usa en lugar de la compatibilidad para evitar la posible ambigüedad
  • La Seguridad. La capacidad del software para proteger información y los datos, para que personas o sistemas desautorizados no puedan leer o pueden modificar los mismos, y a las personas o sistemas autorizados no les sea denegado el acceso a ellos. Debe aplicarse a los datos en transmisión. Debe tomarse en cuenta para la aplicación completa
  • La Conformidad. La capacidad del software para adherirse a las normas que se le apliquen , convenciones, regulaciones, leyes y las prescripciones similares
• Confiabilidad. La capacidad del software para mantener su nivel de ejecución cuando se usa bajo las condiciones especificadas. El sobre uso o el envejecimiento no ocurre en el software
  • La Madurez. Capacidad del software de evitar errores como resultado de haberse producido un fallo del software
  • La Tolerancia ante fallos. Capacidad del software de mantener un nivel de ejecución específico en caso de fallos del software o de infracción de sus interfaces especificadas. Un nivel de ejecución específico puede incluir la falta la capacidad segura
  • La facilidad de restablecer. Capacidad del software de restablecer su nivel de ejecución y recobrar los datos directamente afectados en caso de avería.
• Facilidad de Uso. La capacidad del software ser comprendido, aprendido, utilizado y de ser amigable para el usuario, cuando se emplee bajo las condiciones especificadas.
  • La Facilidad de Comprensión. La capacidad del producto de software para permitirle al usuario entender si el software es conveniente, y cómo puede usarse para las tareas particulares y condiciones de uso. Esto dependerá de la documentación y la impresión inicial dada por el software.
  • La Facilidad Cognoscitiva. La capacidad del producto del software para permitirle al usuario aprender su aplicación.
  • La Operabilidad. La capacidad del producto del software para permitirle al usuario operarlo y controlarlo. Operabilidad corresponde a la capacidad de ser controlado, la tolerancia ante errores y la conformidad con las expectativas del usuario
  • La Atracción. La capacidad del producto del software de ser amigable para el usuario. Esto se refiere a los atributos del software que se aplican para hacer el software más atractivo al usuario.
• Eficiencia. La capacidad del software para proporcionar la requerida ejecución, en relación con la cantidad de recursos usados, bajo las condiciones declaradas.
  • El crono-comportamiento. La capacidad del software para proporcionar una respuesta apropiada y los tiempos de procesamiento y tasas de rendimiento de procesamiento al realizar su función, bajo condiciones declaradas.
  • La Utilización de los Recursos. La capacidad del software para usar los recursos apropiados en un plazo de tiempo adecuado cuando el software realiza su función bajo las condiciones declaradas
• Facilidad de mantenimiento. La capacidad del software de ser modificado. Las modificaciones pueden incluir las correcciones, mejoras o adaptación del software a los cambios en el ambiente, y en los requisitos y las especificaciones funcionales.
  • La Facilidad de Diagnostico. La capacidad del producto del software ser diagnosticado para detectar deficiencias o causas de defectos o errores en el software y detectar a las partes para ser modificadas para ser identificadas
  • La Mutabilidad. La capacidad del producto del software para permitir llevar a cabo una modificación especificada. Incluye la codificación, diseño y documentación de los cambios.
  • La Estabilidad. La capacidad del software para minimizar los efectos inesperados de las modificaciones del software.
  • La facilidad de Comparación. La capacidad del producto del software para permitir validar el software modificado
• Portabilidad. Capacidad de software ser transferido de un ambiente a otro. El ambiente puede incluir el ambiente del software, del hardware u organizacional
  • La facilidad de adaptación. La capacidad del software de ser modificado para los ambientes especificados sin aplicar acciones o medios de otra manera que aquellos suministrados con este propósito para el software considerado. Adaptabilidad incluye el escalado de la capacidad interna (por ejemplo los campos de la pantalla, las tablas, los volúmenes de transacción o los formatos de informes.).
  • La facilidad de Instalación. La capacidad del software ser instalado en un ambiente especificado
  • La coexistencia. La capacidad del software para coexistir con otro software independiente en un ambiente común que comparte los recursos comunes
  • La facilidad de Reemplazo. La capacidad del software ser usado en lugar de otro software especificado en el ambiente de ese software. Se usa en lugar de la compatibilidad para evitar la posible ambigüedad con el interoperabilidad.

Como se puede comprender, sobre estas características o atributos del software, es muy importante tenerlas muy en cuenta y definirlas. Es claro que para un determinado software se seleccionan algunas de estas características, esto se debe a gran variedad de tipos de software que se pueden desarrollar, no es lo mismo desarrollar un editor de texto que una aplicación de gestión de información. Pero al seleccionar, estos atributos, implica un compromiso de demostrar al final del desarrollo que se ha llegado a una conformidad exitosa de estas. En próximos cursos se hablará de métricas de software que ayudan a validar el software sobre las características definidas y el como evaluar.

Para este documento, la visión de la utilización de estas características es poder identificar a los requisitos no funcionales de la aplicación que se está modelando. De este modo se definirá algunas de las características que a consideración del Grupo de Investigación corresponden para la aplicación Hotelera.

REQUISITOS NO FUNCIONALES PARA LA APLICACIÓN

FUNCIONALIDAD

• La Idoneidad. La aplicación debe proporcionar opciones bien descritas para los usuarios, explicando la operación que se puede realizar.
• La Precisión. Debe proporcionar al usuario opciones que permiten realizar el trabajo y deben estar correctamente descritas y debe existir una orientación para cada una de ellas. No debe presentarse al usuario opciones restringidas
• La Seguridad. El acceso a la aplicación debe estar controlada por una contraseña y nombre de usuario. La contraseña debe estar protegida de acuerdo a un algoritmo de encriptación a un nivel internacional, correctamente documentado. Debe garantizarse que la información transmitida no pueda ser capturada o interpretada.

CONFIABILIDAD.

• La Madurez. Debe presentarse al usuario información sobre los errores que comete al utilizar al aplicación, estos errores deben estar bien identificados y en el idioma Español. Los mensajes de error deben contar con una ayuda para orientar al usuario en su trabajo así no cometer reiteradamente el mismo error, además debe existir una explicación del por qué del error.

FACILIDAD DE USO.

• La Facilidad de Comprensión. La aplicación debe ayudar al trabajo o al interés del usuario. Debe explicarse de una manera correcta las distintas opciones que le permite la aplicación o una determinada interfaz. Cada opción debe escribirse de forma completa
• La Facilidad Cognoscitiva. Debe considerarse imágenes para la mejor comprensión y aprendizaje de la aplicación, tomando en cuenta el tiempo de ejecución.
• La Atracción. Debe definirse un estándar de interfaz tomando en cuenta los colores de la institución y los colores de la empresa que desarrolla la aplicación, ya que con estas dos combinaciones se tiene la probabilidad de que el usurario este cómodamente trabajando con la aplicación. No se debe olvidar el estándar que proporciona la interfaz Windows y el diseño de interfaz que muestra Microsoft para las paginas Web.

EFICIENCIA.

• La Utilización de los Recursos. Debe utilizarse procedimientos almacenados básicos, que no tengan más de una sentencia, esto para el acceso a la base de datos. Los filtros de búsquedas o logica del negocio para los datos debe implementarse en la capa de negocio.

FACILIDAD DE MANTENIMIENTO.

• La Facilidad de Diagnostico. Debe realizarse la Prueba con la ayuda de los casos de uso de prueba. De esta forma garantizar el buen funcionamiento de la aplicación.

PORTABILIDAD.

• La facilidad de adaptación. Se debe utilizar un marco de trabajo que garantice un mantenimiento respecto a la tecnología que pueda aparecer y a los paradigmas de desarrollo de interfaz. Además, la interfaz a desarrollar debe ser probada en distintos escenarios de navegadores y/o computadoras, para de esta forma garantizar la adaptación de la aplicación.
• La facilidad de Instalación. Debe crearse para la aplicación un paquete de instalación con su respectivo manual para que los encargados de la aplicación puedan restablecer con bastante rapidez la aplicación, debe tomarse en cuenta que pude ser más de un instalador ya que la aplicación está orientada a los Servicios. Solo se tomará en cuenta la tecnología Windows para desarrollar el paquete de instalación.
• La coexistencia. Debe poderse instalar en una sola computadora toda la aplicación, ya sea los Servicios Web como las Aplicaciones Web. Pero, deben tener características independientes.

De esta forma se ha especificado los Requisitos No Funcionales para la aplicación de Hotel.

Como se ha dicho anteriormente, al describir los atributos se llega a un compromiso de cumplimiento de cada uno de estos. Este curso no demostrará el cumplimiento de estos ya que se tiene que estudiar parte de la teoría de Mediciones y Métricas en el Software.

Luego de determinar y explicar como tiene que llevarse a cabo los requisitos no funcionales se deben realizar varias actividades adicionales son las siguientes:

– Determinar la importancia y el riesgo

– Separar en ciclos (Priorizar).

– Determinar los paquetes

– Detallar de forma expandida (completa)

DETERMINAR LA IMPORTANCIA Y EL RIESGO

Para realizar estas dos tareas, las cuales se las puede llevar conjuntamente se debe realizar un análisis por cada caso de uso y determinar la importancia que tiene en la aplicación, se puede utilizar una escala del 1 al 5, donde 5 es más significativo. Esto se realiza para determinar parte del dominio del riego por requisito y determinar cual caso de uso debe ser más estudiado para no tener dificultades. Luego se determina el total del dominio de riesgo por cada caso de uso, para esto se realiza un estudio del flujo básico de cada caso de uso y los procesos de la empresa a través del los diagrama de actividad. El riego es considerado como el cambio que se puede producir en el requisito. Muchos de los requisitos (casos de uso) pueden cambiar en su flujo básico de interacción con el usuario o que la empresa cambie sus procesos que van a influenciar al requisito, este cambio implica un cambio total en todas las etapas. Por este motivo es muy importante determinar el riesgo de cada caso de uso. El riesgo y la importancia que se determinen permitirán realizar un seguimiento correcto a los casos de uso.

En este curso no se ve como llevar a cabo estas tareas.

SEPARAR EN CICLOS DE DESARROLLO.

Una vez determinada la importancia de los casos de uso se pueden separar por ciclos de desarrollo. Un ciclo de desarrollo será llevado a cabo de principio a fin, logrando en su finalización un producto que funcione y que este probado. Cada ciclo, que esta compuesto por casos de uso, seguirá un ciclo de vida del producto.

A continuación se ve un ejemplo de cómo se ha determinado los ciclos de desarrollo.

Se ve en la Figura 1 un diagrama de casos de uso que corresponde a una aplicación que distribuye productos de todo tipo.

Figura 1. Diagrama de Casos de Uso Distribución de Productos

La Figura 2 muestra el Primer Ciclo de desarrollo

Figura 2. Primer Ciclo de Desarrollo

En la siguiente figura, Figura 3, se ve el Segundo ciclo.

Figura 3. Segundo Ciclo de Desarrollo

La siguiente Figura 3 muestra el último ciclo de desarrollo.

Figura 4. Tercer Ciclo de Desarrollo

Como se puede observar, cada ciclo representa parte de las funcionalidades futuras de la aplicación de la aplicación que se irán construyendo.

A continuación, se lleva a cabo el análisis de los ciclos para la aplicación que sirve de emplo.

La Pantalla 1 es el resultado del desarrollo del Diagrama de Casos de Uso, el cual no servirá para analizar los ciclos de desarrollo.

Pantalla 1. Diagrama de Casos de Uso

Existen muchas alternativas para definir los ciclos de desarrollo. Se puede dividir en ciclo de desarrollo, por ejemplo, por Actor de la aplicación, es decir tener cuatro ciclos de desarrollo, que serian:

– Primer Ciclo: Gestionar Empleados, Gestionar Bebidas, Gestionar Cocina.

– Segundo Ciclo de Desarrollo: CU Reservar Habitación, CU Confirmar Reserva, CU Salir del Hotel.

– Tercer Ciclo de Desarrollo: Cambiar Contraseña, Autenticar Empleado.

– Cuarto Ciclo de Desarrollo: CU Registrar Solicitud de Servicio a la Habitación, CU Registrar Solicitud de Servicio Básico.

También, se puede dividir por funcionalidad de los casos de uso, es decir, los que estén relacionados para realizar una actividad completa, por ejemplo:

– Primer Ciclo de Desarrollo: Gestionar Empleados, Autenticar Empleado, Cambiar Contraseña.

– Segundo Ciclo de Desarrollo: CU Reservar Habitación, CU Confirmar Reserva, Salir Hotel.

– Tercer Ciclo de Desarrollo: Gestionar Bebidas, Gestionar Cocina, CU Registrar Solicitud de Servicio Básico, CU Registrar Solicitud de Servicio a la Habitación.

Como se puede ver, en los dos casos, al final de cada ciclo el resultado debe ser una aplicación que pueda realizar algunas de las tareas necesarias para el usuario. Dentro del primer ciclo se debe seleccionar a los casos de uso que sean independientes, con poco acoplamiento entre los otros. Por ejemplo, para reservar una habitación, el Empleado debe estar autenticado y tener autorización para realizar esta actividad, caso contrario no se podría reserva la habitación, por este motivo es necesario desarrollar el primero el caso de uso que es Gestionar Empleado, luego Autenticar Empleado y Cambiar Contraseña. Este tipo de análisis se debe realizar para determinar cada ciclo de desarrollo.

Para el ejemplo de desarrollo, se toma la segunda opción de división de ciclos. Como se puede ver en las siguientes Pantallas, se ha dividido por ciclo.

El primer Ciclo a desarrollar se pude ver en la Pantalla 2.

Pantalla 2. Primer Ciclo de Desarrollo

El Segundo Ciclo de Desarrollo se puede ver en la Pantalla 3.

Pantalla 3. Segundo Ciclo de Desarrollo

El Tercer Ciclo de Desarrollo se puede ver en la Pantalla 4.

Pantalla 4. Tercer Ciclo de Desarrollo

Cada uno de estos ciclos tendrá las siguientes características (Ejemplo):

– Planificación para llevar a cabo el desarrollo por cada caso de uso

– Asignación de personas para el desarrollo

– Plan de revisiones

– Plan de integración

– La disciplina de Análisis si es que se debe hacer

– La Disciplina de diseño

– La Disciplina de Implementación

– La disciplina de Prueba

Cada ciclo que se determine tendrá muchos artefactos que le acompañen, esto implica realizar todas las actividades del desarrollo de software. En el curso no se llevará acabo el desarrollo por ciclos, solo se utilizara dos casos de uso que permitan ejemplificar algunas de las actividades necesarias para tener una aplicación.

Los otros dos puntos de Determinar los Paquetes y Detallar de forma Expandida se verán con mayor detalle en los próximos documentos.

DESCRIPCIÓN DE LOS CASOS DE USO DE LA APLICACIÓN

DESARROLLO DE APLICACIONES WEB EN MICROSOFT C# .NET MODELADAS EN UML.

DESCRIPCIÓN DE LOS CASOS DE USO DE LA APLICACIÓN

Se cuenta con el Diagrama de Casos de Uso del Sistema que nos da una idea muy amplia de las funcionalidades que tendrá la aplicación. A continuación se describe cada caso de uso de forma resumida (alto nivel) ya que en la parte de análisis se hará de forma completa con todas las interacciones del usuario hacia la aplicación. Esta descripción resumida nos permitirá realizar una estimación del esfuerzo, costo y tiempo a través de los Puntos Función y los Casos de Uso. Esta técnica se describirá en este documento.

A continuación se realiza una breve descripción de los casos de uso.

La plantilla que se utiliza para la descripción de los casos de uso es la siguiente:

Caso de Uso	Nombre del caso de uso
Actores	Actores
Resumen	Breve descripción de lo que hace el CU

Tabla 1. Plantilla para la descripción de los Casos de Uso

DESCRIPCIÓN DE LOS CASOS DE USO

Caso de Uso	Reservar Habitación
Actores	Usuario (Recepcionista y Cliente)
Resumen	El caso de uso se inicia cuando el Usuario quiere reservar una habitación, respecto a su necesidad. La habitación puede ser individual, doble o triple, el usuario debe registrar sus datos y la aplicación tiene que proporcionarle opciones de selección para registrar la reserva.

Caso de Uso	Confirmar Reserva
Actores	Recepcionista
Resumen	El caso de uso se inicia cuando el Recepcionista debe confirmar la estancia de un Cliente hacia una habitación, anteriormente reservada ya sea por el Cliente o el Recepcionista, la aplicación debe dar la opción de confirmar la habitación enviando un mensaje. De esta forma el Cliente tendrá una cuenta habilitada para todos los servicios del hotel.

Caso de Uso	Salir del Hotel
Actores	Recepcionista
Resumen	El caso de uso se inicia cuando el Recepcionista decide cerrar el hospedaje de un Cliente. El recepcionista debe calcular el monto de dinero que ha significado el servicio hacia el Cliente. La aplicación debe proporcionar opciones para calcular el monto de dinero y emitir la factura

Caso de Uso	Cambiar Contraseña
Actores	Empleado (Recepcionista y Jefe de Cocina)
Resumen	El caso de uso se inicia cuando el empleado quiere cambiar la contraseña de acceso a la aplicación. La aplicación debe proporcionarle una interfaz para que pueda cambiar la contraseña de acceso, además, debe emitir un mensaje de conformidad.

Caso de Uso	Autentificar Empleado
Actores	Empleado (Recepcionista y Jefe de Cocina)
Resumen	El caso de uso se inicia cuando el Empleado quiere ingresar a la aplicación, para esto debe introducir su cuenta y contraseña de acceso a una interfaz que le proporciona la aplicación.

Caso de Uso	Registrar Solicitud de Servicio a la Habitación
Actores	Jefe de Cocina
Resumen	El caso de uso se inicia cuando el Jefe de Cocina va a registrar una solicitud de servicio a la habitación que ha hecho el Cliente, esta solicitud involucra las comidas, las bebidas y la habitación. La aplicación le debe proporcionar una interfaz para registrar la solicitud, para esto debe seleccionar de una lista las bebidas y las comidas.

Caso de Uso	Registrar Solicitud de Servicio Básico
Actores	Jefe de Cocina
Resumen	El caso de uso se inicia cuando el Jefe de Cocina va a registrar un solicitud de servicio básico (Desayuno, Almuerzo o Cena) que ha hecho el Cliente a través del mozo, esta solicitud involucra las comidas, las bebidas y la habitación. La aplicación debe proporcionar una interfaz para registrar la solicitud, para esto debe seleccionar de una lista las bebidas y las comidas solicitadas

Caso de Uso	Gestionar Empleados
Actores	Administrador
Resumen	El caso de uso se inicia cuando el Administrador necesita Adicionar, Modificar, Eliminar o Imprimir sus datos de un empleado. El sistema debe proporcionarle las opciones para realizar estas operaciones

Caso de Uso	Gestionar Bebidas
Actores	Administrador
Resumen	El caso de uso se inicia cuando el Administrador necesita Adicionar, Modificar, Eliminar o Imprimir datos de las bebidas disponibles para el Cliente. La aplicación debe proporcionarle las opciones para realizar estas operaciones

Caso de Uso	Gestionar Comidas
Actores	Administrador
Resumen	El caso de uso se inicia cuando el Administrador necesita Adicionar, Modificar, Eliminar o Imprimir datos de las comidas disponibles para el Cliente. La aplicación debe proporcionarle las opciones para realizar estas operaciones

Caso de Uso	Gestionar Habitación
Actores	Administrador
Resumen	El caso de uso se inicia cuando el Administrador necesita Adicionar, Modificar, Eliminar o Imprimir datos de las habitaciones disponibles para el Cliente. La aplicación debe proporcionarle las opciones e interfaz para realizar estas operaciones

De esta forma se ha descrito de forma breve los casos de uso, lo cual da una pequeña idea de la magnitud de la aplicación. A continuación realizaremos una estimación de esfuerzo, costo y tiempo para la aplicación Hotelera.

ESTIMACIÓN DE ESFUERZO, COSTO Y TIEMPO

Utilizar los Casos de Uso que permite documentar a los requisitos de una aplicación en términos de Actores y Casos de Uso. Como se ha explicado en anteriores documentos, un Actor típicamente representa a un usuario humano o a otra aplicación que interactúa con la aplicación bajo Desarrollo. Un Caso de Uso representa un requisito de la Aplicación bajo análisis, relata de forma secuencial las acciones que uno o más actores llevan a cabo en el sistema para obtener un resultado de valor significativo.

Si bien los Casos de Uso permiten especificar la funcionalidad de una aplicación bajo análisis, no permiten, por sí mismos, efectuar una estimación del tamaño que tendrá la aplicación o del esfuerzo que tomaría implementar.

Para la estimación del tamaño de una aplicación a partir de sus requisitos, una de las técnicas más difundidas es el Análisis de Puntos de Función. Ésta técnica permite cuantificar el tamaño de un sistema en unidades independientes del lenguaje de programación, las metodologías, plataformas y/o tecnologías utilizadas.

Por otro lado, el SEI (del inglés, Software Engineering Institute) propone desde hace algunos años un método para la estimación del esfuerzo llamado COCOMO II. Éste método está basado en ecuaciones matemáticas que permiten calcular el esfuerzo a partir de ciertas métricas de tamaño estimado, como el Análisis de Puntos de Función y las líneas de código fuente (en inglés SLOC, Source Line Of Code).

Existe una relación natural entre los Puntos de Función y los Casos de Uso. Los Puntos de Función permiten estimar el tamaño del software a partir de sus requisitos, mientras que los Casos de Uso permiten documentar los requisitos. Ambos tratan de ser independientes de las tecnologías utilizadas para la implementación. En etapas tempranas del ciclo de vida, se identifican los Actores y los Casos de Uso de la aplicación y se documenta cada uno de estos mediante una breve descripción.

Utilizando el Análisis de Puntos de Función a estos Casos de Uso, se podrá obtener una estimación grosera del tamaño y a partir de esta del esfuerzo. Esta estimación es bastante imprecisa debido, principalmente, a la escasa información que se tiene sobre el software al principio de un proyecto, pero permitirá obtener una idea del esfuerzo necesario para llevar adelante el mismo, y podrá ser refinada a medida que se obtenga más información.

Se recalca que es una estimación, lo más importante de esta actividad es que se podrá realizar un plan para el desarrollo de software. La Planificación está muy relacionada con las actividades de la estimación, para determinar las actividades dentro de la planificación es muy necesario conocer el tiempo, costo y el esfuerzo que se necesitarán para llevar a cabo el desarrollo.

Pressman señala los siguiente: Para llevar a cabo un buen proyecto de desarrollo de software, debemos comprender el ámbito del trabajo a realizar, las tareas a ejecutar, las referencias a tener en cuenta, la agenda a seguir, el esfuerzo a emplear y los recursos requeridos.

Con la descripción y estudio de los casos de uso se determina el ámbito del trabajo, las tareas a ejecutar y las referencias a tener en cuenta. Con la estimación con ayuda de los Puntos Función y los Casos de Uso, se llega a determinar los recursos y el esfuerzo que se van a necesitar. Dentro de estos documentos que describen el desarrollo de una aplicación no se llega a tocar el punto de planificación del proyecto, la agenda de las actividades que se deben realizar para llevar a cabo el desarrollo. Pero, todo en la vida se debe planificar, si no se llega a obtener una planificación no se podrá hacer, no se tendrá una estrategia y no se tendrá un proyecto. El plan de proyecto debe tener en cuenta el alcance, tareas, calidad, métricas, cronogramas y disponibilidad de recursos. El desarrollo de software cumple un ciclo de vida como todo producto tangible, el ciclo de vida del proyecto de software se puede determinar en cinco fases de proceso que determina la Guía del PMBOK y son: Proceso de Inicialización, Planificación, Ejecución, Seguimiento y Control y el Proceso de Cierre.

En un próximo conjunto de documentos se hablará de la Gestión de Proyectos de Software.

Para entender con mayor facilidad se define los siguientes conceptos:

• Esfuerzo: Tiempo que necesita una persona para trabajar en el desarrollo del proyecto (hombres/mes, hombres/días, hombres/horas).
• Tiempo: duración total del proyecto.
• Cantidad de Personas: Recursos necesarios para desarrollar el software.
• Costo: cantidad de dinero que se necesita para llevar a cabo el desarrollo de software.
• Transacciones: Está representada por uno o más pasos del flujo de eventos principal del Caso de Uso, pudiendo existir más de una transacción dentro del mismo Caso de Uso. Los flujos de eventos alternativos dentro del Caso de Uso, ayudan a clarificar las transacciones.

La estimación mediante el análisis de Puntos de Casos de Uso es un método propuesto originalmente por Gustav Karner de Objectory AB, y posteriormente refinado por muchos otros autores. Se trata de un método de estimación del tiempo de desarrollo de un proyecto mediante la asignación de «pesos» a un cierto número de factores que lo afectan, para finalmente, contabilizar el tiempo total estimado para el proyecto a partir de esos factores.

El primer paso es calcular los Puntos de Casos de Uso sin Ajustar. Este valor se calcula con la siguiente ecuación:

UUCP = UAW + UUCW

donde,

• UUCP: Puntos de Casos de Uso sin ajustar
• UAW: Factor de Peso de los Actores sin ajustar
• UUCW: Factor de Peso de los Casos de Uso sin ajustar

El Factor de Peso de los Actores (UAW) sin ajustar se calcula mediante un análisis de la cantidad de Actores presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los Actores se establece teniendo en cuenta:

• Si se trata de una persona o de otro sistema
• La forma en la que el actor interactúa con el sistema.

Los criterios se muestran en la siguiente tabla

Tipo de Actor	Descripción	Factor de Peso
Simple	Otro sistema que interactúa con el sistema a desarrollar mediante una interfaz de programación (API, Application Programming Interface)	1
Medio	Otro sistema que interactúa con el sistema a desarrollar mediante un protocolo o una interfaz basada en texto	2
Complejo	Una persona que interactúa con el sistema mediante una interfaz gráfica	3

Tabla 2. Posibles Factores de Peso de los Actores

El Factor de Peso de los Casos de Uso sin Ajustar (UUCW) se calcula mediante un análisis de la cantidad de Casos de Uso presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los Casos de Uso se establece teniendo en cuenta la cantidad de transacciones efectuadas en el mismo, donde una transacción se entiende como una secuencia de actividades atómica, es decir, se efectúa la secuencia de actividades completa, o no se efectúa ninguna de las actividades de la secuencia. Los criterios se muestran en la siguiente tabla:

Tipo de Caso de Uso	Descripción	Factor de Peso
Simple	El caso de uso tiene de 1 a 3 transacciones	5
Medio	El caso de uso tiene de 4 a 7 transacciones	10
Complejo	El caso de uso contiene mas de 8 transacciones	15

Tabla 3. Posibles Factores de Peso para los Casos de Uso

Aplicando el análisis al ejemplo de desarrollo que llevamos en estos documentos, se realiza el calculo de

Los Puntos de Casos de Uso sin Ajustar.

Análisis de los Actores para encontrar el Factor de Peso de Actores sin Ajustar

Actor	Factor Peso
Cliente	3
Recepcionista	3
Jefe de Cocina	3
Administrador	3

UAW= 3+3+3+3 = 12 (Peso de los Actores sin Ajustar)

Análisis de los Casos de Uso para encontrar el Factor de Peso de Casos de Uso sin Ajustar

El análisis se debe hacer a cada caso de uso y pensar cuantas transacciones tiene cada uno de ellos.

Casos de Uso	Factor de Peso
Reservar Habitación	(Una transacción) 5
Confirmar Reserva	(Dos transacciones) 5
Salir del Hotel	(Cuatro Transacciones) 10
Cambiar Contraseña	(Una Transacción) 5
Autenticar Empleado	(Una Transacción) 5
Registrar Solicitud de Servicio a la Habitación	(Tres Transacciones) 5
Registrar Solicitud de Servicio Básico	(Tres Transacciones) 5
Gestionar Empleados	(Siete Transacciones) 10
Gestionar Bebidas	(Siete Transacciones) 10
Gestionar Comidas	(Siete Transacciones) 10
Gestionar Habitación	(Siete Transacciones) 10

UUCW= 5+5+10+5+5+5+5+10+10+10+10 = 80 (Peso de Casos de Uso sin Ajustar)

Finalmente, los Puntos de Casos de Uso sin ajustar seria:

UUCP = 12 + 80 = 92

Nos falta calcular varias cosas antes de obtener el esfuerzo.

Una vez que se tiene los Puntos de Casos de Uso sin Ajustar se debe ajustar este valor mediante la siguiente ecuación:

UCP = UUCP x TCF x EF

donde,

• UCP: Puntos de Casos de Uso ajustados
• UUCP: Puntos de Casos de Uso sin ajustar
• TCF: Factor de complejidad técnica
• EF: Factor de ambiente

Para calcular el Factor de Complejidad Técnica se debe definir varios Factores que influyen en la complejidad técnica, son los siguientes:

• Sistema Distribuido. La aplicación a desarrollar será distribuida si varios módulos estarán en varios lugares.
• Objetivos de Comportamiento o tiempo de respuesta. Si es necesario que el sistema de una respuesta en un espacio de tiempo mínimo. Si es en un entorno Web, el cargado entre paginas no sea muy lento
• Eficacia del Usuario Final. El usuario debe tener varias caminos para realizar su trabajo incrementando su eficacia
• Procedimiento Interno Complejo. Si la codificación será compleja y requerirá de investigación para realizarla o para optimizarla
• El código debe ser reutilizable. Si varios módulos o componentes deben poder ser utilizados en otras aplicaciones
• Facilidad de Instalación. Si se debe crear inhaladores para la cómoda configuración de la aplicación
• Facilidad de uso. La aplicación debe ser fácil de aprender, recordar, visible, entendible, etc
• Portabilidad. La aplicación esta desarrollada para facilitar el traslado de la tecnología a otra.
• Facilidad de Cambio. La aplicación debe estar implementada de manera que sea fácil detectar defectos y realizar los cambios para eliminarlos.
• Concurrencia. Si la aplicación será utilizada por un conjunto de personas grande debe comportase de manera óptima
• Incluye objetivos especiales de seguridad. Si va a ser necesario implementar parte de la seguridad para los datos o el acceso a la aplicación.
• Provee acceso a terceras partes. Si la aplicación será utilizada por otras aplicaciones
• Se requiere facilidades especiales de entrenamiento a usuarios. Si se debe planificar un entrenamiento para que la aplicación sea utilizada.

Este coeficiente se calcula mediante la cuantificación de los factores explicados anteriormente, que determinan la complejidad técnica del sistema. Cada uno de los factores se cuantifica con un valor de 0 a 5, donde 0 significa un aporte irrelevante y 5 un aporte muy importante. En la siguiente tabla se muestra el significado y el peso de cada uno de éstos factores:

Factor	Descripción	Peso
T1	Sistema Distribuido	2
T2	Objetivos de Comportamiento o tiempo de respuesta	1
T3	Eficacia del Usuario Final	1
T4	Procedimiento Interno Complejo	1
T5	El código debe ser reutilizable	1
T6	Facilidad de instalación	0.5
T7	Facilidad de Uso	0.5
T8	Portabilidad	2
T9	Facilidad de Cambio	1
T10	Concurrencia	1
T11	Incluye objetos especiales de seguridad	1
T12	Provee Acceso directo a terceras partes	1
T13	Se requiere facilidades especiales de entrenamiento a usuarios	1

Tabla 3. Factores que influyen en la Complejidad Técnica

El Factor de Complejidad Técnico se calcula mediante la ecuación:

TCF = 0.6 + 0.01 * S(Peso_i * ValorAsignado_i)

Para nuestro ejemplo el Factor de Complejidad Técnica tendrá el valor:

Factor	Descripción	Peso	Comentario
T1	Sistema Distribuido	2	La aplicación utilizará varios Servicios Web
T2	Objetivos de Comportamiento o tiempo de respuesta	4	La aplicación debe proporcionar una alta rapidez de respuesta a los Cliente
T3	Eficacia del Usuario Final	4	Debe asegurarse que la aplicación proporcione una alta eficacia para los usuarios
T4	Procedimiento Interno Complejo	2	No muchos cálculos complejos
T5	El código debe ser reutilizable	5	El código debe ser reutilizable, los cual permita ser utilizado en otras aplicaciones
T6	Facilidad de instalación	2	Escasos requisitos de facilidad de instalación.
T7	Facilidad de Uso	5	Es muy necesario crear interfaz que sean fáciles de aprender, memorizar, que sean agradables y comprensibles.
T8	Portabilidad	2	Es necesario que sea compatible con los distintos navegadores Web existentes
T9	Facilidad de Cambio	1	Se debe garantizar la utilización de un estándar para la codificación
T10	Concurrencia	3	La concurrencia será relativamente fluida
T11	Incluye objetivos especiales de seguridad	2	Seguridad Baja
T12	Provee Acceso directo a terceras partes	1	Los Usuarios Web tienen acceso
T13	Se requiere facilidades especiales de entrenamiento a usuarios	1

TCF = 0.6 + 0.01 * (2*2 + 1*4 + 1*4 + 1*2 + 1*5 + 0.5*2 + 0.5*5 + 2*2 + 1*1 + 1*3 + 1*2 + 1*1 + 1*1)

TCF = 0.945

Otro factor importante que debe calcularse es el Factor Ambiente (EF). Este factor determinar las habilidades.

Y entrenamiento del grupo involucrado en el desarrollo tiene un gran impacto en la estimación de tiempo. El cálculo de este factor es similar al de Factor de Complejidad Técnica, se debe cuantificar con valores de 0 a 5.

La siguiente tabla muestra a los factores, la descripción y el peso.

Factor	Descripción	Peso
E1	Familiaridad con el modelo del proyecto utilizado	1.5
E2	Experiencia en la aplicación	0.5
E3	Experiencia en Teoría Orientado a Objetos	1
E4	Capacidad del Analista Líder	0.5
E5	Motivación de los involucrados en el desarrollo	1
E6	Estabilidad de los requisitos	2
E7	Personal Tiempo Parcial (Part-Time)	-1
E8	Dificultad del Lenguaje de Programación	-1

Tabla 4. Factores que influyen en el Ambiente

• Para los factores E1 al E4, un valor asignado de 0 significa sin experiencia, 3 experiencia media y 5 amplia experiencia (experto).
• Para el factor E5, 0 significa sin motivación para el proyecto, 3 motivación media y 5 alta motivación.
• Para el factor E6, 0 significa requisitos extremadamente inestables, 3 estabilidad media y 5 requisitos estables sin posibilidad de cambios.
• Para el factor E7, 0 significa que no hay personal tiempo parcial (es decir todos son tiempo completo), 3 significa mitad y mitad, y 5 significa que todo el personal es tiempo parcial (nadie es tiempo completo).
• Para el factor E8, 0 significa que el lenguaje de programación es fácil de usar, 3 medio y 5 que el lenguaje es extremadamente difícil.

El Factor Ambiente se debe calcular con la siguiente ecuación:

EF = 1.4 – 0.03 * ∑(Peso_i * Valor Asignado_i)

Ahora se calcula el factor ambiente para el ejemplo que se esta desarrollando

Factor	Descripción	Valor Asignado	Comentario
E1	Familiaridad con el Modelo del Proyecto utilizado	3	Esta Familiarizado con el Modelo
E2	Experiencia en la aplicación	4	Se ha trabajado desde el inicio de la aplicación
E3	Experiencia en Teoría Orientada a Objetos	5	Se tiene una fuerte preparación
E4	Capacidad del Analista Líder	3	El principiante pero tiene la especialidad
E5	Motivación de los involucrados en el Desarrollo	5	Se tiene una gran motivación para el desarrollo de la aplicación
E6	Estabilidad de los requisitos	2	Se esperan cambios
E7	Personal Tiempo Parcial (Part-Time)	0	La persona será la encargada de llevar el desarrollo hasta la finalización
E8	Dificultad del Lenguaje de Programación	3	Se usará el lenguaje C#

El valor del Factor Ambiente será:

EF = 1.4 – 0.03 (1.5*3 + 0.5*4 + 1*5 + 0.5*3 + 1*5 + 2*2 – 1*0 – 1*3)

EF = 0.83 (Factor Ambiente)

Se esta listo para calcular los Casos de Uso ajustados. Los dos factores anteriormente calculados ayudaran a ajustar los casos de uso.

UCP = UUCP x TCF x EF

UCP = 92 * 0.945 * 0.83

UCP = 72.16 (Puntos de Casos de Uso)

Con este último cálculo se podrá calcular el Esfuerzo.

Un investigador llamado Gustav Karner propuso, en el año 1993, que para cada Punto de Caso de Uso requiere 20 horas-hombre. Pero, en el transcurso del tiempo se ha perfeccionado al siguiente criterio:

• Se contabilizan cuántos factores de los que afectan al Factor de ambiente están por debajo del valor medio (3), para los factores E1 a E6.
• Se contabilizan cuántos factores de los que afectan al Factor de ambiente están por encima del valor medio (3), para los factores E7 y E8.
• Si el total es 2 o menos, se utiliza el factor de conversión 20 horas-hombre/Punto de Casos de Uso, es decir, un Punto de Caso de Uso toma 20 horas-hombre.
• Si el total es 3 o 4, se utiliza el factor de conversión 28 horas-hombre/Punto de Casos de Uso, es decir, un Punto de Caso de Uso toma 28 horas-hombre.
• Si el total es mayor o igual que 5, se recomienda efectuar cambios en el proyecto, ya que se considera que el riesgo de fracaso del mismo es demasiado alto.

Por esta teoría, se determina que cada Punto de Caso de Uso tendrá 20 horas-hombre para nuestro ejemplo de desarrollo.

Para calcular el esfuerzo se debe aplicar la siguiente ecuación:

E = UCP * CF

Donde:

E es el Esfuerzo

CF es Factor de Conversión

UCP es Casos de Uso Ajustados

El Factor de Conversión será 20 horas-hombre

Se debe tomar en cuanta que los cálculos hechos para estimar de esfuerzo solo pertenecen a la parte del ciclo de vida de la implementación o codificación. Para una estimación más completa de la duración total del proyecto, hay que agregar a la estimación del esfuerzo obtenida por los Puntos de Casos de Uso, las estimaciones de esfuerzo de las demás actividades relacionadas con el desarrollo de software. Para ello se puede tener en cuenta el siguiente criterio, que estadísticamente se considera aceptable. El criterio plantea la distribución del esfuerzo entre las diferentes actividades de un proyecto, según la siguiente aproximación:

Actividad	Porcentaje (%)
Análisis	10
Diseño	20
Programación	40
Prueba	15
Sobrecarga (otras actividades)	15

Tabla 5. Porcentajes que involucran el tiempo de desarrollo

Estos porcentajes pueden variase considerando la experiencia que se tenga en el desarrollo y se debe justificar la variación.

Para el ejemplo que se esta desarrollando el cálculo del esfuerzo será:

E = 72.16 * 20

E = 1443.204 Horas-Hombre

Si se toma en cuanta que se trabaja 8 horas diarias y 20 días al mes se tardaría en implementar esta aplicación 9 meses para una sola persona.

Para calcular el total del esfuerzo se debe calcular, por una regla de tres las otras fases.

Actividad	Porcentaje
Análisis	360.801
Diseño	721.602
Programación	1443.204
Prueba	541.2015
Sobre Carga (Otras Actividades)	541.2015
TOTAL	3608.01

Si se toma que se trabaja 8 horas al día y 20 días al mes el tiempo total para el desarrollo 22 meses. Bastante tiempo para una sola persona.

Pero si se trabaja en equipo, por lo menos cuatro personas que se encarguen de las primeras cuatro actividades, el tiempo de desarrollo seria de 5 meses.

Para calcular el costo de desarrollo se toma como parámetro el sueldo mínimo nacional que es de Bs.- 500. Esto significa que por hora se paga Bs.- 3. Si multiplicamos el total del esfuerzo por el valor por hora el resultado seria Bs.- 10824.03.

De esta forma se ha culminado la estimación del Esfuerzo, Costo y Tiempo. Como se puede entender es importante tener una experiencia alta para realizar la estimación del numero de transacciones por cada casos de uso, además de definir correctamente los pesos de los factores.

Un detalle que nos lleva a reflexionar es el monto del salario mínimo nacional utilizado en el cálculo anterior. Si se hace una estimacion solo se gana Bs.- 25 por día trabajado. Se gana menos que una persona que realiza actividades técnicas, ya que estas personas tienen un pago de Bs.- 50 por día. Siendo una actividad muy compleja el desarrollar software, como se ha descrito en estos documentos, no es posible que se gane por día Bs.- 25. Aunque muchos dirán que es fácil hoy en día, implementar software, pero surgen preguntas… ¿A qué costo? ¿A que Calidad? ¿Cuánto durará el Software? ¿La persona que ha desarrollado software se convertirá en un “activo fijo” en la organización? Es claro que surgen más preguntas, a las cuales se debe responder con claridad.

Una vez determinado el esfuerzo, tiempo y costo, podemos realizar una planificación de las actividades principales del desarrollo de software. Este curso no entra en detalles de la planificación de las actividades del Desarrollo de Software. Sin embargo, se muestra en los cuadros siguientes un ejemplo de planificación de un proyecto. No se debe olvidar que la planificación es un proceso que va desde la determinación de las actividades pasando por la definición de los riesgos hasta la gestión del proyecto.

EJEMPLO DE PLAN DE PROYECTO DE SOFTWARE

En el siguiente documento se determinan los requisitos no funcionales de la aplicación, los cuales serán los que hablen de la aplicación desarrollada.

Introducción al Modelo Relacional

Objetivo.

Estudiar el modelo relacional que permite diseñar una base de datos.

Definiciones del Modelo Relacional.

– Para el Móledo Relacional una afinidad es una tabla de dos dimensiones.

– El modelo relacional está conformado por tres componentes.

o Una estructura de datos.

§ Relación. Es una colección o grupo de objetos que tienen en común un conjunto de características o atributos.

§ Entidad (tabla). Es una unidad de datos en una relación con un conjunto finito de atributos. Consiste en n valores. El modelo relacional proporciona una manera simple de representar los datos. Es a través de, una tabla bidimensional llamada relación. Cada fila corresponde a un objeto y cada columna corresponde a un atributo de un objeto.

Nombre	FechaNacimiento	Dirección	País
Carlos	23/10/1972	Luja 1020	Bolivia
Rommel	14/08/1968	América	Chile

§ Atributo. También llamado característica, cada atributo de una tabla o relación tiene asociado un dominio en el cual toma sus valores. Los atributos son las columnas de una relación y describen las características particulares de estas.

§ Esquema. Es el nombre que se le da a una relación, más el nombre de los atributos. Persona(Nombre, FechaNacimiento, Dirección, País).

§ Tuplas. Se considera una tupla a cada una de la filas en una relación que contiene valores que corresponden a un objeto (Carlos, 23/10/1972, lujan 1020, Bolivia).

· En una relación no debe existir dos tuplas iguales.

· El orden de las filas no es significativo.

Si una Relación cumple con estas dos características se la denomina normalizada.

§ Dominio. Es un conjunto de valores que puede tomar un atributo en una tabla o relación.

Ejemplo: Alumno à Determinar la Relación, Entidad, Atributo y Dominio.

o Operadores.

§ Operadores de actualización.

· Agregar. Al insertar una tupla en una relación, el valor de un atributo que sea llave foránea puede ser nulo, o algún valor del atributo de la llave primaria en la relación correspondiente.

· Borrar. Se tiene una tupla en una relación R₁ con un atributo A_i como llave primaria, y otra relación R₂ que tiene ese mismo atributo Ai pero como llave foránea, se tiene tres casos.

o Borrado restringido. No se puede borrar la tupla en relación R1 cuya llave primaria tenga el valor en la relación R2.

o Borrado en Cascada. Al borrar una tupla en la relación R1 con cierto valor en la llave primaria, se borrarán todas las tuplas en R2 que tengan ese mismo valor en la llave foránea.

o Borrado por nulificacion. Al borrar una tupla en la relación R1, a todas las tuplas con el mismo valor en la relación R2 se les asigna un valor nulo en el atributo de la llave foránea.

· Cambiar (modificar).

o Modificación en cascada. Al modificar una llave primaria en R1 se le cambia los valores correspondientes en la llave foránea de R2.

o Modificación por nulificacion. Al cambiar los valores de la llave primaria en R1 a los correspondientes valores en la llave foránea de R2 se les pone un valor nulo.

§ Operadores del algebra relacional.

o Reglas de integridad.

§ Llave primaria. Es única en un conjunto de atributos que permite identificar a una tupla de manera única en cualquier momento.

§ Llave Foránea. Es un atributo que hace referencia a una llave primaria de otra tabla. Esto da que una tabla pueda tener varas llaves foráneas.

§ Valor Nulo. Es un valor que está fuera de la definición de cualquier dominio en el cual deja el valor del atributo en latente. Su uso es frecuente en las siguiente situaciones:

· Cuando no se conocen todos los valores de cada uno de los atributos.

· Cuando se agrega un atributo a una tabla ya existente.

· Para no tomarse en cuente al hacer cálculos numéricos.

§ Integridad de Tablas. Ningún atributo que forme parte de una llave primaria puede aceptar valores nulos.

§ Integridad Referencial. Al tener una Tabla Q con llave primaria A de dominio D y otra tabla R con atributo A que no es llave primaria de R, entonces cualquier valor en el atributo A en R debe ser:

· Nulo, o

· Un valor que esté en el atributo A de la llave primaria de una tupla en la tabla Q.

– Cada hilera en la tabla tiene datos que pertenecen a alguna cosa. Estas se denominan Tuplas o Tuples.

– El Modelo relacional está relacionado con el algebra y cálculo relacional.

Algebra relacional

– Es un lenguaje procedimental

– Define las operaciones usadas en los lenguajes de consultas relacionales.

– Operadores

o Primitivos. Pertenecen a la teoría de conjuntos.

§ Unión (È). Debe cumplir con los siguientes requisitos

· Las relaciones r y s deben tener el mismo número de atributos.

· Lso dominios del atributo i-ésimo de r y del atributo i-ésimo de s, deben ser los mismos.

§ Diferencia (-): Permite encontrar tuplas que estén en una relación, pero o en la otra.

§ Producto cartesiano (x): a partir de las tuplas de una relación r se forma una nueva relación con todas combinaciones resultantes de su relación con las tuplas de una relación s.

o Derivados

§ Combinación (join) |x|:

· Es una operación binaria que nos permite combinar ciertas selecciones y un producto cartesiano en una operación.

· Forma un producto cartesiano de sus dos argumentos realiza una realización forzando la igualdad en aquellos atributos que aparezcan en ambas planificaciones de relaciones y finalmente quita las columnas duplicadas.

· r êxês = P_rÈs (s_r.A1=s.A1Ç…Çs_r.An=s.AnRxS)

§ Intersección (Ç).

§ Dicisión (¸).

· Se establece para aquellas consultas que incluyen la frase “para todos”.

Cálculo Relacional.

– El cálculo relacional de tuplas y dominios es un lenguaje no procedimental que representan la capacidad básica requerida en un lenguaje de consulta relacional.

o Cálculo relacional de tuplas.

o Cálculo relacional de dominios.

¿Por qué el modelo relacional?

– Se considera al modelo Entidad- Relación como un modelo conceptual, no es ni lógico ni físico.

– El modelo relacional es un modelo lógico que se conoce como “esquema de base de datos”. A partir del cual, se podrá realizar el modelo físico.

Ventajas del modelo relacional

– Su simplicidad. Implica independencia de los datos.

– La información se maneja en forma de tablas.

– Creación. Anadir un producto P. se agrega la nueva ocurrencia en la tabla Producto. Es posible hacerlo aunque ningún suministrador lo suministre.

– Supresión. Se puede eliminar el suministrador S1 sin perder el producto P6, a pesar que es el único suministrador que lo suministra.

– Modificación. Se puede cambiar el precio del producto P2 sin necesidad de búsquedas adicionales ni posibilidad de inconsistencias.

Teoría de la normalización.

– El concepto de esta teoría de normalización fue introducido por E.D. Cood y fue pensada para aplicarse a sistemas relacionales.

– Se basa en la necesidad de encontrar una representación del conjunto de relaciones que en el proceso de actualización sea la más adecuada. Se basa en el proceso de llevar una relación a través de formas normales. Es decir, que una relación debe cumplir con las condiciones que implican las Formas Normales. Esto evita las anomalías en la actualización. Además, mejora la independencia de los datos.

– La Normalización (teoría de la normalización) involucra varias fases que se realizan en orden.

– Existen tres (1FN, 2FN, 3FN) formas normales, incluyendo a de Boyce-Codd (FNBC), cuarta (4FN) y quinta (5FN).

DIAGRAMA DE CASOS DE USO

DESARROLLO DE APLICACIONES WEB EN MICROSOFT C# .NET MODELADAS EN UML.

Modelo de casos de uso

Un Modelo de Casos de Uso es un modelo de las funciones deseadas de la aplicación y sus ambientes, y sirve como un contrato entre el cliente y los desarrolladores. Los casos de uso sirven como un hilo unificador a lo largo de desarrollo de la aplicación. El Modelo de Casos de Uso es el resultado del flujo de Requisitos y es usado como parte importante del Análisis, Diseño y de la Prueba.

Existen muchas maneras de modelar una aplicación, cada una puede servir para un propósito diferente. Sin embargo, el propósito más importante de un modelo de casos de uso es comunicar el comportamiento de la aplicación al cliente o usuario final. Por consiguiente, el modelo debe ser fácil de entender.

Los usuarios y cualquier otro sistema que pueden interactuar con la aplicación a desarrollar, serán considerados como actores, porque estos representan a los usuarios de la aplicación, los actores ayudan a delimitar la aplicación y dan un cuadro más claro de lo que se supone que debe hacer. Los casos de uso se desarrollan en base a las necesidades de los actores, esto asegura que la aplicación terminará siendo la solución que esperan los usuarios.

Cómo Evoluciona el Modelo de Casos de Uso

Los actores y los casos de uso son encontrados analizando las necesidades de los usuarios, el Modelo del Negocio (si es que se ha desarrollado) y los usuarios potenciales como información vital. Cuando los casos de uso son capturados, deben describirse de forma resumida (alto nivel) y los actores de igual forma. Antes de que los casos de uso se describan con todos los detalles necesarios para su completa comprensión, deben ser revisados por el cliente para verificar que se encuentran todos los casos de uso y actores, y que juntos pueden proporcionar lo que el cliente necesita.

Cuando se han encontrado los actores y casos de uso, el flujo de eventos de cada caso de uso se describe de forma detallada. Estas descripciones muestran cómo el sistema interactúa con los actores y lo que la aplicación hace en cada caso individual.

Finalmente, el Modelo de Casos de Uso terminado (incluyendo las descripciones de casos del uso) se revisa, los encargados de esta revisión son los diseñadores y clientes, ya que son los que usarán y los interesados, ellos deben de estar de acuerdo en lo que la aplicación hará.

Casos de Uso Concretos y Abstractos

Existe una diferencia entre un Caso de Uso Concretos y un Casos de Uso Abstractos. Un caso del uso concreto es iniciado por un actor y constituye un flujo completo de eventos. «Concreto» significa que un caso de caso realiza la operación de forma completa requerida por el actor.

Un caso del uso abstracto nunca es iniciado por si mismo, ni tampoco iniciado por un actor. Los casos de uso abstractos son “Incluido hacia”, “Extendido hacia”, o “Generalizado a”. Cuando un caso de uso concreto comienza, una instancia del caso de uso abstracto se crea.

La diferencia entre los dos es importante, porque en los casos de uso concretos los actores serán los que utilicen.

Existen cuatro tipos de relaciones o asociaciones (comunicación) en el diagrama de casos de uso, son las siguientes:

– Comunicación.Es una relación simple entre un actor y un caso de uso, como se puede ver en el ejemplo siguiente:

– Inclusión (Include). Si existe una parte de un caso de uso que representa una función que está en otro caso de uso, que sólo depende del resultado, pero no el método usado para producir el resultado, se puede crear esa parte fuera a un caso de uso que sea adicional. La adicción se inserta, explícitamente, en un caso de uso relacionado con el creado y se debe incluir en la relación “Incluir” o “Include”. Como se puede ver en el ejemplo siguiente:

– Extensión (Extend). Si existe una parte de un caso del uso concreto que es optativa, es decir que exista una condición lógica para su ejecución o no necesaria, se puede crear un nuevo caso de uso con la parte condicionada, esto ayuda a simplificar la estructura del caso de uso concreto. La adicción se relaciona, implícitamente, con el caso de uso concreto y el creado, se debe usar la relación “Extender” o “Extend”. Como se puede ver en el ejemplo siguiente:

– Herencia.Si hay casos del uso que tienen conducta en común, estructura y similitudes dentro de su propósito, las partes comunes pueden ser separadas en un caso de uso concreto (padre), el cual puede heredas a otros casos de uso adicionales (hijos). Los casos de uso de Hijos pueden insertar nuevas conductas y pueden modificar la conducta en la estructura que ellos heredan del caso de uso de padre.

Se puede usar la generalización de actores para mostrar cómo los casos de uso son especializaciones de otros entre si. Como se puede ver en el ejemplo siguiente:

Un caso de uso debe ser simple, inteligible, claro y conciso. Generalmente hay pocos actores asociados a cada Caso de Uso. Para encontrar algunos parámetros en la construcción de un caso de uso se debe realizar las siguientes preguntas:

– ¿Cuáles son las tareas del actor?

– ¿Qué información crea, guarda, modifica, destruye o lee el actor?

– ¿Debe el actor notificar a la aplicación los cambios externos?

– ¿Debe el sistema informar al actor de los cambios internos?

La flecha de comunicación define al actor que inicia el caso de uso esperando una respuesta. Una línea sin flecha asume una comunicación bidireccional, donde el caso de uso es el que manda una respuesta a un actor, para luego, el actor, realice una actividad que active al caso de uso, pero pude que el caso de uso solo informe, en este caso la flecha apuntaría al actor.

Un caso del uso puede comenzarse según una programación (por ejemplo, una vez a la semana o una vez al día), que significa que el reloj de la aplicación es el iniciador del caso de uso. Para la claridad del Diagrama de Casos de Uso, se debe utilizar un actor ficticio «Tiempo» para mostrar cómo el caso de uso se inicia.

Un aspecto, importante, para la organización y comprensión del modelo de casos de uso, es agrupar los casos del uso en paquetes. Un paquete es un mecanismo de propósito general para organizar elementos en grupos.

A continuación se realiza el Diagrama de Casos de Uso para la aplicación de Hotel.

Para iniciar se debe determinar a los actores y a los casos de uso.

En primer lugar se determina a los actores de la aplicación, son los siguientes:

Actor	Descripción
Recepcionista	Es la persona de atender al cliente en la reserva o confirmación de una habitación en el hotel, además de llevar el costo del consumo que el cliente realice mientras este hospedado en el hotel. Este actor podrá realizar actividades de reserva, confirmación y cierre de cuenta para el cliente.
Cliente	Es una persona que está interesada en reservar una habitación dentro del hotel. Este actor podrá solo realizar la actividad de reserva de habitación por medio de una interfaz
Jefe de Cocina	Es la persona encargada de registrar las solicitudes de servicio de los clientes ya sea a la habitación, donde se hospeda el cliente o en los servicios básicos que ofrece el hotel para el cliente como desayuno, almuerzo o cena. Este actor podrá realizar las actividades de registro de solicitudes
Administrador	Es la persona que se encarga de gestionar los permisos hacia la aplicación, las bebidas y las comidas. Este actor podrá realizar las actividades de crear, actualizar y eliminar comidas y bebidas para los servicios hacia el cliente, además de crear y modificar los permisos.

Existen dos métodos para la determinación de los casos de uso, son los siguientes:

– Método basado en Actores. En el método debe tomarse en cuenta que los actores estén relacionados en una aplicación o una empresa y que por cada actor se identifican los procesos que inician o en que participan.

– Método basado en Eventos. En el método debe identificarse a los eventos externos a los que la aplicación debe responder y se debe analizar si los actores se relacionan con los actores y con casos de uso.

Para el ejemplo utilizaremos el primer método.

Actor	Casos de Uso
Recepcionista	Reservar Habitación Confirmar Reserva Salir del Hotel Cambiar Contraseña Autenticar Empleado
Cliente	Reservar Habitación
Jefe de Cocina	Cambiar Contraseña Autenticar Empleado Registrar Solicitud de Servicio a la Habitación Registrar Solicitud de Servicio Básico
Administrador	Gestionar Empleados Gestionar Bebidas Gestionar Cocina

Como se puede observar, existen varios casos de uso que se repiten, lo que importa es identificar las actividades de cada actor, las cuales realizará con la aplicación.

Hay que señalar, que una ayuda para la determinación de los casos de uso son los Diagramas de Actividad que corresponden a los casos de uso del negocio. Se debe realizar un análisis de cada actividad dentro de los diagramas de actividad, debe preguntarse por cada actividad ¿se pede automatizar?, ya que muchas, no todas, de las actividades son verbales o llegan a una solución sin generar una información persistente. Otras situaciones que influyen en la decisión de automatizar, es la economía y la disponibilidad de los clientes y usuarios, ya que la tecnología será un limitante para el desarrollo del software, como también la disponibilidad de la inversión en dinero. Para el ejemplo, se propone una interfaz Web, para realizar una reserva de habitación, ya sean los actores Cliente o Recepcionista podrán realizar la reserva de una habitación, pero puede cambiar la política y decir que solo el Recepcionista es el encargado de realizar la reserva de la habitación, en este caso puede que no sea necesario el desarrollo de una interfaz Web para realizar esta actividad.

Una vez identificados todos los casos de uso, que representa la solución a las necesidades de los usuarios se debe crear el Diagrama de Casos de Uso.

A continuación se crea el Diagrama de Casos de Uso en el Rational Rose. La creación es similar al Diagrama de Casos de Uso del Negocio.

Iniciemos la creación del Diagrama de Casos de Uso. Como se puede ver en la Pantalla 1, la ubicación dentro del Rational Rose será Use-Case Model (Modelo de Caso de Uso).

Pantalla 1. Ubicación para la creación del Modelo de Casos de Uso

La carpeta de Use-Case Model esta conformada por dos subcarpetas que son: Actors y Use Case (Actores y Casos de Uso), dentro de estas colocaremos, respectivamente, a los actores que se han determinado y a los casos de uso que se han captado de la aplicación de ejemplo. Como se puede ver en la Pantalla 2, las subcarpetas tienen una estructura para documentar la aplicación, muestra donde se tiene que colocar a los actores y como crear los casos de uso. Dentro de la carpeta Use Cases se encuentran dos subcarpetas con el nombre de Use Case Name e Included Use Cases. La primera subcarpeta nos indica que por casa caso de uso se debe crear una carpeta y dentro de esta, recién, el caso de uso. La segunda subcarpeta, Included Use Cases, es para los casos de uso que tienen una relación con otro caso de uso de tipo “Include”. De igual forma que los casos de uso concretos, por cada caso de uso incluido debe existir una carpeta y dentro de esta el caso de uso.

Pantalla2. Plantilla para el Modelo de Casos de Uso

El primer paso es crear a los actores de la aplicación, para esto se debe realizar un clic derecho en la carpeta Actors, se visualizará un menú emergente, ya conocido, se debe seleccionar la opción New, la cual desplegará un submenu, la opción que se debe seleccionar es Actor, sobre la cual se debe realizar un clic como se puede ver en la Pantalla 3.

Pantalla 3. Crear un Actor de la aplicación

El resultado será la Pantalla 4, donde se debe cambiar el nombre del actor por uno que sea significativo para la aplicación.

Pantalla 4. Resultado de la Creación de un Actor

En la Pantalla 5 se ve al primer actor creado

Pantalla 5. Primer Actor Creado

Para los siguientes actores deben realizarse las operaciones anteriormente descritas. El resultado de la creación de los actores se puede observar en la Pantalla 6.

Pantalla 6. Resultado de la creación de los Actores de la Aplicación

Luego de crear a los actores resta crear a los casos de uso, es similar al proceso de creación de los casos de uso de negocio. No debe olvidarse que por cada caso de uso debe existir una carpeta como se puede ver en la plantilla seleccionada al inicio de cada proyecto. Para crear un caso de uso se debe realizar un clic derecho en la carpeta Use Cases, esta actividad desplegará un menú emergente como se puede ver en la Pantalla 7, debe seleccionarse la opción New y luego Package, esta última permite crear una carpeta a la cual se debe cambiar el nombre.

Pantalla 7. Crear una Carpeta para el caso de uso

Como se dijo anteriormente, se debe cambiar el nombre a la carpeta, en este caso el nombre del primer caso de uso que se ha captado, que es: Reservar Habitación. El resultado de esta actividad se puede ver en la Pantalla 8.

Pantalla 8. Cambio de Nombre de una Carpeta

Queda crear el caso de uso, para esto se debe realizar un clic derecho en la carpeta Reservar Habitación, aparecerá un menú emergente del cual se debe seleccionar la opción New y Use Case, como se puede ver en la Pantalla 9.

Pantalla 9. Crear un Caso de Uso

Una vez realizada la actividad, resta cambiar de nombre al caso de uso creado, en este caso será Reservar Habitación. El resultado de esta actividad se puede ver en la Pantalla 10.

Pantalla 10. Creación del caso de uso Reservar Habitación

Para crear los otros casos de uso se debe realizar los pasos anteriormente descritos, el resultado se puede ver en la Pantalla 11. Se crea una carpeta por cada caso de uso, debido a que un caso de uso puede ser descrito ya sea por medio de un diagrama de actividad o de forma literal e incluso por medio de un diagrama de secuencia, diagrama de clases o un diagrama de estado. Estas descripciones están en función de las políticas de la empresa o el grupo de desarrollo, por este motivo RUP aconseja que por cada caso de uso se deba crear una carpeta.

Pantalla 11. Resultado de crear los casos de Uso

Para este ejemplo de aplicación de Hotel, no se adiciona ningún otro estereotipo por caso de uso, solo se hará una descripción de forma literal.

El paso final es crear el Diagrama de Casos de Uso, para realizar esta actividad se debe realizar un clic derecho en la carpeta Use-Case Model, aparecerá un menú emergente del cual se debe seleccionar la opción de New y Use Case Diagram. Como se puede observar en la Pantalla 12.

Pantalla 12. Crear un Diagrama de Casos de Uso

El siguiente paso es cambiar de nombre, el nombre debe ser “Vista del Diagrama de Casos de Uso”, como se puede ver en la Pantalla 13.

Pantalla 13. Cambio de nombre al Diagrama

Una vez realizada la actividad se debe realizar doble clic en el diagrama, en la parte derecha de Rational Rose se visualizará una plantilla, en la cual se debe crear el Diagrama de Casos de Uso. Para crear el diagrama de casos de uso solo se debe arrastrar los actores y los casos de uso creados. El resultado se puede ver en Pantalla 14.

Pantalla 14. Casos de Uso y Actores en la Plantilla del Diagrama de Casos de Uso

La actividad final es identificar las relaciones (comunicación) que existe entre los actores y los casos de uso, para esto se debe utilizar el botón con el nombre de Unidireccional Association , se debe hacer un clic, ya sea en el actor o en el caso de uso, y arrastrar hasta el esteriotipo donde se piense que se tiene una relación. El resultado de esta actividad se puede ver en la Pantalla 15.

Pantalla 15. Vista de Diagrama de Casos de Uso

En la Vista del Diagrama de Casos de Uso se puede utilizar el concepto de Generalización para los actores, ya que varios de estos utilizan un mismo caso de uso, se recomienda, para la mejor comprensión del diagrama y para el futuro del Diagrama de Clases, que solo un actor sea el que inicia un caso de uso. En la Pantalla 16 se puede observar la utilización de la Generalización para los actores.

Pantalla 16. Utilización del Concepto de Generalización en Actores de la Aplicación

Para utilizar la Generalización en los actores se debe utilizar el botón Generalization , la operación para determinar la relación es similar a la de actor con un caso de uso.

De esta forma se ha creado el Modelo de Casos de Uso, en los próximos documentos se indica como describir los casos de uso, de forma tal que representen la interacción entre el actor y la aplicación.

Los próximos documentos son muy importantes, ya que son temas muy interesantes y darán una visión diferente, ya sea, para la documentación como en la planificación en un proyecto de desarrollo de software.