Ingenieria de Software

Orientada a Objetos

Ing. Diana Minda Gilces, M.Sc.

diana.mindag@ug.edu.ec
CISC – Universidad de Guayaquil
 Sistemas vs. Modelos

 Sistemas = REALIDAD
 Modelos = ABSTRACCION

 Distribuidor de boletos
(Sistema)
 Planos para distribuidor
(Modelo)
 Ingeniería de Software:
Actividad de Resolución de Problemas

 Análisis:
 Comprender la naturaleza del problema y
descomponerlo en pequeñas partes.
 Síntesis:
 Juntar todas las partes en una sola
estructura.
Para la resolución de problemas, usamos
técnicas, metodologías y herramientas.
 Técnicas, Metodologías y
Herramientas
Técnicas
Procedimientos formales para producir
resultados usando una notación bien definida.
Metodologías
Colección de técnicas aplicadasa a lo largo de el
desarrollo de software, unificados por la misma
filosofía.
Herramientas
Instrumentos o sistemas autónomos necesarios
para desarrollar una técnica.
CASE = Computer Aided Software Engineering
 Ingeniería de Software: Definición
Colección de técnicas, metodologías y
herramientas que ayudan en la producción
de:
Un Software de alta calidad desarrollado
con un presupuesto específico antes de
una fecha tope, mientras se administran
cambios.

Desafío: Lidiar con la complejidad y

el cambio.
20
 ACTIVIDAD 1
 Cual es el propósito del modelado?
 Liste 2 ventajas y 2 desventajas del uso de
un lenguaje de programación como notación
única a lo largo del proceso de desarrollo.
 Considere una tarea con la que no este
familiarizado. Cómo podría atacar el
problema?
 Diseño de un automóvil con cero emisiones de
contaminantes.
 Establezca la diferencia entre la
programación y la Ingeniería de Software.
Conceptos de
Orientación a
Objetos
 Indice
 Que es modelado?
 Tipo de datos Clases, clases
abstractas y objetos
 Relaciones entre Objetos

 Eventos y Mensajes Modelado

Orientado a Objetos
 Modelado
 Describir un Sistema en un nivel
alto de abstracción.
 Plantilla para el sistema

 Utilizado para requerimientos y

especificaciones.

 Es necesario modelar software?

Modelado Orientado a Objetos
 Tipos de datos
 Abstracción en el contexto de
lenguaje de programación.
 Nombre único que lo distingue con
respecto a otros.
 Aseguran que sólo se apliquen
operaciones válidas.
 Clase
 Encapsula estructura y
comportamiento.
 Define operaciones y atributos de sus
instancias.
 Pueden ser definidas por otras clases
usando la generalización.
 Clase reloj

Subclase RelojCalculadora
Generalización
 Clase Abstracta
 Generalización que NO se instancia.
 Sirve solo propósitos de modelado.
 Introducidas para reducir la complejidad en el
modelo.
 Ejemplo: CompuestoQuimico
 Objeto
 Instanciade una clase.
 Tiene una identidad

 Almacena valores de atributo.

 Eventos y Mensajes
 Clases de evento : representan un tipo de
evento para el cual el sistema tiene una
respuesta común.
 Envío de mensaje entre dos objetos.
 “Oprime el botón izquierdo”
 “Después de 2 minutos”

Mensaje: Mecanismo por el cual el objeto

solicita ejecución de una operación.
Compuesto por nombre y argumentos.
 Que es UML?
 Lenguaje Unificado de Modelado.
 Lenguaje gráfico estándar de la industria
para:
 especificar, visualizar, construir y
documentar los elementos de
software.
 Notaciones gráficas para expresar el análisis
y diseño de proyectos de software.
 Simplifica el proceso complejo de diseño de
software.
Modelado Orientado a Objetos

 Objetos y llamadas a Métodos

 Interfaces

 Notación UML

 Relaciones entre objetos

 Llamadas a Métodos
elmer.areCoprimes( Prime factorization:
905, 1988 905 = 5  181
) 1988 = 2  2  7  71

