© 2007 Microsoft Corporation.
Términos orientados a objetos
Objeto. Entidad provista de un conjunto de propiedades
o atributos (datos) y de comportamiento o funcionalidad
(“métodos”). Corresponden a los objetos reales del
mundo que nos rodea, o a objetos internos del sistema
(del programa).
Clase: Es la descripción de un conjunto de objetos que
comparten los mismos atributos, operaciones , relaciones
y semántica.
Términos orientados a objetos
Método: algoritmo asociado a un objeto ( o a una
clase de objetos), cuya ejecución se desencadena
tras la recepción de un “mensaje”.
Evento: un suceso en el sistema (tal como una
interacción del usuario con la máquina, o un
mensaje enviado por un objeto). El sistema
maneja el evento enviado el mensaje adecuado al
objeto pertinente.
Términos orientados a objetos
 Mensaje: una comunicación dirigida a un objeto, que le
ordena que ejecute uno de sus métodos con ciertos
parámetros asociados al evento que lo generó.
 Propiedad o atributo: contenedor de un tipo de datos
asociados a un objeto (o a una clase de objetos), que
hace los datos visibles desde fuera de un objeto, y cuyo
valor puede ser alterado por la ejecución de algún
método.
Ejemplo de una clase
Foco
Encender ()
Apagar()
Características de TOO
 Encapsulamiento: también llamado “ocultación de la
información “.cada objeto esta aislado del exterior, es un
módulo natural, y cada tipo de objeto expone una
interfaz a otros objetos que especifica cómo pueden
interactuar con los objetos de la clase.
Características de TOO
 Polimorfismo: comportamientos diferentes ,
asociados a objetos distintos, pueden compartir el
mismo nombre, al llamarlos por ese nombre se
utilizará el comportamiento correspondiente al
objeto que se esté usando.
 Herencia: los objetos heredan las propiedades y
el comportamiento de todas las clases a las que
pertenecen. La herencia organiza y facilita el
polimorfismo y el encapsulamiento permitiendo a
los objetos ser definidos y creados como tipos
especializados de objetos preexistentes.
Ejemplo de polimorfismo
operaciones
suma (int x, int y)
Suma (double x, double y)
Suma (char x, char y)
Ejemplo de herencia
Forma
Dibujar ()
Borrar ()
Obtienecolor ()
Poncolor ()
Circulo
Rectángulo
Cuadrado
Práctica
 Para el siguiente ejercicio, hacer la jerarquía de
clases, agregando métodos y atributos a las
siguientes clases.
Cursos
Escuela
Estudiante
Ingeniería de software
Proceso .- es una secuencia de pasos para
alcanzar un propósito específico.
Personas
Procedimientos
Herramientas
Proceso .- es lo que las personas hacen, usando
procedimientos, métodos, herramientas, y equipo
para transformar un material en un producto.
Ingeniería de software
Proceso de desarrollo de SW es un conjunto de
actividades, métodos, prácticas y
transformaciones que las personas emplean para
desarrollar y mantener software y productos
asociados tales como planes de proyecto,
documentos de diseño, código, casos de prueba,
manuales de usuarios, etc..
Modelos de desarrollo de SW
 Línea Secuencial (Cascada)
 Análisis de requerimientos
 Diseño
 Implementación
 Pruebas y mantenimiento
 Modelo en espiral
 Comunicación con el cliente
 Planificación
 Análisis de riesgos
 Diseño
 Construcción y adaptación
 Evaluación
Ejemplos de otros procesos de
desarrollo de SW
RUP
eXtreme Programming (XP)
Microsoft Solution Framework
Rational Unified Process (RUP)
Consta de 4 fases
Inicio
Elaboración
Construcción
Transmisión
Extreme Programing (XP)
 Esta metodología se basa en:
Pruebas Unitarias
Refabricación
Programación de pares
 Propuestas de XP
