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


4



5



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


¿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?


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”


Principios de la Orientación a Objetos:

– Abstracción

– Encapsulación

– Modularidad

– Jerarquías


9


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


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


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


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.


¿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


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



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)


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


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


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


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


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


18

Agenda


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)


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:


Boundary

Entity

Control

< < b o u n d a ry > >

< < c o n t ro l> >

< < e n t it y > >

===

<<ESTEREOTIPOS>>



Cliente

<<boundary>>

<<boundary>>

<<control>>

<<boundary>>

<<entity>> <<entity>>

21





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


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


23


Las asociaciones son:

Un forma (semántica) de especificar que existe una conexión entre instancias (de las clases)


1: hacerAlgo

Objeto Cliente

Objeto Proveedor

Mensaje

Link

:Cliente

:Prov eedor

Un Link es unainstancia de unaAsociasión


Materia<<entity>>

Profesor<<entity>>Instructor

Departamento<<entity>>Coordina


Las asociaciones pueden clarificarse utilizando:

Nombre de Asociaciones

Roles de las Clases (Obligatorio en Asociaciones Reflexivas)

24

Relaciones:

– Asociación “Conoce A”

Departamento

Empleado


Relaciones:

– Asociación “Conoce A”• Agregación “Tiene Un”

Banco

Cuenta Corriente


25

Relaciones:

– Asociación “Conoce A”• Agregación “Tiene Un”• Composición “Está Compuesto Por”

Autos

Ruedas


Relaciones:


– Generalización “Es un”

Mamífero

Elefante


26

Relaciones:


– Generalización “Es un”

– Realización “Se Comporta Como”

DocumentoImprimible

Carta


Aplicando las clases en un Diagrama de Secuencia:


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


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


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.)


Múltiples Correspondencias:

Clases del Análisis Elementos de Diseño<<boundary>>

<<control>>

<<entity>>

<<boundary>>

29


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()


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


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



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 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>>



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



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 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



Herencia:– Relaciones “Es un”

Cuentasaldonombrenumero

retirar()depositar()

CtaCorr CajaAhorro

getInteres()

Super Clase

(padre)

Sub-clases

Relación de Generalización

Descendientes

Ancestros



Herencia vs Agregación:

Scrollbar

Window

WindowConScrollbar11

Window

WindowConScrollbar

Scrollbar

Un WindowConScrollbar “es un”WindowUn WindowConScrollbar “contiene un” Scrollbar

34

Agenda


Preguntas

35

Muchas Gracias

German Del Zotto Quadratica

Charla OOAD y RUP a ABAPeros de Repsol (2004)

Technology

Transcript of Charla OOAD y RUP a ABAPeros de Repsol (2004)