Result:
YES!

Stu Elmer
Factorizacion en primos de 905:
5181 (2 distintos factores)
Factorizacion en primos de 1988:
22771 (4 factors, 3 distintos)
Dos enteros son coprimos s entre si si no tienen otro factor comun ademas
del 1 o si su mayor comun divisor es 1. No se pueden simplificar.
 Los Objetos NO aceptan llamadas
arbitrarias.
Llamadas aceptables se definen mediante métodos de
objeto.
(también conocidas como Operaciones, Procedimientos, Subrutinas, Funciones)

Objeto: Método-3:
Método-1: Métodos-2: Selección
Cajero Automático
Aceptar Tarjeta Leer clave
1234
5678
12345

1
4 2
7 5 3
8 6
0 9
 Interfaz de Objetos
Define que métodos deben ser implementados por
una clase.
“Firma del método: nombre, parámetros, tipo de dato que regresa
Interfaz
Metodo-1 Objeto esconde
su estado
Metodo-2 (atributos). Los
atributos son
accesibles solo
Metodo-3 a través de la
interfaz.
 Clientes, Servidores,
Mensajes
Client
Client Object
Object Server
Server
Object
Object

Message

• Los objetos envían mensajes llamando a los métodos.

• Objeto cliente: Envía mensajes y requieren un servicio.

• Objeto Servidor: Provee servicios y retorna resultados.

Objetos == Módulos
Módulo de Software

Inputs State Outputs

(e.g., force) (represented by (e.g., force)
state variables,
e.g.,
momentum,
mass, size, …)
 Funciones versus Objetos
Funciones: agrupaciones sueltas de subprogramas y datos.
“Acceso no
autorizado a datos,
Subprograms resulta en uso
(behavior) indebido.

Data
(state)

Software Module 1 Software Module 2 Software Module 3

Objetos encapsulan datos

Atributos
Metodos
/datos
(Comportamiento)
(estado)

Objeto Software 1 Objeto Software 2 Objeto Software 3

 Notación UML para Clases
Implementación Interfaz de Software
Clase Software

nombreClase «interface»
InterfazBase
# atributo_1 : int
Tres compartimientos:
# atributo_2 : boolean + operacion()
1. Nombre Clasificador # atributo_3 : String
2. Atributos

3. Operaciones + operacion_1() : void

Clase1Implementa Clase2Implementa
+ operacion_2() : String
+ operacion() + operacion()
+ operacion_3(arg1 : int)
nombreObjeto
Relacion de Herencia :
# atributo_1: 15
# atributo__2:TRUE Interfaz Base es
Implementada por dos clases.

+ contestar()
 EJERCICIO 1

1. Detallar la clase Numero_de_Cuenta mediante

la notacion UML.

(Incluir al menos 2 atributos y 3 operaciones)

 EJERCICIO 2

1. Emplear la notación UML para especificar la

clase celular.

2. Instancie un objeto de la clase celular.

Imaginemos que diseñamos un Sistema para una

tienda que vende y repara equipos celulares.

3. Aplique la relación de Generalización para

construir dos clases más necesarias para el
análisis de este sistema.
Clase Celular
Instanciar Objeto
Generalización
 Diagrama de Clases
 Describen estructura y comportamiento en
los casos de uso.
 Proveen un modelo conceptual del sistema
en términos de sus entidades y sus
relaciones.
 Captura de requerimientos,
interacción con el usuario final.
 Diagramas muy detallados sirven también
para el desarrollo de sistemas.
 Representación de Clases
 Rectángulo subdivido en tres compartimientos
 Nombre

 Atributos

 Operaciones

 Modificadores indican la visibilidad de los

atributos y operaciones.
 ‘+’ denotan visibilidad Pública (todos)

 ‘#’ denotan visibilidad Protegida (derivados)

 ‘-’ denotan visibilidad Privada (nadie)

 Por defecto todos los atributos están ocultos y
las operaciones visibles.
 Numero_de_Cuenta

