Carrera: Ingeniería de Sistemas

Asignatura: Ingeniería de Software I

Unidad IV - Modelado de Software - Principios que
Guían la Práctica.

TRABAJO CORRESPONDIENTE A LOS ESTUDIANTES:

1) Giovana Guadalupe Marachi Baez

2) Alexis Javier Sanabria Gaona

3) Ana Cecilia Barreto Jara

GUÍA DE ESTUDIO N° 5

Fecha de entrega:

02/09/2022.Puntos: 10

Luego de la lectura el libro PRESSMAN, Roger S. “INGENIERÍA DEL SOFTWARE: UN

ENFOQUEPRÁCTICO”. 7ma Edición, realizar:

Contesto

1. Hablar sobre la serie de lineamientos informales que ayudarán a su

identificación yrepresentación de las clases:

5.1 Identificación de las clases de análisis

Al mirar una habitación, se observa un conjunto de objetos físicos que se identifican,

clasifican y definen fácilmente (en términos de atributos y operaciones). Pero cuando se
“ve” el espacio del problema de una aplicación de software, las clases (y objetos) son más
difíciles de concebir.
Se comienza por identificar las clases mediante el análisis de los escenarios de uso
desarrollados como parte del modelo de requerimientos y la ejecución de un “análisis
gramatical” sobre los casos de uso desarrollados para el sistema que se va a construir. Las
clases se determinan subrayando cada sustantivo o frase que las incluya para introducirlo
en una tabla simple. Deben anotarse los sinónimos. Si la clase (sustantivo) se requiere para
implementar una solución, entonces forma parte del espacio de solución; de otro modo, si
sólo es necesaria para describir la solución, es parte del espacio del problema.

Las clases de análisis se manifiestan en uno de los modos siguientes:

• Entidades externas (por ejemplo, otros sistemas, dispositivos y personas) que producen
o consumen la información que usará un sistema basado en computadora.

• Cosas (reportes, pantallas, cartas, señales, etc.) que forman parte del dominio de
información para el problema.

• Ocurrencias o eventos (como una transferencia de propiedad o la ejecución de una serie

de movimientos de un robot) que suceden dentro del contexto de la operación del
sistema.

• Roles (gerente, ingeniero, vendedor, etc.) que desempeñan las personas que interactúan
con el sistema.

• Unidades organizacionales (división, grupo, equipo, etc.) que son relevantes para una
aplicación.

• Lugares (piso de manufactura o plataforma de carga) que establecen el contexto del

problema y la función general del sistema.

• Estructuras (sensores, vehículos de cuatro ruedas, computadoras, etc.) que definen una
clase de objetos o clases relacionadas de éstos.

5.2 Especificación de atributos

Para desarrollar un conjunto de atributos significativos para una clase de análisis, debe
estudiarse cada caso de uso y seleccionar aquellas “cosas” que “pertenezcan”
razonablemente a la clase. Además, debe responderse la pregunta siguiente para cada
clase: “¿qué aspectos de los datos (compuestos o elementales) definen por completo esta
clase en el contexto del problema en cuestión?”
Cada uno de los datos a la derecha del signo igual podría definirse más, hasta un nivel
elemental, pero para nuestros propósitos constituye una lista razonable de atributos para
la clase Sistema. Los sensores forman parte del sistema general CasaSegura, pero no están
enlistados como datos o atributos en la figura 6.9. Sensor ya se definió como clase, y se
asociarán múltiples objetos Sensor con la clase Sistema. En general, se evita definir algo
como atributo si más de uno va a asociarse con la clase.

5.3 Definición de las operaciones

Las operaciones definen el comportamiento de un objeto. Aunque existen muchos tipos