Empieza en pequeño y añade funcionalidad con
retroalimentación continua.
El manejo del cambio se convierte en parte sustantiva
del proceso
El costo del cambio no depende de la fase o etapa
No introduce funcionalidades antes que sean necesarias
El cliente o el usuario se convierte en miembro del
equipo
XP Extreme Programming
La metodología XP (Extreme programing) tiene
el propósito de desarrollar un software en un
corto tiempo, utilizando las etapas que se cree
son las mas importantes, empezando con los
requerimientos y posteriormente la
diagramación, utilizando la metodología UML. Al
momento de utilizar la diagramación UML
puedes realizar solo algunos de los diagramas
como lo son los diagramas de casos de uso,
diagrama de clases y diagrama de
implementación.
Microsoft Solution Framework (MSF)
Tiene las siguientes características:
Adaptable
Escalable
Flexible
Tecnología agnóstica
Se compone de varios modelos:
Modelo de Arquitectura del Proyecto
Modelo de Equipo
Modelo de Proceso
Modelo de Gestión del Riesgo
Modelo de Diseño del Proceso
Modelo de Aplicación
Modelo Visual
Modelar.- Es una manera efectiva de administrar
la complejidad del desarrollo de SW.
Un modelo sirve como una abstracción, una
representación aproximadamente del mundo real
que se quiere construir.
Porque modelar
El dominio del problema es bien conocido
La solución es relativamente fácil de construir
Muy pocas personas colaboran en la
construcción de la solución
La solución requiere mantenimiento mínimo
Es poco probable que haya requerimientos
posteriores
En que casos modelar
Complejidad
Riesgos
Los participantes iniciales en la solución de la
construcción no siempre completan la tarea
Modelar un Sistema
Provee a los arquitectos e involucrados en el
proyecto:
La habilidad de visualizar el sistema completo
Evaluar diferentes opciones
Comunicar el diseño de una manera más clara
antes de iniciar con el proyecto
Evaluar riesgos técnicos, financieros y de
construcción
Modelar un Sistema
Permite que los desarrolladores:
Tengan un mejor entendimiento de lo que van a
construir
Puedan crear y comunicar los diseños de SW
antes de comprometer recursos adicionales
Puedan agregar requerimientos al sistema
Asegurar que los que están construyendo es lo
que el usuario espera
Arquitectura basada en modelos
Nuevo enfoque originado por Object Management
Group para el desarrollo de SW
Separar el diseño de la arquitectura y de las
tecnologías de construcción
Diseño: Requerimientos funcionales
Tecnologías de construcción: Requerimientos no
funcionales
Especificar la arquitectura a un nivel de mayor detalle
incluyendo tecnologías de la capa de presentación, de la
capa de negocio, de persistencia o tecnología de mapeo
o de persistencia
Los métodos de análisis y diseño
¿Qué es un método?
Un método define un sistema reproducible para
obtener resultados fiables. Todos los ámbitos del
conocimiento utilizan métodos mas o menos
sofisticados y mas o menos formalizados. Los cocineros
hablan de recetas de cocina, los pilotos realizan checklist antes de despegar. Los arquitectos dibujan planos y
los músicos siguen reglas de composición.
Asimismo, un método de elaboración de programas
describe cómo modelar y construir sistemas de
programas de manera fiable y reproducible.
Los métodos de análisis y diseño
¿Qué es un método?
De manera general, los métodos permiten
construir modelos a partir de elementos de
modelado que constituyen los conceptos
fundamentales para la representación de sistemas
o fenómenos. Las notas escritas sobre las
partituras son elementos de modelado para la
música. La aproximación orientada a objetos
propone el equivalente de las notas – los objetos –
para la representación de los programas.
Los métodos de análisis y diseño
¿Qué es un método?
Los métodos definen también una representación – a
menudo gráfica – que permite, por una parte, manipular
fácilmente los modelos y, por otra, comunicar e
intercambiar la información entre los diferentes
interlocutores. Una buena representación busca el
equilibrio entre la densidad de información y la legibilidad
Además de los elementos de modelado y de sus
representaciones gráficas, un método define reglas de
implementación que describen la articulación de los
diferentes puntos de vista, el encadenamiento de las
acciones, la ordenación de las tareas y el reparto de las
responsabilidades.
Principales etapas de la definición de UML
En desarrollo 2004…)
UML 2.0
Adaptación oficial 2003
UML 1.5
Estandarización por el OMG
Sumisión al OMG- enero 97
UML 1.0
Especificación disponible
en Internet
Versión Beta OOPSLA 96
www – junio 96
UML 0.9
Especificación disponible
en Internet
OOPSLA 95
Método unificado 0.8
Juego de
documentación
Booch 93
OMT-2
Comentarios
Otros métodos
Booch 91
OMT -1
OOSE
Colaboradores
Modelo de casos de uso
Flujos de evento
Actores
Un actor representa una persona, hardware o
sistema externo que interactúa con el sistema.
En UML un actor es representado de la siguiente
manera:
actor
Ejemplo:
Cliente
Cliente
comercial
Generalización
Casos de uso
Un caso de usos especifica el comportamiento de
un sistema o una parte de un sistema y es una
descripción de una secuencia de acciones
incluyendo las variantes que un sistema desarrolla
para ofrecer un resultado observable a un actor.
El objetivo de un caso de uso es definir el
comportamiento de un sistema.
Un caso de uso es representado de la siguiente
manera:
Nombre
Casos de uso (continuación)
Los casos de uso deben de tener un nombre que
permita distinguir entre un caso de uso y otro.
Se recomienda que los casos de uso sean
cortos, verbos y que indiquen el comportamiento
del sistema que se está modelando.
Nombre simple
Valida usuario
Registra pedido
Diagramas de Casos de uso
Un diagrama de casos de uso es uno de los
diagramas en UML para modelar la funcionalidad
del sistema
Muestra un conjunto de casos de uso, actores y
sus relaciones.
Son utilizados para modelar la vista del sistema.
Modelando el contexto del sistema
Modelando los requerimientos del sistema.
Diagramas de Casos de uso
(Modelando el contexto del sistema)
Sistema de validación de
tarjetas de crédito
Ejecuta transacción
Institución de
autoservicio
Cliente
Administra cuenta
Cliente
individual
Cliente
corporativo
Institución
financiera
Paquetes de Casos de uso
En UML el paquete es un mecanismo de
propósito general para organizar los elementos del
modelado de grupos.
Reglas de negocio
Flujos de eventos
Documentación de un caso de uso
Flujos primarios y alternos
Análisis de casos de uso
Flujos primarios y alternos
El flujo de eventos se utiliza para especificar el
comportamiento de un caso de uso, indicando
como y cuando inicia y termina.
Administración
de
Registra
pedido
pedidos
Realización
<<include>> y <<extend>> generalización.
El primero indica que el Caso de Uso requiere
de usar otro caso de uso para poder ser
llevado a cabo. Esta es una forma muy
adecuada de sacar factor común entre Casos
de Uso, o incluso de fraccionar Casos de Uso
muy grandes.
El segundo indica que un Caso de Uso es una
variación de otro caso de uso. Observamos
también que “Comer pan” y “Beber cafe” son
una generalización de “Alimentarse”.
Ejemplo ( Generalización, Include, Extend)
Registra
<<Extended>>
pedido especial
pedido
<<Include>>
Valida
contraseña
Seguimiento
de pedidos
Registra
<<Include>>
Valida
usuario
Escanea
retina
Ejemplo (Diagrama de Casos de uso)
Registra
Registra
llamada
conferencia
Red de
teléfonos
celulares
Recibe
llamada
Recibe
Llamadas
adicionales
Agenda de
Usuario
usuario
Teléfono celular
Análisis de casos de uso
Identificar los actores
Organizar los actores
Para cada actor, considerar la forma principal en
que interactúa con el elemento
Considerar excepciones
Organizar el comportamiento en casos de uso
(aplicando include y extend)
Ejemplo
Cobros
Registra
pedido
<<Include>>
Seguimiento
<<Include>>
de pedidos
Valida
cliente
<<Include>>
Entrega
pedido
<<Extended>>
Entrega
pedido
especial
Documentación de caso de uso
La documentación de los casos de uso puede ser
realizada de la siguiente manera
Documentando los escenarios a través de
texto
Mediante colaboración y organizando los
casos de uso
Documentación de caso de uso
Casos de uso
Caso de uso: Reporte
Numero del caso de uso: 3
Actores :
Propósito:
Resumen:
Tipo: Primario y esencial
Referencias cruzadas:
Curso normal de los eventos
Acción del actor
Respuesta del sistema
Requerimientos
Caso de estudio: punto de venta
Supongamos como caso de estudio el sistema de
una terminal de punto de venta. Esta terminal es
un sistema automatizado con el que se registran
las ventas y se realizan los pagos.
Por lo general este tipo de sistemas comprenden
hardware (un computador y un lector de código de
barra) y software (el sistema que se ejecuta en la
terminal)
Requerimientos
a) Panorama general
Este proyecto tiene por objeto crear un sistema de
terminal para el punto de venta que se utilizara en las
ventas de un supermercado.
b) Metas
En términos generales, la meta es una mayor
automatización del pago en las cajas registradoras, y dar
soporte a servicios mas rápidos, mas baratos y mejores.
Concretamente, la meta incluye:
 Pago rápido de los clientes.
 Análisis rápido y exacto de las ventas.
 Control automático del inventario.
