Analisis y Diseo Orientado A Objetos

ANLISIS Y DISEO ORIENTADO A OBJETOS (ADOO) CON UML
Alejandro Domnguez / Jorge Kashiwamoto / Enrique Torres (Versin 4.0) Curso impartido en la Fundacin Arturo Rosenblueth y en UNITEC de 1998-2010
Objetivos generales
Proporcionar el conocimiento de los principios inherentes en el anlisis y diseo orientado a objetos Introducir el Lenguaje Unificado de Modelado (Unified Modeling Language: UML), el cual es el lenguaje estndar para el anlisis y diseo orientado a objetos Utilizar UML para modelar un caso prctico de sistemas
Panormica general del curso (1)

El curso en 13 captulos
Captulo 1: Tratamiento de la complejidad y la orientacin a objetos
Captulo 2: Historia de la orientacin a objetos

Captulo 3: Conceptos de la orientacin a objetos Captulo 4: Introduccin a UML y al anlisis y diseo orientado a objetos Captulo 5: Modelo de requerimientos (modelado de casos de uso)
3

El curso est compuesto por ...
Captulo 6: Modelo de anlisis (diagramas de clase) Captulo 7: Modelo de diseo (diagramas de secuencia)
Captulo 8: Modelo de diseo (diagramas de estado)

Captulo 9: Modelo de diseo (diagramas de colaboracin) Captulo 10: Modelo de diseo (diagramas de actividad) Captulo 11: Modelo de implantacin (diagramas de componentes)
Captulo 12: Modelo de implantacin (diagramas de deployment)

Captulo 13: Introduccin al proceso unificado de desarrollo de software
4

El curso est compuesto por ...
Captulo 13: Introduccin al Proceso Unificado de Desarrollo de Software
RUP

Adicionalmente el alumno debe cubrir de forma autodidacta el aprendizaje de la herramienta Rational Rose o Visio de las partes 4 a 12
Se puede obtener una versin de evaluacin de Rational Rose por 30 das en http://www.rational.com
En clase se presentarn algunos ejemplos para facilitar la comprensin de la elaboracin de diagramas.
Material de consulta (1)

Alejandro Domnguez FAR
Anlisis y Diseo Orientado a Objetos con UML Versin 3.0
Booch, G., J. Rumbaugh y I. Jacobson. The unified modeling language user guide. AddisonWesley, 1999. Fowler, M. Y K. Scott. UML gota a gota. Pearson, 1999. Oestereich, B. Developing software with UML. Addison-Wesley, 1999.
7

Schneider, G. y J.P. Winters. Applying use cases. AddisonWesley, 1999.
Taylor, D.A. Object technology. Addison-Wesley, 1998. Rational Software, 1997. UML
notation guide. Version 1.1.

http://www.rational.com
Rational Software, 1997. UML
semantics. Version 1.3.
http://www.rational.com
8

Booch, G., J. Rumbaugh y I. Jacobson. The unified modeling language reference guide. Addison-Wesley, 1999. Larman, C. / UML y Patrones / Pearson / 1999
Rumbaugh / OMT / Addison-Wesley
Booch, G., J. Rumbaugh y I. Jacobson. El Proceso Unificado de Desarrollo de Software. Addison-Wesley, 1999.
Evaluacin del curso

100% anlisis y diseo de un caso prctico de sistemas que incluya:
Diagramas de casos de uso
Diagramas de clase
Diagramas de secuencia Diagramas de estado
10
TRATAMIENTO DE LA COMPLEJIDAD Y LA ORIENTACIN A OBJETOS
Alejandro Domnguez
11
Panormica general
Complejidad de los sistemas de software
Tratamiento de la complejidad y descomposicin Descomposicin orientada a procesos y a objetos
12
Los sistemas
Un sistema es:
Un grupo conexo y organizado de objetos Un todo compuesto de partes organizadas acorde a algn esquema o plan
Los sistemas tienen:

Fronteras Entorno
Caractersticas propias
Propiedades emergentes
13
Sistemas complejos
La complejidad de un sistema es una propiedad inherente, no accidental La interconexin de los sistemas es una fuente potencial para inconsistencias e incongruencias
14
Origen de la complejidad de los sistemas

Desarrollado por personas
Desarrollado a travs de un proceso largo y tedioso
Sujeto a cambios
La no existencia de leyes fundamentales para explicar los fenmenos y enfoques Existencia del Lmite de Miller
El ser humano slo puede manejar, procesar o mantener la pista de aproximadamente 7 objetos, entidades o conceptos a la vez
No se comprende el sistema en su totalidad

Difcil de documentar y probar Potencialmente inconsistente o incompleto
15
4 razones para la complejidad (Grady Booch)

1 razn.- La naturaleza del dominio del problema:
Requerimientos complejos
Decaimiento de los sistemas
2 razn.- Complejidad de los procesos:

Problemas en la administracin y gestin Necesidad de simplificacin
16
4 razones para la complejidad (Grady Booch)

3 razn.- La flexibilidad de los sistemas es un arma de dos filos 4 razn.- Caracterizar el comportamiento discreto de los sistemas:
Existencia de varios estados Dificultad para explorar todos los estados
17
5 atributos de los sistemas complejos (Grady Booch)

1er atributo
Los subsistemas son jerrquicos e interactuan entre ellos
2 atributo
Los subsistemas se han definido arbitrariamente
3er atributo
El acoplamiento entre componentes del mismo subsistema es fuerte y el acoplamiento entre componentes de diferentes subsistemas es dbil
18
5 atributos de los sistemas complejos (Grady Booch)

4 atributo
Poseen una serie de subsistemas recurrentes que aparecen en diferentes combinaciones y arreglos
5 atributo
No siempre evolucionaron de sistemas simples a sistemas complejos
19
Tratamiento de la complejidad
Principios que permitirn el tratamiento de la complejidad:
Abstraccin
Ignorar los detalles no esenciales y construir un modelo ideal y generalizado
Jerarqua
Clasificar en grupos de abstracciones relacionadas para poder distinguir explcitamente las propiedades comunes y distintas
Descomposicin
Orientada a procesos Orientada a objetos
20
Descomposicin
La mejor tcnica conocida desde tiempos inmemoriales para enfrentar la complejidad es: divide et
impera
Con esta tcnica se solventa la restriccin impuesta por el lmite de Miller

21
Se aplica para descomponer un problema en pequeos pasos o procesos La unidad fundamental de este tipo de descomposicin es el subproceso
Descomposicin orientada a procesos (OP)
El proceso resultante toma la forma de un rbol en el que cada subproceso realiza su trabajo, llamando a otro subproceso
22
Descomposicin orientada a objetos (OO)

El sistema se visualiza como un conjunto de objetos autnomos, que al colaborar entre si muestran cierta conducta Los procesos no existen de manera independiente, estn asociados a las objetos Cada objeto exhibe un comportamiento propio bien definido, y adems modela alguna entidad del mundo real
23
Descomposicin OP vs OO
Cul es la forma correcta de descomponer un sistema complejo, OP u OO?
Las dos formas son importantes
La OP muestra el orden de los eventos La OO enfatiza las entidades que causan la accin
No es recomendable descomponer un sistema complejo de ambas formas simultneamente debido a que se incrementa la complejidad
24
Recomendacin para el tratamiento de la complejidad

Primero aplicar un descomposicin OO, la cual servir como marco de referencia para continuar con una descomposicin OP
25
HISTORIA DE LA ORIENTACIN A OBJETOS
Alejandro Domnguez
26
Panormica general
La vida media de las tecnologas de IS Aspectos histricos de la orientacin a objetos(OO)
La OO en lo 1990s
Lo que se ha aprendido de la OO
27
15 aos de fama
La experiencia nos dice que las tecnologas de ingeniera de software (IS) ms populares tienen el siguiente comportamiento:
Toman algn tiempo en llegar a ser populares Tienen un periodo de florecimiento de 15 aos
Un ejemplo es la metodologa estructurada

Empez a ser popular entre de 1973-1975
Alcanz su pico de popularidad entre 1985-1989

28
La vida media para las tecnologas de IS

La vida media para las tecnologas indica el punto medio en su ciclo de vida La vida media en la orientacin a objetos significa que:
Se ha utilizado esta tecnologa por algn tiempo en proyectos reales
Ser remplazada por otras tecnologas dentro de un periodo de 7 a 10 aos
29
Aspectos histricos (1)

1963:
I. Sutherland disea Sketchpad en el cual se presentan grficas e interfaces grficas de usuario OO; as como clases (masters) e instancias
1966:
Se introduce al mercado Simula, el primer lenguaje de programacin OO
Finales de 1960s:
Alan Kay trabaja en la mquina denominada FLEX, la precursora de Dynabook, la Xerox Star, y la Apple Macintosh
30

1970:
El trmino orientado a objetos se introduce en la literatura. Muchas personas se lo acreditan a Alan Kay
1972:
Se desarrolla la primera versin de Smalltalk
1980:
Grady Booch introduce el diseo orientado objetos Se introducen las primeras versiones de hardware OO
31

1985:
aparecen las bases de datos OO aparecen la bibliotecas de clases OO
1986:
Se introducen las primeras versiones de anlisis OO y de anlisis de requerimientos OO
1988:
anlisis del dominio OO aparece en la literatura
32

1980s:
Se desarrollan un gran cantidad de aplicaciones OO
Estas aplicaciones son principalmente aplicaciones de tiempo real
Literalmente, se producen millones de lneas de cdigo OO
Finales de 1980s:
Aparece un gran nmero de lenguajes de programacin OO; incluyendo: C++, Eiffel, CLOS, etc.
33

Algol
1960
No orientado a objetos
Orientado a objetos
Fortran
LISP
Cobol
PL/1
Simula
1970
Smalltalk-72 Smalltalk-74 Pascal C

Smalltalk-76 Smalltalk-78
Prolog
Loops
1980
Smalltalk-80
Ada
Object Pascal C ++
Objective C Eiffel
CLOS
1990
Ada 9
Object Cobol Java
34
Mediados de los 1990s (1)

La MOO empieza a mostrar signos de vida media:
Literalmente cientos de millones de lneas de cdigo fuente OO se han escrito
Algunos productos OO contienen alrededor de 2,000,000 de lneas de cdigo
La tecnologa de BDOO tiene un xito sin precedente

La Object Management Group (OMG) hace un esfuerzo por estandarizar la tecnologa de BDOO El mercado de los sistemas de bases de datos OO se duplica cada ao
35

Los desarrolladores de software pueden elegir entre un gran nmero de herramientas CASE OO
Object Internationals Object Tool Rationals Rose Protosofts Paradigm Plus
Existen muchos enfoques de desarrollo de software OO: Booch, Rumbaugh, Coad, WirfsBrock, Berard, Fusion, Shlaer-Mellor, ...
Alrededor de 30 enfoques son populares
36

El trmino orientado a objetos aparece de forma regular en las publicaciones de negocios: The Wall Street Journal, Business Week, ...
La comunidad de administracin de los SI empieza a utilizar la tecnologa OO
37

Ada/Booch OOSA Shalaer/Mellor RDD Wirfs-Brock Booch 91 Booch
1990
OOSE Jacobsen
OMT Rumbaugh et al.

Booch 93
OBA Gibson/Goldb.
OOA Coad/Yourdon
OOSE 94
1995
OMT 94
Fusion Coleman
OODA Martin/Odell
State Charts Harel
SOMA Graham Team Fusion Coleman et al.
MOSES Henderson-Sellers RD Shalaer/Mellor
1997
38
A finales de los 1990s

Existe una tendencia a estandarizar las tecnologas orientadas a objetos
Unified modeling language (UML) Business objects
Existe un crecimiento significante (y explosivo) de tecnologas basadas en la orientacin a objetos

programacin basada en componentes programacin basada en agentes
39
Lo que se ha aprendido (1)

La tecnologa OO es una oportunidad, no una garanta
Los proyectos orientados a objetos pueden fallar
La tecnologa OO es vasta
Ms amplia que lo indicado en los lenguajes de programacin OO
40

La evidencia emprica muestra que, cuando se compara con las mismas aplicaciones desarrolladas utilizando enfoques tradicionales, las soluciones OO
Son ms pequeas Son menos complejas Son ms apropiadas para aplicaciones de tiempo real Toman menos tiempo en desarrollarse
41

La tecnologa OO hace mas nfasis en la reusabilidad del software que los mtodos tradicionales
Sin embargo muy pocas personas dentro de la comunidad OO entiende lo que verdaderamente significa reusabilidad
42

La tecnologa OO tiene impacto en los dominios de:
Las practicas administrativas
Las metodologas del ciclo de vida La seleccin de herramientas El almacenamiento persistente Los lenguajes de programacin
43
CONCEPTOS DE LA ORIENTACIN A OBJETOS
Jorge Kashiwamoto / Alejandro Domnguez

44
Panormica general
La orientacin a objetos Objetos y abstraccin Clasificacin y clases Caractersticas de los Objetos Relaciones Agregacin Modularidad
Encapsulamiento
Generalizacin y especializacin Polimorfismo
Herencia y herencia mltiple

Conclusiones
45
Qu es la Orientacin a Objetos?
46
Paradigma
PARADIGMA Procedural Funcional Restricciones Objetos ASPECTOS ESENCIALES QUE MODELA Algoritmos Metas u objetivos en un clculo de predicado Relaciones invariantes Clases y objetos
47
Paradigma de la ORIENTACIN A OBJETOS

Marco conceptual propio
Anlisis de problemas Enfoque particular del problema.
Planteamiento ms claro
Determinados problemas
Determinado marco conceptual
Apropiado para el desarrollo de aplicaciones comnes
Donde el anlisis de la complejidad juega el papel ms importante

48
Derivados de la OO
Tecnologas Metodologas Programacin Lenguajes Bases de Datos Etc.
49
Motivaciones de la OO
Tratar o abordar dominios de problemas ms amplios y complejos
Mejorar la interaccin entre los usuarios y los analistas. Incrementar la programacin consistencia entre anlisis, diseo y
Representar explcitamente los aspectos comunes dentro de una clase o familia de entidades.
Construir especificaciones fciles de cambiar o adaptar

