BIBLIOTECA

Una biblioteca necesita disponer de una base de datos para llevar la gestión de sus
préstamos.

La base de datos deberá almacenar los siguientes datos sobre los lectores:

Un identificador de lector, su nombre, ciudad en la que vive, tipo de libros que le

gustan leer y el número de habitantes de su ciudad (para elaborar posibles
estadísticas). Por su parte, sobre los libros de la biblioteca se debe registrar el
código del libro, título, tipo de libro (drama, comedia, terror, romántico,
aventuras, biografía, etc.) y lo más importante, la biblioteca debe conocer en todo
momento que libro esta prestado y a quien, así como la fecha de realización y
devolución del préstamo
onclusiones Específicas
● En el levantamiento de requerimientos funcionales, por medio del uso de
instrumentos de recolección de información se obtuvo el paso para un posterior
análisis y depuración que se dio de manera conjunta con los usuarios finales del
SIB. Se logró converger a un punto en común como lo son las funciones
principales del sistema, las cuales fueron entregadas y socializadas en las
juntas de planificación de requisitos al equipo de trabajo conformado por los
usuarios finales (administradores y operativos de la biblioteca) y
desarrolladores, pactando así los términos base del desarrollo del sistema.

En cuanto a la fase de diseño se realizó el entregable de los diferentes

diagramas en base al Modelo de Vistas de Arquitectura 4+1, que permitieron
tanto a los usuarios finales como también a los desarrolladores, de manera
gráfica, el comprender el funcionamiento final del SIB. De igual manera en esta
fase se crearon, revisaron y aceptaron los mockups de la interfaz gráfica del
sistema, dando como resultado una interfaz intuitiva y amigable a los diferentes
roles de usuarios finales.
● Y en lo que respecta a la fase de construcción y la fase de implementación, el
sistema de información bibliotecario (SIB) fue desarrollado en base al patrón de

"Métricas Técnicas para Sistemas Orientados a Objetos"

del libro de Roger Pressman. (2006). Ingenieria del Software: Un Enfoque Práctico.
McGraw-Hill.

Este informe tiene que contener los siguientes puntos:

Hoja de presentación, con portada referente al tema

Indice
Introducción
contenido (resumen en sí, de 15 páginas)

Las métricas para los sistemas OO se enfocan en mediciones que pueden aplicarse a
las ca#racterísticas de clase y de diseño (localización, encapsulación,
ocultamiento de información,
herencia y técnicas de abstracción de objeto) que hacen única a la clase. La suite
de métricas
CK define seis métricas de software orientado a clase que se enfocan en la clase y
en la jerarquía
de clase. La suite de métricas también desarrolla métricas para valorar las
colaboraciones entre
clases y la cohesión en métodos que residen dentro de una clase. En un nivel
orientado a clase,
la suite de métricas CK puede aumentarse con las métricas propuestas por Lorenz y
Kidd y con la
suite de métricas MOOD.

Métricas para diseño orientado a objetos