Requerimientos
c) Funciones del sistema
Las funciones del sistema son lo que este deberá
de hacer:
Las funciones pueden clasificarse en tres
categorías: evidentes, ocultas y superfluas. Las
evidentes deben de realizarse, y el usuario debe de
saber que se han realizado. Las ocultas también
deben realizarse, y puede que no sean visibles para
el usuario. Las superfluas son opcionales, y su
inclusión no repercute significativamente en el costo
ni en otras funciones.
Requerimientos
Estas son algunas de las funciones del sistema de punto de venta:
Ref.
R1.1
R1.2
R1.3
R1.4
R1.5
R1.6
R1.7
R1.8
R1.9
Función
Registra la venta en proceso (actual): los productos
comprados.
Calcula el total de la venta actual, se incluye el impuesto.
Captura la información sobre el objeto comprado usando su
código de barras, o usando una captura manual del código de
producto.
Reduce las cantidades del inventario cuando se realiza una
venta.
Se registran las ventas efectuadas.
El cajero debe de introducir una identificación y una
contraseña para poder utilizar el sistema.
Ofrece un mecanismo de almacenamiento persistente.
Ofrece mecanismos de comunicación entre los procesos y
entre los sistemas.
Muestra la descripción y el precio del producto registrado.
Categoría
Casos de uso
Diagrama UML de casos de uso para el sistema de punto de
venta:
Punto de venta
Compra productos
Cajero
Registra los datos
Cliente
Entrega el cambio de los
productos comprados
Este esquema tiene por objeto ofrecer un diagrama contextual
que nos permita conocer rápidamente los actores externos de
un sistema y las formas básicas en que estos lo utilizan.
Casos de uso
Un diagrama de
casos de uso
más refinado
seria el siguiente:
Punto de venta
Compra productos
Cajero
Registra los datos
Cliente
Entrega el cambio de los
productos comprados
Inicia
termina
Administra a
los usuarios
Adm. Del
sistema
Gerente
Práctica
Sistema de control escolar.
Inscripción
Alta de materias
Lista de profesores
Sistema de inscripciones
Reportes
Reporte de calificaciones
Cardex
Boletas de calificaciones
7. Diagrama de clases
Diagrama de clases