Reusar resultados previos de anlisis, diseo y programacin Proveer una representacin subyacente consistente para el anlisis, el diseo y la programacin
50
Orientacin a Objetos
El software se organiza como una coleccin de objetos discretos que contienen tanto estructuras de datos como comportamiento
Rumbaugh
Los objetos renen las caractersticas esenciales que los definen.
51
La orientacin a objetos (OO)

Significa notaciones, tcnicas y mtodos para producir varios modelos de un sistema en diferentes niveles de abstraccin y granularidad basados en los principios de:
Objetos Clases de objetos Encapsulamiento
Herencia
Polimorfismo
52
Definicin de objeto
Un objeto es:
Diccionario Larousse: Objeto (del bajo latn objectum < lat.)
Cosa material y concreta, por lo regular de dimensiones reducidas Trmino con lo que se denota aquello sobre lo que recae la accin expresada por el verbo
The 3 amigos:
Una manifestacin concreta de una abstraccin Una entidad con una frontera e identidad bien definidas que encapsula estado y comportamiento Una instancia de una clase
53
OBJETO
Es una entidad que retiene una cierta informacin abstracta y sabe como realizar ciertas operaciones sobre esta informacin
Wirfs-Brock
OBJETO =
ATRIBUTOS + COMPORTAMIENTO
Entidad discreta con lmites e identidad bien delimitadas que encapsula el estado y el comportamiento. Instancia de una clase.
UML
54
Ejemplos de objetos
En una empresa procesadora de alimentos
Objetos pasivos:
Un saco de lentejas Un paquete de caf Factura 895 enviada a alguna empresa
Agentes humanos
Zoila Baca del Corral (Secretaria ejecutiva) Armando B. Roncas (Guardia de seguridad)
Objetos estructurales
Departamento de ventas
Objetos activos:
Camioneta placas 1234AB La mquina de fax de la empresa
55
Abstraccin
La abstraccin surge desde un reconocimiento de similaridades entre ciertos objetos, situaciones o procesos en el mundo real, y la decisin de concentrar la atencin sobre estas similaridades e ignorar por el momento las diferencias.[Hoare] La abstraccin es una descripcin simplificada, o especificacin, de un sistema que enfatiza algunos de los detalles o propiedades del sistema mientras suprime otras. Una buena abstraccin es una que enfatiza detalles que son significativos al lector o usuario y suprime detalles que son, al menos por el momento, inmateriales o que distraen la atencin. [Shaw]
56
Abstraccin
Un concepto califica como una abstraccin slo si este puede ser descrito, comprendido y analizado independientemente del mecanismo que eventualmente ser usado para realizar ste. [Berzins, Gray y Naumann]
Una abstraccin denota las caractersticas esenciales de un objeto que distinguen a ste de todos los otros tipos de objetos y de esta forma proporciona lmites conceptuales definidos sucintamente, relativos a la perspectiva del observador. [Booch]
57
Abstraccin
Abstraccin es el principio de ignorar aquellos aspectos de un sujeto que no son relevantes al propsito actual, con el objetivo de concentrar la atencin completamente en aquellos que lo son. [Oxford University] La abstraccin de datos es el principio de definir un tipo de dato en trminos de las operaciones que se aplican a objetos de este tipo, con la restriccin de que los valores de tales objetos pueden ser modificados y observados slo mediante el uso de estas operaciones. [Oxford University]
58
Abstraccin (Resumen 1/2)

Forma fundamental en que los seres humanos se enfrentan con la complejidad de los problemas del mundo circundante. Una abstraccin denota las caractersticas esenciales de un objeto, distinguindolo de otros tipos de objetos y obviando caractersticas irrelevantes a los intereses del observador que hace la abstraccin
59
Abstraccin (Resumen 2/2)

Segn Booch
Una abstraccin denota las caractersticas esenciales de un objeto que lo distingue de todos los dems y, por lo tanto, proporciona fronteras conceptuales definidas, relativas a la perspectiva del observador
Lo que un observador concibe no necesariamente lo concibe un observador diferente
60
Clasificacin
Los objetos con iguales estructuras y comportamiento (operaciones) se agrupan para formar una clase que los describe.
En este sentido el concepto de clase nos permite dividir y clasificar los objetos de nuestro problema. Se dice que la clase en tanto describe funciona como el tipo y el objeto en tanto es descrito y puede tener una existencia concreta, como la instancia o variable del tipo.
CLASES
61
Dificultades de la clasificacin
62
CLASE
Es una coleccin de objetos los cuales comparten las mismas caractersticas y comportamientos.
Wirfs-Brock
Descriptor para un conjunto de objetos que comparten los mismos atributos, operaciones, mtodos, relaciones y comportamiento. Concepto del sistema modelado.
UML
63
Representacin de clase
64
Tipo de dato abstracto Abstract Data Type (ADT)

Un tipo de dato abstracto es una caracterizacin precisa de una entidad en termino de atributos y operaciones, la cual brinda una interfaz y una implementacin.
Su interfaz es el medio de comunicacin con el exterior, donde se describe la forma en que deben ser invocada cada una de las operaciones, mientras que su implementacin consiste en la representacin interna que tengan cada uno de los atributos, as como la forma concreta en que cada una de las operaciones acta sobre dichos atributos. La implementacin es una parte oculta al usuario del ADT, un mismo ADT puede tener varias implementaciones pero una nica interface.
65
Ejemplo de Pila (abstraccin)

programacin en C muy primitiva programacin en C con abstraccin typedef int T; typedef struct{ int top, size; T *stack; }stack; int stack_create(stack *s, int size); void stack_destroy(stack *s); void stack_push(stack *s, T item ); void stack_pop(stack *s, T *item); int stack_is_empty(stack *s); int stack_is_full(stack *s);
typedef int T; # define Max_Stack 100 T stack[Max_Stack]; int top=0; T item;

/* Interface para el manejo de la pila */ int create(int size); int destroy(void); void push(T new_item); void pop(T *old_top); void top(T *cur_top); int is_empty(void); int is_full(void);
2
66
Ejemplo de Pila (ADT)

