1. INGENIERÌA DE SOFTWARE I

2. El Lenguaje de Modelamiento Unificado
(UML - Unified Modeling Language) es un
lenguaje gráfico para visualizar, especificar y
documentar cada una de las partes que
comprende el desarrollo de software.

4. CLASE
Es la unidad básica que encapsula toda
la información de un Objeto (un objeto es
una instancia de una clase). A través de ella
podemos modelar el entorno en estudio
(una Casa, un Auto, una Cuenta
Corriente, etc.).

5. En UML, una clase es representada por
un rectángulo que posee tres divisiones:
Superior: Contiene el nombre de la Clase
Intermedio: Contiene los atributos (o variables
de instancia) que caracterizan a la Clase
(pueden ser private, protected o public).
Inferior: Contiene los métodos u operaciones,
los cuales son la forma como interactúa el
objeto con su entorno (dependiendo de la
visibilidad: private, protected o public).

6. Objeto: es una cosa, generalmente extraída del
vocabulario del espacio del problema o del
espacio de la solución.
Atributo: Es una característica concreta de una
clase.
Método: Es una operación concreta de una
determinada clase.
Instancia: Es una manifestación concreta de
una clase

7. ATRIBUTOS Y MÉTODOS
 Atributos: Los atributos o características de una Clase pueden