Hay mucho de subjetivo en el diseño orientado a objetos: un diseñador experimentado
“sabe”
cómo caracterizar un sistema OO de modo que implemente de manera efectiva los
requerimien#tos del cliente. Pero, conforme un modelo de diseño OO crece en tamaño
y complejidad, una
visión más objetiva de las características del diseño puede beneficiar tanto al
diseñador experi#mentado (quien adquiere comprensión adicional) como al novato
(quien obtiene un indicio de
la calidad que de otro modo no tendría disponible).
En un tratamiento detallado de las métricas de software para sistemas OO, Whitmire
[Whi97]
describe nueve características distintas y mensurables de un diseño OO:
Cita:
“La medición puede verse como
una desviación. Ésta es necesa#ria porque los humanos
básicamente no son capaces de
tomar decisiones claras y objeti#vas [sin apoyo cuantitativo]”.
Horst Zuse
23Pressman(526-552).indd 537 19/1/10 23:29:55
www.FreeLibros.me538 PARTE TRES ADMINISTRACIÓN DE LA CALIDAD
Tamaño. El tamaño se define en función de cuatro visiones: población, volumen,
longitud
y funcionalidad. La población se mide al realizar un conteo estático de entidades
OO, tales
como clases u operaciones. Las medidas de volumen son idénticas a las medidas de
pobla#ción, pero se recolectan de manera dinámica: en un instante de tiempo
determinado. La
longitud es una medida de una cadena de elementos de diseño interconectados (por
ejem#plo, la profundidad de un árbol de herencia es una medida de longitud). Las
métricas de
funcionalidad proporcionan un indicio indirecto del valor entregado al cliente por
una apli#cación OO.
Complejidad. Como el tamaño, existen muchas visiones diferentes de la complejidad
del
software [Zus97]. Whitmire ve la complejidad en términos de características
estructurales al
examinar cómo se relacionan mutuamente las clases de un diseño OO.
Acoplamiento. Las conexiones físicas entre elementos del diseño OO (por ejemplo, el
nú#mero de colaboraciones entre clases o el de mensajes que pasan entre los
objetos) repre#sentan el acoplamiento dentro de un sistema OO.
Suficiencia. Whitmire define suficiencia como “el grado en el que una abstracción
posee
las características requeridas de él o en el que un componente de diseño posee
característi#cas en su abstracción, desde el punto de vista de la aplicación
actual”. Dicho de otra forma,
se pregunta: “¿Qué propiedades debe poseer esta abstracción (clase) para serme
útil?”
[Whi97]. En esencia, un componente de diseño (por ejemplo, una clase) es suficiente
si re#fleja por completo todas las propiedades del objeto de dominio de aplicación
que se mo#dela, es decir, si la abstracción (clase) posee sus características
requeridas.
Completitud. La única diferencia entre completitud y suficiencia es “el conjunto de
carac#terísticas contra las cuales se compara la abstracción o el componente de
diseño” [Whi97].
La suficiencia compara la abstracción desde el punto de vista de la aplicación
actual. La
completitud considera múltiples puntos de vista, y plantea la pregunta: “¿qué
propiedades
se requieren para representar por completo al objeto de dominio problema?”. Puesto
que el
criterio para completitud considera diferentes puntos de vista, tiene una
implicación indi#recta en el grado en el que puede reutilizarse la abstracción o el
componente de diseño.
Cohesión. Como su contraparte en software convencional, un componente OO debe
dise#ñarse de manera que tenga todas las operaciones funcionando en conjunto para
lograr un
solo propósito bien definido. La cohesividad de una clase se determina al examinar
el
grado en el que “el conjunto de propiedades que posee es parte del problema o
dominio de
diseño” [Whi97].
Primitivismo. Una característica que es similar a la simplicidad, el primitivismo
(aplicado
tanto a operaciones como a clases), es el grado en el que una operación es atómica,
es de#cir, la operación no puede construirse a partir de una secuencia de otras
operaciones con#tenidas dentro de una clase. Una clase que muestra un alto grado de
primitivismo encap#sula sólo operaciones primitivas.
Similitud. El grado en el que dos o más clases son similares en términos de su
estructura,
función, comportamiento o propósito se indica mediante esta medida.
Volatilidad. Como se menciona muchas veces en este libro, los cambios en el diseño
pue#den ocurrir cuando se modifican los requerimientos o cuando ocurren
modificaciones en
otras partes de una aplicación, lo que da como resultado la adaptación obligatoria
del com#ponente de diseño en cuestión. La volatilidad de un componente de diseño OO
mide la pro#babilidad de que ocurrirá un cambio.
En realidad, las métricas de producto para sistemas OO pueden aplicarse no sólo al
modelo de
diseño, sino también al de requerimientos. En las siguientes secciones se estudian
las métricas
¿Qué características
pueden medirse cuando
se valora un diseño
OO?
?
Cita:
“Muchas de las decisiones en las
cuales tuve que confiar en el
folclore y el mito, ahora se pue#den resolver haciendo uso de
datos cuantitativos.”
Scott Whitmire
23Pressman(526-552).indd 538 19/1/10 23:29:55
www.FreeLibros.meCAPÍTULO 23 MÉTRICAS DE PRODUCTO 539
que proporcionan un indicio de la calidad en el nivel de clase OO y en el de
operación. Además,
también se exploran las métricas aplicables a la administración del proyecto y a
las pruebas.

Conclusión
Bibligrafía
El documento debe ser guardado con el siguiente formato:
Apellido_Nombre_Unidad4Informe.
Valor 2 puntos. !No lo pierdas!

Para enviar:

Hacer clic en seleccionar archivo, se abre un cuadro de dialogo/ventana para que

busques el archivo que deseas subir, lo seleccionas, luego pulsas abrir y por
último subir este archivo.

¡Adelante!

Su tutora

Disponible en: Monday, 29 de March de 2021, 22:38