Programacin en C++ con abstraccin en Objectos typedef int T; class stack{ public: //interface stack(int size); ~stack(void); void push(const T &item); void pop(T &item); int is_empty(void) const; int is_full(void) const; private: //implementacin int top_, size_; T *stack; } stack s1(10); s1.push(473); Abstraccin y genericidad usando POO template <class T> class stack{ public: //interface stack(int size); ~stack(void); void push(const T &item); void pop(T &item); int is_empty(void) const; int is_full(void) const; private: //implementacin int top_, size_; T *stack; } stack<int> s1(10); s1.push(10); stack<empleado> s2(20); s2.push(juan);
67
Caractersticas de un objeto
Abstraccin / Clasificacin Modularidad Extensibilidad Persistencia Concurrencia Estado Comportamiento
68
Encapsulamiento
Herencia
Polimorifismo
Identidad Reusabilidad
Caractersticas bsicas de los objetos

Un objeto tiene
Estado Comportamiento
Identidad
69
Estado
Una condicin o situacin durante la vida de un objeto que satisface alguna condicin, lleva a cabo alguna actividad, o espera algn evento
Transicin
Cambio de estado.
Evento
Un suceso u ocurrencia de un fenmeno que lleva a una transicin.
70
Comportamiento
Los efectos observables de un evento, incluyendo sus resultados
71
Comportamiento: Implantacin
Operacin
Es una funcin de transformacin sobre los atributos del objeto (no necesariamente cambindolos). Los tipos ms comunes de operacin sobre un objeto son: Modificacin,
Seleccin, Iteracin.
Mtodo
Es la implementacin especfica de una operacin. Algunos especialistas utilizan los trminos Operacin y Mtodo de manera intercambiable.
72
Comportamiento: Tipo de Objetos

Objetos Activos y Objetos Pasivos
Los objetos activos son aquellos que dirigen su propio hilo de control. Los objetos pasivos slo pueden ejecutar transiciones cuando se acta sobre ellos. Dado que los objetos activos son autnomos, ellos son la raz del control en un sistema. La existencia de hilos mltiples de control en un programa (concurrencia) slo puede lograrse con mltiples objetos activos, mientras que los sistemas secuenciales slo tienen un objeto activo a la vez.
Objeto Cliente y Objeto Servidor

El objeto servidor responde a una solicitud de servicio (mensaje) del objeto cliente. Se establece una relacin de contrato cliente-servidor. Segn este contrato el servidor debe cumplir las responsabilidades que se le exigen en el mismo.
73
Identidad
Propiedad que permite distinguirlo de todos los dems objetos existentes
74
Identidad
Los datos estn cuantificados en entidades discretas y distinguibles, con fronteras bien definidas, denominadas objetos.
Cada objeto tendr una existencia propia, independientemente del valor de sus atributos. No es diferenciar los objetos por su nombre, sino ellos mismos, por el hecho de existir. Todo objeto contiene una referencia a si mismo. Ejemplo
clasedefinida a,b a <> b
75
Propiedades de los objetos (1)

Atributos
Son la estructura de los objetos: sus componentes y la informacin o datos contenidos en l
Son las caractersticas o propiedades intrnsecas o internas de los objetos
Son pares del tipo nombre: valor

El nombre debe reflejar la semntica de la caracterstica o propiedad que representa El nombre se utiliza para accesar el valor de la caracterstica del objeto El valor de los atributos puede cambiar en el tiempo, pero este no es el caso del nombre
Determinan el estado del objeto
76

Operaciones
Son servicios que pueden realizar los objetos cuando se les enva un mensaje Determinan el comportamiento de los objetos Algunas veces se utilizan las palabras servicios o mtodos o errneamente procedimientos o funciones
77

Restricciones
Son condiciones, requerimientos y reglas que deben satisfacer los objetos Restringen las propiedades y estados de los objetos Regularmente estn determinadas por los valores que pueden tomar los atributos
78
Ejemplo: un circulo
Nombre: circulo Atributos: radio (radio:r) y posicin del centro (centro:(a,b)) Operaciones: desplegar, remover, reposicionar, modificar tamao Restricciones: el radio debe ser positivo
79
Modularidad
"La accin de particionar un programa en componentes individuales puede reducir su complejidad en algn grado...".[Myers] "La modularizacin consiste en el hecho de dividir un programa en mdulos los cuales puedan ser compilados separadamente, pero stos tienen conexiones con otros mdulos". [Liskov] "Las conexiones entre los mdulos son las asunciones que los mdulos hacen acerca de cada otro". [Parnas] " Modularidad es la propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos acoplados coherentemente y libremente". [Booch] "La meta global de la descomposicin en mdulos es la reduccin del costo del software al permitir que los mdulos sean diseados y revisados independientemente... La estructura de un mdulo debe ser lo suficientemente simple de forma tal que sta pueda ser comprendida completamente; debe ser posible cambiar la implementacin de unos mdulos sin la necesidad de conocer de la implementacin de otros mdulos y sin afectar su comportamiento".
80
Modularidad
Principio de programacin que nos permite precisar las interfaces con distintas decisiones de diseo. Los mdulos son una forma de organizar y especializar el trabajo de programacin.
Deben ir en un mismo mdulo todas aquellas herramientas que tengan una unidad conceptual y de vocabulario, aquellas que se refieran al tratamiento de un mismo aspecto.
En la medida en que cada uno de estos aspectos este bien distinguido y generalizado en un mdulo mayor ser la utilidad y rango de aplicacin de ste. Esta forma de pensar nos permite hacer diseos ms amplios y especializados que rebasan las necesidades de nuestra aplicacin y nos permiten obtener herramientas ms duraderas. Se debe buscar completitud.
81
Encapsulamiento
La abstraccin y el encapsulamiento son conceptos complementarios: la abstraccin focaliza sobre la visin externa de un objeto y el encapsulamientotambin conocido como ocultamiento de informacin impide que los clientes vean la visin interna del objeto, donde el comportamiento de la abstraccin es implementado. De esta manera, el encapsulamiento proporciona barreras explcitas entre diferentes abstracciones. "Para trabajar la abstraccin, la implementacin debe ser encapsulada". [Liskov] En la prctica, esto significa que cada clase debe tener dos partes: una interfaz y una implementacin. La interfaz de una clase captura slo su visin externa, encerrando nuestra abstraccin del comportamiento comn de todas las instancias de la clase. La implementacin de una clase comprende la representacin de la abstraccin as como los mecanismos que alcanzan el comportamiento deseado.
82
Encapsulamiento
"El encapsulamiento es el proceso de ocultamiento de todos los detalles de un objeto que no contribuyen a sus caractersticas esenciales". [Booch] En la prctica, uno oculta la representacin de un objeto as como la implementacin de sus mtodos. "El encapsulamiento (ocultamiento de informacin) es un principio usado cuando se desarrolla la estructura global de un programa, donde cada componente de un programa debe encapsular u ocultar una nica decisin de diseo...La interfaz de cada mdulo es definida en forma tal que revele tan poco como sea posible acerca de su funcionamiento interno. [Oxford University] Esto ayuda a un trabajo eficiente de los programadores de manera que tengan que invertir pocos esfuerzos a la hora de hacer cambios o modificaciones.
83
Encapsulamiento (Resumen)
La abstraccin y el encapsulamiento son conceptos complementarios
La abstraccin se centra en el comportamiento observable de un objeto El encapsulamiento se centra en el origen de dicho comportamiento
El encapsulamiento
Se logra a travs del ocultamiento de la informacin que no contribuye a sus caractersticas esenciales de un objeto
84
Ejemplo de encapsulamiento
85
Permisos de Acceso
Publico: Los atributos y operaciones declarados pblicos (interfaz de la clase) sern del acceso de cualquier funcin, ya sea sta una operacin en una clase derivada o en cualquier otra clase cliente de los servicios de la clase. Protegido: Los atributos y operaciones declarados protegidos (implementacin de la clase) sern del acceso de cualquier funcin que sea una operacin en una clase derivada. Privado: Los atributos y operaciones declarados privados (implementacin de la clase) sern del acceso slo de las funciones de la propia clase.
86
Permisos de Acceso
Tipos de Clientes
Operaciones en otras clases que invocan operaciones sobre los objetos de la clase (simples clientes)
mantener el encapsulamiento Los usuarios no deben tener otra visin de la clase que no sea la que puede tener a travs de su interface
Operaciones en clases derivadas (clientes privilegiados)

Tener ciertos derechos a conocer ms a fondo los detalles de implementacin
87
Permisos de Acceso
Rompimiento del Encapsulamiento

Funcionamiento adecuado Permisos de Acceso Sobre
Atributos privadas Operaciones privadas De de la clase base
Causas
Importancia de la Redefinicin
Eficiencia
88
Ejemplo
Circulo
Privado: Xcoor, Ycoor Protegido: radio Publico: leer_coor() mostrar() ocultar() esta_oculto() trasladar() Circulo expandible
Publico: Expandir() Contraer()
89
Clases y funciones amigas

En ocasiones un concepto de diseo (una funcionalidad) puede ser vista como la interaccin o el trabajo coordinado de objetos pertenecientes a ms de una clase. En este marco podra ser necesario por ejemplo que las operaciones de cada una de las clases tuvieran accesos plenos a todos los atributos (a toda la implementacin) de todas las clases involucradas .
90
Relacin
Conexin entre cosas
Utilizadas en el modelado OO
Se trazan como rutas con diferentes tipos de lnea para distinguir diferentes clases de relaciones.
91
Tipo de Relacin: DEPENDENCIA

Es una relacin que establece que un cambio en la especificacin de un objeto puede afectar otro que lo utiliza, pero no necesariamente a la inversa. Tambin conocidas como
Relacin de referencia asociacin de referencia
92
Dependencia
La conexin slo se refiere a otro objeto
La conexin se lleva a cabo a travs del paso de mensajes Un mensaje consiste de 3 partes
Un objeto receptor Una operacin que el receptor sabe como ejecutar Un conjunto ordenado de parmetros que esta operacin requiere para llevar a cabo su funcin
Parte opcional; si la operacin no necesita informacin adicional para hacer su trabajo, no existen parmetros
93
Dependencia: ejemplos
Empleado
Atributos Nombre: Tecla Puesto: Bibliotecaria Edad: 40 Salario: 3000.00 Relaciones con Usuarios Jefe Libros Operaciones Prestar libros Reasignar colocaciones Estar de mal humor Solicitar aumento de salario
Reasignar colocacin
Vehculo avanzar: 100 km

Receptor Operacin Parmetro
94
Dependiencia y dinmica de los objetos

La dinmica de los objetos se genera por los mensajes existentes entre los objetos El recibir un mensaje provoca que una operacin sea ejecutada por el objeto receptor
La operacin puede mandar mensajes adicionales a otros objetos
95
Dependencia: Modelado
Se traza como una lnea punteada dirigida. Utilice las dependencias cuando se desea mostrar que un objeto usa a otro. Frecuentemente se utilizar cuando una clase utliza a otro como argumento de la firma de una operacin. La dependencia puede tener nombre cuando se requiera calidad por la cantidad de referencias.
96
Ejemplo de Dependiencia
97
Estereotipos de Dependencia
bind
El origen instanca la plantilla destino utilizando los parmetros actuales
derive
El orrigen puede ser calculado a partir del destino
friend
Especifica que el orgien se le otroga una visibilidad especial dentro del destino
instanceOf
Especifica que el objeto orgien es una instancia del clasficador destino
98
Estereotipos de Dependencia
instantiate
El origen crea instancias del destino
powertype
El destino es powertype del origen Powertype es un clasificador cuyos objetos son hijos de un padre dado.
refine
Especifica que el orgien es un grado ms fino de abstraccin que el destino
99
Tipo de Relacin: GENERALIZACIN

Es una relacin entre una cosa general (superclase o padre) y una cosa ms especfica (subclase o hijo).
es-un-tipo-de
Los hijos pueden ser utilizados dondequiera que el padre aparece.
Herencia
Polimorfismo
Una clase sin padre se llama Raz (root)

Tipos: Herencia Simple y Mltiple
100
Tipo de Relacin: ASOCIACIN

Relacin estructural que especifica que objetos de una cosa son conectos a objetos de otra. Son ligas, conexiones o relaciones entre un objeto y uno o ms objetos Existen asociaciones unidireccionales y bidireccionales, as como estticas y dinmicas
Relaciones estticas: El acoplamiento de los objetos perdura por un periodo largo de tiempo Relaciones dinmicas: Son aquellas establecidas por las operaciones
101
Al conectarse 2 clases, se puede navegar bidireccionalmente. Existe recursividad.
Por el # de clases que conectan

Binarias n-Elementos
Adornments
Nombre Rol Multiplicidad Agregacin
102
Asociacin: Nombre
Describe la naturaleza y direccin de la relacin
TrabajaPara
Persona
Empresa
103
Asociacin: Rol
Faceta de la clase en una relacin dada
Los roles pueden ser explcitos

Persona +Empleado +Empleador Empresa
104
Asociacin: Multiplicidad
Cantidad de objetos a ser conectados a travs de una instancia de la asociacin
Persona
1..*
+Empleador
*
+Empleado
Empresa
105
Asociacin: Agregacin
Relacin estructural entre puntos
Las dos clases estn al mismo nivel, no hay una clase ms importante que otra. Todo/Partes o Contenedor/Contenido
Tiene
Empresa
1 *
Departamento
106
Asociacin: Agregacin
Agregacin
Crea objetos compuestos a partir de objetos simples Es la composicin de un objeto como un conjunto de partes Granja
Uvalda Ubre
Lety Leche
Paty Pastura
107
Tipos de asociaciones de agregacin

Existen dos tipos de agregacin
Normal: Es una relacin tiene
Una universidad tiene facultades Un CD tiene pistas Nota: Puede faltar alguna de las partes sin afectar el todo (las partes forman el todo)
Composicin: Es aquella que posee (contiene) a sus partes (fuerte dependencia de propiedad)
Un auto contiene motor, llantas, puertas, ... Un avin contiene motor, asientos, bodega, baos, ... Nota: Si falta alguna de sus partes se afecta el todo (las partes viven el el todo)
108
Taxonoma y generalizacin
Taxonoma (del griego taxis, ordenacin + nomos, ley)
1 Disciplina que estudia los principios, mtodos y fines de clasificacin 2 Clasificacin de cualquier cosa segn unos mtodos establecidos Cuenta
Una generalizacin es una relacin taxonmica entre un elemento ms general y uno ms especfico
Cuenta corriente
Cuenta de inters
Cuenta de depsito
109
Generalizacin y especializacin
Generalizacin implica generalizacin-especializacin de la clase base a la clase derivada
Donde existe una clase general y diferentes clases especializacin
Empleado
es un hereda de
Director Conductor La clase general se llama Administrativo de camiones superclase y las clases especializacin se llaman subclases
Una generalizacin es una relacin es un, es un tipo de, hereda de
110
Generalizacin y herencia
La generalizacin cuando se manifiesta en un lenguaje de programacin se le conoce como herencia La herencia es una relacin entre diferentes clases, las cuales comparten caractersticas comunes
111
Herencia: Definicin
Es un mecanismo para compartir atributos operaciones comunes entre clases, mediante una relacin jerrquica y transitiva, donde una clase hereda de otra sus atributos y operaciones y aade otros nuevos que van a ser exclusivos para ella y sus posibles descendientes, o sea clases que se formen de ella a su vez.
112
Herencia: Definicin
Es el mecanismo por el cual elementos ms especficos incorporan estructura y comportamiento definidos por elementos ms generales.
UML
113
Herencia: Ejemplo
114
Herencia: Ejemplo
Clase: Acadmico
Atributos Direccin Edad Nombre Operaciones Solicitar libros Realizar reportes Hacer abstracciones Desarrollar investigaciones
Estudiante
Atributos Sexo Aos de estudio Programa acadmico
Operaciones Asistir a clases Entregar tareas Hacer tesis
Profesor
Atributos Sexo Especialidad Grado acadmico
Operaciones Impartir clase Generar notas de clase Asignar calificaciones
Comparticin de atributos y operaciones: un objeto es la instancia de una clase
115
Generalizacin y herencia
Una superclase hereda a una subclase y una subclase es heredada por una superclase
Se heredan los atributos, las operaciones y todas las asociaciones
116
Generalizacin, herencia y clases abstractas

Clase abstracta
es aquella que no tiene ningn objeto; i.e., no se pueden crear instancias u objetos
Slo se utiliza para heredar de ella y para describir atributos y comportamientos comunes de otras clases
Vehculo (clase abstracta)
Automvil Automvil deportivo Automvil familiar Automvil turismo Avin militar
Avin Avin de carga Avin de pasajeros

117
Generalizacin, herencia y clases concretas

Clases concretas
Son opuestas de las clases abstractas Es posible crear instancias u objetos de ellas y tienen implementaciones de todas las operaciones
Vehculo (clase abstracta)
Automvil
Automvil deportivo Automvil A Automvil familiar Automvil B Automvil turismo Automvil C Avin militar
Avin Avin de carga Avin de pasajeros

118
Instancias u objetos
Propiedades de la herencia
Permite reutilizacin
Los componentes pueden reutilizarse
Enfoque de reutilizacin bottom-up
Los diseos pueden reutilizarse

Enfoque de reutilizacin top-down
Permite claridad en la descripcin

Debido a que la descripcin de objetos en trminos jerrquicos es una forma fcil y comprensiva de comunicar tanto estructura como funcionalidad
119
Herencia: Ejemplo
120
Polimorfismo
Una misma operacin puede tener comportamientos diferentes segn el objeto que la ejecuta.
Es decir, el mismo mensaje puede tener respuestas diferentes por parte de objetos diferentes.
Sin embargo el sentido de la operacin sigue siendo el mismo para las dos clases.
Luego en este sentido los objetos de ambas clases se dicen polimrficos entre s.
Ejemplo
CalculaArea(int lado) CalculaArea(int largo, int ancho)
121
Polimorfismo
El comportamiento del sistema se define por el comportamiento dinmico de las instancias de las clases Segn Jacobson
Polimorfismo significa que el originador del mensaje no necesita conocer a la instancia de la clase que lo recibe. La instancia receptora puede pertenecer a una clase arbitraria
122
Polimorfismo
El polimorfismo permite que diferentes instancias de diferentes clases estn asociadas Una instancia receptora interpreta las operaciones de acuerdo a la clase a la que pertenece Ejemplo:
El mensaje dibujar se puede interpretar de diferentes formas por las instancias de una clase
123
Polimorfismo: Formas de Aplicacin

Se detecta a travs de la firma de los mtodos
Nombre Nmero de Argumentos
Tipo de Dato de los Argumentos

[Valor de Regreso]
Dentro de la misma clase

Sobrecarga de mtodos (funciones) Caso Especial: Sobrecarga de Operadores
Entre clases de la misma jerarqua

Uso principal del Polimorfismo
124
Principio de Subclasificacin
Liskov
Este principio establece que toda clase B descendiente de una clase A, no importa a que nivel, puede verse haciendo abstraccin como una clase A. O sea, los objetos de la clase B, son tambin objetos de la clase A, pero no a la inversa. Luego cualquier operacin que espere un objeto de la clase A, puede recibir un objeto de la clase B, en tanto los objetos de la clase B saben hacer todas las operaciones que hacen los de la clase A.
125
Principio de Abierto/Cerrado
La mxima utilidad del polimorfismo es la redefinicin de operaciones de las clases bases en las clases derivadas. Cerrado = el software ya elaborado no sufrir modificaciones directas
Reusabilidad
Reusabilidad y Extensibilidad
Abierto = se puede definir nuevo software como especializacin del anterior

Extensibilidad
Aplicacin de la Herencia
126
Implicaciones
La aplicacin ms importante de la herencia es
la simplificacin conceptual del problema al reducir el nmero de caractersticas independientes, y mecanismo para formar complejas estructuras de datos por niveles de construccin desde ms abstractos hasta ms concretos.
El que una clase comparta atributos y operaciones de otra significa tener en cuenta consideraciones como
el encapsulamiento y
el mantenimiento de la consistencia de la clase en las clases derivadas.
127
Problema de Herencia Selectiva

Anulacin de operaciones de la clase base para la clase derivada. Aunque un buen diseo de clases exige que se mantenga el principio de subclasificacin, o sea, todo lo que tenga sentido para una clase base debe tenerlo tambin para sus descendientes, en ocasiones se presentan problemas reales donde se precisa de una herencia selectiva o herencia con restricciones. En el primer caso se heredar slo parte del comportamiento de la clase base, que tenga sentido para la nueva clase, es decir slo una parte de las operaciones. En el segundo, se heredarn todas las operaciones pero algunas de ellas tendrn redefiniciones con restricciones respecto a la forma de sus parmetros.
128
Ejemplo
Aves Color del plumaje Perodo de incubacin
Pingino
Herencia con Anulacin

Volar()
Anidar() Aparearse() comer() Volar()
129
Ejemplo
Rectngulo Ancho Largo Crear( a,l ) Trasladarse() Mostrarse() Ocultarse() Rel_Aspecto( a,l )
Cuadrado
Herencia con Restricciones

Crear( a,a ) Rel_Aspecto( a,a )
130
Herencia: Consistencia
La herencia un mecanismo controlado de redefinicin.
En ocasiones tambin es necesario contar con herramientas (algunos lenguajes las tienen) para lograr herencias que controlen la redefinicin no slo en interfaz sino tambin en implementacin. la clase base se puede adjudicar el derecho de permitir la redefinicin de sus operaciones imponiendo ciertas condiciones a la nueva implementacin que mantengan la consistencia de la clase. Por ejemplo, que despus de la operacin se mantenga una cierta relacin entre los valores de los atributos.
131
Herencia Simple
La clase se define o deriva a partir de una nica clase base
Animal
Mamfero
Hombre
132
Herencia mltiple
Es una forma de herencia en donde una clase hereda la estructura y comportamiento de dos Director clase base Existen varias superclases para una subclase Permite estructuras de clase ms complejas, pero es menos fcil de comprender
Empleado
es un
Administrativo
Empleado eventual
es un
Conductor de camiones
Empleado de bodega
Empleado de oficina
Todologo
133
Ambigedades en la herencia mltiple

Colisin de nombres Herencia incorrecta repetida
A
(A) (A)
(A)
? ?
(A)
134
Persistencia
Un objeto en software ocupa alguna cantidad de espacio y existe para una cantidad particular de tiempo. Existe un espectro de existencia de objetos que va desde objetos transitorios que aparecen dentro de la evaluacin de una expresin, hasta objetos en una base de datos que sobreviven a la ejecucin de un programa. [Atkinson]
Este espectro de persistencia de objetos abarca, entre otras, las siguientes:
Resultados transientes en la evaluacin de una expresin Variables locales en activaciones de procedimientos Variables propias [como en Algol 60] y variables globales
Datos que existen entre las ejecuciones de un programa

Datos que existen entre varias versiones de un programa Datos que sobreviven al programa
135
Persistencia
Los lenguajes tradicionales de programacin usualmente direccionan solo los tres primeros tipos de objetos persistentes, la persistencia de los ltimos tres tipos es tpicamente del dominio de la tecnologa de bases de datos. La persistencia es la propiedad de un objeto a travs de la cual su existencia trasciende en el tiempo (el objeto contina existiendo despus de que su creador deja de existir) y/o en el espacio (la localizacin del objeto se mueve de la direccin en la cual ste fue creado). [Booch]
136
Conclusiones: Caractersticas de la OO
Reduce la brecha semntica entre la realidad y los modelos
Hace que el sistema sea ms fcil de entender

Permite modificaciones locales de los modelos Permite el manejo del cambio Promueve la reutilizacin Asegura la continuidad de la representacin
137
Conclusiones: Debilidades de la OO
Reutilizacin a gran escala an no se lleva a cabo Existen pocas bibliotecas reutilizables La administracin de las bibliotecas reutilizables es un problema debido a su falta de estandarizacin Se requiere un entrenamiento fuerte del personal antes de que se pueda implantar
138
Conclusiones: La OO y los sistemas

Los sistemas pueden ser
Basados en objetos
encapsulamiento + identidad de objetos
Basados en clases
basados en objetos + abstraccin de conjunto
Orientados a objetos
basados en clases + herencia +autorrecursin
139
INTRODUCCIN A UML Y AL ADOO
Alejandro Domnguez
140
Panormica general
Surgimiento y desarrollo de UML
UML como lenguaje de modelado Bloques que componen a UML

La arquitectura de los sistemas
Los modelos en UML

141
Surgimiento de UML
UML (Unified Modeling Language: lenguaje unificado de modelado)
Es el sucesor de los diferentes modelos para llevar a cabo anlisis y diseo orientados a objetos (ADOO) Naci como una unificacin de los modelos de Booch, Rumbaugh (OMT) y Jacobson (The 3 amigos) Es el lenguaje de modelado estndar aprobado por la OMG en 1997
142
Desarrollo de UML
Ada/Booch Booch 91 Booch OOSE Jacobsen RDD Wirfs-Brock OBA Gibson/Goldb.
1990
OOSA Shalaer/Mellor
OMT Rumbaugh et al. Booch 93
OOA Coad/Yourdon
OOSE 94
1995
OMT 94
Fusion Coleman
OODA Martin/Odell
Harel
Cartas de estado UM 0.8 OOPSLA 95 Booch/Rumbaugh SOMA Graham UML 0.9 MOSES Henderson-Sellers
The 3 amigos
1997
UML 1.0 Team Fusion The 3 amigos Notacin Coleman et al. UML 1.1
OPEN/OML Open-Group (+30 colaboradores)
RD Shalaer/Mellor
143
Aceptado por la OMG 11/97
UML como lenguaje de modelado

UML no es un mtodo Un mtodo consiste en un lenguaje y en un proceso para modelar UML es un lenguaje de modelado
Un lenguaje provee un vocabulario y reglas para combinar las palabras en ese vocabulario El modelado conduce a un entendimiento de los sistemas Un lenguaje de modelado es aquel cuyo vocabulario y reglas estn enfocadas a la representacin conceptual y fsica de un sistema
144
Caractersticas de UML
UML es un lenguaje para
Visualizar
Es un lenguaje grfico con una semntica bien definida
Especificar
Permite construir modelos precisos, no ambiguos, y completos
Construir
UML no es un lenguaje de programacin visual, pero los modelos creados con l pueden conectarse directamente a una gran variedad de stos
Documentar
Permite expresar, a cualquier nivel de detalle, la arquitectura, los requerimientos, y las pruebas de un sistema
145
UML y los artefactos del sistema

UML permite modelar los artefactos inherentes de un sistema
requerimientos, arquitectura, diseo, cdigo fuente, planos del proyecto, pruebas, prototipos, versiones, etc.
Dependiendo de la cultura de desarrollo estos artefactos se tratan a un nivel de detalle diferente
146
Bloques que componen a UML

El vocabulario de UML est compuesto por tres grandes bloques
Cosas
Abstracciones en un modelo
Relaciones
Unen o ligan las cosas
Diagramas
Agrupan las colecciones de cosas
147
El bloque de las cosas en UML

Existen 4 tipos de cosas en UML:
Estructurales
Son los sustantivos o nombres de los modelos de UML
Casos de uso, clases, interfaces, componentes, nodos
De comportamiento
Son la parte dinmica de los modelos de UML
Interaccin entre objetos (mensajes y secuencias de accin) y mquinas de estado
De agrupamiento
Son las partes organizacionales en los modelos de UML
Paquetes (mecanismos de propsito general para organizar elementos en grupos)
De notacin
Son las partes que explican los modelos en UML
Notas
148
El bloque de las relaciones en UML

Existen 4 tipos de relaciones en UML:
Dependencia
Es una relacin semntica entre dos cosas en la cual un cambio de una cosa afectar la semntica de otra
Asociacin
Es una relacin estructural que describe un conjunto de ligas (conexiones entre objetos)
Generalizacin
Es una relacin de especializacin/generalizacin en la cual los elementos hijo se sustituyen por elementos padre
Realizacin
Es una relacin semntica entre clasificadores (especifica un contrato que otro clasificador asegura llevar a cabo)
149
El bloque de los diagramas en UML

UML comprende 8 diagramas:
Diagramas de casos de uso Diagramas de clases y objetos Diagramas de secuencia
Un diagrama es la representacin grfica de un conjunto de elementos
Diagramas de colaboracin
Diagramas de estado Diagramas de actividad Diagramas de componentes Diagramas de implantacin
150
Arquitectura de los sistemas (1)

La arquitectura de un sistema se refiere a
Su organizacin
La seleccin de los elementos estructurales, y sus interfaces que lo componen Su comportamiento
expresado como colaboraciones entre sus elementos (o subsistemas)
151
Arquitectura de los sistemas (2)

La arquitectura de un sistema se refiere a (cont.)
La conjuncin de estos elementos estructurales y de comportamiento en sistemas mas grandes
El estilo arquitectnico que gua esta organizacin
los elementos estticos y dinmicos y sus interfaces, sus colaboraciones, y su composicin
152
Modelo de una arquitectura de sistemas
CASOS DE USO DEL SISTEMA
PRUEBA
153
La arquitectura como constructora de modelos

Modelo de requerimientos Modelo de diseo
Modelo de anlisis
CASOS DE USO DEL SISTEMA
Modelo de implementacin
PRUEBA
Modelo de prueba
154
Los modelos y la representacin en UML: alcance del curso

Modelo de requerimientos
Diagrama de clases (primera versin)
Modelo de casos de uso Casos de uso Casos de uso (+ descripciones) Secuencia de las operaciones
Modelo de anlisis
Modelo diseo
Diagrama de clases (+ paquetes) Clases
Asociaciones Atributos de Clases
Diagrama de secuencias Estados de las Diagrama de estado operaciones Definicin de la interfaz 2 Definicin Diagrama de la 155 de clases interfaz 1
MODELO DE REQUERIMIENTOS (MODELADO DE CASOS DE USO )
Alejandro Domnguez
156
Panormica general
Proporcionar las bases del modelo de casos de uso (use cases):
Actores Casos de uso
Notaciones relevantes de UML
157
Entorno del modelo de casos de uso

Modelo de anlisis
Modelo diseo
Asociaciones Atributos de Clases
Diagrama de secuencias Estados de las Diagrama de estado operaciones Definicin de la interfaz 2 Definicin Diagrama de la 158 de clases interfaz 1
Caractersticas de los requerimientos de un sistema

Los requerimientos de un sistema
Necesitan ser los adecuados
Necesitan estar ms enfocados al usuario

Son los primeros en someterse a un proceso de reingeniera Deben involucrar 100% al usuario
Los requerimientos de un sistema deben centrarse en los usuarios
159
Anlisis centrado en los usuarios

En un proceso para capturar los requerimientos desde la perspectiva de los usuarios Seguido de
Anlisis
Explora la conectividad y las consecuencias de los conflictos (diferentes y potenciales) que surgen en los requerimientos del usuario
Tell me what you want, what you really, really want
Diseo
Mapea los requerimientos en una aplicacin de software
160
Obtencin de los requerimientos del usuario

El usuario debe decir que desea El analista debe
Entender el negocio del usuario Conocer las caractersticas de todas las cosas y personas que interactuarn con el sistema Tomar tiempo para explorar las necesidades del usuario Observar y tomar nota de cmo el usuario trabaja
Estructurar la informacin de tal forma que pueda ser utilizada ms tarde en el anlisis y diseo
Descubrir, con ayuda de expertos, las reglas de negocio crticas Enfocarse en el qu y no en el cmo
161
Durante y despus de los requerimientos

El analista debe
Escribir la informacin recolectada de tal forma que el usuario la comprenda Crear una serie de diagramas acerca del negocio del usuario
Ayudan a la comprensin Proporcionan un punto de partida para confirmar los requerimientos reales
Los modelos de casos de uso ayudan llevar a cabo lo anterior
162
Qu es un modelo de casos de uso?

Un modelo de caso de uso:
Describe los servicios que el sistema proporciona al usuario Proporciona informacin acerca de los usuarios (actores) del sistema
Actores: Humanos, otros sistemas, mquinas
Muestra la naturaleza de las interacciones entre el actor y el sistema (casos de uso)

El sistema contiene los casos de uso
Relaciona actores y casos de uso
163
Produccin de un modelo de casos de uso

INPUTS
PROCESOS Derivar posibles actores y casos de uso Discriminar sobre posibles caso de uso Identificar asociaciones entre casos de uso OUTPUTS 1 modelo de casos de uso
Prcticas existentes de sistemas Requerimientos del nuevo sistema
164
Actores
Un actor
Es alguien o algo externo al sistema
Personas, software, hardware, almacenes de datos, o redes
No sigue acciones precisas Representa cualquier cosa fuera del sistema y que interactuar con l
Puede ser humano o un mquina
Los detalles acerca de los actores son no necesarios

SISTEMA Cliente Operador
165
Quines pueden ser actores?

Los usuarios del sistema Los instaladores del sistema
Los operadores del sistema

Los que dan soporte tcnico al sistema Otras sistemas que utilizan el sistema Los que obtienen informacin del sistema Los que proporcionan informacin al sistema
166
Actores primarios
Son aquellos para los cuales se especifica y se construye
Son activos Inician su actividad con el sistema
Usuario de computadoras con la computadora Usuario del telfono con el telfono Cobrador con el sistema de cobranza Interanuta con el visualizador web
167
Obtienen siempre algo a cambio
Actores secundarios
Supervisan, ayudan y mantienen al sistema
Son pasivos: no inician ninguna actividad con el sistema
Slo existen para que los actores primarios puedan utilizar el sistema
Siempre disponibles cuando el sistema necesita de su ayuda
Pueden ser mquinas u otros sistemas

Impresoras, plotters, modems, ...
Aplicaciones adicionales Posiblemente actores humanos
168
Caractersticas de los actores

Un actor no es un usuario en particular
Un actor representa el papel que juega el usuario Un usuario es alguien que juega un papel especfico mientras usa el sistema
Juan Prez es un alumno
Cada actor utiliza el sistema de formas diferentes

De otra forma debera ser el mismo actor
Cada forma en que el usuario utiliza el sistema es un caso de uso
169
Casos de uso (1)

Describen las transacciones ofrecidas por el sistema Representan lo qu el sistema debe proporcionar, en lugar de cmo lo debe hacer
Cmo el sistema proporcionar el servicio no debe ser importante para el usuario
Cuando se utiliza el telfono , no es importante cmo se lleva a cabo la conexin con otro
170
Son iniciados por los actores

Pueden ser llamados por otros casos de uso Pueden ser combinados para ofrecer mayor funcionalidad
Casos de uso (2)

Un caso de uso:
Es una serie completa de caminos de las acciones (con eventos de inicio y trmino, con actores involucrados y objetos utilizados en la accin) y las reglas que gobiernan cmo se ligan esas acciones
Es la definicin de la interaccin entre el sistema y el actor

Incluye los caminos normales y alternativos Es parecido a un proceso de interaccin humano-mquina
171
Casos de uso (3)

Los casos de uso existen debido a las necesidades del usuario
De esta forma se garantiza que el sistema har lo que el usuario espera
Los casos de uso no son escenarios

No son recolectores de un conjunto particular de interacciones entre el usuario y el sistema Los casos de uso surgen a partir de los escenarios
172
Casos de uso y escenarios (1)

Un escenario
Es un orden especfico de eventos
Es una sesin que un actor tiene con el sistema

Tiene detalles de los datos reales y de la salida esperada Puede ser ligeramente diferente que el previo, an cuando se haga esencialmente lo mismo
173

Pueden existir cientos de escenarios en un aplicacin
Los escenarios son importantes fuentes de informacin para descubrir casos de uso
Mas de un escenario se puede generar de un simple caso de uso si una o ms reglas para ligar a las acciones no estn en secuencia estricta
174

Los casos de uso proporcionan un conjunto potencial de escenarios
Observando una familia de escenarios similares, se puede obtener la esencia de lo que se est llevando a cabo
Escenarios similares seguirn patrones similares y proporcionarn tipos similares de resultados
Escenarios
Caso de uso
175

Ejemplo de escenario 1
Juan teclea la cuenta 12345 Juan teclea su NIP 54321 Juan su balance promedio entre 1/1/1995 - 31/12/99 El sistema proporciona el balance promedio
Mara teclea la cuenta 23457 Mara teclea su NIP 75432 Mara su balance promedio entre 1/1/1995 - 30/12/99 El sistema proporciona el balance promedio
Pedro teclea la cuenta 23456 Pedro teclea su NIP 65432 Pedro su balance promedio entre30/11/1999 - 30/12/99 El sistema proporciona el balance promedio
176

Existen dos tipos de escenarios
Primarios
Describen lo que sucede en un flujo normal de interaccin con el sistema
Existen cuando
Todo funciona bien No existen bugs No existen errores
Secundarios
Describen las excepciones encontradas en un flujo normal (flujos alternativos)
Existen cuando
Una accin debe tomarse en algn punto Algo es errneo en algn punto Algn comportamiento que puede pasar en algn momento
177
Descripcin de actores y casos de uso

Cada actor necesita
un nombre descriptivo una breve descripcin de una o dos oraciones de longitud
Las sentencias deben describir al actor con respecto al sistema
Cada caso de uso necesita

Un nombre descriptivo
Una descripcin de una o dos oraciones de longitud

Slo si el nombre no dice suficiente acerca de la funcionalidad del caso de uso
178
Ejemplos de descripcin de actores

Actores
Cliente - una persona quien ordena productos de la compaa Vendedor - un empleado de la compaa quien procesa los pedidos del cliente Mensajera - UPS, FedEx, DHL, MexPost, etc.
Empacador - Un empleado de la compaa que empaca, etiqueta y enva ordenes

Sistema de inventario - software que almacena y procesa la informacin del inventario de productos Sistema contable - software que almacena y procesa la informacin contable
179
Prctica
Tabla de Actores
Nombre del Actor Tipo
Primario Secundario Ambos
Descripcin
180
Ejemplos de descripcin de casos de uso

Casos de uso
Del cliente - elaborar orden, obtener estado de orden, regresar producto, cancelar orden, registrar observaciones
Del vendedor - elaborar orden, obtener estado de orden, regresar producto, cancelar orden, registrar observaciones
A la mensajera - enviar paquetes listos para envo
Del empacador - imprimir etiqueta de correo, calcular cuota postal

Al inventario del sistema - proporcionar informacin del producto, actualizar inventario Del inventario del sistema - capturar las ordenes recibidas Al sistema contable - cargar a cuenta, proporcionar crdito
181
Prctica
Relacin de Actores con Casos de Uso
Actor Direccin Casos de Uso
182
El modelo de casos de uso y la descripcin de sistemas (1)

El modelo de casos de uso caracteriza el comportamiento de todo el sistema y los actores externos
Un sistema se describe por un modelo de casos de uso
El modelo contiene un conjunto finito de casos de uso
183

Un sistema potencialmente tiene un nmero infinito de escenarios
Familias de escenarios generan casos de uso y stos a su vez el modelo de casos de uso
Cada caso de uso en el modelo debe ser numerado, de otra forma el sistema no ser funcionalmente completo
184

Con el modelo de casos de uso el sistema puede ser puesto a prueba en sus entradas (inputs), salidas (outputs) y naturaleza de la interaccin
185
Notacin grfica en un diagrama de casos de uso

Notacin para un actor
Notacin para el sistema
Nombre del actor
Nombre del sistema

Notacin para el caso de uso Nombre del caso de uso Nombre: frase verbal activa o en infinitivo
186
Diagrama bsico de un caso de uso

Nombre del sistema
Nombre del caso de uso
Nombre del actor
187
Actores primarios en un diagrama de casos de uso

Sistema de inversiones Ejecutar orden Actores primarios Corredor de bolsa Verificar inversin
Inversionista
188
Actores secundarios en un diagrama de casos de uso

Sistema de inversiones Actores primarios Ejecutar orden Corredor de bolsa Verificar inversin
Actor secundario
Sistema bancario
Transferir dinero Inversionista
189
Reglas para crear diagramas de casos de uso

Los actores primarios se muestran a la izquierda del diagrama y los secundarios a la derecha
Un caso de uso debe proporcionar un servicio real al usuario Escribir los nombres de los casos de uso dentro de la elipse con el fin de ahorrar espacio
Mantener los diagramas claros y ntidos

No poner demasiados casos de uso en un diagrama
Diagramas sencillos son mas fciles de entender
190
Relaciones de generalizacin en casos de uso

Estas relaciones estn ligadas a los escenarios secundarios Extend
Cuando un caso de uso se extiende a otro al agregar acciones
Include
Cuando un caso de uso incorpora el comportamiento de otro caso de uso en un lugar especfico del primero Verificar balance Validar cuenta <<include>> Prestar efectivo <<extend>> Verificar cantidad prestada
191
Extensiones de casos de uso (extend)

Las extensiones
Permiten al analista cambiar o agregar funcionalidad un caso de uso base, sin alterarlo
Un caso de uso es similar a otro, pero este ltimo hace un poco ms
Se utilizan para modelar partes opcionales de un caso de uso

Caminos alternativos complejos se deben modelar en casos de uso diferentes
192
Diagrama de la asociacin
extend
Sistema de cajero automtico Verificar balance

<<extend>>
Capturar transacciones Prestar efectivo Cliente del banco

<<extend>> <<extend>>
Depositar efectivo
193
Inclusin de casos de uso (include)

La inclusin
Es diferente que la relacin de extensin Es ms una subrutina, ms que una especializacin Aparece cuando un cumulo de acciones es recurrente en muchos casos de usos y se quiere evitar repetir la descripcin de este cumulo
Cada cumulo de acciones deben manejarse de forma separada en otros casos de uso
194
Diagrama de la asociacin
include

<<extend>>
Capturar transacciones
<<extend>>
Prestar efectivo Cliente del banco

<<include>
<<extend>> <<include>
Depositar efectivo
Generar anotacin
195
Herencia en casos de uso y actores

Existe herencia entre casos de uso
En un caso de uso la herencia puede se utilizada entre actores
Debido a que son considerados como clases en UML Cliente
hereda
Herencia entre actores significa que un actor cumple el mismo papel que otro actor y puede jugar papeles adicionales
Cliente del banco

196
Propiedades de la herencia entre actores

Simplifica el diagrama sin perdida de detalle
Cliente del banco
Seala la relacin jerrquica entre actores

El actor receptor obtiene las capacidades del actor padre Los actores padres no notan la presencia de la herencia
Persona fsica
Persona moral
Otro banco
197
Diagrama de la herencia entre actores

<<extend>>
Capturar transacciones Cliente del banco Prestar efectivo

Depositar efectivo
Obtener comisin
Otro banco
198
Consejos para el modelado de casos de uso (1)

Considerar la situacin en la que se utiliza el sistema
Definir las fronteras del sistema

Identificar todos los actores Identificar todas las tareas para las cuales el sistema se utiliza
Identifique todos los caminos alternativos
199
Consejos para el modelado de casos de uso (2)

Revisar constantemente todos el modelo de caso de uso
Distinguir los diferentes casos de uso utilizando frecuencias de uso

Describir nicamente las acciones en las que interviene una interaccin entre el actor y el sistema
200
Ejemplo: el problema
Definir el modelo de casos de uso para un sistema de biblioteca:
Mostrar las relaciones include y extend entre los casos de uso y los casos de uso abstractos Incluir al menos 3 casos de uso:
Caso de uso para la bsqueda de libros Caso de uso para el prstamo de libros Caso de uso para el regreso de libros
Definir los caminos normales y alternativos de los casos de uso
201
Ejemplo: descripcin de actores y casos de uso

Actores
Usuario - persona que interacta directamente con el sistema
Bibliotecario - persona que da soporte al sistema y auxilia al usuario en los servicios de prstamo
Casos de uso
Del usuario - buscar por autor, buscar por ttulo, buscar por clave, buscar por autor-ttulo, reservar libro Del bibliotecario - prestar libro Al bibliotecario - regresar libro
202
Ejemplo: el modelo a documentar

Reservar libro
<<include>> <<extend>>
Autenticar usuario
Usuario
Buscar por autor
Buscar libro
Regresar libro
<<extend>> << include >>
Buscar por ttulo

<< include >>
<<extend>>
Buscar por clave

<<include>>
Bibliotecario
Buscar por autor-ttulo

<<include>>
Prestar libro
203
Accesar datos de libros actuales
<<extend>>
Buscar libros actuales
MODELO DE ANLISIS (DIAGRAMAS DE CLASE)
Alejandro Domnguez
204
Panormica general
Desarrollar las descripciones de casos de uso
Describir los principios de los diagramas de clase Construccin de diagramas de clase a partir del modelo de casos de uso Introducir nuevos tipos de objetos
Determinar los principios para el diseo por etapas
205
El modelo de anlisis
Modelo de anlisis
Asociaciones Atributos Modelo de Clases
diseo
Diagrama de secuencia Estados de las Diagrama de estado operaciones DIAGRAMA Definicin de la interfaz 2 Definicin de la206 DE CLASES interfaz 1
Produccin de un modelo de descripcin de casos de uso

PROCESOS
INPUTS Diagramas de casos de uso Generar descripciones de casos de uso Refinar y completar casos de uso y el modelo Describir y probar interfaces de usuario Describir interfaces del sistema
OUTPUTS 1 modelo de casos de uso Descripciones del caso de uso Descripciones de la interfaz del usuario
207
Descripciones de casos de uso

A cada elipse se debe asociar un texto que describa el caso de uso en mas detalle
El texto puede ser resmenes con palabras clave
Formato bsico
Cada elipse puede incluir condicionales, ramificaciones, y ciclos The rational unified process tiene un formato bsico para describir los casos de uso
Nombre Actores Pre-condiciones Flujo de eventos Post-condiciones Caminos alternativos

208
Elementos del formato bsico de descripcin (1)

Actores
Actores relacionados con el caso de uso
Pre-condiciones
Estado del sistema antes que el caso de uso ocurra
Post-condiciones
Estado del sistema despus de que el caso de uso ha ocurrido exitosamente
209

Flujo de eventos
Serie de declaraciones que listan los pasos de un caso de uso Son el ncleo principal del caso de uso Asociados a los escenarios primarios Alternativas y repeticiones se muestran utilizando ramificaciones o listandolos en la seccin de caminos alternativos
Se utilizan las sentencias

Si ... Entonces ... para indicar alternativas Repetir ... hasta que ... cuando se necesita repetir un paso o un conjunto de pasos al menos una vez Mientras que ... cuando se necesita repetir un paso o un conjunto de pasos al cero ms veces Para (#inicial) hasta (#final) hacer ... Cuando se necesita repetir un paso o un conjunto de pasos un nmero definido de veces
210

Caminos alternativos
Alternativas al camino principal Se utilizan en lugar de una ramificacin cuando la alternativa es compleja Apropiados para mostrar cosas que pueden pasar en cualquier momento
Algo que puede interrumpir el flujo normal de eventos
Excepciones y situaciones de error que pueden ocurrir en el contexto del caso de uso
No son errores tcnico, sino errores relativos al dominio
Prdida de derechos de acceso, imposibilidad de llenados de formas, etc.
211
Ejemplo: el modelo a describir

Reservar libro
Autenticar usuario
Usuario
Buscar por autor
Buscar libro
Regresar libro
<<extend>> << include >>
Buscar por ttulo

<< include >>
<<extend>>
Buscar por clave

<<include>>
Bibliotecario
Buscar por autor-ttulo

<<include>>
Prestar libro
212
Accesar datos de libros actuales
<<extend>>
Buscar libros actuales
Ejemplo: Descripcin de buscar por ttulo

Actores: Usuario
Pre-condiciones: El sistema est en espera de datos de bsqueda

Flujo de eventos:
1. El usuario teclea las palabras clave y entonces presiona el botn de bsqueda 2. El sistema despliega los datos del libro que tiene todas las palabras clave que aparecen en el ttulo
2.1. do include accesar datos de libros actuales
3. Si el libro existe, entonces do extend buscar libro
Post-condicin: El sistema est en posibilidades de reservar el libro
213
Ejemplo: Descripcin de reservar libro (1)

Actores: Usuario
Pre-condiciones: El sistema est en posibilidades de reservar libro
Flujo de eventos:
1. Si el sistema no tiene informacin para autenticar al usuario, entonces do extend autenticar usuario 2. Si el usuario conoce datos del libro y desea reservarlo, entonces introduce datos al sistema y presiona el botn reservar, de otra forma el sistema le informa que el libro no est disponible
214
Ejemplo: Descripcin de reservar libro (2)

4. Si el usuario quiere salir, entonces presiona el botn SALIDA
5. Si el usuario no conoce datos del libro y desea reservarlo, entonces ir casos de uso de bsqueda
Post-condiciones: El sistema hace reservacin
215
Interfaces
Pueden ser definidas por actores, casos de uso, o ambos Dice lo que se espera que la entidad haga No es parte de los actores o casos de uso
Es una descripcin de cmo interactuar con el actor o caso de uso
Puede existir ms de una interfaz para un actor o caso de uso
216
Estructura de las interfaces

Una interfaz tiene un nombre y un conjunto de firmas de operaciones (operation signatures)
Una firma de operacin seala el tipo de dato que se pasa con operacin y el tipo de dato que se pasa cuando la operacin se completa
La operacin seala que se espera que la entidad haga
Ejemplo: Interfaces para el caso de uso buscar por ttulo Buscar por ttulo ( ) Introducir palabras clave (Palabras Clave) Regresar ttulos con palabras clave Presionar buscar libro( )
217
Notacin para interfaces

Interfaz del usuario
Efectuar pedido
Cliente
Indican quin usa la interfaz
Interfaz para ordenar pedidos
Interfaz para bsqueda de pedidos
Cancelar pedido
Vendedor
218
Pantallas para interfaces

Dada la definicin de las interfaces se disean las respectivas pantallas
Omitir pantallas de error y de informacin No invertir demasiado tiempo en la apariencia TTULO
CAMPO 1 CAMPO 2 CAMPO 3
OK
Cancelar
219
Mapa de navegacin de interfaces (1)

Una vez diseadas las interfaces se debe hacer un mapa de navegacin entre ellas
El mapa de navegacin seala la secuencia de la interaccin humanomquina va las interfaces de usuario
Notacin
Rectngulo = pantalla
Seala que otra pantalla ser invocada
Circulo = pantalla hoja

Seala que ninguna otra pantalla ser invocada
Cada rectngulo y circulo contienen ttulo y el nmero o nombre del caso de uso
Flecha unidireccional = flujo entre interfaces Flecha bidireccional = cancelar 220 y regresar
Mapa de navegacin de interfaces (2)

TTULO
CAMPO 1
Login UC001 Pantalla Principal UC002
CAMPO 2
CAMPO 3
OK
Cancelar
Despliegue de Horario UC003
Despliegue de Materias UC004
Confirmacin
221
Recomendacin para las interfaces

Definir un nmero considerable de pequeas interfaces Esto hace el sistema ms flexible para cambios futuros debido a que
Una interfaz completa se puede agregar o remover fcilmente, ms que cambiar una existente Se puede utilizar una misma interfaz con un actor o caso de uso Se pueden reutilizar
222
Documentacin final del sistema por casos de uso (template)

1. Nombre del sistema 2. Breve descripcin del sistema 3. Actores y casos de uso 4. Casos de uso 4.x. Nombre del Caso de Uso Actores Pre-condiciones Flujo de eventos Post-condiciones Caminos alternativos Interfaces 5. Diagrama de casos de uso 6. Diagrama de secuencias de interfaces
223
El modelo final de casos de uso
FASES DE PRODUCCIN
224
El modelo final de casos de uso (continuacin)
FASES DE PRODUCCIN
225
Produccin de un diagrama de clases

Propsito: Proporcionar un modelo lgico del software del sistema
OUTPUTS PROCESOS INPUTS

Modelo de casos de uso y descripciones Listado de objetos en el dominio del problema Bosquejar el diagrama de clases inicial Reexaminar el comportamiento de en los casos de uso y los objetos Refinar el diagrama de clases Efectuar verificaciones de los diagramas Revisar diagramas de clase Agrupar clases en paquetes Diagramas de clase incluyendo descripciones de las clases Asociaciones entre clases El papel que juegan las clases Jerarquas de herencia
226
Descripcin de objetos atributos y operaciones

En las descripciones de los casos de uso
Los objetos y las clases se determinan subrayando cada sujeto o sustantivo
Los atributos se determinan subrayando todos los adjetivos asociados a sus respectivos objetos Las operaciones se determinan subrayando todos los verbos y frases verbales asociados a los respectivos objetos
227
Clases en UML
Existen dos notaciones posibles:
Nombre de la clase
Polgono
centro: punto vrtices: lista de puntos color del borde: color color de relleno: color despliegue (on: superficie) rotar (ngulo: entero) borrar ( ) destruir ( ) seleccionar (p: punto): boolean)
Nombre del atributo: tipo
Operacin (parmetro: tipo): tipo de resultado
Nombre de la clase
Polgono
228
Objetos en en UML
Existen dos notaciones posibles:
Nombre del objeto Triangulo1: Polgono
centro = (0,0) vrtices = (0,0), (4,0), (4,3) color del borde: negro color de relleno: blanco despliegue (on: superficie) rotar (ngulo: entero) borrar ( ) destruir ( ) seleccionar (p: punto): boolean)
Nombre del atributo: tipo
(mismas operaciones para todas las instancias de una clase)
Nombre del objeto: Nombre de la clase
Triangulo1: Polgono
229
Generalizacin en UML
Superclase
Personal
Bibliotecario
Subclase
Instructor
Subclase Manejador
Investigador
Subclase
Manejador de teclado
Manejador de mouse
Manejador de joystick
230
Asociaciones en UML (1)