ser de tres tipos, los que definen el grado de comunicación y
visibilidad de ellos con el entorno, estos son:
◦ public (+, ): Indica que el atributo será visible tanto
dentro como fuera de la clase, es decir, es accesesible
desde todos lados.
◦ private (-, ): Indica que el atributo sólo será accesible
desde dentro de la clase (sólo sus métodos lo pueden
accesar).
◦ protected (#, ): Indica que el atributo no será accesible
desde fuera de la clase, pero si podrá ser accesado por
métodos de la clase además de las subclases que se
deriven (ver herencia).

8. ATRIBUTOS Y MÉTODOS
 Métodos: Los métodos u operaciones de una clase son la forma
en como ésta interactúa con su entorno, éstos pueden tener las
características:
◦ public (+, ): Indica que el método será visible tanto
dentro como fuera de la clase, es decir, es accsesible
desde todos lados.
◦ private (-, ): Indica que el método sólo será accesible
desde dentro de la clase (sólo otros métodos de la clase
lo pueden accesar).
◦ protected (#, ): Indica que el método no será accesible
desde fuera de la clase, pero si podrá ser accesado por
métodos de la clase además de métodos de las
subclases que se deriven (ver herencia).

9. RELACIONES ENTRE CLASES
 Ahora ya definido el concepto de Clase, es
necesario explicar como se pueden
interrelacionar dos o más clases (cada uno
con características y objetivos diferentes).
 Antes es necesario explicar el concepto de
cardinalidad de relaciones: En UML, la
cardinalidad de las relaciones indica el grado
y nivel de dependencia, se anotan en cada
extremo de la relación y éstas pueden ser:
uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
número fijo: m (m denota el número).

10. Indica que una subclase hereda los métodos y
atributos especificados por una Super
Clase, por ende la Subclase además de poseer
sus propios métodos y atributos, poseerá las
características y atributos visibles de la Super
Clase (public y protected)

11. Para modelar objetos complejos, no
bastan los tipos de datos básicos que
proveen los lenguajes: enteros, reales y
secuencias de caracteres. Cuando se requiere
componer objetos que son instancias de
clases definidas por el desarrollador de la
aplicación, tenemos dos posibilidades

12.  Por Valor: Es un tipo de relación estática, en
donde el tiempo de vida del objeto incluido
esta condicionado por el tiempo de vida del
que lo incluye. Este tipo de relación es
comúnmente llamada Composición (el Objeto
base se construye a partir del objeto
incluido, es decir, es "parte/todo").

13.  Por Referencia: Es un tipo de relación
dinámica, en donde el tiempo de vida del
objeto incluido es independiente del que lo
incluye. Este tipo de relación es comúnmente
llamada Agregación (el objeto base utiliza al
incluido para su funcionamiento).

14. Ejemplo:
En donde se destaca que:
•Un Almacén posee Clientes y Cuentas (los rombos van en el
objeto que posee las referencias).
•Cuando se destruye el Objeto Almacén también son
destruidos los objetos Cuenta asociados, en cambio no son
afectados los objetos Cliente asociados.
•La composición (por Valor) se destaca por un rombo relleno.
•La agregación (por Referencia) se destaca por un rombo
transparente.
•La flecha en este tipo de relación indica la navegabilidad del
objeto referenciado. Cuando no existe este tipo de
particularidad la flecha se elimina.

15. La relación entre clases conocida como
Asociación, permite asociar objetos que
colaboran entre si. Cabe destacar que no es
una relación fuerte, es decir, el tiempo de
vida de un objeto no depende del otro.
Ejemplo
Un cliente puede tener asociadas muchas
Ordenes de Compra, en cambio una orden de
compra solo puede tener asociado un cliente.

16.  Representa un tipo de relación muy
particular, en la que una clase es
instanciada (su instanciación es
dependiente de otro objeto/clase). Se
denota por una flecha punteada.
 El uso más particular de este tipo de
relación es para denotar la dependencia que
tiene una clase de otra

17. Ejemplo:
Cabe destacar que el objeto creado (en este caso la
Ventana gráfica) no se almacena dentro del objeto que lo
crea (en este caso la Aplicación).

18. Estos métodos establecieron los fundamentos
para la notación moderna de DOO.
El método de Rumbaugh.
El diseño de sistema se centra en el esquema
de los componentes que se necesitan para
construir un sistema o producto completo.

19. El modelo de análisis se divide en
subsistemas, los cuales se asignan a
procesadores y tareas.
 Se define una estrategia para implementar la
administración de datos.
 Se identifican los recursos y mecanismos de
control requeridos para accesarlos.
 El diseño de objetos enfatiza el esquema
detallado de un objeto individual.
 Se seleccionan las operaciones del modelo de
análisis, y los algoritmos se definen para cada
operación

20.  Se representan las estructuras de datos
apropiadas para atributos y algoritmos.
 Las clases y atributos de clase son diseñados
de manera que se optimice el acceso a los
datos, y se mejore la eficiencia
computacional.

21. Es una versión simplificada del método
propietario Objectory, también desarrollado
por Jacobson.
 En principio, el modelo idealizado de análisis
se adapta para acoplarse al ambiente del
mundo real.
 Después los objetos de diseño
primarios, llamados bloques’, son creados y
catalogados como bloques de
interfaz, bloques de entidades y bloques de
control

22.  La comunicación entre bloques durante la
ejecución se define y los bloques se
organizan en subsistemas.

23.  La orientacion a objetos es tan iportante para
el diseño de software que el OMG (Grupo de
Administracion de Objetos), una coorporacion
no lucrativa que establece las normas para el
desarrollo orientado a objetos, predice que
los ingresos obtenidos por el software
orientado a objetos seran de 3 millardos de
dolares en los siguientes tres a cinco años.

24.  El UML influye en esto permitirle generar
modelos de objetos faciles de usar y
comprender para que los desarrolladores
puedan convertirlos en software.

25.  Es una descripción de un conjunto de objetos
similares.
 Una clase es una descripción de un conjunto
de objetos que comparten los mismos
atributos, operaciones, relaciones y
semántica.
 Una clase puede representarse de forma
esquemática (plegada), con los detalles como
atributos y operaciones suprimidos, siendo
entonces tan solo un rectángulo con el
nombre de la clase

26.  Gráficamente se representa como un
rectángulo que incluye su nombre, sus
atributos y sus operaciones
VENTANA
ORIGEN
TAMAÑO
ABRIR
CERRAR
MOVER
DIBUJAR

27.  Una clase activa es igual que una clase,
excepto que sus objetos representan
elementos cuyo comportamiento es
concurrente con otros elementos.
 Se representa igual que una clase pero con
líneas más gruesas
GESTOR DE EVENTOS
SUSPENDER ()
VACIAR COLA ()

28.  Los objetos concretos y virtuales, están a
nuestro alrededor, ellos conforman nuestro
mundo.
 Un objeto es la instancia de una clase
(categoría).
 Cuenta con una estructura, es decir atributos
(propiedades) y acciones.
 Las acciones son todas las actividades que el
objeto es capaz de realizar .
 Los atributos y acciones, en conjunto se
conocen como características o rasgos.

29.  Asociación:
Es el tipo de relación más básica que indica la
invocación desde un actor o caso de uso a otra
operación (caso de uso). Dicha relación se denota
con una flecha simple .
 Se le puede añadir un pequeño rectángulo negro
que indique la dirección de la asociación.

30.  Dependencia o Instanciación
Es una forma muy particular de relación
entre clases, en la cual una clase depende de
otra, es decir, se instancia (se crea). Dicha
relación se denota con una flecha punteada.

31.  Generalización
Este tipo de relación esta orientado exclusivamente para
casos de uso (y no para actores). Los casos de uso pueden
tener relaciones con otros casos de uso.
 Los tipos de relaciones más comunes entre casos de uso
son:
◦ <<include>> que especifica una situación en la que un caso de
uso tiene lugar dentro de otro caso de uso
◦ <<extends>> que especifica que en ciertas situaciones, o en
algún punto (llamado punto de extensión) un caso de uso será
extendido por otro.
Generalización que especifica que un caso de uso hereda
las características del «super» caso de uso, y puede volver
a especificar algunas o todas ellas de una forma muy
similar a las herencias entre clases.

32.  Un sistema de bases de datos es básicamente
un sistema computarizado para llevar
registros. Es posible considerar a la propia
base de datos como una especie de armario
electrónico para archivar.
 El DBMS es, por mucho, el componente de
software más importante del sistema en gene
ral, aunque no es el único

33. Los sistemas relaciónales están basados en una
teoría formal denominada el modelo de datos
relacional, de acuerdo con el la cual:
 En tablas, los datos son representados por
medio de filas y estas filas pueden interpretarse
directamente como proposiciones verdaderas.
 Se proporcionan operadores para operar sobre
las columnas de las tablas, y estos operadores
soportan directamente el proceso de inferir
proposiciones verdaderas adicionales a partir de
las ya dadas

34.  la respuesta a estas preguntas depende de si
el sistema en cuestión es de un solo usuario
o multi-usuario.

35.  Compactación: No hay necesidad de archivos en
papel voluminosos.
 Velocidad: La máquina puede recuperar y
actualizar datos más rápidamente que un
humano. En particular, las consultas específicas
sin mucha elaboración .
 Menos trabajo laborioso; Se puede eliminar gran
parte del trabajo de llevar los archivos a mano.
 Actualidad: En el momento que la
necesitemos, tendremos a nuestra disposición
informa-ción precisa y actualizada

36.  Los datos pueden compartirse
 Es posible reducir la redundancia
 Es posible (hasta cierto grado) evitar la
inconsistencia
 Es posible brindar un manejo de
transacciones
 Es posible mantener la integridad
 Es posible hacer cumplir la seguridad
 Es posible hacer cumplir los estándares

38. Introducción
El diagrama de casos de uso representa la
forma en como un Cliente (Actor) opera con el
sistema en desarrollo, además de la forma, tipo y
orden en como los elementos interactúan
(operaciones o casos de uso).
Un diagrama de casos de uso consta de los
siguientes elementos:
 Actor.
 Casos de Uso.
 Relaciones de Uso, Herencia y Comunicación.

39. Cuando se trabaja con casos de uso, es
importante tener presentes algunas sencillas
reglas:
◦ Cada caso de uso está relacionado como mínimo
con un actor
◦ Cada caso de uso es un iniciador (es decir, un
actor)
◦ Cada caso de uso lleva a un resultado relevante
(un resultado con «valor intrínseco»)

40. Una definición previa, es que un Actor es
un rol que un usuario juega con respecto al
sistema. Es importante destacar el uso de la
palabra rol, pues con esto se especifica que
un Actor no necesariamente representa a una
persona en particular, sino más bien la labor
que realiza frente al sistema.
Esto significa que cuando una
persona interactúa con el sistema de
diferentes maneras (asumiendo
diferentes papeles), estará
representado por varios actores.

41. Como ejemplo a la definición
anterior, tenemos el caso de un sistema de
ventas en que el rol de Vendedor con
respecto al sistema puede ser realizado por
un Vendedor o bien por el Jefe de Local.
Un caso de uso describe, —desde
el punto de vista de los actores—
, un grupo de actividades de un
sistema que produce un resultado
concreto y tangible.
Jefe de Local Vendedor

42. Es una operación/tarea específica que se
realiza tras una orden de algún agente
externo, sea desde una petición de un actor o
bien desde la invocación desde otro caso de
uso.
Los casos de uso son descriptores de
las interacciones típicas entre los
usuarios de un sistema y ese mismo
sistema. Representan el interfaz
externo del sistema y especifican qué
requisitos de funcionamiento debe
tener este (recuerde, únicamente el
qué, nunca el cómo).

43. Como una primera aproximación identificamos a
los actores que interactúan con el sistema:
Luego, tenemos que un Cliente puede Depositar
Ítems y un Operador puede cambiar la información
de un ítem o bien puede Imprimir un informe:

44. Además podemos notar que un ítem puede ser
una Botella, un Tarro o una Jaba.
Otro aspecto es la impresión de
comprobantes, que puede ser
realizada después de depositar
algún ítem por un cliente o bien
puede ser realizada a petición de
un operador.

45. Entonces, el diseño completo del diagrama Use Case es: