Charla OOAD y RUP a ABAPeros de Repsol (2004)
-
Upload
german-del-zotto -
Category
Technology
-
view
373 -
download
0
Transcript of Charla OOAD y RUP a ABAPeros de Repsol (2004)
1
Análisis y DiseñoOrientado a Objetos
21-Abr-2004
German Del Zotto
Quadratica
:Archivo:Archivador
:Expediente
1: existeExpediente(id)
2: getId()
Agenda
Desarrollo de Software (un poco de historia) Introducción al mundo OO Diferencias entre Análisis y Diseño Análisis guiado por Casos de Uso Clases del Sistema (Análisis) Clases del Sistema (Diseño) Preguntas
2
Evolución del Desarrollo de Software
Año 1975:
CPUs de poca potencia+
Poca RAM+
Poco Almacenamiento+
Poca Metodología+
Poca Conectividad+
Lenguajes Primitivos
Clientes Insatisfechos
Año 2003:
Toda la potencia que uno quiera+
Más RAM que la necesaria+
Se almacena hasta lo que no se usa+
Metodologías para todos los gustos+
Conectividad barata en todos lados+
Lenguajes Poderosisimos
Clientes Insatisfechos
La ingeniería como aporte a las industrias
3
El “gap” entre analístas del negocio y técnicos
El “gap” entre analístas del negocio y técnicos
4
El “gap” entre analístas del negocio y técnicos
El “gap” entre analístas del negocio y técnicos
5
El “gap” entre analístas del negocio y técnicos
El “gap” entre analístas del negocio y técnicos
6
Desarrollo de Software Introducción al mundo OO Diferencias entre Análisis y Diseño Análisis guiado por Casos de Uso Clases del Sistema (Análisis) Clases del Sistema (Diseño) Preguntas
Agenda
Introducción al mundo OO
¿Porque OO?
Se parece más al mundo
¿Qué es un Objeto?
Todo es un Objeto ¡¿~?!
¿Es lo mismo de siempre con otro nombre?
Pensar en Objetos….
7
Introducción al mundo OO
¿Qué es un Objeto?Es una pieza de software. Son utilizados para construir un modeloque represente una situación del mundo real.
¿Qué es una Clase?Es un “molde” que define el comportamiento y estructura comúnque se observa en objetos de un mismo tipo.
¿Qué es una Relación?Es un recurso utilizado para describir la forma en que se relalacionan los objetos.
¿Qué es un Mensaje?Es el medio por el cual se comunican los objetos entre si.
unObjeto: ClaseClase
otroObjeto: Clase
cuantoMedis?
Introducción al mundo OO
Un objeto representa:
– Entidades Físicas
– Entidades Conceptuales
– Entidades de Software
Camión
Proceso Químico
Lista Enlazada
8
Un objeto, visión conceptual:
ESTADO– Lo que el objeto sabe
COMPORTAMIENTO– Lo que el objeto hace
IDENTIDAD– Cada objeto es único e identificable, más allá de su estado
Fecha de Nacimiento: 1978Lugar de Nacimiento: ArgentinaEstudios: Secundarios
Edad?EsExtranjero?OtorgarTitulo
“Matildo Evaristo del Prado Echagüe”
Introducción al mundo OO
Principios de la Orientación a Objetos:
– Abstracción
– Encapsulación
– Modularidad
– Jerarquías
Introducción al mundo OO
9
Introducción al mundo OO
Objetos para los desarrolladores….
¿Cómo beneficia al “Cliente Insatisfecho”?
Análisis Estructurado / Programación OO:– “Una cabaña hecha de bloques de hielo es un iglú”– Si quiero construir una cabaña necesito:• Madera• Planos• Serruchos y Martillos• Clavos• “la Carpintería como oficio”• CARPINTEROS!!!
•Objetos / Una Plataforma•Arquitectura•Herramientas de Desarrollo•Patrones•Metodología•Profesionales Idóneos
Desarrollo de Software Introducción al mundo OO Diferencias entre Análisis y Diseño Análisis guiado por Casos de Uso Clases del Sistema (Análisis) Clases del Sistema (Diseño) Resumen Preguntas
Agenda
10
Diferencias entre Análisis y Diseño
Requirimientos NO FuncionalesRequerimientos Funcionales
Modelos grandesModelos pequeños
Ciclo de Vida de los Objetos
Operaciones y AtributosComportamiento
Trabajar en el plano de lo REAL
Trabajar en el plano de lo IDEAL
Debe enforcarse para explicar la SOLUCIÓN
Debe enforcarse para explicar el PROBLEMA
DiseñoAnálisis
UML no es metodología
us er : Clerk
m ainWnd : M ainWnd
fi leMgr : FileMgr
reposi tory : Repos i torydoc um ent : Docum ent
gFi le : GrpFi le
9: sor t ByNam e ( )
L1: Doc view r equest ( )
2: f et chDoc( )
5: r eadDoc ( )
7: r eadFile ( )
3: cr eat e ( )
6: fill Docum ent ( )
4: cr eat e ( )
8: fill Fi le ( )
W in do w9 5
¹ ®¼ - °ü ¸ ®
Å ¬ ¶ó À̾ ðÆ ®.E X E
W in do wsN T
¹ ®¼ - °ü ¸ ®¿ £ Áø .E X E
Win d o wsN T
Win d o ws 95
S ola r is
À À ¿ë¼ -¹ ö. EX E
Alp h aU N IX
IBM
M a inf ram e
µ ¥ ÀÌ Å̧ º£ À̽ º¼ -¹ö
Win d o ws 95
¹ ®¼ - °ü ¸ ®¾Ö Ç Ã̧ ´
Docum ent
FileM ana ger
Grap hicFile
File
Reposit ory Docum entLis t
FileList
us erm ainWndfi leMgr :
Fi leMgrreposi torydoc um ent :
Doc umentgFi le
1 : Do c vie w r eq ue st ( )
2 : f et ch Do c( )
3 : cre at e ( )
4 : cre at e ( )
5 : r ea d Do c( )
6 : f illD o cum en t( )
7 : r ea d File ( )
8 : f illF ile ( )
9 : sor tB y Nam e( )
Æ Á̄ ¤¹ ®¼ - ¿¡ ë́ Ç Ñ º̧ ±â̧ ¦» ç ¿ë À Ú°¡ ¿ ä û Ç Ñ́ Ù.
È - ÀÏ° ü̧ ® ÀÚ ´  À о î ¿  ¹ ®¼ - À Ç Á¤ º̧ ¦̧ ÇØ ´ ç¹ ®¼ -
° Ã́¼¿¡ ¼ ³ Á¤ À» ¿ äà » ÇÑ ´ Ù.
È -̧ é °́ ü ´  Àо î µ éÀ ΰ Ã́¼ µ é¿ ¡́ ë ÇØ ÀÌ §̧ º°· ÎÁ ¤· Ä À» ½Ã Ä ÑÈ -̧ é¿ ¡
º ¿̧ © ÁØ ´ Ù.
Actor A
Use Case 1
Use Case 2
Actor B
Use Case 3
G r pFile
r ead( )open( )
cr eat e( )f illF il e( )
r ep
Repos it or y
nam e : char * = 0
r eadDoc( )
r eadFi le( )
( f r om Per sist ence)
Fil eM gr
f et chDoc( )sor t ByNam e( )
Docum ent List
add( )delet e( )
Docum ent
nam e : intdocid : int
num Fie ld : int
get ( )
open( )close( )r ead( )
sor t FileL ist( )cr eat e( )f ill Docum ent ( )
f List
1
Fil eList
add( )delet e( )
1
Fil e
r ead( )
r ead( ) fill t he
code. .
O penning
Wr it ing
Read ing Clos ing
add f ile [ num ber Of file= =M AX ] /
f lag O FF
add f ile
close f ile
close f ile
Mucho trabajo…
Demasiados Modelos…
¿Necesito tanto?
En OO usamosUML como“Herramienta deComunicación.”
11
Agenda
Desarrollo de Software Introducción al mundo OO Diferencias entre Análisis y Diseño Análisis guiado por Casos de Uso Clases del Sistema (Análisis) Clases del Sistema (Diseño) Preguntas
Análisis guiado por Casos de Uso
¿Por qué y para quién es el análisis Orientado a Objetos?
Vista de Procesos Vista de Despliegue
Vista Lógica Vista de Implementación
Programadores
Software management
Performance
escalabilidad
throughput
Integrador de Sistemas
Topología del Sistema
instalación
comunicación
Administrador de Sistemas
Analístas / Diseñadores
Estructur
View de Casos de Uso
Cliente / Usuario
Funcionalidad
12
EspecificaciónSuplementaria Diagramas de
Secuencia
Diagramas de Colaboracion
Análisis guiado por Casos de Uso
Programa deCarreras
Ver Calif icaciones
Anotarseen
Materias
Calif icar Alumnos
Postularse para EnseñarMaterias
Estudiante
Prof esor
Sistema Contable
Mantener Inf ormación deAlumnos
Mantener Inf ormación deProf esores
Login
Cerrar Inscripciones
Secretario
Actores:Interactúan con el sistema, no son parte del mismo
Casos de Uso:
Capturan la funcionalidad del sistemaEl Usuario tiene que poder entenderlos
Especificación deCasos de Uso
Diagrama de Casos de Uso
Casos de Uso
Análisis guiado por Casos de Uso
13
Pero…. ¿Qué es un Caso de Uso?
Que NO es un Caso de Uso:
No es un procesoNo es lo que hace el sistema¿CRUD? Que es eso?????
“Un caso de uso es cierta funcionalidad, observable externamente, que el sistema provee a los actores”
Deben ser simples, concisos y los tienen que
entender prácticamente
todos los involucrados en el
proyecto.
Deben ser simples, concisos y los tienen que
entender prácticamente
todos los involucrados en el
proyecto.
Análisis guiado por Casos de Uso
¿Cómo obtener los Casos de Uso?
Observando lo que hacen los Actores
Observando lo que necesitan los Actores
¿Cómo Documentarlos?
En un Modelo de Casos de UsoDiagramas de Casos de Uso
Especificaciones de Casos de UsoEspecificaciones UC
Modelo de Casos de Uso
ActoresCasos de Uso
Análisis guiado por Casos de Uso
14
Cada Caso de Uso:
Tiene una secuencia de transacciones normal y básica
Puede tener varias secuencias de transacciones alternativas
Generalmente tiene varias secuencias de transacciones excepcionales, las cuales manejan situaciones de error
También puede tener pre y post condiciones bien definidas
Análisis guiado por Casos de Uso
Análisis guiado por Casos de Uso
Diagramas de Clase
Diagramas de Secuencia
Especificación de Casos de Uso
Diagramas de Colaboración
Modelos de Casos de Uso Modelos de Diseño
Caso de Uso Realización de Casos de Uso
15
Los Casos de Uso no Cambian excepto que cambie el alcance del sistema o la forma del negocio
No se descomponen o explotan los Casos de Uso
No existe un Caso de Uso llamado “Guardar en la Base de Datos”No existe un Caso de Uso llamado “Calcular Totales”Un sistema no tiene más de 30 Casos de Uso (muy grande)
Análisis guiado por Casos de Uso
Escenarios:
Es una instancia de un Caso de Uso
Se pueden relevar fácilmente con los usuarios
Son comprobables
Sirven para generar los casos de prueba
John : Estudi ante
Formul arioRegistro
CursosDisponi bles
Formul arioPrograma
1: i ngresar id
2: vali dar i d
3: i ngresar semestre actual
4: crear un nuevo pr ograma
5: mostr ar
6: obtener cursos
Análisis guiado por Casos de Uso
16
Diagramas de Secuencia:
Permiten observar la interacción entre los objetos del sistema
Representan a Escenarios, el usuario debería comprenderlos
Pueden generarse con más o menos nivel de abstracciónSe refinan cuando se avanza con el diseño
John : Estudi ante
Formul arioRegistro
CursosDisponi bles
Formul arioPrograma
1: i ngresar id
2: vali dar i d
3: i ngresar semestre actual
4: crear un nuevo pr ograma
5: mostr ar
6: obtener cursos
Análisis guiado por Casos de Uso
Diagramas de Colaboración:
Tienen la misma información que un diagrama de secuencia
Sirven para ver las relaciones entre clases
El usuario seguramente no los podrá comprender
John : Student
registration form
schedule formavailable classes
1: enter id
2: validate id
3: enter current semester
4: create new schedule5: display
6: get courses
Análisis guiado por Casos de Uso
17
Diagramas de Actividad:
Reemplazan al cursograma
Ideales para representar procesos que involucran mucho actores
Más útiles para documentar Casos de Uso del negocio
Análisis guiado por Casos de Uso
Resumen
Examine los requerimientos para encontrar Actores
Identifique Casos de Usos y especifíquelos
Describa Escenarios para los Casos de Uso
Genere Diagramas de Interacción para los Escenarios
Vuelva a Empezar!!!
Recuerde
El Análisis y Diseño no es Bottom-Up ni Top-Down
Análisis guiado por Casos de Uso
18
Agenda
Desarrollo de Software Introducción al mundo OO Diferencias entre Análisis y Diseño Análisis guiado por Casos de Uso Clases del Sistema (Análisis) Clases del Sistema (Diseño) Preguntas
RECORDATORIO
CLASE: definición abstracta de un objeto
INSTANCIA: un objeto es una instancia de una clase
OBJETO: palabra demasiado utilizada
19
Proceso:
Complementar la descripción de los Casos de Uso
Identificar las Clases a partir del Comportamiento de los Casos de Uso
Atribuir las responsabilidades a las Clases
Describir Atributos y Asociaciones
Unificar las Clases entre todas la Realizaciones de Casos de Uso
Clases del Sistema (Análisis)
Clases del Sistema (Análisis)
Complementar las Descripciones de los Casos de Uso:
Es el momento para agregar ciertos detalles de la realidad (menos ideales…más reales)
Acomodar los flujos de eventos
20
Identificar las Clases a partir del Comportamiento de los Casos de Uso:
Clases del Sistema (Análisis)
Boundary
Entity
Control
< < b o u n d a ry > >
< < c o n t ro l> >
< < e n t it y > >
===
<<ESTEREOTIPOS>>
Identificar las Clases a partir del Comportamiento de los Casos de Uso:
Clases del Sistema (Análisis)
Cliente
<<boundary>>
<<boundary>>
<<control>>
<<boundary>>
<<entity>> <<entity>>
21
Identificar las Clases a partir del Comportamiento de los Casos de Uso:
Clases del Sistema (Análisis)
Identificar las Clases a partir del Comportamiento de los Casos de Uso:
Clases del Sistema (Análisis)
22
Atribuir las responsabilidades a las Clases:
Para asegurar la consistencia se debe buscar:
Responsabilidades redundantes entre clases
Responsabilidades no cohesivas en una misma clase
Clases con una única responsabilidad
Clases sin responsabilidades
Distribución del comportamiento
Clases que interactúan con demasiadas clases
Clases del Sistema (Análisis)
Describir Atributos y Asociaciones:
Los atributos se usan para:
Valores (~no referencias)
Valores controlados únicamente por esa instancia
Se acceden sólo con Accesors y Mutators
Clases del Sistema (Análisis)
23
Describir Atributos y Asociaciones:
Las asociaciones son:
Un forma (semántica) de especificar que existe una conexión entre instancias (de las clases)
Clases del Sistema (Análisis)
1: hacerAlgo
Objeto Cliente
Objeto Proveedor
Mensaje
Link
:Cliente
:Prov eedor
Un Link es unainstancia de unaAsociasión
Clases del Sistema (Análisis)
Materia<<entity>>
Profesor<<entity>>Instructor
Departamento<<entity>>Coordina
Describir Atributos y Asociaciones:
Las asociaciones pueden clarificarse utilizando:
Nombre de Asociaciones
Roles de las Clases (Obligatorio en Asociaciones Reflexivas)
24
Relaciones:
– Asociación “Conoce A”
Departamento
Empleado
Clases del Sistema (Análisis)
Relaciones:
– Asociación “Conoce A”• Agregación “Tiene Un”
Banco
Cuenta Corriente
Clases del Sistema (Análisis)
25
Relaciones:
– Asociación “Conoce A”• Agregación “Tiene Un”• Composición “Está Compuesto Por”
Autos
Ruedas
Clases del Sistema (Análisis)
Relaciones:
– Asociación “Conoce A”• Agregación “Tiene Un”• Composición “Está Compuesto Por”
– Generalización “Es un”
Mamífero
Elefante
Clases del Sistema (Análisis)
26
Relaciones:
– Asociación “Conoce A”• Agregación “Tiene Un”• Composición “Está Compuesto Por”
– Generalización “Es un”
– Realización “Se Comporta Como”
DocumentoImprimible
Carta
Clases del Sistema (Análisis)
Aplicando las clases en un Diagrama de Secuencia:
Clases del Sistema (Análisis)
1: EjecutarResponsabilidad
Objecto Cliente Objecto Proveedor
Mensaje
:Cliente :Proveedor
Focus of Control
Un Script de ejemplo, son útiles
Para hacer un paralelismo con el caso de Uso
Mensaje ReflexivoLíneas de Vida
1.1: EjecutarOtraRespons
Numeración Jerárquica
27
Clases del Sistema (Análisis)
Revisando el Trabajo:
¿Son razonables las clases?
¿Los nombres representan el rol que se supone que tienen?
¿Las clases representan una única abstracción bien definida?
¿Los atributos y las responsabilidades son coherentes?
¿La clase ofrece el comportamiento que se espera de ella?
¿Fueron entendidos y atendidos todos los requerimientos especifícos?
Agenda
Desarrollo de Software Introducción al mundo OO Diferencias entre Análisis y Diseño Análisis guiado por Casos de Uso Clases del Sistema (Análisis) Clases del Sistema (Diseño) Preguntas
28
Clases del Sistema (Diseño)
Puntos a cubrir en el diseño:
Identificación de interfaces
Diseño de subsistemas
Identificación y diseño de clases
Modelado del diseño e Implementación de mecanismos
Modelado de requerimientos No-Funcionales (concurrencia, distribución, etc.)
Clases del Sistema (Diseño)
Múltiples Correspondencias:
Clases del Análisis Elementos de Diseño<<boundary>>
<<control>>
<<entity>>
<<boundary>>
29
Clases del Sistema (Diseño)
Subsistemas:
Encapsulan completamente cierto comportamiento
Tienen una interfaz definida
Permiten múltiples implementaciones
Candidatos para Reuso
InterfaceX
X()W()
<<Interface>>
SubsistemaN<<subsystem>>
SubsistemaM<<subsystem>>
ClaseA1
W()
ClaseA2
X()
ClaseB1
W()Y()
ClaseB2
X()
ClaseB3
Z()
Clases del Sistema (Diseño)
Identificando Clases de Diseño:
: Actor : Boundary : Control : Entity
1: 2:
3:
: Actor:Browser
: UCDis patc her:Helper : Session : Interface
1: 2:
3:
5: Análisis
Diseño
4:
30
Clases del Sistema (Diseño)
Identificando Clases de Diseño: Las Asociaciones son relaciones Estructurales Las Dependencias son relaciones No-Structurales Para que se “puedan ver” deben estar relacionadas
Referencia por variable LocalReferencia por parámetroReferencia global
Referencia por Propiedades
Asociación
ClienteProveedor1
Proveedor2Dependencia
Clases del Sistema (Diseño)
Identificando Clases de Diseño:
Usar Composición cuando:– Propiedades requieren una entidad– Varias clases tienen los mismos atributos– Las propiedades tienen una estructura compleja– Las propiedades tienen un comportamiento complejo– Las propiedades tienen relaciones explícitas
En el resto de los casos usar Atributos
Camion Conductor1 1
31
Clases del Sistema (Diseño)
Identificando Clases de Diseño:
Clases Asociativas:– Es una clase attachada a
una asociación– Tienen comportamiento
propio– Tiene sus propios
atributos para describir la relación
– Corresponde una instancia por cada link
InfoSuscripcionstatus
// recomendado()// cancelar()// esta al dia?()
<<entity>>
Abonado<<entity>>
Plan<<entity>>
0..*0..2
promociones
planes contratados0..* 0..6
SubscripcionPromocionaldescuento
// es aplicable?()// fecha desde()// fecha hasta()
<<entity>>
Clases del Sistema (Diseño)
Identificando Clases de Diseño:
Multiplicidad:– Relaciones 1 o 0..1:• Pueden implementarse con
una referencia simple
– Relaciones 0..*:• Requieren un container
específico• Los lenguajes suelen
proveer algo
instructorProfesor Materia
0..*0..1
Materia<<entity>>
Profesor<<entity>>
ListaMaterias
+ new()+ add()
1
0..*
0..10..1
+instructor
Materias
0..*0..1
instructor
List
Profesor
32
Clases del Sistema (Diseño)
Identificando Clases de Diseño:
Multiplicidad:– Relaciones 1 o 0..1:• Pueden implementarse con
una referencia simple
– Relaciones 0..*:• Requieren un container
específico• Los lenguajes suelen
proveer algo
MateriaProfesor
enseña(aMateria) : Boolean 0..1 0..* tieneInstructor( ) : Boolean
Cuando las relaciones son opcionales es conveniente agregar métodos para testear la existencia
Clases del Sistema (Diseño)
Identificando Clases de Diseño:
Clases Abstractas:– No se pueden instanciar– Pueden ser abstractas por
definición de clase o por tener métodos abstractos
Barco
mueve ()
Auto
mueve ()
Vehiculo
{abstract}
mueve () {abstract}
33
Clases del Sistema (Diseño)
Identificando Clases de Diseño:
Herencia:– Relaciones “Es un”
Cuentasaldonombrenumero
retirar()depositar()
CtaCorr CajaAhorro
getInteres()
Super Clase
(padre)
Sub-clases
Relación de Generalización
Descendientes
Ancestros
Clases del Sistema (Diseño)
Identificando Clases de Diseño:
Herencia vs Agregación:
Scrollbar
Window
WindowConScrollbar11
Window
WindowConScrollbar
Scrollbar
Un WindowConScrollbar “es un”WindowUn WindowConScrollbar “contiene un” Scrollbar
34
Agenda
Desarrollo de Software Introducción al mundo OO Diferencias entre Análisis y Diseño Análisis guiado por Casos de Uso Clases del Sistema (Análisis) Clases del Sistema (Diseño) Preguntas
Preguntas
35
Muchas Gracias
German Del Zotto Quadratica