asociacin navegacin (permite comunicacin por medio del envo de mensajes) composicin (todo contiene partes) ventana contiene men, botn, ... (el todo posee a sus partes) (las partes viven en el todo) agregacin (todo tiene partes) la universidad tiene facultades (las partes componen el todo)
231
todo
partes
todo
partes
Asociaciones en UML (2)

ciudad nombre poblacin
es capital de
Asociacin simple
pas nombre poblacin
/es yerno de
Asociacin derivada Joven nombre es novio de
Joven nombre
Joven nombre
232
Asociaciones (3)
empresa persona trabaja para nombre nombre empleado #IMSS domicilio empleador Roles Muchos Exactamente uno Cero o ms Uno o ms Cero o uno Rango especificado
1
0.. 1.. 0..1 2..4, 7
233
Ejemplos de asociaciones en UML

Usuario
Notacin para clase asociada
autorizar en >
Estacin de trabajo
1 1
Nombre atributos
operaciones
Autorizacin prioridades privilegios iniciar sesin terminar sesin

1
Atributo
Operacin
Directorio
234
Estereotipos
Se utilizan para especificar la semntica de elementos ya definidos en UML Son elementos generalizables (se pueden especializar o generalizar) Se pueden especificar en una clase delante del nombre de la clase
Indican que tipo de clase es y se indica como << >>