distintos de operaciones, por lo general se dividen en cuatro categorías principales: 1)
operaciones que manipulan datos en cierta manera (por ejemplo, los agregan, eliminan,
editan, seleccionan, etc.), 2) operaciones que realizan un cálculo, 3) operaciones que
preguntan sobre el estado de un objeto y 4) operaciones que vigilan un objeto en cuanto a
la ocurrencia de un evento de control. Estas funciones se llevan a cabo con operaciones
sobre los atributos o sobre asociaciones de éstos. Por tanto, una operación debe tener
“conocimiento” de la naturaleza de los atributos y de las asociaciones de la clase. Como
primera iteración al obtener un conjunto de operaciones para una clase de análisis, se
estudia otra vez una narración del procesamiento (o caso de uso) y se eligen aquellas que
pertenezcan razonablemente a la clase.

Para lograr esto, de nuevo se efectúa el análisis gramatical y se aíslan los verbos. Algunos
de éstos serán operaciones legítimas y se conectarán con facilidad a una clase específica.
Por ejemplo, de la narración del procesamiento de CasaSegura ya presentada en este
capítulo, se observa que “se asigna a sensor un número y tipo” o “se programa un
password maestro para activar y desactivar el sistema” indican cierto número de cosas:

• Que una operación asignar( ) es relevante para la clase Sensor.

• Que se aplicará una operación programar( ) a la clase Sistema.

• Que activar( ) y desactivar( ) son operaciones que se aplican a la clase Sistema.

5.4 Modelado clase-responsabilidad-colaborador (CRC)

El modelado clase-responsabilidad-colaborador (CRC) [Wir90] proporciona una manera

sencilla de identificación y organización de las clases que son relevantes para los
requerimientos de un sistema o producto. Ambler [Amb95] describe el modelado CRC en
la siguiente forma:
 Un modelo CRC en realidad es un conjunto de tarjetas índice estándar que representan
clases. Las tarjetas se dividen en tres secciones. En la parte superior de la tarjeta se escribe
el nombre de la clase, en la parte izquierda del cuerpo se enlistan las responsabilidades de
la clase y en la derecha, los colaboradores.

5.5 Asociaciones y dependencias

En muchos casos, dos clases de análisis se relacionan de cierto modo con otra, en forma
muy parecida a como dos objetos de datos se relacionan entre sí. En UML, estas relaciones
se llaman asociaciones. En ciertos casos, una asociación puede definirse con más detalle si
se indica multiplicidad.

En tales casos, una clase cliente depende de algún modo de la clase servidor, y se
establece una relación de dependencia. Las dependencias están definidas por un
estereotipo. Un estereotipo es un “mecanismo extensible” [Arl02] dentro del UML que
permite definir un elemento especial de modelado con semántica y especialización
determinadas. En UML, los estereotipos se representan entre paréntesis dobles angulares
(por ejemplo, <<estereotipo>>).

5.6 Paquetes de análisis

. Una parte importante del modelado del análisis es la categorización. Es decir, se clasifican
distintos elementos del modelo de análisis (por ejemplo, casos de uso y clases de análisis) de
manera que se agrupen en un paquete —llamado paquete de análisis— al que se da un
nombre representativo. El signo más (suma) que precede al nombre de la clase de análisis en
cada paquete, indica que las clases tienen visibilidad pública, por lo que son accesibles desde
otros paquetes. También hay otros símbolos que preceden a un elemento dentro de un
paquete.

El signo menos (resta) indica que un elemento queda oculto desde todos los demás paquetes.
Y el símbolo # señala que un elemento es accesible sólo para los paquetes contenidos dentro
de un paquete dado.
 PUNTAJE (2 PUNTOS CADA
INDICADORES DE EVALUACIÓN
ÍTEM)

1 - Posee los conceptos, características y conocimientos generales

del contenido, utilizando vocabulario técnico.

2 - Demuestra secuencia y estructura lógica en la presentación de

su trabajo.

3 - Expresa ideas claras, redacta de forma apropiada contenidos

técnicos.

4 - Reconoce los contenidos mínimos requeridos en la asignatura.

5. Desarrollo ordenado y coherencia en la exposición.

TOTAL PUNTAJE OBTENIDO