Nombre
Numero_de_Cuenta
- Nombre_cliente
Atributos
- Balance
+Depositar( ) Operaciones
+Retirar( )
+Transferir( )
DIAGRAMAS DE CLASE
(Continuación)
Un modelo es una
simplificación de
la realidad.
 MODELADO
 Comunicar la estructura de un
sistema complejo.
 Especificar el comportamiento
deseado del sistema.
 Compresión del sistema que
estamos construyendo.
 Descubrir oportunidades de
simplificación y reutilización.
El modelo ha de
capturar lo
esencial.
 Modelos Estructurales
(Organización del Sistema)
 Modelos de comportamiento

(Dinámica del sistema)

 Diagramas de clases
proporcionan una perspectiva
estática del Sistema.

 (Diseño Estructural)
 Esquema
 Clases y/u objetos intervinientes

 Relación entre:

 Objetos

 Entorno

Diseñar el Sistema en un lenguaje de

programación Orientado a Objetos.
easyUML

Análisis y Diseño de Sistemas

 Visualización a partir de clases y sus
vínculos.
 Interacción de objetos con su entorno.
 Relaciones entre Objetos

 2 tipos de Relaciones
 Generalización (padre-hijo)
 Asociación (estudiante se registra en un
curso)
 Asociaciones se subdividen en
 Agregación
 Composición
 Clase
Generalizacion

Avion

SubClase1 SubClase2

- Expresa una relación Avion Comercial Avion Militar

padre/hijo entre
clases. Avion

- Elementos comunes
- Abstraer detalles en
algunas capas Avion Comercial Avion Militar
 Asociación

 Representa la relación entre instancias de

las clases.
 Estudiante se registra en un curso.
 Los cursos tienen estudiantes.
 Los cursos tienen exámenes.
 Etc.
 Association:
 Multiplicidad (Un curso muchos estudiantes)
 Navegabilidad (unidireccional, bidireccional)
 Asociacion: Multiplicidad

estudiantes
1 *

Universidad Persona

0..1 *
empleados profesores
 Asociacion: Multiplicidad

Simbolo Significado
1 Uno solamente
0..1 Cero o Uno
M..N De M a N
* Desde 0 a culaquier entero positivo
0..* Desde 0 a culaquier entero positivo
1..* Desde 1 a culaquier entero positivo
 EJERCICIO 3
 Una biblioteca tiene copias de libros. Estos
ultimos se caracterizan por su nombre,
tipo (novela, teatro, poesia, ensayo),
editorial, año y autor.
 Los autores se caracterizan por su
nombre, nacionalidad y fecha de
nacimiento.
 AGREGACIÓN
Clase Contenedora
Class C
Relación especifica
AGREGACION
Contenedor – Contenido
Class E1 Class E2
Expresa una relación donde
una instancia de la clase
Clases Contenidas
contenedora tiene la
responsabilidad de tener y
Canasta Supermercado
mantener instancias de la clase
contenida que se han creado
fuera de los auspicios de la
Manzanas Arroz clase contenedora.
 AGREGACIÓN
Relación especifica
Contenedor – Contenido
Empleada para expresar una relación más informal que
la que expresa la composición.
Esto es, una relación apropiada donde el contenedor y
los contenidos pueden ser manipulados de manera
independiente.
Es apropiada cuando el contenedor y los contenidos no
tienen privilegios / accesos especiales entre cada uno .
 Agregación vs. Composición

•Composición forma de la agregación

•Componentes tienen solamente un dueño .
•Componentes no pueden existir independientes el
uno del otro.
•Componentes “viven o mueren” con su dueño
e.j. Cada carro tiene un motor que no puede se
compartido con otra carro.

•Agregaciones pueden formar parte del agregado, pero

no pueden ser esencial para estos.
•Pueden existir de manera independiente al agregado.
 REFERENCIAS

 Bruegge, Dutoit. Ingenieria de Software

Orientado a Objetos, 4ta. Edicion. Prentice
Hall, Mexico, 2012.