Se sitan encima o delante del nombre del elemento <<Actor>> <<nico>> <<GUI>>
Cliente Gerente Ventana
235
3 estereotipos importantes
Clases interfaz
Para todo lo relacionado las interfaces del sistema
Clases entidad
Para informacin persistente y el comportamiento acoplado a ella
Clases control
Para funcionalidad no necesariamente atada a otras clases
236
Estereotipos: Clases interfaz

Contienen la funcionalidad directamente dependiente del entorno del sistema
Se centran en la interaccin entre los actores y los casos de uso
<<interface>> Impresor de recibo imprimir (recibo) <<interface>> Dispositivo de alarma sonido (alarma)
237
Estereotipos: Clases entidad y sus atributos

Almacenan informacin que persiste despus de completar un caso de uso Definen el comportamiento para manipular esta informacin Las operaciones se caracterizan por:
almacenar y obtener informacin <<entidad>> Depositar artculo Nombre: cadena valor depositado: ECU Total diario: entero Crear () Obtener_valor (entero) Incremento ()
crear y remover objetos

el comportamiento cambiante si el objeto entidad cambia <<entidad>> Lata
<<entidad>> Botella
<<entidad>> Caja
238
Estereotipos: Clases control

Son necesarias para:
Definir el comportamiento no natural en las clases interface y entidad
Fungir como goma de pegar entre clases en casos de uso Definir comportamientos tpicos de control Mejorar el mantenimiento del sistema
<<control>> Controlador Verificar_validez () Calcular_total () Mandar_a_imprimir () <<control>> Generador de reportes Compilar (Reporte) Monitorear (Reporte) Imprimir (Reporte)
239
Explotacin de los casos de uso para dibujar diagramas de clase