Clases
Operaciones
Relaciones de herencia, agregación y dependencia
Multiplicidad
Clases


“Es la descripción de un conjunto de objetos que
comparten los mismos atributos, operaciones, relaciones y
semántica.”
“Describe un conjunto de objetos que tienen
características y comportamiento idéntico. “
Atributos


Es un componente de información que el objeto conoce de
si mismo.
Elementos de un atributo.

Visibilidad

Nombre del atributo

Tipo de dato

Valor por defecto
Operaciones


Una operación es la implementación de un servicio del
cual puede ser solicitado por cualquier objeto de la clase
para afectar su comportamiento.
Elementos de una operación:

Nombre de operación

Argumentos

Tipo de dato a regresar.

Visibilidad
Visibilidad

Es el adjetivo que se le asigna a las operaciones o
atributos de una clase y especifica cuando puede ser
usado por otras clases.

Public.- El método o atributo puede ser utilizado por
cualquier clase(+).

Protected.- El método o atributo puede ser utilizado por
cualquier descendiente de la clase (#).

Private.- El método o atributo puede ser utilizado solo
por la misma clase(-).
Ejemplo:
Toolbar
Protected
Public
Private
# CurrentSelection: Tool
# ToolCourt: Integer
+ pickItem (i: integer)
+ addTool (t: Tool)
+ removeTool: (i: integer)
+ getTool () : Tool
# checkOrphans ()
- Compact ()
Relaciones de Herencia y asociación


La asociación es una relación que indica la comunicación
que existe entre dos clases.
La herencia es representada con una relación de
generalización entre clases (una clase base y subclases).
Ejemplo
Window
Open()
close()
move()
display()
Generalización
ConsoleWindow
DialogBox
Control
Asociación
Multiplicidad

La Multiplicidad se utiliza para indicar cuantos objetos
pueden estar conectados a través de una relación de
asociación.
Multiplicidad
Persona
1.. *
Empleado
1
Empleador
Asociación
Compañía
Tipos de clases



Abstracta: Son clases que no tienen instancias de forma directa,
en UML es especificada con el nombre en tipo de letra cursiva.
Raíz.- Es una clase que no tiene padres, en UML es especificada
escribiendo “root” abajo del nombre de la clase.
Hoja: Es una clase que no tiene hijos, en UML es especificada
escribiendo “leaf” abajo del nombre de la clase.
Ejemplo
Clase abstracta
Icon
(root)
Clase base
Origin: Point
Display ( )
Get ID ( ): integer (leaf)
Operación abstracta
RectangularIcon
Height: integer
Width: integer
Clase abstracta
ArbitraryIcon
Edge: LineCollection
IsInside (p: Point) : Boolean
Button
Display ( )
Clase concreta
OKButton
(leaf)
Display ( )
Clase leaf
Agregación y Composición
Equipo
Jugador
Agregación
Libro
Pagina
Composición
8.- Diagramas de Secuencia
Clases y Objetos


Una clase es la descripción de un conjunto de objetos que
comparten los mismos atributos, operaciones, relaciones y
semántica.
Un objeto es la instancia de la clase.
Diagrama de Secuencia


Un diagrama de secuencia es un diagrama de interacción que
se utiliza para modelar el aspecto dinámico del sistema.
El diagrama de secuencia hace énfasis en el orden de ejecución
de los mensajes con respecto al tiempo.
Línea de vida

La línea de vida de un objeto es una línea punteada
vertical que representa la existencia de un objeto en un
tiempo determinado.
Cliente
Línea de vida
Foco de control

El foco de control de un objeto es un rectángulo que muestra el
tiempo durante el cual un objeto está ejecutando una acción de
forma directa o a través de un procedimiento subordinado.
Cliente
Foco de
control
Mensajes y Operaciones



Un mensaje es la especificación de la comunicación entre
objetos.
Cuando un mensaje es enviado, la acción que resulta es
una sentencia ejecutable que forma una abstracción de un
procedimiento computacional.

Call.- Invoca a una operación a un objeto.

Return.- Regresa un valor de regreso a quien lo invoco.

Send.- Envía una señal a un objeto.

Create.- Crea un objeto.

Destroy.- Destruye un objeto.
Operación: Es la implementación de un servicio
que puede recibir peticiones de un objeto.
Mensajes y operaciones (ejemplo)
p:Planning Assistance
c:Client
Create
Create
TicketAgent
Setltinerary (l)
CalculateRoute()
Return
Destroy
Call
Route
Destroy
X
Notity()
Send
Diagrama de colaboración


Un diagrama de colaboración es un diagrama de
interacción que se utiliza para modelar el aspecto
dinámico del sistema.
El diagrama de colaboración hace énfasis en la
organización de los objetos que participan en la
interacción.
EJEMPLO DIAGRAMA DE
COLABORACIÓN
Descargar

Slide 1