Emplear clases, casos de uso, descripciones de casos de uso, listas de objetos, clases, atributos y operaciones para
definir el primer bosquejo de las clases y los atributos
definir asociaciones entre clases

describir roles y responsabilidades de cada clase distribuir el comportamiento especificado en los casos de uso para cada clase asegurar que existe una clase para cada comportamiento revisar y refinar el diagrama
producir una vista del caso de uso, i.e., un diagrama de clases para cada caso de uso
producir un nico diagrama de clases para todos los casos de uso240
241
Paquetes (1)
Son consecuencia del gran nmero de clases existentes en un sistema Son necesarios para:
Proporcionar funcionalidad opcional Minimizar los efectos del cambio
Deben poseer
Acoplamiento interno fuerte Acoplamiento externo dbil
242
Paquetes (2)
Pueden
Contener paquetes anidados con paquetes de servicio como partes atmicas Tener clases individuales fuera de ellos Ser el resultado de problemas organizacionales o administrativos
243
Ejemplo de paquetes
<<subsystem>> Editor Controler
Diagram elements
Domain elements
Graphics core
WindowsCore Motif
Windowing system
MotifCore
Microsoft Windows244
Modelo de anlisis
ETAPAS DE PRODUCCIN
245
EL MODELO DE DISEO (DIAGRAMAS DE SECUENCIA)
Alejandro Domnguez
246
Panormica general
Definir la relacin entre el anlisis y el diseo
Definir las fases de diseo

Sealar el impacto que tiene el ambiente de implementacin Definir los diagramas de secuencia
Crear clases interfaz

247
El modelo de diseo I
Diagrama de clases (primera versin) Modelo de casos de uso Casos de uso Casos de uso (+ descripciones) Secuencia de las operaciones
Modelo de anlisis
diseo
Diagrama de secuencia Estados de las Diagrama de estado operaciones DIAGRAMA Definicin de la interfaz 2 Definicin de la DE CLASES interfaz248 1
Contenido del modelo de diseo

INPUTS
Especificacin de requerimientos relacionados al ambiente de implementacin Modelo de anlisis y diagramas de clase Descripciones de los casos de uso
OUTPUTS
PROCESOS
Identificar el ambiente de implementacin Modelar el diseo inicial del diagrama de clases Disear el control de flujo Definir la clase interfaz Modelar diagramas de estados Finalizar el diseo del diagrama de clases Diagramas de secuencia (un diagrama por caso de uso) Diagramas de estado (un diagrama por clase) Modelo de diseo completo (diagramas de clase) 249
Diagramas de clase con UML en anlisis y diseo
DIAGRAMAS DE CLASE EN EL ANLISIS Modelo conceptual del sistema
DIAGRAMAS DE CLASE EN EL DISEO Construccin del sistema

250
MISMA NOTACIN, DIFERENTE PERSPECTIVA
El ambiente de implementacin
Factores que intervienen
Sistema operativo Lenguaje de programacin Sistema de administracin de la interfaz de usuario Administrados de bases de datos Bibliotecas reutilizables
ANLISIS
DISEO AMBIENTE DE IMPLEMENTACIN
Procesos de desarrollo
251
Ejemplo: Cambios debido al lenguaje de implementacin

Utilizacin de un lenguaje que no soporta herencia mltiple (e.g. Java)
<<entidad>> Empleado <<entidad>> Empleado de tiempo completo <<entidad>> Director <<entidad>> Empleado de tiempo parcial <<entidad>> Secretaria <<entidad>> Secretaria de tiempo parcial <<entidad>> Empleado <<entidad>> Empleado de tiempo parcial <<entidad>> Secretaria 1..1 tiempo parcial
<<entidad>> 1..1 Secretaria de tiempo parcial 252
Etapas iniciales del diseo
? ? ? Traduccin del modelo de anlisis al modelo de diseo ?
Diseo del flujo de control
Adaptacin al medio ambiente y revisar

253
Diagramas de secuencia
De todas la tcnicas de modelado de UML, esta es probablemente la ms compleja Son tiles para decidir y modelar cmo el sistema llevar a cabo lo que se describi en el modelo de casos de uso Ayudan a asignar responsabilidades a las clases y objetos Ayudan para que se pueda comprender en un programa OO el flujo de control (secuencia) general de los objetos
254
Receta para la creacin de un diagrama de secuencia (1)

1. Tomar la descripcin un caso de uso y convertirla en pseudocdigo colocandola a la derecha del diagrama 2. A partir de la descripcin del caso de uso, seleccionar las clases que se tomarn en consideracin 3. Para cada uno de los pasos en pseudocdigo, decidir cuales clases tienen la responsabilidad de hacer qu tarea
255
Receta para la creacin de un diagrama de secuencia (2)

4. Para cada una de las tareas, dividirlas en tarea menores 5. Agregar lo correspondiente para los include y extend del caso de uso 6. Considerar los posibles errores importantes que no fueron cubiertos por el modelo de casos de uso 7. Considerar los nuevos descubrimientos de necesidades y alimentarlos al modelo de casos de uso
256
Diagrama de secuencias en UML: La notacin

Muestra interacciones entre un conjunto de objetos en forma temporal
Convenciones de notacin: tiempo
Objetos: Su existencia se muestra como una lnea vertical (lnea de vida)
crear
A f( )
B crear g( )
Mensajes: Lneas horizontales etiquetadas con el nombre del mensaje y sus valores del argumento Tiempo de activacin del objeto: Rectngulos delgados Destruccin de objetos: Denotado por X
h( )
destruir
257
La forma tenedor en los diagramas de secuencia

Descripcin Tarea principal Hacer esto Hacer esto Hacer esto
Clase 1: objeto Tarea principal Clase 2: objeto
Clase 3: objeto
Clase 4: objeto
Hacer esto Hacer esto
Hacer esto
258
Ejemplo de la forma tenedor

Descripcin Obtener direccin
Obtener direccin
:Cliente Direccin: Direccin de cliente
Obtener nmero telefnico
259
La forma escalera en los diagramas de secuencia

Descripcin Tarea principal Hacer esto Hacer esto Hacer esto
Clase 1: objeto Tarea principal Clase 2: objeto
Clase 3: objeto
Clase 4: objeto
Hacer esto Hacer esto
Hacer esto
260
Ejemplo de la forma escalera

Descripcin
:Cliente Direccin: Direccin del cliente
Obtener telfono
261
Ejemplo: Telfono celular (marcado)

Dgito: Botn
:Adaptador DgitoBotn
Marcador
Display: DisplayMarcador
:Altavoz
BotnPresionado( )
Dgito( ) DespliegueDgito(cdigo )
EmitirTono( cdigo)
El rectngulo que encierra al grupo de mensajes define una iteracin
Para cada dgito
La condicin del ciclo se muestra en la base del rectngulo
262
Ejemplo: Telfono celular (send)

Mandar: Botn :Mandar AdaptadorBotn :Marcador :Celular Diplay: DisplayCelular
BotnPresionado( ) Send( ) Conectar( ) EnUso( )
263
Ejemplo: Telfono celular (conectar y desconectar)

:Marcador :Celular
Conectar( ) Crear( ) Conectar( ) ConexinEstablecida( )
:Conexin
Fin( )
Desconectar( ) Desconectar( ) Destruir( )
264
Ejemplo: Cajero automtico

:Interfaz del cajero : Cliente Solicitar NIP
:despachador
Verificar NIP ( )
:retirador
:cuenta
Solicitar monto y nmero cuenta
retirar ( ) Dar dinero Proporcionar saldo ( )
Dar dinero
265
EL MODELO DE DISEO (DIAGRAMAS DE ESTADO)

Jorge Kashiwamoto
266
Panormica general
Definir el concepto de Evento, Actividad y Estado
Comprender las partes de un Estado y de Transicin

Analizar ejemplos de diagramas de Estado Comprender distintos tipos de diagramas de Estado
267
El modelo de diseo I
Diagrama de clases (primera versin) Modelo de casos de uso Casos de uso Casos de uso (+ descripciones) Secuencia de las operaciones
Modelo de anlisis
diseo
Diagrama de secuencia Estados de las Diagrama de estado operaciones DIAGRAMA Definicin de la interfaz 2 Definicin de la DE CLASES interfaz268 1
Representacin del Comportamiento

Modelado del aspecto Dinmico
Interaccin
Comportamiento de una sociedad de objetos
Mquina de Estados
Comportamiento de un objeto
269
Mquina de Estados
Secuencia de estados del tiempo de vida de un objeto, suscitados por Eventos
Seales Operaciones Dependiendo del Estado Actual del Objeto Ejecucin de una Actividad
El paso del Tiempo
Ocurrencia de un Evento
270
Evento
Especificacin de una ocurrencia significativa que tiene una ubicacin en el tiempo y el espacio Ocurrencia de un estmulo que dispara la transicin de un estado
271
Actividad
Ejecucin no-atmica dentro de una maquina de estados Produce
Cambio de Estado Regresa un valor Dependiendo del Estado Actual del Objeto Ocurrencia de un Evento Ejecucin de una Actividad Cambio de Estado del Objeto
272
Estado
Condicin o situacin de un objeto durante su tiempo de vida, en la cual
Satisface una condicin Realiza alguna actividad
Espera la ocurrencia de un evento
La respuesta es afectada por el pasado

273
Transicin
Relacin de cambio entre 2 estados
Adeudo
Pagar
Pagado
Transicin
274
Visualizacin de una Mquina de Estados

Por el Flujo de Control
DIAGRAMA DE ACTIVIDAD
Por los Estados Potenciales y sus Transiciones

DIAGRAMA DE ESTADOS
275
Caractersticas de una Mquina de Estados

Una mquina de estados bien estructurada es:
Eficiente Simple
Adaptable
Entendible
276
Representacin de un Estado
ESTADOS NOMBRE ESTADO FINAL
envo Solicitado
Entregado
devolucin ESTADO INICIAL

277
Partes de un Estado
Nombre
Acciones de Entrada/Salida
Transiciones internas
Subestados
Eventos Diferidos
Actividad
Solicitado entry/ ponBitcora(PrdCve,SolEnt) exit/ponBitcora(PrdCve,SolOut) nuevoDestinatario / Producto.CambiaDest() do / EsperaMensajera descuentaInv / defer

278
Partes de una Transicin

Estado Origen Disparador de evento
Event Trigger
Condicin de transicin
Guard Condition
Accin Estado Destino

279
Partes de una transicin

EVENTO DE TIEMPO ENVO DE SEAL despues(24 horas)/send o.RevExist AUTOTRANSICIN DISPARADOR Solicitado EnInventario pedido ConProveedor TRANSICIN SIN DISPARADOR
Autoriza(PrdCve) [cobroValido] Pagado Entregado envo / m.AgregaEnvo ACCIN GUARD CONDITION DISPARADOR DE EVENTO CON PARAMETROS
280
Subestados secuenciales
TRANSICION DE/A ESTADO COMPUESTO insertarTarjeta Validando ESTADO COMPUESTO SUBESTADO SECUENCIAL Activo
Desocupado
cancelar mantener
Seleccionando
[continuar] Procesando
[no continuar]
Mantenimiento
TRANSICION DE SUBESTADO
entry/leerTarjeta exit /expulsarTarjeta
Imprimiendo
281
Subestados histricos
ESTADO INICIAL PARA LA PRIMERA ENTRADA Respaldando Comando
Acumulado
consulta
ESTADO HISTRICO SHALLOW
Copiado
Borrado
282
Subestados concurrentes
SUBESTADOS CONCURRENTES FORK mantener Desocupado JOIN
ESTADO COMPUESTO
Mantenimiento Probando Probando Dispositivos Ordenando Auto Diagnsticos
[continuar] Esperando keyPress Comando

[no continuar]
283
EL MODELO DE DISEO (DIAGRAMAS DE COLABORACIN)

Jorge Kashiwamoto
284
Panormica general
Comprender la utilizacin de los diagramas de colaboracin:
Fundamentos
Relacin con Diagramas de Secuencia Elementos Flujos de Control Usos
Pasos de la Aplicacin Metodolgica

285
Diagrama de colaboracin
Tipo de diagrama de interaccin
Modela el aspecto dinmico

Interaccin = Conjunto de objetos y sus relaciones (mensajes) Enfatiza la Organizacin Estructural de los objetos que mandan y reciben mensajes
286
Elementos de un diagrama de colaboracin

Objetos
Ligas
Mensajes
287
Elementos
objeto
c:Cliente liga o enlace <<local>> 1: <<crea>> 2: ponAcciones(a,d,o) estereotipo 3: <<destruye>> de ruta mensaje :Transaccin {transient} objeto <<global>> p:ODBCProxy
2.1: ponValores(d,3.4) 2.2: ponValores(a,CO) secuencia

288
Diferencias con el diagrama de secuencia

Primera
RUTA
Cmo un objeto se liga con otro
<<local>> el objeto es local al objeto cliente <<global>> <<parameter>> <<self>>
289
Diferencias con el diagrama de secuencia

Segunda
NUMERACIN DE LA SECUENCIA
Indicacin del Orden de Ejecucin Se precede cada mensaje con un nmero Numeracin decimal Dewey para subsecuencias
290
Flujos
Flujo Secuencial de Control Flujos Complejos
Iteracin
Precediendo con
* *[ i := 1..n]
Salto
[condicin_booleana] Ramas con la misma numeracin
Las expresiones pueden ser pseudocdigo o de algn lenguaje en particular.

291
Equivalencia semntica
Los diagramas de colaboracin y de secuencia tienen equivalencia semntica. Aunque no necesariamente explcitamente visualicen la misma informacin.
292
Cundo usar diagramas de colaboracin?

Enfatizar las relaciones estructurales entre las instancias de la interaccin (mensajes) Visualizar iteraciones y saltos complejos Visualizar mltiples flujos concurrentes de control
293
Pasos
1. Establecer el contexto
(sistema, subsistema, operacin, clase, escenario de caso de uso, colaboracin)
2. Identificar los objetos.

Colocarlos como vrtices Los objetos ms importantes van al centro
294
Pasos
3. Establecer los valores iniciales de cada uno de estos objetos
(valores, estados, roles, instanciacin mltiple become, copy -)
4. Especificar la liga entre los objetos y los mensajes a ser utilizados

4.1 Trazar las ligas de asociacin: Conexiones estructurales 4.2 Trazar otras ligas y catalogarlas con Estereotipos de Ruta (global, local)
295
Pasos
5. Iniciar el trazo de mensajes
5.1 Comenzar con el mensaje que inicia la interaccin 5.2 Aadir mensajes subsecuentes 5.3 Aplicar la secuencia de numeracin
6. Si es necesario, aplicar restricciones de tiempo o espacio. 7. Un control ms formal implica precondiciones y postcondciones para cada mensaje.
296
Otros consejos
Usualmente los diagramas de secuencia muestran un flujo de control Tpicamente, se tienen varios diagramas de interaccin
Primarios
Rutas alternativas
297
2: agregarEstudiante(s)
r:RegistrarAgente
1: <<crear>> 3: registrar() 3.1: obtenItinerario()
:Escuela
<<local>>
{self}
s:Estudiante registrado = False

3.2: agrega(s)
s:Estudiante registrado = False
3.4: <<become>> 3.3: agrega(s)
c1:Curso
c2:Curso
{association}
298
{association}
Diagramas de Interaccin Bien Estructurados

Se enfoca en un aspecto de la dinmica del sistema Contiene solamente aquellos elementos que son esenciales para entender un aspecto del sistema Provee detalles consistentes con su nivel de abstraccn y aquellos adornments esenciales No es demasiado general ni exageradamente detallado
299
EL MODELO DE DISEO (DIAGRAMAS DE ACTIVIDAD)

Jorge Kashiwamoto
300
Panormica general
Comprender la utilizacin de los diagramas de Actividad:
Fundamentos
Relacin con Diagramas de Secuencia Elementos Flujos de Control Usos
Pasos de la Aplicacin Metodolgica

301
Diagrama de actividad
Muestra el Flujo de Actividad a Actividad
Modela el aspecto dinmico de una sociedad de objetos

Modelado de pasos
Secuencia (de un procedimiento computacional) Concurrente
302
Diagrama de actividad (2)

Modela el Flujo de un Objeto, de cmo se mueve de un estado a otro en los diferentes flujos de control. Comprando con D. de Interaccin:
D.Interaccin: Flujo de control de objeto a objeto.
D.Actividad: Flujo de control de actividad a actividad.
303
Actividad
Ejecucin no atmica dentro de una mquina de estados. Las actividades resultan en una Accin (clculos atmicos ejecutables):
Cambio de Estado
Regreso de un Valor
304
Acciones
Agrupan a
La llamada a otra operacin Enviar una seal Crear o destruir objetos
Clculos puros
V.g.: Evaluar una expresin
305
Ejemplo
estado inicial
Seleccionar Lugar Comisionar Arquitecto Desarrollar un Plan
estado de accin
Autorizar Plan [no aceptado]
salto secuencial
[else] Elaborar Construccin
estado de actividad con submquina
fork concurrente
Hacer Negociaciones()
join concurrente
Finalizar Construccin
:Escrituras
[Completo]
estado final
flujo de objeto
306
Estados Accin
Representan una accin
No pueden descomponerse, es atmico

No puede interrumpirse
Tiempo de ejecucin insignificante
307
Estados Accin
expresin
Autorizar Plan
accin sencilla
i := Sqrt(j) + 1
308
Estados Actividad
Pueden descomponerse
Su actividad est respresentada por otros diagramas de actividad No son atmicos, pueden interrumpirse Se considera que toma algn tiempo en ejecutarse Un Estado Accin es un subcaso del Estado Actividad
309
Estados Actividad
Estado Actividad =
+ Estados Accin + Estados Actividad
Partes
Accin de Entrada Accin de Salida Especificaciones de Submquina
310
Estados Actividad
Hacer construccin
entry/Bloquea()
Procesar Factura(f)
Accin de Entrada
Submquina
311
Transiciones
Es el paso de un estado accin o actividad a otro, una vez que ste se ha completado. Se representan con lneas con puntas de flecha dirigidas
Se denominan de tipo sin disparador o triggerless.

312
Saltos
Especificacin de rutas alternativas basadas en expresiones Booleanas. Se representa con un rombo a partir del cual, se tienen ms de una transicin alternativa especificadas con Guard Conditions entre corchetes. Se usa la palabra reservada else Pueden modelarse iteraciones.
313
Fork / Join
Modelar actividades concurrentes
Pueden anidarse
Se representan con lneas horizontales a partir de las cuales salen las transiciones iniciales o llegan las finales de los estados concurrentes.
314
Swimlanes
Grupos o particiones de estados de actividad segn la organizacin de negocio responsable.
Modelar flujos de trabajo de Procesos de Negocio.
Se representan con rectngulos etiquetados con la unidad organizacional dentro de los cuales se agrupan los estados.
315
Flujos de Objeto
Modela los objetos (particulamente con estado) que pasan de un estado a otro. Se representa como se hace convencionalmente en UML y se une con lneas rayadas dirigidas entre los estados.
316
Aplicacin Metodolgica para Flujos de Trabajo

1. Establecer el foco del flujo de trabajo 2. Seleccionar los objetos de negocio de alta nivel de responsabilidad 3. Identificar las precondiciones para el estado inicial y las postcondiciones para el estado final 4. Se trazan los elementos
317
Flujos de Trabajo
5. Para acciones o conjunto de acciones complicadas, se colapsan en estados Actividad. 6. Trazar las transiciones, comenzar con las secuenciales, saltos y concurrentes en este orden. 7. Se grafican los objetos importantes con sus valores o estados.
318
Ejemplo
Cliente
Solicita Devolucin Dar Folio Enviar Artculo
Ventas
Contabilidad
Almacn
Recibir Artculo
i:Artculo
[Regresado]
Resurtir Artculo Registrar
i:Artculo
[Disponible]
319
Aplicacin Metodolgica para Operaciones

1. Se agrupan las abstracciones involucradas en la operacin (parmetros, atributos y clases) 2. Identificar precondiciones al estado inicial y postcondiciones al estado final. 3. Comenzar con el trazado de estados. 4. Especificar saldos y concurrencia.
320
EL MODELO DE IMPLANTACIN (DIAGRAMAS DE COMPONENTES)

Jorge Kashiwamoto
321
Panormica general
Comprender la utilizacin de los diagramas de componentes:
Fundamentos
Relacin con Clases Relacin con Interfaces Reemplazo Binario Tipos
Ejemplos
322
Diagrama de Componentes
Modelado de Aspectos Fsicos del Sistema
Muestra de un conjunto de componentes

la Organizacin, y la Dependencia
Modela una vista de implantacin esttica de un sistema

323
Involucra el modelado de cosas fsicas que residen en un NODO
Ejecutables Bibliotecas
Tablas
Archivos Documentos
324
Definicin
Visualiza
Un conjunto de componentes y Sus relaciones
Grficamente es un conjunto de
Vrtices Arcos
325
Componente
Parte fsica y reemplazable de un sistema que conforma la realizacin de un conjunto de interfaces
kernel32.dll
326
Nombre de un componente
Interfaz (Servicios)
FraudAgent.dll Realizes FraudAgent FraudPolicy FraudSearch
agent.java
system::dialog.dll
{versin=2.1.75}
RUTA (V.g. Paquete)

327
Componentes y Clases
Semejanzas
Nombre Realizan un conjunto de interfaces Participan en relaciones de
Dependencia Generalizacin y Asociacin
Anidarse
Tienen instancias
Participan en interacciones
328
Representacin fsica Empaquetamiento fsico Operaciones a travs de interfaces Representacin lgica Nivel de abstraccin Acceso a atributos y operaciones
329
Diferencias
Residen en un nodo Implementacin fsica de un conjunto de elementos lgicos (clases y colaboraciones) Servicios disponibles solo por interfaces
330
Otro Caso Diseo lgico contenible en otros elementos Servicios configurables
FraudAgent.dll
COMPONENTES
FraudAgent
PatternSearch
FraudPolicy
CLASES
331
Componentes e Interfaces
Interfaz
Coleccin de Operaciones que utilizada para especificar un servicio de una clase o componente. Son el pegamento entre los diferentes componentes (se requiere infraestructura basada en componentes del sistema operativo)
COM+ CORBA Enterprise Java Beans
332
Componentes e Interfaces
Descomposicin de la Implementacin Fsica
Proveer componentes que realicen las interfaces

Este mecanismo permite implantar sistemas cuyos servicios son location-independent, o remplazables.
333
FORMA ICNICA
image.java
ImageObserver
component.java
FORMA EXPANDIDA
<<interface>> ImageObserver abort: int {final static} error: int {final static}
imageUpdate():Boolean
334
image.java
component.java
Reemplazo binario
Partes reemplazables binarias en el Sistema Operativo No implican reconstruccin o recompilacin inmediata
Extensibilidad a travs de interfaces
335
Reemplazo binario
Un componente es
Fsico Reemplazable
Sustituible Mismas Interfaces
Parte del Sistema

Arquitectura Tecnologa
Conforma y provee un conjunto de interfaces

336
Tipos de Componentes
De Implantacin
Necesarios y suficientes para generar sistemas ejecutables
.EXE .DLL o equivalente Tablas, Pginas Web dinmicas, modelos de objetos, otros ejecutables, etc.
Productos de Trabajo
Fuentes Archivos de Datos
De Ejecucin
Aquellos que slo existen en el ambiente de ejecucin
Objeto COM+ instanciado
337
Elementos Estndares
Ejecutable (Executable) Biblioteca (Library)
Esttica o Dinmica
Tabla (Table) Archivo (File) Documento (Document)

338
Modelado de Ejecutables y Bibliotecas

animator.exe
{versin=5.0.1} dlog.dll
render.dll raytrce.dll
wrfrme.dll
339
Modelado de Tablas, Archivos y Documentos

animator.hlp dlog.dll
animator.exe
{versin=5.0.1}
animator.ini
render.dll raytrce.dll shapes.tbl
wrfrme.dll
340
Modelado de APIs
animator.exe
{versin=5.0.1} IScripts
IRendering
IApplication
IModels
341
Modelado de Cdigo Fuente

render.h
{versin=5.3}
render.cpp
{versin=5.3.7}
rengine.h
{versin=4.6}
poly.h
{versin=4.1}
colortab.h
{versin=4.1}
342
EL MODELO DE IMPLANTACIN (DIAGRAMAS DE IMPLANTACIN o DEPLOYMENT)

Jorge Kashiwamoto
343
Panormica general
Comprender la utilizacin de los diagramas de Deployment:
Fundamentos Nodos
Relacin con componentes Paquetes
Conexiones Atributos
Usos
344
Diagramas de Deployment
Modelado de los Aspectos Fsicos del Sistema Junto con el de componentes son los 2 diagramas en este nivel
Muestra la configuracin de los nodos de procesamiento en tiempo de ejecucin y los componentes residentes en ellos
345
Modela una vista de implantacin esttica
Modela la topologa del hardware donde se ejecuta la aplicacin

Esencialmente son diagramas de clase enfocados a nodos en el sistema
346
Visualiza el aspecto esttico de los nodos fsicos y sus relaciones; as como los detalles de su Modem bank construccin
Internet
Nodos
<<processor>> caching server <<processor>> caching server
Nodos
Conexin
<<network>> local network
<<processor>> primary server
<<processor>> server
347
Elementos de un Diagrama de Deployment

Nodos
Relaciones de
Dependencia Asociacin
348
Nodo
Elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional
mi_server
Nombre
349
Nombres de Nodo
Nombres extendidos
ventas
Nombres simples
mi_server
Deploys pos.exe contacts.exe
Package
server::backup {remoteAdministrationOnly}
350
Semejanzas entre Nodos y Componentes

Nombres Relaciones
Dependencia Generalizacin Asociacin
Anidarse Tener instancias
Participar en interacciones
351
Diferencias entre Nodos y Componentes

Ejecutan componentes Representan la implantacin fsica de componentes Participan en la ejecucin de un sistema Representan el empaquetamiento fsico de otros elementos lgicos
352
Relacin entre nodos y componentes

ventas
pos.exe
contacts.exe
353
Nodos y Paquetes
Los nodos pueden ser agrupados en paquetes
Servidores
server_1
server_backup
354
Conexiones
Asociaciones entre nodos
cajero
Conexin
<<10-T Ethernet>>
server
RAID Array
consola
<<RS-232>>
355
tributos y adornments
:cajero Deploys user.exe
<<10-T Ethernet>>
s : server processorSpeed = 300 MHz memory = 128 Mb Deploys dbadmin.exe tktmstr.exe :RAID Array
c: consola Deploys admin.exe config.exe
<<RS-232>>
356
Usos comunes
Modelado de
Sistemas Embebidos Sistemas Cliente / Servidor Sistemas Distribuidos
357
INTRODUCCIN AL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

Jorge Kashiwamoto
358
Panormica general
Conocer la existencia de una propuesta de proceso unificado de desarrollo Conocer la arquitectura del proceso de desarrollo Apreciar la importancia, ventajas y desventajas de este tipo de proceso de desarrollo
359
Metodologa
LENGUAJE
V.g.: UML
PROCESO
V.g.: Rational Unified Process
HERRAMIENTA
V.g.: Rose
360
PROCESO
Elementos de Proyecto
Fases Etapas Mtodos Tcnicas y Prcticas
Que las personas realizan para desarrollar y mantener software con sus artefactos asociados
361
RUP
Rational Unified Process
Proceso unificado de desarrollo de software
Caractersticas
Proceso de Desarrollo de Software Dirigido por Casos de Uso Centrado en la Arquitectura Iterativo e Incremental
362
Iterativo e Incremental
Inception
Elaboration
Transition
Construction
363
Rational Unified Process (RUP)

Objectory Process y otros (Dic98)
4 Fases 9 Flujos de Trabajo Iteraciones
364
RUP
365
Trabajadores (Workers)
Personas que participan en el proceso
Tienen competencias especficas

En cada flujo de trabajo
Worker
366
Trabajadores (2)
1. Analista de Sistemas 2. Especificador de Casos de Uso
3. Arquitecto
4. Ingeniero de Casos de Uso 5. Ingeniero de Componentes 6. Integrador de Sistemas 7. Diseador de Pruebas 8. Ingeniero de Pruebas de Integracin 9. Ingeniero de Pruebas del Sistema
367
Analista de Sistemas
Responsable del conjunto de requisitos modelados en los casos de uso
Requisitos funcionales y no funcionales
Delimitar el sistema
Analista de Sistemas Flujos de Trabajo Requerimientos
Encontrar actores y casos de uso
Asegurar modelos de casos de uso completos y consistentes

Elaborar un glosario para mantener la consistencia semntica Dirigir el modelado Coordinar la captura de requisitos
368
Especificador de Casos de Uso

Responsable de la descripcin detallada de un caso de uso Establecer una comunicacin estrecha y eficaz con los usuarios (directos) Especificador de C.U. Flujos de Trabajo Requerimientos
369
Diseador de Interfaces
Disear las interfaces de usuario
Aspecto visual
Diseador de Interfaces Flujos de Trabajo Requerimientos
Desarrollar prototipos de interfaces de usuario para algunos casos de uso
370
Arquitecto
Requerimientos
Describir la arquitectura y prioridades del modelo de casos de uso
Anlisis
Garantizar la integridad del modelo de anlisis
Arquitecto
Correcto, consistente y legible
Flujos de Trabajo Diseo Garantizar la integridad de los modelos de Requerimientos diseo y despliegue Anlisis Implantacin Diseo Garantizar la integridad del modelo de Implantacin implantacin
Asignar componentes a nodos
371
Ingeniero de Casos de Uso

Anlisis
Mantener la integridad de las realizaciones de casos de uso
Diseo Ingeniero de C.U. Flujos de Trabajo Anlisis Diseo

Detallar las realizaciones de casos de uso Verificar la correspondencia entre anlisis y diseo
372
Ingeniero de Componentes
Anlisis
Definir y mantener las responsabilidades, atributos, relaciones y requisitos especiales de una o varias clases del anlisis
Diseo
Ingeniero de Componentes
Definir y mantener las operaciones, mtodos, atributos, relaciones y requisitos de implantacin de una o ms clases del diseo
Flujos de Trabajo Implantacin Definir y mantener el cdigo fuente de uno o Anlisis varios componentes Diseo Pruebas Implantacin Desarrollar componentes de prueba que Pruebas
automatizan algunos de los procedimientos de prueba
373
Integrador de Sistemas
Planificar la secuencia de construcciones necesarias en cada iteracin Integrador de Sistemas Flujos de Trabajo Implantacin
374
Integrar cada construccin a partir de sus partes implementadas
Diseador de Pruebas
Garantizar la integridad del modelo de pruebas Planear las pruebas Diseador de Pruebas Flujos de Trabajo Pruebas
Establecer objetivos de prueba apropiados
Seleccionar y describir casos de prueba y los procedimientos de prueba
375
Ingeniero de Pruebas de Integracin

Ejecutar las pruebas de integracin Verificar el correcto funcionamiento de componentes Ing. de Pruebas Documentar los defectos de Integracin Flujos de Trabajo Pruebas
376
Ingeniero de Pruebas del Sistema

Ejecutar las pruebas del sistema para cada iteracin completa Verificar los resultados en conjunto con los usuarios finales Ing. de Pruebas del Sistema Flujos de Trabajo Pruebas Documentar los defectos Facilidad para tener familiaridad con el comportamiento observable del sistema
377
Ventajas de un Proceso
Process Know-How Toma de Decisiones Estadarizacin Calidad y Mejores prcticas Mantenimiento Control de Complejidad Control de Proyecto
Reduccin de Costos
378
Ventajas de RUP
Aplicacin de Principios de Ingeniera
Desarrollo
Iteratividad Orientado a Requerimientos Basado en Arquitectura
Retroalimentacin
Prototipado
Definicin de Producto
379
Desventajas de RUP
Solamente es un Proceso No tiene Soporte Multiproyecto Influencia de los Fabricantes de Herramientas Carencias en:
Mtrica Reuso Control de Personal
Control de Pruebas
380

Analisis y Diseo Orientado A Objetos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analisis y Diseo Orientado A Objetos

Enviado por

Direitos autorais:

Formatos disponíveis

ANLISIS Y DISEO ORIENTADO A OBJETOS (ADOO) CON UML

Panormica general del curso (1)

Captulo 2: Historia de la orientacin a objetos

Panormica general del curso (2)

Captulo 8: Modelo de diseo (diagramas de estado)

Captulo 12: Modelo de implantacin (diagramas de deployment)

Panormica general del curso (2)

Panormica general del curso (3)

En clase se presentarn algunos ejemplos para facilitar la comprensin de la elaboracin de diagramas.

Material de consulta (1)

Anlisis y Diseo Orientado a Objetos con UML Versin 3.0

Material de consulta (2)

notation guide. Version 1.1.

Rational Software, 1997. UML

semantics. Version 1.3.

Material de consulta (3)

Evaluacin del curso

TRATAMIENTO DE LA COMPLEJIDAD Y LA ORIENTACIN A OBJETOS

Tratamiento de la complejidad y descomposicin Descomposicin orientada a procesos y a objetos

Los sistemas tienen:

Origen de la complejidad de los sistemas

No se comprende el sistema en su totalidad

4 razones para la complejidad (Grady Booch)

2 razn.- Complejidad de los procesos:

4 razones para la complejidad (Grady Booch)

5 atributos de los sistemas complejos (Grady Booch)

5 atributos de los sistemas complejos (Grady Booch)

Con esta tcnica se solventa la restriccin impuesta por el lmite de Miller

Descomposicin orientada a procesos (OP)

Descomposicin orientada a objetos (OO)

Recomendacin para el tratamiento de la complejidad

HISTORIA DE LA ORIENTACIN A OBJETOS

Un ejemplo es la metodologa estructurada

Alcanz su pico de popularidad entre 1985-1989

La vida media para las tecnologas de IS

Aspectos histricos (1)

Aspectos histricos (2)

Aspectos histricos (3)

Aspectos histricos (4)

Aspectos histricos (5)

Smalltalk-72 Smalltalk-74 Pascal C

Object Cobol Java

Mediados de los 1990s (1)

La tecnologa de BDOO tiene un xito sin precedente

Mediados de los 1990s (2)

Mediados de los 1990s (3)

Mediados de los 1990s (4)

OMT Rumbaugh et al.

State Charts Harel

SOMA Graham Team Fusion Coleman et al.

MOSES Henderson-Sellers RD Shalaer/Mellor

A finales de los 1990s

Existe un crecimiento significante (y explosivo) de tecnologas basadas en la orientacin a objetos

Lo que se ha aprendido (1)

Lo que se ha aprendido (2)

Lo que se ha aprendido (3)

Lo que se ha aprendido (4)

CONCEPTOS DE LA ORIENTACIN A OBJETOS

Jorge Kashiwamoto / Alejandro Domnguez

Herencia y herencia mltiple

Paradigma de la ORIENTACIN A OBJETOS

Determinado marco conceptual

Apropiado para el desarrollo de aplicaciones comnes